From nobody Thu Mar 1 05:08:24 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757BD126D85; Thu, 1 Mar 2018 05:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHSI_Tc1VC0o; Thu, 1 Mar 2018 05:08:20 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486D9126D45; Thu, 1 Mar 2018 05:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6908; q=dns/txt; s=iport; t=1519909700; x=1521119300; h=from:to:cc:subject:date:message-id:mime-version; bh=QryMJIQ+XkQ38cit0dmLCs3C0TUoSDLvf8+tPYorYGo=; b=aZtMfcQTN7Bbu8V0q4AsfnKq8G7dOs91Twh8HdSPRyjjeFAWe4pcs40X DHdm75fWx85jYB9clOJCPgEZaKwYbo8HIuAcRHng6oJmFCH2ipFc3uTkq rgNKFlkFjtgvtTSjFDWXqR4fbx7y6SgU6LVoVMbs5WWyvHq10Fj8jWmou E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AgAk+pda/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJadmZwKAqDSpgVgVuBPY8MhSCCFQojhQ0cgkMhNhYBAgEBAQE?= =?us-ascii?q?BAQJrKIVNVhIBSgIEMCcEAQ2EPGQQqxOCJyaIQYIWAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWHTYFXgg8MhiYCAgEYgTODMDCCMgWIN5IhCQKBUoR+iiiOdol7hys?= =?us-ascii?q?CERkBgS0BJQIvgVJwFWQBghiEWncBi2+BFwEBAQ?= X-IronPort-AV: E=Sophos; i="5.47,408,1515456000"; d="scan'208,217"; a="77302381" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2018 13:08:19 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w21D8Jnj001911 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Mar 2018 13:08:19 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 1 Mar 2018 08:08:18 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 1 Mar 2018 08:08:17 -0500 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" , "v6ops@ietf.org WG" CC: "draft-ietf-opsec-v6.authors@ietf.org" , "erey@ernw.de" Thread-Topic: What is new in draft-ietf-opsec-v6-13.txt ? Thread-Index: AQHTsV5d1CvXh4YmeEu9TUqIp+knmg== Date: Thu, 1 Mar 2018 13:08:17 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.12] Content-Type: multipart/alternative; boundary="_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_" MIME-Version: 1.0 Archived-At: Subject: [v6ops] What is new in draft-ietf-opsec-v6-13.txt ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 13:08:23 -0000 --_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIGEgbG90IG9mIGNoYW5nZXMgaW4gdGhlIC0xMyB2ZXJzaW9uLCBtYW55IG1pbm9y IGFuZCBhIGNvdXBsZSBvZiBiaWdnZXIgb25lcyAoc3VjaCB0aGUgVUxBIHNlY3Rpb24pLiBBIG5l dyBhdXRob3IsIEVubm8gUmV5LCBoYXMgam9pbmVkIHRoZSB0ZWFtIGFuZCBoYXMgcHJvdmlkZWQg YSB0cmVtZW5kb3VzIGFtb3VudCBvZiBzdWdnZXN0aW9ucy9jaGFuZ2VzLiBXZSBhbHNvIGhhdmUg YWN0ZWQgb24gdGhlIGNvbW1lbnRzIGZyb20gT2xlIFRyb2FuLCBSb24gQm9ubmljYSwgQmVybmll IFZvbHosIEZlcm5hbmRvIEdvbnQgYW5kIEVyaWsgS2xpbmUuDQoNCkFzIHVzdWFsIHlvdSBjYW4g Y29tcGFyZSB0aGUgdmVyc2lvbnMgd2l0aDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtb3BzZWMtdjYtMTMudHh0DQoNClRoZSBhdXRob3JzIHdpbGwgd2Vs Y29tZSByZXZpZXdzIGFuZCBjb21tZW50cyBlc3BlY2lhbGx5IG9uIHRoZSBuZXcgc2VjdGlvbiAy LjEuMiAoVXNlIG9mIFVMQXMpOiB0aGlzICd1Z2x5JyB0b3BpYyBuZWVkcyB0byBiZSBpbiB0aGlz IGRvY3VtZW50IGFuZCBubyBhdXRob3Igd2FudHMgdG8gcmVjb21tZW5kIGl0IG9idmlvdXNseSA7 LSkNCg0KT25lIG9wZW4gcG9pbnQgaXMgd2hhdCB0byBkbyB3aXRoICdtb3N0bHkgb2Jzb2xldGUn IHR1bm5lbGluZyBzdWNoIGFzIFRlcmVkbyBhbmQgNnRvNCA/IE9sZSB3YW50cyB0byByZW1vdmUg dGhvc2Ugc2VjdGlvbnMgY29tcGxldGVseSBidXQgdGhlIGF1dGhvcnMgZmVlbCB0aGF0IHdlIG5l ZWQgdG8ga2VlcCB0aGVtIHRvIGJlIGV4aGF1c3RpdmUuDQoNClNhbWUgZm9yIHRoZSBDR04gKE5B VDQ0NCkgc2VjdGlvbiwgbm90IHJlYWxseSBhbiBJUHY2IHRvcGljLCBidXQgYW4gaW1wb3J0YW50 IHJlbGF0ZWQtb25lIGFuZCB0aGUgZG9jdW1lbnQgaXMgaW4gT1BTRUMgV0cgKHdoaWNoIGlzIHBy b3RvY29sIHZlcnNpb24gYWdub3N0aWMpLg0KDQpUaGFuayB5b3UgaW4gYWR2YW5jZSBhbmQgc2Vl IHlvdSBpbiBMb25kb24NCg0KLcOpcmljDQo= --_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1142C9D42D61BA4F8A49306493BEE553@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ VGhlcmUgYXJlIGEgbG90IG9mIGNoYW5nZXMgaW4gdGhlIC0xMyB2ZXJzaW9uLCBtYW55IG1pbm9y IGFuZCBhIGNvdXBsZSBvZiBiaWdnZXIgb25lcyAoc3VjaCB0aGUgVUxBIHNlY3Rpb24pLiBBIG5l dyBhdXRob3IsIEVubm8gUmV5LCBoYXMgam9pbmVkIHRoZSB0ZWFtIGFuZCBoYXMgcHJvdmlkZWQg YSB0cmVtZW5kb3VzIGFtb3VudCBvZiBzdWdnZXN0aW9ucy9jaGFuZ2VzLg0KIFdlIGFsc28gaGF2 ZSBhY3RlZCBvbiB0aGUgY29tbWVudHMgZnJvbSBPbGUgVHJvYW4sIFJvbiBCb25uaWNhLCBCZXJu aWUgVm9seiwgRmVybmFuZG8gR29udCBhbmQgRXJpayBLbGluZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFzIHVzdWFsIHlvdSBjYW4gY29tcGFyZSB0aGUgdmVy c2lvbnMgd2l0aDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNlYy12Ni0xMy50eHQiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzZWMtdjYtMTMudHh0PC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGF1dGhvcnMgd2ls bCB3ZWxjb21lIHJldmlld3MgYW5kIGNvbW1lbnRzIGVzcGVjaWFsbHkgb24gdGhlIG5ldyBzZWN0 aW9uIDIuMS4yIChVc2Ugb2YgVUxBcyk6IHRoaXMgJ3VnbHknIHRvcGljIG5lZWRzIHRvIGJlIGlu IHRoaXMgZG9jdW1lbnQgYW5kIG5vIGF1dGhvciB3YW50cyB0byByZWNvbW1lbmQgaXQgb2J2aW91 c2x5IDstKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T25lIG9w ZW4gcG9pbnQgaXMgd2hhdCB0byBkbyB3aXRoICdtb3N0bHkgb2Jzb2xldGUnIHR1bm5lbGluZyBz dWNoIGFzIFRlcmVkbyBhbmQgNnRvNCA/IE9sZSB3YW50cyB0byByZW1vdmUgdGhvc2Ugc2VjdGlv bnMgY29tcGxldGVseSBidXQgdGhlIGF1dGhvcnMgZmVlbCB0aGF0IHdlIG5lZWQgdG8ga2VlcCB0 aGVtIHRvIGJlIGV4aGF1c3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5TYW1lIGZvciB0aGUgQ0dOIChOQVQ0NDQpIHNlY3Rpb24sIG5vdCByZWFsbHkgYW4g SVB2NiB0b3BpYywgYnV0IGFuIGltcG9ydGFudCByZWxhdGVkLW9uZSBhbmQgdGhlIGRvY3VtZW50 IGlzIGluIE9QU0VDIFdHICh3aGljaCBpcyBwcm90b2NvbCB2ZXJzaW9uIGFnbm9zdGljKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rIHlvdSBpbiBhZHZh bmNlIGFuZCBzZWUgeW91IGluIExvbmRvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+LcOpcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_B4FE0D9445064FA0970FB0343A718D8Aciscocom_-- From nobody Thu Mar 1 09:11:09 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1733212EB78 for ; Thu, 1 Mar 2018 09:11:08 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNUlkU-c2nbP for ; Thu, 1 Mar 2018 09:11:04 -0800 (PST) Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) (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 AE67612EB79 for ; Thu, 1 Mar 2018 09:11:03 -0800 (PST) X-AuditID: d9a97918-55fff70000006b07-c3-5a9834231db6 Received: from TELMBXB06RM001.telecomitalia.local ( [10.14.252.35]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id B8.13.27399.324389A5; Thu, 1 Mar 2018 18:10:59 +0100 (CET) From: Fioccola Giuseppe To: Tom Herbert , "Van De Velde, Gunter (Nokia - BE/Antwerp)" CC: "v6ops@ietf.org WG" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt Thread-Index: AQHTrwdzxFtAa/T71keSxFrfEUiteqO2vQsAgABjl4CAABJBgIAArkOAgAKXhgCAASX6EA== Date: Thu, 1 Mar 2018 17:10:59 +0000 Message-ID: References: <151965246238.31386.1515320046883185252.idtracker@ietfa.amsl.com> <2549744f-4d30-76f2-e48e-72c79f15016a@gmail.com> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.247] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsXCxfdHWVfZZEaUwY/rBhZvF/9gtLh86RGz xelje5kdmD16505j9Viy5CeTx91bl5gCmKMaGG0S8/LySxJLUhVSUouTbZVcMouTcxIzc1OL FEJSc1KT83OVFDJTbJWMlRQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpecn5KZl66 rZJnsL+uhYWppa6hkl1gaWpxSb5CbmpxcWJ6ema+QmrCesGMt68OMRWstK1Ys+IzawPjV8Mu Rk4OCQETiSlzn7F1MXJxCAlMYZKYt/cBC0iCTcBG4uCrE2wgtohAicTalo2MIDazgIbE3N2N YHFhgQSJC3unMUPUJEksXL+BFcIOk/h8ZQ4TiM0ioCKx/tE19i5GDg5egUCJlS/lIXbtYZZY fHcSWC8nUHz3zUaw+YwCshITdi+C2iUu8WL6CXaIQwUkluw5zwxhi0q8fPyPFcI2kNi6dB8L hK0osbp5PhOELSOx8MhkVog5ehI3pk5hg7C1JZYtfA02h1dAUOLkzCcsExjFZiFZNwtJyywk LbOQtCxgZFnFKJpbYWCiVwKJv8ySxJzMRL3Mkk2MwBRyc2WlxA7G7rXOhxgFOBiVeHi/6syI EmJNLCuuzD3EKMHBrCTCe3r7tCgh3pTEyqrUovz4otKc1OJDjD7AEJvILCWanA9Mb3kl8YYm FpaGxhYWRoYWZqY4hJXEeTdKAY0XSAcmsOzU1ILUIphxTBycUg2MDssltTk2t/y7zFj9xvj4 pg9CbuF/k2c9Tlvz9vvLS7sCf/vIb21VDds+4dV90/mMmSXLywWOT1c+9Fq2a8vmbTdipL4/ UOKRe3R+U909IX3lVykHFv08cmhH2489U2Ie3m6e0d3VVvV+Sc7Hf/ZJd85f6tGIb/+0dor3 r4o3/9mOMyefCf8+Y7USS3FGoqEWc1FxIgCxTvHgTgMAAA== Archived-At: Subject: [v6ops] R: FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:11:08 -0000 Hi Tom, Thanks for your feedbacks! My answers inline tagged as [GF]. Giuseppe -----Messaggio originale----- Da: v6ops [mailto:v6ops-bounces@ietf.org] Per conto di Tom Herbert Inviato: gioved=EC 1 marzo 2018 01:25 A: Van De Velde, Gunter (Nokia - BE/Antwerp) Cc: v6ops@ietf.org WG Oggetto: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-i= pv6-alt-mark-00.txt On Tue, Feb 27, 2018 at 12:50 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Indeed, the proposal would leave 18 bits for entropy (worst case is that 2= bits are used for Alternate marking according the Alternate marking standar= d). > > An important aspect to keep in mind that is about the outer header of the= tunneled traffic, and not the payload inside IPv6 headers. These outer tunn= el headers do not always reach the DC because they are removed by the DCI or= ASBR when sending traffic beyond. > > The motivation that triggered this work is the passive measurement of MBH= traffic in a pure IPv6 underlay environment. This is area where specialized= HW (name your preferred network device vendor) is active, and these routers= can use flowlabel in any form to generate entropy. It is a nodal capability= and is under control of the operator to configure on or not to configure. I'm not sure a standard Internet protocol could be based on assumptions that= only specialized HW is used, or that all devices support a feature that has= not been standardized (i.e. applying a mask to flow label for ECMP). [GF]: A mask to flow label for ECMP is only a possibility. > > Yes, it is an important operational consideration, to document that the ap= plication domain of this draft, if not done so yet. > Another question I have concerns this purported benefit: "Less bits on the wire (going SRv6 has already a significant bits-on-wire ta= x because of the outer IPv6 header and the SRv6 EH)." The "significant on-the-wire tax" is at least something like 64 bytes (IP hd= r + SR header + 1 SID)! The passive measurement requires a grand total of tw= o bits and is always used in conjunction with SR AFAICT. Wouldn't it be easier to just put these two bits somewhere in the segment ro= uting EH instead of redefining a standard field in IPv6 header with sematics= that have long been applied in deployment? [GF]: I understand your point. For now it seems we focus only on SRv6 and fl= ow label field but this is only an Use Case we considered as a consequence o= f our experiment (as described in RFC 8321). This new version of the draft d= oes not give a unique solution but aims to analyze the several alternatives= that can be taken into consideration for the choice of the marking field (E= xtension Header, IPv6 Address, Flow Label). Our intent is to understand, tog= ether with v6OPS WG, which is the better way to apply this technology to IPv= 6. Tom > G/ > > -----Original Message----- > From: Brian Carpenter [mailto:becarpenter46@gmail.com] On Behalf Of > Brian E Carpenter > Sent: Monday, February 26, 2018 23:27 > To: Tom Herbert ; Van De Velde, Gunter (Nokia - > BE/Antwerp) > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] FW: New Version Notification for > draft-fioccola-v6ops-ipv6-alt-mark-00.txt > > On 27/02/2018 10:21, Tom Herbert wrote: >> On Mon, Feb 26, 2018 at 7:24 AM, Van De Velde, Gunter (Nokia - >> BE/Antwerp) wrote: >>> Hi All, >>> >>> This is a new draft to document the usage of Alternate Marking in native= IPv6 networks when IPv6 tunnels are used (i.e. when SRv6 is used). Feedback= on the work is welcome. >>> >> >> Hi, >> >> I believe the following requirement contradicts flow label solution >> having "easier backward compatibility": >> >> "The methodology SHOULD be used within a controlled domain where the >> load-balancing based on flow label is disabled. Otherwise, the >> network elements MUST mask the Mark Field (MF), so it will not change >> hashing calculation for the same flow because only 18 bits + 2 zeros >> can be used for the entropy." >> >> RFC6438 states that the flow label for ECMP occupies the full 20 bits >> and that "The same flow label value MUST be used for all packets in a >> single user flow". There is no concept of a mask in that RFC and not >> all network elements support a flow label mask (Linux does not for >> instance), so the default solution will be to disable flow label for >> load-balancing. That is unfortunate in itself, but since extension >> headers are in use there may be devices in the network that don't >> parse over extension headers to find transport ports for the hash, so >> load-balancing with flow granularity may be lost as a result. > > Well, I haven't read the new draft yet, but from earlier discussion > with Gunter and his colleagues, I believe their proposal would leave > 19 bits of entropy in the flow label, with just one bit forced to zero, wh= en the packet *leaves* the domain. I think that does give enough entropy for= flow-label based ECMP to operate well *outside* the domain. The same would= apply to server load-balancing (RFC7098). > However, as far as I can see, this technique definitely creates problems f= or a site that relies internally on ECMP or server load-balancing. > > Brian > >> >> Tom >> >>> G/ >>> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, February 26, 2018 14:41 >>> To: Giuseppe Fioccola ; Van De >>> Velde, Gunter (Nokia - BE/Antwerp) ; >>> Muley, Praveen (Nokia - US/Mountain View) ; >>> Mauro Cociglio >>> Subject: New Version Notification for >>> draft-fioccola-v6ops-ipv6-alt-mark-00.txt >>> >>> >>> A new version of I-D, draft-fioccola-v6ops-ipv6-alt-mark-00.txt >>> has been successfully submitted by Giuseppe Fioccola and posted to the I= ETF repository. >>> >>> Name: draft-fioccola-v6ops-ipv6-alt-mark >>> Revision: 00 >>> Title: IPv6 Performance Measurement with Alternate Marking Meth= od >>> Document date: 2018-02-26 >>> Group: Individual Submission >>> Pages: 9 >>> URL: https://www.ietf.org/internet-drafts/draft-fioccola-v6op= s-ipv6-alt-mark-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-fioccola-v6ops-ip= v6-alt-mark/ >>> Htmlized: https://tools.ietf.org/html/draft-fioccola-v6ops-ipv6-al= t-mark-00 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-fioccola-v6o= ps-ipv6-alt-mark-00 >>> >>> >>> Abstract: >>> This document describes how the alternate marking method can be used >>> as the passive performance measurement method in an IPv6 domain, and >>> will discuss the strengths and the weaknesses of the implementation >>> options available to network operations. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submis= sion until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Thu Mar 1 09:28:15 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2EC12EBA3 for ; Thu, 1 Mar 2018 09:28:13 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEKdWt6u79mr for ; Thu, 1 Mar 2018 09:28:11 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 6961B12EBA9 for ; Thu, 1 Mar 2018 09:28:11 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id y6so8510902qtm.7 for ; Thu, 01 Mar 2018 09:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3go95WcUm471uwBElia0rAjsQ0D8uh959iQcXbRQ2IQ=; b=D9iHtFtJBera/RwnHVX3zCYNB86y/RriaEPvsGs7TTXPCV/F8so3NeknDUN84gNcn7 LsRyUJKkmv5XiPLhMO6KxONk74IrXF6XxoZ0/DeY5w4ZLxbJW+3gcJK/O1zE65EpHaJH uma6NxM9rcN1/FLrEthIEvBAk9KPgkpsnXaOMB8GWtiER2yWLGlXG0qXbWyGQsgzFoQ0 W1u8cVQ1vwlDvHwbGtsHO7GWL2frNfYOcD1WiGBiS+2BXLXp0Iu1HCFpWPWE/vLlUApP a9xoQHFAVr0NaRlEYtLG7/jc6KnAINlA/394n4f0KEbC8GbD1XyKKpuFwK0C0MRnoFKW J7cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3go95WcUm471uwBElia0rAjsQ0D8uh959iQcXbRQ2IQ=; b=JKj96R1BRco8G4jNV28mOIZgI94IKBPRLQpyubzx9BZ95JdkqaAcMOyrt+/ZdLf3YG Fs79jiXQbN4TtoGaJFfkiwiZP6MTy26xkfKfFUwsaW9uHH2fgtN77s0+/hG7gW84kwB5 H10HCVmze2nLaiXQvXLNoF97yX7KAdjhHXUObw1uLtjkaF4WLuDxkGUVM0/oXLplBqEH VKJG7buXwwN0oJYeIQp1+BVGUySP48RkDWjQueyJteqhwUwsdPenxpQt2Lt4t4ToaGJ2 R7M03xyYt+FX0oxkTVP9ZEkk0uL31FFZ/q30Y5E85BLjab+tM0yJLwPCLM/TvpO8khaX 5tNw== X-Gm-Message-State: AElRT7Hk3FpNIIOchTVR4K84EVisMGW5J4HPCIBsMo5IwQC5Bni1UNO2 qT42k69ObXYzL8QfLvHrkIoKBD4IZ5/L0BBTuqKT1Q== X-Google-Smtp-Source: AG47ELvbgvHB+deUOnKtsS5mczkhWYuqCW7hZvKiwyc/7UC6J/U+0TxbQe5w0sZKtCtzOXMh2nDKaHfu32pwXWvphxQ= X-Received: by 10.200.52.73 with SMTP id v9mr4111454qtb.66.1519925290276; Thu, 01 Mar 2018 09:28:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Thu, 1 Mar 2018 09:28:09 -0800 (PST) In-Reply-To: References: <151965246238.31386.1515320046883185252.idtracker@ietfa.amsl.com> <2549744f-4d30-76f2-e48e-72c79f15016a@gmail.com> From: Tom Herbert Date: Thu, 1 Mar 2018 09:28:09 -0800 Message-ID: To: Fioccola Giuseppe Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:28:13 -0000 On Thu, Mar 1, 2018 at 9:10 AM, Fioccola Giuseppe wrote: > Hi Tom, > Thanks for your feedbacks! > My answers inline tagged as [GF]. > > Giuseppe > > -----Messaggio originale----- > Da: v6ops [mailto:v6ops-bounces@ietf.org] Per conto di Tom Herbert > Inviato: gioved=C3=AC 1 marzo 2018 01:25 > A: Van De Velde, Gunter (Nokia - BE/Antwerp) > Cc: v6ops@ietf.org WG > Oggetto: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6op= s-ipv6-alt-mark-00.txt > > On Tue, Feb 27, 2018 at 12:50 AM, Van De Velde, Gunter (Nokia - > BE/Antwerp) wrote: >> Indeed, the proposal would leave 18 bits for entropy (worst case is that= 2 bits are used for Alternate marking according the Alternate marking stan= dard). >> >> An important aspect to keep in mind that is about the outer header of th= e tunneled traffic, and not the payload inside IPv6 headers. These outer tu= nnel headers do not always reach the DC because they are removed by the DCI= or ASBR when sending traffic beyond. >> >> The motivation that triggered this work is the passive measurement of MB= H traffic in a pure IPv6 underlay environment. This is area where specializ= ed HW (name your preferred network device vendor) is active, and these rout= ers can use flowlabel in any form to generate entropy. It is a nodal capabi= lity and is under control of the operator to configure on or not to configu= re. > > I'm not sure a standard Internet protocol could be based on assumptions t= hat only specialized HW is used, or that all devices support a feature that= has not been standardized (i.e. applying a mask to flow label for ECMP). > > [GF]: A mask to flow label for ECMP is only a possibility. > >> >> Yes, it is an important operational consideration, to document that the = application domain of this draft, if not done so yet. >> > Another question I have concerns this purported benefit: > > "Less bits on the wire (going SRv6 has already a significant bits-on-wire= tax because of the outer IPv6 header and the SRv6 EH)." > > The "significant on-the-wire tax" is at least something like 64 bytes (IP= hdr + SR header + 1 SID)! The passive measurement requires a grand total o= f two bits and is always used in conjunction with SR AFAICT. > Wouldn't it be easier to just put these two bits somewhere in the segment= routing EH instead of redefining a standard field in IPv6 header with sema= tics that have long been applied in deployment? > > [GF]: I understand your point. For now it seems we focus only on SRv6 and= flow label field but this is only an Use Case we considered as a consequen= ce of our experiment (as described in RFC 8321). This new version of the dr= aft does not give a unique solution but aims to analyze the several alterna= tives that can be taken into consideration for the choice of the marking fi= eld (Extension Header, IPv6 Address, Flow Label). Our intent is to understa= nd, together with v6OPS WG, which is the better way to apply this technolog= y to IPv6. > Okay, then I think you may want to add a couple of alternatives to the draf= t: 1) Adding a field to an existing proposed EH (e.g. SRv6) instead of defining a new EH. 2) Using a field from an extensible encapsulation, such as GUE, to carry the passive measurement bits. This technique was discussed at length in nvo3. The intended status should also be informational I would think. Thanks, Tom From nobody Thu Mar 1 11:19:06 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C90312EE45 for ; Thu, 1 Mar 2018 11:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4dqdxcTECmk for ; Thu, 1 Mar 2018 11:19:03 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F88D12ECCE for ; Thu, 1 Mar 2018 11:19:03 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id z9so14213861wmb.3 for ; Thu, 01 Mar 2018 11:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=v842KNfc3flcObEPW+5Ego87ZO0Gk0RxelNDde6cxUw=; b=esFUjuFtP+aRm47XtW/3S8PglmBxf1k3I7O+gDCqcNBkrtHMCUp60cXBCYzLw964E3 epC/gNEuyAc8jQd1kwRHFXkx1eQVtOSuSqxXV4QZd4ACHIcPHb0oFFzYJa0cB/kjxELT oMGVC9IRDDtaJfAPmuFc2jenqqkEyOQCsKAsnXkCydARn17Fl2iWwuK7kdGEW/Y19Kjq 2g6NUQevtUoam8+b+ZJkqqe0a6NygXjUiaBDBOqI7wPpKQL+nSZKJEbsCzqYfHrigD32 70rXZqFKMLUa+B9hUD1zaV8emba6nZqmrOuDjJYj9m8nQyJxoV4eYePOsOu5a8Wfqqz0 vazA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=v842KNfc3flcObEPW+5Ego87ZO0Gk0RxelNDde6cxUw=; b=XzFIVzNQPj7Q0skoXjOdKBkx1136srK+F1x5Pew5gSaG58fIyHTOCtjxn2B4g+Q8wL sAI3CpaKcdr4TSQmb1+m5qPq+mpIDjBQ8M8BNQb55w+CTj3e+uLVsbanU6Rw1sy0W7Ym CiC25G/lS35bEVDV2lu/aWt8k0mmI7kiC8vsxDF34GyLvgED0Xyq8JsPGaxPv09/TLA+ RyCqP8Uh44sPs1BFPwS854NHonjZLwpTYAEWS5cmtUbUeLX8EgdTLoWyMZ8CArcvKspn fLOqtHXqzYhpUH+Q2D8tCQb7A3DP3xaZmC0VHXuK8M/TFLez7L3Gxh172xFQbutn4uya o4+g== X-Gm-Message-State: APf1xPB89GPR0sM5uf37fprf83A/1FLk2uovMbptzOmMPgkpcMuuvwmN P6veJ+WpzPDvVdKnoZKG8U2NacpP X-Google-Smtp-Source: AG47ELu6HoJXi9vHMXicTHyorPoEvTjbUuy2z6eaznqWW4vSsMhZlp3GMQ/23Xfwr+7/8Jq8+DZcKA== X-Received: by 10.28.50.69 with SMTP id y66mr2839838wmy.35.1519931941529; Thu, 01 Mar 2018 11:19:01 -0800 (PST) Received: from ?IPv6:2600:8801:d004:600:a8a8:e5c7:9943:dcf1? ([2600:8801:d004:600:a8a8:e5c7:9943:dcf1]) by smtp.gmail.com with ESMTPSA id o10sm4230395wra.12.2018.03.01.11.18.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 11:19:00 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_299F62D0-DADD-4142-9EAF-82F4638B8458"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.11\)) Date: Thu, 1 Mar 2018 11:18:57 -0800 References: <708322BD-310E-478E-B5BA-91C61A839968@gmail.com> To: V6 Ops List In-Reply-To: <708322BD-310E-478E-B5BA-91C61A839968@gmail.com> Message-Id: <58E1BBA9-E944-43FF-AF51-2ED0223B23DB@gmail.com> X-Mailer: Apple Mail (2.3445.6.11) Archived-At: Subject: Re: [v6ops] V6ops status this morning X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 19:19:05 -0000 --Apple-Mail=_299F62D0-DADD-4142-9EAF-82F4638B8458 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft cut-off for IETF 101 is Monday, and the chairs will be = preparing an agenda next week. We need to hear from you regarding it. At this point, we have: - an invited talk from Mythical Beasts, an IPv6-preferred data center = in London - two working group drafts, both of which have been updated in the = past two months. I have asked for an update to ipv6rtr pursuant to the review done = in January. - draft-fioccola-v6ops-ipv6-alt-mark, which is a report on Telecom = Italia's use of RFC 8321 measurements - draft-templin-v6ops-pdhost - five draft-palet-* drafts that I'm told will be updated this = weekend. - AOB - 2.5 hours Monday morning What we need from you is any thoughts you might have about what of the = above is interesting and useful. > On Mar 1, 2018, at 11:09 AM, Fred Baker = wrote: >=20 > Correction. We heard from Pete Stevens of Mythical Beasts, and he is = preparing a talk. >=20 >> On Mar 1, 2018, at 11:03 AM, Fred Baker = wrote: >>=20 >> WG: Updated WG Document >> 2018-02-27 draft-ietf-v6ops-conditional-ras >> 2018-01-02 draft-ietf-v6ops-ipv6rtr-reqs >>=20 >> Individual Submission: Unupdated >> 2017-10-30 draft-palet-v6ops-ipv6-only >> 2017-10-30 draft-shytyi-v6ops-danir >> 2017-10-29 draft-palet-v6ops-he-reporting >> 2017-10-29 draft-palet-v6ops-p2p-from-customer-prefix >> 2017-10-17 draft-palet-v6ops-rfc7084-bis-transition >> 2017-10-17 draft-xli-v6ops-cernet-deployment >> 2017-10-09 draft-palet-v6ops-464xlat-deployment >> 2017-08-28 draft-xu-v6ops-dslite-redundancy >>=20 >> Individual Submission: Updated >> 2018-02-26 draft-fioccola-v6ops-ipv6-alt-mark >> 2017-12-19 draft-templin-v6ops-pdhost >>=20 >> Russ has updated ipv6rtr, and Gunter has filed = draft-fioccola-v6ops-ipv6-alt-mark. Jordi tells me (us?) that he intends = to revise and re-file each of his drafts; I have told him that agenda = placement is dependent on email commentary in the working group. >>=20 >> draft-fioccola-v6ops-ipv6-alt-mark is essentially an operational = commentary on the use of RFC 8321 measurement in Telecom Italia's = network. https://datatracker.ietf.org/doc/rfc8321/, = https://tools.ietf.org/html/rfc8321 >>=20 >> I have queried the Mythical Beasts guy a couple of times and gotten = no response. Absent a response, I don't think we schedule him. >=20 --Apple-Mail=_299F62D0-DADD-4142-9EAF-82F4638B8458 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlqYUiEACgkQEhdRnd2G P+Cqgg/6Axyav9bv4sOf6vXUzWjZbB8kkN/WB2JcPeXa/xJEuQWb6hlgUHD6qmAe aDbuDNdJX8b/mLwUvoC3LsCEplP7cauF8gT4zsdL/oVx4yIH1PGjks2Im1WGYqpX ZVUpt7yUh/JPDITD16H4NdvKo55NHtKFnaXhEbPY6aK6P2XJoux9xhU1KhqGeHMN 3GWBv7w+1uytI8n8rSBXrWmOBLAQHCTcBFS+wi/MByuVNcvWxEqsrQhqRxBCkjpC T982JwWsebDnjUZ4izzCIqr6pwGctfkKEopIdr7oUD7vZb7CNtsvOOYOYianM+72 c6xWGGYpTJX79DBiL4pA5XI0FSt7ofPXd75oWEA5ngMOYBqyhEO4HOanfpjfjdqL 6EPMvUUoTPQx9sI2vn+g6PKx0Z3Pbo3jNrWtyOIZadGwQxzy2bxj1C2aww/iQpWm VTKyZ9rGqYZ9E4vP6aX8yUJf6GE8z1gr7R2FkOw7dip8tHCCrskya7eFUSTPkrwg cLKuOmDB/5yKeGncUnFY22A0MNsScrqAFP4U1j52taSaUf5oRW1H639rmikqUYvM vJtPV0CNJug2rEWIkT2OCAcXO9hr3Yo1BIM3OJ+5/XXKS9y7k4Y9JFbesrHfyYbw OuYpUSo9S+EHX2TcXVTlsA6ipAQN7ovDIWZDx6Yv7llm8prWWDY= =OwtU -----END PGP SIGNATURE----- --Apple-Mail=_299F62D0-DADD-4142-9EAF-82F4638B8458-- From nobody Thu Mar 1 11:48:04 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD8112F4DC for ; Thu, 1 Mar 2018 11:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpw73LcPxUYF for ; Thu, 1 Mar 2018 11:47:55 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e: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 1211112F4DB for ; Thu, 1 Mar 2018 11:47:55 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id y8so2746698pgr.9 for ; Thu, 01 Mar 2018 11:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YwC2Oul904FliL38tBm3IxGCPy1jTZ3fe8RM2TgVCbQ=; b=ZJ8Wl+9HUVh5hyM5+IwVsmfhWJ538gXFEQZC2NKXysDfXwjQgh1nxLaftokFpdDt2d YXVYFRfH6nQI3tWMb4W3NuX+QIC3MkY5AgO53qWYIZlKRFv8k4UBH27oyjIIn220/Rfd fbpTNqGra339fEvBHVTJ2UZR+Bc0JhrVnW3CMNTxPofpgJtK/G7b6I5Da73XqEHLoVAJ lpwNa0IH2vY2hNvjs26jCRy1C00jrs0fE5xV5PSNAbWCPL/biuBVYt1OWFfqc2q6ASUZ zmhgxD/S8WMnM0GOTewmPc9pT/tbdDAMhFyjWykLhXqQnMD1HRX/gzKvP3pMYh+jkuEb naxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YwC2Oul904FliL38tBm3IxGCPy1jTZ3fe8RM2TgVCbQ=; b=o36JbhDhNq1d3qlgR5j2MiRCOh+YL6T3sp4Q2elkltO0bawSChwjIoextFtE6fiNfi v7B2I7a14hvS7yq+gBuV6zTITUTPJPtEe8qWAlGwjiDdmflzEAm/62x8uR2SfEhDFuHV EXE5WJfFr2/JVELC02cwTU4pLUz6C8/5/F64AzK66oeAamhOJQrm92iBbdB+6Wm0qZxI jh6vIDr+dBfV56OqQdHer87tNQl5LO6HnB5ljh6qIbwZc1KK9x0kREhiFO89zU7fKYzF SBuhcTphiFL1YjgDzehepx0JbMEZRBWOmCsHm7EleN/M4uTW4fF1aBhcIIuvrkSgDCqJ Gc2A== X-Gm-Message-State: APf1xPC1rkTNPPYhKpmlnJ4eoNd2GXVBHGtD/y9K7t4MNXobIg+TVPpq hZzXpkOa8ZxDY3goIhqSpMY= X-Google-Smtp-Source: AG47ELsYqtkkSep37I5P03Wx8EgP6XSjUgCgBxw8Hly1FPP43+mn7c2KWexU8NqqKf35yrmLrVhRFA== X-Received: by 10.98.108.2 with SMTP id h2mr3054686pfc.43.1519933674546; Thu, 01 Mar 2018 11:47:54 -0800 (PST) Received: from [192.168.43.75] ([118.148.131.111]) by smtp.gmail.com with ESMTPSA id q17sm8584352pgt.7.2018.03.01.11.47.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 11:47:53 -0800 (PST) Sender: Brian Carpenter To: Tom Herbert Cc: Fioccola Giuseppe , "v6ops@ietf.org WG" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" References: <151965246238.31386.1515320046883185252.idtracker@ietfa.amsl.com> <2549744f-4d30-76f2-e48e-72c79f15016a@gmail.com> From: Brian E Carpenter Message-ID: <899847f0-aa36-8a5d-929e-e03172f8385b@gmail.com> Date: Fri, 2 Mar 2018 08:27:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 19:47:57 -0000 > The intended status should also be informational I would think. Yes, that seems right to me - it's a description of possible practice that is sort-of compatible with the existing standard if carefully deployed. Actual standardisation of bits in the IPv6 header belongs in 6MAN, but remembering the heavy lifting involved in the present flow label standard, IMHO this would be hard to achieve. Brian On 02/03/2018 06:28, Tom Herbert wrote: > On Thu, Mar 1, 2018 at 9:10 AM, Fioccola Giuseppe > wrote: >> Hi Tom, >> Thanks for your feedbacks! >> My answers inline tagged as [GF]. >> >> Giuseppe >> >> -----Messaggio originale----- >> Da: v6ops [mailto:v6ops-bounces@ietf.org] Per conto di Tom Herbert >> Inviato: gioved=C3=AC 1 marzo 2018 01:25 >> A: Van De Velde, Gunter (Nokia - BE/Antwerp) >> Cc: v6ops@ietf.org WG >> Oggetto: Re: [v6ops] FW: New Version Notification for draft-fioccola-v= 6ops-ipv6-alt-mark-00.txt >> >> On Tue, Feb 27, 2018 at 12:50 AM, Van De Velde, Gunter (Nokia - >> BE/Antwerp) wrote: >>> Indeed, the proposal would leave 18 bits for entropy (worst case is t= hat 2 bits are used for Alternate marking according the Alternate marking= standard). >>> >>> An important aspect to keep in mind that is about the outer header of= the tunneled traffic, and not the payload inside IPv6 headers. These out= er tunnel headers do not always reach the DC because they are removed by = the DCI or ASBR when sending traffic beyond. >>> >>> The motivation that triggered this work is the passive measurement of= MBH traffic in a pure IPv6 underlay environment. This is area where spec= ialized HW (name your preferred network device vendor) is active, and the= se routers can use flowlabel in any form to generate entropy. It is a nod= al capability and is under control of the operator to configure on or not= to configure. >> >> I'm not sure a standard Internet protocol could be based on assumption= s that only specialized HW is used, or that all devices support a feature= that has not been standardized (i.e. applying a mask to flow label for E= CMP). >> >> [GF]: A mask to flow label for ECMP is only a possibility. >> >>> >>> Yes, it is an important operational consideration, to document that t= he application domain of this draft, if not done so yet. >>> >> Another question I have concerns this purported benefit: >> >> "Less bits on the wire (going SRv6 has already a significant bits-on-w= ire tax because of the outer IPv6 header and the SRv6 EH)." >> >> The "significant on-the-wire tax" is at least something like 64 bytes = (IP hdr + SR header + 1 SID)! The passive measurement requires a grand to= tal of two bits and is always used in conjunction with SR AFAICT. >> Wouldn't it be easier to just put these two bits somewhere in the segm= ent routing EH instead of redefining a standard field in IPv6 header with= sematics that have long been applied in deployment? >> >> [GF]: I understand your point. For now it seems we focus only on SRv6 = and flow label field but this is only an Use Case we considered as a cons= equence of our experiment (as described in RFC 8321). This new version of= the draft does not give a unique solution but aims to analyze the severa= l alternatives that can be taken into consideration for the choice of the= marking field (Extension Header, IPv6 Address, Flow Label). Our intent i= s to understand, together with v6OPS WG, which is the better way to apply= this technology to IPv6. >> >=20 > Okay, then I think you may want to add a couple of alternatives to the = draft: >=20 > 1) Adding a field to an existing proposed EH (e.g. SRv6) instead of > defining a new EH. > 2) Using a field from an extensible encapsulation, such as GUE, to > carry the passive measurement bits. This technique was discussed at > length in nvo3. >=20 > The intended status should also be informational I would think. >=20 > Thanks, > Tom >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Mar 1 15:52:48 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133B9126FDC for ; Thu, 1 Mar 2018 15:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdE1S4C27cJm for ; Thu, 1 Mar 2018 15:52:43 -0800 (PST) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::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 C7C471270A3 for ; Thu, 1 Mar 2018 15:52:43 -0800 (PST) Received: by mail-pl0-x22a.google.com with SMTP id m22-v6so1078184pls.5 for ; Thu, 01 Mar 2018 15:52:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PfwLHRma7wNBbPegOc9PMiUQeAiSAuMOWZSy3a0+8gA=; b=JcWpAGpl7aqIr/tsqKkkt7YqX8viJY34JSDaxh2f7wucu45kIdfVXhIt6n6g3Aya9C quzGJmSXvbt5unGfK4Mu/lWsWRoisLBOy6LLjz2iRbJJLsvQ+OYktAlvs/NFzwANA2PV wtZQOjJP+f9OGICNLvRP4XiGX+uM0o0KkyVCZit54hFLIndmsHDPPy7a11JkTCZ4TyBg fSpJ8uih183trX67U3dOrmNVBJNQ3GuLKeYa9w+d0OMwSczy4E+zJWZeoAb/HMrtER7s bVcV4BYXS2R8pBGtkAr6Krr5+NI6xZK6M+2ZSz+zGvjneGLNHVol924iTyYN38P9GYSg thrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PfwLHRma7wNBbPegOc9PMiUQeAiSAuMOWZSy3a0+8gA=; b=IxYkFlHTFTLtk+epsWomfNiO79I/1Vdwqr6X68kJYcXudQ80T+4IwYVXDAWiAOt/xV Epu10063qJCP77GdHezFNWXj8tYuiaFuuYtilJN/rn2jGtwtzrGct+1s22Bmp2xjiCrl jZZSvtC4tf/hYK5gvWi1MrozcNnlfzkMsRbwiQmAVYAw8aLxXaXlGqnNpjfAsor0/VRz Jyj3HYhZnjA1siZ9sQOUGYTbZEr2Ll6NwDGWp4IKPIZCg1thdx7GSGowY2+w05WiAbT6 BoC/xkUFkX+rWwefpBQFURTatI9RH/tm4HnPP9lowr+4piFatoxqSeK27lQet3ofK9bt SJBw== X-Gm-Message-State: APf1xPBRDyNcEf81Vc3yZZvm6ZyxVh/3tfRa3SPwmktCdjVyAmBO5zS2 CYyaHsw8foV8iD0r7aVZ9+I= X-Google-Smtp-Source: AG47ELvWovvNKPTX37t4zhk2T1f4Ng1pY7CLvX16CmRgxZmIUJKxIBrSxzZ6779p5d7Vx2OeSR4exg== X-Received: by 2002:a17:902:6c06:: with SMTP id q6-v6mr3521200plk.142.1519948363452; Thu, 01 Mar 2018 15:52:43 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d186sm10484136pfd.1.2018.03.01.15.52.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 15:52:42 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5A934405-0B57-4A13-A5FB-4D4444768A7C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 1 Mar 2018 15:52:40 -0800 In-Reply-To: Cc: Bob Hinden , Fioccola Giuseppe , "v6ops@ietf.org WG" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tom Herbert References: <151965246238.31386.1515320046883185252.idtracker@ietfa.amsl.com> <2549744f-4d30-76f2-e48e-72c79f15016a@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 23:52:46 -0000 --Apple-Mail=_5A934405-0B57-4A13-A5FB-4D4444768A7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>=20 >=20 > Okay, then I think you may want to add a couple of alternatives to the = draft: >=20 > 1) Adding a field to an existing proposed EH (e.g. SRv6) instead of > defining a new EH. > 2) Using a field from an extensible encapsulation, such as GUE, to > carry the passive measurement bits. This technique was discussed at > length in nvo3. >=20 > The intended status should also be informational I would think. Or Experimental, given that RFC 8321 that this appears to be based on is = Experimental. Also, this should only reference RFC8200, not RFC8200 and RFC2460. The = latter was obsoleted by RFC8200. Thanks, Bob >=20 > Thanks, > Tom >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_5A934405-0B57-4A13-A5FB-4D4444768A7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlqYkkgACgkQrut0EXfn u6iHrQf+PCf/asuferWCm/kmAKxWTa9D1+OzlT/V4JxnsklwpUq/O1Uq+TilrKqT U/18HrahoYjleQO8QMFKsBNA20rYFU1Jv5+gvjurgNpofji6UOS1oh6VC65scxoV /0HZDcD8G4rKe9P/OfdUo0nD1iU9RIcJ9DGEE3cZzzG+KV3n47nN1xnbQmn2lkga 8iupMHe7dQaEatwUDwcJWqHUSyHXQFs5ybR6f+PRR/lMo7r8lgpa3mCTj0JX8JBi Ml/g77URW+mvO0QeUzjLy2mHLOWSHbB3D0U+E1vnLBqJxtqngXB9MmkG/GG3UVE+ K2tXjVutcPCNQn4DRdxAhg1guAnufw== =2z7h -----END PGP SIGNATURE----- --Apple-Mail=_5A934405-0B57-4A13-A5FB-4D4444768A7C-- From nobody Fri Mar 2 08:21:40 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5106012D7E8 for ; Fri, 2 Mar 2018 08:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpefOQqgI-a9 for ; Fri, 2 Mar 2018 08:21:37 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 339D4129C6D for ; Fri, 2 Mar 2018 08:21:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GFAACxeJla/wUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ8IzFmcCgKjW2NeYICgRaULYFTQgolhQsCgmEhNBgBAgEBAQE?= =?us-ascii?q?BAQIDaCeCazwDDCEHAi8BAQEBAQEBAQEBAQEBHAIPLxIBARgBAQEBAxIoNBcEA?= =?us-ascii?q?gEIDQEDBAEBAQoUCQcyFAkIAgQBEggTB4R5AQ+ec40XIQKIQIIrhSyCKYFYgWS?= =?us-ascii?q?DLoMuAgIBGIESHSkkgxWCMgSaXgkChlCMEk6DZ4MPhU2JfIdZgS4eOSaBLHAVG?= =?us-ascii?q?SGCQwmEP3cBAYl8B4EqAYEXAQEB?= X-IPAS-Result: =?us-ascii?q?A2GFAACxeJla/wUHmMZdGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?8IzFmcCgKjW2NeYICgRaULYFTQgolhQsCgmEhNBgBAgEBAQEBAQIDaCeCazwDD?= =?us-ascii?q?CEHAi8BAQEBAQEBAQEBAQEBHAIPLxIBARgBAQEBAxIoNBcEAgEIDQEDBAEBAQo?= =?us-ascii?q?UCQcyFAkIAgQBEggTB4R5AQ+ec40XIQKIQIIrhSyCKYFYgWSDLoMuAgIBGIESH?= =?us-ascii?q?SkkgxWCMgSaXgkChlCMEk6DZ4MPhU2JfIdZgS4eOSaBLHAVGSGCQwmEP3cBAYl?= =?us-ascii?q?8B4EqAYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.47,412,1515474000"; d="scan'208";a="271397397" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Mar 2018 11:21:34 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2018 11:21:34 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 11:21:33 -0500 From: "Mudric, Dusan (Dusan)" To: Jen Linkova , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt Thread-Index: AQHTsAUtisLDvvf/pkypsJNLkuJmW6O4/8GAgAQQT3A= Date: Fri, 2 Mar 2018 16:21:32 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.130.24 dlp-reaction: no-action x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 16:21:39 -0000 Hi, In Abstract: "The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic." Should be: "The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires the hosts to select the correct source address based on a destination address for that traffic,=20 the hosts to select a first hop router based on the packet source address, and the network to select the correct egress ISP based o= n the packet source address" This introduction would be more suited for Figures 2&3. If not, please clar= ify the intent of the draft. 3.2.1. Single Router, Primary/Backup Uplinks What "if{packet_destination_address is in 2001:db8:1::/48 or 2001:db8:2::/4= 8}"? Will the next hop still be determined by the source address? If yes, i= s the destination address check needed? 3.2.2. Two Routers, Primary/Backup Uplinks Similar as above.=20 Why would R1 have a policy that sends a packet to "next-hop is ISP_B_uplink= ", if it does not talk to ISP_B? With R1 and R2 policies, H1 would have only one prefix all the time. How wi= ll H1 do load balancing or send one application stream over ISP_A and anoth= er over ISP_B, if needed? Maybe the first sentence needs to state that only= one ISP can be used. 3.2.3. Single Router, Load Balancing Between Uplinks If load balancing is used, R1 sends packets to an ISP_x based on the source= address. This means the host must know which ISP (source address) to selec= t. How does host know this? 3.2.5. Topologies with Dedicated Border Routers "For load-balancing case ... prefix 2001:db8:2:1::/64 { if ISP_B_uplink_route is present then preferred_lifetime =3D 0 else preferred_lifetime =3D 604800 }" Is this just copy and paste from the NON-load-balancing policy? Why would H= 1 use 2001:db8:2:1::/64 if "ISP_B_uplink_route is NOT present" and send tra= ffic over R2 - R3 - ISP_A with 2001:db8:2:1::x source address? Page 10: Typo: "trgger" Regards, Dusan Mudric. > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova > Sent: Tuesday, February 27, 2018 3:03 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt >=20 > The draft (draft-ietf-v6ops-conditional-ras)has been updated to > address comments received in Singapore. >=20 > Any feedback is appreciated, especially if you have any suggestions on > how to improve the document. >=20 > On Wed, Feb 28, 2018 at 6:57 AM, wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the IPv6 Operations WG of the IETF. > > > > Title : Using Conditional Router Advertisements for E= nterprise > Multihoming > > Authors : Jen Linkova > > Massimiliano Stucchi > > Filename : draft-ietf-v6ops-conditional-ras-01.txt > > Pages : 17 > > Date : 2018-02-27 > > > > Abstract: > > This document discusses most common scenarios of connecting an > > enterprise network to multiple ISPs using an address space assigned > > by an ISP. The problem of enterprise multihoming without address > > translation of any form has not been solved yet as it requires both > > the network to select the correct egress ISP based on the packet > > source address and hosts to select the correct source address based > > on the desired egress ISP for that traffic. > > [I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to > > this problem by introducing a new routing functionality (Source > > Address Dependent Routing) to solve the uplink selection issue and > > using Router Advertisements to influence the host source address > > selection. While the above-mentioned document focuses on solving th= e > > general problem and on covering various complex use cases, this > > document describes how the solution proposed in > > [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limite= d > > number of common use cases. In particular, the focus is on scenario= s > > where an enterprise network has two Internet uplinks used either in > > primary/backup mode or simultaneously and hosts in that network migh= t > > not yet properly support multihoming as described in [RFC8028]. > > > > > > The IETF datatracker status page for this draft is: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dconditional- > 2Dras_&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhI > oUWB8YLZU23029sMQGQ2kY&m=3DTvwolb891s9E__RcQ05Srqho90KVleyHRFiv > eiJiW4g&s=3D4GiE9981xqO7DwH-RffXvRXuxwZGkG_QrwoHaFUVsc4&e=3D > > > > There are also htmlized versions available at: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dconditional-2Dras- > 2D01&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > UWB8YLZU23029sMQGQ2kY&m=3DTvwolb891s9E__RcQ05Srqho90KVleyHRFive > iJiW4g&s=3D1q5WZlStkpgafuIZcNyITzCYHMR9sxnxPjqRsanSv0w&e=3D > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dconditional- > 2Dras- > 2D01&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > UWB8YLZU23029sMQGQ2kY&m=3DTvwolb891s9E__RcQ05Srqho90KVleyHRFive > iJiW4g&s=3D3Yki_IS8Q3O9n3vWhd8JTcchlcUF0_8nCIMTKUFeBc8&e=3D > > > > A diff from the previous version is available at: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dconditional- > 2Dras- > 2D01&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIo > UWB8YLZU23029sMQGQ2kY&m=3DTvwolb891s9E__RcQ05Srqho90KVleyHRFive > iJiW4g&s=3DEzOsCZBnjl_2C2UOT7sBNzyvAVc7XN7ULjrSXwlcL34&e=3D > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_inter= net- > 2Ddrafts_&d=3DDwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iC > rhIoUWB8YLZU23029sMQGQ2kY&m=3DTvwolb891s9E__RcQ05Srqho90KVleyHR > FiveiJiW4g&s=3Dk-4jLyp-ruXqFPp_GKnLNTWz_VXishJWQtLDfIixeFU&e=3D > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DTvwol > b891s9E__RcQ05Srqho90KVleyHRFiveiJiW4g&s=3DjY0VQvQFNS1fCWqzD1ewRO > p807KXejHGqSOM79nXAWA&e=3D >=20 >=20 >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DTvwol > b891s9E__RcQ05Srqho90KVleyHRFiveiJiW4g&s=3DjY0VQvQFNS1fCWqzD1ewRO > p807KXejHGqSOM79nXAWA&e=3D From nobody Fri Mar 2 10:57:03 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8CE1242F5 for ; Fri, 2 Mar 2018 10:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzyUsDTdZ2xp for ; Fri, 2 Mar 2018 10:57:00 -0800 (PST) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF18A124217 for ; Fri, 2 Mar 2018 10:56:59 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2FBA843725 for ; Fri, 2 Mar 2018 19:56:57 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 231114195A; Fri, 2 Mar 2018 19:56:57 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 14F5A328B5; Fri, 2 Mar 2018 19:56:57 +0100 (CET) Date: Fri, 2 Mar 2018 19:56:57 +0100 From: Gert Doering To: "Mudric, Dusan (Dusan)" Cc: Jen Linkova , "v6ops@ietf.org" Message-ID: <20180302185656.GT56288@Space.Net> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> X-NCC-RegID: de.space User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 18:57:02 -0000 Hi, On Fri, Mar 02, 2018 at 04:21:32PM +0000, Mudric, Dusan (Dusan) wrote: > In Abstract: > > "The problem of enterprise multihoming without address > translation of any form has not been solved yet as it requires both > the network to select the correct egress ISP based on the packet > source address and hosts to select the correct source address based > on the desired egress ISP for that traffic." > > Should be: > "The problem of enterprise multihoming without address > translation of any form has not been solved yet as it requires > the hosts to select the correct source address based > on a destination address for that traffic, > the hosts to select a first hop router based on the packet > source address, and the network to select the correct egress ISP based on the packet > source address" Actually the new text is completely missing the point. Source address selection *for a destination address* is something already addressed nicely (RFC6724). Selecting the right source address *to select the egress ISP to use* is the part not addressed in host stacks at all yet. The network part "select egress based on proper source address" is halfway solved with the homenet protocol suite (source address dependent babel, hncp, etc.) - but that is stuff not usually found on Enterprise routers. 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 2 14:29:39 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC5912D876 for ; Fri, 2 Mar 2018 14:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5mSZOodjhHl for ; Fri, 2 Mar 2018 14:29:20 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 C8F8212D7F1 for ; Fri, 2 Mar 2018 14:29:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2H6AAAnz5la/wUHmMZeGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ8VIFWKAqNbY16ggKBFpQtghUKhTACgmEhNBgBAgEBAQEBAQI?= =?us-ascii?q?DaCeFJAEBAQEDEig/DAQCAQgNBAQBAQEKFAkHMhQJCAIEDgUIGoR5AZ81jRchA?= =?us-ascii?q?ohFgiuFLIIpgViFEoUjgzmCMgSaXgkCmiaFTZFVgS4eOYFScBWCfYRId4skAYE?= =?us-ascii?q?XAQEB?= X-IPAS-Result: =?us-ascii?q?A2H6AAAnz5la/wUHmMZeGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?8VIFWKAqNbY16ggKBFpQtghUKhTACgmEhNBgBAgEBAQEBAQIDaCeFJAEBAQEDE?= =?us-ascii?q?ig/DAQCAQgNBAQBAQEKFAkHMhQJCAIEDgUIGoR5AZ81jRchAohFgiuFLIIpgVi?= =?us-ascii?q?FEoUjgzmCMgSaXgkCmiaFTZFVgS4eOYFScBWCfYRId4skAYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.47,414,1515474000"; d="scan'208";a="234430713" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Mar 2018 17:29:16 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2018 17:29:16 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0352.000; Fri, 2 Mar 2018 17:29:14 -0500 From: "Mudric, Dusan (Dusan)" To: Gert Doering CC: Jen Linkova , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt Thread-Index: AQHTslhDclx4oiwf+kCK4BGrRHE5GaO9g8Xw Date: Fri, 2 Mar 2018 22:29:13 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> In-Reply-To: <20180302185656.GT56288@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.130.24 dlp-reaction: no-action x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 22:29:32 -0000 " hosts to select the correct source address based > on the desired egress ISP for that traffic." will not work in the load sharing example. Unlike the router, when the host= has two prefixes it does not know which one is 'desired'. Possible option = is to assign a prefix preference in RA. "Actually the new text is completely missing the point. Selecting the right= source address *to select the egress ISP to use* is the part not addressed in host stacks at all yet" If so, the draft needs to make it clear. The underlined assumption is that = the host selected the right source address and the router uses that address= to send a packet to a right ISP. Regards, Dusan. > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Friday, March 02, 2018 1:57 PM > To: Mudric, Dusan (Dusan) > Cc: Jen Linkova; v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt >=20 > Hi, >=20 > On Fri, Mar 02, 2018 at 04:21:32PM +0000, Mudric, Dusan (Dusan) wrote: > > In Abstract: > > > > "The problem of enterprise multihoming without address > > translation of any form has not been solved yet as it requires both > > the network to select the correct egress ISP based on the packet > > source address and hosts to select the correct source address based > > on the desired egress ISP for that traffic." > > > > Should be: > > "The problem of enterprise multihoming without address > > translation of any form has not been solved yet as it requires > > the hosts to select the correct source address based > > on a destination address for that traffic, > > the hosts to select a first hop router based on the packet > > source address, and the network to select the correct egress ISP bas= ed on > the packet > > source address" >=20 > Actually the new text is completely missing the point. Source address > selection *for a destination address* is something already addressed > nicely (RFC6724). >=20 > Selecting the right source address *to select the egress ISP to use* is > the part not addressed in host stacks at all yet. >=20 > The network part "select egress based on proper source address" is halfwa= y > solved with the homenet protocol suite (source address dependent babel, > hncp, etc.) - but that is stuff not usually found on Enterprise routers. >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Mar 2 21:39:01 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC50124D37 for ; Fri, 2 Mar 2018 21:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNpfVrjv4ZJV for ; Fri, 2 Mar 2018 21:38:58 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD0D120724 for ; Fri, 2 Mar 2018 21:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1520055534; x=1520660334; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=wBBNkwt0 /RSvcOAH6mt1ZG48HYmsKbtSaTBqx2Sowcg=; b=rv/6iqw8BOFOoe7ysuCSCpGw 4xUhheFT+Dq8+cwJeHrgOi99qpJxdpQp6s7ghzoDRwkE1WF9os/TCVHAddPZFx4h d5y+XGdEhtljhEcCX5m9IilaF7mAcjU3GPuM51SY+92lPmjQAwLAwNLQVctF/FeM 7aq9cJFjRfb+T0T5iIo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 03 Mar 2018 06:38:54 +0100 X-Spam-Processed: mail.consulintel.es, Sat, 03 Mar 2018 06:38:54 +0100 Received: from [172.16.0.173] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005716937.msg for ; Sat, 03 Mar 2018 06:38:53 +0100 X-MDRemoteIP: 10.8.10.10 X-MDHelo: [172.16.0.173] X-MDArrival-Date: Sat, 03 Mar 2018 06:38:53 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1600606fd9=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.a.0.180210 Date: Sat, 03 Mar 2018 11:23:39 +0545 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: New Version Notification for draft-palet-v6ops-transition-ipv4aas-00.txt References: <152005484345.8242.10067695209281528559.idtracker@ietfa.amsl.com> In-Reply-To: <152005484345.8242.10067695209281528559.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 05:39:00 -0000 Hi all, I just posted this document, together with my co-author Hans M.-H. Liu from= D-Link. Transition Requirements for IPv6 Customer Edge Routers to support IPv4 as a= Service https://datatracker.ietf.org/doc/draft-palet-v6ops-transition-ipv4aas/?incl= ude_text=3D1 It is replacing all the previous draft-palet-v6ops-rfc7084-bis* documents, = following the recommendations of the last v6ops meeting. In summary: 1) The document "extends" RFC7084 transition mechanism to ensure the suppor= t of IPv4 as a Service if there is IPv6-only in the WAN link. 2) Follows the same structure in terms of "requirements" as RFC7084. 3) It is clearly stated that the document doesn't recommend one or the othe= r mechanism. 4) Defines how automated provisioning can choose one or another mechanism. 5) Explains the reasons for requiring the IPv4aaS. 6) Explains that we include support for several mechanisms, because all the= m have the same data plane and share code. 7) Defines usage scenarios and end-user network architecture, in order to s= et the stage compared with those in RFC7084. Regards, Jordi =20 =EF=BB=BF-----Mensaje original----- De: Fecha: s=C3=A1bado, 3 de marzo de 2018, 11:12 Para: "Hans M.-H. Liu" , Jordi Palet Martinez , Jordi Martinez , Hans Liu Asunto: New Version Notification for draft-palet-v6ops-transition-ipv4aas-0= 0.txt =20 A new version of I-D, draft-palet-v6ops-transition-ipv4aas-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-transition-ipv4aas Revision: 00 Title: Transition Requirements for IPv6 Customer Edge Routers to suppo= rt IPv4 as a Service Document date: 2018-03-02 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= transition-ipv4aas-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-tran= sition-ipv4aas/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-transitio= n-ipv4aas-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -transition-ipv4aas-00 =20 =20 Abstract: This document specifies the transition requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider o= r thru the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" ([RFC7084]) in order to allow the provisionin= g of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS) by means of new transition mechanisms, which where not available at the time [RFC7084] was published. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called IPv4 "as-a-service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sun Mar 4 17:19:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65593124C27 for ; Sun, 4 Mar 2018 17:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPGRrEY2qU-F for ; Sun, 4 Mar 2018 17:19:33 -0800 (PST) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9721201FA for ; Sun, 4 Mar 2018 17:19:32 -0800 (PST) Received: by mail-pl0-x22b.google.com with SMTP id v9-v6so8750981plp.12 for ; Sun, 04 Mar 2018 17:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:from:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=GOlKXmGLu+AMsUEeE1WnT+X0SWXLdRYShXoq6Jol7vE=; b=cDvrib+LP6nRBnCl4gG+FAORI+AtoB00YQz2z7+TP2QcS6cxRakcEnAJy3GN+H5kXT 7luk+IgTtpHhOtvQys2sg19xvfXgxXBAogyBmVYf3Cy0Y5+uuszVI5fIc0cG1mRaVXoQ S0vLtVMMGsz+OtEVJyBaFyHjOy+LJEsJpuibY7V6AcpeM59oOUzeD4jWpmmRBn6ETlEY xYwRvVw3AsHhBUWe+yzV7iNwpbkWhANQQcrLUDA6WWghE1+XFXTD5axticd/XXOeCkVd 8KL4nMitkVGXxDDlJANyQrzWArMF/aGks/flfNqFPWoio2ajJcMVDOeiK1hwVcig4GJY iWEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:from:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=GOlKXmGLu+AMsUEeE1WnT+X0SWXLdRYShXoq6Jol7vE=; b=gP1qZlKZQEp8tTYEdwQ5TgTls+1Kx8TpZEfmj1oadQ9czxel17RLMafqETwiGAiCZ/ 8uUmS2lz3ycP/IFNYRarYV6jWXNN/vg0tUmmIfOPXuNNnJJgqRYkFFFBvNEki4yO1PMl euxJvJ/MMVEJGXSyoyVkwT3EIikCyhx+D89iik9hgO68XBgsod7cY9otaEntOnUpWQH/ gN6q+gOFOdhHWLqcddPjgOWDI/P8xHHMADQyLMgdNtmd0UvSM/7WAl7QsOsBFIV7MXyo 5iwTTOzZdtHSOarPD2NI1Zg6y0I428/WAZoF6lxEL06TcsB2szlI2rHGeQdLBOBV1xNh +W1w== X-Gm-Message-State: AElRT7E/fTtsrQYIa5ULNY8q7nbzkoBTD/RInn/oK71fofn6JbjmCXHB USnSh4tZd7PTm7lOc3fjcxA+Fmrr X-Google-Smtp-Source: AG47ELvtlQDIJpmWtH26UEXCr9dMoQebk2Mf/Y5rVm1ILAi39s139mRttUetznlEokvUAiHI7ikhzA== X-Received: by 2002:a17:902:6943:: with SMTP id k3-v6mr4340566plt.214.1520212771941; Sun, 04 Mar 2018 17:19:31 -0800 (PST) Received: from [192.168.182.31] ([114.23.138.211]) by smtp.gmail.com with ESMTPSA id l12sm24191530pfb.35.2018.03.04.17.19.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Mar 2018 17:19:31 -0800 (PST) Sender: Brian Carpenter To: IPv6 Operations From: Brian E Carpenter Message-ID: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> Date: Mon, 5 Mar 2018 14:19:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and_?= =?utf-8?q?cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 01:19:34 -0000 Success at last :-) http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_evidence_and_surveillance/ Regards Brian From nobody Sun Mar 4 17:59:09 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF12124D6C for ; Sun, 4 Mar 2018 17:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaCxLz6rykjA for ; Sun, 4 Mar 2018 17:59:07 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5A2124C27 for ; Sun, 4 Mar 2018 17:59:06 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id w77so15627369wrc.6 for ; Sun, 04 Mar 2018 17:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bTIEJSJuaxQz0h3n4t6iYK6TionXStRFLSXsz+X3GDw=; b=nHRaLS1+R2cy47uCGe/kXvbRiq+3Xpj1whTnOvCUBewaS0wvE2GRsQhbERN2JXu5l4 EVFoKIEY2JtgxM85cac6Tag5XY7KV1IEBG3gvWYFwQPMex1y/PtHgTZIYSMg7NWDfkpE XfHLDw9eXXwufgq7hUKSuTkgstVNbReAQUSTxjJCwrEj35CzvNvY7cwKulrdzckxM+40 cJdedp+NJrDrluVlXhmTJHGqsE0dQ50nHkFFPyKlOqDYPIHYj6VkzekYztU8V7Kl7RdX RCC/y26Woe8pCPgyg2bnOcwGCbCTp1rsFKWXS84G7TG+IGZVXla7Nx//AqCiUiawmXy5 /H5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bTIEJSJuaxQz0h3n4t6iYK6TionXStRFLSXsz+X3GDw=; b=j6lfiN+UqlgxoC3QTddodj6AATjnRvjmgAF5t6udMU8jIyKa3Bruy7plbq4h33PAje TvPwEH+EIWxxbh78WEruVWq+opJhM1EHvn6vqFpvYoINoAh6CW0rLb0X4T+4cMGNbfwi Qp1DcCywdg3L4lF/c5d0NW21QNEuDhPb8+kAg0Sxm/Y+YvZCmcOb/cGeU3Pvqg6KzHEy RM1fLs4fV/iKDbpqEo3KfD5M8ucDsJpjdJaqRdNi8ugllQNHtAmQedr/Dkml7iZk+LZF etAqD8ys/aNCS++lDladWe0xd/ViFPJuk1JqdTslQ0mA1Qmv59oZ7OwR3mvaOxIgv12w zDlg== X-Gm-Message-State: APf1xPCrsm4XMF04GOBp9GkA/oGnxJ6cZCfoQ7+3lIAhE6B1uCMK0PMj hpiMO4e0X3vfW1EtoSVRK3dkBMO0bpZEqmTqav8= X-Google-Smtp-Source: AG47ELuE6AplgQXx5Z10tTZySfj29rJ+KY3KduCbS70npNt/WvGvbJoc3yukC/sPTxO237bxr5Z1W0a/NIEN4zQtGP0= X-Received: by 10.223.171.13 with SMTP id q13mr11483400wrc.183.1520215145211; Sun, 04 Mar 2018 17:59:05 -0800 (PST) MIME-Version: 1.0 References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> In-Reply-To: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> From: Ca By Date: Mon, 05 Mar 2018 01:58:54 +0000 Message-ID: To: Brian E Carpenter Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="94eb2c1b50bab66dfe0566a0ab82" Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 01:59:08 -0000 --94eb2c1b50bab66dfe0566a0ab82 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 4, 2018 at 5:19 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Success at last :-) > > > http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_evidence_and_surveillance/ > > Regards > Brian > Sad the Australian government is subject to this level of missinformation. They essentially copied some ill conceived dogmas from 2003 and ignored practical deployments. 1. Encryption has nothing to do with ipv6, full stop. As a practical matter, ipv6 means nothing for crypto. Modern day consumer crypto is a layer 7 matter (https) 2. The idea that ipv6 reduces attribution is literally ludicris. No elaboration needed. I have first hand knowledge in this space. Also sad that El Reg progates this misinformation. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c1b50bab66dfe0566a0ab82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Mar 4, 2018 a= t 5:19 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Success at last :-)

http:= //www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_evidence_an= d_surveillance/

Regards
=C2=A0 =C2=A0Brian

Sad the Australi= an government is subject to this level of missinformation. =C2=A0 They esse= ntially copied some ill conceived dogmas from 2003 and ignored practical de= ployments.=C2=A0

1. Encr= yption has nothing to do with ipv6, full stop. As a practical matter, ipv6 = means nothing for crypto.=C2=A0 Modern day consumer crypto is a layer 7 mat= ter (https)

2.=C2=A0 The= idea that ipv6 reduces attribution is literally ludicris. No elaboration n= eeded. I have first hand knowledge in this space.=C2=A0

Also sad that El Reg progates this misinfor= mation.=C2=A0


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--94eb2c1b50bab66dfe0566a0ab82-- From nobody Sun Mar 4 18:15:16 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC03C124D6C for ; Sun, 4 Mar 2018 18:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R8Sb4--6Knm for ; Sun, 4 Mar 2018 18:15:14 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 6D1DE124B0A for ; Sun, 4 Mar 2018 18:15:14 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D21DE3AB001; Mon, 5 Mar 2018 02:15:11 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 93EDE160069; Mon, 5 Mar 2018 02:15:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 75E32160068; Mon, 5 Mar 2018 02:15:11 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OqTQLxdRr7wb; Mon, 5 Mar 2018 02:15:11 +0000 (UTC) Received: from [172.30.42.66] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id AA9C7160064; Mon, 5 Mar 2018 02:15:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Mon, 5 Mar 2018 13:15:07 +1100 Cc: Brian E Carpenter , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> To: Ca By X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 02:15:16 -0000 You missed the point. Technically illiterate government bodies are now = paying attention to IPv6. It=E2=80=99s gone mainstream. The AGD = repeatedly demonstrates this level of technical illiteracy. Now if they were to mandate that ISP=E2=80=99s had to hand out /48=E2=80=99= s to customers to reduce the processing load that might be a good thing = overall (there are pros and cons). It=E2=80=99s this mis-mash of prefix = sizes that makes attributing a IPv6 address to a customer harder, not = the number of addresses. Mark > On 5 Mar 2018, at 12:58 pm, Ca By wrote: >=20 >=20 > On Sun, Mar 4, 2018 at 5:19 PM Brian E Carpenter = wrote: > Success at last :-) >=20 > = http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_evide= nce_and_surveillance/ >=20 > Regards > Brian >=20 > Sad the Australian government is subject to this level of = missinformation. They essentially copied some ill conceived dogmas = from 2003 and ignored practical deployments.=20 >=20 > 1. Encryption has nothing to do with ipv6, full stop. As a practical = matter, ipv6 means nothing for crypto. Modern day consumer crypto is a = layer 7 matter (https) >=20 > 2. The idea that ipv6 reduces attribution is literally ludicris. No = elaboration needed. I have first hand knowledge in this space.=20 >=20 > Also sad that El Reg progates this misinformation.=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 4 18:15:54 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6691F124B0A; Sun, 4 Mar 2018 18:15:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152021615239.27925.6946415833371012617@ietfa.amsl.com> Date: Sun, 04 Mar 2018 18:15:52 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 02:15:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Routers Authors : Zaid Ali Kahn John Brzozowski Russ White Filename : draft-ietf-v6ops-ipv6rtr-reqs-02.txt Pages : 32 Date : 2018-03-04 Abstract: The Internet is not one network, but rather a collection of networks. The interconnected nature of these networks, and the nature of the interconnected systems that make up these networks, is often more fragile than it appears. Perhaps "robust but fragile" is an overstatement, but the actions of each vendor, implementor, and operator in such an interconnected environment can have a major impact on the stability of the overall Internet (as a system). The widespread adoption of IPv6 could, particularly, disrupt network operations, in a way that impacts the entire system. This time of transition is an opportune time to take stock of lessons learned through the operation of large scale networks on IPv4, and consider how to apply these lessons to IPv6. This document provides an overview of the design and architectural decisions that attend IPv6 deployment, and a set of IPv6 requirements for routers, switches, and middleboxes deployed in IPv6 networks. The hope of the editors and contributors is to provide the necessary background to guide equipment manufacturers, protocol implementors, and network operators in effective IPv6 deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-02 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 Sun Mar 4 19:29:52 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7876C124D6C for ; Sun, 4 Mar 2018 19:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UiBQdKWD9Se for ; Sun, 4 Mar 2018 19:29:49 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 C80DC124C27 for ; Sun, 4 Mar 2018 19:29:48 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s188so19031447qkb.2 for ; Sun, 04 Mar 2018 19:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0p797Yeg8hp+iSGPWTQsIyCXgcZL1pKyGb8O3WOUFJY=; b=jQVYKvb1GS/8wW/o3u+24dnH8ePBSNMppIZC5UZXo3jRQMN+bOrfb+ZoIaUId2IcxY cX6AMBGMu5DCGpwPfFz4wH2+AGQfQ1wdMLRo0b9cnHG5no33zUWzkNiBJKLQAN9z84Rf RQZphnFMnxpfYvegtkDc9wSfvlEAH7fievPdYyLrGhB639qnzrxlrtHBpq4E7ivbkIsP PeGIfFJ8f5JGxSRGyiIOceg6VJ5FkpeBFc3KOHULDOfHEu9JRmBfAoa6RBOqG8AtPOlO 3bI+3hNdSWJ56iMbwtmrFvjpBOIMvHoutZAuCt+Mf8qxvouV1dxcNG3dVjbrxt3gHqWE hY4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0p797Yeg8hp+iSGPWTQsIyCXgcZL1pKyGb8O3WOUFJY=; b=oSvvTbluUwDrxhbsgGWG0yuqnNzCTBF/Cd3h2zaHtKh6QEwkwy3smRAF2BhNPy4C1s pVEHwppUg3yQROup3258PS/36UhtP2S5TYpj4OA29EGdbxrBkwFQjFOJwGHKZ6ODHAPR gNU1QYotDXNjwqGIpITGYbAoFtpdMdhuBloldBvwp0wg+fm3d8RspyZBTjYjwAHKjZVL x7yyMCDpPtCdYpddekGZHr3TKonN8rgmMsoHKVKxPyndSE7lomfiDREJ2vG0+QFL4z8F 5ThnKWNSWyfyMF9zNO5SK+wHFtkKllfLNtVGzCc79wEk2Sq6rdRBcrDVilKwiTnjydA5 Bh0w== X-Gm-Message-State: AElRT7E4PWKMISB+XvatuebfnozA2+Ph9sStGHrd47BsvTlJdomSz/ob ue4iLRtFrJY2WrYwsxRvWicAGi5se22xgT7768XMxA== X-Google-Smtp-Source: AG47ELtH8l82Y9FO4wEIrR7/aazeDn4L/Uym/iafvkPS1dSNw92NNC74K0wYQpAhgpbiO7hG5dFjrXO9zuUiYl2oP2E= X-Received: by 10.55.168.212 with SMTP id r203mr19410589qke.257.1520220587773; Sun, 04 Mar 2018 19:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 19:29:47 -0800 (PST) In-Reply-To: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> From: Tom Herbert Date: Sun, 4 Mar 2018 19:29:47 -0800 Message-ID: To: Brian E Carpenter Cc: IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 03:29:50 -0000 On Sun, Mar 4, 2018 at 5:19 PM, Brian E Carpenter wrote: > Success at last :-) > > http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_evidence_and_surveillance/ > Brian, With current address assignment techniques I believe the opposite true. It is easier to track individuals when IPv6 is used than when CGNAT is used (Europol has acknowledged that). The problem with it being easy for law enforcement to track individuals is that its also going to be easy for bad guys to do it also-- so there is a privacy issue. We raise this issue in draft-herbert-ipv6-prefix-address-privacy-00 and will probably talk about the draft in int-area meeting in London if you're interested. Tom > Regards > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Mar 4 19:53:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A303D124C27 for ; Sun, 4 Mar 2018 19:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0D_QCyz-t_R for ; Sun, 4 Mar 2018 19:53:38 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 BED521241F3 for ; Sun, 4 Mar 2018 19:53:37 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id v18so15120221wrv.0 for ; Sun, 04 Mar 2018 19:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0V1BDBDsUWmaFKxA96LRRTLjqM83mnjlom85KvM3CgU=; b=mCUhQSCwL9/PMZTK9/aVgAA1f5me4ZLEjf50ICI67yBydgZt/T71au2GPlv8svTdCF 00SJB4NvkqPZD7r3E7vyXlNNFNBXjT9o49y4OBiizqV4zfj6Pk+DZ+NPK7/pmxePDhf9 hYpx6KrRUp3r4Qxgo5EDeYdvp19Ji1ba+BMMmEG3KgHbb5E5A0zZPYT0xMA8r+t2LMK3 ilKJNhAJTDTHjR/qDXMNebq6SFbXLalfV36y7haRB7IXALjPV+4eOtrK9Z++Rx9EEjEX +/jjci3SuMD2XkuVov7/1+aU/AKCA9YfsGbujs0BIYYDTxsUWK2HjSSe4nv4YzR/HhiZ AsZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0V1BDBDsUWmaFKxA96LRRTLjqM83mnjlom85KvM3CgU=; b=X7P7wQWICgFs7h5TK4H2kChsnDtlJkpAMSakalLrbU2ge1B/QzoSncL7FDaWghbqj5 nW84DfZhqSBQ8c6hm8kenImUiaR/M17B7YpjQ5WQfQqQCiYzsa2SpW05/piT4Vuc/TiL 3mz/20nuK/k+xw3QZymmU9LTHhoQhNAnux/jjIgW2QCiD49YXX4vk1wt9Z7b5uSockmW H39p5cW6pf1/xr04jhlAvyVuZe07WEumSFye/qDsAUsaSzVlHlqNxq7Q4o2wUVKNdSo+ Azv4q+9lP4ms5U9/yh+NBYORxCptgHdDbishfuxw3bsFhLyhQuf9DvPBZddqInrR3uuT qDZQ== X-Gm-Message-State: APf1xPC3kpPh/0qboJ2TXIWIhUzvSgN6u1IrqCr6g5B3B/QhSAcGbShq OZRDZzd4Z6kkt3uBq/RVVJ4uJ0mjynkQ6ehmhaw= X-Google-Smtp-Source: AG47ELvjdRQ7OMumGcJkC9gbwFna4AEAaRNzi0r1ctTkQcyeA3NdsY0+Lv7FWdBZhf/s+cYgBpccXS9TYMvymQjDHHU= X-Received: by 10.223.130.76 with SMTP id 70mr10980660wrb.95.1520222016306; Sun, 04 Mar 2018 19:53:36 -0800 (PST) MIME-Version: 1.0 References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> In-Reply-To: From: Ca By Date: Mon, 05 Mar 2018 03:53:25 +0000 Message-ID: To: Tom Herbert Cc: Brian E Carpenter , IPv6 Operations Content-Type: multipart/alternative; boundary="001a114b38264304540566a245a3" Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 03:53:40 -0000 --001a114b38264304540566a245a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 4, 2018 at 7:30 PM Tom Herbert wrote: > On Sun, Mar 4, 2018 at 5:19 PM, Brian E Carpenter > wrote: > > Success at last :-) > > > > > http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_evid= ence_and_surveillance/ > > > Brian, > > With current address assignment techniques I believe the opposite > true. It is easier to track individuals when IPv6 is used than when > CGNAT is used (Europol has acknowledged that). The problem with it > being easy for law enforcement to track individuals is that its also > going to be easy for bad guys to do it also-- so there is a privacy > issue. We raise this issue in > draft-herbert-ipv6-prefix-address-privacy-00 and will probably talk > about the draft in int-area meeting in London if you're interested. > > Tom > There are 2 specific issues at play here. One is traceability. With ipv6, it is possible for LEA to issue a warrant to facebook to find out which address accessed the account, and then with that address, issue a warrant to the isp to get an account / identity / location. I am fine with all that above. The accounting of all connections is a different issue i am not ok with, and these accounting are likely in any central NAT box. With CGNAT, the isp has a full session log of every outbound connection you make. The isp may sell this session log to advertisers or worse that may want to understand your =E2=80=9Cdigital life=E2=80=9D. Also, the session log is discoverable with warrant for all your activity, not just as a subsequent investigation of an identity. And, hackers may have access to that session log. So, CGNAT / ILA is much much more dangerous, in my experience. That said Aussies know what they have and know what they are giving up. > > > Regards > > Brian > > > > _______________________________________________ > > 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 > --001a114b38264304540566a245a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Mar 4, 2018 a= t 7:30 PM Tom Herbert <tom@herber= tland.com> wrote:
On Sun, = Mar 4, 2018 at 5:19 PM, Brian E Carpenter
<brian.= e.carpenter@gmail.com> wrote:
> Success at last :-)
>
> = http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_eviden= ce_and_surveillance/
>
Brian,

With current address assignment techniques I believe the opposite
true. It is easier to track individuals when IPv6 is used than when
CGNAT is used (Europol has acknowledged that). The problem with it
being easy for law enforcement to track individuals is that its also
going to be easy for bad guys to do it also-- so there is a privacy
issue. We raise this issue in
draft-herbert-ipv6-prefix-address-privacy-00 and will probably talk
about the draft in int-area meeting in London if you're interested.

Tom

There are 2 spec= ific issues at play here.

One is traceability. With ipv6, it is possible for LEA to issue a warrant= to facebook to find out which address accessed the account, and then with = that address, issue a warrant to the isp to get an account / identity / loc= ation.=C2=A0

I am fine w= ith all that above.=C2=A0

The accounting of all connections is a different issue i am not ok with, = and these accounting are likely in any central NAT box.=C2=A0

With CGNAT, the isp has a full sessio= n log of every outbound connection you make. The isp may sell this session = log to advertisers or worse that may want to understand your =E2=80=9Cdigit= al life=E2=80=9D.=C2=A0

= Also, the session log is discoverable with warrant for all your activity, n= ot just as a subsequent investigation of an identity.=C2=A0

And, hackers may have access to that = session log.=C2=A0

So, C= GNAT / ILA is much much more dangerous, in my experience.=C2=A0

That said Aussies know what they ha= ve and know what they are giving up.



> Regards
>=C2=A0 =C2=A0 Brian
>
> _______________________________________________
> 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
--001a114b38264304540566a245a3-- From nobody Sun Mar 4 20:11:23 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA854126C19 for ; Sun, 4 Mar 2018 20:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khCSjJrNGkDp for ; Sun, 4 Mar 2018 20:11:20 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 3DBB6124C27 for ; Sun, 4 Mar 2018 20:11:20 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s198so19109219qke.5 for ; Sun, 04 Mar 2018 20:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vltB92E7Ui5VO6Em3Dy2qtjTcEH89fKsLjrcL7QNFIo=; b=nRRZuiy2wd3MoBQzDy5IdKmuK51ONyz3PkJBMBbZG7KTBzEtiP2R/+4gFCLe35dBfq jYkHFCpmU5z2WDeYfvMAgut4UfNrCFORdmP0BJejaQikQojnhLzx0sCqBjdz6eMbdGES LvV6y0lGR6TBTD1mlcjwme7oxEeww9zb13M+e+zsa3pkRJIkCrcLnEpRdBP2lvLLEHyQ hEVEDaFuoz+OpJyl6MsYj5MxG8CLLV7KtLRK/9DS3Cot3EpLZpGp9pgsiaEjaQPfirMC 1omDVoA94Oy8GTekMHN9Ov9P/WQZ+SKQqVhATZOZoDmHxe7bYO0ieGe2Qx46ZDF88r5j 0sXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vltB92E7Ui5VO6Em3Dy2qtjTcEH89fKsLjrcL7QNFIo=; b=E5ie0ViNnJA3vRIWNoCpRHLaZ/NgiZ1w3PivWygZol0mdJii8KrLNeKHR0Syd3OH2O MeQ7+0dt0RMcsDsjmx+PmTTLo0+4p5ks+GYa/v1RUqBAwiSjy4zM3KLHmkpAMeM1Wk0b xDLj4BSTcQaCIAiooTsBe4HXChkcckTH488bgSJMaxM5KCQiFv0kUerYEWxP6XFQRFWl 8pz5H+zBgyTJ06xr1nn08HGLNkIVXe/WTOxil+zP+Y8qeSqYuXxwBXVdENXrQ3XMEDhS oKk16FjauGAOUlv9HqnwuDClVkDnwasZqhVjZSTmY7JvHvs2iqSj8siIs/qTfD8sLzI8 +Maw== X-Gm-Message-State: AElRT7EPUYOdsm2iPO8L824CrKqM/pFUkqWfI2UfdQqUZiEGJol7kn1x bPoSh8WtWmQLoj69CbCo0oWR4BaCpOdGlvj3CBZobA== X-Google-Smtp-Source: AG47ELseMSlruAdb+/AwxUfD5YCENJuMM9rV8aBqqOswagC5fZ01lGMVvPjnJRcFRS3P6iLyJ4jk/xBW+Gg2yvIwcns= X-Received: by 10.55.75.77 with SMTP id y74mr20796504qka.44.1520223079167; Sun, 04 Mar 2018 20:11:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.181 with HTTP; Sun, 4 Mar 2018 20:11:18 -0800 (PST) In-Reply-To: References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> From: Tom Herbert Date: Sun, 4 Mar 2018 20:11:18 -0800 Message-ID: To: Ca By Cc: Brian E Carpenter , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 04:11:22 -0000 On Sun, Mar 4, 2018 at 7:53 PM, Ca By wrote: > > On Sun, Mar 4, 2018 at 7:30 PM Tom Herbert wrote: >> >> On Sun, Mar 4, 2018 at 5:19 PM, Brian E Carpenter >> wrote: >> > Success at last :-) >> > >> > >> > http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_e= vidence_and_surveillance/ >> > >> Brian, >> >> With current address assignment techniques I believe the opposite >> true. It is easier to track individuals when IPv6 is used than when >> CGNAT is used (Europol has acknowledged that). The problem with it >> being easy for law enforcement to track individuals is that its also >> going to be easy for bad guys to do it also-- so there is a privacy >> issue. We raise this issue in >> draft-herbert-ipv6-prefix-address-privacy-00 and will probably talk >> about the draft in int-area meeting in London if you're interested. >> >> Tom > > > There are 2 specific issues at play here. > > One is traceability. With ipv6, it is possible for LEA to issue a warrant= to > facebook to find out which address accessed the account, and then with th= at > address, issue a warrant to the isp to get an account / identity / locati= on. > > I am fine with all that above. > > The accounting of all connections is a different issue i am not ok with, = and > these accounting are likely in any central NAT box. > > With CGNAT, the isp has a full session log of every outbound connection y= ou > make. The isp may sell this session log to advertisers or worse that may > want to understand your =E2=80=9Cdigital life=E2=80=9D. > > Also, the session log is discoverable with warrant for all your activity, > not just as a subsequent investigation of an identity. > > And, hackers may have access to that session log. > > So, CGNAT / ILA is much much more dangerous, in my experience. > Ca, A provider has all the information about users and addresses they are assigned as well as packet log traces if they wish. That's in the nature of their operations. There's not much we can do protocol wise if they are carelessly or maliciously divulging information about users, that is more in the realm of contracts and legalities. However, we can address the issue of third parties being able to make inferences when they don't have access to the data. Also, the Europol bulletin seems to indicate that ISPs aren't necessarily providing all the data needed for their investigations. There seems to be a gap here with the idea that ISPs are already giving law enforcement everything they need. Tom > That said Aussies know what they have and know what they are giving up. > >> >> >> > Regards >> > Brian >> > >> > _______________________________________________ >> > 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 4 20:14:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F7A126C3D for ; Sun, 4 Mar 2018 20:14:33 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_k8R6r0bDnL for ; Sun, 4 Mar 2018 20:14:32 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 17B8C126C19 for ; Sun, 4 Mar 2018 20:14:32 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id c7so18885920qtn.3 for ; Sun, 04 Mar 2018 20:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jOpu9lctnxRLj/8jGIICpyv5EA+bIRj1tW/f1Gzg/C0=; b=XVz7ba6fF+nKbxrrVfo2Vg5IR23h6LH8a9Sv0Way7HYfOIqu7r4jaMyrG52vw5VVKk CEksvN6WsWlCm2Jn6JzB0dLKyt+p4NRVUF9ck/KyXG+iNFiWPMgb0zVC7e6ZWep/gN27 gvALLThw92NqadrZmhqynfyxoV4IYlG+UnIOwjUPZA6U5Qb0GALGeKdX2dRtuLtGLUh8 rX+PzK3pVhsBzKgPX5T0ZWYoKM2FwISe5ALSFZ/7PjjnoHX3RM/HWfdwijGdYn/uNzFw LeTN1NEaWw9gEw/BhRBcDn/vNaXnvJlxkZhj4f/KDhpIzLVC1UY6C99+f4EmGR/CHbZI uVmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jOpu9lctnxRLj/8jGIICpyv5EA+bIRj1tW/f1Gzg/C0=; b=cBehQIg+8/LgqS4YsgKXH32uQVyih8R0A00Lupf/dFqj20ZEIPqrR7FsYEgk8ESvbp owrGxxi5Rf4xPCxoE4EXAejB/l04zxOpM27FAwjiWFRtJv3HOOFOg5Z681HrapBzcu9h EsbgV3khBFbKbOtF7W4hHgVYk/FcTxfkykxTNX4e2Bj/2yk9w1v7mKgN8uNk0lxYkGeG fPzPYDxzmfamLb4ik6esJzhfZKzrnOR71/vqXzWhkSDr6NtdeNm/5STfWhTDCFPk2JEW MWuY2A3/F4YnNt4wtb1U4I+RIOksAtcew3ktx9zexVmu4wZUVRUraXHjQtmuFVFXtiSR 0pLA== X-Gm-Message-State: AElRT7G46SLievwhmk4wAmsw3VHaxuVrkKgy9xu54Jf7CnD4JSCuAJRG DIybgigtFLQxheZIvQX/9/chyQ== X-Google-Smtp-Source: AG47ELusbTwenV1/yQrmbRqLEiTV9NEFmojdUoiRaAIBtBZGeht1uuy9yYYCOa7c65LemT1p7NXQWQ== X-Received: by 10.237.50.37 with SMTP id y34mr21503722qtd.234.1520223271234; Sun, 04 Mar 2018 20:14:31 -0800 (PST) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id z22sm7944998qti.75.2018.03.04.20.14.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Mar 2018 20:14:30 -0800 (PST) From: Ted Lemon Message-Id: <85E8B25B-551D-4898-9813-53693ADAC475@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_250CD833-EF6E-4BA5-B03C-4851EF11573C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 4 Mar 2018 23:14:28 -0500 In-Reply-To: Cc: Ca By , IPv6 Operations To: Tom Herbert References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 04:14:34 -0000 --Apple-Mail=_250CD833-EF6E-4BA5-B03C-4851EF11573C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 4, 2018, at 11:11 PM, Tom Herbert wrote: > A provider has all the information about users and addresses they are > assigned as well as packet log traces if they wish. This is true, but of course if you have a CGN in place, then it _has_ to = track this information, and you've already spent the money, so getting = the logs is "free." If you don't have a CGN in place, tracking all of = the connections made through a particular customer's connection requires = you to spend money. ISPs tend not to do that if there's nothing in it = for them. --Apple-Mail=_250CD833-EF6E-4BA5-B03C-4851EF11573C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Mar 4, 2018, at 11:11 PM, Tom Herbert <tom@herbertland.com>= wrote:
A provider has all = the information about users and addresses they are
assigned as well as packet log traces if they = wish.

This = is true, but of course if you have a CGN in place, then it _has_ to = track this information, and you've already spent the money, so getting = the logs is "free."   If you don't have a CGN in place, tracking = all of the connections made through a particular customer's connection = requires you to spend money.   ISPs tend not to do that if there's = nothing in it for them.

= --Apple-Mail=_250CD833-EF6E-4BA5-B03C-4851EF11573C-- From nobody Sun Mar 4 21:08:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DC3126C3D for ; Sun, 4 Mar 2018 21:08:29 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSN7eFQu3nX6 for ; Sun, 4 Mar 2018 21:08:27 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 B1CDE124B0A for ; Sun, 4 Mar 2018 21:08:26 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id k9so15834224wre.9 for ; Sun, 04 Mar 2018 21:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=48H8bCdy22bvm2towxQJcSbH+y2TFaiL8QyT9v+0yFY=; b=ZPEEgmmU2a3gE6jBuZ/43fyugcpMJNd1t866ujDv4JUzmNAK6X93k89X288eBJcuB2 9KuulzQqOU6VkIx5w/n9c5nzcl1bz6lBexWA2guUlOHoehd8PWa0H5nmo4B2tleCPk0u OQcG/sWjjhKp9rcQ6oGDPVj8ngGfSNDNDhLJa9Ab0cWlqgS/7DmRALT2bvhNXsEyhh0w zpKHq0l6xdJcO/qIetcepe1/HphLkJlacLwbMKl6arIB2H3DMMSeu9frUrMDDfYmE+8m E/Kt6EEkYtPaeHWa6he0YH7FzRUqK17AD+5eIWBy+yB4sTe7aGBeYoGW8XfiAbnDFFdH 81Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=48H8bCdy22bvm2towxQJcSbH+y2TFaiL8QyT9v+0yFY=; b=QjmG3G+rBCScrBmebqeWe9OulxGRb90f0vO1X4OcHX4k9C+8XW9+cYyiy1B0F6IiNl EQnqp4/4MIIcVujwUY1emFc4N9jnxlXufNhPd+7sYzwmVIqnkpjGaB7ATB6LXCltIWIg IaOmZ8i0HCmKOCZY3mlCKIdm4YYq4XJn8VqIU9WfXQqcNnqC7+yZCGgoeQ4VPVn0SHmL MZkAelq+voamqbxito4zWS2jAtUCiy2/tlf1H8RVwaMuxebS7bidbk/NdbABFEb7XckH h5c1fYV/XLZL4XGZg1k5ZypwAw+lp1doUjhoGk2nYtNVHOTJyuqwdxTU5RIg1OlC87YW 3gZA== X-Gm-Message-State: APf1xPCrvMHtDY1nb3ZK4VSLcVG2GYI+NXGmJXanDW4AOYGT/FlVUV8J kpEKjPk+0QSqZ48DomLEgu/5J8YhUdwv1Kzlzv5b4Q== X-Google-Smtp-Source: AG47ELuUvSpagHqt6/HSvvaOtEBv2JdgZbpMnZnemhlW9/sEPqukhKy61xg6oXDx54t2aSBV0pMXmVuQbCNLfw9lWq8= X-Received: by 10.223.145.67 with SMTP id j61mr11911824wrj.152.1520226504954; Sun, 04 Mar 2018 21:08:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.63.79 with HTTP; Sun, 4 Mar 2018 21:08:04 -0800 (PST) In-Reply-To: <152021615239.27925.6946415833371012617@ietfa.amsl.com> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> From: Lorenzo Colitti Date: Mon, 5 Mar 2018 14:08:04 +0900 Message-ID: To: internet-drafts Cc: i-d-announce@ietf.org, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c06b392cecae80566a350ea" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 05:08:29 -0000 --94eb2c06b392cecae80566a350ea Content-Type: text/plain; charset="UTF-8" On Mon, Mar 5, 2018 at 11:15 AM, wrote: > Title : Requirements for IPv6 Routers > Authors : Zaid Ali Kahn > John Brzozowski > Russ White > Filename : draft-ietf-v6ops-ipv6rtr-reqs-02.txt > I continue to object to the one-size-fits all approach taken in the document. Here are two examples of how that leads to harmful outcomes. Saying that mobile phones (which forward IPv6 packets when the user desires them to) should support YANG, SNMP, and syslog would just be ridiculous if it wasn't harmful (because it creates the potential for a security vulnerability - the more remote management code running on the device, the greater the risk of vulnerability). Saying that mobile phones must support DHCPv6 is harmful, because: - If DHCPv6 is enabled, it's harmful to users for the reasons explained in https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html . - If DHCPv6 is disabled, it's harmful to users because somebody wrote code for something that's never enabled. - I don't think there will ever be any other choices than the above two, since no popular OS will provide a configuration mechanism for the user to enable/disable DHCPv6 on the mobile hotspot. (If you don't agree with that assertion then consider: those OSes don't even allow the user to enable/disable IPv6. Why would they allow the user to enable/disable DHCPv6?) Authors: the last time v6ops dealt with a "kitchen sink shopping list" document of this sort was RFC 7849. That document generated a lot of noise on the mailing lists, went back and forth for many months, and ended up being withdrawn as a WG document and published as individual submission which has zero normative value. I assume that's not your desired goal for this document? If so, I would suggest adding an applicability statement that clarifies that not every piece of equipment under the sun that ever happens to forward an IPv6 packet must meet these requirements. --94eb2c06b392cecae80566a350ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Mar 5, 2018 at 11:15 AM, <internet-drafts@ietf.org> wrote:
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Requireme= nts for IPv6 Routers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Zaid= Ali Kahn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Russ White
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-ipv6rtr-reqs-02.txt

I cont= inue to object to the one-size-fits all approach taken in the document. Her= e are two examples of how that leads to harmful outcomes.

Saying that mobile phones (which forward IPv6 packets when the user= desires them to) should support YANG, SNMP, and syslog would just be ridic= ulous if it wasn't harmful (because it creates the potential for a secu= rity vulnerability - the more remote management code running on the device,= the greater the risk of vulnerability).

Saying th= at mobile phones must support DHCPv6 is harmful, because:
    If DHCPv6 is enabled, it's harmful to users for the reasons explained = in https://www.ietf.org/mail-archive/web/v6ops/cu= rrent/msg26286.html .
  • If DHCPv6 is disabled, it's = harmful to users because somebody wrote code for something that's never= enabled.
  • I don't think there will ever be any other choices th= an the above two, since no popular OS will provide a configuration mechanis= m for the user to enable/disable DHCPv6 on the mobile hotspot. (If you don&= #39;t agree with that assertion then consider: those OSes don't even al= low the user to enable/disable IPv6. Why would they allow the user to enabl= e/disable DHCPv6?)
Authors: the last time v6ops dealt w= ith a "kitchen sink shopping list" document of this sort was RFC= =C2=A07849. That document generated a lot of noise on the mailing lists, we= nt back and forth for many months, and ended up being withdrawn as a WG doc= ument and published as individual submission which has zero normative value= . I assume that's not your desired goal for this document? If so, I wou= ld suggest adding an applicability statement that clarifies that not every = piece of equipment under the sun that ever happens to forward an IPv6 packe= t must meet these requirements.
--94eb2c06b392cecae80566a350ea-- From nobody Sun Mar 4 21:54:15 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A304C1270A7 for ; Sun, 4 Mar 2018 21:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbBqd_vd_IpC for ; Sun, 4 Mar 2018 21:54:09 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 5F49B126CC4 for ; Sun, 4 Mar 2018 21:54:08 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id w63so8035034ita.3 for ; Sun, 04 Mar 2018 21:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=boUP+wq7niBxB3dWkVUWln/5OPw17GmwaLRh6cW6lQ4=; b=jskfCmSXhtc8uHjT6y7Ib2GFtmOJqrt0iIWc/yQTHGiox0fxonhlRC3xtbuZWwSyEy AGmSyI4eHIQuBjqUp/d8/QTeCAI9S+vgHh6mlTi4CH2l5OHAZk6scdhWYe1ROwLT6iNB i/COFmuf25WDdrbU96w9ZP0cuXuI6HyfUvQaWg7V4pHdtyN7M6vOVUWDe6h+uX7YdGJC cnkJU3En0X1O6HdC3k1Vod1q7oS5ViWM4ElAQxse5zWsbWIcNPGu5UUSlJwxrWY5rBE6 w/syRi+3zdYBaZpevnljg2l9EMmiyZ43F8tQ+6IrrLnejhxT7RXrsJb2kkE7P+bKVRbB d0qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=boUP+wq7niBxB3dWkVUWln/5OPw17GmwaLRh6cW6lQ4=; b=Su8+0GarMMER3UzvpqMorxcx+7enQXemYYmN5OKsZbIrt3f5qLD4pnkfz1ZwO4balp OIWxo2Qc7BS8Pi907dNR7nWROi83Tw6G3WgEUBF1fuKt10epMXScQmT3Pu2h2h06Y+Dd bfdG8noilA0+ltOdTFgeUAv5XK9m7zdQQrejvhfCtOotA9VHYtw4/Zoe7AzNP+TMfzDs rZBnFO6OJTtoYFB04pYDfamsQ9SjlgkGrpzzN6EjxeUGr/55yUg2SUIzAgNcLzglM6mq c4DPoSdX1GBOFglXC/WFI9GG2M+1SF0gr9I4JyeSQfXiOD4EHSQzB62Qf0tYIN4T8w8l 887g== X-Gm-Message-State: AElRT7Fe5u+K/hM1FgMHk6WkGhnc159Y/+Ic067XRL+RCr+qaa8b4nWb 7aY6aYVIv7pIzqSX5jZ4AA5ImP+P X-Google-Smtp-Source: AG47ELui48NhPQnw2oAX8kqa7Vjcag4eb3+fsIA8c2/LhuG9e9IKfn5wJ/ZcKwABC2o8MZZ5dR8qyQ== X-Received: by 10.36.74.148 with SMTP id k142mr12811016itb.115.1520229247544; Sun, 04 Mar 2018 21:54:07 -0800 (PST) Received: from [192.168.178.30] ([118.148.64.93]) by smtp.gmail.com with ESMTPSA id l18sm1132538itl.1.2018.03.04.21.54.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Mar 2018 21:54:06 -0800 (PST) Sender: Brian Carpenter To: Lorenzo Colitti Cc: "v6ops@ietf.org WG" References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Mon, 5 Mar 2018 18:54:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 05:54:12 -0000 On 05/03/2018 18:08, Lorenzo Colitti wrote: > On Mon, Mar 5, 2018 at 11:15 AM, wrote: > >> Title : Requirements for IPv6 Routers >> Authors : Zaid Ali Kahn >> John Brzozowski >> Russ White >> Filename : draft-ietf-v6ops-ipv6rtr-reqs-02.txt >> > > I continue to object to the one-size-fits all approach taken in the > document. I think the problem starts with the title. "Requirements for Enterprise IPv6 Routers" or "Requirements for Fully Featured IPv6 Routers" would be more like it. I expected to see much more text about scoping added at the start of the document. Probably, looking ahead to a network of 10^12 nodes with massive amounts of mesh networking, the large majority of devices that forward IP packets will not require most of these features. Brian > Here are two examples of how that leads to harmful outcomes. > > Saying that mobile phones (which forward IPv6 packets when the user desires > them to) should support YANG, SNMP, and syslog would just be ridiculous if > it wasn't harmful (because it creates the potential for a security > vulnerability - the more remote management code running on the device, the > greater the risk of vulnerability). > > Saying that mobile phones must support DHCPv6 is harmful, because: > > - If DHCPv6 is enabled, it's harmful to users for the reasons explained > in https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html . > - If DHCPv6 is disabled, it's harmful to users because somebody wrote > code for something that's never enabled. > - I don't think there will ever be any other choices than the above two, > since no popular OS will provide a configuration mechanism for the user to > enable/disable DHCPv6 on the mobile hotspot. (If you don't agree with that > assertion then consider: those OSes don't even allow the user to > enable/disable IPv6. Why would they allow the user to enable/disable > DHCPv6?) > > Authors: the last time v6ops dealt with a "kitchen sink shopping list" > document of this sort was RFC 7849. That document generated a lot of noise > on the mailing lists, went back and forth for many months, and ended up > being withdrawn as a WG document and published as individual submission > which has zero normative value. I assume that's not your desired goal for > this document? If so, I would suggest adding an applicability statement > that clarifies that not every piece of equipment under the sun that ever > happens to forward an IPv6 packet must meet these requirements. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Sun Mar 4 22:35:32 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEFC126FB3; Sun, 4 Mar 2018 22:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gg89qocY8Uq; Sun, 4 Mar 2018 22:35:28 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 9CECE126D0C; Sun, 4 Mar 2018 22:35:28 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id DF4C23AB03F; Mon, 5 Mar 2018 06:35:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id CA7DA160069; Mon, 5 Mar 2018 06:35:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B153A160068; Mon, 5 Mar 2018 06:35:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aDBJp1hfYZ7L; Mon, 5 Mar 2018 06:35:25 +0000 (UTC) Received: from [172.30.42.66] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id AF315160064; Mon, 5 Mar 2018 06:35:24 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Mon, 5 Mar 2018 17:35:22 +1100 Cc: internet-drafts , "v6ops@ietf.org WG" , i-d-announce@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 06:35:30 -0000 > On 5 Mar 2018, at 4:08 pm, Lorenzo Colitti wrote: >=20 > On Mon, Mar 5, 2018 at 11:15 AM, wrote: > Title : Requirements for IPv6 Routers > Authors : Zaid Ali Kahn > John Brzozowski > Russ White > Filename : draft-ietf-v6ops-ipv6rtr-reqs-02.txt >=20 > I continue to object to the one-size-fits all approach taken in the = document. Here are two examples of how that leads to harmful outcomes. >=20 > Saying that mobile phones (which forward IPv6 packets when the user = desires them to) should support YANG, SNMP, and syslog would just be = ridiculous if it wasn't harmful (because it creates the potential for a = security vulnerability - the more remote management code running on the = device, the greater the risk of vulnerability). >=20 > Saying that mobile phones must support DHCPv6 is harmful, because: > =E2=80=A2 If DHCPv6 is enabled, it's harmful to users for the = reasons explained in = https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html . The phone can advertise itself as a DNS server. It needs to do this = anyway to properly service reverse DNS for the address ranges it is = adverting in the RA. > =E2=80=A2 If DHCPv6 is disabled, it's harmful to users because = somebody wrote code for something that's never enabled. > =E2=80=A2 I don't think there will ever be any other choices = than the above two, since no popular OS will provide a configuration = mechanism for the user to enable/disable DHCPv6 on the mobile hotspot. = (If you don't agree with that assertion then consider: those OSes don't = even allow the user to enable/disable IPv6. Why would they allow the = user to enable/disable DHCPv6?) Well most home routers for last 10 years didn=E2=80=99t have a option to = disable IPv4 but had options to enable/disable DHCP. > Authors: the last time v6ops dealt with a "kitchen sink shopping list" = document of this sort was RFC 7849. That document generated a lot of = noise on the mailing lists, went back and forth for many months, and = ended up being withdrawn as a WG document and published as individual = submission which has zero normative value. I assume that's not your = desired goal for this document? If so, I would suggest adding an = applicability statement that clarifies that not every piece of equipment = under the sun that ever happens to forward an IPv6 packet must meet = these requirements. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 4 22:45:23 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79C51270A7 for ; Sun, 4 Mar 2018 22:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ8AZAwXb9bZ for ; Sun, 4 Mar 2018 22:45:21 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 BE3DD126FDC for ; Sun, 4 Mar 2018 22:45:20 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id a20so11653508wmd.1 for ; Sun, 04 Mar 2018 22:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/R4iEysLOwIOjlqhPOF4QWnDUoZjeqABAHoCzjj4uZw=; b=PeKUcYpvjMsATfQxXvM/Ic1rCGArw2ozzPTqLYyBC8xVScHTBY6cXxmaJBjC4ESV5o H1MYjz/9wS9BP797d9G1MApOZ1/cW3oHL3cSLYSvAWU70lROqUYSixr1/hx2Hj23GHPe 11ip0tfq3ZeAgd6e3SL5Nnx+XJR9H7ipxwsNn01rFmy8bPMrOgwsAc5qoKI57PcNgqLw vUlNxTHBKH5hFua/ZQmmTKLTZ/T/IOzT0VTLoawQKrk6mzxriGqEuN5IAgGU3MzXXJ6n H1+OJ2XLivLN36ykm6E4EDVe5H7H2Ixp3SI42NTOxb2lSyjYVI5rbhvEVH0Pv3Po0Nq6 VD6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/R4iEysLOwIOjlqhPOF4QWnDUoZjeqABAHoCzjj4uZw=; b=TCTAAt8MRsHB/Fuh0GFsFG1azO/KNiH1SQNWSY1lTr/yLl1nIMR7t1dhESGPpD/UIU 7EvD7UBwZB1ctXYKPVlBqKFIrTk9SyWhVdPwOyQzxoLUAmKp03zOnPH0OhHoZFRMUwC4 x0gbbKhCA0XHjfLkf96B1NR/awDU63/peHSUCWa4yRAQlvFZpAU+Fa1M6uyZofXHarSt jOO551RI3nGTXrhAss0fDpRCyF7CwdKiw3+34hvJCkrKS4i45yvPeAuAMjx5w9GWmxZK zcXNuCyGzTnCRV7lb5RfeqRXUOQI/eKBBwvjJWM4IbXMCyPAGNjFgeS6XqxoKYwCaRRA WGwg== X-Gm-Message-State: AElRT7G214iV7b31zhhHx3EX9NAEdNHKYTkrESZjHCpRfEJnF6ciDpT9 dwwY8EaGdEwU5jY7/jYS5JJnxLYDUjL3BAYztLmgVw== X-Google-Smtp-Source: AG47ELtZH1zRtl4zb//XmrNJi4HD0q9jYHr8XaB3z7XO34FbQPSZfm/WeTghDY9LBhgggJge/VKzCMtfz4pC5G7Vmys= X-Received: by 10.28.12.79 with SMTP id 76mr6665802wmm.116.1520232318911; Sun, 04 Mar 2018 22:45:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.63.79 with HTTP; Sun, 4 Mar 2018 22:44:58 -0800 (PST) In-Reply-To: <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> From: Lorenzo Colitti Date: Mon, 5 Mar 2018 15:44:58 +0900 Message-ID: To: Mark Andrews Cc: internet-drafts , "v6ops@ietf.org WG" , i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="001a11444ad658e1600566a4abf7" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 06:45:23 -0000 --001a11444ad658e1600566a4abf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 5, 2018 at 3:35 PM, Mark Andrews wrote: > > Saying that mobile phones must support DHCPv6 is harmful, because: > > =E2=80=A2 If DHCPv6 is enabled, it's harmful to users for the rea= sons > explained in https://www.ietf.org/mail-archive/web/v6ops/current/ > msg26286.html . > > The phone can advertise itself as a DNS server. It needs to do this > anyway to properly service reverse DNS for the address ranges it is > adverting in the RA. > The phone does this already. Please read the email again. --001a11444ad658e1600566a4abf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Mar 5, 2018 at 3:35 PM, Mark Andrews <marka@isc.org> wrote:<= br>
> Saying that mobile phones must support DHCPv6 is harmful, because: >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If DHCPv6 is enabled, it's har= mful to users for the reasons explained in https://www.ietf.org/mail-archive/web/v6ops/current/msg26= 286.html .

The phone can advertise itself as a DNS server.=C2=A0 It needs to do= this anyway to properly service reverse DNS for the address ranges it is a= dverting in the RA.

The phone does this= already.=C2=A0Please read the email again.
--001a11444ad658e1600566a4abf7-- From nobody Sun Mar 4 22:52:01 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A8F127010 for ; Sun, 4 Mar 2018 22:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCKjic2fNAOf for ; Sun, 4 Mar 2018 22:51:57 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 CC0FD124239 for ; Sun, 4 Mar 2018 22:51:57 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 20F973AB001; Mon, 5 Mar 2018 06:51:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0D850160046; Mon, 5 Mar 2018 06:51:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EB8A0160068; Mon, 5 Mar 2018 06:51:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qj-D9SYU_KYq; Mon, 5 Mar 2018 06:51:54 +0000 (UTC) Received: from [172.30.42.66] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 49E3A160046; Mon, 5 Mar 2018 06:51:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Mon, 5 Mar 2018 17:51:51 +1100 Cc: "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 06:51:59 -0000 > On 5 Mar 2018, at 5:44 pm, Lorenzo Colitti wrote: >=20 > On Mon, Mar 5, 2018 at 3:35 PM, Mark Andrews wrote: > > Saying that mobile phones must support DHCPv6 is harmful, because: > > =E2=80=A2 If DHCPv6 is enabled, it's harmful to users for the = reasons explained in = https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html . >=20 > The phone can advertise itself as a DNS server. It needs to do this = anyway to properly service reverse DNS for the address ranges it is = adverting in the RA. >=20 > The phone does this already. Please read the email again. Where is the text below does it state that it is advertising itself as a = DNS server? The scenario only fails when it is re-advertising the = TELCO=E2=80=99s DNS servers and when they differ between cell towers. Mark The Android phone in my pocket is a router when I go to the coffee shop = every morning and turn on tethering. As the maintainer of that code, I = absolutely do not want to spend software engineering time writing a = DHCPv6 server that is not only less capable than the RDNSS = implementation that we have now, but also degrades functionality. The reason it is degrades functionality is that with stateless DHCPv6 it = is impossible to implement even such basic things as "tell the client = that its DNS server is now gone because the cellular network went down = and came back up with a different prefix when you temporarily lost cell = coverage". This works today using RDNSS, but if we implement DHCPv6, = this will stop working for clients that support DHCPv6, even if they = also support RDNSS. =E2=80=A2 Client gets DNS addresses from both RDNSS and DHCPv6, = and prefers DHCPv6 due to RFC 8106. =E2=80=A2 Upstream goes down. We deprecate the prefix (we can't = make it invalid because of the 2-hour rule), and declare the DNS servers = invalid. We can't do anything about DHCPv6. =E2=80=A2 The upstream comes back with a new prefix. We announce = the new DNS servers using RDNSS. But the client still uses the = out-of-date DHCPv6-provided DNS servers, because RFC 8106 says it should = prefer DHCPv6 over RDNSS. I cannot live with breaking user experience like this. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 4 22:55:16 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47246126E64 for ; Sun, 4 Mar 2018 22:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id el-pGMLBuJkF for ; Sun, 4 Mar 2018 22:55:13 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 8F2E11270A7 for ; Sun, 4 Mar 2018 22:55:12 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id x7so13244263wmc.0 for ; Sun, 04 Mar 2018 22:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vDXxrg5AdVjIX2LrY2El1y7te82P77WnHA6t3MngKT8=; b=EWCrrYewWT89ceU+tkSp+cT0DSj+z2HT0iH4rKL2qyXBvjVf26F+ob4llK23m0ob4O HfqfN24WDUV1znFjwPdivf+kirK4bpso6xdLNcSPxHDhnpKrLmiUDGgjeJSdHYvv1unZ ohnGkL2g1gQbKhBQH7ivs4AQw/Cy3mVIP2ufQ1SjGH9mKNdbPbGjR+B0Ddy9T+3qga3E a8Ec0cZUYqKyeRGisvpJHQMX/Vt9XayXBCf/msJXYSYAMyJX33YDqlcwlRaFRr0m4tBk WShm6+0D00TymMoDOdNpr6ulnr0GUQmY63aaiSMEoOH+09uN4Grsz/FZLvxK0/smpsWY aBmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vDXxrg5AdVjIX2LrY2El1y7te82P77WnHA6t3MngKT8=; b=k4EAyoIRLR9oU8JnVjXHqqczQOkAB7+01u/MUqwejDeEeZtCEW6T3vQGpCGFRtsoO4 o0WYtqPBiriDUVEevNOrE2yp48wEasmLoJx/B6sM+YovHyv5hK123ZKx5VnG6WAIjGDu hq916iihU2VQKATQGx8iRrwOZwQ745wEHGt2jLi2kunABgV1tpvLQbFZszTOaJ9wxIl7 erHPN74T+Ta3r7YZjc8lOwZ2h/QYDYu9LTxp7oA+aynFAI3LMTJODyKe+Uoq7XYFAN+z m6pIL7tAZM3v8QDIQr+4qH3PO2kQL0AWMqW9eL18qOuSxPk7YqlgBlg8gKGF0PMTNOj4 SxOQ== X-Gm-Message-State: AElRT7G4FkY7yj+z1Rf/qNZvrT10d9Jqu7vKdSRnsUEu/Ky9eYVzS0eh YCRs5XSoT7A8WlarnZHQpavolWrLoilDlNSnwQdrHA== X-Google-Smtp-Source: AG47ELuMRrGAQJ566zoF33QFEL57DrRl0R5e9PotddGHBKT7P4zBmJ/HSABv6dM30CNtLvuR1GWtETEE7qvDrJwDhck= X-Received: by 10.28.92.17 with SMTP id q17mr6758068wmb.97.1520232910742; Sun, 04 Mar 2018 22:55:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.63.79 with HTTP; Sun, 4 Mar 2018 22:54:49 -0800 (PST) In-Reply-To: <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> From: Lorenzo Colitti Date: Mon, 5 Mar 2018 15:54:49 +0900 Message-ID: To: Mark Andrews Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1146df069f7d9b0566a4cebd" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 06:55:15 -0000 --001a1146df069f7d9b0566a4cebd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DNS servers don't differ between cell towers. The thing that differs is the /64 assigned to the device. The phone announces its address in that /64 as the DNS server. When the phone's /64 prefix changes, the old address is no longer valid and potentially belongs to another customer of the network. But with stateless DHCPv6, there's no way for the phone to tell clients not to use it any more= . On Mon, Mar 5, 2018 at 3:51 PM, Mark Andrews wrote: > > > On 5 Mar 2018, at 5:44 pm, Lorenzo Colitti wrote: > > > > On Mon, Mar 5, 2018 at 3:35 PM, Mark Andrews wrote: > > > Saying that mobile phones must support DHCPv6 is harmful, because: > > > =E2=80=A2 If DHCPv6 is enabled, it's harmful to users for the r= easons > explained in https://www.ietf.org/mail-archive/web/v6ops/current/ > msg26286.html . > > > > The phone can advertise itself as a DNS server. It needs to do this > anyway to properly service reverse DNS for the address ranges it is > adverting in the RA. > > > > The phone does this already. Please read the email again. > > Where is the text below does it state that it is advertising itself as a > DNS server? The scenario only fails when it is re-advertising the TELCO= =E2=80=99s > DNS servers and when they differ between cell towers. > > Mark > > The Android phone in my pocket is a router when I go to the coffee shop > every morning and turn on tethering. As the maintainer of that code, I > absolutely do not want to spend software engineering time writing a DHCPv= 6 > server that is not only less capable than the RDNSS implementation that w= e > have now, but also degrades functionality. > > The reason it is degrades functionality is that with stateless DHCPv6 it > is impossible to implement even such basic things as "tell the client tha= t > its DNS server is now gone because the cellular network went down and cam= e > back up with a different prefix when you temporarily lost cell coverage". > This works today using RDNSS, but if we implement DHCPv6, this will stop > working for clients that support DHCPv6, even if they also support RDNSS. > =E2=80=A2 Client gets DNS addresses from both RDNSS and DHCPv6, a= nd > prefers DHCPv6 due to RFC 8106. > =E2=80=A2 Upstream goes down. We deprecate the prefix (we can't m= ake it > invalid because of the 2-hour rule), and declare the DNS servers invalid. > We can't do anything about DHCPv6. > =E2=80=A2 The upstream comes back with a new prefix. We announce = the new > DNS servers using RDNSS. But the client still uses the out-of-date > DHCPv6-provided DNS servers, because RFC 8106 says it should prefer DHCPv= 6 > over RDNSS. > I cannot live with breaking user experience like this. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > --001a1146df069f7d9b0566a4cebd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
DNS servers don't differ between cell towers. The thin= g that differs is the /64 assigned to the device.

T= he phone announces its address in that /64 as the DNS server. When the phon= e's /64 prefix changes, the old address is no longer valid and potentia= lly belongs to another customer of the network. But with stateless DHCPv6, = there's no way for the phone to tell clients not to use it any more.

On= Mon, Mar 5, 2018 at 3:51 PM, Mark Andrews <marka@isc.org> wrote= :

> On 5 Mar 2018, at 5:44 pm, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Mon, Mar 5, 2018 at 3:35 PM, Mark Andrews <marka@isc.org> wrote:
> > Saying that mobile phones must support DHCPv6 is harmful, because= :
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If DHCPv6 is enabled, it'= s harmful to users for the reasons explained in https://www.ietf.org/mail-archive/web/v6ops/current/= msg26286.html .
>
> The phone can advertise itself as a DNS server.=C2=A0 It needs to do t= his anyway to properly service reverse DNS for the address ranges it is adv= erting in the RA.
>
> The phone does this already. Please read the email again.

Where is the text below does it state that it is advertising it= self as a DNS server?=C2=A0 The scenario only fails when it is re-advertisi= ng the TELCO=E2=80=99s DNS servers and when they differ between cell towers= .

Mark

The Android phone in my pocket is a router when I go to the coffee shop eve= ry morning and turn on tethering. As the maintainer of that code, I absolut= ely do not want to spend software engineering time writing a DHCPv6 server = that is not only less capable than the RDNSS implementation that we have no= w, but also degrades functionality.

The reason it is degrades functionality is that with stateless DHCPv6 it is= impossible to implement even such basic things as "tell the client th= at its DNS server is now gone because the cellular network went down and ca= me back up with a different prefix when you temporarily lost cell coverage&= quot;. This works today using RDNSS, but if we implement DHCPv6, this will = stop working for clients that support DHCPv6, even if they also support RDN= SS.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Client gets DNS addresses from both R= DNSS and DHCPv6, and prefers DHCPv6 due to RFC 8106.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Upstream goes down. We deprecate the = prefix (we can't make it invalid because of the 2-hour rule), and decla= re the DNS servers invalid. We can't do anything about DHCPv6.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 The upstream comes back with a new pr= efix. We announce the new DNS servers using RDNSS. But the client still use= s the out-of-date DHCPv6-provided DNS servers, because RFC 8106 says it sho= uld prefer DHCPv6 over RDNSS.
I cannot live with breaking user experience like this.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTERNET: marka@isc.org


--001a1146df069f7d9b0566a4cebd-- From nobody Sun Mar 4 23:00:46 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA06127275 for ; Sun, 4 Mar 2018 23:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NPD59q6j7RM for ; Sun, 4 Mar 2018 23:00:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 A049A127241 for ; Sun, 4 Mar 2018 23:00:42 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id ED7123AB1B5; Mon, 5 Mar 2018 07:00:39 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DAC89160046; Mon, 5 Mar 2018 07:00:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C7EC5160068; Mon, 5 Mar 2018 07:00:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1KljEXgevAsC; Mon, 5 Mar 2018 07:00:39 +0000 (UTC) Received: from [172.30.42.66] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 10C8C160046; Mon, 5 Mar 2018 07:00:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Mon, 5 Mar 2018 18:00:36 +1100 Cc: "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 07:00:44 -0000 > On 5 Mar 2018, at 5:54 pm, Lorenzo Colitti wrote: >=20 > DNS servers don't differ between cell towers. The thing that differs = is the /64 assigned to the device. >=20 > The phone announces its address in that /64 as the DNS server. When = the phone's /64 prefix changes, the old address is no longer valid and = potentially belongs to another customer of the network. But with = stateless DHCPv6, there's no way for the phone to tell clients not to = use it any more. So you are tearing down the network too fast in the phone. The point to = =E2=80=9Cdeprecating=E2=80=9D the prefix is to keep stuff like this = working for a while using the deprecated addresses. If the stateless = DHCPv6 is adverting resources with TTLs longer than the RA timers then = you as a developer of the phone have build a broken product. > On Mon, Mar 5, 2018 at 3:51 PM, Mark Andrews wrote: >=20 > > On 5 Mar 2018, at 5:44 pm, Lorenzo Colitti = wrote: > > > > On Mon, Mar 5, 2018 at 3:35 PM, Mark Andrews wrote: > > > Saying that mobile phones must support DHCPv6 is harmful, because: > > > =E2=80=A2 If DHCPv6 is enabled, it's harmful to users for = the reasons explained in = https://www.ietf.org/mail-archive/web/v6ops/current/msg26286.html . > > > > The phone can advertise itself as a DNS server. It needs to do this = anyway to properly service reverse DNS for the address ranges it is = adverting in the RA. > > > > The phone does this already. Please read the email again. >=20 > Where is the text below does it state that it is advertising itself as = a DNS server? The scenario only fails when it is re-advertising the = TELCO=E2=80=99s DNS servers and when they differ between cell towers. >=20 > Mark >=20 > The Android phone in my pocket is a router when I go to the coffee = shop every morning and turn on tethering. As the maintainer of that = code, I absolutely do not want to spend software engineering time = writing a DHCPv6 server that is not only less capable than the RDNSS = implementation that we have now, but also degrades functionality. >=20 > The reason it is degrades functionality is that with stateless DHCPv6 = it is impossible to implement even such basic things as "tell the client = that its DNS server is now gone because the cellular network went down = and came back up with a different prefix when you temporarily lost cell = coverage". This works today using RDNSS, but if we implement DHCPv6, = this will stop working for clients that support DHCPv6, even if they = also support RDNSS. > =E2=80=A2 Client gets DNS addresses from both RDNSS and = DHCPv6, and prefers DHCPv6 due to RFC 8106. > =E2=80=A2 Upstream goes down. We deprecate the prefix (we = can't make it invalid because of the 2-hour rule), and declare the DNS = servers invalid. We can't do anything about DHCPv6. > =E2=80=A2 The upstream comes back with a new prefix. We = announce the new DNS servers using RDNSS. But the client still uses the = out-of-date DHCPv6-provided DNS servers, because RFC 8106 says it should = prefer DHCPv6 over RDNSS. > I cannot live with breaking user experience like this. >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 >=20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 4 23:42:21 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A031272E1 for ; Sun, 4 Mar 2018 23:42:19 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVNoplLqLXRl for ; Sun, 4 Mar 2018 23:42:18 -0800 (PST) Received: from mail.fud.no (mail.fud.no [IPv6:2a02:c0:4f0:bb02:f816:3eff:fed3:8342]) (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 801EB127275 for ; Sun, 4 Mar 2018 23:42:18 -0800 (PST) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=43874 helo=echo.ms.redpill-linpro.com) by mail.fud.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1esklC-0000ej-La; Mon, 05 Mar 2018 08:42:14 +0100 Date: Mon, 5 Mar 2018 08:42:14 +0100 From: Tore Anderson To: Mark Andrews Cc: Lorenzo Colitti , "v6ops@ietf.org WG" Message-ID: <20180305084214.6389aec9@echo.ms.redpill-linpro.com> In-Reply-To: <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 07:42:20 -0000 * Mark Andrews > > On 5 Mar 2018, at 5:54 pm, Lorenzo Colitti wrote: > >=20 > > DNS servers don't differ between cell towers. The thing that > > differs is the /64 assigned to the device. > >=20 > > The phone announces its address in that /64 as the DNS server. When > > the phone's /64 prefix changes, the old address is no longer valid > > and potentially belongs to another customer of the network. But > > with stateless DHCPv6, there's no way for the phone to tell clients > > not to use it any more. =20 >=20 > So you are tearing down the network too fast in the phone. The point > to =E2=80=9Cdeprecating=E2=80=9D the prefix is to keep stuff like this wo= rking for a > while using the deprecated addresses. If the stateless DHCPv6 is > adverting resources with TTLs longer than the RA timers then you as a > developer of the phone have build a broken product. You're forgetting that the network could be torn down for all sorts of reasons outside the phone's control, like driving through a tunnel. When you emerge from the tunnel 10 seconds later, the phone might receive a new /64. Tore From nobody Sun Mar 4 23:51:00 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E758127275 for ; Sun, 4 Mar 2018 23:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PxJfXffFtfv for ; Sun, 4 Mar 2018 23:50:56 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 82D5D126579 for ; Sun, 4 Mar 2018 23:50:56 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id t6so13536593wmt.5 for ; Sun, 04 Mar 2018 23:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xRLsN4fjzDVsR60MtdFay3fc8Ey5Dii8r//TIsYYXjI=; b=hLLsZ5TfpijxD1z9zf0mQxTEDJOvHMy0k+on7fdgyn7LMYTjG1Am8AfVp4mGb+Eqvb 6sceZjjGFzrAuY6XgI1YzLlFKzBE5vCYag7Pu+XmP4ZgDmkWVHXDPignJvj8ptnW6Pk+ HGSCWTU+mBOVJZoNbKitvwWVfTRmNgRlsgac9QI+A0HbaQIxCary3qfMPbuqkL6oyrvR RJe322M7R/dm+yH/5KycQOMWuH3XdPJdmtAfFFswDQJsx580B2uYX+sWGaaqR3J8FhPu 6TSbwAVQdeHx2aBSgBn3sVybuVRyKOYsJZZaT6G5IcV8iD6B6pM+gqPtzmtTgX/hDbSS zABA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xRLsN4fjzDVsR60MtdFay3fc8Ey5Dii8r//TIsYYXjI=; b=PwzbdDC3yB2/ec8OX8L36iMZGL/sFDEGTJiTy35pDV9amwPRWGAqRklA7JHhmFVT8q BfNTAl09HZs3jqRKF1ApgQxBIDi2/CEy7xYHQCksGuH8TjNtt8pPoKpL35eg1maJl6IB NGdnIcllT24aB8UEcPkcGeAKeVjmYZi0AV+Qm9BZotKhhMbv3l5cFS9//AdmwWtexm/4 qnz26bp4xBiXIaihkV5HevJPEXScD8HCSOSCw3eG6Bu5XFNMcuI+zPWqDGyErIFDRTLl 35w8bVFVFgal8SoGVbeQ46E6hIJyGk/ZrDM1doTIjZnPwBSzSuOGBndtE4Kzwe3n/bFU 1R1g== X-Gm-Message-State: AElRT7G6C/8Mx+0UDrtWMjB1RGNdXjAxjgDaMD2m0Ib3jCX1ZBMWGN+j /lox85qKaX6IkFvU0p74sLGRJgx0jyLqZpqb3iCBow== X-Google-Smtp-Source: AG47ELtJGoHlIJgFRRyxi5XV+iJOupYANyjv/m9wYFOxlRZ6j300rWG3nmOxlHCic0nbSE3tNFevcQXx/W5m64LDaJ8= X-Received: by 10.28.153.75 with SMTP id b72mr3050275wme.127.1520236254700; Sun, 04 Mar 2018 23:50:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.63.79 with HTTP; Sun, 4 Mar 2018 23:50:33 -0800 (PST) In-Reply-To: <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> From: Lorenzo Colitti Date: Mon, 5 Mar 2018 16:50:33 +0900 Message-ID: To: Mark Andrews Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114b2d32f04af40566a5953e" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 07:50:58 -0000 --001a114b2d32f04af40566a5953e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 5, 2018 at 4:00 PM, Mark Andrews wrote: > > The phone announces its address in that /64 as the DNS server. When the > phone's /64 prefix changes, the old address is no longer valid and > potentially belongs to another customer of the network. But with stateles= s > DHCPv6, there's no way for the phone to tell clients not to use it any mo= re. > > So you are tearing down the network too fast in the phone. The point to > =E2=80=9Cdeprecating=E2=80=9D the prefix is to keep stuff like this worki= ng for a while > using the deprecated addresses. We tear the network down when the network tears it down. Per 3GPP standards, the prefix lifetime in the RA is infinite and the prefix is current for as long as the link is up. The bottom line is if you want end-to-end connectivity, a configuration protocol that does not allow push updates is broken. --001a114b2d32f04af40566a5953e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Mar 5, 2018 at 4:00 PM, Mark Andrews <marka@isc.org> wrote:<= br>
> The phone announces its address in that /64 as the DNS server. When t= he phone's /64 prefix changes, the old address is no longer valid and p= otentially belongs to another customer of the network. But with stateless D= HCPv6, there's no way for the phone to tell clients not to use it any m= ore.

So you are tearing down the network too fast in the phone.=C2=A0 The= point to =E2=80=9Cdeprecating=E2=80=9D the prefix is to keep stuff like th= is working for a while using the deprecated addresses.
We tear the network down when the network tears it down. Per 3G= PP standards, the prefix lifetime in the RA is infinite and the prefix is c= urrent for as long as the link is up.

The bottom l= ine is if you want end-to-end connectivity, a configuration protocol that d= oes not allow push updates is broken.
--001a114b2d32f04af40566a5953e-- From nobody Sun Mar 4 23:55:51 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6271312741D for ; Sun, 4 Mar 2018 23:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dERdLzUQnF_Z for ; Sun, 4 Mar 2018 23:55:47 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 75BD5126579 for ; Sun, 4 Mar 2018 23:55:47 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 1F2673AB001; Mon, 5 Mar 2018 07:55:45 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 05E08160069; Mon, 5 Mar 2018 07:55:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E4E47160068; Mon, 5 Mar 2018 07:55:44 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OWcEmXMYi4vM; Mon, 5 Mar 2018 07:55:44 +0000 (UTC) Received: from [172.30.42.66] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id E11C6160046; Mon, 5 Mar 2018 07:55:43 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20180305084214.6389aec9@echo.ms.redpill-linpro.com> Date: Mon, 5 Mar 2018 18:55:41 +1100 Cc: Lorenzo Colitti , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <9E282363-869B-49D5-AD90-B7AA38EAF606@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> <20180305084214.6389aec9@echo.ms.redpill-linpro.com> To: Tore Anderson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 07:55:49 -0000 > On 5 Mar 2018, at 6:42 pm, Tore Anderson wrote: >=20 > * Mark Andrews >=20 >>> On 5 Mar 2018, at 5:54 pm, Lorenzo Colitti = wrote: >>>=20 >>> DNS servers don't differ between cell towers. The thing that >>> differs is the /64 assigned to the device. >>>=20 >>> The phone announces its address in that /64 as the DNS server. When >>> the phone's /64 prefix changes, the old address is no longer valid >>> and potentially belongs to another customer of the network. But >>> with stateless DHCPv6, there's no way for the phone to tell clients >>> not to use it any more. =20 >>=20 >> So you are tearing down the network too fast in the phone. The point >> to =E2=80=9Cdeprecating=E2=80=9D the prefix is to keep stuff like = this working for a >> while using the deprecated addresses. If the stateless DHCPv6 is >> adverting resources with TTLs longer than the RA timers then you as a >> developer of the phone have build a broken product. >=20 > You're forgetting that the network could be torn down for all sorts of > reasons outside the phone's control, like driving through a tunnel. > When you emerge from the tunnel 10 seconds later, the phone might > receive a new /64. So? The existing /64 is STILL valid. You just have 2 prefixes. > Tore --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Mar 4 23:56:58 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D87126BF0 for ; Sun, 4 Mar 2018 23:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELlVKGnH0sUh for ; Sun, 4 Mar 2018 23:56:55 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 0A69D126579 for ; Sun, 4 Mar 2018 23:56:55 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id 139so13578113wmn.2 for ; Sun, 04 Mar 2018 23:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xMCDhTbbgZt7rTu29OusYwS+CMSA6LKar8N+bJRov3o=; b=Vc3RIAlp3WnfpnDC9DTk1T0P5Xeg7dbKtxZYRTMqAqgIx1+1n9QdTEwcaIRyVmz1Qn mJYHg2tgWR5bC2ARYMUChIH7sMZVOIi7ydrHx1t8c0ePtXArqWMc379VCVglK+11ds8Q /HYR8yRkv2MwSVO6q08ZYdRyFF8bRBTRHR/b0GwvghS1myrRS0CxyKad/iVuswRzTRMw 39aZvZlZkzIo8gRo5tthjuLFz+n4hN5gofV+qEqJKb34bbbNAPaayIyDGWlihykEUeJz oqHiheoo3MlkVIDaOl11VeXPEc0XhDoI+GenQBSat6NM9O9lpfpI1O8QAQ8RGY3QB95O 9C1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xMCDhTbbgZt7rTu29OusYwS+CMSA6LKar8N+bJRov3o=; b=LeAHoRGIPDTy2VoXLmVRCrxRilqO36pIlgAWLr8/UfIYeK9Aw4ssJ/xcd2Wd2Q0/ut qwlj3edThz6dRcttHUK6SdI8YwIjwtXVLQ4gcoNFO2CNvBjCJBIxTgd7Ahq4x8S07ddj XBQjQaFxh3/pQu6bsKlmZu3kjiOpm/4V890jt+hqsew0KUqiFIiTb6tCL0RkdBnZNHH8 6c1daK22lY4CGf/598TmoUcuiqarsvkcDBN6CI4S0hoSt0h5AISfBMEWALJqnzt7h8Bh qrYTOauswg5UZq+mxOJ4eicss1Tv49Zat3LhY+lm71Ngphd8qc5XQNGTJhWomiyBemnL OutA== X-Gm-Message-State: AElRT7FkNINqiLYz3gWxvJ3A08SA983NgjjEEnb5msVvZpBFqJDeBfan f9oekGQKQnA9nYE9tatIkgvFWOyomOMiEGoNcHUrRI8O X-Google-Smtp-Source: AG47ELu2w9kos80Pb7x2z9sEZxICIkXRqrUkpJ29FtkUQaQOuwY2tsIMkRIySV1CDXjcGrvHUG5FwPDfQNBuadJQflo= X-Received: by 10.28.172.202 with SMTP id v193mr6849376wme.129.1520236613177; Sun, 04 Mar 2018 23:56:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.63.79 with HTTP; Sun, 4 Mar 2018 23:56:32 -0800 (PST) In-Reply-To: <9E282363-869B-49D5-AD90-B7AA38EAF606@isc.org> References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> <20180305084214.6389aec9@echo.ms.redpill-linpro.com> <9E282363-869B-49D5-AD90-B7AA38EAF606@isc.org> From: Lorenzo Colitti Date: Mon, 5 Mar 2018 16:56:32 +0900 Message-ID: To: Mark Andrews Cc: Tore Anderson , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1141f2244e37cb0566a5abd7" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 07:56:57 -0000 --001a1141f2244e37cb0566a5abd7 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 5, 2018 at 4:55 PM, Mark Andrews wrote: > > You're forgetting that the network could be torn down for all sorts of > > reasons outside the phone's control, like driving through a tunnel. > > When you emerge from the tunnel 10 seconds later, the phone might > > receive a new /64. > > So? The existing /64 is STILL valid. You just have 2 prefixes. > No you don't, the network is free to assign the old one to someone else. --001a1141f2244e37cb0566a5abd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Mar 5, 2018 at 4:55 PM, Mark Andrews <marka@isc.org> wrote:<= br>
> You're forgetti= ng that the network could be torn down for all sorts of
> reasons outside the phone's control, like driving through a tunnel= .
> When you emerge from the tunnel 10 seconds later, the phone might
> receive a new /64.

So?=C2=A0 The existing /64 is STILL valid. You just have 2 prefixes.=

No you don't, the network is free = to assign the old one to someone else.
--001a1141f2244e37cb0566a5abd7-- From nobody Mon Mar 5 00:00:57 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640041270A7 for ; Mon, 5 Mar 2018 00:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71-Ns0CEpXCz for ; Mon, 5 Mar 2018 00:00:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 27B16126BF0 for ; Mon, 5 Mar 2018 00:00:42 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id DF9223AB03F; Mon, 5 Mar 2018 08:00:39 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7CFE8160046; Mon, 5 Mar 2018 08:00:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 60707160068; Mon, 5 Mar 2018 08:00:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W1fb7oO1ZI1y; Mon, 5 Mar 2018 08:00:39 +0000 (UTC) Received: from [172.30.42.66] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 94B83160046; Mon, 5 Mar 2018 08:00:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Mon, 5 Mar 2018 19:00:36 +1100 Cc: Tore Anderson , "v6ops@ietf.org WG" Content-Transfer-Encoding: 7bit Message-Id: References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> <20180305084214.6389aec9@echo.ms.redpill-linpro.com> <9E282363-869B-49D5-AD90-B7AA38EAF606@isc.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 08:00:44 -0000 > On 5 Mar 2018, at 6:56 pm, Lorenzo Colitti wrote: > > On Mon, Mar 5, 2018 at 4:55 PM, Mark Andrews wrote: > > You're forgetting that the network could be torn down for all sorts of > > reasons outside the phone's control, like driving through a tunnel. > > When you emerge from the tunnel 10 seconds later, the phone might > > receive a new /64. > > So? The existing /64 is STILL valid. You just have 2 prefixes. > > No you don't, the network is free to assign the old one to someone else. Again there is NOTHING stopping the phone advertising itself over a ULA prefix even if it is tearing down the prefixes from upstream. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Mar 5 00:07:29 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7CD126D45 for ; Mon, 5 Mar 2018 00:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC9nAclqJXUH for ; Mon, 5 Mar 2018 00:07:27 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C700126579 for ; Mon, 5 Mar 2018 00:07:27 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id q83so13963365wme.5 for ; Mon, 05 Mar 2018 00:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5nR4HHoZp7aFYYIqxIpARWbSGHODQQ5lUAaruZdGF5M=; b=KrF43ydw6u4OdXg96l0vd2a6aRBB5GvH83PWiugUtZFu4+o2UFDNfxkYPbUg7EvFKJ sFYD2N5G9sx9IKxuABpTi0Ap0sBKOO7KIon9FVl9zNpx3hJ46rlrBC1bL4Nrk1pd4uSL cxJ9H2QbKD+LZJKtNjiud1W552XB86Xb/dArSegMWhbVH9drGjnAJouo2KQAb3iaMAEw /y6X3Qw++ho1/iS4tvj7SWkh10Cv3FkjE7QFq5100WJbgPVP6EznTotGiNklEC+QEXuV VHRJSSztOPugOm767IMw0yO4lrXAbIIWEz+I3RRuC7t14KYS+1fgMl7PgFof+hsetGTn nqmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5nR4HHoZp7aFYYIqxIpARWbSGHODQQ5lUAaruZdGF5M=; b=mxfMY6ZxIgE2WDaJ5QzpbbBjQOt6H9DfiQ4KCJwdRoEb7FDsyMmf+xxlaexMNGyKch mPyPcHvPq+xvpO6r1N6179cA6IUEule3RcTLWqJRTK7C3bXmNhJxsGSErZ1Rv7lfvcgX D0eI5pfpRAvFWo59Tc5NB66jGwaoQyQBWZ064JqHr/+n+Mjb+9/EEqyCaR9BqIz38Hiy dRmlrucUqyPlkNV4ac1EHlk8zWNSGtqvoK5DOdi8ean48CR4oN/8eZDp/hDUNPbsB/b1 JKSRF+yIeQtGouwqpS3fWyXawylW0pwJ0ZgWOFPpH91I8pB1ekjenL0FoG2Du4Jj7zY0 uLjQ== X-Gm-Message-State: AElRT7GQRI2zp6Uvqe3+sJCBL3LrbqmExtvHjZkhwBLixXZg9EmYeTR4 1PrD+FsCi0lCnLZD6JT9oOBoEkHMoNc0px5IuUU7P34J X-Google-Smtp-Source: AG47ELsLmLhoG+qoJCKR+7+xQ43/C0f8aJlJgY5CU9oPUp0oEUyR3OmwU/CHBnhut21ZvEIuoZJ+iRRo/YPyRY63xHA= X-Received: by 10.28.182.212 with SMTP id g203mr6998362wmf.155.1520237245493; Mon, 05 Mar 2018 00:07:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.63.79 with HTTP; Mon, 5 Mar 2018 00:07:04 -0800 (PST) In-Reply-To: References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <0E0957B6-FA65-4CB0-965F-832699118204@isc.org> <9C6ADA3B-8EC8-4E30-94C9-36285A9FFCCA@isc.org> <02EF1B15-1344-4316-8F96-3105D82F4E4D@isc.org> <20180305084214.6389aec9@echo.ms.redpill-linpro.com> <9E282363-869B-49D5-AD90-B7AA38EAF606@isc.org> From: Lorenzo Colitti Date: Mon, 5 Mar 2018 17:07:04 +0900 Message-ID: To: Mark Andrews Cc: Tore Anderson , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1148f228fea1450566a5d070" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 08:07:29 -0000 --001a1148f228fea1450566a5d070 Content-Type: text/plain; charset="UTF-8" "Let's add another IPv6 address range because our configuration protocols can't update the one we have." Seems like the wrong solution. On Mon, Mar 5, 2018 at 5:00 PM, Mark Andrews wrote: > > > On 5 Mar 2018, at 6:56 pm, Lorenzo Colitti wrote: > > > > On Mon, Mar 5, 2018 at 4:55 PM, Mark Andrews wrote: > > > You're forgetting that the network could be torn down for all sorts of > > > reasons outside the phone's control, like driving through a tunnel. > > > When you emerge from the tunnel 10 seconds later, the phone might > > > receive a new /64. > > > > So? The existing /64 is STILL valid. You just have 2 prefixes. > > > > No you don't, the network is free to assign the old one to someone else. > > Again there is NOTHING stopping the phone advertising itself over a ULA > prefix even if it is tearing down the prefixes from upstream. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > --001a1148f228fea1450566a5d070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Let's add another IPv6 address range because our= configuration protocols can't update the one we have."

Seems like the wrong = solution.

On= Mon, Mar 5, 2018 at 5:00 PM, Mark Andrews <marka@isc.org> wrote= :

> On 5 Mar 2018, at 6:56 pm, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> On Mon, Mar 5, 2018 at 4:55 PM, Mark Andrews <marka@isc.org> wrote:
> > You're forgetting that the network could be torn down for all= sorts of
> > reasons outside the phone's control, like driving through a t= unnel.
> > When you emerge from the tunnel 10 seconds later, the phone might=
> > receive a new /64.
>
> So?=C2=A0 The existing /64 is STILL valid. You just have 2 prefixes. >
> No you don't, the network is free to assign the old one to someone= else.

Again there is NOTHING stopping the phone advertising itself ov= er a ULA
prefix even if it is tearing down the prefixes from upstream.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 INTERNET: marka@i= sc.org


--001a1148f228fea1450566a5d070-- From nobody Mon Mar 5 03:01:14 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EB0128961 for ; Mon, 5 Mar 2018 03:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGloB0DVrtuS for ; Mon, 5 Mar 2018 03:01:10 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824E812783A for ; Mon, 5 Mar 2018 03:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1520247668; x=1520852468; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=7cE8V3pI qu3rIDXpLIp1tnIe3BSBz1z8dYWX7cTOplk=; b=NurNAXaNv9/YVbprMc9UOYa7 FOAxc0Wf/AAs+8aRnq5z6Vf7meHLLcLhWx4cGtZotgjDJR+3mj6Dp6B7sn8G+1d/ rUThPaIPxGXsiGjjrR8mGab6wsAVyq87X/ZK9vBPeo2JdFiba3CN1zB5oe/4mIgz hf/ZU758IQVmlAdL91s= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 05 Mar 2018 12:01:08 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 05 Mar 2018 12:01:07 +0100 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005717873.msg for ; Mon, 05 Mar 2018 12:01:06 +0100 X-MDRemoteIP: 2001:470:1f09:495:21f6:7243:897d:259a X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 05 Mar 2018 12:01:06 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1602d02a78=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.a.0.180210 Date: Mon, 05 Mar 2018 12:01:06 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: New Version Notification for draft-palet-v6ops-nat64-deployment-00.txt References: <152024746250.27921.7443947330506188583.idtracker@ietfa.amsl.com> In-Reply-To: <152024746250.27921.7443947330506188583.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-nat64-deployment-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 11:01:12 -0000 Hi all, As agreed in the last v6ops WG meeting, I've re-worked the document draft-p= alet-v6ops-464xlat-deployment-00 into a wider discussion and guidelines for= NAT64 deployment in operators and enterprise networks, considering all the= possible issues. https://datatracker.ietf.org/doc/draft-palet-v6ops-nat64-deployment/?includ= e_text=3D1 Regards, Jordi =20 =EF=BB=BF-----Mensaje original----- De: Fecha: lunes, 5 de marzo de 2018, 11:57 Para: Jordi Palet Martinez , Jordi Martinez= Asunto: New Version Notification for draft-palet-v6ops-nat64-deployment-00.= txt =20 A new version of I-D, draft-palet-v6ops-nat64-deployment-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-nat64-deployment Revision: 00 Title: NAT64 Deployment Guidelines in Operator and Enterprise Networks Document date: 2018-03-04 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= nat64-deployment-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-nat6= 4-deployment/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-nat64-dep= loyment-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -nat64-deployment-00 =20 =20 Abstract: This document describes how NAT64 ([RFC6146]) can be deployed in an IPv6 operator or enterprise network and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64 ([RFC6147]), b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Mar 5 05:16:42 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E37B12D94F for ; Mon, 5 Mar 2018 05:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzV9cxPdQubd for ; Mon, 5 Mar 2018 05:16:35 -0800 (PST) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 4979D12D80E for ; Mon, 5 Mar 2018 05:16:35 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w25DGXHd027593 for ; Mon, 5 Mar 2018 14:16:33 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 386DC2069DE for ; Mon, 5 Mar 2018 14:16: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 25BBA203B54 for ; Mon, 5 Mar 2018 14:16:33 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w25DGWH9028369 for ; Mon, 5 Mar 2018 14:16:33 +0100 To: v6ops@ietf.org References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> From: Alexandre Petrescu Message-ID: <976066da-49d0-0fc7-2b19-4196398c837d@gmail.com> Date: Mon, 5 Mar 2018 14:16:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 13:16:42 -0000 Well, if 5G IPv6 is a hell for spooks and cops then 4G IPv4 was a hell too: nobody tracks people by IP addresses in cellular networks. In cellular networks people are tracked by their phone numbers, basestation id and good timestamps. These stay the same in 5G. Cops may want to use IP addresses to track DDoS sources but that's not issued from a mobile network(?) I am not even sure that 5G will use IPv6 :-) Alex Le 05/03/2018 à 02:19, Brian E Carpenter a écrit : > Success at last :-) > > http://www.theregister.co.uk/2018/02/27/ipv6_5g_complicate_gathering_evidence_and_surveillance/ > > Regards > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Mar 5 07:28:06 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D02A12D777 for ; Mon, 5 Mar 2018 07:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLRQIk__gl6u for ; Mon, 5 Mar 2018 07:28:03 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 2673E127201 for ; Mon, 5 Mar 2018 07:28:03 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w25FQbiY008738 for ; Mon, 5 Mar 2018 15:28:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=+2+GRMweT7dEtyk6acRY5DlPe3N9SB1CDIrJUa9qXDQ=; b=MOwqwWnQeRpTbjA8yJFSnHDqPfyDYEWoC094/kkckwZzM4syMv8CUa9/PnDR6EPqd/cq VPgfzdbFtzCrlW3eudb7gMyDLMW9WI/u5on7bfmMFu7MRwp2pmnq6cz9dNQATbzPwPB9 7r1Lx4WsD0hUCWBjHdvCdY749JxJHh0dxAFKi0wLn9Y7htpCFb4C6T9CtFS4yc0Iibih mDLWuywIl3k3ORKOFzEgwkYUp5U6I9WaXccVGBCsXYN9k1Jcf3X5Q2jP99xZH2luJLr7 e7dPimKsWXz2ofH3+fR0vTd/sG0jTghH2R2SlMZyJ4M70ZN6Hn75auwsGdDiedJMKo/s 2A== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2gfr9n5s3v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 05 Mar 2018 15:28:01 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w25FPbhc027801 for ; Mon, 5 Mar 2018 10:28:01 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2gfqx0mttc-1 for ; Mon, 05 Mar 2018 10:28:00 -0500 Received: from [172.28.11.215] (padesk.kendall.corp.akamai.com [172.28.11.215]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 8A0878441C for ; Mon, 5 Mar 2018 15:28:00 +0000 (GMT) Cc: v6ops@ietf.org References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> From: Pablo Alvarez Message-ID: <7356fe3a-3818-1c9e-2a90-d65fe8b3bb14@akamai.com> Date: Mon, 5 Mar 2018 10:28:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <152021615239.27925.6946415833371012617@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-05_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803050183 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-05_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803050183 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 15:28:04 -0000 I am happy with the updates to section 5.4, ICMP considerations. Thanks Pablo Alvarez On 03/04/18 21:15, 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 WG of the IETF. > > Title : Requirements for IPv6 Routers > Authors : Zaid Ali Kahn > John Brzozowski > Russ White > Filename : draft-ietf-v6ops-ipv6rtr-reqs-02.txt > Pages : 32 > Date : 2018-03-04 > > Abstract: > The Internet is not one network, but rather a collection of networks. > The interconnected nature of these networks, and the nature of the > interconnected systems that make up these networks, is often more > fragile than it appears. Perhaps "robust but fragile" is an > overstatement, but the actions of each vendor, implementor, and > operator in such an interconnected environment can have a major > impact on the stability of the overall Internet (as a system). The > widespread adoption of IPv6 could, particularly, disrupt network > operations, in a way that impacts the entire system. > > This time of transition is an opportune time to take stock of lessons > learned through the operation of large scale networks on IPv4, and > consider how to apply these lessons to IPv6. This document provides > an overview of the design and architectural decisions that attend > IPv6 deployment, and a set of IPv6 requirements for routers, > switches, and middleboxes deployed in IPv6 networks. The hope of the > editors and contributors is to provide the necessary background to > guide equipment manufacturers, protocol implementors, and network > operators in effective IPv6 deployment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-02 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-02 > > > 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 > From nobody Mon Mar 5 10:07:17 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F9012D869 for ; Mon, 5 Mar 2018 10:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRviFKcy-90G for ; Mon, 5 Mar 2018 10:07:10 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6D7912DA23 for ; Mon, 5 Mar 2018 10:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1520273226; x=1520878026; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=PprgbWfF R2mTtbvLCX3QGoNOzgabY0N6guoLnnlD9bg=; b=tPysgdT3+r91LEEEA0Lr4KDY y0FNOsewE2KmKldfsXqjwTCRh7bRxEY1W4PpG2FSozyFu5ajb3yZ5NWYqKX9dk7C hv0BCMDX62TVndiJD3M4DXFUiFrlyx0+Cmu2COs/cry1XgMY8Kvnhauo3eL5qGQh cFF/l8EFYoa/00D5YIM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 05 Mar 2018 19:07:06 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 05 Mar 2018 19:07:06 +0100 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005718228.msg for ; Mon, 05 Mar 2018 19:07:06 +0100 X-MDRemoteIP: 2001:470:1f09:495:8123:d275:e3ff:e0c9 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 05 Mar 2018 19:07:06 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1602d02a78=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.a.0.180210 Date: Mon, 05 Mar 2018 19:07:02 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <42829C86-4C9C-412F-99A7-11D323255552@consulintel.es> Thread-Topic: New Version Notification for draft-palet-v6ops-p2p-links-00.txt References: <152027294701.14511.6374903529986173430.idtracker@ietfa.amsl.com> In-Reply-To: <152027294701.14511.6374903529986173430.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-links-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 18:07:12 -0000 Hi all, As requested in the last v6ops meeting, I've worked in a new version of dra= ft-palet-v6ops-p2p-from-customer-prefix-01, in order to consider all the po= ssible options for point-to-point links: https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-links/?include_text= =3D1 Regards, Jordi =20 =EF=BB=BF-----Mensaje original----- De: Fecha: lunes, 5 de marzo de 2018, 19:02 Para: Jordi Palet Martinez , Jordi Martinez= Asunto: New Version Notification for draft-palet-v6ops-p2p-links-00.txt =20 A new version of I-D, draft-palet-v6ops-p2p-links-00.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-palet-v6ops-p2p-links Revision: 00 Title: IPv6 Point-to-Point Links Document date: 2018-03-05 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-palet-v6ops-= p2p-links-00.txt Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-= links/ Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-p2p-links= -00 Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6ops= -p2p-links-00 =20 =20 Abstract: This document describes different alternatives for configuring IPv6 point-to-point links, considering the prefix size, numbering choices and prefix pool to be used. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Mar 5 16:49:32 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315A912D7F4 for ; Mon, 5 Mar 2018 16:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_EuCtRV-rtX for ; Mon, 5 Mar 2018 16:49:26 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 288561241F5 for ; Mon, 5 Mar 2018 16:49:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w260nPXs043999; Mon, 5 Mar 2018 17:49:25 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w260nFkf043941 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Mon, 5 Mar 2018 17:49:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 5 Mar 2018 16:49:14 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Mon, 5 Mar 2018 16:49:14 -0800 From: "Templin, Fred L" To: V6 Ops List Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdO040AYKA7pQ0viQHaxO112MVrszA== Date: Tue, 6 Mar 2018 00:49:14 +0000 Message-ID: <907e34a0fd884fa5b5bc71abfc538f8b@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 00:49:32 -0000 See below for the draft submission announcement for a new version of this document. The major change was the addition of the following new section: +++ 10. Prefix Delegation Services Selection of prefix delegation services must be considered according to specific use cases. An example service is that offered by DHCPv6 [RFC3633]. An alternative service based on IPv6 ND messaging has also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]. Other, non-router, mechanisms may exist, such as proprietary IPAMs, [I-D.ietf-anima-prefix-management] and [I-D.sun-casm-address-pool-management-yang]. +++ Please review and post comments to the list. Thanks - Fred -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, March 02, 2018 8:09 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-19.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation Models Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-19.txt Pages : 14 Date : 2018-03-02 Abstract: IPv6 prefixes are typically delegated to requesting routers which assign them to their downstream-attached links and networks. This document considers prefix delegation models according to whether the requesting router acts as a router on behalf of any downstream networks, as a host on behalf of its local applications or as both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-19 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-19 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Mar 5 17:51:06 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13680124217 for ; Mon, 5 Mar 2018 17:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg3iUW6tpd4y for ; Mon, 5 Mar 2018 17:51:00 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D76127286 for ; Mon, 5 Mar 2018 17:51:00 -0800 (PST) Received: from [192.168.3.68] (unknown [186.138.211.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8093D86367; Tue, 6 Mar 2018 02:50:58 +0100 (CET) To: "v6ops@ops.ietf.org" From: Fernando Gont Message-ID: <8cee137e-9f24-d816-2424-9fc4b7a5f35b@si6networks.com> Date: Mon, 5 Mar 2018 22:38:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs: ICMP considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 01:51:02 -0000 Folks, Couple of comments: > Internet Control Message Protocol (ICMP) is described in [RFC0792] > and [RFC4443]. ICMP is often used to perform a traceroute through a > network (normally by using a TTL expired ICMP message), for Path MTU > discovery, and, in IPv6, for autoconfiguration and neighbor > discovery. ICMP is often blocked by middleboxes of various kinds > and/or ICMP filters configured on the ingress edge of a provider > network, most often to prevent the discovery of reachable hosts and > network topology. I don't disagree with this comment. Although I'd say that because of rate-limiting it's more reliable to fire TCP segment for network recon (e.g., by TCP dstport=80, and wait for SYN/ACK or RST). Routers implementing IPv6: > > o Should rate limit the generation of ICMP echo and echo responses > by default (for instance, using a token bucket method as described > in [RFC4443]). The device should support the configuration of not > generating ICMP echo and echo response packets to prevent topology > discovery. I'd s/topology discovery/node discovery/ Me, I'd associate *Time Exceeded Message* (traceroute) with topology discovery. 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 Mon Mar 5 18:54:20 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B100B1273E2 for ; Mon, 5 Mar 2018 18:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3r28iSSgQYs for ; Mon, 5 Mar 2018 18:54:16 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 8DB961201FA for ; Mon, 5 Mar 2018 18:54:15 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id 37so26264348lfs.7 for ; Mon, 05 Mar 2018 18:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8OdB/1a+NwAm5tW9Ggw1KCUOWwp6AkZ9JJWAyl/JgVM=; b=HmGlfO1abKJPUZ2R1BdjGES14g/wcr6atq9iUNiiYpFK1MEGVWJ42wg+8rNS/O7rmU jBi63yTLPXgHeITEzwgBcIaxwwU37CR5cPYlsIiDGY087M+D0E7RVkZWCtwu9f+iD9uY Ce+k40lTkvU7jBbtQzWJ4p0XwNB2MQjtVsCYFCmIzptHmlCX+9dxaDbcJtbKWeEGVdQt 6rfNV/tddazn+iheLUIGRT5osrHLX5ulm1tjwoYqt/DkN5vF2Fhp6sglSR53kagRxtOo 6LdL7PitHPd7S8ILGdQK1u94h/Bj00bLpr17X7aMZUUhu0f6Pphn6OPjpLyZ0tKcgHpD 54RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8OdB/1a+NwAm5tW9Ggw1KCUOWwp6AkZ9JJWAyl/JgVM=; b=co7tiVKMqMaT7lSFaP17cwBOzmeGoT7BCr2ouzkFhEYnhFF3lOohuzP/gIlfzkeldN UBlj5VNDpJdTTzv3B/x16k55ugXFV3i6CtWi5vwdhmWdhrDaTJ+erZibQJVeHQhVLSus jPR9nQ309wk0/xknJPn6Hgr5jPDfLcoJnD4xAmfG5XY3Ckr/QsNKhdPCS+b+CZUGYFye TaSaZnbCQCiO4ai4+pVHC6Dc6yW2qvf2knY84019U/I//iEF8iY1c4nSYxTm10rR4C7i IvZ+DJY70HLdebctG2I65XEdspgl29jag5EuQK9q1RkoT9KKg+naUe/fxwBb359ReyQb SKKw== X-Gm-Message-State: AElRT7ETerStvaTPepbPI5cdp7jm/S+An13dQq7QwTsZ/CGXgfHpTw5x MTdc5lGPXuehkJJEoEHTigkKi7UN8QgYcHtZtkv017NN X-Google-Smtp-Source: AG47ELsnSMTfCQFFPq//yQf/+jdpowIJ6wySqYu/5EZXTdgWmcDTkZ0i8a3JdoAC5qbosNYzH8ZjYuljfBY8CfjAw68= X-Received: by 10.46.92.7 with SMTP id q7mr11389908ljb.21.1520304853530; Mon, 05 Mar 2018 18:54:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.209.10 with HTTP; Mon, 5 Mar 2018 18:53:52 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> From: Jen Linkova Date: Tue, 6 Mar 2018 13:53:52 +1100 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 02:54:19 -0000 Hi Dusan, First of all, thanks for your comments! On Sat, Mar 3, 2018 at 3:21 AM, Mudric, Dusan (Dusan) wrote: > In Abstract: > > "The problem of enterprise multihoming without address > translation of any form has not been solved yet as it requires both > the network to select the correct egress ISP based on the packet > source address and hosts to select the correct source address based > on the desired egress ISP for that traffic." > > Should be: > "The problem of enterprise multihoming without address > translation of any form has not been solved yet as it requires > the hosts to select the correct source address based > on a destination address for that traffic, > the hosts to select a first hop router based on the packet > source address, and the network to select the correct egress ISP based on the packet > source address" As Gert has pointed out already, your text does not describe the problem the draft is trying to solve. 1) "the hosts to select the correct source address based on a destination address for that traffic," - this is default address selection RFC. If all information the host has (all information which needs to be taken into account) is the destination IP and the set of source IPs, then the RFC6724 describes how it should be done. 2) " the hosts to select a first hop router based on the packet source address, and the network to select the correct egress ISP based on the packet source address" If hosts in the given multihomed network can use any/all uplinks (the draft refers to it as 'load-balancing scenario'), then yes, it would work but only while all uplinks are available. As soon as one IPS uplink can not be used (because it's failed or because of the policy - the draft refers to it as 'active/backup uplink scenario') we need a mechanism to close the feedback loop and signal back to hosts that source addresses need to be selected based on the ISP uplink available. > > 3.2.1. Single Router, Primary/Backup Uplinks > > What "if{packet_destination_address is in 2001:db8:1::/48 or 2001:db8:2::/48}"? Will the next hop still be determined by the source address? If yes, is the destination address check needed? I see. I think I need to change 'next-hop' to 'default'. Obviously intra-site routing should not be affected, this example policy is for determining the ISP uplink only. All destinations are sent there, it's about choosing between the default route pointing to the ISP_A and default route pointing to the ISP_B. I'll update the text to make it more clear. > > 3.2.2. Two Routers, Primary/Backup Uplinks > Similar as above. > > Why would R1 have a policy that sends a packet to "next-hop is ISP_B_uplink", if it does not talk to ISP_B? Because R1 still may receive packets from hosts with source addresses belonging to ISP_B address space. > With R1 and R2 policies, H1 would have only one prefix all the time. How will H1 do load balancing or send one application stream over ISP_A and another over ISP_B, if needed? Maybe the first sentence needs to state that only one ISP can be used. It's explained in https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-01#section-2.1 : " - Uplink(s) to one ISP is a primary (preferred) one. All other uplinks are backup and are not expected to be used while the primary one is operational; - If the primary uplink is operational, all Internet traffic should flow via that uplink; " Section 2 defines the scenarios the draft is applicable to, and then Section 3 illustrates how the conditional RAs can be used in those scenarios. I'll add an additional reference to the Section 2 if you think it makes the document more clear. > > 3.2.3. Single Router, Load Balancing Between Uplinks > If load balancing is used, R1 sends packets to an ISP_x based on the source address. This means the host must know which ISP (source address) to select. How does host know this? It does not. Hosts select source addresses as per RFC6724 so (depends on the destination addresses) we can not predict which prefix will be used as a source. As both (all) uplinks can be used at the same time, that's fine, each flow will be sent to the correct uplink based on its source address. Maybe the words 'load balancing' are confusing. Does 'load sharing' sound better? > 3.2.5. Topologies with Dedicated Border Routers > "For load-balancing case ... > prefix 2001:db8:2:1::/64 { > if ISP_B_uplink_route is present then preferred_lifetime = 0 > else preferred_lifetime = 604800 > }" > > Is this just copy and paste from the NON-load-balancing policy? Why would H1 use 2001:db8:2:1::/64 if "ISP_B_uplink_route is NOT present" and send traffic over R2 - R3 - ISP_A with 2001:db8:2:1::x source address? Ah, yeah, typo indeed, should read ' if ISP_B_uplink_route is present then preferred_lifetime 604800, else preferred_lifetime = 0'. Good catch, thanks! > > Page 10: > Typo: "trgger" Thanks, will fix it. > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Jen Linkova >> Sent: Tuesday, February 27, 2018 3:03 PM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt >> >> The draft (draft-ietf-v6ops-conditional-ras)has been updated to >> address comments received in Singapore. >> >> Any feedback is appreciated, especially if you have any suggestions on >> how to improve the document. >> >> On Wed, Feb 28, 2018 at 6:57 AM, wrote: >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts directories. >> > This draft is a work item of the IPv6 Operations WG of the IETF. >> > >> > Title : Using Conditional Router Advertisements for Enterprise >> Multihoming >> > Authors : Jen Linkova >> > Massimiliano Stucchi >> > Filename : draft-ietf-v6ops-conditional-ras-01.txt >> > Pages : 17 >> > Date : 2018-02-27 >> > >> > Abstract: >> > This document discusses most common scenarios of connecting an >> > enterprise network to multiple ISPs using an address space assigned >> > by an ISP. The problem of enterprise multihoming without address >> > translation of any form has not been solved yet as it requires both >> > the network to select the correct egress ISP based on the packet >> > source address and hosts to select the correct source address based >> > on the desired egress ISP for that traffic. >> > [I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to >> > this problem by introducing a new routing functionality (Source >> > Address Dependent Routing) to solve the uplink selection issue and >> > using Router Advertisements to influence the host source address >> > selection. While the above-mentioned document focuses on solving the >> > general problem and on covering various complex use cases, this >> > document describes how the solution proposed in >> > [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited >> > number of common use cases. In particular, the focus is on scenarios >> > where an enterprise network has two Internet uplinks used either in >> > primary/backup mode or simultaneously and hosts in that network might >> > not yet properly support multihoming as described in [RFC8028]. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dconditional- >> 2Dras_&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhI >> oUWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFiv >> eiJiW4g&s=4GiE9981xqO7DwH-RffXvRXuxwZGkG_QrwoHaFUVsc4&e= >> > >> > There are also htmlized versions available at: >> > https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dconditional-2Dras- >> 2D01&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo >> UWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFive >> iJiW4g&s=1q5WZlStkpgafuIZcNyITzCYHMR9sxnxPjqRsanSv0w&e= >> > https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dconditional- >> 2Dras- >> 2D01&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo >> UWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFive >> iJiW4g&s=3Yki_IS8Q3O9n3vWhd8JTcchlcUF0_8nCIMTKUFeBc8&e= >> > >> > A diff from the previous version is available at: >> > https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dconditional- >> 2Dras- >> 2D01&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo >> UWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFive >> iJiW4g&s=EzOsCZBnjl_2C2UOT7sBNzyvAVc7XN7ULjrSXwlcL34&e= >> > >> > >> > 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: >> > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet- >> 2Ddrafts_&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iC >> rhIoUWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHR >> FiveiJiW4g&s=k-4jLyp-ruXqFPp_GKnLNTWz_VXishJWQtLDfIixeFU&e= >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1 >> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Tvwol >> b891s9E__RcQ05Srqho90KVleyHRFiveiJiW4g&s=jY0VQvQFNS1fCWqzD1ewRO >> p807KXejHGqSOM79nXAWA&e= >> >> >> >> -- >> SY, Jen Linkova aka Furry >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1 >> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Tvwol >> b891s9E__RcQ05Srqho90KVleyHRFiveiJiW4g&s=jY0VQvQFNS1fCWqzD1ewRO >> p807KXejHGqSOM79nXAWA&e= -- SY, Jen Linkova aka Furry From nobody Mon Mar 5 19:03:10 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E469B12E042 for ; Mon, 5 Mar 2018 19:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItUwcgkpxZvD for ; Mon, 5 Mar 2018 19:03:07 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 9142612DB6D for ; Mon, 5 Mar 2018 19:03:06 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id f75so26286635lfg.6 for ; Mon, 05 Mar 2018 19:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cRY78B/FN15b1/RgkEgZB0NXpCEGyGby749Zw0J86qQ=; b=doTEqfFhqegxNqnfkphD459plmXDt+PmVtiI33QYdFXuBQlKvBK32mUy2vONhudnI3 OCHwVYdxBmVg9iJrlmHoPOaeOllN36/DRDGigODds6STfa/EnoViIct9V9PpSMwq3RFu MDeFJWIsDtdDT56l9H4AJMJfPonr6X0mpF9H3awopWsbXnsz7pG6aW+4KtUudb6g0+ew 27hyFtPupywv+lfJDgwZ+w+OV6hSDj0YSw1cY7mXyjl1YztVsW5oOWLADMsc7rmbPTFp cOsohQGVJ0/I2UW9SBsFfowD75oLVB4pcFBrpN4Afsab27pGkgtXBfZA0hQEgfnJaFJ8 qcpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cRY78B/FN15b1/RgkEgZB0NXpCEGyGby749Zw0J86qQ=; b=k3WWxIKWL47RGgciTNB2qiJ02r7NHQWKJT9PrGkr0SjGmM8TdDBjvxLACW90NPZxnc QmVifHTebZ++uMDxcjz5SFjpjW168y8SCmm8xl4Xc1IN9GMPt1jSMMdgn3Lel73Y9Uha 2PxtQzpW34qzJj9wbM8/1XDEe1bU6dSSk91/OCrEG6uFkny38pU8oN1wWZxOK2laMpec hC/B+MBG0+wHaF0dMbhL/iVyA2LO8lOuV7wpSNZy2KUQziE0+DPjXDFlZ9aIbzJDEgOO ldBp3E5H0M2/f8fB2/iKLlwdCeZ2pBfnJmOMH4WrRnX8NGt1l2lw26yzyQf/NSsAZYun mLKg== X-Gm-Message-State: AElRT7EpsXNe/ImJz54kIcxw4QruyA3/MP3ALjo7viyq/rKB8i1xZLQi OtcWfMcdVz1wMhgIjYFeDGt5eGp8cZOdPaVDNVI= X-Google-Smtp-Source: AG47ELuDNJfLUxPauLkfk/9aU++4IZDUOz4kCGLb3yLpPf1/ykmUr4wB+BDO3RWRxzCGZ3/ldjQWEM4T1j1+Ovg1ojY= X-Received: by 10.25.149.2 with SMTP id x2mr11966899lfd.119.1520305384711; Mon, 05 Mar 2018 19:03:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.209.10 with HTTP; Mon, 5 Mar 2018 19:02:44 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> From: Jen Linkova Date: Tue, 6 Mar 2018 14:02:44 +1100 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: Gert Doering , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 03:03:10 -0000 On Sat, Mar 3, 2018 at 9:29 AM, Mudric, Dusan (Dusan) wrote: > " hosts to select the correct source address based >> on the desired egress ISP for that traffic." > will not work in the load sharing example. Unlike the router, when the host has two prefixes it does not know which one is 'desired'. It's not 'desired', it's 'can be used' (== 'communication is possible'). In the load sharing scenario both uplinks can be used so hosts are free to select addresses in all prefixes. Please note that we are not trying to make hosts *full* aware of all paths properties, traffic engineering is not in scope. All we are doing is signalling to hosts which addresses would provide network connectivity (if the ISP uplink is down, there is no network connectivity for source addresses in that prefix). If a hosts has received a signal that there is more than one prefix is available (== network is capable of sending packets with that source address out), then the host is using RFC6724 to select the addess. >Possible option is to assign a prefix preference in RA. Kind of a combination of Rule 5.5 and router preference? Both of them are not widely implemented, that's the whole point of the draft. > "Actually the new text is completely missing the point. Selecting the right source address *to select the egress ISP to use* is > the part not addressed in host stacks at all yet" > If so, the draft needs to make it clear. The introduction says: "However using IPv6 PA blocks in multihoming scenario introduces some challenges, including but not limited to: o Selecting the correct uplink based on the packet source address; o Signaling to hosts that some source addresses should or should not be used (e.g. an uplink to the ISP went down or became available again). " >The underlined assumption is that the host selected the right source address and the router uses that address to send a packet to a right ISP. It's the first bullet point, but the second one addresses your concern, I believe. > > >> -----Original Message----- >> From: Gert Doering [mailto:gert@space.net] >> Sent: Friday, March 02, 2018 1:57 PM >> To: Mudric, Dusan (Dusan) >> Cc: Jen Linkova; v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt >> >> Hi, >> >> On Fri, Mar 02, 2018 at 04:21:32PM +0000, Mudric, Dusan (Dusan) wrote: >> > In Abstract: >> > >> > "The problem of enterprise multihoming without address >> > translation of any form has not been solved yet as it requires both >> > the network to select the correct egress ISP based on the packet >> > source address and hosts to select the correct source address based >> > on the desired egress ISP for that traffic." >> > >> > Should be: >> > "The problem of enterprise multihoming without address >> > translation of any form has not been solved yet as it requires >> > the hosts to select the correct source address based >> > on a destination address for that traffic, >> > the hosts to select a first hop router based on the packet >> > source address, and the network to select the correct egress ISP based on >> the packet >> > source address" >> >> Actually the new text is completely missing the point. Source address >> selection *for a destination address* is something already addressed >> nicely (RFC6724). >> >> Selecting the right source address *to select the egress ISP to use* is >> the part not addressed in host stacks at all yet. >> >> The network part "select egress based on proper source address" is halfway >> solved with the homenet protocol suite (source address dependent babel, >> hncp, etc.) - but that is stuff not usually found on Enterprise routers. >> >> 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 -- SY, Jen Linkova aka Furry From nobody Tue Mar 6 02:25:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63A5126FDC for ; Tue, 6 Mar 2018 02:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfXpNL9iD0In for ; Tue, 6 Mar 2018 02:25:26 -0800 (PST) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 EF025126CF6 for ; Tue, 6 Mar 2018 02:25:24 -0800 (PST) X-AuditID: d9a9790a-6abff70000008093-b7-5a9e6c92998f Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id 18.0B.32915.29C6E9A5; Tue, 6 Mar 2018 11:25:22 +0100 (CET) From: Fioccola Giuseppe To: Bob Hinden , Tom Herbert , "Brian E Carpenter (brian.e.carpenter@gmail.com)" CC: "v6ops@ietf.org WG" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt Thread-Index: AQHTrwdzxFtAa/T71keSxFrfEUiteqO2vQsAgABjl4CAABJBgIAArkOAgAKXhgCAASX6EP//99yAgABrbwCABwfyAA== Date: Tue, 6 Mar 2018 10:25:22 +0000 Message-ID: <92e346ead86942d59e5dec2384eb6f86@TELMBXB02RM001.telecomitalia.local> References: <151965246238.31386.1515320046883185252.idtracker@ietfa.amsl.com> <2549744f-4d30-76f2-e48e-72c79f15016a@gmail.com> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.232] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXCxfdHSndSzrwog1P3zS22vt/HZtF2cR+T xdvFPxgtLl96xGxx+theZgdWj52z7rJ79M6dxuqxZMlPJo+7ty4xBbBENTDaJObl5ZcklqQq pKQWJ9squWQWJ+ckZuamFimEpOakJufnKilkptgqGSspFOQkJqfmpuaV2ColFhSk5qUo2XEp YAAboLLMPIXUvOT8lMy8dFslz2B/XQsLU0tdQyW7wNLU4pJ8hdzU4uLE9PTMfIXUhPWCGS9f z2YpeMBVcbftH1sD42WOLkZODgkBE4n/65awdzFycQgJTGGSuH7uADNIgk3ARuLgqxNsIAkR gbmMEqtnzgNLMAuUS/ze0csCYgsLJEhc2DsNLC4ikCSxcP0GVgg7S2LO4o9gNSwCKhL/F/8D s3kFAiXuvWxlgtj2j0Xi04NT7CAJTgFbiS2vt4A1MwrISkzYvYgRYpm4xIvpJ9ghThWQWLLn PDOELSrx8vE/VgjbQGLr0n0sELaixJIT+9kgbBmJhUcms0LM0ZO4MXUKG4StLbFs4WtmiIME JU7OfMIygVFsFpJ1s5C0zELSMgtJywJGllWMorkVBoZ6JZAYzCxJzMlM1Mss2cQITDI3V1Zy 7WB8vcr5EKMAB6MSD29E6rwoIdbEsuLK3EOMEhzMSiK8EfpAId6UxMqq1KL8+KLSnNTiQ4w+ wCCbyCwlmpwPTIB5JfGGJhaWhsYWFkaGFmamOISVxHnDY4FmCaQDk1h2ampBahHMOCYOTqkG xgkzbuXKsPuWzi//yZmo9PZBa1K5F598duSy4CnLea06jd/MebOy4Ms5lVNvmD+a7Q5S5P5R zlB/ZsPiC/2r+QX1bZgKu0X/zZ9/SLzAv3n1zgX503UKH0x51bfE6so/AcNZ9tJ79283WiDn Edd28vvdrZcO7A3c8EcnyWa+7B+etRtuG7cWWyixFGckGmoxFxUnAgBzSg7QXwMAAA== Archived-At: Subject: [v6ops] R: FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 10:25:29 -0000 Thank you for the suggestions, I keep notes of these comments and will wait for further comments in London. A new revision could be published after the IETF meeting. Best Regards, Giuseppe -----Messaggio originale----- Da: Bob Hinden [mailto:bob.hinden@gmail.com] Inviato: venerd=EC 2 marzo 2018 00:53 A: Tom Herbert Cc: Bob Hinden; Fioccola Giuseppe; v6ops@ietf.org WG; Van De Velde, Gunter (= Nokia - BE/Antwerp) Oggetto: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-i= pv6-alt-mark-00.txt >> > > Okay, then I think you may want to add a couple of alternatives to the dra= ft: > > 1) Adding a field to an existing proposed EH (e.g. SRv6) instead of > defining a new EH. > 2) Using a field from an extensible encapsulation, such as GUE, to > carry the passive measurement bits. This technique was discussed at > length in nvo3. > > The intended status should also be informational I would think. Or Experimental, given that RFC 8321 that this appears to be based on is Exp= erimental. Also, this should only reference RFC8200, not RFC8200 and RFC2460. The latt= er was obsoleted by RFC8200. Thanks, Bob > > Thanks, > Tom > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Tue Mar 6 06:54:45 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E9B127076 for ; Tue, 6 Mar 2018 06:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAaOjXvIO2Q8 for ; Tue, 6 Mar 2018 06:54:41 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 99990124235 for ; Tue, 6 Mar 2018 06:54:41 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HFAAB3qp5a/wUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ8VIFWKAqDSookjXmCAoEWhyONERSCAQqFMAIagmkhNBgBAgE?= =?us-ascii?q?BAQEBAQIDaCeFJAEBAQEDEhERRQwEAgEIDQEDBAEBAQICBh0DAgICHxEUAQgIA?= =?us-ascii?q?gQOBQgTB4RhAxUBnUiKcIInIQKHBw2BMIImgQ+EH4IugViFEoJqgXsVDxoVgnQ?= =?us-ascii?q?wgjIEmjYxCQKNQAGFI4Q1gw+FTYo2hyCBLh45gVJwFYJ9hEh3iV2BMQGBFwEBA?= =?us-ascii?q?Q?= X-IPAS-Result: =?us-ascii?q?A2HFAAB3qp5a/wUHmMZdGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?8VIFWKAqDSookjXmCAoEWhyONERSCAQqFMAIagmkhNBgBAgEBAQEBAQIDaCeFJ?= =?us-ascii?q?AEBAQEDEhERRQwEAgEIDQEDBAEBAQICBh0DAgICHxEUAQgIAgQOBQgTB4RhAxU?= =?us-ascii?q?BnUiKcIInIQKHBw2BMIImgQ+EH4IugViFEoJqgXsVDxoVgnQwgjIEmjYxCQKNQ?= =?us-ascii?q?AGFI4Q1gw+FTYo2hyCBLh45gVJwFYJ9hEh3iV2BMQGBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,431,1515474000"; d="scan'208";a="278447281" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Mar 2018 09:54:38 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2018 09:54:38 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0352.000; Tue, 6 Mar 2018 09:54:37 -0500 From: "Mudric, Dusan (Dusan)" To: Jen Linkova CC: Gert Doering , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt Thread-Index: AQHTtPeYUkzxmpjEuEKRkMb0PC5AE6PDRcgQ Date: Tue, 6 Mar 2018 14:54:36 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.130.24 dlp-reaction: no-action x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 14:54:44 -0000 SGkgSmVuLA0KDQpQbGVhc2Ugc2VlIGlubGluZWQuIA0KDQpSZWdhcmRzLA0KRHVzYW4uDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmVuIExpbmtvdmEgW21haWx0bzpm dXJyeTEzQGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBNYXJjaCAwNSwgMjAxOCAxMDowMyBQ TQ0KPiBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pDQo+IENjOiBHZXJ0IERvZXJpbmc7IHY2b3Bz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt djZvcHMtY29uZGl0aW9uYWwtcmFzLTAxLnR4dA0KPiANCj4gT24gU2F0LCBNYXIgMywgMjAxOCBh dCA5OjI5IEFNLCBNdWRyaWMsIER1c2FuIChEdXNhbikNCj4gPGRtdWRyaWNAYXZheWEuY29tPiB3 cm90ZToNCj4gPiAiIGhvc3RzIHRvIHNlbGVjdCB0aGUgY29ycmVjdCBzb3VyY2UgYWRkcmVzcyBi YXNlZA0KPiA+PiAgICBvbiB0aGUgZGVzaXJlZCBlZ3Jlc3MgSVNQIGZvciB0aGF0IHRyYWZmaWMu Ig0KPiA+IHdpbGwgbm90IHdvcmsgaW4gdGhlIGxvYWQgc2hhcmluZyBleGFtcGxlLiBVbmxpa2Ug dGhlIHJvdXRlciwgd2hlbiB0aGUgaG9zdA0KPiBoYXMgdHdvIHByZWZpeGVzIGl0IGRvZXMgbm90 IGtub3cgd2hpY2ggb25lIGlzICdkZXNpcmVkJy4NCj4gDQo+IEl0J3Mgbm90ICdkZXNpcmVkJywg aXQncyAnY2FuIGJlIHVzZWQnICg9PSAnY29tbXVuaWNhdGlvbiBpcw0KPiBwb3NzaWJsZScpLiBJ biB0aGUgbG9hZCBzaGFyaW5nIHNjZW5hcmlvIGJvdGggdXBsaW5rcyBjYW4gYmUgdXNlZCBzbw0K PiBob3N0cyBhcmUgZnJlZSB0byBzZWxlY3QgYWRkcmVzc2VzIGluIGFsbCBwcmVmaXhlcy4NCj4g DQo+IFBsZWFzZSBub3RlIHRoYXQgd2UgYXJlIG5vdCB0cnlpbmcgdG8gbWFrZSBob3N0cyAqZnVs bCogYXdhcmUgb2YgYWxsDQo+IHBhdGhzIHByb3BlcnRpZXMsIHRyYWZmaWMgZW5naW5lZXJpbmcg aXMgbm90IGluIHNjb3BlLiBBbGwgd2UgYXJlDQo+IGRvaW5nIGlzIHNpZ25hbGxpbmcgdG8gaG9z dHMgd2hpY2ggYWRkcmVzc2VzIHdvdWxkIHByb3ZpZGUgbmV0d29yaw0KPiBjb25uZWN0aXZpdHkg KGlmIHRoZSBJU1AgdXBsaW5rIGlzIGRvd24sIHRoZXJlIGlzIG5vIG5ldHdvcmsNCj4gY29ubmVj dGl2aXR5IGZvciBzb3VyY2UgYWRkcmVzc2VzIGluIHRoYXQgcHJlZml4KS4NCj4gSWYgYSBob3N0 cyBoYXMgcmVjZWl2ZWQgYSBzaWduYWwgdGhhdCB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIHByZWZp eCBpcw0KPiBhdmFpbGFibGUgKD09IG5ldHdvcmsgaXMgY2FwYWJsZSBvZiBzZW5kaW5nIHBhY2tl dHMgd2l0aCB0aGF0IHNvdXJjZQ0KPiBhZGRyZXNzIG91dCksIHRoZW4gdGhlIGhvc3QgaXMgdXNp bmcgUkZDNjcyNCB0byBzZWxlY3QgdGhlIGFkZGVzcy4NCg0KW1tEdXNhbl1dIA0KW1tEdXNhbl1d IFdoYXQgSSBhbSB0cnlpbmcgdG8gc2F5IGlzIFJGQzY3MjQgZG9lcyBub3Qga25vdyB3aGljaCBJ U1AgaXMgcHJlZmVycmVkLCB3aGVuIGJvdGggcHJlZml4ZXMgYXJlIGFkdmVydGlzZWQuIElmIGEg cm91dGVyIHdpbGwgaGF2ZSBhIG5ldyBwb2xpY3kgdG8ga25vdyB0aGUgSVNQIHByZWZlcmVuY2Us IHRoZSBwcmVmZXJlbmNlIHNob3VsZCBiZSBwYXNzZWQgdG8gdGhlIGhvc3QsIGFuZCBSRkM2NzI0 IHNob3VsZCBiZSBlbmhhbmNlZCB0byB1c2UgdGhhdCBwcmVmZXJlbmNlLiBUaGlzIHdpbGwgZmFj aWxpdGF0ZSBhIG5ldHdvcmsgbWFuYWdlbWVudCB3aGVyZSBvbmUgcm91dGVyIHBvbGljeSBpcyBj b25maWd1cmVkIGFuZCBhbGwgdGhlIGhvc3RzIGJlbmVmaXQgZnJvbSB0aGF0IGtub3dsZWRnZS4g V2hlbiBhbGwgdGhpcyBpcyBwdXQgdG9nZXRoZXIsIHdpdGggbXVsdGlwbGUgcHJlZml4ZXMsIGEg aG9zdCB3aWxsIHNlbGVjdCB0aGUgcHJlZmVycmVkIHNvdXJjZSBhZGRyZXNzIGFuZCBhIHJvdXRl ciB3aWxsIHVzZSBpdCB0byBmb3J3YXJkIHBhY2tldCB0byBwcmVmZXJyZWQgSVNQLiBJZiB0aGUg aG9zdCBwYXJ0IGlzIG5vdCBhZGRyZXNzZWQsIHRoZSBob3N0IHdpbGwgJ3JhbmRvbWx5JyAoY3Vy cmVudCBSRkM2NzI0IHdpbGwgbm90IHVzZSB0aGUgcHJlZml4IHByZWZlcmVuY2UpIHNlbGVjdCB0 aGUgc291cmNlIGFkZHJlc3MgYW5kIHBhY2tldHMgbWlnaHQgZ28gdG8gZWl0aGVyIElTUDEgb3Ig SVNQMi4NCg0KDQo+IA0KPiA+UG9zc2libGUgb3B0aW9uIGlzIHRvIGFzc2lnbiBhIHByZWZpeCBw cmVmZXJlbmNlIGluIFJBLg0KPiANCj4gS2luZCBvZiBhIGNvbWJpbmF0aW9uIG9mIFJ1bGUgNS41 IGFuZCByb3V0ZXIgcHJlZmVyZW5jZT8gQm90aCBvZiB0aGVtDQo+IGFyZSBub3Qgd2lkZWx5IGlt cGxlbWVudGVkLCB0aGF0J3MgdGhlIHdob2xlIHBvaW50IG9mIHRoZSBkcmFmdC4NCg0KW1tEdXNh bl1dIA0KW1tEdXNhbl1dIEV4YWN0bHkuIFNpbmNlIGJvdGggcHJlZml4ZXMgYXJlIGFzc2lnbmVk IGJ5IHR3byBuZXh0IGhvcHMsIFJ1bGUgNS41IHNob3VsZCBiZSBlbmhhbmNlZCB0byB1c2UgdGhl IHByZWZlcnJlZCBwcmVmaXguIFN0YW5kYXJkcyBzaG91bGQgbm90IGFkZHJlc3MgdGhlIGN1cnJl bnQgZGVwbG95bWVudCBzdGF0ZSwgYnV0IHByb3ZpZGUgYSBiZXR0ZXIgc29sdXRpb24uIEkgd291 bGQgbm90IGZvY3VzIG9uIHdoYXQgaXMgbm90IGN1cnJlbnRseSBpbXBsZW1lbnRlZCBidXQgcmF0 aGVyIG9uIHdoYXQgc2hvdWxkIGJlIGltcGxlbWVudGVkLiANCg0KPiANCj4gPiAiQWN0dWFsbHkg dGhlIG5ldyB0ZXh0IGlzIGNvbXBsZXRlbHkgbWlzc2luZyB0aGUgcG9pbnQuIFNlbGVjdGluZyB0 aGUgcmlnaHQNCj4gc291cmNlIGFkZHJlc3MgKnRvIHNlbGVjdCB0aGUgZWdyZXNzIElTUCB0byB1 c2UqIGlzDQo+ID4gdGhlIHBhcnQgbm90IGFkZHJlc3NlZCBpbiBob3N0IHN0YWNrcyBhdCBhbGwg eWV0Ig0KPiA+IElmIHNvLCB0aGUgZHJhZnQgbmVlZHMgdG8gbWFrZSBpdCBjbGVhci4NCj4gDQo+ IFRoZSBpbnRyb2R1Y3Rpb24gc2F5czoNCj4gIkhvd2V2ZXIgdXNpbmcgSVB2NiBQQSBibG9ja3MN Cj4gICAgaW4gbXVsdGlob21pbmcgc2NlbmFyaW8gaW50cm9kdWNlcyBzb21lIGNoYWxsZW5nZXMs IGluY2x1ZGluZyBidXQgbm90DQo+ICAgIGxpbWl0ZWQgdG86DQo+IA0KPiAgICBvICBTZWxlY3Rp bmcgdGhlIGNvcnJlY3QgdXBsaW5rIGJhc2VkIG9uIHRoZSBwYWNrZXQgc291cmNlIGFkZHJlc3M7 DQo+IA0KPiAgICBvICBTaWduYWxpbmcgdG8gaG9zdHMgdGhhdCBzb21lIHNvdXJjZSBhZGRyZXNz ZXMgc2hvdWxkIG9yIHNob3VsZCBub3QNCj4gICAgICAgYmUgdXNlZCAoZS5nLiBhbiB1cGxpbmsg dG8gdGhlIElTUCB3ZW50IGRvd24gb3IgYmVjYW1lIGF2YWlsYWJsZQ0KPiAgICAgICBhZ2Fpbiku DQo+ICINCg0KW1tEdXNhbl1dIA0KW1tEdXNhbl1dIFRoZXNlIHR3byBjYXNlcyBhcmUgdmFsaWQg YnV0IHRoZXkgZG9uJ3QgY292ZXIgIi5TZWxlY3RpbmcgdGhlIHJpZ2h0IHNvdXJjZSBhZGRyZXNz ICp0byBzZWxlY3QgdGhlIGVncmVzcyBJU1AgdG8gdXNlKiIuIFRoaXMgd291bGQgYmUgYSB0aGly ZCBwcm9ibGVtIHRvIGFkZHJlc3MuIFRoaXMgY29tZXMgYmVmb3JlIHRoZSBmaXJzdCBidWxsZXQg KHRoZSBzb3VyY2UgYWRkcmVzcyBuZWVkcyB0byBiZSBjaG9zZW4gZmlyc3QsIHRoZW4gdGhlIGNv cnJlY3QgdXBsaW5rKS4gVGhlIHNlY29uZCBidWxsZXQgdGFsa3MgYWJvdXQgdGhlIGNvbm5lY3Rp dml0eSBpc3N1ZXMsIHdoZXJlIGEgcHJlZml4IGlzIHJlbW92ZWQgd2hlbiBhIGxpbmsgaXMgZG93 bi4gV2UgbmVlZCB0byBtZW50aW9uIHRoZSBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rpb24gd2hlbiBi b3RoIGxpbmtzIGFyZSB1cC4NCg0KPiANCj4gPlRoZSB1bmRlcmxpbmVkIGFzc3VtcHRpb24gaXMg dGhhdCB0aGUgaG9zdCBzZWxlY3RlZCB0aGUgcmlnaHQgc291cmNlIGFkZHJlc3MNCj4gYW5kIHRo ZSByb3V0ZXIgdXNlcyB0aGF0IGFkZHJlc3MgdG8gc2VuZCBhIHBhY2tldCB0byBhIHJpZ2h0IElT UC4NCj4gDQo+IEl0J3MgdGhlIGZpcnN0IGJ1bGxldCBwb2ludCwgYnV0IHRoZSBzZWNvbmQgb25l IGFkZHJlc3NlcyB5b3VyDQo+IGNvbmNlcm4sIEkgYmVsaWV2ZS4NCj4gDQoNCltbRHVzYW5dXSBU byBzb21lIGV4dGVudC4gSXQgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLiBBbmQgdGhlIGRyYWZ0IHNo b3VsZCBzdGF0ZSBpZiwgaG93IGFuZCB3aGVyZSAiU2VsZWN0aW5nIHRoZSByaWdodCBzb3VyY2Ug YWRkcmVzcyAqdG8gc2VsZWN0IHRoZSBlZ3Jlc3MgSVNQIHRvIHVzZSoiIGlzIGRvbmUuDQoNCg0K DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBH ZXJ0IERvZXJpbmcgW21haWx0bzpnZXJ0QHNwYWNlLm5ldF0NCj4gPj4gU2VudDogRnJpZGF5LCBN YXJjaCAwMiwgMjAxOCAxOjU3IFBNDQo+ID4+IFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCj4g Pj4gQ2M6IEplbiBMaW5rb3ZhOyB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWNvbmRpdGlvbmFsLXJhcy0wMS50eHQN Cj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IE9uIEZyaSwgTWFyIDAyLCAyMDE4IGF0IDA0OjIx OjMyUE0gKzAwMDAsIE11ZHJpYywgRHVzYW4gKER1c2FuKSB3cm90ZToNCj4gPj4gPiBJbiBBYnN0 cmFjdDoNCj4gPj4gPg0KPiA+PiA+ICJUaGUgcHJvYmxlbSBvZiBlbnRlcnByaXNlIG11bHRpaG9t aW5nIHdpdGhvdXQgYWRkcmVzcw0KPiA+PiA+ICAgIHRyYW5zbGF0aW9uIG9mIGFueSBmb3JtIGhh cyBub3QgYmVlbiBzb2x2ZWQgeWV0IGFzIGl0IHJlcXVpcmVzIGJvdGgNCj4gPj4gPiAgICB0aGUg bmV0d29yayB0byBzZWxlY3QgdGhlIGNvcnJlY3QgZWdyZXNzIElTUCBiYXNlZCBvbiB0aGUgcGFj a2V0DQo+ID4+ID4gICAgc291cmNlIGFkZHJlc3MgYW5kIGhvc3RzIHRvIHNlbGVjdCB0aGUgY29y cmVjdCBzb3VyY2UgYWRkcmVzcyBiYXNlZA0KPiA+PiA+ICAgIG9uIHRoZSBkZXNpcmVkIGVncmVz cyBJU1AgZm9yIHRoYXQgdHJhZmZpYy4iDQo+ID4+ID4NCj4gPj4gPiBTaG91bGQgYmU6DQo+ID4+ ID4gIlRoZSBwcm9ibGVtIG9mIGVudGVycHJpc2UgbXVsdGlob21pbmcgd2l0aG91dCBhZGRyZXNz DQo+ID4+ID4gICAgdHJhbnNsYXRpb24gb2YgYW55IGZvcm0gaGFzIG5vdCBiZWVuIHNvbHZlZCB5 ZXQgYXMgaXQgcmVxdWlyZXMNCj4gPj4gPiAgICB0aGUgaG9zdHMgdG8gc2VsZWN0IHRoZSBjb3Jy ZWN0IHNvdXJjZSBhZGRyZXNzIGJhc2VkDQo+ID4+ID4gICAgb24gYSBkZXN0aW5hdGlvbiBhZGRy ZXNzIGZvciB0aGF0IHRyYWZmaWMsDQo+ID4+ID4gICAgdGhlIGhvc3RzIHRvIHNlbGVjdCBhIGZp cnN0IGhvcCByb3V0ZXIgYmFzZWQgb24gdGhlIHBhY2tldA0KPiA+PiA+ICAgIHNvdXJjZSBhZGRy ZXNzLCBhbmQgdGhlIG5ldHdvcmsgdG8gc2VsZWN0IHRoZSBjb3JyZWN0IGVncmVzcyBJU1AgYmFz ZWQgb24NCj4gPj4gdGhlIHBhY2tldA0KPiA+PiA+ICAgIHNvdXJjZSBhZGRyZXNzIg0KPiA+Pg0K PiA+PiBBY3R1YWxseSB0aGUgbmV3IHRleHQgaXMgY29tcGxldGVseSBtaXNzaW5nIHRoZSBwb2lu dC4gIFNvdXJjZSBhZGRyZXNzDQo+ID4+IHNlbGVjdGlvbiAqZm9yIGEgZGVzdGluYXRpb24gYWRk cmVzcyogaXMgc29tZXRoaW5nIGFscmVhZHkgYWRkcmVzc2VkDQo+ID4+IG5pY2VseSAoUkZDNjcy NCkuDQo+ID4+DQo+ID4+IFNlbGVjdGluZyB0aGUgcmlnaHQgc291cmNlIGFkZHJlc3MgKnRvIHNl bGVjdCB0aGUgZWdyZXNzIElTUCB0byB1c2UqIGlzDQo+ID4+IHRoZSBwYXJ0IG5vdCBhZGRyZXNz ZWQgaW4gaG9zdCBzdGFja3MgYXQgYWxsIHlldC4NCj4gPj4NCj4gPj4gVGhlIG5ldHdvcmsgcGFy dCAic2VsZWN0IGVncmVzcyBiYXNlZCBvbiBwcm9wZXIgc291cmNlIGFkZHJlc3MiIGlzIGhhbGZ3 YXkNCj4gPj4gc29sdmVkIHdpdGggdGhlIGhvbWVuZXQgcHJvdG9jb2wgc3VpdGUgKHNvdXJjZSBh ZGRyZXNzIGRlcGVuZGVudCBiYWJlbCwNCj4gPj4gaG5jcCwgZXRjLikgLSBidXQgdGhhdCBpcyBz dHVmZiBub3QgdXN1YWxseSBmb3VuZCBvbiBFbnRlcnByaXNlIHJvdXRlcnMuDQo+ID4+DQo+ID4+ IEdlcnQgRG9lcmluZw0KPiA+PiAgICAgICAgIC0tIE5ldE1hc3Rlcg0KPiA+PiAtLQ0KPiA+PiBo YXZlIHlvdSBlbmFibGVkIElQdjYgb24gc29tZXRoaW5nIHRvZGF5Li4uPw0KPiA+Pg0KPiA+PiBT cGFjZU5ldCBBRyAgICAgICAgICAgICAgICAgICAgICAgIFZvcnN0YW5kOiBTZWJhc3RpYW4gdi4g Qm9taGFyZA0KPiA+PiBKb3NlcGgtRG9sbGluZ2VyLUJvZ2VuIDE0ICAgICAgICAgIEF1ZnNpY2h0 c3JhdHN2b3JzLjogQS4gR3J1bmRuZXItQ3VsZW1hbm4NCj4gPj4gRC04MDgwNyBNdWVuY2hlbiAg ICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAoQUcgTXVlbmNoZW4pDQo+ID4+IFRlbDogKzQ5 ICgwKTg5LzMyMzU2LTQ0NCAgICAgICAgICAgVVN0LUlkTnIuOiBERTgxMzE4NTI3OQ0KPiANCj4g DQo+IA0KPiAtLQ0KPiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo= From nobody Tue Mar 6 14:58:51 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A986126D05 for ; Tue, 6 Mar 2018 14:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDXgvUFyQZOq for ; Tue, 6 Mar 2018 14:58:48 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 B20CD1200FC for ; Tue, 6 Mar 2018 14:58:47 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id i80-v6so435835lfg.5 for ; Tue, 06 Mar 2018 14:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Smfyq9wGfoPUWH/S3eLNMJtZKGb3+6AqbPw4jNI8iUk=; b=GU84gBylorR1RbzH1bNhW/NGmRgUcq/Q1HOO/hrvTjaJdNk+WSyiHMqT3ZArzNVjZ4 aHLUuNPtwUXXj6AskImpL0oFt5hd2VVJbGnAcAf2Xs4Lbpy9YuhYUhXMtcaIQE4/Cw5G /YK6Ibhpy4WiX/tjdpw1dNpwlYgcp6Ru4yT0NJK1y/1pOB4pD98ExsqSTYoRFhqUMEOA 29MIXW4QszpASTr0Uu0UtUxdszO2nnDslI3MOVKa8Ga79RRrVVvtbdwO9fR3HDJF2z3o GAx0kkpaVAvnB7Je1YDFLnTxz4TzvrZWPEaxbjl6p8gC/c3RixeaqipjjPMu8T1tecrb YpQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Smfyq9wGfoPUWH/S3eLNMJtZKGb3+6AqbPw4jNI8iUk=; b=dIjUmx+G00PdzumRuWsSIFWILH040DWV0efygHzEiGImlb0W+deyV7GxzOBHg02nrJ 0Wk/VNS1TwJ8sho48ITdbd9Uq8Q2ReXnhtigi4DZpm/22qMZA4In8H+F/voFTTyCdH3N pFUmxEkHetYERZRKeNbq03i0JSNjUf8vrQfRYJEHu2EVhoaynuqRxVWj5/7UuIMkwM91 6EtGKL93UMaHm62640dbr9+QBHrujWUOX9Vn3RkV4hTmtbUXgK96NYI3cuSzd0sL6DYK XAXRVk1/FBghXYfYMO5ZBTtEMRp2Ax5a8meCKLQ5lI3RWYVQfDyzofl9wWIKa2PV09t8 VhtA== X-Gm-Message-State: AElRT7GB621A+F2I9WqMNAE/rFocsRbL8/A30e+8KHNAC3TwsGt533Y5 Io8ASVZ4IRpMsf3gk332tzxtDAvd1aQOIji/Qc0= X-Google-Smtp-Source: AG47ELv/knOVk9gJ0KZOyT3PB8f6JspUvlPPjD6/+B2gbQ7dsurddC38pE3l3VmDL2U9KbAdGpU0/MP5pRnqZWHrBKY= X-Received: by 10.25.38.11 with SMTP id m11mr13633566lfm.22.1520377124399; Tue, 06 Mar 2018 14:58:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.209.10 with HTTP; Tue, 6 Mar 2018 14:58:23 -0800 (PST) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> From: Jen Linkova Date: Wed, 7 Mar 2018 09:58:23 +1100 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: Gert Doering , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 22:58:50 -0000 On Wed, Mar 7, 2018 at 1:54 AM, Mudric, Dusan (Dusan) w= rote: > [[Dusan]] What I am trying to say is RFC6724 does not know which ISP is p= referred, when both prefixes are advertised. Sorry, it looks like I did not explain it very well.. If/when both prefixes are advertised, both ISPs are "preferred" (in the same way IPv6 address can be in "preferred" state, which means 'it can be used for outgoing communications". Again, we are not solving traffic engineering issue, nor we are trying to make hosts be fully aware of various paths properties (shameless plug: please come to PANRG for that :)). ISP uplink is either "preferred" (hosts are allowed to use it, the network can send packets there, because the uplink is up and there is no explict policy which indicates that the uplink should not be used if other uplinks are available) or not preferred (it's down or there is a policy to prevent using this uplink ex. for backup). If an uplink is preferred - the corresponding prefix is advertised with non-zero preferred lifetime. It's perfectly fine to have multiple preferred uplinks/ISPs. Hosts can use addresses from any of them. >If a router will have a new policy to know the ISP preference, the prefere= nce should be passed to the host, It's binary state. ISP is either "usable" (preferred lifetime > 0) or not (preferred lifetime =3D=3D 0). It's how the preference is passed to the host. >and RFC6724 should be enhanced to use that preference. No changes in RFC6724 are needed. Hosts with Rule 5.5 and default support will do it anyway (if R1 has is a preferred default router, then the host selects a source address from prefixes received from R1). >This will facilitate a network management where one router policy is confi= gured and all the hosts benefit from that knowledge. When all this is put t= ogether, with multiple prefixes, a host will select the preferred source ad= dress and a router will use it to forward packet to preferred ISP. If the h= ost part is not addressed, the host will 'randomly' (current RFC6724 will n= ot use the prefix preference) select the source address and packets might g= o to either ISP1 or ISP2. If ISP2 should not be used and ISP1 should be preferred (is it the scenario you are talking about??) then ISP2 prefix should be advertised to hosts with preferred_lifetime 0. Then hosts will not select addresses from ISP 2 prefix but use ISP1 prefix instead and routers will forward packet to preferred ISP1. Why do we need "prefix preference" for this? >> >Possible option is to assign a prefix preference in RA. >> >> Kind of a combination of Rule 5.5 and router preference? Both of them >> are not widely implemented, that's the whole point of the draft. > > [[Dusan]] > [[Dusan]] Exactly. Since both prefixes are assigned by two next hops, Rul= e 5.5 should be enhanced to use the preferred prefix. Standards should not = address the current deployment state, but provide a better solution. I woul= d not focus on what is not currently implemented but rather on what should = be implemented. Have I sent this email to 6man@ by mistake? Ah, does not look like that :) And I seem to set the document status to 'Informational'. This draft documents a solution which works right here, right now, the solution I can deploy today in my network. Better (more general, covering more use cases, relying on Rule 5.5) approach to the problem is documented in https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-03 but it can not be used in networks with hosts which do not support 5.5. Also there is mPVD work etc. >> The introduction says: >> "However using IPv6 PA blocks >> in multihoming scenario introduces some challenges, including but not >> limited to: >> >> o Selecting the correct uplink based on the packet source address; >> >> o Signaling to hosts that some source addresses should or should not >> be used (e.g. an uplink to the ISP went down or became available >> again). >> " > [[Dusan]] > [[Dusan]] These two cases are valid but they don't cover ".Selecting the = right source address *to select the egress ISP to use*". This would be a th= ird problem to address. This comes before the first bullet (the source addr= ess needs to be chosen first, then the correct uplink). The second bullet t= alks about the connectivity issues, where a prefix is removed when a link i= s down. We need to mention the source address selection when both links are= up. If the both uplinks are up and can be used (so load sharing scenario) then hosts can use either uplink. ISP1 or ISP2. Why is it a problem? If one uplink (let;s say ISP2) should not be preferred (low bandwidth/higher price etc) then it's a 'primary/backup' scenario and hosts are selecting ISP1 prefix as it's the only prefix with non-zero preferred lifetime. >> > >> > >> >> -----Original Message----- >> >> From: Gert Doering [mailto:gert@space.net] >> >> Sent: Friday, March 02, 2018 1:57 PM >> >> To: Mudric, Dusan (Dusan) >> >> Cc: Jen Linkova; v6ops@ietf.org >> >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.= txt >> >> >> >> Hi, >> >> >> >> On Fri, Mar 02, 2018 at 04:21:32PM +0000, Mudric, Dusan (Dusan) wrote= : >> >> > In Abstract: >> >> > >> >> > "The problem of enterprise multihoming without address >> >> > translation of any form has not been solved yet as it requires b= oth >> >> > the network to select the correct egress ISP based on the packet >> >> > source address and hosts to select the correct source address ba= sed >> >> > on the desired egress ISP for that traffic." >> >> > >> >> > Should be: >> >> > "The problem of enterprise multihoming without address >> >> > translation of any form has not been solved yet as it requires >> >> > the hosts to select the correct source address based >> >> > on a destination address for that traffic, >> >> > the hosts to select a first hop router based on the packet >> >> > source address, and the network to select the correct egress ISP= based on >> >> the packet >> >> > source address" >> >> >> >> Actually the new text is completely missing the point. Source addres= s >> >> selection *for a destination address* is something already addressed >> >> nicely (RFC6724). >> >> >> >> Selecting the right source address *to select the egress ISP to use* = is >> >> the part not addressed in host stacks at all yet. >> >> >> >> The network part "select egress based on proper source address" is ha= lfway >> >> solved with the homenet protocol suite (source address dependent babe= l, >> >> hncp, etc.) - but that is stuff not usually found on Enterprise route= rs. >> >> >> >> Gert Doering >> >> -- NetMaster >> >> -- >> >> have you enabled IPv6 on something today...? >> >> >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cu= lemann >> >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> >> >> >> -- >> SY, Jen Linkova aka Furry --=20 SY, Jen Linkova aka Furry From nobody Tue Mar 6 23:33:26 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C38124BE8 for ; Tue, 6 Mar 2018 23:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMEb7gCZXoU7 for ; Tue, 6 Mar 2018 23:33:22 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 6CF03124C27 for ; Tue, 6 Mar 2018 23:33:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 09400B0; Wed, 7 Mar 2018 08:33:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1520407998; bh=PRRbhUgswAKn/25Q/gTDD+XySmV5DsZdJE7sYHNwCbU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=k9K+A2ggq4gO5vmgpoAYTQH8x9X6V4/cS97itQUYlqNlc7JjFm+Y+rivojA0plxgp eTBTMqnTGxzDxwMXaLf9iJk/MqzcK2l5hHXT2xUNwT5Dqr9UvSFubPy8n/XG7IhP4O bR0Ru1CV893mhFZ4hjuiG6g47MKYVGY75YZt+Y1M= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0361EAF; Wed, 7 Mar 2018 08:33:18 +0100 (CET) Date: Wed, 7 Mar 2018 08:33:17 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: <976066da-49d0-0fc7-2b19-4196398c837d@gmail.com> Message-ID: References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> <976066da-49d0-0fc7-2b19-4196398c837d@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII; FORMAT=flowed Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2018 07:33:24 -0000 On Mon, 5 Mar 2018, Alexandre Petrescu wrote: > Well, if 5G IPv6 is a hell for spooks and cops then 4G IPv4 was a hell > too: nobody tracks people by IP addresses in cellular networks. The information about who had what address at what time is typically kept, so that an IP address can be tracked back to a subscription. In IPv6, this is done by prefix and not by address in a 3GPP network (since a /64 is used per PDP). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 8 02:45:12 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D93124C27 for ; Thu, 8 Mar 2018 02:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8BdK-lyq1KP for ; Thu, 8 Mar 2018 02:45:08 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 0A23C1205F0 for ; Thu, 8 Mar 2018 02:45:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w28Aj5Mx116134; Thu, 8 Mar 2018 11:45:05 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF77B204350; Thu, 8 Mar 2018 11:45:05 +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 A8DEB2042E5; Thu, 8 Mar 2018 11:45:05 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w28Aj5ta008250; Thu, 8 Mar 2018 11:45:05 +0100 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <1e03132f-9220-a55c-8d48-0216b6b5e306@gmail.com> <976066da-49d0-0fc7-2b19-4196398c837d@gmail.com> From: Alexandre Petrescu Message-ID: <5aae4fee-bd3a-4363-24cd-af95f2505082@gmail.com> Date: Thu, 8 Mar 2018 11:45:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] =?utf-8?q?IPv6_and_5G_will_make_life_hell_for_spooks_and?= =?utf-8?q?_cops_say_Australia=27s_spooks_and_cops_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 10:45:10 -0000 Le 07/03/2018 à 08:33, Mikael Abrahamsson a écrit : > On Mon, 5 Mar 2018, Alexandre Petrescu wrote: > >> Well, if 5G IPv6 is a hell for spooks and cops then 4G IPv4 was a >> hell too: nobody tracks people by IP addresses in cellular >> networks. > > The information about who had what address at what time is typically > kept, so that an IP address can be tracked back to a subscription. YEs that information is typically kept, but it's complex to use to track someone because it changes all the time at each handover or re-connection. > In IPv6, this is done by prefix and not by address in a 3GPP network > (since a /64 is used per PDP). YEs, I agree. YEt the certainty that IP prefix gives is fuzzy. (IP address privacy technology _is_ good but little relevant in mobile networks) Alex From nobody Thu Mar 8 08:40:23 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D926E127333 for ; Thu, 8 Mar 2018 08:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nkjwTFznRUH for ; Thu, 8 Mar 2018 08:40:18 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 7D6D01272E1 for ; Thu, 8 Mar 2018 08:40:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F5AAApZqFa/wUHmMZeGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ8IzFmbygKg0aKHo14ggKBFocdjQwUgT9CCiWFAAIagnAhNBg?= =?us-ascii?q?BAgEBAQEBAQIDaCeCazwDDCEHAi8BAQEBAQEBAQEBAQEBHAIPLxIBARgBAQEBA?= =?us-ascii?q?gESERFFBQcEAgEIDQEDBAEBAQICBh0DAgICHxEUAQgIAgQOBQgTB4RfAw0IAQ6?= =?us-ascii?q?gJIpvgiYhAocKDYEwghgFgQ6EJ4IugVeBZIIggQ6CakQBAQIBGIESCAkBCwEGA?= =?us-ascii?q?QcaFQ+CYzCCMgSIFIcVinUxCQKGR4ZnAYUahDSDB4VDiXk5hxWBLB45YXFwFYJ?= =?us-ascii?q?9gjEcgXt3AQGIcAEOGASBBgGBFgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2F5AAApZqFa/wUHmMZeGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?8IzFmbygKg0aKHo14ggKBFocdjQwUgT9CCiWFAAIagnAhNBgBAgEBAQEBAQIDa?= =?us-ascii?q?CeCazwDDCEHAi8BAQEBAQEBAQEBAQEBHAIPLxIBARgBAQEBAgESERFFBQcEAgE?= =?us-ascii?q?IDQEDBAEBAQICBh0DAgICHxEUAQgIAgQOBQgTB4RfAw0IAQ6gJIpvgiYhAocKD?= =?us-ascii?q?YEwghgFgQ6EJ4IugVeBZIIggQ6CakQBAQIBGIESCAkBCwEGAQcaFQ+CYzCCMgS?= =?us-ascii?q?IFIcVinUxCQKGR4ZnAYUahDSDB4VDiXk5hxWBLB45YXFwFYJ9gjEcgXt3AQGIc?= =?us-ascii?q?AEOGASBBgGBFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.47,441,1515474000"; d="scan'208";a="234964553" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 08 Mar 2018 11:40:13 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2018 11:40:13 -0500 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 11:40:11 -0500 From: "Mudric, Dusan (Dusan)" To: Jen Linkova CC: Gert Doering , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt Thread-Index: AQHTtZ6gUkzxmpjEuEKRkMb0PC5AE6PGcGtQ Date: Thu, 8 Mar 2018 16:40:10 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.150.1 dlp-reaction: no-action x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 16:40:21 -0000 SGkgSmVuLA0KDQpJIGJlbGlldmUgSSB1bmRlcnN0b29kIHRoZSBpbnRlbnQgb2YgdGhlIGRyYWZ0 LiBMZXQgbWUgZXhwbGFpbiBteSB1bmRlcnN0YW5kaW5nIG9mIHJ1bGUgNS41LiBQbGVhc2Ugc2Vl IGlubGluZWQuDQoNClRoYW5rcywNCkR1c2FuLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEplbiBMaW5rb3ZhIFttYWlsdG86ZnVycnkxM0BnbWFpbC5jb21dDQo+IFNl bnQ6IFR1ZXNkYXksIE1hcmNoIDA2LCAyMDE4IDU6NTggUE0NCj4gVG86IE11ZHJpYywgRHVzYW4g KER1c2FuKQ0KPiBDYzogR2VydCBEb2VyaW5nOyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLWNvbmRpdGlvbmFsLXJhcy0w MS50eHQNCj4gDQo+IE9uIFdlZCwgTWFyIDcsIDIwMTggYXQgMTo1NCBBTSwgTXVkcmljLCBEdXNh biAoRHVzYW4pDQo+IDxkbXVkcmljQGF2YXlhLmNvbT4gd3JvdGU6DQo+ID4gW1tEdXNhbl1dIFdo YXQgSSBhbSB0cnlpbmcgdG8gc2F5IGlzIFJGQzY3MjQgZG9lcyBub3Qga25vdyB3aGljaCBJU1Ag aXMNCj4gcHJlZmVycmVkLCB3aGVuIGJvdGggcHJlZml4ZXMgYXJlIGFkdmVydGlzZWQuDQo+IA0K PiBTb3JyeSwgaXQgbG9va3MgbGlrZSBJIGRpZCBub3QgZXhwbGFpbiBpdCB2ZXJ5IHdlbGwuLg0K PiANCj4gSWYvd2hlbiBib3RoIHByZWZpeGVzIGFyZSBhZHZlcnRpc2VkLCBib3RoIElTUHMgYXJl ICJwcmVmZXJyZWQiIChpbg0KPiB0aGUgc2FtZSB3YXkgSVB2NiBhZGRyZXNzIGNhbiBiZSBpbiAi cHJlZmVycmVkIiBzdGF0ZSwgd2hpY2ggbWVhbnMgJ2l0DQo+IGNhbiBiZSB1c2VkIGZvciBvdXRn b2luZyBjb21tdW5pY2F0aW9ucyIuDQo+IA0KPiBBZ2Fpbiwgd2UgYXJlIG5vdCBzb2x2aW5nIHRy YWZmaWMgZW5naW5lZXJpbmcgaXNzdWUsIG5vciB3ZSBhcmUgdHJ5aW5nDQo+IHRvIG1ha2UgaG9z dHMgYmUgZnVsbHkgYXdhcmUgb2YgdmFyaW91cyBwYXRocyBwcm9wZXJ0aWVzIChzaGFtZWxlc3MN Cj4gcGx1ZzogcGxlYXNlIGNvbWUgdG8gUEFOUkcgIGZvciB0aGF0IDopKS4NCj4gSVNQIHVwbGlu ayBpcyBlaXRoZXIgInByZWZlcnJlZCIgKGhvc3RzIGFyZSBhbGxvd2VkIHRvIHVzZSBpdCwgdGhl DQo+IG5ldHdvcmsgY2FuIHNlbmQgcGFja2V0cyB0aGVyZSwgYmVjYXVzZSB0aGUgdXBsaW5rIGlz IHVwIGFuZCB0aGVyZSBpcw0KPiBubyBleHBsaWN0IHBvbGljeSB3aGljaCBpbmRpY2F0ZXMgdGhh dCB0aGUgdXBsaW5rIHNob3VsZCBub3QgYmUgdXNlZA0KPiBpZiBvdGhlciB1cGxpbmtzIGFyZSBh dmFpbGFibGUpIG9yIG5vdCBwcmVmZXJyZWQgKGl0J3MgZG93biBvciB0aGVyZQ0KPiBpcyBhIHBv bGljeSB0byBwcmV2ZW50IHVzaW5nIHRoaXMgdXBsaW5rIGV4LiBmb3IgYmFja3VwKS4NCj4gDQo+ IElmIGFuIHVwbGluayBpcyBwcmVmZXJyZWQgLSB0aGUgY29ycmVzcG9uZGluZyBwcmVmaXggaXMg YWR2ZXJ0aXNlZA0KPiB3aXRoIG5vbi16ZXJvIHByZWZlcnJlZCBsaWZldGltZS4NCj4gSXQncyBw ZXJmZWN0bHkgZmluZSB0byBoYXZlIG11bHRpcGxlIHByZWZlcnJlZCB1cGxpbmtzL0lTUHMuIEhv c3RzIGNhbg0KPiB1c2UgYWRkcmVzc2VzIGZyb20gYW55IG9mIHRoZW0uDQo+IA0KPiA+SWYgYSBy b3V0ZXIgd2lsbCBoYXZlIGEgbmV3IHBvbGljeSB0byBrbm93IHRoZSBJU1AgcHJlZmVyZW5jZSwg dGhlIHByZWZlcmVuY2UNCj4gc2hvdWxkIGJlIHBhc3NlZCB0byB0aGUgaG9zdCwNCj4gDQo+IEl0 J3MgYmluYXJ5IHN0YXRlLiBJU1AgaXMgZWl0aGVyICJ1c2FibGUiIChwcmVmZXJyZWQgbGlmZXRp bWUgPiAwKSBvcg0KPiBub3QgKHByZWZlcnJlZCBsaWZldGltZSA9PSAwKS4gSXQncyBob3cgdGhl IHByZWZlcmVuY2UgaXMgcGFzc2VkIHRvDQo+IHRoZSBob3N0Lg0KPiANCj4gPmFuZCBSRkM2NzI0 IHNob3VsZCBiZSBlbmhhbmNlZCB0byB1c2UgdGhhdCBwcmVmZXJlbmNlLg0KPiANCj4gTm8gY2hh bmdlcyBpbiBSRkM2NzI0IGFyZSBuZWVkZWQuDQo+IEhvc3RzIHdpdGggUnVsZSA1LjUgYW5kIGRl ZmF1bHQgc3VwcG9ydCB3aWxsIGRvIGl0IGFueXdheSAoaWYgUjEgaGFzDQo+IGlzIGEgcHJlZmVy cmVkIGRlZmF1bHQgcm91dGVyLCAgdGhlbiB0aGUgaG9zdCBzZWxlY3RzIGEgc291cmNlIGFkZHJl c3MNCj4gZnJvbSBwcmVmaXhlcyByZWNlaXZlZCBmcm9tIFIxKS4NCj4gDQogW1tEdXNhbl1dIA0K W1tEdXNhbl1dIFRoZSByb3V0ZXIga25vd3MgbW9yZSB0aGFuIHRoYXQuIEZvciAndXNhYmxlJyBw cmVmaXhlcywgdGhlIHJvdXRlciBrbm93cyB3aGljaCBwcmVmaXggaXMgdGhlIG1vc3QgcHJlZmVy cmVkLiBUaGUgcm91dGVyIGNhbiBwYXNzIHRoYXQga25vd2xlZGdlIGluIFJBIFBJTyBvcHRpb24s IHVzaW5nICdyZXNlcnZlZCcgYml0cywgZm9yIGV4YW1wbGUgKGxpa2UgUHJmIGluIHJmYzQxOTEj c2VjdGlvbi0yLjIgKS4gV2l0aG91dCB0aGlzIGluZm9ybWF0aW9uLCBpZiB0aGVyZSBhcmUgdHdv IHByZWZpeGVzIChJU1AxLUQgYW5kIElTUDItRCkgaG93IHdpbGwgaG9zdCBrbm93IGlmIGl0IHNo b3VsZCB0YWxrIHRvIEQgb3ZlciBJU1AxIG9yIElTUDI/IFJ1bGUgNS41IGNhbm5vdCBkZXRlcm1p bmUgaXQ6DQoNCiAgIFJ1bGUgNS41OiBQcmVmZXIgYWRkcmVzc2VzIGluIGEgcHJlZml4IGFkdmVy dGlzZWQgYnkgdGhlIG5leHQtaG9wLg0KICAgSWYgU0Egb3IgU0EncyBwcmVmaXggaXMgYXNzaWdu ZWQgYnkgdGhlIHNlbGVjdGVkIG5leHQtaG9wIHRoYXQgd2lsbA0KICAgYmUgdXNlZCB0byBzZW5k IHRvIEQgYW5kIFNCIG9yIFNCJ3MgcHJlZml4IGlzIGFzc2lnbmVkIGJ5IGEgZGlmZmVyZW50DQog ICBuZXh0LWhvcCwgdGhlbiBwcmVmZXIgU0EuDQoNCllvdSBjYW4gY29uc2lkZXIgdGhlIHRyaWNr IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dnLWVudGVycHJp c2UtcGEtbXVsdGlob21pbmctMDMjc2VjdGlvbi00LjIuMiBieSBzZXR0aW5nIHR3byByb3V0ZXMg aW4gUkEgYW5kIHRoZSBQcmYgZnJvbSByZmM0MTkxI3NlY3Rpb24tMi4yLCBiYXNlZCBvbiB0aGUg cm91dGVyIHBvbGljeS4gVGhpcyB3b3VsZCBhbGxvdyBhIGhvc3QgdG8gc2VsZWN0IHRoZSBwcmVm ZXJyZWQgbmV4dCBob3AgYW5kIHVzZSB0aGUgcHJlZmVycmVkIG5leHQgaG9wIGluIFJ1bGUgNS41 LiBVc2luZyBQcmYgaW4gUklPIHRoZSByb3V0ZXIgcG9saWN5IGlzIGRpc3RyaWJ1dGVkIHRvIGFs bCBob3N0cyBhbmQgdGhleSBjYW4gc2VsZWN0IHRoZSBwcmVmZXJyZWQgSVNQLiBBIHJvdXRlciBT SE9VTEQgc2V0IFByZiBiYXNlZCBvbiB0aGUgSVNQIHNlbGVjdGlvbiBwb2xpY3kuIFRoZXJlIG1p Z2h0IGJlIHVzZSBjYXNlIHdoZW4gdGhlIG5ldHdvcmsgd291bGQgdXNlIG9ubHkgb25lIHJvdXRl IGFuZCBhZHZlcnRpc2Ugb25lIHByaWZpeC4NCg0KPiA+VGhpcyB3aWxsIGZhY2lsaXRhdGUgYSBu ZXR3b3JrIG1hbmFnZW1lbnQgd2hlcmUgb25lIHJvdXRlciBwb2xpY3kgaXMNCj4gY29uZmlndXJl ZCBhbmQgYWxsIHRoZSBob3N0cyBiZW5lZml0IGZyb20gdGhhdCBrbm93bGVkZ2UuIFdoZW4gYWxs IHRoaXMgaXMgcHV0DQo+IHRvZ2V0aGVyLCB3aXRoIG11bHRpcGxlIHByZWZpeGVzLCBhIGhvc3Qg d2lsbCBzZWxlY3QgdGhlIHByZWZlcnJlZCBzb3VyY2UgYWRkcmVzcw0KPiBhbmQgYSByb3V0ZXIg d2lsbCB1c2UgaXQgdG8gZm9yd2FyZCBwYWNrZXQgdG8gcHJlZmVycmVkIElTUC4gSWYgdGhlIGhv c3QgcGFydCBpcyBub3QNCj4gYWRkcmVzc2VkLCB0aGUgaG9zdCB3aWxsICdyYW5kb21seScgKGN1 cnJlbnQgUkZDNjcyNCB3aWxsIG5vdCB1c2UgdGhlIHByZWZpeA0KPiBwcmVmZXJlbmNlKSBzZWxl Y3QgdGhlIHNvdXJjZSBhZGRyZXNzIGFuZCBwYWNrZXRzIG1pZ2h0IGdvIHRvIGVpdGhlciBJU1Ax IG9yDQo+IElTUDIuDQo+IA0KPiBJZiBJU1AyIHNob3VsZCBub3QgYmUgdXNlZCBhbmQgSVNQMSBz aG91bGQgYmUgcHJlZmVycmVkIChpcyBpdCB0aGUNCj4gc2NlbmFyaW8geW91IGFyZSB0YWxraW5n IGFib3V0Pz8pIHRoZW4gSVNQMiBwcmVmaXggc2hvdWxkIGJlDQo+IGFkdmVydGlzZWQgdG8gaG9z dHMgd2l0aCBwcmVmZXJyZWRfbGlmZXRpbWUgMC4gVGhlbiBob3N0cyB3aWxsIG5vdA0KPiBzZWxl Y3QgYWRkcmVzc2VzIGZyb20gSVNQIDIgcHJlZml4IGJ1dCB1c2UgSVNQMSBwcmVmaXggaW5zdGVh ZCBhbmQNCj4gcm91dGVycyB3aWxsIGZvcndhcmQgcGFja2V0IHRvIHByZWZlcnJlZCBJU1AxLg0K PiBXaHkgZG8gd2UgbmVlZCAicHJlZml4IHByZWZlcmVuY2UiIGZvciB0aGlzPw0KDQpbW0R1c2Fu XV0gDQpbW0R1c2FuXV0gQmVjYXVzZSB0aGUgcm91dGVyIHNob3VsZCBub3QgbGltaXQgdGhlIGNv bW11bmljYXRpb24gb3ZlciBvbmUgSVNQIGJ5IGFkdmVydGlzaW5nIG9ubHkgb25lIHByZWZpeC4g VGhlIGhvc3Qgc2hvdWxkIGJlIGFibGUgdG8gZGVjaWRlIHdoaWNoIG9mIHRoZSB0d28gSVNQcyB0 byB1c2UuIEJvdGggcHJlZml4ZXMgc2hvdWxkIGJlIGdpdmVuIHRvIHRoZSBob3N0IGFuZCB0aGV5 IHNob3VsZCBoYXZlIHRoZSBwcmVmZXJlbmNlIGFzc2lnbmVkLg0KDQo+IA0KPiA+PiA+UG9zc2li bGUgb3B0aW9uIGlzIHRvIGFzc2lnbiBhIHByZWZpeCBwcmVmZXJlbmNlIGluIFJBLg0KPiA+Pg0K PiA+PiBLaW5kIG9mIGEgY29tYmluYXRpb24gb2YgUnVsZSA1LjUgYW5kIHJvdXRlciBwcmVmZXJl bmNlPyBCb3RoIG9mIHRoZW0NCj4gPj4gYXJlIG5vdCB3aWRlbHkgaW1wbGVtZW50ZWQsIHRoYXQn cyB0aGUgd2hvbGUgcG9pbnQgb2YgdGhlIGRyYWZ0Lg0KPiA+DQo+ID4gW1tEdXNhbl1dDQo+ID4g W1tEdXNhbl1dIEV4YWN0bHkuIFNpbmNlIGJvdGggcHJlZml4ZXMgYXJlIGFzc2lnbmVkIGJ5IHR3 byBuZXh0IGhvcHMsIFJ1bGUgNS41DQo+IHNob3VsZCBiZSBlbmhhbmNlZCB0byB1c2UgdGhlIHBy ZWZlcnJlZCBwcmVmaXguIFN0YW5kYXJkcyBzaG91bGQgbm90IGFkZHJlc3MNCj4gdGhlIGN1cnJl bnQgZGVwbG95bWVudCBzdGF0ZSwgYnV0IHByb3ZpZGUgYSBiZXR0ZXIgc29sdXRpb24uIEkgd291 bGQgbm90IGZvY3VzDQo+IG9uIHdoYXQgaXMgbm90IGN1cnJlbnRseSBpbXBsZW1lbnRlZCBidXQg cmF0aGVyIG9uIHdoYXQgc2hvdWxkIGJlDQo+IGltcGxlbWVudGVkLg0KPiANCj4gSGF2ZSBJIHNl bnQgdGhpcyBlbWFpbCB0byA2bWFuQCBieSBtaXN0YWtlPyBBaCwgZG9lcyBub3QgbG9vayBsaWtl IHRoYXQgOikNCj4gQW5kIEkgc2VlbSB0byBzZXQgdGhlIGRvY3VtZW50IHN0YXR1cyB0byAnSW5m b3JtYXRpb25hbCcuDQoNCltbRHVzYW5dXSANCltbRHVzYW5dXSBJZiB3ZSBjaGFuZ2UgSVBPIG9w dGlvbiwgaXQgaXMgbm90IGluZm9ybWF0aW9uYWwgYW55IG1vcmUuDQo+IA0KPiBUaGlzIGRyYWZ0 IGRvY3VtZW50cyBhIHNvbHV0aW9uIHdoaWNoIHdvcmtzIHJpZ2h0IGhlcmUsIHJpZ2h0IG5vdywg dGhlDQo+IHNvbHV0aW9uIEkgY2FuIGRlcGxveSB0b2RheSBpbiBteSBuZXR3b3JrLg0KPiBCZXR0 ZXIgKG1vcmUgZ2VuZXJhbCwgY292ZXJpbmcgbW9yZSB1c2UgY2FzZXMsIHJlbHlpbmcgb24gUnVs ZSA1LjUpDQo+IGFwcHJvYWNoIHRvIHRoZSBwcm9ibGVtIGlzIGRvY3VtZW50ZWQgaW4NCj4gaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRydGd3Zy0yRGVudGVycHJpc2UtMkRwYS0N Cj4gMkRtdWx0aWhvbWluZy0NCj4gMkQwMyZkPUR3SUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2 NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvDQo+IFVXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPWdy X2x0aGpSUzhfREQtTjkxZUwyZWpSTkxnVVZ0SjRjLQ0KPiAxclE2OWFfLWlrJnM9M0JmSl9ZcHBw OGF0Q25vWDlJakZYUDd1ZDlxb3ltWDB5QWo4MGN5SkREZyZlPQ0KDQpbW0R1c2FuXV0gDQpbW0R1 c2FuXV0gWW91IGFwcHJvYWNoIHRvIHJlbW92ZSB0aGUgcHJlZml4IGZyb20gdGhlIGhvc3Qgd2hl biBvbmUgbGluayBmYWlscyB3aWxsIGFkZHJlc3MgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRnd2ctZW50ZXJwcmlzZS1wYS1tdWx0aWhvbWluZy0wMyNzZWN0aW9uLTEg UEEgbXVsdGlob21pbmcgcHJvYmxlbToNCg0KIklmIHRoZQ0KICAgcGFja2V0IHdpdGggc291cmNl IGFkZHJlc3MgaW4gcHJlZml4LUEgd2FzIHNlbnQgdG8gSVNQLUIgYmVjYXVzZSB0aGUNCiAgIHVw bGluayB0byBJU1AtQSBmYWlsZWQsIHRoZW4gaWYgSVNQLUIgZG9lcyBub3QgZHJvcCB0aGUgcGFj a2V0IGFuZA0KICAgdGhlIHBhY2tldCByZWFjaGVzIGl0cyBkZXN0aW5hdGlvbiBzb21ld2hlcmUg b24gdGhlIEludGVybmV0LCB0aGUNCiAgIHJldHVybiBwYWNrZXQgd2lsbCBiZSBzZW50IGJhY2sg d2l0aCBhIGRlc3RpbmF0aW9uIGFkZHJlc3MgaW4gcHJlZml4LQ0KICAgQS4gIFRoZSByZXR1cm4g cGFja2V0IHdpbGwgYmUgcm91dGVkIG92ZXIgdGhlIEludGVybmV0IHRvIElTUC1BLCBidXQNCiAg IGl0IHdpbGwgbm90IGJlIGRlbGl2ZXJlZCB0byB0aGUgbXVsdGlob21lZCBzaXRlIGJlY2F1c2Ug aXRzIGxpbmsgd2l0aA0KICAgSVNQLUEgaGFzIGZhaWxlZC4iDQoNCkRpZCB5b3UgbWVudGlvbiB0 aGlzIGluIHlvdXIgZHJhZnQ/DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJ0Z3dnLWVudGVycHJpc2UtcGEtbXVsdGlob21pbmctMDMjc2VjdGlvbi00IHN0YXRlczoN CiJUaGUgaG9zdCB3aWxsIGNvbnRyb2wgd2hpY2ggSVNQIGlzIHVzZWQNCiAgIGZvciBpdHMgdHJh ZmZpYyBieSBzZWxlY3Rpbmcgb25lIG9mIHRoZSBhZGRyZXNzZXMgY29uZmlndXJlZCBvbiB0aGUN CiAgIGhvc3QgYXMgdGhlIHNvdXJjZSBhZGRyZXNzIGZvciBvdXRnb2luZyB0cmFmZmljLg0KDQp0 aGUgY2hvaWNlIG9mIHNvdXJjZSBhZGRyZXNzDQogICBieSB0aGUgaG9zdCBtYXkgYmUgZHJpdmVu IC4uLg0KYnkgdGhlIGRlc2lyZSB0byB0YWtlIGFkdmFudGFnZSBvZg0KICAgY2VydGFpbiBwcm9w ZXJ0aWVzIG9mIGEgcGFydGljdWxhciB1cGxpbmsgb3IgSVNQLg0KDQogICBIb3cgYSBob3N0IHNo b3VsZCBtYWtlIGdvb2QgZGVjaXNpb25zIGFib3V0IHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbg0K ICAgaW4gYSBtdWx0aWhvbWVkIHNpdGUgaXMgbm90IGEgc29sdmVkIHByb2JsZW0uICBXZSBkbyBu b3QgYXR0ZW1wdCB0bw0KICAgc29sdmUgdGhpcyBwcm9ibGVtIGluIHRoaXMgZG9jdW1lbnQuICBJ bnN0ZWFkIHdlIGRpc2N1c3MgdGhlIGN1cnJlbnQNCiAgIHN0YXRlIG9mIGFmZmFpcnMgd2l0aCBy ZXNwZWN0IHRvIHN0YW5kYXJkaXplZCBzb2x1dGlvbnMgYW5kDQogICBpbXBsZW1lbnRhdGlvbiBv ZiB0aG9zZSBzb2x1dGlvbnMuIA0KDQpGb3IgYSBzZXNzaW9uIG9yaWdpbmF0ZWQgYnkgYSBob3N0 IGludGVybmFsIHRvIHRoZSBtdWx0aS1ob21lZCBzaXRlLA0KICAgdGhlIGRlY2lzaW9uIG9mIHdo YXQgc291cmNlIGFkZHJlc3MgdG8gc2VsZWN0IGlzIG1vcmUgY29tcGxpY2F0ZWQuDQogICBXZSBj b25zaWRlciB0aHJlZSBtYWluIG1ldGhvZHMgZm9yIGhvc3RzIHRvIGdldCBpbmZvcm1hdGlvbiBh Ym91dCB0aGUNCiAgIG5ldHdvcmsuICBUaGUgdHdvIHByb2FjdGl2ZSBtZXRob2RzIGFyZSBOZWln aGJvciBEaXNjb3ZlcnkgUm91dGVyDQogICBBZHZlcnRpc2VtZW50cyAuLi4iDQoNCllvdXIgcHJv cG9zYWwgaW4gdGhpcyBkcmFmdCBpcyB0byB1c2UgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRnd2ctZW50ZXJwcmlzZS1wYS1tdWx0aWhvbWluZy0wMyNzZWN0aW9uLTQu MSANCiIgUnVsZSAzIChBdm9pZCBkZXByZWNhdGVkIGFkZHJlc3NlcykNCi4uLg0KIHNlbmQgYSBS b3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdlIGNvbnRhbmluZyBhDQogICBQcmVmaXggSW5mb3Jt YXRpb24gT3B0aW9uIGZvciB0aGUgc291cmNlIHByZWZpeCB0byBiZSBkaXNjb3VyYWdlZCAob3IN CiAgIHByb2hpYml0ZWQpIHdpdGggdGhlIHByZWZlcnJlZCBsaWZldGltZSBzZXQgdG8gemVyby4i DQpCdXQNCiIgVGhpcyBpcyBhIHJhdGhlciBibHVudCB0b29sLCINCg0KQW5kIHRoaXMgZHJhZnQg aGFzIHRoZSBzYW1lIGlzc3VlIHdoZW4gdHdvIHByZWZpeGVzIGFyZSBhZHZlcnRpc2VkOg0KIiAg IFJ1bGUgNS41IChQcmVmZXIgYWRkcmVzc2VzIGluIGEgcHJlZml4IGFkdmVydGlzZWQgYnkgdGhl IG5leHQtaG9wKSBpcw0KICAgbm90IHVzZWZ1bCBpbiB0aGUgc2NlbmFyaW8gd2hlbiBib3RoIFIx IGFuZCBSMiB3aWxsIGFkdmVydGlzZSBib3RoDQogICBzb3VyY2UgcHJlZml4ZXMuIg0KDQpSdWxl IDcgaGFzIHRoZSBzYW1lIGlzc3VlOg0KIlJ1bGUgNyAoUHJlZmVyIHRlbXBvcmFyeSBhZGRyZXNz ZXMpDQouLi4NCnByZWZlciB0aGUgdHdvIHRlbXBvcmFyeSBhZGRyZXNzZXMsIGJ1dCBpdCB3b3Vs ZCBub3QgYnJlYWsgdGhlIHRpZQ0KICAgYmV0d2VlbiB0aGUgdHdvIHNvdXJjZSBwcmVmaXhlcyBm cm9tIElTUC1BIGFuZCBJU1AtQi4iDQp3aGljaCBjb3VsZCBiZSBhdm9pZGVkIGlmIFJ1bGUgNS41 IHNlbGVjdGVkIG9uZSBhZGRyZXNzLg0KDQpXaGF0IHRoZXkgZGlkIHdhczoNCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Z3dnLWVudGVycHJpc2UtcGEtbXVsdGlob21p bmctMDMjc2VjdGlvbi00LjIuMiAuIFlvdXIgZHJhZnQgY2FuIHVzZSB0aGUgc2FtZSBhcHByb2Fj aCBhbmQgc2V0IHR3byByb3V0ZXMgaW4gUkEgYW5kIHRoZSBQcmYgZnJvbSByZmM0MTkxI3NlY3Rp b24tMi4yLCBiYXNlZCBvbiB0aGUgcm91dGVyIHBvbGljeS4gTm8gcHJvdG9jb2wgY2hhbmdlIGlz IHJlcXVpcmVkLg0KDQo+IGJ1dCBpdCBjYW4gbm90IGJlIHVzZWQgaW4gbmV0d29ya3Mgd2l0aCBo b3N0cyB3aGljaCBkbyBub3Qgc3VwcG9ydA0KPiA1LjUuDQo+IEFsc28gdGhlcmUgaXMgbVBWRCB3 b3JrIGV0Yy4NCj4gDQo+ID4+IFRoZSBpbnRyb2R1Y3Rpb24gc2F5czoNCj4gPj4gIkhvd2V2ZXIg dXNpbmcgSVB2NiBQQSBibG9ja3MNCj4gPj4gICAgaW4gbXVsdGlob21pbmcgc2NlbmFyaW8gaW50 cm9kdWNlcyBzb21lIGNoYWxsZW5nZXMsIGluY2x1ZGluZyBidXQgbm90DQo+ID4+ICAgIGxpbWl0 ZWQgdG86DQo+ID4+DQo+ID4+ICAgIG8gIFNlbGVjdGluZyB0aGUgY29ycmVjdCB1cGxpbmsgYmFz ZWQgb24gdGhlIHBhY2tldCBzb3VyY2UgYWRkcmVzczsNCj4gPj4NCj4gPj4gICAgbyAgU2lnbmFs aW5nIHRvIGhvc3RzIHRoYXQgc29tZSBzb3VyY2UgYWRkcmVzc2VzIHNob3VsZCBvciBzaG91bGQg bm90DQo+ID4+ICAgICAgIGJlIHVzZWQgKGUuZy4gYW4gdXBsaW5rIHRvIHRoZSBJU1Agd2VudCBk b3duIG9yIGJlY2FtZSBhdmFpbGFibGUNCj4gPj4gICAgICAgYWdhaW4pLg0KPiA+PiAiDQo+ID4g W1tEdXNhbl1dDQo+ID4gW1tEdXNhbl1dIFRoZXNlIHR3byBjYXNlcyBhcmUgdmFsaWQgYnV0IHRo ZXkgZG9uJ3QgY292ZXIgIi5TZWxlY3RpbmcgdGhlIHJpZ2h0DQo+IHNvdXJjZSBhZGRyZXNzICp0 byBzZWxlY3QgdGhlIGVncmVzcyBJU1AgdG8gdXNlKiIuIFRoaXMgd291bGQgYmUgYSB0aGlyZCBw cm9ibGVtDQo+IHRvIGFkZHJlc3MuIFRoaXMgY29tZXMgYmVmb3JlIHRoZSBmaXJzdCBidWxsZXQg KHRoZSBzb3VyY2UgYWRkcmVzcyBuZWVkcyB0byBiZQ0KPiBjaG9zZW4gZmlyc3QsIHRoZW4gdGhl IGNvcnJlY3QgdXBsaW5rKS4gVGhlIHNlY29uZCBidWxsZXQgdGFsa3MgYWJvdXQgdGhlDQo+IGNv bm5lY3Rpdml0eSBpc3N1ZXMsIHdoZXJlIGEgcHJlZml4IGlzIHJlbW92ZWQgd2hlbiBhIGxpbmsg aXMgZG93bi4gV2UgbmVlZCB0bw0KPiBtZW50aW9uIHRoZSBzb3VyY2UgYWRkcmVzcyBzZWxlY3Rp b24gd2hlbiBib3RoIGxpbmtzIGFyZSB1cC4NCj4gDQo+IElmIHRoZSBib3RoIHVwbGlua3MgYXJl IHVwIGFuZCBjYW4gYmUgdXNlZCAoc28gbG9hZCBzaGFyaW5nIHNjZW5hcmlvKQ0KPiB0aGVuIGhv c3RzIGNhbiB1c2UgZWl0aGVyIHVwbGluay4gSVNQMSBvciBJU1AyLiBXaHkgaXMgaXQgYSBwcm9i bGVtPw0KPiBJZiBvbmUgdXBsaW5rIChsZXQ7cyBzYXkgSVNQMikgc2hvdWxkIG5vdCBiZSBwcmVm ZXJyZWQgKGxvdw0KPiBiYW5kd2lkdGgvaGlnaGVyIHByaWNlIGV0YykgdGhlbiBpdCdzIGEgJ3By aW1hcnkvYmFja3VwJyBzY2VuYXJpbyBhbmQNCj4gaG9zdHMgYXJlIHNlbGVjdGluZyBJU1AxIHBy ZWZpeCBhcyBpdCdzIHRoZSBvbmx5IHByZWZpeCB3aXRoIG5vbi16ZXJvDQo+IHByZWZlcnJlZCBs aWZldGltZS4NCj4gDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBHZXJ0IERvZXJpbmcgW21haWx0bzpnZXJ0QHNwYWNlLm5l dF0NCj4gPj4gPj4gU2VudDogRnJpZGF5LCBNYXJjaCAwMiwgMjAxOCAxOjU3IFBNDQo+ID4+ID4+ IFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCj4gPj4gPj4gQ2M6IEplbiBMaW5rb3ZhOyB2Nm9w c0BpZXRmLm9yZw0KPiA+PiA+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXY2b3BzLWNvbmRpdGlvbmFsLXJhcy0wMS50eHQNCj4gPj4gPj4NCj4gPj4gPj4gSGks DQo+ID4+ID4+DQo+ID4+ID4+IE9uIEZyaSwgTWFyIDAyLCAyMDE4IGF0IDA0OjIxOjMyUE0gKzAw MDAsIE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KPiB3cm90ZToNCj4gPj4gPj4gPiBJbiBBYnN0cmFj dDoNCj4gPj4gPj4gPg0KPiA+PiA+PiA+ICJUaGUgcHJvYmxlbSBvZiBlbnRlcnByaXNlIG11bHRp aG9taW5nIHdpdGhvdXQgYWRkcmVzcw0KPiA+PiA+PiA+ICAgIHRyYW5zbGF0aW9uIG9mIGFueSBm b3JtIGhhcyBub3QgYmVlbiBzb2x2ZWQgeWV0IGFzIGl0IHJlcXVpcmVzIGJvdGgNCj4gPj4gPj4g PiAgICB0aGUgbmV0d29yayB0byBzZWxlY3QgdGhlIGNvcnJlY3QgZWdyZXNzIElTUCBiYXNlZCBv biB0aGUgcGFja2V0DQo+ID4+ID4+ID4gICAgc291cmNlIGFkZHJlc3MgYW5kIGhvc3RzIHRvIHNl bGVjdCB0aGUgY29ycmVjdCBzb3VyY2UgYWRkcmVzcyBiYXNlZA0KPiA+PiA+PiA+ICAgIG9uIHRo ZSBkZXNpcmVkIGVncmVzcyBJU1AgZm9yIHRoYXQgdHJhZmZpYy4iDQo+ID4+ID4+ID4NCj4gPj4g Pj4gPiBTaG91bGQgYmU6DQo+ID4+ID4+ID4gIlRoZSBwcm9ibGVtIG9mIGVudGVycHJpc2UgbXVs dGlob21pbmcgd2l0aG91dCBhZGRyZXNzDQo+ID4+ID4+ID4gICAgdHJhbnNsYXRpb24gb2YgYW55 IGZvcm0gaGFzIG5vdCBiZWVuIHNvbHZlZCB5ZXQgYXMgaXQgcmVxdWlyZXMNCj4gPj4gPj4gPiAg ICB0aGUgaG9zdHMgdG8gc2VsZWN0IHRoZSBjb3JyZWN0IHNvdXJjZSBhZGRyZXNzIGJhc2VkDQo+ ID4+ID4+ID4gICAgb24gYSBkZXN0aW5hdGlvbiBhZGRyZXNzIGZvciB0aGF0IHRyYWZmaWMsDQo+ ID4+ID4+ID4gICAgdGhlIGhvc3RzIHRvIHNlbGVjdCBhIGZpcnN0IGhvcCByb3V0ZXIgYmFzZWQg b24gdGhlIHBhY2tldA0KPiA+PiA+PiA+ICAgIHNvdXJjZSBhZGRyZXNzLCBhbmQgdGhlIG5ldHdv cmsgdG8gc2VsZWN0IHRoZSBjb3JyZWN0IGVncmVzcyBJU1AgYmFzZWQNCj4gb24NCj4gPj4gPj4g dGhlIHBhY2tldA0KPiA+PiA+PiA+ICAgIHNvdXJjZSBhZGRyZXNzIg0KPiA+PiA+Pg0KPiA+PiA+ PiBBY3R1YWxseSB0aGUgbmV3IHRleHQgaXMgY29tcGxldGVseSBtaXNzaW5nIHRoZSBwb2ludC4g IFNvdXJjZSBhZGRyZXNzDQo+ID4+ID4+IHNlbGVjdGlvbiAqZm9yIGEgZGVzdGluYXRpb24gYWRk cmVzcyogaXMgc29tZXRoaW5nIGFscmVhZHkgYWRkcmVzc2VkDQo+ID4+ID4+IG5pY2VseSAoUkZD NjcyNCkuDQo+ID4+ID4+DQo+ID4+ID4+IFNlbGVjdGluZyB0aGUgcmlnaHQgc291cmNlIGFkZHJl c3MgKnRvIHNlbGVjdCB0aGUgZWdyZXNzIElTUCB0byB1c2UqIGlzDQo+ID4+ID4+IHRoZSBwYXJ0 IG5vdCBhZGRyZXNzZWQgaW4gaG9zdCBzdGFja3MgYXQgYWxsIHlldC4NCj4gPj4gPj4NCj4gPj4g Pj4gVGhlIG5ldHdvcmsgcGFydCAic2VsZWN0IGVncmVzcyBiYXNlZCBvbiBwcm9wZXIgc291cmNl IGFkZHJlc3MiIGlzDQo+IGhhbGZ3YXkNCj4gPj4gPj4gc29sdmVkIHdpdGggdGhlIGhvbWVuZXQg cHJvdG9jb2wgc3VpdGUgKHNvdXJjZSBhZGRyZXNzIGRlcGVuZGVudCBiYWJlbCwNCj4gPj4gPj4g aG5jcCwgZXRjLikgLSBidXQgdGhhdCBpcyBzdHVmZiBub3QgdXN1YWxseSBmb3VuZCBvbiBFbnRl cnByaXNlIHJvdXRlcnMuDQo+ID4+ID4+DQo+ID4+ID4+IEdlcnQgRG9lcmluZw0KPiA+PiA+PiAg ICAgICAgIC0tIE5ldE1hc3Rlcg0KPiA+PiA+PiAtLQ0KPiA+PiA+PiBoYXZlIHlvdSBlbmFibGVk IElQdjYgb24gc29tZXRoaW5nIHRvZGF5Li4uPw0KPiA+PiA+Pg0KPiA+PiA+PiBTcGFjZU5ldCBB RyAgICAgICAgICAgICAgICAgICAgICAgIFZvcnN0YW5kOiBTZWJhc3RpYW4gdi4gQm9taGFyZA0K PiA+PiA+PiBKb3NlcGgtRG9sbGluZ2VyLUJvZ2VuIDE0ICAgICAgICAgIEF1ZnNpY2h0c3JhdHN2 b3JzLjogQS4gR3J1bmRuZXItDQo+IEN1bGVtYW5uDQo+ID4+ID4+IEQtODA4MDcgTXVlbmNoZW4g ICAgICAgICAgICAgICAgICAgSFJCOiAxMzYwNTUgKEFHIE11ZW5jaGVuKQ0KPiA+PiA+PiBUZWw6 ICs0OSAoMCk4OS8zMjM1Ni00NDQgICAgICAgICAgIFVTdC1JZE5yLjogREU4MTMxODUyNzkNCj4g Pj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0K PiANCj4gDQo+IA0KPiAtLQ0KPiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo= From nobody Thu Mar 8 11:30:20 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4A9124BFA for ; Thu, 8 Mar 2018 11:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLF-knrVyV01 for ; Thu, 8 Mar 2018 11:30:16 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878581201F8 for ; Thu, 8 Mar 2018 11:30:16 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id l131so2613455pga.2 for ; Thu, 08 Mar 2018 11:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=PLyv2JifEPBhc/xsNY6Z16fOW6bCEcrjfNhQy2y4VyE=; b=ldVGiMbj96b89/MhDHsk/TgURQMxoJcINBg2sd0p3v0xF7jypjnLMvA+vJfvz8H3R/ y32WL2yjQXkBgt5dpp6wa02EKlxbJbSj5EjFvyZrbA9jhiun9AYs6iN5PkjWctaVRmvD 6u/M5KmUsuZVz4FrO0gFIm4dkg/yTd4JnnaVX0VHF+34F2RA9Nj1m7pzeSlACOg457Pf HHHqdOAjbJXMdurboldDiktQEnOJXcpNuvFGUfHTfKbjpalRhomIGatjZM4AS18g6xuj wwqThJ69+RSQjC68LvyMlswDWm7pas+Wx71sCkPWXGzOrmEcNVzeHep2Nc5DnaTyOhFw FxUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=PLyv2JifEPBhc/xsNY6Z16fOW6bCEcrjfNhQy2y4VyE=; b=HA8JL0n/0Ei2DlDQBrIYEFPdE05NjSsm08xRyBdCszGHyMm4qbmmC+85JkVyuGKVl7 fHy8ze04VHGE0I1pVdRhOY3+Y1dFU8Jc6livD91kwl1zkszXkpMNmi8GuCargqe2S12C 8rf+P1BTb4n+MjHf36awKJz2XKgLwSM7aF7eHnfhZKvABV6DqKeVKCTZdmcpHzcg02Qb 5uguhBvt5AyAGN+M+FblCmB7XWOamuRe4hfa3iq1eaxo5N/zfhFwOaz5IHOvh5tofb9N FAkqs2FvOGL0jJUTeKA8AG0GqfrJNvq1LJprmyW5TrAIwcMl7TDEDREdots/K2s3Zo/M 0QzQ== X-Gm-Message-State: APf1xPAcJp2y39419KoWmbd5VRSnLiSahyVoi7y8bDc3Vl56EA5hZZeV llySeGv8iFjF7EIYFRKQPRAPwWiG X-Google-Smtp-Source: AG47ELtVkt9+M4QdXgAz6dqag8Us5Lj6crVoJCSK8ZOPuWtTeIyweMSwJEIp+aq0E41Hpou03YxlQg== X-Received: by 10.99.146.91 with SMTP id s27mr21925710pgn.367.1520537416129; Thu, 08 Mar 2018 11:30:16 -0800 (PST) Received: from ?IPv6:2600:8801:d004:600:20c8:8217:2ac4:2385? ([2600:8801:d004:600:20c8:8217:2ac4:2385]) by smtp.gmail.com with ESMTPSA id o82sm50114129pfj.163.2018.03.08.11.30.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 11:30:15 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_DB4B7E11-C297-434F-91E4-3E3AD92724BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.15\)) Message-Id: <919CC8C6-089B-405A-BEA1-5A5192BDE931@gmail.com> Date: Thu, 8 Mar 2018 11:30:13 -0800 Cc: Ron Bonica , Lee Howard , Warren Kumari To: V6 Ops List X-Mailer: Apple Mail (2.3445.6.15) Archived-At: Subject: [v6ops] Preliminary Agenda for IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 19:30:18 -0000 --Apple-Mail=_DB4B7E11-C297-434F-91E4-3E3AD92724BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have posted a preliminary agenda for IETF 101 at = https://datatracker.ietf.org/doc/agenda-101-v6ops/. --Apple-Mail=_DB4B7E11-C297-434F-91E4-3E3AD92724BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlqhj0UACgkQEhdRnd2G P+Dp2g//ZvDuojAsSPmTamoIzsMKVSpL+9/NZ77cAjxOzdwwJWfX55r9Xh1EQAlX gUeUF8Ld2Oxm00amipclwo8EBEjo0VJWaH08QyWFCHRV0IomcP/KR8N8ntaaToSX HSoQeFYUcOo424ZWKCPjxl62/YXCmrr7tW+MGmAkk2RlNgN0P7uLt6uQtVk1VxZh J92HBF17tqGcUFR2kgNWwwpJnic2xXsBL9IzcAEJx9IBa0+8ojz8l3D4dx7UM0LC KnsS1v79HVUUWlpkkHc8nvdjaFK+llp3fV6qBy0Lv+A9krwjNEqs43tape+RtO0N lycr+LjaJXIsvJh+J9VEbDRCEULxRamshGjlzpJXWmlJV7v3BpgfFwCMgOeSOnMt Y5lZjajFcLYyMi0Kwjj6xcr+iImbuAtQ3+NDccjL7O18k6wF1PjMfW1xABISE6aL ha5Fuh7GMS2/9NrCaRdNAEETeSN19UGvnCUzOguKsJo72G1rsi6zcS+GRC9DMnnP 4BS7SX/fnPynLAWkQ+wNq/Y2kbMOft0n5JYqYSwRA2bTfsjlUvV7bQKFCG0KyWey HVD6coojHnECnONkdc+kqN3ki/E9VzdI+COQF8VSj+Qj5bZkZNcBCDo0rs4zPjWX JHzwn34odLLfSp1t30ADr2TcrzKzo+OBzP4Pqrd1XClA/DR3MaU= =plH2 -----END PGP SIGNATURE----- --Apple-Mail=_DB4B7E11-C297-434F-91E4-3E3AD92724BB-- From nobody Thu Mar 8 11:42:17 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D551270AC; Thu, 8 Mar 2018 11:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4diQUIyEmdm; Thu, 8 Mar 2018 11:42:08 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e: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 6C081124BFA; Thu, 8 Mar 2018 11:42:05 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id q27so2616383pgn.8; Thu, 08 Mar 2018 11:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=h4dMh84JXdrW50zgRlCOgATdnXQ4BQ2bFwiHo5rjUWk=; b=gV6XCs50eBiB/Bwfy6DlL4ajuA9Uu7MrijS2Wcl/4YwjCLdvXfNKJVlcGBhQI2v2P7 jaMawXj3omCp82ZrothRG55yCalrXDOHPN8A5RG7+Q46Xp/SumSpZt9pm9RBCHWpj3xV 6p9o9AbO2bRmRm36wZgmUeFiO5xxGhSpsAqgru3yKe/Vk7Y97Wk//Yd1KvAGxKDeidEV qHZySPDCe2Qz9P7UZYiOD/uSBcdyKp/WjMS2v4H9hth8FNqJW8y1lk0nwxrAaA83kAOX xEiQhYHa25kOPrKj5jMEA2+qoSFAZ0Kh71bUtKVvGWZDGN5cZohOTHPoCeo/fDDGQxSj QS2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h4dMh84JXdrW50zgRlCOgATdnXQ4BQ2bFwiHo5rjUWk=; b=E4XR8DyfqME8Hh91YLBXsDt+IxNVprraelsx5EfB07CsREbfzrMUpuD5GNZXMXPE6s WBC46eaN81OBgrpqSyMpcsyH906s+8zuWSVoq9nHzHGV1JQQmusANSCd2gX/v7TBfuAR GIr6tldrD24qR4NuSBrww6NrS6nhS4hf9pAx4qQOYt7X+E1qrOpGck6U4wEYgzVBJJoL TvzE+Rki2sxeyioMoh0yfHJTC+NMEyGkq1RDx03L45Lz0IBeiLahj5hnVh0zASdiQ31x vKOntLvqmh2pyXZNbJRCY1y+r0bReVcCGLWT/mjhCUPklWqslq4oIOZduh1RPziB+H1B Rs6g== X-Gm-Message-State: APf1xPBQMVKY0OL2ycA8MnDkz7PTmY5dmkvGDNa21hn65kLiyzchKOUe q/2YAPICtg44N2vZ0OYT8EyYad4c X-Google-Smtp-Source: AG47ELvW+2CZfRenEhi27ifhBaKd21UlhKSLJnI9bc7N0xrFnYLupiTDnM4MIAMcALyNvX7JnxQAKA== X-Received: by 10.101.83.140 with SMTP id x12mr21429817pgq.288.1520538124781; Thu, 08 Mar 2018 11:42:04 -0800 (PST) Received: from [192.168.43.75] ([118.148.220.220]) by smtp.gmail.com with ESMTPSA id r1sm22183847pgq.41.2018.03.08.11.42.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 11:42:03 -0800 (PST) Sender: Brian Carpenter To: "Eric Vyncke (evyncke)" , "opsec@ietf.org" , "v6ops@ietf.org WG" Cc: "draft-ietf-opsec-v6.authors@ietf.org" References: From: Brian E Carpenter Message-ID: <733d8fa5-eb9c-23ec-5beb-81d17bd87a24@gmail.com> Date: Fri, 9 Mar 2018 08:30:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] What is new in draft-ietf-opsec-v6-13.txt ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 19:42:10 -0000 Eric, On 02/03/2018 02:08, Eric Vyncke (evyncke) wrote: > There are a lot of changes in the -13 version, many minor and a couple of bigger ones (such the ULA section). A new author, Enno Rey, has joined the team and has provided a tremendous amount of suggestions/changes. We also have acted on the comments from Ole Troan, Ron Bonnica, Bernie Volz, Fernando Gont and Erik Kline. > > As usual you can compare the versions with: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-13.txt > > The authors will welcome reviews and comments especially on the new section 2.1.2 (Use of ULAs): this 'ugly' topic needs to be in this document and no author wants to recommend it obviously ;-) I don't see anything ugly in the new text of 2.1.2; it is neutral and accurate. (There are specialised use cases for ULAs such as draft-ietf-anima-autonomic-control-plane, but I don't think it's necessary to mention them here.) > One open point is what to do with 'mostly obsolete' tunneling such as Teredo and 6to4 ? Ole wants to remove those sections completely but the authors feel that we need to keep them to be exhaustive. I agree with the authors. Also, you say: "Teredo is now mostly never used and it is no more automated in most environment, so, it is less of a threat." I was amazed recently to discover that this statement is untrue. I refer to fully updated Windows 10 Home laptops (two of them) which came up with an active Teredo interface that I had to disable. Actually, such a statement is more true of 6to4 today, which I think nobody configures by default. > Same for the CGN (NAT444) section, not really an IPv6 topic, but an important related-one and the document is in OPSEC WG (which is protocol version agnostic). However, the scope of the draft is "IPv6 Networks" so this really does seem out of scope to me. Brian From nobody Fri Mar 9 10:36:01 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A65012778D; Fri, 9 Mar 2018 10:35:55 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Tv-Zgl7e9cO; Fri, 9 Mar 2018 10:35:53 -0800 (PST) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 385C0124239; Fri, 9 Mar 2018 10:35:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w29IZqLF021036; Fri, 9 Mar 2018 11:35:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w29IZqZi020781 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 9 Mar 2018 11:35:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 9 Mar 2018 10:35:51 -0800 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Fri, 9 Mar 2018 10:35:51 -0800 From: "Templin, Fred L" To: "ipv6@ietf.org" , V6 Ops List Thread-Topic: RS/RA-based prefix delegation Thread-Index: AdO31FwtO+XEDp9JSOaTHzMONumduQ== Date: Fri, 9 Mar 2018 18:35:51 +0000 Message-ID: <7a76f69b23004ce5bb6518d294a41bfa@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] RS/RA-based prefix delegation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2018 18:35:55 -0000 Hi, going back to discussions from last month, we have implemented an RS/RA= -based prefix delegation service. The service is based on RS/RA messaging between = the client and the first-hop router, with the first-hop router serving as a relay to t= he DHCPv6 server on the back end. A wireshark/tcpdump capture between the client and first-hop router would s= how ordinary RS/RA messages with options that include the body of a DHCPv6 mess= age as discussed in: https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/ But, it is not necessary that the RS/RA options include a formal DHCPv6 mes= sage, because the first-hop router can convert whatever is contained in the RS message in= to DHCPv6 messages for its exchanges with the back end server, and then reconvert the= DHCPv6 Reply into the appropriate response for inclusion in the RA. So, we can plu= g in whatever RS/RA message options that would eventually be designed to facilitate prefi= x delegation. The code is available here: http://linkupnetworks.net/aero/AERO-OpenVPN-1.1.tgz Please review the draft and code and send comments to the list. Thanks - Fred fred.l.templin@boeing.com From nobody Sat Mar 10 03:11:17 2018 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFBB120724; Sat, 10 Mar 2018 03:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msEBEj4qtMrO; Sat, 10 Mar 2018 03:11:14 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 82041124217; Sat, 10 Mar 2018 03:11:14 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id k21so2373388ioc.2; Sat, 10 Mar 2018 03:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=tYnruAZbCp6fiE9JiTZNnGygXg5paFy37Z8iAy66h+A=; b=AV+F7xj8kpbaBJTVvVG1hC+8BVmFOR1I7z6/4v+xHa4oabSAfJ1rHmJ+AZ+Yt5nL8Z KM51DHsS0qEOm+dwem3xAMmrE7m/1l+yvZLs6htzVGIHLP/hTX9tWdvz76qLTNpfo3bV 12g/VfvL0NAB77kwOmtzll7tTdGq+MJkg54BINLz3yGAUTl4W48/nkOlUczlwt1dH4OA P9uVIcP3JIdK1at6Gii/GWS7o8Z4MUg726taZ6+xU/PRhvXycTYNPYyLmq6CP5gmpTTZ lJi/NHV7Q5Coupea0IbgQ+nTMfjieQurkjK7fceXAV/mr/wmYkBMuuYQwueAKorQllfn 67Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=tYnruAZbCp6fiE9JiTZNnGygXg5paFy37Z8iAy66h+A=; b=NqdqDzMyCBz1DHixdmGp2gpMAnLl9ExwgL7dDI2qjWz/72ANqVMFtH3YS+bw13YFJt 96sMe1BlJesycyUylt289LRU5l4EMzXyPjJjdSHdKW0naHqQtwp402AIJms2gTbrrA9U Bs7KOeK01MlnKGSDH6cDuDhH5gnIBHZ+M7cHtCwIIcVroYc1xcowHBXm5slsxU8Tc5Kd qRjBHSvM4tqrDslcA3apgT4VFsidkyUPI8PCVo81fcdnX2ZUblVI33UhyI91L+QyAVjx d6efb6KkdLflN5rVxon92NL5VfmKCLLNpZ/S7lRkEL87nbY5Y4VlQlEXDh5w5OMUfztv HFiw== X-Gm-Message-State: AElRT7FF807uBg5eFA+q2gp7mKdW5qK3cvRnbSkMY0ADYLSj6tBICEVH oevkrMeAdW4tD3u5eLo8cxZtDg== X-Google-Smtp-Source: AG47ELswaic5ecCx6LmeNTzV+i8jp+sXWl4w1VrnV5Y5bdTI+8v8qwREO+I16J9IZ371zzM+7N4GuQ== X-Received: by 10.107.101.8 with SMTP id z8mr1702315iob.279.1520680273719; Sat, 10 Mar 2018 03:11:13 -0800 (PST) Received: from Russ ([2600:1700:720:1050:153d:411e:bd7c:8be7]) by smtp.gmail.com with ESMTPSA id u77sm518022ita.30.2018.03.10.03.11.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Mar 2018 03:11:13 -0800 (PST) From: <7riw77@gmail.com> To: "'Lorenzo Colitti'" , "'internet-drafts'" Cc: , References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> In-Reply-To: Date: Sat, 10 Mar 2018 06:11:14 -0500 Message-ID: <00b901d3b860$81e731e0$85b595a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFOj4SCAN8kJXBrD1a3n5TRO1DFbAHIesC0pMVcclA= Content-Language: en-us Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 11:11:16 -0000 =20 > Saying that mobile phones must support DHCPv6 is harmful, because: Saying that a mobile phone is a router _designed_ to forward IPv6 = packets, when it clearly only forwards these packets incidentally, seems = like a stretch, however. =20 > this document? If so, I would suggest adding an applicability = statement that > clarifies that not every piece of equipment under the sun that ever = happens > to forward an IPv6 packet must meet these requirements. If you can write such an applicability statement, beyond what is already = in there, that does not essentially make the document pointless, please = suggest text. What is there, at this point, already makes the draft = non-normative, as there is apparently no possible way to write a = normative set of requirements for anything relating to IPv6 -- every = deployment is apparently a special snowflake with nothing in common = other than the number of bits in the address. =F0=9F=98=8A /r From nobody Sat Mar 10 03:13:31 2018 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69B1124217 for ; Sat, 10 Mar 2018 03:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rv7zxNknWE3 for ; Sat, 10 Mar 2018 03:13:27 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6CE120724 for ; Sat, 10 Mar 2018 03:13:27 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id m22so6299591iob.12 for ; Sat, 10 Mar 2018 03:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=BzNoCcTFZtibIyUYuYLrqlk20flj9/B2Mzit7GCc5w8=; b=bRQhsqk4CBo+KUGPT3Tz8WtZTCRzpNPNInpLSSetuMk4EcV6VGmSeUTsYm2F9d8qjz LIZW4H1KCCHochWcjRhjU9o/lf8L9Z3KkxUv+HtjVl3fWXcd3d9Vo7fBFN/1BI1RDMwl 9pUUAotEsS3/5hR124QwJWMfTdeFxFICiaoKZSeWHf2eWZQ3C/DGOXrPWwMsOl60v+G5 Lf9OQKpqNIuKPobSK2NSHx+yrAyeWaPMsLra8veoE0Lo153ulElRIP3qgy/Cuqs5lA92 LISiO0Va0WG+APKfeafFkr9NSdKztKAAhnkQOetcpDDWDPkC3sQSZGBhAbOZxeupucTq +YUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=BzNoCcTFZtibIyUYuYLrqlk20flj9/B2Mzit7GCc5w8=; b=rth83QvTnamm8D+rOpPe2bARHQynK8lBzx2v1l9USBv0FNlCcHVHkELdxHbX4o05M9 3j+XN3AjUFf+fLzT1gIdTkCIREDJCIZRNWwAEx1UDALmFnFr9k6Lq45ZUki4jngWJSN3 nea1PISthJ9xVi28tFBDJ0+UD4qDnesR7A82kB6oOqCQmxApqXEVAH6MBOf5Ghry7+HG VR2NvCi7OE7f4EnREPoAKySGtuA51BxiGmX1Sc1JoN0UTXiKOlPHZhcoSrjn1L27E6ym OxQrtCa5COnGRlTMIjcnVAb+xJoLthczg76i1sCyhqZbMAW4swt3bB5x5qC+umpMvyLn rORg== X-Gm-Message-State: AElRT7FGQT5idcZw0Oh0N6r9vTD8DLE8JLotTIM4qWoOyg1R+FZAJQcy zntxVuhDL9zLdGUZn0iZqQrBYw== X-Google-Smtp-Source: AG47ELuQHtt6zOdD4w8IfXJ07SIWOo23q/da4tbaKwFGaEOEt3fgAXT92T3hxN2goUpodgmM5Seycw== X-Received: by 10.107.31.1 with SMTP id f1mr1825795iof.12.1520680406511; Sat, 10 Mar 2018 03:13:26 -0800 (PST) Received: from Russ ([2600:1700:720:1050:153d:411e:bd7c:8be7]) by smtp.gmail.com with ESMTPSA id f83sm2197962ioj.20.2018.03.10.03.13.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Mar 2018 03:13:26 -0800 (PST) From: <7riw77@gmail.com> To: "'Pablo Alvarez'" Cc: References: <152021615239.27925.6946415833371012617@ietfa.amsl.com> <7356fe3a-3818-1c9e-2a90-d65fe8b3bb14@akamai.com> In-Reply-To: <7356fe3a-3818-1c9e-2a90-d65fe8b3bb14@akamai.com> Date: Sat, 10 Mar 2018 06:13:28 -0500 Message-ID: <00ea01d3b860$d1329280$7397b780$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFOj4SCAN8kJXBrD1a3n5TRO1DFbAEBd6EtpMuWztA= Content-Language: en-us Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 11:13:29 -0000 > I am happy with the updates to section 5.4, ICMP considerations. Thanks! =F0=9F=98=8A /r From nobody Sat Mar 10 04:07:00 2018 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DEA1271FD for ; Sat, 10 Mar 2018 04:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNCW0-YXk5mk for ; Sat, 10 Mar 2018 04:06:57 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 325DB124217 for ; Sat, 10 Mar 2018 04:06:57 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id l12so6382483ioc.10 for ; Sat, 10 Mar 2018 04:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=pyJYOTbrVp5awz8qGGtRZfOZGeieGdZcotCm48LdxdA=; b=jmYTEW3MbozdFSyzlNib6A7AYCRRuaFsX4UIKbdlf85vG582fyEMFDkOyLVMl7dxPL 4xM80NNZxMt1121xbsgDLAaH4AXcP+5hGPin/BuiffvDeG6aRt9SgYhZFLXN3bJIeCee dds6di69xDoBTrZvbSadFa9g+fCVnl3MZCiXTMRAc6vo6hB0rqhVvePUI9I37dKZhiQg rGNgAepWn5mu9m4qWM0Aasac2TW2eqBwM5WRG7kEXbf/gnKW98Qkdaj/dJ9kW2urGNV9 7h5arFR/MpLb0phGO2tLjftIjIZUwd/Tlrl6qqvusEcCeKxgTwOtzdLEfHsibMkPK4d+ CmSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=pyJYOTbrVp5awz8qGGtRZfOZGeieGdZcotCm48LdxdA=; b=CaOz2jbj6PM0bAiiDnkBUiGgfdd5eijRSWd3ZXIxQ78H3Mwb0QDXMGuLfUkVKK3QkE DNyIcIBj1Dz12oAnHUHkxYlOQwofNJsT1EoWsK3ohqXyuhQNW1aIaoFgNJYynbOpUUZq /TWVHlSpofP7iND+YpA3iMe5o6pmzSBKW/+O1Yhb8k3fyLr9YPdjG1Mcp8YlWUyyl7c7 DoPv6tdPp5fH/CHq+rS9j7CQJ6iJAEdTPA6G8i3WacmPcO8BoE37cPNN0eQZC3rPRQJ4 RdSgLeuUCn9axjAuRukB2sCz0t4WFXpiXwqdB0Y6mZIrYQGShqyalURg2Zxk2B5EraUj AX6g== X-Gm-Message-State: AElRT7Fr3pt9C9+8sVTfdZfU7iQtAf5gVibyjJCh38J7tDieyE36b/Ws tnK5gQj3pkTgpJT+pGkTcb0oOQ== X-Google-Smtp-Source: AG47ELs6cLoB5djOskIVs8tPAT/mTbCsQxxTXK/3ZgzI4O+TqLDcUNtloSyiocw5yHcMQOQx7HAh1g== X-Received: by 10.107.175.231 with SMTP id p100mr2107136ioo.40.1520683616319; Sat, 10 Mar 2018 04:06:56 -0800 (PST) Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net. [162.229.180.77]) by smtp.gmail.com with ESMTPSA id u68sm2258272iou.0.2018.03.10.04.06.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Mar 2018 04:06:55 -0800 (PST) From: <7riw77@gmail.com> To: "'Fernando Gont'" , "'v6ops@ops.ietf.org'" References: <8cee137e-9f24-d816-2424-9fc4b7a5f35b@si6networks.com> In-Reply-To: <8cee137e-9f24-d816-2424-9fc4b7a5f35b@si6networks.com> Date: Sat, 10 Mar 2018 07:06:36 -0500 Message-ID: <017401d3b868$4a51c9e0$def55da0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKf89J30t1lrltIMxWmK1vz2+WlpqIw6JAg Content-Language: en-us Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs: ICMP considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 12:06:58 -0000 > > o Should rate limit the generation of ICMP echo and echo = responses > > by default (for instance, using a token bucket method as = described > > in [RFC4443]). The device should support the configuration of = not > > generating ICMP echo and echo response packets to prevent = topology > > discovery. >=20 > I'd s/topology discovery/node discovery/ >=20 > Me, I'd associate *Time Exceeded Message* (traceroute) with topology > discovery. Thanks for pointing this out! I think it's likely both, so I'll add time = exceeded messages to the text above. =F0=9F=98=8A Russ From nobody Sat Mar 10 04:08:25 2018 Return-Path: <7riw77@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F841271FD for ; Sat, 10 Mar 2018 04:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNPwaWFeBgso for ; Sat, 10 Mar 2018 04:08:23 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB29124217 for ; Sat, 10 Mar 2018 04:08:22 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id l12so6384434ioc.10 for ; Sat, 10 Mar 2018 04:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=leVDRQTfrOLjDiXWHZ50hwoE78LI/l3HZ9oP4XZt6hs=; b=LAsw51i5kERdK7Rys5hZEg9Iy3tS9PvJOtqjri02k3cNo0D2Q+95wSh4DI23a9G1ly BZDNZAD8P80gSiNcfz1smMEvLzvyvU5wQBpvwAyoThrem4woGLgA8tUV2hVTCpOYrpE9 qUv+ogZV19po4LqOoV5dlNnOm0hae6pys+214LPkKIUDzsmLtXMsk8PriBfstURsiejL KBdVdipyqaYYd4ZuAA8yqrgKIdC2mouwGf6TU5/OesAQi5w35SoGYIQkIh+pKzzGOdTt QKu24NXiYC5RVGV1rHBIokDN1C8JgG6rVrJ2SU5di/Ma7h0HWAdnyYVNWcAxfgW+tDXV ahTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=leVDRQTfrOLjDiXWHZ50hwoE78LI/l3HZ9oP4XZt6hs=; b=i4FCmTD1dfX2G1YdNRB31IsZNd21wGXtebygB9iinz1yW7n3PKzaZRebWgM92bBWcQ dXKovbr8yAPoAtjvbHez1P4WnlkWpclqWt/F5PsINt00k6pB1Eyl2Kw/0iCBS2+cvzN8 bE/0NGIT70w/OQZ0VRM6i7E9NTIcEiUiBzu7b1T8k781DZcO280fga23uNG5eDgtvXRA 4fhASSK7H7ITDpGiP5OEKXRIdj48cdg+qxCMrCNWQzCH0+IOH9Wj1iLFQYqmhBXH1juN Vk48J+fi6WSL7ZdJrFngC+OiWwp98F9ynjkOEAOyxKa1Ytp8VpW9HRBq+RuOnS7bzR4K QXLA== X-Gm-Message-State: AElRT7ENhcHGawV5eX8yUJYNUYMYGzWS1pdd6ZH+2XOKXQqqQPXotUX3 yx94uAqX95ay707HUogyMOQa3A== X-Google-Smtp-Source: AG47ELtiSoVOb4c/gRcl5k4F/khlqjA52fjlK1r7m10LOOcuBiJDOm3vZa9n34XqdlIhyuVi6SrLRw== X-Received: by 10.107.198.151 with SMTP id w145mr1892761iof.255.1520683702235; Sat, 10 Mar 2018 04:08:22 -0800 (PST) Received: from Russ ([2600:1700:720:1050:153d:411e:bd7c:8be7]) by smtp.gmail.com with ESMTPSA id 69sm2156339iol.59.2018.03.10.04.08.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Mar 2018 04:08:21 -0800 (PST) From: <7riw77@gmail.com> To: "'Templin, Fred L'" , References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> Date: Sat, 10 Mar 2018 07:08:23 -0500 Message-ID: <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIDRCcMhEyMSuhJ480FFwk6dJsgYQGzXGMOo1yttjA= Content-Language: en-us Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 12:08:24 -0000 > Please review and comment on the latest draft version (below). Would = like to > see support for this as a working group item, as it provides value to = the > community. I support this as a WG draft. =F0=9F=98=8A Russ From nobody Sat Mar 10 11:44:18 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3201270A7 for ; Sat, 10 Mar 2018 11:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxy-R5Xchi-S for ; Sat, 10 Mar 2018 11:44:15 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B0E124239 for ; Sat, 10 Mar 2018 11:44:15 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id a15so528816pgn.5 for ; Sat, 10 Mar 2018 11:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BD87o4cbUaqjSZsJZpYb29XCJHtAGq9403wf3pLzUPM=; b=ltiDbD1oFBI/StnAlvGyP+Bv6gQDzdfb3WvMkom0PMU6GpDLJnzxki3osm00SU1zjn kTi+w6MxMPF2pnHbYbzG7T5MeJW0UMx4vJJ6geKtGk8Jgp57EfC7bA5d5RwysGELJQNg 6jYIMelmK6WgXIZaAHOZs+SHn6wbOGXNJHKWrt29bBeM5imOY15M8rjuOVtaxSc5r6PM eVi4HS08LDdytEHD9m+WUSLtup7BLl8oRDR+st21u49CPExsWwb5QrSdPvmoatWIQ/IK umpG9aC9t+CT5eeH+xu5ehCG032DgloUxIvkikYsozljQ1ELacGNUH55Sy4w2VS5o5Oc hGEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:subject:to:references:cc:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BD87o4cbUaqjSZsJZpYb29XCJHtAGq9403wf3pLzUPM=; b=eodUBnJwMRBcuucWiI3l4c0lKnpy2SzKl8HWXWDPYVgwZm55eoX2Z0dxhcBSuo44ec qTknaOfKKaWKUZY2h4OBqNV/tcHY/h1tUduGKFz9YkZWOSR1t3yQPahps3Cn7SIvqQxj 4OlmDh3owKRjhczcPuUuTwRg8c99EcIvWceW/hbGaTvNS/QM81QO0uiVsHPgMnwIDdjV 6vy2VoSBAsrK5fGR89WZAvewk9TqAQlvT+JpQu8zA9g7ibxqsHvs9xWIeiVQ/PgaduQ5 gabvWsDJK/ye0oFeJSjMwSZ4+crDvos6nFvBcC6oT1pd9p+QltUl8OSuA8UvTNSitOFn o6Zg== X-Gm-Message-State: AElRT7FaeBw1er6QWM6X7hY6c/0W57JuavMvGQVogFTICOSqAkUiF0rg c/7qzELpp8A13OzpMsSQVpdT7ZK0 X-Google-Smtp-Source: AG47ELtk73sk0kwIK2o3/nodEmqRmxsm/oKPXgBYu5yHDJdoJiXXCE9EylBT8KAGugGIFNvRmsFcuQ== X-Received: by 10.98.189.24 with SMTP id a24mr2831025pff.125.1520711054955; Sat, 10 Mar 2018 11:44:14 -0800 (PST) Received: from [192.168.178.30] ([118.148.72.177]) by smtp.gmail.com with ESMTPSA id m12sm7128360pgr.35.2018.03.10.11.44.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Mar 2018 11:44:13 -0800 (PST) Sender: Brian Carpenter From: Brian E Carpenter To: JORDI PALET MARTINEZ References: <152027294685.14511.12101390842726850001@ietfa.amsl.com> Cc: IPv6 Operations Message-ID: Date: Sun, 11 Mar 2018 08:44:08 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152027294685.14511.12101390842726850001@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-p2p-links-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 19:44:17 -0000 Hi Jordi, This is useful, I think. A couple of quick comments: I think you should refer to RFC7608, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, which makes it clear that *any* prefix length is valid. Also split the references into Informational and Normative. For example RFC3627 is definitely not normative! About ULAs: 1) link-locals in ICMP message are equally bad and are sometimes seen in the wild. That should be mentioned, I think. 2) isn't it OK to use a ULA (or link-local) on a particular link if and only if you program the router to use a GUA in ICMP messages? In other words the rule is not: don't use ULA or link-local. It's actually: do give the router at least one GUA and use that GUA in ICMP messages. Regards Brian On 06/03/2018 07:02, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Point-to-Point Links > Author : Jordi Palet Martinez > Filename : draft-palet-v6ops-p2p-links-00.txt > Pages : 10 > Date : 2018-03-05 > > Abstract: > This document describes different alternatives for configuring IPv6 > point-to-point links, considering the prefix size, numbering choices > and prefix pool to be used. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-links/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-palet-v6ops-p2p-links-00 > https://datatracker.ietf.org/doc/html/draft-palet-v6ops-p2p-links-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Sat Mar 10 13:32:40 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8F1274D2 for ; Sat, 10 Mar 2018 13:32:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tzbldz9ReC3V for ; Sat, 10 Mar 2018 13:32:36 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA291270FC for ; Sat, 10 Mar 2018 13:32:36 -0800 (PST) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id CB8DB2D5064; Sat, 10 Mar 2018 21:32:31 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E7FFA2023DB4B5; Sat, 10 Mar 2018 22:32:29 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_810ECC1E-F47A-4133-AA32-9EA3414507D8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 10 Mar 2018 22:32:28 +0100 In-Reply-To: Cc: JORDI PALET MARTINEZ , IPv6 Operations To: Brian E Carpenter References: <152027294685.14511.12101390842726850001@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-p2p-links-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 21:32:38 -0000 --Apple-Mail=_810ECC1E-F47A-4133-AA32-9EA3414507D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I think you should refer to RFC7608, "IPv6 Prefix Length = Recommendation for Forwarding", BCP 198, which makes it clear that *any* = prefix length is valid. >=20 > Also split the references into Informational and Normative. For = example RFC3627 is definitely not normative! >=20 > About ULAs: > 1) link-locals in ICMP message are equally bad and are sometimes seen = in the wild. That should be mentioned, I think. > 2) isn't it OK to use a ULA (or link-local) on a particular link if = and only if you program the router to use a GUA in ICMP messages? In = other words the rule is not: don't use ULA or link-local. It's actually: = do give the router at least one GUA and use that GUA in ICMP messages. That's not the rule. The rule is stated in RFC4443, section 2.2. Ole --Apple-Mail=_810ECC1E-F47A-4133-AA32-9EA3414507D8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlqkTuwACgkQvtpYqJhC 33YTAQ/+PvaqCZD78GkVsKBj7OK4MvXtaZhPLDSHNL0lDYcEVD9lpayLQMIxu76i toPFDWADR4IsZcLxq5Y7yw+O7Ik2M+qvNk+r7TS4O21t0wVeD3qK7lCwlEkyGhVj Rw4w43oXbfcL/TFHKls0xGXM4jsOwcVNYjF8w1k10KAFYYZ7sVaCzEOX9elQpZin 4ACD/P+qNJ7mfXmHn0JewDLMpTycB/ZySaH1/k5mQbGZvKC1RPSRuoUybwfUUjVr v3iTzYOoVbdQLJuyPYcq+ouuvzwzPrH7xJFoCK+iYLWmYUTsqGBdUDHD71cZApiN K+GKFh9SYxZrHhSO24xtk213YWO9bF/W9DLrnZWrx8agkMXo/v0L90WHrGwmFrgr jelwRtRB40lNb/KY6wequ4Lxph5Dv50ryBOYPm5vRres8kqW942u1avFu12YgDRA sAykS9rME9c7Yc+0P4OhJVWxu2IN0OrDJ3s89swcYYQ5bvlhSvKcfCWd/7Nv6Sh5 6dCzR/DxFeYb92KKUgM4O/YXelO+aWn9ChUCYJJ6c2xhX1txq9CoJNx0u3lw1wxR Jw0YJkhwzmNyfpoCAKR2d0oUbsYyamfrA94Uep9/4KRxwk7HNyNH7l1c6wzEHnfk FmgeY857lBSi1IO9eCWVn4Dbu8NT8sQFVZIeUnMW6KYYNlUvpTg= =fM5f -----END PGP SIGNATURE----- --Apple-Mail=_810ECC1E-F47A-4133-AA32-9EA3414507D8-- From nobody Sat Mar 10 15:01:39 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBE01242F7 for ; Sat, 10 Mar 2018 15:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvEVPt0ZUPAL for ; Sat, 10 Mar 2018 15:01:36 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 851E2120047 for ; Sat, 10 Mar 2018 15:01:36 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id x1so2771758pfh.7 for ; Sat, 10 Mar 2018 15:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=a1JEhVrCmMKW3g1pIIxfdCnfX5ZWkAQCTTORQEEv2I0=; b=uSnWuqjYmy7zUhCPwB5HiGM0c17qJ4RRC9VrsKiGAFh9b+BT+tjpjYQSgt9vBRavHL y6qAUBbPV4X8YY73B7sb/RYRaBNmW4fkMnZkP4FOTyPI+nGrBz5d32t0YwNX0YdUYGwF ZOLSPYq6mVAqKJwKMvlQ/N9cyaRTOMQhiC/wkLINrUq3N72/r2Dr+2Ov8u3QwGHZQ7Vo ClC7K/W5CTdnhzyjiFKcrIWdBqDGXlTgjqHCdXGcgshtAk3sAhPLDZfT0Uvr/9kjaUFd Qo6TiWvajhS5S9M4LM2vqCy44XDIptiGSG4QlIeztH4ruVDXseEcvzlM3tbtuPxhPJIN 2LWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=a1JEhVrCmMKW3g1pIIxfdCnfX5ZWkAQCTTORQEEv2I0=; b=Q1MwpwohvY6aG7c1V0maq1CZA0Nkq9u6WmzLlRfAnEj+3RKxGvfKtXIsN5e+pWyHyg E//8aY33kmRkoa87UqbJwdSfObCphFPBqYjOBJbYv9sEMURrsc+1+SARIGqAAFw68ZDa AYjOXL9bKJf3uwqxSK1FBXdqHckrFEliKJ1BzdJslzjR+8SLbX0XRLKzDw8dNEaugT7f Tc0yAsX6JFz8NPXPyGXxH7KNEXSB7Dyjw3KkdEuJQoOSh/pwz2p940ZpCY2pem9CYL57 oRkkofy1WXlVPXbcnqLNRUYOmnZqTgerBIe/P8ymOUZUTpkhV2GHxSw438mz4p6juk8b lRhQ== X-Gm-Message-State: AElRT7ENBfdichNnc1eeN8+0cq8kg4i3kvI+Xl6ATwl/cMor39/kNdSj WZZilVLtnmfgmijpAbLNTNEUb+f4 X-Google-Smtp-Source: AG47ELtCbUUxX9ZcrSVoJRIacuK2wSJjsuxOU7S4pGp45PycEaKqHW93k8vuHXXBzdq445w1e+AAkw== X-Received: by 10.99.190.68 with SMTP id g4mr2625417pgo.143.1520722895878; Sat, 10 Mar 2018 15:01:35 -0800 (PST) Received: from [192.168.178.30] ([118.148.72.177]) by smtp.gmail.com with ESMTPSA id s68sm7817580pgb.43.2018.03.10.15.01.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Mar 2018 15:01:34 -0800 (PST) Sender: Brian Carpenter To: Ole Troan Cc: JORDI PALET MARTINEZ , IPv6 Operations References: <152027294685.14511.12101390842726850001@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <68f08ca9-db92-94fc-670c-98708a02ae64@gmail.com> Date: Sun, 11 Mar 2018 12:01:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-p2p-links-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2018 23:01:38 -0000 On 11/03/2018 10:32, Ole Troan wrote: >> I think you should refer to RFC7608, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, which makes it clear that *any* prefix length is valid. >> >> Also split the references into Informational and Normative. For example RFC3627 is definitely not normative! >> >> About ULAs: >> 1) link-locals in ICMP message are equally bad and are sometimes seen in the wild. That should be mentioned, I think. >> 2) isn't it OK to use a ULA (or link-local) on a particular link if and only if you program the router to use a GUA in ICMP messages? In other words the rule is not: don't use ULA or link-local. It's actually: do give the router at least one GUA and use that GUA in ICMP messages. > > That's not the rule. The rule is stated in RFC4443, section 2.2. Thanks. It would be good to add a reference. The operative phrase in 4443 seems to be this: "However, it MAY be selected in an alternative way if this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet." What I think the current draft should do is specify how to apply that option, if the RFC4443 rule leads to using a link-local source. This isn't exactly a new discussion: https://www.ietf.org/mail-archive/web/ipv6/current/msg13393.html The issue is mentioned in RFC7404 section 2.1. RFC7404 asserts this: "[RFC6724] recommends that IPv6 addresses that are greater than link- local scope be used as the source IPv6 address for all generated ICMPv6 messages sent to a non-link-local address, with the exception of ICMPv6 redirect messages." I can't find any such statement in RFC6724. Brian From nobody Sun Mar 11 01:22:29 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B5B126D05 for ; Sun, 11 Mar 2018 01:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rbhuH3cqqIh for ; Sun, 11 Mar 2018 01:22:25 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F34124B0A for ; Sun, 11 Mar 2018 01:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1520760142; x=1521364942; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=yDTo0hhu QUpKNhoefHNlFvBtyhNnQywpwuzwX2TPP4I=; b=Hd4zJGJo7aqOUWK80fwQ34Qj GsVgJ0ogurIdA0TN2OaOB6bc9XF26eNQW8Sy2jx4QD5qnJMj710Ee55waWQuQu8b Vu1UcqALjO2fp0l77lehe5IRs3bJn351KIhvg9KUaIlkeBMnQRxYLPcOF4vVv5uL VxK82yz5xM8Hz735fS4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 11 Mar 2018 10:22:22 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 11 Mar 2018 10:22:22 +0100 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005721920.msg for ; Sun, 11 Mar 2018 10:22:21 +0100 X-MDRemoteIP: 2001:470:1f09:495:a429:4af6:da27:11ce X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sun, 11 Mar 2018 10:22:21 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1608b02863=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.a.0.180210 Date: Sun, 11 Mar 2018 10:22:16 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <68D92685-CE2E-461B-8ABF-6ACCF8D465E5@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-p2p-links-00.txt References: <152027294685.14511.12101390842726850001@ietfa.amsl.com> <68f08ca9-db92-94fc-670c-98708a02ae64@gmail.com> In-Reply-To: <68f08ca9-db92-94fc-670c-98708a02ae64@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-p2p-links-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2018 09:22:27 -0000 Hi Brian, Ole, Thanks a lot for your inputs, very useful. I'm already editing a v-01 and w= ill incorporate them. Regarding Ole suggestions, I think this text can fix it: 3.2. ULA (Unique Local Addresses) Some networks use ULAs for numbering the point-to-point links. This approach may cause numerous problems and therefore is strongly discouraged. For example, if the CE needs to send an ICMPv6 message to a host outside that network (to the Internet), the packet with ULA source address will not get thru and PMTUD will break, which in turn will completely break that IPv6 connection when the MTU is not the same for all the path. However, this approach is valid if, following section 2.2 of RFC4443,=20 and despite using ULA for the point-to-point link, the router is=20 configured with at least one GUA and the source of the ICMPv6=20 message is always a GUA. I'm going to use also a similar text for the unnumbered (link-local) sectio= n 3.3. What do you think? Saludos, Jordi =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Fecha: domingo, 11 de marzo de 2018, 0:02 Para: Ole Troan CC: JORDI PALET MARTINEZ , IPv6 Operations = Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-p2p-links-00.txt On 11/03/2018 10:32, Ole Troan wrote: >> I think you should refer to RFC7608, "IPv6 Prefix Length Recommendat= ion for Forwarding", BCP 198, which makes it clear that *any* prefix length= is valid. >> >> Also split the references into Informational and Normative. For exam= ple RFC3627 is definitely not normative! >> >> About ULAs: >> 1) link-locals in ICMP message are equally bad and are sometimes see= n in the wild. That should be mentioned, I think. >> 2) isn't it OK to use a ULA (or link-local) on a particular link if = and only if you program the router to use a GUA in ICMP messages? In other = words the rule is not: don't use ULA or link-local. It's actually: do give = the router at least one GUA and use that GUA in ICMP messages. >=20 > That's not the rule. The rule is stated in RFC4443, section 2.2. =20 Thanks. It would be good to add a reference. The operative phrase in 44= 43 seems to be this: "However, it MAY be selected in an alternative way if= this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet." What I think the current draft shoul= d do is specify how to apply that option, if the RFC4443 rule leads to using a link-local source. =20 This isn't exactly a new discussion: https://www.ietf.org/mail-archive/web/ipv6/current/msg13393.html The issue is mentioned in RFC7404 section 2.1. =20 RFC7404 asserts this: "[RFC6724] recommends that IPv6 addresses that are greater than link- local scope be used as the source IPv6 address for all generated ICMPv6 messages sent to a non-link-local address, with the exception of ICMPv6 redirect messages." I can't find any such statement in RFC6724. =20 Brian =20 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Mar 13 08:16:07 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D23124B0A for ; Tue, 13 Mar 2018 08:16:05 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxKJv4vDmgU8 for ; Tue, 13 Mar 2018 08:16:04 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 2600D1252BA for ; Tue, 13 Mar 2018 08:16:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w2DFG2Y1037979; Tue, 13 Mar 2018 08:16:03 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w2DFFqeq037813 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Mar 2018 08:15:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 13 Mar 2018 08:15:51 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Tue, 13 Mar 2018 08:15:51 -0700 From: "Templin, Fred L" To: "7riw77@gmail.com" <7riw77@gmail.com>, "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN5HTyrRmwjS1ZdShWOMaQopwcupAxYoANQA4rzf4AAjG8ZoA== Date: Tue, 13 Mar 2018 15:15:51 +0000 Message-ID: <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> In-Reply-To: <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.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] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 15:16:06 -0000 VGhhbmtzIFJ1c3MsDQoNCk90aGVycyBoYXZlIGFsc28gZXhwcmVzc2VkIHRoZWlyIHN1cHBvcnQg aW4gZWFybGllciBwb3N0czoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi92Nm9wcy9jdXJyZW50L21zZzI4NjYzLmh0bWwNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvdjZvcHMvY3VycmVudC9tc2cyODY3NS5odG1sDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjg3NDYuaHRtbA0KDQpUaGVy ZSB3YXMgYWxzbyBxdWl0ZSBhIGJpdCBvZiBsaXN0IGRpc2N1c3Npb24gYWJvdXQgaXQgYmFjayBp biB0aGUgTm92LURlYw0KdGltZWZyYW1lIHNpbmNlIElFVEYxMDAuDQoNCkZyZWQNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IDdyaXc3N0BnbWFpbC5jb20gW21haWx0 bzo3cml3NzdAZ21haWwuY29tXQ0KPiBTZW50OiBTYXR1cmRheSwgTWFyY2ggMTAsIDIwMTggNDow OCBBTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsg djZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12Nm9w cy1wZGhvc3QgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Pw0KPiANCj4gDQo+ID4gUGxlYXNlIHJldmll dyBhbmQgY29tbWVudCBvbiB0aGUgbGF0ZXN0IGRyYWZ0IHZlcnNpb24gKGJlbG93KS4gV291bGQg bGlrZSB0bw0KPiA+IHNlZSBzdXBwb3J0IGZvciB0aGlzIGFzIGEgd29ya2luZyBncm91cCBpdGVt LCBhcyBpdCBwcm92aWRlcyB2YWx1ZSB0byB0aGUNCj4gPiBjb21tdW5pdHkuDQo+IA0KPiBJIHN1 cHBvcnQgdGhpcyBhcyBhIFdHIGRyYWZ0Lg0KPiANCj4g8J+Yig0KPiANCj4gUnVzcw0KPiANCg0K From nobody Wed Mar 14 10:23:51 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF040120047 for ; Wed, 14 Mar 2018 10:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82EQof57RMDN for ; Wed, 14 Mar 2018 10:23:49 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 59207120227 for ; Wed, 14 Mar 2018 10:23:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w2EHNlYD004413; Wed, 14 Mar 2018 10:23:48 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w2EHNcSe004298 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Wed, 14 Mar 2018 10:23:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 14 Mar 2018 10:23:38 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Wed, 14 Mar 2018 10:23:38 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN5HTyrRmwjS1ZdShWOMaQopwcupAxYoANQA4rzf4AAjG8ZoAA26csA Date: Wed, 14 Mar 2018 17:23:38 +0000 Message-ID: References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.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] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2018 17:23:51 -0000 VG8gYWRkIHRvIHdoYXQgSSBzYWlkIHllc3RlcmRheSwgdG8gbXkgdW5kZXJzdGFuZGluZyB0aGlz IHF1YWxpZmllcyB0aGUNCndvcmsgdG8gYmUgYWRkZWQgdG8gdGhlIElFVEYxMDEgYWdlbmRhLiBQ bGVhc2UgY29uZmlybS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2 Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZW1wbGlu LCBGcmVkIEwNCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTggODoxNiBBTQ0KPiBUbzog N3Jpdzc3QGdtYWlsLmNvbTsgdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10g ZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Pw0KPiANCj4g VGhhbmtzIFJ1c3MsDQo+IA0KPiBPdGhlcnMgaGF2ZSBhbHNvIGV4cHJlc3NlZCB0aGVpciBzdXBw b3J0IGluIGVhcmxpZXIgcG9zdHM6DQo+IA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjg2NjMuaHRtbA0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjg2NzUuaHRtbA0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjg3NDYu aHRtbA0KPiANCj4gVGhlcmUgd2FzIGFsc28gcXVpdGUgYSBiaXQgb2YgbGlzdCBkaXNjdXNzaW9u IGFib3V0IGl0IGJhY2sgaW4gdGhlIE5vdi1EZWMNCj4gdGltZWZyYW1lIHNpbmNlIElFVEYxMDAu DQo+IA0KPiBGcmVkDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ IEZyb206IDdyaXc3N0BnbWFpbC5jb20gW21haWx0bzo3cml3NzdAZ21haWwuY29tXQ0KPiA+IFNl bnQ6IFNhdHVyZGF5LCBNYXJjaCAxMCwgMjAxOCA0OjA4IEFNDQo+ID4gVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IHY2b3BzQGlldGYub3JnDQo+ID4gU3Vi amVjdDogUkU6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QgYSB3b3JraW5nIGdy b3VwIGRyYWZ0Pw0KPiA+DQo+ID4NCj4gPiA+IFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24g dGhlIGxhdGVzdCBkcmFmdCB2ZXJzaW9uIChiZWxvdykuIFdvdWxkIGxpa2UgdG8NCj4gPiA+IHNl ZSBzdXBwb3J0IGZvciB0aGlzIGFzIGEgd29ya2luZyBncm91cCBpdGVtLCBhcyBpdCBwcm92aWRl cyB2YWx1ZSB0byB0aGUNCj4gPiA+IGNvbW11bml0eS4NCj4gPg0KPiA+IEkgc3VwcG9ydCB0aGlz IGFzIGEgV0cgZHJhZnQuDQo+ID4NCj4gPiDwn5iKDQo+ID4NCj4gPiBSdXNzDQo+ID4NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3Bz IG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Wed Mar 14 22:23:54 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB2F124319; Wed, 14 Mar 2018 22:23:53 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SsMq1bADedL; Wed, 14 Mar 2018 22:23:52 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 2DAC61200A0; Wed, 14 Mar 2018 22:23:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w2F5NpaP053242; Wed, 14 Mar 2018 22:23:51 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w2F5Nn9p053222 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Mar 2018 22:23:50 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 14 Mar 2018 22:23:49 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Wed, 14 Mar 2018 22:23:49 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN5HTyrRmwjS1ZdShWOMaQopwcupAxYoANQA4rzf4AAjG8ZoAA26csAABkP6uA= Date: Thu, 15 Mar 2018 05:23:49 +0000 Message-ID: <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.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] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 05:23:53 -0000 djZvcHMgY2hhaXJzLA0KDQpNeSB1bmRlcnN0YW5kaW5nIGZyb20gd2hhdCBJIGhhdmUgYmVlbiB0 b2xkIGluIHRoZSBwYXN0IGlzIHRoYXQsIGluIG9yZGVyDQp0byBnZXQgYSBtZWV0aW5nIGFnZW5k YSBzbG90IGZvciBhIGRvY3VtZW50LCB0aGVyZSBuZWVkcyB0byBiZSBkaXNjdXNzaW9uDQpvbiB0 aGUgbGlzdCBhbmQgcGVvcGxlIGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24uIFRoaXMg ZG9jdW1lbnQNCmhhcyBzZWVuIGJvdGggb2YgdGhvc2UsIHNvIHBsZWFzZSBhZGQgJ2RyYWZ0LXRl bXBsaW4tdjZvcHMtcGRob3N0JyB0bw0KdGhlIGFnZW5kYSAtIDEwbWlucyBzaG91bGQgYmUgZmlu ZS4NCg0KVGhhbmtzIC0gRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRl bXBsaW4sIEZyZWQgTA0KPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDE0LCAyMDE4IDEwOjI0IEFN DQo+IFRvOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC10ZW1w bGluLXY2b3BzLXBkaG9zdCBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQ/DQo+IA0KPiBUbyBhZGQgdG8g d2hhdCBJIHNhaWQgeWVzdGVyZGF5LCB0byBteSB1bmRlcnN0YW5kaW5nIHRoaXMgcXVhbGlmaWVz IHRoZQ0KPiB3b3JrIHRvIGJlIGFkZGVkIHRvIHRoZSBJRVRGMTAxIGFnZW5kYS4gUGxlYXNlIGNv bmZpcm0uDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiwg RnJlZCBMDQo+ID4gU2VudDogVHVlc2RheSwgTWFyY2ggMTMsIDIwMTggODoxNiBBTQ0KPiA+IFRv OiA3cml3NzdAZ21haWwuY29tOyB2Nm9wc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbdjZv cHNdIGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0IGEgd29ya2luZyBncm91cCBkcmFmdD8NCj4g Pg0KPiA+IFRoYW5rcyBSdXNzLA0KPiA+DQo+ID4gT3RoZXJzIGhhdmUgYWxzbyBleHByZXNzZWQg dGhlaXIgc3VwcG9ydCBpbiBlYXJsaWVyIHBvc3RzOg0KPiA+DQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9wcy9jdXJyZW50L21zZzI4NjYzLmh0bWwNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjg2 NzUuaHRtbA0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdjZvcHMv Y3VycmVudC9tc2cyODc0Ni5odG1sDQo+ID4NCj4gPiBUaGVyZSB3YXMgYWxzbyBxdWl0ZSBhIGJp dCBvZiBsaXN0IGRpc2N1c3Npb24gYWJvdXQgaXQgYmFjayBpbiB0aGUgTm92LURlYw0KPiA+IHRp bWVmcmFtZSBzaW5jZSBJRVRGMTAwLg0KPiA+DQo+ID4gRnJlZA0KPiA+DQo+ID4NCj4gPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiA3cml3NzdAZ21haWwuY29tIFtt YWlsdG86N3Jpdzc3QGdtYWlsLmNvbV0NCj4gPiA+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAxMCwg MjAxOCA0OjA4IEFNDQo+ID4gPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPjsgdjZvcHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbdjZvcHNdIGRy YWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0IGEgd29ya2luZyBncm91cCBkcmFmdD8NCj4gPiA+DQo+ ID4gPg0KPiA+ID4gPiBQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50IG9uIHRoZSBsYXRlc3QgZHJh ZnQgdmVyc2lvbiAoYmVsb3cpLiBXb3VsZCBsaWtlIHRvDQo+ID4gPiA+IHNlZSBzdXBwb3J0IGZv ciB0aGlzIGFzIGEgd29ya2luZyBncm91cCBpdGVtLCBhcyBpdCBwcm92aWRlcyB2YWx1ZSB0byB0 aGUNCj4gPiA+ID4gY29tbXVuaXR5Lg0KPiA+ID4NCj4gPiA+IEkgc3VwcG9ydCB0aGlzIGFzIGEg V0cgZHJhZnQuDQo+ID4gPg0KPiA+ID4g8J+Yig0KPiA+ID4NCj4gPiA+IFJ1c3MNCj4gPiA+DQo+ ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZv cHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0K From nobody Thu Mar 15 02:47:52 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF9A12D947; Thu, 15 Mar 2018 02:47:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iKX3SET98tC; Thu, 15 Mar 2018 02:47:49 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA37A12D942; Thu, 15 Mar 2018 02:47:48 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id l123so3779078vke.8; Thu, 15 Mar 2018 02:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VXWRSXNWxZSS/4kztEq+Dkt0zzFtgVbiSezXKYYS0Xc=; b=hkOMNe+Dgfh7PPlDvuMiFLBc94/a575R7SmMiTIAmL+Pz3zXPErSi8AH0yVJi/HWfL 7uRDHKDjJ+Wgt1Vg5OLX3dBLgG/7fVFDS1CYqFlWF2/dTyIzRtJfdHotVL1XFIqht06U eAQZjeiZcNoFxZJxpjDX7k9d2/8RV9tg8E67JYSrafrX5ZD+nefJmCq+z/TYrEz7pr9L xyna7/SANZPx+9bF0lzqA2sMY+fY6/vqNo17Hi4+A3IsKsNFIjw8l/mLj7DxvR54gM1m l1J8tgcANmwfpKOnZzgGyxQI+SAxwfFnY92oargHAOa4ZasOhXBs/4tJBhPIISeOp8Rq SDOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VXWRSXNWxZSS/4kztEq+Dkt0zzFtgVbiSezXKYYS0Xc=; b=LvG47HEhhIFt9V4AronniZFYadLkIEMKqoBfSjcR1T/mNniVnEGadk+vkR9BX87Wso ypkzBuBuqaxJVu6yCOwZenRf+5ldrUZ3ogy4DRKfYwZZgJQjvJZdqMh1lmaN/zkdxZap Kmk48fOgqv+DpQUbhp+3TWGVbxQR4UjYEXZhH7kP5hkJbdK1DN3nrUUQJME7EORwde+v +fDSvM4jlH+gwUEkyACSZL8D58iRYs6wr97pTd3CZ47rAHTyZq7+rxezdf/zQjzMb3G7 zKN7kyh1ZJLFHKwtRufWb22Bb15EwxbTTk6qsYGUDho7C7+iI7nPXjdHvNnvrjawycMu LuTQ== X-Gm-Message-State: AElRT7FMo1bzm+epfwXDjQLQjwjsVgyjYKlgVGKCalCpmlBhITv75qgK 5ho+lvFyDaPHh22iZPfQQL8= X-Google-Smtp-Source: AG47ELuEjeGrD/CPcLLSe2n+jTLpfZcb000AL3bgyDl2QbHur4Yc3+Eg14K4yxitKn32kXPR82avwA== X-Received: by 10.31.108.87 with SMTP id h84mr2808530vkc.166.1521107267789; Thu, 15 Mar 2018 02:47:47 -0700 (PDT) Received: from [172.20.7.214] ([67.203.214.34]) by smtp.gmail.com with ESMTPSA id y50sm1589315uay.19.2018.03.15.02.47.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 02:47:46 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5BA61AC6-AB84-4864-BC9A-8A6BBB08BE08"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 15 Mar 2018 05:47:44 -0400 In-Reply-To: <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> Cc: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" To: Fred Templin References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 09:47:51 -0000 --Apple-Mail=_5BA61AC6-AB84-4864-BC9A-8A6BBB08BE08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 15, 2018, at 1:23 AM, Templin, Fred L = wrote: >=20 > v6ops chairs, >=20 > My understanding from what I have been told in the past is that, in = order > to get a meeting agenda slot for a document, there needs to be = discussion > on the list and people expressing support for adoption. This document > has seen both of those, so please add 'draft-templin-v6ops-pdhost' to > the agenda - 10mins should be fine. >=20 > Thanks - Fred I have updated the agenda at = https://datatracker.ietf.org/meeting/101/materials/agenda-101-v6ops I would't actually agree that support for adoption is required; that = comes when we want to discuss adoption. And for adoption, on a mailing = list with 1000 people, of which 100-200 show up at meetings, four (and = with the author, five) doesn't constitute a consensus. What I have told = you is that people need to show operational interest in the draft - = "this would be useful in my environment". What the chairs are looking = for in the case of pdhost is people saying "that would be a useful model = for me to deploy in my data center or other environment". >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, = Fred L >> Sent: Wednesday, March 14, 2018 10:24 AM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group = draft? >>=20 >> To add to what I said yesterday, to my understanding this qualifies = the >> work to be added to the IETF101 agenda. Please confirm. >>=20 >>> -----Original Message----- >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, = Fred L >>> Sent: Tuesday, March 13, 2018 8:16 AM >>> To: 7riw77@gmail.com; v6ops@ietf.org >>> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group = draft? >>>=20 >>> Thanks Russ, >>>=20 >>> Others have also expressed their support in earlier posts: >>>=20 >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg28663.html >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg28675.html >>> https://www.ietf.org/mail-archive/web/v6ops/current/msg28746.html >>>=20 >>> There was also quite a bit of list discussion about it back in the = Nov-Dec >>> timeframe since IETF100. >>>=20 >>> Fred >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: 7riw77@gmail.com [mailto:7riw77@gmail.com] >>>> Sent: Saturday, March 10, 2018 4:08 AM >>>> To: Templin, Fred L ; v6ops@ietf.org >>>> Subject: RE: [v6ops] draft-templin-v6ops-pdhost a working group = draft? >>>>=20 >>>>=20 >>>>> Please review and comment on the latest draft version (below). = Would like to >>>>> see support for this as a working group item, as it provides value = to the >>>>> community. >>>>=20 >>>> I support this as a WG draft. >>>>=20 >>>> =F0=9F=98=8A >>>>=20 >>>> Russ >>>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_5BA61AC6-AB84-4864-BC9A-8A6BBB08BE08 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlqqQUAACgkQEhdRnd2G P+B/PA/+O3jxFpJECDg/iMXmRlA8wyJ839DlcdCDd4RIX/JY6x9TxKgW0T6Of7xO Ph7yz5hHzlxgCa3CgMbGFALrK3iChOfWrZ52y2r1IThnJsvTiBtinCZ23u+Mau30 EynAMNot+kTFjnAsZhFN+NlKKhyhdaA5hiI/jADU1pGiR23ctrETnjMzUGBuoeWn n4nvCBjWUnZDqmYiGJ0DaYH1vdI99SHbte9tYxfzxvCC1E3ukKkqNO3p+WGtYuu/ 5Yob8PEUefqhQ0kLjxuWdd49AXUbVfmVaWUfhc5ru244gVZdb78BTi+sEqmbQcTa 1ulMODchoY/BaYLOfCs1DBfM0W5d0Pk2jXnzg9uqv0MYvOKq5AKqYlunQaeYn3eh 4g8UWYyRFhRXerhuy49DJmc2RkDs8DoaskZV+XZNgtZv2N0tZNZKN5RO16kUgtx7 QgERAFqeE2oHseyMI5V4CsEfEUWFc76noh5v4XDxM+nuseqLj5n6VikeQgzy6gix ZviODpC2iX9bd65CuolNg9+g62+PoX4LVSb67+m5RC51PjUNwNpgF0BX5aHsPcv8 PAfIRo4+VDwqbPfQuGXL6Xe/mx9HhhdERf5clIeZY3MMtZcYwB1geqxfTb91SOdA IxZbEqga540G23xG/jZTMFXEmMNDzQFtt35N/i56jgbJfEXjll0= =muGp -----END PGP SIGNATURE----- --Apple-Mail=_5BA61AC6-AB84-4864-BC9A-8A6BBB08BE08-- From nobody Thu Mar 15 05:44:55 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60FA1270AC for ; Thu, 15 Mar 2018 05:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7-yCbSb9h5k for ; Thu, 15 Mar 2018 05:44:52 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 C8F2E126B6E for ; Thu, 15 Mar 2018 05:44:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 53EA1AF; Thu, 15 Mar 2018 13:44:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1521117889; bh=bED5ut+Nj2bJd1/YNoUJoP15jKeXEtzJddgbpLMYzsE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ME1s4UXYmBfQU4iNMrspR2deDtdMIKp5RbkTO9t1NEAG24kyc+13zU1V90OtkGGZ3 GyKwKmLK+A+SRKB4DR4hDmqTQnwYFgtm87mhBPMGUvC4Oj0/hNKlt8CaU2p6dj9/LM Y5ZK2Ki5X2WI9iaHoEK/CXtKFfEJ9hbuRGem3HNc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 50F4B9F; Thu, 15 Mar 2018 13:44:49 +0100 (CET) Date: Thu, 15 Mar 2018 13:44:49 +0100 (CET) From: Mikael Abrahamsson To: Fred Baker cc: Fred Templin , "v6ops@ietf.org" In-Reply-To: Message-ID: References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 12:44:54 -0000 On Thu, 15 Mar 2018, Fred Baker wrote: > I would't actually agree that support for adoption is required; that > comes when we want to discuss adoption. And for adoption, on a mailing > list with 1000 people, of which 100-200 show up at meetings, four (and > with the author, five) doesn't constitute a consensus. What I have told > you is that people need to show operational interest in the draft - > "this would be useful in my environment". What the chairs are looking > for in the case of pdhost is people saying "that would be a useful model > for me to deploy in my data center or other environment". Hi, I would like to be able to delegate lots of addresses to hosts/routers, using something that has the properties of what we can currently do in RA, ie zero-lifetime things very quickly (and other aspects). I agree with Fred in that there is a need to do what he wants to do. I might not agree in the exact details in his proposals, but I believe we should work on this problem, either here or in 6man. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 15 06:03:03 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18AB1270AC for ; Thu, 15 Mar 2018 06:03:01 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzDd0PUPYXGn for ; Thu, 15 Mar 2018 06:02:59 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627EB126B6E for ; Thu, 15 Mar 2018 06:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1521118976; x=1521723776; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=Rsprv5SR KhQgwTjpK8j6/nuuFmwtDs9MgPUES0BNOw4=; b=JtT2Eh/R7Hc6S+PostmfUQPi qmOPYQw7QuWG5rLg2M2PsvWoOzfDNV2cJBma4tqfvubtiofMruQIkNMyEGELCsk1 Dfn35OYy2gDVmLgjHKp3w4Ss6xunRPbGqN0HYh1Sgyq5ePlXvqI6uPS9aV6QNPvj S61IVK1yQFq064KKJMk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 15 Mar 2018 14:02:56 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 15 Mar 2018 14:02:56 +0100 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005724974.msg for ; Thu, 15 Mar 2018 14:02:55 +0100 X-MDRemoteIP: 2001:470:1f09:495:40a8:74b:821a:cf35 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 15 Mar 2018 14:02:55 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=161253f764=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.b.0.180311 Date: Thu, 15 Mar 2018 14:02:53 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <4C79EA07-58F6-46E8-939E-C80BF5BDE7D2@consulintel.es> Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 13:03:02 -0000 +1 Saludos, Jordi =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Fecha: jueves, 15 de marzo de 2018, 13:45 Para: Fred Baker CC: "v6ops@ietf.org" Asunto: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? On Thu, 15 Mar 2018, Fred Baker wrote: =20 > I would't actually agree that support for adoption is required; that= =20 > comes when we want to discuss adoption. And for adoption, on a mailin= g=20 > list with 1000 people, of which 100-200 show up at meetings, four (an= d=20 > with the author, five) doesn't constitute a consensus. What I have to= ld=20 > you is that people need to show operational interest in the draft -= =20 > "this would be useful in my environment". What the chairs are looking= =20 > for in the case of pdhost is people saying "that would be a useful mo= del=20 > for me to deploy in my data center or other environment". =20 Hi, =20 I would like to be able to delegate lots of addresses to hosts/routers,= =20 using something that has the properties of what we can currently do in = RA,=20 ie zero-lifetime things very quickly (and other aspects). I agree with= =20 Fred in that there is a need to do what he wants to do. =20 I might not agree in the exact details in his proposals, but I believe = we=20 should work on this problem, either here or in 6man. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Mar 15 07:31:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CAF12D88F for ; Thu, 15 Mar 2018 07:31:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTzfdkYyKKVg for ; Thu, 15 Mar 2018 07:31:46 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDF712D88A for ; Thu, 15 Mar 2018 07:31:46 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D6B2D2D50C6; Thu, 15 Mar 2018 14:31:43 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 75C3A202541E5B; Thu, 15 Mar 2018 15:31:41 +0100 (CET) From: Ole Troan Message-Id: <74CF8FA4-146F-4E27-9407-0907E8C2D27F@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_157E6B4D-775D-44EC-820D-033EB6EB041C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Mar 2018 15:31:40 +0100 In-Reply-To: Cc: Fred Baker , "v6ops@ietf.org" To: Mikael Abrahamsson References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 14:31:48 -0000 --Apple-Mail=_157E6B4D-775D-44EC-820D-033EB6EB041C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mikael, > I would like to be able to delegate lots of addresses to = hosts/routers, using something that has the properties of what we can = currently do in RA, ie zero-lifetime things very quickly (and other = aspects). I agree with Fred in that there is a need to do what he wants = to do. >=20 Could you elaborate on the requirements, so that we can understand what = is missing in the existing mechanisms? Ole --Apple-Mail=_157E6B4D-775D-44EC-820D-033EB6EB041C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlqqg8wACgkQvtpYqJhC 33YM5xAAjftEdaKzLMBTdY1CcGoDh7dyOaHD2N841yoymCl0Ufwxbaaxsg9nVhhz bGTZ6ajsZaH4sFLgy6JynDdBu4OmSuWMlCPDq4j3lVdoHUKrGAfp0i93G+mbpTZN AfVrMHcD55EOla2BBImlM52CvWLvOUy3X+zPLUENpAfGhsBPbuUTRC53kZzOVQkb lnl9xVd1e1ptVbKmUN9W1/XuGx06qh/0fltDqAOxI7c4ikjdC/Sx5DTFUL+3v2rh FR2iyq23+cwgHAahVSH1Q6L/t8aJhKdFJQ+TcSwCza7TYL23uWEldh31fbZZD2I1 po3loLxHaC/2RfxVEwmXWZOZWgHVh/gcnbSs69U8PlxFoqmNEP1bVBKSZe7Om4Qf UBuujZQeNAUB9a65Es3DD1VIM8ZS0baLPabigTFozd4Cf51xr4H2Y7saE+u8UafJ amprI6drae9rmURvYBT9cvzHO+5omGGXSZONLw59cxhVun50EyBVoq5w7+corO4l txZFYOmIgPUjCDXakX1GjpatxroapC9CxyrWANAKuG9CzvGe5KobC7zMFy0oBMko EXUYD2/IhVqaE/hfgE3VMnjfA6+9WCooBCwHqrScXkaH1DRXALclHUlkW+7fP8Zo UiJF4q1qlwXZtePov54Q0TO3xPIIjIv38nbRdYIHhEsAgKciqZU= =28q9 -----END PGP SIGNATURE----- --Apple-Mail=_157E6B4D-775D-44EC-820D-033EB6EB041C-- From nobody Thu Mar 15 11:10:36 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5175312D80E for ; Thu, 15 Mar 2018 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrMBkdJUzwcf for ; Thu, 15 Mar 2018 11:10:33 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 4105E12D940 for ; Thu, 15 Mar 2018 11:10:33 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 91CA0B64 for ; Thu, 15 Mar 2018 18:10:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX7EjXLskrBB for ; Thu, 15 Mar 2018 13:10:32 -0500 (CDT) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 580D484D for ; Thu, 15 Mar 2018 13:10:32 -0500 (CDT) Received: by mail-vk0-f71.google.com with SMTP id p197so4645222vkf.22 for ; Thu, 15 Mar 2018 11:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fMQS4uxUaBNwwNzWwFssC22mqRuNdSfTrSbJC/AS86o=; b=U4zUvlKXZxjHqsmSMpQGdLQH4l1YVoyYkDQfe4ObTn3TYpp843tGzMcfTF2WKtr4lF 2JSWPqYPrWFriwb5y+NKfscywVWgR/zqpKmCl7dLQpfVZ9600jJBKk+URoQSTVQfK71V N+a3Qjma24To/ME4CKm1jg/L2EuFPTCCImUHKIeo05oJJgfmyIJYucyqRRRbPYH/bNmc U05qBM7jxxMsN3ZzJzuX1KwyN8fQsG+5ceJ8kKQU94DSHG3n1gPgF1dU9hXd74pbPrcC 0D/XrX9REym7OQclzFJKx2HadnO8PKSSaUFTYY4JbNK0IaDYqcT6WmuT2beCImCIj17R TFDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fMQS4uxUaBNwwNzWwFssC22mqRuNdSfTrSbJC/AS86o=; b=VBXlHkD2BuRwitjBm8e5wRnfzQ1h6a0bwcVauoF1ysB+slv76y/8V49i7bWtUtbpJ+ R5SyKUbM5iAvJXO8LheOGVO3SVb/120pEvrAA4B5srKsGzYHRQ5OivGqWyxCYNDt1MyB EcwEnjr5yoc7Ci8GvW0pMKvqhyxzZlrpIeIJOJwx/GiLy1qp24gyB8lXAfmlSJ6TjPHQ i9EwylIf5Zbs997rwaXChiS1jMJ/FAaNkvFSgbnLr2AvAxkSU8cC/rSc6gTbopvWRW7R GIJ1zmuH6HeLqG7AdZ4kHl6wL3s794rlv6Y6eJ55Dz78kqtoiGlW86B6qN1v8ljIsWHF GgNg== X-Gm-Message-State: AElRT7FgX+P5XD6sDOZRTKA9nshoQD0G8AP7RA0lE4iZOUAzS8Z91sTW tYCExjTu+T+rGJUnFCIy7njMnrlGsTv8GhCd5+l3z8BBAxbsq/iH2DbsCqLvhgiOd1bMau+6wlU 43PoMa/S0tgUQnW1HgHXPYH2q/A== X-Received: by 10.176.78.212 with SMTP id x20mr6915482uah.194.1521137431247; Thu, 15 Mar 2018 11:10:31 -0700 (PDT) X-Google-Smtp-Source: AG47ELuGMRHYDQ5xOH5rd8Y84wKMygo5OYGOftOm69wSaH5tqPSXSexBtTIIDagLseuLc5WkBgpUP/MSBm+KESDKTYY= X-Received: by 10.176.78.212 with SMTP id x20mr6915470uah.194.1521137430944; Thu, 15 Mar 2018 11:10:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.34.132 with HTTP; Thu, 15 Mar 2018 11:10:29 -0700 (PDT) In-Reply-To: References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Thu, 15 Mar 2018 13:10:29 -0500 Message-ID: To: Fred Baker Cc: Fred Templin , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" Content-Type: multipart/alternative; boundary="f403045ee48439fae00567776819" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 18:10:35 -0000 --f403045ee48439fae00567776819 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 15, 2018 at 4:47 AM, Fred Baker wrote: > > I have updated the agenda at https://datatracker.ietf.org/ > meeting/101/materials/agenda-101-v6ops > > I would't actually agree that support for adoption is required; that comes > when we want to discuss adoption. And for adoption, on a mailing list with > 1000 people, of which 100-200 show up at meetings, four (and with the > author, five) doesn't constitute a consensus. What I have told you is that > people need to show operational interest in the draft - "this would be > useful in my environment". What the chairs are looking for in the case of > pdhost is people saying "that would be a useful model for me to deploy in > my data center or other environment". > I'll say I'm interested in the deployment model of assigning hosts whole /64 prefixes. I'm pushing my vendors (router and WiFi systems) to support RFC8273 now. I'd actaully prefer a DHCPv6-PD in the host model. However, until at least one large OS vendor includes this capability in their base software, deployment in my campus environment is pointless. So please count me as operationally interested in this model, I'm not yet ready to say this draft is the one that should carry the torch for the model, but I have a great interest in the model of DHCPv6-PD to the host. Thanks. =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045ee48439fae00567776819 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 15, 2018 at 4:47 AM, Fred Baker <fredbaker.ietf@gma= il.com> wrote:

I have updated the agenda at http= s://datatracker.ietf.org/meeting/101/materials/agenda-101-v6ops

I would't actually agree that support for adoption is required; that co= mes when we want to discuss adoption. And for adoption, on a mailing list w= ith 1000 people, of which 100-200 show up at meetings, four (and with the a= uthor, five) doesn't constitute a consensus. What I have told you is th= at people need to show operational interest in the draft - "this would= be useful in my environment". What the chairs are looking for in the = case of pdhost is people saying "that would be a useful model for me t= o deploy in my data center or other environment".


=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Network= ing & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 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
--f403045ee48439fae00567776819-- From nobody Thu Mar 15 16:31:02 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487EB127599; Thu, 15 Mar 2018 16:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_PbzUgYp9uC; Thu, 15 Mar 2018 16:30:59 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 063701275FD; Thu, 15 Mar 2018 16:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w2FNUver019995; Thu, 15 Mar 2018 16:30:57 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w2FNUrxF019987 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Mar 2018 16:30:53 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (137.136.238.222) by XCH15-06-10.nw.nos.boeing.com (137.136.239.219) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 15 Mar 2018 16:30:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Thu, 15 Mar 2018 16:30:52 -0700 From: "Templin, Fred L" To: David Farmer , Fred Baker CC: "v6ops@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdN5HTyrRmwjS1ZdShWOMaQopwcupAxYoANQA4rzf4AAjG8ZoAA26csAABkP6uAAGvCVvgAK/9VQ Date: Thu, 15 Mar 2018 23:30:52 +0000 Message-ID: References: <172cd17ae54a4adba58ffcdfb522fac5@XCH15-06-08.nw.nos.boeing.com> <1af67899f24b43fa87013c61e59f0de8@XCH15-06-08.nw.nos.boeing.com> <017501d3b868$7d9a9a70$78cfcf50$@gmail.com> <9490580a13eb497ba22c19a9e360a49b@XCH15-06-08.nw.nos.boeing.com> <4e2c097afdd34ad2a7f31cb463704a72@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_a5398270c6194456b737ca2ef44a8827XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 23:31:01 -0000 --_000_a5398270c6194456b737ca2ef44a8827XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCj4gYnV0IEkgaGF2ZSBhIGdyZWF0IGludGVyZXN0IGluIHRoZSBtb2RlbCBv ZiBESENQdjYtUEQgdG8gdGhlIGhvc3QuDQoNClRoYXQgaXMgZ29vZCB0byBrbm93LiBZb3Ugd291 bGQgcHJvYmFibHkgYmUgaW50ZXJlc3RlZCBpbiByZXZpZXdpbmcNCmFuZC9vciBleHBlcmltZW50 aW5nIHdpdGggb3VyIGNvZGU6DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvdjZvcHMvY3VycmVudC9tc2cyODg2MC5odG1sDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjkwMjQuaHRtbA0KDQpUaGFua3MgZm9yIHlv dXIgaW50ZXJlc3QsDQoNCkZyZWQNCg0KRnJvbTogRGF2aWQgRmFybWVyIFttYWlsdG86ZmFybWVy QHVtbi5lZHVdDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTUsIDIwMTggMTE6MTAgQU0NClRvOiBG cmVkIEJha2VyIDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+DQpDYzogVGVtcGxpbiwgRnJlZCBM IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgdjZvcHNAaWV0Zi5vcmc7IHY2b3BzLWNoYWly c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhv c3QgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Pw0KDQoNCg0KT24gVGh1LCBNYXIgMTUsIDIwMTggYXQg NDo0NyBBTSwgRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPG1haWx0bzpmcmVk YmFrZXIuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSSBoYXZlIHVwZGF0ZWQgdGhlIGFnZW5k YSBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAxL21hdGVyaWFscy9h Z2VuZGEtMTAxLXY2b3BzDQoNCkkgd291bGQndCBhY3R1YWxseSBhZ3JlZSB0aGF0IHN1cHBvcnQg Zm9yIGFkb3B0aW9uIGlzIHJlcXVpcmVkOyB0aGF0IGNvbWVzIHdoZW4gd2Ugd2FudCB0byBkaXNj dXNzIGFkb3B0aW9uLiBBbmQgZm9yIGFkb3B0aW9uLCBvbiBhIG1haWxpbmcgbGlzdCB3aXRoIDEw MDAgcGVvcGxlLCBvZiB3aGljaCAxMDAtMjAwIHNob3cgdXAgYXQgbWVldGluZ3MsIGZvdXIgKGFu ZCB3aXRoIHRoZSBhdXRob3IsIGZpdmUpIGRvZXNuJ3QgY29uc3RpdHV0ZSBhIGNvbnNlbnN1cy4g V2hhdCBJIGhhdmUgdG9sZCB5b3UgaXMgdGhhdCBwZW9wbGUgbmVlZCB0byBzaG93IG9wZXJhdGlv bmFsIGludGVyZXN0IGluIHRoZSBkcmFmdCAtICJ0aGlzIHdvdWxkIGJlIHVzZWZ1bCBpbiBteSBl bnZpcm9ubWVudCIuIFdoYXQgdGhlIGNoYWlycyBhcmUgbG9va2luZyBmb3IgaW4gdGhlIGNhc2Ug b2YgcGRob3N0IGlzIHBlb3BsZSBzYXlpbmcgInRoYXQgd291bGQgYmUgYSB1c2VmdWwgbW9kZWwg Zm9yIG1lIHRvIGRlcGxveSBpbiBteSBkYXRhIGNlbnRlciBvciBvdGhlciBlbnZpcm9ubWVudCIu DQoNCkknbGwgc2F5IEknbSBpbnRlcmVzdGVkIGluIHRoZSBkZXBsb3ltZW50IG1vZGVsIG9mIGFz c2lnbmluZyBob3N0cyB3aG9sZSAvNjQgcHJlZml4ZXMuIEknbSBwdXNoaW5nIG15IHZlbmRvcnMg KHJvdXRlciBhbmQgV2lGaSBzeXN0ZW1zKSB0byBzdXBwb3J0IFJGQzgyNzMgbm93LiBJJ2QgYWN0 YXVsbHkgcHJlZmVyIGEgREhDUHY2LVBEIGluIHRoZSBob3N0IG1vZGVsLiAgSG93ZXZlciwgdW50 aWwgYXQgbGVhc3Qgb25lIGxhcmdlIE9TIHZlbmRvciBpbmNsdWRlcyB0aGlzIGNhcGFiaWxpdHkg aW4gdGhlaXIgYmFzZSBzb2Z0d2FyZSwgZGVwbG95bWVudCBpbiBteSBjYW1wdXMgZW52aXJvbm1l bnQgaXMgcG9pbnRsZXNzLg0KDQpTbyBwbGVhc2UgY291bnQgbWUgYXMgb3BlcmF0aW9uYWxseSBp bnRlcmVzdGVkIGluIHRoaXMgbW9kZWwsIEknbSBub3QgeWV0IHJlYWR5IHRvIHNheSB0aGlzIGRy YWZ0IGlzIHRoZSBvbmUgdGhhdCBzaG91bGQgY2FycnkgdGhlIHRvcmNoIGZvciB0aGUgbW9kZWws IGJ1dCBJIGhhdmUgYSBncmVhdCBpbnRlcmVzdCBpbiB0aGUgbW9kZWwgb2YgREhDUHY2LVBEIHRv IHRoZSBob3N0Lg0KDQpUaGFua3MuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpEYXZpZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJtZXJA dW1uLmVkdTxtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcgJiBUZWxl Y29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kN ClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAgICAgICBQ aG9uZTogNjEyLTYyNi0wODE1DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSAgIENlbGw6IDYx Mi04MTItOTk1Mg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCg== --_000_a5398270c6194456b737ca2ef44a8827XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj4gYnV0IEkgaGF2ZSBhIGdyZWF0 IGludGVyZXN0IGluIHRoZSBtb2RlbCBvZiBESENQdjYtUEQgdG8gdGhlIGhvc3QuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgZ29vZCB0byBrbm93LiBZb3Ugd291bGQgcHJvYmFibHkg YmUgaW50ZXJlc3RlZCBpbiByZXZpZXdpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmFuZC9vciBleHBlcmltZW50aW5nIHdpdGggb3VyIGNvZGU6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv djZvcHMvY3VycmVudC9tc2cyODg2MC5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQvbXNnMjg4NjAuaHRtbDwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQv bXNnMjkwMjQuaHRtbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi92Nm9w cy9jdXJyZW50L21zZzI5MDI0Lmh0bWw8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgaW50ZXJlc3QsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5GcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRGF2aWQgRmFybWVyIFtt YWlsdG86ZmFybWVyQHVtbi5lZHVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNo IDE1LCAyMDE4IDExOjEwIEFNPGJyPg0KPGI+VG86PC9iPiBGcmVkIEJha2VyICZsdDtmcmVkYmFr ZXIuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0 O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7OyB2Nm9wc0BpZXRmLm9yZzsgdjZvcHMtY2hh aXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LXRlbXBs aW4tdjZvcHMtcGRob3N0IGEgd29ya2luZyBncm91cCBkcmFmdD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMTUsIDIwMTggYXQgNDo0NyBBTSwg RnJlZCBCYWtlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkkg aGF2ZSB1cGRhdGVkIHRoZSBhZ2VuZGEgYXQgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlhbHMvYWdlbmRhLTEwMS12Nm9wcyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMS9tYXRlcmlh bHMvYWdlbmRhLTEwMS12Nm9wczwvYT48YnI+DQo8YnI+DQpJIHdvdWxkJ3QgYWN0dWFsbHkgYWdy ZWUgdGhhdCBzdXBwb3J0IGZvciBhZG9wdGlvbiBpcyByZXF1aXJlZDsgdGhhdCBjb21lcyB3aGVu IHdlIHdhbnQgdG8gZGlzY3VzcyBhZG9wdGlvbi4gQW5kIGZvciBhZG9wdGlvbiwgb24gYSBtYWls aW5nIGxpc3Qgd2l0aCAxMDAwIHBlb3BsZSwgb2Ygd2hpY2ggMTAwLTIwMCBzaG93IHVwIGF0IG1l ZXRpbmdzLCBmb3VyIChhbmQgd2l0aCB0aGUgYXV0aG9yLCBmaXZlKSBkb2Vzbid0IGNvbnN0aXR1 dGUgYSBjb25zZW5zdXMuDQogV2hhdCBJIGhhdmUgdG9sZCB5b3UgaXMgdGhhdCBwZW9wbGUgbmVl ZCB0byBzaG93IG9wZXJhdGlvbmFsIGludGVyZXN0IGluIHRoZSBkcmFmdCAtICZxdW90O3RoaXMg d291bGQgYmUgdXNlZnVsIGluIG15IGVudmlyb25tZW50JnF1b3Q7LiBXaGF0IHRoZSBjaGFpcnMg YXJlIGxvb2tpbmcgZm9yIGluIHRoZSBjYXNlIG9mIHBkaG9zdCBpcyBwZW9wbGUgc2F5aW5nICZx dW90O3RoYXQgd291bGQgYmUgYSB1c2VmdWwgbW9kZWwgZm9yIG1lIHRvIGRlcGxveSBpbiBteSBk YXRhDQogY2VudGVyIG9yIG90aGVyIGVudmlyb25tZW50JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbGwg c2F5IEknbSBpbnRlcmVzdGVkIGluIHRoZSBkZXBsb3ltZW50IG1vZGVsIG9mIGFzc2lnbmluZyBo b3N0cyB3aG9sZSAvNjQgcHJlZml4ZXMuIEknbSBwdXNoaW5nIG15IHZlbmRvcnMgKHJvdXRlciBh bmQgV2lGaSBzeXN0ZW1zKSB0byBzdXBwb3J0IFJGQzgyNzMgbm93LiBJJ2QgYWN0YXVsbHkgcHJl ZmVyIGEgREhDUHY2LVBEIGluIHRoZSBob3N0IG1vZGVsLiZuYnNwOyBIb3dldmVyLCB1bnRpbCBh dCBsZWFzdA0KIG9uZSBsYXJnZSBPUyB2ZW5kb3IgaW5jbHVkZXMgdGhpcyBjYXBhYmlsaXR5IGlu IHRoZWlyIGJhc2Ugc29mdHdhcmUsIGRlcGxveW1lbnQgaW4gbXkgY2FtcHVzIGVudmlyb25tZW50 IGlzIHBvaW50bGVzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U28gcGxlYXNlIGNvdW50IG1lIGFzIG9wZXJhdGlvbmFsbHkgaW50ZXJlc3Rl ZCBpbiB0aGlzIG1vZGVsLCBJJ20gbm90IHlldCByZWFkeSB0byBzYXkgdGhpcyBkcmFmdCBpcyB0 aGUgb25lIHRoYXQgc2hvdWxkIGNhcnJ5IHRoZSB0b3JjaCBmb3IgdGhlIG1vZGVsLCBidXQgSSBo YXZlIGEgZ3JlYXQgaW50ZXJlc3QgaW4gdGhlIG1vZGVsIG9mIERIQ1B2Ni1QRCB0byB0aGUgaG9z dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT08YnI+DQpEYXZpZCBGYXJtZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkVtYWlsJTNBZmFybWVy QHVtbi5lZHUiIHRhcmdldD0iX2JsYW5rIj4NCkVtYWlsOmZhcm1lckB1bW4uZWR1PC9hPjxicj4N Ck5ldHdvcmtpbmcgJmFtcDsgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXM8YnI+DQpPZmZpY2Ug b2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTxicj4NClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhJm5i c3A7Jm5ic3A7IDxicj4NCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgUGhvbmU6IDYxMi02MjYtMDgxNTxicj4NCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0z MDI5Jm5ic3A7Jm5ic3A7IENlbGw6IDYxMi04MTItOTk1Mjxicj4NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_a5398270c6194456b737ca2ef44a8827XCH150608nwnosboeingcom_-- From nobody Fri Mar 16 11:51:10 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB21B120727 for ; Fri, 16 Mar 2018 11:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZuGjmyX5Y7H for ; Fri, 16 Mar 2018 11:51:05 -0700 (PDT) Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id DFE49129515 for ; Fri, 16 Mar 2018 11:51:04 -0700 (PDT) Received: from [192.168.1.8] (dusted.otenet.gr [195.167.126.245]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 4798213803D for ; Fri, 16 Mar 2018 20:51:03 +0200 (EET) To: v6ops@ietf.org References: From: Yannis Nikolopoulos Message-ID: <2d2082bd-ef71-bb2f-c7d7-05b1f8f14da5@otenet.gr> Date: Fri, 16 Mar 2018 20:51:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CB0A70931AE74CD2B1ECC4AF" Content-Language: en-US Archived-At: Subject: Re: [v6ops] discussion of transition technologies X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 18:51:08 -0000 This is a multi-part message in MIME format. --------------CB0A70931AE74CD2B1ECC4AF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit A bit of a late addition to the spreadsheet. Also, I find it a bit strange that lightweight 4o6 did not get a single mention in the whole thread regards, Yannis On 01/19/2018 10:15 PM, Lee Howard wrote: > > The WG Chairs were discussing the various transition technologies at > some length today. > I mentioned a previous conversation in another forum that led to this > list of networks and their mechanisms: > https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 > (Corrections and additions encouraged, especially with links) > > Our impression was that of the 26+ transition mechanisms defined, only > a few have any modern relevance (editorial comments are mine, not > consensus positions): > 6rd.   It may be that its light is waning, with early deployments > moving to native IPv6, and no new deployments. > DS-Lite.   Widely deployed, existing support among home gateway > manufacturers. > NAT64/464xlat.   Implies NAT64, SIIT, which may be used elsewhere. > Handset CLATs. No home gateway CLAT yet. > MAP-T.   Announced trials and lots of buzz, but no large-scale > deployments, no home gateway support yet. > MAP-E.   Some buzz, no announced trials or deployments, no home > gateway support yet. > Native dual-stack.   Still the gold standard, but doesn’t solve IPv4 > address shortage. > > (Note that “yet†may change at any time). > As a matter of discussion, do you agree? > To guide our work, is there work we should do to document or deprecate > any of these? > > Thanks, > > Lee > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------CB0A70931AE74CD2B1ECC4AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit A bit of a late addition to the spreadsheet. Also, I find it a bit strange that lightweight 4o6 did not get a single mention in the whole thread

regards,
Yannis

On 01/19/2018 10:15 PM, Lee Howard wrote:

The WG Chairs were discussing the various transition technologies at some length today.
I mentioned a previous conversation in another forum that led to this list of networks and their mechanisms:
(Corrections and additions encouraged, especially with links)

Our impression was that of the 26+ transition mechanisms defined, only a few have any modern relevance (editorial comments are mine, not consensus positions):
6rd.   It may be that its light is waning, with early deployments moving to native IPv6, and no new deployments.
DS-Lite.   Widely deployed, existing support among home gateway manufacturers.
NAT64/464xlat.   Implies NAT64, SIIT, which may be used elsewhere. Handset CLATs. No home gateway CLAT yet.
MAP-T.   Announced trials and lots of buzz, but no large-scale deployments, no home gateway support yet.
MAP-E.   Some buzz, no announced trials or deployments, no home gateway support yet.
Native dual-stack.   Still the gold standard, but doesn’t solve IPv4 address shortage.

(Note that “yet†may change at any time).
As a matter of discussion, do you agree?
To guide our work, is there work we should do to document or deprecate any of these?

Thanks,

Lee



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

--------------CB0A70931AE74CD2B1ECC4AF-- From nobody Sat Mar 17 07:09:10 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2B51270AB for ; Sat, 17 Mar 2018 07:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYMebM_cI3CJ for ; Sat, 17 Mar 2018 07:09:06 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 46891126E01 for ; Sat, 17 Mar 2018 07:09:06 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id y19-v6so19344942lfd.4 for ; Sat, 17 Mar 2018 07:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F7GmimYE2XZL+q/7iNv3UhySesa3Ey1L7Eh0wN7Arm4=; b=ce00xja0TTdEWMlhUdmmfKSGmN3A4LgMQAkjPN4Z3VJW3Qhk8q1vlE5qzs1DGCzWEI /CDInsf/Cm9rhgS6iaUyF1sM2GvcWOMyybPum4JcSAU0OxRmzQh3pUj/jsKVEl9VOCFw 5ByXYmfXAYd7IeEB4M5VRkEIpuAZax+dTu5C8oYrViBs+kRqiWtpOXOta+VM9gBjSVib LwsgIVztZHdCkPvhNoSQNK1UpEsXKwsLlWQqTqGXWlhzKm9u7PSEyQwvv2cspDgC2HBD O1aYbHWBB9kMVDZ2RQal04aib1gBpsrH3J8naVL8ro7fMmxWUM7WHpiXkiNmqSr/nSBV htwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F7GmimYE2XZL+q/7iNv3UhySesa3Ey1L7Eh0wN7Arm4=; b=YqxXsSDNCOkqxxqYmuHcp9yyCSkJvPNdzsG+949Xi+4D4ga68Ub8EHjVCIxWMKRmlD 3dWuYvm3AcOWQoIeBpfUYJGLATjDTr9Ojc/d84AQycvxX0VHI7ULZi2wdXZmxLsqnxAp NVwRopYr1oFBA+cDziHelm0kxMc4FlpVM+P4dHxXYjcdyl6PRy2oSS31hRURCui6goWx 6HF1zWmavtczFH2Fqw03tCAULQg7CcHN8dAxn0Etxq4XjRKKN6dvWloCaU3pXgjVCOlp xtMGAqQyADMdrPqkS8+ObcFNdSRexIdjytwAhAXrK7z+FveZJCxUYH81q0Hzk+386vn2 UYMg== X-Gm-Message-State: AElRT7HI08ivoVu+0u51bkfVGRxZYoEj6/kK/2BYUXZsKDRLtGZNsZ29 HSUqwSVHOZXL1O6XikkV1FMS86rzNqWFyQOZIPc= X-Google-Smtp-Source: AG47ELuNyBosZMxx5jNcNbsqFYgeyx2XW8F+SDHktpnKobC1rPZfbRr5RmGF/WB4f6uA+eCFGsu1laUJ9Z6268387PU= X-Received: by 10.46.60.22 with SMTP id j22mr3861525lja.27.1521295744342; Sat, 17 Mar 2018 07:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Sat, 17 Mar 2018 07:08:43 -0700 (PDT) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> From: Jen Linkova Date: Sun, 18 Mar 2018 01:08:43 +1100 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: Gert Doering , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 14:09:08 -0000 On Fri, Mar 9, 2018 at 3:40 AM, Mudric, Dusan (Dusan) w= rote: > I believe I understood the intent of the draft. Let me explain my underst= anding of rule 5.5. Please see inlined. >> ISP uplink is either "preferred" (hosts are allowed to use it, the >> network can send packets there, because the uplink is up and there is >> no explict policy which indicates that the uplink should not be used >> if other uplinks are available) or not preferred (it's down or there >> is a policy to prevent using this uplink ex. for backup). >> It's binary state. > [[Dusan]] The router knows more than that. For 'usable' prefixes, the rou= ter knows which prefix is the most preferred. Would you be able to give an example for 'most preferred'? The network has two uplinks to two ISPs, two prefixes. Both uplinks can be used. Each border router has a default route pointing to the uplink. What prefix is 'most preferred' to reach Internet? >The router can pass that knowledge in RA PIO option, using 'reserved' bits= , for example (like Prf in rfc4191#section-2.2 ). Without this information,= if there are two prefixes (ISP1-D and ISP2-D) how will host know if it sho= uld talk to D over ISP1 or ISP2? Rule 5.5 cannot determine it: > > Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. > If SA or SA's prefix is assigned by the selected next-hop that will > be used to send to D and SB or SB's prefix is assigned by a different > next-hop, then prefer SA. > > You can consider the trick in https://tools.ietf.org/html/draft-ietf-rtgw= g-enterprise-pa-multihoming-03#section-4.2.2 by setting two routes in RA an= d the Prf from rfc4191#section-2.2, based on the router policy. This would = allow a host to select the preferred next hop and use the preferred next ho= p in Rule 5.5. Using Prf in RIO the router policy is distributed to all hos= ts and they can select the preferred ISP. A router SHOULD set Prf based on = the ISP selection policy. There might be use case when the network would us= e only one route and advertise one prifix. I'm not sure if you've been following the whole story....When draft-ietf-rtgwg-enterprise-pa-multihoming was presented to v6ops in Berlin, we came to conclusion that while the described trick is nice, it could not be widely used now. So some tactical solution is needed. That's why this draft was 'forked' from the RTGWG one. So anything which require protocol changes/new features/rule 5.5 support is out of scope of this draft by the definition. > [[Dusan]] Because the router should not limit the communication over one = ISP by advertising only one prefix. The host should be able to decide which= of the two ISPs to use. Both prefixes should be given to the host In the 'load sharing' scenario it is exactly what happens. All ISP prefixes are included in PIO. In the active/backup scenario only active uplinks prefixes are advertised, because the network policy does not allow hosts to use the backup uplink so hosts should not select backup uplinks. > and they should have the preference assigned. Which hosts would not recognize. >> Have I sent this email to 6man@ by mistake? Ah, does not look like that = :) >> And I seem to set the document status to 'Informational'. > [[Dusan]] If we change IPO option, it is not informational any more. Again, the goal of *this particular* draft is to document existing solution, which can be used right now w/o any changes on the host. If we have ideas how to improve the protocol - great, but those ideas should not be in this draft. --=20 SY, Jen Linkova aka Furry From nobody Sat Mar 17 14:47:59 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF525126BF0 for ; Sat, 17 Mar 2018 14:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlyXZHjVLTEs for ; Sat, 17 Mar 2018 14:47:57 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 7C4241252BA for ; Sat, 17 Mar 2018 14:47:57 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id s18so14873841wrg.9 for ; Sat, 17 Mar 2018 14:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=+wX16hnx6Y5o4aWnS30iUtSxU2KI4wNVaWWrYznErcI=; b=jHeiKtW+FENVGz/VvaCE/INCEJwkygyQtWQ/2NPhOt8laOUKFKC0+6h0+4E9iCBgs9 FXlbSb5t/u5A3Lrh7Ro4IFZZTus8HYfXUd6acm1JcQMeoIgbSDvxOdhEJXQSPAUEBxBH HI8QC9KnSftxsSmoGN+obTeSp87KJ607NZPJE6rLAv8EW6zrAj8AYvWXxTuVZM9zoRKl BM0E0aADmjFsvBxClmIwYemGBudbiTVY39khNb1Pv8gLDg5H53xczaKcighRYQVvakrn 2Qpy1PZF+pNCKhl4PDe+0CvSxJjMAkZlvAeP2iDOLkaz+9QDrU7jq9O0X+8LZ4Y1WXBq tZnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=+wX16hnx6Y5o4aWnS30iUtSxU2KI4wNVaWWrYznErcI=; b=NOwUXPDFopX3uJbQbRpVUWDMW6oPwdP4Mf6ViZkwTkHpHouJwKgcZW04feQ2bPVS4V JwO0uqcCmyadKI6jii6I1azw/kz0IRECMNUR/koACLb/pzk2dyi/ceguU+1mhqCAwPeI kU1FmI5Tk+j9DOamryEkcHo7GQGcJSC+YOlVbjE8nND5qBM7oaLQLNiBDt/cHMPSKP95 feT/Gq4fFiMIg2rnadad/rrMPED8EqCS/NLlLDOc5UhamjeeE59q9T89W7Z3Ium4ngDg qYX7YNvPGkeYuWo4QEUmvEJVkKP7grDTVw9u+FQuu+QpGDc9ipXOBc+meEpkQ4quQHKc pLGw== X-Gm-Message-State: AElRT7FsAUPorpAn6Aidltr8cDHhyUZ9R3LLYmRT3KOnTdnL+BZ0t/iC ELnx2aJ+jRehNn4qkUGtejPBgYeNKM1ax0xv0Fw3fGnT X-Google-Smtp-Source: AG47ELtbJKeO83AM23ZlkHWTG5psOdZvBQCUb2CilH7ImDgJ/4vGoAee4zmNzNEgRn/yqPVdarBcmQqEqfzrH4+yWys= X-Received: by 10.223.138.234 with SMTP id z39mr5603606wrz.35.1521323275691; Sat, 17 Mar 2018 14:47:55 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.151.19 with HTTP; Sat, 17 Mar 2018 14:47:55 -0700 (PDT) From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Sat, 17 Mar 2018 14:47:55 -0700 X-Google-Sender-Auth: iqGITi3i44raB3ZzxaDYUcsPv9g Message-ID: To: v6ops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] comments on draft-templin-v6ops-pdhost-13 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 21:47:59 -0000 I've read draft-templin-v6ops-pdhost-13. I found it generally well written. I have a couple of quick comments: - Section 1 'R' could instead function under the strong end system (aka "strong host") model [RFC1122][RFC8028] by assigning IPv6 addresses taken from 'P' to an upstream interface as shown in Figure 3: I think this usage should clarify its relationship with the following part of RFC3633: [...] the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router. Perhaps the implicit assumption is that the "prefix" itself is assigned to a different interface than the upstream interface and should be justified. But (even if so) I believe it should be at least explained explicitly, and I guess it could be controversial and should better reach an explicit consensus. - Section 3 In contrast, a node that configures addresses from a delegated prefix can assign them without invoking MLD/DAD on an upstream interface, since the prefix has been delegated to the node for its own exclusive use and is not shared with any other nodes. I personally think it still technically violates RFC4862 Section 5.4: Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions: These exceptions don't include "when the prefix is delegated to the host". In fact, my understanding is that the sense of RFC4862 is quite strongly err on the side of caution and try to catch a situation of configuration errors - in the context of the draft, including cases where the upstream router accidentally assigns an address from the prefix. With some more discussion it may be justified, but I personally don't think the current brief description is enough. Also, for this reason this document should be a standard track document updating RFC4862. -- JINMEI, Tatuya From nobody Sat Mar 17 15:53:45 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3085312D889 for ; Sat, 17 Mar 2018 15:53:43 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtLqSw9547jN for ; Sat, 17 Mar 2018 15:53:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED71212D942 for ; Sat, 17 Mar 2018 15:53:40 -0700 (PDT) Received: from [10.142.115.191] (unknown [88.99.210.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E728D8058C; Sat, 17 Mar 2018 23:53:36 +0100 (CET) References: <43fe7a37-0a14-e3e0-7703-1769ff7926d0@si6networks.com> To: IPv6 Operations From: Fernando Gont X-Forwarded-Message-Id: <43fe7a37-0a14-e3e0-7703-1769ff7926d0@si6networks.com> Message-ID: <3dc65b52-c8ba-b35a-8c5a-ea49cc799f4e@si6networks.com> Date: Sat, 17 Mar 2018 19:05:00 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <43fe7a37-0a14-e3e0-7703-1769ff7926d0@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Fwd: SLAAC on non-/64 networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2018 22:53:43 -0000 FYI -------- Forwarded Message -------- Subject: SLAAC on non-/64 networks Date: Sat, 17 Mar 2018 18:06:13 -0300 From: Fernando Gont To: 6man@ietf.org <6man@ietf.org> CC: phessler@openbsd.org, Florian Obser Folks, FYI, OpenBSD now ships with RFC7217 support, and in the process, they have removed the artificial /64 limit, and can do SLAAC on prefixes shorter and longer than /64 (say, /60, /32, etc.). Quite cool. -- but even if you disagree, I guess the "FYI" is still valuable. :-) P.S.: The reader might enjoy the commit message at: :-) 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 Sun Mar 18 03:02:22 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE041200A0; Sun, 18 Mar 2018 03:02:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152136733766.6194.16359887713134334579@ietfa.amsl.com> Date: Sun, 18 Mar 2018 03:02:17 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 10:02:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Using Conditional Router Advertisements for Enterprise Multihoming Authors : Jen Linkova Massimiliano Stucchi Filename : draft-ietf-v6ops-conditional-ras-02.txt Pages : 17 Date : 2018-03-18 Abstract: This document discusses most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. [I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue and using Router Advertisements to influence the host source address selection. While the above-mentioned document focuses on solving the general problem and on covering various complex use cases, this document describes how the solution proposed in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited number of common use cases. In particular, the focus is on scenarios where an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in [RFC8028]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-conditional-ras-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-02 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 19 04:23:30 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E59412741D for ; Mon, 19 Mar 2018 04:23:28 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h71j95cpfYKf for ; Mon, 19 Mar 2018 04:23:26 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 1DB14127077 for ; Mon, 19 Mar 2018 04:23:24 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx67.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1exssc-0001EM-1W for v6ops@ietf.org; Mon, 19 Mar 2018 12:23:06 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1exssE-00033o-Q5 for v6ops@ietf.org; Mon, 19 Mar 2018 07:22:46 -0400 Received: (qmail 19239 invoked from network); 19 Mar 2018 11:22:22 -0000 Received: from unknown (HELO [31.133.134.201]) (Authenticated-user:_huitema@huitema.net@[31.133.134.201]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Mar 2018 11:22:22 -0000 To: v6ops@ietf.org From: Christian Huitema Message-ID: Date: Mon, 19 Mar 2018 11:22:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.72) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5susPuoPpi6Ks91ON3m8/Uh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9Ax3mhXNTgerhsAQp1GLsVN1FDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5GU+7Zn1h1zEIZSy0Vfl59U5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+Uz0sPgnp Ak2KA2vJwMd1uVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaItf4+twGXVB88RVqZKbNnqF8FcHzzV3acxBudgYcInb3Q5exnkGFhL qha708z4JOiZ4+t4LK79cWIqQA4tGr3po0jfgLl+Ahd0TIbt0Zij6hgeJ07QR0GiieIKGR3KfdmQ xACKGgjW6av7lJfpYBfZXUaHqdOKLJ13TYQgD1U8MFwBl1z1+w2zS/h3e6UiVResEfG0UUAqguR9 nAB/4gFQeaFtm269EuqSVTegjTtzN2eqA47D/juB1cx4exzYk7wIdHXqmiNP5dvI77+8YOq/647l NwN4qOsSZg+fYhVZG9EQ9b9YI+9ZsqMLtlmzzH7VwaDsyRiTeu4Ip+KAECko9HdE0Smt1e6HZuGs N7RwePAFMvX7q8M4x6bP/gjzw0OFbIWNJOiaifOc2xlkb46Pa4K5MPGI7fF8+j7E9IwdcQR2aish SbQcCCOvcJLn8v/2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:23:28 -0000 I am listening to the fragmentation discussion in the V6OPS meeting in London. Here is a small related experience: https://huitema.wordpress.com/2018/03/03/having-fun-and-surprises-with-ipv6/. The symptom was, "why are you sending QUIC packets in the wrong order". The root cause was, packet was fragmented, fragments were received in different order than non fragmented packets. -- Christian Huitema From nobody Mon Mar 19 04:44:14 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84061275F4 for ; Mon, 19 Mar 2018 04:44:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG6tLOyJO2Ek for ; Mon, 19 Mar 2018 04:44:11 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 088D112D961 for ; Mon, 19 Mar 2018 04:44:09 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id s2so2430762qti.2 for ; Mon, 19 Mar 2018 04:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cJtmFCaEmZ0mayoDTSsTVJbDJ6o0aEWak7lI4IFnaWI=; b=LzCLKc6ACJQDD/OoGwljoMwuhU9VuMMdW7A4cotS1jxy13b/EQ4P64y6pHKkgavJoO RpT1EggruIFjTZRon3HuqWHHFV2y2m2REePoty1OOLZ789b5Cr943YNjB477+FR6Zz7D YOmdNL7GsHfRySIQ/UVvm9Pku7mytMfyGOnFahxJJ/8Bu/pvuMKmJhkNRCD5SP8zOlfB pxu4775dhV1ZNuruLzrxPvIKlUvg+9AL5B1HDEzUHuh4PdyyCkgBa+90EipmHdQaEQLs 2E0gY9bcQb3SjuzYWcDJ2A/cgdcKEPUAuaVk4dm1YLp3fCIgQ4+OGMYNGCxT8T6pbGyl SFXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cJtmFCaEmZ0mayoDTSsTVJbDJ6o0aEWak7lI4IFnaWI=; b=nmxVxT5PjBfSn+EF50MdwGZqzp/jLfKScQFQQY+VJVk6wCCIDmJsTMLNg9wDb5yb0l X8XAMF2lHx47QWsHT9mI2PnEuzDv33QgRNOGc2mrQ/lnZUqIiIDdvBTifnQqYjHiH9qO 7Lh1LomjtqmdeMCk/FYLeYMPFH6xngEMOzjjF7/DLavfl3idmkR1S9nXnOqpLAxnEJqn ZEnpR9Fd5MkNxpKC3fX7gmnVa0VeVolhV3tzKH3hmTWtiSbWmoVjJFudTAAObnPkQGTA ZVgK20Z/BW4C96F9ioOi02f2g1Hj6wGO1ry/Aqkl0ndzgjpaYzpM8h/KwnSxCMWG/Odo q4XQ== X-Gm-Message-State: AElRT7G5i+VKJrQ8dSGKB2pibUXzmOBmR2KP7TeCGt/Orq0u2Wy+D6mH sgq+6Fbh2IVxLfNobZmfEez2AHVOGLC8DuU7PytufQ== X-Google-Smtp-Source: AG47ELv6rp6pgG5iWKV9ycnadmiNWqCm/o9EV3UifCResEMGGB5BHSeicyA0IO3fdf+OWoLLiuresYnHG43lpZWQ0xQ= X-Received: by 10.200.42.37 with SMTP id k34mr1581570qtk.101.1521459848030; Mon, 19 Mar 2018 04:44:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.26.135 with HTTP; Mon, 19 Mar 2018 04:44:07 -0700 (PDT) In-Reply-To: References: From: Tom Herbert Date: Mon, 19 Mar 2018 04:44:07 -0700 Message-ID: To: Christian Huitema Cc: IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 11:44:13 -0000 On Mon, Mar 19, 2018 at 4:22 AM, Christian Huitema wrote: > I am listening to the fragmentation discussion in the V6OPS meeting in > London. Here is a small related experience: > https://huitema.wordpress.com/2018/03/03/having-fun-and-surprises-with-ipv6/. > > The symptom was, "why are you sending QUIC packets in the wrong order". > The root cause was, packet was fragmented, fragments were received in > different order than non fragmented packets. > Christian, That will be common in the presence of ECMP or RSS. There's no way to include ports when a fragment is being forwarded so these fallback to doing ECMP based on 3-tuple hash only for fragments which means fragmented packets produce a different hash then 5-tuple would and hence take a different path. In order to keep fragements in order, if MF is set ECMP should not use the ports for the first fragment even though they are present. The fix for this is IPv6 is to use the flow label in the ECMP/RSS hash and ignore the ports (hash over addrs and flow label). For a flow the same flow label should be used for fragments and non-fragments so they should be routed the same way. Tom > -- Christian Huitema > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Mar 19 05:46:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456E4127601 for ; Mon, 19 Mar 2018 05:46:40 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIXxBUX-DoU0 for ; Mon, 19 Mar 2018 05:46:38 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C861242F5 for ; Mon, 19 Mar 2018 05:46:38 -0700 (PDT) Received: from [192.168.1.128] (unknown [31.75.233.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 304578241F; Mon, 19 Mar 2018 13:46:34 +0100 (CET) To: Christian Huitema , v6ops@ietf.org References: From: Fernando Gont Message-ID: Date: Mon, 19 Mar 2018 12:46:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 12:46:40 -0000 On 03/19/2018 11:22 AM, Christian Huitema wrote: > I am listening to the fragmentation discussion in the V6OPS meeting in > London. Here is a small related experience: > https://huitema.wordpress.com/2018/03/03/having-fun-and-surprises-with-ipv6/. Fragmentation experience with IPv6: RFC7872. Short version of it: it fails on the IPv6 Internet. And the same is true for other EHs (yes...that unfortunately includes IPsec-related). 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 19 07:15:08 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23240124B18 for ; Mon, 19 Mar 2018 07:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du532CAyvNYt for ; Mon, 19 Mar 2018 07:15:00 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 CB5771204DA for ; Mon, 19 Mar 2018 07:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zLmciSjA6hyDiskx//04ODMagXQp7SU0IevdM5Kaigs=; b=2MAVIGgiFWmm/JJCkNF/F3cHD bbZYz0vp/3TfPC0J4i2XUGF//s4ytQJQFYOvNRZqtfyclhLz/m9wM3LcxYJ0FgCALgANZSxkRFA1+ uvGCDPBYsAaCxPf64Qo5I3k0V3DakrN5Fr+l1TcnF3VjbHpUKz6cOwmoAs27D1wRFHBWxHU7kVm0G JfEFkjfwZ+fzQN3f2wLwhH5tXrOB71HVS/nSO7JeXH0eiTH78MqKqmKw550phPNy36cVKJAuzriTr vFKy7UeI2kb/F+CMxXEw8Y+otbwCtDXz+7QJn8szMoi6SPoQzz36EL6TxzphSgvT3jBXfynSVGVOP LEBMI0wiQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58970 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1exvYm-001DFX-B3; Mon, 19 Mar 2018 10:14:49 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D679C4EF-3F23-4ADF-B06A-4BB197703608" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Mon, 19 Mar 2018 07:14:47 -0700 Cc: Christian Huitema , IPv6 Operations Message-Id: <5752F08E-98B9-4A66-AA64-FB251154D425@strayalpha.com> References: To: Tom Herbert X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 14:15:07 -0000 --Apple-Mail=_D679C4EF-3F23-4ADF-B06A-4BB197703608 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 19, 2018, at 4:44 AM, Tom Herbert wrote: >=20 > That will be common in the presence of ECMP or RSS. There's no way to > include ports when a fragment is being forwarded UDP options provide a workaround - allowing the app to transmit in = UDP-sized chunks while allowing UDP to source fragment at the transport = layer, which includes the conventional UDP header in each fragment. That said, I agree with the conclusion that this is what IPv6 flow = labels were intended to also support. Joe= --Apple-Mail=_D679C4EF-3F23-4ADF-B06A-4BB197703608 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Mar 19, 2018, at 4:44 AM, Tom Herbert <tom@herbertland.com>= wrote:

That will be common in the = presence of ECMP or RSS. There's no way to
include ports when a fragment is = being forwarded

UDP options provide a workaround - allowing the app to = transmit in UDP-sized chunks while allowing UDP to source fragment at = the transport layer, which includes the conventional UDP header in each = fragment.

That = said, I agree with the conclusion that this is what IPv6 flow labels = were intended to also support.

Joe
= --Apple-Mail=_D679C4EF-3F23-4ADF-B06A-4BB197703608-- From nobody Mon Mar 19 09:41:38 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1E7127201 for ; Mon, 19 Mar 2018 09:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn8cBtRzBdzG for ; Mon, 19 Mar 2018 09:41:35 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 4DA5A128959 for ; Mon, 19 Mar 2018 09:41:35 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f125so8603034wme.4 for ; Mon, 19 Mar 2018 09:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=i3bEGvVIeT6vbG41cCNVnCWAhprYXQ+Y6Z5GsTWp6fo=; b=EGgklYf+86CIIqZuepJzR2KlyPu27ut/2933wG00T71XQ+wzQeAds4oULrj8kF7GpR VtA79yKQ2eOYubhdAPllnjS/SaDQD3LjnOC3yMH4dLG8S7GuC3O+5CHOFIcbLdiePkqo yD3nqT34VEhaTiUu/QxAxRWRP/QXbt6Jr3R/cKtMkxFbh3oHkz/T8e+w+jBMs3eD6xaG gAa8dxPIih7zUkSxNvhPOy4E75viucI/7XrPzlE6DMOHfBDfR3G1bAWwosrLv8ZT1cpf w0qsB+f+cghByDpWpoX2w6dUH4x88USSanNPPXIpPYhd6vXznjntgV3Gtkvb1CMJ+NFD bLTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=i3bEGvVIeT6vbG41cCNVnCWAhprYXQ+Y6Z5GsTWp6fo=; b=mB2QehWZei+St6ig3R6m+LuHJYrxaZ3/eQvtqJuEY16R1VAZUnWZBO78rxBcK/ZzkY yLyATk4j6uL+c/xnNJjIObT4cWTsXw3WGDhjIq4XYffkP+mKzCUqRZ0Yx80qOFbbeMH7 phRT+Emi/OAl90YV6tUFO5YltHPCd+si8wZjsGfIPqiZg+r1CqHede+ZvmY4KZ9fCeH/ dcopvzDL8HEalfSOp4VQngo2qQTMxMhxtoYt/0BdHckU75I2F3tsIWciVtJwnI6tO9aC 63bxVKwbY7R8bVNiQX7rlKXqGLg6Ra27CLv3WiWg7mujjyGMVQFvlPb32lpEc5UwTMbM Wxow== X-Gm-Message-State: AElRT7EqTEMoVgSRHvdXvuDXU/4t+DuFlC4fdA8N4oq9e+3oq3o7Rv+l 7YOHz1zNOigq0wqIoY+wJ5Fymxp+ X-Google-Smtp-Source: AG47ELvjY+Qho9aBi4oTIxL0ZGK5m/9T2QlP4LE708fHQMbek58xgMf66MXWhdhuaNZ70sLMfyQFrA== X-Received: by 10.28.50.69 with SMTP id y66mr9755336wmy.133.1521477693895; Mon, 19 Mar 2018 09:41:33 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:e9f3:4618:5e12:76ed? ([2001:67c:1232:144:e9f3:4618:5e12:76ed]) by smtp.gmail.com with ESMTPSA id m184sm908086wme.40.2018.03.19.09.41.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 09:41:33 -0700 (PDT) From: Fred Baker Message-Id: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FAC60D74-4579-42BB-B3F6-3C61FB51CE7A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 19 Mar 2018 16:41:31 +0000 In-Reply-To: Cc: v6ops@ietf.org To: Christian Huitema References: X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 16:41:37 -0000 --Apple-Mail=_FAC60D74-4579-42BB-B3F6-3C61FB51CE7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 19, 2018, at 11:22 AM, Christian Huitema = wrote: >=20 > The symptom was, "why are you sending QUIC packets in the wrong = order". > The root cause was, packet was fragmented, fragments were received in > different order than non fragmented packets. The question I would ask is "why would QUIC care? IP is a best effort = network, and will therefore reorder some percentage of traffic". --Apple-Mail=_FAC60D74-4579-42BB-B3F6-3C61FB51CE7A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlqv6DsACgkQEhdRnd2G P+A0xhAAmA5c1QYBPBoBcDoSvze/3pQEIAS84mAeLKCVvNHDBzkrDwzvlT5/bq8g oz69UFhQQqEa/jbblvDI3eyz1TsDtpHpg6Ts99qcKridbSptO5p626iR1KQHUooC c6yeeAGDLzZBGX/Ah02lDcbD/E33Ewf1lGQrkmJuybhCVjRCqNgh8GaVfRqYMQMM 6r/Hvl7GbqWJE+aG43mKL9WHknmpULY5dxbR16c2eDAEhqCF9axaDnpjQOZGwhcT ok5lK7tMzwqC/xLJJOzZRV1YbxI0IiLWMIWxbz3uloGLjqxKuyj0M5DSPDEussHZ z3ogQX8ST2tdL9Mh5Gqs47tzQWobYurMGnntRTZsHFcG6hUlcjyiPMHKHDBOXUB6 d3QPV87zZxIxKKY6VCf9CCN6/kq6lrm8LHlOmzGFzPtqJnuG/zU+XJz9/QwZPxiU p/2L23R+Rk7QaIqkoaYzZ3eRRGoul3++zOUdNj17m2ZkLDUSrxlDwRGpuOZZd+de U7tYkPlTyZjvWOIjkBH8UP6kC2aZgCc5a18BmuFMHZHMnlEExM8JEo+OFPdgjumn HhMq6sgKM+06ms93/j4fumLpPYlWImeB/iCQu9AljUEoLk/cdqbss7EiX1/nav+r o4bh3lgW13yivpGVmflPlxl8QGVqt+QOZqwsb6G4k3PZuo+Uj2s= =fM1O -----END PGP SIGNATURE----- --Apple-Mail=_FAC60D74-4579-42BB-B3F6-3C61FB51CE7A-- From nobody Mon Mar 19 12:44:43 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8C1271DF for ; Mon, 19 Mar 2018 12:44:42 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaIorrT3SftZ for ; Mon, 19 Mar 2018 12:44:40 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 7835012025C for ; Mon, 19 Mar 2018 12:44:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w2JJid3i059563; Mon, 19 Mar 2018 12:44:39 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w2JJiV63059490 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 19 Mar 2018 12:44:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 19 Mar 2018 12:44:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Mon, 19 Mar 2018 12:44:31 -0700 From: "Templin, Fred L" To: =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , "v6ops@ietf.org" Thread-Topic: [v6ops] comments on draft-templin-v6ops-pdhost-13 Thread-Index: AQHTvjmnd2PZUMbnDkSvjv+G177776PX73Og Date: Mon, 19 Mar 2018 19:44:31 +0000 Message-ID: <6bea281428f944c899f42ef4750eab10@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] comments on draft-templin-v6ops-pdhost-13 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 19:44:43 -0000 Hi, see below for responses: > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of ???? > Sent: Saturday, March 17, 2018 2:48 PM > To: v6ops@ietf.org > Subject: [v6ops] comments on draft-templin-v6ops-pdhost-13 >=20 > I've read draft-templin-v6ops-pdhost-13. I found it generally well > written. I have a couple of quick comments: Thanks for taking the time to read and comment. > - Section 1 >=20 > 'R' could instead function under the strong end system (aka "strong > host") model [RFC1122][RFC8028] by assigning IPv6 addresses taken > from 'P' to an upstream interface as shown in Figure 3: >=20 > I think this usage should clarify its relationship with the > following part of RFC3633: >=20 > [...] the requesting router MUST > NOT assign any delegated prefixes or subnets from the delegated > prefix(es) to the link through which it received the DHCP message > from the delegating router. Yes, you are correct per RFC3633 and this document intends to honor the requirement. The difference is that this document only permits the assignment of *addresses* to the upstream interfaces - not prefixes or subnets. Can this be addressed by the addition of a single sentence such as: "While addresses taken from the delegated prefix can be assigned to the upstream interface, the prefix itself (nor any subnets taken from the prefix) cannot be assigned to the upstream interface (see: RFC3633)." > Perhaps the implicit assumption is that the "prefix" itself is > assigned to a different interface than the upstream interface and > should be justified. But (even if so) I believe it should be at > least explained explicitly, and I guess it could be controversial > and should better reach an explicit consensus. I think the terminology says that prefixes are added to an interface's prefix list (i.e., they are not "assigned" to an interface per se). But, the assumption in this document is that the prefix would be added to the prefix list of some downstream interface (e.g., a loopback) or not added to any interface prefix list at all. > - Section 3 >=20 > In contrast, a node that configures addresses from a delegated prefix > can assign them without invoking MLD/DAD on an upstream interface, > since the prefix has been delegated to the node for its own exclusive > use and is not shared with any other nodes. >=20 > I personally think it still technically violates RFC4862 Section > 5.4: >=20 > Duplicate Address Detection MUST be performed on all unicast > addresses prior to assigning them to an interface, regardless of > whether they are obtained through stateless autoconfiguration, > DHCPv6, or manual configuration, with the following exceptions: One of the exceptions is: - An interface whose DupAddrDetectTransmits variable is set to zero does not perform Duplicate Address Detection. So, if delegated prefixes are the only autoconfiguration parameters that wi= ll ever be received over the upstream interface then it should be OK to set DupAddrDetectTransmits to 0. But, maybe you are thinking of some kind of mixed mode of operation where the node may receive both delegated prefixes and on-link prefixes over the upstream interface. In that case, there would need to be a provision for avoiding DAD only for the delegated prefixes and honoring DAD for the on-link prefixes. Is this getting to the point you are making? > These exceptions don't include "when the prefix is delegated to the > host". This may in fact be a new exception to be added to the list if we want to support "mixed mode". > In fact, my understanding is that the sense of RFC4862 is > quite strongly err on the side of caution and try to catch a > situation of configuration errors - in the context of the draft, > including cases where the upstream router accidentally assigns an > address from the prefix. We want to avoid unnecessary DAD to avoid unnecessarily disturbing other nodes on the link. I think the case of the upstream router assigning an address from the delegated prefix is a bug like any other, and going out of our way to test for this particular bug seems unnecessary. (For example, in another bug a node with a duplicate address could be misconfigured to ignore the NS messages sent by DAD.) > With some more discussion it may be justified, but I personally > don't think the current brief description is enough. Please feel free to suggest text. > Also, for this > reason this document should be a standard track document updating > RFC4862. I see your point about updating RFC4862, but that pertains only to the desire to avoid DAD on upstream interfaces that may receive a mix of delegated prefixes and on-link prefixes. The rest of the document is operational and not a protocol standard. So, how would it be if we split into two documents. The main document would be operational-only and would retain about 80% of the text of the current document. The other 20% would be used to form a new standards-track document with the intention of updating RFC4862. What do you think? Thanks - Fred > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Mar 19 14:33:37 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12A412D94C for ; Mon, 19 Mar 2018 14:33:35 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MpMb4pi8Fd4 for ; Mon, 19 Mar 2018 14:33:34 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 1228F12D94B for ; Mon, 19 Mar 2018 14:33:34 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ey2PE-00026y-U7 for v6ops@ietf.org; Mon, 19 Mar 2018 22:33:28 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ey2P8-0001IG-U2 for v6ops@ietf.org; Mon, 19 Mar 2018 17:33:22 -0400 Received: (qmail 519 invoked from network); 19 Mar 2018 21:33:17 -0000 Received: from unknown (HELO [31.133.151.142]) (Authenticated-user:_huitema@huitema.net@[31.133.151.142]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Mar 2018 21:33:17 -0000 To: Fred Baker Cc: v6ops@ietf.org References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> From: Christian Huitema Message-ID: <731431f9-9014-b492-7561-389e61383f05@huitema.net> Date: Mon, 19 Mar 2018 21:33:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.16) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iF2efO6hVQP0UtBQf+hLE5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9AxuXombfALRWZwRub/iuWHglDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j53+WMpwnUbJ+TjLEQpJpwzk5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+Uz0sPgnp Ak2KA2vJwMd1uVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2Drvl3AsHuisl/RSyh5DLe 1OidX4Ts4xdG+C13IyWeZaJp2rd0CUmEqTszreuN8Vs3nnXm95a0vRtjH3/UwFOlrczh4K30Q/WM YRlj/Fze7d23B+q+bUHXAsYFgsNREGhlzTFYPIyr5voE3ggyv83xvYRfyCMB4QZToA5YKb0SaS5E llm5CBzrwBATJ22MAarYUW/FXbMuS2WlB161/YGFak7k+vjbEFIODONvVl7uk825/eD5OFEj0Kd1 z8U/pNWnoCPWWd7Z50ey2j28i5vGBtfH1yALUGC6BHMPRvkcc+1710xXBYdzBVKJBN+veLiv9R/2 gMGq0KWAzmMf+ibVDrPB08Z8zR1gAMBxZUX6NJOqWKEc9MBxZCWS72/wjopIVAY+3RHRetx4B6Z4 Ei5woFss+n2ffnQxt6aJ7klZab+5U3mWTJPTqb+xVIKqgeO7n3iwosDmKSszPVW9RecIRsxn9uie 2n4+ooHGqAOWILQxL7hrJSk60SF3F6RYOYr2 X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 21:33:36 -0000 On 3/19/2018 4:41 PM, Fred Baker wrote: > >> On Mar 19, 2018, at 11:22 AM, Christian Huitema = wrote: >> >> The symptom was, "why are you sending QUIC packets in the wrong order"= =2E >> The root cause was, packet was fragmented, fragments were received in >> different order than non fragmented packets. > The question I would ask is "why would QUIC care? IP is a best effort n= etwork, and will therefore reorder some percentage of traffic". The Quic trial actually succeeded. The packets were resent, etc. But in that specific case the recovery used a strange code path, because the out of order packet was encrypted with a key negotiated in the "previous" packet. In any case, out of order transmission is not helpful.= -- Christian Huitema From nobody Mon Mar 19 15:56:19 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38312D7F2 for ; Mon, 19 Mar 2018 15:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGjXTUlVbSSe for ; Mon, 19 Mar 2018 15:56:16 -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 F1ECB12AF84 for ; Mon, 19 Mar 2018 15:56:15 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w2JMu99R011979 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2018 22:56:10 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local Message-ID: <5AB04008.7000400@foobar.org> Date: Mon, 19 Mar 2018 22:56:08 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.24 (Macintosh/20180302) MIME-Version: 1.0 To: Christian Huitema CC: Fred Baker , v6ops@ietf.org References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> In-Reply-To: <731431f9-9014-b492-7561-389e61383f05@huitema.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 22:56:18 -0000 Christian Huitema wrote: > In any case, out of order transmission is not helpful. this depends on the use case: there are plenty of situations on bandwidth-constrained edge networks where it is useful, e.g. where transmission of a single large mtu packet takes an appreciable amount of time. In general, o-o-o transmission is not useful in network core. Nick From nobody Mon Mar 19 23:01:05 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04C120713 for ; Mon, 19 Mar 2018 23:01:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW5KRx3nb7LK for ; Mon, 19 Mar 2018 23:01:01 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 4D939120454 for ; Mon, 19 Mar 2018 23:01:01 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id h2so371229wre.12 for ; Mon, 19 Mar 2018 23:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=5KzgG4V4zDfZh8MIuPrhAluK7tYiEmpkMR1rBBSt70M=; b=IjmpJJ4voJme5A3JzhSi1VoZ/sx5HYI2JaCwcuP9iddRH4SSbLxO54XY5QdJPgpLtG N8k7hDHJEkOcbiB+MmruK0q1i8+B6Qr5v4gEOKK9X+VjedbcHnqsHmfuX0PRAQiw7yq6 4FTG3uk83vzwUKzdBzp2rlWU95YcCj/aJnLyIXv9pT6wgPhR7JfxbUDY/Y92OaUx++aE xoZjOEV4PQ5ZAUHQxRhvXOoqwG8b/EY2hnh1y0xGrtXBFFL1Fr4IMwpdIkIQQNskLnDV /ksr/VBaVwuGBHRsim/dZnTbpqqAhAxMgf81PtrRPhN4cGuTM8yPUyF+YfRxcdr0nIPf sWDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=5KzgG4V4zDfZh8MIuPrhAluK7tYiEmpkMR1rBBSt70M=; b=U7fsgaKTXF2jOL3dqY4mK0rK0tn8q7hw/CRW9N2Q+8hLcveqT7inEO2MInqkbOmdxZ 1oZdvjGp1n8X3z/IZ9qETjoYk0VMGkaO/KQJ8E4F0TTgML8Y6lvUroWc0v9HV/qH2Mrv WPu8ZIKY4/YGBi4mC7Iz2A+EPLuTMelY2G9bOWUjpHwx+6yDiiaVEvDZPuUQvpHKtY9t s+UWSy0yO4FkPiQjxw05WZmFrUyQp/WxiCa9rP580gDTS0Bh33/adq33M+7EanHs70IR CPaz4gZuNQuW0n4LoZT1n38s4g2+8/tp/3VFXL3B/L10N/ptmoQfLRD35oqj7DUu951g Tcbg== X-Gm-Message-State: AElRT7HBKiZXcHjuUYi9XzAuCutLsXW/bIL5eQ0rezKirgI72JPiUc97 ByFYlcGy5ix06Z9gfV2pvZ2u4Mgg X-Google-Smtp-Source: AG47ELtC+r8d1JNlyFIl7cORwuwy/u/mHIFkx/FEBgPwk1vy9usjJSxzKpdS6lruIGLhXG3bMZc2oQ== X-Received: by 10.223.182.132 with SMTP id j4mr11560951wre.66.1521525659507; Mon, 19 Mar 2018 23:00:59 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:20ca:b8ba:4af7:9d7d? ([2001:67c:1232:144:20ca:b8ba:4af7:9d7d]) by smtp.gmail.com with ESMTPSA id 67sm608760wmq.17.2018.03.19.23.00.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Mar 2018 23:00:58 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_8D081B4D-2FA7-45FC-88B5-88A38E7CBD4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <9FFC570F-57EE-47C7-852B-00D5A2C97E2E@gmail.com> Date: Tue, 20 Mar 2018 06:00:56 +0000 To: V6 Ops List X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [v6ops] draft-ietf-v6ops-conditional-ras WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 06:01:03 -0000 --Apple-Mail=_8D081B4D-2FA7-45FC-88B5-88A38E7CBD4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As discussed at IETF 101, we are opening a Working Group Last Call on = draft-ietf-v6ops-conditional-ras. Please read the draft now. The chairs = need to understand both whether you think this is valuable in an = operational environment such as yours, and if there are issues in the = draft, what those might be. This will close April 8. --Apple-Mail=_8D081B4D-2FA7-45FC-88B5-88A38E7CBD4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlqwo5gACgkQEhdRnd2G P+B7YQ//Rm4FcG+7Ckk8XiERTRlrSgi56eqsSX7tmsOIkYmGx9OeLJzLCDRrjRte Nka28ifkmGmRNcG0B7fyswf1/g0TD6BE7aVRqtQzHm2PpYe87aZKQs86xSpQwypl rc2K/Y5PC1vrWH40wCVTamywU+MS4cGos+g5anvYB3eO3pk8bRnJt0sdWChRD0WJ kIAJoFD1BH67pZ541YmBaTIFkw9rNrmddDZI2yqE377r4Pou6wZEYad1HxFyBjm0 jNUQEToAw+UuVtAnS0xmGlkUYOK4Iji/0hxq1H2ZWJd6sZhfh2QKehfTNA3RK8jD Me45Sz6wErPjxc+E25AvjTlAdYBZ04CKff1wOH3uJxayenPVgUqVR02CuK5Nf7T8 3GK+8MG2O0O2eaJnUEfxuTWO7DWPVztsu7gOclcvDkBAU3t0LuIxrURDw7+vSm/d NOpZlx4E5w7iH078X2MDe3LfoEcM0ph3nAiipsB7xtXSM3AE3YB9AlzZ5Jysxwe+ arW5QJQBpu+6eqDwjF0UMzi+6qhMVQSdRC+v97EICdG4pamqAca3FzXCA/K/Mpsj vFJCBqMtfsvnJEhFu0pw8QT+OQeGUQdgGxbANmdTHEZQkjBnzt1bMER4bLsYQdJo vV7tTuJRdlnNKREyoJpsa4em0JUc97TMfm0TAe5O9lEFaL4Wir8= =eLgN -----END PGP SIGNATURE----- --Apple-Mail=_8D081B4D-2FA7-45FC-88B5-88A38E7CBD4F-- From nobody Tue Mar 20 01:30:22 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AE612D869 for ; Tue, 20 Mar 2018 01:30:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRsgylCvhzef for ; Tue, 20 Mar 2018 01:30:18 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 435FC12D82F for ; Tue, 20 Mar 2018 01:30:18 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id n12so723654wra.2 for ; Tue, 20 Mar 2018 01:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DCo6aTNMdA1MUUWSXCg9jLbRcmSxhLS4ADACXot9Yjg=; b=gsJOY5isqrPMb3nW1U1coVvC2sUPSeOqCJF5XF8GSX9R6AUNe/SDpzihRZyE38LwEP 4KNi39pW98Y+C1/PxxaDWKSQt3fZPc/ENgBHf1o4Xkw+dO/jHU8s31C7JR1fMwVos3FJ Xo0AubGZeqdCjPVGNoDq5TVHSDMf+8Sz5ionDvufMO/bnvnUQhjnycrfjhZLr3VxCHBL RSr2PHFhs047UcXn+U+oTQESdzCynclOm2j+DIa0Z6K3aau2U8Th7Q2bR0Rl3NrbEfCq sMKHDS9jKpdkW5pY0RhTcVekhycrEsnZmfSewbgjYhmJDBUh3IZ44rD5VKmKOWBSSiUo opoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DCo6aTNMdA1MUUWSXCg9jLbRcmSxhLS4ADACXot9Yjg=; b=YE6YDvlH4DFZ6zZjCQxxyXKMyckD8TkzlBqVZjse5WG9PFRGKshXWLM69MlHXFNW+y 3ghKmihWShEMazAH26YD3Z4d1wv4dTgT1lgkUHrMLsZGmN6uBXKC71H69Nd/SKbyHz1K OY/vYKDoR/2MBmxTogfzJyKK2YbvTC5dyHTFFKURCdG+GRqyo5d7VzJsJNJV60YPaKHJ QkGGhz6b1VLjjdJNoW31dNbOlQNDDkyPH0dBWxSjJTC8ypKmbBlwvGu3CVrKVDz9gMl8 D0WMNSqW08hNx8dMOjxn35zNTMvyq+woDl4akLBMmV0lmDYPtlF9R1oyW4TqP8hATpKp S5ww== X-Gm-Message-State: AElRT7HYi3IOWD2U2m/pntlyiSkANpjFZD9qhdI51QlN3CYvRW0oRgzC ntZCdbNVaRbOdKeDOF7uwFVL2rcD X-Google-Smtp-Source: AG47ELuDzZOROMQarBaIoJ++4esqGaseKM44cKotYKc+RDh7m7KRVpVvyyhzjTIfzlROkQD3uV2w3w== X-Received: by 10.223.199.71 with SMTP id b7mr12971112wrh.228.1521534616860; Tue, 20 Mar 2018 01:30:16 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:30cd:91db:b00c:7949? ([2001:67c:1232:144:30cd:91db:b00c:7949]) by smtp.gmail.com with ESMTPSA id 4sm647640wmz.31.2018.03.20.01.30.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 01:30:15 -0700 (PDT) From: Fred Baker Message-Id: <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_73E6A377-C42C-4A1C-BEE7-078D6FA534A7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 20 Mar 2018 08:30:13 +0000 In-Reply-To: <731431f9-9014-b492-7561-389e61383f05@huitema.net> Cc: v6ops@ietf.org To: Christian Huitema References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 08:30:21 -0000 --Apple-Mail=_73E6A377-C42C-4A1C-BEE7-078D6FA534A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 19, 2018, at 9:33 PM, Christian Huitema = wrote: >=20 > On 3/19/2018 4:41 PM, Fred Baker wrote: >=20 >>=20 >>> On Mar 19, 2018, at 11:22 AM, Christian Huitema = wrote: >>>=20 >>> The symptom was, "why are you sending QUIC packets in the wrong = order". >>> The root cause was, packet was fragmented, fragments were received = in >>> different order than non fragmented packets. >> The question I would ask is "why would QUIC care? IP is a best effort = network, and will therefore reorder some percentage of traffic". > The Quic trial actually succeeded. The packets were resent, etc. But = in > that specific case the recovery used a strange code path, because the > out of order packet was encrypted with a key negotiated in the > "previous" packet. In any case, out of order transmission is not = helpful. No doubt. But the Internet is a Best Effort Network; by definition, it = can drop packets, it can duplicate packets, and it can reorder packets. = It is nice when they arrive in order, because that is the usual case and = the simplest code path in the receiver. But complaining about reordering = is a fool's errand. It happens. --Apple-Mail=_73E6A377-C42C-4A1C-BEE7-078D6FA534A7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlqwxpUACgkQEhdRnd2G P+AHlA//VkEfNYkVyHrMNT2wq4alcQ/bz9amgdpHzkWlZIDSJp6qowr4UOJTuTAP LNPxk19Y/jsGQn89LHjkhKwAY/h29Fl78DKytGdkZtN4Q997PipuoetVVCL1WmeY 873/3mibA1Fz9GdbaQV5CmZ4TCw2Hre4YhwkcKuqCuKMME3Eg3mRiiYRkPnXjAiW 2H0aKgbQwMtifl2eP50Tc+dot/sWNVk6mlxLpVfGTG0QsvPbV9HCD2wvjNi/dN7V qC/FrBOyy4HztdJ4iBQ+qScNwVjPvdxANOfnoL9wAwkm7zDSB4iRSljU61udpaVt +l+q6mLhAMle88fsBprRsRkuac/B+f83oFL7XAoLZtSTYDhqPFtT81zyUlvl5+R4 +8M2BEyChiNQWf6s4S9N+c2CJbP82iH0WkCZ1Rkv+vgQCwgs7Ixe+ApiQe6FcKdO Eg8GWDUWjBuzUQvCNdFd4TRBSms08/LKqHMFERHU1gofmjPYjsUNGloG7j1J07wS tbpYJ2xlW2/qQkWhuq//jVezsdq+DzahqzspyB0jDU9zZrcD/wFJObImI7lqvP8G Xp0ifG2vvLmGtyr0ZsgHszNOPvO55tYw8FnBA5OIPA5kVSqPVNyQCtzbJ05RhC53 9K69GH8XE5fjyNAah/0SOjwbQ/fa36AkGJ3yZ8C8kAw0sOhexgo= =JhQh -----END PGP SIGNATURE----- --Apple-Mail=_73E6A377-C42C-4A1C-BEE7-078D6FA534A7-- From nobody Tue Mar 20 01:37:28 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BD4120726 for ; Tue, 20 Mar 2018 01:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3Rg78w55xYf for ; Tue, 20 Mar 2018 01:37:24 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318361205D3 for ; Tue, 20 Mar 2018 01:37: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 1A03F41B67 for ; Tue, 20 Mar 2018 09:37:22 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0DEDF41B65; Tue, 20 Mar 2018 09:37:22 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id F39C914B10; Tue, 20 Mar 2018 09:37:21 +0100 (CET) Date: Tue, 20 Mar 2018 09:37:21 +0100 From: Gert Doering To: Fred Baker Cc: Christian Huitema , v6ops@ietf.org Message-ID: <20180320083721.GS89741@Space.Net> References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xaJmculcd5PV2weY" Content-Disposition: inline In-Reply-To: <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 08:37:26 -0000 --xaJmculcd5PV2weY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Mar 20, 2018 at 08:30:13AM +0000, Fred Baker wrote: > No doubt. But the Internet is a Best Effort Network; by definition, > it can drop packets, it can duplicate packets, and it can reorder > packets. It is nice when they arrive in order, because that is the > usual case and the simplest code path in the receiver. But complaining > about reordering is a fool's errand. It happens. It does. But the point I found interesting here is that it did not happen "every now and then" but for every single connection setup, which makes this peculiar enough to look more closer. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --xaJmculcd5PV2weY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlqwyEEACgkQ31bAZeTO f8XByRAArx+n4IrAzpPm/c9cGX3mtx/CbJj5DRdYiZEQO8tjYjmIgU5/2ZrV9z0z nqppuldmwNny42ce5KZf2TaJPG8rhz/Ju09dRKr0ikPjLjm269PY8xg3wprqaKR8 sudy+gQqNN+UzLOlB0Ejflc5g/u+qqGV2JlAHSTAQpNjZRMYXlcwx6kohfoRwrWF XSBqUmCSI4oc6aqRlgM5HhHWQ0vJ01M7PAoowuDZdj5GRtsfz6j/Yq4r+pkM5sqc DuWWcLX0TM2k60O8RO/GcwZTChdN1vxZd+NC1vmH4fuho/gnVv50C6ATUEk0YowT 92SkDpKb75/3ASkNI6mGv6r3k/J9apMTPFEhYLe+UAp8CytVSvxXrg1mBpgISlfL 4enLb9xwLbw15ObmT/7TkRGEMKDtWAoWfwqhc9uWg/iP2kNpy9LkxupkW0uqvVQ5 RGc1ggfO9XmVJZYGXd2Sv9NnYyMi8NIyyZUw48Wn5v6bk8KlrsovrS8a0h6fSBD2 wtabfS5+qJ4rcS7x7kpdBNslx1ISzgen1fp4bL2M4NfI/GmZauNnEBqON+0Anf82 Ks6dJ/AiM6BcFsrKdNIRfVCXblx0dE8Ca5lv2Em6yKiQjGLOVqCJE0FmfEjOKnNa UONVFCUDWYY//ykrA+EnNqoIY2pMFnoJDV/BBt8RjQsX5d+3f4U= =P7Tc -----END PGP SIGNATURE----- --xaJmculcd5PV2weY-- From nobody Tue Mar 20 03:51:22 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119E3126B6D for ; Tue, 20 Mar 2018 03:51:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq6ZPxC_HMrH for ; Tue, 20 Mar 2018 03:51:19 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 6F9671243F6 for ; Tue, 20 Mar 2018 03:51:19 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id v11so1026425qtj.6 for ; Tue, 20 Mar 2018 03:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xhVAS+pZEvFsRK2KqGXJirSC2urCKqIB/XEQeedIupo=; b=GRkak6wsmy3fkq8XyyIyjlPGt0g2xvh67IE0iX9UpR0jRRRvasnpExULhPMFoqoHMB eO+e6woCps3sVSV48O/+tsRzS9O3IsddYO9v92hVryTeCJXbSlHYGUMZWR/v90jnywAz S0F8NSjrchNb522yRS8G1X6+3DCY/9nXUVGq2h2V028gnp92h5wU+Q7uzQTqNKYDdxvE x73BgmMj9HcxVGdyX9PH9KLEDdYboQj7jvxTSj5863v/Ai/voMLDq95deALArjG08N9s mGmYluj5hZEy/FNG6DeEh1NDRKCCQgcNaomDX7EUmhPyLfAUaynnJtnU6FwXASmsa/VK dcow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xhVAS+pZEvFsRK2KqGXJirSC2urCKqIB/XEQeedIupo=; b=X0edlLU7D4rvjIIVVtsIHI/mVA4kWLZSWgucBGgaSoDfCulh2zSCYFUVrcZd8/B0tM fo6SQMJswff3MVLXWS/z0BWcBM1UjOncIAmj6gy027P6Xg28AHfXw5KHYNYIZwo1riyL pmDptmh7SqaukI2nL2hBCDn2TSSDE/bVyAXM6sxtMXT0LQBnKpVTB1cYjjLXKdEBPFot x0Q/jFvKaNa8xP1xIgL2Pk1patZF1hyvd/I+mtfS3V5CYHmMabzpUjIZpGRT57wKZZLT my2Lzs5KcNLb0SQUfSH927HoCIQ8m3rhBk7yeszVq+SHgsDwMTVpN2dwl4cQPKmSPgua kuJg== X-Gm-Message-State: AElRT7Hoj7JWSG2ZeuwTGoK8gpeX1V6uOqeRvPZX7Bxrc+j/XTV4Ii5e EF0JOiVEcMdO0zxu2WYnc1CRYEK+cIlwQSAuSxJRiA== X-Google-Smtp-Source: AG47ELsHj9mgadTF6KMt8uLPyRf43ubFIQRarOf3g7QcYnWD6jbkIiGb46sjD/JuJUSZ32AIHC7VS4/d6abb+wTSZt0= X-Received: by 10.237.37.50 with SMTP id v47mr23322624qtc.66.1521543078297; Tue, 20 Mar 2018 03:51:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.26.135 with HTTP; Tue, 20 Mar 2018 03:51:17 -0700 (PDT) In-Reply-To: <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> From: Tom Herbert Date: Tue, 20 Mar 2018 03:51:17 -0700 Message-ID: To: Fred Baker Cc: Christian Huitema , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 10:51:21 -0000 On Tue, Mar 20, 2018 at 1:30 AM, Fred Baker wrot= e: > > >> On Mar 19, 2018, at 9:33 PM, Christian Huitema wro= te: >> >> On 3/19/2018 4:41 PM, Fred Baker wrote: >> >>> >>>> On Mar 19, 2018, at 11:22 AM, Christian Huitema = wrote: >>>> >>>> The symptom was, "why are you sending QUIC packets in the wrong order"= . >>>> The root cause was, packet was fragmented, fragments were received in >>>> different order than non fragmented packets. >>> The question I would ask is "why would QUIC care? IP is a best effort n= etwork, and will therefore reorder some percentage of traffic". >> The Quic trial actually succeeded. The packets were resent, etc. But in >> that specific case the recovery used a strange code path, because the >> out of order packet was encrypted with a key negotiated in the >> "previous" packet. In any case, out of order transmission is not helpful= . > > No doubt. But the Internet is a Best Effort Network; by definition, it ca= n drop packets, it can duplicate packets, and it can reorder packets. It is= nice when they arrive in order, because that is the usual case and the sim= plest code path in the receiver. But complaining about reordering is a fool= 's errand. It happens. > Fred, That's true, on end hosts the biggest effect of OOO delivery should be that some protocol optimizations might be lost for those packets-- but that should never have a major impact on communications. For QUIC trial, it seems like that probably just uncovered a nice bug. One cause of OOO delivery is when packets within a flow take a different path which can lead to problems in itself. This happens in the case of fragmentation because ECMP might choose different paths between fragmented and non-fragmented packets. Also happens when ECMP is based on flow label and the label changes during the flow lifetime. Per definition of IP, packets taking a different path is not supposed to be a problem (i.e. the Internet is not circuit switched). But it does seem to cause problem for stateful firewalls, load balancers, and other intermediate devices that somehow assume flow semantics in the path. Tom > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Mar 20 03:58:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B1A126CD6 for ; Tue, 20 Mar 2018 03:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6-XARxqGCRK for ; Tue, 20 Mar 2018 03:58:45 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 54A75126CD8 for ; Tue, 20 Mar 2018 03:58:45 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2E326AF; Tue, 20 Mar 2018 11:58:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1521543523; bh=WVZcKycEY7FAhyAon3XTNZlj3Zzh//R6KsIoY6ikgBY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GN+x0bc77d+GLq0skQmPJ/GN6FuyKE16dkHZSkeFT9/y5DGHgLspJl15vYElqGEN1 U5JuDfCA+k4KkCHQMnlmrWDgcsFx3hfppSq5h57wJmgEWCHclsoaodYmqMaG2D3Lny YbGMF0ql5E9XFhBmchJRkC7b8rVXKUL87mK62xFs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2B8E39F; Tue, 20 Mar 2018 11:58:43 +0100 (CET) Date: Tue, 20 Mar 2018 11:58:43 +0100 (CET) From: Mikael Abrahamsson To: Tom Herbert cc: Fred Baker , IPv6 Operations , Christian Huitema In-Reply-To: Message-ID: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 10:58:48 -0000 On Tue, 20 Mar 2018, Tom Herbert wrote: > One cause of OOO delivery is when packets within a flow take a different > path which can lead to problems in itself. This happens in the case of > fragmentation because ECMP might choose different paths between > fragmented and non-fragmented packets. Also happens when ECMP is based > on flow label and the label changes during the flow lifetime. Per > definition of IP, packets taking a different path is not supposed to be > a problem (i.e. the Internet is not circuit switched). But it does seem > to cause problem for stateful firewalls, load balancers, and other > intermediate devices that somehow assume flow semantics in the path. This is another case of "please don't do that, but others need to understand that it sometimes happens, and try to handle it". Same as the IP fragments advisory, or PMTUD advisory etc. Network operators should try to assure that re-ordering doesn't happen, and applications need to gracefully handle when this happens anyway. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Mar 20 04:06:51 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB77E126CD6 for ; Tue, 20 Mar 2018 04:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eQfbhYqDeS8 for ; Tue, 20 Mar 2018 04:06:49 -0700 (PDT) Received: from jax4mhob01.myregisteredsite.com (jax4mhob01.myregisteredsite.com [64.69.218.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 6AF76124319 for ; Tue, 20 Mar 2018 04:06:49 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by jax4mhob01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id w2KB6lUX020484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 20 Mar 2018 07:06:47 -0400 Received: (qmail 23391 invoked by uid 0); 20 Mar 2018 11:06:46 -0000 X-TCPREMOTEIP: 31.133.153.83 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.153.83?) (lee@asgard.org@31.133.153.83) by 0 with ESMTPA; 20 Mar 2018 11:06:46 -0000 To: v6ops@ietf.org References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> From: Lee Howard Message-ID: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> Date: Tue, 20 Mar 2018 11:06:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:06:51 -0000 On 03/20/2018 10:58 AM, Mikael Abrahamsson wrote: > On Tue, 20 Mar 2018, Tom Herbert wrote: > >> One cause of OOO delivery is when packets within a flow take a >> different path which can lead to problems in itself. This happens in >> the case of fragmentation because ECMP might choose different paths >> between fragmented and non-fragmented packets. Also happens when ECMP >> is based on flow label and the label changes during the flow >> lifetime. Per definition of IP, packets taking a different path is >> not supposed to be a problem (i.e. the Internet is not circuit >> switched). But it does seem to cause problem for stateful firewalls, >> load balancers, and other intermediate devices that somehow assume >> flow semantics in the path. > > This is another case of "please don't do that, but others need to > understand that it sometimes happens, and try to handle it". Same as > the IP fragments advisory, or PMTUD advisory etc. > > Network operators should try to assure that re-ordering doesn't happen, How would an operator do that? Lee From nobody Tue Mar 20 04:11:03 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8343B126CBF for ; Tue, 20 Mar 2018 04:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCccY1-mH4Pe for ; Tue, 20 Mar 2018 04:11:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 73292124319 for ; Tue, 20 Mar 2018 04:11:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0DCFCAF; Tue, 20 Mar 2018 12:10:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1521544259; bh=jNEbmxKGgZmhPBMYHPgRsFD2wV6pPTcPdDjGhl8et9Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=on0TZVrz9sJ6fvwWnKRfFkUIAjhsYWSYxqn1RzvTSTw+Ureuls2UpKVwkVr8wtzQc 2TOIu9wFqcGefgRcmuogpOPu0lwtq1uF+Gboj8if1/jWICOe3NFLfq6p6lc6oxv/1m cp1wMBrT5gTSt64ecjWU1S0va3zXdAy93InAuhL8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0B9849F; Tue, 20 Mar 2018 12:10:59 +0100 (CET) Date: Tue, 20 Mar 2018 12:10:59 +0100 (CET) From: Mikael Abrahamsson To: Lee Howard cc: v6ops@ietf.org In-Reply-To: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> Message-ID: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:11:01 -0000 On Tue, 20 Mar 2018, Lee Howard wrote: >> Network operators should try to assure that re-ordering doesn't happen, > > How would an operator do that? Well, one way would to not configure their ECMP to be per-packet, and make sure it's per-flow. Yes, there is equipment where this is a thing, and people who configure it that way. So while there are corner cases where re-ordering happens sometimes for some traffic, but there are configuration knobs where re-ordering is going to happen a lot more frequently. Don't do that. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Mar 20 04:13:43 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A7D126CD6 for ; Tue, 20 Mar 2018 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZpJLODLmnOh for ; Tue, 20 Mar 2018 04:13:41 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198B8124319 for ; Tue, 20 Mar 2018 04:13:41 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id z143-v6so1893324lff.3 for ; Tue, 20 Mar 2018 04:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=glXEZp2qqopD8qystjEeeVmlA7SDzAxap+Oa1zDLfhg=; b=hByNr8e0OCv/swP4VMtF6keq2dnotIf0Xg8Lg6ly1/Z8xXnKA4VE2oaK1WgcvrZWgv XSTqXtZeKmW98x/MunmFuU4V5mBGH7ys1+rFTQs5fe+giXtW/1gL/5tMa9hzeYZCI7NE L5vmdhJxdUk39bVdW3+dvn0sv4MOokzyZb1tf9HrRwW2o2ziin2uIgF3Rq+hZliYDpia ax4C+Misno1fplUBqll602/fF0KyqRJHRJecPRZ7qu9uAN9O2RjBWaUWlY2nFk5xDadO iNm9xsuJX0ynjaqLCvBBqyJvqLh9NORPOhP/ktySSmMTUL9XkcnVyTxbG3tqeanT5pQx jgYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=glXEZp2qqopD8qystjEeeVmlA7SDzAxap+Oa1zDLfhg=; b=chA4B7K+43o+8GTA5D/zOGc+xWbOcSubMDbU2qJiws+UvigcUth3h4gLWoWJk4zPTy OwMxSkktI6Id5LgjFiQcDrKbZhvzdDXfvVU0jZbI+F7ILbJskZqyu3FBSvTJW4XixR3N bD/iE2ypnY8phCYzpT632hwptQKJTTCUz4izoYa41IYFPKJrLTUEdKlERBy6tfpd+kay aEN1zqYroqs0ji6SuM7ve72oXafbXoJkUxPnI9sgNk7wyjm/zyPqA1WXnJ+KFdQoBSkA 0nYhw7devMZpq5fKfnUjDGpb7zpfOWtK9EgfIjJaO7cllXP1H/+DNk7aNCFAczXC3R60 sQ4Q== X-Gm-Message-State: AElRT7FXkHTioh/GRqa/ZA9KcPdbi5yY68SYKCPtiAjplQ7FO2YWN+q4 OVRXG8aQ7UYQrG6Wtzoka/XOXJbd8FMqhw0b+Cbq8w== X-Google-Smtp-Source: AG47ELuc9uTjGywjzfGYpXGWVDb3xBeQENw9Ik3axyYBrFiwH1xhwyAJnsWC5rUsv7T1NyAkBbUOdRtrbKecRjgw7pk= X-Received: by 10.46.101.16 with SMTP id z16mr2582526ljb.72.1521544419249; Tue, 20 Mar 2018 04:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 04:13:18 -0700 (PDT) In-Reply-To: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> From: Jen Linkova Date: Tue, 20 Mar 2018 22:13:18 +1100 Message-ID: To: Lee Howard Cc: V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:13:42 -0000 On Tue, Mar 20, 2018 at 10:06 PM, Lee Howard wrote: >> Network operators should try to assure that re-ordering doesn't happen, > How would an operator do that? The trivial example: do not use per-packet load-balancing but use per-flow instead. In general - tune their hashing configuration to minimize the chances of out-of-order packets. -- SY, Jen Linkova aka Furry From nobody Tue Mar 20 04:21:23 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC8A126DED for ; Tue, 20 Mar 2018 04:21: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7AGWwr0TYgW for ; Tue, 20 Mar 2018 04:21:10 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A561B12E8D6 for ; Tue, 20 Mar 2018 04:21:10 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id s2so1116869qti.2 for ; Tue, 20 Mar 2018 04:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ctBcE5L99xsn2urs3YHNOdH8RPhX+DQu8tFTvJskt90=; b=qKKXtTTRce717/6QB2ZVRTY9eL32t4z8JfS1yYsPFrmyrF0UzM1nLewjjlo2KHJptZ BGqVfCuV55eySHHCKe9MvpjkH5tmhwrqgAnu+KUd05hR9UTylTwmboeV5yLly8msnepS k36lZSfexOQDfNahUGO9r5UdV+vmZ2HIFIgHtd+PDkP7NcLrxGSNRtxzAF4ncyF8NB+r TfWz74CU2fIaUy5HcwxfIJpivRXToBiLvZTcOG3JSPyYcIK/o7TU3PKls5o7fEwszVx/ hIMk3D7Yv74DrW16Fq2JzIz4EIBhKHmqUvIfrKrlJ4uQ1C8IckbOi4C+o1IUKaNf1bvB PJow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ctBcE5L99xsn2urs3YHNOdH8RPhX+DQu8tFTvJskt90=; b=rOS/MtOAraDCGKFUg/30EB1gwLb7S6RlaABvVRstDoNY8XceiRv9AcThaBQd7TOnb7 eEvrwd6ZRQBnG+vFD0EODgVZZCvzNaRo3Lsd3f9pnNGmYsBakdZuuv+h8YL/U/VTTkEA ZmgtTFVt9r7M1YhismMOfCjzBtvsSiVnYEq21hvLgOYeX3N7FXlySaKy1hSLXz+nJsAW YyBLJvKf3VEmq4HFXgKqoElmVrA1NzZ0KVHZCvvfdFkB5P/LCCeIN0eMydoA0Gf/O82F C0J0QMyJANcrJ/14cM9ePGwTZ/4WXhIpJCQNTjffJmLQ4Pjz2hT6B33GZhEx7C/7CuQJ UVng== X-Gm-Message-State: AElRT7El+Y2FISlwIl0vkXzuRMbBcWkXXM4NvVEBBMbosduB3qzb/jrN 45fexJNfwY0L8ohp0dnYyoMO3M4Z9qXVA4w/vfxH7A== X-Google-Smtp-Source: AG47ELvdmRo62s4ic/n24y6Yd/T2suPqhtoIbp4Flf4zosJ4h6odfIudfs58bTVLo8nO4+/RdN7r9RrKh3oxcQYTGM0= X-Received: by 10.200.1.142 with SMTP id x14mr22508691qtf.142.1521544869674; Tue, 20 Mar 2018 04:21:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.26.135 with HTTP; Tue, 20 Mar 2018 04:21:09 -0700 (PDT) In-Reply-To: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> From: Tom Herbert Date: Tue, 20 Mar 2018 04:21:09 -0700 Message-ID: To: Jen Linkova Cc: Lee Howard , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:21:16 -0000 On Tue, Mar 20, 2018 at 4:13 AM, Jen Linkova wrote: > On Tue, Mar 20, 2018 at 10:06 PM, Lee Howard wrote: >>> Network operators should try to assure that re-ordering doesn't happen, > >> How would an operator do that? > > The trivial example: do not use per-packet load-balancing but use > per-flow instead. > In general - tune their hashing configuration to minimize the chances > of out-of-order packets. > Jen, The problem with that is that not all packets for a flow are guaranteed to contain the same information or even the necessary information for computing a flow specific hash. Fragments beyond the first one don't include transport layer ports for instance. Tom > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Mar 20 04:23:57 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A0D126DC2 for ; Tue, 20 Mar 2018 04:23:55 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l6sf75JkQpS for ; Tue, 20 Mar 2018 04:23:54 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0267312D872 for ; Tue, 20 Mar 2018 04:23:52 -0700 (PDT) Received: from h.hanazo.no (dhcp-94e3.meeting.ietf.org [31.133.148.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id B0A752D50E2; Tue, 20 Mar 2018 11:23:51 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8B9F72025E53B6; Tue, 20 Mar 2018 11:23:34 +0000 (GMT) From: Ole Troan Message-Id: <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_E5B7BEFD-B5E0-4A86-90D2-B7A764A48136"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Mar 2018 11:23:33 +0000 In-Reply-To: Cc: Lee Howard , v6ops@ietf.org To: Mikael Abrahamsson References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:23:55 -0000 --Apple-Mail=_E5B7BEFD-B5E0-4A86-90D2-B7A764A48136 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> Network operators should try to assure that re-ordering doesn't = happen, >>=20 >> How would an operator do that? >=20 > Well, one way would to not configure their ECMP to be per-packet, and = make sure it's per-flow. Yes, there is equipment where this is a thing, = and people who configure it that way. >=20 > So while there are corner cases where re-ordering happens sometimes = for some traffic, but there are configuration knobs where re-ordering is = going to happen a lot more frequently. Don't do that. I guess this is more dependent on implementation rather than something = the operator can control. A good ECMP implementation should fall back to load-balancing on the = 3-tuple instead of the 5-tuple if MF=3D1 or fragment offset > 0. Or use only 4-tuple SA, DA, NH and Flow, if flow>0. Ole --Apple-Mail=_E5B7BEFD-B5E0-4A86-90D2-B7A764A48136 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlqw7zUACgkQvtpYqJhC 33ZhVA/7BAvuVSydqXWKPiAH7h8SGnrBDuZHKgWT2EO1+jgfuqrfxzIUEwBN90LH Aqba6+WXPouNFeIipxENtDGW6GO6VIaGZ7xbVY1KtC32Tn8tP+rYJjaPvimYCIsC Ty0505unuRQtr+qpFe0ab59QMMlHRL94HvPuqNOO7Qe8voB3R0hICk9jyvKJXvpA qD1TyTg8ZQBCJvDwo6u+tNlqI+oVu2+Fu2f8teCJ5MvPUFbks2bVpQG5rRNI7K7j qkcVYH3GQrVenmmu2PDfoI+GNuyr0cu7tH3OAr0eINNAkQxl9Z0RxpJ7jAgbRreG kRAqvWwjie6RddvJJUrRmQ3pluBozGGqvg7fG49bE5Cize2pUskOU8p+h12kF7h5 qnt6F2u/fdbiMpvNlJ0h5NzUe0pCDgKYkf9w8JSLhU4V/C4IGLfNm1nbr6W5QO61 Qh5yca0G4TAY6Xcqt8ek/nJ1KIJkIXlUjnddWy67ok9lI4uChu9X4TxuXCPySN+Z hpkJM1GoIcnn7rAdAaAS2kEmSh2825CNC1G3zdTZF/1WyrEagSLATZ1MxOyftVbL VKFHScOYc09NSmynXMZbqyvMzAfK6F+CWuCylR52Wpm4Zx/8CSIBRlmvGZJHvBW5 SPBH5ShbO5cd+iwGVT0VOMxGwgP1LY5an7n7JV7+NcUJ865BPqE= =DBZI -----END PGP SIGNATURE----- --Apple-Mail=_E5B7BEFD-B5E0-4A86-90D2-B7A764A48136-- From nobody Tue Mar 20 04:28:14 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E1A126DC2 for ; Tue, 20 Mar 2018 04:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbH9ayP0wZ43 for ; Tue, 20 Mar 2018 04:28:12 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 8AC3A1200F1 for ; Tue, 20 Mar 2018 04:28:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7F9644C; Tue, 20 Mar 2018 12:28:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1521545288; bh=kTreJu9XySg1kUI8MOH mdeES/p/qFd3FTuBU1IkrbSw=; b=Ei07YQkBZu+gEL9C0ZrW+ulld1EggTwjDQ5 WTC9vtFL/Xarf2eWWjb2vz9Q3COA5gEHQAUXmSP77oEdQiNvZACsKNRtbsgvrbK2 aO53NNvgRUd2114mG6IBlVQUiA8JxYYW9Th0ybB2aEh5HNDb7AIZpMJ31IlxEbrR zl+lBe0s= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H1YByfeMjW4o; Tue, 20 Mar 2018 12:28:08 +0100 (CET) Received: from [172.20.10.3] (unknown [31.161.156.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id DBE714B; Tue, 20 Mar 2018 12:28:07 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_890454AB-4512-4468-AA7A-1CE2124D7B42"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Mar 2018 11:28:06 +0000 In-Reply-To: <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> Cc: Mikael Abrahamsson , v6ops@ietf.org To: Ole Troan References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:28:13 -0000 --Apple-Mail=_890454AB-4512-4468-AA7A-1CE2124D7B42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > A good ECMP implementation should fall back to load-balancing on the = 3-tuple instead of the 5-tuple if MF=3D1 or fragment offset > 0. Which will cause fragmented and non-fragmented packets to take different = paths... It's only stable if you use the 3-tuple (or 4-tuple) all the = time. Cheers, Sander --Apple-Mail=_890454AB-4512-4468-AA7A-1CE2124D7B42 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEKBusetbVKSypyi4qHuGLwtPIfLYFAlqw8EYACgkQHuGLwtPI fLYSmwf+MbsGBv4fT4iNB+yonl8IruQ1MjqIN4aqdiS0PZ60C32JnzLTzNoRgD6T HU6RqbygmFqDITL6w3nfUJIDttw/XfwLopcAx78+WsDtwnMnOBQkTOz2OFlSbOt+ AaVngaiJzkIpYVSKqLx35nuM/kJJRohIW/0gWJrIAK48Ht2f25MZ/dLt/zswOjmT 2WtcfYcsK54Nv+b8kZbcEmVx0gIG60MN2NjKL9o6j9ujHO+1dZQM+LgJnkwdlO6Z YkhHDK1C2nTaDozxk41zyRTPGI0W4T30jWZ8tXPbi4RjXI00YIbBMv92DKkhJCLQ hNzleYl1rix/mNywZufV8czrbBy9fg== =uR3j -----END PGP SIGNATURE----- --Apple-Mail=_890454AB-4512-4468-AA7A-1CE2124D7B42-- From nobody Tue Mar 20 04:32:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDD7126DED for ; Tue, 20 Mar 2018 04:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmPRSMERRoCT for ; Tue, 20 Mar 2018 04:32:54 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 E6F36126DC2 for ; Tue, 20 Mar 2018 04:32:53 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id v207-v6so1955847lfa.10 for ; Tue, 20 Mar 2018 04:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yx3GyKZyDTBgSTFcOglQn20liS5+kDvRyKlo+M+788k=; b=FMmNMY2b1QNs1H0jNY0cxppgYZhv27gF8rAnPvr8i0ny/1zsM+Dg0UBTsJ4VRzFqMq lvEflaJVCDoEIPb8NPUZeimZ/sQr2w/tZIAA3/CHivacT6Qp+POa0/GEaW5faPU/19Cb dYtiAP3Zjbj2jmQJ0DC61klojaP+sptEW4UihY+W+paMmB9rXR/t0lIiIXePL6+RROhA AsR8gutalVfHNwsOZaapLZ3uFZPP5gAUzPVCGOw3m6hGEqHV4NFuax89PqlbvDwmdjt+ BrbBTfzZCWUp8KYh61HMtDc9l2TIP4hho4ZZf8EYLQmD+BJIgKHwOCNX51XTx3DooUlo 4K4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yx3GyKZyDTBgSTFcOglQn20liS5+kDvRyKlo+M+788k=; b=iDpEDpnM6l85gwbhYpSExx0y5cpaApT2WfPJvvJPt3ouYFM/pamqTNXY8RraB9YcCp wZxE9YkqTxM5QCn3UudQCk0LHWK2/I/NjHEY9EFQnBw3xMdPm7DHMI3wXGrX9BK5Bn6R OKLsk4E8bCyrN9fMwegYxFMtiQFeKQd7hnx4Ct4j9Gvds0WIzOa+3kCbzDvNUkbtZsTG 8eopB6wFLWSKcHAurN6pK2kIisn8/H10w4bMOkR4DijXyiSj3ntlegqe1lKmYJTu01dB 6v+7/PvlI2b1XvTSuY1U0IBLncAuUSZZk0MCuVU0dfiiD2SiIGP7Zk+3/axvStdvtkeP DYBQ== X-Gm-Message-State: AElRT7HZWXeiz6Lfuhtr1IlxZUaFpVgc1K0tjswLE2TnDDeDHc53Bftr CCH06pI02fqKjy1eP97Np7SbYzb6b7mZIRSU7udAFjDc X-Google-Smtp-Source: AG47ELtVy0x7bhPgGFcE6aHLXcAaAasZBDOYUT1e7AyDRM3mqzuLE+W0ICjNGGxd1JrbB6Lhi5h/STU2ODt7gGT5U8U= X-Received: by 10.46.101.16 with SMTP id z16mr2629359ljb.72.1521545572155; Tue, 20 Mar 2018 04:32:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 04:32:31 -0700 (PDT) In-Reply-To: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> From: Jen Linkova Date: Tue, 20 Mar 2018 22:32:31 +1100 Message-ID: To: Tom Herbert Cc: Lee Howard , V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:32:55 -0000 On Tue, Mar 20, 2018 at 10:21 PM, Tom Herbert wrote: >>>> Network operators should try to assure that re-ordering doesn't happen, > The problem with that is that not all packets for a flow are > guaranteed to contain the same information or even the necessary > information for computing a flow specific hash. Fragments beyond the > first one don't include transport layer ports for instance. Indeed. There are other cases (besides fragmentations) when packets might arrive out of order, at least for short period of time. I do not think we can 100% prevent out-of-order packets. As I've said, operators should do their best to prevent it in most cases (== have sane config on the devices). -- SY, Jen Linkova aka Furry From nobody Tue Mar 20 04:34:33 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38341126DED for ; Tue, 20 Mar 2018 04:34:31 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SShe5Q5qnK6U for ; Tue, 20 Mar 2018 04:34:29 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7B6126DC2 for ; Tue, 20 Mar 2018 04:34:29 -0700 (PDT) Received: from h.hanazo.no (dhcp-94e3.meeting.ietf.org [31.133.148.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 767EF2D5064; Tue, 20 Mar 2018 11:34:28 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A142A2025E63CC; Tue, 20 Mar 2018 11:34:26 +0000 (GMT) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3BACA667-772F-4021-AC2A-BDA45D329341"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Mar 2018 11:34:25 +0000 In-Reply-To: <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> Cc: Mikael Abrahamsson , v6ops@ietf.org To: Sander Steffann References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:34:31 -0000 --Apple-Mail=_3BACA667-772F-4021-AC2A-BDA45D329341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sander, >> A good ECMP implementation should fall back to load-balancing on the = 3-tuple instead of the 5-tuple if MF=3D1 or fragment offset > 0. >=20 > Which will cause fragmented and non-fragmented packets to take = different paths... It's only stable if you use the 3-tuple (or 4-tuple) = all the time. eh, no? It will use 3-tuple for all fragments, including the first. Cheers, Ole --Apple-Mail=_3BACA667-772F-4021-AC2A-BDA45D329341 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlqw8cEACgkQvtpYqJhC 33YMUg//etf6bRFyVbt99dL+Nk7qyINcLEM85f8wtXM/AOSbrA4BODHl0eFCJX1V 2mACU13d5G8jV0nE+7+PyRc0X9OU0wLGKDzI2DM+fZ2Y3w3WaayfS2tQOvP95yfz thXYhOiEBfCm8/QpMELVa5Exq9fBhIyoAG3jUsJOFPGDv+8Rp/sgOQP+CUi2AWjG bpmdb1VTJTUdpMqfJYkX+u6rKuKosFrc/vtvqzDi37U8DgEywleGtPBdLglcYDJk VVtuCTl2Ip7J8bSds4p+Q7AI0EQ12HTkEf5PbFVwqgHV92yir4zPZ9fWcqFomPGO 33KfTri8dI9dZOQXWsKPibLFNB5FDvrVJQRg1/wuBBfwx46SMuBPy04jsH6yyVOH VftrHuRP0nqudCkd+A/1VgcVBV/tguQHbDMce2fssRJCiWbC0KaG6IfZc006uiCM fwznoFWWswYVu4VRhVbQ9bd7wtQYm603RQBBSkHM1XMHQBRQq92gAr1OSw5HR4yI sHVmcx6hfAIMsjKbM+uvDoh2cv9ruoVvDKqwG89XHMuSQN4bxDP7l9lOr28OjLXB xXmar3DmkXFL7/VJrKuHT7XYNT4APW4JHMSnd5FMEPSMzUnKkRzxP0oNIvpmvj1L fqfHsm69WcViujLyGrAq8sXu1nlfbrybaObNM1oJpir+tp8h7lM= =yYt5 -----END PGP SIGNATURE----- --Apple-Mail=_3BACA667-772F-4021-AC2A-BDA45D329341-- From nobody Tue Mar 20 04:36:55 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A59312D892 for ; Tue, 20 Mar 2018 04:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2XUDDsp3s3f for ; Tue, 20 Mar 2018 04:36:52 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 42CBF1200F1 for ; Tue, 20 Mar 2018 04:36:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 1414C4B; Tue, 20 Mar 2018 12:36:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1521545793; bh=lECSlFMSXh9483tG8XV QTjSBkVgwb2/BfB5SsYfNdRk=; b=OH5dYAB1tmIwRqx+EGVOQPnfSr+rhfgD3Sl PbVH6nO3iLN3heZKpw611tEG7BEpxrBBk14NCK08XKNMnRbC/8jKHd7xq03uysMf c6swJI48OyrK5JwMm1btEy8QebenYRTwIMNrfjDz5kFLMuS53ZHle7/yxAmNBQeN /h0rVaKE= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 77NpU7czvHXR; Tue, 20 Mar 2018 12:36:33 +0100 (CET) Received: from [172.20.10.3] (unknown [31.161.137.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id D5E524A; Tue, 20 Mar 2018 12:36:32 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <7B8BC336-33C8-4716-8079-EB3433A0CE0E@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_C523D520-DB24-4D75-9E5C-768407221AF6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Mar 2018 11:36:29 +0000 In-Reply-To: Cc: Mikael Abrahamsson , v6ops@ietf.org To: Ole Troan References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:36:53 -0000 --Apple-Mail=_C523D520-DB24-4D75-9E5C-768407221AF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Op 20 mrt. 2018, om 11:34 heeft Ole Troan het = volgende geschreven: >=20 >>> A good ECMP implementation should fall back to load-balancing on the = 3-tuple instead of the 5-tuple if MF=3D1 or fragment offset > 0. >>=20 >> Which will cause fragmented and non-fragmented packets to take = different paths... It's only stable if you use the 3-tuple (or 4-tuple) = all the time. >=20 > eh, no? > It will use 3-tuple for all fragments, including the first. What about non-fragmented packets in the flow? Not every packet will be = fragmented. Cheers, Sander --Apple-Mail=_C523D520-DB24-4D75-9E5C-768407221AF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEKBusetbVKSypyi4qHuGLwtPIfLYFAlqw8j0ACgkQHuGLwtPI fLbAnQf/aPoNMbQuWAbTc3AuCoAe8QQ9kvFh8iLkAVRbnXUccVcsg57M1K5zeGly KU/HEn3mGc/xRZq8s7BRSbEySY2eOojoseOlx/x3RMc8xbxXakwke7E7kurk+gB7 mfsywPMfzOA3KKai06dH3iYV9xsMXb46hkyDCk5+zc9Ub0KXYqK0M+ZTTRpz9MmN m7ARE6+kWF0nF1K9uMAxMmJdDV2BarSNFRqNAPUyIcjUNaOATc3OhJqEQS5tH+pj hTEwM5MVkbpx9ZZwrK1MO4wNE5L93xXMCRxrcEuBBKuDP88iJdJJkUb6ooFxdpYy yTTMV9iHVayCjySUMr3IiJKYo66jRQ== =uSjw -----END PGP SIGNATURE----- --Apple-Mail=_C523D520-DB24-4D75-9E5C-768407221AF6-- From nobody Tue Mar 20 04:37:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F362512E8F1 for ; Tue, 20 Mar 2018 04:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9omNkPATTR5 for ; Tue, 20 Mar 2018 04:37:44 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 9282812DA54 for ; Tue, 20 Mar 2018 04:37:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A9C9DB0; Tue, 20 Mar 2018 12:37:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1521545861; bh=7oCI4OuT3qXPBLQwa1aUgtjXoTUnXcMPZmQ0vw1TTus=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vYi5N6jJyxj54kjw92ElAE2Hcw8jc6V0wBLkwgY+5sAB78xS3VrQsiz0Y+3R79+uB AOYNwCwBayRJQ+/IzDf79eexq7miBaKT+P11c0awaLrDPJKerwSjcmNm8Te20yFARG 6tAsaJRrXyn2GZK1MobGe1NBGQ7sZp33MDKCe46A= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A5EC3AF; Tue, 20 Mar 2018 12:37:41 +0100 (CET) Date: Tue, 20 Mar 2018 12:37:41 +0100 (CET) From: Mikael Abrahamsson To: Ole Troan cc: Lee Howard , v6ops@ietf.org In-Reply-To: <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> Message-ID: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:37:48 -0000 On Tue, 20 Mar 2018, Ole Troan wrote: > I guess this is more dependent on implementation rather than something the operator can control. > A good ECMP implementation should fall back to load-balancing on the 3-tuple instead of the 5-tuple if MF=1 or fragment offset > 0. > Or use only 4-tuple SA, DA, NH and Flow, if flow>0. In my example, this isn't even about fragments. There is equipment out there that can be configured to do ECMP per-packet, and not even try to do flows. Much less try to match fragments to a flow. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Mar 20 04:43:11 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7822D12D887 for ; Tue, 20 Mar 2018 04:43:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH_DotbVzY_e for ; Tue, 20 Mar 2018 04:43:01 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBEC126DFB for ; Tue, 20 Mar 2018 04:42:30 -0700 (PDT) Received: from h.hanazo.no (dhcp-94e3.meeting.ietf.org [31.133.148.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 94A392D5064; Tue, 20 Mar 2018 11:42:29 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C74E92025E6B1D; Tue, 20 Mar 2018 11:42:27 +0000 (GMT) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E9D7CC42-E978-4E4F-A3B4-63838F782FD1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Mar 2018 11:42:26 +0000 In-Reply-To: <7B8BC336-33C8-4716-8079-EB3433A0CE0E@steffann.nl> Cc: Mikael Abrahamsson , v6ops@ietf.org To: Sander Steffann References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <7B8BC336-33C8-4716-8079-EB3433A0CE0E@steffann.nl> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:43:04 -0000 --Apple-Mail=_E9D7CC42-E978-4E4F-A3B4-63838F782FD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>>> A good ECMP implementation should fall back to load-balancing on = the 3-tuple instead of the 5-tuple if MF=3D1 or fragment offset > 0. >>>=20 >>> Which will cause fragmented and non-fragmented packets to take = different paths... It's only stable if you use the 3-tuple (or 4-tuple) = all the time. >>=20 >> eh, no? >> It will use 3-tuple for all fragments, including the first. >=20 > What about non-fragmented packets in the flow? Not every packet will = be fragmented. Yes, that's true. But the fragments should be kept on the same path, but = no guarantee that the set of fragments and non-fragmented would follow = same path. Cheers, Ole --Apple-Mail=_E9D7CC42-E978-4E4F-A3B4-63838F782FD1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlqw86IACgkQvtpYqJhC 33Zp+g/+Ij7bHau6J1BKHKVHUpugyIh0/gHLCnTO0RGreFTAFy/fa4g3GiIqP7lA R2NT0GYhNItnU5iRGfpDflZBuNc2vP228R9vjq47lq2eUfTEdoGhsGBVvUTyo2D1 wddKSsFzmH81Sgeao0eeBrxd8sxayDDqsQ+AqZU1f2KfKj7zwJZuPjGQhafp4mMY NXdJP+T+dbLC/GJmlrfA37s7+Qz3kfgL6gnwzSXT2a6D+tFxDtaJsmQVDDhzXRCJ 3EqFIrrf4SoHpjj0Nt0iV2Dsb8pxZtpKx99cUpCd5fTOv4FKgkL4UmEMeY38S8Nn wEKdKJFl1haK5YfJrg6DUasbStIjIJPxHPwPSk43AwA5xIE3YEQ1fTxzouE5wvzN boNGFzXAp2cv1M4c4zQGre62i3I7XBaHMLpjxGf39RRq76Sr+ISwKVlXiSxkXZgc 9MhdZJsbHoEbrnbYqqGnvFWyrmxDIrNqN075SVDtnSg0fa3iY35Vvulyp7iF+VB0 DwXZGGXzRX/FelZkqK0Hn+6/ouDZZYcyjKFGg1H0o4On5hxGK5g3BFs2zVtjGfMN ZHmmmihxIYmX0YlfrrvjErKzWPPszhhap2DnpX+y5Oj0syZbEBbXdYwjycTexjqw H75m18IDkhCv6VQFULutLVWQBxOuBC2RaqeCf5OQ0esF1dK3V+Q= =ovlE -----END PGP SIGNATURE----- --Apple-Mail=_E9D7CC42-E978-4E4F-A3B4-63838F782FD1-- From nobody Tue Mar 20 04:44:11 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B580126DC2 for ; Tue, 20 Mar 2018 04:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA_mGS2OgIda for ; Tue, 20 Mar 2018 04:44:08 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (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 AAAF712EAF6 for ; Tue, 20 Mar 2018 04:43:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4FFA54B; Tue, 20 Mar 2018 12:43:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1521546220; bh=hSGam2QjkHPljd9co90 23GWqyHEfgDAQtifOfGyRkyE=; b=GzlE8iRR/AzX14YlOLgwUD96jyoj/1kwjVE 7Jl/D4QyC6j8n9vaZkvuYsTeT1C253YQPEQHdy4Ulp+NoOgNMlYQQnf3z7YoO2o+ wu6PJd+1mX479m7Z6wZ+HVa8Q3tihu8UpMtYV+wRdXC1K3xEiXiJRgHf+pX7zc/+ nm275K2g= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Tt_RXJ83DOxK; Tue, 20 Mar 2018 12:43:40 +0100 (CET) Received: from [172.20.10.3] (unknown [31.161.137.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 8A8454A; Tue, 20 Mar 2018 12:43:38 +0100 (CET) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Message-Id: <09FA137F-4175-4A92-933B-88DDD3D371F8@steffann.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_85E961DD-A1C6-479A-9A9D-16CFFB41D6E6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 20 Mar 2018 11:43:36 +0000 In-Reply-To: Cc: Mikael Abrahamsson , v6ops@ietf.org To: Ole Troan References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <7B8BC336-33C8-4716-8079-EB3433A0CE0E@steffann.nl> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:44:10 -0000 --Apple-Mail=_85E961DD-A1C6-479A-9A9D-16CFFB41D6E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > Yes, that's true. But the fragments should be kept on the same path, = but no guarantee that the set of fragments and non-fragmented would = follow same path. Indeed, and that can cause out-of-order delivery from the application's = point of view. Cheers, Sander --Apple-Mail=_85E961DD-A1C6-479A-9A9D-16CFFB41D6E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEKBusetbVKSypyi4qHuGLwtPIfLYFAlqw8+gACgkQHuGLwtPI fLZc0gf+LFD39up6yky4QnDOpGftEr95E/pM7uX2lwKnHIVIb/z+ilF+0SlmU9qR fmeqJMTm5QnEj5Yz12M69H8cF1zkXGQZDfuUYjkDg8fcQb9q8BW5LfOfuD8Xtnxn byr7qtUI7I/9pBeH++qBJLnCRwTGM1uR3FzGmgecnUeyCavv7Tlb/KxznGPB+zIy +avza8kW220xJt8i7OCx/NBtnRf9ShxMrj4cbGwazfzcc3OwxP17hU/MQ0FWYPLx zS1F1waV/RB4VGqrmRzp5T/2IorDt30EoE08CYQYyr8Q+cMBEAo1OH8KOlEk2my2 pdIrn8scCFpPUT8uibJmhAYE12feVA== =HnqX -----END PGP SIGNATURE----- --Apple-Mail=_85E961DD-A1C6-479A-9A9D-16CFFB41D6E6-- From nobody Tue Mar 20 04:45:26 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCC1127078 for ; Tue, 20 Mar 2018 04:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0w3Pg21huie for ; Tue, 20 Mar 2018 04:45:22 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 12061126DED for ; Tue, 20 Mar 2018 04:45:10 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id j73so1216324qke.6 for ; Tue, 20 Mar 2018 04:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zY4HrkX1f1MC2PJ7d2UsZSHeubgUS7GJmGF0aCxgO9E=; b=QBdhijQBC5mb2bEQymmbfwq0r5Zg1BfxQtHq8lX8m4A8QoA2dGXZtLrHLdFwkaB8nT 2Crwgex38ZkzrzCSNuYCyLUZviqHoxDbdErhshFwjP9YDaYS4/OKYZcZxHH1fQ0v6AC8 mZ8ouXF39tKhiTm+Kl1GvpO+HwqiGJUcdaD66CqVHgUyuikeqrd9KkB0y7AtuclefxF6 KCBvbyhWHAxpZhCxQasW7ylPRo/61zlL2ucbF5CZpiUrCCy56MFC3pbsufk9xyJUxEOj i3BoVJhp8Sklg0I0cioCJjcIfpLcPovQ0xoS67doNWdhKXI93NYDSEr8SLf7E2taRN8r tjsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zY4HrkX1f1MC2PJ7d2UsZSHeubgUS7GJmGF0aCxgO9E=; b=nOA01qJSXCgZg8/mPS6V2VvcUJ0H1p0j2lpykwHIRbWxTTJq+K6vbH2ghnCV31GM2K ViUqGqViVe0XHvG1Tf9s5YbbE+vQiG95yz4YPe6ijSTyOeD64MSxHPX6OnoRYN5QtSLg wpQyz4h6OLwipz0pEX8WMojzrKaqiJg8jwnt6ta69IzdN2DL+1ku5065GEZH/NdSbjsL 9W6tyNSWlt5Bp6YvU7wchJMSH4A2+alnMTaAilcRl6UwshkCVMiKw6TwW/BPsAxG9etM evIor3AehdjevqJzV9sqbFaaSciRuY6jpZ4hcSqR9Us52KZI6FmLpPG1HLl4CPz19Nmr Vyvw== X-Gm-Message-State: AElRT7EJI+U18hoIbvHs3AsqlzEv5Gdg3exUyGKrA7R29Vl00OkKTwb+ IsMrx/0Dg63XBb0Qu29xaQiskpMhiDZ/v7P5oq5raA== X-Google-Smtp-Source: AG47ELv0W7RLNnu9+NSVjScGoe2t21OdehTFmLdUHZQl8MEkxWBMaUIAHFH6g7jhLkI9LBJtkjmE7ag1OQ/fUn8ePRk= X-Received: by 10.55.75.205 with SMTP id y196mr2962506qka.44.1521546309039; Tue, 20 Mar 2018 04:45:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.26.135 with HTTP; Tue, 20 Mar 2018 04:45:08 -0700 (PDT) In-Reply-To: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <7B8BC336-33C8-4716-8079-EB3433A0CE0E@steffann.nl> From: Tom Herbert Date: Tue, 20 Mar 2018 04:45:08 -0700 Message-ID: To: Ole Troan Cc: Sander Steffann , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:45:25 -0000 On Tue, Mar 20, 2018 at 4:42 AM, Ole Troan wrote: >>>>> A good ECMP implementation should fall back to load-balancing on the 3-tuple instead of the 5-tuple if MF=1 or fragment offset > 0. >>>> >>>> Which will cause fragmented and non-fragmented packets to take different paths... It's only stable if you use the 3-tuple (or 4-tuple) all the time. >>> >>> eh, no? >>> It will use 3-tuple for all fragments, including the first. >> >> What about non-fragmented packets in the flow? Not every packet will be fragmented. > > Yes, that's true. But the fragments should be kept on the same path, but no guarantee that the set of fragments and non-fragmented would follow same path. > RIght, and that is going to be a problem for network devices that expect packets in a flow to always take the same path. Tom > Cheers, > Ole > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Mar 20 04:52:00 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FAC127078 for ; Tue, 20 Mar 2018 04:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZRSoZX0s1o3 for ; Tue, 20 Mar 2018 04:51:56 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDE51271FD for ; Tue, 20 Mar 2018 04:51:42 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id y2-v6so2063695lfc.5 for ; Tue, 20 Mar 2018 04:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gWN9ExW6DMPnQSmnanXWmitPdH8lH0BRT3nX+DLoQIg=; b=WlnZDtOryQzdbYO9nzrcb1MGsN75JJ1myKVmkVhONStip/XZ2oCfH5TaNi5lH3ewp/ OcyOzaaLmUAXd2svLFiU7mKFXpD/ElbgNjVWC31IJrN5lZ97X9HQozYlZzi64zp4eHX/ Y0wO0GnJLoAOZt8VSR+fKdyPl4l875IMsPDbWQLEEQ1qfhPN1aNH57cD6sBJ1SpvRN8v tR7a3eUv7wsa8tHLojhHNlAw+mFTDW/mWBkSQZNfDatv7C33UDYEroq41jZbidtzH4Pe KgWQ9t6shb/82Q2kTvFfXgo0NUWI0bX06b5o9vqM+3xxVupDq22UmeXor4KYkRrm736u hH0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gWN9ExW6DMPnQSmnanXWmitPdH8lH0BRT3nX+DLoQIg=; b=W2DJvl0b7bfwJONYPgqwRBTrv11SOWFZ3W123JozA3ciD8YPwQTyBpbCk081ckVnWO IUxVlHOigaHBgvt91KJlBg1IQ45Urbkn+xGxNwkG4ICksOUo18SijboWvLXk56Zipb9K R2Ydi+Dt+2giSdn3rMdWfJhWaUj7L4mmXasQS58BFqNtnjlIjya9adVjIfhDk3ydErGE zft0gF8xqWPoWHCjugWTsch0Q9SDxppeI9oFy8sk+vk4njVemcLwPeYOgTzpAeMNoL8Y gXQc2rBpw0A8XOHFH5bqVrHW/gNXv/Lu69HZbamzqUJMoXBc1XnljrWr83BJEnHjhDYx vLnQ== X-Gm-Message-State: AElRT7H52VT5XSdUEm7oC5SucqgsxJ2N8X/KlUKUSF5sBRMKzTQd3F3T 2WDHwqmEGnnrrirKJB175cL99QLKDEmgm9iYTcqF/acM X-Google-Smtp-Source: AG47ELsA0jok9X5dSG9ocZDYMMS81xdPwPV/UNbmLq7DWpLugUZDV0HTcSszfdAcdmJBhM+HzYJYXYuu/71dhKXAg9M= X-Received: by 2002:a19:2044:: with SMTP id g65-v6mr8978730lfg.0.1521546701028; Tue, 20 Mar 2018 04:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 04:51:20 -0700 (PDT) In-Reply-To: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <7B8BC336-33C8-4716-8079-EB3433A0CE0E@steffann.nl> From: Jen Linkova Date: Tue, 20 Mar 2018 22:51:20 +1100 Message-ID: To: Tom Herbert Cc: Ole Troan , IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 11:51:59 -0000 On Tue, Mar 20, 2018 at 10:45 PM, Tom Herbert wrote: > On Tue, Mar 20, 2018 at 4:42 AM, Ole Troan wrote: >>> What about non-fragmented packets in the flow? Not every packet will be fragmented. >> >> Yes, that's true. But the fragments should be kept on the same path, but no guarantee that the set of fragments and non-fragmented would follow same path. >> > RIght, and that is going to be a problem for network devices that > expect packets in a flow to always take the same path. What I've failed to understand for far is why do those devices have such expectations in the first place? Out-of-order packets will happen, have expectations like 'all packets on the flow are on the same path and arrive in order' is unrealistically optimistic. BTW another thing operators could do to minimize the impact is to ensure that their 'equal' paths have similar RTTs. -- SY, Jen Linkova aka Furry From nobody Tue Mar 20 08:01:52 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62B6126DEE for ; Tue, 20 Mar 2018 08:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSFHROKayCEt for ; Tue, 20 Mar 2018 08:01:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F41E1200B9 for ; Tue, 20 Mar 2018 08:01:41 -0700 (PDT) Received: from MBP.local ([IPv6:2601:647:4201:9671:888a:f93d:8ae3:71d1]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w2KF1bOh058357 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 20 Mar 2018 15:01:37 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9671:888a:f93d:8ae3:71d1] claimed to be MBP.local To: Jen Linkova , Tom Herbert Cc: V6 Ops List References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> From: joel jaeggli Message-ID: Date: Tue, 20 Mar 2018 08:01:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 15:01:44 -0000 On 3/20/18 4:32 AM, Jen Linkova wrote: > On Tue, Mar 20, 2018 at 10:21 PM, Tom Herbert wro= te: >>>>> Network operators should try to assure that re-ordering doesn't hap= pen, >> The problem with that is that not all packets for a flow are >> guaranteed to contain the same information or even the necessary >> information for computing a flow specific hash. Fragments beyond the >> first one don't include transport layer ports for instance. > Indeed. There are other cases (besides fragmentations) when packets > might arrive out of order, at least for short period of time. > I do not think we can 100% prevent out-of-order packets. > As I've said, operators should do their best to prevent it in most > cases (=3D=3D have sane config on the devices). The point is not to avoid entirely reordering which is implausible, it's in general to avoid pathological reordering. A case where you reorder all initial and non-initial fragments would certainly fall into the case of being pathological. If you were to apply qos policy based on transport header policies the non-initial fragments could well end up in a different queue. From nobody Tue Mar 20 11:19:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356B4129C5D for ; Tue, 20 Mar 2018 11:19: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNo0jSWlrBG3 for ; Tue, 20 Mar 2018 11:19:32 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 4E250128D2E for ; Tue, 20 Mar 2018 11:19:32 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id z8so2696316wrh.7 for ; Tue, 20 Mar 2018 11:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ftr/XDN6gxxKwiNpNhrpLvNfuuoA3RwPjJjUiMXRr3Q=; b=MfICIvj2rOA1uO3OOe0VJLyBAKCwrwJXzs+YX0TjF3leI8NWVovCr86St1/tL0fMdT kXQksC0ZDEwK0UK4GCdEa46YqZCtdMfJwZTaQHMfyYYQtBisXJbKedhv39l+VcwqyZGn tKZaAuiyb3oFjVqmsCfEeAcKA3SlSP12hCpHGB6cdwKI495+KX1dFhratL+5BVCjvtdI cQYX/nQFKoHtSz+982XmpLy5rV7ianBcx4/yRfCij0TXsz+TAFT1549+3ZaQqcvD5F/N VcwRC+9DmEk9oFTVhuyfwIMRz0d/HY7HAAma8V0euBIuruq3LJ4b1vWWNhUsmnkLW3Zr m9eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ftr/XDN6gxxKwiNpNhrpLvNfuuoA3RwPjJjUiMXRr3Q=; b=MBmQR3cJ18fbQv0Jkhix7Wh64IsXmMiP9pPy9uFBPVqALvMcoslSDXuFPCURTQVp7D NbKKHjdVb+fwAtyz8cudW21RTeBuoZ5jviufoBIGs+0Y+Vd+O3no5Ecugb8PHZY/4ddt ssgoPDlsz9IcJSf2ftpf48ZCdGM9XNZgml0fzIKQF6CVWNkUK3qCX8UvcRyXt1SmIzNY psM/ob3ait5m13WrhZOrKEfT3Znu2Pxm47EoteJ8ihAk2XspM0XdNdSHsVvBJluv3IcM tgBlXzqT3TiHgMlw2Qc8LgQ6cbXSsp5sIIlg6xGDzET+AYTsPcEt0tUZplozccomoZZu Zn4g== X-Gm-Message-State: AElRT7FyI6ce6C8qe+Z2QezqZzQLRAqgtqd0l2DeCCKUH0q99lSe90ps +LY1EdepRjdUnFpU89CmSY8= X-Google-Smtp-Source: AG47ELuiufPLmiP6ShrgU3jH1+QEMcjKoUwX1AZIp3I72br4tuw1W9VmIRle9GnWehSjPR55dXc4xw== X-Received: by 10.223.173.197 with SMTP id w63mr14899846wrc.83.1521569970912; Tue, 20 Mar 2018 11:19:30 -0700 (PDT) Received: from dhcp-94f5.meeting.ietf.org (dhcp-94f5.meeting.ietf.org. [31.133.148.245]) by smtp.gmail.com with ESMTPSA id 124sm370792wmv.19.2018.03.20.11.19.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Mar 2018 11:19:29 -0700 (PDT) From: Bob Hinden Message-Id: <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B83F4AE8-8494-423B-8E3D-B9337DAFC805"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 20 Mar 2018 18:19:28 +0000 In-Reply-To: <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> Cc: Bob Hinden , "v6ops@ietf.org WG" To: Sander Steffann References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 18:19:34 -0000 --Apple-Mail=_B83F4AE8-8494-423B-8E3D-B9337DAFC805 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 20, 2018, at 11:28 AM, Sander Steffann = wrote: >=20 > Hi, >=20 >> A good ECMP implementation should fall back to load-balancing on the = 3-tuple instead of the 5-tuple if MF=3D1 or fragment offset > 0. >=20 > Which will cause fragmented and non-fragmented packets to take = different paths... It's only stable if you use the 3-tuple (or 4-tuple) = all the time. As well as the first fragment and subsequent fragments taking different = paths. Hence why we wrote the draft. Bob --Apple-Mail=_B83F4AE8-8494-423B-8E3D-B9337DAFC805 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAlqxULAACgkQrut0EXfn u6gdswf/cVm+OKL4nqseGs+meR09LXZw8PGYnruJyqaQvWvVGGdnI19ZOuXOGdUZ iMwvAard3jNYiEZj2VssO9nS9Fbm8NUyZtyPxwbIn/stJTT3r2ZRNeQ84lX+KtZW H6yDKE5AzabsoU5M6F20S1tzuTN5ASz7OsRoZRxahzTTWylj2LNDcYL2Kb9Ph6Un X9FJgTGUO22YBaO+BRR9GnEs8AVKrCllYEFnYtrNVnaYci0+aPxADdvz+dlMR08Y ArSDA9gRZdPAcny4heGeAnhdvnlPenQNoIMvRoV+NJfILFvpVrwUs6zz0q7ILV2f ZtSA1I/vEp+LIiddgGkghFG4dGVN+g== =vLx/ -----END PGP SIGNATURE----- --Apple-Mail=_B83F4AE8-8494-423B-8E3D-B9337DAFC805-- From nobody Tue Mar 20 18:33:45 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C9412D876 for ; Tue, 20 Mar 2018 18:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1l7ttH1l2tm for ; Tue, 20 Mar 2018 18:33:42 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 304C41241F8 for ; Tue, 20 Mar 2018 18:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QoMwa6saXubs8vcE+igUB5LI0Q0Hdkvvgf48b81+CI4=; b=WleZtFglHx48iwu5fLWJAnBcj7 URWktwAcr1NYAT4SpOlxK8jzLaow16Cmg9XKBdQm7npYStwwIcETc0jYN8ZgUN1bpyWMzk0cGgCFb fokygamA7JyGyLldBltKeT8feydMPBGR13zytKZL00W9GRCNlzoicTg7Hr72K5JY2y4sF1boR8QTN V6GkMnkWmFxFcgVhUc15dX9BGnK36lrK/Ba2UC7rH3n8raa2De1mWv/9UroZXXaqjPXv1yCU7TOqg tjxSKjpAWd8m4a5f1VZSmmD6xVsA0AGjwW/SpohOFILmfmKO4Cv7vsbyUJECd5FDPqi0EmHrAe6X0 e0T+lY4w==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54943 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eySdI-0032nT-9g; Tue, 20 Mar 2018 21:33:40 -0400 To: Bob Hinden , Sander Steffann Cc: "v6ops@ietf.org WG" References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> From: Joe Touch Message-ID: <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> Date: Tue, 20 Mar 2018 18:33:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 01:33:43 -0000 Hi, all, At some level, we need to understand that "fragmentation is harmful" is fundamentally incorrect and misleading. The reality is that "network devices that rely on transport info without reconstituting it are harmful". I.e., any device that forwards, filters, translates, folds, spindles, or otherwise mutilates IP packets based on transport information needs to either:     a) act like the transport endpoint it becomes once it relies on transport info, and reassemble the fragments into a full packet or     b) emulate the net effect of (a) by caching initial fragment state and processing subsequent fragments in that context (perhaps including holding non-initial fragments until that initial frag creates that state). Devices that claim to be line-rate forwarders but can't do the above at line rate are broken and/or lying about their performance, not "optimized". Optimization works better than the default; the default case still has to work. Joe From nobody Wed Mar 21 01:20:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C3712D958 for ; Wed, 21 Mar 2018 01:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Efp0mYN3rvHE for ; Wed, 21 Mar 2018 01:20:53 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 B5C04126CC4 for ; Wed, 21 Mar 2018 01:20:53 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1139FAF; Wed, 21 Mar 2018 09:20:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1521620451; bh=e/O/K3IhkxhL14JBkHViRIIfQ9/jGafsP0FsKpwCPRA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fJcj8SkSvdOvvYnwCLLBQkjXGSU5TF9MKdhPTFj7tBRpeT6EvIHubTA0nfMM9G/41 1N21Hsm5eX5dSWFy4X/pSdbsT9ALyRFx9n8plK1KM47OFtFow2ltd3YqlB7Xu9W5gZ kmj/UZBUknqhZvpItmll8rOcOPFRgQsEg/GiURwk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0EFC89F; Wed, 21 Mar 2018 09:20:51 +0100 (CET) Date: Wed, 21 Mar 2018 09:20:51 +0100 (CET) From: Mikael Abrahamsson To: Joe Touch cc: "v6ops@ietf.org WG" In-Reply-To: <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> Message-ID: References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 08:20:56 -0000 On Tue, 20 Mar 2018, Joe Touch wrote: > Devices that claim to be line-rate forwarders but can't do the above at > line rate are broken and/or lying about their performance, not > "optimized". Optimization works better than the default; the default > case still has to work. Unfortunately your view of things seem to be shared by only a small minority of equipment vendors and customers. It'd also increase cost a lot to create devices that do what you say, so that's not going to happen anytime soon. The network isn't perfect, and applications need to handle this gracefully. The network should strive to be perfect, but we all know it won't always. The pain to the users when it isn't, should be mitigated. I'm fine with customer performance degradation when the network is doing things wrong, but it shouldn't stop completely. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Mar 21 02:41:53 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A859D12D963 for ; Wed, 21 Mar 2018 02:41:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Pr8dtqqDq9M for ; Wed, 21 Mar 2018 02:41:50 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D4212D95B for ; Wed, 21 Mar 2018 02:41:49 -0700 (PDT) Received: from h.hanazo.no (dhcp-809d.meeting.ietf.org [31.133.128.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 3EBDB2D4FF7; Wed, 21 Mar 2018 09:41:49 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 293452025ED539; Wed, 21 Mar 2018 09:41:47 +0000 (GMT) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1FA54196-84B1-4B9E-9684-F155E8CCA53D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 21 Mar 2018 09:41:45 +0000 In-Reply-To: <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> Cc: Bob Hinden , Sander Steffann , "v6ops@ietf.org WG" To: Joe Touch References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 09:41:52 -0000 --Apple-Mail=_1FA54196-84B1-4B9E-9684-F155E8CCA53D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joe, >=20 > At some level, we need to understand that "fragmentation is harmful" = is > fundamentally incorrect and misleading. >=20 > The reality is that "network devices that rely on transport info = without > reconstituting it are harmful". >=20 > I.e., any device that forwards, filters, translates, folds, spindles, = or > otherwise mutilates IP packets based on transport information needs to > either: >=20 > a) act like the transport endpoint it becomes once it relies on > transport info, and reassemble the fragments into a full packet >=20 > or >=20 > b) emulate the net effect of (a) by caching initial fragment state > and processing subsequent fragments in that context (perhaps including > holding non-initial fragments until that initial frag creates that = state). >=20 > Devices that claim to be line-rate forwarders but can't do the above = at > line rate are broken and/or lying about their performance, not > "optimized". Optimization works better than the default; the default > case still has to work. For IPv4 (and only IPv4) I do think we have a strong case against = fragmentation. Routing on the transport layer ports is now a fundamental part of the = IPv4 Internet architecture. If the layer 4 information isn't there, then the packet cannot be = routed. See RFC6346, RFC7596, 7597, 7599, et al. Note that in this architecture any protocol that does not carry ports, = i.e. anything which isn't UDP or TCP will not be forwarded. (So from that perspective you can argue that IPv4 fragments would fare = somewhat better than non TCP/UDP traffic. :-)) Cheers, Ole --Apple-Mail=_1FA54196-84B1-4B9E-9684-F155E8CCA53D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlqyKNkACgkQvtpYqJhC 33ahchAAqUcpSNrpg5WE9asv2ZdU1PifodT6LUPm7o3dreGDBxqIk5lqohOpLiAF /AVSQmuk7eCi+hGAB3CeTJ/WZ2mNEbzQ4v4+F9mqMnKyVt8TnArGt/sVYv8zUBIJ fel9cbU3p9cRywYtoIvf2A0/gl5UYD1t34yuCFsL5aYV7yfeGsd4WtPYSinyxAjA 15AEoh6wH0DzPF33P8OirzpyidrVEO8pFkegh0EPmh5weUmZtBnSFfeSv25yv4cZ EVaAjtrNISSxmSsWGzzUOgo0KE0miY1F2bn/rnNfwSbvH0DsIeO4fFPsbyLki7i8 GkXKmpNMZ7288yzKEYBFTshC/l8HjujJE8wc+ZUssCvYYb0USZjilC/RRmcUy1cG lIGAkJTctCjXj+PauXxAabpDCqYbsoXkej88PopgrSlZj9lN6ok6M0w2EmBxiCe9 4usZpIsL3uBQ8AQpMc8ULSoZPrEJR9DMsdlThnPtE3/X4itJRhUQlqII1j0DU96N ElBTPlAzMuN9PPYt7IWqW1UztcFDM4Q7kafvmypRB/uphy0PSXIv4xk4AU6blvi/ NlrEkw8r7hlf71L+xYVS5uD6neBDQ41vT56BQMLiKh4aGqf3xmLzvW/BzVB7rnAU zS7HGKPDR/wj8LbevCSgPn8LyXgnOeQRtreNgasWeXhlwUUW4fM= =fe/B -----END PGP SIGNATURE----- --Apple-Mail=_1FA54196-84B1-4B9E-9684-F155E8CCA53D-- From nobody Wed Mar 21 02:44:12 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A72120726; Wed, 21 Mar 2018 02:44:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152162545088.6103.10266745621515516124@ietfa.amsl.com> Date: Wed, 21 Mar 2018 02:44:10 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 09:44:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Routers Authors : Zaid Ali Kahn John Brzozowski Russ White Filename : draft-ietf-v6ops-ipv6rtr-reqs-03.txt Pages : 32 Date : 2018-03-21 Abstract: The Internet is not one network, but rather a collection of networks. The interconnected nature of these networks, and the nature of the interconnected systems that make up these networks, is often more fragile than it appears. Perhaps "robust but fragile" is an overstatement, but the actions of each vendor, implementor, and operator in such an interconnected environment can have a major impact on the stability of the overall Internet (as a system). The widespread adoption of IPv6 could, particularly, disrupt network operations, in a way that impacts the entire system. This time of transition is an opportune time to take stock of lessons learned through the operation of large scale networks on IPv4, and consider how to apply these lessons to IPv6. This document provides an overview of the design and architectural decisions that attend IPv6 deployment, and a set of IPv6 requirements for routers, switches, and middleboxes deployed in IPv6 networks. The hope of the editors and contributors is to provide the necessary background to guide equipment manufacturers, protocol implementors, and network operators in effective IPv6 deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 21 06:04:42 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104EC127522 for ; Wed, 21 Mar 2018 06:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8KeTbvy0vLA for ; Wed, 21 Mar 2018 06:04:39 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 BEA5B124234 for ; Wed, 21 Mar 2018 06:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=srHtbnBRv1rrI/X8SQGRsWaJ0B7692uBhqT0pWaZjsg=; b=7DGq8p6Ju27bpJXVvTfKybkLB wf+EsKNRnVnBfSrn4PlnovR3m7LcITl+tF748DOnVAs3VPXgtX3acq2dM9hAra9rAjIpfcpu9BN3K AE2NX9Np7nLCMEZgOQiT93OSMcCb7UkJ0ilH/QhXKAshcDVLNT9lW5N/Wsh4rD7gt3RFqTVLiGwma lrKVBeoUUhycHnC467qZS66YjrZr+3t0MqlWl97RmXuBbdTzulDvXbxqR6RJlcUGxkOoeOl4kVNsp KLS5nbWQwXSlCoHUTD/uF7FkmX3ITL9HLoCjYfmbkq8szXFWwLnD0ZjcPbn816TqJpC4M2T8lpoCQ kCLTPS+QQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:59983 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eydPx-002wCW-7j; Wed, 21 Mar 2018 09:04:38 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Wed, 21 Mar 2018 06:04:29 -0700 Cc: "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 13:04:41 -0000 > On Mar 21, 2018, at 1:20 AM, Mikael Abrahamsson = wrote: >=20 > On Tue, 20 Mar 2018, Joe Touch wrote: >=20 >> Devices that claim to be line-rate forwarders but can't do the above = at line rate are broken and/or lying about their performance, not = "optimized". Optimization works better than the default; the default = case still has to work. >=20 > Unfortunately your view of things seem to be shared by only a small = minority of equipment vendors and customers. Vendors are in the business of making money, which sometimes includes = misrepresenting their products. Customers can=E2=80=99t always tell which device is causing the problem = or may have no control over that device. I don=E2=80=99t know of many = customers who are big fans of NATs, e.g. The real issue is that the IETF lacks a compliance arm. > It'd also increase cost a lot to create devices that do what you say, = so that's not going to happen anytime soon. Yes, but it also increases cost to run at line rate for min size packets = vs just saying you do and hoping the packets don=E2=80=99t get so small = you can=E2=80=99t keep up. And some grocery stores put sawdust in their ground beef. Again, the lack of compliance assurance is the issue. >=20 > The network isn't perfect, and applications need to handle this = gracefully. The network should strive to be perfect, but we all know it = won't always.=20 There=E2=80=99s a big difference between tolerating bugs and faulty = equipment vs. tolerating behavior that violates our specs. If we ever = really try to do the latter, we should pack the IETF and go home. > The pain to the users when it isn't, should be mitigated. I'm fine = with customer performance degradation when the network is doing things = wrong, but it shouldn't stop completely. So how well does your router work when the IP protocol isn=E2=80=99t 4 = or 6, or when the EtherID is incorrect? At some point we have to stand = behind our specs. Joe From nobody Wed Mar 21 06:11:10 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A92127522 for ; Wed, 21 Mar 2018 06:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO2ZbSxvGx7Q for ; Wed, 21 Mar 2018 06:11:05 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 3E2A412E877 for ; Wed, 21 Mar 2018 06:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7L1xObJgTX84IUrc7FJm5GVsVonxTSqgFyUDvxZ1DKg=; b=Yuf7f0Jnzgw5YI/elO83i97Eq xJHtA4jmLSMGJb08XtdGF3x34HNOQ+QUYaCOVPwd4ebjuHJ4XOxIneHve9dlrLqSJotZTQ/sODCxJ pVIkNVtPkPu5HY4nqRA4Jk6eYCqT/mKC9omidY8BxujAXovuT1KR3BJkRhHggOydk7GUipbEerT03 VpH72niSlbhrTOfW150tzVklILr5VBB4QmjQhd06vDlUpgbnQu0sPo8GVY5SZ40ZwfAfIwvXGB51v yjzXDiQeL0Gz68F6TIMq8CnkEFIo5fuejCKM2dAga3JSa4d8J08ngzyI4tddC+/JJ9wWQ8sZ9QLb8 8hhcaxFVg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60010 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eydW3-0034YQ-As; Wed, 21 Mar 2018 09:10:57 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_70E0CD8B-677F-4FFF-B651-B5C886A228D4" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Wed, 21 Mar 2018 06:10:54 -0700 Cc: Bob Hinden , Sander Steffann , "v6ops@ietf.org WG" Message-Id: <975356C9-C00B-4863-967C-88554D6ED087@strayalpha.com> References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> To: Ole Troan X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 13:11:09 -0000 --Apple-Mail=_70E0CD8B-677F-4FFF-B651-B5C886A228D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 21, 2018, at 2:41 AM, Ole Troan wrote: >=20 > For IPv4 (and only IPv4) I do think we have a strong case against = fragmentation. > Routing on the transport layer ports is now a fundamental part of the = IPv4 Internet architecture. > If the layer 4 information isn't there, then the packet cannot be = routed. DPI into the packet body is also a fundamental part too. However, if the lack of layer 4 info creates a situation where a packet = can=E2=80=99t be routed, then the device isn=E2=80=99t a router. Yes, the Internet has many many broken parts. That includes RFCs that = are inconsistent with our core architecture requirements. If anyone in the IAB is listening, you=E2=80=99d earn your middle name = better by dealing with those than trying to seek new =E2=80=9Cfun=E2=80=9D= stuff on which to pontificate. Joe= --Apple-Mail=_70E0CD8B-677F-4FFF-B651-B5C886A228D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 21, 2018, at 2:41 AM, Ole Troan <otroan@employees.org> wrote:

For IPv4 (and only IPv4) I do = think we have a strong case against fragmentation.
Routing on the transport layer ports is now a = fundamental part of the IPv4 Internet architecture.
If the layer 4 information isn't there, then the = packet cannot be routed.

DPI into the packet body is also a fundamental = part too.

However, if the lack of = layer 4 info creates a situation where a packet can=E2=80=99t be routed, = then the device isn=E2=80=99t a router.

Yes, the Internet has many many broken parts. That = includes RFCs that are inconsistent with our core architecture = requirements.

If anyone in the IAB = is listening, you=E2=80=99d earn your middle name better by dealing with = those than trying to seek new =E2=80=9Cfun=E2=80=9D stuff on which to = pontificate.

Joe
= --Apple-Mail=_70E0CD8B-677F-4FFF-B651-B5C886A228D4-- From nobody Wed Mar 21 06:45:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6005B12E048 for ; Wed, 21 Mar 2018 06:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8rzMln__apS for ; Wed, 21 Mar 2018 06:45:51 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 B5F28127078 for ; Wed, 21 Mar 2018 06:45:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w2LDjnGm035062 for ; Wed, 21 Mar 2018 14:45:49 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C396201C71 for ; Wed, 21 Mar 2018 14:45: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 02B23201B53 for ; Wed, 21 Mar 2018 14:45:49 +0100 (CET) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w2LDjmj8015840 for ; Wed, 21 Mar 2018 14:45:48 +0100 To: v6ops@ietf.org References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <975356C9-C00B-4863-967C-88554D6ED087@strayalpha.com> From: Alexandre Petrescu Message-ID: <6e33fb90-b0d7-de4c-ca2f-981e5f002fb0@gmail.com> Date: Wed, 21 Mar 2018 14:45:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <975356C9-C00B-4863-967C-88554D6ED087@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 13:45:54 -0000 Le 21/03/2018 à 14:10, Joe Touch a écrit : > > >> On Mar 21, 2018, at 2:41 AM, Ole Troan > > wrote: >> >> For IPv4 (and only IPv4) I do think we have a strong case against >> fragmentation. >> Routing on the transport layer ports is now a fundamental part of the >> IPv4 Internet architecture. >> If the layer 4 information isn't there, then the packet cannot be routed. > > DPI into the packet body is also a fundamental part too. > > However, if the lack of layer 4 info creates a situation where a packet > can’t be routed, then the device isn’t a router. > > Yes, the Internet has many many broken parts. That includes RFCs that > are inconsistent with our core architecture requirements. Worse, there are implementations that dont have specifications. E.g. IPv6-over-802.11 spec does not exist, implementations of it frag at both IP and MAC layer (e.g. ping -s 2000 issues IP Fragments carried with MAC frag headers), and people seem to agree it's the wrong thing to do. Alex > > If anyone in the IAB is listening, you’d earn your middle name better by > dealing with those than trying to seek new “fun†stuff on which to > pontificate. > > Joe > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Mar 21 06:49:32 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF8412DA27 for ; Wed, 21 Mar 2018 06:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5_G_AYW8tzY for ; Wed, 21 Mar 2018 06:49:29 -0700 (PDT) Received: from jax4mhob03.myregisteredsite.com (jax4mhob03.myregisteredsite.com [64.69.218.83]) (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 6B6AD12E889 for ; Wed, 21 Mar 2018 06:49:29 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by jax4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id w2LDnQZH027778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Mar 2018 09:49:27 -0400 Received: (qmail 27698 invoked by uid 0); 21 Mar 2018 13:49:26 -0000 X-TCPREMOTEIP: 31.130.238.73 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?IPv6:2001:67c:370:1998:a5e2:8919:98b8:ed18?) (lee@asgard.org@31.130.238.73) by 0 with ESMTPA; 21 Mar 2018 13:49:26 -0000 To: v6ops@ietf.org References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <975356C9-C00B-4863-967C-88554D6ED087@strayalpha.com> From: Lee Howard Message-ID: Date: Wed, 21 Mar 2018 13:49:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <975356C9-C00B-4863-967C-88554D6ED087@strayalpha.com> Content-Type: multipart/alternative; boundary="------------EDE6A37B936A777E980D1ECA" Content-Language: en-US Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 13:49:31 -0000 This is a multi-part message in MIME format. --------------EDE6A37B936A777E980D1ECA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 03/21/2018 01:10 PM, Joe Touch wrote: > > >> On Mar 21, 2018, at 2:41 AM, Ole Troan > > wrote: >> >> For IPv4 (and only IPv4) I do think we have a strong case against >> fragmentation. >> Routing on the transport layer ports is now a fundamental part of the >> IPv4 Internet architecture. >> If the layer 4 information isn't there, then the packet cannot be routed. > > DPI into the packet body is also a fundamental part too. Not generally at scale, and not with many of the new and upcoming protocols. > > However, if the lack of layer 4 info creates a situation where a > packet can’t be routed, then the device isn’t a router. I don't understand this. I understand you mean the subsequent fragments, except that routers as I understand them perform "network layer forwarding" [RFC1812, Requirements for IP Version 4 Routers] Layer 4 is not the network layer; are devices that need L4 info considered routers? > > Yes, the Internet has many many broken parts. That includes RFCs that > are inconsistent with our core architecture requirements. > > If anyone in the IAB is listening, you’d earn your middle name better > by dealing with those than trying to seek new “fun†stuff on which to > pontificate. As I take off several hats, I'm not sure what to ask of the IAB here. Is it to be the "compliance arm" you mentioned elsewhere in the thread? Lee > > Joe > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------EDE6A37B936A777E980D1ECA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 03/21/2018 01:10 PM, Joe Touch wrote:


On Mar 21, 2018, at 2:41 AM, Ole Troan <otroan@employees.org> wrote:

For IPv4 (and only IPv4) I do think we have a strong case against fragmentation.
Routing on the transport layer ports is now a fundamental part of the IPv4 Internet architecture.
If the layer 4 information isn't there, then the packet cannot be routed.

DPI into the packet body is also a fundamental part too.

Not generally at scale, and not with many of the new and upcoming protocols.

However, if the lack of layer 4 info creates a situation where a packet can’t be routed, then the device isn’t a router.

I don't understand this. I understand you mean the subsequent fragments, except that routers as I understand them perform "network layer forwarding" [RFC1812, Requirements for IP Version 4 Routers]
Layer 4 is not the network layer; are devices that need L4 info considered routers?

Yes, the Internet has many many broken parts. That includes RFCs that are inconsistent with our core architecture requirements.

If anyone in the IAB is listening, you’d earn your middle name better by dealing with those than trying to seek new “fun†stuff on which to pontificate.

As I take off several hats, I'm not sure what to ask of the IAB here.

Is it to be the "compliance arm" you mentioned elsewhere in the thread?

Lee


Joe


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

--------------EDE6A37B936A777E980D1ECA-- From nobody Wed Mar 21 11:22:33 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB47127863 for ; Wed, 21 Mar 2018 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCFGzIyUnrUj for ; Wed, 21 Mar 2018 11:22:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 CA30C12778D for ; Wed, 21 Mar 2018 11:22:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GVAACBorJa/wUHmMZdGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJrUmFwKAqDUod/jQ2BcYEQhnGMNxSBOD0LIwmEWQIagzwhNBg?= =?us-ascii?q?BAgEBAQEBAQIDaBwMgms1BwMMIQkCLwEBAQEBAQEBAQEBAQEcAg9BAQEYAQEBA?= =?us-ascii?q?QMSERFFDAQCAQgNAQMEAQEBAgIGHQMCAgIfERQBCAgCBA4FCBMHhFQDFQEOok2?= =?us-ascii?q?JbIIgGwKGcg2BLIF2BYEJhjqBVD+DGIEAglFCBBmBAggJAQwGASEVgmowgiQDk?= =?us-ascii?q?T+GTS8JAoYMhgYBhGSDfoJlhQiJMzuGSIEmHDlhcXAVgn2Ff4pQcI0yDhiBCAG?= =?us-ascii?q?BFQEB?= X-IPAS-Result: =?us-ascii?q?A2GVAACBorJa/wUHmMZdGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?rUmFwKAqDUod/jQ2BcYEQhnGMNxSBOD0LIwmEWQIagzwhNBgBAgEBAQEBAQIDa?= =?us-ascii?q?BwMgms1BwMMIQkCLwEBAQEBAQEBAQEBAQEcAg9BAQEYAQEBAQMSERFFDAQCAQg?= =?us-ascii?q?NAQMEAQEBAgIGHQMCAgIfERQBCAgCBA4FCBMHhFQDFQEOok2JbIIgGwKGcg2BL?= =?us-ascii?q?IF2BYEJhjqBVD+DGIEAglFCBBmBAggJAQwGASEVgmowgiQDkT+GTS8JAoYMhgY?= =?us-ascii?q?BhGSDfoJlhQiJMzuGSIEmHDlhcXAVgn2Ff4pQcI0yDhiBCAGBFQEB?= X-IronPort-AV: E=Sophos;i="5.48,340,1517893200"; d="scan'208";a="236415719" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 21 Mar 2018 14:22:08 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 14:22:08 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0352.000; Wed, 21 Mar 2018 14:22:07 -0400 From: "Mudric, Dusan (Dusan)" To: Jen Linkova CC: Gert Doering , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt Thread-Index: AQHTvfmTCDwHYFt5g0SYi8yGx9x3RaPbA57A Date: Wed, 21 Mar 2018 18:22:06 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.150.1 dlp-reaction: no-action x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 18:22:30 -0000 SGkgSmVuLA0KDQpQbGVhc2Ugc2VlIGlubGluZWQuDQoNClRoYW5rcywNCkR1c2FuLg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEplbiBMaW5rb3ZhIFttYWlsdG86ZnVy cnkxM0BnbWFpbC5jb21dDQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAxNywgMjAxOCAxMDowOSBB TQ0KPiBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pDQo+IENjOiBHZXJ0IERvZXJpbmc7IHY2b3Bz QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt djZvcHMtY29uZGl0aW9uYWwtcmFzLTAxLnR4dA0KPiANCj4gT24gRnJpLCBNYXIgOSwgMjAxOCBh dCAzOjQwIEFNLCBNdWRyaWMsIER1c2FuIChEdXNhbikNCj4gPGRtdWRyaWNAYXZheWEuY29tPiB3 cm90ZToNCj4gPiBJIGJlbGlldmUgSSB1bmRlcnN0b29kIHRoZSBpbnRlbnQgb2YgdGhlIGRyYWZ0 LiBMZXQgbWUgZXhwbGFpbiBteSB1bmRlcnN0YW5kaW5nDQo+IG9mIHJ1bGUgNS41LiBQbGVhc2Ug c2VlIGlubGluZWQuDQo+IA0KPiA+PiBJU1AgdXBsaW5rIGlzIGVpdGhlciAicHJlZmVycmVkIiAo aG9zdHMgYXJlIGFsbG93ZWQgdG8gdXNlIGl0LCB0aGUNCj4gPj4gbmV0d29yayBjYW4gc2VuZCBw YWNrZXRzIHRoZXJlLCBiZWNhdXNlIHRoZSB1cGxpbmsgaXMgdXAgYW5kIHRoZXJlIGlzDQo+ID4+ IG5vIGV4cGxpY3QgcG9saWN5IHdoaWNoIGluZGljYXRlcyB0aGF0IHRoZSB1cGxpbmsgc2hvdWxk IG5vdCBiZSB1c2VkDQo+ID4+IGlmIG90aGVyIHVwbGlua3MgYXJlIGF2YWlsYWJsZSkgb3Igbm90 IHByZWZlcnJlZCAoaXQncyBkb3duIG9yIHRoZXJlDQo+ID4+IGlzIGEgcG9saWN5IHRvIHByZXZl bnQgdXNpbmcgdGhpcyB1cGxpbmsgZXguIGZvciBiYWNrdXApLg0KPiA+PiBJdCdzIGJpbmFyeSBz dGF0ZS4NCj4gDQo+ID4gW1tEdXNhbl1dIFRoZSByb3V0ZXIga25vd3MgbW9yZSB0aGFuIHRoYXQu IEZvciAndXNhYmxlJyBwcmVmaXhlcywgdGhlIHJvdXRlcg0KPiBrbm93cyB3aGljaCBwcmVmaXgg aXMgdGhlIG1vc3QgcHJlZmVycmVkLg0KPiANCj4gV291bGQgeW91IGJlIGFibGUgdG8gZ2l2ZSBh biBleGFtcGxlIGZvciAnbW9zdCBwcmVmZXJyZWQnPyBUaGUgbmV0d29yaw0KPiBoYXMgdHdvIHVw bGlua3MgdG8gdHdvIElTUHMsIHR3byBwcmVmaXhlcy4gQm90aCB1cGxpbmtzIGNhbiBiZSB1c2Vk Lg0KPiBFYWNoIGJvcmRlciByb3V0ZXIgaGFzIGEgZGVmYXVsdCByb3V0ZSBwb2ludGluZyB0byB0 aGUgdXBsaW5rLg0KPiBXaGF0IHByZWZpeCBpcyAnbW9zdCBwcmVmZXJyZWQnIHRvIHJlYWNoICBJ bnRlcm5ldD8NCg0KW1tEdXNhbl1dIA0KW1tEdXNhbl1dIE9uZSBJU1AgbWlnaHQgYmUgbW9yZSBy ZWxpYWJsZSBvciBjYW4gcHJvdmlkZSBiZXR0ZXIgUW9TLCBmb3IgZXhhbXBsZS4NCg0KPiANCj4g PlRoZSByb3V0ZXIgY2FuIHBhc3MgdGhhdCBrbm93bGVkZ2UgaW4gUkEgUElPIG9wdGlvbiwgdXNp bmcgJ3Jlc2VydmVkJyBiaXRzLCBmb3INCj4gZXhhbXBsZSAobGlrZSBQcmYgaW4gcmZjNDE5MSNz ZWN0aW9uLTIuMiApLiBXaXRob3V0IHRoaXMgaW5mb3JtYXRpb24sIGlmIHRoZXJlIGFyZQ0KPiB0 d28gcHJlZml4ZXMgKElTUDEtRCBhbmQgSVNQMi1EKSBob3cgd2lsbCBob3N0IGtub3cgaWYgaXQg c2hvdWxkIHRhbGsgdG8gRCBvdmVyDQo+IElTUDEgb3IgSVNQMj8gUnVsZSA1LjUgY2Fubm90IGRl dGVybWluZSBpdDoNCj4gPg0KPiA+ICAgIFJ1bGUgNS41OiBQcmVmZXIgYWRkcmVzc2VzIGluIGEg cHJlZml4IGFkdmVydGlzZWQgYnkgdGhlIG5leHQtaG9wLg0KPiA+ICAgIElmIFNBIG9yIFNBJ3Mg cHJlZml4IGlzIGFzc2lnbmVkIGJ5IHRoZSBzZWxlY3RlZCBuZXh0LWhvcCB0aGF0IHdpbGwNCj4g PiAgICBiZSB1c2VkIHRvIHNlbmQgdG8gRCBhbmQgU0Igb3IgU0IncyBwcmVmaXggaXMgYXNzaWdu ZWQgYnkgYSBkaWZmZXJlbnQNCj4gPiAgICBuZXh0LWhvcCwgdGhlbiBwcmVmZXIgU0EuDQo+ID4N Cj4gPiBZb3UgY2FuIGNvbnNpZGVyIHRoZSB0cmljayBpbg0KPiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX190b29scy5pZXRmLm9yZ19odG1s X2RyYWZ0LTJEaWV0Zi0yRHJ0Z3dnLTJEZW50ZXJwcmlzZS0yRHBhLQ0KPiAyRG11bHRpaG9taW5n LTJEMDMtMjNzZWN0aW9uLQ0KPiAyRDQuMi4yJmQ9RHdJRmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2la SDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3INCj4gaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09 LQ0KPiBqV0tMc2RSX1R5Nld5VzcxUTRzOWhOYlJDQnU3Y2ZyNkxFNURsSmQtDQo+IFJFJnM9aTdD RnQ1a2Q2M2hPZTQ0R21HRTN1M3BkOE9WZ1puSnhHR3NqMUpPTndycyZlPSBieSBzZXR0aW5nIHR3 bw0KPiByb3V0ZXMgaW4gUkEgYW5kIHRoZSBQcmYgZnJvbSByZmM0MTkxI3NlY3Rpb24tMi4yLCBi YXNlZCBvbiB0aGUgcm91dGVyIHBvbGljeS4NCj4gVGhpcyB3b3VsZCBhbGxvdyBhIGhvc3QgdG8g c2VsZWN0IHRoZSBwcmVmZXJyZWQgbmV4dCBob3AgYW5kIHVzZSB0aGUgcHJlZmVycmVkDQo+IG5l eHQgaG9wIGluIFJ1bGUgNS41LiBVc2luZyBQcmYgaW4gUklPIHRoZSByb3V0ZXIgcG9saWN5IGlz IGRpc3RyaWJ1dGVkIHRvIGFsbCBob3N0cw0KPiBhbmQgdGhleSBjYW4gc2VsZWN0IHRoZSBwcmVm ZXJyZWQgSVNQLiBBIHJvdXRlciBTSE9VTEQgc2V0IFByZiBiYXNlZCBvbiB0aGUgSVNQDQo+IHNl bGVjdGlvbiBwb2xpY3kuIFRoZXJlIG1pZ2h0IGJlIHVzZSBjYXNlIHdoZW4gdGhlIG5ldHdvcmsg d291bGQgdXNlIG9ubHkgb25lDQo+IHJvdXRlIGFuZCBhZHZlcnRpc2Ugb25lIHByaWZpeC4NCj4g DQo+IEknbSBub3Qgc3VyZSBpZiB5b3UndmUgYmVlbiBmb2xsb3dpbmcgdGhlIHdob2xlIHN0b3J5 Li4uLldoZW4NCj4gZHJhZnQtaWV0Zi1ydGd3Zy1lbnRlcnByaXNlLXBhLW11bHRpaG9taW5nIHdh cyBwcmVzZW50ZWQgdG8gdjZvcHMgaW4NCj4gQmVybGluLCB3ZSBjYW1lIHRvIGNvbmNsdXNpb24g dGhhdCB3aGlsZSB0aGUgZGVzY3JpYmVkIHRyaWNrIGlzIG5pY2UsDQo+IGl0IGNvdWxkIG5vdCBi ZSB3aWRlbHkgdXNlZCBub3cuIFNvIHNvbWUgdGFjdGljYWwgc29sdXRpb24gaXMgbmVlZGVkLg0K PiBUaGF0J3Mgd2h5IHRoaXMgZHJhZnQgd2FzICdmb3JrZWQnIGZyb20gdGhlIFJUR1dHIG9uZS4N Cj4gU28gYW55dGhpbmcgd2hpY2ggcmVxdWlyZSBwcm90b2NvbCBjaGFuZ2VzL25ldyBmZWF0dXJl cy9ydWxlIDUuNQ0KPiBzdXBwb3J0IGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0IGJ5IHRo ZSBkZWZpbml0aW9uLg0KPiANCg0KW1tEdXNhbl1dIA0KW1tEdXNhbl1dIFdoeSB0aGUgUHJmIGZy b20gcmZjNDE5MSNzZWN0aW9uLTIuMiBjYW5ub3QgYmUgc2V0IGJ5IHRoZSByb3V0ZXI/IFRoaXMg aXMgbm90IGEgcHJvdG9jb2wgY2hhbmdlPyBUaGUgZmxhZ3MgYXJlIGFscmVhZHkgZGVmaW5lZCBp biB0aGUgUkZDNDE5MS4NCg0KDQo+ID4gW1tEdXNhbl1dIEJlY2F1c2UgdGhlIHJvdXRlciBzaG91 bGQgbm90IGxpbWl0IHRoZSBjb21tdW5pY2F0aW9uIG92ZXIgb25lIElTUA0KPiBieSBhZHZlcnRp c2luZyBvbmx5IG9uZSBwcmVmaXguIFRoZSBob3N0IHNob3VsZCBiZSBhYmxlIHRvIGRlY2lkZSB3 aGljaCBvZiB0aGUNCj4gdHdvIElTUHMgdG8gdXNlLiBCb3RoIHByZWZpeGVzIHNob3VsZCBiZSBn aXZlbiB0byB0aGUgaG9zdA0KPiANCj4gSW4gdGhlICdsb2FkIHNoYXJpbmcnIHNjZW5hcmlvIGl0 IGlzIGV4YWN0bHkgd2hhdCBoYXBwZW5zLiBBbGwgSVNQDQo+IHByZWZpeGVzIGFyZSBpbmNsdWRl ZCBpbiBQSU8uDQo+IEluIHRoZSBhY3RpdmUvYmFja3VwIHNjZW5hcmlvIG9ubHkgYWN0aXZlIHVw bGlua3MgcHJlZml4ZXMgYXJlDQo+IGFkdmVydGlzZWQsIGJlY2F1c2UgdGhlIG5ldHdvcmsgcG9s aWN5IGRvZXMgbm90IGFsbG93IGhvc3RzIHRvIHVzZSB0aGUNCj4gYmFja3VwIHVwbGluayBzbyBo b3N0cyBzaG91bGQgbm90IHNlbGVjdCBiYWNrdXAgdXBsaW5rcy4NCj4gDQo+ID4gYW5kIHRoZXkg c2hvdWxkIGhhdmUgdGhlIHByZWZlcmVuY2UgYXNzaWduZWQuDQo+IA0KPiBXaGljaCBob3N0cyB3 b3VsZCBub3QgcmVjb2duaXplLg0KDQpbW0R1c2FuXV0gDQpbW0R1c2FuXV0gVGhpcyBpcyBhbiBp bXBsZW1lbnRhdGlvbiBhc3BlY3QuIElmIGhvc3RzIGltcGxlbWVudCB0aGUgUHJmIGZyb20gcmZj NDE5MSNzZWN0aW9uLTIuMiwgdGhleSB3aWxsIHJlY29nbml6ZSBScmYuIFlvdSBzaG91bGQgbm90 IGxpbWl0IHRoZSBvcHRpb25zIGJhc2VkIG9uIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucy4N Cg0KPiANCj4gPj4gSGF2ZSBJIHNlbnQgdGhpcyBlbWFpbCB0byA2bWFuQCBieSBtaXN0YWtlPyBB aCwgZG9lcyBub3QgbG9vayBsaWtlIHRoYXQgOikNCj4gPj4gQW5kIEkgc2VlbSB0byBzZXQgdGhl IGRvY3VtZW50IHN0YXR1cyB0byAnSW5mb3JtYXRpb25hbCcuDQo+IA0KPiA+IFtbRHVzYW5dXSBJ ZiB3ZSBjaGFuZ2UgSVBPIG9wdGlvbiwgaXQgaXMgbm90IGluZm9ybWF0aW9uYWwgYW55IG1vcmUu DQo+IA0KPiBBZ2FpbiwgdGhlIGdvYWwgb2YgKnRoaXMgcGFydGljdWxhciogZHJhZnQgaXMgdG8g ZG9jdW1lbnQgZXhpc3RpbmcNCj4gc29sdXRpb24sIHdoaWNoIGNhbiBiZSB1c2VkIHJpZ2h0IG5v dyB3L28gYW55IGNoYW5nZXMgb24gdGhlIGhvc3QuDQo+IA0KPiBJZiB3ZSBoYXZlIGlkZWFzIGhv dyB0byBpbXByb3ZlIHRoZSBwcm90b2NvbCAtIGdyZWF0LCBidXQgdGhvc2UgaWRlYXMNCj4gc2hv dWxkIG5vdCBiZSBpbiB0aGlzIGRyYWZ0Lg0KPiANCltbRHVzYW5dXSBJIHRoaW5rIFJyZiBzZXR0 aW5nIHNob3VsZCBiZSBpbiB0aGUgZHJhZnQuIEl0IG1pZ2h0IG5vdCBiZSB1c2VkIGJ5IHRoZSBo b3N0cyB0b2RheSwgYnV0IGNhbiBiZSB1c2VkIGJ5IHRoZSBob3N0cyBvZiB0b21vcnJvdy4NCg0K PiAtLQ0KPiBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5DQo= From nobody Wed Mar 21 11:34:41 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F370127863 for ; Wed, 21 Mar 2018 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XyCFAcVuHNC for ; Wed, 21 Mar 2018 11:34:37 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0D112778D for ; Wed, 21 Mar 2018 11:34:37 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f19so11573283wmc.0 for ; Wed, 21 Mar 2018 11:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5uieORYGZYu2WYxyd0DOPSEPLWaj2ok2XS/UQ2sczEo=; b=UbCUJ1V4g1h+aVG9cDVKPFmgIUBMukUbUNkHnrnwfHqD+QCRDvdNWqyDWJe+5twf39 9wyOv7zetkrLTPVo/gtiVwPro6qR3JVE2jLzOOZ01MtnMZBPVbqNiyDhaIw7Q1tsFF/Q 22k5OhF2XvSRq3ev905I5TqAQSwO0/55i2hTHJoq7cqR77AJsTYuNDsUqe7zagi8ES8u mWCWLWaDR3aDKecP+LbqJN/yTwvi+lOw1wJiMOFO3YH82SlWu73myrW31zJ7qscXovDl 4zkBCiS3kFdJl4z2K2CwqEcc2JF49qhady3vDkx3MXOnXCEO2PhdHf+M4fS3srhgQwu6 58CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5uieORYGZYu2WYxyd0DOPSEPLWaj2ok2XS/UQ2sczEo=; b=cBHuNKyVNgEZlCVLIR2dd4/jZwQuBBI24IlPTt1Cl3VH6NWRH3Z/Yl3cP1y7+VmMyg VStPlr/tWECucdb0yLy5jSw1BTegC0zN67uTLDzBS/3H3DrZJjaA57xQ0mmgiwfIgcxM bvKkWxl04AjXNmDRmHpos0HGUBlMUT0zOkfK4NXRaO7iQmFOdOKA9l8uNX94ju/gX2Ag yV6pX6Ri00NavnRGndtQjUTrzEMa0/Gmux3WPjFYWFp5jUMdhEW1yE+YEO2JxIwphhqt 8jPrhDQHHu30JBqngiCBEScEy9nRDGIdrdi8BsELfYmgP1zqhj+RwWYGo7SkoD/5TgKA B2ow== X-Gm-Message-State: AElRT7H01umOGwUAvk5jA0F0rK0fQ3rSbEdP8Mev1l+NeGi638aGgQyK H0xTABcyNr45JsDYoB7qFVIXw8Fji2j4hf33W3Zcsg== X-Google-Smtp-Source: AG47ELtMbpBySfiz8AFGEK6+Anznhg8ZFWAtwqLYxXbXRZ9w3Q7Brkdgltj4qQxS2UnQz77xc9CQnuomY7BSexLNCxM= X-Received: by 10.28.84.77 with SMTP id p13mr3275286wmi.129.1521657275692; Wed, 21 Mar 2018 11:34:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.130.204 with HTTP; Wed, 21 Mar 2018 11:34:14 -0700 (PDT) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> From: Lorenzo Colitti Date: Wed, 21 Mar 2018 18:34:14 +0000 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: Jen Linkova , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cd2c66405b50567f071ca" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 18:34:39 -0000 --94eb2c1cd2c66405b50567f071ca Content-Type: text/plain; charset="UTF-8" On Wed, Mar 21, 2018 at 6:22 PM, Mudric, Dusan (Dusan) wrote: > [[Dusan]] This is an implementation aspect. If hosts implement the Prf > from rfc4191#section-2.2, they will recognize Rrf. You should not limit the > options based on the current implementations. > Actually, we should. This is an operational working group, and as such, needs to document practices that work today. --94eb2c1cd2c66405b50567f071ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 21, 2018 at 6:22 PM, Mudric, Dusan (Dusan) <dmudric@avaya.com&= gt; wrote:
[[Dusan]] This is an im= plementation aspect. If hosts implement the Prf from rfc4191#section-2.2, t= hey will recognize Rrf. You should not limit the options based on the curre= nt implementations.

Actually, we should= . This is an operational working group, and as such, needs to document prac= tices that work today.=C2=A0
--94eb2c1cd2c66405b50567f071ca-- From nobody Wed Mar 21 12:03:07 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC43127201 for ; Wed, 21 Mar 2018 12:03:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AEQ37uChgxt for ; Wed, 21 Mar 2018 12:03:03 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e: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 9694A12E050 for ; Wed, 21 Mar 2018 12:03:03 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id t12so527806pgp.13 for ; Wed, 21 Mar 2018 12:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=p/GraLQ5vEGQORAIJ62A1ilYNDsbeVi+ijqMZ+xdoA0=; b=jRonxPrPjCwSlsj5ipiY2jTg/VqDZbUg6j9vVXqWgn5ccHe4VKQGbM6P7Yj9UlZ1K3 DaGKdFIOL9VVMYcI/sY7VDj9je5y4y1CTGGnNVHiXmmPzWmtkZaROfvH7ze/WZx9gVRD 2hAR3/GY4UcC5CCSnt2twCQfFuq66nKxRE4D5q+pMs1u11CPpd1iFqmsabsOUOKx4YpG IpTplB1h7eRaNTApFjUJjkgLy+/PRc2YGaI9tjPFiSj5URU3BLx5Zk/HcDAr47ujJyzV I/7nBeoKG+ERLsZk+lhxiybuY1D0VWErchdheLBBL254+rGLCUdBVDOjivyAtG5RXLMW Hbvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=p/GraLQ5vEGQORAIJ62A1ilYNDsbeVi+ijqMZ+xdoA0=; b=l8rkvhJXSgrr5XfhqKSBnnwZR03CTvscdDGQylrrATBhUx6NBky4AbzLFDgjRfoAPl 1hjixfnVOSgmRMX6OCZlL/1MPXvBIQKrlHVtMN7U5SKemfUFPHY3SgvhiV45qQ7y9gSN HgK6jjyCrvcAjoQLgCawCvxPqI3k2rDqqtvC+SAdniN/L0R5oH6skSErvoiBMCx/oSDn yNnMngaKbXSfIwW5fB5f+gX7yIPCtZWc7o3a8YshjGMmZaZA8E+Xtm3F8BpYP3RtGNkB nteSvRVzsNZ4qrMPMW/fjaY4t78HkLAnOA7RGB60OhcdY1LZLaIlbZ1KDagqsxonlT9J yWYQ== X-Gm-Message-State: AElRT7H6tCr2lKY/uME4qrwOPHsDJVJ7czvStsR/uIdq3cVgltdvxs25 gAAuR5D/5eagNhHwlv6uSGNKcQ== X-Google-Smtp-Source: AG47ELuDSpwklWQcCT/dA02TCxP8eP4zD0IJztPhxQZVOBn02W74ALorCLh6y4ZFUZYKd4whFXL+vg== X-Received: by 10.99.45.131 with SMTP id t125mr11260502pgt.267.1521658982754; Wed, 21 Mar 2018 12:03:02 -0700 (PDT) Received: from [192.168.178.30] (86.225.69.111.dynamic.snap.net.nz. [111.69.225.86]) by smtp.gmail.com with ESMTPSA id z9sm4770958pfg.183.2018.03.21.12.03.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 12:03:01 -0700 (PDT) Sender: Brian Carpenter To: v6ops@ietf.org References: <152162545088.6103.10266745621515516124@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <38053359-601a-fc03-ea95-4b173cf0bd15@gmail.com> Date: Thu, 22 Mar 2018 08:03:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <152162545088.6103.10266745621515516124@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 19:03:06 -0000 Hi, I think Section 1.3 makes the scope much clearer, thanks. Maybe a couple of points need to be added to the Abstract too: This document is not designed to apply to consumer devices; it is up to each provider or equipment purchaser to determine how best to apply it to their environment. Regards Brian On 21/03/2018 22:44, 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 WG of the IETF. > > Title : Requirements for IPv6 Routers > Authors : Zaid Ali Kahn > John Brzozowski > Russ White > Filename : draft-ietf-v6ops-ipv6rtr-reqs-03.txt > Pages : 32 > Date : 2018-03-21 > > Abstract: > The Internet is not one network, but rather a collection of networks. > The interconnected nature of these networks, and the nature of the > interconnected systems that make up these networks, is often more > fragile than it appears. Perhaps "robust but fragile" is an > overstatement, but the actions of each vendor, implementor, and > operator in such an interconnected environment can have a major > impact on the stability of the overall Internet (as a system). The > widespread adoption of IPv6 could, particularly, disrupt network > operations, in a way that impacts the entire system. > > This time of transition is an opportune time to take stock of lessons > learned through the operation of large scale networks on IPv4, and > consider how to apply these lessons to IPv6. This document provides > an overview of the design and architectural decisions that attend > IPv6 deployment, and a set of IPv6 requirements for routers, > switches, and middleboxes deployed in IPv6 networks. The hope of the > editors and contributors is to provide the necessary background to > guide equipment manufacturers, protocol implementors, and network > operators in effective IPv6 deployment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-03 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-03 > > > 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 > From nobody Wed Mar 21 12:26:46 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96521275AB for ; Wed, 21 Mar 2018 12:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSVqqlDqgRNm for ; Wed, 21 Mar 2018 12:26:43 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 CD43012785F for ; Wed, 21 Mar 2018 12:26:42 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id l16so11944210wmh.3 for ; Wed, 21 Mar 2018 12:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NuKFIUX6KDYbIBkiUJ9cXw0on5iowggU56blrz3Av1M=; b=WjxpXx9RKhOr8JM/HW2oufUoQMZiZcuHvRSPaQKbmT2GWhD5ODGKJ8KLgUriWqBCnu LHX2+EEmXsHzN1HiILobY7QR31B8QuKKwCSdepxQ5T+/6S42R7gwFxwhgk2YhEVQ3zZb CVQZCEr2ZypTaaphhGR76u+UTsW2hiNUd66V0/SzBnpo0qrzHPxbkMQu4j2LfTx+QUuD NoXp+7JEzFpajfPf1WJxIxlm9Ht5L+hXAhPSywekL+cYkhRvCsAhT2WzwRKHQMLAByVu TG7SV5No6v64M0hctZ9bgVoaWLHm1uIGge+aqvx7/L5iAm55up68ANOEa0P/p/4KiWXB 4yPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NuKFIUX6KDYbIBkiUJ9cXw0on5iowggU56blrz3Av1M=; b=QgFyeVQWpJGpc6ONNdOt90WBdDNB7OjIKYlvAWy3LfWUS4EzICJJDXFAjXr8csyfCd 7hdhElm5rxxBi9fEnaaRucm/Vb3wpe2UmELc/e5sZ2Yg5goo9TjB3565/X7rw40/syGN 50zpdv7bxpVXKiIwXrgE90G1omEBbyW3vuJzXNaKMDg5fA1ma1XvYAP1eeJ4+ubhAysg BTr+AyCzCddwuSSaJoNhp+WJVS3oGkdLxUWWu7iIsue/b1eAELV1A54KVUaJXqed8Coz Zj+z4GAjA/CR4gbpDtGPHMZduPEz3v7353Phox1c0WSH7Op3v/eXW5c3eKydoDw+eFi2 aEjQ== X-Gm-Message-State: AElRT7GOC1qPpsAltfM6TMiQlnmyIYCxBYHhYU2Kv+5ar9Kjpsl1ikzs 0s1/M7lTh0VCaYkF9rq35StSQjAP7VCXVyiDoYE= X-Google-Smtp-Source: AG47ELsTnuz8sVlZdpEdDlsY9wfE+g7Hhls6nkhrse7gna3wydQZwDQG/0OePQvIdBaoUa3DCTtF8Nt4VH+/a4YBgN0= X-Received: by 10.28.166.206 with SMTP id p197mr3369851wme.81.1521660400933; Wed, 21 Mar 2018 12:26:40 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.151.19 with HTTP; Wed, 21 Mar 2018 12:26:40 -0700 (PDT) In-Reply-To: References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 21 Mar 2018 12:26:40 -0700 X-Google-Sender-Auth: Cmrz4nRHVOMtMQkEaFVROaWANqs Message-ID: To: Lorenzo Colitti Cc: "Mudric, Dusan (Dusan)" , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 19:26:45 -0000 At Wed, 21 Mar 2018 18:34:14 +0000, Lorenzo Colitti wrote: > > [[Dusan]] This is an implementation aspect. If hosts implement the Prf > > from rfc4191#section-2.2, they will recognize Rrf. You should not limit the > > options based on the current implementations. > > Actually, we should. This is an operational working group, and as such, > needs to document practices that work today. I've not closely followed this thread so this may be out of context (if so, sorry), but if it's about host implementation of the "Prf" value of RFC4191, BSD variants have been supporting it for more than 10 years (for example, FreeBSD added it in 2006 https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_rtr.c?revision=156871&view=markup). So I suspect it's also in iOS. Unlike other features of the RFC like route information option, implementing Prf is pretty simple, so I wouldn't be surprised if it's also available in non BSD-flavor host implementations. -- JINMEI, Tatuya From nobody Wed Mar 21 12:40:55 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5621275AB for ; Wed, 21 Mar 2018 12:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7FQgFqyxBZ2 for ; Wed, 21 Mar 2018 12:40:51 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80560126C25 for ; Wed, 21 Mar 2018 12:40:51 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id y2-v6so9643408lfc.5 for ; Wed, 21 Mar 2018 12:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NeDGVqCNe5hki+n94C3hWaNzAgabclLIS6dKxjFzfgY=; b=BC4DdDcMrkC6zbM7fxPVckmDAeeROkqRBcAQk0E20f61OD/MO/naFwjNvII/rIa01G VmnstplAlESB6M/txs1i7j+ZTKFpSW1Bm3VO4Q5PXUAndqQBxy7UXOPP/PheeNeyqIP5 NRuLjpv9ZK0bFjoivML8IToekPSmgKMB4upyr5ajj2O8vORPvsTFxjfSr4zGWECfL7Vs /TArauwM8kQSFm6GEdOGzuKh3lZwPA8QVaVOT2OiCZDqNOmjt5Uq40f8xyvby/KazbMx d57XNg05txO3Jb2D71r2JapLpjwMDyQ+tLHNq8YDjd+I2HgX2B+DEHdQSNKLeEF0dIUM RRxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NeDGVqCNe5hki+n94C3hWaNzAgabclLIS6dKxjFzfgY=; b=sS+d+owMH/1UWESvDx6Zo1UtyYYFr9+iRm1w7x3NDb3a3MrNN1RIGyy7Lo8q9kaDTC l0EB/QoJCCzjtSMhYTKPgmZVixf60iH7rj3XgLSeSFGLGWmBYaq6JkPd1HrNitAPg9QM o0/r649sxk+9GyI/e3M0Bw/Krb6P/6m6zxyNq2MpLnx/6Hb11xpxiYL5Rr5jflrLKH2e 5nAbmnwnIe2+r1sraV1f+NPFyJ9uHss0P+Z+EUHDLmExFkF574EdbwpzAD+3mrnWdjTI XJE9nf452EEaLYIDUFlZqT6onIhPLZSLqyqIn7e2qL+s2VUsk2GfnnC44X4mlTLmSruK 4Kqg== X-Gm-Message-State: AElRT7EPRMRqxZYLHUcs/9fKVU93ANckVUtiQCrcGLQGw+hl5nRaTY62 XCTUmkxpY5hLyulKGDaw1EBbTVUsLlIFObYa/tnxCxDE X-Google-Smtp-Source: AG47ELufr9hjr5ixRpWlW6paJCShkxwO3WAyz8t2vrb91bknO0LWhsY+TwVM46Sa1vXVpXUgBGyJA/tmlU4OwV58cQU= X-Received: by 10.46.137.13 with SMTP id d13mr7855901lji.27.1521661249589; Wed, 21 Mar 2018 12:40:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 12:40:28 -0700 (PDT) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> From: Jen Linkova Date: Thu, 22 Mar 2018 06:40:28 +1100 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: Gert Doering , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 19:40:54 -0000 Hi Dusan, On Thu, Mar 22, 2018 at 5:22 AM, Mudric, Dusan (Dusan) wrote: >> Would you be able to give an example for 'most preferred'? The network >> has two uplinks to two ISPs, two prefixes. Both uplinks can be used. >> Each border router has a default route pointing to the uplink. >> What prefix is 'most preferred' to reach Internet? > [[Dusan]] One ISP might be more reliable or can provide better QoS, for example. In this case it comes down to 'active/backup uplink' scenario: use the more reliable uplink, keep the second one as a backup/prefix deprecated. > [[Dusan]] Why the Prf from rfc4191#section-2.2 cannot be set by the router? This is not a protocol change? The flags are already defined in the RFC4191. It can be set by a router but I'm aware of just one host OS which supports this. So the router preference in RAs would not be recognized by end devices. Again, please note, that the draft documents a solution which can be deployed *today* in SMB/Enterprise environment, where BYOD is common, w/o upgrading/replacing host OSes. >> > and they should have the preference assigned. >> >> Which hosts would not recognize. > > [[Dusan]] This is an implementation aspect. If hosts implement the Prf from rfc4191#section-2.2, they will recognize Rrf. You should not limit the options based on the current implementations. It looks like I'm not explaining it properly. *This* particular draft is written to document a solution which works with existing hosts in existing networks today. Solutions which do not exist right now but may be deployed in 3-5-10 years, when all hosts get new shiny features implemented are out of scope of this particular document. As I've mentioned, a solution similar to what you are suggesting (using 5.5 and rfc4191) is documented in https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming . > [[Dusan]] I think Rrf setting should be in the draft. It might not be used by the hosts today, but can be used by the hosts of tomorrow. What would be the difference between what you are suggesting and draft-ietf-rtgwg-enterprise-pa-multihoming? -- SY, Jen Linkova aka Furry From nobody Wed Mar 21 12:46:02 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5E127333 for ; Wed, 21 Mar 2018 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqXgy1qx5Gxk for ; Wed, 21 Mar 2018 12:46:00 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 ABF8F126C25 for ; Wed, 21 Mar 2018 12:45:59 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id m16-v6so5907820lfc.4 for ; Wed, 21 Mar 2018 12:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ip4mZdDtSrIW2epVwNwY+k3GuEffc1Dl/1Oanl4dnWk=; b=DQgBZAK4Uvs+jkC64lgkZoQ+8tLELZKuhkTEVuva2XjdzXu2mWX1dxLW0xGqS9ddyT UHOfaRy+fFrwutXq+M0+v+dSmC4H+ohlQbwFhMHTRAIDCCDTqmJkl0pLpNfj3g6CNXmR 6JRHadPghqprX7gy5FmVkaaS9uOOCZrPqEzQQE5tVy8lrFVaB8nLz9xs8F33PbosKWTM zLnU/ogNfuFkZYHlCHFUgwwE4U/ca43t7xOBqR2MTQD+0eeRapr9Zyddytuf2oc8sd3I 4m3WbPLkEMxy2n7OnJrgkpPc4vP/vVaeOmQG95nns4DJkhdDvCew8Nr32X1vDfB0p2xV WDlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ip4mZdDtSrIW2epVwNwY+k3GuEffc1Dl/1Oanl4dnWk=; b=bwZHx3bRcwDNJ3cIQXvth9dO6HhNA3oGZDpje/hmaXklGnYjvPaROoxxiJvsZU0o91 aaqPeRYvw6ldCyViZmPqnLNEj3Ya2XIMQ0GaLWKyEYu51y1UcOCNOPrMKvBNOm+tDlXZ DvIm/dfYQvSAnDIwjbf7OR4I5dEoxwaXzzXicdrojL2qYcApsxJUZCILp+O43MWy8Sh8 888uJeeYD51F7ud0WTYdqwbNTV+5/zPtvGVVr0eXYIBs+wWdAPNqwSkiOVjSx+iCH307 fdTF86bYpBk1KznHq3hNIxu9XVeCSyRnokD5/ZnEK9X1uKRU40dBF7hDyxZorsTdLnDx IuyA== X-Gm-Message-State: AElRT7GEjXbBfH8fnrazftTD/HrlwyrjAAB1gui9xpltdJ3BdxlcyiLc QBT1GAkNO4r/J8WTYI6ykhwPwfCfmPNVh9V5fU8mZQ== X-Google-Smtp-Source: AG47ELtvrDiYSLMMB4gQPMLdwc/2Jyr9N+Hx3Dq2ot2P00ymrB9kYBJ0zby0z5iR9W0Es9XesIpinAQlnjzIy4//nQI= X-Received: by 10.46.45.18 with SMTP id t18mr2330596ljt.48.1521661557854; Wed, 21 Mar 2018 12:45:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 12:45:36 -0700 (PDT) In-Reply-To: References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> From: Jen Linkova Date: Thu, 22 Mar 2018 06:45:36 +1100 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Lorenzo Colitti , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 19:46:02 -0000 On Thu, Mar 22, 2018 at 6:26 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >> > [[Dusan]] This is an implementation aspect. If hosts implement the Prf >> > from rfc4191#section-2.2, they will recognize Rrf. You should not limi= t the >> > options based on the current implementations. >> >> Actually, we should. This is an operational working group, and as such, >> needs to document practices that work today. > > I've not closely followed this thread so this may be out of context > (if so, sorry), but if it's about host implementation of the "Prf" > value of RFC4191, BSD variants have been supporting it for more than > 10 years (for example, FreeBSD added it in 2006 > https://svnweb.freebsd.org/base/head/sys/netinet6/nd6_rtr.c?revision=3D15= 6871&view=3Dmarkup). > So I suspect it's also in iOS. Unlike other features of > the RFC like route information option, implementing Prf is pretty > simple, so I wouldn't be surprised if it's also available in non > BSD-flavor host implementations. Yeah, you are right, it's reasonably well supported. The issue here is that just using router preference would not help at all (or may even make the routing more sub-optimal). Let's say a host honors the router preference and selects a router R1 (connected to an ISP1) as a default gateway but it does not support Rule 5.5, then it may select ISP2 source prefix and the packet will be send to ISP2 ( R1 -> R2 -> ISP2). So I'm not sure I can see any value in using the router preference w/o rule 5.5 support in this scenario..Am I missing anything? --=20 SY, Jen Linkova aka Furry From nobody Wed Mar 21 13:04:51 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FDE12785F for ; Wed, 21 Mar 2018 13:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFQPeV4cVB2A for ; Wed, 21 Mar 2018 13:04:48 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB68212706D for ; Wed, 21 Mar 2018 13:04:47 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 36D3741B46 for ; Wed, 21 Mar 2018 21:04:45 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 28D5941B42; Wed, 21 Mar 2018 21:04:45 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1ABF940CF4; Wed, 21 Mar 2018 21:04:45 +0100 (CET) Date: Wed, 21 Mar 2018 21:04:45 +0100 From: Gert Doering To: Joe Touch Cc: Mikael Abrahamsson , "v6ops@ietf.org WG" Message-ID: <20180321200444.GX89741@Space.Net> References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> X-NCC-RegID: de.space User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 20:04:49 -0000 Hi, On Wed, Mar 21, 2018 at 06:04:29AM -0700, Joe Touch wrote: > There???s a big difference between tolerating bugs and faulty equipment vs. tolerating behavior that violates our specs. In which way, exactly, does a device "vioulate our specs" (which ones, exactly?) by routing one packet left and one packet right, based on some local decision process how to distribute packets across multiple links? If "left" and "right" happen to have very different RTTs, this will lead to (unintended) reordering, but which standard exactly forbids this for IP packets? 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 21 16:09:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4821312D574 for ; Wed, 21 Mar 2018 16:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSohdleuBQKi for ; Wed, 21 Mar 2018 16:09:46 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 819D4129C6E for ; Wed, 21 Mar 2018 16:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xOXoyNaaQR/E7/9U5wCmiWD2Us+HGR9s55IZT3g5NPo=; b=fx1HKXNKcCmVzEvZBzeasewdf MWTPGogckO+qogICMsuvslKt9YbTAReXH/ImU2DWtJc3mcuXdghp/IU9N50cDbwMeqmemwFeJSJD7 Euyt1vVZJBybegPwZfN99OGsUkCeRJUSc3sF2kOpoCS+c1XBTpR9PpMLxVtbzbYby+1cy6p40s/rO bTJgSED/JWwog9iw0RVF0PMyO7zJ74eRlRyUnWPAIhsOSmaLMmKrXB6uY+N25mbsdBO8NZD3+S+kj oBDkGEkGgoupco1Ybysl126fvihOjLK1yx4rsQhuUBXfJs7ui8IRjBY+KBAY7YYJBfN14Sn7MvEAM POBAzgFFA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57272 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eymrV-0022WD-2k; Wed, 21 Mar 2018 19:09:45 -0400 To: Lee Howard , v6ops@ietf.org References: <5BEC18B0-F97C-4AFD-9C42-A98CC8B03834@gmail.com> <731431f9-9014-b492-7561-389e61383f05@huitema.net> <310FBE4B-844E-45CF-9305-498C5B63C0E8@gmail.com> <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <975356C9-C00B-4863-967C-88554D6ED087@strayalpha.com> From: Joe Touch Message-ID: Date: Wed, 21 Mar 2018 16:09:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C7EDC9FD1BB9F86C11FBBAA5" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 23:09:48 -0000 This is a multi-part message in MIME format. --------------C7EDC9FD1BB9F86C11FBBAA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 3/21/2018 6:49 AM, Lee Howard wrote: > > On 03/21/2018 01:10 PM, Joe Touch wrote: >> >>> On Mar 21, 2018, at 2:41 AM, Ole Troan >> > wrote: >>> >>> For IPv4 (and only IPv4) I do think we have a strong case against >>> fragmentation. >>> Routing on the transport layer ports is now a fundamental part of >>> the IPv4 Internet architecture. >>> If the layer 4 information isn't there, then the packet cannot be >>> routed. >> >> DPI into the packet body is also a fundamental part too. > > Not generally at scale, and not with many of the new and upcoming > protocols. Yes, but that's how NAT started too... >> >> However, if the lack of layer 4 info creates a situation where a >> packet can’t be routed, then the device isn’t a router. > > I don't understand this. I understand you mean the subsequent > fragments, except that routers as I understand them perform "network > layer forwarding" [RFC1812, Requirements for IP Version 4 Routers] > Layer 4 is not the network layer; are devices that need L4 info > considered routers? No, but that's the point. If a router can't forward a fragment *because* it lacks transport info, then it's not acting like a router. >> >> Yes, the Internet has many many broken parts. That includes RFCs that >> are inconsistent with our core architecture requirements. >> >> If anyone in the IAB is listening, you’d earn your middle name better >> by dealing with those than trying to seek new “fun†stuff on which to >> pontificate. > > As I take off several hats, I'm not sure what to ask of the IAB here. > > Is it to be the "compliance arm" you mentioned elsewhere in the thread? It is the inconsistency part mentioned above. E.g., take a look at "TRILL over IP transport" and explain to me what "slicing" a packet is in the context of TCP as a tunnel. Or, for that matter, what "IP transport" is. Joe --------------C7EDC9FD1BB9F86C11FBBAA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 3/21/2018 6:49 AM, Lee Howard wrote:

On 03/21/2018 01:10 PM, Joe Touch wrote:

On Mar 21, 2018, at 2:41 AM, Ole Troan <otroan@employees.org> wrote:

For IPv4 (and only IPv4) I do think we have a strong case against fragmentation.
Routing on the transport layer ports is now a fundamental part of the IPv4 Internet architecture.
If the layer 4 information isn't there, then the packet cannot be routed.

DPI into the packet body is also a fundamental part too.

Not generally at scale, and not with many of the new and upcoming protocols.
Yes, but that's how NAT started too...

However, if the lack of layer 4 info creates a situation where a packet can’t be routed, then the device isn’t a router.

I don't understand this. I understand you mean the subsequent fragments, except that routers as I understand them perform "network layer forwarding" [RFC1812, Requirements for IP Version 4 Routers]
Layer 4 is not the network layer; are devices that need L4 info considered routers?
No, but that's the point. If a router can't forward a fragment *because* it lacks transport info, then it's not acting like a router.


Yes, the Internet has many many broken parts. That includes RFCs that are inconsistent with our core architecture requirements.

If anyone in the IAB is listening, you’d earn your middle name better by dealing with those than trying to seek new “fun†stuff on which to pontificate.

As I take off several hats, I'm not sure what to ask of the IAB here.

Is it to be the "compliance arm" you mentioned elsewhere in the thread?
It is the inconsistency part mentioned above.

E.g., take a look at "TRILL over IP transport" and explain to me what "slicing" a packet is in the context of TCP as a tunnel.

Or, for that matter, what "IP transport" is.

Joe
--------------C7EDC9FD1BB9F86C11FBBAA5-- From nobody Wed Mar 21 16:10:33 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00A412E856 for ; Wed, 21 Mar 2018 16:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93E4Gi2IabUg for ; Wed, 21 Mar 2018 16:10:30 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 B449D12E741 for ; Wed, 21 Mar 2018 16:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ke5PoPR40tJtQXzc+V6idltrwBCRb7y/Iw6M7YH0RcU=; b=Z06Rg73I9M9f2zmvoi8zGqHTF4 icofDMgpdO89uq4hVMETXLguJ5Eh8zUb0AM6Fw1bJqQh7phnNiVEDYCILrQCRHLNxrTHp8Roq+NJf Oer6jz71TaadmmrrzIVZxR2GqoP/af292H+83ytp3eQG+mPXBBNFpSxDXyMe2prmQ56u37vCCpR+a 7yF2og0baXDz/z4HyZlje6Fu3/0G4vq4La+0c5oo5qgHKwJ5w/yTbYsF3pgLMJCYE8XAYfzeazh5W vgq1p9LhMriOu+2UOYuGKmN4SXuEEW+aHXzsNCy0rSTw2UJAcKZV3DjfbQhJKKShuostJGPm94ji4 5IyqPpWg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57273 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eymsG-0023PQ-9T; Wed, 21 Mar 2018 19:10:28 -0400 To: Gert Doering Cc: Mikael Abrahamsson , "v6ops@ietf.org WG" References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> From: Joe Touch Message-ID: <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> Date: Wed, 21 Mar 2018 16:10:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180321200444.GX89741@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 23:10:32 -0000 On 3/21/2018 1:04 PM, Gert Doering wrote: > Hi, > > On Wed, Mar 21, 2018 at 06:04:29AM -0700, Joe Touch wrote: >> There???s a big difference between tolerating bugs and faulty equipment vs. tolerating behavior that violates our specs. > In which way, exactly, does a device "vioulate our specs" (which ones, > exactly?) by routing one packet left and one packet right, based on > some local decision process how to distribute packets across multiple > links? It doesn't when it does that. It does when it drops a fragment *because* it lacks a transport header. Joe From nobody Thu Mar 22 03:20:20 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820C41200C5 for ; Thu, 22 Mar 2018 03:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufB4nOZgMJrH for ; Thu, 22 Mar 2018 03:20:15 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF05112D969 for ; Thu, 22 Mar 2018 03:20:14 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id E24C841B42 for ; Thu, 22 Mar 2018 11:20:10 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id D397A41B39; Thu, 22 Mar 2018 11:20:10 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id CFE72403A2; Thu, 22 Mar 2018 11:20:10 +0100 (CET) Date: Thu, 22 Mar 2018 11:20:10 +0100 From: Gert Doering To: Joe Touch Cc: Gert Doering , Mikael Abrahamsson , "v6ops@ietf.org WG" Message-ID: <20180322102010.GE89741@Space.Net> References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RTy+eQJHeE7YIlEm" Content-Disposition: inline In-Reply-To: <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> X-NCC-RegID: de.space User-Agent: Mutt/1.9.3 (2018-01-21) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 10:20:18 -0000 --RTy+eQJHeE7YIlEm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 21, 2018 at 04:10:27PM -0700, Joe Touch wrote: > It does when it drops a fragment *because* it lacks a transport header. Where exactly in this thread was "dropping fragments" mentioned? Fragmented packets arrived *earlier* than non-fragmented, which caused surprises. "Arrive earlier" is sort of the opposite thing from "drop". Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --RTy+eQJHeE7YIlEm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlqzg1gACgkQ31bAZeTO f8UxJA//RX36Ea4TgNm3S4zYXbNmbnhXjlIyRQE3ygd5kRjJHV8B4iohnPt4T3a/ vGFyyD4APRr9OtR4kbaxDUOAgNTQTj32mqog+Th1xZQvF4EBilaYSj2lsOqTUxin HZld19DP8oKUM9NK8w9R4E2O8sh59dwR31QxZ1PUMblSBwejXKipgvJxe9lmJ0NV MlJnSFlTgu/CJlBzjxN2Bm5MFkpwFDiSDdkjrp+lURA/HBdtRfrQd8zj63DWfOUH dWVDyFGgIWe7mN5EzKxDvBgZw1zqjJx/VK4mxjhfAv3OFchkYmsHjjU0XB8gzIzI 3kQOr7NOi72KxxuhCvj/ZLkjJy13/zZgN/yBrJoCD8+a0UD84RgWNnfCaggFrjbl tUxpaIYPyThNRGkO15JlG7/HCfkQLPerwl5M47eCwrJEaquKzJhxusyZWmVFMxmw SJhnqWhYzazD1pJLAm2kq932/r4Kjzei8qzsEOIRG3zYoW8NIudijK2KSO56KKjn iF7mMtSOG9leZQofJQz0dIvsxkwF71kbj8YhhF2ISW7TgGL7USURKjAK9fHSCVU5 Mrp1pggBr6EHUUA/Xs99opJorfEpreLWZUY63ydJYOusbX1D9ayTO8dNM9PyCqlB JoHiz3dARSkHdEnTPbkRDZaFnKT3js4G+4S90dC2FFOdL5Q8vy0= =6Szv -----END PGP SIGNATURE----- --RTy+eQJHeE7YIlEm-- From nobody Thu Mar 22 07:55:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60612D872 for ; Thu, 22 Mar 2018 07:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNSBKzl2O3nh for ; Thu, 22 Mar 2018 07:55:44 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 AA70D12D86E for ; Thu, 22 Mar 2018 07:55:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GcAAC7w7Na/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJrUmFwKAqDUod/jQ2Bc4ERkmGBST0LIwmEWQIag0khNBgBAgE?= =?us-ascii?q?BAQEBAQIDaBwMgmsvBgcDDCEJAgMBAQEBAQEmAQEBAQEBAQEBAQEBARwCDy8SA?= =?us-ascii?q?QEYAQEBAQMSEQQNOgsMBAIBBgINAQMEAQEBAgIGHQMCAgIwFAEICAIEAQ0FCBq?= =?us-ascii?q?EbAEOjx6RTYlrgWs1GwKII4IJBYEIhCeCEYFVP4QSgxMBAQEBARiBHQYBASCCf?= =?us-ascii?q?zCCJAOXfggChVyKTIZPhHuHNIFqhm6BJRw5gVJwFTqCQ4V/hROFPW8BjgsOGIE?= =?us-ascii?q?IAYEVAQE?= X-IPAS-Result: =?us-ascii?q?A2GcAAC7w7Na/yYyC4ddGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?rUmFwKAqDUod/jQ2Bc4ERkmGBST0LIwmEWQIag0khNBgBAgEBAQEBAQIDaBwMg?= =?us-ascii?q?msvBgcDDCEJAgMBAQEBAQEmAQEBAQEBAQEBAQEBARwCDy8SAQEYAQEBAQMSEQQ?= =?us-ascii?q?NOgsMBAIBBgINAQMEAQEBAgIGHQMCAgIwFAEICAIEAQ0FCBqEbAEOjx6RTYlrg?= =?us-ascii?q?Ws1GwKII4IJBYEIhCeCEYFVP4QSgxMBAQEBARiBHQYBASCCfzCCJAOXfggChVy?= =?us-ascii?q?KTIZPhHuHNIFqhm6BJRw5gVJwFTqCQ4V/hROFPW8BjgsOGIEIAYEVAQE?= X-IronPort-AV: E=Sophos;i="5.48,345,1517893200"; d="scan'208";a="280659523" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Mar 2018 10:55:36 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 10:55:36 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0352.000; Thu, 22 Mar 2018 10:55:36 -0400 From: "Mudric, Dusan (Dusan)" To: Jen Linkova , =?utf-8?B?56We5piO6YGU5ZOJ?= CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt Thread-Index: AQHTvfmTCDwHYFt5g0SYi8yGx9x3RaPbA57AgAAVi6GAAEhOAIAA+byw Date: Thu, 22 Mar 2018 14:55:35 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B57E18B@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.150.1 dlp-reaction: no-action x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 14:55:47 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmVuIExpbmtvdmENCj4gU2VudDog V2VkbmVzZGF5LCBNYXJjaCAyMSwgMjAxOCAzOjQ2IFBNDQo+IFRvOiDnpZ7mmI7pgZTlk4kNCj4g Q2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtdjZvcHMtY29uZGl0aW9uYWwtcmFzLTAxLnR4dA0KPiANCj4gT24gVGh1LCBNYXIg MjIsIDIwMTggYXQgNjoyNiBBTSwg56We5piO6YGU5ZOJIDxqaW5tZWlAd2lkZS5hZC5qcD4gd3Jv dGU6DQo+ID4+ID4gW1tEdXNhbl1dIFRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gYXNwZWN0LiBJ ZiBob3N0cyBpbXBsZW1lbnQgdGhlIFByZg0KPiA+PiA+IGZyb20gcmZjNDE5MSNzZWN0aW9uLTIu MiwgdGhleSB3aWxsIHJlY29nbml6ZSBScmYuIFlvdSBzaG91bGQgbm90IGxpbWl0IHRoZQ0KPiA+ PiA+IG9wdGlvbnMgYmFzZWQgb24gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zLg0KPiA+Pg0K PiA+PiBBY3R1YWxseSwgd2Ugc2hvdWxkLiBUaGlzIGlzIGFuIG9wZXJhdGlvbmFsIHdvcmtpbmcg Z3JvdXAsIGFuZCBhcyBzdWNoLA0KPiA+PiBuZWVkcyB0byBkb2N1bWVudCBwcmFjdGljZXMgdGhh dCB3b3JrIHRvZGF5Lg0KPiA+DQo+ID4gSSd2ZSBub3QgY2xvc2VseSBmb2xsb3dlZCB0aGlzIHRo cmVhZCBzbyB0aGlzIG1heSBiZSBvdXQgb2YgY29udGV4dA0KPiA+IChpZiBzbywgc29ycnkpLCBi dXQgaWYgaXQncyBhYm91dCBob3N0IGltcGxlbWVudGF0aW9uIG9mIHRoZSAiUHJmIg0KPiA+IHZh bHVlIG9mIFJGQzQxOTEsIEJTRCB2YXJpYW50cyBoYXZlIGJlZW4gc3VwcG9ydGluZyBpdCBmb3Ig bW9yZSB0aGFuDQo+ID4gMTAgeWVhcnMgKGZvciBleGFtcGxlLCBGcmVlQlNEIGFkZGVkIGl0IGlu IDIwMDYNCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtDQo+IDNBX19zdm53ZWIuZnJlZWJzZC5vcmdfYmFzZV9oZWFkX3N5c19uZXRpbmV0Nl9uZDYt NUZydHIuYy0zRnJldmlzaW9uLQ0KPiAzRDE1Njg3MS0yNnZpZXctDQo+IDNEbWFya3VwJmQ9RHdJ R2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpDQo+IENyaElv VVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09QnQ1VHIzT0Z6dU1nLUtENi0NCj4gVm5KT1lKeHVFX285 OE11QlV1dldoZUtRWVUmcz1mS1pWN3VPWjZ0bXlXaXA0R3ZoMm9USWJlRk0tDQo+IDQ4TGVqREZF RWxnU2Y3byZlPSkuDQo+ID4gU28gSSBzdXNwZWN0IGl0J3MgYWxzbyBpbiBpT1MuICBVbmxpa2Ug b3RoZXIgZmVhdHVyZXMgb2YNCj4gPiB0aGUgUkZDIGxpa2Ugcm91dGUgaW5mb3JtYXRpb24gb3B0 aW9uLCBpbXBsZW1lbnRpbmcgUHJmIGlzIHByZXR0eQ0KPiA+IHNpbXBsZSwgc28gSSB3b3VsZG4n dCBiZSBzdXJwcmlzZWQgaWYgaXQncyBhbHNvIGF2YWlsYWJsZSBpbiBub24NCj4gPiBCU0QtZmxh dm9yIGhvc3QgaW1wbGVtZW50YXRpb25zLg0KPiANCj4gWWVhaCwgeW91IGFyZSByaWdodCwgaXQn cyByZWFzb25hYmx5IHdlbGwgc3VwcG9ydGVkLiBUaGUgaXNzdWUgaGVyZSBpcw0KPiB0aGF0IGp1 c3QgdXNpbmcgcm91dGVyIHByZWZlcmVuY2Ugd291bGQgbm90IGhlbHAgYXQgYWxsIChvciBtYXkg ZXZlbg0KPiBtYWtlIHRoZSByb3V0aW5nIG1vcmUgc3ViLW9wdGltYWwpLiBMZXQncyBzYXkgYSBo b3N0IGhvbm9ycyB0aGUgcm91dGVyDQo+IHByZWZlcmVuY2UgYW5kIHNlbGVjdHMgYSByb3V0ZXIg IFIxIChjb25uZWN0ZWQgdG8gYW4gSVNQMSkgYXMgYQ0KPiBkZWZhdWx0IGdhdGV3YXkgYnV0IGl0 IGRvZXMgbm90IHN1cHBvcnQgUnVsZSA1LjUsIHRoZW4gaXQgbWF5IHNlbGVjdA0KPiBJU1AyIHNv dXJjZSBwcmVmaXggYW5kIHRoZSBwYWNrZXQgd2lsbCBiZSBzZW5kIHRvIElTUDIgKCBSMSAtPiBS MiAtPg0KPiBJU1AyKS4gU28gSSdtIG5vdCBzdXJlIEkgY2FuIHNlZSBhbnkgdmFsdWUgaW4gdXNp bmcgdGhlIHJvdXRlcg0KPiBwcmVmZXJlbmNlIHcvbyBydWxlIDUuNSBzdXBwb3J0IGluIHRoaXMg c2NlbmFyaW8uLkFtIEkgbWlzc2luZw0KPiBhbnl0aGluZz8NCj4gDQoNCltbRHVzYW5dXSANCltb RHVzYW5dXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0 MzQtYmlzLTA3IG1ha2VzIFJ1bGUgNS41IFNIT1VMRCByZXF1aXJlbWVudDoNCiJbUkZDODAyOF0N CiAgIHVwZGF0ZXMgcnVsZSA1LjUgZnJvbSBbUkZDNjcyNF07IGltcGxlbWVudGF0aW9ucyBTSE9V TEQgaW1wbGVtZW50DQogICB0aGlzIHJ1bGUuIg0KDQpUaGF0IGRvZXMgbm90IG1lYW4gdGhlcmUg YXJlIG5vdCBlbmQgcG9pbnRzIHRoYXQgZG9uJ3QgYmVuZWZpdCBmcm9tIFJ1bGUgNS41LiBJZiBi b3RoIFByZiBhbmQgUnVsZSA1LjUgYXJlIGltcGxlbWVudGVkLCB0aGUgZW5kcG9pbnRzIHdpbGwg YmVuZWZpdCBmcm9tIFByZiBwcmVmZXJlbmNlIHNlbnQgZnJvbSB0aGUgcm91dGVyLg0KDQpCdHcs IGlzIHRoZXJlIGFueSB1cGRhdGUgb24gdGhpcyBkaXNjdXNzaW9uIGFib3V0IExpbnV4IFJ1bGUg NS41OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Y2b3BzL2N1cnJlbnQv bXNnMjQ5MzQuaHRtbCANCg0KPiANCj4gLS0NCj4gU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g djZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJR2FRJmM9QkZwV1F3OGJzdUtwbDENCj4gU2dpWkg2NFEm cj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09QnQ1VHIzDQo+ IE9GenVNZy1LRDYtDQo+IFZuSk9ZSnh1RV9vOThNdUJVdXZXaGVLUVlVJnM9ZkFDbDE5VGVlcTJ4 VThldk5Yc2dpam1vcWJ3WUptTFhzag0KPiA4NVg5RXV4R00mZT0NCg== From nobody Thu Mar 22 08:12:53 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB812D88D for ; Thu, 22 Mar 2018 08:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQE62iV8pZ7b for ; Thu, 22 Mar 2018 08:12:51 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93232126D05 for ; Thu, 22 Mar 2018 08:12:50 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id g203-v6so13676619lfg.11 for ; Thu, 22 Mar 2018 08:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DIKN9GZPURLlGSpeOCpC+q47A+yabUSUSddvQMDsDvQ=; b=G+qfjx6tPAEHTWQZ0B8AETELAIAhEHvT3pssCf9XjR1ib3V5BTVnvnhttcuINMVKNE OombYtCwPDnFIDvjbwERIMQK1+x1UgNdVebKO5tM3w2RhScIXzxqmo3ZQwHbu9CLXeQk fhwK4FT7AYjM05pmAOZF09Iug5Z/4tkGEJlV+/n5YFniaR7/t9A1ZwYXrcMF6/CobN/k eDiV188W0Unjos0HWueOFnjIUL9V0avdrgn8a2Niknn/VA7TZzhTp2XVeSsob31sN/TW XNJIuppnfST9HPL168UHZg7hBeR+nVNd9CmWgd9b7CnVHtD8TasNzZ2fMCETlmV4s8Di SVNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DIKN9GZPURLlGSpeOCpC+q47A+yabUSUSddvQMDsDvQ=; b=qlq5NL+FPQeEt6nHuO8pUZNb477Vvg+etq8NxoPRjIAfCyFGsIP4Y0Uh+WXPEtGMBH jpJ2gsXmhJeoyNoSTEtV/h5SLIXHiW1VD/hzcmYhgjafKVZl801dhpLCjfMBQ6ZvBEea Kbg3ZMwmOoBNUcFpbGTmuTQx/N+hkSo0YTGNG6+BXvcpjWXBHHmh6mJY4AViCvpAY8iG JFpkn96EGkGpafMtX5LPmEAJQKHYviJNGXTFFqoLPtPixbgh6uzdmguYYlheXVlRWgVe trntnBZRY/wgiobw2qQEY8JgVRPElecguMqL3udIlVfqQGJWAdCJYeJuqFOV0UnCy3pT 5nZQ== X-Gm-Message-State: AElRT7GOEgBAXYzBRrDvC0E9ws/wqHqEbTZ4h7wfGzNga66Aee0Q+fUq kXzMgthcZFoYOD62uGcp1zJLi6I4yQd1f2O6urm+rS4g X-Google-Smtp-Source: AG47ELvsgk6M3gZdT+rCes4mZ+zp7dTIFP4o+OWqQ6uBtr4IJYVdrSjVEEOJeWjuMiF7Tkq7f8W3uynVeebMw2xKGd0= X-Received: by 2002:a19:2145:: with SMTP id h66-v6mr16225391lfh.63.1521731568675; Thu, 22 Mar 2018 08:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 08:12:27 -0700 (PDT) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B57E18B@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57E18B@AZ-US1EXMB03.global.avaya.com> From: Jen Linkova Date: Fri, 23 Mar 2018 02:12:27 +1100 Message-ID: To: "Mudric, Dusan (Dusan)" Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 15:12:52 -0000 On Fri, Mar 23, 2018 at 1:55 AM, Mudric, Dusan (Dusan) wrote: > [[Dusan]] https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-07 makes Rule 5.5 SHOULD requirement: > "[RFC8028] > updates rule 5.5 from [RFC6724]; implementations SHOULD implement > this rule." > > That does not mean there are not end points that don't benefit from Rule 5.5. If both Prf and Rule 5.5 are implemented, the endpoints will benefit from Prf preference sent from the router. Sure. There is draft, draft-ietf-rtgwg-enterprise-pa-multihoming which discusses in details multihoming for networks, where hosts support Rule 5.5. However there is a demand to provide multihoming for networks where not all endpoints support rule 5.5. The general solution described in draft-ietf-rtgwg-enterprise-pa-multihoming has some limitations in those case. So another document (this one) was written and explicitly scoped to very specific use case: 1) Internet access only; 2) Internet uplinks are used in either 'Active/Backup' or load sharing (no traffic engineering) modes; 3) hosts are not expected to support rule 5.5 (== the documented solution should work for hosts which do not support it). So I'm not sure I understand why do you insist on expanding the scope of this document to the scope covered by draft-ietf-rtgwg-enterprise-pa-multihoming. Doing so will violate the requirement #3 above. From nobody Thu Mar 22 08:31:07 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6649412D947 for ; Thu, 22 Mar 2018 08:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WUfyLiwcdtO for ; Thu, 22 Mar 2018 08:30:58 -0700 (PDT) Received: from jax4mhob16.registeredsite.com (jax4mhob16.registeredsite.com [64.69.218.104]) (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 91ADD12D893 for ; Thu, 22 Mar 2018 08:30:58 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by jax4mhob16.registeredsite.com (8.14.4/8.14.4) with ESMTP id w2MFUrx4042041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 22 Mar 2018 11:30:53 -0400 Received: (qmail 13086 invoked by uid 0); 22 Mar 2018 15:30:53 -0000 X-TCPREMOTEIP: 31.133.147.181 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.147.181?) (lee@asgard.org@31.133.147.181) by 0 with ESMTPA; 22 Mar 2018 15:30:53 -0000 To: v6ops@ietf.org From: Lee Howard Message-ID: Date: Thu, 22 Mar 2018 15:30:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6EBA187FF7F6F79F6F07E82E" Content-Language: en-US Archived-At: Subject: [v6ops] Transition mechanisms in use X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 15:31:05 -0000 This is a multi-part message in MIME format. --------------6EBA187FF7F6F79F6F07E82E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As I mentioned during the WG meeting, I wondered who was using which transition technologies, and here's what I got: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit?usp=sharing This sheet has all the properties inherent to crowd-sourcing: anyone can edit, and anyone can create mayhem. For the record, here are just a few columns from the sheet: ISP (name) Country Transition Mechanism (NAT64/464xlat, 6rd, DS-Lite, Dual Stack, ...) Network Type (mobile, DSL, fiber, cable, satellite,...) AFAIR Cablecom DS-Lite Altibox DK,NO 6RD Fibre AT&T US ? Mobile AT&T US 6rd AT&T Old PPPoE ADSL AT&T Uverse US Native IPv6 (Dual Stack) 802.1x "IPDSL" over ADSL/ADSL2/ADSL2+/VDSL and Fiber Bouygues FR 464XLAT BT/EE GB 464XLAT Mobile CenturyLink US 6rd Charter US MAP-T (EFT) DOCSIS Comcast US dual stack DOCSIS Digicel TT Dual Stack Mobile DNA FI dual stack eir IE dual stack VDSL2 & FTTH Forthnet GR Dual-Stack, DS-Lite DSL FPT VN dual stack LTE Free FR 6rd Get NO Dual stack DOCSIS Ice NO Dual stack 3GPP Jazztel dual stack, DS-Lite fibre? Kabel Deutschland DE DS-Lite DOCSIS MTS RU dual-stack Netassist UA dual stack fibre, ETTH O2 CZ DS-Lite DSL Orange Espana ES dual stack, DS-Lite fibre Orange France FR Dual-stack Mobile Orange France FR Dual-stack ADSL, VDSL, Fibre Orange Polska PL 464XLAT Mobile Orange Polska PL DS-Lite DSL and fibre Orange Slovakia SK DS-Lite DSL OTE GR Dual-stack / lw4o6 xDSL Proximus BE dual stack DSL RCS & RDS RO Dual Stack FTTH Reliance Jio IN MAP-T, Dual-stack DOCSIS Rogers CA Dual Stack Wireline Rogers CA NAT64/XLAT464 Wireless SK Telecom KR 464XLAT Sky UK UK Dual Stack DSL + Fibre Sonic.net US 6rd Wireline Sprint US 464XLAT mobile Swisscom CH 6rd DSL and fibr T-Mobile US 464XLAT, NAT64 mobile Tele2 SE Dual stack 3GPP Telecentro AR Telenet BE dual stack DOCSIS Telenor NO Dual stack GPON, DOCSIS, xDSL, 3GPP Telstra AU 464XLAT mobile Telus CA 464XLAT? Transix JP DS-Lite Tre DK,SE Dual stack 3GPP Verizon FIOS US IPv4 only fibr Verizon Wireless US Dual-stack mobile Virgin Media (LGI) IE DS-Lite Docsis Ziggo NL DS-Lite Docsis JPNE JP MAP-E If you see inaccuracies, or have information on other providers, please add it using the link above. Lee --------------6EBA187FF7F6F79F6F07E82E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

As I mentioned during the WG meeting, I wondered who was using which transition technologies, and here's what I got:

https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit?usp=sharing

This sheet has all the properties inherent to crowd-sourcing: anyone can edit, and anyone can create mayhem. For the record, here are just a few columns from the sheet:

ISP (name) Country Transition Mechanism (NAT64/464xlat, 6rd, DS-Lite, Dual Stack, ...) Network Type (mobile, DSL, fiber, cable, satellite,...)
AFAIR Cablecom
DS-Lite
Altibox DK,NO 6RD Fibre
AT&T US ? Mobile
AT&T US 6rd AT&T Old PPPoE ADSL
AT&T Uverse US Native IPv6 (Dual Stack) 802.1x "IPDSL" over ADSL/ADSL2/ADSL2+/VDSL and Fiber
Bouygues FR 464XLAT
BT/EE GB 464XLAT Mobile
CenturyLink US 6rd
Charter US MAP-T (EFT) DOCSIS
Comcast US dual stack DOCSIS
Digicel TT Dual Stack Mobile
DNA FI dual stack
eir IE dual stack VDSL2 & FTTH
Forthnet GR Dual-Stack, DS-Lite DSL
FPT VN dual stack LTE
Free FR 6rd
Get NO Dual stack DOCSIS
Ice NO Dual stack 3GPP
Jazztel
dual stack, DS-Lite fibre?
Kabel Deutschland DE DS-Lite DOCSIS
MTS RU dual-stack
Netassist UA dual stack fibre, ETTH
O2 CZ DS-Lite DSL
Orange Espana ES dual stack, DS-Lite fibre
Orange France FR Dual-stack Mobile
Orange France FR Dual-stack ADSL, VDSL, Fibre
Orange Polska PL 464XLAT Mobile
Orange Polska PL DS-Lite DSL and fibre
Orange Slovakia SK DS-Lite DSL
OTE GR Dual-stack / lw4o6 xDSL
Proximus BE dual stack DSL
RCS & RDS RO Dual Stack FTTH
Reliance Jio IN MAP-T, Dual-stack DOCSIS
Rogers CA Dual Stack Wireline
Rogers CA NAT64/XLAT464 Wireless
SK Telecom KR 464XLAT
Sky UK UK Dual Stack DSL + Fibre
Sonic.net US 6rd Wireline
Sprint US 464XLAT mobile
Swisscom CH 6rd DSL and fibr
T-Mobile US 464XLAT, NAT64 mobile
Tele2 SE Dual stack 3GPP
Telecentro AR

Telenet BE dual stack DOCSIS
Telenor NO Dual stack GPON, DOCSIS, xDSL, 3GPP
Telstra AU 464XLAT mobile
Telus CA 464XLAT?
Transix JP DS-Lite
Tre DK,SE Dual stack 3GPP
Verizon FIOS US IPv4 only fibr
Verizon Wireless US Dual-stack mobile
Virgin Media (LGI) IE DS-Lite Docsis
Ziggo NL DS-Lite Docsis
JPNE JP MAP-E

If you see inaccuracies, or have information on other providers, please add it using the link above.

Lee


--------------6EBA187FF7F6F79F6F07E82E-- From nobody Thu Mar 22 08:32:42 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F99C126E64 for ; Thu, 22 Mar 2018 08:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4_nkyz5eqdY for ; Thu, 22 Mar 2018 08:32:39 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 A6CE8127076 for ; Thu, 22 Mar 2018 08:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oOYb0x02upnYy2Kj9e0wVIfSQgNyfja9Gq6GK86bkBU=; b=rfQlPBqruXzIyCRw+hk3WIwi1 NVBFruRBW/toz8q1MMMwTsx8Xh/EscRZlPNVjFT9t2dXpLHBvhamjeK5bhnbJbwWN/21BZtnqd2Dp nLeJbhuYuh4XqQzfDSHogCWJLzY/bT9TU3Hg5phNi8FBbSldEWKELekb4Hg7Lr1spDZMmasvuv1vS lcDBqMwjYiyO37/uS0ita0r67NdXIU5iYjaS47fSmwhBPhHge2kavNg2tYkPgYSr/oXWp2wBl8QBk ew30XwfBvbgIamotTCdSqW/pvz8P0q5TlFZYnrO28tv67ZL4YMU+/Xki2WYArfPrTd+cP44LM0Xkq V3TeA5pZA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60145 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ez2CY-0040Fy-Nr; Thu, 22 Mar 2018 11:32:27 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_5835CF1E-FC4E-4335-99DE-2CB636A0748D" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <20180322102010.GE89741@Space.Net> Date: Thu, 22 Mar 2018 08:32:24 -0700 Cc: Mikael Abrahamsson , "v6ops@ietf.org WG" Message-Id: References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 15:32:41 -0000 --Apple-Mail=_5835CF1E-FC4E-4335-99DE-2CB636A0748D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 22, 2018, at 3:20 AM, Gert Doering wrote: >=20 > On Wed, Mar 21, 2018 at 04:10:27PM -0700, Joe Touch wrote: >> It does when it drops a fragment *because* it lacks a transport = header. >=20 > Where exactly in this thread was "dropping fragments" mentioned? Sorry - I was assuming that was the problem because =E2=80=94 (see next = comment) >=20 > Fragmented packets arrived *earlier* than non-fragmented, which caused > surprises. "Arrive earlier" is sort of the opposite thing from = "drop=E2=80=9D. If reordering is a =E2=80=9Csurprise=E2=80=9D then you are not running = IP. Joe --Apple-Mail=_5835CF1E-FC4E-4335-99DE-2CB636A0748D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 22, 2018, at 3:20 AM, Gert Doering <gert@space.net> = wrote:

On Wed, Mar 21, 2018 at = 04:10:27PM -0700, Joe Touch wrote:
It does when it drops a = fragment *because* it lacks a transport header.

Where exactly in this thread was = "dropping fragments" mentioned?

Sorry - I was = assuming that was the problem because =E2=80=94 (see next comment)

Fragmented packets arrived *earlier* than = non-fragmented, which caused
surprises.  "Arrive = earlier" is sort of the opposite thing from = "drop=E2=80=9D.

If = reordering is a =E2=80=9Csurprise=E2=80=9D then you are not running = IP.

Joe

= --Apple-Mail=_5835CF1E-FC4E-4335-99DE-2CB636A0748D-- From nobody Thu Mar 22 09:13:43 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4C124B18 for ; Thu, 22 Mar 2018 09:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8ZSFvaXvgIX for ; Thu, 22 Mar 2018 09:13:40 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 6A0991200FC for ; Thu, 22 Mar 2018 09:13:40 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 139so17247653wmn.2 for ; Thu, 22 Mar 2018 09:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Njs34lozp2GU5EYfaPV6QYajhewJxtvDjApJDX2OEr4=; b=uU7+IEbn8YGjGYBGg6Qwft14m9J2kuwzpzxJpU1b0Rp6Fo7pokCOzRHCknFnPYSoc7 RQMb4ts8a+/GHnIhOKDgDR28AspfT09Y4ZElJ72kX66ywR4kZDsyGb35SPeLqVN3Y8co jCGBTJh8rOJaCMb06df1tU3SOi3ovvmJNLdEGEWMts9nWLalTIvA2/BV/VjHlFJUIn9h 3YalLfWOrcgdtN4NgPQPzVmiUTLoMFO7G7hC8/zk+m8Bj3o4Mq+/6teMkG9tXq+bgVT4 gAQDSVBdsJUg9WY6lvCcsoyeaNaU/prhK5cSQc7dXTvx7VYnrkQMAlXfFvdxGDKwpUQ0 uxRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Njs34lozp2GU5EYfaPV6QYajhewJxtvDjApJDX2OEr4=; b=XL4Y3D7BgaELXL70Q0pJz/hzzFP1oy/4JbHOiYaj/gMbbYNGWjabluNeHdF6vK5YuA 2SZbcU1CdlwicglXgU1QbJYfGJ1ykQXWmlS5r3GXjfVDLN8nHPTmNoYp3q/iSKt6IJWL vUMfU+EMdzpZMNgVW1tckpfVYOdYh0MnSU+y4CraY/DaMpn7gohvoM8uKRt2iZT9FB7n izCkSZu1/VU48epH+qq2dEk44PVrWyfPUyHF0O5TvA4uQDRcp7Gv+6TziA4Q4Iz5JDFO cC6l5r/PD+F7cAP1ipAZ3GFsCEJ/XeFyqQJuqeJoYu2ZPu3+w4ZnWUHjiiwejvZIAdz1 kMcQ== X-Gm-Message-State: AElRT7Fdy8q14OD2O9xY6zEBpimqO3VyW2A6qf7lN082mTIsOfYXR1gW 0RSNQ4P4A6BEnii6koAbUSKdGX2B7jlvg8R8bv/BzQ== X-Google-Smtp-Source: AG47ELuXacs3fTlkbhU+9vuCCH7q+P9J3QV1GhATHbbfGVuwV7lz+PFXkNNQEMPnTrTHrE8wXFJMm7zFn5+BeezvLVA= X-Received: by 10.28.153.75 with SMTP id b72mr6500999wme.127.1521735218456; Thu, 22 Mar 2018 09:13:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.130.204 with HTTP; Thu, 22 Mar 2018 09:13:17 -0700 (PDT) In-Reply-To: References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57E18B@AZ-US1EXMB03.global.avaya.com> From: Lorenzo Colitti Date: Thu, 22 Mar 2018 16:13:17 +0000 Message-ID: To: Jen Linkova Cc: "Mudric, Dusan (Dusan)" , "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary="001a114b2d32241d630568029753" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 16:13:42 -0000 --001a114b2d32241d630568029753 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 22, 2018 at 3:12 PM, Jen Linkova wrote: > 3) hosts are not expected to support rule 5.5 (== the documented > solution should work for hosts which do not support it). > I think this is the key point here. This is an operational working group and the goal of this document is to describe operational practices that work on existing hosts, and the majority of hosts today do *not* support rule 5.5. If setting the router preference will help such hosts multihome better, *and* if the router preference is accepted by the majority of hosts today (is it?) then that could be in scope for this document. But I think that practices that will not help the majority of existing hosts aren't in scope for this document. --001a114b2d32241d630568029753 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 22, 2018 at 3:12 PM, Jen Linkova <furry13@gmail.com>= wrote:
3) hosts are n= ot expected to support rule 5.5 (=3D=3D the documented
solution should work for hosts which do not support it).

I think this is the key point here. This is an operationa= l working group and the goal of this document is to describe operational pr= actices that work on existing hosts, and the majority of hosts today do *no= t* support rule 5.5.

If setting the router prefere= nce will help such hosts multihome better, *and* if the router preference i= s accepted by the majority of hosts today (is it?) then that could be in sc= ope for this document. But I think that practices that will not help=C2=A0t= he majority of existing hosts aren't in scope for this document.
<= /div>
--001a114b2d32241d630568029753-- From nobody Thu Mar 22 09:19:24 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC04E126D3F for ; Thu, 22 Mar 2018 09:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7HlHHFDqrLG for ; Thu, 22 Mar 2018 09:19:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 6D064126DED for ; Thu, 22 Mar 2018 09:19:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GtAACa1rNa/yYyC4ddGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJrUmFwKAqDUod/jQ2Bc4ERhmqLd4FJPQsjCYRZAhqDSSE0GAE?= =?us-ascii?q?CAQEBAQEBAgNoHAyCazUHAwwhCQIvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBA?= =?us-ascii?q?xIREUUMBAIBBgINAQMEAQEBAgIGHQMCAgIfERQBCAgCBA4FCBMHhFQDFQEOjxy?= =?us-ascii?q?RTYlrgiAbAoZpDYEsggkFgQiEJ4IRgVU/hBKCUUIEGX9GFYJqMIIkA5dQLggCh?= =?us-ascii?q?VyFfQGEToN0gluEe4keO4YzgSUcOYFScBWCfYIcg2OKUG+PRAGBFQEB?= X-IPAS-Result: =?us-ascii?q?A2GtAACa1rNa/yYyC4ddGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?rUmFwKAqDUod/jQ2Bc4ERhmqLd4FJPQsjCYRZAhqDSSE0GAECAQEBAQEBAgNoH?= =?us-ascii?q?AyCazUHAwwhCQIvAQEBAQEBAQEBAQEBARwCD0EBARgBAQEBAxIREUUMBAIBBgI?= =?us-ascii?q?NAQMEAQEBAgIGHQMCAgIfERQBCAgCBA4FCBMHhFQDFQEOjxyRTYlrgiAbAoZpD?= =?us-ascii?q?YEsggkFgQiEJ4IRgVU/hBKCUUIEGX9GFYJqMIIkA5dQLggChVyFfQGEToN0glu?= =?us-ascii?q?Ee4keO4YzgSUcOYFScBWCfYIcg2OKUG+PRAGBFQEB?= X-IronPort-AV: E=Sophos;i="5.48,345,1517893200"; d="scan'208";a="236533594" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Mar 2018 12:19:03 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 12:19:03 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.03.0352.000; Thu, 22 Mar 2018 12:19:02 -0400 From: "Mudric, Dusan (Dusan)" To: Jen Linkova CC: =?utf-8?B?56We5piO6YGU5ZOJ?= , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt Thread-Index: AQHTwfBIEDppexEgS0q8/8aeBkftOKPcbIZQ Date: Thu, 22 Mar 2018 16:19:01 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B57F2AF@AZ-US1EXMB03.global.avaya.com> References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B562054@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57DDBB@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E459B57E18B@AZ-US1EXMB03.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.150.1 dlp-reaction: no-action x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 16:19:23 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmVuIExpbmtvdmEgW21h aWx0bzpmdXJyeTEzQGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDIyLCAyMDE4 IDExOjEyIEFNDQo+IFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikNCj4gQ2M6IOelnuaYjumBlOWT iTsgdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi12Nm9wcy1jb25kaXRpb25hbC1yYXMtMDEudHh0DQo+IA0KPiBPbiBGcmksIE1hciAy MywgMjAxOCBhdCAxOjU1IEFNLCBNdWRyaWMsIER1c2FuIChEdXNhbikNCj4gPGRtdWRyaWNAYXZh eWEuY29tPiB3cm90ZToNCj4gPiBbW0R1c2FuXV0gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0y RGlldGYtMkQ2bWFuLTJEcmZjNjQzNC0yRGJpcy0NCj4gMkQwNyZkPUR3SUJhUSZjPUJGcFdRdzhi c3VLcGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvDQo+IFVXQjhZTFpVMjMwMjlz TVFHUTJrWSZtPTNnZm5oR3ZabXlBSnNUSWNubWpFM3JHd05YSTlNMlBzVEJVYQ0KPiBaMkhNTnA0 JnM9SUJvMTJBU25pZ3lqdEYzeTltelVHLWp4b0xZRTVJb2Y4MHYzdHdZM0FzOCZlPSBtYWtlcw0K PiBSdWxlIDUuNSBTSE9VTEQgcmVxdWlyZW1lbnQ6DQo+ID4gIltSRkM4MDI4XQ0KPiA+ICAgIHVw ZGF0ZXMgcnVsZSA1LjUgZnJvbSBbUkZDNjcyNF07IGltcGxlbWVudGF0aW9ucyBTSE9VTEQgaW1w bGVtZW50DQo+ID4gICAgdGhpcyBydWxlLiINCj4gPg0KPiA+IFRoYXQgZG9lcyBub3QgbWVhbiB0 aGVyZSBhcmUgbm90IGVuZCBwb2ludHMgdGhhdCBkb24ndCBiZW5lZml0IGZyb20gUnVsZSA1LjUu DQo+IElmIGJvdGggUHJmIGFuZCBSdWxlIDUuNSBhcmUgaW1wbGVtZW50ZWQsIHRoZSBlbmRwb2lu dHMgd2lsbCBiZW5lZml0IGZyb20gUHJmDQo+IHByZWZlcmVuY2Ugc2VudCBmcm9tIHRoZSByb3V0 ZXIuDQo+IA0KPiBTdXJlLiBUaGVyZSBpcyBkcmFmdCwgZHJhZnQtaWV0Zi1ydGd3Zy1lbnRlcnBy aXNlLXBhLW11bHRpaG9taW5nIHdoaWNoDQo+IGRpc2N1c3NlcyBpbiBkZXRhaWxzIG11bHRpaG9t aW5nIGZvciBuZXR3b3Jrcywgd2hlcmUgaG9zdHMgc3VwcG9ydA0KPiBSdWxlIDUuNS4NCj4gSG93 ZXZlciB0aGVyZSBpcyBhIGRlbWFuZCB0byBwcm92aWRlIG11bHRpaG9taW5nIGZvciBuZXR3b3Jr cyB3aGVyZQ0KPiBub3QgYWxsIGVuZHBvaW50cyBzdXBwb3J0IHJ1bGUgNS41LiBUaGUgZ2VuZXJh bCBzb2x1dGlvbiBkZXNjcmliZWQgaW4NCj4gZHJhZnQtaWV0Zi1ydGd3Zy1lbnRlcnByaXNlLXBh LW11bHRpaG9taW5nIGhhcyBzb21lIGxpbWl0YXRpb25zIGluDQo+IHRob3NlIGNhc2UuIFNvIGFu b3RoZXIgZG9jdW1lbnQgKHRoaXMgb25lKSB3YXMgd3JpdHRlbiBhbmQgZXhwbGljaXRseQ0KPiBz Y29wZWQgdG8gdmVyeSBzcGVjaWZpYyB1c2UgY2FzZToNCj4gDQo+IDEpIEludGVybmV0IGFjY2Vz cyBvbmx5Ow0KPiAyKSBJbnRlcm5ldCB1cGxpbmtzIGFyZSB1c2VkIGluIGVpdGhlciAnQWN0aXZl L0JhY2t1cCcgb3IgbG9hZCBzaGFyaW5nDQo+IChubyB0cmFmZmljIGVuZ2luZWVyaW5nKSBtb2Rl czsNCj4gMykgaG9zdHMgYXJlIG5vdCBleHBlY3RlZCB0byBzdXBwb3J0IHJ1bGUgNS41ICg9PSB0 aGUgZG9jdW1lbnRlZA0KPiBzb2x1dGlvbiBzaG91bGQgd29yayBmb3IgaG9zdHMgd2hpY2ggZG8g bm90IHN1cHBvcnQgaXQpLg0KPiANCj4gU28gSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB3aHkg ZG8geW91IGluc2lzdCBvbiBleHBhbmRpbmcgdGhlIHNjb3BlDQo+IG9mIHRoaXMgZG9jdW1lbnQg dG8gdGhlIHNjb3BlIGNvdmVyZWQgYnkNCj4gZHJhZnQtaWV0Zi1ydGd3Zy1lbnRlcnByaXNlLXBh LW11bHRpaG9taW5nLg0KPiBEb2luZyBzbyB3aWxsIHZpb2xhdGUgdGhlIHJlcXVpcmVtZW50ICMz IGFib3ZlLg0KDQpbW0R1c2FuXV0gDQpbW0R1c2FuXV0gVGhpcyBzY29wZSBpcyB2ZXJ5IGNsZWFy LiBDYW4geW91IHBsZWFzZSBwdXQgaXQgaW4gdGhlIGRyYWZ0Pw0KDQpQbGVhc2UgYWRkIHRoYXQg d2hlbiB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yIGNvbmZpZ3VyZXMgdGhlIHBvbGljeSBmb3Ig bG9hZCBiYWxhbmNpbmcgb24gcm91dGVycyBSMSBhbmQgUjIsIHRoZSBzYW1lIHBvbGljeSBtaWdo dCBiZSB1c2VkIHRvIHNldCB0aGUgZGVmYXVsdCBvciBtb3JlIHNwZWNpZmljIHJvdXRlciBwcmVm ZXJlbmNlcyBmcm9tIFJGQzQxOTEuDQo= From nobody Thu Mar 22 09:45:42 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0547E124B17 for ; Thu, 22 Mar 2018 09:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_kUaaA-xVYz for ; Thu, 22 Mar 2018 09:45:38 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 1981E1242F5 for ; Thu, 22 Mar 2018 09:45:38 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id a22-v6so14147379lfg.9 for ; Thu, 22 Mar 2018 09:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OjDP5aDOHQjvAAwkQNexmraeNsa7Sr4UBuFnZ3ny+i4=; b=c7xI1lFW+dE50UtKc6HAdVYorioRPOECmqWvxoEzvJKJWfoxKbRfVXMDvGYxFp4G5S /RxiF6WocxabgyyH9e4CPF369/PcE1w6jzXZWWdAs40LQlpSeRJvpB9jjqJDYlwpIdyB S27RfjINd+D/WBvv49/dLKH/GwGv2hZ7y/MIZv6/0+H6nuM0b/ypZsbkkVWO6OFfy7Ul t5B1izfV4NbZiKBmbiRkxp14o5ZAmxNr9cTTb1fH0PUG53yzr4vUgv3PCnB3d5sbm5rw nmF0mwFyq0TUiWGtixg5APHXb9XCgiNpROsOrVjxPExg9WSLrhsYJ/oX04vShrbeIhCk R33Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OjDP5aDOHQjvAAwkQNexmraeNsa7Sr4UBuFnZ3ny+i4=; b=K9N86DnMFwJGK/Qc11Q1EIB1h13t4TtkS2GHv3+XBzebHuidZZa3Jho9OJ2LpjxMsx T3Gm6U5Qi+IWu9eomNJYvka6NRG9HzEAa2hlBiOrmDL2eEsRDrPhxZ2RORsX6ZBzKq50 UbsixAtYuteSimJq4KQeZeLXyOksvxnItQy4WVqFD5F5qpjFZn82lNzBe/R0xd6R02ug pVrmGodEVpS4oV48bKdxWL4hH1FjMFLEoyxpPAut35iCHAfKyLLuV3k+MQ3b5CxCMtuh FjaBdLuUdsxlyv+WVFS9Z1PtXx5D5jqKGuPiBKiU7Avf5NNgori7y5cn37CNRdBI+ebh /OLg== X-Gm-Message-State: AElRT7HgupisPr1f++lhDZSUBvo2mW5dns35P+v+ttjQaB9s/RHxevn0 vEpVxzl5tPRWUMBXFEuaMb9ZoI0HIPHBnl2c6BA= X-Google-Smtp-Source: AG47ELuiagkLtpkNfflJzly6/bTJ5CJydRD9crW7GEQRaQkrm9ddQeAmQef7yXeCMGHJ3X9l7XBtLouR7QcYEDAPb7g= X-Received: by 2002:a19:17d4:: with SMTP id 81-v6mr16615758lfx.22.1521737136257; Thu, 22 Mar 2018 09:45:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 09:45:15 -0700 (PDT) In-Reply-To: <20180322102010.GE89741@Space.Net> References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> From: Jen Linkova Date: Fri, 23 Mar 2018 03:45:15 +1100 Message-ID: To: Gert Doering Cc: Joe Touch , "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 16:45:40 -0000 On Thu, Mar 22, 2018 at 9:20 PM, Gert Doering wrote: > On Wed, Mar 21, 2018 at 04:10:27PM -0700, Joe Touch wrote: >> It does when it drops a fragment *because* it lacks a transport header. > > Where exactly in this thread was "dropping fragments" mentioned? Actually,,, There is one really nasty scenario when hashing is causing not just reordering but packet loss. Scenario 1.1: a router R1 is doing ECMP, sends 1st fragment to R2 while other fragments went to R3. If the paths to the destination (anycast!) on R2 and R3 do not converge, the first and subsequent fragments might never meet. Scenario 1.2: a load-balancer using 5-tupes and a number of end systems behind it. If the first fragment is forwarded by using L4 info, then the chances for the end system to re-assemble will be ~1/N, where N is number of end systems. > Fragmented packets arrived *earlier* than non-fragmented, which caused > surprises. "Arrive earlier" is sort of the opposite thing from "drop". In some cases they arrive eariler and to the wrong host. -- SY, Jen Linkova aka Furry From nobody Thu Mar 22 09:58:15 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF68126D3F for ; Thu, 22 Mar 2018 09:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPe3QCw4uKOU for ; Thu, 22 Mar 2018 09:58:11 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 8CBFF120726 for ; Thu, 22 Mar 2018 09:58:11 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id h14so9935521qkj.11 for ; Thu, 22 Mar 2018 09:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8g439tRAyXfyqpXX6IJ3GwjOKJhAhhJjIBbFRHTwB+k=; b=VjTe4kubbSmVBuOoEzLY/nD9SM7/fsgj/JNSfBltNp5ujuzqiJijzj6mvcuHBKMuB5 vTyz32mn4J7WgvpA/0iuMFmYx6Eee+eLrNHuFKVPIwSxJTVfexZSm/ALlOZrtUvefC3/ IolaMTcjukfdIexh6EQ2KvYU6E3o5uDDuqOfRK9FjiV3vMUA8RpALINKTV2ltus1VavY iptXHyI67eIyJCT2GhpW/FG1eBGW5bA49ROS17dHMEP0pEV8Jwfk0GrKkfw+5xKWBXkk gxLbR7K7sYV/wTL7bPJVsTe2vPiTeS1dkorh4dfFKCWULY534b1BUp+Njs6oTBxQCdNH jFpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8g439tRAyXfyqpXX6IJ3GwjOKJhAhhJjIBbFRHTwB+k=; b=cjulja+QB47Sw9YJMuTKvZtyMJ8oshDKBorzKY9nx+/ITtUPl4WJ2/t980m1BFOOup 9YHzjglWx66vo01C8MUV1Vb4eZPYv3SYvYwnC5GmZvusZNf4tH2M49LjM91iahVF4Guz Ci/Az0mkPbE9Oafc6htpVWij6ILQbKCyMAINOcyKPiQqOW2SbEhK9UIpWFq2/hyCf32K bEaHflA53bYsMKglUgeThdP+kzKV+b4AiAxuo+w7lh/8E0FcWs6a2Wl9tbYIE2jwPyNY 8mHWXSeG58MAPHKkseSfMzGVt0CX/Mq+C2o+wxCrni+0VXjMvOf9snFLmEsObPMo3cQh bJDg== X-Gm-Message-State: AElRT7F/07n1a4QTv6KtKCBzXCMcOUlehOfIoHPWISDTEIfmvq9RBdBe 1BOBD0tk2Tl6OioB8d3uHt7a/UOVG/kYZ3ccLM92RQ== X-Google-Smtp-Source: AIpwx48SUQuTgsXCipY4R/ea6fFFx1BHJLlaR2+RAkO3ysAN9lBsLmoEkrxykikCr/tC/loRn/uViZK33ussCBeJNEY= X-Received: by 10.55.4.129 with SMTP id 123mr8969907qke.203.1521737890505; Thu, 22 Mar 2018 09:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.26.135 with HTTP; Thu, 22 Mar 2018 09:58:09 -0700 (PDT) In-Reply-To: References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> From: Tom Herbert Date: Thu, 22 Mar 2018 09:58:09 -0700 Message-ID: To: Jen Linkova Cc: Gert Doering , "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 16:58:14 -0000 On Thu, Mar 22, 2018 at 9:45 AM, Jen Linkova wrote: > On Thu, Mar 22, 2018 at 9:20 PM, Gert Doering wrote: >> On Wed, Mar 21, 2018 at 04:10:27PM -0700, Joe Touch wrote: >>> It does when it drops a fragment *because* it lacks a transport header. >> >> Where exactly in this thread was "dropping fragments" mentioned? > > Actually,,, There is one really nasty scenario when hashing is causing > not just reordering but packet loss. > Scenario 1.1: a router R1 is doing ECMP, sends 1st fragment to R2 > while other fragments went to R3. If the paths to the destination > (anycast!) on R2 and R3 do not converge, the first and subsequent > fragments might never meet. > Scenario 1.2: a load-balancer using 5-tupes and a number of end > systems behind it. If the first fragment is forwarded by using L4 > info, then the chances for the end system to re-assemble will be ~1/N, > where N is number of end systems. > >> Fragmented packets arrived *earlier* than non-fragmented, which caused >> surprises. "Arrive earlier" is sort of the opposite thing from "drop". > > In some cases they arrive eariler and to the wrong host. > Jen, That's one of the problems with intermediate nodes that attempt to infer or participate in transport layer semantics. Similar behavior can happen if a device is using flow label for load balancing and the flow label changes mid flow, or if there is a routing change an packets of a flow hit a different load balancer that implements a different hash. In these cases it's not IP protocol that is broken, but technically it's incorrect and convenient assumptions being made within the network that fail under certain circumstances. Tom > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 22 10:21:56 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0429126B6D for ; Thu, 22 Mar 2018 10:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54WcGlTtMJmD for ; Thu, 22 Mar 2018 10:21:52 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792BC126579 for ; Thu, 22 Mar 2018 10:21:52 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id z143-v6so14337958lff.3 for ; Thu, 22 Mar 2018 10:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UvDMKNg2k/uWx3JVdRsdlz7yp+g1oMDNPnyh3lH27FM=; b=XMyLDaXDrDCx/WrDwuDKi8ExRV7HLNaWCt8RkHonzj8ViSYsbVQUe0tiX6dP+TutSA cZq3Z15JdXd/EaTN/IQb4VzhLq+0Yo1P9XAU0msC/lJNFqZZsMdJVdUrYBXS78a3lj+k JkpUZHFNZP0zIUbXfK1DYICI3TmDlrPRwl1aGUMhCdVqqkogxo1hi/X637yRgvrtIQkb LY2bcnUsi9avs/LydvS+kgKFlV1A5YzpjPVmbhjJvQvOVdVjU778fJnw3cA7UsTuFENu wNfhySvCBt53dXbDp5DLDGlTXEIgMNTJygHH/eSPdLjvFzyn+fOkTNvlCG5BdbeONJge 9cOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UvDMKNg2k/uWx3JVdRsdlz7yp+g1oMDNPnyh3lH27FM=; b=r1VWt+WMgk2oCFHRoOPBNx4o+5xAN9aiCusi+YyuBoY4V846u1+kuhyF7Gga25poIP oMVMfjMsRn91c6IQVCtOR1mXqqZVROsXpQReH2eK8O5YnnvO+J/mUQgbwBt9imaTsSmR ZRDLzFGHRQEUuT+bRrk+tl0hdgopUHnf2azh19TTjPNpw/nH9+p/KOPjUzV5RjOTbWPU 9txuJkBOFPO22fRa+k+LyInXQ+EHtwD832+h0iAp2+sGYTu++ztz1+5Jrd2N2FRYi0Kj jM7QHsVotY0C1p+Z35O0i7iuiFuqs7vZxv3OhljYw+v+rsoeZJHHydq1rKQfg07GHsUp rtUQ== X-Gm-Message-State: AElRT7GwKfSE6q/JfdugReVqWpIc9xRVGxIYAS1+H5KUrVHQS0nK6FFX cn9Lmr53TQdWrdUFMB3f0Lt9HPLCN+1CkI8HxwU= X-Google-Smtp-Source: AG47ELuNp38/Lz/pU1eW+FrlBm3X9WsZasJcCfRMM/84oXsCSmG1LESCaOY9nBWT95MyT+adlIj49yznC+352knz4ZA= X-Received: by 2002:a19:2145:: with SMTP id h66-v6mr16535447lfh.63.1521739310603; Thu, 22 Mar 2018 10:21:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 10:21:29 -0700 (PDT) In-Reply-To: References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> From: Jen Linkova Date: Fri, 23 Mar 2018 04:21:29 +1100 Message-ID: To: Tom Herbert Cc: Gert Doering , "v6ops@ietf.org WG" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 17:21:56 -0000 On Fri, Mar 23, 2018 at 3:58 AM, Tom Herbert wrote: > That's one of the problems with intermediate nodes that attempt to > infer or participate in transport layer semantics. I agree it's most unfortunate that almost every intermediate network device is interested in transport layer semantics of transit packets. However I'm not sure it can be changed. Obviously the situations when such behavior is causing the packets being dropped need to be fixed, and I totally agree that it's not end points but intermediate devices fault. On the other hand it's unrealistic to expect that any modern network of decent size would be able to operate w/o taking transport layer into account (well, there was an awesome idea of deprecating L4 ports and using IPv6 addresses instead but...;))) So from operational perspective we might need to think about how to limit the damage. As an example, network operators might want to look into how ECMP and L2 balancing work in their networks and maybe talk to vendors about adding special treatment for EHs - as well as reconsidering filtering policies. The expectations need to be set and documented. I mean, it's reasonable to expect that an ISP might use L4 for balancing and/or applying QoS policies (which in MPLS TE networks, for example, might mean 'your RTT will vary'). Filtering fragments to/from your DNS servers? Not such a brilliant idea.. >Similar behavior > can happen if a device is using flow label for load balancing and the > flow label changes mid flow, or if there is a routing change an > packets of a flow hit a different load balancer that implements a > different hash. In these cases it's not IP protocol that is broken, > but technically it's incorrect and convenient assumptions being made > within the network that fail under certain circumstances. Exactly why it's a good idea to document most common scenarios and discuss who we can ...well, maybe not to solve them completely but make hurt less. -- SY, Jen Linkova aka Furry From nobody Thu Mar 22 17:26:22 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55EA1270AE for ; Thu, 22 Mar 2018 17:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FUsMydxKkV1 for ; Thu, 22 Mar 2018 17:26:20 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 3664A127058 for ; Thu, 22 Mar 2018 17:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DCmlhv19xeRseycZKNmvDstW6r6okbIQZ5ZBKq/mbCI=; b=hQF4L1SOe7JQdgZBnFTpPnxVKk 9K+VWGf0lu/j8DGM6V37YhO5bjngmv4HWfokTobRw5ONBilYmSeDmfx/IrGVr33URYacRliySPFs1 Fc8ByURVAOCzNlnS/fpczgun3d3VpVpq3dJ8Y6R/lPZEPqDaMgi8UXOEHG5R6dwFiZi+ixtCFbej3 ZHMHMVAT6cZl4NfuCGeJDEOVt2dW+n5rORAF5LrfIk5CXOtCPx9Nv7+D6YmGlXQW7kfujCHLHCK14 Mhi4vX71JMXDfvwlsYm/2Tmp8OTji2JONylgACG+Rg58Wjtd9ycanrkTdlhQriRo0Dbu806D/EDBj mWrPwMxQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58895 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ezAX1-001lLd-Tw; Thu, 22 Mar 2018 20:26:08 -0400 To: Jen Linkova , Gert Doering Cc: "v6ops@ietf.org WG" References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> From: Joe Touch Message-ID: <85e26785-149c-aba7-d035-d49d2957405e@strayalpha.com> Date: Thu, 22 Mar 2018 17:26:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 00:26:22 -0000 On 3/22/2018 9:45 AM, Jen Linkova wrote: > Actually,,, There is one really nasty scenario when hashing is causing > not just reordering but packet loss. > Scenario 1.1: a router R1 is doing ECMP, sends 1st fragment to R2 > while other fragments went to R3. If the paths to the destination > (anycast!) on R2 and R3 do not converge, (to finish that sentence correctly) then your routing is broken anyway and all bets are off. Don't blame either fragmentation or ECMP for that problem. ... > Scenario 1.2: a load-balancer using 5-tupes and a number of end > systems behind it. If the first fragment is forwarded by using L4 > info, (again, to finish the sentence correctly) then the load balancer should either reassemble the fragments or keep enough state to make sure they fate-share to the same recipient. Otherwise, what you call a "load balancer" is basically doing random forwarding, which is broken routing, and again -- all bets are off. Fragmentation isn't the cause of these problems; broken routing is. Joe From nobody Thu Mar 22 17:29:04 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECBA1270AE for ; Thu, 22 Mar 2018 17:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2uJYL9gkpid for ; Thu, 22 Mar 2018 17:29:01 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 BF31F127058 for ; Thu, 22 Mar 2018 17:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lSnyukp27J8XShgmhAIm6V0fBaH7Ch6AXs15nEeVMrE=; b=q6DDzUEcHHW/8RGkikYc53HDfz ho4lRNC2pzQkvNqLC/LLX2X2fciLTt4jbFdc80UB4G7imauhsEWr2jygEbqGFDnzvNGI/jM6s0t76 0i0/EWOKjNrpLYkyU+L7ouUkBBguEo68rqMLwJoh3tnmekPgO5rhsOIxh6GpvyO8oMLvK6C60rsao zJjD4XJHKwcQJdbdgJENA8KWa6Vhe3xDt86ilOunSNTz6jPchy9o9Wyj8vFvbXQuIpdia6fwOi4e7 LODi7E5dKOnxP4GNX1JCyU8e2/fR7soCcHUV3PPUWQ48w/pE1dmwlc3CKZTC8yZsCPoUlq+K8W2KN 6PCgiiog==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58914 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ezAZe-001ogj-9V; Thu, 22 Mar 2018 20:28:50 -0400 To: Jen Linkova , Tom Herbert Cc: "v6ops@ietf.org WG" References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> From: Joe Touch Message-ID: <133d0300-7d11-133d-dec1-07aa7546f3df@strayalpha.com> Date: Thu, 22 Mar 2018 17:28:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 00:29:03 -0000 On 3/22/2018 10:21 AM, Jen Linkova wrote: > The expectations need to be set and documented. On that, I agree. The expectation is that a device that inspects L4 will preserve L4 semantics - which means that if it starts forwarding on L4, it had better keep doing so for the rest of the fragments for that L4. Just saying "that's what everyone does" isn't an answer. Everyone (in general) disobeys speed limits; that doesn't mean we stop putting them up or stop enforcing them. Joe From nobody Thu Mar 22 17:36:03 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AC5127136 for ; Thu, 22 Mar 2018 17:36:02 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN1MugBQD_fZ for ; Thu, 22 Mar 2018 17:36:01 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1EA1270AE for ; Thu, 22 Mar 2018 17:36:01 -0700 (PDT) Received: from [192.168.10.117] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D2EDD2D5064; Fri, 23 Mar 2018 00:36:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15D100) In-Reply-To: <133d0300-7d11-133d-dec1-07aa7546f3df@strayalpha.com> Date: Fri, 23 Mar 2018 01:35:58 +0100 Cc: Jen Linkova , Tom Herbert , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <6265ABC4-73D9-4A6B-BA52-71F26483AAE7@employees.org> References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> <133d0300-7d11-133d-dec1-07aa7546f3df@strayalpha.com> To: Joe Touch Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 00:36:03 -0000 Joe, It seems you are in denial about the consequences for IPv4 with ever increas= ing address sharing.=20 Ole > On 23 Mar 2018, at 01:28, Joe Touch wrote: >=20 >=20 >=20 >> On 3/22/2018 10:21 AM, Jen Linkova wrote: >> The expectations need to be set and documented. >=20 > On that, I agree. >=20 > The expectation is that a device that inspects L4 will preserve L4 > semantics - which means that if it starts forwarding on L4, it had > better keep doing so for the rest of the fragments for that L4. >=20 > Just saying "that's what everyone does" isn't an answer. Everyone (in > general) disobeys speed limits; that doesn't mean we stop putting them > up or stop enforcing them. >=20 > Joe >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Mar 22 17:50:44 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B6A12711B for ; Thu, 22 Mar 2018 17:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpbXx2gfxlPh for ; Thu, 22 Mar 2018 17:50:38 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 7B6F1127058 for ; Thu, 22 Mar 2018 17:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=X/t0zkvAPtXl6AnlkUIClbQHqyOVEH2siKKIgO+LrNs=; b=S5y1ucSYWQx/m7Y45wfHPx0FA zCuStET3F2Cw4tuDFVNjFdAbauYbAQx0vhTdLDkCaCnPZOEZCFle+ehx8x883wtltVQkxG3Anpdrz EJjh0feXxNyIiNvUf7RE6wy4HV13SGTNXCsb4Ast0TwGBKUIrP6bpuw/kWrndKv1gKw7UtLFplswB uCoLTI+i52cHJXdxuy6eJDzs4SWswgs5Z/2Mhfiky3mjYzQYHNwzHbMQrAqfQ70ehEIyN+rBZxDsz zXcHUiBLegznCyN40wekWkmwWjYNZXRHO5qs7PgeSxAIynKNhMt+9NAgcAjPww0Muo+YXXiLW+VyL lwynL8kyg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49935 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ezAuZ-002BgY-Nj; Thu, 22 Mar 2018 20:50:32 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (15D100) In-Reply-To: <6265ABC4-73D9-4A6B-BA52-71F26483AAE7@employees.org> Date: Thu, 22 Mar 2018 17:50:27 -0700 Cc: Jen Linkova , Tom Herbert , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <0519C8D2-BD94-45E5-B26A-CD5B96A8A27B@strayalpha.com> References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> <133d0300-7d11-133d-dec1-07aa7546f3df@strayalpha.com> <6265ABC4-73D9-4A6B-BA52-71F26483AAE7@employees.org> To: Ole Troan X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 00:50:42 -0000 > On Mar 22, 2018, at 5:35 PM, Ole Troan wrote: >=20 > Joe, >=20 > It seems you are in denial about the consequences for IPv4 with ever incre= asing address sharing.=20 You are willing to pay money to be lied to. I am not Joe >=20 > Ole >=20 >> On 23 Mar 2018, at 01:28, Joe Touch wrote: >>=20 >>=20 >>=20 >>> On 3/22/2018 10:21 AM, Jen Linkova wrote: >>> The expectations need to be set and documented. >>=20 >> On that, I agree. >>=20 >> The expectation is that a device that inspects L4 will preserve L4 >> semantics - which means that if it starts forwarding on L4, it had >> better keep doing so for the rest of the fragments for that L4. >>=20 >> Just saying "that's what everyone does" isn't an answer. Everyone (in >> general) disobeys speed limits; that doesn't mean we stop putting them >> up or stop enforcing them. >>=20 >> Joe >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Mar 23 03:21:10 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1F612D864 for ; Fri, 23 Mar 2018 03:21:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y_XU4T3xUgg for ; Fri, 23 Mar 2018 03:21:07 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC16B126BF0 for ; Fri, 23 Mar 2018 03:21:07 -0700 (PDT) Received: from h.hanazo.no (unknown [173.38.220.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 8E6172D4FF7; Fri, 23 Mar 2018 10:21:07 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8EC9420261DB13; Fri, 23 Mar 2018 10:20:49 +0000 (GMT) From: Ole Troan Message-Id: <53B81EAD-6AB9-4A2C-BEBC-2B80A10533BF@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_ED5446F6-265D-4179-A78D-9776975A8783"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 23 Mar 2018 10:20:48 +0000 In-Reply-To: <0519C8D2-BD94-45E5-B26A-CD5B96A8A27B@strayalpha.com> Cc: Jen Linkova , Tom Herbert , "v6ops@ietf.org WG" To: Joe Touch References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> <133d0300-7d11-133d-dec1-07aa7546f3df@strayalpha.com> <6265ABC4-73D9-4A6B-BA52-71F26483AAE7@employees.org> <0519C8D2-BD94-45E5-B26A-CD5B96A8A27B@strayalpha.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 10:21:10 -0000 --Apple-Mail=_ED5446F6-265D-4179-A78D-9776975A8783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joe, >> It seems you are in denial about the consequences for IPv4 with ever = increasing address sharing. >=20 > You are willing to pay money to be lied to. I am not I am the one taking your money and implementing it, and trying not to = lie to you in the process. I have also written some of the specs in this space. I can guarantee you = that A+P has a higher fragment drop probability than an 1:1 IPv4 = Internet. Given that we do not have that luxury, the resulting decaying = IPv4 Internet is what we have to live with. We've told you to move to = IPv6 for quite a while now. And if you are upset about fragments having an increasing drop = probability, then please don't try to put anything but 6 or 17 in that = protocol field. The relevant path of the IPv4 forwarding path I've implemented is here: https://git.fd.io/vpp/tree/src/vnet/map/ip4_map.c#n195 Ole --Apple-Mail=_ED5446F6-265D-4179-A78D-9776975A8783 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlq01QAACgkQvtpYqJhC 33b0Ow//Q8yTNQ3Xa4Mb3Yk9G5h2ytiwyeKya43VyggSKdbA4Vhgks5OvrfFDi2F 7THrI3g12S59Bri+abLBTkabCYuQLxBACCPyIhRAdGOPjtKlW6Y5m6yWaLJPtqJ2 Ga5svT8qXoMRxxl8nHBe6Xu9um0iAfeDpeCAGW6J9Ow2vZhatqA/jGNgqpUgCh0Q vsIjruTUWTBbvLv+C7YfUMKjfmjidM4T4mDVzSTN0ThMK98SZAiQLSvg7DXIcl6G OKZRD+cdMjhVEiaosZlq25z/kQ5Ztxorup+CX3Dq46DPjZoDD9D+VYcwfsn/leDu ETl/SZ+/AZ5AblVscEZGFmzSN5Ia+q4e+6Ra/0lkFbbngJ+8bB5ZUjed3Whlxd/y 82CJRq9SN0FeKaimY1bUQJxlza3Q9tEBVTIfYYu/GppHXl/UaNlwNbctz4ivvShJ EP7rkb9V57RLPLhJXSZ3RpL594pKPJXWEbmpKNDOhPP7B+AhbwwlYcsg2Z+lXR/Y rx3GoyDf1Hnbr/IGUkkyrpx3THJUwRoU5WIwtKRn/dbZR/7Pib4YdVKf8Zd7N8vK i2hN6KgXGqIwd28RtzqW8b7jUWPd77Lr/t4GLt8cRLdzGoj0BKZ55aG45MF4V+0R Fn+TvGNrkOGX1PLVlnSwCeWvB3ikfWfZXgQb817dJ7cccQdXxDg= =KTOd -----END PGP SIGNATURE----- --Apple-Mail=_ED5446F6-265D-4179-A78D-9776975A8783-- From nobody Fri Mar 23 07:05:11 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C1D1243F6 for ; Fri, 23 Mar 2018 07:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpuqF_0aWe6F for ; Fri, 23 Mar 2018 07:05:07 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 8C41B1200F1 for ; Fri, 23 Mar 2018 07:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TG3PTAN86F1ni5PaNcO3dkiTOtIv8/9I2mtyt3BY4eU=; b=eqphu1+Flzw/3Ay+sU1OD85gm MtXkQScheKvsK4NHrtZQsi7a5oj181XpthvIc1yquxRyPS2YWirr2Ya4wmwL8j0SElKhVb9pAzs7Z TXy02xcm0XOmqa2JzZTvD7xohXa88+KztsZ6iTxnXxFAo9HpUJpofenSlP3pTeBeaEzJTTmrUKstX tVeselqp4+R5L0R/BJioFKo9HF5b3DQPFbLx+y8HA5kEreXWf3+zFkYSX9/uWuKdelXWBI9nra37N HBDtD2Wx92QUdcjw5n/0ME5RIUdCdt41PNc0y/5NZ+QEE4NrsPeNvKcBjyJJEzsjgPmk91aVVQNhr 2uCVaVbmg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:60958 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ezNJB-003hlX-7k; Fri, 23 Mar 2018 10:04:46 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: <53B81EAD-6AB9-4A2C-BEBC-2B80A10533BF@employees.org> Date: Fri, 23 Mar 2018 07:04:32 -0700 Cc: Jen Linkova , Tom Herbert , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> <133d0300-7d11-133d-dec1-07aa7546f3df@strayalpha.com> <6265ABC4-73D9-4A6B-BA52-71F26483AAE7@employees.org> <0519C8D2-BD94-45E5-B26A-CD5B96A8A27B@strayalpha.com> <53B81EAD-6AB9-4A2C-BEBC-2B80A10533BF@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] IPv6 fragmentation experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 14:05:09 -0000 > On Mar 23, 2018, at 3:20 AM, Ole Troan wrote: >=20 > Joe, >=20 >>> It seems you are in denial about the consequences for IPv4 with ever = increasing address sharing. >>=20 >> You are willing to pay money to be lied to. I am not >=20 > I am the one taking your money and implementing it, and trying not to = lie to you in the process. Here=E2=80=99s what you need to do to stop lying that you=E2=80=99re = selling me an IP router (or A+P device): 1) if you look at L4, then you need to either reassemble the packet or = cache the front fragment and use it as context for later fragment = forwarding. 2) if you can=E2=80=99t keep up with #1, then you need to ignore L4 = context for that packet and forward it using only L3 3) remember that ECMP still requires a valid P (path); if a =E2=80=9Cpath=E2= =80=9D doesn=E2=80=99t go to a destination for a fragment, it=E2=80=99s = not a path and should not be in your forwarding table I=E2=80=99m doing what I can to help reduce the amount of #2 traffic = here in the IETF (UDP options) and certainly everyone should be doing = some sort of PLPMTUD too. Sure, we all should also try to move to IPv6. But that doesn=E2=80=99t mean those who sell IPv4 devices get to lie. We all need to be aware of implementation *errors* and fix them. Joe= From nobody Fri Mar 30 16:35:37 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 805851272E1; Fri, 30 Mar 2018 16:35:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152245293147.19724.9713690927195889269@ietfa.amsl.com> Date: Fri, 30 Mar 2018 16:35:31 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 23:35: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 WG of the IETF. Title : Using Conditional Router Advertisements for Enterprise Multihoming Authors : Jen Linkova Massimiliano Stucchi Filename : draft-ietf-v6ops-conditional-ras-03.txt Pages : 18 Date : 2018-03-30 Abstract: This document discusses most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. [I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue and using Router Advertisements to influence the host source address selection. While the above-mentioned document focuses on solving the general problem and on covering various complex use cases, this document describes how the solution proposed in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited number of common use cases. In particular, the focus is on scenarios where an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in [RFC8028]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-03 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-conditional-ras-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-03 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 Fri Mar 30 16:38:57 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFBD127369 for ; Fri, 30 Mar 2018 16:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOyvg3J2cIWv for ; Fri, 30 Mar 2018 16:38:53 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 7EF491272E1 for ; Fri, 30 Mar 2018 16:38:53 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id u3-v6so14138346lff.5 for ; Fri, 30 Mar 2018 16:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=9jBqiVSfXaWoSxeehtyMgK5e9lPWeJEqLsL3rSTv8Z8=; b=N10HUkBolRDYcMK2T+zkgst9SpGsCMhaW70V7pl9OiBscrK23DdF1DT5JMQs8WFSiw ZDN8qgXRsfSz1z4rtK2TqJIOdLMWZqGcl3HI+Du6AN8Wh6Uts/xg26VyO8lHoCZHacX8 rXrNzGjuzshPEto6xFE3LIFFZLa6HeMNbE0+3vmHEJPNrDaimQZ1/geah4zUd8Vv0T7P It3aPdnki5Z0/IFOYr2JVLoNvsTRZgkCeKPofTVfYsRCMT9fajf9g67MteXF7XqZD3+V i0D+gK+zj9dSGlmp20STXqL6h3gSPbydQXHwYUvnRJI8XaROHbZxdYNcNQaxAswR/gEJ 6/hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=9jBqiVSfXaWoSxeehtyMgK5e9lPWeJEqLsL3rSTv8Z8=; b=MdIUtk3ooZn2uk3j7tBVRNzWTDN0VhrINwGsbKfcxnvDXgFNagW6JW4d5b+zCGown6 cdKhXtdrBV8pMYPOG97U8upuZXVb5v8N93X2efwJJCer9r53SZrFmuSq7DYOmC6CXvMM wAIGF1xis6uHTJv4+wfCi+fQhMd+0LyHHp4GCRGFOPdBhKZb6CcrwY6aFKkPTQmKGR3u 8/A1IKfbbLT4EHeY3xwoZftEfkX/CxahLerDWq5gVCBZ1k+4Xtzp7lvJXN/ORDIl95T8 hAM6FLrild5SkqsUHVNPzOQy8x6GTIW0//EDWsTwSgGviv4ytm0aEiyuR56rf51+NX66 2zrA== X-Gm-Message-State: ALQs6tB1bH7B37C+818mUCCQIUe/N0tmvKPPEt8Z6N0/FR1H70jqBmKk TAbiTat1q2e8ZYaQLJGHMcC1P3q8Wm/Ew0oHj+k= X-Google-Smtp-Source: AIpwx4/6VFhAy+frdcxMOY9qGUswIs6fLGVu4PCf7nCTsl+J17j9fbADjo9mA4Z8YCwPZ+c4PEhplKZVO5JSDAtVL2E= X-Received: by 10.46.153.199 with SMTP id l7mr450166ljj.21.1522453131690; Fri, 30 Mar 2018 16:38:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:c742:0:0:0:0:0 with HTTP; Fri, 30 Mar 2018 16:38:31 -0700 (PDT) In-Reply-To: <9FFC570F-57EE-47C7-852B-00D5A2C97E2E@gmail.com> References: <9FFC570F-57EE-47C7-852B-00D5A2C97E2E@gmail.com> From: Jen Linkova Date: Sat, 31 Mar 2018 10:38:31 +1100 Message-ID: To: Fred Baker , V6 Ops List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-conditional-ras WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2018 23:38:56 -0000 The updated version of the draft (https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-03) has been submitted. The main changes: - adding text clarifying that hosts are not expected to support Rule 5.5; - adding a section discussing connections interruptions during the uplink state change (as per Lorenzo's suggestion). On Tue, Mar 20, 2018 at 5:00 PM, Fred Baker wrot= e: > As discussed at IETF 101, we are opening a Working Group Last Call on dra= ft-ietf-v6ops-conditional-ras. Please read the draft now. The chairs need t= o understand both whether you think this is valuable in an operational envi= ronment such as yours, and if there are issues in the draft, what those mig= ht be. This will close April 8. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 SY, Jen Linkova aka Furry From nobody Sat Mar 31 12:34:52 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128C71270AE; Sat, 31 Mar 2018 12:34:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAQ_R9YfYktW; Sat, 31 Mar 2018 12:34:49 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 76DB51270AC; Sat, 31 Mar 2018 12:34:49 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id v26so6977428pge.11; Sat, 31 Mar 2018 12:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=z4jdg9MG8v4M4Kq8WItrpVJ1fgwu0neE1flRiG34cBg=; b=WJWIKjD8pCrHveuPnumMMb4MOYcXbenz/3oqZek5uwavHOhGxfYiy0SRdI94hTLvJQ 0j9LECOmy6isptohgTl33ooQQ5G6fCXUWZgA/Fijt4G8knalZSsgci+fFGv6N+qMnOHO U4UYO0/mw+gPxFmdX4XGVIUivr3WxTYVK+o13FVVlkUIReYpT55z39LQtWPDYEhPL5M4 20q12fwDDZHxZ/+FhS8Z0s3leZGYtvV9Zh5wayjC5NHlN3+bhW/eSPXZsCj3iqw5LQzc 0LRyRiituZp8AU3McYntRGgeEwk9i9knEJM5ZzpnzRCLqiagmvJxur8l+9Eaa57J9/Q0 iTJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=z4jdg9MG8v4M4Kq8WItrpVJ1fgwu0neE1flRiG34cBg=; b=sO0f+ZfwJDh+ttUb04FHx0eL5l/qhl98q05fqBbvclbJreZsQTh4DAQs1hryyxh/vx SXVrGL8fllB7Q8m4SOM9/ei4waX4OjdIE/hkHXaii1Qo7QI3hp7bsyCX7kaoJ+l7oosG lQ7DBgcdx/jQ3NfJd80zBlKgCV5UeA/Z2fqTyXSQXM+MNrQuBUG8m+/8NVTohHS/Z7Dd +d+Ca7WDMk5duHZFatNRPMBIvwa15H/2b9nWsjsNtCdEn8SmoaAtub77H4QSII9vLXCs YnzF0YEQhjK5/ExDrjdhWMJj17dMsw6+zehBGGtcG+nnuxZXHRcqkORZVavLN84xgjUW 7vNA== X-Gm-Message-State: AElRT7Ffn+MmStW6+coLKfvIv5F3asLpa70IkdeBUOOQP+9EMT5aWYEW MwO9IEGufQtGYhMZJxbY7UD6xA== X-Google-Smtp-Source: AIpwx4/VBuy4QkBcUmkRkGDCCFmjUHhJAO/bzF3pJXhuGlFh0RUmE7l7Pw3nKp+s54O+dHi4E3dIkw== X-Received: by 2002:a17:902:8c93:: with SMTP id t19-v6mr3966517plo.301.1522524888838; Sat, 31 Mar 2018 12:34:48 -0700 (PDT) Received: from [192.168.1.7] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id z14sm18363401pgv.26.2018.03.31.12.34.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Mar 2018 12:34:48 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.b.0.180311 Date: Sat, 31 Mar 2018 12:34:47 -0700 From: Jeff Tantsura To: CC: , rtgwg-chairs Message-ID: <794587A2-46DF-4F2F-86B5-56083D0864A5@gmail.com> Thread-Topic: RTGWG last call draft-ietf-rtgwg-enterprise-pa-multihoming-03 References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3605344488_1737852222" Archived-At: Subject: [v6ops] RTGWG last call draft-ietf-rtgwg-enterprise-pa-multihoming-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2018 19:34:51 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3605344488_1737852222 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi, In preparation for RTGWG last call for draft-ietf-rtgwg-enterprise-pa-multihoming-03, RTGWG chairs would like to ask you to review and provide comments (if any) on the draft. Many thanks! Cheers, Jeff & Chris --B_3605344488_1737852222 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi,

 

In preparation for RTGWG last cal= l for draft-ietf-rtgwg-enterprise-pa-multihoming-03, RTGWG chairs would like= to ask you to review and provide comments (if any) on the draft.

Many thanks!

 

<= span style=3D'mso-bookmark:_MailOriginalBody'>Cheers,

Jeff & Chris

--B_3605344488_1737852222--