From nobody Tue Sep 1 01:42:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11EA1B8B2B for ; Tue, 1 Sep 2015 01:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYTFIs2gHXkB for ; Tue, 1 Sep 2015 01:42:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 026851B8B28 for ; Tue, 1 Sep 2015 01:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5694; q=dns/txt; s=iport; t=1441096937; x=1442306537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vdbk3nLSzx/E0piWpjw6Ei6y+6drLRXO6AaxqCpr2QQ=; b=lkuD+a4BsXLt950Rl2AURhkhcEbXICB2WovltREYMUAhde9hRAgQTUp0 VXNbudMmznrUkvKLjDexQ+UyjNKv35uYu8iSp5DDue/cBAYn5ROP7KCrU g1rSRX6YMP3nGfdnuRZnVEvRJN4EzB6iPWjvuQS2QD8pALwslYd9Gzm6t A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CTAgC9Y+VV/4oNJK1egxtUaQaDHbsFAQmBbQqFewIcgRM4FAEBAQEBAQGBCoQkAQEEAQEBIBE6CxACAQgaAiYCAgIlCxUQAgQBDQWILg2xcJULAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIoVOAYN0gQWEMyUzB4JpgUMFlUEBhQaHboFKlTaDbCaCDxyBVHEBgQVCgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,448,1437436800"; d="scan'208";a="23352296" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 01 Sep 2015 08:42:16 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t818gG3a024988 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Sep 2015 08:42:17 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Sep 2015 03:42:16 -0500 Received: from xhc-aln-x04.cisco.com (173.36.12.78) by xch-rcd-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 1 Sep 2015 03:42:16 -0500 Received: from xmb-aln-x02.cisco.com ([169.254.5.3]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0248.002; Tue, 1 Sep 2015 03:42:15 -0500 From: "Eric Vyncke (evyncke)" To: Fernando Gont , IPv6 Operations Thread-Topic: [v6ops] Why operators filter IPv6 packets with extension headers? Thread-Index: AQHQ5FR+4zgN0QwpRkC1p2R36M7UAp4n0NcA Date: Tue, 1 Sep 2015 08:42:14 +0000 Message-ID: References: <55E4FCB6.8040407@gont.com.ar> In-Reply-To: <55E4FCB6.8040407@gont.com.ar> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.36.7.11] Content-Type: text/plain; charset="utf-8" Content-ID: <289DED9938736B4BB0A86375BAE847D4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org" , "ipv6-ops@lists.cluenet.de" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] Why operators filter IPv6 packets with extension headers? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 08:42:21 -0000 RmVybmFuZG8gZXQgYWwuLA0KDQpBIGNvdXBsZSBvZiBxdWljayBjb21tZW50czoNCg0KLSB0aGlz IHJlbWluZHMgbWUgb2YgdGF5bG9yLXY2b3BzLWZyYWdkcm9wICh3aGljaCB5b3UgY2l0ZSBhdCB0 aGUgZW5kKSwNCmRpZCB5b3UgYXBwcm9hY2ggYW55IG9mIHRoaXMgb2xkIEktRCBhdXRob3JzPw0K DQotIG5vdCBzdXJlIHdoZXRoZXIgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBzaG91bGQgYmUg cmUtc3RhdGVkIGFnYWluIGluDQp0aGlzIGRvY3VtZW50LCBsZXQncyByYXRoZXIgc3BsaXQgdGhl IHNlY3VyaXR5ICYgb3BlcmF0aW9uYWwgaXNzdWVzIGludG8NCnR3byBkb2N1bWVudHMNCg0KLSBp biB0aGUgaW50cm9kdWN0aW9uLCAnd2lkZXNwcmVhZCBpbXBsZW1lbnRhdGlvbiBsaW1pdGF0aW9u cycgaXMgcHJvYmFibHkNCnRvbyBzdHJvbmcgKGFuZCBJIGFncmVlIHRoYXQgbXkgZW1wbG95ZXIg cHJvZHVjdHMgY291bGQgZG8gYmV0dGVyKQ0KDQotIGluIHRoZSBpbnRyb2R1Y3Rpb24sICJpbnRl bnRpb25hbGx5IGRyb3BwZWQiID8gSSBhbSBhZnJhaWQgdGhhdCBzb21lDQpkcm9wIGFyZSBub3Qg aW50ZW50aW9uYWwNCg0KLSBJIHdvdWxkIHNob3J0ZW4gYSBsb3QgdGhlIHNlY3Rpb24gMyAoc2Vj dXJpdHkgaW1wbGljYXRpb25zKSBhbmQgc2ltcGx5DQpwdXQgYSBsb3Qgb2YgcmVmZXJlbmNlcyB0 byBleGlzdGluZyBnb29kIGRvY3VtZW50cyBvZiB5b3VycyBhbmQgb3RoZXJzDQoNCi0gSSBsaWtl IHNlY3Rpb24gNCAob3BlcmF0aW9uYWwgaW1wbGljYXRpb25zKSBidXQgaXQgZG9lcyBub3QgbWF0 Y2ggdGhlDQp0aXRsZSwgaXQgaXMgbW9yZSBhYm91dCB3aHkgdHJhbnNpdCBvcGVyYXRvcnMgaGF2 ZSB0byBsb29rIGF0IGxheWVyLTQNCg0KLSBzZWN0aW9uIDQgYXBwcm9hY2hlcyB0aGUgZ29hbCBk ZXNjcmliZWQgaW4gdGhlIGFic3RyYWN0IGJ1dCBhY3R1YWxseQ0Kb25seSBwcm92aWRlIGNsdWVz IHdoeSBvcGVyYXRvcnMgaW50ZW50aW9uYWxseSAob3Igbm9uIGludGVudGlvbmFsbHkpDQpkcm9w cyBwYWNrZXRzIHdpdGggRUguIEZvciBleGFtcGxlLCBiZWluZyB1bmFibGUgdG8gZG8gRUNNUCBp cyBvZiBjb3Vyc2UNCmFuIG9wZXJhdGlvbmFsIGltcGFjdCBidXQgd2h5IHdvdWxkIGl0IGJlIHRo ZSBjYXVzZSBvZiBFSCBkcm9wPw0KDQotIHNlY3Rpb24gNC4xIChpQUNMKSwgYmV5b25kIHRoZSBw ZXJtaXQvZGVueSwgc29tZSBvcGVyYXRvcnMgYWxzbyByYXRlDQpsaW1pdCBzb21lIHRyYWZmaWMg c3VjaCBwaW5ncw0KDQotIHNlY3Rpb24gNC4xLCBwZXJoYXBzIHdvcnRoIG1lbnRpb25pbmcgdGhh dCBpbmZyYXN0cnVjdHVyZSBBQ0wgYXJlIG1vcmUNCmluIHRoZSB3aGl0ZSBsaXN0IGFwcHJvYWNo LCBpLmUuLCB3aGF0IGlzIG5vdCBCR1AvSUNNUCAoaW4geW91ciBleGFtcGxlKQ0KdG8gc29tZSBw cmVmaXhlcyBpcyBkcm9wcGVkLCBzbywgaWYgc29tZW9uZSB1c2VzIEVIIHRvIG9ic2N1cmUgdGhl DQp0cmFmZmljLCB0aGlzIEVIIHRyYWZmaWMgbWF0Y2hpbmcgdGhlIGRlc3RpbmF0aW9uIHByZWZp eCBpcyBkcm9wcGVkIGFueXdheQ0KYnkgdGhlIEFDTCAoc28gaUFDTCB3b3JrcykgYnV0IHRyYWZm aWMgZGVzdGluZWQgdG8gb3RoZXIgZGVzdGluYXRpb24gaXMNCm5vdCBpbXBhY3RlZC4gT3IgZGlk IEkgZ290IHNvbWV0aGluZyB3cm9uZz8NCg0KLSBzZWN0aW9uIDQuMiAocm91dGUgcHJvY2Vzc29y IHByb3RlY3Rpb24pIGlzIGEgbGl0dGxlIHVuY2xlYXINCg0KLSB0aGUgcHJvY2Vzc2luZyBvZiBI Ykggd291bGQga2lsbCB0aGUgSW50ZXJuZXQgb2YgY291cnNlIChhdCBsZWFzdCB3aXRoDQptb3N0 IHJvdXRlcnMpLCBzaG91bGQgSGJIIGJlIHNlcGFyYXRlbHkgY2FsbGVkPw0KDQotIHNlY3Rpb24g NC4zIChERG9TIG1pdGlnYXRpb24pLCBJIGFtIHVuc3VyZSBhYm91dCBGbG93U1BlYyBidXQgY2Fu IGl0DQphbHNvIHNwZWNpZnkgJ2FueSB0cmFmZmljIHdpdGggRUgnID8gVGhpcyB3b3VsZCBkbyB0 aGUgdHJpY2sgcHJvYmFibHkgZm9yDQpkcm9wcGluZyBvciBkaXZlcnRpbmcgdGhlIERvUyBwYWNr ZXRzPw0KDQotIG1pc3NpbmcgaXNzdWUgaXMgbGFjayBvZiBncmFudWxhciBFSCBjb250cm9sIGJ5 IHNvbWUgcm91dGVycywgZm9yDQpleGFtcGxlIGlmIGFuIG9wZXJhdG9yIHdhbnRzIHRvIGJsb2Nr IGl0cyBzdWJzY3JpYmVycyBSSC0wIGJ1dCBjYW4gb25seQ0KZHJvcCBSSCAoYmVjYXVzZSBSSCB0 eXBlIGNhbm5vdCBiZSBzcGVjaWZpZWQpLCB0aGVuIGFsbCBSSCBhcmUgZHJvcHBlZA0KaW5jbHVk aW5nIE1JUHY2DQoNCi0gc2VjdGlvbiA1IChwb3RlbnRpYWwgYXR0YWNrIHZlY3RvcikgYXBwZWFy cyB0byBiZSBmb2N1cyBvbiBmcmFnbWVudCBkcm9wDQpieSB0aGUgcHVibGljIEludGVybmV0LiBX aGlsZSBpdCBjYW4gcHJvYmFibHkgd29yaywgdGhlIGlzc3VlcyBhcmUNCnR3b2ZvbGQ6IA0KMSkg YmFkIGhvc3QgaW1wbGVtZW50YXRpb25zIG5vdCBkb2luZyBlbm91Z2ggdGVzdHMgYmVmb3JlIGFj Y2VwdGluZyBhIElDTVANCnBhY2tldC10b28tYmlnIA0KMikgcHVibGljIEludGVybmV0IGRyb3Bw aW5nIHZhbGlkIGZyYWdtZW50cyBpbiB0cmFuc2l0DQpJbiBib3RoIGNhc2VzLCB3ZSAodGhlIGlu ZHVzdHJ5LCB2ZW5kb3JzICsgb3BlcmF0b3JzKSBuZWVkIHRvIGZpeCB0aG9zZQ0KdHdvIGlzc3Vl cy4NCg0KDQpNYXkgSSBTVFJPTkdMWSBzdWdnZXN0IHRvIHJlbW92ZSBhbGwgc2VjdXJpdHkgaXNz dWVzIChvdGhlciBkb2NzIGFyZQ0KZGVzY3JpYmluZyB0aGlzKSBhbmQgZm9jdXMgb25seSBvbiB0 aGUgb3BlcmF0aW9uYWwgaXNzdWVzIChlc3AgaW4gVjZPUFMpID8NCkFuZCBza2lwIGFueSBkaXNj dXNzaW9uIG9uIHRoZSByYXRpb25hbGUgd2h5IHBhY2tldHMgd2l0aCBFSCBhcmUgZHJvcHBlZD8N Cg0KDQpIb3BlIHRoaXMgaGVscHMgdG8gcmVmaW5lIGEgcG90ZW50aWFsbHkgdXNlZnVsIEktRC4N Cg0KDQoNCi3DqXJpYw0KDQoNCk9uIDEvMDkvMTUgMDM6MTcsICJ2Nm9wcyBvbiBiZWhhbGYgb2Yg RmVybmFuZG8gR29udCINCjx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBmZXJu YW5kb0Bnb250LmNvbS5hcj4gd3JvdGU6DQoNCj5Gb2xrcywNCj4NCj5UaGUgdG9waWMgb2Ygb3Bl cmF0b3JzIGRyb3BwaW5nIElQdjYgcGFja2V0cyBjb250YWluaW5nIGV4dGVuc2lvbg0KPmhlYWRl cnMgaGFzIGJlZW4gcmFpc2VkIHF1aXRlIGEgZmV3IHRpbWVzIG9uIHRoaXMgbGlzdCBhbmQgZWxz ZXdoZXJlLg0KPg0KPkEgbW9udGggYWdvIG9yIHNvIHdlIHB1Ymxpc2hlZCBhIGRvY3VtZW50IHRy eWluZyB0byBzdW1tYXJpemUgdGhlDQo+cmVhc29ucyBmb3Igd2hpY2ggb3BlcmF0b3JzIGZpbHRl ciBJUHY2IHBhY2tldHMgY29udGFpbmluZyBleHRlbnNpb24NCj5oZWFkZXJzLiBUaGUgZG9jdW1l bnQgaXMgYXZhaWxhYmxlIGF0Og0KPjxodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWdv bnQtdjZvcHMtaXB2Ni1laHMtcGFja2V0LWRyb3BzLTAwLnR4dD4NCj4NCj5XZSdyZSBjdXJyZW50 bHkgd29ya2luZyBvbiBhIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQsIGFuZCB3b3VsZCBsaWtl DQo+dG8gaGVhciBmZWVkYmFjayBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHJlZ2FyZGluZyBvdXIg ZG9jdW1lbnQuIGUuZy4sDQo+DQo+KiBEaWQgd2UgZ2V0IGFueXRoaW5nIHdyb25nPw0KPiogSXMg dGhlcmUgYW55dGhpbmcgbWlzc2luZz8NCj4NCj5PciwgaWYgeW91IGxpa2UgdGhlIGRvY3VtZW50 IGFuZCBhZ3JlZSB3aXRoIGl0cyBjb250ZW50LCB0aGF0J3MgYWxzbw0KPmludGVyZXN0aW5nIGZl ZWRiYWNrIHRvIGhhdmUuDQo+DQo+VGhhbmtzIQ0KPg0KPkJlc3QgcmVnYXJkcywNCj4tLSANCj5G ZXJuYW5kbyBHb250DQo+ZS1tYWlsOiBmZXJuYW5kb0Bnb250LmNvbS5hciB8fCBmZ29udEBzaTZu ZXR3b3Jrcy5jb20NCj5QR1AgRmluZ2VycHJpbnQ6IDc4MDkgODRGNSAzMjJFIDQ1QzcgRjFDOSAz OTQ1IDk2RUUgQTlFRiBEMDc2IEZGRjENCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Tue Sep 1 03:10:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30401B74B8 for ; Tue, 1 Sep 2015 03:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEX1vDD4r47t for ; Tue, 1 Sep 2015 03:10:38 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361411B465F for ; Tue, 1 Sep 2015 03:10:35 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZWiVJ-0000dn-3Q; Tue, 01 Sep 2015 12:09:25 +0200 To: "Eric Vyncke (evyncke)" , Fernando Gont , IPv6 Operations References: <55E4FCB6.8040407@gont.com.ar> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <55E578C1.3040507@si6networks.com> Date: Tue, 1 Sep 2015 07:06:57 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org" , "ipv6-ops@lists.cluenet.de" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] Why operators filter IPv6 packets with extension headers? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 10:10:48 -0000 Hi, Eric, Thanks so much for the timely feedback! Please find some comments inline (more in a subsequent email)... On 09/01/2015 05:42 AM, Eric Vyncke (evyncke) wrote: > > A couple of quick comments: > > - this reminds me of taylor-v6ops-fragdrop (which you cite at the end), > did you approach any of this old I-D authors? Warren (co-author of this I-D) was a co-author of both draft-taylor-v6ops-fragdrop and draft-wkumari-long-headers -- but I did not approach all co-authors of the aforementioned I-Ds. FWIW, version -00 of our I-D is based in part on what was in version -00 of draft-gont-v6ops-ipv6-ehs-in-real-world (before we decided to have that one just focus on the measurements), and then discussions of this topic on the v6ops mailing-list (mostly the input from Nick and Gert, which was then augmented/elaborated for this I-D). > - not sure whether the security implications should be re-stated again in > this document, let's rather split the security & operational issues into > two documents FWIW, the intent here with respect to the security implications was to provide a rather high-level discussion, and provide pointers for the interested reader. While in principle I don't object to splitting considerations in separate documents, I'm not sure it's possible to separate them, since the security aspect is probably one of the reasons for which some people filter them, though. > - in the introduction, 'widespread implementation limitations' is probably > too strong (and I agree that my employer products could do better) The intent here was to note that it's not a single product/vendor that has limitations in this respect, but rather rather a more widespread/general thing. Do you have any suggestions on how to tweak the text? > - in the introduction, "intentionally dropped" ? I am afraid that some > drop are not intentional Agreed. We noted that "...may be intentionally dropped on the public Internet in some network deployments". i.e., some operators do filter packets with EHs for a reason (rather than just e.g. wrong configuration defaults of buggy boxes). > - I would shorten a lot the section 3 (security implications) and simply > put a lot of references to existing good documents of yours and others This is indeed an open question. One one hand, the idea was to provide pointers (please let us know the ones we may have missed). On the other hand, we tried to provide some level discussion of each of the bullets such that folks could get some idea of "what this is all about" without digging into lots of documents. > - I like section 4 (operational implications) but it does not match the > title, it is more about why transit operators have to look at layer-4 My mental model of this section is "We filter packets with EHs because they prevent us from doing our job, because we need the layer-4 info... And this is why we need that info". > - section 4 approaches the goal described in the abstract but actually > only provide clues why operators intentionally (or non intentionally) > drops packets with EH. For example, being unable to do ECMP is of course > an operational impact but why would it be the cause of EH drop? You mean other than you don't have many header fields on which to hash? > - section 4.1 (iACL), beyond the permit/deny, some operators also rate > limit some traffic such pings Yep. Will fix. > - section 4.2 (route processor protection) is a little unclear > > - the processing of HbH would kill the Internet of course (at least with > most routers), should HbH be separately called? I think that'd be sensible. -- and seem to recall that there was some I-D (RFC?) focusing on HbH? (or was it on router alert option?) > - missing issue is lack of granular EH control by some routers, for > example if an operator wants to block its subscribers RH-0 but can only > drop RH (because RH type cannot be specified), then all RH are dropped > including MIPv6 Good point. Will add this. > - section 5 (potential attack vector) appears to be focus on fragment drop > by the public Internet. Yes. > While it can probably work, the issues are twofold: FWIW, kernel.org was vulnerable to this (before the Linux kernel was patched to prevent the generation of atomic fragments) > 1) bad host implementations not doing enough tests before accepting a ICMP > packet-too-big Agreed. However: i) RFC4443 does not require such checks (unfortunately) ii) Because of EHs, at least in theory you might not even have such info available (a packet with EHs might mean that what you get in the ICMPv6 payload does not even have the layer-4 header) > 2) public Internet dropping valid fragments in transit > In both cases, we (the industry, vendors + operators) need to fix those > two issues. "Agreed" -- although some have argued against that (fwiw, I'm just the messenger :-) ) > May I STRONGLY suggest to remove all security issues (other docs are > describing this) and focus only on the operational issues (esp in V6OPS) ? > And skip any discussion on the rationale why packets with EH are dropped? Let's hear from other folks what they think. I think that without at least some "roadmap"/brief discussion, folks might need to dig deep into many documents in order to grasp "what this is ll about". FWIW, 8just me thinking out loud), I guess that one of the possible outcomes could be to have (some reduced version of) Section 3 be a subsection of Section 4? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Sep 1 13:43:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3AD1B382D for ; Tue, 1 Sep 2015 13:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tApubPglRUAt for ; Tue, 1 Sep 2015 13:43:52 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657F51B2F57 for ; Tue, 1 Sep 2015 13:43:52 -0700 (PDT) Received: by pacwi10 with SMTP id wi10so6905472pac.3 for ; Tue, 01 Sep 2015 13:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=1gkwlXU2LVTRN92JlevcA4qfL5CZQiFMhainp7U6gfI=; b=BIeOIy6ndW3zDNiCMKk3wgODeg8ezMajWfdVGfqzwXZq4IDFYfPKcPwdX4ypAbQV6i so0cJ2XPh8cjgZ27rvRM9H1xosTgbxJmsH9fW0jEj8b2YcNPmMksiWTs57esKjXuYU0b YHQZEON/OVKu0EDaGbHGNxOvVLE8mTkxesa4arl3PnlZC0IOGDuvpF46jlIEvbSL1z+5 TYEs8KQ5xijLc9t6uFw8xqIWUikLVFXX9bDE1gOjKk3HmHo0KyMmP2a+yyWcXuJlhaNu QKiKcrVCTGEiyTxb4T7lEF6TEx6xymH40d4+Z4i2gbVvZYjkbU16z6hVWBsdeu2MNekl t6zg== X-Received: by 10.66.161.137 with SMTP id xs9mr50928727pab.117.1441140231958; Tue, 01 Sep 2015 13:43:51 -0700 (PDT) Received: from ?IPv6:2406:e007:41d3:1:28cc:dc4c:9703:6781? ([2406:e007:41d3:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i8sm12652906pbq.31.2015.09.01.13.43.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Sep 2015 13:43:50 -0700 (PDT) To: Fernando Gont , "Eric Vyncke (evyncke)" , Fernando Gont , IPv6 Operations References: <55E4FCB6.8040407@gont.com.ar> <55E578C1.3040507@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55E60E06.1050305@gmail.com> Date: Wed, 2 Sep 2015 08:43:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55E578C1.3040507@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org" , "ipv6-ops@lists.cluenet.de" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] Why operators filter IPv6 packets with extension headers? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 20:43:53 -0000 On 01/09/2015 22:06, Fernando Gont wrote: > Hi, Eric, > > Thanks so much for the timely feedback! Please find some comments inline > (more in a subsequent email)... > > > On 09/01/2015 05:42 AM, Eric Vyncke (evyncke) wrote: ... >> - the processing of HbH would kill the Internet of course (at least with >> most routers), should HbH be separately called? > > I think that'd be sensible. -- and seem to recall that there was some > I-D (RFC?) focusing on HbH? (or was it on router alert option?) You're probably thinking of draft-baker-6man-hbh-header-handling, but there's a slight conflict between that and RFC 7045, which made a normative change to HbH by downgrading them to SHOULD: The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour. Also of course the next version of 2460bis will revisit this topic. Brian From nobody Thu Sep 3 16:40:18 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237DB1B34DD; Thu, 3 Sep 2015 16:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzcg_TYWleNi; Thu, 3 Sep 2015 16:40:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C90FF1B34E8; Thu, 3 Sep 2015 16:40:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150903234014.31800.84200.idtracker@ietfa.amsl.com> Date: Thu, 03 Sep 2015 16:40:14 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-host-addr-availability-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 23:40:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Host address availability recommendations Authors : Lorenzo Colitti Vint Cerf Stuart Cheshire David Schinazi Filename : draft-ietf-v6ops-host-addr-availability-01.txt Pages : 13 Date : 2015-09-03 Abstract: This document recommends that networks provide general-purpose end hosts with multiple global addresses when they attach, and describes the benefits of and the options for doing so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-01 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 Sep 7 05:15:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A95C1B4B69 for ; Mon, 7 Sep 2015 05:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl-d5EGchaQp for ; Mon, 7 Sep 2015 05:15:27 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002: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 799611B488E for ; Mon, 7 Sep 2015 05:15:27 -0700 (PDT) Received: by ykcf206 with SMTP id f206so78461120ykc.3 for ; Mon, 07 Sep 2015 05:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kDTlSdugY4M9wtDt/p4uz2Mk+8c2HA9pHCYTU6vf9zE=; b=cOTGaTgp/50Hs1rTkID62lo+D7LUirvDjHCPxO49mSoOkBx1EbwptzYUvxaGlAVTeA azjA5rSfamV31TU5eoe00x1O7lbi4DBPXMj7+rxulG6qtbTCxgyJZHfZTwHjwPF3xzdz d4ESXW70b00y6ViK3R4tyaPrgOY5jqmq9S2iEupMdVimS2L1s60NUFXCCdIzjRh8JrCm /OOCYPaQMsCWZG15ffv2+CMqd/blmJmrbHRl2vfMdgcOWVCTI1qk+55PAOsZJyNtnKkC SWwpqi+XCoj9jiIkDwxNXRYqsypU5HcYXpW/J1R4Vtsz4pt/628TbGxDjnxZ+PLS+H2w yW9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kDTlSdugY4M9wtDt/p4uz2Mk+8c2HA9pHCYTU6vf9zE=; b=NmSbAaF3VcP4vZ3T0earzIMM38Kn+hcU+oGgDxBDO0FBv2TksPzNaYXnkFCZV+nkfw VUJdpVbtftjZilx9vH11e+8UyrCa/Gj+X3LRsrpfzLf63v/FQMyffWiz9hV7geuuyiCQ GM3RWI74uS3STBiPJKvluM+dSqM2UXkvk6X1FcH+0mjSB4op1Ims8GMuYuqjhZFHpfY8 p11kXu65zAJvmJRbcCA5sCPyiSTZr+/rfadO5qoGqlwykmScAB0gm/gOOJBayoWTGfwH czr0N+QmMYGGjwKUTxyYVI2zpAaCU1oGzYOETF6vJFtPOfrsFEAopLxy5fBnpmCbLbfH JGhA== X-Gm-Message-State: ALoCoQnbCk6tvgwnJsusrZON+U6H1qzZe1lMhGYOxtltDdEYNeIpKFqAP7nqAl4gtKWDCO11ZxKm X-Received: by 10.13.254.4 with SMTP id o4mr20294289ywf.88.1441628126667; Mon, 07 Sep 2015 05:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Mon, 7 Sep 2015 05:15:07 -0700 (PDT) In-Reply-To: <6875692D-AD67-4B40-A635-047A8F7C1DFB@umn.edu> References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <6875692D-AD67-4B40-A635-047A8F7C1DFB@umn.edu> From: Lorenzo Colitti Date: Mon, 7 Sep 2015 21:15:07 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=94eb2c08152863d1d7051f27348d Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 12:15:29 -0000 --94eb2c08152863d1d7051f27348d Content-Type: text/plain; charset=UTF-8 On Mon, Aug 31, 2015 at 6:59 AM, David Farmer wrote: > 1. Section "3. Consequences" seems to express disapproval of ignoring RA's > or IPv6 traffic altogether while devices are asleep. However, there are no > recommendations regarding the proper behavior of host implementations in > this respect within Section 4. Please clearly recommend RAs not be > ignored, if that is the intent. Otherwise, maybe suggest an upper limit on > the period RA's or IPv6 traffic MAY be ignored by host implementations. > There are recommendations on host implementations. Specifically, the draft says: - Mobile devices that intend to maintain IPv6 connectivity while asleep MUST NOT ignore RAs while asleep. - Mobile devices that do not intend to maintain IPv6 connectivity while asleep SHOULD disconnect from the IPv6 network and SHOULD reconnect to the network (including performing any DNAv6 procedures [RFC6059], sending Router Solicitations and performing Duplicate Address Detection) when waking up. 2. Section "4. Recommendations" currently intermixes recommendations for > router implementations and network operators. I would like to see three > sets of recommendations that clearly delineate the recommendations for > router implementations, host implementations, and network operators > separately. This may cause some slight repetition, however I think the > clarity provided would be very beneficial. > There are only 4 recommendations. I split them half way and ended up with: ========= 4. Recommendations 4.1. Network recommendations 1. Router manufacturers SHOULD allow network administrators to configure the routers to respond to Router Solicitations with unicast Router Advertisements if: * The Router Solicitation's source address is not the unspecified address, and: * The solicitation contains a valid Source Link-Layer Address option. 2. Administrators of networks that serve large numbers (tens or hundreds) of battery-powered devices SHOULD enable this behaviour. 3. Networks that serve battery-powered devices SHOULD NOT send multicast RAs too frequently (e.g., more than one every 5-10 minutes for current battery-powered devices) unless the information in the RA packet has substantially changed. If there is a desire to ensure that hosts pick up configuration changes quickly, those networks MAY send frequent Router Advertisements for a limited period of time (e.g., not more than one minute) immediately after a configuration change. No protocol changes are required. Responding to Router Solicitations with unicast Router Advertisements is already allowed by section 6.2.6 of [RFC4861], and Router Advertisement intervals are already configurable by the administrator to a wide range of values. 4.2. Device recommendations 1. Mobile devices that intend to maintain IPv6 connectivity while asleep MUST NOT ignore RAs while asleep. 2. Mobile devices that do not intend to maintain IPv6 connectivity while asleep SHOULD disconnect from the IPv6 network and SHOULD reconnect to the network (including performing any DNAv6 procedures [RFC6059], sending Router Solicitations and performing Duplicate Address Detection) when waking up. ========= I'm not sure if the result is better or worse. --94eb2c08152863d1d7051f27348d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 31, 2015 at 6:59 AM, David Farmer <farmer@umn.edu> wrot= e:
1. Section "3. Consequences" seems to expr= ess disapproval of ignoring RA's or IPv6 traffic altogether while devic= es are asleep.=C2=A0 However, there are no recommendations regarding the pr= oper behavior of host implementations in this respect within Section 4.=C2= =A0 Please clearly recommend RAs not be ignored, if that is the intent.=C2= =A0 Otherwise, maybe suggest an upper limit on the period RA's or IPv6 = traffic MAY be ignored by host implementations.

There are recommendations on host implementations. Specifically, t= he draft says:
  • Mobile devices that intend to maintain IPv= 6 connectivity while asleep MUST NOT ignore RAs while asleep.
  • M= obile devices that do not intend to maintain IPv6 connectivity while asleep= SHOULD disconnect from the IPv6 network and SHOULD reconnect to the networ= k (including performing any DNAv6 procedures [RFC6059], sending Router Soli= citations and performing Duplicate Address Detection) when waking up.
    • <= /ul>
2. Section "4. Recommendations" currently intermixes recommendati= ons for router implementations and network operators.=C2=A0 I would like to= see three sets of recommendations that clearly delineate the recommendatio= ns for router implementations, host implementations, and network operators = separately.=C2=A0 This may cause some slight repetition, however I think th= e clarity provided would be very beneficial.

There are only 4 recommendations. I split them half way and ended up = with:

=3D=3D=3D=3D=3D=3D=3D=3D=3D
4= .=C2=A0 Recommendations

4.1.=C2=A0 Network recomme= ndations

=C2=A0 =C2=A01.=C2=A0 Router manufacturer= s SHOULD allow network administrators to
=C2=A0 =C2=A0 =C2=A0 =C2= =A0configure the routers to respond to Router Solicitations with
= =C2=A0 =C2=A0 =C2=A0 =C2=A0unicast Router Advertisements if:

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0* =C2=A0The Router Solicitation's= source address is not the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uns= pecified address, and:

=C2=A0 =C2=A0 =C2=A0 =C2=A0= * =C2=A0The solicitation contains a valid Source Link-Layer Address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 option.

=C2= =A0 =C2=A02.=C2=A0 Administrators of networks that serve large numbers (ten= s or
=C2=A0 =C2=A0 =C2=A0 =C2=A0hundreds) of battery-powered devi= ces SHOULD enable this
=C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour.

=C2=A0 =C2=A03.=C2=A0 Networks that serve battery-powe= red devices SHOULD NOT send
=C2=A0 =C2=A0 =C2=A0 =C2=A0multicast = RAs too frequently (e.g., more than one every 5-10
=C2=A0 =C2=A0 = =C2=A0 =C2=A0minutes for current battery-powered devices) unless the
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0information in the RA packet has substantial= ly changed.=C2=A0 If there
=C2=A0 =C2=A0 =C2=A0 =C2=A0is a de= sire to ensure that hosts pick up configuration changes
=C2=A0 = =C2=A0 =C2=A0 =C2=A0quickly, those networks MAY send frequent Router Advert= isements
=C2=A0 =C2=A0 =C2=A0 =C2=A0for a limited period of time = (e.g., not more than one minute)
=C2=A0 =C2=A0 =C2=A0 =C2=A0immed= iately after a configuration change.

=C2=A0 =C2=A0= No protocol changes are required.=C2=A0 Responding to Router Solicitations<= /div>
=C2=A0 =C2=A0with unicast Router Advertisements is already allowe= d by section
=C2=A0 =C2=A06.2.6 of [RFC4861], and Router Advertis= ement intervals are already
=C2=A0 =C2=A0configurable by the admi= nistrator to a wide range of values.

4.2.=C2=A0 De= vice recommendations

=C2=A0 =C2=A01.=C2=A0 Mobile = devices that intend to maintain IPv6 connectivity while
=C2=A0 = =C2=A0 =C2=A0 =C2=A0asleep MUST NOT ignore RAs while asleep.

=
=C2=A0 =C2=A02.=C2=A0 Mobile devices that do not intend to maint= ain IPv6 connectivity
=C2=A0 =C2=A0 =C2=A0 =C2=A0while asleep SHO= ULD disconnect from the IPv6 network and SHOULD
=C2=A0 =C2=A0 =C2= =A0 =C2=A0reconnect to the network (including performing any DNAv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0procedures [RFC6059], sending Router Solicitat= ions and performing
=C2=A0 =C2=A0 =C2=A0 =C2=A0Duplicate Address = Detection) when waking up.

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

I'm not sure if the result is = better or worse.
--94eb2c08152863d1d7051f27348d-- From nobody Mon Sep 7 05:34:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D5E1B466B; Mon, 7 Sep 2015 05:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jra7p32a-O55; Mon, 7 Sep 2015 05:34:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4961B46D3; Mon, 7 Sep 2015 05:34:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150907123450.21037.18849.idtracker@ietfa.amsl.com> Date: Mon, 07 Sep 2015 05:34:50 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 12:34:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Reducing energy consumption of Router Advertisements Authors : Andrew Yourtchenko Lorenzo Colitti Filename : draft-ietf-v6ops-reducing-ra-energy-consumption-01.txt Pages : 5 Date : 2015-09-07 Abstract: Frequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-reducing-ra-energy-consumption/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-reducing-ra-energy-consumption-01 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 Sep 7 09:29:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA51B4C20 for ; Mon, 7 Sep 2015 09:29:30 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFfHenIs2L5s for ; Mon, 7 Sep 2015 09:29:28 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id B19EA1B4C3D for ; Mon, 7 Sep 2015 09:29:28 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Mon, 7 Sep 2015 11:29:27 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-io0-f170.google.com [209.85.223.170] #+LO+TS+TR X-Umn-Classification: local Received: by iofh134 with SMTP id h134so92637442iof.0 for ; Mon, 07 Sep 2015 09:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=nNICSNN1kYuzs2O+4M9b9D6jhzrcDDmD4+vhm9imRfs=; b=Nxg0sOqMg8NS2FQD6oa0azgBYG605oLbaAmDAUmvVk39fn8f//m0hGcQx48xa8h5GY JDWNFFH59laLRmRqITYApGrNzVFVI+8wAK2KCk2Z1USPGZjtNdEAEvXt8RLSl3AunGHW LeXDXy+Wh7laYYgJhouqlqrPau0JtKSYGTVwI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=nNICSNN1kYuzs2O+4M9b9D6jhzrcDDmD4+vhm9imRfs=; b=O332porxoMdFR/22TKA5Au08QOY353HjD/C//lHIxqiyIKf4z2+nkTj+kkmax5q3GE AgXpG7sIhATxN3olO6OQACqRIJaivEQ6VcunKccqfEvl7FyeRdInx09fchrJFP1Dv9kP nptfv7Kndjt9X8s8+sSMZZJJn8jljEJ0VBE6Kk65IMUcKgJtINmyga5lRCM0td+zD6nE rh5S6zl7bEanaeih5apuRxG1hSTkeOI5ZtTj31mzEaw7VJB9tLbXmyQRgGdnnsTw3LTp kUr31Mbrih442Odg1jOnY6kYCo8OXsEcMKSM47sG0JBThTUzr0tS891Nj5oyP7UGuK9V mUVQ== X-Gm-Message-State: ALoCoQkJM1DzNrphRPijHf9nbZtGe991o/z9jjhbS41zgkumaX0UHE7XZSY7niwdwR1GaifYPCRr/M03f6XgxqfDQcnFEuwYqAvS0rFG2qAnnJ7etdbi5xYVm+TbYlrY6gnB8M13AS85 X-Received: by 10.107.160.67 with SMTP id j64mr8700158ioe.128.1441643366793; Mon, 07 Sep 2015 09:29:26 -0700 (PDT) X-Received: by 10.107.160.67 with SMTP id j64mr8700075ioe.128.1441643366216; Mon, 07 Sep 2015 09:29:26 -0700 (PDT) Received: from ?IPv6:2601:449:8100:a59f:c835:1e19:7c98:7f79? ([2601:449:8100:a59f:c835:1e19:7c98:7f79]) by smtp.gmail.com with ESMTPSA id 75sm374877ion.16.2015.09.07.09.29.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Sep 2015 09:29:24 -0700 (PDT) References: <201508231800.t7NI011E029031@irp-lnx1.cisco.com> <6875692D-AD67-4B40-A635-047A8F7C1DFB@umn.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5BDD6589-37DE-48C6-B0DC-B6BD78668709@umn.edu> X-Mailer: iPad Mail (12H321) From: David Farmer Date: Mon, 7 Sep 2015 11:29:23 -0500 To: Lorenzo Colitti Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 16:29:30 -0000 > On Sep 7, 2015, at 07:15, Lorenzo Colitti wrote: >=20 > 4.2. Device recommendations >=20 > 1. Mobile devices that intend to maintain IPv6 connectivity while > asleep MUST NOT ignore RAs while asleep. >=20 > 2. Mobile devices that do not intend to maintain IPv6 connectivity > while asleep SHOULD disconnect from the IPv6 network and SHOULD > reconnect to the network (including performing any DNAv6 > procedures [RFC6059], sending Router Solicitations and performing > Duplicate Address Detection) when waking up. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > I'm not sure if the result is better or worse. The added text uses the term "mobile devices", where as the rest of the docu= ment uses the term "battery-powered devices". I think I prefer the term use= d in the rest of the document. Otherwise, the added text resolves two of th= e issues I brought up. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Mon Sep 7 10:09:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF2D1B36BA for ; Mon, 7 Sep 2015 10:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9nk7AHrq3c3 for ; Mon, 7 Sep 2015 10:09:35 -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 087821B36A3 for ; Mon, 7 Sep 2015 10:09:35 -0700 (PDT) Received: from mb.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t87H9X7D001069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 7 Sep 2015 17:09:34 GMT (envelope-from joelja@bogus.com) To: IPv6 Ops WG From: joel jaeggli Message-ID: <55EDC4C7.4040508@bogus.com> Date: Mon, 7 Sep 2015 10:09:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wHAQFFCQEOfsmwXGi7SFi5HA2i2nE7OGQ" Archived-At: Subject: [v6ops] The SIIT package of documents should IETF last-call on tuesday X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 17:09:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wHAQFFCQEOfsmwXGi7SFi5HA2i2nE7OGQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable One of these will be 4 weeks. Informational https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ Proposed standard https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ regards joel --wHAQFFCQEOfsmwXGi7SFi5HA2i2nE7OGQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXtxMgACgkQ8AA1q7Z/VrK4wgCcClKbi0q7HIZK2kKE+1TdegXP +/kAnAm9aExfHfx84MyxIBL/AMDiWzKS =0sT8 -----END PGP SIGNATURE----- --wHAQFFCQEOfsmwXGi7SFi5HA2i2nE7OGQ-- From nobody Mon Sep 7 22:45:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23911B3AEC for ; Mon, 7 Sep 2015 22:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Zq0G3ap_Exn for ; Mon, 7 Sep 2015 22:45:51 -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 9BB421B3B03 for ; Mon, 7 Sep 2015 22:45:51 -0700 (PDT) Received: from mb.local (c-98-248-47-249.hsd1.ca.comcast.net [98.248.47.249]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t885jdxg004703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Sep 2015 05:45:40 GMT (envelope-from joelja@bogus.com) To: "Eric Vyncke (evyncke)" , Fernando Gont , IPv6 Operations References: <55E4FCB6.8040407@gont.com.ar> From: joel jaeggli Message-ID: <55EE75FD.5060704@bogus.com> Date: Mon, 7 Sep 2015 22:45:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8eoTj9dF8A1Fo8L3esjV1elq4kGwHchLA" Archived-At: Cc: "draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org" , "ipv6-ops@lists.cluenet.de" , "ipv6-wg@ripe.net" Subject: Re: [v6ops] Why operators filter IPv6 packets with extension headers? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 05:45:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8eoTj9dF8A1Fo8L3esjV1elq4kGwHchLA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/1/15 1:42 AM, Eric Vyncke (evyncke) wrote: > Fernando et al., >=20 > A couple of quick comments: >=20 > - this reminds me of taylor-v6ops-fragdrop (which you cite at the end),= > did you approach any of this old I-D authors? I think it's safe to say they we're all operating in the same milieu. > - not sure whether the security implications should be re-stated again = in > this document, let's rather split the security & operational issues int= o > two documents >=20 > - in the introduction, 'widespread implementation limitations' is proba= bly > too strong (and I agree that my employer products could do better) >=20 > - in the introduction, "intentionally dropped" ? I am afraid that some > drop are not intentional >=20 > - I would shorten a lot the section 3 (security implications) and simpl= y > put a lot of references to existing good documents of yours and others >=20 > - I like section 4 (operational implications) but it does not match the= > title, it is more about why transit operators have to look at layer-4 >=20 > - section 4 approaches the goal described in the abstract but actually > only provide clues why operators intentionally (or non intentionally) > drops packets with EH. For example, being unable to do ECMP is of cours= e > an operational impact but why would it be the cause of EH drop? >=20 > - section 4.1 (iACL), beyond the permit/deny, some operators also rate > limit some traffic such pings >=20 > - section 4.1, perhaps worth mentioning that infrastructure ACL are mor= e > in the white list approach, i.e., what is not BGP/ICMP (in your example= ) > to some prefixes is dropped, so, if someone uses EH to obscure the > traffic, this EH traffic matching the destination prefix is dropped any= way > by the ACL (so iACL works) but traffic destined to other destination is= > not impacted. Or did I got something wrong? >=20 > - section 4.2 (route processor protection) is a little unclear >=20 > - the processing of HbH would kill the Internet of course (at least wit= h > most routers), should HbH be separately called? >=20 > - section 4.3 (DDoS mitigation), I am unsure about FlowSPec but can it > also specify 'any traffic with EH' ? This would do the trick probably f= or > dropping or diverting the DoS packets? >=20 > - missing issue is lack of granular EH control by some routers, for > example if an operator wants to block its subscribers RH-0 but can only= > drop RH (because RH type cannot be specified), then all RH are dropped > including MIPv6 >=20 > - section 5 (potential attack vector) appears to be focus on fragment d= rop > by the public Internet. While it can probably work, the issues are > twofold:=20 > 1) bad host implementations not doing enough tests before accepting a I= CMP > packet-too-big=20 > 2) public Internet dropping valid fragments in transit > In both cases, we (the industry, vendors + operators) need to fix those= > two issues. >=20 >=20 > May I STRONGLY suggest to remove all security issues (other docs are > describing this) and focus only on the operational issues (esp in V6OPS= ) ? > And skip any discussion on the rationale why packets with EH are droppe= d? >=20 >=20 > Hope this helps to refine a potentially useful I-D. >=20 >=20 >=20 > -=C3=A9ric >=20 >=20 > On 1/09/15 03:17, "v6ops on behalf of Fernando Gont" > wrote: >=20 >> Folks, >> >> The topic of operators dropping IPv6 packets containing extension >> headers has been raised quite a few times on this list and elsewhere. >> >> A month ago or so we published a document trying to summarize the >> reasons for which operators filter IPv6 packets containing extension >> headers. The document is available at: >> >> >> We're currently working on a revision of this document, and would like= >> to hear feedback from the working group regarding our document. e.g., >> >> * Did we get anything wrong? >> * Is there anything missing? >> >> Or, if you like the document and agree with its content, that's also >> interesting feedback to have. >> >> Thanks! >> >> Best regards, >> --=20 >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@si6networks.com >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --8eoTj9dF8A1Fo8L3esjV1elq4kGwHchLA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXudf4ACgkQ8AA1q7Z/VrJokQCfe58pyZl42MS2ovdS4RBh+flX GkUAn3iRkxBm1e+COe/cOmkqT8/m6+ts =iHkP -----END PGP SIGNATURE----- --8eoTj9dF8A1Fo8L3esjV1elq4kGwHchLA-- From nobody Tue Sep 8 06:06:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42931B4435; Tue, 8 Sep 2015 06:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1orWg2nRyuv7; Tue, 8 Sep 2015 06:06:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EABB1B42AE; Tue, 8 Sep 2015 06:06:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150908130616.2563.87115.idtracker@ietfa.amsl.com> Date: Tue, 08 Sep 2015 06:06:16 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 13:06:20 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of the Stateless IP/ICMP Translation (SIIT) algorithm in an IPv6 Internet Data Centre (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilisation of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feel that dual stack causes undesirable operational complexity. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Sep 8 06:07:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABC21B458A; Tue, 8 Sep 2015 06:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH4yMjkKRTPW; Tue, 8 Sep 2015 06:07:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 161D01B3F93; Tue, 8 Sep 2015 06:07:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150908130704.10575.87361.idtracker@ietfa.amsl.com> Date: Tue, 08 Sep 2015 06:07:04 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (SIIT-DC: Dual Translation Mode) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 13:07:05 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'SIIT-DC: Dual Translation Mode' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Centre Environments architecture (SIIT-DC), which allows applications, protocols, or nodes that are incompatible with IPv6, and/or Network Address Translation to operate correctly in an SIIT-DC environment. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency. The reader is expected to be familiar with the SIIT-DC architecture described in I-D.ietf-v6ops-siit-dc. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc-2xlat/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Sep 8 06:07:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ED21B2CC1; Tue, 8 Sep 2015 06:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlXhmM60TPAm; Tue, 8 Sep 2015 06:07:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFF61A6F02; Tue, 8 Sep 2015 06:07:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150908130751.10251.8565.idtracker@ietfa.amsl.com> Date: Tue, 08 Sep 2015 06:07:51 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Explicit Address Mappings for Stateless IP/ICMP Translation) to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 13:07:53 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Explicit Address Mappings for Stateless IP/ICMP Translation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document extends the Stateless IP/ICMP Translation Algorithm (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-eam/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Sep 8 09:22:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A1A1AC3F2 for ; Tue, 8 Sep 2015 09:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD6AxV9TwTss for ; Tue, 8 Sep 2015 09:21:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83341B5000 for ; Tue, 8 Sep 2015 09:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7232; q=dns/txt; s=iport; t=1441729316; x=1442938916; h=from:to:subject:date:message-id:references:mime-version; bh=rLzU2dLRabA/cjg7tpdAwVXmSB/avOOTsQCC/0c45eM=; b=GWBLmnRKey/ZEf7eDFE8BHjZHN9NGVTnW7u+a+AsrI7+HMAut9+qeEIq vvtTRX3SVF77Rc0SQ+YSlsF1Kn1SYM32OC7CTMVfK/9+FHAOrgeIuBtaq K7mwd+96bzKxhyc8jNjnht7eXK+36fAGogkwEt13d2ZJGkdNvxIi10WAy 0=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3AwBYCu9V/4cNJK1dgyNUaQaDHroGCoFtCoV5AoE2OBQBAQEBAQEBgQqEIwEBAQMBHQZbCwIBGQMBAhYVAgIyFAcCCAIEEw4GC4gHCA23KpQGAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4kCgmyEKREBQB4EgiQ7Eh2BFAWMd4heAYJCgV1qgm2FA4FMRoNtkQyDbCaEAHGHCjqBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,490,1437436800"; d="asc'?scan'208";a="27160894" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 08 Sep 2015 16:21:55 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t88GLtD9024715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Sep 2015 16:21:55 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Sep 2015 11:21:54 -0500 Received: from xhc-rcd-x04.cisco.com (173.37.183.78) by xch-aln-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 8 Sep 2015 11:21:54 -0500 Received: from xmb-rcd-x09.cisco.com ([169.254.9.173]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0248.002; Tue, 8 Sep 2015 11:21:54 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: NomCom 2015: Call for nominations Thread-Index: AQHQ6lJ5cofNuk5k/UqrIOR0D1SJ+Q== Date: Tue, 8 Sep 2015 16:21:53 +0000 Message-ID: References: <55EE8A1B.3030903@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.20] Content-Type: multipart/signed; boundary="Apple-Mail=_08CE6E98-CFDE-4496-8E5D-C0856081C125"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: NomCom 2015: Call for nominations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 16:21:59 -0000 --Apple-Mail=_08CE6E98-CFDE-4496-8E5D-C0856081C125 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Folks: The Nominating Committee is looking for a Network Management AD (an O&M = AD along with Joel, but primarily managing the network management = working groups). If you're happy with Benoit, they need to hear that. If = you're unhappy with Benoit, they need to hear that. If you have a = qualified nomination for them (e.g., you asked the person and they = agreed to be nominated), they also need candidates. Fred > Begin forwarded message: >=20 > From: Benoit Claise > Subject: Fwd: Fwd: NomCom 2015: Call for nominations > Date: September 8, 2015 at 12:11:23 AM PDT > To: > Cc: "ops-ads@tools.ietf.org" >=20 > Dear OPS chairs, >=20 > Please make sure your WG/community is aware of (the importance of) = this message. >=20 > Regards, Benoit >=20 > -------- Forwarded Message -------- > Subject: NomCom 2015: Call for nominations > Date: Wed, 26 Aug 2015 03:13:13 -0700 > From: NomCom Chair 2015 > Reply-To: ietf@ietf.org, nomcom15@ietf.org > To: IETF Announcement List > CC: ietf@ietf.org >=20 >=20 >=20 > The 2015-16 Nominating Committee (Nomcom) is seeking nominations from > now until October 8, 2015. The open positions being considered by this > year's Nomcom can be found at the end of this email and also on this > year's Nomcom website: >=20 > https://datatracker.ietf.org/nomcom/2015/ >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2015 home page, or by visiting the following URL: >=20 > https://datatracker.ietf.org/nomcom/2015/nominate/ >=20 > {Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: > https://datatracker.ietf.org/accounts/create/ } >=20 > If you are unable to use the web form, nominations may instead be made > by email tonomcom15@ietf.org. If using email, please include the word > "Nominate" in the Subject and indicate in the email who is being > nominated, their email address (to confirm acceptance of the > nomination), and the position for which you are making the nomination. > If you are nominating someone other than yourself, please tell us if > we may tell the nominee that you were the one who made the nomination. > If you wish to nominate someone via email for more than one position, > please use separate emails to do so. >=20 > Self-nomination is welcome! >=20 > NomCom 2015-16 will follow the policy for "Open Disclosure of Willing > Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The > list of nominees willing to be considered for positions under review > in the current Nomcom cycle is not confidential". Willing nominees for > each position will be listed in a publicly accessible way - anyone > with a datatracker account may access the lists. Additionally, the > nomination form asks if we may share your own name with the > nominee. In all other ways, the confidentiality requirements of BCP10 > remain in effect. All feedback and all Nomcom deliberations will > remain confidential and will not be disclosed. >=20 > There is a field on the form you can mark in order to allow the Nomcom > to tell the nominee that you were the one who made the > nomination. This is a new thing this year, and it defaults to =E2=80=9Cn= o=E2=80=9D - > we won=E2=80=99t tell. After the nomination cycle, we will evaluate = the result > of this and recommend whether the next Nomcom should do something > different. >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the > Nomcom on or before October 8, 2015. >=20 > Please submit your nominations as early as possible for the sake of > your nominees. Note that nominations should not wait for management > permission, as it is easier to decline the nomination than put one in > late. We have set the questionnaire submission deadline for October > 15, 2015. >=20 > The Nomcom appoints individuals to fill the open slots on the IAOC, > the IAB, and the IESG. The list of people and posts whose terms end > with the March 2016 IETF meeting, and thus the positions for which > this Nomcom is responsible, follows: >=20 > IAB: > * Mary Barnes > * Joe Hildebrand > * Ted Hardie > * Erik Nordmark > * Brian Trammell > * Mark Blanchet >=20 > IESG: > - Alissa Cooper, ART > - Barry Leiba, ART > - Brian Haberman, Internet (*) > - Benoit Claise, O&M > - Alia Atlas, Routing > - Kathleen Moriarty, Security > - Martin Stiemerling, Transport (*) >=20 > *- have indicated that they do not intend to accept a > renomination. This information is always up to date on > https://datatracker.ietf.org/nomcom/2015/ >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF, and also, please consider accepting a nomination. You'll > find extensive information about specific positions, developed by the > IAB, IESG, and IAOC, under individual tabs at: >=20 > https://datatracker.ietf.org/nomcom/2015/requirements/ >=20 > In addition to nominations, the Nomcom seeks community input on the > positions themselves. We need and welcome the community's views and > input on the jobs within each organization. If you have ideas on the > positions' responsibilities (more, less, different), please let us > know. >=20 > Please send suggestions and feedback about this tonomcom15@ietf.org. >=20 > Thank you for your help in identifying qualified nominees! >=20 > Harald Alvestrand > Nomcom Chair 2015-16 > nomcom-chair-2015@ietf.org,hta+nomcom@alvestrand.no --Apple-Mail=_08CE6E98-CFDE-4496-8E5D-C0856081C125 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVe8LIkayAOS/EQ8MAQJkExAAsUSgfMysSpVo1RvoNP7ndVwjkVlW2O4i POwEwxxy3qZL0lBEOtifap6jH/PII28XBaJneTCTihCAGHEW1fSfMwW2b4lrjSev YnlnOJRnCGZ50YpoxTeMmw7m7vcH7pZsf0nizy+Ala4O3hxUoxc974I/FQ9f3IMa z83OOJuK0NbyfYdbnO+XlGwaW0l6Ko0doz9FWM0egw6Ak14tasqUZy0SAq47Xpkl xUEANUd577tamgstqx1AFpxPGaPF0N5JXkX4JGHQJqKoUxe+l5mCRUpfr6ADDMei BWx6V1FrMfTJCD3Xm0zB8pSst9YTgHb4SurN+qNHKzvrOpvL1vwA1G2amhodC75Z UwFjrlqZpi90RcFMrnJfI4fyAyg76OafGfrdLi5KXat/UznzMuVDnOd8Gkc+FjTp dlgBOCKXakWJq3rf3MYYZuRCXy78A9klGoXShZNXya75eNOpAmB7jDBo8QUOBPRC dYlRsZuAlNtAkY2vxOrdupkds4FUOTuLIaS9cZpCasEHw1/9ZJ5Ble/ps1DMkBmb s2/6ixagqM4MCrD4BgDXXN661Shxx6h5g3TMAXWJJRiJTb/VsUcbTkVEMvM5/oH3 s9+rue5sEonetXNHHODw1qLNBbbAy7WjAsU98NVpF6vCsZln5tEl7R0mj5Cmat3M lSZJuKt9ZNM= =6PPy -----END PGP SIGNATURE----- --Apple-Mail=_08CE6E98-CFDE-4496-8E5D-C0856081C125-- From nobody Wed Sep 9 05:10:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9711B397B for ; Wed, 9 Sep 2015 05:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nznDcHywHMer for ; Wed, 9 Sep 2015 05:10:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FE61B3988 for ; Wed, 9 Sep 2015 05:10:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBB40469; Wed, 09 Sep 2015 12:10:46 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Sep 2015 13:10:43 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.156]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 9 Sep 2015 20:10:39 +0800 From: "Liushucheng (Will)" To: Lorenzo Colitti Thread-Topic: [v6ops] Review for draft-ietf-v6ops-host-addr-availability Thread-Index: AdDhRK8mEsSwFY5dTgqAjgOzIUGw1gCzJYIAAbikG1A= Date: Wed, 9 Sep 2015 12:10:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.84] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB89571D56SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-host-addr-availability@tools.ietf.org" Subject: Re: [v6ops] Review for draft-ietf-v6ops-host-addr-availability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 12:10:52 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB89571D56SZXEMA509MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBQbGVhc2Ugc2VlIG15IHJl cGx5IGlubGluZSB3aXRoIFtXaWxsXS4NCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86 bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAxLCAyMDE1IDk6 MjAgQU0NClRvOiBMaXVzaHVjaGVuZyAoV2lsbCkNCkNjOiBkcmFmdC1pZXRmLXY2b3BzLWhvc3Qt YWRkci1hdmFpbGFiaWxpdHlAdG9vbHMuaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3Y2b3BzXSBSZXZpZXcgZm9yIGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWls YWJpbGl0eQ0KDQpXaWxsLA0KDQp0aGFua3MgZm9yIHRoZSByZXZpZXcuIENvbW1lbnRzIGlubGlu ZS4NCg0KT24gRnJpLCBBdWcgMjgsIDIwMTUgYXQgMTI6NTEgUE0sIExpdXNodWNoZW5nIChXaWxs KSA8bGl1c2h1Y2hlbmdAaHVhd2VpLmNvbTxtYWlsdG86bGl1c2h1Y2hlbmdAaHVhd2VpLmNvbT4+ IHdyb3RlOg0KPiAgIEFzc2lnbmluZyBhIGxpbWl0ZWQgbnVtYmVyIG9mIGFkZHJlc3NlcyBwZXIg aG9zdCBpbXBsaWVzIHRoYXQNCj4gICBmdW5jdGlvbnMgdGhhdCByZXF1aXJlIG11bHRpcGxlIGFk ZHJlc3NlcyB3aWxsIGVpdGhlciBiZSB1bmF2YWlsYWJsZQ0KPiAgIChlLmcuLCBpZiB0aGUgbmV0 d29yayBwcm92aWRlcyBvbmx5IG9uZSBJUHY2IGFkZHJlc3MgcGVyIGhvc3QsIG9yIGlmDQo+ICAg dGhlIGhvc3QgaGFzIHJlYWNoZWQgdGhlIGxpbWl0IG9mIHRoZSBudW1iZXIgb2YgYWRkcmVzc2Vz IGF2YWlsYWJsZSksDQo+ICAgb3IgdGhhdCB0aGUgZnVuY3Rpb25zIHdpbGwgb25seSBiZSBhdmFp bGFibGUgYWZ0ZXIgYW4gZXhwbGljaXQNCj4gICByZXF1ZXN0IHRvIHRoZSBuZXR3b3JrIGlzIGdy YW50ZWQuICBUaGUgbmVjZXNzaXR5IG9mIGV4cGxpY2l0DQoNCkNvdWxkIHlvdSBleHBsaWNpdGx5 IHBvaW50IG91dCB3aGljaCAiZnVuY3Rpb25zIiBvciBhZGQgYSByZWZlcmVuY2U/DQoNClRoZSBm dW5jdGlvbnMgZGVmaW5lZCBpbiB0aGUgcHJlY2VkaW5nIHNlY3Rpb24uDQoNClNlY3Rpb24gNjoN Cj4gICAgbyAgVXNpbmcgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24gW1JGQzQ4 NjJdLiAgU0xBQUMgYWxsb3dzDQo+ICAgICAgIGhvc3RzIHRvIGNyZWF0ZSBnbG9iYWwgSVB2NiBh ZGRyZXNzZXMgb24gZGVtYW5kIGJ5IHNpbXBseSBmb3JtaW5nDQo+ICAgICAgIG5ldyBhZGRyZXNz ZXMgZnJvbSB0aGUgZ2xvYmFsIHByZWZpeCBhc3NpZ25lZCB0byB0aGUgbGluay4NCg0KVHJhZGl0 aW9uYWwgc2xhYWMgb25seSBhbGxvd3MgZm9yIGEgc2luZ2xlIHN0YWJsZSBhZGRyZXNzLCBzaW5j ZSB0aGUgYWRkcmVzcyBpcyBnZW5lcmF0ZWQgYnkgZW1iZWRkaW5nIHRoZSB1bmRlcmx5aW5nIG1h YyBhZGRyZXNzLg0KDQpUaGVyZSBhcmUgb3RoZXIgd2F5cyB0byBjb25maWd1cmUgc3RhYmxlIGFk ZHJlc3NlcyBhcyB3ZWxsLCBlLmcuLCBSRkM3MjE3LiBBbHNvLCB0aGlzIGRpc2N1c3Npb24gaXMg bm90IGxpbWl0ZWQgdG8gb25seSBzdGFibGUgYWRkcmVzc2VzLg0KW1dpbGxdIEkgc2VlLiBUaGVu IGl0IHdvdWxkIGJlIGdyZWF0IHRvIG5vdGUgdGhpcyBpbiB5b3VyIGRyYWZ0LCBhbmQgZS5nLiwg aW5jbHVkZSBhIHJlZmVyZW5jZSB0byBSRkM3MjE3Lg0KDQo+ICBJdCBpcyBhbHNvIHBvc3NpYmxl IGZvciBhIGNsaWVudCB0bw0KPiAgICAgICByZXF1ZXN0IGFkZGl0aW9uYWwgYWRkcmVzc2VzIHVz aW5nIGEgZGlmZmVyZW50IERVSUQuDQoNCldvdWxkIHRoaXMgcmVhbGx5IGNvbXBseSB3aXRoIHRo ZSBzcGlyaXQgb2YgREhDUHY2Pw0KDQpHb29kIHF1ZXN0aW9uLiBSRkMgMzMxNSBzZWN0aW9uIDkg aXMgbm90IGNsZWFyIG9uIHRoaXMuIE9uZSByZWFkaW5nIG9mIHRoYXQgc2VjdGlvbiBpcyB0aGF0 IGEgaG9zdCBjb3VsZCBydW4gbXVsdGlwbGUgImNsaWVudHMiLCBlYWNoIHdpdGggYSBkaWZmZXJl bnQgRFVJRC4gUmV3b3JkZWQgdG8gbm90ZSB0aGF0IHRoaXMgaXMgdGVjaG5pY2FsbHkgcG9zc2li bGUgYnV0IGxpa2VseSBub3QgZXhwZWN0ZWQgYmVoYXZpb3VyLg0KW1dpbGxdIEknbSBhIGxpdHRs ZSB1bnN1cmUgYWJvdXQgdGhpcy4gRm9yIGV4YW1wbGUsIHBhZ2UgMTkgc2VjdGlvbiA5IHNheXM6 DQogICAgIOKAnFRoZSBEVUlEIGlzDQogICBkZXNpZ25lZCB0byBiZSB1bmlxdWUgYWNyb3NzIGFs bCBESENQIGNsaWVudHMgYW5kIHNlcnZlcnMsIGFuZCBzdGFibGUNCiAgIGZvciBhbnkgc3BlY2lm aWMgY2xpZW50IG9yIHNlcnZlciAtIHRoYXQgaXMsIHRoZSBEVUlEIHVzZWQgYnkgYQ0KICAgY2xp ZW50IG9yIHNlcnZlciBTSE9VTEQgTk9UIGNoYW5nZSBvdmVyIHRpbWUgaWYgYXQgYWxsIHBvc3Np YmxlOyBmb3INCiAgICAgIGV4YW1wbGUsIGEgZGV2aWNlJ3MgRFVJRCBzaG91bGQgbm90IGNoYW5n ZSBhcyBhIHJlc3VsdCBvZiBhIGNoYW5nZSBpbg0KICAgICAgdGhlIGRldmljZSdzIG5ldHdvcmsg aGFyZHdhcmUu4oCdDQoNCkNvcnJlY3QgbWUgaWYgSeKAmW0gd3JvbmcsIElNSE8sIGhlcmUgc2Vl bXMgdG8gYXNzdW1lIHRoYXQgeW91IGdldCBvbmUgRFVJRCBwZXIgImRldmljZSI/DQoNCg0KPiBJ bW11bmUgdG8gbGF5ZXIgMyBvbi0gIHwgICAgTm8gICB8ICAgIFllcyAgICAgfCAgIFllcyAgIHwg ICBZZXMgICB8DQo+ICAgIHwgbGluayByZXNvdXJjZSAgICAgICAgICB8ICAgICAgICAgfCAgICAg ICAgICAgIHwgICAgICAgICB8ICAgICAgICAgfA0KPiAgICB8IGV4aGF1c3Rpb24gYXR0YWNrDQoN CldoYXQgZG8geW91IG1lYW4gYnkgIkltbXVuZSB0byBsYXllciAzIG9uLWxpbmsgcmVzb3VyY2Ug ZXhoYXVzdGlvbiBhdHRhY2siPw0KDQpJdCBtZWFucyB0aGF0IGEgY2xpZW50IGNhbm5vdCBwZXJm b3JtIGEgc3RhdGUgZXhoYXVzdGlvbiBhdHRhY2sgb24gdGhlIG5ldHdvcmsgYnksIGUuZy4sIGNv bmZpZ3VyaW5nIHRvbyBtYW55IElQIGFkZHJlc3Nlcy4gVGhhdCdzIGNvdmVyZWQgaW4gc2VjdGlv biA5LjMuDQpbV2lsbF0gSSB3b3VsZCBzdWdnZXN0IHRvIG1ha2UgdGhpcyBjbGFyaWZpZWQgc29t ZWhvdy4NCg0KUmVnYXJkcywNCldpbGwNCg== --_000_C9B5F12337F6F841B35C404CF0554ACB89571D56SZXEMA509MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhpIExvcmVuem8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBy ZXNwb25zZS4gUGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUgd2l0aCBbV2lsbF0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBDb2xpdHRp IFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks IFNlcHRlbWJlciAwMSwgMjAxNSA5OjIwIEFNPGJyPg0KPGI+VG86PC9iPiBMaXVzaHVjaGVuZyAo V2lsbCk8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtdjZvcHMtaG9zdC1hZGRyLWF2YWlsYWJp bGl0eUB0b29scy5pZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt2Nm9wc10gUmV2aWV3IGZvciBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFi aWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5XaWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+dGhhbmtzIGZvciB0aGUgcmV2aWV3LiBDb21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIEF1ZyAyOCwgMjAxNSBh dCAxMjo1MSBQTSwgTGl1c2h1Y2hlbmcgKFdpbGwpICZsdDs8YSBocmVmPSJtYWlsdG86bGl1c2h1 Y2hlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpdXNodWNoZW5nQGh1YXdlaS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsgJm5ic3A7QXNzaWdu aW5nIGEgbGltaXRlZCBudW1iZXIgb2YgYWRkcmVzc2VzIHBlciBob3N0IGltcGxpZXMgdGhhdDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ZnVuY3Rpb25zIHRoYXQgcmVxdWlyZSBtdWx0aXBsZSBhZGRy ZXNzZXMgd2lsbCBlaXRoZXIgYmUgdW5hdmFpbGFibGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyhl LmcuLCBpZiB0aGUgbmV0d29yayBwcm92aWRlcyBvbmx5IG9uZSBJUHY2IGFkZHJlc3MgcGVyIGhv c3QsIG9yIGlmPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDt0aGUgaG9zdCBoYXMgcmVhY2hlZCB0aGUg bGltaXQgb2YgdGhlIG51bWJlciBvZiBhZGRyZXNzZXMgYXZhaWxhYmxlKSw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwO29yIHRoYXQgdGhlIGZ1bmN0aW9ucyB3aWxsIG9ubHkgYmUgYXZhaWxhYmxlIGFm dGVyIGFuIGV4cGxpY2l0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtyZXF1ZXN0IHRvIHRoZSBuZXR3 b3JrIGlzIGdyYW50ZWQuJm5ic3A7IFRoZSBuZWNlc3NpdHkgb2YgZXhwbGljaXQ8YnI+DQo8YnI+ DQpDb3VsZCB5b3UgZXhwbGljaXRseSBwb2ludCBvdXQgd2hpY2ggJnF1b3Q7ZnVuY3Rpb25zJnF1 b3Q7IG9yIGFkZCBhIHJlZmVyZW5jZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZnVuY3Rpb25zIGRlZmluZWQgaW4gdGhlIHByZWNl ZGluZyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+U2VjdGlvbiA2Ojxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG8mbmJzcDsgVXNp bmcgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24gW1JGQzQ4NjJdLiZuYnNwOyBT TEFBQyBhbGxvd3M8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aG9zdHMgdG8g Y3JlYXRlIGdsb2JhbCBJUHY2IGFkZHJlc3NlcyBvbiBkZW1hbmQgYnkgc2ltcGx5IGZvcm1pbmc8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmV3IGFkZHJlc3NlcyBmcm9tIHRo ZSBnbG9iYWwgcHJlZml4IGFzc2lnbmVkIHRvIHRoZSBsaW5rLjxicj4NCjxicj4NClRyYWRpdGlv bmFsIHNsYWFjIG9ubHkgYWxsb3dzIGZvciBhIHNpbmdsZSBzdGFibGUgYWRkcmVzcywgc2luY2Ug dGhlIGFkZHJlc3MgaXMgZ2VuZXJhdGVkIGJ5IGVtYmVkZGluZyB0aGUgdW5kZXJseWluZyBtYWMg YWRkcmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGVyZSBhcmUgb3RoZXIgd2F5cyB0byBjb25maWd1cmUgc3RhYmxlIGFkZHJlc3Nl cyBhcyB3ZWxsLCBlLmcuLCBSRkM3MjE3LiBBbHNvLCB0aGlzIGRpc2N1c3Npb24gaXMgbm90IGxp bWl0ZWQgdG8gb25seSBzdGFibGUgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+W1dpbGxdIEkgc2VlLiBUaGVuIGl0IHdvdWxkIGJlIGdyZWF0IHRvIG5vdGUg dGhpcyBpbiB5b3VyIGRyYWZ0LCBhbmQgZS5nLiwgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBSRkM3 MjE3Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mZ3Q7Jm5ic3A7IEl0IGlzIGFsc28gcG9zc2libGUgZm9yIGEgY2xpZW50IHRvPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlcXVlc3QgYWRkaXRpb25hbCBhZGRyZXNz ZXMgdXNpbmcgYSBkaWZmZXJlbnQgRFVJRC48YnI+DQo8YnI+DQpXb3VsZCB0aGlzIHJlYWxseSBj b21wbHkgd2l0aCB0aGUgc3Bpcml0IG9mIERIQ1B2Nj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Hb29kIHF1ZXN0aW9uLiBSRkMgMzMxNSBz ZWN0aW9uIDkgaXMgbm90IGNsZWFyIG9uIHRoaXMuIE9uZSByZWFkaW5nIG9mIHRoYXQgc2VjdGlv biBpcyB0aGF0IGEgaG9zdCBjb3VsZCBydW4gbXVsdGlwbGUgJnF1b3Q7Y2xpZW50cyZxdW90Oywg ZWFjaCB3aXRoIGEgZGlmZmVyZW50IERVSUQuIFJld29yZGVkIHRvIG5vdGUmbmJzcDt0aGF0IHRo aXMgaXMgdGVjaG5pY2FsbHkgcG9zc2libGUgYnV0IGxpa2VseQ0KIG5vdCBleHBlY3RlZCBiZWhh dmlvdXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjUuNXB0Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPltXaWxsXSBJJ20gYSBsaXR0bGUgdW5zdXJlIGFib3V0IHRoaXMuIEZvciBl eGFtcGxlLCBwYWdlIDE5IHNlY3Rpb24gOSBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjExLjBwdCI+PGI+ PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsg4oCcVGhlIERVSUQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMS4wcHQiPjxiPjxp PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IGRlc2lnbmVkIHRvIGJlIHVuaXF1ZSBhY3Jvc3MgYWxsIERIQ1AgY2xpZW50cyBhbmQgc2VydmVy cywgYW5kIHN0YWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjExLjBwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZm9yIGFueSBzcGVjaWZp YyBjbGllbnQgb3Igc2VydmVyIC0gdGhhdCBpcywgdGhlIERVSUQgdXNlZCBieSBhPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NS41cHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IGNsaWVudCBvciBzZXJ2ZXIgU0hPVUxEIE5PVCBjaGFuZ2Ugb3Zl ciB0aW1lIGlmIGF0IGFsbCBwb3NzaWJsZTsgZm9yPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS41cHQiPjxiPjxp PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4YW1wbGUsIGEgZGV2aWNlJ3MgRFVJRCBzaG91bGQgbm90IGNo YW5nZSBhcyBhIHJlc3VsdCBvZiBhIGNoYW5nZSBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuNXB0Ij48Yj48 aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZGV2aWNlJ3MgbmV0d29yayBoYXJkd2FyZS7igJ08bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo1LjVwdCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Q29ycmVjdCBtZSBpZiBJ4oCZbSB3cm9uZywgSU1ITywgaGVyZSBzZWVtcyB0byBhc3N1 bWUgdGhhdCB5b3UgZ2V0IG9uZSBEVUlEIHBlciAmcXVvdDtkZXZpY2UmcXVvdDs/PC9zcGFuPjwv aT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCiZn dDsgSW1tdW5lIHRvIGxheWVyIDMgb24tJm5ic3A7IHwmbmJzcDsgJm5ic3A7IE5vJm5ic3A7ICZu YnNwO3wmbmJzcDsgJm5ic3A7IFllcyZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDtZ ZXMmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDtZZXMmbmJzcDsgJm5ic3A7fDxicj4NCiZndDsm bmJzcDsgJm5ic3A7IHwgbGluayByZXNvdXJjZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyB8IGV4aGF1c3Rpb24gYXR0YWNrPGJyPg0KPGJyPg0KV2hhdCBkbyB5b3UgbWVhbiBi eSAmcXVvdDtJbW11bmUgdG8gbGF5ZXIgMyBvbi1saW5rIHJlc291cmNlIGV4aGF1c3Rpb24gYXR0 YWNrJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkl0IG1lYW5zIHRoYXQgYSBjbGllbnQgY2Fubm90IHBlcmZvcm0gYSBzdGF0ZSBl eGhhdXN0aW9uIGF0dGFjayBvbiB0aGUgbmV0d29yayBieSwgZS5nLiwgY29uZmlndXJpbmcgdG9v IG1hbnkgSVAgYWRkcmVzc2VzLiBUaGF0J3MgY292ZXJlZCBpbiBzZWN0aW9uIDkuMy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltXaWxsXSBJIHdvdWxkIHN1Z2dlc3QgdG8g bWFrZSB0aGlzIGNsYXJpZmllZCBzb21laG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5XaWxsPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C9B5F12337F6F841B35C404CF0554ACB89571D56SZXEMA509MBSchi_-- From nobody Wed Sep 9 08:02:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAB11B33FD for ; Tue, 8 Sep 2015 09:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ETpreDH99yL for ; Tue, 8 Sep 2015 09:18:15 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229871B321F for ; Tue, 8 Sep 2015 09:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2647; q=dns/txt; s=iport; t=1441729094; x=1442938694; h=from:to:cc:subject:date:message-id:mime-version; bh=bV6YVoQ/cB9QHxhiR0qlahx8EwgdlmzU/08qSO8qpJE=; b=Mact2J868r1KUMkC1H0lyhr/pLrKTJzVnqykdTt3e3gAmOslCCxCLmHF /UZBLBFDmlZVDEpA8CdpD94h+463wbeqhb9by2QJESw5k5cAml8nNKp6A lQlojb+95gOthUHUa+uAflqCxrwMtYLOIOAOUCn/m+zHdM65x4ogHqjEN I=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSAwCaCe9V/4sNJK1dgyNUb70kCoF3hXmBODgUAQEBAQEBAYEKhCYEeRIBgQAnBA4TiCANyy4BAQEBAQEBAQEBAQEBAQEBAQEWBIkCh3iDH4EUBZVVAYJCgV1qh3CadyaEAIg1gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,490,1437436800"; d="asc'?scan'208";a="186043407" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 08 Sep 2015 16:18:13 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t88GICGv031908 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Sep 2015 16:18:13 GMT Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Sep 2015 11:18:11 -0500 Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 8 Sep 2015 11:18:11 -0500 Received: from xmb-rcd-x09.cisco.com ([169.254.9.173]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Tue, 8 Sep 2015 11:18:11 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: draft-sivakumar-yang-nat-01.txt) Thread-Index: AQHQ6lH0XgsZU/ervEy/nj9OfpvGuA== Date: Tue, 8 Sep 2015 16:18:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.20] Content-Type: multipart/signed; boundary="Apple-Mail=_8AE5D854-5BBE-4BF5-AC22-5C3E0C4FBE54"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 09 Sep 2015 08:01:59 -0700 Cc: "simon.perreault@viagenie.ca" , "cliffwang2000@yahoo.com" , "draft-sivakumar-yang-nat@tools.ietf.org" , "raraghun@cisco.com" , "srisuresh@yahoo.com" , "rrohit74@hotmail.com" , Immo Wehrenberg , "npai@cisco.com" Subject: [v6ops] draft-sivakumar-yang-nat-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 16:18:16 -0000 --Apple-Mail=_8AE5D854-5BBE-4BF5-AC22-5C3E0C4FBE54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors of draft-sivakumar-yang-nat are looking for a home for it. = This is a YANG management model for NATs, including NAT64, NPTv6, and = other variants. In the revised charter filed with the IESG, this would be most similar = to the third issue, which is a catch-all. It fits if we say that it = fits. https://datatracker.ietf.org/doc/charter-ietf-v6ops/. There may = also be other options; I am specifically asking the sunset4 chairs = whether it fits there, and one wonders about int-area. The obvious = working groups, behave and softwire, are closed or closing. My question for the moment is a simple one: many of us are looking at = YANG as a network management model; would a YANG model for a translator = be useful to those operating 464XLAT, SIIT-DC, MAP-T/E, or other = networks that target IPv6 operation and require translation of some = type? If so, would this be a useful starting point, and would this = working group be an appropriate place to discuss it? I have copied the = authors of network management efforts related to NAT and some operators = I know are using it. If in answering the question anyone were to review the document and = compare it to RFC 4008 or other models for information and structure to = be modeled, I imagine the authors would appreciate that. --Apple-Mail=_8AE5D854-5BBE-4BF5-AC22-5C3E0C4FBE54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVe8KREayAOS/EQ8MAQKnsxAAtr02F6ezPx8ZjqjJoRo0zXhdpYzyJU2F 1dLyRhky0T88Q0e2ASR+hL/5mQYxwDxGhnXtg/uNONgVzt1BAWjmJorOptdu/46D d/gkNcILB16+tlpqzleYGB2v+54/lYh6p6edfYQz1jTRVFUY6JV0mfNTTPEsMrSf 0W2SXdHUpGCv5QZ3t6c9nTCaP7AuyjMbLLNy2IB7yj7Bh4zM6k428nCW8bPnLFx1 7p6J/xyO6rw4E62lY9ooe0+Jl0o4KtJTGmb+/z8NcsVhyOyF9FSmyu222Wi5YxwD 3XwSwOSarisUqQNkDb4ZZA42mcyE0eMN3SnJ7JWJU379zZHW9VinpwIk4l03PjbN IWMeRvHZOFT5SB/qGqBXElfIWZ65NhyTachD4+3n8erfF03OmHt+VpDT2zhYZc2R lW6Y5+Ih+YmQZec7RvX595ymDZ/gS/Eguwly3UnXEaYDaHLRjpKV683MksG89Z1v XI/Z3fqdHzW6ochbRt/3WI172l+XbOYEulvOVT4fVgL7IZKdi5j1w8IlQOJqd0a4 gkmWCpCxDtwLQkNl0RGma6x3jtyXlqkkoZjAqjIOw04PuuxU5Lj6ZBedPl1161Dt rG9SIqz7Mcld2O83cKPQr7pwFnCObsM2btdYp9c2Z4eBL5iW3boTTHQYzIRURhN5 GKn3bl5lJvg= =7yas -----END PGP SIGNATURE----- --Apple-Mail=_8AE5D854-5BBE-4BF5-AC22-5C3E0C4FBE54-- From nobody Sun Sep 13 11:00:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A01B4602 for ; Sun, 13 Sep 2015 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.612 X-Spam-Level: X-Spam-Status: No, score=-112.612 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T2UsLirkQVs for ; Sun, 13 Sep 2015 11:00:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FA51A899D for ; Sun, 13 Sep 2015 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=636; q=dns/txt; s=iport; t=1442167205; x=1443376805; h=date:from:message-id:to:subject:cc; bh=mS12KjShGnTiRnpO3yYdoejEunxpjhBbj24GoWoGHnE=; b=NqacIVSplZkzB4JmdJDtb6hp+dOCx5IIMFLLz6wKt/jlMLKAE+vS7lG4 i1DmC/fPaUKoxd/20VyNi+3+NKqylGEfeQh6XjV9TEFrfcjJN1h/FZZxg YdW2zxNgExQe3NJfPzpNhTaPuW0YOk8ND8AgNg2YUJzLZX7UThROD6yk8 M=; X-IronPort-AV: E=Sophos;i="5.17,523,1437436800"; d="scan'208";a="32046335" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 13 Sep 2015 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t8DI03qj007799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Sep 2015 18:00:04 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t8DI03Tq026653; Sun, 13 Sep 2015 11:00:03 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t8DI03cc026651; Sun, 13 Sep 2015 11:00:03 -0700 Date: Sun, 13 Sep 2015 11:00:03 -0700 From: fred@cisco.com Message-Id: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 18:00:06 -0000 This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. From nobody Sun Sep 13 13:43:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898751B30AE; Sun, 13 Sep 2015 13:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QEqXshHrJfJ; Sun, 13 Sep 2015 13:43:32 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F94C1B2F73; Sun, 13 Sep 2015 13:43:32 -0700 (PDT) Received: by pacex6 with SMTP id ex6so123045106pac.0; Sun, 13 Sep 2015 13:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=X3xhtMMIUNgh3pwZBN2RYf3ohPQfRSTkxIql2Xxw8Kw=; b=HPxx5zfGNg8YgfjKxU+X/d+LPrAmlNwUbInnSXQXIEImMJmhyX2uyAgS9m0GblzfJ4 ccPqrAXiXbfCahMlc7J3TbhYBP7Nhx/14jCvPyOhIuYwtfqvYFU8ujFnhJK094vBNVx7 TAfScJBXF/Og0MzGkCfkor/T6D7DYkoITyqUPi1LZfv6x1Lmj/CMz68RPLJm3BYoFsIV F9IqQjZ70B77IBeWj+JYd86sKWbPG51NgSU+ayshvGNjENC4rpgnuhLp6XMixErePXeY e/ItzHqOSFFfhQ/3mxSInzvkZGsrawNWMrwpQEbpbBJO7f1Oz7aY1+g9KhAt2Y2VfBOO XeUQ== X-Received: by 10.68.196.233 with SMTP id ip9mr26505687pbc.139.1442177011734; Sun, 13 Sep 2015 13:43:31 -0700 (PDT) Received: from [192.168.178.25] (38.224.69.111.dynamic.snap.net.nz. [111.69.224.38]) by smtp.gmail.com with ESMTPSA id xi1sm11924348pac.48.2015.09.13.13.43.29 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Sep 2015 13:43:30 -0700 (PDT) To: IPv6 Operations References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55F5DFEA.8010409@gmail.com> Date: Mon, 14 Sep 2015 08:43:22 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-v6ops-host-addr-availability@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 20:43:33 -0000 I believe this document is important and should go forward. Small issues: 1) Neither the title nor the Abstract mentions IPv6 specifically. 2) In the Introduction: > In IPv6, each link has a > virtually unlimited amount of address space [RFC7421]. I suggest making that reference specifically to section 3.1 of RFC7421. It's a long RFC. 3) Section 8 still says > Assigning prefixes smaller than a /64 ... and "smaller" is still confusing. (Also, this would be the place for a more general reference to RFC7421, which discusses at length the issues caused by prefixes longer than /64.) 4) > 9.1. Stateful addressing and host tracking I thinking that "auditing" is a better word than "tracking" throughout this section. (This is another topic that is also discussed in RFC7421.) Regards Brian From nobody Sun Sep 13 22:53:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938011B5917; Sun, 13 Sep 2015 22:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s8jVDnLFZCz; Sun, 13 Sep 2015 22:53:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C1F1B3430; Sun, 13 Sep 2015 22:53:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914055336.29506.81240.idtracker@ietfa.amsl.com> Date: Sun, 13 Sep 2015 22:53:36 -0700 Archived-At: Cc: Joel Jaeggli , Fred Baker , v6ops@ietf.org Subject: [v6ops] Joel Jaeggli's Yes on charter-ietf-v6ops-03-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 05:53:37 -0000 Joel Jaeggli has entered the following ballot position for charter-ietf-v6ops-03-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ There are no remarks associated with this position. From nobody Mon Sep 14 18:06:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EA71B3EE6; Mon, 14 Sep 2015 18:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz9c44Xi3vts; Mon, 14 Sep 2015 18:06:21 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF51A1B3E71; Mon, 14 Sep 2015 18:06:20 -0700 (PDT) Received: from [181.46.190.53] (helo=[172.16.17.13]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZbegK-0007hN-RD; Tue, 15 Sep 2015 03:05:13 +0200 References: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 To: opsawg@ietf.org X-Forwarded-Message-Id: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> Message-ID: <55F76EA7.6090405@si6networks.com> Date: Mon, 14 Sep 2015 22:04:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Internet Area , "'opsec@ietf.org'" , TSV Area , tsvwg , IPv6 Operations Subject: [v6ops] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 01:06:23 -0000 Folks, We have published an I-D entitled "On Firewalls in Internet Security". The I-D is available at: . Our I-D covers a broad range of topics (ranging from operations to internet and transport area topics) -- hence the crosspost of this announcement to multiple mailing-lists. While we (co-authors) are subscribed to most of the lists to which this announcement is being crossposted, we expect (for the sake of unifying the discussion in a single place) the discussion to happen in the opsawg@ietf.org mailing-list. Your feedback will be very welcome. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt Date: Mon, 14 Sep 2015 17:49:41 -0700 From: internet-drafts@ietf.org To: Paul E. Hoffman , Fernando Gont , Fernando Gont , Fred Baker , Fred Baker , Paul Hoffman A new version of I-D, draft-gont-opsawg-firewalls-analysis-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsawg-firewalls-analysis Revision: 00 Title: On Firewalls in Internet Security Document date: 2015-09-15 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-gont-opsawg-firewalls-analysis-00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsawg-firewalls-analysis/ Htmlized: https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-00 Abstract: This document analyzes the role of firewalls in Internet security, and suggests a line of reasoning about their usage. It analyzes common kinds of firewalls and the claims made for them. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Sep 15 05:54:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251B51B3F0B for ; Tue, 15 Sep 2015 05:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5h6BhSDMk_Y for ; Tue, 15 Sep 2015 05:54:23 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB701B34E8 for ; Tue, 15 Sep 2015 05:54:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8FCsLoF013129 for ; Tue, 15 Sep 2015 14:54:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E36882068C9 for ; Tue, 15 Sep 2015 14:59:10 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D06FA2068B1 for ; Tue, 15 Sep 2015 14:59:10 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8FCsJx6006769 for ; Tue, 15 Sep 2015 14:54:20 +0200 To: v6ops@ietf.org References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Alexandru Petrescu Message-ID: <55F814FB.5030003@gmail.com> Date: Tue, 15 Sep 2015 14:54:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 12:54:25 -0000 I disagree with the following statements: > If the network requires explicit requests > for address space (e.g., if it requires DHCPv6 to connect), it is > RECOMMENDED that the network assign a /64 prefix to every host (e.g., > via DHCPv6 PD). That should be a /63, not a /64. Please dont make this draft yet another hardcoding of 64. Alex Le 13/09/2015 20:00, fred@cisco.com a écrit : > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 15 05:59:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247FC1B446A for ; Tue, 15 Sep 2015 05:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xICqsSExlppL for ; Tue, 15 Sep 2015 05:59:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9831B4461 for ; Tue, 15 Sep 2015 05:59:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8FCxOxP026768 for ; Tue, 15 Sep 2015 14:59:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 062D0206842 for ; Tue, 15 Sep 2015 15:04:14 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F139C200800 for ; Tue, 15 Sep 2015 15:04:13 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8FCxN5q026028 for ; Tue, 15 Sep 2015 14:59:23 +0200 To: v6ops@ietf.org References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Alexandru Petrescu Message-ID: <55F8162B.4030905@gmail.com> Date: Tue, 15 Sep 2015 14:59:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] finer-grain Extend the Network (was: draft-ietf-v6ops-host-addr-availability WGLC - two-stage) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 12:59:29 -0000 On table 1: > +--------------------------+-------+-------------+--------+---------+ > | | SLAAC | DHCPv6 | DHCPv6 | DHCPv4 | > | | | IA_NA / | PD | | > | | | IA_TA | | | > +--------------------------+-------+-------------+--------+---------+ > | Extend network | Yes | No | Yes | Yes | > | | | | | (NAT44) | > | "Unlimited" endpoints | Yes* | Yes* | No | No | > | Stateful, request-based | No | Yes | Yes | Yes | > | Immune to layer 3 on- | No | Yes | Yes | Yes | > | link resource exhaustion | | | | | > | attacks | | | | | > +--------------------------+-------+-------------+--------+---------+ SLAAC can indeed extend the network when 64share is used. But only to a certain extent - i.e. only one more subnet. DHCPv6 PD can also extend the network but to more than just one subnet. In that sense, SLAAC extends the network with a "Yes, hm" whereas DHCPv6-PD is a "YES!". Alex Le 13/09/2015 20:00, fred@cisco.com a écrit : > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 15 11:38:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F041A90E7 for ; Tue, 15 Sep 2015 11:38:15 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mQotpz2rDP9 for ; Tue, 15 Sep 2015 11:38:13 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7982E1A90C3 for ; Tue, 15 Sep 2015 11:38:13 -0700 (PDT) Received: by padhy16 with SMTP id hy16so183722704pad.1 for ; Tue, 15 Sep 2015 11:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zZ9YfVI8iMWqeDrCndy4qevWQMbzLO/dntjZQzZXyT8=; b=d99iL7q5128M/RcQu9QOoZfFQUmMN0VwKxIXhL/qPtWybY7F+NBaBfO/d6cpgd19u2 OTG6AcIewNDa1n+9R6Oi96ej7sTk1dMhPDGU2KhAuXRXnYIqkUyEXh7clYJbqvkZyQn6 5asA4yi6zd8oaXLQA/U4bQV5Hs0oXPIL/1rDE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zZ9YfVI8iMWqeDrCndy4qevWQMbzLO/dntjZQzZXyT8=; b=b9xECQwZLyyO+Yerp5M9NPOLcGLXtiisisuPbHqDTahMWcT/5ikcaGgAtGdNmzNurT mGO2qYlIU9SlzjSQVpDSkA+yFVTEXG6551pdylrhmAs+o0HSAMoXKe/23Zf/F06Yxkz8 hP3MXmTjon1TDOJCEVBOzHj07ne0Pkd0J7DbPT9tKa45B81zflW4Y3vbGFDlXmkRGCkH mhi776mbNMndJ0ta3AtetK7u27YwrajnbG4xOuBq9DohpDYUHxERuAU9VjHlpzDMMw9A iuZbnOWw8dm6z3OBIH5RkjFzdCTwLmRPzWOsuEhI1NWyPi7vjqnB8MfUCad1vi6EqxQH ND3w== X-Gm-Message-State: ALoCoQnHMLPzOIywBptSt/gNsZztPQtEKYb7RCe0YXBDTCwI87ykoStxLWAWdKEWizmkzYCGndwf X-Received: by 10.67.30.74 with SMTP id kc10mr49205615pad.147.1442342293095; Tue, 15 Sep 2015 11:38:13 -0700 (PDT) Received: from dhcp-100-96-162-236.pao.corp.google.com ([100.96.162.236]) by smtp.gmail.com with ESMTPSA id j16sm23413624pbq.23.2015.09.15.11.38.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Sep 2015 11:38:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: james woodyatt In-Reply-To: <55F76EA7.6090405@si6networks.com> Date: Tue, 15 Sep 2015 11:38:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0F1D70B7-63D3-4414-B73A-9A5FA1A76B0C@nestlabs.com> References: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> <55F76EA7.6090405@si6networks.com> To: draft-gont-apsawg-firewalls-analysis@tools.ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 18:38:15 -0000 On Sep 14, 2015, at 18:04, Fernando Gont wrote: >=20 > [=E2=80=A6] While we (co-authors) are subscribed to most of the lists = to which this > announcement is being crossposted, we expect (for the sake of unifying > the discussion in a single place) the discussion to happen in the > opsawg@ietf.org mailing-list. I can=E2=80=99t subscribe to the opsawg list. Here=E2=80=99s my = feedback. =E2=80=94 There are many things I don=E2=80=99t like about the style of = this draft, but I shall confine my feedback to constructive technical = criticisms. In particular, there is one criticism leveled at the end of = this message, which has me quite exercised, so please read that one if = you read nothing else. =E2=80=94 Section 2, Terminology: "All modern firewalls allow an = administrator to change the policies in the firewall=E2=80=9D is not = true. There is an important and very common exception: RFC 6092 = residential gateways simple security firewalls, which makes no = recommendation allowing administrators to change policies. =E2=80=94 Section 3.3, Building a communication: "Attacks on = infrastructure occur when message volume overwhelms infrastructure or = uses infrastructure but has no obvious receiver.=E2=80=9D Normal = communications are possible when one or both of the sender and receiver = are not obviously identifiable to a third part, including the network = operator. I hope I don=E2=80=99t need to defend that assertion to the = authors of this draft. Recommend: =E2=80=9C=E2=80=A6uses infrastructure = but has no authorized receiver." =E2=80=94 continuing=E2=80=A6 "to drop traffic sent by an unauthorized = or inappropriate sender or which has no host or application willing to = receive it as close as possible to the sender=E2=80=9D is problematic. = Recommend: =E2=80=9Cto drop traffic with no authorized sender or = receiver.=E2=80=9D =E2=80=94 On the topic of authorized senders and receivers=E2=80=A6 It = may be worth pointing out that some firewalls, e.g. Context or = Zone-based Firewalls, operate on the principle that hosts inside a = protected perimeter are authorized by solely virtue of their network = location to send and receive, by default with exceptional policies = applied to deny sending and receiving to specifically identified hosts. =E2=80=94 Section 4.3, Intrusion Management. "Reputation databases have = a bad reputation for distributing information which is incorrect or out = of date=E2=80=A6=E2=80=9D or compromised by attackers. =E2=80=94 Section 10, Recommedations. "Zone-based firewalls, when used, = SHOULD exclude all session initiation from outside the zone regardless = of attributes such as the use of IPsec. They SHOULD also facilitate the = use of a protocol such as PCP by hosts to identify traffic (IPsec AH, = IPsec ESP, transports in general, or transports using specified = destination port ranges) that they are willing to receive, and interpret = that into rules permitting specified traffic to those specific = systems.=E2=80=9D >>>> Wait, WHAT? Where was the discussion in this draft about making = firewalls break IPsec? This would be a major walk-back on the discussion = of IPsec and Internet Key Exchange in section 3.2.4 of RFC 6092, which = we arrived at by a long and arduous discussion in V6OPS. We expressly = carved out an exception for IPsec in simple security because it is = understood that protecting hosts with a zone-based firewall shouldn=E2=80=99= t prevent them from taking responsibility for their own end-to-end = network security by using IPsec and Internet Key Exchange. What happened = to make us change our minds about that? =E2=80=94james= From nobody Tue Sep 15 15:06:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3A51B2BA2 for ; Tue, 15 Sep 2015 15:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO633GSxaRLv for ; Tue, 15 Sep 2015 15:06:14 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C0F1B2BA6 for ; Tue, 15 Sep 2015 15:06:13 -0700 (PDT) Received: by igbni9 with SMTP id ni9so21579801igb.0 for ; Tue, 15 Sep 2015 15:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QstYGK+js/OhJyCqPMQFcPqVKQZ0IAMmbs/BtbHJJqQ=; b=vJnEtzEfmwi1DMHv7T+5YokiTIyQ60VG7zug/0aAMFNefOGxLhJ92aGwWLFN95qEQe 5+HY4mbJMMSSSSMHucpZUiNIosiOjiyLOdmCl55/YJnLAoxoa6V7KJI6cPRe4iUK3pBF orggKJ1C3q3ZEVAKV9eRW7J4GfV0V5/gZukrCGas/lY1YluBUIrqIFRHBLeEOxS+Vtuj /wP8VxbajhaO2+mk24SWFcMMJqZP15P7ejPEW23bm7skUQDz50zZMrlwFvhyTIUa93pV hQo3KfllVWjKWhRNB9ABrZfkwx0+LhUtLKBSCbENFBlbw62jTEE3/TafFcJ92goNXZ0A lm6w== MIME-Version: 1.0 X-Received: by 10.50.50.240 with SMTP id f16mr10370309igo.95.1442354773243; Tue, 15 Sep 2015 15:06:13 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Tue, 15 Sep 2015 15:06:13 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Tue, 15 Sep 2015 15:06:13 -0700 (PDT) In-Reply-To: <55F814FB.5030003@gmail.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> Date: Wed, 16 Sep 2015 08:06:13 +1000 Message-ID: From: Mark Smith To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7bd76c00e6418e051fd06313 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:06:15 -0000 --047d7bd76c00e6418e051fd06313 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 Sep 2015 22:55, "Alexandru Petrescu" wrote: > > I disagree with the following statements: >> >> If the network requires explicit requests >> for address space (e.g., if it requires DHCPv6 to connect), it is >> RECOMMENDED that the network assign a /64 prefix to every host (e.g., >> via DHCPv6 PD). > > > That should be a /63, not a /64. > Can you explain further why? > Please dont make this draft yet another hardcoding of 64. > RECOMMENDED is not a MUST. > Alex > > > > Le 13/09/2015 20:00, fred@cisco.com a =C3=A9crit : >> >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. >> Please read it now. If you find nits (spelling errors, minor suggested >> wording changes, etc), comment to the authors; if you find greater >> issues, such as disagreeing with a statement or finding additional >> issues that need to be addressed, please post your comments to the >> list. >> >> We are looking specifically for comments on the importance of the >> document as well as its content. If you have read the document and >> believe it to be of operational utility, that is also an important >> comment to make. >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7bd76c00e6418e051fd06313 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 15 Sep 2015 22:55, "Alexandru Petrescu" <alexandru.petrescu@gmail.com> wrote: >
> I disagree with the following statements:
>>
>> If the network requires explicit requests
>> =C2=A0 =C2=A0for address space (e.g., if it requires DHCPv6 to con= nect), it is
>> =C2=A0 =C2=A0RECOMMENDED that the network assign a /64 prefix to e= very host (e.g.,
>> =C2=A0 =C2=A0via DHCPv6 PD).
>
>
> That should be a /63, not a /64.
>

Can you explain further why?

> Please dont make this draft yet another hardcoding of 6= 4.
>

RECOMMENDED is not a MUST.

> Alex
>
>
>
> Le 13/09/2015 20:00, fred@cisco.com<= /a> a =C3=A9crit :
>>
>> This is to initiate a two week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availabi= lity.
>> Please read it now. If you find nits (spelling errors, minor sugge= sted
>> wording changes, etc), comment to the authors; if you find greater=
>> issues, such as disagreeing with a statement or finding additional=
>> issues that need to be addressed, please post your comments to the=
>> list.
>>
>> We are looking specifically for comments on the importance of the<= br> >> document as well as its content. If you have read the document and=
>> believe it to be of operational utility, that is also an important=
>> comment to make.
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7bd76c00e6418e051fd06313-- From nobody Tue Sep 15 17:21:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F61B2F38 for ; Tue, 15 Sep 2015 17:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7M8Eoa7YnNC for ; Tue, 15 Sep 2015 17:21:49 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBA81B2F34 for ; Tue, 15 Sep 2015 17:21:49 -0700 (PDT) Received: from [179.40.181.238] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Zc0Sn-0008Hq-UN; Wed, 16 Sep 2015 02:20:42 +0200 From: Fernando Gont To: james woodyatt , draft-gont-opsawg-firewalls-analysis@tools.ietf.org References: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> <55F76EA7.6090405@si6networks.com> <0F1D70B7-63D3-4414-B73A-9A5FA1A76B0C@nestlabs.com> X-Enigmail-Draft-Status: N1110 Message-ID: <55F8AAB1.2010406@si6networks.com> Date: Tue, 15 Sep 2015 20:33:05 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0F1D70B7-63D3-4414-B73A-9A5FA1A76B0C@nestlabs.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 00:21:51 -0000 Hi, James, Thanks so much for ou feedback! -- Please ind my comments in-line.... On 09/15/2015 03:38 PM, james woodyatt wrote: > On Sep 14, 2015, at 18:04, Fernando Gont > wrote: >> >> [
] While we (co-authors) are subscribed to most of the lists to >> which this announcement is being crossposted, we expect (for the >> sake of unifying the discussion in a single place) the discussion >> to happen in the opsawg@ietf.org mailing-list. > > I can’t subscribe to the opsawg list. Here’s my feedback. > > — There are many things I don’t like about the style of this draft, > but I shall confine my feedback to constructive technical criticisms. > In particular, there is one criticism leveled at the end of this > message, which has me quite exercised, so please read that one if you > read nothing else. FWIW, I'll read all :-) > — Section 2, Terminology: "All modern firewalls allow an > administrator to change the policies in the firewall” is not true. > There is an important and very common exception: RFC 6092 residential > gateways simple security firewalls, which makes no recommendation > allowing administrators to change policies. That doesn't necessarily invalidate our claim: do you know of any firewall that does not allow the fw policies to be changed? In any case, would s/all/most/ address your concern? > — Section 3.3, Building a communication: "Attacks on infrastructure > occur when message volume overwhelms infrastructure or uses > infrastructure but has no obvious receiver.” Normal communications > are possible when one or both of the sender and receiver are not > obviously identifiable to a third part, including the network > operator. Not sure what you mean by "normal communications"... In the ase of a DoS scenario, that's certainly not true. > I hope I don’t need to defend that assertion to the authors > of this draft. Recommend: “
uses infrastructure but has no authorized > receiver." The term authorization tends to have a specific meaning which I'm not sure it's applicable here. > — continuing
 "to drop traffic sent by an unauthorized or > inappropriate sender or which has no host or application willing to > receive it as close as possible to the sender” is problematic. > Recommend: “to drop traffic with no authorized sender or receiver.” So: please define "authorized". > — On the topic of authorized senders and receivers
 It may be worth > pointing out that some firewalls, e.g. Context or Zone-based > Firewalls, operate on the principle that hosts inside a protected > perimeter are authorized by solely virtue of their network location > to send and receive, by default with exceptional policies applied to > deny sending and receiving to specifically identified hosts. Will do. > — Section 4.3, Intrusion Management. "Reputation databases have a bad > reputation for distributing information which is incorrect or out of > date
” or compromised by attackers. Will add this. Thanks! > — Section 10, Recommedations. "Zone-based firewalls, when used, > SHOULD exclude all session initiation from outside the zone > regardless of attributes such as the use of IPsec. They SHOULD also > facilitate the use of a protocol such as PCP by hosts to identify > traffic (IPsec AH, IPsec ESP, transports in general, or transports > using specified destination port ranges) that they are willing to > receive, and interpret that into rules permitting specified traffic > to those specific systems.” > >>>>> Wait, WHAT? Where was the discussion in this draft about >>>>> making firewalls break IPsec? This has nothing to do with breaking IPsec. The fact that a flow is authenticated doesn't mean, per se, that you have to let the traffic through. -- that's all this I-D is saying. >>>>> This would be a major walk-back >>>>> on the discussion of IPsec and Internet Key Exchange in >>>>> section 3.2.4 of RFC 6092, which we arrived at by a long and >>>>> arduous discussion in V6OPS. We expressly carved out an >>>>> exception for IPsec in simple security because it is >>>>> understood that protecting hosts with a zone-based firewall >>>>> shouldn’t prevent them from taking responsibility for their >>>>> own end-to-end network security by using IPsec and Internet >>>>> Key Exchange. What happened to make us change our minds about >>>>> that? I wasn't involved in such discussion, so I'll let Fred respond to this one. That said, 1) I personally disagree with the aforementioned advice, at least for a general zone-based firewall. Use of IPsec has a different intent that packet filtering. Use of one need not preclude the use of the other. For instance, use of IPsec need not prevent DoS attacks -- atually, in some cases it may even enable it. 2) We plan to split the "recommendations" section into a separate document. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Sep 15 18:38:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541811B2F08 for ; Tue, 15 Sep 2015 18:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSR0zhWmYBKo for ; Tue, 15 Sep 2015 18:38:44 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71351B2EB5 for ; Tue, 15 Sep 2015 18:38:44 -0700 (PDT) Received: by ioiz6 with SMTP id z6so216361648ioi.2 for ; Tue, 15 Sep 2015 18:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+W2s7w6E7McvedIuM6nFgvOWWHhh7lFBE+a5DtqYKXY=; b=qnRIZpOSYmx63SB0SxLXLBf57bg+0u8FqmrVBRGdsyk35HpAAbobcT0vv7C/ptQelA ZdIfKCuJVPJ4d+bkrGRGvBrxbjZfjgHlXuDIdoZDU5/wInUDnGvRotxNAUPHL1FfEkYB 1IHRjG3eVAtohD5SzwqJ+a4rB9ad9qXx0sKiMXZsNm2u3SsjAqfUf5SqluC5Kf1068RG cFTFlnmKNB8Frsd58+vbq/pveB+91maAcyZ8Japx4q+iDoEdKQVsG57IcDapSTX6zVwf xTEexlhZ3MSwOynjLY/sD5Rhc3UMRti3/Xo7y7BvplxyAwumHBDq2uLzyceOrmV2Sh4/ zIfQ== X-Received: by 10.107.164.197 with SMTP id d66mr31114774ioj.85.1442367524160; Tue, 15 Sep 2015 18:38:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.148 with HTTP; Tue, 15 Sep 2015 18:38:14 -0700 (PDT) In-Reply-To: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Mark Smith Date: Wed, 16 Sep 2015 11:38:14 +1000 Message-ID: To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 01:38:46 -0000 Hi, Firstly, I think this is an important document and should be formally published. Regarding the "Benefits of multiple addresses" I think another example that could be mentioned is the use of Multipathing (more specifically MPTCP) to make applications more robust to addressing renumbering events e.g., an application connection surviving a transition from one GUA prefix to another. The main thing that has influenced my thinking is Fred's draft, "Happier Eyeballs" (https://tools.ietf.org/html/draft-baker-happier-eyeballs-00), so I think it should be a reference. I think the most important and interesting observation in Fred's draft is that multiple addresses on a host's single interface is also a form of multi-homing. If an application uses multipathing between the set(s) of IPv6 addresses on the hosts (of any scope, including link-locals if the destination host is known to be on-link for the host's one or more interfaces), then the application connection should have a much better chance of surviving the expiry/replacement of one of those addresses. (MPTCP supports IPv4 too, however mentioning that would probably be out of scope of this draft). For example, there might be two global prefixes on the link, an old, being phased out global prefix, and a new, being phased in global prefix. If the MPTCP host notified its peer of the new address(es) it generated when the new global prefix became available, the MPTCP hosts could start using the new global addresses, allowing the MPTCP connection to then survive the eventual expiry of the old prefix global addresses. This robustness would also work across different address scopes (e.g., ULA disappearing while a GUA still available, GUA and ULAs disappearing while Link-Locals are still (always) available, assuming the destination host is reachable over an attached link). Fred's draft is making it clearer that the Happy Eyeballs technique is a more general mechanism than one limited to TCP or to web browsers. I've started to think that HE and MPTCP style multipathing are complimentary - HE is a single connection set up robustness technique, where as MPTCP is a multiple connection robustness technique deployed after a single connection has been established. It probably isn't in scope for this draft, however I think it would be beneficial for applications to combine the ideas of both - if there are multiple source and destination addresses available, try to use all of them to establish the application session/connection (excepting link-local destinations unless they're known to be on-link somehow e.g., MDNS), and then use MPTCP-style multipathing and ongoing signalling/testing of new and removed addresses to make the connection robust against addresses changing. Specific to the text, considering the above, I think: "Today, there are many host functions that require more than one IP address to be available to the host:" should be changed to: "Today, there are many host functions that require *or would benefit from* more than one IP address *being* available to the host:" Regards, Mark. From nobody Wed Sep 16 01:51:32 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB75B1B3941 for ; Wed, 16 Sep 2015 01:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPz9aesj944I for ; Wed, 16 Sep 2015 01:51:30 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC8E1B3949 for ; Wed, 16 Sep 2015 01:51:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8G8pQkG007662 for ; Wed, 16 Sep 2015 10:51:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AC7B1201A9A for ; Wed, 16 Sep 2015 10:56:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A4B21201A44 for ; Wed, 16 Sep 2015 10:56:18 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8G8pRFI023621 for ; Wed, 16 Sep 2015 10:51:27 +0200 To: v6ops@ietf.org References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> From: Alexandre Petrescu Message-ID: <55F92D8F.1080203@gmail.com> Date: Wed, 16 Sep 2015 10:51:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 08:51:32 -0000 Le 16/09/2015 00:06, Mark Smith a écrit : > > On 15 Sep 2015 22:55, "Alexandru Petrescu" > wrote: > > > > I disagree with the following statements: > >> > >> If the network requires explicit requests > >> for address space (e.g., if it requires DHCPv6 to connect), it is > >> RECOMMENDED that the network assign a /64 prefix to every host (e.g., > >> via DHCPv6 PD). > > > > > > That should be a /63, not a /64. > > > > Can you explain further why? Because it is as valid to recommend a /63 as a /64. Moreover, any value between /1 and /127 could be recommended. There is no reason to recommend /64 in particular. > > > Please dont make this draft yet another hardcoding of 64. > > > > RECOMMENDED is not a MUST. I agree. But I think we can RECOMMEND as much each one of the prefix lengths from /1 to /127 (i.e. 1, 2, 3...127). Alex > > > Alex > > > > > > > > Le 13/09/2015 20:00, fred@cisco.com a écrit : > >> > >> This is to initiate a two week working group last call of > >> http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. > >> Please read it now. If you find nits (spelling errors, minor suggested > >> wording changes, etc), comment to the authors; if you find greater > >> issues, such as disagreeing with a statement or finding additional > >> issues that need to be addressed, please post your comments to the > >> list. > >> > >> We are looking specifically for comments on the importance of the > >> document as well as its content. If you have read the document and > >> believe it to be of operational utility, that is also an important > >> comment to make. > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 16 02:08:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D121F1B3934; Wed, 16 Sep 2015 02:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpHqWua5BFBh; Wed, 16 Sep 2015 02:08:37 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A8E1B392F; Wed, 16 Sep 2015 02:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6546; q=dns/txt; s=iport; t=1442394517; x=1443604117; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=cQ5fqc3oYTVD0dYxh9LGtzG30TQPjZmsm3mABck8VRQ=; b=Xa3GiWgUYNRCaNohCU7LIzMpB8BiAaiHh1yQyEl+fd/MhoWCHtpVwxwB 6XdM5gIBLUOANMa2RyjWQt8hm/v6ZPnDjJ9ExxbGJ/hjdMgIh+BceFLr1 Y8mfR5tUU6jqFg0qR4k0vGkjcQkdS59zyDQEEbb7JiVRTr/nKHMULerV6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CeBABQMflV/xbLJq1dg3dpvy8MhXcCgg8BAQEBAQGBC4QkAQEEAQEBJBEtCQoBEAsYCRYPCQMCAQIBFTAGAQwGAgEBiCoNyUMBAQEBAQEBAQEBAQEBAQEBAQEBFQSGc4R9hEJLB4QsAQSSDyeDKIUQgihFhQaBTYczI44Bg2xjhAM8MwEBiigBAQE X-IronPort-AV: E=Sophos;i="5.17,538,1437436800"; d="scan'208";a="607034831" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Sep 2015 09:08:34 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8G98Yqt026359; Wed, 16 Sep 2015 09:08:34 GMT To: joel jaeggli , draft-ietf-v6ops-pmtud-ecmp-problem@ietf.org References: <55C20D5A.6070409@cisco.com> <55C2A2B7.3050304@cisco.com> <55C382E1.8070406@bogus.com> From: Benoit Claise Message-ID: <55F93192.5080908@cisco.com> Date: Wed, 16 Sep 2015 11:08:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55C382E1.8070406@bogus.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem-03: AD review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 09:08:40 -0000 Thanks Joel, Sending this to IETF LC. Regards, Benoit > On 8/5/15 4:56 PM, Benoit Claise wrote: >> Dear all, >> >> Joel, being a document author, asked me to look into this draft >> Here is my feedback. I don't have any background on this draft. So a >> fresh pair of eyes. >> >> 1. It took me a little bit of time to grasp the problem behind this draft. >> From the abstract, I(wrongly) assumed a PTB packet sent from the server >> back to the source. > yup it's the one from the client. let me see if we can tweak this slightly. > >> It's only in section 2 that I found my answer (well, the second time I >> read it) >> >> An ICMPv6 type 2 PTB message generated >> on an intermediate device _for a packet sent from a server_ >> >> And the figure 1 was not too helpful, as, obviously I was wondering >> about the ptb direction... > figure 1 contains > > ptb -> router ecmp -> nexthop L4/L7 load balancer -> destination > > the limitations of ascii art may be a limitation here, but it's not > really a state flow since it could be emitted by any device in the path. > at any time. but I think if we address item 1 the problem of > directionality is no doubt clear. > >> What would have made it crystal-clear is a figure 1 such as: >> >> Topology >> >> client -...-- router -- load balancer 1 --- server 1 >> \\-- load balancer 2 --- server 2 >> \-- load balancer N --- server N >> >> >> Sequence 1: packet from source to server >> client -> ... -> router ecmp -> nexthop L4/L7 load balancer -> >> server (*) >> >> Sequence 2: reply from server to source >> .... <- router ecmp <- nexthop L4/L7 load balancer >> <- server (*) >> >> Sequence 3: ptb sent back to the server >> ptb -> router ecmp -> nexthop L4/L7 load balancer -> >> server (**) >> >> Note: As (*) and (**) are unlikely the same instance, so the ptb >> could be mis-delivered >> >> >> 2. >> Confused about the order >> >> 3 >> . Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> >> 3.1 >> . Alternatives . . . . . . . . . . . . . . . . . . . . . . 5 >> > 3.1 can be changed to Alternative mitigations > > it's important that clamping the mss doesn't get lost in all if this > because both the ietf considers that minimum best effort (everything has > to carry 1280 right) and because people do it. > >> 3.2 >> . Implementation . . . . . . . . . . . . . . . . . . . . . 5 >> >> 3.2.1 >> . Alternatives . . . . . . . . . . . . . . . . . . . . 6 >> >> >> 3.2 is the implementation of what? The intro in section 3? > 3.2 yes is an example mitigiation based on 3 paragraph 2 > >> So why do you insert alternatives 3.1 (which you don't recommend) in >> between? >> And 3.2.1 is the alternative to what? the implementation in section 3.2 > 3.2.1 yes. the point being there's more than one way to solve the > problem. operationally one approach may be more desirable the the other, > in point of fact when I asked the cloudflare guys came up with their's > so I added it. > > >> 3. >> >> 1. Filter-based-forwarding matches next-header ICMPv6 type-2 and >> matches a next-hop on a particular subnet directly attached to >> both border routers. The filter is policed to reasonable limits >> (we chose 1000pps, more conservative rates might be required in >> other implementations). >> >> border router? make it consistent with the terminology in figure 1 > ok routers > >> 2. Filter is applied on input side of all external interfaces >> >> Make it clear that you speak about router in figure 1 > external routers > >> 4. Anycast servers receive the PTB error and process packet as >> needed. >> >> "anycast server" make it consistent with the terminology is figure 1 > figure 1 is bounded by width limitations for ascii art otherwise the > label would be longer, the fact that it is naycast is brought up in > section 2. we can probably arrange to us server more freely in the text > prior to this. > >> 4. >> Section 3.2.1 >> "ECMP hop could distribute the proxy onto the end systems" > Alternatively, network designs in which a common layer 2 network > exists on the ECMP hop could distribute the proxy onto the end > systems, eliminating the need for policy routing. > > Proxy in this case refers to the mitigiation proposed in section 3 > paragraph 2 of which this is a sub section. > > The excerpt is missing a preposition ( exists on the ECMP hop) and I > agree it's hard to parse without that. > >> Not sure what it means. >> >> 5. >> section 4. Improvements to what? The implementation or the potential specification. > These are improvements on the mitigation. they are not specification > changes rfc 4821 already exists it's just not widely (at all afaik) used. > >> I guess the "specification", but then, how is this different that the mitigation section? >> Your improvement point 1 is the same as the "mitigation" section paragraph 1 > Right but no asic or at least microcode exists today can actually do that. > >> Your improvement point 2 is the same as the "mitigation" section paragraph 2 > no it isn't. in the mitigitation it was necessary to build a proxy to > flood them by rewritting the L2 nexthop. that's rather different than > getting router to forward a unicast packet to say 16 destinations if > somebody gives me a knob for the latter then all this proxy junk is done. > >> nits: >> implmentation -> implementation >> >> Regards, Benoit >> >> >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From SRS0=/faI=JW=darou.fr=pierre.pfister@bounces.m4x.org Wed Sep 16 02:37:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B081B3ADD for ; Wed, 16 Sep 2015 02:37:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_i2TpdPGih2 for ; Wed, 16 Sep 2015 02:37:47 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDF11B3ACE for ; Wed, 16 Sep 2015 02:37:47 -0700 (PDT) Received: from [10.228.42.122] (unknown [173.38.220.46]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id CC69D1408EEF7; Wed, 16 Sep 2015 11:37:43 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_AE9B6A28-6CE8-43A7-BF1C-02B72FAA888B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Pierre Pfister In-Reply-To: <55F92D8F.1080203@gmail.com> Date: Wed, 16 Sep 2015 11:37:42 +0200 Message-Id: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.2104) X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Wed Sep 16 11:37:44 2015 +0200 (CEST)) Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 09:42:39 -0000 --Apple-Mail=_AE9B6A28-6CE8-43A7-BF1C-02B72FAA888B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Alex and Mark, > Le 16 sept. 2015 =E0 10:51, Alexandre Petrescu = a =E9crit : >=20 >=20 >=20 > Le 16/09/2015 00:06, Mark Smith a =E9crit : >>=20 >> On 15 Sep 2015 22:55, "Alexandru Petrescu" = > > wrote: >> > >> > I disagree with the following statements: >> >> >> >> If the network requires explicit requests >> >> for address space (e.g., if it requires DHCPv6 to connect), it = is >> >> RECOMMENDED that the network assign a /64 prefix to every host = (e.g., >> >> via DHCPv6 PD). >> > >> > >> > That should be a /63, not a /64. >> > >>=20 >> Can you explain further why? >=20 > Because it is as valid to recommend a /63 as a /64. Moreover, any = value between /1 and /127 could be recommended. There is no reason to = recommend /64 in particular. I think the spirit of the document is to say that hosts should be = assigned *at least* a 64. It is later stated that a prefix longer than 64 may cause trouble, which = is true. On the other hand, providing a bigger prefix is not likely to cause = trouble (I assume a DHCPv6-PD client failing at receiving a 63 is just broken). So what about such a change ? OLD: If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that the network assign a /64 prefix to every host (e.g., via DHCPv6 PD). NEW: If the network requires explicit requests for address space (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that the network assign prefix of length 64 or less to = every host (e.g., via DHCPv6 PD). - Pierre --Apple-Mail=_AE9B6A28-6CE8-43A7-BF1C-02B72FAA888B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello Alex and Mark,


Le 16 sept. 2015 =E0 10:51, Alexandre = Petrescu <alexandre.petrescu@gmail.com> a =E9crit :



Le 16/09/2015 00:06, Mark Smith a =E9crit :

On 15 Sep = 2015 22:55, "Alexandru Petrescu" <alexandru.petrescu@gmail.com
<mailto:alexandru.petrescu@gmail.com>> wrote:
>
> I disagree with the following = statements:
>>
>> If the = network requires explicit requests
>> =    for address space (e.g., if it requires DHCPv6 to = connect), it is
>>    RECOMMENDED = that the network assign a /64 prefix to every host (e.g.,
= >>    via DHCPv6 PD).
>
>
> That should be a /63, not a /64.
>

Can you explain further = why?

Because it is as valid to = recommend a /63 as a /64.  Moreover, any value between /1 and /127 = could be recommended.  There is no reason to recommend /64 in = particular.

I think the spirit of the document = is to say that hosts should be assigned *at least* a 64.
It is later stated that a prefix longer than 64 may cause = trouble, which is true.
On the other hand, = providing a bigger prefix is not likely to cause trouble (I assume a = DHCPv6-PD client
failing at receiving a 63 is just = broken).

So = what about such a change ?

OLD:
If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
   via DHCPv6 PD).

NEW:
If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign prefix of length 64 or less to =
every host (e.g.,
   via DHCPv6 PD).


- = Pierre

= --Apple-Mail=_AE9B6A28-6CE8-43A7-BF1C-02B72FAA888B-- From nobody Wed Sep 16 04:15:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703D81A88D8 for ; Wed, 16 Sep 2015 04:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8JZhC-qhNhA for ; Wed, 16 Sep 2015 04:15:52 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6CA1A88C2 for ; Wed, 16 Sep 2015 04:15:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8GBFmDT020423; Wed, 16 Sep 2015 13:15:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C67E82028D0; Wed, 16 Sep 2015 13:20:39 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BA8AD2022DA; Wed, 16 Sep 2015 13:20:39 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8GBFloZ009364; Wed, 16 Sep 2015 13:15:48 +0200 To: Pierre Pfister References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> From: Alexandre Petrescu Message-ID: <55F94F63.8000009@gmail.com> Date: Wed, 16 Sep 2015 13:15:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 11:15:54 -0000 Le 16/09/2015 11:37, Pierre Pfister a écrit : > Hello Alex and Mark, > > >> Le 16 sept. 2015 à 10:51, Alexandre Petrescu >> > > a écrit : >> >> >> >> Le 16/09/2015 00:06, Mark Smith a écrit : >>> >>> On 15 Sep 2015 22:55, "Alexandru Petrescu" >>> >> >>> > wrote: >>>> >>>> I disagree with the following statements: >>>>> >>>>> If the network requires explicit requests for address space >>>>> (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED >>>>> that the network assign a /64 prefix to every host >>> (e.g., >>>>> via DHCPv6 PD). >>>> >>>> >>>> That should be a /63, not a /64. >>>> >>> >>> Can you explain further why? >> >> Because it is as valid to recommend a /63 as a /64. Moreover, any >> value between /1 and /127 could be recommended. There is no >> reason to recommend /64 in particular. > > I think the spirit of the document is to say that hosts should be > assigned *at least* a 64. Sounds reasonable in a sense. There is a difference between a Host on WiFi and a Host on cellular. I think one can not say that a Host on WiFi is allocated a /64. On WiFi it hears a /64 prefix and forms an address; or it gets allocated an address with DHCP. But it is not _allocated_ that /64 only for itself. On cellular one can consider that the terminal is (currently) "allocated" a /64 for itself, simply because there's nobody else on that link. There is a difference between DHCP-PD and DHCP-Address. DHCP-Address only allocates a /128, not /64. DHCP-PD allocates a prefix - but that prefix is not to be used to form an address on the interface where that prefix was received. As such _that_ allocated prefix has nothing to do with the 64bit length of IPv6-over-Ethernet. To summarize, that 'RECOMMEND'ation seems to deal with a smartphone connecting on 4G and using DHCPv6-PD. As such it has no reason to RECOMMEND 64. It should recommend _any_ length. > It is later stated that a prefix longer than 64 may cause trouble, > which is true. YEs, a prefix length greater than 64 in a RA will cause trouble to stateless address auto-configuration on Ethernet - the kernel complies in /var/log/messages. However, it causes no trouble to DHCP. > On the other hand, providing a bigger prefix is not likely to cause > trouble (I assume a DHCPv6-PD client failing at receiving a 63 is > just broken). I also agree with this. Allocating a prefix length smaller than 64 will not cause trouble on Ethernet neither to SLAAC nor to DHCP. Implementations simply pad zeros up to the 64bit boundary necessary to SLAAC-over-Ethernet. > So what about such a change ? > > OLD: > > If the network requires explicit requests for address space (e.g., if > it requires DHCPv6 to connect), it is RECOMMENDED that the network > assign a /64 prefix to every host (e.g., via DHCPv6 PD). > > > NEW: > > If the network requires explicit requests for address space (e.g., if > it requires DHCPv6 to connect), it is RECOMMENDED that the network > assign prefix of length 64 or less to every host (e.g., via DHCPv6 > PD). Still not ok to me. How about this: > If the network requires explicit requests for address space (e.g., if > it requires the use of DHCPv6 at connect time), it is RECOMMENDED > that the network assigns an address to each host (e.g., via DHCPv6). > It is also recommended that the network allocates a Prefix to a Host > if that Host requested it (if Host used DHCP Prefix Delegation). The > Prefix Length is RECOMMENDED by the Host and can have any value > between 1 and 127. Alex > > > > - Pierre > From nobody Wed Sep 16 04:56:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853451A6F2A for ; Wed, 16 Sep 2015 04:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 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, FREEMAIL_REPLY=1, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6e3MJiqPeSL for ; Wed, 16 Sep 2015 04:55:59 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 27D541A89C6 for ; Wed, 16 Sep 2015 04:55:14 -0700 (PDT) Received: by ioiz6 with SMTP id z6so21897678ioi.3 for ; Wed, 16 Sep 2015 04:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xmdzKkqYpUBc589uxLpoXn22KpyYs3PCnQXfObJ+GAk=; b=DXTz8WvZrFGhdM/zQ/SU/ngUJMx5pVJkmNwvJdtGBDT7xusY7j5bY/Rq474PVv91o+ Sf6V0mhKcbsWsjfsvapwEeO3qvIShVPbYxkr1WXQJCqTxd/HyETz7BhTbmp/YX9crl+M 8HT+cfKT0qPuEr3+lNG8/oXDmAWSoo8+4ww4ustXnq1zlNvTCoCz2D9bDO5bsowU1czq 8qrHTzGbXLIS+IBugLduZ3+QoXRKJ68Vqova4MH0/UZP5MJZKCcm3Hpsw9/kb704RFXV 05kBD+AIZyvoGehUnZDwC8X+9v4mHjeQsSZTGbICXZ3304pZXJMdVVipDKtyx7ci9lPZ ydOw== MIME-Version: 1.0 X-Received: by 10.107.35.78 with SMTP id j75mr40911570ioj.123.1442404513580; Wed, 16 Sep 2015 04:55:13 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Wed, 16 Sep 2015 04:55:13 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Wed, 16 Sep 2015 04:55:13 -0700 (PDT) In-Reply-To: <55F94F63.8000009@gmail.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> Date: Wed, 16 Sep 2015 21:55:13 +1000 Message-ID: From: Mark Smith To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=001a1141a2a2a78c4c051fdbf855 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 11:56:01 -0000 --001a1141a2a2a78c4c051fdbf855 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 Sep 2015 21:16, "Alexandre Petrescu" wrote: > > > > Le 16/09/2015 11:37, Pierre Pfister a =C3=A9crit : >> >> Hello Alex and Mark, >> >> >>> Le 16 sept. 2015 =C3=A0 10:51, Alexandre Petrescu >>> >> > a =C3=A9crit : >>> >>> >>> >>> >>> Le 16/09/2015 00:06, Mark Smith a =C3=A9crit : >>>> >>>> >>>> On 15 Sep 2015 22:55, "Alexandru Petrescu" >>>> >>> >>>> > wrote: >>>>> >>>>> >>>>> I disagree with the following statements: >>>>>> >>>>>> >>>>>> If the network requires explicit requests for address space >>>>>> (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED >>>>>> that the network assign a /64 prefix to every host >>>> >>>> (e.g., >>>>>> >>>>>> via DHCPv6 PD). >>>>> >>>>> >>>>> >>>>> That should be a /63, not a /64. >>>>> >>>> >>>> Can you explain further why? >>> >>> >>> Because it is as valid to recommend a /63 as a /64. Moreover, any >>> value between /1 and /127 could be recommended. There is no >>> reason to recommend /64 in particular. >> >> >> I think the spirit of the document is to say that hosts should be >> assigned *at least* a 64. > > > Sounds reasonable in a sense. > > There is a difference between a Host on WiFi and a Host on cellular. > > I think one can not say that a Host on WiFi is allocated a /64. On WiFi > it hears a /64 prefix and forms an address; or it gets allocated an > address with DHCP. But it is not _allocated_ that /64 only for itself. > > On cellular one can consider that the terminal is (currently) > "allocated" a /64 for itself, simply because there's nobody else on that > link. > > There is a difference between DHCP-PD and DHCP-Address. DHCP-Address > only allocates a /128, not /64. DHCP-PD allocates a prefix - but that > prefix is not to be used to form an address on the interface where that > prefix was received. As such _that_ allocated prefix has nothing to do > with the 64bit length of IPv6-over-Ethernet. > > To summarize, that 'RECOMMEND'ation seems to deal with a smartphone > connecting on 4G and using DHCPv6-PD. As such it has no reason to > RECOMMEND 64. It should recommend _any_ length. > > >> It is later stated that a prefix longer than 64 may cause trouble, >> which is true. > > > YEs, a prefix length greater than 64 in a RA will cause trouble to > stateless address auto-configuration on Ethernet - the kernel complies > in /var/log/messages. However, it causes no trouble to DHCP. > > >> On the other hand, providing a bigger prefix is not likely to cause >> trouble (I assume a DHCPv6-PD client failing at receiving a 63 is >> just broken). > > > I also agree with this. Allocating a prefix length smaller than 64 will > not cause trouble on Ethernet neither to SLAAC nor to DHCP. > Implementations simply pad zeros up to the 64bit boundary necessary to > SLAAC-over-Ethernet. > > >> So what about such a change ? >> >> OLD: >> >> If the network requires explicit requests for address space (e.g., if >> it requires DHCPv6 to connect), it is RECOMMENDED that the network >> assign a /64 prefix to every host (e.g., via DHCPv6 PD). >> >> >> NEW: >> >> If the network requires explicit requests for address space (e.g., if >> it requires DHCPv6 to connect), it is RECOMMENDED that the network >> assign prefix of length 64 or less to every host (e.g., via DHCPv6 >> PD). > > > Still not ok to me. How about this: > >> If the network requires explicit requests for address space (e.g., if >> it requires the use of DHCPv6 at connect time), it is RECOMMENDED >> that the network assigns an address to each host (e.g., via DHCPv6). >> It is also recommended that the network allocates a Prefix to a Host >> if that Host requested it (if Host used DHCP Prefix Delegation). The >> Prefix Length is RECOMMENDED by the Host and can have any value >> between 1 and 127. > So this is again going down the path of providing just enough rather than more than enough addresses. Variation and "right sizing" has a cost - more complexity and less predictability and therefore less ability to plan and easily troubleshoot. It is far simpler to work with "every host gets a /64", rather than trying to work with "a host gets what it asks for, up to a /1 (which it won't ever get), or down to a /127, depending on what applications it is running and what they would like or need to have at any particular time.". There is no need for "right sizing" in IPv6 when the address space is 73 billion billion times larger than IPv4's. Regards, Mark. > > Alex > >> >> >> >> - Pierre >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1141a2a2a78c4c051fdbf855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Sep 2015 21:16, "Alexandre Petrescu" <alexandre.petrescu@gmail.com> wrote: >
>
>
> Le 16/09/2015 11:37, Pierre Pfister a =C3=A9crit :
>>
>> Hello Alex and Mark,
>>
>>
>>> Le 16 sept. 2015 =C3=A0 10:51, Alexandre Petrescu
>>> <alexandre.= petrescu@gmail.com
>>> <mailto:ale= xandre.petrescu@gmail.com>> a =C3=A9crit :
>>>
>>>
>>>
>>>
>>> Le 16/09/2015 00:06, Mark Smith a =C3=A9crit :
>>>>
>>>>
>>>> On 15 Sep 2015 22:55, "Alexandru Petrescu"
>>>> <alexan= dru.petrescu@gmail.com
>>>> <mailto:alexandru.petrescu@gmail.com>
>>>> <mailto:alexandru.petrescu@gmail.com>> wrote:
>>>>>
>>>>>
>>>>> I disagree with the following statements:
>>>>>>
>>>>>>
>>>>>> If the network requires explicit requests for addr= ess space
>>>>>> (e.g., if it requires DHCPv6 to connect), it is RE= COMMENDED
>>>>>> that the network assign a /64 prefix to every host=
>>>>
>>>> (e.g.,
>>>>>>
>>>>>> via DHCPv6 PD).
>>>>>
>>>>>
>>>>>
>>>>> That should be a /63, not a /64.
>>>>>
>>>>
>>>> Can you explain further why?
>>>
>>>
>>> Because it is as valid to recommend a /63 as a /64.=C2=A0 More= over, any
>>> =C2=A0value between /1 and /127 could be recommended.=C2=A0 Th= ere is no
>>> reason to recommend /64 in particular.
>>
>>
>> I think the spirit of the document is to say that hosts should be<= br> >> assigned *at least* a 64.
>
>
> Sounds reasonable in a sense.
>
> There is a difference between a Host on WiFi and a Host on cellular. >
> I think one can not say that a Host on WiFi is allocated a /64.=C2=A0 = On WiFi
> it hears a /64 prefix and forms an address; or it gets allocated an > address with DHCP.=C2=A0 But it is not _allocated_ that /64 only for i= tself.
>
> On cellular one can consider that the terminal is (currently)
> "allocated" a /64 for itself, simply because there's nob= ody else on that
> link.
>
> There is a difference between DHCP-PD and DHCP-Address.=C2=A0 DHCP-Add= ress
> only allocates a /128, not /64. DHCP-PD allocates a prefix - but that<= br> > prefix is not to be used to form an address on the interface where tha= t
> prefix was received.=C2=A0 As such _that_ allocated prefix has nothing= to do
> with the 64bit length of IPv6-over-Ethernet.
>
> To summarize, that 'RECOMMEND'ation seems to deal with a smart= phone
> connecting on 4G and using DHCPv6-PD.=C2=A0 As such it has no reason t= o
> RECOMMEND 64.=C2=A0 It should recommend _any_ length.
>
>
>> It is later stated that a prefix longer than 64 may cause trouble,=
>> which is true.
>
>
> YEs, a prefix length greater than 64 in a RA will cause trouble to
> stateless address auto-configuration on Ethernet - the kernel complies=
> in /var/log/messages.=C2=A0 However, it causes no trouble to DHCP.
>
>
>> On the other hand, providing a bigger prefix is not likely to caus= e
>> trouble (I assume a DHCPv6-PD client failing at receiving a 63 is<= br> >> just broken).
>
>
> I also agree with this.=C2=A0 Allocating a prefix length smaller than = 64 will
> not cause trouble on Ethernet neither to SLAAC nor to DHCP.
> Implementations simply pad zeros up to the 64bit boundary necessary to=
> SLAAC-over-Ethernet.
>
>
>> So what about such a change ?
>>
>> OLD:
>>
>> If the network requires explicit requests for address space (e.g.,= if
>> it requires DHCPv6 to connect), it is RECOMMENDED that the network=
>> assign a /64 prefix to every host (e.g., via DHCPv6 PD).
>>
>>
>> NEW:
>>
>> If the network requires explicit requests for address space (e.g.,= if
>> it requires DHCPv6 to connect), it is RECOMMENDED that the network=
>> assign prefix of length 64 or less to every host (e.g., via DHCPv6=
>> PD).
>
>
> Still not ok to me.=C2=A0 How about this:
>
>> If the network requires explicit requests for address space (e.g.,= if
>> it requires the use of DHCPv6 at connect time), it is RECOMMENDED<= br> >> that the network assigns an address to each host (e.g., via DHCPv6= ).
>> It is also recommended that the network allocates a Prefix to a Ho= st
>> if that Host requested it (if Host used DHCP Prefix Delegation).= =C2=A0 The
>> Prefix Length is RECOMMENDED by the Host and can have any value >> between 1 and 127.
>

So this is again going down the path of providing just enoug= h rather than more than enough addresses.

Variation and "right sizing" has a cost - more com= plexity and less predictability and therefore less ability to plan and easi= ly troubleshoot. It is far simpler to work with "every host gets a /64= ", rather than trying to work with "a host gets what it asks for,= up to a /1 (which it won't ever get), or down to a /127, depending on = what applications it is running and what they would like or need to have at= any particular time.".

There is no need for "right sizing" in IPv6 when t= he address space is 73 billion billion times larger than IPv4's.

Regards,
Mark.

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

--001a1141a2a2a78c4c051fdbf855-- From nobody Wed Sep 16 06:35:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D081A1B3B8A for ; Wed, 16 Sep 2015 06:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8oDCp1J7lld for ; Wed, 16 Sep 2015 06:35:50 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 00A031B3B8E for ; Wed, 16 Sep 2015 06:35:49 -0700 (PDT) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Wed, 16 Sep 2015 08:35:48 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f182.google.com [209.85.213.182] #+LO+TS+TR X-Umn-Classification: local Received: by igbkq10 with SMTP id kq10so35114585igb.0 for ; Wed, 16 Sep 2015 06:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=R22mCQijZpZxhYOKjmmKGN6FYz59IM7JaRlLAXQCt04=; b=S6w3vlr99zA9ieahmI/XoVFfLz3FjKftZA6mBrupow52uWoT6Zo99HSCpZDy0SF74W w8nTYiet601M9oRALw55ZYNy2agNa5EvoIK5KLJax8HMYc4EzbLjKTXmaoFDapDAwSc0 jzWDM2K7oIJmjxo870ATQvuRmB5/XLP/TFRDw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=R22mCQijZpZxhYOKjmmKGN6FYz59IM7JaRlLAXQCt04=; b=ciOeWd65eg8caKnDuyDTonAlxudTgxmIXb0LD+y3sbEJSM/2g8pVQtuIoTlPpYFbnU gXCAbbZBFqio8y0DXy865LTKw35H9T0VVF/8vPlOd8c65DW/Q9hYEzInhP0ST+KyhrTi rfOqVm+vKSgV4F7PbHuSt4OOhoeuQ8RrOkOz3bJbdBcJxsf2Khkk4w6jwn8C/mQ6t7Ql 7RDN3eySTAApsyR23bAAB93UB1bQ/iysur1ReDWUf4f9i+4lGMguOsCI8+OwgbMPFJNv 57TF+BRZPj5SRor1ojEBL8E8piHLB+pMgdIX7+098h3Ey7QSP+pkf/vN1HYnE+IFSExj u3/A== X-Gm-Message-State: ALoCoQnLVCKlA9erQazi5oX4U2oSCINNtFB+RV5GA8i4G6Y/sKO7Z80nrN96nrubBOICQEWq6/T7hXvMlXs85T9lvIgc46Tp5hxBB2bDsKCYAws/ps6L4JU1DfANVr9///noeOM+Sd47 X-Received: by 10.50.60.100 with SMTP id g4mr6144117igr.41.1442410548338; Wed, 16 Sep 2015 06:35:48 -0700 (PDT) X-Received: by 10.50.60.100 with SMTP id g4mr6144079igr.41.1442410548022; Wed, 16 Sep 2015 06:35:48 -0700 (PDT) Received: from [10.0.0.7] (c-75-73-121-154.hsd1.mn.comcast.net. [75.73.121.154]) by smtp.gmail.com with ESMTPSA id n14sm10362241ioi.15.2015.09.16.06.35.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 06:35:46 -0700 (PDT) References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-7EB3FC35-3281-4F68-8DAE-009BD9F27955 Message-Id: <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> X-Mailer: iPad Mail (12H321) From: David Farmer Date: Wed, 16 Sep 2015 08:35:45 -0500 To: Mark Smith Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 13:35:52 -0000 --Apple-Mail-7EB3FC35-3281-4F68-8DAE-009BD9F27955 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Sep 16, 2015, at 06:55, Mark Smith wrote: > So this is again going down the path of providing just enough rather than m= ore than enough addresses. >=20 > Variation and "right sizing" has a cost - more complexity and less predict= ability and therefore less ability to plan and easily troubleshoot. It is fa= r simpler to work with "every host gets a /64", rather than trying to work w= ith "a host gets what it asks for, up to a /1 (which it won't ever get), or d= own to a /127, depending on what applications it is running and what they wo= uld like or need to have at any particular time.". >=20 > There is no need for "right sizing" in IPv6 when the address space is 73 b= illion billion times larger than IPv4's. >=20 > Regards, > Mark. >=20 Let's be clear, a /64 is enough addresses for a host to do ANYTHING it could= ever possible what to do. A /64 is only ever NOT enough in the context of w= anting more than one subnet, for what ever reason it may be desired. This D= raft is about ensuring a Host has sufficient addresses to do what were it wa= nts to do. I believe a /64 more than fulfills that desire in the context des= cribed in the Draft. A host, user, site or whatever wanting more than on subnet is perfectly appr= opriate too. However, it's a different request, requirement, desire, or con= text then I think is being discussed in this draft. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Apple-Mail-7EB3FC35-3281-4F68-8DAE-009BD9F27955 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On Sep 16, 2015= , at 06:55, Mark Smith <markzzz= smith@gmail.com> wrote:

So this is again going down the path of providing just enough= rather than more than enough addresses.

Variation and "right sizing" has a cost - more complexity and= less predictability and therefore less ability to plan and easily troublesh= oot. It is far simpler to work with "every host gets a /64", rather than try= ing to work with "a host gets what it asks for, up to a /1 (which it won't e= ver get), or down to a /127, depending on what applications it is running an= d what they would like or need to have at any particular time.".

There is no need for "right sizing" in IPv6 when the address s= pace is 73 billion billion times larger than IPv4's.

Regards,
Mark.

Let's be clear, a /64 is enough addresses for a ho= st to do ANYTHING it could ever possible what to do.  A /64 is only eve= r NOT enough in the context of wanting more than one subnet, for what ever r= eason it may be desired.  This Draft is about ensuring a Host has suffi= cient addresses to do what were it wants to do. I believe a /64 more than fu= lfills that desire in the context described in the Draft.

A host, user, site or whatever wanting more than on subnet is perfectly app= ropriate too.  However, it's a different request, requirement, desire, o= r context then I think is being discussed in this draft.

-- 
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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       &nb= sp;                  Email: farmer@umn.edu
Office of Information Techno= logy
University of Minnesota    
2218 University Ave SE    = ;     Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell= : +1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

= --Apple-Mail-7EB3FC35-3281-4F68-8DAE-009BD9F27955-- From nobody Wed Sep 16 06:44:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DC81B3BCA for ; Wed, 16 Sep 2015 06:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrFP7-GNXDVB for ; Wed, 16 Sep 2015 06:44:16 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321B41B3BC9 for ; Wed, 16 Sep 2015 06:44:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8GDiDPt008636; Wed, 16 Sep 2015 15:44:13 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 678852030CD; Wed, 16 Sep 2015 15:49:04 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 56D3120244F; Wed, 16 Sep 2015 15:49:04 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8GDiBMT021793; Wed, 16 Sep 2015 15:44:12 +0200 To: Mark Smith References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> From: Alexandre Petrescu Message-ID: <55F9722B.9030309@gmail.com> Date: Wed, 16 Sep 2015 15:44:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 13:44:18 -0000 right-sizing... Le 16/09/2015 13:55, Mark Smith a écrit : [...] >>> So what about such a change ? >>> >>> OLD: >>> >>> If the network requires explicit requests for address space >>> (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that >>> the network assign a /64 prefix to every host (e.g., via DHCPv6 >>> PD). >>> >>> >>> NEW: >>> >>> If the network requires explicit requests for address space >>> (e.g., if it requires DHCPv6 to connect), it is RECOMMENDED that >>> the network assign prefix of length 64 or less to every host >>> (e.g., via DHCPv6 PD). >> >> >> Still not ok to me. How about this: >> >>> If the network requires explicit requests for address space >>> (e.g., if it requires the use of DHCPv6 at connect time), it is >>> RECOMMENDED that the network assigns an address to each host >>> (e.g., via DHCPv6). It is also recommended that the network >>> allocates a Prefix to a Host if that Host requested it (if Host >>> used DHCP Prefix Delegation). The Prefix Length is RECOMMENDED >>> by the Host and can have any value between 1 and 127. >> > > So this is again going down the path of providing just enough rather > than more than enough addresses. > > Variation and "right sizing" has a cost - more complexity and less > predictability and therefore less ability to plan and easily > troubleshoot. > It is far simpler to work with "every host gets a /64", "every host gets at least 32 unagreggatable /128s for self and 32 /64s for its tethered" - EHGAT64. > rather than trying to work with "a host gets what it asks for, up to > a /1 (which it won't ever get), or down to a /127, depending on what > applications it is running and what they would like or need to have > at any particular time.". I agree, too much. I think I meant that RECOMMENDing only prefix size (63, or 64) is not really giving ensurance that enough addresses be available to a Host. Alex > > There is no need for "right sizing" in IPv6 when the address space > is 73 billion billion times larger than IPv4's. > > Regards, Mark. > >> >> Alex >> >>> >>> >>> >>> - Pierre >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 16 06:47:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9B71B3C08 for ; Wed, 16 Sep 2015 06:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cahd7-QTBpkb for ; Wed, 16 Sep 2015 06:47:34 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A6A1B3C06 for ; Wed, 16 Sep 2015 06:47:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DxAQDUXPlV/yYyC4daAw4LAQEBgjohLFRpBr0hAQ2HcgIcgSQ4FAEBAQEBAQGBCoQkAQEBAxIRCkwOAgIBCA0VHQMCAgIZBhEUEQIEAQ0FCBqHdwMSAapJilyPUw2EYgEBAQEBAQEBAQEBAQEBAQEBAQEBARcEhnGEe4JQgVoRASAFEQsQBxKCVy+BFAWSNoMoAYsUAYM6hDWDFYo7hz4fAQFCg0M+cYhrOoEFAQEB X-IPAS-Result: A2DxAQDUXPlV/yYyC4daAw4LAQEBgjohLFRpBr0hAQ2HcgIcgSQ4FAEBAQEBAQGBCoQkAQEBAxIRCkwOAgIBCA0VHQMCAgIZBhEUEQIEAQ0FCBqHdwMSAapJilyPUw2EYgEBAQEBAQEBAQEBAQEBAQEBAQEBARcEhnGEe4JQgVoRASAFEQsQBxKCVy+BFAWSNoMoAYsUAYM6hDWDFYo7hz4fAQFCg0M+cYhrOoEFAQEB X-IronPort-AV: E=Sophos;i="5.17,539,1437451200"; d="scan'208,217";a="136310902" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Sep 2015 09:47:33 -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/AES128-SHA; 16 Sep 2015 09:47:33 -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.0174.001; Wed, 16 Sep 2015 09:47:32 -0400 From: "Mudric, Dusan (Dusan)" To: David Farmer , Mark Smith Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ7k4LcCy99O/jtUGatjdNzwwqHp4+KOn7gAD3R4CAAAzsAIAAG2iAgAALBICAABwXgP//vsqQ Date: Wed, 16 Sep 2015 13:47:31 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E457A84EDE8@AZ-US1EXMB03.global.avaya.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> In-Reply-To: <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457A84EDE8AZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 13:47:36 -0000 --_000_9142206A0C5BF24CB22755C8EC422E457A84EDE8AZUS1EXMB03glob_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hpY2ggcHJlZml4ZXMgZG8geW91IGV4cGVjdCB0byBiZSBhc3NpZ25lZCB0byB0aG9zZSB0aGF0 IGRlbGVnYXRlIHRoZW0/IEFyZSB5b3Ugc2F5aW5nIGV2ZXJ5IG9yZ2FuaXphdGlvbiBoYXMgdG8g b2J0YWluIC82MyBvciBzbWFsbGVyIHByZWZpeD8gQXJlIHdlIGFwcHJvYWNoaW5nIC8zMiBJUHY0 PyBDYW4geW91IHByb3ZpZGUgYSBuZXR3b3JrIGhpZXJhcmNoeSBleGFtcGxlcyBwbGVhc2U/DQoN ClRoYW5rcywNCkR1c2FuLg0KDQpPbiBTZXAgMTYsIDIwMTUsIGF0IDA2OjU1LCBNYXJrIFNtaXRo IDxtYXJrenp6c21pdGhAZ21haWwuY29tPG1haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tPj4g d3JvdGU6DQoNClNvIHRoaXMgaXMgYWdhaW4gZ29pbmcgZG93biB0aGUgcGF0aCBvZiBwcm92aWRp bmcganVzdCBlbm91Z2ggcmF0aGVyIHRoYW4gbW9yZSB0aGFuIGVub3VnaCBhZGRyZXNzZXMuDQoN ClZhcmlhdGlvbiBhbmQgInJpZ2h0IHNpemluZyIgaGFzIGEgY29zdCAtIG1vcmUgY29tcGxleGl0 eSBhbmQgbGVzcyBwcmVkaWN0YWJpbGl0eSBhbmQgdGhlcmVmb3JlIGxlc3MgYWJpbGl0eSB0byBw bGFuIGFuZCBlYXNpbHkgdHJvdWJsZXNob290LiBJdCBpcyBmYXIgc2ltcGxlciB0byB3b3JrIHdp dGggImV2ZXJ5IGhvc3QgZ2V0cyBhIC82NCIsIHJhdGhlciB0aGFuIHRyeWluZyB0byB3b3JrIHdp dGggImEgaG9zdCBnZXRzIHdoYXQgaXQgYXNrcyBmb3IsIHVwIHRvIGEgLzEgKHdoaWNoIGl0IHdv bid0IGV2ZXIgZ2V0KSwgb3IgZG93biB0byBhIC8xMjcsIGRlcGVuZGluZyBvbiB3aGF0IGFwcGxp Y2F0aW9ucyBpdCBpcyBydW5uaW5nIGFuZCB3aGF0IHRoZXkgd291bGQgbGlrZSBvciBuZWVkIHRv IGhhdmUgYXQgYW55IHBhcnRpY3VsYXIgdGltZS4iLg0KDQpUaGVyZSBpcyBubyBuZWVkIGZvciAi cmlnaHQgc2l6aW5nIiBpbiBJUHY2IHdoZW4gdGhlIGFkZHJlc3Mgc3BhY2UgaXMgNzMgYmlsbGlv biBiaWxsaW9uIHRpbWVzIGxhcmdlciB0aGFuIElQdjQncy4NCg0KUmVnYXJkcywNCk1hcmsuDQpM ZXQncyBiZSBjbGVhciwgYSAvNjQgaXMgZW5vdWdoIGFkZHJlc3NlcyBmb3IgYSBob3N0IHRvIGRv IEFOWVRISU5HIGl0IGNvdWxkIGV2ZXIgcG9zc2libGUgd2hhdCB0byBkby4gIEEgLzY0IGlzIG9u bHkgZXZlciBOT1QgZW5vdWdoIGluIHRoZSBjb250ZXh0IG9mIHdhbnRpbmcgbW9yZSB0aGFuIG9u ZSBzdWJuZXQsIGZvciB3aGF0IGV2ZXIgcmVhc29uIGl0IG1heSBiZSBkZXNpcmVkLiAgVGhpcyBE cmFmdCBpcyBhYm91dCBlbnN1cmluZyBhIEhvc3QgaGFzIHN1ZmZpY2llbnQgYWRkcmVzc2VzIHRv IGRvIHdoYXQgd2VyZSBpdCB3YW50cyB0byBkby4gSSBiZWxpZXZlIGEgLzY0IG1vcmUgdGhhbiBm dWxmaWxscyB0aGF0IGRlc2lyZSBpbiB0aGUgY29udGV4dCBkZXNjcmliZWQgaW4gdGhlIERyYWZ0 Lg0KDQpBIGhvc3QsIHVzZXIsIHNpdGUgb3Igd2hhdGV2ZXIgd2FudGluZyBtb3JlIHRoYW4gb24g c3VibmV0IGlzIHBlcmZlY3RseSBhcHByb3ByaWF0ZSB0b28uICBIb3dldmVyLCBpdCdzIGEgZGlm ZmVyZW50IHJlcXVlc3QsIHJlcXVpcmVtZW50LCBkZXNpcmUsIG9yIGNvbnRleHQgdGhlbiBJIHRo aW5rIGlzIGJlaW5nIGRpc2N1c3NlZCBpbiB0aGlzIGRyYWZ0Lg0KDQotLQ0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkRhdmlkIEZhcm1lciAgICAgICAg ICAgICAgICAgICAgICAgICAgRW1haWw6IGZhcm1lckB1bW4uZWR1PG1haWx0bzpmYXJtZXJAdW1u LmVkdT4NCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQpVbml2ZXJzaXR5IG9mIE1p bm5lc290YQ0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAgICAgICAgIFBob25lOiArMS02MTItNjI2 LTA4MTUNCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICAgQ2VsbDogKzEtNjEyLTgxMi05OTUy DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQo= --_000_9142206A0C5BF24CB22755C8EC422E457A84EDE8AZUS1EXMB03glob_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hp Y2ggcHJlZml4ZXMgZG8geW91IGV4cGVjdCB0byBiZSBhc3NpZ25lZCB0byB0aG9zZSB0aGF0IGRl bGVnYXRlIHRoZW0/IEFyZSB5b3Ugc2F5aW5nIGV2ZXJ5IG9yZ2FuaXphdGlvbiBoYXMgdG8gb2J0 YWluIC82MyBvciBzbWFsbGVyIHByZWZpeD8gQXJlIHdlIGFwcHJvYWNoaW5nIC8zMiBJUHY0Pw0K IENhbiB5b3UgcHJvdmlkZSBhIG5ldHdvcmsgaGllcmFyY2h5IGV4YW1wbGVzIHBsZWFzZT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RHVzYW4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Ck9uIFNlcCAxNiwgMjAxNSwgYXQgMDY6NTUsIE1hcmsgU21pdGggJmx0OzxhIGhyZWY9Im1haWx0 bzptYXJrenp6c21pdGhAZ21haWwuY29tIj5tYXJrenp6c21pdGhAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+U28gdGhpcyBpcyBhZ2FpbiBnb2lu ZyBkb3duIHRoZSBwYXRoIG9mIHByb3ZpZGluZyBqdXN0IGVub3VnaCByYXRoZXIgdGhhbiBtb3Jl IHRoYW4gZW5vdWdoIGFkZHJlc3Nlcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+VmFyaWF0aW9uIGFu ZCAmcXVvdDtyaWdodCBzaXppbmcmcXVvdDsgaGFzIGEgY29zdCAtIG1vcmUgY29tcGxleGl0eSBh bmQgbGVzcyBwcmVkaWN0YWJpbGl0eSBhbmQgdGhlcmVmb3JlIGxlc3MgYWJpbGl0eSB0byBwbGFu IGFuZCBlYXNpbHkgdHJvdWJsZXNob290LiBJdCBpcyBmYXIgc2ltcGxlciB0byB3b3JrIHdpdGgg JnF1b3Q7ZXZlcnkgaG9zdCBnZXRzIGEgLzY0JnF1b3Q7LCByYXRoZXIgdGhhbiB0cnlpbmcgdG8g d29yayB3aXRoICZxdW90O2EgaG9zdCBnZXRzIHdoYXQgaXQgYXNrcw0KIGZvciwgdXAgdG8gYSAv MSAod2hpY2ggaXQgd29uJ3QgZXZlciBnZXQpLCBvciBkb3duIHRvIGEgLzEyNywgZGVwZW5kaW5n IG9uIHdoYXQgYXBwbGljYXRpb25zIGl0IGlzIHJ1bm5pbmcgYW5kIHdoYXQgdGhleSB3b3VsZCBs aWtlIG9yIG5lZWQgdG8gaGF2ZSBhdCBhbnkgcGFydGljdWxhciB0aW1lLiZxdW90Oy48bzpwPjwv bzpwPjwvcD4NCjxwPlRoZXJlIGlzIG5vIG5lZWQgZm9yICZxdW90O3JpZ2h0IHNpemluZyZxdW90 OyBpbiBJUHY2IHdoZW4gdGhlIGFkZHJlc3Mgc3BhY2UgaXMgNzMgYmlsbGlvbiBiaWxsaW9uIHRp bWVzIGxhcmdlciB0aGFuIElQdjQncy48bzpwPjwvbzpwPjwvcD4NCjxwPlJlZ2FyZHMsPGJyPg0K TWFyay48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkxldCdzIGJlIGNsZWFyLCBhIC82NCBpcyBlbm91Z2ggYWRkcmVzc2VzIGZvciBhIGhvc3QgdG8g ZG8gQU5ZVEhJTkcgaXQgY291bGQgZXZlciBwb3NzaWJsZSB3aGF0IHRvIGRvLiAmbmJzcDtBIC82 NCBpcyBvbmx5IGV2ZXIgTk9UIGVub3VnaCBpbiB0aGUgY29udGV4dCBvZiB3YW50aW5nIG1vcmUg dGhhbiBvbmUgc3VibmV0LCBmb3Igd2hhdCBldmVyIHJlYXNvbiBpdCBtYXkgYmUgZGVzaXJlZC4g Jm5ic3A7VGhpcyBEcmFmdCBpcw0KIGFib3V0IGVuc3VyaW5nIGEgSG9zdCBoYXMgc3VmZmljaWVu dCBhZGRyZXNzZXMgdG8gZG8gd2hhdCB3ZXJlIGl0IHdhbnRzIHRvIGRvLiBJIGJlbGlldmUgYSAv NjQgbW9yZSB0aGFuIGZ1bGZpbGxzIHRoYXQgZGVzaXJlIGluIHRoZSBjb250ZXh0IGRlc2NyaWJl ZCBpbiB0aGUgRHJhZnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BIGhvc3QsIHVzZXIsIHNpdGUgb3Igd2hhdGV2ZXIgd2FudGluZyBtb3JlIHRoYW4gb24g c3VibmV0IGlzIHBlcmZlY3RseSBhcHByb3ByaWF0ZSB0b28uICZuYnNwO0hvd2V2ZXIsIGl0J3Mg YSBkaWZmZXJlbnQgcmVxdWVzdCwgcmVxdWlyZW1lbnQsIGRlc2lyZSwgb3IgY29udGV4dCB0aGVu IEkgdGhpbmsgaXMgYmVpbmcgZGlzY3Vzc2VkIGluIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQgRmFybWVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0VtYWlsOiA8YSBocmVmPSJtYWlsdG86ZmFybWVyQHVtbi5lZHUiPg0KZmFybWVyQHVt bi5lZHU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5pdmVyc2l0eSBvZiBNaW5uZXNvdGEg Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUGhvbmU6ICYjNDM7MS02MTItNjI2LTA4MTU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICZuYnNw OyBDZWxsOiAmIzQzOzEtNjEyLTgxMi05OTUyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9142206A0C5BF24CB22755C8EC422E457A84EDE8AZUS1EXMB03glob_-- From nobody Wed Sep 16 07:07:50 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC99A1B3D35 for ; Wed, 16 Sep 2015 07:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV70qsjtmFMn for ; Wed, 16 Sep 2015 07:07:47 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F741B37C2 for ; Wed, 16 Sep 2015 07:07:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8GE7i84019997; Wed, 16 Sep 2015 16:07:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 75B0720316F; Wed, 16 Sep 2015 16:12:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 668F1201209; Wed, 16 Sep 2015 16:12:36 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8GE7i4G012169; Wed, 16 Sep 2015 16:07:44 +0200 To: David Farmer , Mark Smith References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> From: Alexandre Petrescu Message-ID: <55F977AF.7020701@gmail.com> Date: Wed, 16 Sep 2015 16:07:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 14:07:49 -0000 Le 16/09/2015 15:35, David Farmer a écrit : > > > > On Sep 16, 2015, at 06:55, Mark Smith > wrote: >> >> So this is again going down the path of providing just enough >> rather than more than enough addresses. >> >> Variation and "right sizing" has a cost - more complexity and less >> predictability and therefore less ability to plan and easily >> troubleshoot. It is far simpler to work with "every host gets a >> /64", rather than trying to work with "a host gets what it asks >> for, up to a /1 (which it won't ever get), or down to a /127, >> depending on what applications it is running and what they would >> like or need to have at any particular time.". >> >> There is no need for "right sizing" in IPv6 when the address space >> is 73 billion billion times larger than IPv4's. >> >> Regards, Mark. >> > Let's be clear, a /64 is enough addresses for a host to do ANYTHING > it could ever possible what to do. > > A /64 is only ever NOT enough in the context of wanting more than one > subnet, for what ever reason it may be desired. Ok, 2^64 means many addresses but only if bridged. And, at the same time, no-one will ever put 2^64 machines on a single subnet - someone will have to route to scale, which will break bridging. > This Draft is about ensuring a Host has sufficient addresses to do > what were it wants to do. In a sense yes. But the draft also says "tethering" as benefit of multiple addresses. Also draft's "Running virtual machines", "per-app addresses" - will appreciate routing instead of bridging. > I believe a /64 more than fulfills that desire in the context > described in the Draft. > > A host, user, site or whatever wanting more than on subnet is > perfectly appropriate too. However, it's a different request, > requirement, desire, or context then I think is being discussed in > this draft. I think the mechanisms are the same for multiple addresses at a site as are for multiple addresses inside a Host. Were the draft to be removed the "tethering" and the virtual machine benefits, I think it would be left with little to recommend, because the existing systems already allocate /64s to Hosts. (if we understand the same thing by "allocating". To be clear: a prefix in an RA is not allocation; and DHCPv6-PD containing a /64 means the Host must not make an address on its interface out of that /64) Alex > -- =============================================== David Farmer > Email: farmer@umn.edu Office of Information > Technology University of Minnesota 2218 University Ave SE Phone: > +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 > =============================================== > From nobody Wed Sep 16 07:16:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280271B3DB8; Wed, 16 Sep 2015 07:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chuc1cNvQaZU; Wed, 16 Sep 2015 07:16:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D611B3DBE; Wed, 16 Sep 2015 07:16:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150916141619.22801.80942.idtracker@ietfa.amsl.com> Date: Wed, 16 Sep 2015 07:16:19 -0700 Archived-At: Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 14:16:22 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination (typically the server) in ECMP load balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Sep 16 08:09:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38A01A88F9; Wed, 16 Sep 2015 08:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckU2FSbMkRcn; Wed, 16 Sep 2015 08:09:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B13F91A88C6; Wed, 16 Sep 2015 08:09:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150916150914.5645.31934.idtracker@ietfa.amsl.com> Date: Wed, 16 Sep 2015 08:09:14 -0700 Archived-At: Cc: Joel Jaeggli , Fred Baker , v6ops@ietf.org Subject: [v6ops] Benoit Claise's Yes on charter-ietf-v6ops-03-00: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 15:09:16 -0000 Benoit Claise has entered the following ballot position for charter-ietf-v6ops-03-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-v6ops/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "Future work items within this scope will be adopted by the Working Group only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF." Slightly confused by "this scope". At first glance, I thought about the entire charter, and then wonder about the meaning of "if the work clearly does not fit elsewhere in the IETF". I guess that the scope in question is the previous paragraph. Simple solution: combine the paragraph with the previous one. From nobody Wed Sep 16 12:30:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A081A0145 for ; Wed, 16 Sep 2015 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b88nu7P625hp for ; Wed, 16 Sep 2015 12:30:47 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD471A0143 for ; Wed, 16 Sep 2015 12:30:47 -0700 (PDT) Received: by padhy16 with SMTP id hy16so217391203pad.1 for ; Wed, 16 Sep 2015 12:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nestlabs.com; s=google; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=jkvoSGwsr/6h7HkbBTpKoFD9GAvAKT6aZBda1G819kY=; b=HB4UILT3ja83o/BrXM73tASEjQzHUSp2byICOPfGPNB8m+hPSgt98rTytP9oCpqLqp uiJqjtjgdLAtqcwdOU5RGPz5FhEqZGih/d23a2KXvjSO2NSs5hIPTI6+uvec9UPkDGnC f7AHD4sGJSa4iwbexsBp6TwF88oCmRpr+7/K4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=jkvoSGwsr/6h7HkbBTpKoFD9GAvAKT6aZBda1G819kY=; b=NAuS/z5aSD/aMcecAcYYioR7sGH3lKUzzKu+v6rLuu1JJNOh1tB/GT6IsIOkdPq3Px KVPSUrQGFn1fff/XERfI/HgqpyqflUr65Rlos+nBNkkJu0+FLPrjzaZS1O7Tj1wlg08W rTiRlaBOCijg2PW9Y2lXNqwfRpfvDOBxZ84vko3Hx+aafPfG3f7mpgk7GD/Yl6YxadZt QYc3jLr8rAFu2nZpmZiCmK6oCUUzEOI76j9uH3qIuvDEBt5NAf8TsBAnQgUNffcU0pYs N2NzSb1ifm1jvRdGZqkmx7nvXs5PtlNQBFhr/gkxeYh7C2tUrvxJ1og0cCyFFzZAWqe5 QA+w== X-Gm-Message-State: ALoCoQlPTpQLJfgwAxD2P9V1h1naOjN2RE21rFHaRR3uHLK6Q0A5TCGoDGU/yKaYl4B2WlHqDihRMqn13TDNmpU7LX2/AhhZqkX2xhnkAdBRAhwHo55lzhQJslA8Ca5eRb4iEqC8vjoOVDDfbaf7SYJN8jFB2riBDoYKfHRN4rzrZXUVr5t4nPU= X-Received: by 10.66.234.138 with SMTP id ue10mr63909181pac.9.1442431846609; Wed, 16 Sep 2015 12:30:46 -0700 (PDT) Received: from ?IPv6:2620::10e7:4:251d:6b3c:68e8:5f9b? ([2620:0:10e7:4:251d:6b3c:68e8:5f9b]) by smtp.gmail.com with ESMTPSA id ts1sm29281287pbc.74.2015.09.16.12.30.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 12:30:45 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_44B19991-7C9C-454C-AC12-C4A92C8B5F76" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Wed, 16 Sep 2015 12:30:44 -0700 References: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> <55F76EA7.6090405@si6networks.com> <0F1D70B7-63D3-4414-B73A-9A5FA1A76B0C@nestlabs.com> <55F8AAB1.2010406@si6networks.com> To: v6ops@ietf.org In-Reply-To: <55F8AAB1.2010406@si6networks.com> X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] "On Firewalls in Internet Security" (miscellaneous issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:30:52 -0000 --Apple-Mail=_44B19991-7C9C-454C-AC12-C4A92C8B5F76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [this is the first of my responses. another specifically discussing = IPsec will come later.] On Sep 15, 2015, at 16:33, Fernando Gont wrote: > On 09/15/2015 03:38 PM, james woodyatt wrote: >>=20 >> =E2=80=94 Section 2, Terminology: "All modern firewalls allow an >> administrator to change the policies in the firewall=E2=80=9D is not = true. >> There is an important and very common exception: RFC 6092 residential >> gateways simple security firewalls, which makes no recommendation >> allowing administrators to change policies. >=20 > That doesn't necessarily invalidate our claim: do you know of any > firewall that does not allow the fw policies to be changed? Yes. They=E2=80=99re actually pretty common in the United States. Many = ISPs provide customers with home gateways that perform RFC 6092 simple = security functions without any provision for changing the policy rules. = In some cases, there are mechanisms for changing the policy rules, but = it=E2=80=99s very rare that customers are actively made aware of them, = and they are always strongly counseled against using them. The effective = result is that firewall policies are unmanaged. > In any case, would s/all/most/ address your concern? Yes. >> =E2=80=94 Section 3.3, Building a communication: "Attacks on = infrastructure >> occur when message volume overwhelms infrastructure or uses >> infrastructure but has no obvious receiver.=E2=80=9D Normal = communications >> are possible when one or both of the sender and receiver are not >> obviously identifiable to a third party, including the network >> operator. >=20 > Not sure what you mean by "normal communications"... In the case of a = DoS scenario, that's certainly not true. Of course, I accept that denial of service attacks are not =E2=80=9Cnormal= =E2=80=9D communications. Nevertheless, it is certainly possible for a sender and a receiver to = establish normal communications, i.e. not denial of service attacks, = over clear channels that are monitored by the third parties where = neither the sender nor the receiver intend for them to have the = capability to identify who is communicating. If you want to argue that such communications cannot ever be = =E2=80=9Cnormal=E2=80=9D communications, expressly because the parties = in communication are not identifiable to the operator of an on-path = firewall, then I=E2=80=99d like you to elaborate your thoughts in light = of the following phrase in RFC 7258: =E2=80=9C...or through correlation = with other communication events, reveal information the parties did not = intend to be revealed." >> I hope I don=E2=80=99t need to defend that assertion to the authors >> of this draft. Recommend: =E2=80=9C=E2=80=A6uses infrastructure but = has no authorized >> receiver." >=20 > The term authorization tends to have a specific meaning which I'm not > sure it's applicable here. Then please add some language that attempts to clarify what = =E2=80=9Cauthorization=E2=80=9D means in the context of a zone-based = firewall. I=E2=80=99ll admit to having rather woolly-headed thoughts on = the matter, so I=E2=80=99ll leave it to you how best to illustrate it. =E2=80=94james --Apple-Mail=_44B19991-7C9C-454C-AC12-C4A92C8B5F76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[this is the first of my responses. another = specifically discussing IPsec will come later.]

On Sep 15, 2015, at 16:33, Fernando Gont <fgont@si6networks.com> wrote:
On 09/15/2015 03:38 = PM, james woodyatt wrote:

=E2=80=94 Section 2, = Terminology: "All modern firewalls allow an
administrator = to change the policies in the firewall=E2=80=9D is not true.
There is an important and very common exception: RFC 6092 = residential
gateways simple security firewalls, which = makes no recommendation
allowing administrators to change = policies.

That doesn't necessarily invalidate our claim: = do you know of any
firewall that does not = allow the fw policies to be changed?

Yes. They=E2=80=99re actually pretty common in the = United States. Many ISPs provide customers with home gateways that = perform RFC 6092 simple security functions without any provision for = changing the policy rules. In some cases, there are mechanisms for = changing the policy rules, but it=E2=80=99s very rare that customers are = actively made aware of them, and they are always strongly counseled = against using them. The effective result is that firewall policies are = unmanaged.

In any case, would = s/all/most/ address your concern?

Yes.

=E2=80=94 = Section 3.3, Building a communication: "Attacks on infrastructure
occur when message volume = overwhelms infrastructure or uses
infrastructure but has = no obvious receiver.=E2=80=9D Normal communications
are = possible when one or both of the sender and receiver are not
obviously identifiable to a third party, including the = network
operator.

Not sure what you mean by "normal = communications"... In the case of a DoS scenario, that's certainly not true.

Of course, = I accept that denial of service attacks are not =E2=80=9Cnormal=E2=80=9D = communications.

Nevertheless, it is = certainly possible for a sender and a receiver to establish normal = communications, i.e. not denial of service attacks, over clear channels = that are monitored by the third parties where neither the sender nor the = receiver intend for them to have the capability to identify who is = communicating.

If you want to argue = that such communications cannot ever be =E2=80=9Cnormal=E2=80=9D = communications, expressly because the parties in communication are not = identifiable to the operator of an on-path firewall, then I=E2=80=99d = like you to elaborate your thoughts in light of the following phrase in = RFC 7258: =E2=80=9C...or through correlation with other communication = events, reveal information the parties did not intend to be = revealed."

I hope I don=E2=80=99t need to defend that assertion to = the authors
of this draft. Recommend: =E2=80=9C=E2=80=A6uses= infrastructure but has no authorized
receiver."

The term authorization = tends to have a specific meaning which I'm not
sure it's applicable here.

Then please = add some language that attempts to clarify what =E2=80=9Cauthorization=E2=80= =9D means in the context of a zone-based firewall. I=E2=80=99ll admit to = having rather woolly-headed thoughts on the matter, so I=E2=80=99ll = leave it to you how best to illustrate it.

=E2=80=94james

= --Apple-Mail=_44B19991-7C9C-454C-AC12-C4A92C8B5F76-- From nobody Wed Sep 16 12:44:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7211A01F4 for ; Wed, 16 Sep 2015 12:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6dZtatrtXBF for ; Wed, 16 Sep 2015 12:44:26 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3A11A01F2 for ; Wed, 16 Sep 2015 12:44:26 -0700 (PDT) Received: from r186-50-223-88.dialup.adsl.anteldata.net.uy ([186.50.223.88] helo=[10.1.29.73]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZcIcw-0006WC-KL; Wed, 16 Sep 2015 21:44:23 +0200 To: james woodyatt , v6ops@ietf.org References: <20150915004941.13204.35415.idtracker@ietfa.amsl.com> <55F76EA7.6090405@si6networks.com> <0F1D70B7-63D3-4414-B73A-9A5FA1A76B0C@nestlabs.com> <55F8AAB1.2010406@si6networks.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <55F9C69A.90100@si6networks.com> Date: Wed, 16 Sep 2015 16:44:26 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] "On Firewalls in Internet Security" (miscellaneous issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:44:29 -0000 Hi, James, Thanks so much for your prompt response! -- Please find my comments in-line... On 09/16/2015 04:30 PM, james woodyatt wrote: > [this is the first of my responses. another specifically discussing > IPsec will come later.] > > On Sep 15, 2015, at 16:33, Fernando Gont > wrote: >> On 09/15/2015 03:38 PM, james woodyatt wrote: >>> >>> — Section 2, Terminology: "All modern firewalls allow an >>> administrator to change the policies in the firewall” is not true. >>> There is an important and very common exception: RFC 6092 residential >>> gateways simple security firewalls, which makes no recommendation >>> allowing administrators to change policies. >> >> That doesn't necessarily invalidate our claim: do you know of any >> firewall that does not allow the fw policies to be changed? > > Yes. They’re actually pretty common in the United States. Many ISPs > provide customers with home gateways that perform RFC 6092 simple > security functions without any provision for changing the policy rules. > In some cases, there are mechanisms for changing the policy rules, but > it’s very rare that customers are actively made aware of them, and they > are always strongly counseled against using them. The effective result > is that firewall policies are unmanaged. > >> In any case, would s/all/most/ address your concern? > > Yes. I've applied this change in my working copy of the I-D. >>> — Section 3.3, Building a communication: "Attacks on infrastructure >>> occur when message volume overwhelms infrastructure or uses >>> infrastructure but has no obvious receiver.” Normal communications >>> are possible when one or both of the sender and receiver are not >>> obviously identifiable to a third party, including the network >>> operator. >> >> Not sure what you mean by "normal communications"... In the case of a >> DoS scenario, that's certainly not true. > > Of course, I accept that denial of service attacks are not “normal” > communications. > > Nevertheless, it is certainly possible for a sender and a receiver to > establish normal communications, i.e. not denial of service attacks, > over clear channels that are monitored by the third parties where > neither the sender nor the receiver intend for them to have the > capability to identify who is communicating. What we meant here is that at times DoS attacks can be launched with packets that e.g. target non-existing addresses. So, if you're receiving a flood od packets to an address in your network that you know that doesn't exist, you can filter such traffic. > If you want to argue that such communications cannot ever be “normal” > communications, expressly because the parties in communication are not > identifiable to the operator of an on-path firewall, No. That's certainly not what we meant. >>> I hope I don’t need to defend that assertion to the authors >>> of this draft. Recommend: “…uses infrastructure but has no authorized >>> receiver." >> >> The term authorization tends to have a specific meaning which I'm not >> sure it's applicable here. > > Then please add some language that attempts to clarify what > “authorization” means in the context of a zone-based firewall. I’ll > admit to having rather woolly-headed thoughts on the matter, so I’ll > leave it to you how best to illustrate it. Point taken. Will try to improve this. 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 Wed Sep 16 19:56:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245FE1ACD8B for ; Wed, 16 Sep 2015 19:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFE7rw6zIJgj for ; Wed, 16 Sep 2015 19:56:35 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id DEE7A1ACDA8 for ; Wed, 16 Sep 2015 19:56:34 -0700 (PDT) Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id t8H2uWnY005860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Sep 2015 19:56:33 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_0871E4C5-471C-40CB-819B-542315FE9972" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Owen DeLong In-Reply-To: <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> Date: Wed, 16 Sep 2015 19:56:31 -0700 Message-Id: <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 02:56:37 -0000 --Apple-Mail=_0871E4C5-471C-40CB-819B-542315FE9972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 16, 2015, at 06:35 , David Farmer wrote: >=20 >=20 >=20 >=20 > On Sep 16, 2015, at 06:55, Mark Smith > wrote: >> So this is again going down the path of providing just enough rather = than more than enough addresses. >>=20 >> Variation and "right sizing" has a cost - more complexity and less = predictability and therefore less ability to plan and easily = troubleshoot. It is far simpler to work with "every host gets a /64", = rather than trying to work with "a host gets what it asks for, up to a = /1 (which it won't ever get), or down to a /127, depending on what = applications it is running and what they would like or need to have at = any particular time.". >>=20 >> There is no need for "right sizing" in IPv6 when the address space is = 73 billion billion times larger than IPv4's. >>=20 >> Regards, >> Mark. >>=20 > Let's be clear, a /64 is enough addresses for a host to do ANYTHING it = could ever possible what to do. A /64 is only ever NOT enough in the = context of wanting more than one subnet, for what ever reason it may be = desired. This Draft is about ensuring a Host has sufficient addresses = to do what were it wants to do. I believe a /64 more than fulfills that = desire in the context described in the Draft. >=20 Everyone here knows that I am a pretty big fan of profligate address = distribution. Having said that, I oppose the recommendation to assign a /64 or shorter = to every host required to get addressing via DHCP. Few hosts would be able to fully utilize even a /32. However, few = networks can support as many as 65,536 hosts. As such, I would like to advocate that a reasonable tradeoff if we are = using DHCP-PD to assign addresses to hosts that the host is _NOT_ = expected to delegate downstream would be to assign a /80 from the /64 = shared on the media segment or a /64 if it is an isolated media segment. In this way, the host can manage 64 billion+ addresses as it sees fit = and up the subnet still has plenty of chunks for all the likely hosts. If more than one subnet is needed, then multiple /64s should be assigned = accordingly. If an entire subnet is needed, then I support assigning a = /64. If we=E2=80=99re talking about (e.g.) VMs in a datacenter, I think this = hybrid /80 approach represents a reasonable tradeoff in many = circumstances. Owen --Apple-Mail=_0871E4C5-471C-40CB-819B-542315FE9972 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 16, 2015, at 06:35 , David Farmer <farmer@umn.edu> = wrote:



On Sep 16, 2015, at = 06:55, Mark Smith <markzzzsmith@gmail.com> wrote:

So this is again going down the path of providing just enough = rather than more than enough addresses.

Variation and "right sizing" has a cost - more complexity and = less predictability and therefore less ability to plan and easily = troubleshoot. It is far simpler to work with "every host gets a /64", = rather than trying to work with "a host gets what it asks for, up to a = /1 (which it won't ever get), or down to a /127, depending on what = applications it is running and what they would like or need to have at = any particular time.".

There is no need for = "right sizing" in IPv6 when the address space is 73 billion billion = times larger than IPv4's.

Regards,
Mark.

Let's be clear, a /64 is enough = addresses for a host to do ANYTHING it could ever possible what to do. =  A /64 is only ever NOT enough in the context of wanting more than = one subnet, for what ever reason it may be desired.  This Draft is = about ensuring a Host has sufficient addresses to do what were it wants = to do. I believe a /64 more than fulfills that desire in the context = described in the Draft.


Everyone here knows that I am a pretty big fan of = profligate address distribution.

Having said that, I oppose the recommendation to = assign a /64 or shorter to every host required to get addressing via = DHCP.

Few hosts would be able to = fully utilize even a /32. However, few networks can support as many as = 65,536 hosts.

As such, I would like = to advocate that a reasonable tradeoff if we are using DHCP-PD to assign = addresses to hosts that the host is _NOT_ expected to delegate = downstream would be to assign a /80 from the /64 shared on the media = segment or a /64 if it is an isolated media segment.

In this way, the host can manage 64 billion+ = addresses as it sees fit and up the subnet still has plenty of chunks = for all the likely hosts.

If more = than one subnet is needed, then multiple /64s should be assigned = accordingly. If an entire subnet is needed, then I support assigning a = /64.

If we=E2=80=99re talking about = (e.g.) VMs in a datacenter, I think this hybrid /80 approach represents = a reasonable tradeoff in many circumstances.

Owen

= --Apple-Mail=_0871E4C5-471C-40CB-819B-542315FE9972-- From nobody Wed Sep 16 20:16:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EDA1ACD86 for ; Wed, 16 Sep 2015 20:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtOa3kPzP9WT for ; Wed, 16 Sep 2015 20:15:51 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::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 27E811ACD7E for ; Wed, 16 Sep 2015 20:15:51 -0700 (PDT) Received: by ykdu9 with SMTP id u9so5584218ykd.2 for ; Wed, 16 Sep 2015 20:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b0NhKPTm3+PlrR5H9iRaKtPARcAq1197pSTFkjIUnP8=; b=nNnmiJQrKq0aTLBSqe8qgTL5t2iF6Z4U880QTRCsMw2guWic/inLK6aPR/oh6HGFaq QqUUmJvp46LC0Hg3TW3IUmnrWmLZSOKSKKyltsP0ci3ERDbclYeh+PK6a5uwmXjJULtk gCBZ1e5yWOLgQytHW9TGGnhZpdD+4SMf2HMouJmbH5TjTJTV0/T1ib0uRFb9cCDIiRsN GDgY67N/bUsT/KJ1lKtS5L8M4QEcatH2DXFUysNdulOw5UK1orF354/egWVEz/5AWmaV R7Q5tI0JyDV1sFBNfhtmZlMGgWAPC7K4bj3K+QIS8LythP6pVlc1G4vhW75vUE3C+Tj0 c5eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b0NhKPTm3+PlrR5H9iRaKtPARcAq1197pSTFkjIUnP8=; b=FIvWL9GZk+I2DatnstpZueRkj6clcqebUTocwLeEV8hiVM0L2YeeJh4fvwTVQQ//ps fDVFfW6VcscbfzXmWPdFatoroBc9aAPhRz1F/9cKQvPJ328QuVoCkZXdFJrXFkxSy/y5 Ga+nllAx8xzKFvc0H2MvQlKfcbUeVgawIn7sln8xur0k8OnqRL8SK7e11LVpf3+M9TNP JhHPRtIqTmGnvu851b1prOTe0yk9No5ySFbkd0GvgIXSAFuDzpzWOOVddMDTA5GgJzyy kqndJWatB4ATgvvcxM5xpcgFpG3vYN3MK/5qUTdP1UdSAq5rMyKIiN6/b2AiiwN2PB2i SIAQ== X-Gm-Message-State: ALoCoQnsy216FmzXr/HzppSwok6PlHlYxeXF7p+U+3yZmznpngARKALbPY9QY7Dhv5saIVM2O6Vx X-Received: by 10.129.16.212 with SMTP id 203mr32924713ywq.142.1442459750337; Wed, 16 Sep 2015 20:15:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Wed, 16 Sep 2015 20:15:30 -0700 (PDT) In-Reply-To: <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> From: Lorenzo Colitti Date: Thu, 17 Sep 2015 12:15:30 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=001a1142cd3405d1d1051fe8d525 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 03:15:52 -0000 --001a1142cd3405d1d1051fe8d525 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 17, 2015 at 11:56 AM, Owen DeLong wrote: > As such, I would like to advocate that a reasonable tradeoff if we are > using DHCP-PD to assign addresses to hosts that the host is _NOT_ expected > to delegate downstream would be to assign a /80 from the /64 shared on the > media segment or a /64 if it is an isolated media segment. > The problem with using something smaller than /64 is as follows. Statefully allocating something smaller than /64 (let's use /80 as in your example) forces any devices that wishes to provide downstream connectivity (e.g., to VMs, tethered devices, etc) to use stateful address assigment - presumably using DHCPv6 PD. Because those hosts may well be general-purpose hosts, then that means that general-purpose hosts need to accept arbitrarily small prefixes. The reason is as follows: If I connect my laptop to a network and get a /80, then I can't give a VM or a tethered device more space than, say, a /88. That in turn forces any devices that wish to operate downstream to support stateful address assignment and accept a prefix size of /88. That means that if a network assigns a device a /88, then it will accept that prefix, but it will be unable to provide any downstream connectivity, and will be forced to implement NAT66 if it wishes to do so. I think any value that is /64 or smaller has this problem. /64 does not because it allows a device to use non-hierarchical means (such as bridging and SLAAC) to extend the network. --001a1142cd3405d1d1051fe8d525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 17, 2015 at 11:56 AM, Owen DeLong <owen@delong.com> wr= ote:
As such, = I would like to advocate that a reasonable tradeoff if we are using DHCP-PD= to assign addresses to hosts that the host is _NOT_ expected to delegate d= ownstream would be to assign a /80 from the /64 shared on the media segment= or a /64 if it is an isolated media segment.
=
The problem with using something smaller than /64 is as foll= ows.

Statefully allocating something smaller than = /64 (let's use /80 as in your example) forces any devices that wishes t= o provide downstream connectivity (e.g., to VMs, tethered devices, etc) to = use stateful address assigment - presumably using DHCPv6 PD.=C2=A0Because t= hose hosts may well be general-purpose hosts, then that means that general-= purpose hosts need to accept arbitrarily small prefixes.

The reason is as follows: If I connect my laptop to a network and ge= t a /80, then I can't give a VM or a tethered device more space than, s= ay, a /88. That in turn forces any devices that wish to operate downstream = to support stateful address assignment and accept a prefix size of /88. Tha= t means that if a network assigns a device a /88, then it will accept that = prefix, but it will be unable to provide any downstream connectivity, and w= ill be forced to implement NAT66 if it wishes to do so.

I think any value that is /64 or smaller has this problem. /64 does n= ot because it allows a device to use non-hierarchical means (such as bridgi= ng and SLAAC) to extend the network.
--001a1142cd3405d1d1051fe8d525-- From nobody Wed Sep 16 20:17:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD721ACE65 for ; Wed, 16 Sep 2015 20:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkNGOBeWEuAm for ; Wed, 16 Sep 2015 20:17:22 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10A81ACD90 for ; Wed, 16 Sep 2015 20:17:21 -0700 (PDT) Received: by ykdt18 with SMTP id t18so5568607ykd.3 for ; Wed, 16 Sep 2015 20:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TSQY150s51rSuoqUeOd10WaBJ5lF7VdcAg3AZ90DOZ4=; b=Hty0fQTktkJ3XVKd/SEU3s00WmbqALca4JoHxypj9hfWNc87/Yg2pmnsfmb5W3gffN VVGEFIGtqER9CMs7kH84u2CfoQtrOZ8ARGy9MHpb6KFHf3rrT60HefUJQVKQ9OFRX+ui GGQAvn6wqDoib0rAzQ+KkW06puRLIfweHdtk/6Eap2Zg+kE0j0fJo/0N0vlcWT9W588l icj9UvmJTgavgRI0cOARbG803UQcdeqtrwaApagVeA0cPBduZ92Tz5dsuyg9CZmsWI7f et9BeFRa0iQDaNugbq3/pl/EqB5tEStD0bM1mxjtEbSD25EQXBGW41bE9pOQY+XiFN7E C+Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TSQY150s51rSuoqUeOd10WaBJ5lF7VdcAg3AZ90DOZ4=; b=NOKC8tJvBzivOriFKFHtYw4Gh5MSSLN/YZqxsPNM4uPYPH9zTt9g680YZebh/aqX/o Ph1xrjuxMaJu/et6BrsjCMooILCXNKn5E+k2mznXb23Yn2G4cu3yWPog1B/oGli6THKf zvoxSXKi/RKMUbkuANRmCcudvQ3T0kFUHphnRYuDxb0Ku4GR1Wv6ZFgUJdlxCQupPx5C KG5wlHBSKUttbezlLS9A/IcoOpqbruWKDS1NN4oHuC/trtrURDCkFky7y1jPR3xEIvNz MdK0c7OIVyKiHHM06+DSQAUofWRURf9aHnwTIgEC6ExWgq8DQS6Bgi+yT5d7XPnT84QK febw== X-Gm-Message-State: ALoCoQnqjk24nkev+a7aPHnBsYXfru49YJ9d+eIn15B+YHfZ3XwEQV80MLEYMVlFe3jUAW431c1t X-Received: by 10.170.122.88 with SMTP id o85mr32226602ykb.119.1442459840962; Wed, 16 Sep 2015 20:17:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Wed, 16 Sep 2015 20:17:01 -0700 (PDT) In-Reply-To: <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> From: Lorenzo Colitti Date: Thu, 17 Sep 2015 12:17:01 +0900 Message-ID: To: Owen DeLong Content-Type: multipart/alternative; boundary=001a1137cd2e6cdf2a051fe8daaa Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 03:17:22 -0000 --001a1137cd2e6cdf2a051fe8daaa Content-Type: text/plain; charset=UTF-8 On Thu, Sep 17, 2015 at 11:56 AM, Owen DeLong wrote: > As such, I would like to advocate that a reasonable tradeoff if we are > using DHCP-PD to assign addresses to hosts that the host is _NOT_ expected > to delegate downstream > Expected by who? By the owner of the host? By the administrator of the DHCPv6 server? By someone else? Those expectations may well be different. --001a1137cd2e6cdf2a051fe8daaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 17, 2015 at 11:56 AM, Owen DeLong <owen@delong.com> wr= ote:
=
As such, I would like to advocate that a reasonable tradeoff if we are= using DHCP-PD to assign addresses to hosts that the host is _NOT_ expected= to delegate downstream

Expecte= d by who? By the owner of the host? By the administrator of the DHCPv6 serv= er? By someone else? Those expectations may well be different.
<= /div>
--001a1137cd2e6cdf2a051fe8daaa-- From nobody Wed Sep 16 21:12:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA741B2AF0 for ; Wed, 16 Sep 2015 21:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4jtOLXSTePK for ; Wed, 16 Sep 2015 21:12:20 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DF01B2ABA for ; Wed, 16 Sep 2015 21:12:20 -0700 (PDT) Received: by padhy16 with SMTP id hy16so8370702pad.1 for ; Wed, 16 Sep 2015 21:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=oz3Z4QRB1Ag/GGMUIK+6bIYJDckRMjRqJ4jEvs7jFPs=; b=kTBKD40ENPaESyLUy6gj4JnpT3iFReCIz+J5SG+M0v3YJmSnLvG7dB+7ISOLWCKtbb Ubeg3Lt3GYz4AcOaZv5LTwpf9lSIF8/GT5SSzTGDew7C9YklER3ULMS8d/OLe8hZB+Dp agMQG+Qdq1YnsnDw438CS8GhEH/UCmx1/KDPGq3Gnle7852UQeRXW7/kP2p6Gov0l+Eh 4PqQ2WiJT8VZghHbf+D/qkdeTdA8MuyWykt8FbKV6lH/Z2vJS9xtEauk2rCXdbG1XfhB FSUficQxQE33zej3wcp+xudXHdyDjNx9R31Qbfxby8wVsbKq55Tg7N+IfFrOyhRMTqru qsNA== X-Received: by 10.66.191.131 with SMTP id gy3mr66777548pac.113.1442463139659; Wed, 16 Sep 2015 21:12:19 -0700 (PDT) Received: from [192.168.178.25] ([163.47.220.238]) by smtp.gmail.com with ESMTPSA id a17sm1010303pbu.55.2015.09.16.21.12.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2015 21:12:18 -0700 (PDT) To: Lorenzo Colitti , Owen DeLong References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55FA3DA8.5090808@gmail.com> Date: Thu, 17 Sep 2015 16:12:24 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 04:12:22 -0000 On 17/09/2015 15:15, Lorenzo Colitti wrote: > On Thu, Sep 17, 2015 at 11:56 AM, Owen DeLong wrote: > >> As such, I would like to advocate that a reasonable tradeoff if we are >> using DHCP-PD to assign addresses to hosts that the host is _NOT_ expected >> to delegate downstream would be to assign a /80 from the /64 shared on the >> media segment or a /64 if it is an isolated media segment. >> > > The problem with using something smaller than /64 is as follows. And is a major topic of RFC 7421. Brian > > Statefully allocating something smaller than /64 (let's use /80 as in your > example) forces any devices that wishes to provide downstream connectivity > (e.g., to VMs, tethered devices, etc) to use stateful address assigment - > presumably using DHCPv6 PD. Because those hosts may well be general-purpose > hosts, then that means that general-purpose hosts need to accept > arbitrarily small prefixes. > > The reason is as follows: If I connect my laptop to a network and get a > /80, then I can't give a VM or a tethered device more space than, say, a > /88. That in turn forces any devices that wish to operate downstream to > support stateful address assignment and accept a prefix size of /88. That > means that if a network assigns a device a /88, then it will accept that > prefix, but it will be unable to provide any downstream connectivity, and > will be forced to implement NAT66 if it wishes to do so. > > I think any value that is /64 or smaller has this problem. /64 does not > because it allows a device to use non-hierarchical means (such as bridging > and SLAAC) to extend the network. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 16 21:52:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FAE1B30DC for ; Wed, 16 Sep 2015 21:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FJWiKTq59ep for ; Wed, 16 Sep 2015 21:52:40 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EB81B304D for ; Wed, 16 Sep 2015 21:52:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9C359A1; Thu, 17 Sep 2015 06:52:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442465556; bh=Xp+SoUfktgEM+xU/QNxsrufmsZidIVujoy9REXMcR9Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=OjeNRfCsOS/407VBk3Y7JdVfnQShymUJvtLC2xCGUSqPSStPDNBlzpKQjVQXOfJLG Lt83gH8+Bo9bquIHa4GxztHdsV7LbIfUOXyvNIxZkd8nsExqXW97960NEm8jZwaj27 2ZPR3h6ozuyjtR+gz5WyAV6UQnPGB05W2rWAtlRE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 91F559F; Thu, 17 Sep 2015 06:52:36 +0200 (CEST) Date: Thu, 17 Sep 2015 06:52:36 +0200 (CEST) From: Mikael Abrahamsson To: fred@cisco.com In-Reply-To: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 04:52:43 -0000 On Sun, 13 Sep 2015, fred@cisco.com wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. I have re-read the document as if I never read it before. This is an important and valuable document, and I would like it to proceed as intended. However, I have concerns regarding section 9, operational considerations. I feel that it should either be expanded with more information (and there is a lot to discuss I believe), or it should refer to other documents that might already have this information/discussion. Right now it seems to me that if someone reads this document that do not have prior experience here, it'll leave them either disagreeing with the text because they don't have the background and their actual background experience might oppose the text in here, and there are no pointers to other documents that might have this information. There might also be current use-cases that is not brought up in the operational considerations as it stands today. This document also brings up the whole "cascaded DHCPv6-PD tree structure" (what if you're running a VM that requests DHCPv6-PD from a host that has received DHCPv6-PD /64 from the network) but doesn't really give any guidance on the issue... Lorenzo posted on the list that if you have a /64 you can PD a /80 to each VM etc. This absolutely makes sense, but I am not aware of any document that actually looks into this more deeply? I remember Fred B saying we didn't have any text on this when I spoke at the mic at IETF75, my first IETF, and I still haven't seen any real text giving recommendations on the subject. Also, the document talks about giving /64 to hosts. It seems to me that the whole "what is a host, what is a router" distinction is going away, and almost everything is becoming a router of some kind. This is just normal progression of technology and this document already has text on cases where this is happening, but would it make sense to include a paragraph somewhere on the terminology and what is meant? Just for someone who might make a hard distinction between hosts and routers (I do not, but I've encountered people who seems to do that). So just to be clear, I do not oppose anything in the document, I think the document contains a lot of valuable information and I do not oppose the document moving forward, and it might just be more important to get the document out the door and create documents that discuss my above concerns separately at a later date. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 17 01:13:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7C1AD0AF for ; Thu, 17 Sep 2015 01:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9yfRd9pdtHF for ; Thu, 17 Sep 2015 01:12:59 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D731AD0C5 for ; Thu, 17 Sep 2015 01:12:54 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E8BB8A1; Thu, 17 Sep 2015 10:12:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442477570; bh=E6FCaGZTvNKhZhGXmy/1VAOsK23RJhJ3Es7vX/ndT7s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1n4XHimszY4O2b/dVTg4eLx1/znnhtoEWgRy8RdIPqiESkW77WJpowagyFJvGSVVS tqw6FLH4UXz9q9QZ1sjJJ/CxNK0zW5BdaINOqvJlzSynJNcNCe0TTH9ISqV3gGQzyz hxhtfm1xepvSkhBqbu64VCIYooKOUcQCKS8RMOIU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E1D339F; Thu, 17 Sep 2015 10:12:50 +0200 (CEST) Date: Thu, 17 Sep 2015 10:12:50 +0200 (CEST) From: Mikael Abrahamsson To: Fernando Gont In-Reply-To: <55E4FCB6.8040407@gont.com.ar> Message-ID: References: <55E4FCB6.8040407@gont.com.ar> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: draft-gont-v6ops-ipv6-ehs-packet-drops@tools.ietf.org, IPv6 Operations Subject: Re: [v6ops] Why operators filter IPv6 packets with extension headers? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 08:13:02 -0000 On Mon, 31 Aug 2015, Fernando Gont wrote: > Folks, > > The topic of operators dropping IPv6 packets containing extension > headers has been raised quite a few times on this list and elsewhere. > > A month ago or so we published a document trying to summarize the > reasons for which operators filter IPv6 packets containing extension > headers. The document is available at: > > > We're currently working on a revision of this document, and would like > to hear feedback from the working group regarding our document. e.g., > > * Did we get anything wrong? > * Is there anything missing? > > Or, if you like the document and agree with its content, that's also > interesting feedback to have. I find this document useful and agree with the content. I think you have been able to remove most of the mentions of "filtering" when intent isn't there, but there is still one in the security considerations section (at least that's my opinion). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 17 06:45:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E581B2FAC for ; Thu, 17 Sep 2015 06:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDNj7M88LbkQ for ; Thu, 17 Sep 2015 06:45:11 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEFD1B2FF2 for ; Thu, 17 Sep 2015 06:45:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8HDj6hO000751 for ; Thu, 17 Sep 2015 15:45:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 303B2203353 for ; Thu, 17 Sep 2015 15:49:59 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1E6B420323F for ; Thu, 17 Sep 2015 15:49:59 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8HDj5XN014904 for ; Thu, 17 Sep 2015 15:45:06 +0200 To: v6ops@ietf.org References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> From: Alexandre Petrescu Message-ID: <55FAC3E1.3020206@gmail.com> Date: Thu, 17 Sep 2015 15:45:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 13:45:13 -0000 [...] > As such, I would like to advocate that a reasonable tradeoff if we are > using DHCP-PD to assign addresses to hosts DHCP-PD can not be used to assign addresses to Hosts. If you want to do that then you must come up with a mechanism for the Host to form an IP address out of an Interface ID and the prefix allocated by DHCP-PD. Right now there is no such mechanism AFAIK. Alex that the host is _NOT_ > expected to delegate downstream would be to assign a /80 from the /64 > shared on the media segment or a /64 if it is an isolated media segment. > > In this way, the host can manage 64 billion+ addresses as it sees fit > and up the subnet still has plenty of chunks for all the likely hosts. > > If more than one subnet is needed, then multiple /64s should be assigned > accordingly. If an entire subnet is needed, then I support assigning a /64. > > If we’re talking about (e.g.) VMs in a datacenter, I think this hybrid > /80 approach represents a reasonable tradeoff in many circumstances. > > Owen > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Sep 17 06:49:27 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C913E1B2FDD for ; Thu, 17 Sep 2015 06:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2qZulknNVU3 for ; Thu, 17 Sep 2015 06:49:25 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58F31B2FAC for ; Thu, 17 Sep 2015 06:49:25 -0700 (PDT) Received: by ykdu9 with SMTP id u9so17028775ykd.2 for ; Thu, 17 Sep 2015 06:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0GYe3chSSaNH0tzGA3wcMqnRoXqoAv2U5oSqEAB49AU=; b=L3lEafToMhA237i/Ah+aQHwaIEhg/y5P/0pdoM9bz4Gpowj5OReEpUN5yLV3Z/3sz/ FPqgRu5iEDFb4hYK6fKIWBs/OIKgbQcXpJ7dfLEWmXzlocwBrh9yw4UJ1hq+V/7uSHdi zByiyyhnsHuzuAPZMlSk0davE5A3geucv88Yn16CXHua7vtoEUqLRuiz7VS2ncvucCdA quSHwT3TAPTxu24bZv6U6WxADL4/f1udTUhPfROQ24NmNIdGODgPjRBHY3eigJFAeeA3 9DJNPqH/LhLO08jYtDnJ+AX8swnxGBPS16+K++RXEZrXPUjS0b7dabx+GZnCPrgf2H1j PaLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0GYe3chSSaNH0tzGA3wcMqnRoXqoAv2U5oSqEAB49AU=; b=mQIVq2P5E4xdBgQQK5m29ojUXzGh6fo5tuR9IuwystPr14y+dE+BpwwCuvdchOvFtP Obbn8P9oBEqut34Ps1RErcR4AQ329LiYoSjN8R8PoviebTV0l2URhiTdvtUnyxEey7Wa bmgnePn8aLkbFaVEw+OU19cKfxLfL9jI2qvIYHBn72udg7KRza9bcIKVwR1gtc30vWBP VCBBG09raw4A522gEOROI8HLk+prlSp5wosEHrgq9Byqzyzs/PH7sWCjdM9wKgHiNr9r YwnpqT3eBWqIi/AzKt+TUHs0cYfpKUkTJHQK/kAq/tox6tash5pNe/wgJcRSQHSr9VYk fi/w== X-Gm-Message-State: ALoCoQkD3ta1XWJbqxz5kA4WPppssdnUM0SiVDuUgAP5IXT2pDEt0EYAwva/o2UzcGc2VVgBSROT X-Received: by 10.13.254.3 with SMTP id o3mr34164969ywf.161.1442497764932; Thu, 17 Sep 2015 06:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Thu, 17 Sep 2015 06:49:05 -0700 (PDT) In-Reply-To: <55FAC3E1.3020206@gmail.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> <55FAC3E1.3020206@gmail.com> From: Lorenzo Colitti Date: Thu, 17 Sep 2015 22:49:05 +0900 Message-ID: To: Alexandre Petrescu Content-Type: multipart/alternative; boundary=94eb2c054c90dec3ab051ff1ae9e Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 13:49:27 -0000 --94eb2c054c90dec3ab051ff1ae9e Content-Type: text/plain; charset=UTF-8 On Thu, Sep 17, 2015 at 10:45 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > DHCP-PD can not be used to assign addresses to Hosts. > > If you want to do that then you must come up with a mechanism for the Host > to form an IP address out of an Interface ID and the prefix allocated by > DHCP-PD. Right now there is no such mechanism AFAIK. > If the whole prefix is assigned to the host, there is no need to specify a mechanism. The host can just pick whatever address it wants. There is precedent for this in RFC 7084: ... it MUST create a global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces ... --94eb2c054c90dec3ab051ff1ae9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 17, 2015 at 10:45 PM, Alexandre Petrescu <alexandre.pet= rescu@gmail.com> wrote:
DHCP-PD can not b= e used to assign addresses to Hosts.

If you want to do that then you must come up with a mechanism for the Host = to form an IP address out of an Interface ID and the prefix allocated by DH= CP-PD.=C2=A0 Right now there is no such mechanism AFAIK.

If the whole prefix is assigned to the host, there is no = need to specify a mechanism. The host can just pick whatever address it wan= ts.

There is precedent for this in RFC 7084:
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ... it MUST c= reate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a global IPv6= address(es) from its delegated prefix(es) and
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 configure those on one of its internal virtual net= work
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interfaces ...
=
--94eb2c054c90dec3ab051ff1ae9e-- From nobody Thu Sep 17 06:58:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EDD1B3005 for ; Thu, 17 Sep 2015 06:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRfqMoVuHn1F for ; Thu, 17 Sep 2015 06:58:12 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D9D1B2FCA for ; Thu, 17 Sep 2015 06:58:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8HDw9am004611 for ; Thu, 17 Sep 2015 15:58:09 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 99D6C203335 for ; Thu, 17 Sep 2015 16:03:02 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 91DE3201CE8 for ; Thu, 17 Sep 2015 16:03:02 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8HDw8Ma022847 for ; Thu, 17 Sep 2015 15:58:09 +0200 To: v6ops@ietf.org References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> From: Alexandre Petrescu Message-ID: <55FAC6F0.5040601@gmail.com> Date: Thu, 17 Sep 2015 15:58:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 13:58:15 -0000 Le 17/09/2015 05:15, Lorenzo Colitti a écrit : > On Thu, Sep 17, 2015 at 11:56 AM, Owen DeLong > wrote: > > As such, I would like to advocate that a reasonable tradeoff if we > are using DHCP-PD to assign addresses to hosts that the host is _NOT_ > expected to delegate downstream would be to assign a /80 from the /64 > shared on the media segment or a /64 if it is an isolated media > segment. > > > The problem with using something smaller than /64 is as follows. WE definitely must use common terminology. A "smaller than /64" prefix is a prefix containing less addresses, i.e. a "larger than 64" prefix length? > Statefully allocating something smaller than /64 (let's use /80 as in > your example) forces any devices that wishes to provide downstream > connectivity (e.g., to VMs, tethered devices, etc) to use stateful > address assigment - presumably using DHCPv6 PD. Statefully allocating a prefix whose len is larger than 64 forces any device wishing to provide tethered connectivity to employ stateful address assignment e.g. DHCP also on its downstream. Because the only way common Hosts (common: on Ethernet and keen kinds of links links, with built-in SLAAC) can connect to this device is by involving an Interface ID of length precisely 64 RFC2464. Any prefix len larger than 64 added to that Interface ID 64 will overflow the 128bit size of the IPv6 addresses. > Because those hosts may well be general-purpose hosts, then that > means that general-purpose hosts need to accept arbitrarily small > prefixes. > > The reason is as follows: If I connect my laptop to a network and get > a /80, then I can't give a VM or a tethered device more space than, > say, a /88. That in turn forces any devices that wish to operate > downstream to support stateful address assignment and accept a prefix > size of /88. That means that if a network assigns a device a /88, > then it will accept that prefix, but it will be unable to provide any > downstream connectivity, and will be forced to implement NAT66 if it > wishes to do so. > > I think any value that is /64 or smaller has this problem. /64 does > not because it allows a device to use non-hierarchical means (such as > bridging and SLAAC) to extend the network. YEs, I agree (provided we mean "any value that is larger than 64", because prefix lengths of size smaller than 64 are ok.) Alex > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Sep 17 07:02:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AFA1A005A for ; Thu, 17 Sep 2015 07:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfnhVZhZ10tu for ; Thu, 17 Sep 2015 07:02:17 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F341A0027 for ; Thu, 17 Sep 2015 07:02:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8HE2EIU015670; Thu, 17 Sep 2015 16:02:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DCFC4201CE8; Thu, 17 Sep 2015 16:07:06 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C7480201252; Thu, 17 Sep 2015 16:07:06 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8HE2DTQ027300; Thu, 17 Sep 2015 16:02:13 +0200 To: Lorenzo Colitti References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <5C06E141-E9E4-43FC-A7B5-0E260FFC5162@delong.com> <55FAC3E1.3020206@gmail.com> From: Alexandre Petrescu Message-ID: <55FAC7E5.4060001@gmail.com> Date: Thu, 17 Sep 2015 16:02:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 14:02:18 -0000 Le 17/09/2015 15:49, Lorenzo Colitti a écrit : > On Thu, Sep 17, 2015 at 10:45 PM, Alexandre Petrescu > > wrote: > > DHCP-PD can not be used to assign addresses to Hosts. > > If you want to do that then you must come up with a mechanism for > the Host to form an IP address out of an Interface ID and the prefix > allocated by DHCP-PD. Right now there is no such mechanism AFAIK. > > > If the whole prefix is assigned to the host, there is no need to specify > a mechanism. The host can just pick whatever address it wants. YEs from the routing perspective: they'll all be routed to it. But I can guess there are exceptions (i.e. don't take 0, no 'ffff', etc.) > > There is precedent for this in RFC 7084: > > ... it MUST create > a global IPv6 address(es) from its delegated prefix(es) and > configure those on one of its internal virtual network > interfaces ... Sure it MUST, but how? Alex From nobody Thu Sep 17 08:09:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8417A1A870F for ; Thu, 17 Sep 2015 08:09:32 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwbkd8lLZ-Fu for ; Thu, 17 Sep 2015 08:09:30 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 88BB91A219F for ; Thu, 17 Sep 2015 08:09:27 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 17 Sep 2015 10:09:22 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-io0-f178.google.com [209.85.223.178] #+LO+TS+TR X-Umn-Classification: local Received: by ioiz6 with SMTP id z6so25053675ioi.2 for ; Thu, 17 Sep 2015 08:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=tVOulDi7JYgtDlWml6bjxGJlK01NBR3cWHobGF5BF8A=; b=X2TBqgKLDkWAtIhIv+QP9Q6KGMC6DzTOz/WA3IioKBbyf6K6MCbhjVIjvDrnhHDmkA 6IBQK3JL5G+4xKza9zPb+VrfA8VbXZ7YJH27AifvCdHXQdzHNWFdmKLJNshsl9icukwb DFTjzUAyGsUb8e6kk5Cguw3KUYWXYBYvCS1Jg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=tVOulDi7JYgtDlWml6bjxGJlK01NBR3cWHobGF5BF8A=; b=hUT5eK2E5Ln51QHjaAEBWZwx8l8RutaKDZTFaSO70gRMwt7vDmkHAGhg1DPEpv/J5N inJhydhdrJhgvVwNHWGjqseUKhZ5YNC8uspt4BVvh3x70lnPdDJol05DArOEV0Vq2X8S RnxcUGdPm50EYNZeT6OJgZrMeGLKtc/X8OL9U8Tk3RNJZii0hbJ0RlfdLlU6chE9UEhN hufWnc8u8NLpNVYeIOmWP0VDDoUStuakxBD16sJPXXMJoWIhFtKW1lszwjFqU6z3p6A8 4luLyoPg+C8blcoH22XEYRsWTMAUn96n+WfBIpj4S6MtPRCI5w6trVQRFeTF6U/arGX4 XPjA== X-Gm-Message-State: ALoCoQkqjmK8g4LsfK3/THYsPqiD7zsJvhrwU8D2hRN9apTXLWi66KbK2ace3eeuGLQ+VlvQv7983vtdCubwtrqn+8/rtuZPmCe2OYCbDDj4ZVgMHIQZ3D91+OKSTVpBraTe7sQPGflJ X-Received: by 10.107.160.143 with SMTP id j137mr7268279ioe.13.1442502562018; Thu, 17 Sep 2015 08:09:22 -0700 (PDT) X-Received: by 10.107.160.143 with SMTP id j137mr7268234ioe.13.1442502561716; Thu, 17 Sep 2015 08:09:21 -0700 (PDT) Received: from [10.118.137.221] ([166.175.57.75]) by smtp.gmail.com with ESMTPSA id a4sm4339703igh.16.2015.09.17.08.09.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Sep 2015 08:09:19 -0700 (PDT) References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <55F977AF.7020701@gmail.com> In-Reply-To: <55F977AF.7020701@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (12H321) From: David Farmer Date: Thu, 17 Sep 2015 10:09:18 -0500 To: Alexandre Petrescu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 15:09:32 -0000 The primary thesis of this draft is "don't limit hosts to one IPv6 address".= Don't limit them to 2 or 3, or 5, or 10 IPv6 addresses either. The recomm= endation is there should be no specific limit at all. However, if you are g= oing to set a limit, for god sake, don't set it to anything less than 32. Everything else is discussing the many reasons why hosts want more than one a= ddress or mitigating the counter arguments causing people to want to set a l= imit. Tethering and virtual hosts are simple among the many reason NOT to l= imit the number of IPv6 addresses a host can have. Assigning a /64 and rout= ing is simply a way to mitigate neighbor discovery explosion, if you are wor= ried about that. It is not specifying when you should or should not do that= , just saying there are other options than setting a limit on the number of I= Pv6 addresses a host can have. This isn't about telling people how they should tether, or how many addresse= s to allocate or not to allocate, again the recommendation is "no specific l= imit" on the number of IPv6 addresses a host can have, that's it. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Thu Sep 17 11:21:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F066D1B30BF for ; Thu, 17 Sep 2015 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dVPFs0UlFXw for ; Thu, 17 Sep 2015 11:21:35 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D5E1B30C3 for ; Thu, 17 Sep 2015 11:21:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8HILWDQ023910; Thu, 17 Sep 2015 20:21:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2B48B206E31; Thu, 17 Sep 2015 20:26:25 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1D79A206E1C; Thu, 17 Sep 2015 20:26:25 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.49]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8HILUfg013315; Thu, 17 Sep 2015 20:21:31 +0200 To: David Farmer References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <55F977AF.7020701@gmail.com> From: Alexandre Petrescu Message-ID: <55FB04A2.8000905@gmail.com> Date: Thu, 17 Sep 2015 20:21:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 18:21:37 -0000 Le 17/09/2015 17:09, David Farmer a écrit : > The primary thesis of this draft is "don't limit hosts to one IPv6 > address". Sorry it seems I dont understand. Nobody limits a host to one IPv6 address. The Host itself can make 2^64 addresses. The multiplication of privacy addresses, multi-homing and various scopes - they are all in place in each IPv6 Host today. What limit is this draft referring to? I do believe there are some limits, but not in the number of addresses for a Host. > Don't limit them to 2 or 3, or 5, or 10 IPv6 addresses either. The > recommendation is there should be no specific limit at all. However, > if you are going to set a limit, for god sake, don't set it to > anything less than 32. It sounds reasonable, if only there were a limit. > Everything else is discussing the many reasons why hosts want more > than one address or mitigating the counter arguments causing people > to want to set a limit. Tethering and virtual hosts are simple > among the many reason NOT to limit the number of IPv6 addresses a > host can have. Assigning a /64 and routing is simply a way to > mitigate neighbor discovery explosion, if you are worried about that. > It is not specifying when you should or should not do that, just > saying there are other options than setting a limit on the number of > IPv6 addresses a host can have. > > This isn't about telling people how they should tether, or how many > addresses to allocate or not to allocate, again the recommendation > is "no specific limit" on the number of IPv6 addresses a host can > have, that's it. > Ok. Alex From nobody Thu Sep 17 12:43:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13A1A8A68 for ; Thu, 17 Sep 2015 12:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HlBZdUTeIbz for ; Thu, 17 Sep 2015 12:42:59 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148901A8A25 for ; Thu, 17 Sep 2015 12:42:58 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 53998A1; Thu, 17 Sep 2015 21:42:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442518976; bh=Cc20Qc8DktwYarwg9iX6wn+h3zWHByHi9tvcJDiPA6Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=evWTCF8ReA7KQXqqloec6LjXN2947TDBMepoyQWBA+a3pMWWm6uvOH3/XrHKtrG/1 MvaauiQ7DU+CC+rgRE1/kHNHpmI3PYO5LWpVxhewH62zrb2/CT/wrnpZaIyiMIv8+a XgJN9bwbXLhkoXitW60FO7jQ0zhTVonS6584BIDA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4C8689F; Thu, 17 Sep 2015 21:42:56 +0200 (CEST) Date: Thu, 17 Sep 2015 21:42:56 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu In-Reply-To: <55FB04A2.8000905@gmail.com> Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <55F977AF.7020701@gmail.com> <55FB04A2.8000905@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 19:43:00 -0000 On Thu, 17 Sep 2015, Alexandre Petrescu wrote: > What limit is this draft referring to? The fact that the network administrator might say A=0, M=1 and only give out single IA_NA to the host. That is the specific deployment case that this draft is trying to say "don't do that". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 17 13:05:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA9D1B3165 for ; Thu, 17 Sep 2015 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-JluFruEyBT for ; Thu, 17 Sep 2015 13:05:27 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E0E1B3164 for ; Thu, 17 Sep 2015 13:05:27 -0700 (PDT) Received: by igcrk20 with SMTP id rk20so3503652igc.1 for ; Thu, 17 Sep 2015 13:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=McvqVHWNEog++mSuh4qjvLWjTlatjxKAqlkvTNLEtEQ=; b=lBMOCHSyt7Q8D/HYe2T/yo9o28EINAWZuee34Zw436I7HnRsducFx2UJ3lliFNs/am 87VDmHEoEKq+7tIM08R5FqcFGfXSq2a7EedPDKr9PgZuld83UQBugp1DUYYR8qsMJDzS 9+H6QJ7+U4P2IadkB8fHrpjYDSzHjOcShwjNWCxnW7td2pyWk5eahQ/OIKEIc4dDWqwK fr7kPZxngtRNzILbQ9IEb+t5qYi0gcjBdEdEurhdVbUa0t13MZ48zvXyiXAPNfrJsfEO ttpRdgiec0AGDOKU1hRLo/ZCJVQB2jInfGPJCxAgeSOQwz1Un+SmuqZec0F1qZfs9qMr i4+w== MIME-Version: 1.0 X-Received: by 10.50.111.167 with SMTP id ij7mr9244900igb.41.1442520326471; Thu, 17 Sep 2015 13:05:26 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.140.12 with HTTP; Thu, 17 Sep 2015 13:05:26 -0700 (PDT) In-Reply-To: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Date: Thu, 17 Sep 2015 13:05:26 -0700 X-Google-Sender-Auth: Vof7NEBuvjQJEVdFwQCdU-epNjU Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:05:29 -0000 On Sun, Sep 13, 2015 at 11:00 AM, wrote: > This is to initiate a two week working group last call of > http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. > Please read it now. If you find nits (spelling errors, minor suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the > list. I think this document raises an important question and generally provides sensible and useful suggestions. It's generally well written overall. But, I think I'd like to understand some bigger picture, even if this may be out of scope of this particular document in the end. Consider cases like a hotel network where hotel guests are charged connectivity fee per the number of MAC (layer 2) addresses so every different "device" is charged separately. I suspect such setup is not uncommon, and I guess avoiding the "double charge" is one motivation for supporting NAT66 for VMs (https://communities.vmware.com/docs/DOC-29954). Now, specifically what would we propose with this document so we won't end up using NAT66 in this situation? Discouraging the operators of such networks from deploying "per-device" charge is certainly one option, but since this document actually tries to promote the (possibility of) use of multiple addresses (which can mean multiple MAC addresses depending on the underlying technology), we can't say "it may prove counterproductive if customers respond by using NAT". So, let's assume (for now) this type of charge won't disappear anyway. Then another solution would be to suggest using prefix delegation in such networks, but that is largely up to the operator, and they probably don't see an incentive to do this since they'd rather have the possible extra revenue due to the per-device charge. It may also not be feasible in terms of address space management for this kind of network. Yet another solution would be to implement the RFC7278-style of prefix sharing in the VM host, but in this case the prefix must be completely owned by each physical device. I'm not sure if this assumption is feasible in this case. Obviously we won't be able to solve all possible cases, and in any case it's probably not in the scope of this document to provide *any* such solution. But I'd like to see one feasible scenario of specifically how this document can be used in a scenario like the above one, and (while it may be only me) I couldn't be sure about that just by reading the draft. It would be nice if this is somehow clarified in this last call discussion, and it would be nicer if some part of it is applied to the draft itself. ===== Some specific comments to the draft body: - On the table in Section 6: I don't understand why the cell for 'DHCPv6 PD' x '"Unlimited" endpoints' is 'No'. - (minor nit) Section 7, first sentence: s/section Section/Section/ If we itemize the use cases from section Section 3, we can estimate - Section 8: Assigning prefixes smaller than a /64 will limit the flexibility of I vaguely remember someone already made the same comment, but "smaller than a /64" sounds ambiguous to me (is /63 is "smaller" or "larger" than /64?). I suggest: Assigning prefixes with the length larger than 64 will limit... - Section 9.1 [...] Additionally, attempts to track this sort of information via DHCPv6 are likely to become decreasingly viable due to ongoing efforts to improve the privacy of DHCP This is true, but isn't it the same for (e.g.) SLAAC due to the ongoing efforts to improve privacy (e.g. by employing MAC address randomization)? So this rather seems to be about the discussion of how/whether host tracking is performed in general in the privacy conscious era, rather than about how the addresses are configured. - Section 9.1 Indeed, many large enterprise networks, including the enterprise networks of the authors, are fully dual-stack but do not currently use or support DHCPv6. - In this context, host tracking should also be performed in some way (otherwise not using DHCPv6 doesn't add any information in the context). Is that the case? - A minor point, but I wonder whether this means both Google or Apple, or only either of them. Not that important, but if it's the latter I'd say "some authors" instead of "the authors" to be accurate. - Section 9.2, first paragraph [...] In IPv6, that is equivalent to assigning one /64 per host out of a /48. On the first read I didn't get it smoothly. Maybe it's trivial to others, but I'd suggest revising this sentence as: In IPv6 with the recommendation of providing each host with multiple addresses, that is equivalent to assigning one /64 per host out of a /48. Same for the second paragraph. - Section 9.2 Currently, residential users receive one IPv4 address and a /48, /56 or /60 IPv6 prefix. While such networks do not have enough space to assign a /64 per device, today such networks almost universally use SLAAC. I don't get what the second sentence tries to implicate in this context. Some more explanation might help here. -- JINMEI, Tatuya From nobody Thu Sep 17 13:43:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EC71A0120 for ; Thu, 17 Sep 2015 13:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehH-FOUqu1h0 for ; Thu, 17 Sep 2015 13:43:45 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37BDD1A010E for ; Thu, 17 Sep 2015 13:43:45 -0700 (PDT) Received: by pacex6 with SMTP id ex6so29076228pac.0 for ; Thu, 17 Sep 2015 13:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=AZ4J3Yj05wfKXPyNGlwnaNPEUT5ftpzQIlasLq9IEVs=; b=KwHlegLrA406r8eRU8GVdmyyI6u58BKFYSGDNNh6rISVDIuirzDTNVHhCgiqOLRVW8 AR0PzqTvFzog68Ugn/af/NnGuvD6jtnatMYX1C/ZBZt3N17FeZJD/E9tf5dRj6X8muxx VKqBjBsmQB8p7XRm5Z30LMRifURRB6dtQD8cDIRYbRxXPbFds3CHHSHTCMm4DSPGnt1q Qtf/cNIcHfb1J21yLdCCe7By+VIq4qMht4P6fK9KsWscQz/P/907YzUmAKcO29Nmb3St 0SK3Q3xW5kyw+pQahB/aWCgqb2H9++3b5WGA1y5ouFUDHWLkYMh1pOgDMlqTPtLESYgL xyVQ== X-Received: by 10.68.135.69 with SMTP id pq5mr2199261pbb.162.1442522624844; Thu, 17 Sep 2015 13:43:44 -0700 (PDT) Received: from [192.168.178.25] ([163.47.223.240]) by smtp.gmail.com with ESMTPSA id yi8sm5026823pab.22.2015.09.17.13.43.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Sep 2015 13:43:43 -0700 (PDT) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , "Fred Baker (fred)" References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55FB2607.1010506@gmail.com> Date: Fri, 18 Sep 2015 08:43:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:43:47 -0000 On 18/09/2015 08:05, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > On Sun, Sep 13, 2015 at 11:00 AM, wrote: >=20 >> This is to initiate a two week working group last call of >> http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. >> Please read it now. If you find nits (spelling errors, minor suggested= >> wording changes, etc), comment to the authors; if you find greater >> issues, such as disagreeing with a statement or finding additional >> issues that need to be addressed, please post your comments to the >> list. >=20 > I think this document raises an important question and generally > provides sensible and useful suggestions. It's generally well written > overall. >=20 > But, I think I'd like to understand some bigger picture, even if this > may be out of scope of this particular document in the end. Consider > cases like a hotel network where hotel guests are charged connectivity > fee per the number of MAC (layer 2) addresses so every different > "device" is charged separately. =20 In my experience the system is more often a restriction to two or three devices per hotel room. My most recent hotel stay was annoying because we had one laptop and two smartphones with us, and only two of them could= connect simultaneously. But you are correct, this is a common problem. However, it may be imposed as a crude load management system. So maybe th= e draft should point out that the number of IP addresses is not a proxy for= the traffic load. Brian > I suspect such setup is not uncommon, > and I guess avoiding the "double charge" is one motivation for > supporting NAT66 for VMs (https://communities.vmware.com/docs/DOC-29954= ). >=20 > Now, specifically what would we propose with this document so we won't > end up using NAT66 in this situation? Discouraging the operators of > such networks from deploying "per-device" charge is certainly one > option, but since this document actually tries to promote the > (possibility of) use of multiple addresses (which can mean multiple > MAC addresses depending on the underlying technology), we can't say > "it may prove counterproductive if customers respond by using NAT". > So, let's assume (for now) this type of charge won't disappear anyway. > Then another solution would be to suggest using prefix delegation in > such networks, but that is largely up to the operator, and they > probably don't see an incentive to do this since they'd rather have > the possible extra revenue due to the per-device charge. It may also > not be feasible in terms of address space management for this kind of > network. Yet another solution would be to implement the RFC7278-style > of prefix sharing in the VM host, but in this case the prefix must be > completely owned by each physical device. I'm not sure if this > assumption is feasible in this case. >=20 > Obviously we won't be able to solve all possible cases, and in any > case it's probably not in the scope of this document to provide *any* > such solution. But I'd like to see one feasible scenario of > specifically how this document can be used in a scenario like the > above one, and (while it may be only me) I couldn't be sure about that > just by reading the draft. It would be nice if this is somehow > clarified in this last call discussion, and it would be nicer if some > part of it is applied to the draft itself. >=20 > =3D=3D=3D=3D=3D >=20 > Some specific comments to the draft body: >=20 > - On the table in Section 6: I don't understand why the cell for > 'DHCPv6 PD' x '"Unlimited" endpoints' is 'No'. >=20 > - (minor nit) Section 7, first sentence: s/section Section/Section/ >=20 > If we itemize the use cases from section Section 3, we can estimate >=20 > - Section 8: >=20 > Assigning prefixes smaller than a /64 will limit the flexibility of >=20 > I vaguely remember someone already made the same comment, but > "smaller than a /64" sounds ambiguous to me (is /63 is "smaller" or > "larger" than /64?). I suggest: >=20 > Assigning prefixes with the length larger than 64 will limit... >=20 > - Section 9.1 >=20 > [...] Additionally, attempts to track this sort > of information via DHCPv6 are likely to become decreasingly viable > due to ongoing efforts to improve the privacy of DHCP >=20 > This is true, but isn't it the same for (e.g.) SLAAC due to the > ongoing efforts to improve privacy (e.g. by employing MAC address > randomization)? So this rather seems to be about the discussion of > how/whether host tracking is performed in general in the privacy > conscious era, rather than about how the addresses are configured. >=20 > - Section 9.1 >=20 > Indeed, many large > enterprise networks, including the enterprise networks of the > authors, are fully dual-stack but do not currently use or support > DHCPv6. >=20 > - In this context, host tracking should also be performed in some > way (otherwise not using DHCPv6 doesn't add any information in the > context). Is that the case? > - A minor point, but I wonder whether this means both Google or > Apple, or only either of them. Not that important, but if it's > the latter I'd say "some authors" instead of "the authors" to be > accurate. >=20 > - Section 9.2, first paragraph >=20 > [...] In IPv6, that is equivalent to assigning one > /64 per host out of a /48. >=20 > On the first read I didn't get it smoothly. Maybe it's trivial to > others, but I'd suggest revising this sentence as: >=20 > In IPv6 with the recommendation of providing each host with > multiple addresses, that is equivalent to assigning one /64 per > host out of a /48. >=20 > Same for the second paragraph. >=20 > - Section 9.2 >=20 > Currently, residential users receive one IPv4 address and a /48, /56= > or /60 IPv6 prefix. While such networks do not have enough space to= > assign a /64 per device, today such networks almost universally use > SLAAC. >=20 > I don't get what the second sentence tries to implicate in this > context. Some more explanation might help here. >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Thu Sep 17 13:44:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A5C1A0130 for ; Thu, 17 Sep 2015 13:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX7x5hYfw8F1 for ; Thu, 17 Sep 2015 13:44:28 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F741A0125 for ; Thu, 17 Sep 2015 13:44:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 91907A1; Thu, 17 Sep 2015 22:44:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442522665; bh=n2kr8EQaR/bP65Huze0he7UtTDIH5hZeFa+DNbcuTRA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yWYlIA9Ed0Tn0Tt9TshWg4xd75iFjEkUHPKlYqzDao6HGVN754OyGjaWPp02dz8k+ ubF0G6SscZ9Q82IsQo7WDsnZ4YORV/UHMUsqi8+Jz6mDk+QkJ2DiN3i6oO9EexAYo5 ceUcUOlnWyJ0tOMUKw01KY4gpCBpFspfg/Rzgquk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8B3409F; Thu, 17 Sep 2015 22:44:25 +0200 (CEST) Date: Thu, 17 Sep 2015 22:44:25 +0200 (CEST) From: Mikael Abrahamsson To: =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= In-Reply-To: Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-2059692229-1442522665=:8750" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:44:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-2059692229-1442522665=:8750 Content-Type: TEXT/PLAIN; charset=ISO-2022-JP; format=flowed On Thu, 17 Sep 2015, $B?@L@C#:H(J wrote: > Now, specifically what would we propose with this document so we won't > end up using NAT66 in this situation? Discouraging the operators of The proposal is to use DHCPv6-PD because otherwise we'll get NAT66, as you already have identified. The operator(s) needs to understand that they can't charge per-device because that doesn't actually work, because then the customer will deploy NAT66, then the operator will deploy DPI to look into user-agent string, and then the customer will encrypt everythingm and now the operator has lost all insight into what the customer is doing, and the operator has lost and we're all worse off than when we started. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-2059692229-1442522665=:8750-- From nobody Thu Sep 17 13:48:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E921A017E for ; Thu, 17 Sep 2015 13:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbwBTQw2Lakx for ; Thu, 17 Sep 2015 13:48:17 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93781A017A for ; Thu, 17 Sep 2015 13:48:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 73B35A1; Thu, 17 Sep 2015 22:48:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442522895; bh=7vro8eJ2zgyHbt3ys76EYaFabh4Nx7/4uytidhdnW/8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=n6yjHz0r7Nz1epEK//p/NNLUPfz2CL3JR9DV+9nLA8asH0EBic1K5KjbB552U4RK5 nnQ4svkB8b0Fu8nsIbQ8mwJEf0Tv2bh7yL2M0VzIlTZxFSNSqo2gNU7E7Hrgzy8i6Q Bau+y6qWt1YZBmSwc7wLvqNeSsewNkOkJ8akBUHA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6CEC99F; Thu, 17 Sep 2015 22:48:15 +0200 (CEST) Date: Thu, 17 Sep 2015 22:48:15 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <55FB2607.1010506@gmail.com> Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 20:48:18 -0000 On Fri, 18 Sep 2015, Brian E Carpenter wrote: > However, it may be imposed as a crude load management system. So maybe > the draft should point out that the number of IP addresses is not a > proxy for the traffic load. So while this is extremely true, I'm not sure that this draft is the place to try to share this kind of opinion. I've seen people working for operators that called it "abuse" when their customers used tethering on a non-tethering mobile plan. The only thing the customer really needs to tell the operator is source and destination address, and the operator can tell the size of the packet. Anything else will become invisible to the operator if they try to use this information for differentiation between plans. It's actually taken longer than I thought to get a lot more encryption considering the amount of DPI and recompression etc of concent that is done in the fly today. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 17 21:58:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4641A8984 for ; Thu, 17 Sep 2015 21:58:38 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hhgAzITEvac for ; Thu, 17 Sep 2015 21:58:37 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.119.20]) by ietfa.amsl.com (Postfix) with ESMTP id 107A61A6F34 for ; Thu, 17 Sep 2015 21:58:37 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Thu, 17 Sep 2015 23:58:35 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ig0-f178.google.com [209.85.213.178] #+LO+TS+TR X-Umn-Classification: local Received: by igbni9 with SMTP id ni9so10163075igb.0 for ; Thu, 17 Sep 2015 21:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=7QR989rT18k8a8YoVOE8HOuXeYsGfufDAmq7zjSqemA=; b=OA4yOfbP7iP05r1qdOfUvQzWCp4Rpa5597yKO0ruK8SQyDjPxgUPRzWvkw796ijIXI p3UQ6OZO96ghfvWzAPwzKmva1wbi/qoUsL+o8ych7Hci2RNnMpq0Emq1RtRpm884FIUV 0MoFnop57927iOEQdceNkhvoynHbYrtOVCdW0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=7QR989rT18k8a8YoVOE8HOuXeYsGfufDAmq7zjSqemA=; b=fdgWx2eKiw/A88iRhKCkLP5cezApB3yU/AYpDdxGe5NBQaSf8FyBeOMA0o3HeYtfga JIUybhRPPsuUtgISokv+sEBbFmh5JmnBZlbAbaoeP7juKKh4kdC22cTlCSU/Tu6Uovvp iVM42RdSrUvSmEWlADEB38cnFXPlSn2arzTOIycT+G6LVxo7P2GZ5bD/ng5EYT5Z5O9e PSDzqcHPZlsVwLLzGEmGv5UzMWkXz/hdQojDeJn+OMLWmmwwmyC+BTF4FdxhclKuy3NM f4pqpE+HuC0I4EFtuuPS6jtAYkN7KWmFZ64BGl8j5nXnKjCYPI3NF5BT9MRQdcLeipSw rW/w== X-Gm-Message-State: ALoCoQl0G0E7yWr/7pX+XLvK8a1XpBhPxq9/AGaMT6mNQADJ98XMTwGcQlebJzgZPESuVAHKjE+UY4AgDpx3MxhzoAhAqtv8HKEibuNwlbDpCO4kQ6/XstnGZvXfT9f8E3QRlIdOYPXr X-Received: by 10.50.6.100 with SMTP id z4mr11319793igz.97.1442552315400; Thu, 17 Sep 2015 21:58:35 -0700 (PDT) X-Received: by 10.50.6.100 with SMTP id z4mr11319785igz.97.1442552315086; Thu, 17 Sep 2015 21:58:35 -0700 (PDT) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id pi6sm5794901igb.21.2015.09.17.21.58.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Sep 2015 21:58:33 -0700 (PDT) References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <55F977AF.7020701@gmail.com> <55FB04A2.8000905@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <4C569781-29F2-4B58-B2A0-07B5D3162E87@umn.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (12H321) From: David Farmer Date: Thu, 17 Sep 2015 23:58:32 -0500 To: Mikael Abrahamsson Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 04:58:38 -0000 >> On Sep 17, 2015, at 14:42, Mikael Abrahamsson wrote: >>=20 >> On Thu, 17 Sep 2015, Alexandre Petrescu wrote: >>=20 >> What limit is this draft referring to? >=20 > The fact that the network administrator might say A=3D0, M=3D1 and only gi= ve out single IA_NA to the host. That is the specific deployment case that t= his draft is trying to say "don't do that". Ok, I just reread the Draft, and I think it probably needs to say that it is= possible to limit the number of IPv6 addresses a host can receive by disabl= ing SLAAC (A=3D0 in the RA) and implementing a limit within the DHCPv6 serve= r. Other readers may be under the misimpression that it is not possible to l= imit the number of IPv6 addresses a host can receive. If they are under thi= s misimpression, the Draft and its arguments may not completely make sense. Disabling SLAAC and using the DHCPv6 server to limit the number of IPv6 addr= esses a host can receive, while the most logical way to achieve such a limit= , it is by no mean the only way. While somewhat perverse, and probably cons= idered malicious activity by many, it would also be possible to use DAD to d= eny the use of additional addresses by a host even in a SLAAC only environme= nt. Given that this is just plain evil, only the more conventional DHCPv6 f= orm of limiting the number of IPv6 addresses a host can receive needs to be a= cknowledged in the Draft. So while I totally agree with the recommendation of no specific limit on the= number of IPv6 addresses that a host should be allowed to use; I think it a= lso should be discussed that network operators may consider a single host us= ing an exorbitant number of IPv6 addresses as malicious activity. Again, a s= pecific number for what is "exorbitant" isn't going to be possible. But a g= eneral-purpose host using many hundreds or thousands of IPv6 addresses is li= kely to be considered malicious activity by at least some network operators.= I'll note we have seen hosts on our network consuming many hundreds to more t= han a thousand IPv6 addresses in a relatively short period (like as little a= s few hours). We haven't been able to determine the cause of this; a bug, o= verly aggressive privacy settings, or genuine malicious activity are all pla= usible explanations. We are not limiting hosts with this curious use profil= e today, and at least at this point, we don't intend to either. However, if= in the future hosts with this profile were to be shown to be a significant s= ource of malicious activity on our network; I suspect we would quickly chang= e our views on this issue and impose some kind of limit. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Thu Sep 17 22:31:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDAF1A9050 for ; Thu, 17 Sep 2015 22:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvZg6gA3ZTiB for ; Thu, 17 Sep 2015 22:31:13 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2FB1A904F for ; Thu, 17 Sep 2015 22:31:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DE338A1; Fri, 18 Sep 2015 07:31:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442554270; bh=9onNyICZt3nwWKwFbu9LGmXEea8RyCbKoar31e5W8w8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=NAlfapZt218Qi+5Y3NHSq3LNXv7twO2yO0hcZieyv4alsQARDcRk/j3dcEZyW6ZSu J9EdqZyJZK6rbewn6z2ptT6uXYMt0rGHLQ3fbGpXaJPIaZzV+C7uc3rn/rt3CirqLO 4n+PqzLnn2kFDw7t0tmvnlQjESg892zcUpY1marA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D699D9F; Fri, 18 Sep 2015 07:31:10 +0200 (CEST) Date: Fri, 18 Sep 2015 07:31:10 +0200 (CEST) From: Mikael Abrahamsson To: David Farmer In-Reply-To: <4C569781-29F2-4B58-B2A0-07B5D3162E87@umn.edu> Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <55F977AF.7020701@gmail.com> <55FB04A2.8000905@gmail.com> <4C569781-29F2-4B58-B2A0-07B5D3162E87@umn.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 05:31:15 -0000 On Thu, 17 Sep 2015, David Farmer wrote: > Ok, I just reread the Draft, and I think it probably needs to say that > it is possible to limit the number of IPv6 addresses a host can receive > by disabling SLAAC (A=0 in the RA) and implementing a limit within the > DHCPv6 server. Other readers may be under the misimpression that it is > not possible to limit the number of IPv6 addresses a host can receive. > If they are under this misimpression, the Draft and its arguments may > not completely make sense. The introduction pretty much says that it's possible to limit the number of adresses to 1, but it doesn't say how. I am not one of the authors, but I'd imagine they didn't want to spell out exactly how to limit the addresses to 1 because they don't see this as a desired outcome, but I guess it could be included in section 2 that the analogy how things are normally done in IPv4 (DHCPv4 single address) for IPv6 is DHCPv6 IA_NA single address, A=0, M=1. I'd imagine this is not an uncommon deployment model today for IPv6 in some networks, and I have heard network administrators express a desire for this outcome. The draft is a response to that, and instead suggests that hosts get an address range (single block) instead of single address. I believe this is a good compromise, but it would require hosts to gain this functionality, and network administrators to implement this. Perhaps you could suggest text and where to put it so the authors can consider it? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Sep 18 01:43:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AA41ACD9A for ; Fri, 18 Sep 2015 01:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmDuY_BohSUH for ; Fri, 18 Sep 2015 01:43:22 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639F21ACD9D for ; Fri, 18 Sep 2015 01:43:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8I8hKoM026640; Fri, 18 Sep 2015 10:43:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36134203637; Fri, 18 Sep 2015 10:48:14 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1F86D201CF0; Fri, 18 Sep 2015 10:48:14 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8I8hItw028589; Fri, 18 Sep 2015 10:43:19 +0200 To: Mikael Abrahamsson References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55F814FB.5030003@gmail.com> <55F92D8F.1080203@gmail.com> <55F94F63.8000009@gmail.com> <08160628-9391-421D-8AE6-34A6537694B2@umn.edu> <55F977AF.7020701@gmail.com> <55FB04A2.8000905@gmail.com> From: Alexandre Petrescu Message-ID: <55FBCEA6.6010803@gmail.com> Date: Fri, 18 Sep 2015 10:43:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 08:43:24 -0000 Le 17/09/2015 21:42, Mikael Abrahamsson a écrit : > On Thu, 17 Sep 2015, Alexandre Petrescu wrote: > >> What limit is this draft referring to? > > The fact that the network administrator might say A=0, M=1 and only give > out single IA_NA to the host. That is the specific deployment case that > this draft is trying to say "don't do that". That makes sense. So this is a recommendation for DHCP-Address to deliver more than one GUA or ULA address (in case the A/M mix in RA forbids the Host to SLAAC). I agree with it. From this, I dont think it should recommend to involve DHCP-PD to solve that problem, because (1) there is no specified way to form an address out of the prefix in DHCP-PD and (2) the routing established by DHCP-PD needs an address already formed on the Host (not out of that prefix). (for (2) one needs to read draft-petrescu-relay-route-pd-problem-00.txt written in 2013) Alex > From nobody Fri Sep 18 08:29:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642D11B2E17; Fri, 18 Sep 2015 08:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZvmDEuRfUE0; Fri, 18 Sep 2015 08:29:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0961B2E1D; Fri, 18 Sep 2015 08:29:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150918152948.15492.96498.idtracker@ietfa.amsl.com> Date: Fri, 18 Sep 2015 08:29:48 -0700 Archived-At: Cc: v6ops WG Subject: [v6ops] WG Action: Rechartered IPv6 Operations (v6ops) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 15:29:50 -0000 The IPv6 Operations (v6ops) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. IPv6 Operations (v6ops) ------------------------------------------------ Current Status: Active WG Chairs: Lee Howard Fred Baker Assigned Area Director: Joel Jaeggli Mailing list Address: v6ops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/v6ops Archive: https://mailarchive.ietf.org/arch/browse/v6ops/ Charter: The global deployment of IPv6 is underway, creating an Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks, ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of IPv6 networks, and provides operational guidance on how to deploy and operate IPv6 in new and existing networks. The main focus of the IPv6 Operations Working Group is to look at the deployment and operational issues in IPv6 networks. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv6 Internet, and determine solutions or workarounds to those issues. 2. Solicit input from network operators and users to identify operational interaction issues with the IPv4 Internet, and determine solutions or workarounds to those issues. 3. Operational solutions for identified issues should be developed in v6ops and documented in informational or BCP drafts. These documents should document IPv6 operational experience, including interactions with IPv4, in dual stack networks, IPv6 networks with IPv4 delivered as an overlay or translation service, or IPv6-only networks. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops Working Group may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the Working Group only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Milestones: Sep 2015 - Describe a Translation solution for IPv6-only data centers Nov 2015 - Describe and recommend mitigations for energy consumption in Neighbor Discovery Nov 2015 - Describe routing choices and trade-offs for enterprise and service provider networks Nov 2015 - Update RFC 6145 Translation in view of operational experience Nov 2015 - Describe emerging IPv6 allocations to hosts Nov 2015 - File report on behavior of IPv6 traffic with Extension Headers From nobody Fri Sep 18 11:52:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B605E1B303E for ; Fri, 18 Sep 2015 11:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZJonpIrYg-6 for ; Fri, 18 Sep 2015 11:52:45 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03C21B2F20 for ; Fri, 18 Sep 2015 11:52:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8IIqgBY019767 for ; Fri, 18 Sep 2015 20:52:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8E914201B1E for ; Fri, 18 Sep 2015 20:57:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86675201933 for ; Fri, 18 Sep 2015 20:57:36 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.83]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8IIqex5030082 for ; Fri, 18 Sep 2015 20:52:41 +0200 To: v6ops@ietf.org References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> From: Alexandre Petrescu Message-ID: <55FC5D78.4070008@gmail.com> Date: Fri, 18 Sep 2015 20:52:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FB2607.1010506@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 18:52:47 -0000 Le 17/09/2015 22:43, Brian E Carpenter a écrit : > On 18/09/2015 08:05, 神明達哉 wrote: >> On Sun, Sep 13, 2015 at 11:00 AM, wrote: >> >>> This is to initiate a two week working group last call of >>> http://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability. >>> >>> Please read it now. If you find nits (spelling errors, minor suggested >>> wording changes, etc), comment to the authors; if you find >>> greater issues, such as disagreeing with a statement or finding >>> additional issues that need to be addressed, please post your >>> comments to the list. >> >> I think this document raises an important question and generally >> provides sensible and useful suggestions. It's generally well >> written overall. >> >> But, I think I'd like to understand some bigger picture, even if >> this may be out of scope of this particular document in the end. >> Consider cases like a hotel network where hotel guests are charged >> connectivity fee per the number of MAC (layer 2) addresses so every >> different "device" is charged separately. > > In my experience the system is more often a restriction to two or > three devices per hotel room. I agree, for IPv4. But is there such hotspot with IPv6 addresses? I doubt so. In my recent travels I never seen one IPV6 hotspot in a hotel, restaurant, airport, plane, taxi, bus. I speculate the first public IPv6 hotspots will use SLAAC (not DHCP) and filter on the MAC addresses with captive portals. In these cases a good recommendation would be a recommendation on the firewall (allow multiple MAC addresses), less on DHCP because DHCP is not used. Also, in these cases the risk is - in addition to NAT66 - the end user multiplexing one MAC address among multiple devices (user tools to set MAC addresses, and hardwar supporting it, are widely available), which risks breaking other things than the things which NAT66 breaks. > My most recent hotel stay was annoying because we had one laptop and > two smartphones with us, and only two of them could connect > simultaneously. But you are correct, this is a common problem. Yes, I fully agree. I experienced same problem. > However, it may be imposed as a crude load management system. So > maybe the draft should point out that the number of IP addresses is > not a proxy for the traffic load. Well, I think one particular IP address can still be used to identify one device in order to load balance. But do not assume there to be as many devices as IP addresses are. I dont know how crude load balancers may work, though. Alex > > Brian > >> I suspect such setup is not uncommon, and I guess avoiding the >> "double charge" is one motivation for supporting NAT66 for VMs >> (https://communities.vmware.com/docs/DOC-29954). >> >> Now, specifically what would we propose with this document so we >> won't end up using NAT66 in this situation? Discouraging the >> operators of such networks from deploying "per-device" charge is >> certainly one option, but since this document actually tries to >> promote the (possibility of) use of multiple addresses (which can >> mean multiple MAC addresses depending on the underlying >> technology), we can't say "it may prove counterproductive if >> customers respond by using NAT". So, let's assume (for now) this >> type of charge won't disappear anyway. Then another solution would >> be to suggest using prefix delegation in such networks, but that is >> largely up to the operator, and they probably don't see an >> incentive to do this since they'd rather have the possible extra >> revenue due to the per-device charge. It may also not be feasible >> in terms of address space management for this kind of network. Yet >> another solution would be to implement the RFC7278-style of prefix >> sharing in the VM host, but in this case the prefix must be >> completely owned by each physical device. I'm not sure if this >> assumption is feasible in this case. >> >> Obviously we won't be able to solve all possible cases, and in any >> case it's probably not in the scope of this document to provide >> *any* such solution. But I'd like to see one feasible scenario of >> specifically how this document can be used in a scenario like the >> above one, and (while it may be only me) I couldn't be sure about >> that just by reading the draft. It would be nice if this is >> somehow clarified in this last call discussion, and it would be >> nicer if some part of it is applied to the draft itself. >> >> ===== >> >> Some specific comments to the draft body: >> >> - On the table in Section 6: I don't understand why the cell for >> 'DHCPv6 PD' x '"Unlimited" endpoints' is 'No'. >> >> - (minor nit) Section 7, first sentence: s/section >> Section/Section/ >> >> If we itemize the use cases from section Section 3, we can >> estimate >> >> - Section 8: >> >> Assigning prefixes smaller than a /64 will limit the flexibility >> of >> >> I vaguely remember someone already made the same comment, but >> "smaller than a /64" sounds ambiguous to me (is /63 is "smaller" >> or "larger" than /64?). I suggest: >> >> Assigning prefixes with the length larger than 64 will limit... >> >> - Section 9.1 >> >> [...] Additionally, attempts to track this sort of information via >> DHCPv6 are likely to become decreasingly viable due to ongoing >> efforts to improve the privacy of DHCP >> >> This is true, but isn't it the same for (e.g.) SLAAC due to the >> ongoing efforts to improve privacy (e.g. by employing MAC address >> randomization)? So this rather seems to be about the discussion >> of how/whether host tracking is performed in general in the >> privacy conscious era, rather than about how the addresses are >> configured. >> >> - Section 9.1 >> >> Indeed, many large enterprise networks, including the enterprise >> networks of the authors, are fully dual-stack but do not currently >> use or support DHCPv6. >> >> - In this context, host tracking should also be performed in some >> way (otherwise not using DHCPv6 doesn't add any information in the >> context). Is that the case? - A minor point, but I wonder whether >> this means both Google or Apple, or only either of them. Not that >> important, but if it's the latter I'd say "some authors" instead of >> "the authors" to be accurate. >> >> - Section 9.2, first paragraph >> >> [...] In IPv6, that is equivalent to assigning one /64 per host out >> of a /48. >> >> On the first read I didn't get it smoothly. Maybe it's trivial to >> others, but I'd suggest revising this sentence as: >> >> In IPv6 with the recommendation of providing each host with >> multiple addresses, that is equivalent to assigning one /64 per >> host out of a /48. >> >> Same for the second paragraph. >> >> - Section 9.2 >> >> Currently, residential users receive one IPv4 address and a /48, >> /56 or /60 IPv6 prefix. While such networks do not have enough >> space to assign a /64 per device, today such networks almost >> universally use SLAAC. >> >> I don't get what the second sentence tries to implicate in this >> context. Some more explanation might help here. >> >> -- JINMEI, Tatuya >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Sep 18 12:43:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A391B312A for ; Fri, 18 Sep 2015 12:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsRLjBiE-JZe for ; Fri, 18 Sep 2015 12:43:49 -0700 (PDT) Received: from pianosa.iway.ch (pianosa.iway.ch [212.25.24.37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDAA1B3127 for ; Fri, 18 Sep 2015 12:43:48 -0700 (PDT) Received: from pianosa.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B87F0E2478; Fri, 18 Sep 2015 21:43:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/24132.8111); Fri, 18 Sep 2015 21:43:46 +0200 (CEST) Received: from owa.hextop.ch (owa.hextop.ch [212.25.0.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pianosa.iway.ch (Postfix) with ESMTPS; Fri, 18 Sep 2015 21:43:46 +0200 (CEST) Received: from HEX02.hextop.ch ([212.25.0.68]) by hex02 ([212.25.0.68]) with mapi id 14.01.0438.000; Fri, 18 Sep 2015 21:43:44 +0200 From: Silvia Hagen To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ8YQxsbyMmhJJokKgwk/4IVyja55BDo+AgAFzRACAAC7DMA== Date: Fri, 18 Sep 2015 19:43:43 +0000 Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <55FB2607.1010506@gmail.com> <55FC5D78.4070008@gmail.com> In-Reply-To: <55FC5D78.4070008@gmail.com> Accept-Language: de-CH, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:120b:2c71:ec70:74:86e8:da8a:e742] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 19:43:51 -0000 DQoNCj4gQnV0IGlzIHRoZXJlIHN1Y2ggaG90c3BvdCB3aXRoIElQdjYgYWRkcmVzc2VzPyAgSSBk b3VidCBzby4gIEluIG15IHJlY2VudCB0cmF2ZWxzIEkgbmV2ZXIgc2VlbiBvbmUgSVBWNiBob3Rz cG90IGluIGEgaG90ZWwsIHJlc3RhdXJhbnQsIGFpcnBvcnQsIHBsYW5lLCB0YXhpLCBidXMuDQoN ClRoZW4geW91IGhhdmUgbm90IGJlZW4gaW4gWnVyaWNoIHlldCwgb3IgaW4gdGhlIHdyb25nIGhv dGVsICA6LSkNCg0KTW9uem9vbiAoaHR0cDovL3d3dy5tb256b29uLm5ldC8pICBpcyBvZmZlcmlu ZyBkdWFsLXN0YWNrIHdpZmkgZm9yIGhvdGVscyBzaW5jZSBtYW55IHllYXJzIGFuZCBzbyBhbnkg aG90ZWwgdGhhdCB3b3JrcyB3aXRoIE1vbnpvb24gaGFzIElQdjYuIE1vc3QgZ3Vlc3RzIHNpbXBs eSBkb24ndCByZWFsaXplIGFuZCBtYXliZSBub3QgZXZlbiB0aGUgaG90ZWxzIGtub3cuIEJ1dCBt eSBJUHY2IHRlYWNoZXJzIGRvIDotKQ0KDQoNClNpbHZpYQ0KDQo= From nobody Fri Sep 18 14:13:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02A21A00A8; Wed, 16 Sep 2015 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnhNIny2ORg7; Wed, 16 Sep 2015 12:10:37 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4C61A00A7; Wed, 16 Sep 2015 12:10:37 -0700 (PDT) Received: by padhk3 with SMTP id hk3so216794517pad.3; Wed, 16 Sep 2015 12:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=uqw0FlG4Qa6IKk4lkbondsGwyBLWo1pP5ZctD5ZDlso=; b=qJEfu9Z9wYLIdiG1kTnaGG72LkdhIiNzP9NK02RPSwSJQuVqXZp8tHpvxu6OiSG3Sq fDEIZUqYjb0an42la99WCYWeLmNQUhBTSBB9uY0wmtqzwAmLzjplxyvEy+kgmqyNdy37 BQ9ObmpXRBjYOWBePdwXciMoa9U0eTMdD3pyWJpES3nR3Xybu86tMIE0R6iewqqVGM1b 7b6imlwyQYV+AQoc6DQqHZAOHeoo4SQkU7/Vdex4rbbuPXjNVMEXkPBbPRhYG6QuEYfP SiSHUzazn8zYg7PYDLzCyNqGAciVKOhgXBwr8KZK/QbEwfzi5oSxoadfQGoa/XUSWS9Z TVVQ== X-Received: by 10.66.236.74 with SMTP id us10mr63759526pac.64.1442430636618; Wed, 16 Sep 2015 12:10:36 -0700 (PDT) Received: from mb.local ([8.18.217.2]) by smtp.googlemail.com with ESMTPSA id bz4sm29289962pbd.6.2015.09.16.12.10.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Sep 2015 12:10:34 -0700 (PDT) To: Benoit Claise , joel jaeggli , draft-ietf-v6ops-pmtud-ecmp-problem@ietf.org References: <55C20D5A.6070409@cisco.com> <55C2A2B7.3050304@cisco.com> <55C382E1.8070406@bogus.com> <55F93192.5080908@cisco.com> From: joel jaeggli Message-ID: <55F9BEA8.4070405@gmail.com> Date: Wed, 16 Sep 2015 12:10:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Thunderbird/41.0 MIME-Version: 1.0 In-Reply-To: <55F93192.5080908@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 18 Sep 2015 14:13:39 -0700 Cc: "" Subject: Re: [v6ops] draft-ietf-v6ops-pmtud-ecmp-problem-03: AD review X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 19:10:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 cool, thanks joel On 9/16/15 2:08 AM, Benoit Claise wrote: > Thanks Joel, > > Sending this to IETF LC. > > Regards, Benoit >> On 8/5/15 4:56 PM, Benoit Claise wrote: >>> Dear all, >>> >>> Joel, being a document author, asked me to look into this >>> draft Here is my feedback. I don't have any background on this >>> draft. So a fresh pair of eyes. >>> >>> 1. It took me a little bit of time to grasp the problem behind >>> this draft. From the abstract, I(wrongly) assumed a PTB packet >>> sent from the server back to the source. >> yup it's the one from the client. let me see if we can tweak >> this slightly. >> >>> It's only in section 2 that I found my answer (well, the second >>> time I read it) >>> >>> An ICMPv6 type 2 PTB message generated on an intermediate >>> device _for a packet sent from a server_ >>> >>> And the figure 1 was not too helpful, as, obviously I was >>> wondering about the ptb direction... >> figure 1 contains >> >> ptb -> router ecmp -> nexthop L4/L7 load balancer -> destination >> >> the limitations of ascii art may be a limitation here, but it's >> not really a state flow since it could be emitted by any device >> in the path. at any time. but I think if we address item 1 the >> problem of directionality is no doubt clear. >> >>> What would have made it crystal-clear is a figure 1 such as: >>> >>> Topology >>> >>> client -...-- router -- load balancer 1 --- server 1 \\-- load >>> balancer 2 --- server 2 \-- load balancer N --- server N >>> >>> >>> Sequence 1: packet from source to server client -> ... -> >>> router ecmp -> nexthop L4/L7 load balancer -> server (*) >>> Sequence 2: reply from server to source .... <- router ecmp <- >>> nexthop L4/L7 load balancer <- server (*) >>> >>> Sequence 3: ptb sent back to the server ptb -> router ecmp -> >>> nexthop L4/L7 load balancer -> server (**) >>> >>> Note: As (*) and (**) are unlikely the same instance, so the >>> ptb could be mis-delivered >>> >>> >>> 2. Confused about the order >>> >>> 3 >>> . >>> Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . >>> 4 >>> >>> >>> >>> 3.1 >>> . >>> Alternatives . . . . . . . . . . . . . . . . . . . . . . 5 >>> >>> >> >>> 3.1 can be changed to Alternative mitigations >> >> it's important that clamping the mss doesn't get lost in all if >> this because both the ietf considers that minimum best effort >> (everything has to carry 1280 right) and because people do it. >> >>> 3.2 >>> . >>> Implementation . . . . . . . . . . . . . . . . . . . . . 5 >>> >>> >>> >>> 3.2.1 >>> . >>> Alternatives . . . . . . . . . . . . . . . . . . . . 6 >>> >>> >>> >>> >>> 3.2 is the implementation of what? The intro in section 3? >> 3.2 yes is an example mitigiation based on 3 paragraph 2 >> >>> So why do you insert alternatives 3.1 (which you don't >>> recommend) in between? And 3.2.1 is the alternative to what? >>> the implementation in section 3.2 >> 3.2.1 yes. the point being there's more than one way to solve >> the problem. operationally one approach may be more desirable the >> the other, in point of fact when I asked the cloudflare guys came >> up with their's so I added it. >> >> >>> 3. >>> >>> 1. Filter-based-forwarding matches next-header ICMPv6 type-2 >>> and matches a next-hop on a particular subnet directly attached >>> to both border routers. The filter is policed to reasonable >>> limits (we chose 1000pps, more conservative rates might be >>> required in other implementations). >>> >>> border router? make it consistent with the terminology in >>> figure 1 >> ok routers >> >>> 2. Filter is applied on input side of all external interfaces >>> >>> Make it clear that you speak about router in figure 1 >> external routers >> >>> 4. Anycast servers receive the PTB error and process packet >>> as needed. >>> >>> "anycast server" make it consistent with the terminology is >>> figure 1 >> figure 1 is bounded by width limitations for ascii art otherwise >> the label would be longer, the fact that it is naycast is brought >> up in section 2. we can probably arrange to us server more freely >> in the text prior to this. >> >>> 4. Section 3.2.1 "ECMP hop could distribute the proxy onto the >>> end systems" >> Alternatively, network designs in which a common layer 2 network >> exists on the ECMP hop could distribute the proxy onto the end >> systems, eliminating the need for policy routing. >> >> Proxy in this case refers to the mitigiation proposed in section >> 3 paragraph 2 of which this is a sub section. >> >> The excerpt is missing a preposition ( exists on the ECMP hop) >> and I agree it's hard to parse without that. >> >>> Not sure what it means. >>> >>> 5. section 4. Improvements to what? The implementation or the >>> potential specification. >> These are improvements on the mitigation. they are not >> specification changes rfc 4821 already exists it's just not >> widely (at all afaik) used. >> >>> I guess the "specification", but then, how is this different >>> that the mitigation section? Your improvement point 1 is the >>> same as the "mitigation" section paragraph 1 >> Right but no asic or at least microcode exists today can actually >> do that. >> >>> Your improvement point 2 is the same as the "mitigation" >>> section paragraph 2 >> no it isn't. in the mitigitation it was necessary to build a >> proxy to flood them by rewritting the L2 nexthop. that's rather >> different than getting router to forward a unicast packet to say >> 16 destinations if somebody gives me a knob for the latter then >> all this proxy junk is done. >> >>> nits: implmentation -> implementation >>> >>> Regards, Benoit >>> >>> >>> >>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlX5vqgACgkQ8AA1q7Z/VrK8BACcCQnn4z025QbtYZn3EQpkACUL fAAAn3CFC/AHRSRFAIqGkdmEKeb9AII6 =JSSb -----END PGP SIGNATURE----- From nobody Fri Sep 18 14:14:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93281B4677 for ; Tue, 15 Sep 2015 07:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ1R28klSe6t for ; Tue, 15 Sep 2015 07:44:07 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03241B3AAA for ; Tue, 15 Sep 2015 07:44:02 -0700 (PDT) Received: by ioii196 with SMTP id i196so202058523ioi.3 for ; Tue, 15 Sep 2015 07:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=GgjAcssyz7YLBLrsMebTMbtpNlLWrL3PoGHjDPuHkQ4=; b=okYhPJyscybcTZDibwSF6YMFVP3x20y29v/21M/cJUu0YbzQeaqZ/IQSmc9exYJJMO Q6yNfCM2b7MouvBKx2vU5V9xH3oxJRBTVX/XZyQmD/lFNXw+0n+07pqOeYdB1LuXip6q nJyq212N9PUkT+N5UftBxaokKDN4VPDazZFbdd8K/b4/JzKgB+vFd6ZEL/NxyxqwDUq+ 4EuVhn34Vzs+w5fN0AZNK0O3PyqI+orp3vmshZsYNGxRQyN245tXD2ZZCsa8grAlBnXa r97Uh/nZfQxilS37fJZ6WFtOGQd62HHokZl26Ibfmgg/rx15WVuo+KcIswj1fju4TrUW WKeA== X-Received: by 10.107.134.24 with SMTP id i24mr34452529iod.162.1442328242064; Tue, 15 Sep 2015 07:44:02 -0700 (PDT) Received: from [192.168.0.11] (CPEbc4dfba74ed1-CMbc4dfba74ed0.cpe.net.cable.rogers.com. [99.241.125.8]) by smtp.gmail.com with ESMTPSA id y100sm8218874ioi.29.2015.09.15.07.44.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 07:44:01 -0700 (PDT) From: Tom Taylor To: "Fred Baker (fred)" , v6ops list References: Message-ID: <55F82EB0.90807@gmail.com> Date: Tue, 15 Sep 2015 10:44:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 18 Sep 2015 14:14:43 -0700 Cc: "simon.perreault@viagenie.ca" , "cliffwang2000@yahoo.com" , "draft-sivakumar-yang-nat@tools.ietf.org" , "raraghun@cisco.com" , "srisuresh@yahoo.com" , "rrohit74@hotmail.com" , Immo Wehrenberg , "npai@cisco.com" Subject: Re: [v6ops] draft-sivakumar-yang-nat-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 14:44:09 -0000 Metacomment: work up to now on NAT MIB and logging has been cross-posted to the Behave and OPSAWG lists. The module looks reasonable. One general point concerns me, and may be applicable to other Yang documents. To make the module completely intelligible, there should be a description of the applicability of its various components to particular use cases. Is the intention to have such discussion in the Yang module document itself or in a separate document? On a specific technical point: the module restricts itself to an enumeration of transport protocols: UDP, TCP, and ICMP. I thought one of the lessons learned from NAT-MIB-V1 was that the protocol list should be generalized. On the other hand, when I went to apply this principle in suggesting compliance in NAT-MIB-V2, I found it a little tricky to decide just which values in the IANA protocol registry should be supported. I note that only the pool-related notifications are supported, in contrast to the broader set defined by the MIB module. I'll be happy to have comments on that. The statistics are also presented at a courser granularity only, I think, but I will have to do a detailed comparison to be sure. These are just my impressions from skimming over the document. A few detailed comments: On timeouts: units should be stated. What is the difference between mapping-limit and connection-limit? Typo: s/leaf port-preservation-suport/leaf port-preservation-support/ Typo: under "leaf port-free": s/addresses/ports/ in the description Tom Taylor On 08/09/2015 12:18 PM, Fred Baker (fred) wrote: > The authors of draft-sivakumar-yang-nat are looking for a home for it. This is a YANG management model for NATs, including NAT64, NPTv6, and other variants. > > In the revised charter filed with the IESG, this would be most similar to the third issue, which is a catch-all. It fits if we say that it fits. https://datatracker.ietf.org/doc/charter-ietf-v6ops/. There may also be other options; I am specifically asking the sunset4 chairs whether it fits there, and one wonders about int-area. The obvious working groups, behave and softwire, are closed or closing. > > My question for the moment is a simple one: many of us are looking at YANG as a network management model; would a YANG model for a translator be useful to those operating 464XLAT, SIIT-DC, MAP-T/E, or other networks that target IPv6 operation and require translation of some type? If so, would this be a useful starting point, and would this working group be an appropriate place to discuss it? I have copied the authors of network management efforts related to NAT and some operators I know are using it. > > If in answering the question anyone were to review the document and compare it to RFC 4008 or other models for information and structure to be modeled, I imagine the authors would appreciate that. > From nobody Fri Sep 18 14:14:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC8F1AC3B4 for ; Thu, 17 Sep 2015 08:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8Kc4Xz8B8o8 for ; Thu, 17 Sep 2015 08:50:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836EF1ACE38 for ; Thu, 17 Sep 2015 08:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3952; q=dns/txt; s=iport; t=1442505002; x=1443714602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eEsCrXM+fQidw1/ZMMZ+Nq8Bcs4hO+Z5CYcq+zgJf80=; b=hiXGlN5RZkxD8MDLp+JBBQuJupQivFhOyxyPnhPAKzFQ+qofg3sTTzjh 0H13kRSWdNlLPzoSXIaiomMCEr8FOU8jfYTn/eGydWR7bRfckbjcvBoEC mBdLtjyj5F81Rbz8m5bzJffZp1aJeVzj+mS0PHJAiL4ygOORW4YcluZJH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AQAQ4PpV/5FdJa1dgyNUaQa9PAENgXmFeQKBQTgUAQEBAQEBAYEKhCQBAQR5EAIBCBguIRElAgQBDQWIGQMSDccFDYRZAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLcIJQgWVYB4QsBY01iCwBhRCGB4Fuk1uHPx8BAUKEAXEBiGJCgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,547,1437436800"; d="scan'208";a="33514289" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Sep 2015 15:50:01 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8HFo1Zd027944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Sep 2015 15:50:01 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 17 Sep 2015 10:49:48 -0500 Received: from xhc-aln-x12.cisco.com (173.36.12.86) by xch-rcd-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 17 Sep 2015 10:49:48 -0500 Received: from xmb-rcd-x15.cisco.com ([169.254.5.6]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 10:49:08 -0500 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , "Fred Baker (fred)" , v6ops list Thread-Topic: draft-sivakumar-yang-nat-01.txt) Thread-Index: AQHQ6lH0XgsZU/ervEy/nj9OfpvGuJ4+CRgAgALzywA= Date: Thu, 17 Sep 2015 15:49:07 +0000 Message-ID: References: <55F82EB0.90807@gmail.com> In-Reply-To: <55F82EB0.90807@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [173.36.7.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 18 Sep 2015 14:14:43 -0700 Cc: "simon.perreault@viagenie.ca" , "cliffwang2000@yahoo.com" , "draft-sivakumar-yang-nat@tools.ietf.org" , "raraghun@cisco.com" , "srisuresh@yahoo.com" , "rrohit74@hotmail.com" , Immo Wehrenberg , "npai@cisco.com" Subject: Re: [v6ops] draft-sivakumar-yang-nat-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 15:50:05 -0000 The applicability is broad enough to cover most of the use cases, I don=B9t think=20 we need to restrict ourselves to specific use cases. The intention here Is to capture the commonality in MOST of the use cases, and leave the vendor specific implementation details to specific vendors. The transport protocol field in the mapping table can represent protocols other than TCP/UDP/ICMP. But the TCP/UDP/ICMP are well defined in the NAT behave RFCs that require certain behavior and hence the config options for them. The notifications are currently the low threshold for pools and ports, it can be extended to have high threshold like we have in the MIB. The mapping limits are for static mappings, connection limits are dynamically created mappings. Thanks for the other editorial comments, we will take care of it in the next rev. Thanks Senthil On 9/15/15, 10:44 AM, "Tom Taylor" wrote: >Metacomment: work up to now on NAT MIB and logging has been cross-posted >to the Behave and OPSAWG lists. > >The module looks reasonable. One general point concerns me, and may be >applicable to other Yang documents. To make the module completely >intelligible, there should be a description of the applicability of its >various components to particular use cases. Is the intention to have >such discussion in the Yang module document itself or in a separate >document? > >On a specific technical point: the module restricts itself to an >enumeration of transport protocols: UDP, TCP, and ICMP. I thought one of >the lessons learned from NAT-MIB-V1 was that the protocol list should be >generalized. On the other hand, when I went to apply this principle in >suggesting compliance in NAT-MIB-V2, I found it a little tricky to >decide just which values in the IANA protocol registry should be >supported. > >I note that only the pool-related notifications are supported, in >contrast to the broader set defined by the MIB module. I'll be happy to >have comments on that. The statistics are also presented at a courser >granularity only, I think, but I will have to do a detailed comparison >to be sure. These are just my impressions from skimming over the document. > >A few detailed comments: > >On timeouts: units should be stated. > >What is the difference between mapping-limit and connection-limit? > >Typo: s/leaf port-preservation-suport/leaf port-preservation-support/ > >Typo: under "leaf port-free": s/addresses/ports/ in the description > >Tom Taylor > > > >On 08/09/2015 12:18 PM, Fred Baker (fred) wrote: >> The authors of draft-sivakumar-yang-nat are looking for a home for it. >>This is a YANG management model for NATs, including NAT64, NPTv6, and >>other variants. >> >> In the revised charter filed with the IESG, this would be most similar >>to the third issue, which is a catch-all. It fits if we say that it >>fits. https://datatracker.ietf.org/doc/charter-ietf-v6ops/. There may >>also be other options; I am specifically asking the sunset4 chairs >>whether it fits there, and one wonders about int-area. The obvious >>working groups, behave and softwire, are closed or closing. >> >> My question for the moment is a simple one: many of us are looking at >>YANG as a network management model; would a YANG model for a translator >>be useful to those operating 464XLAT, SIIT-DC, MAP-T/E, or other >>networks that target IPv6 operation and require translation of some >>type? If so, would this be a useful starting point, and would this >>working group be an appropriate place to discuss it? I have copied the >>authors of network management efforts related to NAT and some operators >>I know are using it. >> >> If in answering the question anyone were to review the document and >>compare it to RFC 4008 or other models for information and structure to >>be modeled, I imagine the authors would appreciate that. >> From nobody Fri Sep 18 14:14:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311021A90EC for ; Fri, 18 Sep 2015 00:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WlvsQms9Ukb for ; Fri, 18 Sep 2015 00:30:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2881A00E7 for ; Fri, 18 Sep 2015 00:30:53 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 8DE822AC0CB; Fri, 18 Sep 2015 09:30:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B220D38406B; Fri, 18 Sep 2015 09:30:50 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0248.002; Fri, 18 Sep 2015 09:30:50 +0200 From: To: "Senthil Sivakumar (ssenthil)" , Tom Taylor , "Fred Baker (fred)" , v6ops list Thread-Topic: draft-sivakumar-yang-nat-01.txt) Thread-Index: AQHQ6lH0XgsZU/ervEy/nj9OfpvGuJ4+CRgAgALzywCAAPT58A== Date: Fri, 18 Sep 2015 07:30:49 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300539575E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <55F82EB0.90807@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.18.70617 Archived-At: X-Mailman-Approved-At: Fri, 18 Sep 2015 14:14:43 -0700 Cc: "simon.perreault@viagenie.ca" , "cliffwang2000@yahoo.com" , "draft-sivakumar-yang-nat@tools.ietf.org" , "raraghun@cisco.com" , "srisuresh@yahoo.com" , "rrohit74@hotmail.com" , Immo Wehrenberg , "npai@cisco.com" Subject: Re: [v6ops] draft-sivakumar-yang-nat-01.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 07:30:56 -0000 Hi all, I fully agree with Senthil.=20 Cheers, Med > -----Message d'origine----- > De=A0: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] > Envoy=E9=A0: jeudi 17 septembre 2015 17:49 > =C0=A0: Tom Taylor; Fred Baker (fred); v6ops list > Cc=A0: draft-sivakumar-yang-nat@tools.ietf.org; sperreault@jive.com; > tina.tsou.zouting@huawei.com; cathyzhou@huawei.com; > cliffwang2000@yahoo.com; srisuresh@yahoo.com; simon.perreault@viagenie.ca= ; > j.schoenwaelder@jacobs-university.de; npai@cisco.com; raraghun@cisco.com; > rrohit74@hotmail.com; Immo Wehrenberg > Objet=A0: Re: draft-sivakumar-yang-nat-01.txt) >=20 > The applicability is broad enough to cover most of the use cases, I don= =B9t > think > we need to restrict ourselves to specific use cases. The intention here > Is to capture the commonality in MOST of the use cases, and leave the > vendor specific implementation details to specific vendors. >=20 > The transport protocol field in the mapping table can represent protocols > other than TCP/UDP/ICMP. But the TCP/UDP/ICMP are well defined in the NAT > behave > RFCs that require certain behavior and hence the config options for them. >=20 > The notifications are currently the low threshold for pools and ports, it > can be > extended to have high threshold like we have in the MIB. >=20 > The mapping limits are for static mappings, connection limits are > dynamically created mappings. >=20 > Thanks for the other editorial comments, we will take care of it in the > next rev. >=20 > Thanks > Senthil >=20 >=20 > On 9/15/15, 10:44 AM, "Tom Taylor" wrote: >=20 > >Metacomment: work up to now on NAT MIB and logging has been cross-posted > >to the Behave and OPSAWG lists. > > > >The module looks reasonable. One general point concerns me, and may be > >applicable to other Yang documents. To make the module completely > >intelligible, there should be a description of the applicability of its > >various components to particular use cases. Is the intention to have > >such discussion in the Yang module document itself or in a separate > >document? > > > >On a specific technical point: the module restricts itself to an > >enumeration of transport protocols: UDP, TCP, and ICMP. I thought one of > >the lessons learned from NAT-MIB-V1 was that the protocol list should be > >generalized. On the other hand, when I went to apply this principle in > >suggesting compliance in NAT-MIB-V2, I found it a little tricky to > >decide just which values in the IANA protocol registry should be > >supported. > > > >I note that only the pool-related notifications are supported, in > >contrast to the broader set defined by the MIB module. I'll be happy to > >have comments on that. The statistics are also presented at a courser > >granularity only, I think, but I will have to do a detailed comparison > >to be sure. These are just my impressions from skimming over the > document. > > > >A few detailed comments: > > > >On timeouts: units should be stated. > > > >What is the difference between mapping-limit and connection-limit? > > > >Typo: s/leaf port-preservation-suport/leaf port-preservation-support/ > > > >Typo: under "leaf port-free": s/addresses/ports/ in the description > > > >Tom Taylor > > > > > > > >On 08/09/2015 12:18 PM, Fred Baker (fred) wrote: > >> The authors of draft-sivakumar-yang-nat are looking for a home for it. > >>This is a YANG management model for NATs, including NAT64, NPTv6, and > >>other variants. > >> > >> In the revised charter filed with the IESG, this would be most similar > >>to the third issue, which is a catch-all. It fits if we say that it > >>fits. https://datatracker.ietf.org/doc/charter-ietf-v6ops/. There may > >>also be other options; I am specifically asking the sunset4 chairs > >>whether it fits there, and one wonders about int-area. The obvious > >>working groups, behave and softwire, are closed or closing. > >> > >> My question for the moment is a simple one: many of us are looking at > >>YANG as a network management model; would a YANG model for a translator > >>be useful to those operating 464XLAT, SIIT-DC, MAP-T/E, or other > >>networks that target IPv6 operation and require translation of some > >>type? If so, would this be a useful starting point, and would this > >>working group be an appropriate place to discuss it? I have copied the > >>authors of network management efforts related to NAT and some operators > >>I know are using it. > >> > >> If in answering the question anyone were to review the document and > >>compare it to RFC 4008 or other models for information and structure to > >>be modeled, I imagine the authors would appreciate that. > >> From nobody Fri Sep 18 16:05:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DC71B3911 for ; Fri, 18 Sep 2015 16:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBxmSf3COk_d for ; Fri, 18 Sep 2015 16:05:02 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 DB3061B390F for ; Fri, 18 Sep 2015 16:05:01 -0700 (PDT) Received: by igbni9 with SMTP id ni9so27327534igb.0 for ; Fri, 18 Sep 2015 16:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OlF+GYEgOzOXJgxTMQXS6bQ3NZl952wLavEPXx4498w=; b=LjN3biTajt+6AEyn9VYTgNdUFeoGOBg2nDTTisRdE8k+yEOcB7CIhrHFmdKdGxDcO1 y/jHG3DhwXZzTu8RZ2mK1N+bnBGIDrjwQj0DKe5HxZWcZgeL/nZ40ebz6rRe12IEO8Zp Wh5XmKeh0yaGQgZ8Numl3dEWlFa2dqc/73h9iHosNWbFYP1a1Gy44mKyJAvJ6La2AqFE OlQ8Z22pUW+dtWSI+LEUMKm2/sffYN14h5XMdeENj+/iBxe4AZQ0avfTAUzYHWDEHKlg fM0c61tXxvqpijc7tVtY0lTqqONFKmgRg2cU9+u5lxzAFnNM6pe2Z5BvtvyDSxxcFxUX /ZvA== MIME-Version: 1.0 X-Received: by 10.50.111.167 with SMTP id ij7mr780892igb.41.1442617501197; Fri, 18 Sep 2015 16:05:01 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.140.12 with HTTP; Fri, 18 Sep 2015 16:05:01 -0700 (PDT) In-Reply-To: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Date: Fri, 18 Sep 2015 16:05:01 -0700 X-Google-Sender-Auth: rOhMJjJBmLdSM--ZuwFqJHQ0m5g Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 23:05:03 -0000 At Thu, 17 Sep 2015 22:44:25 +0200 (CEST), Mikael Abrahamsson wrote: > > Now, specifically what would we propose with this document so we won't > > end up using NAT66 in this situation? Discouraging the operators of > > The operator(s) needs to understand that they can't charge per-device > because that doesn't actually work, because then the customer will deploy > NAT66, then the operator will deploy DPI to look into user-agent string, > and then the customer will encrypt everythingm and now the operator has > lost all insight into what the customer is doing, and the operator has > lost and we're all worse off than when we started. If we can convince those operators about stopping the per-device charge this way, what we actually need is a "Per-device connectivity charge is considered ineffective and harmful" draft. Then the operators will stop the practice, and there will be no reason for implementing and deploying NAT66 for, e.g., VMs (at least for this reason); we don't need the host-addr-availability draft to stop NAT66. Likewise, > The proposal is to use DHCPv6-PD because otherwise we'll get NAT66, as you > already have identified. we won't need to propose this; the straightforward "bridge mode" should just work without extra charge. I think this matters, since the proposal of using DHCPv6-PD requires a certain amount of implementation and operational cost for both the network operator and host-side implementors (such as VM vendors). I don't deny that the host-addr-availability draft may be useful for other reasons, so I'm not necessarily opposed to advancing this draft because of this. But my interpretation of the draft was that it intends to avoid the proliferation of NAT66 in cases like this scenario, and I was not sure whether host-addr-availability is really effective: if we can simply convince hotel network operators, we'll only need the above "ineffective and harmful" draft; if not, it's also quite unlikely that those operators are willing to deploy DHCPv6-PD, so host-addr-availability will be still not effective. Or, it's also quite possible that I completely misunderstood something, such as about the purpose of the draft or how it can be used for the scenario I asked. If so, I'm happy to be corrected. -- JINMEI, Tatuya From nobody Fri Sep 18 21:19:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248E71A1B0B for ; Fri, 18 Sep 2015 21:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVjj2scfZhQI for ; Fri, 18 Sep 2015 21:19:32 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EFF1A1AFC for ; Fri, 18 Sep 2015 21:19:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C8320A1; Sat, 19 Sep 2015 06:19:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442636369; bh=nNMwuFg7Cg2EtH3cyAwi9/B47aMraTklxa+TVt33jAw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZI4eiWMyuCNojK983b3TU6wW2B8kqmCq3sAvaNs5JG7vY+OA4kBtEEiXoz5IhZZgA weFAfbnSbgkoQISjYmyq2uTmRAX0xx+KUfP/nlWz4rjcDdB4YrJK2sUVfetLhGJMRp deGP3eyy7p+7QHNlpKkdUQIXxTBdldpUizFAqvuA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BC8FC9F; Sat, 19 Sep 2015 06:19:29 +0200 (CEST) Date: Sat, 19 Sep 2015 06:19:29 +0200 (CEST) From: Mikael Abrahamsson To: =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= In-Reply-To: Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1589930565-1442636369=:8750" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 04:19:35 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1589930565-1442636369=:8750 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 18 Sep 2015, 神明達哉 wrote: > If we can convince those operators about stopping the per-device charge > this way, what we actually need is a "Per-device connectivity charge is > considered ineffective and harmful" draft. Then the operators will stop > the practice, and there will be no reason for implementing and deploying > NAT66 for, e.g., VMs (at least for this reason); we don't need the > host-addr-availability draft to stop NAT66. Well, there are operational benefits of using DHCPv6-PD to hosts as well, instead of using a lot of individual addresses. When doing BCP38 filtering and other operations on packets, it's usually more effective to have fewer resources (addresses/prefixes) to act on. Some wifi systems only allow for 8 addresses simultaneously for a host, and just drop all packets from any additional addresses. > we won't need to propose this; the straightforward "bridge mode" > should just work without extra charge. I think this matters, since > the proposal of using DHCPv6-PD requires a certain amount of > implementation and operational cost for both the network operator and > host-side implementors (such as VM vendors). I'd say most of the cost is on the host OS implementor side, and looking at who brought this draft, they are actually the ones suggesting this. > I don't deny that the host-addr-availability draft may be useful for > other reasons, so I'm not necessarily opposed to advancing this draft > because of this. But my interpretation of the draft was that it > intends to avoid the proliferation of NAT66 in cases like this > scenario, and I was not sure whether host-addr-availability is really > effective: if we can simply convince hotel network operators, we'll > only need the above "ineffective and harmful" draft; if not, it's > also quite unlikely that those operators are willing to deploy > DHCPv6-PD, so host-addr-availability will be still not effective. Android does not today support DHCPv6 IA_NA. So if that continues, a large part of the mobile device market will not support a DHCPv6 IA_NA network, and a network provider trying to do this, will not succeed in providing connectivity. I can imagine more devices that do support IA_NA will treat that networks as one "with limited capability" and turn off some functions. This is how we drive network operators to support IA_PD instead, by making the customers aware of what's going on. There are two ways that actually solves the problem at hand: Use SLAAC, but give each Wifi connection its own separate /64 using A=1 (separate broadcast domain per wifi attachment). This works with keeping track of who did what etc, just save the mac address or 802.1x credentials together with the /64 that was given, you can do filtering on this /64 etc. Use DHCPv6-PD and give the device a /XX. Both of these works exactly the same as in IPv4 with the same tracking ability etc that I have heard enterprise and education provider desire to keep from their current IPv4 deployments. But it does require them to move from "One address per device" thinking, to "one subnet per device" thinking, which is the exact thing this draft tries to propose. I think the current draft tries to do both "single address is harmful" and also "here's how to solve it". So I don't think it's enough to have a "this is harmful"-draft, we also need proposed solution, which this draft proposes. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1589930565-1442636369=:8750-- From nobody Fri Sep 18 23:25:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0831B54F4 for ; Fri, 18 Sep 2015 23:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db6JmAExBsgw for ; Fri, 18 Sep 2015 23:25:01 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002: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 28AA61B54F3 for ; Fri, 18 Sep 2015 23:25:01 -0700 (PDT) Received: by ykdt18 with SMTP id t18so64837982ykd.3 for ; Fri, 18 Sep 2015 23:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zxzi8Foo/ubD0DIlWm7DoeFZWz2fMCcx8aZohbwAnWI=; b=nsicB5JNf9YoPbgs8RIZcr8OZdSZh0b2gQuRyw42hozTyBCgDyMaDqjIrbHiqVHJnb +PvNUn6TAfxLPn91CoBTHnDQbPfrkRZiQeXEh3Ne6ZJZ9h8gIbg0/DykdBT671PnwwTK 5sgZf+7JVeZCS4wGmv2pzpJ++G8ccUObZMwzflh4Tt87YdkyCknTSgcgcP3pUzt1WijY YGVIy/I4GSmfv+g96PUM/TXhKqMaeGaH1HWkTAEFU3aO+P/HETLEKqAzjq6DIjVJi6LC uAANyNILfoVY64kONUPB9FG/ZwJQEJXuumAtOS7J3gGw5lBZEed5Mkt+H9ETwhi314z+ 1LeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zxzi8Foo/ubD0DIlWm7DoeFZWz2fMCcx8aZohbwAnWI=; b=MaVBNrRZVw2hJcdtexr3Mq7UZ+6aUeQs0r2UC00HCSday1feyzuPKhuIkOkyPMnYtD vHyUKx626COq4Mun6om/EhTHsgx77VikXKC8mG41Inn4/G+Ohfl4HMPWVNXrwGwdIW+C 3mLENtbHMMO7YHj8Bsyc5f6UPEUG4lR6pInOh/VH5Ue8vYzGSVzM6jal1RtjtmA+SWEs yWbNq+LREHpxJVr1mVyIe8WsgQqvq9gK6Vv25P0UMK5VO3TuVXPr+4vMDN9XQ2iSxeO0 yitspSKriIMKMh1ewPLnbDJb1hTbq0TIFh3HmMbRGr+GrP8TzxijOSKHSPB9uOGb8qWa Cprg== X-Gm-Message-State: ALoCoQna+SMQHDg6sV1yTcOOmz2GOCGwvGN0OSJk/Yi0zzNrROf5AU3l9ENRKI/RDn4RzjhVERUP X-Received: by 10.13.233.193 with SMTP id s184mr8177500ywe.88.1442643900311; Fri, 18 Sep 2015 23:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Fri, 18 Sep 2015 23:24:40 -0700 (PDT) In-Reply-To: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Sat, 19 Sep 2015 15:24:40 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c068ee0378d99052013b5aa Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 06:25:02 -0000 --94eb2c068ee0378d99052013b5aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 18, 2015 at 5:05 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > But, I think I'd like to understand some bigger picture, even if this > may be out of scope of this particular document in the end. Consider > cases like a hotel network where hotel guests are charged connectivity > fee per the number of MAC (layer 2) addresses so every different > "device" is charged separately. I suspect such setup is not uncommon, > and I guess avoiding the "double charge" is one motivation for > supporting NAT66 for VMs (https://communities.vmware.com/docs/DOC-29954). > > Now, specifically what would we propose with this document so we won't > end up using NAT66 in this situation? What we recommend is that operators do not attempt to do this, because there is no point in doing so. The reason that there is no point in doing so is that a device can *always* extend the network, even if it only has one IP address. All it needs to do is to enable NAT for the devices behind it. The draft makes this point very clearly: =3D=3D=3D=3D=3D=3D It is likely not desirable for network operators either, as they may suffer higher support costs, and even when the decision to assign only one IPv6 address per device is dictated by the network's business model, there may be little in the way of incremental revenue, because devices can share their IPv6 address with other devices. =3D=3D=3D=3D=3D=3D So, what we are telling network operators is: "we do not recommend that you do this, because there's not much point in doing it, and it's worse for everybody if you do." If they want to do it anyway, well, there's not much we can do about that. --94eb2c068ee0378d99052013b5aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 18, 2015 at 5:05 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
But, I think I'd l= ike to understand some bigger picture, even if this
may be out of scope of this particular document in the end.=C2=A0 Consider<= br> cases like a hotel network where hotel guests are charged connectivity
fee per the number of MAC (layer 2) addresses so every different
"device" is charged separately.=C2=A0 I suspect such setup is not= uncommon,
and I guess avoiding the "double charge" is one motivation for supporting NAT66 for VMs (https://communities.vmware.co= m/docs/DOC-29954).

Now, specifically what would we propose with this document so we won't<= br> end up using NAT66 in this situation?

What = we recommend is that operators do not attempt to do this, because there is = no point in doing so. The reason that there is no point in doing so is that= a device can *always* extend the network, even if it only has one IP addre= ss. All it needs to do is to enable NAT for the devices behind it. The draf= t makes this point very clearly:

=3D=3D=3D=3D=3D= =3D
=C2=A0 =C2=A0It is likely
=C2=A0 =C2=A0not= desirable for network operators either, as they may suffer higher
=C2=A0 =C2=A0support costs, and even when the decision to assign only one= IPv6
=C2=A0 =C2=A0address per device is dictated by the network&= #39;s business model, there
=C2=A0 =C2=A0may be little in the way= of incremental revenue, because devices can
=C2=A0 =C2=A0share t= heir IPv6 address with other devices.
=3D=3D=3D=3D=3D=3D

So, what we are telling network operators is: &q= uot;we do not recommend that you do this, because there's not much poin= t in doing it, and it's worse for everybody if you do."
=
If they want to do it anyway, well, there's not much we = can do about that.
--94eb2c068ee0378d99052013b5aa-- From nobody Fri Sep 18 23:33:25 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628D11B556C for ; Fri, 18 Sep 2015 23:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QWAI2TbY60j for ; Fri, 18 Sep 2015 23:33:22 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 3A0321B556A for ; Fri, 18 Sep 2015 23:33:22 -0700 (PDT) Received: by ykft14 with SMTP id t14so65044437ykf.0 for ; Fri, 18 Sep 2015 23:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Zlv6Fz0mIfDPUZAPEtamd1FZyeJItM22KXhNBicEjM=; b=a29FW1T4f8PVmqZyL6qkgaM9EQXBxQHav48qkePKFyN3Br+2+53zaeKSOptnAAEdDS cSKz0mYdwqSL/fLh8zfYWoxryoNheEWI1dAUn9GL35ggHaWR3hNtvFI+nwtc6TklkaAH wQB1P/s84KgtirXOVO1vT4iH+DoTe/iJqQmRLjqm5KqAwCfW+Iv18bWg8d5pvmOmvNi4 iJctl0SdsEeBfA9Z7CqVZqi9rzy2/vvkPVJRxr3q/Nfbsw6nm8Fy1P8cBqNyU49iTYTx fxQIgvSVKZOv3n1VjpSu/1N7mT2AYEhlLwZRaekam/S/3MQm7lF8PsAT/EayUeOlLymw d/qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2Zlv6Fz0mIfDPUZAPEtamd1FZyeJItM22KXhNBicEjM=; b=KfWhjzxCWWzZLZdRZoUdmtS3QJOafpIJQrSS2O5QwJ/+/L/ZSJ8Y64xXJ/JGHpBOtC 8s6bU6m86l+V6ADdsFJLwKCBc/nZBJqN+zmjrSURJN7w43dn+HBQdV5EiE+UgWEc97oP qkRAleTkoVKxdPAGVV4/T/5THllfWVSJEuukLMq6JuHaIe75XL9trBtRoT27uLO4GNKz Au1zhIvC1xNP7rp1D1E4yyY+9JIlLM8Eq8M8C/PWFm1Y4ecWhQfAh1NkqYLedQUmdgKp Jbjm5M014UbfYVpGZ2BnMQhYa/DVBuE3DyW7umJUT35WilHiIrXeLxlHJpTOus1Dy65b oJpg== X-Gm-Message-State: ALoCoQnk0ttVFubJDCrbMQSd16b/qeueQhWAWD822yG4w3exvs2Mu4CYfxdd4ySemDEq2oJO+Oig X-Received: by 10.13.240.71 with SMTP id z68mr8254554ywe.65.1442644401413; Fri, 18 Sep 2015 23:33:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Fri, 18 Sep 2015 23:33:01 -0700 (PDT) In-Reply-To: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Sat, 19 Sep 2015 15:33:01 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c03281815b30b052013d3b8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 06:33:23 -0000 --94eb2c03281815b30b052013d3b8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Sep 19, 2015 at 8:05 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > If we can convince those operators about stopping the per-device > charge this way, what we actually need is a "Per-device connectivity > charge is considered ineffective and harmful" draft. Then the > operators will stop the practice I don't think we will stop operators from doing this just by writing an RFC saying it's a bad idea. :-) > we won't need to propose this; the straightforward "bridge mode" > should just work without extra charge. The reason we propose DHCPv6 PD is because some network operators - particularly enterprise and educational network operators - insist that the only way their network will assign IPv6 addresses is via DHCP. In many of these networks (e.g., networks doing 802.1x) bridging isn't even an option. Once you have decided to use DHCPv6, you have two options: multiple IA_NA and PD. We believe that DHCPv6 PD is better and more future-proof than multiple IA_NA for the reasons listed in sections 7 and 8. --94eb2c03281815b30b052013d3b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Sep 19, 2015 at 8:05 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
If we can convince tho= se operators about stopping the per-device
charge this way, what we actually need is a "Per-device connectivity charge is considered ineffective and harmful" draft.=C2=A0 Then the operators will stop the practice

I don'= t think we will stop operators from doing this just by writing an RFC sayin= g it's a bad idea. :-)
=C2=A0
we won= 9;t need to propose this; the straightforward "bridge mode"
should just work without extra charge.

The = reason we propose DHCPv6 PD is because some network operators - particularl= y enterprise and educational network operators - insist that the only way t= heir network will assign IPv6 addresses is via DHCP. In many of these netwo= rks (e.g., networks doing 802.1x) bridging isn't even an option.
<= div>
Once you have decided to use DHCPv6, you have two option= s: multiple IA_NA and PD. We believe that DHCPv6 PD is better and more futu= re-proof than multiple IA_NA for the reasons listed in sections 7 and 8.
--94eb2c03281815b30b052013d3b8-- From nobody Sat Sep 19 02:30:46 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99171B582C for ; Sat, 19 Sep 2015 02:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcxdrMkB-QvN for ; Sat, 19 Sep 2015 02:30:43 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 6C6891B582B for ; Sat, 19 Sep 2015 02:30:42 -0700 (PDT) Received: (qmail 45496 invoked from network); 19 Sep 2015 09:30:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 19 Sep 2015 09:30:39 -0000 Date: Sat, 19 Sep 2015 11:30:39 +0200 (CEST) Message-Id: <20150919.113039.74710669.sthaug@nethelp.no> To: swmike@swm.pp.se From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, jinmei@wide.ad.jp Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 09:30:44 -0000 > Well, there are operational benefits of using DHCPv6-PD to hosts as well, > instead of using a lot of individual addresses. When doing BCP38 filtering > and other operations on packets, it's usually more effective to have fewer > resources (addresses/prefixes) to act on. Some wifi systems only allow for > 8 addresses simultaneously for a host, and just drop all packets from any > additional addresses. As an operator, I'd *love* to only give out DHCPv6-PD prefixes, and get completely rid of IA_NA. Unfortunately, host support for PD is not exactly great. Steinar Haug, AS 2116 From nobody Sat Sep 19 02:39:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19481B589A for ; Sat, 19 Sep 2015 02:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLFQ3XtP0Gk2 for ; Sat, 19 Sep 2015 02:39:08 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002: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 CC3F81B5899 for ; Sat, 19 Sep 2015 02:39:07 -0700 (PDT) Received: by ykft14 with SMTP id t14so66811282ykf.0 for ; Sat, 19 Sep 2015 02:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ong14Gd1ZEASq2bAj7UCUesoWjSNFLwCJiavZVYUpb0=; b=X8Ds7fndPP785pKESU1hj8euukvLEnQUd+wwLIBi8n9w9FBrAKNE6l2b6SC93zA751 zh2j+ZW5U1jHi/NMbEikPw4NpzyEFKftI2biN/tRvSosRkQ+QWXmFUVJljEhPyL8pzUI wdzNyYAoTbgGSibECY/HLvH4//Rfsj5PeR+nQqHsg221KqB+wTgjsbKbHK89xlXfZFHq Dwb0RIlu/SMUbJ5W4S+yJ/13FJCflebfZz6dnSxUIp/UVxCrHGh0T/vF5IIkfQ+LInfK VnJSAaEPRRBjFh6qvkFyhDrwHmd3XVECu/80ogmMntO2O0Ej99PvfA8KZ/Hi02K4NhLJ 6zgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ong14Gd1ZEASq2bAj7UCUesoWjSNFLwCJiavZVYUpb0=; b=JeVQ7GN7eHjWM8OUrm9i4my3/YF2vMixS+7XAk3V2EutU5GTXmw4jUbF/NbSv7k2dR vQneBmiqsSqYZJMJgAoI3zK0Wfoxxqg9XwOOhLjOFLf0juDtc5tqlGij6cTtZtA7v9vA XjQllcNaYJy3kfAlJjpG/Slij+qVhI3JHYep6+O6f+GNCNmzNbpV09ckmkFg8dNOWXGC ft/zdYFWNPtYcoS4PR9oktJ/yo3SsxcNNWbslNhOkhpyzDc3orElbZfb/upQBllULCy/ KuRQrUyiS4/NtfwTiGSeITNuDjLiFkY4s0EEYcL0xr0zdWabAgI+yBoHh8i4vYo24r48 YEcg== X-Gm-Message-State: ALoCoQlQhgUBs+jbib2SHJiUYRfnmZj6yaWz4fEUISesm2IOQ7Watu57YGzEUXyP660b915qRTs2 MIME-Version: 1.0 X-Received: by 10.170.69.66 with SMTP id l63mr8268598ykl.89.1442655546831; Sat, 19 Sep 2015 02:39:06 -0700 (PDT) Received: by 10.37.52.204 with HTTP; Sat, 19 Sep 2015 02:39:06 -0700 (PDT) Received: by 10.37.52.204 with HTTP; Sat, 19 Sep 2015 02:39:06 -0700 (PDT) In-Reply-To: <20150919.113039.74710669.sthaug@nethelp.no> References: <20150919.113039.74710669.sthaug@nethelp.no> Date: Sat, 19 Sep 2015 18:39:06 +0900 Message-ID: From: Lorenzo Colitti To: sthaug@nethelp.no Content-Type: multipart/alternative; boundary=001a113998ba676dfc0520166b14 Archived-At: Cc: "v6ops@ietf.org WG" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 09:39:08 -0000 --001a113998ba676dfc0520166b14 Content-Type: text/plain; charset=UTF-8 On 19 Sep 2015 6:30 p.m., wrote: > > As an operator, I'd *love* to only give out DHCPv6-PD prefixes, and > get completely rid of IA_NA. Unfortunately, host support for PD is > not exactly great. Publishing this draft as an RFC will help change that. --001a113998ba676dfc0520166b14 Content-Type: text/html; charset=UTF-8

On 19 Sep 2015 6:30 p.m., <sthaug@nethelp.no> wrote:
>
> As an operator, I'd *love* to only give out DHCPv6-PD prefixes, and
> get completely rid of IA_NA. Unfortunately, host support for PD is
> not exactly great.

Publishing this draft as an RFC will help change that.

--001a113998ba676dfc0520166b14-- From nobody Sat Sep 19 02:42:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5607D1B58C0 for ; Sat, 19 Sep 2015 02:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ndIHIRynlid for ; Sat, 19 Sep 2015 02:41:59 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 158861B58BF for ; Sat, 19 Sep 2015 02:41:59 -0700 (PDT) Received: by igxx6 with SMTP id x6so32063315igx.1 for ; Sat, 19 Sep 2015 02:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ibZOhXDZe+v2fM8/wY0GBjqgMzc55vMNoBUYlg5fDKw=; b=iNBTE4pSNYZP7t2RpZgbmNlcAA8B3U0qhihPVO052puObXzEPzsf8lm6Q1zH6J6RB2 au5CgHJhIjW2xWvAsFBaJevasfxzknU98fso+adRbUdlQBZI/ObewL91ruzZq+pgF5SI yIcx8/qfD4kQw8188YnNtilytsr2F1FYlDzX94q1WFp/vQjy+JCKZXnl+kFTX9Kc5mRm PZZ6HiKOokzo6K1R3Omv/DljEe4IThG/6sOa7S9FjqrkvC0+J+decQMfWKbzdNMFnxER 9hWbiU1xG1d+WnXAn+TOa2Ec+0zdtBKA14rb8qdzkvPktC9QHa552AA79KtNV+6zQyDk 7dDA== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr2235353igl.18.1442655718488; Sat, 19 Sep 2015 02:41:58 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Sat, 19 Sep 2015 02:41:57 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Sat, 19 Sep 2015 02:41:57 -0700 (PDT) In-Reply-To: References: <20150919.113039.74710669.sthaug@nethelp.no> Date: Sat, 19 Sep 2015 19:41:57 +1000 Message-ID: From: Mark Smith To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=089e011825c0a24130052016750b Archived-At: Cc: "v6ops@ietf.org WG" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 09:42:00 -0000 --089e011825c0a24130052016750b Content-Type: text/plain; charset=UTF-8 On 19 Sep 2015 19:39, "Lorenzo Colitti" wrote: > > On 19 Sep 2015 6:30 p.m., wrote: > > > > As an operator, I'd *love* to only give out DHCPv6-PD prefixes, and > > get completely rid of IA_NA. Unfortunately, host support for PD is > > not exactly great. > > Publishing this draft as an RFC will help change that. > +1 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e011825c0a24130052016750b Content-Type: text/html; charset=UTF-8


On 19 Sep 2015 19:39, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On 19 Sep 2015 6:30 p.m., <sthaug@nethelp.no> wrote:
> >
> > As an operator, I'd *love* to only give out DHCPv6-PD prefixes, and
> > get completely rid of IA_NA. Unfortunately, host support for PD is
> > not exactly great.
>
> Publishing this draft as an RFC will help change that.
>

+1

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

--089e011825c0a24130052016750b-- From nobody Sat Sep 19 03:12:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E861ACCD9 for ; Sat, 19 Sep 2015 03:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVL-ZJdBJHWP for ; Sat, 19 Sep 2015 03:12:42 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 6611B1ACC83 for ; Sat, 19 Sep 2015 03:12:41 -0700 (PDT) Received: (qmail 46994 invoked from network); 19 Sep 2015 10:12:39 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 19 Sep 2015 10:12:39 -0000 Date: Sat, 19 Sep 2015 12:12:39 +0200 (CEST) Message-Id: <20150919.121239.41673351.sthaug@nethelp.no> To: lorenzo@google.com From: sthaug@nethelp.no In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops@ietf.org, jinmei@wide.ad.jp Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 10:12:43 -0000 > The reason we propose DHCPv6 PD is because some network operators - > particularly enterprise and educational network operators - insist that the > only way their network will assign IPv6 addresses is via DHCP. In many of > these networks (e.g., networks doing 802.1x) bridging isn't even an option. > > Once you have decided to use DHCPv6, you have two options: multiple IA_NA > and PD. We believe that DHCPv6 PD is better and more future-proof than > multiple IA_NA for the reasons listed in sections 7 and 8. Fully agreed. We would like to get to a point where we don't use IA_NA at all, only DHCPv6 PD. Steinar Haug, AS 2116 From nobody Sun Sep 20 11:00:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400CE1A0140 for ; Sun, 20 Sep 2015 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.011 X-Spam-Level: X-Spam-Status: No, score=-113.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IXHASH_X1=1.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLT_rWyZQ5LX for ; Sun, 20 Sep 2015 11:00:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE03C1A0141 for ; Sun, 20 Sep 2015 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=129; q=dns/txt; s=iport; t=1442772004; x=1443981604; h=date:from:message-id:to:subject:cc; bh=4kIRMaErY1jozgSq+oF7sLMWlB9Xgi2sO31pBVcvju4=; b=JLTqO2Cs202RTAVfhl/Sz8qB8fOXfueakr2tgm0jD1G7L+FkbjN9AWjG meYP88TqcKKaIBgyqjszFaRAL32FKP+aDaxuj1/Mtd2Ziqj1lxjwVQZZ7 4fYKfZnrOobU0Zk4VcdxzZEpFT/OgY2rMypcO2UGRo3pIrDcLmY06EMsd w=; X-IronPort-AV: E=Sophos;i="5.17,563,1437436800"; d="scan'208";a="33969255" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 20 Sep 2015 18:00:04 +0000 Received: from irp-lnx1.cisco.com (irp-lnx1.cisco.com [171.70.41.115]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8KI03w8009438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Sep 2015 18:00:03 GMT Received: from irp-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by irp-lnx1.cisco.com (8.13.8/8.13.8) with ESMTP id t8KI028X014507; Sun, 20 Sep 2015 11:00:02 -0700 Received: (from fred@localhost) by irp-lnx1.cisco.com (8.13.8/8.13.8/Submit) id t8KI02hV014499; Sun, 20 Sep 2015 11:00:02 -0700 Date: Sun, 20 Sep 2015 11:00:02 -0700 From: fred@cisco.com Message-Id: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> To: v6ops@ietf.org Archived-At: Subject: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 18:00:06 -0000 The working group last call for this draft announced last week continues for another week. Please feel free to comment on it. From nobody Mon Sep 21 06:38:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5866F1B31AF for ; Mon, 21 Sep 2015 06:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a90oqRdDo4m6 for ; Mon, 21 Sep 2015 06:38:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786981B31B5 for ; Mon, 21 Sep 2015 06:38:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8LDck0s008135 for ; Mon, 21 Sep 2015 15:38:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7AB93207117 for ; Mon, 21 Sep 2015 15:43:44 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 67E132070AB for ; Mon, 21 Sep 2015 15:43:44 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8LDcird004168 for ; Mon, 21 Sep 2015 15:38:45 +0200 To: v6ops@ietf.org References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> From: Alexandre Petrescu Message-ID: <56000864.2080600@gmail.com> Date: Mon, 21 Sep 2015 15:38:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:38:51 -0000 I agree with the recommendation: in case DHCP is used then deliver more than just one address to the Host. My last comment is: if a prefix is delivered with DHCP-PD then how does the Host form an address out of it? Alex Le 20/09/2015 20:00, fred@cisco.com a écrit : > The working group last call for this draft announced last week > continues for another week. Please feel free to comment on it. > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 21 06:47:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6521B31D9 for ; Mon, 21 Sep 2015 06:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzROYY_r1lu8 for ; Mon, 21 Sep 2015 06:46:55 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9AA1B31D2 for ; Mon, 21 Sep 2015 06:46:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 03524A1; Mon, 21 Sep 2015 15:46:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442843213; bh=3ZYSPm401QWNhGUuKffuveeIT8mmSzRSAooKBL1XtDU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Do/phScOVChr8az0Ytj0FttRzEXuwiflCzCchrncWIoH2hvekDQ3DJAH5cKIf3OEe 3tz0c8Lco3dTlLIO28DjrnSFHKerG3wT1uAkLsCc8pPnVmf1QlpLAPR1sufUMINuSJ upSCYuVuH4u7hwmZM33sQQg/1yBxNmN79rO5K94g= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F04DD9F; Mon, 21 Sep 2015 15:46:52 +0200 (CEST) Date: Mon, 21 Sep 2015 15:46:52 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu In-Reply-To: <56000864.2080600@gmail.com> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:47:02 -0000 On Mon, 21 Sep 2015, Alexandre Petrescu wrote: > My last comment is: if a prefix is delivered with DHCP-PD then how does > the Host form an address out of it? Well, that's up to the host. If it gets a /64, null route that /64, then it could configure an additional loopback address with a /96 and start adding IPv6 addresses to that /96, and then use those for outgoing communication. It might be that there is a need for some kind of recommendation document in this area, because I think it's not obvious to all implementors how to do this. I have historically advocated to not have a WAN IPv6 address but instead just use PD to home gateways, and the amount of opposition I have had on this proposal is quite substantial, so I think it might make sense to give out recommendation in this area, how to handle a delegated prefix when you do not have an IPv6 GUA/ULA address on the interface wherefrom you received the delegation. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 21 06:55:23 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5CC1B31F1 for ; Mon, 21 Sep 2015 06:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnH8S-Y26eNd for ; Mon, 21 Sep 2015 06:55:20 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C391B31F2 for ; Mon, 21 Sep 2015 06:55:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8LDtH09027121; Mon, 21 Sep 2015 15:55:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0859920249C; Mon, 21 Sep 2015 16:00:16 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E5E4B201224; Mon, 21 Sep 2015 16:00:15 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8LDtGQs014138; Mon, 21 Sep 2015 15:55:17 +0200 To: Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> From: Alexandre Petrescu Message-ID: <56000C44.5090001@gmail.com> Date: Mon, 21 Sep 2015 15:55:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:55:22 -0000 Mikael, I agree that it is up to the Host how to make that address, and how to set it on its (virtual) interfaces. Even simple things like forming an IID and pasting it along the prefix are not specified other than for SLAAC. It might be they deserve making into a recommendation. Alex Le 21/09/2015 15:46, Mikael Abrahamsson a écrit : > On Mon, 21 Sep 2015, Alexandre Petrescu wrote: > >> My last comment is: if a prefix is delivered with DHCP-PD then how >> does the Host form an address out of it? > > Well, that's up to the host. > > If it gets a /64, null route that /64, then it could configure an > additional loopback address with a /96 and start adding IPv6 addresses > to that /96, and then use those for outgoing communication. > > It might be that there is a need for some kind of recommendation > document in this area, because I think it's not obvious to all > implementors how to do this. I have historically advocated to not have a > WAN IPv6 address but instead just use PD to home gateways, and the > amount of opposition I have had on this proposal is quite substantial, > so I think it might make sense to give out recommendation in this area, > how to handle a delegated prefix when you do not have an IPv6 GUA/ULA > address on the interface wherefrom you received the delegation. > From nobody Mon Sep 21 06:55:31 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4DC1B31F9 for ; Mon, 21 Sep 2015 06:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCjRrxNCNppW for ; Mon, 21 Sep 2015 06:55:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2046A1B31F6 for ; Mon, 21 Sep 2015 06:55:25 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so112880281wic.1 for ; Mon, 21 Sep 2015 06:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=boSNSLUQZ+J3kzyFNdfPnW8Tzajh3gKTXZElC+skdW4=; b=ja8m+0IhMOcpxW/jU9WG60ZSUHxRiJDLxM5o/kAhSzelK1aL9Ig9odzG/rkx0jiWB8 XecP7NolvnWuUGutQm8HyK5m6eqFMA5yIDyHFudWQPK0aIpuBrKX2XrAK5jW9THQoOnr E7CD0JwAhnhW8X7T7PIMxRS0QErdd1WdxoTg2kXW1BA9mx7Ieh1o8iERhhXzpt+2Anrf pnZfw9TPBlCWcgGlXnS8BI4CyM5VnXa/dTtvIEGb8wDd6cJMW7185f64tIYqYX/Ifiw3 evme2LZXWt/2AfXmjjeih1kkZHDQB3mlQewDDM697kS7wqDcZLzWiwzLADTKaPZzFjqh eekw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=boSNSLUQZ+J3kzyFNdfPnW8Tzajh3gKTXZElC+skdW4=; b=ds71h5/n+UAzk122EwzLf/Cni4BHhBpWi4mAlEsWLoua/skMZ6H3+D7+Fn+kSXquHV 6w/b6/6gLSj5ylJign08vt0ALre77iGKVG4BVbK0c1qXEAAC14R4cCbwhtswDHsSz0dy CJmjtxEzJvcwTOMaVsvx57o+V7iDvauz75zIxlXt2GItMbIsabEnwbnSbEZVe8zWGV+O 3aFk2NrUiCPgG/SQmlNuCBvkyVsYAhNXAO3isVqVEVXyTiCglhTDUPMM18O4aLaRpgTd pfaCbNKvn34YhPw3T7/7RFW1tL0ncJZ6m8co6Pn28UsJEc8tiXNLquedjc2yyolx9ONN ztWQ== X-Gm-Message-State: ALoCoQl3yYR5U87mduDKlGnpU+0RogWm7v6bPcqi6pxNuj4dP95qTzc10sfAsDnuFYOdZL3NSuGX X-Received: by 10.194.103.103 with SMTP id fv7mr27142603wjb.152.1442843723054; Mon, 21 Sep 2015 06:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.136.81 with HTTP; Mon, 21 Sep 2015 06:55:03 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> From: Erik Kline Date: Mon, 21 Sep 2015 22:55:03 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 13:55:26 -0000 On 21 September 2015 at 22:46, Mikael Abrahamsson wrote: > On Mon, 21 Sep 2015, Alexandre Petrescu wrote: > >> My last comment is: if a prefix is delivered with DHCP-PD then how does >> the Host form an address out of it? > > > Well, that's up to the host. > > If it gets a /64, null route that /64, then it could configure an additional > loopback address with a /96 and start adding IPv6 addresses to that /96, and > then use those for outgoing communication. > > It might be that there is a need for some kind of recommendation document in > this area, because I think it's not obvious to all implementors how to do > this. I have historically advocated to not have a WAN IPv6 address but > instead just use PD to home gateways, and the amount of opposition I have > had on this proposal is quite substantial, so I think it might make sense to > give out recommendation in this area, how to handle a delegated prefix when > you do not have an IPv6 GUA/ULA address on the interface wherefrom you > received the delegation. I wouldn't support any one methodology, but I do think that perhaps it's important to say what requirements any chosen methodology would have to meet. For example, the node would clearly not have to perform DAD for any address it creates within the prefix by the usual method of sending packets off-host and detecting conflicts. However, it might be important to perform some sort of node-local DAD if there are multiple VMs amongst which the host is bridging the received prefix. It's not immediately clear to me if such discussion is purely operational, or if it might stray into 6man territory. From nobody Mon Sep 21 09:13:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139F11A90E9 for ; Mon, 21 Sep 2015 09:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRYMw2hh15hV for ; Mon, 21 Sep 2015 09:13:18 -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 D0BFA1A90EC for ; Mon, 21 Sep 2015 09:13:18 -0700 (PDT) Received: from mb.local ([8.18.217.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t8LGD9cs020176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Sep 2015 16:13:12 GMT (envelope-from joelja@bogus.com) To: Lorenzo Colitti , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <56002C8C.7010601@bogus.com> Date: Mon, 21 Sep 2015 09:13:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Thunderbird/41.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wjIbSPP2EXXDBNrIuBGqas01aq0K52Vfa" Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:13:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wjIbSPP2EXXDBNrIuBGqas01aq0K52Vfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9/18/15 11:33 PM, Lorenzo Colitti wrote: > On Sat, Sep 19, 2015 at 8:05 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <= jinmei@wide.ad.jp > > wrote: >=20 > If we can convince those operators about stopping the per-device > charge this way, what we actually need is a "Per-device connectivit= y > charge is considered ineffective and harmful" draft. Then the > operators will stop the practice >=20 >=20 > I don't think we will stop operators from doing this just by writing an= > RFC saying it's a bad idea. :-) I don't have a problem with the idea of describing a particular approach as bad on the basis of technical merit. thou must allow tethering on the other hand is about business models which I'm really not interested in delving into. there are diverse methods used dto enforce that however.= >=20 > we won't need to propose this; the straightforward "bridge mode" > should just work without extra charge. >=20 > > The reason we propose DHCPv6 PD is because some network operators - > particularly enterprise and educational network operators - insist that= > the only way their network will assign IPv6 addresses is via DHCP. In > many of these networks (e.g., networks doing 802.1x) bridging isn't eve= n > an option. it's unlikely in the context of homenetworks or mobile devices that bridging is universally acceptable in any event. > Once you have decided to use DHCPv6, you have two options: multiple > IA_NA and PD. We believe that DHCPv6 PD is better and more future-proof= > than multiple IA_NA for the reasons listed in sections 7 and 8. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --wjIbSPP2EXXDBNrIuBGqas01aq0K52Vfa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlYALI8ACgkQ8AA1q7Z/VrJ1MACdE0ffUIAiwL2mrmN7A8yHg09u D18An3JOmhBI+ItAVT4IW6M6oCFCJsee =SB/2 -----END PGP SIGNATURE----- --wjIbSPP2EXXDBNrIuBGqas01aq0K52Vfa-- From nobody Mon Sep 21 11:57:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B448C1B33DF for ; Mon, 21 Sep 2015 11:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZdLWO1QMga4 for ; Mon, 21 Sep 2015 11:57:54 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613D21B329C for ; Mon, 21 Sep 2015 11:57:54 -0700 (PDT) Received: by igxx6 with SMTP id x6so64523763igx.1 for ; Mon, 21 Sep 2015 11:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=95e/fYm5DxOflqHJ95XtwLZW7KNx+Bo5K96+6ArMZ/M=; b=lsg6MYl7BkJc+CMXQvlazmHFRojlpHN9mDhGxIeGsaP7c4d61+78EfGYRm1+p+g4pc xf8OF869gcJtYKmvEreQr+VTHTOEC0NViaTG9hag5roHFtkZMgimDpsKhfdNGFlSL0a+ Wow4vXbL4ueTwyP28Dyybvgo2JOF3Hk2Wt5WQcYGNw3RE/iVQ2zYFlYtDEbx7LBywl6h TDCFbQELvKpM5pZBu0j6zw7hH9nB+E6esBrAPWHUqJTwNYQDTrgEvXn0tZaTcBq7H0pg Ht5XKT4HITFpVn8Q35M4mhjFcjmyhx4F6Y8ninWOZAnu92Us6GOFtld3x4fmJTjI3ewB uz6Q== MIME-Version: 1.0 X-Received: by 10.50.111.113 with SMTP id ih17mr11745902igb.64.1442861873637; Mon, 21 Sep 2015 11:57:53 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.140.12 with HTTP; Mon, 21 Sep 2015 11:57:53 -0700 (PDT) In-Reply-To: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Date: Mon, 21 Sep 2015 11:57:53 -0700 X-Google-Sender-Auth: _kk0DZloWYoduY9pBCvceQpbxyo Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 18:57:55 -0000 At Sat, 19 Sep 2015 15:33:01 +0900, Lorenzo Colitti wrote: > > If we can convince those operators about stopping the per-device > > charge this way, what we actually need is a "Per-device connectivity > > charge is considered ineffective and harmful" draft. Then the > > operators will stop the practice > > I don't think we will stop operators from doing this just by writing an RFC > saying it's a bad idea. :-) To be clear, I didn't intend to suggest writing an "ineffective and harmful" draft. I also know the host-addr-availability draft explicitly discusses why it doesn't recommend practices like per-device charge. What I've been trying to say is: - the most critical point to prevent the proliferation of NAT66 is to convince those operators that per-device charge is a bad idea (or at least not effective) - if they agree on this, we can then discuss better practices of host address configuration, DHCPv6-PD for each host, just use SLAAC, etc. - if they don't agree, having the "better practice" discussions won't be very useful, since they won't be willing to deploy DHCPv6-PD, and regardless how they assign addresses the number of addresses will be still limited anyway. I said I wanted to see a "bigger picture" in my first message of this thread because on first read my impression was that the "big goal" (or at least one important goal) of this draft was to stop NAT66 while it rather seemed to focus on the "less critical points" (the second and third bullets above). But, according to the discussion in this thread, perhaps I misunderstood this fundamental point. Perhaps I should have interpreted it as: - although we don't like to see NAT66 due to practices like per-device charge and we can point out why such a practice might not be a good/effective idea, we don't know if it will convince those operators. (and, therefore, NAT66 may or may not be more widely used). - but, *if* they stop those practices with this argument or for some other reasons, we can think about better/best ways to assign IPv6 addresses for end hosts. This draft focuses on this part in the hypothetical environment where there's no such practice as per-device charge. Am I now understanding the intent more accurately? -- JINMEI, Tatuya From nobody Tue Sep 22 00:18:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C0F1A0045 for ; Tue, 22 Sep 2015 00:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.088 X-Spam-Level: X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sHtjTby5KNY for ; Tue, 22 Sep 2015 00:18:53 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405941A0029 for ; Tue, 22 Sep 2015 00:18:53 -0700 (PDT) Received: by ykft14 with SMTP id t14so1042951ykf.0 for ; Tue, 22 Sep 2015 00:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=97gZqkshAX+LV2hue0XI/m83QmHvBgJHuZdPN3T9rTA=; b=YG/24KF3Kp1QtWw1dPOFj2zZLEactpSIqv0QRotvtr+WFAEaRIHU3zWxSoMa+s7hBq 01UTvxgzEDfrRFUwL008wdTDk+RJL/30rz4mZAJ1Oy54Lkagk+f/RV/8Uc1Q/FxujFOa sUdaHHS2zyZFVuir+Xm87M6arCo74w+6LlH5rVbi3+/IeqW7wiW0nai8NgiMNkAcF4EM IfpYa3ySIXsGRJfJcgoogvks25zSqP1C4OpOHDfeFOEcgXsNtwHHAH61wsj3EqwGiLZc rjPZ14LVjdrUPAmTTRxZyUDoP3FoVpzpn8JT5B/ooitOn9+HVmADJw8I9rsgy1mo6OAQ C0Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=97gZqkshAX+LV2hue0XI/m83QmHvBgJHuZdPN3T9rTA=; b=cDluiUWE7d+/FikoINXgXpmZflrCiExwkJa/jv1KXPgXQA3NJa2s6AX823qstiV76l Fk3F6q6o1eyZHmV8zEDYMsYm29MMm96AJK6D2vAtMpJUNCBjObOO8x3xUaQQMmCwXCXL Tv0sTH3PI6CuUidZtcXSeBq3BbXh4ENmT1x6DpuC0aCzn5tf2HOD3NPEgJ7JfTroKvgu or7KPieAvNQkUTxDYjv3V+GnoRIbQahU7iD0jlIRNvOmfYwi+9bVdcYHm9Kfmu/lQVdj IVKsvV0WxtjlfUJWdGJFGtNlhgAYZhVI7uhhwoJhqyLmJlJ15OBBTuAoCzB160ISHaTM 6gTA== X-Gm-Message-State: ALoCoQmCY3tH3aAeEcVe6OzNk2GJSFW51vGNNoZL3l6LKX4MVsF5WGxEGKDjsgDld7Zn8kJAhYWo X-Received: by 10.13.255.4 with SMTP id p4mr9535557ywf.88.1442906332295; Tue, 22 Sep 2015 00:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Tue, 22 Sep 2015 00:18:32 -0700 (PDT) In-Reply-To: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Lorenzo Colitti Date: Tue, 22 Sep 2015 16:18:32 +0900 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Content-Type: multipart/alternative; boundary=94eb2c0874e661dac9052050cf94 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 07:18:54 -0000 --94eb2c0874e661dac9052050cf94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2015 at 3:57 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > Am I now understanding the intent more accurately? > I think you're only focusing on part of the picture - operators that assign a limited number of addresses per device out of a desire to obtain more revenue. Another part of the picture is deployments that only support IPv6 addressing via DHCPv6 and do not support SLAAC. Some of the network administrators have said they do this partly due to a desire to have "one GUA per device" or "a limited number of GUAs per device". These networks are likely *not* concerned with per-device revenue, but they still provide a limited number of addresses for other reasons (some of which may be operational, or even scaling reasons). Because they are not concerned with per-device revenue, even if we convince people that per-device charging is ineffective to increase revenue, then these networks will still be assigning a limited number of addresses per device. This is why the draft makes a more general statement about all networks that do not provide enough address space, regardless of the reason. To respond to your earlier concern that we shouldn't recommend DHCPv6 PD because of the implementation and operational cost, then I would note that: 1. The draft does not recommend DHCPv6 PD in general, only on networks whose policy is to hand out address space only based on explicit request= s from the host. The vast majority (in terms of number of connected device= s) of networks, which use SLAAC, do not fall into that category 2. What's the alternative? If DHCPv6 PD is too much work, then that rules out designing a new protocol, since that's even more work. That leaves either SLAAC or DHCPv6. If the network has decided that stateful, request-based assignment is the only supported way to obtain addresses (e.g., for security reasons), then I doubt they're ever going to use SLA= AC. At that point, it's either multiple IA_NA or DHCPv6 PD, and as set out i= n the draft, there are strong reasons to recommend PD over multiple IA_NA. Cheers, Lorenzo --94eb2c0874e661dac9052050cf94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 22, 2015 at 3:57 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinmei@= wide.ad.jp> wrote:
Am I now understanding= the intent more accurately?

I think yo= u're only focusing on part of the picture - operators that assign a lim= ited number of addresses per device out of a desire to obtain more revenue.=

Another part of the picture is deployments that o= nly support IPv6 addressing via DHCPv6 and do not support SLAAC. Some of th= e network administrators have said they do this partly due to a desire to h= ave "one GUA per device" or "a limited number of GUAs per de= vice". These networks are likely *not* concerned with per-device reven= ue, but they still provide a limited number of addresses for other reasons = (some of which may be operational, or even scaling reasons). Because they a= re not concerned with per-device revenue, even if we convince people that p= er-device charging is ineffective to increase revenue, then these networks = will still be assigning a limited number of addresses per device.

This is why the draft makes a more general statement about = all networks that do not provide enough address space, regardless of the re= ason.

To respond to your earlier concern that we s= houldn't recommend DHCPv6 PD because of the implementation and operatio= nal cost, then I would note that:
  1. The draft does not reco= mmend DHCPv6 PD in general, only on networks whose policy is to hand out ad= dress space only based on explicit requests from the host. The vast majorit= y (in terms of number of connected devices) of networks, which use SLAAC, d= o not fall into that category
  2. What's the alternative? If DH= CPv6 PD is too much work, then that rules out designing a new protocol, sin= ce that's even more work. That leaves either SLAAC or DHCPv6. If the ne= twork has decided that stateful, request-based assignment is the only suppo= rted way to obtain addresses (e.g., for security reasons), then I doubt the= y're ever going to use SLAAC. At that point, it's either multiple I= A_NA or DHCPv6 PD, and as set out in the draft, there are strong reasons to= recommend PD over multiple IA_NA.
Cheers,
Lorenzo
--94eb2c0874e661dac9052050cf94-- From nobody Tue Sep 22 01:51:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4478D1A1A06 for ; Tue, 22 Sep 2015 01:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ubgYL__ZM6m for ; Tue, 22 Sep 2015 01:51:22 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 530681A19F7 for ; Tue, 22 Sep 2015 01:51:22 -0700 (PDT) Received: by iofh134 with SMTP id h134so8992891iof.0 for ; Tue, 22 Sep 2015 01:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GWoFJgIB0uvJy3vBqw+IXdyUlu1jNU8Y3ehxy7g6pJk=; b=bU0bVu6DrnnOeptHPyn2J5NYCytuX/+Fl4u9WRS20rwcEW64qL+sY69bHVVscOcrT0 fEP6rxD04/4+y0i/+QBNewZ2kW3VBc4oovvlSylOFCUgGtFWTsgBj4SZJhMPctftnoVl SbjkkNdgnybSqZ3TGeZuH8v0ywRICScSsoSHNgzgDkFgCfvi8jvfq7w909v8yyIer9hZ oscv8vnVC4xEBhJ14TYEr642u3v6YJFCZ+l67i91pO5OjqT53DiR0cYVny2330i09ONz 5MSPxoytNrSYzWsnA6Q6pR+63nMoS9nIxgAV/ixpQEVT7jb6PtOVJc6eb+B+F1+7YMer J33w== X-Received: by 10.107.19.234 with SMTP id 103mr34994793iot.41.1442911881813; Tue, 22 Sep 2015 01:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.148 with HTTP; Tue, 22 Sep 2015 01:50:52 -0700 (PDT) In-Reply-To: <56000864.2080600@gmail.com> References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> From: Mark Smith Date: Tue, 22 Sep 2015 18:50:52 +1000 Message-ID: To: Alexandre Petrescu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 08:51:23 -0000 Hi Alex, On 21 September 2015 at 23:38, Alexandre Petrescu wrote: > I agree with the recommendation: in case DHCP is used then deliver more > than just one address to the Host. > > My last comment is: if a prefix is delivered with DHCP-PD then how does > the Host form an address out of it? > One way it can be implemented is that the host is conceptually considered a 'one-armed' router, and the delegated prefix/delegated prefix addresses are present on an internal virtual interface, with routing/forwarding occurring between the external/internal interfaces. The addresses on the internal virtual interface would then preferred as source/destination addresses by the host (for the purposes of address selection, including announcing/advertising for referral purposes) over the address(es) present on the host's single physical interface. Strictly that means that all traffic from the host has been forwarded one hop as it leaves the host, as it conceptually originated from the internal virtual interface, and then was forwarded/routed onto the physical interface. The Hop Count should be decremented for this internal to external hop, however it probably isn't necessary to and worthwhile not doing so. Similarly in theory the hop count should be decremented when the host forwards the packets it receives from the external interface to the internal virtual interface, before delivering them to the upper layers. Regards, Mark. From nobody Tue Sep 22 02:03:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F3A1A1A2C for ; Tue, 22 Sep 2015 02:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFxsb_Iaso1R for ; Tue, 22 Sep 2015 02:03:11 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1541A0430 for ; Tue, 22 Sep 2015 02:03:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A2244A1; Tue, 22 Sep 2015 11:03:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442912588; bh=rt0g1hyD0zgIluYnQpnlViJSFIodPATywNwLfKCam6E=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hC6I9Z665FEALvfExU9fyHhszF1G0cD6dEnmrYeo1FanzRJX8qOpHnQNKh7/5cES+ 474FcWRPFuXiAvmpCB9RjreIKo1ayBx2qfrQ8Fcqm6BtqTp8MbJmFbtse2g62XdLTi Cvzgb+NAmtUA2zsFe03v/JXqlH62JunC2IC5D3ok= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9DDE49F; Tue, 22 Sep 2015 11:03:08 +0200 (CEST) Date: Tue, 22 Sep 2015 11:03:08 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 09:03:12 -0000 On Tue, 22 Sep 2015, Mark Smith wrote: > Strictly that means that all traffic from the host has been forwarded > one hop as it leaves the host, as it conceptually originated from the Sounds to me that this is just an incarnation of the weak host model, and I haven't heard anyone state that TTL should be decremented in that scenario? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 22 05:51:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6181A6FD4 for ; Tue, 22 Sep 2015 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-xcukonlnaf for ; Tue, 22 Sep 2015 05:51:00 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B790F1A6F4C for ; Tue, 22 Sep 2015 05:51:00 -0700 (PDT) Received: by iofb144 with SMTP id b144so13532278iof.1 for ; Tue, 22 Sep 2015 05:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vdSq847lkRCCihtd1FS+xyljaNqEATz8qPfEl+qiDEE=; b=u3DSWHWCA0jLZyxBHnAZtTxqDSDbs/MO82KLRM+TaKoWjScJYBugTjBu9G/Vw0ICD5 jFLw9jM2I/WkCQDEUuY9rzNZ79RJnctaWW8/NeQddpvjb1RfjJI/qHYS9t2zxSS0VD5P UtaxxMLcvTkhZpmeXtoeK/ENWzl+gi82n2h7kUPMNwNKIzVXHxZgYgrkreT7qFL0LS/+ Ls7ZN9vgewdqB9OzkR7GubaZfP+HB6CNbXbltyU8ivx+UmHr6nCzQxDwP+x1T0aRfPZZ hfSKFy3XB8p/uqnaeCkPzkS80hbJUDb+MoYwuokzypcnowVTvcQwESqilytyovIgcPFC LhVQ== X-Received: by 10.107.19.234 with SMTP id 103mr36168156iot.41.1442926260129; Tue, 22 Sep 2015 05:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.148 with HTTP; Tue, 22 Sep 2015 05:50:30 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> From: Mark Smith Date: Tue, 22 Sep 2015 22:50:30 +1000 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 12:51:02 -0000 On 22 September 2015 at 19:03, Mikael Abrahamsson wrote: > On Tue, 22 Sep 2015, Mark Smith wrote: > >> Strictly that means that all traffic from the host has been forwarded >> one hop as it leaves the host, as it conceptually originated from the > > > Sounds to me that this is just an incarnation of the weak host model, and I > haven't heard anyone state that TTL should be decremented in that scenario? > I've never been completely sure whether IPv6 supports the weak or strong host model, or whether it is possible for a host/implementation to be one or the other. I find RFC4291 a bit confusing in this regard: "IPv6 addresses of all types are assigned to interfaces, not nodes. An IPv6 unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node." This seems to be fundamentally saying weak host model, however the strong statement about addresses being assigned to interfaces not nodes suggests strong host model. II think it would be good for there to be an explicit statement about IPv6 hosts being strong or weak host model or supporting either host model, if one doesn't already exist that I'm aware of, just to remove any ambiguity. Regards, Mark. From nobody Tue Sep 22 06:22:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26DF1A7005 for ; Tue, 22 Sep 2015 06:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz3r6ms1O_EX for ; Tue, 22 Sep 2015 06:22:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469661A7002 for ; Tue, 22 Sep 2015 06:22:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 43940A1; Tue, 22 Sep 2015 15:22:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442928150; bh=NCJaFIxyWu7ypLtFxi7jcEPboXjJt5WKlw3GteIfvYU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XMnwtk3FOJ7jq8k2jURUFpuLCesciqKCv3GEG3l7+7XZQRdyFc0ijdckbmLvKAHHp kQKOxcQnkmccE1nEFEw9eSf1mHSITxps5TO6M0eoBcppKWZ2rIvLxorYqCv52mRXr1 Lu2L7KDp2c+rk8RFyHuvV8ABYXA3U6ka+0a0ZIJE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 38D029F; Tue, 22 Sep 2015 15:22:30 +0200 (CEST) Date: Tue, 22 Sep 2015 15:22:30 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 13:22:37 -0000 On Tue, 22 Sep 2015, Mark Smith wrote: > I've never been completely sure whether IPv6 supports the weak or strong > host model, or whether it is possible for a host/implementation to be > one or the other. I'd say a bit of both. I find that systems that will respond to an arp query for its eth1 address and the arp request comes in on eth0 to be fundamentally broken. Some people do not agree. From this aspect, I'd say my take is that IPv6 uses the strong hos model. However, most hosts will glady send out traffic sourced from eth0 IPv6 address via eth1, if that happens to be the best default route for the node, indicating weak host model. With hosts implementing MIF, I hope most things will be strong host model only. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 22 07:09:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621341A87B2 for ; Tue, 22 Sep 2015 07:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSV-GMzTjyaT for ; Tue, 22 Sep 2015 07:08:52 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 659B31A87C0 for ; Tue, 22 Sep 2015 07:08:49 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8ME4hG9029480; Tue, 22 Sep 2015 10:08:47 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 1x2uq36nuj-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Sep 2015 10:08:47 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8ME8kHF032549; Tue, 22 Sep 2015 10:08:47 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8ME8a1R032462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Sep 2015 10:08:41 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 22 Sep 2015 14:08:29 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0248.002; Tue, 22 Sep 2015 10:08:28 -0400 From: "STARK, BARBARA H" To: Mikael Abrahamsson , Mark Smith Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ8844Di976n/fM0G7qyXO32snA55HQRwAgAFB5wCAAANuAIAAP4YAgAAI8QD//8eIYA== Date: Tue, 22 Sep 2015 14:08:27 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA0F932@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-22_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509220206 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 14:08:55 -0000 > > I've never been completely sure whether IPv6 supports the weak or > > strong host model, or whether it is possible for a host/implementation > > to be one or the other. >=20 > I'd say a bit of both. >=20 > I find that systems that will respond to an arp query for its eth1 addres= s and > the arp request comes in on eth0 to be fundamentally broken. Some people > do not agree. From this aspect, I'd say my take is that IPv6 uses the str= ong > hos model. >=20 > However, most hosts will glady send out traffic sourced from eth0 IPv6 > address via eth1, if that happens to be the best default route for the no= de, > indicating weak host model. >=20 > With hosts implementing MIF, I hope most things will be strong host model > only. RFC 7084 requires (requirements copied below) CE routers to support the wea= k host model. Extensive discussion around the creation of these requirement= s suggested that anything trying to use an address from an assigned PD to o= riginate and respond to messages across its WAN interface would have to use= the weak model. Actually attaching one of these addresses to the WAN inter= face is strictly forbidden by some RFC (I can't remember which). So the add= ress is attached to a LAN or internal interface. Barbara WAA-7: If the IPv6 CE router does not acquire a global IPv6 address(es) from either SLAAC or DHCPv6, then it MUST create a global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces, unless configured to require a global IPv6 address on the WAN interface. =20 WAA-9: As a router, the IPv6 CE router MUST follow the weak host (Weak End System) model [RFC1122]. When originating packets from an interface, it will use a source address from another one of its interfaces if the outgoing interface does not have an address of suitable scope. From nobody Tue Sep 22 09:32:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A01A9111 for ; Tue, 22 Sep 2015 09:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4hQUT7bE8u2 for ; Tue, 22 Sep 2015 09:32:36 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 A035E1A9102 for ; Tue, 22 Sep 2015 09:32:36 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8MGTCNN011861 for ; Tue, 22 Sep 2015 12:32:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 1x2uq30du8-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 22 Sep 2015 12:32:36 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8MGWYHo009629 for ; Tue, 22 Sep 2015 12:32:35 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8MGWRcc009549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Sep 2015 12:32:28 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 22 Sep 2015 16:32:17 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0248.002; Tue, 22 Sep 2015 12:32:17 -0400 From: "STARK, BARBARA H" To: v6ops list Thread-Topic: v6ops-host-addr-availability: A Little Pushback Thread-Index: AdD1Qz3jXWgqKaqHS3ecNEGJMXADQg== Date: Tue, 22 Sep 2015 16:32:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-22_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509220228 Archived-At: Subject: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 16:32:38 -0000 I read through the draft and found myself feeling that the arguments presen= ted were rather uncompelling. So I'm going to provide some pushback. Since the draft is presenting itself as recommendations for *all* networks,= I decided to think about how I would look at it in the context of (1) a wi= reline broadband access service operator, (2) a wireless operator, and (3) = an enterprise network operator. Going through the list of benefits, the following struck me: 1. Privacy. Changing tracking requirements from needing to track a /128 to = only needing to track a /64 does not provide for any sort of improved priva= cy against tracking. We need to stop perpetuating this myth. draft-ietf-dhc= -dhcp-privacy already describes how to provide a single address that doesn'= t give away the MAC address. Other than not giving away the MAC, there is n= o privacy benefit I can see to more easily allowing tracking systems to tra= ck at the /64 instead of the /128. 2. Several of the listed benefits involve potential use by multiple process= ors on a host, virtual machines on a host, future applications, and identif= ier-locator addressing (ILA). In listing these, there was nothing that said= "this is incredibly useful, but hosts are prevented from doing it (or run = into a lot of complexity) if the host is restricted to a single DHCPv6-assi= gned IPv6 address". I didn't read that hosts would have a hard time having = multiple processors or future applications in the absence of multiple addre= sses, and I didn't get out of the discussion that virtual machines and ILAs= that require their own address are incredibly compelling and hosts and use= rs can't live without them. 3. Tethering and translation (like 464XLAT) tend to be really specific to w= ireless networks. These are the most compelling benefits listed, but they d= on't apply to enterprise and wireline. >From an enterprise and wireline perspective, I'm completely unconvinced tha= t the suggested benefits are worthy of a BCP recommendation.=20 >From a wireline perspective, I also see the recommendation as useless, sinc= e I'm not aware of any wireline architectures (BBF or CableLabs) that don't= do PD. The wireline operators don't need a BCP to tell them to continue do= ing this. Of course the reason they do PD isn't even listed as among the be= nefits, since they don't do this for the sake of attachment by an individua= l host. They do this so customers can run entire private networks behind a = fully-functional CE router. But I'm not aware of any wireline operator who = requires the device requesting IA-PD to be a router. >From a wireless perspective, I don't really see this as being what would co= nvince a wireless operator to deploy PD. The case I try to make is that wir= eless is more and more being used in the same manner as wireline: to suppor= t an entire LAN of networked devices behind a CE router (usually with a USB= -connected wireless device). In many places, operators are saying that wire= less is the deployment model for getting "broadband access" to rural areas.= If this use case is going to be fully supported with IPv6, then PD has to = be supplied. Of course, with wireless networks being able to easily recogni= ze the type of device used and the user, the network operator will always h= ave the ability to selectively offer the PD to only certain users and/or ce= rtain devices. Barbara From nobody Tue Sep 22 10:44:01 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C9B1A911D for ; Tue, 22 Sep 2015 10:44:00 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP-PpMUR9SeN for ; Tue, 22 Sep 2015 10:43:59 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.119.220]) by ietfa.amsl.com (Postfix) with ESMTP id 548271A911B for ; Tue, 22 Sep 2015 10:43:59 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128/128); for ; Tue, 22 Sep 2015 12:43:58 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-io0-f179.google.com [209.85.223.179] #+LO+TS+TR X-Umn-Classification: local Received: by ioii196 with SMTP id i196so21950276ioi.3 for ; Tue, 22 Sep 2015 10:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to; bh=IBth2+1OxNkCdr5Fgx/jvKhdPc1+DQbSfBtsOWr/kJU=; b=hwv2fjTpGEsKLuTUgG7NPPQbuY52z5hkFui1YXcjA1dLLEjrLQs6xBBrxHuz+91MnA EG5ZspOY/nFGMEya0rkITZOJHv3/wX3oXdVmDCKxmj88CdhBopOf20Q77Fe2BFfjxXVa vyRyB8HrmPu/FJCEPgiookAg3JgR/yVKT/PS0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version:content-type :message-id:content-transfer-encoding:cc:from:subject:date:to; bh=IBth2+1OxNkCdr5Fgx/jvKhdPc1+DQbSfBtsOWr/kJU=; b=myu3Gh4FA5U1YMn9XNT8CGaZoGIdHxOoTOYQyH+QrzV4SRuYEGnWZe59VQDIdNR17L If7F+kR3Rd2Ec0atTwfARppfuGuCQXyLnAa0NOe4lEE/faE+MKeIrha1KSTWgCIQftGH scqnXenFsxUY3Admg7t1iATrF3B/mwz96elACPx8n3eEty0lxffh/3dNReBE77fva7c+ 7a9Zop/C8M9URhJ0Kdk1tZGiK8qSjnW9Gf5LWFZqMCOA23EdcjHhmBxFS5y8mQoxmicB AAJO9LeQpviOdg/TzVr/6QwPpQLrLPZN+N0QhV//XbxxOjQc0m1f1JDqNW3Z+VWLhWtA fggw== X-Gm-Message-State: ALoCoQmC+EBq4REHV6yGfDeIg3lq8ag4oinxZGvX5Az/TaHJ7s0ffEcWxYJjsogfT7d9Ngm2934O0t4jbzKUkSHOfPA52IIngE55izu3743Yjwpy3QQoDorMTi/X1FSqlOEnSipat/pQ X-Received: by 10.107.9.79 with SMTP id j76mr34160576ioi.40.1442943837692; Tue, 22 Sep 2015 10:43:57 -0700 (PDT) X-Received: by 10.107.9.79 with SMTP id j76mr34160541ioi.40.1442943837331; Tue, 22 Sep 2015 10:43:57 -0700 (PDT) Received: from [10.0.0.7] (c-68-47-68-88.hsd1.mn.comcast.net. [68.47.68.88]) by smtp.gmail.com with ESMTPSA id h8sm1464687igh.7.2015.09.22.10.43.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Sep 2015 10:43:55 -0700 (PDT) References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <2D09D61DDFA73D4C884805CC7865E6113AA0F932@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA0F932@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (13A344) From: David Farmer Date: Tue, 22 Sep 2015 12:43:54 -0500 To: "STARK, BARBARA H" Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 17:44:01 -0000 On Sep 22, 2015, at 09:08, STARK, BARBARA H wrote: >>> I've never been completely sure whether IPv6 supports the weak or >>> strong host model, or whether it is possible for a host/implementation >>> to be one or the other. >>=20 >> I'd say a bit of both. >>=20 >> I find that systems that will respond to an arp query for its eth1 addres= s and >> the arp request comes in on eth0 to be fundamentally broken. Some people >> do not agree. =46rom this aspect, I'd say my take is that IPv6 uses the s= trong >> hos model. >>=20 >> However, most hosts will glady send out traffic sourced from eth0 IPv6 >> address via eth1, if that happens to be the best default route for the no= de, >> indicating weak host model. >>=20 >> With hosts implementing MIF, I hope most things will be strong host model= >> only. >=20 > RFC 7084 requires (requirements copied below) CE routers to support the we= ak host model. Extensive discussion around the creation of these requirement= s suggested that anything trying to use an address from an assigned PD to or= iginate and respond to messages across its WAN interface would have to use t= he weak model. Actually attaching one of these addresses to the WAN interfac= e is strictly forbidden by some RFC (I can't remember which). So the address= is attached to a LAN or internal interface. > Barbara >=20 > WAA-7: If the IPv6 CE router does not acquire a global IPv6 > address(es) from either SLAAC or DHCPv6, then it MUST create > a global IPv6 address(es) from its delegated prefix(es) and > configure those on one of its internal virtual network > interfaces, unless configured to require a global IPv6 > address on the WAN interface. >=20 > WAA-9: As a router, the IPv6 CE router MUST follow the weak host > (Weak End System) model [RFC1122]. When originating packets > from an interface, it will use a source address from another > one of its interfaces if the outgoing interface does not > have an address of suitable scope. Just like IPv4, IPv6 the protocol itself is neither weak or strong, or both w= eak and strong, depending on your point of view. The point being that it's t= he "weak or strong host model" it's a property of the host not of the protoc= ol (IPv4 or IPv6) itself, in general IPv6 hosts can be weak or strong, some s= ituations and address types dictate to one extent or another one behavior or= the other. =20 But it's more complicated than just simple weak or strong host model though,= primarily because IPv6 supports multiple addresses per-interface, and it's e= ven normally expected there will be multiple addresses in most cases, then c= ombined that with multiple interfaces and the potential for multiple default= routes, then things get complicated quick. I think this draft should probably note that if the DHCPv6-PD option discuss= ed is used some form of IPv6 router requirements will apply to the host, bey= ond just the normal host requirements for IPv6. In other words, it's not ju= st as simple as host requesting a /64 and going on it mary way. Thanks. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: +1-612-626-0815 Minneapolis, MN 55414-3029 Cell: +1-612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Tue Sep 22 11:20:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FC81A9250 for ; Tue, 22 Sep 2015 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H5MVfdbMs3L for ; Tue, 22 Sep 2015 11:20:37 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685BC1A9154 for ; Tue, 22 Sep 2015 11:20:37 -0700 (PDT) Received: by ioii196 with SMTP id i196so22938253ioi.3 for ; Tue, 22 Sep 2015 11:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NItcEMpTqkgnfTra6SRty/LFJ/YR9hRUXJh/SqoTeHA=; b=qYNrDu0aDzrhKo+Ynf4q0X1vZ+b7BtlhpBru/njUrjCZ8mnO14vtT+MFa5QSbWR2e3 54Ehvzi2t+WvtMQysf4QNFfI0ryaEDI3d5lH4Gg33lpwwAUlZh3/wnY2RSREYQBrgyth YGaQ0Qmoly7ZLSmLsYHVcF3w7cmsBPwTxftBnCruTCW5xsvqCZSJXCNucIYyiJEHGloK BnjWelTRvPnbjBt8OA8EIBarRWeVUIgCrytnW3+7mrFYk/JC+GP2d3lR3k4st4wx4s+x xittzZrpPjZZr7C8CBaDr7ypkOtQKhnSGWCy92Ot2a+77XzNNWqMBS7QSkaVz8RyKkNh JdXw== MIME-Version: 1.0 X-Received: by 10.107.132.222 with SMTP id o91mr37077470ioi.172.1442946036824; Tue, 22 Sep 2015 11:20:36 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.140.12 with HTTP; Tue, 22 Sep 2015 11:20:36 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> Date: Tue, 22 Sep 2015 11:20:36 -0700 X-Google-Sender-Auth: zfNZy6beveb8yM9Izj4tC4HNy0Q Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 18:20:39 -0000 (I guess this is already off-topic from discussions on host-addr-availability draft, so we may want to change the subject if this subtopic continues) At Tue, 22 Sep 2015 15:22:30 +0200 (CEST), Mikael Abrahamsson wrote: > > I've never been completely sure whether IPv6 supports the weak or strong > > host model, or whether it is possible for a host/implementation to be > > one or the other. > > I'd say a bit of both. > > I find that systems that will respond to an arp query for its eth1 address > and the arp request comes in on eth0 to be fundamentally broken. Some > people do not agree. From this aspect, I'd say my take is that IPv6 uses > the strong hos model. The IPv6 counterpart of this example is Neighbor Discovery. And I believe it's already pretty clear that ND adopts the strong host model. But that does not necessarily mean IPv6 in general uses the strong host model, and I thought we basically only talks about more general cases in this context. So I suspect the case about ARP/ND is not a good example to draw the conclusion. I vaguely recall this topic was discussed very long time ago. A quick google gave me this link: http://www.ietf.org/ietf-ftp/ipngwg/ipngwg-minutes-96dec.txt (nearly 20 years ago!) which says: Concludes that unicast SHOULD use weak model, but with source-address selection rules that ensure that source address differs from origination interface address only in unusual circumstances, e.g., when responding to a ping of a receive-only interface. ... Noted that the weak model is "less weak" in IPv6 than in IPv4 -- even in the weak model, must not violate IPv6 address scope constraints (link-local, site-local). However, this does *not* mean that source and destination addresses must have the same scope, and Deering recommended not adopting such an unnecessary constraint. ... Strong support for weak addressing model with strong scoping rules. I don't remember if this is the very latest consensus on this topic though. Regarding whether this is explicitly documented somewhere, I don't really remember, but I think RFC4007 (if implicitly) reflects the sense of the "less weak" model. RFC6724 also implicates we allow the weak model (otherwise it would say "MUST use outgoing interface" instead of "Prefer outgoing interface"). -- JINMEI, Tatuya From nobody Tue Sep 22 13:45:38 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2D71B2DE3 for ; Tue, 22 Sep 2015 13:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXyn7wjDrdPT for ; Tue, 22 Sep 2015 13:45:36 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CB81B2D26 for ; Tue, 22 Sep 2015 13:45:32 -0700 (PDT) Received: by pacbt3 with SMTP id bt3so756338pac.3 for ; Tue, 22 Sep 2015 13:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Bhbbpb4TZY/Y8afK5GrGumA2MIb7j6WH2cd1JLMkkzI=; b=LJ3sJujLvcqmkSoCmiiK8HWGPwthOR+bxLY0HKgoKxUnpVnK7mjbeP2gGFI65qUI8O 9HxVk7Y4G9bFXaF/ClBa4bSU9qq5+0j9ogOHN+N0MgVZzaH5LMNK4F67Dv0g7lb5HdPZ VFgYBbyBoT9ni3mHlymGT3IRP+RqmUcF/FgNwvHSR/AZr76HmayKNRPgvXtfnbi4ugR/ UpJDBoNeuY90Fwlht/6EgvEUSZA8RvRkuTs/v6riSIgW62RI6tL4ammpvOjL6rGG07fh OLPRqLXKNzdfhzJh7nEBaDmj9nEQ67UwEgQ9whCQfLQFqRE3U8a+KLNZWhnwDP5szgKQ 0Gug== X-Received: by 10.69.19.225 with SMTP id gx1mr497026pbd.11.1442954731705; Tue, 22 Sep 2015 13:45:31 -0700 (PDT) Received: from [192.168.178.25] (118.226.69.111.dynamic.snap.net.nz. [111.69.226.118]) by smtp.gmail.com with ESMTPSA id zk9sm3980061pac.7.2015.09.22.13.45.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2015 13:45:30 -0700 (PDT) To: Lorenzo Colitti , =?UTF-8?B?56We5piO6YGU5ZOJ?= References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5601BDE9.6000609@gmail.com> Date: Wed, 23 Sep 2015 08:45:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 20:45:37 -0000 On 22/09/2015 19:18, Lorenzo Colitti wrote: I'm fundamentally in favour of what the draft is trying to do, but... > These networks > are likely *not* concerned with per-device revenue, but they still provide > a limited number of addresses for other reasons (some of which may be > operational, or even scaling reasons). And I don't think your document will succeed in its purpose unless it explicitly recognises that those operational or scaling reasons may be reasonable and valid. As you know, operators will do what they need to do. Let's see: on a campus with a few tens of thousands of students, mainly connected wirelessly, will we have problems if a few hundred of them run a popular new app that generates a couple of thousand addresses when given a /64 to play with? Ditto if they catch a Trojan that knows how to have fun with its own /64. How quickly will the whole campus be black-listed? Will the campus have severe legal problems if a couple of thousand students use a new address-agile file sharing app that saturates any form of audit logging, so that offending users can't be identified? Brian From nobody Tue Sep 22 21:32:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60DB1B3186 for ; Tue, 22 Sep 2015 21:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Aa26rQ7bPZR for ; Tue, 22 Sep 2015 21:32:48 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1FF1B318F for ; Tue, 22 Sep 2015 21:32:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 78637A1; Wed, 23 Sep 2015 06:32:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442982765; bh=zaDuynFy/V9rA0F51YswB2/5eKIdR4wmtcU7OV8zMz8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vsmnyqsgbhX2Lyq53nWxWISv2FJRh/D2FAEFLmnO40yhbfIDQvPZ43W4GG3UaylZm oZgaac3Ja0zMEjfZNdr/HfmpSXe9zwpCpqG8XRoIhbwCSdVPm4aAvNkiKjdAg4xIFK bHDrrjheg7wvNdtJwEuGiibWY4HBv6qZrL6PqOYQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 699249F; Wed, 23 Sep 2015 06:32:45 +0200 (CEST) Date: Wed, 23 Sep 2015 06:32:45 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter In-Reply-To: <5601BDE9.6000609@gmail.com> Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <5601BDE9.6000609@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 04:32:50 -0000 On Wed, 23 Sep 2015, Brian E Carpenter wrote: > Ditto if they catch a Trojan that knows how to have fun with its own /64. > How quickly will the whole campus be black-listed? Well, then the other end should blacklist per /64 and not per /128. > Will the campus have severe legal problems if a couple of thousand students > use a new address-agile file sharing app that saturates any form of > audit logging, so that offending users can't be identified? You do audit logging on the /64 handed out, I don't see how this is different from handing out /128 or single address in IPv4? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 22 23:02:15 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749AC1A017C for ; Tue, 22 Sep 2015 23:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhYJ1tpR9FMm for ; Tue, 22 Sep 2015 23:02:12 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4C51A016C for ; Tue, 22 Sep 2015 23:02:12 -0700 (PDT) Received: by iofb144 with SMTP id b144so35402743iof.1 for ; Tue, 22 Sep 2015 23:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YkluN1dCG+ENokX+pTtI+hw+qnv5XI+3eTsD0AvDCZ8=; b=eGNAFuBA3THKxYXfd7NhosB7Z8riwLRPQcjp1BnMDAsDlbIFaWPmarZDAtb5fKaMEV 90atwh7Omymv5zVo/hRgIQIFtgNNoSroFEBWFey70mvQo2/jkgQWeaxFEM2eSM00FJPd ed+RL47+v83kR4EtvVpdvsvvQ16TVkHY/ATZpjneIY56lnYRoSanuIrjtnK2u7bA8pLi pKyAcZKZdWjrp/ds89Z1C5oCBY7uA5pLColRqA+Zcn1hvm2ya7DpLMM5YQDOzzWa2rAi bw8MavCsF11Cxk3w+VHJs3mBjTALao8iGNAEKyXCNmUfqRtY2pZqyV2Rk3DXA1yJTpqF phng== X-Received: by 10.107.19.234 with SMTP id 103mr41176012iot.41.1442988131820; Tue, 22 Sep 2015 23:02:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.148 with HTTP; Tue, 22 Sep 2015 23:01:42 -0700 (PDT) In-Reply-To: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <5601BDE9.6000609@gmail.com> From: Mark Smith Date: Wed, 23 Sep 2015 16:01:42 +1000 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 06:02:13 -0000 On 23 September 2015 at 14:32, Mikael Abrahamsson wrote: > On Wed, 23 Sep 2015, Brian E Carpenter wrote: > >> Ditto if they catch a Trojan that knows how to have fun with its own /64. >> How quickly will the whole campus be black-listed? > > > Well, then the other end should blacklist per /64 and not per /128. > >> Will the campus have severe legal problems if a couple of thousand >> students >> use a new address-agile file sharing app that saturates any form of >> audit logging, so that offending users can't be identified? > > > You do audit logging on the /64 handed out, I don't see how this is > different from handing out /128 or single address in IPv4? > I'm surprised it seems networks with this auditing security requirement aren't requiring authentication to attach to them (e.g., IEEE 802.1X), which would then provide an opportunity associate a user's identity with the addresses they're given and/or using during the authenticated session. Regards, Mark. From nobody Tue Sep 22 23:21:03 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C68A1A036A for ; Tue, 22 Sep 2015 23:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5qazssK6C72 for ; Tue, 22 Sep 2015 23:21:01 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FF01A0358 for ; Tue, 22 Sep 2015 23:21:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 71A92A1; Wed, 23 Sep 2015 08:20:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1442989259; bh=r3t5fBFQF0swwDrxpuqOs8KfYW9SI0RjNNk86yxYV8g=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mrFRxbeKdvKmri6H7bJRXYFDyj7mMjZe31TTGdU25ShHy28Lk//nBn99xKIVsBVlW XG/6I7Yi4zkDGr4tSUKwv3WLoQyFdcTs6G7pcPF/n3koOLv6VZuEyO+63y9PWiXi+v CUqmKUcoJvePAq/ckYIyErtS0BqsFCfOPiZjAQhg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 685F09F; Wed, 23 Sep 2015 08:20:59 +0200 (CEST) Date: Wed, 23 Sep 2015 08:20:59 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: Message-ID: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <5601BDE9.6000609@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 06:21:03 -0000 On Wed, 23 Sep 2015, Mark Smith wrote: > I'm surprised it seems networks with this auditing security requirement > aren't requiring authentication to attach to them (e.g., IEEE 802.1X), > which would then provide an opportunity associate a user's identity with > the addresses they're given and/or using during the authenticated > session. A lot of them do. Then fewer of them use first-hop-security (SAVI), so it's questionable if it actually buys them real security, but at least it logs the mac address of the user when they connect, and perhaps their system at least doesn't allow the user more than one mac address or changing mac addresses mid-session. But it's when one brings up SLAAC A=1 with these people that they tend to get upset, even when one points out that one can scrape ND tables to find out what address belonged to what mac address at a given time. So thus this proposed middle ground between multi-address capability and DHCP based tracking of who had what IP address(es) at what time, where they can keep using their DHCP infrastructure to do the IP/mac/user tracking, but instead of single IA_NA they now have single IA_PD to the device. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 23 00:18:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0B01A6F71 for ; Wed, 23 Sep 2015 00:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rRGYBJg4Wl2 for ; Wed, 23 Sep 2015 00:17:59 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8E71A002D for ; Wed, 23 Sep 2015 00:17:59 -0700 (PDT) Received: from [2a02:c0:2:1:1194:17:0:1029] (port=45468 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZeeJR-0003Ed-0c; Wed, 23 Sep 2015 09:17:57 +0200 Date: Wed, 23 Sep 2015 09:17:56 +0200 From: Tore Anderson To: "STARK, BARBARA H" Message-ID: <20150923091756.604faf11@echo.ms.redpill-linpro.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 07:18:04 -0000 * "STARK, BARBARA H" > 3. Tethering and translation (like 464XLAT) tend to be really > specific to wireless networks. These are the most compelling benefits > listed, but they don't apply to enterprise and wireline. Wrong. 464XLAT can be used in any IPv6-only network, and the problem it solves -- "make AF_INET sockets work on with IPv6-only external connectivity" -- is solved equally well regardless of the technology of the external IPv6-only link. See RFC 6877 sections 4.1 and 5.1. OpenWrt, which most commonly has a wired upstream, does support 464XLAT CLAT operation. I use 464XLAT where needed in my data centres. This is all wired Ethernet, no wireless. I am also considering changing several of the enterprise networks (workstation networks and such) from using public IPv4 addresses to using private IPv4 provided by a CLAT. This allows me to reclaim valuable IPv4 addresses without me requiring me to introduce NAPT44 in my network. (NAT64 is much easier to locate in a network than NAPT44 as it does not require a default route pointing to it.) A very similar application to a 464XLAT CLAT, but which is targeted specifically at a wired environment like at data centre, is described in I-D.ietf-v6ops-siit-dc-2xlat. Just like 464XLAT the functionality is dependent on having exclusive use of a (secondary) IPv6 address. If only a single address can be used, then this application cannot function. For example: https://bugs.launchpad.net/neutron/+bug/1495433 Tore From nobody Wed Sep 23 02:05:29 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE461AC399 for ; Wed, 23 Sep 2015 02:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcmtqhgrnIMJ for ; Wed, 23 Sep 2015 02:05:22 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD8C1A9302 for ; Wed, 23 Sep 2015 02:05:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8N95KO2003654 for ; Wed, 23 Sep 2015 11:05:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 404C9200E3C for ; Wed, 23 Sep 2015 11:10:21 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 37587200E2A for ; Wed, 23 Sep 2015 11:10:21 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8N95GoG000644 for ; Wed, 23 Sep 2015 11:05:19 +0200 To: v6ops@ietf.org References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> From: Alexandre Petrescu Message-ID: <56026B4C.7040605@gmail.com> Date: Wed, 23 Sep 2015 11:05:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] ND and Host/Router strength models (was: draft-ietf-v6ops-host-addr-availability WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 09:05:28 -0000 Hi, Regarding the models, and M. Abrahamsson comments on this topic earlier. Le 22/09/2015 20:20, 神明達哉 a écrit : > (I guess this is already off-topic from discussions on > host-addr-availability draft, so we may want to change the subject if > this subtopic continues) > > At Tue, 22 Sep 2015 15:22:30 +0200 (CEST), Mikael Abrahamsson > wrote: > >>> I've never been completely sure whether IPv6 supports the weak >>> or strong host model, or whether it is possible for a >>> host/implementation to be one or the other. >> >> I'd say a bit of both. >> >> I find that systems that will respond to an arp query for its eth1 >> address and the arp request comes in on eth0 to be fundamentally >> broken. Some people do not agree. From this aspect, I'd say my >> take is that IPv6 uses the strong hos model. > > The IPv6 counterpart of this example is Neighbor Discovery. And I > believe it's already pretty clear that ND adopts the strong host > model. I think there are use-cases where ND follows a stricter model than other use-cases. For example, an NA containing a MAC address in the target link-layer address different than the one in Ethernet header src address (aka proxy ND) can be qualified as a very weak model, if I understand correctly. But, an RA containing a prefix of a link of another interface on same Router, instead of the on-link prefix, is probably just a weak model. (are there strong/weak Router models?) Alex > But that does not necessarily mean IPv6 in general uses the strong > host model, and I thought we basically only talks about more general > cases in this context. So I suspect the case about ARP/ND is not a > good example to draw the conclusion. > > I vaguely recall this topic was discussed very long time ago. A > quick google gave me this link: > http://www.ietf.org/ietf-ftp/ipngwg/ipngwg-minutes-96dec.txt (nearly > 20 years ago!) which says: > > Concludes that unicast SHOULD use weak model, but with > source-address selection rules that ensure that source address > differs from origination interface address only in unusual > circumstances, e.g., when responding to a ping of a receive-only > interface. ... Noted that the weak model is "less weak" in IPv6 than > in IPv4 -- even in the weak model, must not violate IPv6 address > scope constraints (link-local, site-local). However, this does *not* > mean that source and destination addresses must have the same scope, > and Deering recommended not adopting such an unnecessary constraint. > ... Strong support for weak addressing model with strong scoping > rules. > > I don't remember if this is the very latest consensus on this topic > though. > > Regarding whether this is explicitly documented somewhere, I don't > really remember, but I think RFC4007 (if implicitly) reflects the > sense of the "less weak" model. RFC6724 also implicates we allow the > weak model (otherwise it would say "MUST use outgoing interface" > instead of "Prefer outgoing interface"). > > -- JINMEI, Tatuya > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 23 03:39:07 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347231ACE66 for ; Wed, 23 Sep 2015 03:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypVhPxzXM3NW for ; Wed, 23 Sep 2015 03:39:04 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002: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 B2C271ACE6B for ; Wed, 23 Sep 2015 03:39:04 -0700 (PDT) Received: by ykdt18 with SMTP id t18so36767062ykd.3 for ; Wed, 23 Sep 2015 03:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zCrDBolC8N72++abEcbaHCfdCuFGkVLZgkr6q0oUN6I=; b=dFwCmc350B+obZjDSZUQdFsD8SitpUE3CxyIGIEweI3gh1f+R7j1tj76MF1+LyhizG b+8GEKGzWN+b6oeTcdNYTTWVcdzsmZmh7mGAF6ndpta3oInJ9fHk6/lqJtJ4/mPI1i00 9DBtmJJEmAC8HWQj2PZFULidczC5T3vm8SJWmm3mH5j24IL409Wz4GyBUB1Atq0ZEIi8 5mf0XuTsb/L6M3kguVqVldm4fKnVYdulFyxZzY0KhjLfE+ok7fxcnAh+pJWByreB1jJ7 LaRQSWad+S2V6AJlJL2hwnxi3gYB2EU56G8110GlXrZzR48RC4eDtO1ffaEOa1uz9+C8 zTmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zCrDBolC8N72++abEcbaHCfdCuFGkVLZgkr6q0oUN6I=; b=mH06nHbgAaf6PVZGf4qs1UfohvZc2k7Y+mtb9LHUooFOLP/nFv9bA8VOQqI55GYnTU Hph5sHj5xQ2SfdwSFoILDv4GTndW0xUUnGy9J+bbpOn4uDnyCqM87I4jFfKuILzwj67b u9/kPlX8ufOQYXX/8NDNcjtsbb1haphk2/zX+Str6+yJv55bMMMmdJOpwDSkYUyVzrvm 94R1lT59LRLdJ14dZh98TZZ4A9gKBSirdo8cxnUYG+rj2ArMm9RvIW3M6FFK+owhGGEk c1Yz51xCp0oTvN10itTeGxcmX8lYA3fu2lSHCazoXPYPNoRIAChE/YlfoeR2NTR7rmL+ u2yg== X-Gm-Message-State: ALoCoQlhVvbhifm8Z10ulmevg+pq0kdDdmE7qiREusYDFdiGczygB8lznSUytg/IzeRzOnn8OSi4 X-Received: by 10.13.255.4 with SMTP id p4mr15008086ywf.88.1443004743868; Wed, 23 Sep 2015 03:39:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Wed, 23 Sep 2015 03:38:43 -0700 (PDT) In-Reply-To: <5601BDE9.6000609@gmail.com> References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <5601BDE9.6000609@gmail.com> From: Lorenzo Colitti Date: Wed, 23 Sep 2015 19:38:43 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c0874e62b5b3e052067b9cd Archived-At: Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 10:39:06 -0000 --94eb2c0874e62b5b3e052067b9cd Content-Type: text/plain; charset=UTF-8 On Wed, Sep 23, 2015 at 5:45 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > These networks > > are likely *not* concerned with per-device revenue, but they still > provide > > a limited number of addresses for other reasons (some of which may be > > operational, or even scaling reasons). > > And I don't think your document will succeed in its purpose unless it > explicitly recognises that those operational or scaling reasons may be > reasonable and valid. As you know, operators will do what they need to do. > > Let's see: on a campus with a few tens of thousands of students, mainly > connected wirelessly, will we have problems if a few hundred of them run > a popular new app that generates a couple of thousand addresses when > given a /64 to play with? > It depends whether there are any stateful devices in the path, and how smart those stateful devices are. A university campus with no stateful firewall and only IPv6 will never have scaling issues if it assigns a /64 per device. A campus that uses stateful firewalls might - but note that this is a problem even today, and even in IPv4 - a determined attacker can attempt to exhaust NAT or firewall state by opening lots of connections to lots of different IP addresses, for example. Ditto if they catch a Trojan that knows how to have fun with its own /64. > How quickly will the whole campus be black-listed? > Never, because any server that supports IPv6 today needs to survive in the presence of residential users with /56 prefixes and spammers / DoSers with servers in datacenters that get /48s from tunnel brokers. The content providers and CDNs started seeing and dealing with those attacks a long time ago. > Will the campus have severe legal problems if a couple of thousand students > use a new address-agile file sharing app that saturates any form of > audit logging, so that offending users can't be identified? > Not if the campus assigns a /64 per device or per user. They can just pin the blame on that /64. --94eb2c0874e62b5b3e052067b9cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 23, 2015 at 5:45 AM, Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
>= These networks
> are likely *not* concerned with per-device revenue, but they still pro= vide
> a limited number of addresses for other reasons (some of which may be<= br> > operational, or even scaling reasons).

And I don't think your document will succeed in its purpose unle= ss it
explicitly recognises that those operational or scaling reasons may be
reasonable and valid. As you know, operators will do what they need to do.<= br>
Let's see: on a campus with a few tens of thousands of students, mainly=
connected wirelessly, will we have problems if a few hundred of them run a popular new app that generates a couple of thousand addresses when
given a /64 to play with?

It depends wh= ether there are any stateful devices in the path, and how smart those state= ful devices are. A university campus with no stateful firewall and only IPv= 6 will never have scaling issues if it assigns a /64 per device. A campus t= hat uses stateful firewalls might - but note that this is a problem even to= day, and even in IPv4 - a determined attacker can attempt to exhaust NAT or= firewall state by opening lots of connections to lots of different IP addr= esses, for example.

Ditto if they catc= h a Trojan that knows how to have fun with its own /64.
How quickly will the whole campus be black-listed?
Never, because any server that supports IPv6 today needs to sur= vive in the presence of residential users with /56 prefixes and spammers / = DoSers with servers in datacenters that get /48s from tunnel brokers. The c= ontent providers and CDNs started seeing and dealing with those attacks a l= ong time ago.
=C2=A0
Will the campus have s= evere legal problems if a couple of thousand students
use a new address-agile file sharing app that saturates any form of
audit logging, so that offending users can't be identified?

Not if the campus assigns a /64 per device or per = user. They can just pin the blame on that /64.
--94eb2c0874e62b5b3e052067b9cd-- From nobody Wed Sep 23 03:49:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA81ACE70 for ; Wed, 23 Sep 2015 03:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWmgEVyPs--a for ; Wed, 23 Sep 2015 03:49:42 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E54B1ACE67 for ; Wed, 23 Sep 2015 03:49:42 -0700 (PDT) Received: by iofb144 with SMTP id b144so40116413iof.1 for ; Wed, 23 Sep 2015 03:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EAeJIj70mMn7MGvn/NNaHOgVCNVclS/KJKhnAnu447U=; b=n0bh2q9uPhzRQT0XKMI6E/aheifcB1C5Wf59sJarGEkzqMkqg298Qw48ABdSnW1mB1 kiRbKuzYRRsnHzJ2EjHnAsZ8cO1PffCcAam3nN4AFAKXFMEIKzC5CNQlNE/jcPnkdEQ2 nj3xhQreBCaa9xs29WVb23JJvGuoh+08MFJTOPsydoQtRMeNoJyaTnI4FoTH50xUPquL qY1+7OrUKI709LJg1oNvNNWR8hptBLj7sTjkbLvBqkvnpA+w+XG+WczdsQtGJSCxh1qr IjQ3nRk5ul5pSYkIbcxnBwEzAlh9t+rfkZ1Bs+ljgAsvbILW0j7v3EajTzhdTgOG1S5t EaTQ== MIME-Version: 1.0 X-Received: by 10.107.170.223 with SMTP id g92mr34917610ioj.79.1443005381475; Wed, 23 Sep 2015 03:49:41 -0700 (PDT) Received: by 10.107.13.130 with HTTP; Wed, 23 Sep 2015 03:49:41 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 23 Sep 2015 12:49:41 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "STARK, BARBARA H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 10:49:47 -0000 On 9/22/15, STARK, BARBARA H wrote: > I read through the draft and found myself feeling that the arguments > presented were rather uncompelling. So I'm going to provide some pushback= . > Since the draft is presenting itself as recommendations for *all* network= s, > I decided to think about how I would look at it in the context of (1) a > wireline broadband access service operator, (2) a wireless operator, and = (3) > an enterprise network operator. > > Going through the list of benefits, the following struck me: > 1. Privacy. Changing tracking requirements from needing to track a /128 t= o > only needing to track a /64 does not provide for any sort of improved > privacy against tracking. We need to stop perpetuating this myth. > draft-ietf-dhc-dhcp-privacy already describes how to provide a single > address that doesn't give away the MAC address. Other than not giving awa= y > the MAC, there is no privacy benefit I can see to more easily allowing > tracking systems to track at the /64 instead of the /128. I interpret the words in the draft differently: the point is that instead of storing 8*128 bits of bindings on the access router one can store 1*64 bits. (and yes you need to store the bindings if you want to have the secure access today). This can result in being able to serve more clients on the same hardware. > > 2. Several of the listed benefits involve potential use by multiple > processors on a host, virtual machines on a host, future applications, an= d > identifier-locator addressing (ILA). In listing these, there was nothing > that said "this is incredibly useful, but hosts are prevented from doing = it > (or run into a lot of complexity) if the host is restricted to a single > DHCPv6-assigned IPv6 address". I didn't read that hosts would have a hard > time having multiple processors or future applications in the absence of > multiple addresses, and I didn't get out of the discussion that virtual > machines and ILAs that require their own address are incredibly compellin= g > and hosts and users can't live without them. Section 4 talks about the complexities of allocating the addresses in a piecemeal fashion - when I read it, the "IA_NA" is the only thing that comes to mind because there is no other mechanism that is used to assign individual addresses. > > 3. Tethering and translation (like 464XLAT) tend to be really specific to > wireless networks. These are the most compelling benefits listed, but the= y > don't apply to enterprise and wireline. I personally had discussions with multiple large-ish enterprises interested in the 464XLAT or derived tech in their wired networks. > > >From an enterprise and wireline perspective, I'm completely unconvinced > that the suggested benefits are worthy of a BCP recommendation. > > >From a wireline perspective, I also see the recommendation as useless, > since I'm not aware of any wireline architectures (BBF or CableLabs) that > don't do PD. The wireline operators don't need a BCP to tell them to > continue doing this. Of course the reason they do PD isn't even listed as > among the benefits, since they don't do this for the sake of attachment b= y > an individual host. They do this so customers can run entire private > networks behind a fully-functional CE router. But I'm not aware of any > wireline operator who requires the device requesting IA-PD to be a router= . > > >From a wireless perspective, I don't really see this as being what would > convince a wireless operator to deploy PD. The case I try to make is that IPv6 in 3GPP environments allocate /64 per UE today. https://books.google.com/books?id=3Dfml06QWRJXQC&pg=3DPT205&lpg=3DPT205&dq= =3D3GPP+specification+dedicated+prefix&source=3Dbl&ots=3DkDZ1vkE3R7&sig=3DJ= hdouPCEc9DF0kCxrgUaXnDukuQ&hl=3Den&sa=3DX&ved=3D0CC8Q6AEwAmoVChMIiYLusvyMyA= IVSfM-Ch2UaQhH#v=3Donepage&q=3D3GPP%20specification%20dedicated%20prefix&f= =3Dfalse I've been told that the SP WiFi architecture best practice is to also allocate dedicated per-UE prefix on converged WiFi as well. > wireless is more and more being used in the same manner as wireline: to > support an entire LAN of networked devices behind a CE router (usually wi= th > a USB-connected wireless device). In many places, operators are saying th= at > wireless is the deployment model for getting "broadband access" to rural > areas. If this use case is going to be fully supported with IPv6, then PD > has to be supplied. Of course, with wireless networks being able to easil= y > recognize the type of device used and the user, the network operator will > always have the ability to selectively offer the PD to only certain users Every time I mention per-user tweaks with any SP in any context, they make a lemon face. --a > and/or certain devices. > Barbara > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 23 04:06:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B492B1ACE85 for ; Wed, 23 Sep 2015 04:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.094 X-Spam-Level: X-Spam-Status: No, score=0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WlHsa8Xm2sa for ; Wed, 23 Sep 2015 04:06:01 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6629D1A1B65 for ; Wed, 23 Sep 2015 04:06:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id DCFE152; Wed, 23 Sep 2015 13:05:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1443006356; bh=E4ZW4+Uabzvp6MiSgsvqvJMQiDrBW6RNr8ZrQ45zJOU=; b=K G6XKvUVxN0zclQ6YSPTdr2ABkVc+9i/NgSxFT1UNm3TsicDcy+G+IWs7BMLFI+1c okGY06RT2y5LwxSNrVtFI1KVIpAZmef/bpKa0RNQePJ3W1tqS7JSrSC5ggNmw02q z+DgaXvlR9T/UwPHoKIVRycR+SsSZFhNjuC2K2Dfjo= 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 DW9BA1bl1qNB; Wed, 23 Sep 2015 13:05:56 +0200 (CEST) Received: from [IPv6:2a00:8640:1::80fe:84b2:d3ec:7cfb] (unknown [IPv6:2a00:8640:1:0:80fe:84b2:d3ec:7cfb]) by mail.sintact.nl (Postfix) with ESMTPSA id 45EAD38; Wed, 23 Sep 2015 13:05:56 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Wed, 23 Sep 2015 13:05:54 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.3094) Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 11:06:02 -0000 > Every time I mention per-user tweaks with any SP in any context, they > make a lemon face. /me makes lemon face Cheers :) Sander From nobody Wed Sep 23 04:52:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CDD1AD351 for ; Wed, 23 Sep 2015 04:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ocVOBDMt5K7 for ; Wed, 23 Sep 2015 04:52:10 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 63D121AD350 for ; Wed, 23 Sep 2015 04:52:10 -0700 (PDT) Received: by ykdg206 with SMTP id g206so38267354ykd.1 for ; Wed, 23 Sep 2015 04:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hk0F6ciWgvdFTuPX1NDX/hsIjuufzfiekfykRlblTjI=; b=o60hAqu/rTZs+uXXL02BO6zVcKQUeiFy47LtVhF+5KjytHipIrw+jzjzp5ZAYHuGx2 N8a+xHCO94f5nuMvw0Sq49AqFKhtX0D2aEIzwn1yCCedP8VKhH3ponBmR193XQ2smCwH LlAfGJ7AS4QebwCL4d6aw04oG/FUvlUcIiHb6F0x32vOakZGM/kwF0HsfK2DBYkwyI0b hUwVyUKeVSIYh0QFR/Ya0tFrl9m8TeNiEYG0NjnyqpaWYjxODwRPgYWZ4WUs1LcwMUIy XcJpSJTBLsoB2xUfxFgZ0Co1KzhvzAOmZRyPz7bi3UFCxpt5R+xhN6MEmyk0QXJ/YqeU pkeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hk0F6ciWgvdFTuPX1NDX/hsIjuufzfiekfykRlblTjI=; b=YDv5dVC01FejulEEWpach+Aa5aIrqALnOoTpIq/ocS4+MD6/+SfYLdKfLa4rD9Eusa 6/Ux4+txRRJmGdRoCAkAz0xotEy8BzTccHf8b5nKYD87dOs/b51OB1kqCm2sFJm1eJ0w K0kpKU42koHp2U4yVmbs5vfYeD00kLvMLAh5FX4tIs8ded64a1KWLp6hFp5d3nRuMMvE J4AkXbse6DhhQX2UDhsSQAcow1guBeRshXG2AAnLvNmEPiHJU9o/YM7lUCQ2lq4ihldQ wfnoPqlloMZ+paYA17HAIvjY/2RC/xty9wKVBp8srx6NNKJVG1WDBoGaKZFq//xjQj4T jJyw== X-Gm-Message-State: ALoCoQmRh1wAuBp+MujUMOecFe0kytTBsNzLWzjaQHlLYWY3R844HyAaGCgFNit1lheH0vjhvI0C X-Received: by 10.13.240.71 with SMTP id z68mr26794455ywe.65.1443009129412; Wed, 23 Sep 2015 04:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Wed, 23 Sep 2015 04:51:49 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Wed, 23 Sep 2015 20:51:49 +0900 Message-ID: To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=94eb2c032818916925052068be96 Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 11:52:12 -0000 --94eb2c032818916925052068be96 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 23, 2015 at 1:32 AM, STARK, BARBARA H wrote: > 1. Privacy. Changing tracking requirements from needing to track a /128 to > only needing to track a /64 does not provide for any sort of improved > privacy against tracking. We need to stop perpetuating this myth. > draft-ietf-dhc-dhcp-privacy already describes how to provide a single > address that doesn't give away the MAC address. Other than not giving away > the MAC, there is no privacy benefit I can see to more easily allowing > tracking systems to track at the /64 instead of the /128. > Here's one privacy benefit that requires the ability to form multiple addresses: change your privacy address as often as you want, instead of how often the operator wants. Or, use different addresses to talk to different sites (e.g., a web server and an advertising server). These are both useful benefits if the network is trustworthy but the the attack is pervasive monitoring outside the network (e.g., by a national security agency). These aren't in the draft, but we could add them. 2. Several of the listed benefits involve potential use by multiple > processors on a host, virtual machines on a host, future applications, and > identifier-locator addressing (ILA). In listing these, there was nothing > that said "this is incredibly useful, but hosts are prevented from doing it > (or run into a lot of complexity) if the host is restricted to a single > DHCPv6-assigned IPv6 address". I didn't read that hosts would have a hard > time having multiple processors or future applications in the absence of > multiple addresses, and I didn't get out of the discussion that virtual > machines and ILAs that require their own address are incredibly compelling > and hosts and users can't live without them. > As someone who has worked on the ePDG implementation on Android devices, I can assure you that the architecture that's used to ensure that the baseband processor and the application processor could share an IP address is pretty contorted - you might even say nightmarish. And VMs do require their own addresses - no host OS I'm aware of supports sharing an IP address with another host. The sharing has to be done by performing NAT on the upstream. ... which is really the point here. What we're trying to say here is not that these use cases are hard or impossible without multiple addresses. What we're trying to say is that they exist, and that they can either be met using multiple addresses or (in most cases) by performing NAT66 in the host. We're recommending that we do not go to an architecture where hosts need to implement NAT66, and thus we recommend that the network should assign enough addresses that NAT66 is not necessary. Also, I'm not sure exactly what you're trying to say here. Are you saying that: 1. You disagree that if the network assigns a single /128, hosts will implement and use NAT66; that they will instead reduce or disable (possibly user-visible) functionality. 2. You believe that it's fine if networks assign a single /128 to a device, even if it means that hosts will (possibly widely) implement NAT66. 3. Something else? Cheers, Lorenzo --94eb2c032818916925052068be96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 23, 2015 at 1:32 AM, STARK, BARBARA H <bs7652@att.com> = wrote:
1. Privacy. Changing tracking requirements from = needing to track a /128 to only needing to track a /64 does not provide for= any sort of improved privacy against tracking. We need to stop perpetuatin= g this myth. draft-ietf-dhc-dhcp-privacy already describes how to provide a= single address that doesn't give away the MAC address. Other than not = giving away the MAC, there is no privacy benefit I can see to more easily a= llowing tracking systems to track at the /64 instead of the /128.

Here's one privacy benefit that requires the= ability to form multiple addresses: change your privacy address as often a= s you want, instead of how often the operator wants. Or, use different addr= esses to talk to different sites (e.g., a web server and an advertising ser= ver). These are both useful benefits if the network is trustworthy but the = the attack is pervasive monitoring outside the network (e.g., by a national= security agency).

These aren't in the draft, = but we could add them.

2. Several of t= he listed benefits involve potential use by multiple processors on a host, = virtual machines on a host, future applications, and identifier-locator add= ressing (ILA). In listing these, there was nothing that said "this is = incredibly useful, but hosts are prevented from doing it (or run into a lot= of complexity) if the host is restricted to a single DHCPv6-assigned IPv6 = address". I didn't read that hosts would have a hard time having m= ultiple processors or future applications in the absence of multiple addres= ses, and I didn't get out of the discussion that virtual machines and I= LAs that require their own address are incredibly compelling and hosts and = users can't live without them.

As s= omeone who has worked on the ePDG implementation on Android devices, I can = assure you that the architecture that's used to ensure that the baseban= d processor and the application processor could share an IP address is pret= ty contorted - you might even say nightmarish.

And= VMs do require their own addresses - no host OS I'm aware of supports = sharing an IP address with another host. The sharing has to be done by perf= orming NAT on the upstream.

... which is really th= e point here. What we're trying to say here is not that these use cases= are hard or impossible without multiple addresses. What we're trying t= o say is that they exist, and that they can either be met using multiple ad= dresses or (in most cases) by performing NAT66 in the host. We're recom= mending that we do not go to an architecture where hosts need to implement = NAT66, and thus we recommend that the network should assign enough addresse= s that NAT66 is not necessary.

Also, I'm n= ot sure exactly what you're trying to say here. Are you saying that:
  1. You disagree that if the network assigns a single /128, hos= ts will implement and use NAT66; that they will instead reduce or disable (= possibly user-visible) functionality.
  2. You believe that it's fin= e if networks assign a single /128 to a device, even if it means that hosts= will (possibly widely) implement NAT66.
  3. Something else?
<= div>Cheers,
Lorenzo
--94eb2c032818916925052068be96-- From nobody Wed Sep 23 06:32:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056A31A854D for ; Wed, 23 Sep 2015 06:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UZX7whiE1v7 for ; Wed, 23 Sep 2015 06:32:54 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 9B3B21A6FD6 for ; Wed, 23 Sep 2015 06:32:54 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8NDUr5J008782; Wed, 23 Sep 2015 09:32:47 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 1x2uq39yhd-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2015 09:32:47 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NDWkwu001200; Wed, 23 Sep 2015 09:32:46 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NDWfx3001141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Sep 2015 09:32:42 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 23 Sep 2015 13:32:32 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 09:32:32 -0400 From: "STARK, BARBARA H" To: Tore Anderson Thread-Topic: [v6ops] v6ops-host-addr-availability: A Little Pushback Thread-Index: AdD1Qz3jXWgqKaqHS3ecNEGJMXADQgArkEUAAAQ1aYA= Date: Wed, 23 Sep 2015 13:32:31 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA157E7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <20150923091756.604faf11@echo.ms.redpill-linpro.com> In-Reply-To: <20150923091756.604faf11@echo.ms.redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.32.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509230194 Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 13:32:56 -0000 > > 3. Tethering and translation (like 464XLAT) tend to be really specific > > to wireless networks. These are the most compelling benefits listed, > > but they don't apply to enterprise and wireline. >=20 > Wrong. >=20 > 464XLAT can be used in any IPv6-only network, and the problem it solves > -- "make AF_INET sockets work on with IPv6-only external connectivity" > -- is solved equally well regardless of the technology of the external IP= v6- > only link. Good point. OK, so I change my statement to say that translation (like 464X= LAT) only applies in an IPv6-only network. I still contend that tethering i= s specific to "3GPP"-type-technology wireless networks. =20 > OpenWrt, which most commonly has a wired upstream, does support > 464XLAT CLAT operation. I think of OpenWRT as router software. I'm not aware of any pure hosts usin= g it. > I use 464XLAT where needed in my data centres. This is all wired Ethernet= , no > wireless. Do you use 464XLAT inside all the end hosts and offer IPv6-only to all host= s inside the data centers? Or do you use it at the edge, and provide IPv4 a= nd IPv6 addresses to the hosts? The need to do translation (like 464XLAT) i= s listed in this draft as a justification for providing an IPv6 prefix to a= ll end hosts inside all networks (including, presumably, inside data center= s). I'm still not seeing that. Barbara From nobody Wed Sep 23 06:54:44 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74FD1B3226 for ; Wed, 23 Sep 2015 06:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThyNiGD-s4yx for ; Wed, 23 Sep 2015 06:54:40 -0700 (PDT) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25AE1B322C for ; Wed, 23 Sep 2015 06:54:40 -0700 (PDT) Received: from [2a02:fe0:c410:2a51::8b1] (port=41644 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZekVJ-0006pn-TJ; Wed, 23 Sep 2015 15:54:38 +0200 Date: Wed, 23 Sep 2015 15:54:32 +0200 From: Tore Anderson To: "STARK, BARBARA H" Message-ID: <20150923155432.3224e547@envy.fud.no> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA157E7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <20150923091756.604faf11@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6113AA157E7@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 13:54:43 -0000 * STARK, BARBARA H > Good point. OK, so I change my statement to say that translation > (like 464XLAT) only applies in an IPv6-only network. I still contend > that tethering is specific to "3GPP"-type-technology wireless > networks. If you're running virtual machines on your computer, using software such as VirtualBox, Parallels, KVM, or VMware Workstation; you are in principle performing tethering. > > OpenWrt, which most commonly has a wired upstream, does support > > 464XLAT CLAT operation. > > I think of OpenWRT as router software. I'm not aware of any pure > hosts using it. That's right. My point here was that regardless of your uplink being something wired like Ethernet, DSL, whatever - if you're using OpenWrt in your home gateway, you can still use 464XLAT as long as you have an IPv6 uplink and access to a NAT64 service (there are serveral public ones available over the Internet if you'd like to try it yourself). I.e., cementing the point that the 464XLAT technology is not specific to wireless ISPs. > Do you use 464XLAT inside all the end hosts and offer IPv6-only to > all hosts inside the data centers? Or do you use it at the edge, and > provide IPv4 and IPv6 addresses to the hosts? The need to do > translation (like 464XLAT) is listed in this draft as a justification > for providing an IPv6 prefix to all end hosts inside all networks > (including, presumably, inside data centers). I'm still not seeing > that. My core network provides NAT64/DNS64 service. Most of the IPv6-only servers I have are happy with that, since it makes stuff like "git clone https://github.com/foo/bar" work just fine. So no, far from all of my IPv6-only servers are using 464XLAT. However, a minority of the servers need to run software that tries to do low-level IPv4 stuff directly and fails if it cannot - essentially because stuff like "ping 8.8.8.8" doesn't work when the node is IPv6-only. On those servers specifically we activate the 464XLAT CLAT so that stuff like AF_INET sockets and "ping 8.8.8.8" starts working. We do not need the server to have a dedicated prefix for this to work, but it *does* need a second IPv6 address with a global scope. Tore From nobody Wed Sep 23 07:03:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F531A1B6E for ; Wed, 23 Sep 2015 07:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDHErK4zPyDN for ; Wed, 23 Sep 2015 07:03:53 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 2D5001A1AC2 for ; Wed, 23 Sep 2015 07:03:53 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8NDxLOX036002; Wed, 23 Sep 2015 10:03:51 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 1x2uq3snx7-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2015 10:03:51 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NE3p0t002151; Wed, 23 Sep 2015 10:03:51 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NE3ghL002060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Sep 2015 10:03:46 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi132.aldc.att.com (RSA Interceptor); Wed, 23 Sep 2015 14:03:30 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 10:03:30 -0400 From: "STARK, BARBARA H" To: "ayourtch@gmail.com" Thread-Topic: [v6ops] v6ops-host-addr-availability: A Little Pushback Thread-Index: AdD1Qz3jXWgqKaqHS3ecNEGJMXADQgAy9XeAAAKoLcA= Date: Wed, 23 Sep 2015 14:03:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA15A0D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.32.223] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509230198 Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 14:03:55 -0000 PiA+IDEuIFByaXZhY3kuIENoYW5naW5nIHRyYWNraW5nIHJlcXVpcmVtZW50cyBmcm9tIG5lZWRp bmcgdG8gdHJhY2sgYQ0KPiA+IC8xMjggdG8gb25seSBuZWVkaW5nIHRvIHRyYWNrIGEgLzY0IGRv ZXMgbm90IHByb3ZpZGUgZm9yIGFueSBzb3J0IG9mDQo+ID4gaW1wcm92ZWQgcHJpdmFjeSBhZ2Fp bnN0IHRyYWNraW5nLiBXZSBuZWVkIHRvIHN0b3AgcGVycGV0dWF0aW5nIHRoaXMgbXl0aC4NCj4g PiBkcmFmdC1pZXRmLWRoYy1kaGNwLXByaXZhY3kgYWxyZWFkeSBkZXNjcmliZXMgaG93IHRvIHBy b3ZpZGUgYSBzaW5nbGUNCj4gPiBhZGRyZXNzIHRoYXQgZG9lc24ndCBnaXZlIGF3YXkgdGhlIE1B QyBhZGRyZXNzLiBPdGhlciB0aGFuIG5vdCBnaXZpbmcNCj4gPiBhd2F5IHRoZSBNQUMsIHRoZXJl IGlzIG5vIHByaXZhY3kgYmVuZWZpdCBJIGNhbiBzZWUgdG8gbW9yZSBlYXNpbHkNCj4gPiBhbGxv d2luZyB0cmFja2luZyBzeXN0ZW1zIHRvIHRyYWNrIGF0IHRoZSAvNjQgaW5zdGVhZCBvZiB0aGUg LzEyOC4NCj4gDQo+IEkgaW50ZXJwcmV0IHRoZSB3b3JkcyBpbiB0aGUgZHJhZnQgZGlmZmVyZW50 bHk6IHRoZSBwb2ludCBpcyB0aGF0IGluc3RlYWQgb2YNCj4gc3RvcmluZyA4KjEyOCBiaXRzIG9m IGJpbmRpbmdzIG9uIHRoZSBhY2Nlc3Mgcm91dGVyIG9uZSBjYW4gc3RvcmUgMSo2NCBiaXRzLg0K PiAoYW5kIHllcyB5b3UgbmVlZCB0byBzdG9yZSB0aGUgYmluZGluZ3MgaWYgeW91IHdhbnQgdG8g aGF2ZSB0aGUgc2VjdXJlDQo+IGFjY2VzcyB0b2RheSkuDQoNCkV4YWN0bHkgbXkgcG9pbnQuIFRo ZSBzYW1lIGludmFzaW9uLW9mLXByaXZhY3kgdHJhY2tpbmcgY2FuIGJlIGRvbmUgYXQgLzY0IGlu c3RlYWQgb2YgLzEyOCwgdGhlcmVieSBtYWtpbmcgc3VjaCB0cmFja2luZyBlYXNpZXIuIE1ha2lu ZyBpbnZhc2lvbiBvZiBwcml2YWN5IGVhc2llciBzaG91bGQgbm90IGJlIGxpc3RlZCBhcyBhIGJl bmVmaXQuIEJ1dCBJIGNvdWxkIHNlZSAiRWFzaWVyIFRyYWNraW5nIiBiZWluZyBsaXN0ZWQgYXMg YSBiZW5lZml0Lg0KDQo+ID4gMy4gVGV0aGVyaW5nIGFuZCB0cmFuc2xhdGlvbiAobGlrZSA0NjRY TEFUKSB0ZW5kIHRvIGJlIHJlYWxseSBzcGVjaWZpYw0KPiA+IHRvIHdpcmVsZXNzIG5ldHdvcmtz LiBUaGVzZSBhcmUgdGhlIG1vc3QgY29tcGVsbGluZyBiZW5lZml0cyBsaXN0ZWQsDQo+ID4gYnV0 IHRoZXkgZG9uJ3QgYXBwbHkgdG8gZW50ZXJwcmlzZSBhbmQgd2lyZWxpbmUuDQo+IA0KPiBJIHBl cnNvbmFsbHkgaGFkIGRpc2N1c3Npb25zIHdpdGggbXVsdGlwbGUgbGFyZ2UtaXNoIGVudGVycHJp c2VzIGludGVyZXN0ZWQgaW4NCj4gdGhlIDQ2NFhMQVQgb3IgZGVyaXZlZCB0ZWNoIGluIHRoZWly IHdpcmVkIG5ldHdvcmtzLg0KDQpJbiBteSByZXNwb25zZSB0byBUb3JlLCBJIGFja25vd2xlZGdl ZCB0aGF0IEkgc2hvdWxkIGhhdmUgc2FpZCA0NjRYTEFUIG9ubHkgbWFrZXMgc2Vuc2UgaW4gSVB2 Ni1vbmx5IG5ldHdvcmtzLiBCdXQgSSBhbHNvIHN0aWxsIGRvbid0IHNlZSB0aGVzZSBlbnRlcnBy aXNlIG5ldHdvcmtzIGV4cGVjdGluZyB0byBydW4gNDY0WExBVCBpbiBhbGwgZW5kIGhvc3RzIGFu ZCBtYWtlIHRoZSBlbnRpcmUgZW50ZXJwcmlzZSBuZXR3b3JrIElQdjYtb25seS4gSSBzZWUgdGhl bSB3YW50aW5nIHRvIHB1dCB0aGUgNDY0WExBVCBhdCB0aGUgZWRnZS4gVGhpcyBkcmFmdCBpcyBs aXN0aW5nIDQ2NFhMQVQgaW4gZW5kIGhvc3RzIGFzIGEgcmVhc29uIHdoeSBhbGwgbmV0d29ya3Mg c2hvdWxkIGdpdmUgYWxsIGVuZCBob3N0cyBJUHY2IHByZWZpeGVzLg0KDQo+ID4gPkZyb20gYSB3 aXJlbGVzcyBwZXJzcGVjdGl2ZSwgSSBkb24ndCByZWFsbHkgc2VlIHRoaXMgYXMgYmVpbmcgd2hh dA0KPiA+ID53b3VsZA0KPiA+IGNvbnZpbmNlIGEgd2lyZWxlc3Mgb3BlcmF0b3IgdG8gZGVwbG95 IFBELiBUaGUgY2FzZSBJIHRyeSB0byBtYWtlIGlzDQo+ID4gdGhhdA0KPiANCj4gSVB2NiBpbiAz R1BQIGVudmlyb25tZW50cyBhbGxvY2F0ZSAvNjQgcGVyIFVFIHRvZGF5Lg0KDQpSZWFsbHk/IEkn ZCBoZWFyZCB0aGF0IHdhcyB0cnVlIG9mIHNvbWUgZGVwbG95bWVudHMuIEkgaGFkbid0IGhlYXJk IHRoYXQgaXQgd2FzIHRydWUgb2YgYWxsLiBJZiBpdCBpcyB0cnVlIG9mIGFsbCwgdGhlbiBJJ20g dmVyeSBjdXJpb3VzIHdoeSBBcHBsZSBhbmQgR29vZ2xlIGZlZWwgdGhlIG5lZWQgZm9yIHRoaXMg ZHJhZnQuIEJUVywgdGhlIGxpbmsgeW91IHByb3ZpZGVkIHdhcyBkZXNjcmliaW5nIGEgM0dQUCBz dGFuZGFyZC4gVGhlIGlkZWEgdGhhdCBldmVyeXRoaW5nIGRlc2NyaWJlZCBpbiB0aGUgc3RhbmRh cmQgaXMgaW1wbGVtZW50ZWQgYW5kIGRlcGxveWVkIGluIGFsbCAzR1BQIHdpcmVsZXNzIG5ldHdv cmtzIHRoYXQgaGF2ZSBlbmFibGVkIHNvbWUgZGVncmVlIG9mIElQdjYgc3VwcG9ydCBpcyBub3Qg dHJ1ZS4gVGhlcmUncyBxdWl0ZSBhIGJpZyBkaWZmZXJlbmNlIGJldHdlZW4gd2hhdCBnZXRzIHdy aXR0ZW4gaW4gM0dQUCBzdGFuZGFyZHMgYW5kIHdoYXQgZW5kcyB1cCBiZWluZyBkZXBsb3llZCBh bmQgZW5hYmxlZC4NCg0KPiBJJ3ZlIGJlZW4gdG9sZCB0aGF0IHRoZSBTUCBXaUZpIGFyY2hpdGVj dHVyZSBiZXN0IHByYWN0aWNlIGlzIHRvIGFsc28gYWxsb2NhdGUNCj4gZGVkaWNhdGVkIHBlci1V RSBwcmVmaXggb24gY29udmVyZ2VkIFdpRmkgYXMgd2VsbC4NCg0KSW50ZXJlc3RpbmcuIEknbGwg aGF2ZSB0byB0cnkgdGhhdCBvdXQgbmV4dCB0aW1lIEknbSBpbiByYW5nZSBvZiBhIGF0dHdpZmkg aG90c3BvdC4NCiANCj4gPiB3aXJlbGVzcyBpcyBtb3JlIGFuZCBtb3JlIGJlaW5nIHVzZWQgaW4g dGhlIHNhbWUgbWFubmVyIGFzIHdpcmVsaW5lOg0KPiA+IHRvIHN1cHBvcnQgYW4gZW50aXJlIExB TiBvZiBuZXR3b3JrZWQgZGV2aWNlcyBiZWhpbmQgYSBDRSByb3V0ZXINCj4gPiAodXN1YWxseSB3 aXRoIGEgVVNCLWNvbm5lY3RlZCB3aXJlbGVzcyBkZXZpY2UpLiBJbiBtYW55IHBsYWNlcywNCj4g PiBvcGVyYXRvcnMgYXJlIHNheWluZyB0aGF0IHdpcmVsZXNzIGlzIHRoZSBkZXBsb3ltZW50IG1v ZGVsIGZvciBnZXR0aW5nDQo+ID4gImJyb2FkYmFuZCBhY2Nlc3MiIHRvIHJ1cmFsIGFyZWFzLiBJ ZiB0aGlzIHVzZSBjYXNlIGlzIGdvaW5nIHRvIGJlDQo+ID4gZnVsbHkgc3VwcG9ydGVkIHdpdGgg SVB2NiwgdGhlbiBQRCBoYXMgdG8gYmUgc3VwcGxpZWQuIE9mIGNvdXJzZSwgd2l0aA0KPiA+IHdp cmVsZXNzIG5ldHdvcmtzIGJlaW5nIGFibGUgdG8gZWFzaWx5IHJlY29nbml6ZSB0aGUgdHlwZSBv ZiBkZXZpY2UNCj4gPiB1c2VkIGFuZCB0aGUgdXNlciwgdGhlIG5ldHdvcmsgb3BlcmF0b3Igd2ls bCBhbHdheXMgaGF2ZSB0aGUgYWJpbGl0eQ0KPiA+IHRvIHNlbGVjdGl2ZWx5IG9mZmVyIHRoZSBQ RCB0byBvbmx5IGNlcnRhaW4gdXNlcnMNCj4gDQo+IEV2ZXJ5IHRpbWUgSSBtZW50aW9uIHBlci11 c2VyIHR3ZWFrcyB3aXRoIGFueSBTUCBpbiBhbnkgY29udGV4dCwgdGhleSBtYWtlDQo+IGEgbGVt b24gZmFjZS4NCg0KVGhlcmUncyBhIHJhdGhlciBmYW1vdXMgY2FzZSBvZiBhIHdpcmVsZXNzIHBy b3ZpZGVyIHdobyBvbmx5IGFsbG93ZWQgRmFjZXRpbWUgdG8gYmUgdXNlZCBieSBzdWJzY3JpYmVy cyB3aXRoICJTaGFyZSIgZGF0YSBwbGFucyBhbmQgbm90ICJpbmRpdmlkdWFsIiBkYXRhIHBsYW5z LiBUaGF0IHNhbWUgcHJvdmlkZXIgaXMgYWxzbyBrbm93biB0byBzcGVjaWZ5IHdoaWNoIFVFcyBn ZXQgSVB2NiBhZGRyZXNzZXMgYW5kIHdoaWNoIGRvbid0LiBTb21lIHByb3ZpZGVycyBhcmUga25v d24gdG8gaW1wbGVtZW50IGJhbmR3aWR0aCBsaW1pdGF0aW9ucyBvbiBoZWF2eS11c2FnZSBzdWJz Y3JpYmVycy4gUGVyaGFwcyB0aGVyZSBhcmUgc29tZSBwcm92aWRlcnMgd2hvIGRvIG5vdCBpbXBs ZW1lbnQgYW55IFVFLWJhc2VkIG9yIHN1YnNjcmliZXIgLyBzdWJzY3JpYmVkLXBsYW4gYmFzZWQg cG9saWNpZXMuIEJ1dCB0aGVyZSBhcmUgbWFueSB3aG8gZG8uIE9mIGNvdXJzZSBJIGRvbid0IGNv bnNpZGVyIHRoZXNlIHBvbGljaWVzIHRvIGJlICJwZXItdXNlciB0d2Vha3MiLiBJIHdvdWxkIGNo YXJhY3Rlcml6ZSB0aGVtIGFzIHBvbGljaWVzIHRoYXQgaW1wYWN0IGluZGl2aWR1YWwgdXNlcnMg b24gdGhlIGJhc2lzIG9mIHRoZWlyIFVFLCB1c2FnZSwgYW5kIHN1YnNjcmliZWQgZGF0YSBwbGFu OyB0aGV5IG1heSBiZSBpbXBsZW1lbnRlZCB0aHJvdWdob3V0IGEgbmV0d29yayBvciBvbmx5IGlu IGNlcnRhaW4gcmVnaW9ucyBvciBtYXJrZXRzIG9mIGEgbmV0d29yay4gQW5kIHdoZXJlIEkgbGl2 ZSwgdGhleSdyZSBpbmNyZWRpYmx5IGNvbW1vbi4NCkJhcmJhcmENCg== From nobody Wed Sep 23 07:57:55 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3E1A6F60 for ; Wed, 23 Sep 2015 07:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuXvX75aToUW for ; Wed, 23 Sep 2015 07:57:52 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 162FB1A6F5D for ; Wed, 23 Sep 2015 07:57:52 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t8NEt090030835; Wed, 23 Sep 2015 10:57:50 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 1x3v78h9dm-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2015 10:57:50 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NEvnJG009503; Wed, 23 Sep 2015 10:57:49 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t8NEvj0M009220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Sep 2015 10:57:46 -0400 Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (GAALPA1MSGHUBAD.itservices.sbc.com [130.8.218.153]) by alpi133.aldc.att.com (RSA Interceptor); Wed, 23 Sep 2015 14:57:36 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.18]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0248.002; Wed, 23 Sep 2015 10:57:36 -0400 From: "STARK, BARBARA H" To: Lorenzo Colitti Thread-Topic: [v6ops] v6ops-host-addr-availability: A Little Pushback Thread-Index: AdD1Qz3jXWgqKaqHS3ecNEGJMXADQgA1IPuAAAMCgKA= Date: Wed, 23 Sep 2015 14:57:35 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113AA15C83@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.32.223] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6113AA15C83GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509230205 Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 14:57:55 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6113AA15C83GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4tbGluZSwgbWFya2VkIHdpdGggPGJocz4uDQpCYXJiYXJhDQoNCjEuIFByaXZhY3kuIENoYW5n aW5nIHRyYWNraW5nIHJlcXVpcmVtZW50cyBmcm9tIG5lZWRpbmcgdG8gdHJhY2sgYSAvMTI4IHRv IG9ubHkgbmVlZGluZyB0byB0cmFjayBhIC82NCBkb2VzIG5vdCBwcm92aWRlIGZvciBhbnkgc29y dCBvZiBpbXByb3ZlZCBwcml2YWN5IGFnYWluc3QgdHJhY2tpbmcuIFdlIG5lZWQgdG8gc3RvcCBw ZXJwZXR1YXRpbmcgdGhpcyBteXRoLiBkcmFmdC1pZXRmLWRoYy1kaGNwLXByaXZhY3kgYWxyZWFk eSBkZXNjcmliZXMgaG93IHRvIHByb3ZpZGUgYSBzaW5nbGUgYWRkcmVzcyB0aGF0IGRvZXNuJ3Qg Z2l2ZSBhd2F5IHRoZSBNQUMgYWRkcmVzcy4gT3RoZXIgdGhhbiBub3QgZ2l2aW5nIGF3YXkgdGhl IE1BQywgdGhlcmUgaXMgbm8gcHJpdmFjeSBiZW5lZml0IEkgY2FuIHNlZSB0byBtb3JlIGVhc2ls eSBhbGxvd2luZyB0cmFja2luZyBzeXN0ZW1zIHRvIHRyYWNrIGF0IHRoZSAvNjQgaW5zdGVhZCBv ZiB0aGUgLzEyOC4NCg0KSGVyZSdzIG9uZSBwcml2YWN5IGJlbmVmaXQgdGhhdCByZXF1aXJlcyB0 aGUgYWJpbGl0eSB0byBmb3JtIG11bHRpcGxlIGFkZHJlc3NlczogY2hhbmdlIHlvdXIgcHJpdmFj eSBhZGRyZXNzIGFzIG9mdGVuIGFzIHlvdSB3YW50LCBpbnN0ZWFkIG9mIGhvdyBvZnRlbiB0aGUg b3BlcmF0b3Igd2FudHMuIE9yLCB1c2UgZGlmZmVyZW50IGFkZHJlc3NlcyB0byB0YWxrIHRvIGRp ZmZlcmVudCBzaXRlcyAoZS5nLiwgYSB3ZWIgc2VydmVyIGFuZCBhbiBhZHZlcnRpc2luZyBzZXJ2 ZXIpLiBUaGVzZSBhcmUgYm90aCB1c2VmdWwgYmVuZWZpdHMgaWYgdGhlIG5ldHdvcmsgaXMgdHJ1 c3R3b3J0aHkgYnV0IHRoZSB0aGUgYXR0YWNrIGlzIHBlcnZhc2l2ZSBtb25pdG9yaW5nIG91dHNp ZGUgdGhlIG5ldHdvcmsgKGUuZy4sIGJ5IGEgbmF0aW9uYWwgc2VjdXJpdHkgYWdlbmN5KS4NCg0K PGJocz4gUHJpdmFjeSBhZGRyZXNzZXMgY2FuIGhlbHAgd2l0aCAyIHByaXZhY3kgZnVuY3Rpb25z OiAoMSkgdGhleSBvYnNjdXJlIHRoZSBNQUMgYWRkcmVzczsgKDIpIHNlbGYtZ2VuZXJhdGVkIFNM QUFDIHByaXZhY3kgYWRkcmVzc2VzIHJlZHVjZSB0aGUgYWJpbGl0eSB0byBkbyBleHRlcm5hbC10 by10aGUtbG9jYWwgbmV0d29yayB0cmFja2luZyBkb3duIHRvIHRoZSAvNjQgcHJlZml4IGxldmVs LiBXaGVuIHRoZSAvNjQgIGlzIHNoYXJlZCBhbW9uZyBtdWx0aXBsZSBkZXZpY2VzLCB0aGVyZSBj YW4gcG90ZW50aWFsbHkgYmUgYSBsaXR0bGUgYml0IG9mIGFkZGl0aW9uYWwgcHJpdmFjeSBmcm9t IHRyYWNraW5nIOKAkyBidXQgZXZlbiB0aGF0IGRlcGVuZHMsIGdpdmVuIGFsbCB0aGUgaW5mbyBi cm93c2VycyBoYW5kIG91dCB0byBIVFRQIHNlcnZlcnMuIFdoZW4gYSAvNjQgaXMgZGVkaWNhdGVk IHRvIGEgZGV2aWNlLCBhbmQgdGhlIC82NCBuZXZlciBjaGFuZ2VzLCB0aGUgYmVuZWZpdCBvZiBw cml2YWN5IGFkZHJlc3NlcyBpcyByZWR1Y2VkIHRvIG9ic2N1cmluZyB0aGUgTUFDIGFkZHJlc3Mu IEEgc2luZ2xlIHVuY2hhbmdpbmcgcHJpdmFjeSBhZGRyZXNzIHdpdGhpbiB0aGUgdW5jaGFuZ2lu ZyBwcmVmaXggcHJvdmlkZXMgZXhhY3RseSB0aGUgc2FtZSBvYnNjdXJpbmcgb2YgdGhlIE1BQyBh ZGRyZXNzIGFzIGRvemVucyBvZiBjb25zdGFudGx5IGNoYW5naW5nIHByaXZhY3kgYWRkcmVzc2Vz LiBXZSBuZWVkIHRvIHN0b3AgcGVycGV0dWF0aW5nIHRoaXMgcHJpdmFjeSBteXRoLg0KDQpUaGVz ZSBhcmVuJ3QgaW4gdGhlIGRyYWZ0LCBidXQgd2UgY291bGQgYWRkIHRoZW0uDQoNCjxiaHM+IElm IHlvdSB3YW50IHRvIGxpc3QgaW1wcm92ZWQgdHJhY2tpbmcgYXMgYSBiZW5lZml0IChpLmUuLCBy ZWR1Y2VkIHByaXZhY3kpLCBJIHdvdWxkIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQuIE1hbnkg cGVvcGxlIHdvdWxkIGluZGVlZCBzZWUgdGhhdCBhcyBhIGJlbmVmaXQuDQoNCjIuIFNldmVyYWwg b2YgdGhlIGxpc3RlZCBiZW5lZml0cyBpbnZvbHZlIHBvdGVudGlhbCB1c2UgYnkgbXVsdGlwbGUg cHJvY2Vzc29ycyBvbiBhIGhvc3QsIHZpcnR1YWwgbWFjaGluZXMgb24gYSBob3N0LCBmdXR1cmUg YXBwbGljYXRpb25zLCBhbmQgaWRlbnRpZmllci1sb2NhdG9yIGFkZHJlc3NpbmcgKElMQSkuIElu IGxpc3RpbmcgdGhlc2UsIHRoZXJlIHdhcyBub3RoaW5nIHRoYXQgc2FpZCAidGhpcyBpcyBpbmNy ZWRpYmx5IHVzZWZ1bCwgYnV0IGhvc3RzIGFyZSBwcmV2ZW50ZWQgZnJvbSBkb2luZyBpdCAob3Ig cnVuIGludG8gYSBsb3Qgb2YgY29tcGxleGl0eSkgaWYgdGhlIGhvc3QgaXMgcmVzdHJpY3RlZCB0 byBhIHNpbmdsZSBESENQdjYtYXNzaWduZWQgSVB2NiBhZGRyZXNzIi4gSSBkaWRuJ3QgcmVhZCB0 aGF0IGhvc3RzIHdvdWxkIGhhdmUgYSBoYXJkIHRpbWUgaGF2aW5nIG11bHRpcGxlIHByb2Nlc3Nv cnMgb3IgZnV0dXJlIGFwcGxpY2F0aW9ucyBpbiB0aGUgYWJzZW5jZSBvZiBtdWx0aXBsZSBhZGRy ZXNzZXMsIGFuZCBJIGRpZG4ndCBnZXQgb3V0IG9mIHRoZSBkaXNjdXNzaW9uIHRoYXQgdmlydHVh bCBtYWNoaW5lcyBhbmQgSUxBcyB0aGF0IHJlcXVpcmUgdGhlaXIgb3duIGFkZHJlc3MgYXJlIGlu Y3JlZGlibHkgY29tcGVsbGluZyBhbmQgaG9zdHMgYW5kIHVzZXJzIGNhbid0IGxpdmUgd2l0aG91 dCB0aGVtLg0KDQpBcyBzb21lb25lIHdobyBoYXMgd29ya2VkIG9uIHRoZSBlUERHIGltcGxlbWVu dGF0aW9uIG9uIEFuZHJvaWQgZGV2aWNlcywgSSBjYW4gYXNzdXJlIHlvdSB0aGF0IHRoZSBhcmNo aXRlY3R1cmUgdGhhdCdzIHVzZWQgdG8gZW5zdXJlIHRoYXQgdGhlIGJhc2ViYW5kIHByb2Nlc3Nv ciBhbmQgdGhlIGFwcGxpY2F0aW9uIHByb2Nlc3NvciBjb3VsZCBzaGFyZSBhbiBJUCBhZGRyZXNz IGlzIHByZXR0eSBjb250b3J0ZWQgLSB5b3UgbWlnaHQgZXZlbiBzYXkgbmlnaHRtYXJpc2guDQoN CjxiaHM+IEJ1dCBpdOKAmXMgYmVlbiBkb25lPyBOb3cgaWYgeW91IHNhaWQgdGhhdCBub3QgdXNp bmcgdGhpcyBuaWdodG1hcmlzaCBjb2RlIHdvdWxkIGltcHJvdmUgYmF0dGVyeSBsaWZlIG9mIHRo ZSBkZXZpY2VzLCB0aGF0IHdvdWxkIGJlIGEgcmVhbCBiZW5lZml0IChmcm9tIGFuIG9wZXJhdG9y IHBlcnNwZWN0aXZlIOKAkyB3aG8gaXMgeW91ciB0YXJnZXQgYXVkaWVuY2UpLiBCdXQgaWYgdGhl IGNvZGUgaXMgZG9uZSBhbmQgd29ya3MsIHRoZW4gSSBkb27igJl0IHNlZSB3aHkgYW4gb3BlcmF0 b3Igc2hvdWxkIGNhcmUgaG93IG5pZ2h0bWFyaXNoIGl0IHdhcyBmb3IgdGhlIE9TIGltcGxlbWVu dGF0aW9uLg0KDQpBbmQgVk1zIGRvIHJlcXVpcmUgdGhlaXIgb3duIGFkZHJlc3NlcyAtIG5vIGhv c3QgT1MgSSdtIGF3YXJlIG9mIHN1cHBvcnRzIHNoYXJpbmcgYW4gSVAgYWRkcmVzcyB3aXRoIGFu b3RoZXIgaG9zdC4gVGhlIHNoYXJpbmcgaGFzIHRvIGJlIGRvbmUgYnkgcGVyZm9ybWluZyBOQVQg b24gdGhlIHVwc3RyZWFtLg0KDQo8YmhzPiBJIGRpZG7igJl0IHNheSBWTXMgZGlkbuKAmXQgbmVl ZCB0aGVpciBvd24gYWRkcmVzc2VzLiBXaGF0IEkgc2FpZCB3YXMgSSB3YXNu4oCZdCBjb252aW5j ZWQgdGhhdCBhbGwgaG9zdHMgbmVlZGVkIFZNcyBpbiBvcmRlciB0byBkbyB3aGF0ZXZlciBpdCB3 YXMgdGhlIHVzZXIgd2FudGVkIHRoZW0gdG8gZG8uIFlvdSBoYXZlbuKAmXQgcHJvdmlkZWQgYSBj b21wZWxsaW5nIHJlYXNvbiB3aHkgVk1zIGFyZSBiZW5lZmljaWFsIGluIGhvc3RzLiBXaXRob3V0 IHRoYXQsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBJIHNob3VsZCBjYXJlIHdoZXRoZXIgb3Ig bm90ICBhbGwgaG9zdHMgY2FuIHJ1biBWTXMuDQoNCi4uLiB3aGljaCBpcyByZWFsbHkgdGhlIHBv aW50IGhlcmUuIFdoYXQgd2UncmUgdHJ5aW5nIHRvIHNheSBoZXJlIGlzIG5vdCB0aGF0IHRoZXNl IHVzZSBjYXNlcyBhcmUgaGFyZCBvciBpbXBvc3NpYmxlIHdpdGhvdXQgbXVsdGlwbGUgYWRkcmVz c2VzLiBXaGF0IHdlJ3JlIHRyeWluZyB0byBzYXkgaXMgdGhhdCB0aGV5IGV4aXN0LCBhbmQgdGhh dCB0aGV5IGNhbiBlaXRoZXIgYmUgbWV0IHVzaW5nIG11bHRpcGxlIGFkZHJlc3NlcyBvciAoaW4g bW9zdCBjYXNlcykgYnkgcGVyZm9ybWluZyBOQVQ2NiBpbiB0aGUgaG9zdC4gV2UncmUgcmVjb21t ZW5kaW5nIHRoYXQgd2UgZG8gbm90IGdvIHRvIGFuIGFyY2hpdGVjdHVyZSB3aGVyZSBob3N0cyBu ZWVkIHRvIGltcGxlbWVudCBOQVQ2NiwgYW5kIHRodXMgd2UgcmVjb21tZW5kIHRoYXQgdGhlIG5l dHdvcmsgc2hvdWxkIGFzc2lnbiBlbm91Z2ggYWRkcmVzc2VzIHRoYXQgTkFUNjYgaXMgbm90IG5l Y2Vzc2FyeS4NCg0KPGJocz4gTkFUNjYgaXMgbm90IHNvbWV0aGluZyB0aGF0IGhvc3RzIGluc2lk ZSBlbnRlcnByaXNlIG5ldHdvcmtzIG5lZWQgdG8gYmUgd29ycmllZCBhYm91dC4gWWVzLCBJIGNh biBzZWUgdGhhdCBpdOKAmXMgYSBwcm9ibGVtIGZvciBVRXMgaW4gYSB3aXJlbGVzcyBuZXR3b3Jr Lg0KDQpBbHNvLCBJJ20gbm90IHN1cmUgZXhhY3RseSB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gc2F5 IGhlcmUuIEFyZSB5b3Ugc2F5aW5nIHRoYXQ6DQoNCiAgMS4gIFlvdSBkaXNhZ3JlZSB0aGF0IGlm IHRoZSBuZXR3b3JrIGFzc2lnbnMgYSBzaW5nbGUgLzEyOCwgaG9zdHMgd2lsbCBpbXBsZW1lbnQg YW5kIHVzZSBOQVQ2NjsgdGhhdCB0aGV5IHdpbGwgaW5zdGVhZCByZWR1Y2Ugb3IgZGlzYWJsZSAo cG9zc2libHkgdXNlci12aXNpYmxlKSBmdW5jdGlvbmFsaXR5Lg0KICAyLiAgWW91IGJlbGlldmUg dGhhdCBpdCdzIGZpbmUgaWYgbmV0d29ya3MgYXNzaWduIGEgc2luZ2xlIC8xMjggdG8gYSBkZXZp Y2UsIGV2ZW4gaWYgaXQgbWVhbnMgdGhhdCBob3N0cyB3aWxsIChwb3NzaWJseSB3aWRlbHkpIGlt cGxlbWVudCBOQVQ2Ni4NCiAgMy4gIFNvbWV0aGluZyBlbHNlPw0KPGJocz4gSeKAmW0gc2F5aW5n IHRoYXQgeW91IGhhdmVu4oCZdCBwcmVzZW50ZWQgeW91ciBjYXNlIGluIGEgdmVyeSBjb21wZWxs aW5nIG1hbm5lci4gVGhlIGNhc2UgZm9yICh0aGUgaW50ZXJpb3Igb2YpIGVudGVycHJpc2UgbmV0 d29ya3MgaXMgbm9uLWV4aXN0ZW50LiBUaGUgY2FzZSBmb3Igd2lyZWxpbmUgbmV0d29ya3MgaXMg dW5uZWNlc3NhcnkuIEkgdGhpbmsgaXTigJlzIHBvc3NpYmxlIGZvciB5b3UgdG8gbWFrZSBhIGNv bXBlbGxpbmcgY2FzZSBmb3IgM0dQUCB3aXJlbGVzcyBuZXR3b3JrcywgYnV0IHRoYXQgbmVlZHMg d29yay4gSSB0aGluayBpdCB3b3VsZCBiZSBlYXNpZXIgZm9yIHlvdSB0byBtYWtlIHRoYXQgY2Fz ZSBpZiB5b3UgZm9jdXNlZCBvbiB0aGF0IGF1ZGllbmNlIGFuZCB0aGF0IGNhc2UuIEkgYWxzbyB0 aGluayB0aGF0IHlvdSB3b3VsZCBtYWtlIHRoZSBjYXNlIGJldHRlciBpZiB5b3UgcHJvdmlkZWQg YmVuZWZpdHMgd29yZGVkIGluIGEgd2F5IHRoYXQgY2F1c2UgdGhlIG9wZXJhdG9yIHRvIGNhcmUg KGkuZS4sIGJ5IGFwcGVhbGluZyB0byB0aGVpciBzZWxmLWludGVyZXN0KS4gQW5kIOKAnGJlbmVm aXRz4oCdIHRoYXQgYXJlIG5vdCByZWFsIGJlbmVmaXRzIGRldHJhY3QgZnJvbSB0aGUgYXJndW1l bnQgYmVjYXVzZSB0aGV5IHByb3ZpZGUgYW4gZWFzeSB0YXJnZXQgZm9yIGRldHJhY3RvcnMgdG8g YXR0YWNrLCBhbmQgZHJhdyBhdHRlbnRpb24gYXdheSBmcm9tIHRoZSByZWFsIGJlbmVmaXRzLg0K QmFyYmFyYQ0K --_000_2D09D61DDFA73D4C884805CC7865E6113AA15C83GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo0OTQwNzkzNjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODcxMTI1ODIwO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluLWxpbmUsIG1hcmtlZCB3aXRoICZsdDti aHMmZ3Q7Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJhcmJhcmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBQcml2 YWN5LiBDaGFuZ2luZyB0cmFja2luZyByZXF1aXJlbWVudHMgZnJvbSBuZWVkaW5nIHRvIHRyYWNr IGEgLzEyOCB0byBvbmx5IG5lZWRpbmcgdG8gdHJhY2sgYSAvNjQgZG9lcyBub3QgcHJvdmlkZSBm b3IgYW55IHNvcnQgb2YgaW1wcm92ZWQgcHJpdmFjeSBhZ2FpbnN0IHRyYWNraW5nLiBXZSBuZWVk IHRvIHN0b3AgcGVycGV0dWF0aW5nIHRoaXMgbXl0aC4gZHJhZnQtaWV0Zi1kaGMtZGhjcC1wcml2 YWN5DQogYWxyZWFkeSBkZXNjcmliZXMgaG93IHRvIHByb3ZpZGUgYSBzaW5nbGUgYWRkcmVzcyB0 aGF0IGRvZXNuJ3QgZ2l2ZSBhd2F5IHRoZSBNQUMgYWRkcmVzcy4gT3RoZXIgdGhhbiBub3QgZ2l2 aW5nIGF3YXkgdGhlIE1BQywgdGhlcmUgaXMgbm8gcHJpdmFjeSBiZW5lZml0IEkgY2FuIHNlZSB0 byBtb3JlIGVhc2lseSBhbGxvd2luZyB0cmFja2luZyBzeXN0ZW1zIHRvIHRyYWNrIGF0IHRoZSAv NjQgaW5zdGVhZCBvZiB0aGUgLzEyOC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUncyBvbmUgcHJpdmFjeSBiZW5lZml0IHRo YXQgcmVxdWlyZXMgdGhlIGFiaWxpdHkgdG8gZm9ybSBtdWx0aXBsZSBhZGRyZXNzZXM6IGNoYW5n ZSB5b3VyIHByaXZhY3kgYWRkcmVzcyBhcyBvZnRlbiBhcyB5b3Ugd2FudCwgaW5zdGVhZCBvZiBo b3cgb2Z0ZW4gdGhlIG9wZXJhdG9yIHdhbnRzLiBPciwgdXNlIGRpZmZlcmVudCBhZGRyZXNzZXMg dG8gdGFsayB0byBkaWZmZXJlbnQgc2l0ZXMgKGUuZy4sIGENCiB3ZWIgc2VydmVyIGFuZCBhbiBh ZHZlcnRpc2luZyBzZXJ2ZXIpLiBUaGVzZSBhcmUgYm90aCB1c2VmdWwgYmVuZWZpdHMgaWYgdGhl IG5ldHdvcmsgaXMgdHJ1c3R3b3J0aHkgYnV0IHRoZSB0aGUgYXR0YWNrIGlzIHBlcnZhc2l2ZSBt b25pdG9yaW5nIG91dHNpZGUgdGhlIG5ldHdvcmsgKGUuZy4sIGJ5IGEgbmF0aW9uYWwgc2VjdXJp dHkgYWdlbmN5KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDtiaHMmZ3Q7IFByaXZhY3kgYWRk cmVzc2VzIGNhbiBoZWxwIHdpdGggMiBwcml2YWN5IGZ1bmN0aW9uczogKDEpIHRoZXkgb2JzY3Vy ZSB0aGUgTUFDIGFkZHJlc3M7ICgyKSBzZWxmLWdlbmVyYXRlZCBTTEFBQyBwcml2YWN5IGFkZHJl c3NlcyByZWR1Y2UgdGhlIGFiaWxpdHkgdG8gZG8gZXh0ZXJuYWwtdG8tdGhlLWxvY2FsDQogbmV0 d29yayB0cmFja2luZyBkb3duIHRvIHRoZSAvNjQgcHJlZml4IGxldmVsLiBXaGVuIHRoZSAvNjQm bmJzcDsgaXMgc2hhcmVkIGFtb25nIG11bHRpcGxlIGRldmljZXMsIHRoZXJlIGNhbiBwb3RlbnRp YWxseSBiZSBhIGxpdHRsZSBiaXQgb2YgYWRkaXRpb25hbCBwcml2YWN5IGZyb20gdHJhY2tpbmcg 4oCTIGJ1dCBldmVuIHRoYXQgZGVwZW5kcywgZ2l2ZW4gYWxsIHRoZSBpbmZvIGJyb3dzZXJzIGhh bmQgb3V0IHRvIEhUVFAgc2VydmVycy4gV2hlbiBhIC82NA0KIGlzIGRlZGljYXRlZCB0byBhIGRl dmljZSwgYW5kIHRoZSAvNjQgbmV2ZXIgY2hhbmdlcywgdGhlIGJlbmVmaXQgb2YgcHJpdmFjeSBh ZGRyZXNzZXMgaXMgcmVkdWNlZCB0byBvYnNjdXJpbmcgdGhlIE1BQyBhZGRyZXNzLiBBIHNpbmds ZSB1bmNoYW5naW5nIHByaXZhY3kgYWRkcmVzcyB3aXRoaW4gdGhlIHVuY2hhbmdpbmcgcHJlZml4 IHByb3ZpZGVzIGV4YWN0bHkgdGhlIHNhbWUgb2JzY3VyaW5nIG9mIHRoZSBNQUMgYWRkcmVzcyBh cyBkb3plbnMNCiBvZiBjb25zdGFudGx5IGNoYW5naW5nIHByaXZhY3kgYWRkcmVzc2VzLiBXZSBu ZWVkIHRvIHN0b3AgcGVycGV0dWF0aW5nIHRoaXMgcHJpdmFjeSBteXRoLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgYXJl bid0IGluIHRoZSBkcmFmdCwgYnV0IHdlIGNvdWxkIGFkZCB0aGVtLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmx0O2JocyZndDsgSWYgeW91IHdhbnQgdG8gbGlzdCBpbXByb3ZlZCB0cmFja2luZyBh cyBhIGJlbmVmaXQgKGkuZS4sIHJlZHVjZWQgcHJpdmFjeSksIEkgd291bGQgaGF2ZSBubyBwcm9i bGVtIHdpdGggdGhhdC4gTWFueSBwZW9wbGUgd291bGQgaW5kZWVkIHNlZSB0aGF0IGFzIGEgYmVu ZWZpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIuIFNldmVyYWwgb2YgdGhlIGxpc3RlZCBiZW5lZml0cyBpbnZvbHZl IHBvdGVudGlhbCB1c2UgYnkgbXVsdGlwbGUgcHJvY2Vzc29ycyBvbiBhIGhvc3QsIHZpcnR1YWwg bWFjaGluZXMgb24gYSBob3N0LCBmdXR1cmUgYXBwbGljYXRpb25zLCBhbmQgaWRlbnRpZmllci1s b2NhdG9yIGFkZHJlc3NpbmcgKElMQSkuIEluIGxpc3RpbmcgdGhlc2UsIHRoZXJlIHdhcyBub3Ro aW5nIHRoYXQgc2FpZCAmcXVvdDt0aGlzIGlzIGluY3JlZGlibHkNCiB1c2VmdWwsIGJ1dCBob3N0 cyBhcmUgcHJldmVudGVkIGZyb20gZG9pbmcgaXQgKG9yIHJ1biBpbnRvIGEgbG90IG9mIGNvbXBs ZXhpdHkpIGlmIHRoZSBob3N0IGlzIHJlc3RyaWN0ZWQgdG8gYSBzaW5nbGUgREhDUHY2LWFzc2ln bmVkIElQdjYgYWRkcmVzcyZxdW90Oy4gSSBkaWRuJ3QgcmVhZCB0aGF0IGhvc3RzIHdvdWxkIGhh dmUgYSBoYXJkIHRpbWUgaGF2aW5nIG11bHRpcGxlIHByb2Nlc3NvcnMgb3IgZnV0dXJlIGFwcGxp Y2F0aW9ucyBpbiB0aGUgYWJzZW5jZQ0KIG9mIG11bHRpcGxlIGFkZHJlc3NlcywgYW5kIEkgZGlk bid0IGdldCBvdXQgb2YgdGhlIGRpc2N1c3Npb24gdGhhdCB2aXJ0dWFsIG1hY2hpbmVzIGFuZCBJ TEFzIHRoYXQgcmVxdWlyZSB0aGVpciBvd24gYWRkcmVzcyBhcmUgaW5jcmVkaWJseSBjb21wZWxs aW5nIGFuZCBob3N0cyBhbmQgdXNlcnMgY2FuJ3QgbGl2ZSB3aXRob3V0IHRoZW0uPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBz b21lb25lIHdobyBoYXMgd29ya2VkIG9uIHRoZSBlUERHIGltcGxlbWVudGF0aW9uIG9uIEFuZHJv aWQgZGV2aWNlcywgSSBjYW4gYXNzdXJlIHlvdSB0aGF0IHRoZSBhcmNoaXRlY3R1cmUgdGhhdCdz IHVzZWQgdG8gZW5zdXJlIHRoYXQgdGhlIGJhc2ViYW5kIHByb2Nlc3NvciBhbmQgdGhlIGFwcGxp Y2F0aW9uIHByb2Nlc3NvciBjb3VsZCBzaGFyZSBhbiBJUCBhZGRyZXNzIGlzIHByZXR0eSBjb250 b3J0ZWQNCiAtIHlvdSBtaWdodCBldmVuIHNheSBuaWdodG1hcmlzaC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZsdDtiaHMmZ3Q7IEJ1dCBpdOKAmXMgYmVlbiBkb25lPyBOb3cgaWYgeW91IHNhaWQg dGhhdCBub3QgdXNpbmcgdGhpcyBuaWdodG1hcmlzaCBjb2RlIHdvdWxkIGltcHJvdmUgYmF0dGVy eSBsaWZlIG9mIHRoZSBkZXZpY2VzLCB0aGF0IHdvdWxkIGJlIGEgcmVhbCBiZW5lZml0IChmcm9t IGFuIG9wZXJhdG9yIHBlcnNwZWN0aXZlDQog4oCTIHdobyBpcyB5b3VyIHRhcmdldCBhdWRpZW5j ZSkuIEJ1dCBpZiB0aGUgY29kZSBpcyBkb25lIGFuZCB3b3JrcywgdGhlbiBJIGRvbuKAmXQgc2Vl IHdoeSBhbiBvcGVyYXRvciBzaG91bGQgY2FyZSBob3cgbmlnaHRtYXJpc2ggaXQgd2FzIGZvciB0 aGUgT1MgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgVk1zIGRvIHJlcXVpcmUgdGhlaXIgb3duIGFk ZHJlc3NlcyAtIG5vIGhvc3QgT1MgSSdtIGF3YXJlIG9mIHN1cHBvcnRzIHNoYXJpbmcgYW4gSVAg YWRkcmVzcyB3aXRoIGFub3RoZXIgaG9zdC4gVGhlIHNoYXJpbmcgaGFzIHRvIGJlIGRvbmUgYnkg cGVyZm9ybWluZyBOQVQgb24gdGhlIHVwc3RyZWFtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0 O2JocyZndDsgSSBkaWRu4oCZdCBzYXkgVk1zIGRpZG7igJl0IG5lZWQgdGhlaXIgb3duIGFkZHJl c3Nlcy4gV2hhdCBJIHNhaWQgd2FzIEkgd2FzbuKAmXQgY29udmluY2VkIHRoYXQgYWxsIGhvc3Rz IG5lZWRlZCBWTXMgaW4gb3JkZXIgdG8gZG8gd2hhdGV2ZXIgaXQgd2FzIHRoZSB1c2VyIHdhbnRl ZCB0aGVtIHRvDQogZG8uIFlvdSBoYXZlbuKAmXQgcHJvdmlkZWQgYSBjb21wZWxsaW5nIHJlYXNv biB3aHkgVk1zIGFyZSBiZW5lZmljaWFsIGluIGhvc3RzLiBXaXRob3V0IHRoYXQsIEkgZG9u4oCZ dCB1bmRlcnN0YW5kIHdoeSBJIHNob3VsZCBjYXJlIHdoZXRoZXIgb3Igbm90Jm5ic3A7IGFsbCBo b3N0cyBjYW4gcnVuIFZNcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uLiB3aGljaCBpcyByZWFsbHkgdGhlIHBvaW50IGhlcmUu IFdoYXQgd2UncmUgdHJ5aW5nIHRvIHNheSBoZXJlIGlzIG5vdCB0aGF0IHRoZXNlIHVzZSBjYXNl cyBhcmUgaGFyZCBvciBpbXBvc3NpYmxlIHdpdGhvdXQgbXVsdGlwbGUgYWRkcmVzc2VzLiBXaGF0 IHdlJ3JlIHRyeWluZyB0byBzYXkgaXMgdGhhdCB0aGV5IGV4aXN0LCBhbmQgdGhhdCB0aGV5IGNh biBlaXRoZXIgYmUgbWV0IHVzaW5nIG11bHRpcGxlDQogYWRkcmVzc2VzIG9yIChpbiBtb3N0IGNh c2VzKSBieSBwZXJmb3JtaW5nIE5BVDY2IGluIHRoZSBob3N0LiBXZSdyZSByZWNvbW1lbmRpbmcg dGhhdCB3ZSBkbyBub3QgZ28gdG8gYW4gYXJjaGl0ZWN0dXJlIHdoZXJlIGhvc3RzIG5lZWQgdG8g aW1wbGVtZW50IE5BVDY2LCBhbmQgdGh1cyB3ZSByZWNvbW1lbmQgdGhhdCB0aGUgbmV0d29yayBz aG91bGQgYXNzaWduIGVub3VnaCBhZGRyZXNzZXMgdGhhdCBOQVQ2NiBpcyBub3QgbmVjZXNzYXJ5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmx0O2JocyZndDsgTkFUNjYgaXMgbm90IHNvbWV0aGlu ZyB0aGF0IGhvc3RzIGluc2lkZSBlbnRlcnByaXNlIG5ldHdvcmtzIG5lZWQgdG8gYmUgd29ycmll ZCBhYm91dC4gWWVzLCBJIGNhbiBzZWUgdGhhdCBpdOKAmXMgYSBwcm9ibGVtIGZvciBVRXMgaW4g YSB3aXJlbGVzcyBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgSSdtIG5vdCBzdXJlIGV4YWN0bHkgd2hhdCB5 b3UncmUgdHJ5aW5nIHRvIHNheSBoZXJlLiBBcmUgeW91IHNheWluZyB0aGF0OjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KWW91IGRpc2FncmVlIHRoYXQg aWYgdGhlIG5ldHdvcmsgYXNzaWducyBhIHNpbmdsZSAvMTI4LCBob3N0cyB3aWxsIGltcGxlbWVu dCBhbmQgdXNlIE5BVDY2OyB0aGF0IHRoZXkgd2lsbCBpbnN0ZWFkIHJlZHVjZSBvciBkaXNhYmxl IChwb3NzaWJseSB1c2VyLXZpc2libGUpIGZ1bmN0aW9uYWxpdHkuPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KWW91IGJlbGll dmUgdGhhdCBpdCdzIGZpbmUgaWYgbmV0d29ya3MgYXNzaWduIGEgc2luZ2xlIC8xMjggdG8gYSBk ZXZpY2UsIGV2ZW4gaWYgaXQgbWVhbnMgdGhhdCBob3N0cyB3aWxsIChwb3NzaWJseSB3aWRlbHkp IGltcGxlbWVudCBOQVQ2Ni48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpTb21ldGhpbmcgZWxzZT88bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtiaHMmZ3Q7IEni gJltIHNheWluZyB0aGF0IHlvdSBoYXZlbuKAmXQgcHJlc2VudGVkIHlvdXIgY2FzZSBpbiBhIHZl cnkgY29tcGVsbGluZyBtYW5uZXIuIFRoZSBjYXNlIGZvciAodGhlIGludGVyaW9yIG9mKSBlbnRl cnByaXNlIG5ldHdvcmtzIGlzIG5vbi1leGlzdGVudC4gVGhlIGNhc2UgZm9yIHdpcmVsaW5lIG5l dHdvcmtzIGlzIHVubmVjZXNzYXJ5LiBJIHRoaW5rIGl04oCZcyBwb3NzaWJsZSBmb3IgeW91IHRv IG1ha2UNCiBhIGNvbXBlbGxpbmcgY2FzZSBmb3IgM0dQUCB3aXJlbGVzcyBuZXR3b3JrcywgYnV0 IHRoYXQgbmVlZHMgd29yay4gSSB0aGluayBpdCB3b3VsZCBiZSBlYXNpZXIgZm9yIHlvdSB0byBt YWtlIHRoYXQgY2FzZSBpZiB5b3UgZm9jdXNlZCBvbiB0aGF0IGF1ZGllbmNlIGFuZCB0aGF0IGNh c2UuIEkgYWxzbyB0aGluayB0aGF0IHlvdSB3b3VsZCBtYWtlIHRoZSBjYXNlIGJldHRlciBpZiB5 b3UgcHJvdmlkZWQgYmVuZWZpdHMgd29yZGVkIGluIGEgd2F5DQogdGhhdCBjYXVzZSB0aGUgb3Bl cmF0b3IgdG8gY2FyZSAoaS5lLiwgYnkgYXBwZWFsaW5nIHRvIHRoZWlyIHNlbGYtaW50ZXJlc3Qp LiBBbmQg4oCcYmVuZWZpdHPigJ0gdGhhdCBhcmUgbm90IHJlYWwgYmVuZWZpdHMgZGV0cmFjdCBm cm9tIHRoZSBhcmd1bWVudCBiZWNhdXNlIHRoZXkgcHJvdmlkZSBhbiBlYXN5IHRhcmdldCBmb3Ig ZGV0cmFjdG9ycyB0byBhdHRhY2ssIGFuZCBkcmF3IGF0dGVudGlvbiBhd2F5IGZyb20gdGhlIHJl YWwgYmVuZWZpdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkJhcmJhcmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6113AA15C83GAALPA1MSGUSRBF_-- From nobody Wed Sep 23 13:40:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD0C1B2C09 for ; Wed, 23 Sep 2015 13:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt807UpQFc29 for ; Wed, 23 Sep 2015 13:40:35 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 853631A009E for ; Wed, 23 Sep 2015 13:40:35 -0700 (PDT) Received: by padhy16 with SMTP id hy16so50220465pad.1 for ; Wed, 23 Sep 2015 13:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8uwM3+jEYZ66GvRgAIxpHZm0ph+tzxnWOrl1gIEQo9o=; b=ZaXAwZ4qaaY74GK7qytOA5/7Kvy8ZqGlOc1ByuYFa7p5yTHtPIBTxkYl8jo93ffwSp IMxsnSs770QMoi/p5Xofvrjl1fuLPz9Zvxd8VcuvrTzBPoaZRSZFplHksGFQv33ZHMpv OsY3s/wAv+WaLLXxaKdxJshvROfrNUA3t1ZipKHLPENkk6vNkYA02IgbjagnZzyfzx1H tKzFnM8a2lLqbUAKvXZ2ju07CxOPxtjwy2wyG2TTAgl5VAQZQQ7zrBkEtghD0qQ7xRTm /uw+4sMU9D8NHbczdXoYkkht1OxfTXJ+obIb20f4c2WpHpi9J4/ektWYnIFVqS+bOv7R xWdw== X-Received: by 10.66.102.74 with SMTP id fm10mr17564860pab.151.1443040835105; Wed, 23 Sep 2015 13:40:35 -0700 (PDT) Received: from [192.168.178.25] (238.225.69.111.dynamic.snap.net.nz. [111.69.225.238]) by smtp.gmail.com with ESMTPSA id d13sm9601407pbu.17.2015.09.23.13.40.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2015 13:40:33 -0700 (PDT) To: Lorenzo Colitti References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> <5601BDE9.6000609@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56030E44.9010101@gmail.com> Date: Thu, 24 Sep 2015 08:40:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org" , =?UTF-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 20:40:37 -0000 On 23/09/2015 22:38, Lorenzo Colitti wrote: > On Wed, Sep 23, 2015 at 5:45 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> These networks >>> are likely *not* concerned with per-device revenue, but they still >> provide >>> a limited number of addresses for other reasons (some of which may be >>> operational, or even scaling reasons). >> >> And I don't think your document will succeed in its purpose unless it >> explicitly recognises that those operational or scaling reasons may be >> reasonable and valid. As you know, operators will do what they need to do. >> >> Let's see: on a campus with a few tens of thousands of students, mainly >> connected wirelessly, will we have problems if a few hundred of them run >> a popular new app that generates a couple of thousand addresses when >> given a /64 to play with? >> > > It depends whether there are any stateful devices in the path, and how > smart those stateful devices are. A university campus with no stateful > firewall and only IPv6 will never have scaling issues if it assigns a /64 > per device. A campus that uses stateful firewalls might - but note that > this is a problem even today, and even in IPv4 - a determined attacker can > attempt to exhaust NAT or firewall state by opening lots of connections to > lots of different IP addresses, for example. > > Ditto if they catch a Trojan that knows how to have fun with its own /64. >> How quickly will the whole campus be black-listed? >> > > Never, because any server that supports IPv6 today needs to survive in the > presence of residential users with /56 prefixes and spammers / DoSers with > servers in datacenters that get /48s from tunnel brokers. The content > providers and CDNs started seeing and dealing with those attacks a long > time ago. > > >> Will the campus have severe legal problems if a couple of thousand students >> use a new address-agile file sharing app that saturates any form of >> audit logging, so that offending users can't be identified? >> > > Not if the campus assigns a /64 per device or per user. They can just pin > the blame on that /64. And my whole point: if assigning a /64 does *not* cause scaling, logging or security problems the draft needs to explain why not, as you and Mikael and Mark have done. Otherwise, I can pretty much guarantee that those arguments will be used against it. (And I forgot to mention ND cache scaling.) Brian From nobody Wed Sep 23 15:48:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408BE1B2CFC for ; Wed, 23 Sep 2015 15:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyHRay8KUxQV for ; Wed, 23 Sep 2015 15:48:54 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002: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 A05CE1A913F for ; Wed, 23 Sep 2015 15:48:54 -0700 (PDT) Received: by ykft14 with SMTP id t14so57117055ykf.0 for ; Wed, 23 Sep 2015 15:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/l7HMMHVrjFVh9i/sdjl/isIl1TuBnn1xFMb/MAA8ck=; b=HeNjbOltNc5AwNW5uD8Ct05U4tqa79+S4Lu9MZfrsL0u4AacRNdSB6bV6Z/MJCJdIN T7zdeL5Q5weQOTKdh9S/S1pP1M+X/T+AoFeas5GPSEh7r+Z3ccWvF2GtycVfiC/vVu0x n2sl8s1F9nP1J2yfHxoHLomC4kKOenZ/FtwJtTi2oRfLRd9Bmf0Zo9SdIGXxepXKj1+c awt44+TiDMmKHaIvzT09sfJamMeJ7tspMU588HtFzDO+gM4T7ZwDUX3kaAmVj0rjlMhA fITAxnxtQVW8D8ehcSuQP5aiAgDhsYdQlYd7Obn5SLQcAuAHisQtl7hsGs7nmO1o2r3t 9NuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/l7HMMHVrjFVh9i/sdjl/isIl1TuBnn1xFMb/MAA8ck=; b=AkQyk3l0Z9yFP3xNGTmSJiHTw/znQuUpvBuu8JrJ1fZA4h4Ymn/1RYM3TAfM6li7Hs BEVBXmPk9ImHwlxKmH2N0D7NAWbwrZMeBMqIN0h5JqHJGDQJWDRGSN6QFKQhcXyICUkW AjYt130gbRA37wB9CQYSExHvhCps4MBqMDHMHbujHrVrTizJ+IG8HftmrcLIYqtQaieN RYhjrPUtm78n0CtR3jaEO0bUF0+DvBuqkE6PsPmWfYZmWTPZAxtvCjiGICHQsxoztIG+ ZzIpRMzQozVUGTl+Gmnqzc+xSCxg8ik7UTAetY3sfVC8p78MRoACW7U3LVAm8tug844u ZkDw== X-Gm-Message-State: ALoCoQndjyJsa6NYyAiRiBb8dTjALUeR9YdmIVAWvUJ3sAMp5CzUcxVbArz9K+bwxrj/Q55H/nKr X-Received: by 10.13.254.3 with SMTP id o3mr28339058ywf.161.1443048533761; Wed, 23 Sep 2015 15:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Wed, 23 Sep 2015 15:48:34 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA15C83@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113AA15C83@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Lorenzo Colitti Date: Thu, 24 Sep 2015 07:48:34 +0900 Message-ID: To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=94eb2c054c904005dc052071ebd3 Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 22:48:57 -0000 --94eb2c054c904005dc052071ebd3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 23, 2015 at 11:57 PM, STARK, BARBARA H wrote: > > Here's one privacy benefit that requires the ability to form multiple > addresses: change your privacy address as often as you want, instead of h= ow > often the operator wants. Or, use different addresses to talk to differen= t > sites (e.g., a web server and an advertising server). These are both usef= ul > benefits if the network is trustworthy but the the attack is pervasive > monitoring outside the network (e.g., by a national security agency). > > > > Privacy addresses can help with 2 privacy functions: (1) they > obscure the MAC address; (2) self-generated SLAAC privacy addresses reduc= e > the ability to do external-to-the-local network tracking down to the /64 > prefix level. When the /64 is shared among multiple devices, there can > potentially be a little bit of additional privacy from tracking =E2=80=93= but even > that depends, given all the info browsers hand out to HTTP servers. When = a > /64 is dedicated to a device, and the /64 never changes, the benefit of > privacy addresses is reduced to obscuring the MAC address. A single > unchanging privacy address within the unchanging prefix provides exactly > the same obscuring of the MAC address as dozens of constantly changing > privacy addresses. We need to stop perpetuating this privacy myth. > I think what you're saying is not relevant to this discussion? "A single unchanging privacy address" is not what I wrote above - in fact it is the exact opposite. What I wrote was that there's a benefit to frequently changing addresses within the same prefix, or even using different addresses for every website. > 2. Several of the listed benefits involve potential use by multiple > processors on a host, virtual machines on a host, future applications, an= d > identifier-locator addressing (ILA). In listing these, there was nothing > that said "this is incredibly useful, but hosts are prevented from doing = it > (or run into a lot of complexity) if the host is restricted to a single > DHCPv6-assigned IPv6 address". I didn't read that hosts would have a hard > time having multiple processors or future applications in the absence of > multiple addresses, and I didn't get out of the discussion that virtual > machines and ILAs that require their own address are incredibly compellin= g > and hosts and users can't live without them. > > > As someone who has worked on the ePDG implementation on Android devices, = I > can assure you that the architecture that's used to ensure that the > baseband processor and the application processor could share an IP addres= s > is pretty contorted - you might even say nightmarish. > > > > But it=E2=80=99s been done? Now if you said that not using this nig= htmarish > code would improve battery life of the devices, that would be a real > benefit (from an operator perspective =E2=80=93 who is your target audien= ce). But > if the code is done and works, then I don=E2=80=99t see why an operator s= hould care > how nightmarish it was for the OS implementation. > When the code is complex, everybody (users, operators, developers, ...) suffer from a higher incidence of bugs, higher maintenance costs, and increased development cost / development time needed to evolve the code for new features. If you say that's not the operator's problem... well, I like to think that some (perhaps most?) operators strive to do better for their users than that. And anyone trying to advance the state of the Internet, like we do here at the IETF, should be trying to ensure that standards do not force that sort of complexity on implementations. > I didn=E2=80=99t say VMs didn=E2=80=99t need their own addresses. W= hat I said was I > wasn=E2=80=99t convinced that all hosts needed VMs in order to do whateve= r it was > the user wanted them to do. You haven=E2=80=99t provided a compelling rea= son why > VMs are beneficial in hosts. Without that, I don=E2=80=99t understand why= I should > care whether or not all hosts can run VMs. > The question is not whether all hosts need to run VMs. The question is whether some hosts need to run VMs or do other things that benefit from multiple addresses. > ... which is really the point here. What we're trying to say here is not > that these use cases are hard or impossible without multiple addresses. > What we're trying to say is that they exist, and that they can either be > met using multiple addresses or (in most cases) by performing NAT66 in th= e > host. We're recommending that we do not go to an architecture where hosts > need to implement NAT66, and thus we recommend that the network should > assign enough addresses that NAT66 is not necessary. > > > > NAT66 is not something that hosts inside enterprise networks need t= o > be worried about. > Why? I know lots of users of my enterprise network that run VMs, run Android / iOS emulators on their development machines, use ePDG services, etc. With only one /128 per host, you can'd to that without NAT66. > Yes, I can see that it=E2=80=99s a problem for UEs in a wireless network. > NAT66 is currently not a problem on 3GPP wireless networks, because when the wireless standards organizations came to the IETF for advice when designing IPv6 support in 3GPP (I suppose at that time it must have been called GSM), the IETF gave them the same advice given in this draft - that a /128 per device is not enough and that a /64 was needed. > Also, I'm not sure exactly what you're trying to say here. Are you saying > that: > > 1. You disagree that if the network assigns a single /128, hosts will > implement and use NAT66; that they will instead reduce or disable (pos= sibly > user-visible) functionality. > 2. You believe that it's fine if networks assign a single /128 to a > device, even if it means that hosts will (possibly widely) implement N= AT66. > 3. Something else? > > I=E2=80=99m saying that you haven=E2=80=99t presented your case in = a very compelling > manner. The case for (the interior of) enterprise networks is non-existen= t. > So, to be clear - when you say "the case for enterprise networks is non-existent", you're saying that you expect hosts inside enterprise and educational networks (let's not forget about those, BTW) to need to run NAT66 to support features that require multiple addresses, and that's not a problem? --94eb2c054c904005dc052071ebd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 23, 2015 at 11:57 PM, STARK, BARBARA H <bs7652@att.com>= wrote:
=

Here's one privacy benefit that require= s the ability to form multiple addresses: change your privacy address as of= ten as you want, instead of how often the operator wants. Or, use different= addresses to talk to different sites (e.g., a web server and an advertising server). These are both useful benefits if t= he network is trustworthy but the the attack is pervasive monitoring outsid= e the network (e.g., by a national security agency).

=C2=A0

<bhs> Privacy addresses can help with 2 privacy func= tions: (1) they obscure the MAC address; (2) self-generated SLAAC privacy a= ddresses reduce the ability to do external-to-the-local network tracking down to the /64 prefix level. When the /64=C2=A0 is share= d among multiple devices, there can potentially be a little bit of addition= al privacy from tracking =E2=80=93 but even that depends, given all the inf= o browsers hand out to HTTP servers. When a /64 is dedicated to a device, and the /64 never changes, the benefit of privac= y addresses is reduced to obscuring the MAC address. A single unchanging pr= ivacy address within the unchanging prefix provides exactly the same obscur= ing of the MAC address as dozens of constantly changing privacy addresses. We need to stop perpetuating thi= s privacy myth.


I think what you're saying is not relevant to this discussion? "= A single unchanging privacy address" is not what I wrote above - in fa= ct it is the exact opposite. What I wrote was that there's a benefit to= frequently changing addresses within the same prefix, or even using differ= ent addresses for every website.
=C2=A0

<= /p>

=C2=A02. Several of the listed benefits involve pote= ntial use by multiple processors on a host, virtual machines on a host, fut= ure applications, and identifier-locator addressing (ILA). In listing these= , there was nothing that said "this is incredibly useful, but hosts are prevented from doing it (or run into a lot of comple= xity) if the host is restricted to a single DHCPv6-assigned IPv6 address&qu= ot;. I didn't read that hosts would have a hard time having multiple pr= ocessors or future applications in the absence of multiple addresses, and I didn't get out of the discussion that vir= tual machines and ILAs that require their own address are incredibly compel= ling and hosts and users can't live without them.

=
=

=C2=A0

As someone who has worked on the ePDG implementation= on Android devices, I can assure you that the architecture that's used= to ensure that the baseband processor and the application processor could = share an IP address is pretty contorted - you might even say nightmarish.

=C2=A0

<bhs> But it=E2=80=99s been done? Now if you said th= at not using this nightmarish code would improve battery life of the device= s, that would be a real benefit (from an operator perspective =E2=80=93 who is your target audience). But if the code is done and works,= then I don=E2=80=99t see why an operator should care how nightmarish it wa= s for the OS implementation.

=
When the code is complex, everybody (users, operators, devel= opers, ...) suffer from a higher incidence of bugs, higher maintenance cost= s, and increased development cost / development time needed to evolve the c= ode for new features. If you say that's not the operator's problem.= .. well, I like to think that some (perhaps most?) operators strive to do b= etter for their users than that. And anyone trying to advance the state of = the Internet, like we do here at the IETF, should be trying to ensure that = standards do not force that sort of complexity on implementations.
=C2=A0

<= u>

<bhs> I didn=E2=80=99t say VMs didn=E2=80=99t need their ow= n addresses. What I said was I wasn=E2=80=99t convinced that all hosts need= ed VMs in order to do whatever it was the user wanted them to do. You haven=E2=80=99t provided a compelling reason why VMs are beneficia= l in hosts. Without that, I don=E2=80=99t understand why I should care whet= her or not=C2=A0 all hosts can run VMs.


The question is not whether all hosts = need to run VMs. The question is whether some hosts need to run VMs or do o= ther things that benefit from multiple addresses.
=C2=A0=C2=A0

... which is really the point here. What we're t= rying to say here is not that these use cases are hard or impossible withou= t multiple addresses. What we're trying to say is that they exist, and = that they can either be met using multiple addresses or (in most cases) by performing NAT66 in the host. We're re= commending that we do not go to an architecture where hosts need to impleme= nt NAT66, and thus we recommend that the network should assign enough addre= sses that NAT66 is not necessary.

=C2=A0

<bhs> NAT66 is not something that hosts inside enter= prise networks need to be worried about.

=

Why? I know lots of user= s of my enterprise network that run VMs, run Android / iOS emulators on the= ir development machines, use ePDG services, etc. With only one /128 per hos= t, you can'd to that without NAT66.
=C2=A0

Yes, I ca= n see that it=E2=80=99s a problem for UEs in a wireless network.

=

= NAT66 is currently not a problem on 3GPP wireless networks, because when th= e wireless standards organizations came to the IETF for advice when designi= ng IPv6 support in 3GPP (I suppose at that time it must have been called GS= M), the IETF gave them the same advice given in this draft - that a /128 pe= r device is not enough and that a /64 was needed.
=C2=A0

Also, I'm not sure exactly what you're tryin= g to say here. Are you saying that:

  1. You disagree that if the network assigns a single /128, hosts will implemen= t and use NAT66; that they will instead reduce or disable (possibly user-vi= sible) functionality.
  2. You believe that it's fine if networks assign a single /128 to a device= , even if it means that hosts will (possibly widely) implement NAT66.
  3. Something else?

<bhs> I=E2=80=99m saying that you haven=E2=80= =99t presented your case in a very compelling manner. The case for (the int= erior of) enterprise networks is non-existent.


So, to be clear - when you say "the case for= enterprise networks is non-existent", you're saying that you expe= ct hosts inside enterprise and educational networks (let's not forget a= bout those, BTW) to need to run NAT66 to support features that require mult= iple addresses, and that's not a problem?
--94eb2c054c904005dc052071ebd3-- From nobody Wed Sep 23 18:18:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075E01B3456 for ; Wed, 23 Sep 2015 18:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG43KgzSgeeH for ; Wed, 23 Sep 2015 18:18:31 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C2E1B3427 for ; Wed, 23 Sep 2015 18:18:31 -0700 (PDT) Received: by ioiz6 with SMTP id z6so61426232ioi.2 for ; Wed, 23 Sep 2015 18:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ALYwBc1WJw8hGZUe772e1GrAnNeH63GyhVtbGs/xNIs=; b=0Zlv4vZRAwt1BgU6ldNva0vwDL9qMaEYqUZRxX4qvLpFzTPibd+eAONo10fVKTAWTT TDwtuCDYPONCWj58C37UCTyNcgVd4E6MxOXOwD7ywxfYGz4ZtaKFbpdCmyLvMuzc5lgd V0RvWRXVqU5trlBBZv0H90+lCOgPpG/Vlt9iOPZZSluKnoT51iuf9NfAZUSKh7lsg75P gWB2NzLePRg3Lyyuv+2sd7CbvY3j3d7ka+3RbO2xvnmxbpTbvwj0T2zTWDj9CyGgn8yP Hh/zU+NaNl1mfcC1waC2SxIyJUK4f6wRf+IbF8zxfQm9eDCFxGOwx5NQuEsNgd6AdYFC YA9g== MIME-Version: 1.0 X-Received: by 10.107.164.197 with SMTP id d66mr39758809ioj.85.1443057510821; Wed, 23 Sep 2015 18:18:30 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Wed, 23 Sep 2015 18:18:30 -0700 (PDT) Received: by 10.107.142.148 with HTTP; Wed, 23 Sep 2015 18:18:30 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> Date: Thu, 24 Sep 2015 11:18:30 +1000 Message-ID: From: Mark Smith To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a1141c8e252b4b00520740220 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 01:18:33 -0000 --001a1141c8e252b4b00520740220 Content-Type: text/plain; charset=UTF-8 On 22 Sep 2015 11:22 pm, "Mikael Abrahamsson" wrote: > > On Tue, 22 Sep 2015, Mark Smith wrote: > >> I've never been completely sure whether IPv6 supports the weak or strong host model, or whether it is possible for a host/implementation to be one or the other. > > > I'd say a bit of both. > > I find that systems that will respond to an arp query for its eth1 address and the arp request comes in on eth0 to be fundamentally broken. Some people do not agree. From this aspect, I'd say my take is that IPv6 uses the strong hos model. > I agree, and I think it is probably because I first got exposed to multi-address issues on routers, and they followed the strong "host" model. Addresses are assigned to interfaces, and if the interface goes down or is taken down, the associated addresses become unavailable. I find that very intuitive because the address state follows the interface state. > However, most hosts will glady send out traffic sourced from eth0 IPv6 address via eth1, if that happens to be the best default route for the node, indicating weak host model. > > With hosts implementing MIF, I hope most things will be strong host model only. > OTOH, if an interface suffers a transient fault, should all of the sockets that are using the interface's addresses be immediately destroyed? I'd say no, but that then means the weak host model is the better and more robust one. Actually, this has reminded me of probably what I'd prefer on hosts. Weak host model by default, meaning addresses and associated sockets survive transient link faults, strong host model if interfaces are administratively taken down, so addresses and associated sockets disappear when intended by an operator or process. I think this starts to uncover two different behaviours behind the strong and weak host models: - is an address still available for a host to use/listen to if the interface the address is associated with goes down and/or is taken down administratively? - if the address is still available when the associated interface is down, should packets using that address be routed out other interfaces, or should they be dropped. Regards, Mark. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se --001a1141c8e252b4b00520740220 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 22 Sep 2015 11:22 pm, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Tue, 22 Sep 2015, Mark Smith wrote:
>
>> I've never been completely sure whether IPv6 supports the weak= or strong host model, or whether it is possible for a host/implementation = to be one or the other.
>
>
> I'd say a bit of both.
>
> I find that systems that will respond to an arp query for its eth1 add= ress and the arp request comes in on eth0 to be fundamentally broken. Some = people do not agree. From this aspect, I'd say my take is that IPv6 use= s the strong hos model.
>

I agree, and I think it is probably because I first got expo= sed to multi-address issues on routers, and they followed the strong "= host" model. Addresses are assigned to interfaces, and if the interfac= e goes down or is taken down, the associated addresses become unavailable. = I find that very intuitive because the address state follows the interface = state.

> However, most hosts will glady send out traffic sourced= from eth0 IPv6 address via eth1, if that happens to be the best default ro= ute for the node, indicating weak host model.
>
> With hosts implementing MIF, I hope most things will be strong host mo= del only.
>

OTOH, if an interface suffers a transient fault, should all = of the sockets that are using the interface's addresses be immediately = destroyed? I'd say no, but that then means the weak host model is the b= etter and more robust one.

Actually, this has reminded me of probably what I'd pref= er on hosts. Weak host model by default, meaning addresses and associated s= ockets survive transient link faults, strong host model if interfaces are a= dministratively taken down, so addresses and associated sockets disappear w= hen intended by an operator or process.

I think this starts to uncover two different behaviours behi= nd the strong and weak host models:

- is an address still available for a host to use/listen to = if the interface the address is associated with goes down and/or is taken d= own administratively?

- if the address is still available when the associated inte= rface is down, should packets using that address be routed out other interf= aces, or should they be dropped.

Regards,
Mark.

>
> --
> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

--001a1141c8e252b4b00520740220-- From nobody Wed Sep 23 21:42:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9281B303F for ; Wed, 23 Sep 2015 21:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wc39i8C9XjI for ; Wed, 23 Sep 2015 21:42:56 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BEF1B3030 for ; Wed, 23 Sep 2015 21:42:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7674FA1; Thu, 24 Sep 2015 06:42:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443069772; bh=ITtn9FT4xiNkNzJ0cOK8z1x3du1fmgzWLd0kaB5iEUw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=w/FhAMiNQbTcneszsogAjCyrNC4O6u650dFuRONvV9a5Lj2ria2v9Tk9QoiBV09MD UJPm6aTnbvl9psuFxNSCSIDNXgpvh+KZq9WTozLWYDZ5jEqWXCtaJW5ELzpxINA6WZ vAEK0lPNgvUbIQ/0UqtAamt4+07xpC4VhxMrf780= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6C1199F; Thu, 24 Sep 2015 06:42:52 +0200 (CEST) Date: Thu, 24 Sep 2015 06:42:52 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 04:42:58 -0000 On Thu, 24 Sep 2015, Mark Smith wrote: > OTOH, if an interface suffers a transient fault, should all of the > sockets that are using the interface's addresses be immediately > destroyed? I'd say no, but that then means the weak host model is the > better and more robust one. I brought this up on the IETF TCP lists a few years back, that there should be some kind of analysis of this. For instance, if I know that an interface will always give me a new IP address, I would like to configure my connection manager to kill all TCP sessions that terminate on IP addresses on that interface. It's not going to be a transient error, because if that interface goes down, those IP addresses are gone forever. > Actually, this has reminded me of probably what I'd prefer on hosts. > Weak host model by default, meaning addresses and associated sockets > survive transient link faults, strong host model if interfaces are > administratively taken down, so addresses and associated sockets > disappear when intended by an operator or process. Because of BCP38, using the weak model doesn't really work, and anyhow, how are you going to get the packets there if the interface is down? > - if the address is still available when the associated interface is > down, should packets using that address be routed out other interfaces, > or should they be dropped. Most of the time, you won't be able to get packets back (if the interface is down) so making sure you can send out the packets is of limited practical use. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 23 21:45:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477431B3037 for ; Wed, 23 Sep 2015 21:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L_-uI-w3i9I for ; Wed, 23 Sep 2015 21:45:56 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002: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 0110C1B3030 for ; Wed, 23 Sep 2015 21:45:55 -0700 (PDT) Received: by ykdg206 with SMTP id g206so62978664ykd.1 for ; Wed, 23 Sep 2015 21:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UTnexbV8/o39BYlxQ0La3G6ZYSsb2xqbUe4m6CSNViY=; b=QmOCXX5ITXWIQzEfun1Q60P9qnLqHKOLTMJ8A7mRDuVP/3FiWorN5XCCuNllrSjJSp cEyScuZKejSWNH+r/YqkmyqqUa0WPmZoM4t09KUZwlZ59V/NM7Kh0VEKY9boVQyXT4zK FK6AhuL5J/WPLN6VhYYi0XAgRIexEVosggHjmqfHCu22oH+8uFy21k4o7+H3ALLq8svI ieT7VMKJYJIlDLbFNjuhY4XAJ/NLipPGslSyO2CN8LsuwfDgreHj2FXea/EsSNsqKJF1 nMogsOAY4c9fE7lfy7iaaLth0xfj4f+70WlUsn7AA83DNYIsIB7+LBWgyqCMtQNLp9IC 4b8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UTnexbV8/o39BYlxQ0La3G6ZYSsb2xqbUe4m6CSNViY=; b=fUFIdLbEMtEFZhvQWPDCECTJcdk5IL6QxH7WMKxpEukfxVo5sL6PF9loj1rr3AneKs Pi09iM6DAfBbDlmPJtcHa7tkxGxs5B99NqbbfwPEjicAKNknQqbBJK0v5COrDsge4B5C 5fsJCdpcQbeSlU9dmcwTR18p63Coh2YMHNRjehzGwVKCymoK3vpeti04VOebGMz79/mz g4QbvsRT7lR1hhJ6k2ofmzRnAfGIDSueF7qTnMtsdvb+4AM0QVm3rjm1DZX8qLWnt54D TbS5joYRn2+URjKvdChESZOahTE+A8BM+D+VgcQLaKq9h+S8Y7ub3l/J7YTDB/y2wW5u FDuA== X-Gm-Message-State: ALoCoQlWW4d5AdvZ/LkJ5dkh5LH/7vuQbH8uNnKndV0QWgDLK+PchALgeK31V7NkE/Ekx06tYg3e X-Received: by 10.13.254.3 with SMTP id o3mr29162426ywf.161.1443069955201; Wed, 23 Sep 2015 21:45:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Wed, 23 Sep 2015 21:45:35 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> From: Lorenzo Colitti Date: Thu, 24 Sep 2015 13:45:35 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=94eb2c054c90114bc3052076e806 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 04:45:57 -0000 --94eb2c054c90114bc3052076e806 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 24, 2015 at 1:42 PM, Mikael Abrahamsson wrote: > > I brought this up on the IETF TCP lists a few years back, that there > should be some kind of analysis of this. For instance, if I know that an > interface will always give me a new IP address, I would like to configure > my connection manager to kill all TCP sessions that terminate on IP > addresses on that interface. It's not going to be a transient error, > because if that interface goes down, those IP addresses are gone forever. That's certainly what Android does. https://android.googlesource.com/platform/system/netd/+/master/server/NetlinkHandler.cpp#80 --94eb2c054c90114bc3052076e806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 24, 2015 at 1:42 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
I brought this up on the IETF TCP lists a few years back, that there should= be some kind of analysis of this. For instance, if I know that an interfac= e will always give me a new IP address, I would like to configure my connec= tion manager to kill all TCP sessions that terminate on IP addresses on tha= t interface. It's not going to be a transient error, because if that in= terface goes down, those IP addresses are gone forever.
= =C2=A0
That's certainly what Android does.
--94eb2c054c90114bc3052076e806-- From nobody Wed Sep 23 22:00:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC51B306A for ; Wed, 23 Sep 2015 22:00:38 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNd92ehSxyPw for ; Wed, 23 Sep 2015 22:00:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3631B3069 for ; Wed, 23 Sep 2015 22:00:35 -0700 (PDT) Received: from [192.168.1.156] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8O50ErT026182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 23 Sep 2015 22:00:16 -0700 (PDT) References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <2D09D61DDFA73D4C884805CC7865E6113AA0F932@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 To: v6ops list Message-ID: <5603835D.3080000@isi.edu> Date: Wed, 23 Sep 2015 22:00:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 05:00:38 -0000 Hi, all, Catching up... > I've never been completely sure whether IPv6 supports the weak or > strong host model, or whether it is possible for a host/implementation > to be one or the other. Hosts are generally weak at the IP layer (whether v4 or v6) and strong at the Ethernet layer. However, strong/weak deals with two assumptions: 1) the addresses are bound i.e., if an interface goes *down*, then neither model will preserve a connection bound to that address 2) strong/weak focuses on incoming messages the rules for setting the source address of outgoing messages *whose source address is absent* are different, e.g., RFC1122 gives rules in which routes select an outgoing interface then that interface's IP address is used as the source none of these apply when both source is already set; in that case, AFAICT strong model layers/hosts need to send the message out the matching interface whereas weak model/layers might allow other behaviors IPv4, IPv6, and Ethernet all support multiple addresses per interface, FWIW. I don't see that as incompatible with either the strong or weak model, except that the set of addresses associated with a single interface is - by definition - weak within that set, but strong is usually a per-interface concept anyway and thus does not apply within the set of addresses for an interface. Joe From nobody Wed Sep 23 22:58:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514761B3178 for ; Wed, 23 Sep 2015 22:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Mv9vzvW9df for ; Wed, 23 Sep 2015 22:58:38 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A42B1B3171 for ; Wed, 23 Sep 2015 22:58:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6C72FA1; Thu, 24 Sep 2015 07:58:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443074315; bh=1rML+uB8GMlMzeYtFZfB8eBCQpvzv8Avp8jz3ZI2A94=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dlkembn3qjQn1lF8yvkXfdNSCdkwjWGIkEEGsLSNTYsKYSHeMhWfiF8oDUE72CQx1 PEHfbzUxEnSEhYBW+qW4OP0YmDrp+YSZiTa0JaueeiJofbdXUkJ+NXWBHx7K0qiB/s /9CkY8PK3du0qb4qL2PQnJJDvlvpvO7ruTTrgiKw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 64FA49F; Thu, 24 Sep 2015 07:58:35 +0200 (CEST) Date: Thu, 24 Sep 2015 07:58:35 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 05:58:40 -0000 On Thu, 24 Sep 2015, Lorenzo Colitti wrote: > On Thu, Sep 24, 2015 at 1:42 PM, Mikael Abrahamsson > wrote: >> >> I brought this up on the IETF TCP lists a few years back, that there >> should be some kind of analysis of this. For instance, if I know that an >> interface will always give me a new IP address, I would like to configure >> my connection manager to kill all TCP sessions that terminate on IP >> addresses on that interface. It's not going to be a transient error, >> because if that interface goes down, those IP addresses are gone forever. > > That's certainly what Android does. > > https://android.googlesource.com/platform/system/netd/+/master/server/NetlinkHandler.cpp#80 I got shot down pretty well when I suggested this, good that someone agrees with me anyway. They kept suggesting that I should use TCP keepalives instead, but over for instance mobile, that would be really bad for battery life. Generally I think it's better to fail early and then instead let upper layers handle the reconnections. Having TCP timeouts in tens of minutes or even hours isn't really useful for most uses of the network nowadays. Most things that users do are interactive and if it hasn't happened in 10 seconds, most users will give up anyway. Also, failing more often would mean the upper level application developers would be more often exposed to errors and they'd make sure that they could handle it properly. Mosh (https://mosh.mit.edu/) is still pretty much ideal kind of interactive experience for me, I would really like more things to work like it, at least the ones that required interactivity. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 24 01:35:43 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1357C1A011F for ; Thu, 24 Sep 2015 01:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAbb9nvTpZxo for ; Thu, 24 Sep 2015 01:35:39 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAC71A0115 for ; Thu, 24 Sep 2015 01:35:39 -0700 (PDT) Received: by ioii196 with SMTP id i196so69510218ioi.3 for ; Thu, 24 Sep 2015 01:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lQOOM/beQypT1tHgoGI27LVTxsQ3AoKKVcRHE+RLrFc=; b=qITv0ejjMh+1mABeI4pzDovoN7Sg/ui4DCvqW3YX6+2TkCxEXbMDaR83VDe2O1utJc UrbxdWwKg5CC9zglAqudvxkySS2K7i3xHmlo6zry2GpGBEGIeIWtRwxyY0q8A+QqcuCt HU71mG/tCGZZEp3xh0P/9eY89Ud7jd/a0wEo0H4SXTuuARzUti/gCcFMU33hgBpu4MqX GwLtwGUWdgZQh0TMZNR1tX9LQhFp+cINt4tg1zaPTio9iUEiieSb6MOcriH8v4Yqmt5z ZzbGiAEL20BIVvEVz0u81wfi/LIFxpyFxr3TiExHj7Myic2d50IX094ucrsq58pQS0L1 /toA== MIME-Version: 1.0 X-Received: by 10.107.136.213 with SMTP id s82mr43303724ioi.111.1443083738895; Thu, 24 Sep 2015 01:35:38 -0700 (PDT) Received: by 10.107.13.130 with HTTP; Thu, 24 Sep 2015 01:35:38 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA15A0D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113AA15A0D@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 24 Sep 2015 10:35:38 +0200 Message-ID: From: =?UTF-8?B?QW5kcmV3IPCfkb0gIFlvdXJ0Y2hlbmtv?= To: "STARK, BARBARA H" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 08:35:41 -0000 On 9/23/15, STARK, BARBARA H wrote: >> > 1. Privacy. Changing tracking requirements from needing to track a >> > /128 to only needing to track a /64 does not provide for any sort of >> > improved privacy against tracking. We need to stop perpetuating this >> > myth. >> > draft-ietf-dhc-dhcp-privacy already describes how to provide a single >> > address that doesn't give away the MAC address. Other than not giving >> > away the MAC, there is no privacy benefit I can see to more easily >> > allowing tracking systems to track at the /64 instead of the /128. >> >> I interpret the words in the draft differently: the point is that instead >> of >> storing 8*128 bits of bindings on the access router one can store 1*64 >> bits. >> (and yes you need to store the bindings if you want to have the secure >> access today). > > Exactly my point. The same invasion-of-privacy tracking can be done at /64 > instead of /128, thereby making such tracking easier. Making invasion of > privacy easier should not be listed as a benefit. But I could see "Easier > Tracking" being listed as a benefit. Okay, I was interpreting as the latter all the time, so maybe you have some wording tweak in mind you could suggest to the authors... > >> > 3. Tethering and translation (like 464XLAT) tend to be really specific >> > to wireless networks. These are the most compelling benefits listed, >> > but they don't apply to enterprise and wireline. >> >> I personally had discussions with multiple large-ish enterprises >> interested in >> the 464XLAT or derived tech in their wired networks. > > In my response to Tore, I acknowledged that I should have said 464XLAT only > makes sense in IPv6-only networks. But I also still don't see these > enterprise networks expecting to run 464XLAT in all end hosts and make the > entire enterprise network IPv6-only. I see them wanting to put the 464XLAT I see them wanting IPv6-only access networks, besides other things. > at the edge. This draft is listing 464XLAT in end hosts as a reason why all > networks should give all end hosts IPv6 prefixes. > >> > >From a wireless perspective, I don't really see this as being what >> > >would >> > convince a wireless operator to deploy PD. The case I try to make is >> > that >> >> IPv6 in 3GPP environments allocate /64 per UE today. > > Really? I'd heard that was true of some deployments. I hadn't heard that it > was true of all. If it is true of all, then I'm very curious why Apple and > Google feel the need for this draft. I think Lorenzo has commented on this one already. > BTW, the link you provided was > describing a 3GPP standard. The idea that everything described in the > standard is implemented and deployed in all 3GPP wireless networks that have > enabled some degree of IPv6 support is not true. There's quite a big > difference between what gets written in 3GPP standards and what ends up > being deployed and enabled. > >> I've been told that the SP WiFi architecture best practice is to also >> allocate >> dedicated per-UE prefix on converged WiFi as well. > > Interesting. I'll have to try that out next time I'm in range of a attwifi > hotspot. > >> > wireless is more and more being used in the same manner as wireline: >> > to support an entire LAN of networked devices behind a CE router >> > (usually with a USB-connected wireless device). In many places, >> > operators are saying that wireless is the deployment model for getting >> > "broadband access" to rural areas. If this use case is going to be >> > fully supported with IPv6, then PD has to be supplied. Of course, with >> > wireless networks being able to easily recognize the type of device >> > used and the user, the network operator will always have the ability >> > to selectively offer the PD to only certain users >> >> Every time I mention per-user tweaks with any SP in any context, they >> make >> a lemon face. > > There's a rather famous case of a wireless provider who only allowed > Facetime to be used by subscribers with "Share" data plans and not > "individual" data plans. That same provider is also known to specify which > UEs get IPv6 addresses and which don't. Some providers are known to > implement bandwidth limitations on heavy-usage subscribers. Perhaps there > are some providers who do not implement any UE-based or subscriber / > subscribed-plan based policies. But there are many who do. Of course I don't > consider these policies to be "per-user tweaks". I would characterize them > as policies that impact individual users on the basis of their UE, usage, > and subscribed data plan; they may be implemented throughout a network or > only in certain regions or markets of a network. And where I live, they're > incredibly common. Sure, if the necessity requires - indeed. But my overall position is that even if something is done frequently, that does not make it a good idea long-term. An overall analogy would be that this draft advocates that quitting smoking is a best practice. Of course there are short-term localized benefits of smoking and in some places it's even considered cool to smoke. --a > Barbara > From nobody Thu Sep 24 01:53:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AE11A8742 for ; Thu, 24 Sep 2015 01:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tap8OZtj37sC for ; Thu, 24 Sep 2015 01:53:55 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3201A8740 for ; Thu, 24 Sep 2015 01:53:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8O8rqLn029970 for ; Thu, 24 Sep 2015 10:53:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A73AD20215B for ; Thu, 24 Sep 2015 10:58:54 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9FAB7202150 for ; Thu, 24 Sep 2015 10:58:54 +0200 (CEST) Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8O8rnul028078 for ; Thu, 24 Sep 2015 10:53:51 +0200 To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113AA15A0D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Alexandre Petrescu Message-ID: <5603BA1D.4030404@gmail.com> Date: Thu, 24 Sep 2015 10:53:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA15A0D@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 08:53:57 -0000 Le 23/09/2015 16:03, STARK, BARBARA H a écrit : [...] >>>> From a wireless perspective, I don't really see this as being >>>> what would convince a wireless operator to deploy PD. The case >>>> I try to make is that >> >> IPv6 in 3GPP environments allocate /64 per UE today. > > Really? I'd heard that was true of some deployments. I hadn't heard > that it was true of all. It depends how much detail is mentioned. Yes, in IPv6 cellular networks the UE sees a /64 in an RA - the Prefix Information Option. However, that means little about a /64 being 'allocated' to a User Equipment (UE). Yes, the network considers that /64 be for one particular UE; yes, the network uses internally DHCPv6-PD to acquire that /64. The first-hop router requests it and then puts it in an RA towards UE. But no, the UE does not request it, typical smartphones do not run DHCPv6-PD and the network does not respond to prototype UEs making DHCPv6-PD requests. It can also be considered that a /64 so 'allocated' to a cellular UE allows UE to configure each single address in that prefix (as opposed to a laptop seeing a PIO in RA on WiFi, which must DAD it first and which may collide to other laptops hearing the same /64). But this is so - UE has right to each address in a /64 - because the cellular link is still a point-to-point link, contrary to shared WiFi - there's no one else on that UE link. Another detail: cellular networks running DHCPv6 to UE, along with RA, allocate an _address_ to an UE. That address has no prefix length because DHCPv6-Address does not communicate prefix lengths. In some deployment, the first 64bits of the address allocated by DHCPv6 are different than the PIO in the RA received at the same time. The UE ends up with two global addresses: one can be said to _have_ a prefixlen, the other no. In this setting, what one needs is DHCPv6-PrefixDelegation for UE, and the prefixlength must be < 64. The reasons are: (1) it allows to tether/route cleanly more than 1 subnet (2) is future proof for 5G links which will be presumably more shared than ptp, (3) empowers the UE (it _requests_ a prefix first, rather than being _advertised_ a prefix). > If it is true of all, then I'm very curious why Apple and Google feel > the need for this draft. BTW, the link you provided was describing a > 3GPP standard. The idea that everything described in the standard is > implemented and deployed in all 3GPP wireless networks that have > enabled some degree of IPv6 support is not true. There's quite a big > difference between what gets written in 3GPP standards and what ends > up being deployed and enabled. I agree. >> I've been told that the SP WiFi architecture best practice is to >> also allocate dedicated per-UE prefix on converged WiFi as well. > > Interesting. I'll have to try that out next time I'm in range of a > attwifi hotspot. Or maybe try Monzoon-equipped hotels, as an earlier poster pointed to. Alex From nobody Thu Sep 24 02:23:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834FF1B3800 for ; Thu, 24 Sep 2015 02:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeCJyxMy9Jyz for ; Thu, 24 Sep 2015 02:23:37 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0EE1A8AC1 for ; Thu, 24 Sep 2015 02:22:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A16C9A1; Thu, 24 Sep 2015 11:22:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443086576; bh=MqrdhzhZ00iDgGC6BbqbGJojiJ6BwaNmGzfnSKjp2O0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=C9fVpGLQp8widt+SEJbKbegRLAdUBCtQX/cpcgxm/Hn/7RZ9B9l3dV2DVXDt2vrVm VfWzp4mTzyFBj4xBRDQplLfZtEPfoeWO5Lald4t54rYYxzfkLLjX9jo3ciMPm8ExY/ TJNjUQdbYE7IFf5mpcn8ojuPPmAEXVZtkMS9BEbY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9A7209F; Thu, 24 Sep 2015 11:22:56 +0200 (CEST) Date: Thu, 24 Sep 2015 11:22:56 +0200 (CEST) From: Mikael Abrahamsson To: "STARK, BARBARA H" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA15A0D@GAALPA1MSGUSRBF.ITServices.sbc.com> Message-ID: References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113AA15A0D@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 09:23:38 -0000 On Wed, 23 Sep 2015, STARK, BARBARA H wrote: > Really? I'd heard that was true of some deployments. I hadn't heard that > it was true of all. If it is true of all, then I'm very curious why > Apple and Google feel the need for this draft. BTW, the link you The need for this isn't for 3GPP networks. 3GPP networks always give /64 per PDP context (it's in the specs, and since RAs and A=1 is used for the UE to learn the on-link prefix to form addresses from, it can't be anything else than a /64 according to the SLAAC specifications). The problem this draft is trying to alleviate is generally enterprise Wifi networks where some administrators want to use DHCPv6 to allocate addresses. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 24 08:52:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0CF1A1EFC for ; Thu, 24 Sep 2015 08:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw9lUiuZK_o8 for ; Thu, 24 Sep 2015 08:52:10 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) (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 219471A1EF6 for ; Thu, 24 Sep 2015 08:52:09 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 7F167C45E; Thu, 24 Sep 2015 10:52:08 -0500 (CDT) Received: from 2602:3f:916c:a402:7aac:c0ff:fe97:ce69 ([2602:3f:916c:a402:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Thu, 24 Sep 2015 10:52:08 -0500 Date: Thu, 24 Sep 2015 10:52:08 -0500 Message-ID: <20150924105208.Horde.tvHlz77J3rCb3C6dqtYpmBl@mail.drown.org> From: Dan Drown To: v6ops@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113AA15C83@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 15:52:16 -0000 Quoting Lorenzo Colitti : : > As someone who has worked on the ePDG implementation on Android devices, I > can assure you that the architecture that's used to ensure that the > baseband processor and the application processor could share an IP address > is pretty contorted - you might even say nightmarish. : >> NAT66 is not something that hosts inside enterprise networks need to >> be worried about. >> > > Why? I know lots of users of my enterprise network that run VMs, run > Android / iOS emulators on their development machines, use ePDG services, > etc. With only one /128 per host, you can'd to that without NAT66. Because I didn't know what ePDG was before this, I had to look it up. Below is my summary of it, anyone who understands it better, please feel free to correct it. ePDG is a secure tunnel back to your cell phone operator, and wifi calling is one application that can run over it. It runs on the baseband processor rather than the application processor of the phone. There are two different operating systems running on these processors, and they need to share connectivity to the outside world. With v4, I assume this is achived with NAT44 when connected to a wifi AP. Wifi calling is an application that's on millions of phones already. I don't know if ePDG is a popular implementation or if there are any competing implementations. With v6, the design of assigning a dedicated v6 address (from a prefix or a pool) to the baseband processor would make sense for this application, as it makes the phone's internal network easier to understand. The alternatives would be to do NAT66 on the application processor or not have v6 on the baseband processor at all. From nobody Thu Sep 24 11:29:45 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347781A3BA2 for ; Thu, 24 Sep 2015 11:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoOtEVpT09Bs for ; Thu, 24 Sep 2015 11:29:42 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E28D1A21C6 for ; Thu, 24 Sep 2015 11:29:42 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so127612489igb.0 for ; Thu, 24 Sep 2015 11:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NUxivVnhpSixLSrmlejRAb/EXw4eDSHQCS6nZkycCYY=; b=CYgHUAmSvT13zNDihziE95Uz7qDrlFgXmYxjysc+tNlXOK+JAEZA4oXoSsHwSs0woY iMKS6oZEc2U7LeTHmOSdqQmPUXl8rj56umhOWBTBIz5kg4iCMInEG7mm200h6uP+wHVE EyoHIrJVQb0bpfXHewyDCCTW7Vg7zaVjIbfYlRdzjF4Jh85tbLbRcIA8W2AjpNaCH1NO Q4bmQirxqbEc3gj7I35vOZZhD66dVd1rbJ6CTR3ohmExq7q4JMNYm8oD/z/wxT+LiVK3 BJEtZZ3invJ15M5Ti4S7COHw1Xw7oC6BfZGXiy8jXElLSkwCruASx4XlpcX31sfi4nsf IUZA== MIME-Version: 1.0 X-Received: by 10.50.60.100 with SMTP id g4mr28743121igr.41.1443119381974; Thu, 24 Sep 2015 11:29:41 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.107.140.12 with HTTP; Thu, 24 Sep 2015 11:29:41 -0700 (PDT) In-Reply-To: References: <201509131800.t8DI03cc026651@irp-lnx1.cisco.com> Date: Thu, 24 Sep 2015 11:29:41 -0700 X-Google-Sender-Auth: NzZnUNmnq6oQRfeXlNGsCRljmtE Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 18:29:44 -0000 At Tue, 22 Sep 2015 16:18:32 +0900, Lorenzo Colitti wrote: > > Am I now understanding the intent more accurately? > > I think you're only focusing on part of the picture - operators that assign > a limited number of addresses per device out of a desire to obtain more > revenue. I was aware there are other cases and the draft discusses those, but you're probably right that I focused on this particular issue too much. I guess that's because I thought the counter argument against this practice didn't seem very persuading to me (and I thought it wouldn't for those operators) compared with that for other issues. Yet the issue looked quite major to me, so I thought if we can't resolve this case then improvements on other issues won't help much to prevent wider deployment NAT66. > To respond to your earlier concern that we shouldn't recommend DHCPv6 PD > because of the implementation and operational cost, then I would note that: I don't think this is what I tried to say. This concern was in the context of my primary focus on the "per-device revenue" case rather than a general concern about recommending DHCPv6 PD in terms of cost. My point was just that if we can somehow convince those operators (and the operators don't have other reasons to use stateful address management), then other approaches than DHCPv6 PD to provide multiple global addresses would be more preferable as they are less costly. To be clear, I'm basically not opposed to anything described in the draft. Although some of the arguments against particular operational practices seemed weak to me, it's just a subjective impression, and I understand operators will do whatever they want anyway, however strong counter arguments are. In this discussion I just tried to understand what this draft really tries to achieve with what assumptions and which specific recommendations. Based on the discussion in this thread, these seem to be pretty clear for some people, so it may be only me, but these were not really very clear for me. That's why I raised these points. So, hopefully now understanding the points more clearly, if I may suggest something for the draft in the context of WGLC, it would have been clearer for me if the draft was organized this way: 1. describe why we want multiple addresses 2. describe cases that don't allow it and why such practices are employed: - per device/address charge - host tracking - scaling issues And explain why we (authors) think these are not effective or are even harmful. Also clarify that it's beyond the scope of this draft to full convince those operators (and in fact it will be impossible since operators will do whatever they want anyway). 3. recommendations - don't do filtering based on the number of L2/L3 addresses per link if tracking/scaling is not an issue - if tracking/scaling is a concern, use DHCPv6-PD for each host - if tracking/scaling is not a concern, just advertising /64 via RA may be enough, but applications such as VM should use a bridge mode instead of NAT66 The current version of the draft is good about point #1 (described in Section 3). I can see point #2 is also covered with a very careful read (except the "clarification"), but it wasn't clear to me before this thread, since the information is scattered in multiple sections (per device charge is described in Section 4 as part of "why harmful" discussion, tracking issues are in Section 9 after the recommendations section, etc). Regarding the "clarification", it would have helped me understand the draft better since I originally thought convincing those operators is one major goal of this document. Point #3 is currently Section 8. It wasn't very clear to me in terms of the bullets listed above. Perhaps it would be better if it explains in which case each specific recommendation should be used more clearly. I think it would also help if it mentioned the need for using a "VM bridge mode" (or something similar to it). On a related note, I found the first sentence of Section 8 particularly unclear to me: In order to avoid the problems described above, and preserve the in that what are "the problem" isn't clear. That's probably because the related information is scattered, so if the draft is reorganized it might be resolved automatically; or it may be better to explain "the problem" more specifically. -- JINMEI, Tatuya From nobody Thu Sep 24 13:34:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9601B2B99 for ; Thu, 24 Sep 2015 13:34:03 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p5yCFyb1McZ for ; Thu, 24 Sep 2015 13:34:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AF31B2B9A for ; Thu, 24 Sep 2015 13:34:01 -0700 (PDT) Received: from [10.123.87.199] (usc-secure-wireless-207-199.usc.edu [68.181.207.199]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t8OKXapw017205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 24 Sep 2015 13:33:46 -0700 (PDT) To: Mikael Abrahamsson , Lorenzo Colitti References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> From: Joe Touch Message-ID: <56045E1F.1050306@isi.edu> Date: Thu, 24 Sep 2015 13:33:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2015 20:34:03 -0000 On 9/23/2015 10:58 PM, Mikael Abrahamsson wrote: > On Thu, 24 Sep 2015, Lorenzo Colitti wrote: > >> On Thu, Sep 24, 2015 at 1:42 PM, Mikael Abrahamsson >> wrote: >>> >>> I brought this up on the IETF TCP lists a few years back, that there >>> should be some kind of analysis of this. For instance, if I know that an >>> interface will always give me a new IP address, I would like to >>> configure >>> my connection manager to kill all TCP sessions that terminate on IP >>> addresses on that interface. It's not going to be a transient error, >>> because if that interface goes down, those IP addresses are gone >>> forever. >> >> That's certainly what Android does. >> >> https://android.googlesource.com/platform/system/netd/+/master/server/NetlinkHandler.cpp#80 >> > > I got shot down pretty well when I suggested this, good that someone > agrees with me anyway. They kept suggesting that I should use TCP > keepalives instead, but over for instance mobile, that would be really > bad for battery life. There are two separate issues: 1) shutting down an app that isn't making progress 2) cleaning up TCP state #1 can be done at the app layer; some apps don't do much if the connection is dead, whereas others do. that's for the app to decide. #2 isn't needed unless the OS needs to reclaim memory consumed with idle TCP states; more often, that TCP state is cleaned up when a new connection starts that uses the same socket pair. TCP keepalives are a way for an app to force a TCP connection to either stay up or die when a path might go down. They can be important when the path might go down even though the local network interface remains up. E.g., your WIFI works fine but your cable modem dropped the connection to your service provider. There's no panacea, though - the decision on whether to try to keep an app up or let it fail when a path dies depends on the app. Joe From nobody Thu Sep 24 22:14:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBE41B300D for ; Thu, 24 Sep 2015 22:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoQ1EBQqbLfg for ; Thu, 24 Sep 2015 22:14:37 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A481B300A for ; Thu, 24 Sep 2015 22:14:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2F038A2; Fri, 25 Sep 2015 07:14:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443158075; bh=1T6eNReRXwviOHfLhodzbDZwPeKcNIFf64BMovWXoO0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZNoySGMHfLhHOS92RcJJTDpgPrYlGgIDijV8sE9LaH6mp0MKwOxHO/bsQqzCJyyrr ZKgtTejd5C3SksxvZYn4cjdKxtVz4heYTbrMbVDs3+k5cZeeuZ4iM8CD9fhGUUnYap Gvyk3uG+EaMMbX7LWeKByl3VhxTDLghzkoLnKEbE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 26F80A1; Fri, 25 Sep 2015 07:14:35 +0200 (CEST) Date: Fri, 25 Sep 2015 07:14:35 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <56045E1F.1050306@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 05:14:39 -0000 On Thu, 24 Sep 2015, Joe Touch wrote: > #2 isn't needed unless the OS needs to reclaim memory consumed with idle > TCP states; more often, that TCP state is cleaned up when a new > connection starts that uses the same socket pair. I don't understand your reasoning here. What is the use to keep any TCP connection that is anchored at an IP address that we know won't come back? (and yes we know, because the connection manager has been told this by policy) > There's no panacea, though - the decision on whether to try to keep an > app up or let it fail when a path dies depends on the app. We're not talking about a path here, we're talking about an interface IP address that went away and won't come back. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 24 22:37:13 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1A1B35E0 for ; Thu, 24 Sep 2015 22:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzUrc9T9zLSX for ; Thu, 24 Sep 2015 22:37:12 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002: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 3F8E41B3580 for ; Thu, 24 Sep 2015 22:37:12 -0700 (PDT) Received: by ykdg206 with SMTP id g206so104209560ykd.1 for ; Thu, 24 Sep 2015 22:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ATDqT1Jz3xzGPgwoE8BQfXS2/g+pwp1fPIb0QecpGA8=; b=GOMbPBNKp/Rf64paA5hWDDyg8oXK0nVMHmxgAhUP/f6TiFznzFN4OgYbvU61KuSivL XxE++6C4SQOsfPfb67UbzRkx96M2FIS6jSul/fhjxL/dJedlgLB0MN16RD6v+ui3FXT3 y0s4/D/PGmUn4Z+gKKqj8QVfepFXFr8sg/iYhouTKK0c0ZZKRIvcozSBEHHHrEKT3JW3 Ws5wcirBM9mGfuTrflw3YaOp4QrlbCaWtd/FlNVObhVBBeYoxZcx/5iXAxbQBQqc3QtX vjQcnudNGUPVtTP0icVAuTwnJ9fzeQgK1ux51Gqe8bd3Z1RV+rFULEFEub7qDhgTnhsI /ymg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ATDqT1Jz3xzGPgwoE8BQfXS2/g+pwp1fPIb0QecpGA8=; b=CcQplpKA0AQlMnfOmpxx6e7Ta4c9/yjmdFxGvH612xl2lPUXUcB/tUP3xj9JC9DPjK LpTGE386mmGDUSleRYWPvJhuiPLcPQLGunRFSSx44PaafT80ydoGP5pH3AgH8+DMTk2Y ornF8LH2MgF56YXfVjp2yxw0+cYIq8O/eXJ0asgHc8UAJyVxQLcgkJg7F3YoNItJhZu5 R/E/69I31g+hDskCLT3Oym7j9ADSUShjKq5tNGNaTKDTBYZKUpVTOKtAI4oOjUgxGtLB 0mGs817bwfVfZ7kl/cXQl8e2PTuxkex8t0jl+bCCGfcI06IYfHKwgMbA6dFzq/Vn5x8G TD+A== X-Gm-Message-State: ALoCoQl1KIebpKqU2paHFhXgPaC5fIj4fHw9lAeuHtNvQKn/XROdlsV7Oq6ompAnHk1rYaMpLg2p X-Received: by 10.170.187.72 with SMTP id d69mr3098924yke.25.1443159431530; Thu, 24 Sep 2015 22:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Thu, 24 Sep 2015 22:36:51 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> From: Lorenzo Colitti Date: Fri, 25 Sep 2015 14:36:51 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a1142248e45c24f05208bbda8 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 05:37:13 -0000 --001a1142248e45c24f05208bbda8 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 25, 2015 at 2:14 PM, Mikael Abrahamsson wrote: > There's no panacea, though - the decision on whether to try to keep an app >> up or let it fail when a path dies depends on the app. >> > > We're not talking about a path here, we're talking about an interface IP > address that went away and won't come back. I think the point is that you don't know whether it will come back without the ability to predict the future. For example, if you lose link on a wifi network but then 30 seconds later roam into coverage again, you may be able to reuse the same addresses you had before. --001a1142248e45c24f05208bbda8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 25, 2015 at 2:14 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
There's no panacea, though - the decision on whether to try to= keep an app up or let it fail when a path dies depends on the app.

 We're not talking about a path here, we're talking about an interfa= ce IP address that went away and won't come back.

=
I think the point is that you don't know whether it will com= e back without the ability to predict the future. For example, if you lose = link on a wifi network but then 30 seconds later roam into coverage again, = you may be able to reuse the same addresses you had before.
--001a1142248e45c24f05208bbda8-- From nobody Thu Sep 24 23:38:05 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127E71B3167 for ; Thu, 24 Sep 2015 23:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLZDc5lhLedw for ; Thu, 24 Sep 2015 23:38:02 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AF81B3165 for ; Thu, 24 Sep 2015 23:38:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C3024A1; Fri, 25 Sep 2015 08:37:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443163079; bh=RY5N7M4ovyc9F1JgOXvxMQfApG55SD/9BethIq++FFU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1nWthFmpepq4m8BzAyqBYbj6gJwqw7CmckqAIdDLgRxmG6DeQzOiEdJ+iMSsfoTgB M78E0/yekH9VKaRzSnSh+Yo4kBBi2syS4rTjn/lwnh3Dh1wL1gPdfCTd+hZ+l1GatJ m2Fqo7jdLJk31kLSlxp4FkoMB9xXyuNEEDyPVL6I= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BC2E69F; Fri, 25 Sep 2015 08:37:59 +0200 (CEST) Date: Fri, 25 Sep 2015 08:37:59 +0200 (CEST) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 06:38:04 -0000 On Fri, 25 Sep 2015, Lorenzo Colitti wrote: >> We're not talking about a path here, we're talking about an interface IP >> address that went away and won't come back. > > I think the point is that you don't know whether it will come back without > the ability to predict the future. For example, if you lose link on a wifi > network but then 30 seconds later roam into coverage again, you may be able > to reuse the same addresses you had before. For some interfaces this is true, for some it's not. If I *know* with 99.999% certainty (because the DHCP pool is pretty large in my mobile operator) that when the PDP context goes down, when it's brought up again, I will not get the same address again, why on earth wouldn't I just immediately invalidate all TCP connections anchored at that address, when the mobile interface goes down? So my point here is that yes, if you're looking at a solution that needs to work for everything, then the prudent path is the classic path, just let it stay until someone decides it shouldn't, and let's have hours of timeouts. But for some interfaces, this just isn't true anymore, so why don't we use that information and give the users a better experience? Also, punting this to the application developers without giving them a general framework to work with is just not realistic... and the POSIX socket interface hasn't seen any development for 10+ years as far as I can tell, not in any significant manner that can even get close to what Apple and Google are offering their respective application developers. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 24 23:40:35 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE901B3183 for ; Thu, 24 Sep 2015 23:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4rWtGkaDgxL for ; Thu, 24 Sep 2015 23:40:33 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002: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 F17751B3180 for ; Thu, 24 Sep 2015 23:40:32 -0700 (PDT) Received: by ykdg206 with SMTP id g206so105137643ykd.1 for ; Thu, 24 Sep 2015 23:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R1QR8SG2kCrbX7gp5tzsMl9dJSPVuWLe36MJxVRxonY=; b=MIgm7Ip7Cli0rGW9eXIsdDHDcFYg3CV5vXOONvS8eOfWqQCIXzJLFDg/6oQCw4/lvj ytQuhg9sS0sXw0VC2Rw1tLJH+AU4V/9BEZsaATtl2KfYrkPCUc57hyD6ZOvhHYOtJnP8 IG78ctmWgs8AxkqHOJj79gpWI6rX84mJn/RET++JeMpGmGb3im/wsXDWKU7TK3k9i+M+ W6+YGEvjlm96VbJu+YVO/bGVLjD4IJDj1bOcyKPGTg531n4QAQM45RkOVUNecuPdllNK D1T3ArP6k7sdDUB+d76d7PThYLPQCkjYeDVhiA/KEf7wlneh5ux36h6TIHTRh6+wmdd+ wFEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R1QR8SG2kCrbX7gp5tzsMl9dJSPVuWLe36MJxVRxonY=; b=MMRrQavI0hAzUmpzWUYgcoyA4ItdC+s6UQ2LxWanqinU4n8Qq8Q0REo26YTxApOUlx IVv936qf57zg5Toj/QyPZ9Zx3sEbnnqcDiJQUKyocaK44Zl4UbbVCmJcjUy+uVaOt0xi /8Nqvgv4P8r3EL0Bl5ylEzFgvKBQa6/7Mvnakt4p+WZoLPu7YKFLs0crlzxshhodgveU 0grVIhdQ6oP14+CY02uH1yhWQMlgCfjCHzqhFXOBtSlAlqvSms7h+2kxiX0HUglsofa/ G2FGv2bfSFwvGA9hK4fcb3wKWtloMjYO48yu67/2Dufwxtty0izzLrK+KTlpXxQC5WW1 AwLg== X-Gm-Message-State: ALoCoQkYXMA/DcDq4pXmvYiI8A4vM7Xlh/Jj0JwKrcQeoI8x/rd1MUqFpCIVO3oZXGqSBDXnhV9X X-Received: by 10.170.64.7 with SMTP id g7mr3387626ykg.80.1443163232203; Thu, 24 Sep 2015 23:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Thu, 24 Sep 2015 23:40:12 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> From: Lorenzo Colitti Date: Fri, 25 Sep 2015 15:40:12 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a1134f92ecf7b7505208c9f82 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 06:40:34 -0000 --001a1134f92ecf7b7505208c9f82 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 25, 2015 at 3:37 PM, Mikael Abrahamsson wrote: > So my point here is that yes, if you're looking at a solution that needs > to work for everything, then the prudent path is the classic path, just let > it stay until someone decides it shouldn't, and let's have hours of > timeouts. > To be clear: I'm not saying that TCP sockets should stay alive when their IP address goes away. I think that's a bad plan, because it causes apps to get stuck. Particular in mobile networks, I don't know if any popular OSes do it. --001a1134f92ecf7b7505208c9f82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 25, 2015 at 3:37 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
So my point here is that yes= , if you're looking at a solution that needs to work for everything, th= en the prudent path is the classic path, just let it stay until someone dec= ides it shouldn't, and let's have hours of timeouts.

To be clear: I'm not saying that TCP sockets shou= ld stay alive when their IP address goes away. I think that's a bad pla= n, because it causes apps to get stuck. Particular in mobile networks, I do= n't know if any popular OSes do it.
--001a1134f92ecf7b7505208c9f82-- From nobody Fri Sep 25 10:26:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AB61ACE18 for ; Fri, 25 Sep 2015 10:26:19 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlC4wKXQqMQY for ; Fri, 25 Sep 2015 10:26:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75241ACE1A for ; Fri, 25 Sep 2015 10:26:17 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8PHPt5F007317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Sep 2015 10:25:56 -0700 (PDT) To: Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> From: Joe Touch Message-ID: <560583A2.7030405@isi.edu> Date: Fri, 25 Sep 2015 10:25:54 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:26:19 -0000 On 9/24/2015 10:14 PM, Mikael Abrahamsson wrote: > On Thu, 24 Sep 2015, Joe Touch wrote: > >> #2 isn't needed unless the OS needs to reclaim memory consumed with >> idle TCP states; more often, that TCP state is cleaned up when a new >> connection starts that uses the same socket pair. > > I don't understand your reasoning here. > > What is the use to keep any TCP connection that is anchored at an IP > address that we know won't come back? (and yes we know, because the > connection manager has been told this by policy) I'm talking about the TCP protocol spec, which does not *require* a mechanism to take down the state of an idle connection unless keepalives are used. The TCP spec is based on the principle that old connections are taken down only when new events occur - e.g., the next time you want to send a packet and it fails because the interface is down. >> There's no panacea, though - the decision on whether to try to keep an >> app up or let it fail when a path dies depends on the app. > > We're not talking about a path here, we're talking about an interface IP > address that went away and won't come back. You can't possibly know that. If you want to declare "if it's gone more than 4 minutes then it's not coming back", then you really want a keepalive with a 4-minute timeout. Joe From nobody Fri Sep 25 10:29:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41451ACE1C for ; Fri, 25 Sep 2015 10:29:19 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dNuCx_KiG1X for ; Fri, 25 Sep 2015 10:29:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667D31ACE12 for ; Fri, 25 Sep 2015 10:29:18 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8PHSsJL007815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Sep 2015 10:28:55 -0700 (PDT) To: Mikael Abrahamsson , Lorenzo Colitti References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> From: Joe Touch Message-ID: <56058455.20905@isi.edu> Date: Fri, 25 Sep 2015 10:28:53 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:29:19 -0000 On 9/24/2015 11:37 PM, Mikael Abrahamsson wrote: ... > If I *know* with 99.999% certainty (because the DHCP pool is pretty > large in my mobile operator) that when the PDP context goes down, when > it's brought up again, I will not get the same address again, why on > earth wouldn't I just immediately invalidate all TCP connections > anchored at that address, when the mobile interface goes down? You can, as an implementer, make that decision. The TCP spec does not *require* you to do so, nor should it. The only time TCP requires that state be taken down for a dead connection is when the connection is known dead by a failed attempt to send a new message. > So my point here is that yes, if you're looking at a solution that needs > to work for everything, then the prudent path is the classic path, just > let it stay until someone decides it shouldn't, and let's have hours of > timeouts. > > But for some interfaces, this just isn't true anymore, so why don't we > use that information and give the users a better experience? > > Also, punting this to the application developers without giving them a > general framework to work with is just not realistic... and the POSIX > socket interface hasn't seen any development for 10+ years as far as I > can tell, not in any significant manner that can even get close to what > Apple and Google are offering their respective application developers. If you want an implementation to take down connections when the interface disappears, that's fine. It should not be part of a spec. And yes, I think the specification of an abstract API *is* part of a spec (e.g., RFC793 does specify one). Joe From nobody Fri Sep 25 10:34:33 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B318D1A6FB7 for ; Fri, 25 Sep 2015 10:34:32 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bo0KDOZjjuq for ; Fri, 25 Sep 2015 10:34:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9A41A6FB9 for ; Fri, 25 Sep 2015 10:34:31 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8PHY5A8008471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Sep 2015 10:34:05 -0700 (PDT) To: Lorenzo Colitti , Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <5605858B.7070401@isi.edu> Date: Fri, 25 Sep 2015 10:34:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:34:32 -0000 On 9/24/2015 11:40 PM, Lorenzo Colitti wrote: > On Fri, Sep 25, 2015 at 3:37 PM, Mikael Abrahamsson > wrote: > > So my point here is that yes, if you're looking at a solution that > needs to work for everything, then the prudent path is the classic > path, just let it stay until someone decides it shouldn't, and let's > have hours of timeouts. > > To be clear: I'm not saying that TCP sockets should stay alive when > their IP address goes away. This goes to the key point: an OS socket is an OS issue TCP uses the term "socket" to refer to the IP address/port pair, i.e., a connection is defined by a socket pair. TCP sockets might be mapped to OS sockets (e.g., using the Unix bind() call), but they don't have a direct correlation. *TCP* sockets don't go up or down; they're just a pair of values. Interfaces go up or down, sockets are created or destroyed, etc. The impact of those events on TCP is not specified by TCP. TCP connection state persists during idle - there's no inherent mechanism in TCP to "clean up" -- it always waits until a new packet needs to go out to decide what to do. When the packet fails to transmit, only then does TCP decide to clean up state. The same is true for when an OS socket disappears - *TCP* does not dictate that the TCP state disappear at the same time. An *implementation* can do otherwise for many reasons, e.g., to reclaim valuable memory or to force a connection down by edict. Joe From nobody Fri Sep 25 10:46:52 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEE41A00EA for ; Fri, 25 Sep 2015 10:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQW_Q0eF9iK0 for ; Fri, 25 Sep 2015 10:46:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92711A00B9 for ; Fri, 25 Sep 2015 10:46:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id ADDCAA1; Fri, 25 Sep 2015 19:46:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443203205; bh=9W9IjH4n+/ejikoEE6Kd7laaAATxg9nJZFNf3PwBZgc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=fuEwkSIh5lRT/TfRxjnaDKu+KIJpaU70eLuo0n7JKmtPTkMx3INLF48XZFkOUjWRt jpqae3PjBT88pnsGoeRdNA1eseFoX9LsgnqqdoVpQVAZwfMewvuKtW3iGt4RqSLJ26 qraZQY9k6fWwFT0xSIvrAuMd1PhU2KnXNkYZC9RE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A38919F; Fri, 25 Sep 2015 19:46:45 +0200 (CEST) Date: Fri, 25 Sep 2015 19:46:45 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <56058455.20905@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:46:51 -0000 On Fri, 25 Sep 2015, Joe Touch wrote: > You can, as an implementer, make that decision. > > The TCP spec does not *require* you to do so, nor should it. The only > time TCP requires that state be taken down for a dead connection is when > the connection is known dead by a failed attempt to send a new message. So here we again have the problem that most of the IETF protocol groups do not have an "*ops" group that actually deals with real world interaction. v6ops seems to be one of the few. Why don't we have more of them? Where is the "TCP ops" WG that could actually take real world scenarios and give guidance to implementors? > It should not be part of a spec. And yes, I think the specification of > an abstract API *is* part of a spec (e.g., RFC793 does specify one). So this is the problem, protocol spec meets real world. Where do I discuss this in the IETF? Obviously not in the TCP working groups, because there are only people who deal in abstracts and theory there, not practical implementation issues. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Sep 25 10:53:00 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BA11A0011 for ; Fri, 25 Sep 2015 10:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p2btk0dBVhw for ; Fri, 25 Sep 2015 10:52:55 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002: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 2520F1A0108 for ; Fri, 25 Sep 2015 10:49:12 -0700 (PDT) Received: by ykdg206 with SMTP id g206so120337068ykd.1 for ; Fri, 25 Sep 2015 10:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YiuAuliYO7YboAc4bIxFmsAISRa5k35e5RguPtN1g6E=; b=RD2V1vDGy1MqPiI+/Yf1cDxyVIXVZUVS0NrZHUzwDg1mHog78INCRWAp9zz5XHM4vb sKXDGYKWhmr00NciFWbDbJRoWjhvcjPjbdan9P5vWnmTXps7njOz11C02+rWxrlLF5UM v07skQe5F5F13Y8pslW5J48c5VOS1dfmsSXbE0lA7WjWdfStHy3h9NjcS9WOkCIi8TOu 48ToRibwyW9maT3FULzbFkcBDKkaCSi0DsRCMItTk9302ZvWZerscAb0d/q0vvwfsNCh 4j3Q3IGIEWl6bMJE1hfnQFMPNxCGo/MH9ZjwVQ33S8YydHcRA93rN4+fCjlrX8Oc1VQf D1RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YiuAuliYO7YboAc4bIxFmsAISRa5k35e5RguPtN1g6E=; b=hmLW3dbANVjmmRAULx+Bl864gRC6FoCdmTZ79hgFJ4b1bBWWgkJRYmDVYX4Au+c848 1CL3CtuYxrvGVx1mex94WAAZo7s7T2gboJ5iAmBTV64DbN3KlrpqQ9E2tA/cXIr25Cq3 UXjslDtQl1dNZ+JqU1xkqy3/oU5T3uLnd7cUWdMP+YQkBNh5QIPLWDAC7l8qvoAg2o0X 3u63Hmy0V2UHxPDE/3VspBPRB9EvLEnOD0TLKLqUfvv3DgL6LiYY1MdGqPQCInWeXxhS UApdplNAcfPLkv8wjTFC3SuCj/2VMFU9Ty8PVYOiAFc5YrNwMSshci0hXZR59LQQTgbB Mk1A== X-Gm-Message-State: ALoCoQnprBYY8KbPcSJoc9q5fnxpnQcPpsN/RXCuZmd6Em+T+WVlHweJdrY8LNLPh4A7O+Cydh1R X-Received: by 10.170.190.133 with SMTP id h127mr5893508yke.115.1443203351296; Fri, 25 Sep 2015 10:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Fri, 25 Sep 2015 10:48:51 -0700 (PDT) In-Reply-To: <5605858B.7070401@isi.edu> References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <5605858B.7070401@isi.edu> From: Lorenzo Colitti Date: Sat, 26 Sep 2015 02:48:51 +0900 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a113a1302180669052095f738 Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 17:52:56 -0000 --001a113a1302180669052095f738 Content-Type: text/plain; charset=UTF-8 On Sat, Sep 26, 2015 at 2:34 AM, Joe Touch wrote: > An *implementation* can do otherwise for many reasons, e.g., to reclaim > valuable memory or to force a connection down by edict. > ... or to avoid apps staying blocked in read calls for tens of seconds, or even minutes, on connections that are extremely unlikely to ever become usable again. --001a113a1302180669052095f738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Sep 26, 2015 at 2:34 AM, Joe Touch <touch@isi.edu> wrote:
An *implementation* can do otherwise for ma= ny reasons, e.g., to reclaim
valuable memory or to force a connection down by edict.

... or to avoid apps staying blocked in read calls for ten= s of seconds, or even minutes, on connections that are extremely unlikely t= o ever become usable again.
--001a113a1302180669052095f738-- From nobody Fri Sep 25 11:29:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720651A6F63 for ; Fri, 25 Sep 2015 11:29:32 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isv--xewohjJ for ; Fri, 25 Sep 2015 11:29:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D4F1A6F53 for ; Fri, 25 Sep 2015 11:29:31 -0700 (PDT) Received: from [128.9.184.118] ([128.9.184.118]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8PISeN7017567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Sep 2015 11:28:41 -0700 (PDT) To: Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> From: Joe Touch Message-ID: <56059257.2050305@isi.edu> Date: Fri, 25 Sep 2015 11:28:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 18:29:32 -0000 On 9/25/2015 10:46 AM, Mikael Abrahamsson wrote: > On Fri, 25 Sep 2015, Joe Touch wrote: > >> You can, as an implementer, make that decision. >> >> The TCP spec does not *require* you to do so, nor should it. The only >> time TCP requires that state be taken down for a dead connection is when >> the connection is known dead by a failed attempt to send a new message. > > So here we again have the problem that most of the IETF protocol groups > do not have an "*ops" group that actually deals with real world > interaction. v6ops seems to be one of the few. Why don't we have more of > them? > > Where is the "TCP ops" WG that could actually take real world scenarios > and give guidance to implementors? Well, I might blame the IETF for so heavily discounting the need to document abstract APIs for so many years. That appears to be getting better, esp. with things like the TAPS WG. >> It should not be part of a spec. And yes, I think the specification of >> an abstract API *is* part of a spec (e.g., RFC793 does specify one). > > So this is the problem, protocol spec meets real world. Where do I > discuss this in the IETF? Obviously not in the TCP working groups, > because there are only people who deal in abstracts and theory there, > not practical implementation issues. Actually, they would help deal with both, or at least would be a place to start. There are many RFCs from TCPM, TSVWG, etc. that have dealt with implementation issues - they tend to be documented as BCPs. Joe From nobody Fri Sep 25 11:35:28 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCE71A6FFB for ; Fri, 25 Sep 2015 11:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrpkhsGJm58P for ; Fri, 25 Sep 2015 11:35:25 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (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 E07E21A700A for ; Fri, 25 Sep 2015 11:35:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t8PIZRwl026347; Fri, 25 Sep 2015 11:35:27 -0700 Received: from XCH-PHX-212.sw.nos.boeing.com (xch-phx-212.sw.nos.boeing.com [130.247.25.141]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t8PIZPt2026343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 25 Sep 2015 11:35:25 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-212.sw.nos.boeing.com ([169.254.12.56]) with mapi id 14.03.0235.001; Fri, 25 Sep 2015 11:35:22 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Joe Touch Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ97pwecS+NCAn7EaALDKKzLdmeJ5Nj0vQ Date: Fri, 25 Sep 2015 18:35:22 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F0E2CE@XCH-BLV-504.nw.nos.boeing.com> References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <5605858B.7070401@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 18:35:27 -0000 SGksIGdpdmluZyBlbmQgdXNlciBkZXZpY2VzIGEgLzY0IChvciBzaG9ydGVyKSB1c2luZyBESENQ djYgUEQgaGFzIGJlZW4gc3BlY2lmaWVkDQpieSBBRVJPIGZvciBhIGxvbmcgdGltZSBub3cuIFRo ZXJlIGlzIG5vdyBhbHNvIHJ1bm5pbmcgY29kZSB0aGF0IGRvZXMgdGhpczoNCg0KaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pbnQtYXJlYS80UHFwNk5ZWklrQlluNXhaSUxO N2tRUXFESFUNCg0KT25jZSB0aGUgZW5kIHVzZXIgZGV2aWNlIGdldHMgdGhlIC82NCwgaXQgY2Fu IGNvbmZpZ3VyZSBhcyBtYW55IGFkZHJlc3NlcyBhcyBpdA0KbGlrZXMgYW5kIGFzc2lnbiB0aGVt IHRvIGEgaG9zdCBpbnRlcmZhY2Ugc28gdGhhdCBJUCBmb3J3YXJkaW5nIG5lZWQgbm90IGV2ZW4g YmUNCmVuYWJsZWQgYmVjYXVzZSBESENQdjYgUEQgb2NjdXJzIG92ZXIgdGhlIEFFUk8gaW50ZXJm YWNlIGFuZCBub3QgdGhlIGhvc3QNCmludGVyZmFjZS4NCg0KVGhlIEFFUk8gaW1wbGVtZW50YXRp b24gd29ya3MgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgZXhjZWxsZW50IGtlYSBESENQdjYNCnNl cnZlciBmcm9tIElTQy4gS2VhIG5vdyBzdXBwb3J0cyBhbGwgb2YgdGhlIHN0YW5kYXJkIERIQ1B2 NiBtZWNoYW5pc21zDQpuZWVkZWQgYnkgQUVSTyBhbmQgdGhlIGtlYSB0ZWFtIGhhcyBiZWVuIHZl cnkgcmVzcG9uc2l2ZSB0byBpbmNvcnBvcmF0aW5nDQpuZXcgZmVhdHVyZXMuDQoNClRoYW5rcyAt IEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0K From nobody Fri Sep 25 11:51:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74D1A8793 for ; Fri, 25 Sep 2015 11:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhasYMFjZ7WJ for ; Fri, 25 Sep 2015 11:51:54 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEB91A878A for ; Fri, 25 Sep 2015 11:51:54 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so31077923wic.0 for ; Fri, 25 Sep 2015 11:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OTtv7oub0MOMvXMtmNrwRl2qHV+R1JJnCDxRT9NxeBQ=; b=nI1OFTDjTdWo5jowTL5Mw2+OmiFGMIDOC/KS19DJy1yZCVnDZHqMtCjUcOtia2KdtB alB6gvL/dqGuVEwW8ITmuwmoeWdd16oqoA2oxD/16Dw6PQoVR+j1OJ5K05LBJQWil0Ok xTpiDhQS0Fu+EEz506BBYyYPAzJkHBxGnPqhjB7aRBaRrTqvN8sK43xXpvVsily0ykIL 8vxZ1uRfSntoWW4FbwcfgqO2PqYZta6PbTbkljVainBaM2zZ66tPv29Qm0EPFzJUt9e4 YJus/2ObyUQ1lunr0raZ/XAn9E8r5MtKY9fs0zURE5Qp9M9boZGrO9rPinFl1BYLGvu0 3LgA== MIME-Version: 1.0 X-Received: by 10.180.39.175 with SMTP id q15mr5222171wik.73.1443207112553; Fri, 25 Sep 2015 11:51:52 -0700 (PDT) Received: by 10.194.192.40 with HTTP; Fri, 25 Sep 2015 11:51:52 -0700 (PDT) In-Reply-To: <20150924105208.Horde.tvHlz77J3rCb3C6dqtYpmBl@mail.drown.org> References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6113AA15C83@GAALPA1MSGUSRBF.ITServices.sbc.com> <20150924105208.Horde.tvHlz77J3rCb3C6dqtYpmBl@mail.drown.org> Date: Fri, 25 Sep 2015 11:51:52 -0700 Message-ID: From: Ca By To: Dan Drown Content-Type: multipart/alternative; boundary=001a11c2283a47f920052096d753 Archived-At: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 18:51:56 -0000 --001a11c2283a47f920052096d753 Content-Type: text/plain; charset=UTF-8 On Thursday, September 24, 2015, Dan Drown wrote: > Quoting Lorenzo Colitti : > : > >> As someone who has worked on the ePDG implementation on Android devices, I >> can assure you that the architecture that's used to ensure that the >> baseband processor and the application processor could share an IP address >> is pretty contorted - you might even say nightmarish. >> > : > >> NAT66 is not something that hosts inside enterprise networks need to >>> be worried about. >>> >>> >> Why? I know lots of users of my enterprise network that run VMs, run >> Android / iOS emulators on their development machines, use ePDG services, >> etc. With only one /128 per host, you can'd to that without NAT66. >> > > Because I didn't know what ePDG was before this, I had to look it up. > Below is my summary of it, anyone who understands it better, please feel > free to correct it. > > ePDG is a secure tunnel back to your cell phone operator, and wifi calling > is one application that can run over it. It runs on the baseband processor > rather than the application processor of the phone. There are two > different operating systems running on these processors, and they need to > share connectivity to the outside world. With v4, I assume this is achived > with NAT44 when connected to a wifi AP. > > Wifi calling is an application that's on millions of phones already. I > don't know if ePDG is a popular implementation or if there are any > competing implementations. > > Yes, ePDG is common implementation CB > With v6, the design of assigning a dedicated v6 address (from a prefix or > a pool) to the baseband processor would make sense for this application, as > it makes the phone's internal network easier to understand. The > alternatives would be to do NAT66 on the application processor or not have > v6 on the baseband processor at all. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11c2283a47f920052096d753 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thursday, September 24, 2015, Dan Drown <dan-v6ops@drown.org> wrote:
Quoting Lorenzo Colitti <lorenzo@google.com>: :
As someone who has worked on the ePDG implementation on Android devices, I<= br> can assure you that the architecture that's used to ensure that the
baseband processor and the application processor could share an IP address<= br> is pretty contorted - you might even say nightmarish.
:
<bhs> NAT66 is not something that hosts inside enterprise networks ne= ed to
be worried about.


Why? I know lots of users of my enterprise network that run VMs, run
Android / iOS emulators on their development machines, use ePDG services, etc. With only one /128 per host, you can'd to that without NAT66.

Because I didn't know what ePDG was before this, I had to look it up.= =C2=A0 Below is my summary of it, anyone who understands it better, please = feel free to correct it.

ePDG is a secure tunnel back to your cell phone operator, and wifi calling = is one application that can run over it.=C2=A0 It runs on the baseband proc= essor rather than the application processor of the phone.=C2=A0 There are t= wo different operating systems running on these processors, and they need t= o share connectivity to the outside world.=C2=A0 With v4, I assume this is = achived with NAT44 when connected to a wifi AP.

Wifi calling is an application that's on millions of phones already.=C2= =A0 I don't know if ePDG is a popular implementation or if there are an= y competing implementations.


Yes, ePDG is common implementation=C2= =A0

CB=C2=A0
With v6, the design of assigning a dedicated v6 address (from a prefix or a= pool) to the baseband processor would make sense for this application, as = it makes the phone's internal network easier to understand.=C2=A0 The a= lternatives would be to do NAT66 on the application processor or not have v= 6 on the baseband processor at all.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
--001a11c2283a47f920052096d753-- From nobody Fri Sep 25 14:19:16 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456F31A8763 for ; Fri, 25 Sep 2015 14:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWiRc94CZr9h for ; Fri, 25 Sep 2015 14:19:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCB81A872C for ; Fri, 25 Sep 2015 14:19:15 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t8PLIgA0013884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 25 Sep 2015 14:18:43 -0700 (PDT) To: Lorenzo Colitti References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <5605858B.7070401@isi.edu> From: Joe Touch Message-ID: <5605BA32.1060602@isi.edu> Date: Fri, 25 Sep 2015 14:18:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 21:19:16 -0000 On 9/25/2015 10:48 AM, Lorenzo Colitti wrote: > On Sat, Sep 26, 2015 at 2:34 AM, Joe Touch > wrote: > > An *implementation* can do otherwise for many reasons, e.g., to reclaim > valuable memory or to force a connection down by edict. > > > ... or to avoid apps staying blocked in read calls for tens of seconds, > or even minutes, on connections that are extremely unlikely to ever > become usable again. IMO, that's a failure of the app writer to account for such failures - yes, it's fine for the OS implementer to decide they want to help out such apps, but again that's not the responsibility of the TCP spec to mandate. Joe From nobody Fri Sep 25 20:38:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3391AD0A9 for ; Fri, 25 Sep 2015 20:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ug4Yn040GG-8 for ; Fri, 25 Sep 2015 20:38:00 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002: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 138EB1AD0A8 for ; Fri, 25 Sep 2015 20:37:59 -0700 (PDT) Received: by ykdt18 with SMTP id t18so132298063ykd.3 for ; Fri, 25 Sep 2015 20:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yrR20uGb7z9w48jZ6Kp4bLBAh2JOTP374mMhoZqeTV0=; b=Jz4/jF/zaEgAJ4FVyMyi9hMtFQrFtPK7Xk0LxLUVOIpMlIg1rYShk+fRSvvJMYJgFc l8m9Kl+Lj+RxTHUON9/rTP16UJ3P7x8MxCqWwogqe6+AU7XPZKmvBc3+rnbLUZUfPfhT cs8oeEsSXAne1sADoSQvUgmZB0XoZYUnG/Q0HkHds1fQ83UogtjMT9CqSHbzFnEwHaO4 roP9n4AikB8fqPKlA18r4TsM0cISNj0oElbHX630EsJRB3td30BQ4iEt11vujwchCzPo eCCKTkiiEzEtKEjnfT9MnqX7u4108XBji3w9wUfKCfRnAYe+90aiAjMx7QiTGpc/Di2A jQ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yrR20uGb7z9w48jZ6Kp4bLBAh2JOTP374mMhoZqeTV0=; b=OijZvH+O/ib1XINAP1aEdrqYQFZMesRFSBH7RFHK4EZS+rDaa2drGe/gZOmV2bNwk+ on/ByUgCgfGIwMDFR71qYPhL+mjFVzKI0qdE6LQY9OSDUO542MwLZY7py1E7etT7uFn6 aJktYzVwXI8spv2AJXEVdm5Mghlq8ZxdzJ2RELPF0tfUDYgGGK1TUxds7qRIsPSULWJx /4xOLERfP0o2C3nfHhjmD5k+9YGAholv1+0IAQJy7S65Q0/OTJTEfYCkuSoEehxq7dzx jrhjbZ11XL5dsIEbGscY7xiOQG7uLBvqWGFAy4keJFfm+3GQiULLouycAiIVNl87bS7t 8nQA== X-Gm-Message-State: ALoCoQkQrgoO/2d7BahhLUDZLzOg7QpDSMYQxIqIc9XI+5m8CeyAzN9dAnFmmNKm1caPOGOY4G57 X-Received: by 10.13.254.3 with SMTP id o3mr7614813ywf.161.1443238679242; Fri, 25 Sep 2015 20:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Fri, 25 Sep 2015 20:37:39 -0700 (PDT) In-Reply-To: <5605BA32.1060602@isi.edu> References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <5605858B.7070401@isi.edu> <5605BA32.1060602@isi.edu> From: Lorenzo Colitti Date: Sat, 26 Sep 2015 12:37:39 +0900 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=94eb2c054c90cdd10505209e30ad Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 03:38:01 -0000 --94eb2c054c90cdd10505209e30ad Content-Type: text/plain; charset=UTF-8 On Sat, Sep 26, 2015 at 6:18 AM, Joe Touch wrote: > > ... or to avoid apps staying blocked in read calls for tens of seconds, > > or even minutes, on connections that are extremely unlikely to ever > > become usable again. > > IMO, that's a failure of the app writer to account for such failures - > yes, it's fine for the OS implementer to decide they want to help out > such apps, but again that's not the responsibility of the TCP spec to > mandate. > But how would apps do this, though? They can listen to IP address changes themselves, but that's a fair bit of code, and the code will be different for different platforms. They can send more frequent keepalives, but that increases data usage and battery usage, and even then, their connections can still stall for a keepalive interval. And even if the apps do address the problem, they're in exactly the same boat as the OS. They can't predict the future, so the only real option is to close the connection. --94eb2c054c90cdd10505209e30ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Sep 26, 2015 at 6:18 AM, Joe Touch <touch@isi.edu> wrote:
> ... or to avoid apps = staying blocked in read calls for tens of seconds,
> or even minutes, on connections that are extremely unlikely to ever > become usable again.

IMO, that's a failure of the app writer to account for such fail= ures -
yes, it's fine for the OS implementer to decide they want to help out such apps, but again that's not the responsibility of the TCP spec to mandate.

But how would apps do this, th= ough? They can listen to IP address changes themselves, but that's a fa= ir bit of code, and the code will be different for different platforms. The= y can send more frequent keepalives, but that increases data usage and batt= ery usage, and even then, their connections can still stall for a keepalive= interval.

And even if the apps do address the pro= blem, they're in exactly the same boat as the OS. They can't predic= t the future, so the only real option is to close the connection.
--94eb2c054c90cdd10505209e30ad-- From nobody Fri Sep 25 21:06:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFE71AD218 for ; Fri, 25 Sep 2015 21:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsmey2yPOxQO for ; Fri, 25 Sep 2015 21:06:27 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BEF1AD23D for ; Fri, 25 Sep 2015 21:06:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3B4D5A1; Sat, 26 Sep 2015 06:06:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443240384; bh=Mkn0B3KxsjmfLdWqnh+Q+O2jHLjwJbMPEXAWwH7z79o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=e1Kfn5ZmcxhaOQ5TlMOqU+/S8q/a5bz0CjyjDuBuak1u22ZboV1xczKZoQe02q/dN cpaeOpfxf6ne07/7kW3vLVxtOzo5IhDg9E7pRFRtskCY3ErrjlBJvy8OJz2+CBqUdr 0RdUeeBpDLlgpByoWrgTteJZIekRatrkHEVl0q7c= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2FEEA9F; Sat, 26 Sep 2015 06:06:24 +0200 (CEST) Date: Sat, 26 Sep 2015 06:06:24 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <56059257.2050305@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 04:06:28 -0000 On Fri, 25 Sep 2015, Joe Touch wrote: > Actually, they would help deal with both, or at least would be a place > to start. There are many RFCs from TCPM, TSVWG, etc. that have dealt > with implementation issues - they tend to be documented as BCPs. Well, they gave me the same answer you did, so I don't see them as operational. They just said "this is up to the application, there is no need to change anything" and also said "use TCP keepalives" which means they obviously have no idea about power usage on wireless devices. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Sep 25 21:22:12 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A061E1AD353 for ; Fri, 25 Sep 2015 21:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1kuQqCOgu9T for ; Fri, 25 Sep 2015 21:22:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E553F1AD352 for ; Fri, 25 Sep 2015 21:22:08 -0700 (PDT) Received: from [192.168.1.4] (pool-71-103-146-160.lsanca.dsl-w.verizon.net [71.103.146.160]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t8Q4Lm4I008602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Sep 2015 21:21:59 -0700 (PDT) References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <5605858B.7070401@isi.edu> <5605BA32.1060602@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-BED86D3C-736D-4174-8AB1-82ADAB836D06 Message-Id: <16727D86-8EEF-4FA0-9970-75594552DF45@isi.edu> X-Mailer: iPad Mail (13A344) From: Joe Touch Date: Fri, 25 Sep 2015 21:21:47 -0700 To: Lorenzo Colitti X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 04:22:10 -0000 --Apple-Mail-BED86D3C-736D-4174-8AB1-82ADAB836D06 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Sep 25, 2015, at 8:37 PM, Lorenzo Colitti wrote: >=20 >> On Sat, Sep 26, 2015 at 6:18 AM, Joe Touch wrote: >> > ... or to avoid apps staying blocked in read calls for tens of seconds,= >> > or even minutes, on connections that are extremely unlikely to ever >> > become usable again. >>=20 >> IMO, that's a failure of the app writer to account for such failures - >> yes, it's fine for the OS implementer to decide they want to help out >> such apps, but again that's not the responsibility of the TCP spec to >> mandate. >=20 > But how would apps do this, though? They can listen to IP address changes t= hemselves, but that's a fair bit of code, and the code will be different for= different platforms. They can send more frequent keepalives, but that incre= ases data usage and battery usage, and even then, their connections can stil= l stall for a keepalive interval. Non blocking I/O. Sleep mode between polling intervals or wake-on-packet. T= he point is that TCP doesn't need a keep alive unless you care about being i= dle. As long as you're ok with being idle, it doesn't t need to cost much.=20= > And even if the apps do address the problem, they're in exactly the same b= oat as the OS. They can't predict the future, so the only real option is to c= lose the connection. Yup. If the cost of keeping the app is too high and nothing is going on, it= 's always an option to do this.. Again, none of this is in TCPs court - all of these decisions can be ol=C3=A9= enter in various places and there is no single "best" answer. It depends o= n the app. Joe= --Apple-Mail-BED86D3C-736D-4174-8AB1-82ADAB836D06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sep 2= 5, 2015, at 8:37 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

=
= On Sat, Sep 26, 2015 at 6:18 AM, Joe Touch <touch@isi.edu> wrote:<= br>
> ... or to avoid apps s= taying blocked in read calls for tens of seconds,
> or even minutes, on connections that are extremely unlikely to ever
= > become usable again.

IMO, that's a failure of the app writer to account for such failures -=
yes, it's fine for the OS implementer to decide they want to help out
such apps, but again that's not the responsibility of the TCP spec to
mandate.

But how would apps do this, tho= ugh? They can listen to IP address changes themselves, but that's a fair bit= of code, and the code will be different for different platforms. They can s= end more frequent keepalives, but that increases data usage and battery usag= e, and even then, their connections can still stall for a keepalive interval= .

Non blocking= I/O.  Sleep mode between polling intervals or wake-on-packet.  Th= e point is that TCP doesn't need a keep alive unless you care about being id= le.  As long as you're ok with being idle, it doesn't t need to cost mu= ch. 

And even if the apps do ad= dress the problem, they're in exactly the same boat as the OS. They can't pr= edict the future, so the only real option is to close the connection.
<= /div>

Yup.  If the cost of keeping the app is too= high and nothing is going on, it's always an option to do this..
=
Again, none of this is in TCPs court - all of these decisions= can be ol=C3=A9 enter in various places and there is no single "best" answe= r.  It depends on the app.

Joe
= --Apple-Mail-BED86D3C-736D-4174-8AB1-82ADAB836D06-- From nobody Fri Sep 25 21:29:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CB61AD35D for ; Fri, 25 Sep 2015 21:29:09 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5NdjOFg2F_b for ; Fri, 25 Sep 2015 21:29:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE691AD35C for ; Fri, 25 Sep 2015 21:29:08 -0700 (PDT) Received: from [192.168.1.4] (pool-71-103-146-160.lsanca.dsl-w.verizon.net [71.103.146.160]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t8Q4Sprk009749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Sep 2015 21:29:02 -0700 (PDT) References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56000864.2080600@gmail.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> X-Mailer: iPad Mail (13A344) From: Joe Touch Date: Fri, 25 Sep 2015 21:28:51 -0700 To: Mikael Abrahamsson X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 04:29:09 -0000 > On Sep 25, 2015, at 9:06 PM, Mikael Abrahamsson wrote: >=20 >> On Fri, 25 Sep 2015, Joe Touch wrote: >>=20 >> Actually, they would help deal with both, or at least would be a place to= start. There are many RFCs from TCPM, TSVWG, etc. that have dealt with impl= ementation issues - they tend to be documented as BCPs. >=20 > Well, they gave me the same answer you did, so I don't see them as operati= onal. They just said "this is up to the application, there is no need to cha= nge anything" In TCP... > and also said "use TCP keepalives" which means they obviously have no idea= about power usage on wireless devices. Keepalives are needed only if you care if the app is idle. If you do, it's t= he only way to KNOW things are down. Why do you care? It depends on the app whether and why you do. =20 The TSV explored interface signals several times - trigtran was one - and c= oncluded there were too many cases where they won't work to be useful.. The f= act that one interface is down for a time is almost never useful information= unless the app must make progression its communication. Idle app + down in= terface is rarely a useful event to act on - routing being the primary count= erexample. That's where keepalives come in and why. Joe From nobody Fri Sep 25 21:48:14 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC891AD49F for ; Fri, 25 Sep 2015 21:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2KQkCOEnO00 for ; Fri, 25 Sep 2015 21:48:11 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624651AD49B for ; Fri, 25 Sep 2015 21:48:11 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 34560A1; Sat, 26 Sep 2015 06:48:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443242889; bh=ZZwzzVwjS36j00wB04rOWQ9Ea1lkN6IU046DEtO0Rvw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=itN819TWPhb65si0zbewbBhmka+kUK2YhhGCkryu30fXSq6dnL9LiRikjUrxyAQfA rfdy3G9uC+FMy7PKnTPNDDjYmpltFn+Ii8P2UsIReLbetQybj/8rFuFri/GjOSgMqk oo0X392Y69kcPNwz599uVtbU3NEu3IvTsP/SyMBs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 26FFC9F; Sat, 26 Sep 2015 06:48:09 +0200 (CEST) Date: Sat, 26 Sep 2015 06:48:09 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 04:48:12 -0000 On Fri, 25 Sep 2015, Joe Touch wrote: > In TCP... TCP doesn't live in a vacuum with nothing around it. > Keepalives are needed only if you care if the app is idle. If you do, it's the only way to KNOW things are down. No, it's not. If your only world is TCP it might be the only way, but that's not the world we live in. In the real world there are IP addresses that are bound to interfaces that go down, so that TCP could be told that the IP address used isn't valid anymore. > Why do you care? It depends on the app whether and why you do. Because right now we have a substandard user experience because this isn't being handled. > The TSV explored interface signals several times - trigtran was one - > and concluded there were too many cases where they won't work to be > useful.. The fact that one interface is down for a time is almost never > useful information unless the app must make progression its > communication. Idle app + down interface is rarely a useful event to > act on - routing being the primary counterexample. That's where > keepalives come in and why. Ok, let me give you a concrete example: Let's say I run ssh. I have a terminal window. I have a 3GPP USB dongle. I have ssh terminal session up to a server. 3GPP dongle interface goes down. Now, I know for a fact that when it comes up again, it'll have a different IP address. So this TCP session that TCP is running over is just useless. Why do I have to go to a different terminal window to kill the ssh process, because it's now stuck waiting for input (even if I press enter in the session it won't die, even after the 3GPP dongle interface comes back up again). This process is just stuck for at least minutes or hours. And no, I don't want to run keepalives because that takes a lot of battery. I can't understand why you seriously seem to believe that the best solution here is for the individual application developers to insert a lot of code in each application to handle this, when it would instead fix all applications to do it in the operating system or connection manager. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Sep 25 23:29:10 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B041B2AE6 for ; Fri, 25 Sep 2015 23:29:08 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1gxCxgIyDeX for ; Fri, 25 Sep 2015 23:29:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06F81B2AE2 for ; Fri, 25 Sep 2015 23:29:06 -0700 (PDT) Received: from [192.168.1.4] (pool-71-103-146-160.lsanca.dsl-w.verizon.net [71.103.146.160]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8Q6SiwQ012860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Sep 2015 23:28:46 -0700 (PDT) References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> X-Mailer: iPad Mail (13A344) From: Joe Touch Date: Fri, 25 Sep 2015 23:28:44 -0700 To: Mikael Abrahamsson X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 06:29:08 -0000 > On Sep 25, 2015, at 9:48 PM, Mikael Abrahamsson wrote: >=20 >> On Fri, 25 Sep 2015, Joe Touch wrote: >>=20 >> In TCP... >=20 > TCP doesn't live in a vacuum with nothing around it. >=20 >> Keepalives are needed only if you care if the app is idle. If you do, it'= s the only way to KNOW things are down. >=20 > No, it's not. If your only world is TCP it might be the only way, but that= 's not the world we live in. In the real world there are IP addresses that a= re bound to interfaces that go down, so that TCP could be told that the IP a= ddress used isn't valid anymore. There is nothing stopping you from implementing this. It's only that there i= s *nothing*in TCP that requires this either. >> Why do you care? It depends on the app whether and why you do. >=20 > Because right now we have a substandard user experience because this isn't= being handled. If you handle this outside the app without the app asking for this feature, t= hen you could break an app that will work fine elsewhere. Again, that's you= r call. >> The TSV explored interface signals several times - trigtran was one - and= concluded there were too many cases where they won't work to be useful.. Th= e fact that one interface is down for a time is almost never useful informat= ion unless the app must make progression its communication. Idle app + down= interface is rarely a useful event to act on - routing being the primary co= unterexample. That's where keepalives come in and why. >=20 > Ok, let me give you a concrete example: >=20 > Let's say I run ssh. I have a terminal window. I have a 3GPP USB dongle. I= have ssh terminal session up to a server. 3GPP dongle interface goes down. >=20 > Now, I know for a fact that when it comes up again, it'll have a different= IP address. If that's a strict requirement of 3GPP then maybe. But if you hav a tunnel t= hat runs over that interface maybe not. > So this TCP session that TCP is running over is just useless. It is dormant. > Why do I have to go to a different terminal window to kill the ssh process= , because it's now stuck waiting for input (even if I press enter in the ses= sion it won't die, even after the 3GPP dongle interface comes back up again)= . This process is just stuck for at least minutes or hours. That is because our ssh client used blocking reads. Otherwise it would wait= - when you type something, it would shut down *then*. Shutting down when yo= u try to send over the down interface is what I would expect from TCP. > And no, I don't want to run keepalives because that takes a lot of battery= . >=20 > I can't understand why you seriously seem to believe that the best solutio= n here is for the individual application developers to insert a lot of code i= n each application to handle this, when it would instead fix all application= s to do it in the operating system or connection manager. Non blocking reads are hardly a lot of code. Having the OS always drop the socket is making a decision for all apps, incl= uding those that would be just as happy waiting if the connection come back u= p. Joe From nobody Sat Sep 26 10:46:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEA61A1A06 for ; Sat, 26 Sep 2015 10:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.039 X-Spam-Level: * X-Spam-Status: No, score=1.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHqOi9SFmNvs for ; Sat, 26 Sep 2015 10:46:05 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CC71A1A03 for ; Sat, 26 Sep 2015 10:46:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0A8AEA1; Sat, 26 Sep 2015 19:46:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443289563; bh=XS2J3z+KaDc4KaOgiDtifF5yZvb/kGev0O4USRzQToY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sJLwxNPxQ1XkaEN1elpMBGctLAQL35N5ZEJY6lVaXcC2HIUzZ4ZcG8ernu1ma1mri uR1YV4HrpYeIbdu7vXhAuLR3sNYWfMFH7NKubroPENYXe85+7pN3KYTbPr6M4/zRt3 zObL0qeCIEDEWTImzo8CiDkKbc+zIClP6LERv2kY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F3A0B9F; Sat, 26 Sep 2015 19:46:02 +0200 (CEST) Date: Sat, 26 Sep 2015 19:46:02 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 17:46:07 -0000 On Fri, 25 Sep 2015, Joe Touch wrote: >> Now, I know for a fact that when it comes up again, it'll have a different IP address. > > If that's a strict requirement of 3GPP then maybe. But if you hav a tunnel that runs over that interface maybe not. That doesn't make any sense what so ever. The /32 IPv4 address and the /64 IPv4 prefix is gone, I won't get it again. What tunnel? If you have some kind of tunnel interface that has dynamic over different IPv4/IPv6 addresses, then that tunnel interface doesn't go down as the 3GPP prefix/address changes, then that's got nothing to do with what I just wrote. >> So this TCP session that TCP is running over is just useless. > > It is dormant. In my example it's bound to the 3GPP WAN interface address that just went away. It's not coming back. I know this. > That is because our ssh client used blocking reads. Otherwise it would > wait - when you type something, it would shut down *then*. Shutting down > when you try to send over the down interface is what I would expect from > TCP. That doesn't work with any operating system I know of. Linux, Windows, OSX, none of them work like that. > Having the OS always drop the socket is making a decision for all apps, > including those that would be just as happy waiting if the connection > come back up. I never said "always". I said this applied to *some* interfaces. Policy. I know for a fact the connection IP address will never return. Never. So the TCP connection bound to that address is useless. It will never come back to life. This is a dead parrot. Dead. It's not sleeping, it's DEAD! Gone. Forever. No coming back. Forever. Useless. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Sep 26 16:27:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEE81A8999 for ; Sat, 26 Sep 2015 16:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.202 X-Spam-Level: ** X-Spam-Status: No, score=2.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXfxu6LKWEer for ; Sat, 26 Sep 2015 16:27:37 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 5DF701A8997 for ; Sat, 26 Sep 2015 16:27:36 -0700 (PDT) Received: by vkhf67 with SMTP id f67so74005733vkh.1 for ; Sat, 26 Sep 2015 16:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mh6fUjAMtzCIKKfNFfPa3yNztpvrv7NlfUIeVSvBecc=; b=ItQPsScmaomCqjnHkjzIFlCBYllIwOOrNr6pjAgX5VdFbCJ8v8cwEeqb5iH6HDI/eB as5uJbb8EQ/FdWDRZEhulQuaxp+Co5KIW9Ll6thxOqJT9NFAs/moXu/0wwsJq/ZKeFOz W1PqhBgt6S50tyhS/gNmlRG1PMKU5kZdIr4QwHPqy/rsuYFQGYvCngEbcEyIm2SNj8yM l8ayoyMqY8KB8F76kFcejpokXCK34Yw54jZP90DXsTha3Bb7WTwS9mjZUNFiGAGzjlNc 0TsA14aXZR4Yf3QCxdrpvIwSRTJAxs6ge2G/fEdpz79iYcUglhKmRw2sMufP5thb7kzc yMIA== MIME-Version: 1.0 X-Received: by 10.31.49.67 with SMTP id x64mr8185839vkx.133.1443310055473; Sat, 26 Sep 2015 16:27:35 -0700 (PDT) Received: by 10.103.77.16 with HTTP; Sat, 26 Sep 2015 16:27:35 -0700 (PDT) Received: by 10.103.77.16 with HTTP; Sat, 26 Sep 2015 16:27:35 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> Date: Sun, 27 Sep 2015 09:27:35 +1000 Message-ID: From: Mark Smith To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001a1143fc9228492e0520aecfda Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 23:27:39 -0000 --001a1143fc9228492e0520aecfda Content-Type: text/plain; charset=UTF-8 On 27 Sep 2015 03:46, "Mikael Abrahamsson" wrote: > > On Fri, 25 Sep 2015, Joe Touch wrote: > >>> Now, I know for a fact that when it comes up again, it'll have a different IP address. >> >> >> If that's a strict requirement of 3GPP then maybe. But if you hav a tunnel that runs over that interface maybe not. > > > That doesn't make any sense what so ever. The /32 IPv4 address and the /64 IPv4 prefix is gone, I won't get it again. I'm curious how you know you won't get it back again? I'd that something inherent in the 3GPP spec's? If have thought it would be a network operator policy decision (and I've also seen it be a vendor default on a BRAS if it is choosing addresses to hand out). What tunnel? If you have some kind of tunnel interface that has dynamic over different IPv4/IPv6 addresses, then that tunnel interface doesn't go down as the 3GPP prefix/address changes, then that's got nothing to do with what I just wrote. > > >>> So this TCP session that TCP is running over is just useless. >> >> >> It is dormant. > > > In my example it's bound to the 3GPP WAN interface address that just went away. It's not coming back. I know this. > > >> That is because our ssh client used blocking reads. Otherwise it would wait - when you type something, it would shut down *then*. Shutting down when you try to send over the down interface is what I would expect from TCP. > > > That doesn't work with any operating system I know of. Linux, Windows, OSX, none of them work like that. > > >> Having the OS always drop the socket is making a decision for all apps, including those that would be just as happy waiting if the connection come back up. > > > I never said "always". I said this applied to *some* interfaces. Policy. I know for a fact the connection IP address will never return. Never. So the TCP connection bound to that address is useless. It will never come back to life. This is a dead parrot. Dead. It's not sleeping, it's DEAD! Gone. Forever. No coming back. Forever. Useless. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a1143fc9228492e0520aecfda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 27 Sep 2015 03:46, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Fri, 25 Sep 2015, Joe Touch wrote:
>
>>> Now, I know for a fact that when it comes up again, it'll = have a different IP address.
>>
>>
>> If that's a strict requirement of 3GPP then maybe.=C2=A0 But i= f you hav a tunnel that runs over that interface maybe not.
>
>
> That doesn't make any sense what so ever. The /32 IPv4 address and= the /64 IPv4 prefix is gone, I won't get it again.

I'm curious how you know you won't get it back again= ? I'd that something inherent in the 3GPP spec's? If have thought i= t would be a network operator policy decision (and I've also seen it be= a vendor default on a BRAS if it is choosing addresses to hand out).

What tunnel? If you have some kind of tunnel interface that = has dynamic over different IPv4/IPv6 addresses, then that tunnel interface = doesn't go down as the 3GPP prefix/address changes, then that's got= nothing to do with what I just wrote.
>
>
>>> So this TCP session that TCP is running over is just useless.<= br> >>
>>
>> It is dormant.
>
>
> In my example it's bound to the 3GPP WAN interface address that ju= st went away. It's not coming back. I know this.
>
>
>> That is because our ssh client used blocking reads.=C2=A0 Otherwis= e it would wait - when you type something, it would shut down *then*. Shutt= ing down when you try to send over the down interface is what I would expec= t from TCP.
>
>
> That doesn't work with any operating system I know of. Linux, Wind= ows, OSX, none of them work like that.
>
>
>> Having the OS always drop the socket is making a decision for all = apps, including those that would be just as happy waiting if the connection= come back up.
>
>
> I never said "always". I said this applied to *some* interfa= ces. Policy. I know for a fact the connection IP address will never return.= Never. So the TCP connection bound to that address is useless. It will nev= er come back to life. This is a dead parrot. Dead. It's not sleeping, i= t's DEAD! Gone. Forever. No coming back. Forever. Useless.
>
>
> --
> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001a1143fc9228492e0520aecfda-- From nobody Sat Sep 26 22:31:53 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC6A1A90A3 for ; Sat, 26 Sep 2015 22:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4lhmSj9mClA for ; Sat, 26 Sep 2015 22:31:50 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16231A90A1 for ; Sat, 26 Sep 2015 22:31:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 76F4EA1; Sun, 27 Sep 2015 07:31:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443331906; bh=23opguESLuwKA3zVdNoPJ9mfiCoh8c5Fky/v71PIIo4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CUIrjxRlAra/hQOYDJ2QRpe7wt+BMFEMteTVZecvCdtyhomRZtaWAxGFi2lAn3bn9 ndbD/9Gdein4OG2+73zwUD54fFCAKS4vSCtHAR2RgXlpaS2kv8x+BkG+iWmp1IWDyF 3W5Z9MJ7AkYPlxjtuC6VGUL61vXUNYdykNWCc08U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6C2579F; Sun, 27 Sep 2015 07:31:46 +0200 (CEST) Date: Sun, 27 Sep 2015 07:31:46 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith In-Reply-To: Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 05:31:52 -0000 On Sun, 27 Sep 2015, Mark Smith wrote: > I'm curious how you know you won't get it back again? I'd that something > inherent in the 3GPP spec's? If have thought it would be a network > operator policy decision (and I've also seen it be a vendor default on a > BRAS if it is choosing addresses to hand out). Empirical evidence. No, it's not inherent in 3GPP, but I have yet to run into a mobile operator that will give you back your IP address next time you connect. But again, I am talking on per-operator policy here on the phone. Policy I, as end user, set. So if I use an operator that actually gives me the same address again, I can change that policy setting. With mobile phones, this could be included in the "carrier settings" that configures a lot of other aspects of the mobile interface on the phone. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Sep 26 23:20:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389871A90F0 for ; Sat, 26 Sep 2015 23:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB-56rI1mVEo for ; Sat, 26 Sep 2015 23:20:33 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05BA1A90EE for ; Sat, 26 Sep 2015 23:20:32 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so63493999wic.1 for ; Sat, 26 Sep 2015 23:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:cc:content-type; bh=umLqSghe7vhz5A10PVy4CDblo+q4O11bynbaklRzs7c=; b=MfUjm4drh5Rme9mfX41252CKkj443HDf1HqOrVmZhSPC4nmDv8fpDjjQnzUnpJ7wnW SdSK/YOjHNRt33oCukOXN/z2wKWDTbHiJcxCo8oD1e7VwdjkTVCYTq3GcIN+WXiPvoxX mIG2HTPIcV0jby45mZYXWnzACLJI+luvIhTM5MMdi7RUixsO1492cvhAU9AbtgO0V82L e1V76a73qE2I5xqbP8eXlXEAtYxC3r6hhm5QO9/D4fShYFVm34cLUhm9ussPaOal22W/ F8qoPeR1LPDidbnqDRVuvC5/8IFvObdgqQBISVkPWY2GvMM0r3my8/9UIqnVpiJ25cKU gRZA== MIME-Version: 1.0 X-Received: by 10.180.103.199 with SMTP id fy7mr11368637wib.85.1443334831538; Sat, 26 Sep 2015 23:20:31 -0700 (PDT) Sender: mpetach@gmail.com Received: by 10.27.179.209 with HTTP; Sat, 26 Sep 2015 23:20:31 -0700 (PDT) In-Reply-To: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> Date: Sat, 26 Sep 2015 23:20:31 -0700 X-Google-Sender-Auth: Mcyxz3MwMbcUAA24IBQ1Kr4bZgs Message-ID: From: Matthew Petach Cc: v6ops list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 06:20:34 -0000 On Sat, Sep 26, 2015 at 10:31 PM, Mikael Abrahamsson wrote: > On Sun, 27 Sep 2015, Mark Smith wrote: > >> I'm curious how you know you won't get it back again? I'd that something >> inherent in the 3GPP spec's? If have thought it would be a network operator >> policy decision (and I've also seen it be a vendor default on a BRAS if it >> is choosing addresses to hand out). > > > Empirical evidence. No, it's not inherent in 3GPP, but I have yet to run > into a mobile operator that will give you back your IP address next time you > connect. But again, I am talking on per-operator policy here on the phone. > Policy I, as end user, set. So if I use an operator that actually gives me > the same address again, I can change that policy setting. > > With mobile phones, this could be included in the "carrier settings" that > configures a lot of other aspects of the mobile interface on the phone. If this is something that varies from network to network, it hardly seems like it would be proper to define behaviours in any type of RFC or internet draft for lower-layer protocols. At best, it sounds like having a socket option for fast_teardown in the OS domain *might* be applicable, so the OS can decide to drop the socket binding immediately on any interface transition; but that's not a TCP-level issue, really, at least not as far as I can tell from this point of view. Matt From nobody Sun Sep 27 08:13:19 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044FA1B2A61 for ; Sun, 27 Sep 2015 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR0cxbd_80Ra for ; Sun, 27 Sep 2015 08:13:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BBE1B2A60 for ; Sun, 27 Sep 2015 08:13:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 10CF3A1; Sun, 27 Sep 2015 17:13:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443366793; bh=z8TwwRclI9emqHpYehGYU3c+trFYb013ZTfH1nV6+TM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Env6p55Q8Um03mlgpYRbHLSwyMn1sUhtDSADIadIZtlMGLhgp9BjeRtPkraoqpCQO tP3rlf7kwtja4aE1qkFCXpsTnxfa8Oqww8txLQ7QKmdGzpQK+pMVIDTHCpeMPiGwoA cfjnZxa3BfalEf6xAzMFWF6y7TYARpgig9fZXFyY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 05AF69F; Sun, 27 Sep 2015 17:13:13 +0200 (CEST) Date: Sun, 27 Sep 2015 17:13:12 +0200 (CEST) From: Mikael Abrahamsson To: Matthew Petach In-Reply-To: Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 15:13:18 -0000 On Sat, 26 Sep 2015, Matthew Petach wrote: > If this is something that varies from network to network, it hardly > seems like it would be proper to define behaviours in any type of RFC or > internet draft for lower-layer protocols. At best, it sounds like > having a socket option for fast_teardown in the OS domain *might* be > applicable, so the OS can decide to drop the socket binding immediately > on any interface transition; but that's not a TCP-level issue, really, > at least not as far as I can tell from this point of view. So if it's not TCP related, where should this kind of discussion be had in the IETF? Also, why do you think that a socket option is applicable? If the OS knows that this TCP session is anchored at an IP address that will never become available again, what's the use in keeping this TCP session around? Why only do this for applications that set this fast_teardown option? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Sep 27 10:50:56 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4D1A0181 for ; Sun, 27 Sep 2015 10:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_pkenrtcH6M for ; Sun, 27 Sep 2015 10:50:54 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753551A017F for ; Sun, 27 Sep 2015 10:50:54 -0700 (PDT) Received: from [192.168.1.156] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t8RHobcG022165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2015 10:50:38 -0700 (PDT) To: Mikael Abrahamsson , Mark Smith References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> From: Joe Touch Message-ID: <56082C6B.3000507@isi.edu> Date: Sun, 27 Sep 2015 10:50:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t8RHobcG022165 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 17:50:55 -0000 On 9/26/2015 10:31 PM, Mikael Abrahamsson wrote: > On Sun, 27 Sep 2015, Mark Smith wrote: > >> I'm curious how you know you won't get it back again? I'd that >> something inherent in the 3GPP spec's? If have thought it would be a >> network operator policy decision (and I've also seen it be a vendor >> default on a BRAS if it is choosing addresses to hand out). > > Empirical evidence. No, it's not inherent in 3GPP, but I have yet to run > into a mobile operator that will give you back your IP address next time > you connect. The key issue is that: 1) you really don't KNOW you won't get the same IP address when you reconnect that interface 2) IP addresses aren't defined solely by interface; from the Internet specification view, if you brought up a different interface you *could* get that IP address again What you appear to want is a link between the network interface and the OS socket such that when the link goes down the socket disconnects or fails. That's strictly an OS issue. >From TCP's viewpoint, the OS socket is where the TCP address/port pair attaches to a process; until the process goes away or the TCP connection is torn down, there's no reason to strictly disconnect the two. On the network side, TCP is bound to an IP address and port, *NOT* to an interface. As to your question of where this sort of thing might be discussed/developed as a mechanism, there are several OS development venues (e.g., Usenix for Unix variants) that might be useful to explore. But, as we've noted, this is neither a deficiency nor an opportunity (IMO) for Internet standards modification. Joe From nobody Sun Sep 27 11:00:30 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890B61A002F for ; Sun, 27 Sep 2015 11:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIRS4QNYYuT2 for ; Sun, 27 Sep 2015 11:00:27 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549D71A002A for ; Sun, 27 Sep 2015 11:00:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D3E13A1; Sun, 27 Sep 2015 20:00:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443376824; bh=wN4myOoY+VMftH2gOz2nppzd+Zv8IMoBFeupcXzpbU8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DuaZGVXRZMrGpLOoGrsPiuR1vHSkOAl96JENAbGgWV1ie9U7Mw/7Uk6zbQUJPXs2E 2yb7kA0FPxVmb6q7RNSmuZgpS5I9zIlSpXtkNJ7e9zww3EBIg0eJTKSKXsZqRIUK0R Zw7kW8cSD/4r2BGmoyOSL2t101d97yJMs7hCmfpY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CE7109F; Sun, 27 Sep 2015 20:00:24 +0200 (CEST) Date: Sun, 27 Sep 2015 20:00:24 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <56082C6B.3000507@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 18:00:29 -0000 On Sun, 27 Sep 2015, Joe Touch wrote: > 1) you really don't KNOW you won't get the same IP address when you > reconnect that interface So let's say my provider uses 100.64.0.0/10 generally, and they now use /14 out of that per GGSN as a pool, and they implement a 5 minute "quarantine" before re-use of existing address. The odds of me getting my IPv4 address back is miniscule. So with this knowledge in mind, I pretty much KNOW that when the PDP context goes down, that IP address I had is no longer of any use and I might as well kill all sockets associated with that IP address. > What you appear to want is a link between the network interface and the > OS socket such that when the link goes down the socket disconnects or > fails. That's strictly an OS issue. So where should this be discussed in the IETF? Or is your view that this isn't worth discussing? Or it's just not worth discussing in the IETF? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Sep 27 11:13:26 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43111A012D for ; Sun, 27 Sep 2015 11:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeOYH7SVo8be for ; Sun, 27 Sep 2015 11:13:23 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B541A0120 for ; Sun, 27 Sep 2015 11:13:23 -0700 (PDT) Received: from [192.168.1.156] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t8RICrwB024602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2015 11:12:55 -0700 (PDT) To: Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <560831A4.10601@isi.edu> Date: Sun, 27 Sep 2015 11:12:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t8RICrwB024602 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 18:13:25 -0000 On 9/27/2015 11:00 AM, Mikael Abrahamsson wrote: > On Sun, 27 Sep 2015, Joe Touch wrote: > >> 1) you really don't KNOW you won't get the same IP address when you >> reconnect that interface > > So let's say my provider uses 100.64.0.0/10 generally, and they now use > /14 out of that per GGSN as a pool, and they implement a 5 minute > "quarantine" before re-use of existing address. The odds of me getting > my IPv4 address back is miniscule. So with this knowledge in mind, I > pretty much KNOW that when the PDP context goes down, that IP address I > had is no longer of any use and I might as well kill all sockets > associated with that IP address. That's an internal OS decision. >> What you appear to want is a link between the network interface and >> the OS socket such that when the link goes down the socket disconnects >> or fails. That's strictly an OS issue. > > So where should this be discussed in the IETF? Or is your view that this > isn't worth discussing? Or it's just not worth discussing in the IETF? My view is that it's out of scope for the IETF. What you're proposing is that: a) an IP address is strictly bound to a particular interface that runs counter to RFC1122; it's OK for you to make that assumption in an implementation based on a particular interface and ISP, but it's not something that would be appropriate to generalize IMO b) when an interface goes down, an OS socket should go down with it that's an OS issue; there's nothing to specify here that has to do with IP or TCP c) TCP connections should go down anytime an address becomes unavailable due to an interface change TCP is actually designed to do the opposite; to stay up until a message fails to go out, not to come down as soon as that possibility can't happen The last one is a biggie, IMO - it's based on the Postel Principle (be liberal in what you accept, be conservative in what you do). In this context, it would mean: don't assume a failure when you can assume a interruption that doesn't impact you yet There have been protocols or applications that do care about such interruptions - which is exactly why TCP has a keepalive mechanism (which sends nothing if you're already sending, but tests to see if a message could go out if not). But that's from TCP's viewpoint -- you don't want TCP to do anything, which is why this isn't an IETF issue. What you want is the *OS* to do something - specifically, when the interface goes down (not a protocol event), you want the OS socket to go down too (not a protocol event either). That's exactly why this is an OS issue, not a TCP, IP, or IETF one, IMO. Joe From nobody Sun Sep 27 12:16:20 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B41B2CF9 for ; Sun, 27 Sep 2015 12:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiSknIKwEuPA for ; Sun, 27 Sep 2015 12:16:16 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B6A1B2CF6 for ; Sun, 27 Sep 2015 12:16:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8DEEDA1; Sun, 27 Sep 2015 21:16:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443381373; bh=NL5xJNigrS6uIShVOY+/StolpY2FYCV+m0Uh/KyX3Lw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ihmNO82r1p7ho4iEL3xHAXoekAbH7iFRiPc3HX5FXvzAFTiQu1tCtn/ajyklx4SKd I+T83aRlJfxO8IXczNkUCYpOQemUqBjHqGcg0cX2euVGanx0FaSo41YBUSTmNbNCc8 aOuR+kCTvxkjxNRYIh9vOaqBf2bWFPp6+HTiFWlU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 859599F; Sun, 27 Sep 2015 21:16:13 +0200 (CEST) Date: Sun, 27 Sep 2015 21:16:13 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <560831A4.10601@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 19:16:18 -0000 On Sun, 27 Sep 2015, Joe Touch wrote: > What you want is the *OS* to do something - specifically, when the > interface goes down (not a protocol event), you want the OS socket to go > down too (not a protocol event either). That's exactly why this is an OS > issue, not a TCP, IP, or IETF one, IMO. Do you oppose IETF doing things like RFC7084 and other similar documents that aren't pure protocol matters? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Sep 27 12:48:37 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE81B2D83 for ; Sun, 27 Sep 2015 12:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xXGjBfdtjCF for ; Sun, 27 Sep 2015 12:48:35 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300621B2D82 for ; Sun, 27 Sep 2015 12:48:35 -0700 (PDT) Received: from [192.168.1.156] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t8RJm3Wl010758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2015 12:48:05 -0700 (PDT) To: Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> From: Joe Touch Message-ID: <560847F2.7070207@isi.edu> Date: Sun, 27 Sep 2015 12:48:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t8RJm3Wl010758 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 19:48:36 -0000 On 9/27/2015 12:16 PM, Mikael Abrahamsson wrote: > On Sun, 27 Sep 2015, Joe Touch wrote: > >> What you want is the *OS* to do something - specifically, when the >> interface goes down (not a protocol event), you want the OS socket to >> go down too (not a protocol event either). That's exactly why this is >> an OS issue, not a TCP, IP, or IETF one, IMO. > > Do you oppose IETF doing things like RFC7084 and other similar documents > that aren't pure protocol matters? Protocols are more than just the format of messages "on the wire"; they're also the constellation of rules and behaviors that govern those messages. It's not that your concern isn't a "pure" protocol matter. It's simply not a protocol matter at all. Joe From nobody Sun Sep 27 12:49:04 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ACE1B2D82 for ; Sun, 27 Sep 2015 12:49: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVzKSnvNnKy3 for ; Sun, 27 Sep 2015 12:49:01 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEA51B2D81 for ; Sun, 27 Sep 2015 12:49:01 -0700 (PDT) Received: by padhy16 with SMTP id hy16so153176076pad.1 for ; Sun, 27 Sep 2015 12:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=bwjGE522oaFLVlerLnZgHNXXv6M3c8qDuRYISOsjaHg=; b=KP3GKXbd1T0omO+LIByaZvfJ6fUCfQ/t2uAABZ9xWMg0Iq6GgsBEWppT75slSW9DqP GhlaKvLhUYytgOy0XyMapB+qNFNo3zAKwZyNA8i7/qRO49K7JmHvkZvpzZfSXhBSY8QG 7Rnf7X2YuwJtSIHBvogDv/0ZO+bRtvexbxOF6j0IGyCP9SvCpx0ogiespwSIJpPhx63o ifLiSw6LGuEp1U5dxKd030WxABzN+XDYK3nYb+U1GC2RQXaUo1xYzf2BHZUVLY3QBo6P EMYPf6Lb5u4Zxcafu7PU9972+cNTXUMjOdvDNvYTrmIf2pZlogBlC4rV0Gcj4C+jMS1X ddPw== X-Received: by 10.66.228.97 with SMTP id sh1mr21724613pac.91.1443383341457; Sun, 27 Sep 2015 12:49:01 -0700 (PDT) Received: from ?IPv6:2406:e007:4ac8:1:28cc:dc4c:9703:6781? ([2406:e007:4ac8:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id xd10sm15169520pab.25.2015.09.27.12.48.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Sep 2015 12:49:00 -0700 (PDT) To: Joe Touch , Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56084827.4070705@gmail.com> Date: Mon, 28 Sep 2015 08:48:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560831A4.10601@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 19:49:03 -0000 On 28/09/2015 07:12, Joe Touch wrote: > > > On 9/27/2015 11:00 AM, Mikael Abrahamsson wrote: >> On Sun, 27 Sep 2015, Joe Touch wrote: >> >>> 1) you really don't KNOW you won't get the same IP address when you >>> reconnect that interface >> >> So let's say my provider uses 100.64.0.0/10 generally, and they now use >> /14 out of that per GGSN as a pool, and they implement a 5 minute >> "quarantine" before re-use of existing address. The odds of me getting >> my IPv4 address back is miniscule. So with this knowledge in mind, I >> pretty much KNOW that when the PDP context goes down, that IP address I >> had is no longer of any use and I might as well kill all sockets >> associated with that IP address. > > That's an internal OS decision. > >>> What you appear to want is a link between the network interface and >>> the OS socket such that when the link goes down the socket disconnects >>> or fails. That's strictly an OS issue. >> >> So where should this be discussed in the IETF? Or is your view that this >> isn't worth discussing? Or it's just not worth discussing in the IETF? > > My view is that it's out of scope for the IETF. I disagree. We're talking about implementation and operational practice to make the system more robust from an end2end point of view. If we can't talk about that in the iEtf, where's the E gone? > What you're proposing is > that: > > a) an IP address is strictly bound to a particular interface > that runs counter to RFC1122; it's OK for you to > make that assumption in an implementation based > on a particular interface and ISP, but it's not > something that would be appropriate to generalize IMO Statistically, it's a valid generalisation. Most end-user addresses are ephemeral these days, and very unlikely to re-occur on a different interface. RFC1122 was written before we even had DHCP; addresses were statically configured and highly unlikely to change on the fly. > > b) when an interface goes down, an OS socket should go down > with it > that's an OS issue; there's nothing to specify here > that has to do with IP or TCP True, in terms of their protocol state machines and messages. But that isn't this WG's business. > c) TCP connections should go down anytime an address becomes > unavailable due to an interface change > TCP is actually designed to do the opposite; to stay > up until a message fails to go out, not to come down > as soon as that possibility can't happen Yes, and that was a reasonable approach to robustness when addresses were static and would definitely still be valid after somebody changed the Ethernet card on the VAX or moved a cable to the Cisco instead of the Proteon. For a 2015-vintage Android device jumping from Wi-Fi to Wi-Fi as it walks around the city, it's the worst possible approach. > The last one is a biggie, IMO - it's based on the Postel Principle (be > liberal in what you accept, be conservative in what you do). In this > context, it would mean: > > don't assume a failure when you can assume a interruption > that doesn't impact you yet > > There have been protocols or applications that do care about such > interruptions - which is exactly why TCP has a keepalive mechanism > (which sends nothing if you're already sending, but tests to see if a > message could go out if not). But that's from TCP's viewpoint -- you > don't want TCP to do anything, which is why this isn't an IETF issue. You don't want the TCP state machine to do anything, but you do want the stack to do something, which *is* a v6ops issue (in terms of implementation guidance). > > What you want is the *OS* to do something - specifically, when the > interface goes down (not a protocol event), you want the OS socket to go > down too (not a protocol event either). That's exactly why this is an OS > issue, not a TCP, IP, or IETF one, IMO. We disagree on your assumption about IETF scope. Brian From nobody Sun Sep 27 13:07:34 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25F71B2DBC for ; Sun, 27 Sep 2015 13:07:32 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv3nNXY0tmB2 for ; Sun, 27 Sep 2015 13:07:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15981B2DBB for ; Sun, 27 Sep 2015 13:07:30 -0700 (PDT) Received: from [192.168.1.156] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t8RK6r5i009262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2015 13:07:03 -0700 (PDT) To: Brian E Carpenter , Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56084C5B.4060102@isi.edu> Date: Sun, 27 Sep 2015 13:06:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56084827.4070705@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 20:07:32 -0000 On 9/27/2015 12:48 PM, Brian E Carpenter wrote: > On 28/09/2015 07:12, Joe Touch wrote: >> >> >> On 9/27/2015 11:00 AM, Mikael Abrahamsson wrote: >>> On Sun, 27 Sep 2015, Joe Touch wrote: >>> >>>> 1) you really don't KNOW you won't get the same IP address when you >>>> reconnect that interface >>> >>> So let's say my provider uses 100.64.0.0/10 generally, and they now use >>> /14 out of that per GGSN as a pool, and they implement a 5 minute >>> "quarantine" before re-use of existing address. The odds of me getting >>> my IPv4 address back is miniscule. So with this knowledge in mind, I >>> pretty much KNOW that when the PDP context goes down, that IP address I >>> had is no longer of any use and I might as well kill all sockets >>> associated with that IP address. >> >> That's an internal OS decision. >> >>>> What you appear to want is a link between the network interface and >>>> the OS socket such that when the link goes down the socket disconnects >>>> or fails. That's strictly an OS issue. >>> >>> So where should this be discussed in the IETF? Or is your view that this >>> isn't worth discussing? Or it's just not worth discussing in the IETF? >> >> My view is that it's out of scope for the IETF. > > I disagree. We're talking about implementation and operational practice > to make the system more robust from an end2end point of view. If we can't > talk about that in the iEtf, where's the E gone? It's not about E, it's about whether there is a protocol issue here at all. >> What you're proposing is >> that: >> >> a) an IP address is strictly bound to a particular interface >> that runs counter to RFC1122; it's OK for you to >> make that assumption in an implementation based >> on a particular interface and ISP, but it's not >> something that would be appropriate to generalize IMO > > Statistically, it's a valid generalisation. Most end-user addresses are > ephemeral these days, and very unlikely to re-occur on a different interface. That's not true for private addresses. It might also easily be true in a cellphone environment if (when) most devices are NAT'd by the carrier. But I don't care if you want to break your OS this way. If you think it's a protocol issue, please explain *why*. I.e., there are separate issues: a) is it a good idea? (I think not, but don't care whether we agree) b) is this a protocol issue? (clearly not) ... >> b) when an interface goes down, an OS socket should go down >> with it >> that's an OS issue; there's nothing to specify here >> that has to do with IP or TCP > > True, in terms of their protocol state machines and messages. But > that isn't this WG's business. Not sure what you mean here. Are you agreeing that this is out of scope? The IETF used to prohibit work on APIs because they were "implementation details". That was a mistake, as they're part of the specification of a protocol. However, the way in which the protocol endpoint ties into the OS is an OS issue. It has nothing to do with the protocol. >> c) TCP connections should go down anytime an address becomes >> unavailable due to an interface change >> TCP is actually designed to do the opposite; to stay >> up until a message fails to go out, not to come down >> as soon as that possibility can't happen > > Yes, and that was a reasonable approach to robustness when addresses > were static and would definitely still be valid after somebody changed > the Ethernet card on the VAX or moved a cable to the Cisco instead of > the Proteon. For a 2015-vintage Android device jumping from Wi-Fi to Wi-Fi > as it walks around the city, it's the worst possible approach. It might make the endpoint more robust - able to tolerate periods when the interface is down but comes back with the same address. The DHCP client can even be configure to prefer to try to renew an old allocation rather than jumping to a new one. Remember that we're talking about TCP connections that are idle when the link goes down; if they're active, they'd already fail. Further, if you don't think this is the right approach to TCP, I encourage you to design a new transport that behaves differently (maybe there's already one that does). This is how TCP is already spec'd. >> The last one is a biggie, IMO - it's based on the Postel Principle (be >> liberal in what you accept, be conservative in what you do). In this >> context, it would mean: >> >> don't assume a failure when you can assume a interruption >> that doesn't impact you yet >> >> There have been protocols or applications that do care about such >> interruptions - which is exactly why TCP has a keepalive mechanism >> (which sends nothing if you're already sending, but tests to see if a >> message could go out if not). But that's from TCP's viewpoint -- you >> don't want TCP to do anything, which is why this isn't an IETF issue. > > You don't want the TCP state machine to do anything, but you do > want the stack to do something, which *is* a v6ops issue (in terms of > implementation guidance). The socket isn't part of the stack; it's an OS construct to connect a process to the protocol. >> What you want is the *OS* to do something - specifically, when the >> interface goes down (not a protocol event), you want the OS socket to go >> down too (not a protocol event either). That's exactly why this is an OS >> issue, not a TCP, IP, or IETF one, IMO. > > We disagree on your assumption about IETF scope. Who's "we"? --- From nobody Sun Sep 27 14:28:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26051B2ECD for ; Sun, 27 Sep 2015 14:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g48_Er_DJPRf for ; Sun, 27 Sep 2015 14:28:06 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F131B2ECC for ; Sun, 27 Sep 2015 14:28:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EB0A2A1; Sun, 27 Sep 2015 23:28:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1443389282; bh=HhlZaOM1x9OxoO5TdNjTvajGlr4KTwcXwzwY2gq3x+4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=C4NqiMc+vXsnRSUcTdaTVLEFkecFhJpKrXweVTlO5KVxaS28ZpwKxlHPRfw2JDkov ovPS9HLWdlbv1DLBqMSdWFbKpi9Fiy8diwmfaBHcGDcnqG/Gv+Us0GDSaz907ULI/H CvugF9Y11C6NIGFoZ+8iwvDpFaqqOvnul7Z5MWj0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E34E59F; Sun, 27 Sep 2015 23:28:02 +0200 (CEST) Date: Sun, 27 Sep 2015 23:28:02 +0200 (CEST) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <56084C5B.4060102@isi.edu> Message-ID: References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <56084C5B.4060102@isi.edu> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 21:28:08 -0000 On Sun, 27 Sep 2015, Joe Touch wrote: > Remember that we're talking about TCP connections that are idle when the > link goes down; if they're active, they'd already fail. No, that is not what happens in real life. If I lose my existing IPv4 address and get a new IPv4 address and press return in my ssh session bound to the old address, it doesn't terminate the TCP session (on Linux or OSX for instance). That session will keep retrying for a long long long time from a user perspective, uselessly long. I'd imagine it's hours, I haven't bothered to wait. I always give up after 60-120 seconds, kill the ssh process. Or rather not, because nowadays I run mosh because that actually has a useful way of handling connections. I grew tired of having to kill the ssh session whenever I left sleep or moved between networks. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Sep 27 15:52:42 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5E81A0211 for ; Sun, 27 Sep 2015 15:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQol1pEykDRZ for ; Sun, 27 Sep 2015 15:52:38 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12691A020A for ; Sun, 27 Sep 2015 15:52:38 -0700 (PDT) Received: from [192.168.1.156] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t8RMqCkO000945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2015 15:52:14 -0700 (PDT) To: Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <56084C5B.4060102@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <5608731A.90102@isi.edu> Date: Sun, 27 Sep 2015 15:52:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t8RMqCkO000945 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 22:52:40 -0000 On 9/27/2015 2:28 PM, Mikael Abrahamsson wrote: > On Sun, 27 Sep 2015, Joe Touch wrote: > >> Remember that we're talking about TCP connections that are idle when the >> link goes down; if they're active, they'd already fail. > > No, that is not what happens in real life. > > If I lose my existing IPv4 address and get a new IPv4 address and press > return in my ssh session bound to the old address, it doesn't terminate > the TCP session (on Linux or OSX for instance). That session will keep > retrying for a long long long time from a user perspective, uselessly > long. I'd imagine it's hours, I haven't bothered to wait. I always give > up after 60-120 seconds, kill the ssh process. If TCP isn't timing out fast enough, then you needed your SSH implementation to set a shorter TCP user timeout as per RFC5482. And check as to whether SSH is using blocking send() calls or not; if not, then again that's the fault of the application and/or OS - not TCP. I.e., when you have a TCP connection and you write to it, the OS makes a packet and tries to send it out of an existing interface. If there aren't existing interfaces, then the OS could easily decide to fail that operation. However, TCP doesn't and can't know any better. It has a source IP address in the control block and it just uses it. That gets sent to IP. IP is allowed to lose packets; TCP doesn't care why or where. It just retransmits them until either it times out or you disconnect. So you don't like how long that takes, but there are plenty of other people - esp. those taking trains through tunnels - who are very happy that the connections just come alive after such interruptions. E.g., I checked my SSH (Windows cygwin) and took the network interface down then up. The connection stalled until I reconnected. The intervening writes were queued up and sent when an available interface came up. That's a decision of how the implementers designed SSH, not a failure of TCP. The point is that it's up to the application as to what semantics are desired, and up to the OS as to what semantics are provided. Joe From nobody Sun Sep 27 16:56:24 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6E41A1B9E for ; Sun, 27 Sep 2015 16:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hoNyMwU7DBn for ; Sun, 27 Sep 2015 16:56:21 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3571A1B8A for ; Sun, 27 Sep 2015 16:56:20 -0700 (PDT) Received: by pacex6 with SMTP id ex6so156314501pac.0 for ; Sun, 27 Sep 2015 16:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=j9ipT0c7/zZ8bXDwRN8QLjS/BQwJ9yurSMkj0QALP+g=; b=UEKaOwA0Adim6WCy+Qit/h/1FsJRjUozyjXKrhUUYLNiQVMKoE83jG5HaWp9C9+1Qi IsYObPLWgmoKFFaEH1n/Ks3+S1iHvbMveH2BzcpukFvc5ZkrJme7wJG8vDU2X05p1bfO oZ7i0Gk8CfTY9x21UXh7FVHzK49JEsazMyceQNi/WBHny6O6Zjuwx2kQ5gu6U3RMrhCQ 9prUG0rPA8PL8nGnvAlchLZPHHUGDyBopRAKl+iRYaVfCW37HmW2xl/HnSJn/+iIiGHH N8GshLZswMam+T9TKC7q8B4Z7/CoXs+BC74GSHECh0A4JDBf0T0rD/G5l1qFgkgtlZWJ IFrg== X-Received: by 10.66.139.231 with SMTP id rb7mr22668646pab.5.1443398180564; Sun, 27 Sep 2015 16:56:20 -0700 (PDT) Received: from ?IPv6:2406:e007:4ac8:1:28cc:dc4c:9703:6781? ([2406:e007:4ac8:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id li11sm15775539pab.43.2015.09.27.16.56.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Sep 2015 16:56:18 -0700 (PDT) To: Joe Touch , Mikael Abrahamsson References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <56084C5B.4060102@isi.edu> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5608821F.2060603@gmail.com> Date: Mon, 28 Sep 2015 12:56:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56084C5B.4060102@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 23:56:22 -0000 On 28/09/2015 09:06, Joe Touch wrote: ... >> We disagree on your assumption about IETF scope. > > Who's "we"? I meant you and me, although I guess Mikael and I agree. Brian From nobody Sun Sep 27 17:55:11 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B861A8735 for ; Sun, 27 Sep 2015 17:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbnwlWFfHhaT for ; Sun, 27 Sep 2015 17:55:09 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002: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 0EE9D1A8720 for ; Sun, 27 Sep 2015 17:55:08 -0700 (PDT) Received: by ykdt18 with SMTP id t18so159959471ykd.3 for ; Sun, 27 Sep 2015 17:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=guAyuTCXXjmUHebLDnDZ7EmynZGPLGgRXZxX+1Ng4A0=; b=NdJNaW+o6VkhvkgcjeKTlrynYav6DQ/OTYOHBFp+RinkChW4M4C/5M79KccQloZHqH h23sN8cB0j7Q09+raMk/Vn1j2FxsEAEZSzCSNSDnUTlKsDeX9GyDvfd0seVrRyG0umL3 YD2oduPa4QiecaWHvo9AePbOiMHy+KNux7l+yAHU0jyy8Hbif3gKdeP+wXZ5nWlMlRF1 kbLJzaw2nrf3k3ZF4SFPZ4eZ346+b+io53uwwrsb7/3kNjIJMRD1+dIj3AkLTjPL8CD2 pmwdo/QjFGzEh6Vad5IlTnqfK1IzcE+mQUVhy9fJgtwcdFm9cIkgR6gOPDrgcw1JTLr9 RfdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=guAyuTCXXjmUHebLDnDZ7EmynZGPLGgRXZxX+1Ng4A0=; b=SBvDbVmc55OBvx349KjfEC57uqZ85DeMCihtfzNWF/OXes8eu0MHj0bxX/LczKZXYS Nlr3cc/HTBACABTPbik6D3mQUvJ99qfSnOXbjipgDt+185SOqmFCoNvNZD11tERPukjv 0GSJU1x73SR9UUXQz7PE9eGEE+W74RdCAd6JIai/tN09E8ffdSfLKrDKEHCABpiYyEOf Dd1KUPW3HZxLDoMiRKinYP9fJR3sqVPy3UnFw8+aUzrpJA5ZgIPF5cRefQFACghT+g2s unDegdMlNJmp4WxtdsXJtrm5K+atIY0NTGorJd7oKWSwPCXBXSs3yd5BV+Ezb44jySLU BjhQ== X-Gm-Message-State: ALoCoQnKbTTMXC4zoUwEx6S9F2N9kXalHORoGP7MFbXwvDIQ2FrlnTZj6MnaKhMZj2unx8U/wDd5 X-Received: by 10.170.117.84 with SMTP id j81mr14574513ykb.47.1443401708071; Sun, 27 Sep 2015 17:55:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Sun, 27 Sep 2015 17:54:45 -0700 (PDT) In-Reply-To: <5608731A.90102@isi.edu> References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <56084C5B.4060102@isi.edu> <5608731A.90102@isi.edu> From: Lorenzo Colitti Date: Mon, 28 Sep 2015 09:54:45 +0900 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a1137be8e146c950520c4268c Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 00:55:10 -0000 --001a1137be8e146c950520c4268c Content-Type: text/plain; charset=UTF-8 On Mon, Sep 28, 2015 at 7:52 AM, Joe Touch wrote: > If TCP isn't timing out fast enough, then you needed your SSH > implementation to set a shorter TCP user timeout as per RFC5482. And > check as to whether SSH is using blocking send() calls or not; if not, > then again that's the fault of the application and/or OS - not TCP. > Lest anyone think this is a good idea, let me state that in many cases, it's a terrible idea. Having x independent apps each send TCP keepalives every y seconds is terrible for battery life. Depending on how unsynchronized the apps are, due to natural hysteresis cycles and dormancy timers you might end up keeping the radio in a high-power state all the time, even when there is no real traffic to send and receive. It's also quite bad for total network bandwidth - wireless networks such as 802.11 and LTE are optimized for bursts and have substantial channel acquisition costs. TCP keepalives will work on plugged-in workstations connected to wired networks, but I think that's not how most users use the Internet these days. --001a1137be8e146c950520c4268c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Sep 28, 2015 at 7:52 AM, Joe Touch <touch@isi.edu> wrote:
If TCP isn't timing out fast enough, th= en you needed your SSH
implementation to set a shorter TCP user timeout as per RFC5482. And
check as to whether SSH is using blocking send() calls or not; if not,
then again that's the fault of the application and/or OS - not TCP.
=

Lest anyone think this is a good idea, let= me state that in many cases, it's a terrible idea.

Having x independent apps each send TCP keepalives every y seconds is= terrible for battery life. Depending on how unsynchronized the apps are, d= ue to natural hysteresis cycles and dormancy timers you might end up keepin= g the radio in a high-power state all the time, even when there is no real = traffic to send and receive.

It's also quite b= ad for total network bandwidth - wireless networks such as 802.11 and LTE a= re optimized for bursts and have substantial channel acquisition costs.

TCP keepalives will work on plugged-in workstations c= onnected to wired networks, but I think that's not how most users use t= he Internet these days.
--001a1137be8e146c950520c4268c-- From nobody Mon Sep 28 00:33:02 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B071B31D2 for ; Mon, 28 Sep 2015 00:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-gQ2dSG9snf for ; Mon, 28 Sep 2015 00:32:59 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id D7F531A9241 for ; Mon, 28 Sep 2015 00:32:58 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id EB17D3D0B3; Mon, 28 Sep 2015 09:32:56 +0200 (CEST) Date: Mon, 28 Sep 2015 09:32:56 +0200 (CEST) Message-Id: <20150928.093256.46360250.he@uninett.no> To: brian.e.carpenter@gmail.com From: Havard Eidnes In-Reply-To: <56084827.4070705@gmail.com> References: <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 07:33:01 -0000 >> a) an IP address is strictly bound to a particular interface >> that runs counter to RFC1122; it's OK for you to >> make that assumption in an implementation based >> on a particular interface and ISP, but it's not >> something that would be appropriate to generalize IMO > = > Statistically, it's a valid generalisation. Most end-user addresses > are ephemeral these days, and very unlikely to re-occur on a > different interface. That's probably true. But tweak the statement slightly, and change "different interface" to "same interface", and I'm not sure I agree: in my experience most DHCP servers I meet on WiFi networks are quite likely to re-assign the same IP address after a blip in reachability or an interface down/up transition on the WiFi-connected device. If address assignment in mobile networks is different, and there's a specific policy preventing the re-assignment of the same IP address to the same device should it re-surface again shortly after a network reachability transition, that's another thing. I'm wondering if this forced address churn won't reduce the usability of long-lived TCP connections from a device tehtered behind a cell phone. Best regards, - H=E5vard From nobody Mon Sep 28 01:08:47 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E451B321F for ; Mon, 28 Sep 2015 01:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P_FItCWJ8Ox for ; Mon, 28 Sep 2015 01:08:43 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 CD8801B321C for ; Mon, 28 Sep 2015 01:08:43 -0700 (PDT) Received: by ykdz138 with SMTP id z138so168084906ykd.2 for ; Mon, 28 Sep 2015 01:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gr3Y4Xhs7zlmBII1iYD8i3uGJb8ptxkx+EhvDCt7eds=; b=gZ7HhJoWB1X0qq2S8vxdtfGEXrMghR99LvVW5oOasTmWnFKIVkq3r/nxD1NHYaDJyG EV8pNS3Z7CCoUy7Bnc/zGpYxOpRlQ9WIqmxA/tqxK/PLPho4iKYUPpNdwVUulJi4neG7 LhDtuS9OeJmSU09G+EbudIhHGqZhGFcyUjmBEza/Z19fo4+mKomNAEeUW7pwOIALCM2e njYKS4lMCWY0UwMoCmsZS9Vca2nP03rYtyBX/2gCzXXbaiBDO5LDeExw6KgzXh2wGZV8 uxMkvsHwiSDV0JV2fvLdBO0jGHic3cgqre8dESqUmxSYlhTbY64Vc1sjzB9/qC5Yb+jv 3AMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gr3Y4Xhs7zlmBII1iYD8i3uGJb8ptxkx+EhvDCt7eds=; b=fjCR1M1B5rPU/1ckShiSz0nB0BANOhDSdKcfrrQCmmQ/8tN/ndhXCVvoX+UueYrbhN tJDm/QWP/wVQsK/Qh0Yu+VhXJqmcJio3OjMUiDxy59owiABlkUiHxDZn1SSgDudBzJ58 SqpMYJXWqUU2Xfe9Ox1NNFjdg98S8nw8IN19ScPzq4a7ut5XgtllcPKJVpUp1dW1IR+D HEG/Ldr0tgAj1WtJQCPVRwPLplfk0vawnkyJ3XS71jpSRUHj5n02N9ptNpZrqvLEWU/E Uzt71tHf/o40zY67hm18JP7c9S0ABlnV8WCCft+NrndI17miVaNs8HqqvqrAs29HieDF anQQ== X-Gm-Message-State: ALoCoQkWdtel3hURYAf8J4gbbWw1aR1O8DHOJXO2mc3F7FaRzOV+RynK98RmFydMRpMYabllHHUm X-Received: by 10.13.232.194 with SMTP id r185mr14925577ywe.170.1443427722722; Mon, 28 Sep 2015 01:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.204 with HTTP; Mon, 28 Sep 2015 01:08:22 -0700 (PDT) In-Reply-To: <20150928.093256.46360250.he@uninett.no> References: <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <20150928.093256.46360250.he@uninett.no> From: Lorenzo Colitti Date: Mon, 28 Sep 2015 17:08:22 +0900 Message-ID: To: Havard Eidnes Content-Type: multipart/alternative; boundary=94eb2c08711eac69c20520ca34cf Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 08:08:45 -0000 --94eb2c08711eac69c20520ca34cf Content-Type: text/plain; charset=UTF-8 On Mon, Sep 28, 2015 at 4:32 PM, Havard Eidnes wrote: > That's probably true. But tweak the statement slightly, and change > "different interface" to "same interface", and I'm not sure I agree: > in my experience most DHCP servers I meet on WiFi networks are quite > likely to re-assign the same IP address after a blip in reachability > or an interface down/up transition on the WiFi-connected device. > Please everyone realize that the whole point is that when wifi goes away, the next opportunity to connect will be well within a few hundred milliseconds, *on a different network* - i.e., cellular data. That network is almost certainly going to have a different IP address, and any OS, stack or application has exactly two choices: 1) get stuck, hoping that the previous connection will magically show up again, and 2) reconnect. For a mobile device, the smart choice is almost always #2. --94eb2c08711eac69c20520ca34cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Sep 28, 2015 at 4:32 PM, Havard Eidnes <he@uninett.no> wrote= :
That's probably true.=C2=A0 But twe= ak the statement slightly, and change
"different interface" to "same interface", and I'm = not sure I agree:
in my experience most DHCP servers I meet on WiFi networks are quite
likely to re-assign the same IP address after a blip in reachability
or an interface down/up transition on the WiFi-connected device.

Please everyone realize that the whole point is t= hat when wifi goes away, the next opportunity to connect will be well withi= n a few hundred milliseconds, *on a different network* - i.e., cellular dat= a.

That network is almost certainly going to have = a different IP address, and any OS, stack or application has exactly two ch= oices: 1) get stuck, hoping that the previous connection will magically sho= w up again, and 2) reconnect.

For a mobile device,= the smart choice is almost always #2.
--94eb2c08711eac69c20520ca34cf-- From nobody Mon Sep 28 08:14:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654BA1A912B for ; Mon, 28 Sep 2015 08:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCPAeEUroe84 for ; Mon, 28 Sep 2015 08:14:38 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (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 D90EE1A930A for ; Mon, 28 Sep 2015 08:14:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t8SFEe0f009529; Mon, 28 Sep 2015 08:14:40 -0700 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t8SFEaCs009473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 28 Sep 2015 08:14:36 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.197]) with mapi id 14.03.0235.001; Mon, 28 Sep 2015 08:14:33 -0700 From: "Templin, Fred L" To: Lorenzo Colitti , Havard Eidnes Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ+BC1ecS+NCAn7EaALDKKzLdmeJ5OrOeAgAAFZYCAABwaAIAAvTwAgABfboCAAGXAAIAAzm2AgAACvgCAAAN7AIAAGtaAgADEtACAAAnmAIAAAHjQ Date: Mon, 28 Sep 2015 15:14:32 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F0F5DC@XCH-BLV-504.nw.nos.boeing.com> References: <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <20150928.093256.46360250.he@uninett.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: multipart/alternative; boundary="_000_2134F8430051B64F815C691A62D9831832F0F5DCXCHBLV504nwnosb_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 15:14:40 -0000 --_000_2134F8430051B64F815C691A62D9831832F0F5DCXCHBLV504nwnosb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xpdHRpDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAy OCwgMjAxNSAxOjA4IEFNDQpUbzogSGF2YXJkIEVpZG5lcw0KQ2M6IHY2b3BzQGlldGYub3JnIFdH DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLWhvc3QtYWRkci1hdmFpbGFi aWxpdHkgV0dMQw0KDQpPbiBNb24sIFNlcCAyOCwgMjAxNSBhdCA0OjMyIFBNLCBIYXZhcmQgRWlk bmVzIDxoZUB1bmluZXR0Lm5vPG1haWx0bzpoZUB1bmluZXR0Lm5vPj4gd3JvdGU6DQpUaGF0J3Mg cHJvYmFibHkgdHJ1ZS4gIEJ1dCB0d2VhayB0aGUgc3RhdGVtZW50IHNsaWdodGx5LCBhbmQgY2hh bmdlDQoiZGlmZmVyZW50IGludGVyZmFjZSIgdG8gInNhbWUgaW50ZXJmYWNlIiwgYW5kIEknbSBu b3Qgc3VyZSBJIGFncmVlOg0KaW4gbXkgZXhwZXJpZW5jZSBtb3N0IERIQ1Agc2VydmVycyBJIG1l ZXQgb24gV2lGaSBuZXR3b3JrcyBhcmUgcXVpdGUNCmxpa2VseSB0byByZS1hc3NpZ24gdGhlIHNh bWUgSVAgYWRkcmVzcyBhZnRlciBhIGJsaXAgaW4gcmVhY2hhYmlsaXR5DQpvciBhbiBpbnRlcmZh Y2UgZG93bi91cCB0cmFuc2l0aW9uIG9uIHRoZSBXaUZpLWNvbm5lY3RlZCBkZXZpY2UuDQoNClBs ZWFzZSBldmVyeW9uZSByZWFsaXplIHRoYXQgdGhlIHdob2xlIHBvaW50IGlzIHRoYXQgd2hlbiB3 aWZpIGdvZXMgYXdheSwgdGhlIG5leHQgb3Bwb3J0dW5pdHkgdG8gY29ubmVjdCB3aWxsIGJlIHdl bGwgd2l0aGluIGEgZmV3IGh1bmRyZWQgbWlsbGlzZWNvbmRzLCAqb24gYSBkaWZmZXJlbnQgbmV0 d29yayogLSBpLmUuLCBjZWxsdWxhciBkYXRhLg0KDQpUaGF0IG5ldHdvcmsgaXMgYWxtb3N0IGNl cnRhaW5seSBnb2luZyB0byBoYXZlIGEgZGlmZmVyZW50IElQIGFkZHJlc3MsIGFuZCBhbnkgT1Ms IHN0YWNrIG9yIGFwcGxpY2F0aW9uIGhhcyBleGFjdGx5IHR3byBjaG9pY2VzOiAxKSBnZXQgc3R1 Y2ssIGhvcGluZyB0aGF0IHRoZSBwcmV2aW91cyBjb25uZWN0aW9uIHdpbGwgbWFnaWNhbGx5IHNo b3cgdXAgYWdhaW4sIGFuZCAyKSByZWNvbm5lY3QuDQoNCkZvciBhIG1vYmlsZSBkZXZpY2UsIHRo ZSBzbWFydCBjaG9pY2UgaXMgYWxtb3N0IGFsd2F5cyAjMi4NCg0KVGhlc2UgY29uY2VybnMgdmFu aXNoIHdoZW4gdGhlIG1vYmlsZSBkZXZpY2UgY29uZmlndXJlcyBhIHR1bm5lbCBhbmQgZ2V0cyBh DQpzdGFibGUgSVAgYWRkcmVzcyAob3IgcHJlZml4KSB0aGF0IG5ldmVyIGNoYW5nZXMgZXZlbiBp ZiB0aGUgdW5kZXJseWluZyBpbnRlcmZhY2UNCmFkZHJlc3NlcyBjaGFuZ2UgZHluYW1pY2FsbHku IEluIHRoYXQgd2F5LCBhcHBzIG1heSBzZWUgYSBibGlwIHdoZW4gdGhlIG1vYmlsZQ0KY2hhbmdl cyBpdHMgYWNjZXNzIG5ldHdvcmsgY29ubmVjdGlvbiAoZS5nLiwgZnJvbSBXaUZpIHRvIGNlbGx1 bGFyKSBidXQgdGhleSB3aWxsDQpjb250aW51ZSB0byBzZWUgdGhlIHNhbWUgSVAgYWRkcmVzcyBh bmQgY29udGludWUgdG8gb3BlcmF0ZSB3aXRob3V0IGhhdmluZw0KdG8gc2h1dCBkb3duIGFuZCBy ZXN0YXJ0Lg0KDQpUaGFua3MgLSBGcmVkDQo= --_000_2134F8430051B64F815C691A62D9831832F0F5DCXCHBLV504nwnosb_ 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 CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHY2b3BzIFttYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TG9yZW56byBD b2xpdHRpPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgU2VwdGVtYmVyIDI4LCAyMDE1IDE6MDgg QU08YnI+DQo8Yj5Ubzo8L2I+IEhhdmFyZCBFaWRuZXM8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGll dGYub3JnIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZv cHMtaG9zdC1hZGRyLWF2YWlsYWJpbGl0eSBXR0xDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMjgs IDIwMTUgYXQgNDozMiBQTSwgSGF2YXJkIEVpZG5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlQHVu aW5ldHQubm8iIHRhcmdldD0iX2JsYW5rIj5oZUB1bmluZXR0Lm5vPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIHBy b2JhYmx5IHRydWUuJm5ic3A7IEJ1dCB0d2VhayB0aGUgc3RhdGVtZW50IHNsaWdodGx5LCBhbmQg Y2hhbmdlPGJyPg0KJnF1b3Q7ZGlmZmVyZW50IGludGVyZmFjZSZxdW90OyB0byAmcXVvdDtzYW1l IGludGVyZmFjZSZxdW90OywgYW5kIEknbSBub3Qgc3VyZSBJIGFncmVlOjxicj4NCmluIG15IGV4 cGVyaWVuY2UgbW9zdCBESENQIHNlcnZlcnMgSSBtZWV0IG9uIFdpRmkgbmV0d29ya3MgYXJlIHF1 aXRlPGJyPg0KbGlrZWx5IHRvIHJlLWFzc2lnbiB0aGUgc2FtZSBJUCBhZGRyZXNzIGFmdGVyIGEg YmxpcCBpbiByZWFjaGFiaWxpdHk8YnI+DQpvciBhbiBpbnRlcmZhY2UgZG93bi91cCB0cmFuc2l0 aW9uIG9uIHRoZSBXaUZpLWNvbm5lY3RlZCBkZXZpY2UuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgZXZlcnlvbmUgcmVh bGl6ZSB0aGF0IHRoZSB3aG9sZSBwb2ludCBpcyB0aGF0IHdoZW4gd2lmaSBnb2VzIGF3YXksIHRo ZSBuZXh0IG9wcG9ydHVuaXR5IHRvIGNvbm5lY3Qgd2lsbCBiZSB3ZWxsIHdpdGhpbiBhIGZldyBo dW5kcmVkIG1pbGxpc2Vjb25kcywgKm9uIGEgZGlmZmVyZW50IG5ldHdvcmsqIC0gaS5lLiwgY2Vs bHVsYXIgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhdCBuZXR3b3JrIGlzIGFsbW9zdCBjZXJ0YWlubHkgZ29pbmcgdG8gaGF2ZSBh IGRpZmZlcmVudCBJUCBhZGRyZXNzLCBhbmQgYW55IE9TLCBzdGFjayBvciBhcHBsaWNhdGlvbiBo YXMgZXhhY3RseSB0d28gY2hvaWNlczogMSkgZ2V0IHN0dWNrLCBob3BpbmcgdGhhdCB0aGUgcHJl dmlvdXMgY29ubmVjdGlvbiB3aWxsIG1hZ2ljYWxseSBzaG93IHVwIGFnYWluLCBhbmQgMikgcmVj b25uZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Gb3IgYSBtb2JpbGUgZGV2aWNlLCB0aGUgc21hcnQgY2hvaWNlIGlzIGFsbW9zdCBhbHdh eXMgIzIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZXNlIGNvbmNlcm5z IHZhbmlzaCB3aGVuIHRoZSBtb2JpbGUgZGV2aWNlIGNvbmZpZ3VyZXMgYSB0dW5uZWwgYW5kIGdl dHMgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5zdGFibGUgSVAgYWRkcmVzcyAob3IgcHJlZml4KSB0aGF0 IG5ldmVyIGNoYW5nZXMgZXZlbiBpZiB0aGUgdW5kZXJseWluZyBpbnRlcmZhY2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+YWRkcmVzc2VzIGNoYW5nZSBkeW5hbWljYWxseS4gSW4gdGhhdCB3YXksIGFwcHMg bWF5IHNlZSBhIGJsaXAgd2hlbiB0aGUgbW9iaWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmNoYW5nZXMg aXRzIGFjY2VzcyBuZXR3b3JrIGNvbm5lY3Rpb24gKGUuZy4sIGZyb20gV2lGaSB0byBjZWxsdWxh cikgYnV0IHRoZXkgd2lsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jb250aW51ZSB0byBzZWUgdGhlIHNh bWUgSVAgYWRkcmVzcyBhbmQgY29udGludWUgdG8gb3BlcmF0ZSB3aXRob3V0IGhhdmluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj50byBzaHV0IGRvd24gYW5kIHJlc3RhcnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_2134F8430051B64F815C691A62D9831832F0F5DCXCHBLV504nwnosb_-- From nobody Mon Sep 28 10:05:54 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1F71ACEDF for ; Mon, 28 Sep 2015 10:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwRHElSfb2rl for ; Mon, 28 Sep 2015 10:05:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810D81ACEDD for ; Mon, 28 Sep 2015 10:05:51 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8SH5Mpf021685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2015 10:05:23 -0700 (PDT) To: Lorenzo Colitti References: <201509201800.t8KI02hV014499@irp-lnx1.cisco.com> <56058455.20905@isi.edu> <56059257.2050305@isi.edu> <01AC2F6C-AE38-4C8E-BCBB-BFDF60246332@isi.edu> <2DF5111B-0FBD-4014-83A7-0849CDC1A297@isi.edu> <56082C6B.3000507@isi.edu> <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <56084C5B.4060102@isi.edu> <5608731A.90102@isi.edu> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56097352.4010104@isi.edu> Date: Mon, 28 Sep 2015 10:05:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 17:05:53 -0000 On 9/27/2015 5:54 PM, Lorenzo Colitti wrote: > On Mon, Sep 28, 2015 at 7:52 AM, Joe Touch > wrote: > > If TCP isn't timing out fast enough, then you needed your SSH > implementation to set a shorter TCP user timeout as per RFC5482. And > check as to whether SSH is using blocking send() calls or not; if not, > then again that's the fault of the application and/or OS - not TCP. > > > Lest anyone think this is a good idea, let me state that in many cases, > it's a terrible idea. > > Having x independent apps each send TCP keepalives every y seconds is > terrible for battery life. We all agree on that. However, RFC5482 is about setting the timeout when TCP 'gives up' on a connection. You can set that shorter without using TCP keepalives. Joe From nobody Mon Sep 28 10:52:36 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6F1B29D7 for ; Mon, 28 Sep 2015 10:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EnaEPr5y4fe for ; Mon, 28 Sep 2015 10:52:26 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BA01B29D1 for ; Mon, 28 Sep 2015 10:52:24 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7471F60498 for ; Mon, 28 Sep 2015 19:52:21 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 0182760737 for ; Mon, 28 Sep 2015 19:52:21 +0200 (CEST) Received: (qmail 98406 invoked by uid 1007); 28 Sep 2015 19:52:20 +0200 Date: Mon, 28 Sep 2015 19:52:20 +0200 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20150928175220.GW84167@Space.Net> References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 17:52:28 -0000 Hi, On Fri, Sep 25, 2015 at 07:46:45PM +0200, Mikael Abrahamsson wrote: > So here we again have the problem that most of the IETF protocol groups do > not have an "*ops" group that actually deals with real world interaction. > v6ops seems to be one of the few. Why don't we have more of them? Because the amount of real-world exposure is not something IETF would be able to stomach. As is evident from this thread. gert -- 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 Mon Sep 28 11:26:48 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675F81B2AE3 for ; Mon, 28 Sep 2015 11:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4LdL8QFyApW for ; Mon, 28 Sep 2015 11:26:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA80B1B2AE2 for ; Mon, 28 Sep 2015 11:26:44 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t8SIQ0dU026079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2015 11:26:00 -0700 (PDT) To: Gert Doering , Mikael Abrahamsson References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <20150928175220.GW84167@Space.Net> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56098638.3070000@isi.edu> Date: Mon, 28 Sep 2015 11:26:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150928175220.GW84167@Space.Net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t8SIQ0dU026079 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 18:26:46 -0000 On 9/28/2015 10:52 AM, Gert Doering wrote: > Hi, > > On Fri, Sep 25, 2015 at 07:46:45PM +0200, Mikael Abrahamsson wrote: >> So here we again have the problem that most of the IETF protocol groups do >> not have an "*ops" group that actually deals with real world interaction. >> v6ops seems to be one of the few. Why don't we have more of them? > > Because the amount of real-world exposure is not something IETF would > be able to stomach. As is evident from this thread. Shall we open a thread on process management? Memory garbage collection? All of these are real-world issues warranting serious consideration. A network interface goes down. That's a network interface event. This is an issue in the RTG and INT areas, but the reason it's not a transport issue is clear - nothing changed as far as the transport protocol is concerned. The real disconnect here is "when an interface goes away, it *takes away my IP address". No, it really doesn't. DCHP revocation can take away an IP address, as does IPv6 duplicate address detection. But these are network events, not transport events. An interface going down may or may not take down the corresponding IP address. So what exactly would you have the OS do? a) the OS socket could disappear when the IP address does we've already pointed out how that would negatively impact apps when a device has intermittent connectivity b) the OS could tell the app that a write would fail but writes to TCP are buffered; they're not necessarily directly correlated to segment emission unless PSH is set Recall that the IETF used to indicate that APIs were off-limits; it has since admitted that at least abstract APIs (such as are spec'd in RFC793) are in-scope. However, what's clear about the cases above is that this is neither an abstract API issue nor a protocol issue. It's an OS implementation issue. It may be an important one, as is the issue of "how to write a robust app that behaves as the user wants". But the IETF isn't where that's discussed. It's taught in network classes. Joe From nobody Mon Sep 28 11:35:40 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEBB1B2B0D for ; Mon, 28 Sep 2015 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqb_-DAFeJzr for ; Mon, 28 Sep 2015 11:35:36 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E971B2B07 for ; Mon, 28 Sep 2015 11:35:33 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B121360A56 for ; Mon, 28 Sep 2015 20:35:30 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 761AC6017E for ; Mon, 28 Sep 2015 20:35:30 +0200 (CEST) Received: (qmail 10128 invoked by uid 1007); 28 Sep 2015 20:35:30 +0200 Date: Mon, 28 Sep 2015 20:35:30 +0200 From: Gert Doering To: Joe Touch Message-ID: <20150928183530.GX84167@Space.Net> References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <20150928175220.GW84167@Space.Net> <56098638.3070000@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7qisgAVMjBkpGISi" Content-Disposition: inline In-Reply-To: <56098638.3070000@isi.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 18:35:38 -0000 --7qisgAVMjBkpGISi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Sep 28, 2015 at 11:26:00AM -0700, Joe Touch wrote: > But the IETF isn't where that's discussed. It's taught in network classes. Thanks for so evidently emphasizing my point. gert --=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 --7qisgAVMjBkpGISi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVgmIct9WwGXkzn/FAQLDUxAAsx/DGQTYK+fb4mOgtULfskGAeKiNPd3c hGxK1lWxMwmIoCffhgZJAePZk1yhd9uTV8vMBKNQcOXRqTtE4/jftfJQ2SWQdRiQ Go49p6rlTOr6yiG7QLctV0D5eJ089/DLNWwlBl8vRkmZobeEVyQ6ysCUM3Bqj1Ns uko3nj9iVm2XJRI9N8cjGG0RrLj8tWpOMfncJbMlaWlHf1ldUKoXRmf1/Gy3E/XI PML0rae9bPC5FTOGrxa0T6jmbRcUeUliWK7pybat8ci7hdHbLgddho0yRyruR+ti QhnnkYmp+16J7Cbrf4uBKcbSJc/USeZwXYz8ZU0s5hW/ihaFh9CJ/G9OAjQTkOeo JG1W4mNazLjd5F2rhqSs/xP+BxO1dRr5eiaocD3LvnFjKVU6Oi9rt96VCoJg9deN J5WTCD/jPwwUgoOClomNaExlz2LWznrBjHqc39wR+/VHSY+w29bDJtx+sVDeI/BY be/MH2Tbpc14cU+iuUn+4jDBNRNHMf2rMrFXOravzDoGLTxJ92hm9utAt13+v9tE 2XPGnF8JZPMOLpZKWR49pVXsp4i931hofF07gQ+gniZBeMhqU5Xm8fp7lGVleeQ9 IvPqm30M3uqQKXsKkwW0NZRptLyhAtVM+1aUb/AbMvlLbaPFR/s4D+cEUfr70tg/ 0s3fqp8XbFw= =D60j -----END PGP SIGNATURE----- --7qisgAVMjBkpGISi-- From nobody Mon Sep 28 12:03:06 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDC51B2BB3 for ; Mon, 28 Sep 2015 12:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id licNsKwuDSBW for ; Mon, 28 Sep 2015 12:02:58 -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 63AE51B2BBC for ; Mon, 28 Sep 2015 12:02: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 t8SJ2vfn008936; Mon, 28 Sep 2015 12:02:57 -0700 Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t8SJ2phB008892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 28 Sep 2015 12:02:51 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.51]) with mapi id 14.03.0235.001; Mon, 28 Sep 2015 12:02:50 -0700 From: "Templin, Fred L" To: Joe Touch , Gert Doering , "Mikael Abrahamsson" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ+hsfecS+NCAn7EaALDKKzLdmeJ5SR80Q Date: Mon, 28 Sep 2015 19:02:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F0F8EA@XCH-BLV-504.nw.nos.boeing.com> References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <20150928175220.GW84167@Space.Net> <56098638.3070000@isi.edu> In-Reply-To: <56098638.3070000@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 19:03:05 -0000 Hi Joe, There is an ongoing discussion in the Distributed Mobility Management (DMM) working group where they are documenting three different address types: 1) Nomadic 2) Sustained 3) Fixed (or stable) A nomadic address is one that is discovered when the app connects over a network interface. If the interface goes down and comes back up, or if the node switches over to using a different interface, then the original address is deprecated and the app is obliged to use a new address. This is what typically happens when a handset switches over from WiFI to Cellular. A fixed (or stable) address is one that never changes even if the underlyin= g network interfaces change. An interface can go down and come back up with a different address, or the node can switch over to using a different interface, but the fixed address remains unchanged and the app does not need to reconnect. This is the type of address the node gets when it configures a tunnel (or, VPN) over the underlying network interfaces. So, if you want an app to survive a network handover, this is the type of arrangement you should use. A "sustained" address is one that remains unchanged during the app's connection lifetime. But, after the connection terminates, the app may discover and utilize a different sustained address for future connections. Personally, I believe this type of address is mythical as I don't see any practical way of implementing it. IMHO, if you want a stable address that never changes, and/or the ability to configure multiple addresses, use DHCPv6 PD over tunnels. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Monday, September 28, 2015 11:26 AM > To: Gert Doering; Mikael Abrahamsson > Cc: v6ops list > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC >=20 >=20 >=20 > On 9/28/2015 10:52 AM, Gert Doering wrote: > > Hi, > > > > On Fri, Sep 25, 2015 at 07:46:45PM +0200, Mikael Abrahamsson wrote: > >> So here we again have the problem that most of the IETF protocol group= s do > >> not have an "*ops" group that actually deals with real world interacti= on. > >> v6ops seems to be one of the few. Why don't we have more of them? > > > > Because the amount of real-world exposure is not something IETF would > > be able to stomach. As is evident from this thread. >=20 > Shall we open a thread on process management? Memory garbage collection? >=20 > All of these are real-world issues warranting serious consideration. >=20 > A network interface goes down. That's a network interface event. This is > an issue in the RTG and INT areas, but the reason it's not a transport > issue is clear - nothing changed as far as the transport protocol is > concerned. >=20 > The real disconnect here is "when an interface goes away, it *takes away > my IP address". >=20 > No, it really doesn't. DCHP revocation can take away an IP address, as > does IPv6 duplicate address detection. But these are network events, not > transport events. An interface going down may or may not take down the > corresponding IP address. >=20 > So what exactly would you have the OS do? >=20 > a) the OS socket could disappear when the IP address does > we've already pointed out how that would negatively > impact apps when a device has intermittent connectivity >=20 > b) the OS could tell the app that a write would fail > but writes to TCP are buffered; they're not necessarily > directly correlated to segment emission unless PSH is set >=20 > Recall that the IETF used to indicate that APIs were off-limits; it has > since admitted that at least abstract APIs (such as are spec'd in > RFC793) are in-scope. >=20 > However, what's clear about the cases above is that this is neither an > abstract API issue nor a protocol issue. It's an OS implementation > issue. It may be an important one, as is the issue of "how to write a > robust app that behaves as the user wants". >=20 > But the IETF isn't where that's discussed. It's taught in network classes= . >=20 > Joe >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 28 13:11:41 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735201B2C7D for ; Mon, 28 Sep 2015 13:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4fiXGVf_hXP for ; Mon, 28 Sep 2015 13:11:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C3E1B2C7F for ; Mon, 28 Sep 2015 13:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7422; q=dns/txt; s=iport; t=1443471097; x=1444680697; h=from:to:cc:subject:date:message-id:references: mime-version; bh=k6l4KWdMOqCIIDZu6Xr7EGaMt6NTaAND+nicFS4T4CI=; b=NeM1HYQUKJgDONjh1hIlmb/OYpgukJ9gM9fvuMz3INTEbDDZp4BGkgvD RM79RuIAsIXQYHzVzzTAvn9swufqSFygQwBviyzPcDoZCfJG8xKKYifdF WC0PyW6054f6jZNWK+nK6FSm5CBDUk/m6tvqgUV5lDMNrCaIIWlfKUn7c 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C0AgC8nQlW/5tdJa1egyRUaQaDJKtbjjoOgXEKhXkCgU04FAEBAQEBAQGBCoQkAQEBAwEjVgULAgEZAwECASoCAjIbAggCBA4FDhGIBwgNtn2UTgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiQKCboQqEQFAEQ2CKDsSHYEUBYV8gTqOOgGCSoFgBWWHeoFPkS6EVYNsAR8BQ4IQARyBVHGHYjqBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,604,1437436800"; d="asc'?scan'208";a="192020451" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 28 Sep 2015 20:11:36 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t8SKBZ9v027178 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 20:11:36 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 15:11:34 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Mon, 28 Sep 2015 15:11:34 -0500 From: "Fred Baker (fred)" To: v6ops list Thread-Topic: [Rtg-dt-encap-considerations] overlay encapsulation group Thread-Index: AQHQ9wLa6QJAXiB3eEW5Bf0xE00y7A== Date: Mon, 28 Sep 2015 20:11:34 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.39] Content-Type: multipart/signed; boundary="Apple-Mail=_A7D82A90-E0F5-484A-9214-B68F5D7A2D11"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 20:11:39 -0000 --Apple-Mail=_A7D82A90-E0F5-484A-9214-B68F5D7A2D11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Running a question by the list. Tom and I got to talking about this = because I proposed an approach to IPv6 networking for OpenStack = (https://tools.ietf.org/html/draft-baker-openstack-ipv6-model), and Tom = proposed a similar but different model in nvo3 (draft-herbert-nvo3-ila). = =46rom what he says, I gather that Facebook is looking at trial = deployment of a modified version of his approach that takes an important = step in the direction of mine. What I wonder is whether the WG would be interested in an operational = discussion of draft-herbert-nvo3-ila and Facebook's IPv6 deployment at = IETF 94? And specifically, do folks have comments on his updated draft = when he posts it? On Sep 25, 2015, at 2:12 PM, Tom Herbert wrote: > Thanks Fred. >=20 > The ILA draft is = https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila/. >=20 > Tom > From: Tom Herbert > Subject: Re: [Rtg-dt-encap-considerations] overlay encapsulation group > Date: September 24, 2015 at 12:54:41 PM PDT > To: "Fred Baker (fred)" >=20 > Hi Fred, >=20 > I'd like to give you an update on ILA. >=20 > We pushed an initial implementation to upstream > https://lwn.net/Articles/654540/. I have a couple of more patches to > get in, but this will get us to a pretty performant data path (much > better than what we'll get from traditional encapsulation). >=20 > Internally (@FB), we are commencing canary deployments. There was an > interesting debate on whether to use ULA or get a larger address > allocation (the latter won), but so far this approach seems feasible. >=20 > One design change, which I think may be along the lines of you were > asking, is that we will allow untranslated addresses to be routable. > Untranslated packets would be routed to some intermediate device in > the network which perform the translation and forward packet to the > location of the virtual node. We'll have these nodes be able to send > something like an ICMP redirect to the source to eliminate the > triangular routing for future packets. >=20 > I'm planning on updating the ILA draft for IETF. I can present that > work at nvo3, but do you think there would be any interest or reason > to take this to an IPv6 WG? >=20 > Thanks, > Tom >=20 > On Mon, Apr 27, 2015 at 1:41 PM, Fred Baker (fred) = wrote: >>=20 >>> On Apr 27, 2015, at 1:31 PM, Tom Herbert = wrote: >>> In ILA the translation is always symmetric between sender and = receiver, and the translation is transparent to the user in the same way = that NV encapsulation would be. Applications at both endpoints see the = same addresses for the connection (SIR addresses in the draft), and = these are what is put into DNS. Many of the communication scenarios = showing this are in section 4 of the ILA draft. On the wire intermediate = devices would see the translated addresses. >>=20 >> In the data plane, at the network layer. The redirect is in an = application message and might well be encrypted. But the sender of the = redirect has to get it to the receiver, and give an address for the = third party that the receiver can use. >>=20 >>> The problem we are trying to solve in virtualizing data center tasks = is how to allow task A on physical host X to communicate with task B on = physical host Y; and then how to continue communications when task B = moves to physical host Z. I guess this could be considered a = reachability, connectivity, routability, or authorization problem = depending on how you want to look at it. >>=20 >> Yes. It=E2=80=99s one of the first three after it moves and before it = is renumbered. Before moving and after renumbering, it is just an = authorization problem, IMHO. >>=20 >>> In multi-tenancy, we have a requirement for isolation between = tenants. If traffic crosses between tenant networks without = authorization this is fundamentally bad, so we need strong guarantees = (maybe this is what you mean by authorization problem?). >>=20 >> Yes >>=20 >>> The VNID is a mechanism of isolation, but not typically = self-authenticated. >>=20 >> If it=E2=80=99s in the IPv6 IID, it=E2=80=99s assigned by the = orchestrator, and the BCP 38 filter in the vSwitch enforces its use. = That=E2=80=99s the same way VLAN numbers or whatever are used. Which is = to say that it=E2=80=99s at least as secure as using a VLAN, given tat = the orchestrator installs the correct ACLs. >>=20 >>> In GUE, we added a security option that allows shared cookie, secure = hash, etc. Unfortunately, I haven't figured out how to add that in ILA = and without security it makes large scale deployment for the multi = tenant use case problematic (the lack of a secured VNID made VLXAN and = NV-GRE non starters for us). I considered flow label for security bits = in ILA, but maybe this could be something in the header options similar = to what you describe in section B.2 (although I am leery of using any = sort of IP options due to lack of middlebox support). >>=20 >> I think I=E2=80=99m telling you how to do that... >>=20 >>>> So, redraw my section B.5 in ILNP terms. Suppose we put the VNID = (which I call a tenant number) in the IID, and treat the prefix as a = locator as ILNP does. Did we accomplish your goal? I think we did, and = we made it be without the coupling, and we made the ACL configuration = (which is the authorization verification) consistent whether in one = chassis, two data centers, or a hybrid cloud with multiple operators. >>>=20 >>> The VNID (tenant number) is already in the identifier (IID part) in = ILA. I don't see any reason why ACLs can't be created for that. Only the = locator part is translated on the wire, so the VNID is also visible to = intermediate devices. >>=20 >> BUT THE LOCATOR IS TRANSLATED, which brings me back to my pervious = email. In an ILNP system, it doesn=E2=80=99t need to be. Why not just = use the ILNP address? A long list of issues go away. >>=20 --Apple-Mail=_A7D82A90-E0F5-484A-9214-B68F5D7A2D11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVgmfKkayAOS/EQ8MAQJwahAA14eJI8GxVJ5r5qw3xQLD9Z0GVD0JptuF hFb/9Z7G1HE/2AxFX+1Waano+GH66PLcYzaWCWSN+Rw9KPvogaKvdPK8GilJhR7G cJJbEPcFIRHDixlCZz+SvhU15qGFWhqnauPdnCMBfa9D+OKm1CPuxF3ZHQuGTWdl qxdke2lqDHXg8m1f/Uygp2bXk0M3D4y25kc09qvKDkH8Im6pgOIq8+zVMMWwGwDw mvTljozbmJrsLwq+rC3d77c5kZUsaF2qH7zQwecQmJNhpiMjG45cLH77Zn39TWKm p1yvSlmH0H9LK0JUZTR5I0OT8EgE/Xi5OmOu0mWMh66x1grwauN1lX/971yIW9un YqavQrQsNnGFuRP0xhlaravUzFTgQZitMlSOfID0MfhGxXOeq97ZOx73KeC5BAL+ fDne16H0LpmRUUSypjYAPS/PQcY2l2Kpp+QNCvNa+Nr1Jorn1YamzGx96q9k/YFT z6D0fPGskISZY/u6Jh0gBworIqvPLVd+WXSmefw8C0d+h36OwHty3kBFIsqFxlvn 71L4ep8b0FuCZzpUmQI5jqZYOcVvO6sXKI1ZhYn5TUeiHvsTG7DtsII2dIpbtkBG bZK2hiK8SMaEJJkl6X/JzDa7ysYTgTnEMkrJTux/HjjSQMQcwHL7W3Rvb1FRhYI+ DBwvABlVFKg= =eK1z -----END PGP SIGNATURE----- --Apple-Mail=_A7D82A90-E0F5-484A-9214-B68F5D7A2D11-- From nobody Mon Sep 28 13:15:57 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59781B2C8F for ; Mon, 28 Sep 2015 13:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzfLdnuZJGOC for ; Mon, 28 Sep 2015 13:15:54 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5762B1B2C58 for ; Mon, 28 Sep 2015 13:15:54 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so187233580pac.2 for ; Mon, 28 Sep 2015 13:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=YsoL5iC7xSRT+95Gy8eoz1G8b6CypvB/ZeQLE8N+lzQ=; b=JpuDNg/sU4n2lY9x5u+9uvWy2UWoHemEYiYKikKBtsQbaEwbpQ4/tMBAUY8v36FPKf hGM3q0wDNlTn7Ri/WcH07ok2B0mRUIImQRhukIikgGqNrIX1ekJuCP4ZU7dC6ZVg2hMt Vc+TITvN+ZvKkcCu2gZHORxEYy9oqKWUMGXyDtjrHU0hSPpSeB7xAaNBRQ6TDYf572Z7 u4adeky7D2Ka7NeRI+RxnOkJ0DRAUbvmWPJ/IZn/cebj3KV74StX2IBvCaVN/T5e/0Hk an6OCAJSfGzMby2+iLumHR3t2g2vRS3wEco85HiJ4ZOou/SGxWERlc//km4gvVQXAWwd M+ew== X-Received: by 10.66.141.165 with SMTP id rp5mr28296034pab.127.1443471353988; Mon, 28 Sep 2015 13:15:53 -0700 (PDT) Received: from ?IPv6:2406:e007:431c:1:28cc:dc4c:9703:6781? ([2406:e007:431c:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id rl17sm21160386pab.2.2015.09.28.13.15.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Sep 2015 13:15:52 -0700 (PDT) To: Lorenzo Colitti , Havard Eidnes References: <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <20150928.093256.46360250.he@uninett.no> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56099FF7.4060603@gmail.com> Date: Tue, 29 Sep 2015 09:15:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 20:15:56 -0000 On 28/09/2015 21:08, Lorenzo Colitti wrote: > On Mon, Sep 28, 2015 at 4:32 PM, Havard Eidnes wrote: > >> That's probably true. But tweak the statement slightly, and change >> "different interface" to "same interface", and I'm not sure I agree: >> in my experience most DHCP servers I meet on WiFi networks are quite >> likely to re-assign the same IP address after a blip in reachability >> or an interface down/up transition on the WiFi-connected device. >> > > Please everyone realize that the whole point is that when wifi goes away, > the next opportunity to connect will be well within a few hundred > milliseconds, *on a different network* - i.e., cellular data. Or even a different Wi-Fi. In a crowded downtown with many free Wi-Fi SSIDs around, I've seen my Android device switching between SSIDs rather frequently. Brian > > That network is almost certainly going to have a different IP address, and > any OS, stack or application has exactly two choices: 1) get stuck, hoping > that the previous connection will magically show up again, and 2) reconnect. > > For a mobile device, the smart choice is almost always #2. > From nobody Mon Sep 28 13:47:59 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48B71B335D for ; Mon, 28 Sep 2015 13:47:57 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAtpvPL9ygJP for ; Mon, 28 Sep 2015 13:47:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8031B3359 for ; Mon, 28 Sep 2015 13:47:55 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t8SKlDog027707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2015 13:47:14 -0700 (PDT) To: "Templin, Fred L" , Gert Doering , Mikael Abrahamsson References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <20150928175220.GW84167@Space.Net> <56098638.3070000@isi.edu> <2134F8430051B64F815C691A62D9831832F0F8EA@XCH-BLV-504.nw.nos.boeing.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <5609A751.7050708@isi.edu> Date: Mon, 28 Sep 2015 13:47:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F0F8EA@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 20:47:57 -0000 Hi, Fred, On 9/28/2015 12:02 PM, Templin, Fred L wrote: > Hi Joe, > > There is an ongoing discussion in the Distributed Mobility Management (DMM) > working group where they are documenting three different address types: > > 1) Nomadic > 2) Sustained > 3) Fixed (or stable) > > A nomadic address is one that is discovered when the app connects over > a network interface. TCP doesn't bind to an "interface"; it either binds to INADDR_ANY or to a specific address. When INADDR_ANY is indicated, an algorithm selects the source IP address based on a set of rules - e.g., as per RFC6724 for IPv6. That IP address is determined by the outgoing interface selected by the forwarding rules for the destination address coupled with some other context and policy information. I.e., TCP doesn't pick an interface; the OS does -- *because* the app has indicated that it wants this operation. (RFC793 talks about this as well - TCP binds to an address, but not an interface per se). > If the interface goes down and comes back up, or if > the node switches over to using a different interface, then the original > address is deprecated and the app is obliged to use a new address. If the OS indicates that the *address* (note - not the interface) is no longer available, then it might be reasonable to signal the socket to fail. But that would make the TCP connection fail; whether the app will try with a *new* socket on a new address depends on how the app is written. > This > is what typically happens when a handset switches over from WiFI to > Cellular. Isn't that just "one network interface coming up and another going down"? Why is that useful to describe as "nomadic"? What makes an interface - or an address - nomadic? > A fixed (or stable) address is one that never changes even if the underlying > network interfaces change. An interface can go down and come back up > with a different address, or the node can switch over to using a different > interface, but the fixed address remains unchanged and the app does not > need to reconnect. This is the type of address the node gets when it > configures a tunnel (or, VPN) over the underlying network interfaces. So, > if you want an app to survive a network handover, this is the type of > arrangement you should use. > > A "sustained" address is one that remains unchanged during the app's > connection lifetime. But, after the connection terminates, the app may > discover and utilize a different sustained address for future connections. > Personally, I believe this type of address is mythical as I don't see any > practical way of implementing it. What do you call a WiFi interface that can go down, come back, and gets the same IP - and then all applications that were active prior to the interruption come back? That's how WiFi works in Windows, FWIW. AFAICT: a) interfaces go down, taking addresses with them b) interfaces come up, yielding either new addresses or reusing previously assigned ones c) interfaces stay up I don't know what the difference between these is until either you see a change. A-priori, you can't really know the difference - a cellular interface might sit in one place and be on all the time (e.g., to support smart power meters). A tunnel can be torn down. And TCP apps that set the local address to INADDR_ANY fall into your "sustained address" category. I don't see any of this as useful to describe in terms of addresses or interfaces. > IMHO, if you want a stable address that never changes, and/or the > ability to configure multiple addresses, use DHCPv6 PD over tunnels. If the tunnel is created using a virtual interface, then it's possible to assign an address and never need to release that interface. Tunnels can also be created addresses bound to existing physical interfaces, and those tunnels would come down when the interface did, however. Joe >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Monday, September 28, 2015 11:26 AM >> To: Gert Doering; Mikael Abrahamsson >> Cc: v6ops list >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC >> >> >> >> On 9/28/2015 10:52 AM, Gert Doering wrote: >>> Hi, >>> >>> On Fri, Sep 25, 2015 at 07:46:45PM +0200, Mikael Abrahamsson wrote: >>>> So here we again have the problem that most of the IETF protocol groups do >>>> not have an "*ops" group that actually deals with real world interaction. >>>> v6ops seems to be one of the few. Why don't we have more of them? >>> >>> Because the amount of real-world exposure is not something IETF would >>> be able to stomach. As is evident from this thread. >> >> Shall we open a thread on process management? Memory garbage collection? >> >> All of these are real-world issues warranting serious consideration. >> >> A network interface goes down. That's a network interface event. This is >> an issue in the RTG and INT areas, but the reason it's not a transport >> issue is clear - nothing changed as far as the transport protocol is >> concerned. >> >> The real disconnect here is "when an interface goes away, it *takes away >> my IP address". >> >> No, it really doesn't. DCHP revocation can take away an IP address, as >> does IPv6 duplicate address detection. But these are network events, not >> transport events. An interface going down may or may not take down the >> corresponding IP address. >> >> So what exactly would you have the OS do? >> >> a) the OS socket could disappear when the IP address does >> we've already pointed out how that would negatively >> impact apps when a device has intermittent connectivity >> >> b) the OS could tell the app that a write would fail >> but writes to TCP are buffered; they're not necessarily >> directly correlated to segment emission unless PSH is set >> >> Recall that the IETF used to indicate that APIs were off-limits; it has >> since admitted that at least abstract APIs (such as are spec'd in >> RFC793) are in-scope. >> >> However, what's clear about the cases above is that this is neither an >> abstract API issue nor a protocol issue. It's an OS implementation >> issue. It may be an important one, as is the issue of "how to write a >> robust app that behaves as the user wants". >> >> But the IETF isn't where that's discussed. It's taught in network classes. >> >> Joe >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 28 14:01:17 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658591B3392 for ; Mon, 28 Sep 2015 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAGldcPcNxhE for ; Mon, 28 Sep 2015 14:01:14 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D62D1B338D for ; Mon, 28 Sep 2015 14:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9624; q=dns/txt; s=iport; t=1443474074; x=1444683674; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SSb7z2Jehj339yEWoWE6fKGrzTr8JtasmPpaY4bpglQ=; b=S50gXZ1xU6+q5D5RWoXeIkr0lC73eMSH7Vcw7ayaTpESErJto63TQ5VJ mpr5Fsmohc971E5W2OYm95D2TSYRiWpDxNwOCr29UrS3NoLQUNzyYSryu KyteeEcFsCpofMf5KYem0C6rY74JVjNkUX1uxmjVnjxEQN/OOeMUGmYUE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQAhqglW/5NdJa1egyRUaQaDJLoVAQ2Be4V5AhyBMTgUAQEBAQEBAYEKhCQBAQEDASMRSgcEAgEIEQMBAQEBAgIGHQMCAgIwFAEICAIEARIIF4gHCA22fZRRAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIopOhCoRASA4BoJjL4EUBYV8gTgCjjoBhC9liUmRLoRVg20fAQFCghABHIFUcYdiOoEFAQEB X-IronPort-AV: E=Sophos;i="5.17,604,1437436800"; d="scan'208";a="192371340" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP; 28 Sep 2015 21:01:13 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t8SL1DDm022454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Sep 2015 21:01:13 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 16:01:12 -0500 Received: from xhc-rcd-x06.cisco.com (173.37.183.80) by xch-rcd-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 28 Sep 2015 16:01:12 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.153]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 16:01:12 -0500 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , v6ops list Thread-Topic: [v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group Thread-Index: AQHQ9wLa6QJAXiB3eEW5Bf0xE00y7J5ScU0Q Date: Mon, 28 Sep 2015 21:01:11 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891690A34C@xmb-rcd-x06.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 21:01:16 -0000 QXMgbWVudGlvbmVkIGluIHRoZSBiYWtlci1vcGVuc3RhY2staXB2Ni1tb2RlbCBkb2N1bWVudCwg dGhlIElFVEYgaXMgbW92aW5nIGF3YXkgZnJvbSB0aGUgTW9kaWZpZWQgRVVJLTY0IGZvcm1hdCBm b3IgSVB2NiBhZGRyZXNzaW5nIC0gc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLTZtYW4tZGVmYXVsdC1paWRzLTAxLiAgIFRodXMgd2h5IHNob3VsZCB0aGUgSUVURiB0 aGVuIGZvc3RlciB0aGlzIGR0LWVuY2FwLWNvbnNpZGVyYXRpb24gd2hpY2ggaXMgd29ya2luZyB3 aXRoIDY0IGJpdHMgb3IgdGhlcmVhYm91dHMgaW4gdGhlIElQdjYgYWRkcmVzcz8gICANCg0KQWxz bywgdGhlIElMQSBkb2N1bWVudCBjcm9zc2VkIHRoZSA2NC1iaXQgYm91bmRhcnkgYmFzZWQgb24g dGhpcyBmb3JtYXQgaW4gdGhlIGRvY3VtZW50LiAgRHVyaW5nIHRoZSByZWNlbnQgSUVURiBtZWV0 aW5nLCB0aGUgNm1hbiBXRyBkaWQgbm90IGFjY2VwdCBhIGRvY3VtZW50IHdoaWNoIHdhcyBwcm9w b3NpbmcgY3Jvc3NpbmcgdGhlIDY0LWJpdCBib3VuZGFyeSBmb3IgbmV0d29ya2luZyBpbiB0aGUg ZGF0YSBjZW50ZXIuIA0KDQogICAgICAvKiBJTEEgZm9yIElQdjYgKi8NCiAgICAgIHwgICAgICAg ICAgICA2NCBiaXRzICAgICAgICAgICAgIHwzIGJpdHN8ICAgICAgIDYxIGJpdHMgICAgICAgICAg fA0KICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICB8ICAgICAgICAgICAgIExvY2F0b3IgICAgICAgICAg fCBUeXBlIHwgICAgIElkZW50aWZpZXIgICAgICAgICAgICAgICB8DQogICAgICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN Cg0KSGVtYW50DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmVkIEJha2VyIChmcmVk KQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjgsIDIwMTUgNDoxMiBQTQ0KVG86IHY2b3BzIGxp c3QNClN1YmplY3Q6IFt2Nm9wc10gRndkOiBbUnRnLWR0LWVuY2FwLWNvbnNpZGVyYXRpb25zXSBv dmVybGF5IGVuY2Fwc3VsYXRpb24gZ3JvdXANCg0KUnVubmluZyBhIHF1ZXN0aW9uIGJ5IHRoZSBs aXN0LiBUb20gYW5kIEkgZ290IHRvIHRhbGtpbmcgYWJvdXQgdGhpcyBiZWNhdXNlIEkgcHJvcG9z ZWQgYW4gYXBwcm9hY2ggdG8gSVB2NiBuZXR3b3JraW5nIGZvciBPcGVuU3RhY2sgKGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYWtlci1vcGVuc3RhY2staXB2Ni1tb2RlbCksIGFu ZCBUb20gcHJvcG9zZWQgYSBzaW1pbGFyIGJ1dCBkaWZmZXJlbnQgbW9kZWwgaW4gbnZvMyAoZHJh ZnQtaGVyYmVydC1udm8zLWlsYSkuIEZyb20gd2hhdCBoZSBzYXlzLCBJIGdhdGhlciB0aGF0IEZh Y2Vib29rIGlzIGxvb2tpbmcgYXQgdHJpYWwgZGVwbG95bWVudCBvZiBhIG1vZGlmaWVkIHZlcnNp b24gb2YgaGlzIGFwcHJvYWNoIHRoYXQgdGFrZXMgYW4gaW1wb3J0YW50IHN0ZXAgaW4gdGhlIGRp cmVjdGlvbiBvZiBtaW5lLg0KDQpXaGF0IEkgd29uZGVyIGlzIHdoZXRoZXIgdGhlIFdHIHdvdWxk IGJlIGludGVyZXN0ZWQgaW4gYW4gb3BlcmF0aW9uYWwgZGlzY3Vzc2lvbiBvZiBkcmFmdC1oZXJi ZXJ0LW52bzMtaWxhIGFuZCBGYWNlYm9vaydzIElQdjYgZGVwbG95bWVudCBhdCBJRVRGIDk0PyBB bmQgc3BlY2lmaWNhbGx5LCBkbyBmb2xrcyBoYXZlIGNvbW1lbnRzIG9uIGhpcyB1cGRhdGVkIGRy YWZ0IHdoZW4gaGUgcG9zdHMgaXQ/DQoNCk9uIFNlcCAyNSwgMjAxNSwgYXQgMjoxMiBQTSwgVG9t IEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KPiBUaGFua3MgRnJlZC4NCj4g DQo+IFRoZSBJTEEgZHJhZnQgaXMgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaGVyYmVydC1udm8zLWlsYS8uDQo+IA0KPiBUb20NCg0KPiBGcm9tOiBUb20gSGVyYmVydCA8 dG9tQGhlcmJlcnRsYW5kLmNvbT4NCj4gU3ViamVjdDogUmU6IFtSdGctZHQtZW5jYXAtY29uc2lk ZXJhdGlvbnNdIG92ZXJsYXkgZW5jYXBzdWxhdGlvbiBncm91cA0KPiBEYXRlOiBTZXB0ZW1iZXIg MjQsIDIwMTUgYXQgMTI6NTQ6NDEgUE0gUERUDQo+IFRvOiAiRnJlZCBCYWtlciAoZnJlZCkiIDxm cmVkQGNpc2NvLmNvbT4NCj4gDQo+IEhpIEZyZWQsDQo+IA0KPiBJJ2QgbGlrZSB0byBnaXZlIHlv dSBhbiB1cGRhdGUgb24gSUxBLg0KPiANCj4gV2UgcHVzaGVkIGFuIGluaXRpYWwgaW1wbGVtZW50 YXRpb24gdG8gdXBzdHJlYW0gDQo+IGh0dHBzOi8vbHduLm5ldC9BcnRpY2xlcy82NTQ1NDAvLiBJ IGhhdmUgYSBjb3VwbGUgb2YgbW9yZSBwYXRjaGVzIHRvIA0KPiBnZXQgaW4sIGJ1dCB0aGlzIHdp bGwgZ2V0IHVzIHRvIGEgcHJldHR5IHBlcmZvcm1hbnQgZGF0YSBwYXRoIChtdWNoIA0KPiBiZXR0 ZXIgdGhhbiB3aGF0IHdlJ2xsIGdldCBmcm9tIHRyYWRpdGlvbmFsIGVuY2Fwc3VsYXRpb24pLg0K PiANCj4gSW50ZXJuYWxseSAoQEZCKSwgd2UgYXJlIGNvbW1lbmNpbmcgY2FuYXJ5IGRlcGxveW1l bnRzLiBUaGVyZSB3YXMgYW4gDQo+IGludGVyZXN0aW5nIGRlYmF0ZSBvbiB3aGV0aGVyIHRvIHVz ZSBVTEEgb3IgZ2V0IGEgbGFyZ2VyIGFkZHJlc3MgDQo+IGFsbG9jYXRpb24gKHRoZSBsYXR0ZXIg d29uKSwgYnV0IHNvIGZhciB0aGlzIGFwcHJvYWNoIHNlZW1zIGZlYXNpYmxlLg0KPiANCj4gT25l IGRlc2lnbiBjaGFuZ2UsIHdoaWNoIEkgdGhpbmsgbWF5IGJlIGFsb25nIHRoZSBsaW5lcyBvZiB5 b3Ugd2VyZSANCj4gYXNraW5nLCBpcyB0aGF0IHdlIHdpbGwgYWxsb3cgdW50cmFuc2xhdGVkIGFk ZHJlc3NlcyB0byBiZSByb3V0YWJsZS4NCj4gVW50cmFuc2xhdGVkIHBhY2tldHMgd291bGQgYmUg cm91dGVkIHRvIHNvbWUgaW50ZXJtZWRpYXRlIGRldmljZSBpbiANCj4gdGhlIG5ldHdvcmsgd2hp Y2ggcGVyZm9ybSB0aGUgdHJhbnNsYXRpb24gYW5kIGZvcndhcmQgcGFja2V0IHRvIHRoZSANCj4g bG9jYXRpb24gb2YgdGhlIHZpcnR1YWwgbm9kZS4gV2UnbGwgaGF2ZSB0aGVzZSBub2RlcyBiZSBh YmxlIHRvIHNlbmQgDQo+IHNvbWV0aGluZyBsaWtlIGFuIElDTVAgcmVkaXJlY3QgdG8gdGhlIHNv dXJjZSB0byBlbGltaW5hdGUgdGhlIA0KPiB0cmlhbmd1bGFyIHJvdXRpbmcgZm9yIGZ1dHVyZSBw YWNrZXRzLg0KPiANCj4gSSdtIHBsYW5uaW5nIG9uIHVwZGF0aW5nIHRoZSBJTEEgZHJhZnQgZm9y IElFVEYuIEkgY2FuIHByZXNlbnQgdGhhdCANCj4gd29yayBhdCBudm8zLCBidXQgZG8geW91IHRo aW5rIHRoZXJlIHdvdWxkIGJlIGFueSBpbnRlcmVzdCBvciByZWFzb24gDQo+IHRvIHRha2UgdGhp cyB0byBhbiBJUHY2IFdHPw0KPiANCj4gVGhhbmtzLA0KPiBUb20NCj4gDQo+IE9uIE1vbiwgQXBy IDI3LCAyMDE1IGF0IDE6NDEgUE0sIEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbT4g d3JvdGU6DQo+PiANCj4+PiBPbiBBcHIgMjcsIDIwMTUsIGF0IDE6MzEgUE0sIFRvbSBIZXJiZXJ0 IDx0b21AaGVyYmVydGxhbmQuY29tPiB3cm90ZToNCj4+PiBJbiBJTEEgdGhlIHRyYW5zbGF0aW9u IGlzIGFsd2F5cyBzeW1tZXRyaWMgYmV0d2VlbiBzZW5kZXIgYW5kIHJlY2VpdmVyLCBhbmQgdGhl IHRyYW5zbGF0aW9uIGlzIHRyYW5zcGFyZW50IHRvIHRoZSB1c2VyIGluIHRoZSBzYW1lIHdheSB0 aGF0IE5WIGVuY2Fwc3VsYXRpb24gd291bGQgYmUuIEFwcGxpY2F0aW9ucyBhdCBib3RoIGVuZHBv aW50cyBzZWUgdGhlIHNhbWUgYWRkcmVzc2VzIGZvciB0aGUgY29ubmVjdGlvbiAoU0lSIGFkZHJl c3NlcyBpbiB0aGUgZHJhZnQpLCBhbmQgdGhlc2UgYXJlIHdoYXQgaXMgcHV0IGludG8gRE5TLiBN YW55IG9mIHRoZSBjb21tdW5pY2F0aW9uIHNjZW5hcmlvcyBzaG93aW5nIHRoaXMgYXJlIGluIHNl Y3Rpb24gNCBvZiB0aGUgSUxBIGRyYWZ0LiBPbiB0aGUgd2lyZSBpbnRlcm1lZGlhdGUgZGV2aWNl cyB3b3VsZCBzZWUgdGhlIHRyYW5zbGF0ZWQgYWRkcmVzc2VzLg0KPj4gDQo+PiBJbiB0aGUgZGF0 YSBwbGFuZSwgYXQgdGhlIG5ldHdvcmsgbGF5ZXIuIFRoZSByZWRpcmVjdCBpcyBpbiBhbiBhcHBs aWNhdGlvbiBtZXNzYWdlIGFuZCBtaWdodCB3ZWxsIGJlIGVuY3J5cHRlZC4gQnV0IHRoZSBzZW5k ZXIgb2YgdGhlIHJlZGlyZWN0IGhhcyB0byBnZXQgaXQgdG8gdGhlIHJlY2VpdmVyLCBhbmQgZ2l2 ZSBhbiBhZGRyZXNzIGZvciB0aGUgdGhpcmQgcGFydHkgdGhhdCB0aGUgcmVjZWl2ZXIgY2FuIHVz ZS4NCj4+IA0KPj4+IFRoZSBwcm9ibGVtIHdlIGFyZSB0cnlpbmcgdG8gc29sdmUgaW4gdmlydHVh bGl6aW5nIGRhdGEgY2VudGVyIHRhc2tzIGlzIGhvdyB0byBhbGxvdyB0YXNrIEEgb24gcGh5c2lj YWwgaG9zdCBYIHRvIGNvbW11bmljYXRlIHdpdGggdGFzayBCIG9uIHBoeXNpY2FsIGhvc3QgWTsg YW5kIHRoZW4gaG93IHRvIGNvbnRpbnVlIGNvbW11bmljYXRpb25zIHdoZW4gdGFzayBCIG1vdmVz IHRvIHBoeXNpY2FsIGhvc3QgWi4gSSBndWVzcyB0aGlzIGNvdWxkIGJlIGNvbnNpZGVyZWQgYSBy ZWFjaGFiaWxpdHksIGNvbm5lY3Rpdml0eSwgcm91dGFiaWxpdHksIG9yIGF1dGhvcml6YXRpb24g cHJvYmxlbSBkZXBlbmRpbmcgb24gaG93IHlvdSB3YW50IHRvIGxvb2sgYXQgaXQuDQo+PiANCj4+ IFllcy4gSXTigJlzIG9uZSBvZiB0aGUgZmlyc3QgdGhyZWUgYWZ0ZXIgaXQgbW92ZXMgYW5kIGJl Zm9yZSBpdCBpcyByZW51bWJlcmVkLiBCZWZvcmUgbW92aW5nIGFuZCBhZnRlciByZW51bWJlcmlu ZywgaXQgaXMganVzdCBhbiBhdXRob3JpemF0aW9uIHByb2JsZW0sIElNSE8uDQo+PiANCj4+PiBJ biBtdWx0aS10ZW5hbmN5LCB3ZSBoYXZlIGEgcmVxdWlyZW1lbnQgZm9yIGlzb2xhdGlvbiBiZXR3 ZWVuIHRlbmFudHMuIElmIHRyYWZmaWMgY3Jvc3NlcyBiZXR3ZWVuIHRlbmFudCBuZXR3b3JrcyB3 aXRob3V0IGF1dGhvcml6YXRpb24gdGhpcyBpcyBmdW5kYW1lbnRhbGx5IGJhZCwgc28gd2UgbmVl ZCBzdHJvbmcgZ3VhcmFudGVlcyAobWF5YmUgdGhpcyBpcyB3aGF0IHlvdSBtZWFuIGJ5IGF1dGhv cml6YXRpb24gcHJvYmxlbT8pLg0KPj4gDQo+PiBZZXMNCj4+IA0KPj4+IFRoZSBWTklEIGlzIGEg bWVjaGFuaXNtIG9mIGlzb2xhdGlvbiwgYnV0IG5vdCB0eXBpY2FsbHkgc2VsZi1hdXRoZW50aWNh dGVkLg0KPj4gDQo+PiBJZiBpdOKAmXMgaW4gdGhlIElQdjYgSUlELCBpdOKAmXMgYXNzaWduZWQg YnkgdGhlIG9yY2hlc3RyYXRvciwgYW5kIHRoZSBCQ1AgMzggZmlsdGVyIGluIHRoZSB2U3dpdGNo IGVuZm9yY2VzIGl0cyB1c2UuIFRoYXTigJlzIHRoZSBzYW1lIHdheSBWTEFOIG51bWJlcnMgb3Ig d2hhdGV2ZXIgYXJlIHVzZWQuIFdoaWNoIGlzIHRvIHNheSB0aGF0IGl04oCZcyBhdCBsZWFzdCBh cyBzZWN1cmUgYXMgdXNpbmcgYSBWTEFOLCBnaXZlbiB0YXQgdGhlIG9yY2hlc3RyYXRvciBpbnN0 YWxscyB0aGUgY29ycmVjdCBBQ0xzLg0KPj4gDQo+Pj4gSW4gR1VFLCB3ZSBhZGRlZCBhIHNlY3Vy aXR5IG9wdGlvbiB0aGF0IGFsbG93cyBzaGFyZWQgY29va2llLCBzZWN1cmUgaGFzaCwgZXRjLiBV bmZvcnR1bmF0ZWx5LCBJIGhhdmVuJ3QgZmlndXJlZCBvdXQgaG93IHRvIGFkZCB0aGF0IGluIElM QSBhbmQgd2l0aG91dCBzZWN1cml0eSBpdCBtYWtlcyBsYXJnZSBzY2FsZSBkZXBsb3ltZW50IGZv ciB0aGUgbXVsdGkgdGVuYW50IHVzZSBjYXNlIHByb2JsZW1hdGljICh0aGUgbGFjayBvZiBhIHNl Y3VyZWQgVk5JRCBtYWRlIFZMWEFOIGFuZCBOVi1HUkUgbm9uIHN0YXJ0ZXJzIGZvciB1cykuIEkg Y29uc2lkZXJlZCBmbG93IGxhYmVsIGZvciBzZWN1cml0eSBiaXRzIGluIElMQSwgYnV0IG1heWJl IHRoaXMgY291bGQgYmUgc29tZXRoaW5nIGluIHRoZSBoZWFkZXIgb3B0aW9ucyBzaW1pbGFyIHRv IHdoYXQgeW91IGRlc2NyaWJlIGluIHNlY3Rpb24gQi4yIChhbHRob3VnaCBJIGFtIGxlZXJ5IG9m IHVzaW5nIGFueSBzb3J0IG9mIElQIG9wdGlvbnMgZHVlIHRvIGxhY2sgb2YgbWlkZGxlYm94IHN1 cHBvcnQpLg0KPj4gDQo+PiBJIHRoaW5rIEnigJltIHRlbGxpbmcgeW91IGhvdyB0byBkbyB0aGF0 Li4uDQo+PiANCj4+Pj4gU28sIHJlZHJhdyBteSBzZWN0aW9uIEIuNSBpbiBJTE5QIHRlcm1zLiBT dXBwb3NlIHdlIHB1dCB0aGUgVk5JRCAod2hpY2ggSSBjYWxsIGEgdGVuYW50IG51bWJlcikgaW4g dGhlIElJRCwgYW5kIHRyZWF0IHRoZSBwcmVmaXggYXMgYSBsb2NhdG9yIGFzIElMTlAgZG9lcy4g RGlkIHdlIGFjY29tcGxpc2ggeW91ciBnb2FsPyBJIHRoaW5rIHdlIGRpZCwgYW5kIHdlIG1hZGUg aXQgYmUgd2l0aG91dCB0aGUgY291cGxpbmcsIGFuZCB3ZSBtYWRlIHRoZSBBQ0wgY29uZmlndXJh dGlvbiAod2hpY2ggaXMgdGhlIGF1dGhvcml6YXRpb24gdmVyaWZpY2F0aW9uKSBjb25zaXN0ZW50 IHdoZXRoZXIgaW4gb25lIGNoYXNzaXMsIHR3byBkYXRhIGNlbnRlcnMsIG9yIGEgaHlicmlkIGNs b3VkIHdpdGggbXVsdGlwbGUgb3BlcmF0b3JzLg0KPj4+IA0KPj4+IFRoZSBWTklEICh0ZW5hbnQg bnVtYmVyKSBpcyBhbHJlYWR5IGluIHRoZSBpZGVudGlmaWVyIChJSUQgcGFydCkgaW4gSUxBLiBJ IGRvbid0IHNlZSBhbnkgcmVhc29uIHdoeSBBQ0xzIGNhbid0IGJlIGNyZWF0ZWQgZm9yIHRoYXQu IE9ubHkgdGhlIGxvY2F0b3IgcGFydCBpcyB0cmFuc2xhdGVkIG9uIHRoZSB3aXJlLCBzbyB0aGUg Vk5JRCBpcyBhbHNvIHZpc2libGUgdG8gaW50ZXJtZWRpYXRlIGRldmljZXMuDQo+PiANCj4+IEJV VCBUSEUgTE9DQVRPUiBJUyBUUkFOU0xBVEVELCB3aGljaCBicmluZ3MgbWUgYmFjayB0byBteSBw ZXJ2aW91cyBlbWFpbC4gSW4gYW4gSUxOUCBzeXN0ZW0sIGl0IGRvZXNu4oCZdCBuZWVkIHRvIGJl LiBXaHkgbm90IGp1c3QgdXNlIHRoZSBJTE5QIGFkZHJlc3M/IEEgbG9uZyBsaXN0IG9mIGlzc3Vl cyBnbyBhd2F5Lg0KPj4gDQoNCg== From nobody Mon Sep 28 14:09:09 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD811B33CE for ; Mon, 28 Sep 2015 14:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxyqB5o_UArh for ; Mon, 28 Sep 2015 14:09:06 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (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 295901B33C9 for ; Mon, 28 Sep 2015 14:09:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t8SL966d006935; Mon, 28 Sep 2015 16:09:06 -0500 Received: from XCH-BLV-206.nw.nos.boeing.com (xch-blv-206.nw.nos.boeing.com [10.57.37.16]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t8SL8tWm006254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 28 Sep 2015 16:08:56 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-206.nw.nos.boeing.com ([169.254.6.228]) with mapi id 14.03.0235.001; Mon, 28 Sep 2015 14:08:53 -0700 From: "Templin, Fred L" To: Joe Touch , Gert Doering , "Mikael Abrahamsson" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ+hsfecS+NCAn7EaALDKKzLdmeJ5SR80QgACXCYD//47O8A== Date: Mon, 28 Sep 2015 21:08:53 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F0FB67@XCH-BLV-504.nw.nos.boeing.com> References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <20150928175220.GW84167@Space.Net> <56098638.3070000@isi.edu> <2134F8430051B64F815C691A62D9831832F0F8EA@XCH-BLV-504.nw.nos.boeing.com> <5609A751.7050708@isi.edu> In-Reply-To: <5609A751.7050708@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 21:09:08 -0000 Hi Joe, > If the tunnel is created using a virtual interface, then it's possible > to assign an address and never need to release that interface. That is what I am saying, which no one else has been saying - that tunneling can be used to maintain one or more fixed (stable) address that never change even if the underlying interface addresses change. FWIW, if you don't like the terms "nomadic", "sustained" and "fixed" the place to comment on that is in the DMM mailing list. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, September 28, 2015 1:47 PM > To: Templin, Fred L; Gert Doering; Mikael Abrahamsson > Cc: touch@isi.edu; v6ops list > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC >=20 > Hi, Fred, >=20 > On 9/28/2015 12:02 PM, Templin, Fred L wrote: > > Hi Joe, > > > > There is an ongoing discussion in the Distributed Mobility Management (= DMM) > > working group where they are documenting three different address types: > > > > 1) Nomadic > > 2) Sustained > > 3) Fixed (or stable) > > > > A nomadic address is one that is discovered when the app connects over > > a network interface. >=20 > TCP doesn't bind to an "interface"; it either binds to INADDR_ANY or to > a specific address. > When INADDR_ANY is indicated, an algorithm selects the source IP > address based on a set of rules - e.g., as per RFC6724 for IPv6. That IP > address is determined by the outgoing interface selected by the > forwarding rules for the destination address coupled with some other > context and policy information. >=20 > I.e., TCP doesn't pick an interface; the OS does -- *because* the app > has indicated that it wants this operation. >=20 > (RFC793 talks about this as well - TCP binds to an address, but not an > interface per se). >=20 > > If the interface goes down and comes back up, or if > > the node switches over to using a different interface, then the origina= l > > address is deprecated and the app is obliged to use a new address. >=20 > If the OS indicates that the *address* (note - not the interface) is no > longer available, then it might be reasonable to signal the socket to > fail. But that would make the TCP connection fail; whether the app will > try with a *new* socket on a new address depends on how the app is writte= n. >=20 > > This > > is what typically happens when a handset switches over from WiFI to > > Cellular. >=20 > Isn't that just "one network interface coming up and another going > down"? Why is that useful to describe as "nomadic"? What makes an > interface - or an address - nomadic? >=20 > > A fixed (or stable) address is one that never changes even if the under= lying > > network interfaces change. An interface can go down and come back up > > with a different address, or the node can switch over to using a differ= ent > > interface, but the fixed address remains unchanged and the app does not > > need to reconnect. This is the type of address the node gets when it > > configures a tunnel (or, VPN) over the underlying network interfaces. S= o, > > if you want an app to survive a network handover, this is the type of > > arrangement you should use. > > > > A "sustained" address is one that remains unchanged during the app's > > connection lifetime. But, after the connection terminates, the app may > > discover and utilize a different sustained address for future connectio= ns. > > Personally, I believe this type of address is mythical as I don't see a= ny > > practical way of implementing it. >=20 > What do you call a WiFi interface that can go down, come back, and gets > the same IP - and then all applications that were active prior to the > interruption come back? That's how WiFi works in Windows, FWIW. >=20 > AFAICT: >=20 > a) interfaces go down, taking addresses with them > b) interfaces come up, yielding either new addresses or reusing > previously assigned ones > c) interfaces stay up >=20 > I don't know what the difference between these is until either you see a > change. A-priori, you can't really know the difference - a cellular > interface might sit in one place and be on all the time (e.g., to > support smart power meters). A tunnel can be torn down. >=20 > And TCP apps that set the local address to INADDR_ANY fall into your > "sustained address" category. >=20 > I don't see any of this as useful to describe in terms of addresses or > interfaces. >=20 > > IMHO, if you want a stable address that never changes, and/or the > > ability to configure multiple addresses, use DHCPv6 PD over tunnels. >=20 > If the tunnel is created using a virtual interface, then it's possible > to assign an address and never need to release that interface. Tunnels > can also be created addresses bound to existing physical interfaces, and > those tunnels would come down when the interface did, however. >=20 > Joe >=20 > >> -----Original Message----- > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > >> Sent: Monday, September 28, 2015 11:26 AM > >> To: Gert Doering; Mikael Abrahamsson > >> Cc: v6ops list > >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC > >> > >> > >> > >> On 9/28/2015 10:52 AM, Gert Doering wrote: > >>> Hi, > >>> > >>> On Fri, Sep 25, 2015 at 07:46:45PM +0200, Mikael Abrahamsson wrote: > >>>> So here we again have the problem that most of the IETF protocol gro= ups do > >>>> not have an "*ops" group that actually deals with real world interac= tion. > >>>> v6ops seems to be one of the few. Why don't we have more of them? > >>> > >>> Because the amount of real-world exposure is not something IETF would > >>> be able to stomach. As is evident from this thread. > >> > >> Shall we open a thread on process management? Memory garbage collectio= n? > >> > >> All of these are real-world issues warranting serious consideration. > >> > >> A network interface goes down. That's a network interface event. This = is > >> an issue in the RTG and INT areas, but the reason it's not a transport > >> issue is clear - nothing changed as far as the transport protocol is > >> concerned. > >> > >> The real disconnect here is "when an interface goes away, it *takes aw= ay > >> my IP address". > >> > >> No, it really doesn't. DCHP revocation can take away an IP address, as > >> does IPv6 duplicate address detection. But these are network events, n= ot > >> transport events. An interface going down may or may not take down the > >> corresponding IP address. > >> > >> So what exactly would you have the OS do? > >> > >> a) the OS socket could disappear when the IP address does > >> we've already pointed out how that would negatively > >> impact apps when a device has intermittent connectivity > >> > >> b) the OS could tell the app that a write would fail > >> but writes to TCP are buffered; they're not necessarily > >> directly correlated to segment emission unless PSH is set > >> > >> Recall that the IETF used to indicate that APIs were off-limits; it ha= s > >> since admitted that at least abstract APIs (such as are spec'd in > >> RFC793) are in-scope. > >> > >> However, what's clear about the cases above is that this is neither an > >> abstract API issue nor a protocol issue. It's an OS implementation > >> issue. It may be an important one, as is the issue of "how to write a > >> robust app that behaves as the user wants". > >> > >> But the IETF isn't where that's discussed. It's taught in network clas= ses. > >> > >> Joe > >> > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 28 14:22:21 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ACD1B33C9 for ; Mon, 28 Sep 2015 14:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11G0cINPdI3y for ; Mon, 28 Sep 2015 14:22:17 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9655B1B33F8 for ; Mon, 28 Sep 2015 14:22:13 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t8SLLmQF019704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Sep 2015 14:21:49 -0700 (PDT) To: "Templin, Fred L" , Gert Doering , Mikael Abrahamsson References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <20150928175220.GW84167@Space.Net> <56098638.3070000@isi.edu> <2134F8430051B64F815C691A62D9831832F0F8EA@XCH-BLV-504.nw.nos.boeing.com> <5609A751.7050708@isi.edu> <2134F8430051B64F815C691A62D9831832F0FB67@XCH-BLV-504.nw.nos.boeing.com> From: Joe Touch Message-ID: <5609AF6C.6090103@isi.edu> Date: Mon, 28 Sep 2015 14:21:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <2134F8430051B64F815C691A62D9831832F0FB67@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t8SLLmQF019704 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 21:22:19 -0000 On 9/28/2015 2:08 PM, Templin, Fred L wrote: > Hi Joe, > >> If the tunnel is created using a virtual interface, then it's possible >> to assign an address and never need to release that interface. > > That is what I am saying, which no one else has been saying - that > tunneling can be used to maintain one or more fixed (stable) address > that never change even if the underlying interface addresses change. Oh, absolutely. > FWIW, if you don't like the terms "nomadic", "sustained" and "fixed" > the place to comment on that is in the DMM mailing list. Sorry - I don't have enough cycles (it's not clear there *are* enough cycles to fix every such issue in the IETF). Joe >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Monday, September 28, 2015 1:47 PM >> To: Templin, Fred L; Gert Doering; Mikael Abrahamsson >> Cc: touch@isi.edu; v6ops list >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC >> >> Hi, Fred, >> >> On 9/28/2015 12:02 PM, Templin, Fred L wrote: >>> Hi Joe, >>> >>> There is an ongoing discussion in the Distributed Mobility Management (DMM) >>> working group where they are documenting three different address types: >>> >>> 1) Nomadic >>> 2) Sustained >>> 3) Fixed (or stable) >>> >>> A nomadic address is one that is discovered when the app connects over >>> a network interface. >> >> TCP doesn't bind to an "interface"; it either binds to INADDR_ANY or to >> a specific address. >> When INADDR_ANY is indicated, an algorithm selects the source IP >> address based on a set of rules - e.g., as per RFC6724 for IPv6. That IP >> address is determined by the outgoing interface selected by the >> forwarding rules for the destination address coupled with some other >> context and policy information. >> >> I.e., TCP doesn't pick an interface; the OS does -- *because* the app >> has indicated that it wants this operation. >> >> (RFC793 talks about this as well - TCP binds to an address, but not an >> interface per se). >> >>> If the interface goes down and comes back up, or if >>> the node switches over to using a different interface, then the original >>> address is deprecated and the app is obliged to use a new address. >> >> If the OS indicates that the *address* (note - not the interface) is no >> longer available, then it might be reasonable to signal the socket to >> fail. But that would make the TCP connection fail; whether the app will >> try with a *new* socket on a new address depends on how the app is written. >> >>> This >>> is what typically happens when a handset switches over from WiFI to >>> Cellular. >> >> Isn't that just "one network interface coming up and another going >> down"? Why is that useful to describe as "nomadic"? What makes an >> interface - or an address - nomadic? >> >>> A fixed (or stable) address is one that never changes even if the underlying >>> network interfaces change. An interface can go down and come back up >>> with a different address, or the node can switch over to using a different >>> interface, but the fixed address remains unchanged and the app does not >>> need to reconnect. This is the type of address the node gets when it >>> configures a tunnel (or, VPN) over the underlying network interfaces. So, >>> if you want an app to survive a network handover, this is the type of >>> arrangement you should use. >>> >>> A "sustained" address is one that remains unchanged during the app's >>> connection lifetime. But, after the connection terminates, the app may >>> discover and utilize a different sustained address for future connections. >>> Personally, I believe this type of address is mythical as I don't see any >>> practical way of implementing it. >> >> What do you call a WiFi interface that can go down, come back, and gets >> the same IP - and then all applications that were active prior to the >> interruption come back? That's how WiFi works in Windows, FWIW. >> >> AFAICT: >> >> a) interfaces go down, taking addresses with them >> b) interfaces come up, yielding either new addresses or reusing >> previously assigned ones >> c) interfaces stay up >> >> I don't know what the difference between these is until either you see a >> change. A-priori, you can't really know the difference - a cellular >> interface might sit in one place and be on all the time (e.g., to >> support smart power meters). A tunnel can be torn down. >> >> And TCP apps that set the local address to INADDR_ANY fall into your >> "sustained address" category. >> >> I don't see any of this as useful to describe in terms of addresses or >> interfaces. >> >>> IMHO, if you want a stable address that never changes, and/or the >>> ability to configure multiple addresses, use DHCPv6 PD over tunnels. >> >> If the tunnel is created using a virtual interface, then it's possible >> to assign an address and never need to release that interface. Tunnels >> can also be created addresses bound to existing physical interfaces, and >> those tunnels would come down when the interface did, however. >> >> Joe >> >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch >>>> Sent: Monday, September 28, 2015 11:26 AM >>>> To: Gert Doering; Mikael Abrahamsson >>>> Cc: v6ops list >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC >>>> >>>> >>>> >>>> On 9/28/2015 10:52 AM, Gert Doering wrote: >>>>> Hi, >>>>> >>>>> On Fri, Sep 25, 2015 at 07:46:45PM +0200, Mikael Abrahamsson wrote: >>>>>> So here we again have the problem that most of the IETF protocol groups do >>>>>> not have an "*ops" group that actually deals with real world interaction. >>>>>> v6ops seems to be one of the few. Why don't we have more of them? >>>>> >>>>> Because the amount of real-world exposure is not something IETF would >>>>> be able to stomach. As is evident from this thread. >>>> >>>> Shall we open a thread on process management? Memory garbage collection? >>>> >>>> All of these are real-world issues warranting serious consideration. >>>> >>>> A network interface goes down. That's a network interface event. This is >>>> an issue in the RTG and INT areas, but the reason it's not a transport >>>> issue is clear - nothing changed as far as the transport protocol is >>>> concerned. >>>> >>>> The real disconnect here is "when an interface goes away, it *takes away >>>> my IP address". >>>> >>>> No, it really doesn't. DCHP revocation can take away an IP address, as >>>> does IPv6 duplicate address detection. But these are network events, not >>>> transport events. An interface going down may or may not take down the >>>> corresponding IP address. >>>> >>>> So what exactly would you have the OS do? >>>> >>>> a) the OS socket could disappear when the IP address does >>>> we've already pointed out how that would negatively >>>> impact apps when a device has intermittent connectivity >>>> >>>> b) the OS could tell the app that a write would fail >>>> but writes to TCP are buffered; they're not necessarily >>>> directly correlated to segment emission unless PSH is set >>>> >>>> Recall that the IETF used to indicate that APIs were off-limits; it has >>>> since admitted that at least abstract APIs (such as are spec'd in >>>> RFC793) are in-scope. >>>> >>>> However, what's clear about the cases above is that this is neither an >>>> abstract API issue nor a protocol issue. It's an OS implementation >>>> issue. It may be an important one, as is the issue of "how to write a >>>> robust app that behaves as the user wants". >>>> >>>> But the IETF isn't where that's discussed. It's taught in network classes. >>>> >>>> Joe >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 28 15:29:39 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BE11B3484 for ; Mon, 28 Sep 2015 15:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WctSyXWbFqZc for ; Mon, 28 Sep 2015 15:29:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EA91B3481 for ; Mon, 28 Sep 2015 15:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8914; q=dns/txt; s=iport; t=1443479375; x=1444688975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j6ohnEqbPXRxpUCze9r/TrOzTlv3Recl+grc7h64BFI=; b=TE9v6TYOvHCvzAxaCyJJ7fUAhEurMKjySpzHjPo/EHA/IKdKEa6GReQu 0AfzNAtz/R077yoiMiP2Njpe7GAcfi0/jB6ptxRnKorF6+D4nvZvU245m HmxO0AXVmRob35GRqKhn0FFmMeRfTDkhtlYJ5Qoc2RkJOMtBjMj9AACh8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQBSvglW/5xdJa1dgyRUaQaDJLoVAQ2Be4V5AhyBMjgUAQEBAQEBAYEKhCQBAQEDASMRRQUHBAIBCBEDAQEBAQICBh0DAgICMBQBCAgCBAENBQgTBIgHCA22dZRUAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIopOhCoRASAxBwaCYy+BFAWFfIE6jjoBhC9liUmRLoRVg20fAQFCghABHIFUcYdiOoEFAQEB X-IronPort-AV: E=Sophos;i="5.17,604,1437436800"; d="scan'208";a="32814945" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 28 Sep 2015 22:29:34 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t8SMTYqE028546 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 22:29:34 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 17:29:33 -0500 Received: from xhc-aln-x08.cisco.com (173.36.12.82) by xch-aln-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 28 Sep 2015 17:29:33 -0500 Received: from xmb-rcd-x06.cisco.com ([169.254.6.153]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0248.002; Mon, 28 Sep 2015 17:29:33 -0500 From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , v6ops list Thread-Topic: [v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group Thread-Index: AQHQ9wLa6QJAXiB3eEW5Bf0xE00y7J5Si8sA Date: Mon, 28 Sep 2015 22:29:32 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B891690A401@xmb-rcd-x06.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Dino Farinacci \(farinacci@gmail.com\)" Subject: Re: [v6ops] Fwd: [Rtg-dt-encap-considerations] overlay encapsulation group X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 22:29:38 -0000 VG9tLA0KDQpXaHkgZGlkIHlvdSBub3QgY29uc2lkZXIgTElTUCAocmZjNjgzMCkgYXMgYSBzb2x1 dGlvbiB0byB5b3VyIHByb2JsZW0/IElzIGl0IGJlY2F1c2UgTElTUCBpcyBhbiBvdmVybGF5IGFu ZCB5b3UgcHJlZmVycmVkIG5hdGl2ZSB0cmFuc3BvcnQ/ICBZb3VyIGRvY3VtZW50IGRvZXMgb3Zl cmxheSBJUHY0IGRhdGEgaW4gYW4gSVB2NiB0dW5uZWwgYW5kIHRodXMgdGhlIGlwdjQgc29sdXRp b24gY291bGQganVzdCBhcyB3ZWxsIHVzZSBMSVNQPw0KDQpEaW5vLA0KDQpXZSBhcmUgZGlzY3Vz c2luZyB0aGlzIGRvY3VtZW50IHRoYXQgVG9tIGhhcyBhdXRob3JlZC4NCg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhlcmJlcnQtbnZvMy1pbGEtMDANCg0KVGhhbmtzLA0KDQpI ZW1hbnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzIFttYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZyZWQgQmFrZXIgKGZyZWQpDQpT ZW50OiBNb25kYXksIFNlcHRlbWJlciAyOCwgMjAxNSA0OjEyIFBNDQpUbzogdjZvcHMgbGlzdA0K U3ViamVjdDogW3Y2b3BzXSBGd2Q6IFtSdGctZHQtZW5jYXAtY29uc2lkZXJhdGlvbnNdIG92ZXJs YXkgZW5jYXBzdWxhdGlvbiBncm91cA0KDQpSdW5uaW5nIGEgcXVlc3Rpb24gYnkgdGhlIGxpc3Qu IFRvbSBhbmQgSSBnb3QgdG8gdGFsa2luZyBhYm91dCB0aGlzIGJlY2F1c2UgSSBwcm9wb3NlZCBh biBhcHByb2FjaCB0byBJUHY2IG5ldHdvcmtpbmcgZm9yIE9wZW5TdGFjayAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJha2VyLW9wZW5zdGFjay1pcHY2LW1vZGVsKSwgYW5kIFRv bSBwcm9wb3NlZCBhIHNpbWlsYXIgYnV0IGRpZmZlcmVudCBtb2RlbCBpbiBudm8zIChkcmFmdC1o ZXJiZXJ0LW52bzMtaWxhKS4gRnJvbSB3aGF0IGhlIHNheXMsIEkgZ2F0aGVyIHRoYXQgRmFjZWJv b2sgaXMgbG9va2luZyBhdCB0cmlhbCBkZXBsb3ltZW50IG9mIGEgbW9kaWZpZWQgdmVyc2lvbiBv ZiBoaXMgYXBwcm9hY2ggdGhhdCB0YWtlcyBhbiBpbXBvcnRhbnQgc3RlcCBpbiB0aGUgZGlyZWN0 aW9uIG9mIG1pbmUuDQoNCldoYXQgSSB3b25kZXIgaXMgd2hldGhlciB0aGUgV0cgd291bGQgYmUg aW50ZXJlc3RlZCBpbiBhbiBvcGVyYXRpb25hbCBkaXNjdXNzaW9uIG9mIGRyYWZ0LWhlcmJlcnQt bnZvMy1pbGEgYW5kIEZhY2Vib29rJ3MgSVB2NiBkZXBsb3ltZW50IGF0IElFVEYgOTQ/IEFuZCBz cGVjaWZpY2FsbHksIGRvIGZvbGtzIGhhdmUgY29tbWVudHMgb24gaGlzIHVwZGF0ZWQgZHJhZnQg d2hlbiBoZSBwb3N0cyBpdD8NCg0KT24gU2VwIDI1LCAyMDE1LCBhdCAyOjEyIFBNLCBUb20gSGVy YmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbT4gd3JvdGU6DQo+IFRoYW5rcyBGcmVkLg0KPiANCj4g VGhlIElMQSBkcmFmdCBpcyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1o ZXJiZXJ0LW52bzMtaWxhLy4NCj4gDQo+IFRvbQ0KDQo+IEZyb206IFRvbSBIZXJiZXJ0IDx0b21A aGVyYmVydGxhbmQuY29tPg0KPiBTdWJqZWN0OiBSZTogW1J0Zy1kdC1lbmNhcC1jb25zaWRlcmF0 aW9uc10gb3ZlcmxheSBlbmNhcHN1bGF0aW9uIGdyb3VwDQo+IERhdGU6IFNlcHRlbWJlciAyNCwg MjAxNSBhdCAxMjo1NDo0MSBQTSBQRFQNCj4gVG86ICJGcmVkIEJha2VyIChmcmVkKSIgPGZyZWRA Y2lzY28uY29tPg0KPiANCj4gSGkgRnJlZCwNCj4gDQo+IEknZCBsaWtlIHRvIGdpdmUgeW91IGFu IHVwZGF0ZSBvbiBJTEEuDQo+IA0KPiBXZSBwdXNoZWQgYW4gaW5pdGlhbCBpbXBsZW1lbnRhdGlv biB0byB1cHN0cmVhbSANCj4gaHR0cHM6Ly9sd24ubmV0L0FydGljbGVzLzY1NDU0MC8uIEkgaGF2 ZSBhIGNvdXBsZSBvZiBtb3JlIHBhdGNoZXMgdG8gDQo+IGdldCBpbiwgYnV0IHRoaXMgd2lsbCBn ZXQgdXMgdG8gYSBwcmV0dHkgcGVyZm9ybWFudCBkYXRhIHBhdGggKG11Y2ggDQo+IGJldHRlciB0 aGFuIHdoYXQgd2UnbGwgZ2V0IGZyb20gdHJhZGl0aW9uYWwgZW5jYXBzdWxhdGlvbikuDQo+IA0K PiBJbnRlcm5hbGx5IChARkIpLCB3ZSBhcmUgY29tbWVuY2luZyBjYW5hcnkgZGVwbG95bWVudHMu IFRoZXJlIHdhcyBhbiANCj4gaW50ZXJlc3RpbmcgZGViYXRlIG9uIHdoZXRoZXIgdG8gdXNlIFVM QSBvciBnZXQgYSBsYXJnZXIgYWRkcmVzcyANCj4gYWxsb2NhdGlvbiAodGhlIGxhdHRlciB3b24p LCBidXQgc28gZmFyIHRoaXMgYXBwcm9hY2ggc2VlbXMgZmVhc2libGUuDQo+IA0KPiBPbmUgZGVz aWduIGNoYW5nZSwgd2hpY2ggSSB0aGluayBtYXkgYmUgYWxvbmcgdGhlIGxpbmVzIG9mIHlvdSB3 ZXJlIA0KPiBhc2tpbmcsIGlzIHRoYXQgd2Ugd2lsbCBhbGxvdyB1bnRyYW5zbGF0ZWQgYWRkcmVz c2VzIHRvIGJlIHJvdXRhYmxlLg0KPiBVbnRyYW5zbGF0ZWQgcGFja2V0cyB3b3VsZCBiZSByb3V0 ZWQgdG8gc29tZSBpbnRlcm1lZGlhdGUgZGV2aWNlIGluIA0KPiB0aGUgbmV0d29yayB3aGljaCBw ZXJmb3JtIHRoZSB0cmFuc2xhdGlvbiBhbmQgZm9yd2FyZCBwYWNrZXQgdG8gdGhlIA0KPiBsb2Nh dGlvbiBvZiB0aGUgdmlydHVhbCBub2RlLiBXZSdsbCBoYXZlIHRoZXNlIG5vZGVzIGJlIGFibGUg dG8gc2VuZCANCj4gc29tZXRoaW5nIGxpa2UgYW4gSUNNUCByZWRpcmVjdCB0byB0aGUgc291cmNl IHRvIGVsaW1pbmF0ZSB0aGUgDQo+IHRyaWFuZ3VsYXIgcm91dGluZyBmb3IgZnV0dXJlIHBhY2tl dHMuDQo+IA0KPiBJJ20gcGxhbm5pbmcgb24gdXBkYXRpbmcgdGhlIElMQSBkcmFmdCBmb3IgSUVU Ri4gSSBjYW4gcHJlc2VudCB0aGF0IA0KPiB3b3JrIGF0IG52bzMsIGJ1dCBkbyB5b3UgdGhpbmsg dGhlcmUgd291bGQgYmUgYW55IGludGVyZXN0IG9yIHJlYXNvbiANCj4gdG8gdGFrZSB0aGlzIHRv IGFuIElQdjYgV0c/DQo+IA0KPiBUaGFua3MsDQo+IFRvbQ0KPiANCj4gT24gTW9uLCBBcHIgMjcs IDIwMTUgYXQgMTo0MSBQTSwgRnJlZCBCYWtlciAoZnJlZCkgPGZyZWRAY2lzY28uY29tPiB3cm90 ZToNCj4+IA0KPj4+IE9uIEFwciAyNywgMjAxNSwgYXQgMTozMSBQTSwgVG9tIEhlcmJlcnQgPHRv bUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KPj4+IEluIElMQSB0aGUgdHJhbnNsYXRpb24gaXMg YWx3YXlzIHN5bW1ldHJpYyBiZXR3ZWVuIHNlbmRlciBhbmQgcmVjZWl2ZXIsIGFuZCB0aGUgdHJh bnNsYXRpb24gaXMgdHJhbnNwYXJlbnQgdG8gdGhlIHVzZXIgaW4gdGhlIHNhbWUgd2F5IHRoYXQg TlYgZW5jYXBzdWxhdGlvbiB3b3VsZCBiZS4gQXBwbGljYXRpb25zIGF0IGJvdGggZW5kcG9pbnRz IHNlZSB0aGUgc2FtZSBhZGRyZXNzZXMgZm9yIHRoZSBjb25uZWN0aW9uIChTSVIgYWRkcmVzc2Vz IGluIHRoZSBkcmFmdCksIGFuZCB0aGVzZSBhcmUgd2hhdCBpcyBwdXQgaW50byBETlMuIE1hbnkg b2YgdGhlIGNvbW11bmljYXRpb24gc2NlbmFyaW9zIHNob3dpbmcgdGhpcyBhcmUgaW4gc2VjdGlv biA0IG9mIHRoZSBJTEEgZHJhZnQuIE9uIHRoZSB3aXJlIGludGVybWVkaWF0ZSBkZXZpY2VzIHdv dWxkIHNlZSB0aGUgdHJhbnNsYXRlZCBhZGRyZXNzZXMuDQo+PiANCj4+IEluIHRoZSBkYXRhIHBs YW5lLCBhdCB0aGUgbmV0d29yayBsYXllci4gVGhlIHJlZGlyZWN0IGlzIGluIGFuIGFwcGxpY2F0 aW9uIG1lc3NhZ2UgYW5kIG1pZ2h0IHdlbGwgYmUgZW5jcnlwdGVkLiBCdXQgdGhlIHNlbmRlciBv ZiB0aGUgcmVkaXJlY3QgaGFzIHRvIGdldCBpdCB0byB0aGUgcmVjZWl2ZXIsIGFuZCBnaXZlIGFu IGFkZHJlc3MgZm9yIHRoZSB0aGlyZCBwYXJ0eSB0aGF0IHRoZSByZWNlaXZlciBjYW4gdXNlLg0K Pj4gDQo+Pj4gVGhlIHByb2JsZW0gd2UgYXJlIHRyeWluZyB0byBzb2x2ZSBpbiB2aXJ0dWFsaXpp bmcgZGF0YSBjZW50ZXIgdGFza3MgaXMgaG93IHRvIGFsbG93IHRhc2sgQSBvbiBwaHlzaWNhbCBo b3N0IFggdG8gY29tbXVuaWNhdGUgd2l0aCB0YXNrIEIgb24gcGh5c2ljYWwgaG9zdCBZOyBhbmQg dGhlbiBob3cgdG8gY29udGludWUgY29tbXVuaWNhdGlvbnMgd2hlbiB0YXNrIEIgbW92ZXMgdG8g cGh5c2ljYWwgaG9zdCBaLiBJIGd1ZXNzIHRoaXMgY291bGQgYmUgY29uc2lkZXJlZCBhIHJlYWNo YWJpbGl0eSwgY29ubmVjdGl2aXR5LCByb3V0YWJpbGl0eSwgb3IgYXV0aG9yaXphdGlvbiBwcm9i bGVtIGRlcGVuZGluZyBvbiBob3cgeW91IHdhbnQgdG8gbG9vayBhdCBpdC4NCj4+IA0KPj4gWWVz LiBJdOKAmXMgb25lIG9mIHRoZSBmaXJzdCB0aHJlZSBhZnRlciBpdCBtb3ZlcyBhbmQgYmVmb3Jl IGl0IGlzIHJlbnVtYmVyZWQuIEJlZm9yZSBtb3ZpbmcgYW5kIGFmdGVyIHJlbnVtYmVyaW5nLCBp dCBpcyBqdXN0IGFuIGF1dGhvcml6YXRpb24gcHJvYmxlbSwgSU1ITy4NCj4+IA0KPj4+IEluIG11 bHRpLXRlbmFuY3ksIHdlIGhhdmUgYSByZXF1aXJlbWVudCBmb3IgaXNvbGF0aW9uIGJldHdlZW4g dGVuYW50cy4gSWYgdHJhZmZpYyBjcm9zc2VzIGJldHdlZW4gdGVuYW50IG5ldHdvcmtzIHdpdGhv dXQgYXV0aG9yaXphdGlvbiB0aGlzIGlzIGZ1bmRhbWVudGFsbHkgYmFkLCBzbyB3ZSBuZWVkIHN0 cm9uZyBndWFyYW50ZWVzIChtYXliZSB0aGlzIGlzIHdoYXQgeW91IG1lYW4gYnkgYXV0aG9yaXph dGlvbiBwcm9ibGVtPykuDQo+PiANCj4+IFllcw0KPj4gDQo+Pj4gVGhlIFZOSUQgaXMgYSBtZWNo YW5pc20gb2YgaXNvbGF0aW9uLCBidXQgbm90IHR5cGljYWxseSBzZWxmLWF1dGhlbnRpY2F0ZWQu DQo+PiANCj4+IElmIGl04oCZcyBpbiB0aGUgSVB2NiBJSUQsIGl04oCZcyBhc3NpZ25lZCBieSB0 aGUgb3JjaGVzdHJhdG9yLCBhbmQgdGhlIEJDUCAzOCBmaWx0ZXIgaW4gdGhlIHZTd2l0Y2ggZW5m b3JjZXMgaXRzIHVzZS4gVGhhdOKAmXMgdGhlIHNhbWUgd2F5IFZMQU4gbnVtYmVycyBvciB3aGF0 ZXZlciBhcmUgdXNlZC4gV2hpY2ggaXMgdG8gc2F5IHRoYXQgaXTigJlzIGF0IGxlYXN0IGFzIHNl Y3VyZSBhcyB1c2luZyBhIFZMQU4sIGdpdmVuIHRhdCB0aGUgb3JjaGVzdHJhdG9yIGluc3RhbGxz IHRoZSBjb3JyZWN0IEFDTHMuDQo+PiANCj4+PiBJbiBHVUUsIHdlIGFkZGVkIGEgc2VjdXJpdHkg b3B0aW9uIHRoYXQgYWxsb3dzIHNoYXJlZCBjb29raWUsIHNlY3VyZSBoYXNoLCBldGMuIFVuZm9y dHVuYXRlbHksIEkgaGF2ZW4ndCBmaWd1cmVkIG91dCBob3cgdG8gYWRkIHRoYXQgaW4gSUxBIGFu ZCB3aXRob3V0IHNlY3VyaXR5IGl0IG1ha2VzIGxhcmdlIHNjYWxlIGRlcGxveW1lbnQgZm9yIHRo ZSBtdWx0aSB0ZW5hbnQgdXNlIGNhc2UgcHJvYmxlbWF0aWMgKHRoZSBsYWNrIG9mIGEgc2VjdXJl ZCBWTklEIG1hZGUgVkxYQU4gYW5kIE5WLUdSRSBub24gc3RhcnRlcnMgZm9yIHVzKS4gSSBjb25z aWRlcmVkIGZsb3cgbGFiZWwgZm9yIHNlY3VyaXR5IGJpdHMgaW4gSUxBLCBidXQgbWF5YmUgdGhp cyBjb3VsZCBiZSBzb21ldGhpbmcgaW4gdGhlIGhlYWRlciBvcHRpb25zIHNpbWlsYXIgdG8gd2hh dCB5b3UgZGVzY3JpYmUgaW4gc2VjdGlvbiBCLjIgKGFsdGhvdWdoIEkgYW0gbGVlcnkgb2YgdXNp bmcgYW55IHNvcnQgb2YgSVAgb3B0aW9ucyBkdWUgdG8gbGFjayBvZiBtaWRkbGVib3ggc3VwcG9y dCkuDQo+PiANCj4+IEkgdGhpbmsgSeKAmW0gdGVsbGluZyB5b3UgaG93IHRvIGRvIHRoYXQuLi4N Cj4+IA0KPj4+PiBTbywgcmVkcmF3IG15IHNlY3Rpb24gQi41IGluIElMTlAgdGVybXMuIFN1cHBv c2Ugd2UgcHV0IHRoZSBWTklEICh3aGljaCBJIGNhbGwgYSB0ZW5hbnQgbnVtYmVyKSBpbiB0aGUg SUlELCBhbmQgdHJlYXQgdGhlIHByZWZpeCBhcyBhIGxvY2F0b3IgYXMgSUxOUCBkb2VzLiBEaWQg d2UgYWNjb21wbGlzaCB5b3VyIGdvYWw/IEkgdGhpbmsgd2UgZGlkLCBhbmQgd2UgbWFkZSBpdCBi ZSB3aXRob3V0IHRoZSBjb3VwbGluZywgYW5kIHdlIG1hZGUgdGhlIEFDTCBjb25maWd1cmF0aW9u ICh3aGljaCBpcyB0aGUgYXV0aG9yaXphdGlvbiB2ZXJpZmljYXRpb24pIGNvbnNpc3RlbnQgd2hl dGhlciBpbiBvbmUgY2hhc3NpcywgdHdvIGRhdGEgY2VudGVycywgb3IgYSBoeWJyaWQgY2xvdWQg d2l0aCBtdWx0aXBsZSBvcGVyYXRvcnMuDQo+Pj4gDQo+Pj4gVGhlIFZOSUQgKHRlbmFudCBudW1i ZXIpIGlzIGFscmVhZHkgaW4gdGhlIGlkZW50aWZpZXIgKElJRCBwYXJ0KSBpbiBJTEEuIEkgZG9u J3Qgc2VlIGFueSByZWFzb24gd2h5IEFDTHMgY2FuJ3QgYmUgY3JlYXRlZCBmb3IgdGhhdC4gT25s eSB0aGUgbG9jYXRvciBwYXJ0IGlzIHRyYW5zbGF0ZWQgb24gdGhlIHdpcmUsIHNvIHRoZSBWTklE IGlzIGFsc28gdmlzaWJsZSB0byBpbnRlcm1lZGlhdGUgZGV2aWNlcy4NCj4+IA0KPj4gQlVUIFRI RSBMT0NBVE9SIElTIFRSQU5TTEFURUQsIHdoaWNoIGJyaW5ncyBtZSBiYWNrIHRvIG15IHBlcnZp b3VzIGVtYWlsLiBJbiBhbiBJTE5QIHN5c3RlbSwgaXQgZG9lc27igJl0IG5lZWQgdG8gYmUuIFdo eSBub3QganVzdCB1c2UgdGhlIElMTlAgYWRkcmVzcz8gQSBsb25nIGxpc3Qgb2YgaXNzdWVzIGdv IGF3YXkuDQo+PiANCg0K From nobody Tue Sep 29 04:54:58 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451A11A87A5 for ; Tue, 29 Sep 2015 04:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.983 X-Spam-Level: X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Digz_VmcmYmH for ; Tue, 29 Sep 2015 04:54:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289311A87A3 for ; Tue, 29 Sep 2015 04:53:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id t8TBrr45015348 for ; Tue, 29 Sep 2015 13:53:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5A1A5204C3D for ; Tue, 29 Sep 2015 13:59:02 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 487C1204DF1 for ; Tue, 29 Sep 2015 13:59:02 +0200 (CEST) Received: from [127.0.0.1] ([132.166.84.166]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t8TBroJ7023682 for ; Tue, 29 Sep 2015 13:53:52 +0200 To: v6ops@ietf.org References: <560831A4.10601@isi.edu> <56084827.4070705@gmail.com> <20150928.093256.46360250.he@uninett.no> From: Alexandre Petrescu Message-ID: <560A7BCE.3020606@gmail.com> Date: Tue, 29 Sep 2015 13:53:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150928.093256.46360250.he@uninett.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC - tethering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 11:54:33 -0000 Le 28/09/2015 09:32, Havard Eidnes a écrit : [...] > If address assignment in mobile networks is different, and there's a > specific policy preventing the re-assignment of the same IP address > to the same device should it re-surface again shortly after a network > reachability transition, that's another thing. > > I'm wondering if this forced address churn won't reduce the usability > of long-lived TCP connections from a device tehtered behind a cell > phone. Depends how that tethering is done. The tethering of RFC727 aka "64share" will break all TCP connections of the tethered device upon change in IP address of the main device - be they TCP or other. BEcause a new address assigned to the main device involves renumbering the tethering device as well. The tethering that uses Mobile IP (RFC3963) will maintain the address fixed on the tethered device despite the change in address of the main device. And this will not break the long-lived connections on the tethered device even if the main device changes its address. One can also consider other translation, routing, address updating or tunnelling techniques (non-MIP and non-64share) to achieve maintenance of long-lived TCP connections on the tethered device. Alex > > Best regards, > > - Håvard > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 29 09:26:08 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB81A1B47A0 for ; Tue, 29 Sep 2015 09:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFVVtMQKxMRw for ; Tue, 29 Sep 2015 09:26:05 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (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 126881B479F for ; Tue, 29 Sep 2015 09:26:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t8TGQ5sC010211; Tue, 29 Sep 2015 11:26:05 -0500 Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t8TGPrbT009564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 29 Sep 2015 11:25:54 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.202]) with mapi id 14.03.0235.001; Tue, 29 Sep 2015 09:25:52 -0700 From: "Templin, Fred L" To: Joe Touch , Gert Doering , "Mikael Abrahamsson" Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC Thread-Index: AQHQ+hsfecS+NCAn7EaALDKKzLdmeJ5SR80QgACXCYD//47O8IAAetwAgADIcEA= Date: Tue, 29 Sep 2015 16:25:52 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832F1070E@XCH-BLV-504.nw.nos.boeing.com> References: <56045E1F.1050306@isi.edu> <56058455.20905@isi.edu> <20150928175220.GW84167@Space.Net> <56098638.3070000@isi.edu> <2134F8430051B64F815C691A62D9831832F0F8EA@XCH-BLV-504.nw.nos.boeing.com> <5609A751.7050708@isi.edu> <2134F8430051B64F815C691A62D9831832F0FB67@XCH-BLV-504.nw.nos.boeing.com> <5609AF6C.6090103@isi.edu> In-Reply-To: <5609AF6C.6090103@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: v6ops list Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 16:26:07 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, September 28, 2015 2:22 PM > To: Templin, Fred L; Gert Doering; Mikael Abrahamsson > Cc: touch@isi.edu; v6ops list > Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC >=20 >=20 >=20 > On 9/28/2015 2:08 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> If the tunnel is created using a virtual interface, then it's possible > >> to assign an address and never need to release that interface. > > > > That is what I am saying, which no one else has been saying - that > > tunneling can be used to maintain one or more fixed (stable) address > > that never change even if the underlying interface addresses change. >=20 > Oh, absolutely. Here is how to do DHCPv6 Prefix Delegation from a host so that the host can assign multiple addresses from the delegated prefix: "AERO Clients typically configure a TUN/TAP interface [TUNTAP] as a point-to-point linkage between the IP layer and the AERO interface. The IP layer therefore sees only the TUN/TAP interface, while the AERO interface provides an intermediate conduit between the TUN/TAP interface and the underlying interfaces. AERO Clients that act as hosts assign one or more IP addresses from their ACPs to the TUN/TAP interface, i.e., and not to the AERO interface." So, the host performs DHCPv6 PD as a Requesting Router over the AERO interface but it assigns addresses derived from the delegated prefix to the TUN/TAP interface. In that way, applications can use the addresses assigned to the TUN/TAP interface without having to adhere to the weak end system model, since the AERO interface is not visible to the IP layer. Thanks - Fred fred.l.templin@boeing.com=20 > > FWIW, if you don't like the terms "nomadic", "sustained" and "fixed" > > the place to comment on that is in the DMM mailing list. >=20 > Sorry - I don't have enough cycles (it's not clear there *are* enough > cycles to fix every such issue in the IETF). >=20 > Joe >=20 > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Monday, September 28, 2015 1:47 PM > >> To: Templin, Fred L; Gert Doering; Mikael Abrahamsson > >> Cc: touch@isi.edu; v6ops list > >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC > >> > >> Hi, Fred, > >> > >> On 9/28/2015 12:02 PM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>> There is an ongoing discussion in the Distributed Mobility Management= (DMM) > >>> working group where they are documenting three different address type= s: > >>> > >>> 1) Nomadic > >>> 2) Sustained > >>> 3) Fixed (or stable) > >>> > >>> A nomadic address is one that is discovered when the app connects ove= r > >>> a network interface. > >> > >> TCP doesn't bind to an "interface"; it either binds to INADDR_ANY or t= o > >> a specific address. > >> When INADDR_ANY is indicated, an algorithm selects the source IP > >> address based on a set of rules - e.g., as per RFC6724 for IPv6. That = IP > >> address is determined by the outgoing interface selected by the > >> forwarding rules for the destination address coupled with some other > >> context and policy information. > >> > >> I.e., TCP doesn't pick an interface; the OS does -- *because* the app > >> has indicated that it wants this operation. > >> > >> (RFC793 talks about this as well - TCP binds to an address, but not an > >> interface per se). > >> > >>> If the interface goes down and comes back up, or if > >>> the node switches over to using a different interface, then the origi= nal > >>> address is deprecated and the app is obliged to use a new address. > >> > >> If the OS indicates that the *address* (note - not the interface) is n= o > >> longer available, then it might be reasonable to signal the socket to > >> fail. But that would make the TCP connection fail; whether the app wil= l > >> try with a *new* socket on a new address depends on how the app is wri= tten. > >> > >>> This > >>> is what typically happens when a handset switches over from WiFI to > >>> Cellular. > >> > >> Isn't that just "one network interface coming up and another going > >> down"? Why is that useful to describe as "nomadic"? What makes an > >> interface - or an address - nomadic? > >> > >>> A fixed (or stable) address is one that never changes even if the und= erlying > >>> network interfaces change. An interface can go down and come back up > >>> with a different address, or the node can switch over to using a diff= erent > >>> interface, but the fixed address remains unchanged and the app does n= ot > >>> need to reconnect. This is the type of address the node gets when it > >>> configures a tunnel (or, VPN) over the underlying network interfaces.= So, > >>> if you want an app to survive a network handover, this is the type of > >>> arrangement you should use. > >>> > >>> A "sustained" address is one that remains unchanged during the app's > >>> connection lifetime. But, after the connection terminates, the app ma= y > >>> discover and utilize a different sustained address for future connect= ions. > >>> Personally, I believe this type of address is mythical as I don't see= any > >>> practical way of implementing it. > >> > >> What do you call a WiFi interface that can go down, come back, and get= s > >> the same IP - and then all applications that were active prior to the > >> interruption come back? That's how WiFi works in Windows, FWIW. > >> > >> AFAICT: > >> > >> a) interfaces go down, taking addresses with them > >> b) interfaces come up, yielding either new addresses or reusing > >> previously assigned ones > >> c) interfaces stay up > >> > >> I don't know what the difference between these is until either you see= a > >> change. A-priori, you can't really know the difference - a cellular > >> interface might sit in one place and be on all the time (e.g., to > >> support smart power meters). A tunnel can be torn down. > >> > >> And TCP apps that set the local address to INADDR_ANY fall into your > >> "sustained address" category. > >> > >> I don't see any of this as useful to describe in terms of addresses or > >> interfaces. > >> > >>> IMHO, if you want a stable address that never changes, and/or the > >>> ability to configure multiple addresses, use DHCPv6 PD over tunnels. > >> > >> If the tunnel is created using a virtual interface, then it's possible > >> to assign an address and never need to release that interface. Tunnels > >> can also be created addresses bound to existing physical interfaces, a= nd > >> those tunnels would come down when the interface did, however. > >> > >> Joe > >> > >>>> -----Original Message----- > >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Joe Touch > >>>> Sent: Monday, September 28, 2015 11:26 AM > >>>> To: Gert Doering; Mikael Abrahamsson > >>>> Cc: v6ops list > >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability WGLC > >>>> > >>>> > >>>> > >>>> On 9/28/2015 10:52 AM, Gert Doering wrote: > >>>>> Hi, > >>>>> > >>>>> On Fri, Sep 25, 2015 at 07:46:45PM +0200, Mikael Abrahamsson wrote: > >>>>>> So here we again have the problem that most of the IETF protocol g= roups do > >>>>>> not have an "*ops" group that actually deals with real world inter= action. > >>>>>> v6ops seems to be one of the few. Why don't we have more of them? > >>>>> > >>>>> Because the amount of real-world exposure is not something IETF wou= ld > >>>>> be able to stomach. As is evident from this thread. > >>>> > >>>> Shall we open a thread on process management? Memory garbage collect= ion? > >>>> > >>>> All of these are real-world issues warranting serious consideration. > >>>> > >>>> A network interface goes down. That's a network interface event. Thi= s is > >>>> an issue in the RTG and INT areas, but the reason it's not a transpo= rt > >>>> issue is clear - nothing changed as far as the transport protocol is > >>>> concerned. > >>>> > >>>> The real disconnect here is "when an interface goes away, it *takes = away > >>>> my IP address". > >>>> > >>>> No, it really doesn't. DCHP revocation can take away an IP address, = as > >>>> does IPv6 duplicate address detection. But these are network events,= not > >>>> transport events. An interface going down may or may not take down t= he > >>>> corresponding IP address. > >>>> > >>>> So what exactly would you have the OS do? > >>>> > >>>> a) the OS socket could disappear when the IP address does > >>>> we've already pointed out how that would negatively > >>>> impact apps when a device has intermittent connectivity > >>>> > >>>> b) the OS could tell the app that a write would fail > >>>> but writes to TCP are buffered; they're not necessarily > >>>> directly correlated to segment emission unless PSH is set > >>>> > >>>> Recall that the IETF used to indicate that APIs were off-limits; it = has > >>>> since admitted that at least abstract APIs (such as are spec'd in > >>>> RFC793) are in-scope. > >>>> > >>>> However, what's clear about the cases above is that this is neither = an > >>>> abstract API issue nor a protocol issue. It's an OS implementation > >>>> issue. It may be an important one, as is the issue of "how to write = a > >>>> robust app that behaves as the user wants". > >>>> > >>>> But the IETF isn't where that's discussed. It's taught in network cl= asses. > >>>> > >>>> Joe > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> v6ops mailing list > >>>> v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Sep 30 14:32:22 2015 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8B81A90DA for ; Wed, 30 Sep 2015 14:32:21 -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, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6v__lZoeL-l for ; Wed, 30 Sep 2015 14:32:18 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::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 789961A90EF for ; Wed, 30 Sep 2015 14:32:11 -0700 (PDT) Received: by laclj5 with SMTP id lj5so62083308lac.3 for ; Wed, 30 Sep 2015 14:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oxWWjPeLYHpJEe8Y5vjZJ0TJ+/HOpa7HCj5Km/WeQeo=; b=q/YnP3LKrlYhQhHwxtx06+H/XrzJlw52CMIhXHhlHJjOkJAKazQek/XmlmEYiURCul HFUo7zxFs8hltuAgCLkuda6gICgmVKRnqOX434+wQjPl01oRmX48eaTVkKFG9tg/SKRL XENEa1WG7Ymh3N4X8lpt8wtUMBELScbfsOoTBSZK6hUHSdp+yv3B6XL6n3xTbgYkvhn7 Y7jFLQwEwJL9OmH8TLay0WLa6HiX363bkErW6YtHJAYAawII3bgr++j828WwnGkoytuR QXvQIDKlvmNNRVG0KbuksU2otfvDvjbHA+JnzzbyuR5FJQlw5KvxYaHnhO8baVojj1PF Tq1A== MIME-Version: 1.0 X-Received: by 10.152.27.102 with SMTP id s6mr755109lag.80.1443648729112; Wed, 30 Sep 2015 14:32:09 -0700 (PDT) Received: by 10.112.220.8 with HTTP; Wed, 30 Sep 2015 14:32:09 -0700 (PDT) Date: Wed, 30 Sep 2015 16:32:09 -0500 Message-ID: From: Alberto Leiva To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=089e0160b884ade73f0520fda9d3 Archived-At: Subject: [v6ops] Regarding 6145bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 21:32:21 -0000 --089e0160b884ade73f0520fda9d3 Content-Type: text/plain; charset=UTF-8 > Fragmented ICMP/ICMPv6 packets will not be translated by the IP/ICMP > translator. Is this due to some security concern? I can see why fragmented pings can't be handled by a stateless translator, due to the need to add or remove the ambiguous layer 4 length to/from the ICMP checksum's pseudoheader, but a Stateful NAT64 that collects fragments does have access to this information (and is not difficult or slow to handle). I suggest: Fragmented ICMP/ICMPv6 packets will not be translated by stateless IP/ICMP translators. Such packets MAY be translated by stateful IP/ICMP translators. > An IP/ICMP translator has two possible modes of operation: stateless > and stateful [RFC6144]. In both cases, we assume that a system (a > node or an application) that has an IPv4 address but not an IPv6 > address is communicating with a system that has an IPv6 address but > no IPv4 address, or that the two systems do not have contiguous > routing connectivity and hence are forced to have their > communications translated. Take this with a grain of salt (I'm aware it makes it less elegant). "OR they might have contiguous routing connectivity but are interacting via masking addresses (ie. hairpinning)." Right? > the translator MAY provide a configuration function for the network > administrator to adjust the threshold of the minimum IPv6 MTU to a > value that reflects the real value of the minimum IPv6 MTU in the > network (greater than 1280 bytes). > The translator MUST provide a configuration > function for the network administrator to adjust the threshold of the > minimum IPv6 MTU to a value greater than 1280-byte if the real value > of the minimum IPv6 MTU in the network is known to the administrator. This is a MAY, then a MUST. What's happening? > If the DF flag is not set and the IPv4 packet will result in an IPv6 > packet larger than 1280 bytes, the packet SHOULD be fragmented so the > resulting IPv6 packet (with Fragment Header added to each fragment) > will be less than or equal to 1280 bytes. For example, if the packet > is fragmented prior to the translation, the IPv4 packets should be > fragmented so that their length, excluding the IPv4 header, is at > most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the > Fragment Header). The translator MUST provide a configuration > function for the network administrator to adjust the threshold of the > minimum IPv6 MTU to a value greater than 1280-byte if the real value > of the minimum IPv6 MTU in the network is known to the administrator. > The resulting fragments are then translated independently using the > logic described below. Especially if you decide to MUST the requirement above, why not declare it as a variable from the start? Something like If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than a user-defined length (hereinafter referred to as "lowest-ipv6-mtu", and which defaults to 1280 bytes), the packet SHOULD be fragmented so the resulting IPv6 packet (with Fragment Header added to each fragment) will be less than or equal to lowest-ipv6-mtu. (...) > If the DF bit is set and the packet is not a fragment (i.e., the More > Fragments (MF) flag is not set and the Fragment Offset is equal to > zero), then the translator SHOULD NOT add a Fragment Header to the > resulting packet. The IPv6 header fields are set as follows: Why is this worth mentioning? You already said "an IPv6 Fragment Header is only included if the IPv4 packet is already fragmented." I also recommend separating the last sentence into another paragraph. > If the IPv4 packet is discarded, then the translator SHOULD be able > to send back an ICMPv4 error message to the original sender of the > packet, unless the discarded packet is itself an ICMPv4 message. s/is itself an ICMPv4 message/is itself an ICMPv4 error message I've always seen pings generating ICMP errors no problem. > The translator MUST support stateless address mapping algorithm > defined in [RFC6052], > The stateless translator MUST support explicit address mapping > algorithm defined in [I-D.ietf-v6ops-siit-eam]. > [stateless/stateful] IP/ICMP translators that are built specifically to > implement such a protocol, MAY forego implementing the above address > mapping algorithms. Is this not a contradiction? MUST MUST then MAY. Even in the stateless case, why are both mandatory? Traditional SIIT became an RFC without EAM and nobody complained. In addition, the EAMT can hold 0.0.0.0/0 as an entry, which will match any IPv4 packets, thereby removing the need for 6052 translation. In fact, 0.0.0.0/0 can behave just like a /96 6052 prefix. (If the user doesn't need the other prefix lengths, why force the implementation to support 6052?) > Thanks to Tore Anderson and Alberto Leiva Popper for the proposal of > the explicit address mapping (EAM) algorithm. Can you please remove my second last name there :-)? I'm the only one with two. Thanks --089e0160b884ade73f0520fda9d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> Fragmented ICMP/ICMPv6 packets will not be trans= lated by the IP/ICMP
> translator.

Is this due to some securit= y concern?

I can see why fragmented pings can't be handled by a = stateless translator, due to the need to add or remove the ambiguous layer = 4 length to/from the ICMP checksum's pseudoheader, but a Stateful NAT64= that collects fragments does have access to this information (and is not d= ifficult or slow to handle).

I suggest:

=C2=A0=C2=A0=C2=A0 Fr= agmented ICMP/ICMPv6 packets will not be translated by stateless
=C2=A0= =C2=A0=C2=A0 IP/ICMP translators. Such packets MAY be translated by statefu= l IP/ICMP
=C2=A0=C2=A0=C2=A0 translators.

> An IP/ICMP transla= tor has two possible modes of operation: stateless
> and stateful [RF= C6144].=C2=A0 In both cases, we assume that a system (a
> node or an = application) that has an IPv4 address but not an IPv6
> address is co= mmunicating with a system that has an IPv6 address but
> no IPv4 addr= ess, or that the two systems do not have contiguous
> routing connect= ivity and hence are forced to have their
> communications translated.=

Take this with a grain of salt (I'm aware it makes it less eleg= ant).

"OR they might have contiguous routing connectivity but a= re interacting via masking addresses (ie. hairpinning)."

Right?=

> the translator MAY provide a configuration function for the ne= twork
> administrator to adjust the threshold of the minimum IPv6 MTU= to a
> value that reflects the real value of the minimum IPv6 MTU in= the
> network (greater than 1280 bytes).

> The translator = MUST provide a configuration
> function for the network administrator= to adjust the threshold of the
> minimum IPv6 MTU to a value greater= than 1280-byte if the real value
> of the minimum IPv6 MTU in the ne= twork is known to the administrator.

This is a MAY, then a MUST. Wha= t's happening?

> If the DF flag is not set and the IPv4 packe= t will result in an IPv6
> packet larger than 1280 bytes, the packet = SHOULD be fragmented so the
> resulting IPv6 packet (with Fragment He= ader added to each fragment)
> will be less than or equal to 1280 byt= es.=C2=A0 For example, if the packet
> is fragmented prior to the tra= nslation, the IPv4 packets should be
> fragmented so that their lengt= h, excluding the IPv4 header, is at
> most 1232 bytes (1280 minus 40 = for the IPv6 header and 8 for the
> Fragment Header).=C2=A0 The trans= lator MUST provide a configuration
> function for the network adminis= trator to adjust the threshold of the
> minimum IPv6 MTU to a value g= reater than 1280-byte if the real value
> of the minimum IPv6 MTU in = the network is known to the administrator.
> The resulting fragments = are then translated independently using the
> logic described below.<= br>
Especially if you decide to MUST the requirement above, why not decl= are it as a variable from the start?

Something like

=C2=A0=C2= =A0=C2=A0 If the DF flag is not set and the IPv4 packet will result in an I= Pv6
=C2=A0=C2=A0=C2=A0 packet larger than a user-defined length (hereina= fter referred to as
=C2=A0=C2=A0=C2=A0 "lowest-ipv6-mtu", and = which defaults to 1280 bytes), the packet SHOULD
=C2=A0=C2=A0=C2=A0 be f= ragmented so the resulting IPv6 packet (with Fragment Header added
=C2= =A0=C2=A0=C2=A0 to each fragment) will be less than or equal to lowest-ipv6= -mtu.
=C2=A0=C2=A0=C2=A0 (...)

> If the DF bit is set and the = packet is not a fragment (i.e., the More
> Fragments (MF) flag is not= set and the Fragment Offset is equal to
> zero), then the translator= SHOULD NOT add a Fragment Header to the
> resulting packet.=C2=A0 Th= e IPv6 header fields are set as follows:

Why is this worth mentionin= g? You already said "an IPv6 Fragment Header is only included if the I= Pv4 packet is already fragmented."

I also recommend separating = the last sentence into another paragraph.

> If the IPv4 packet is= discarded, then the translator SHOULD be able
> to send back an ICMP= v4 error message to the original sender of the
> packet, unless the d= iscarded packet is itself an ICMPv4 message.

s/is itself an ICMPv4 m= essage/is itself an ICMPv4 error message

I've always seen pings = generating ICMP errors no problem.

> The translator MUST support = stateless address mapping algorithm
> defined in [RFC6052],

&g= t; The stateless translator MUST support explicit address mapping
> a= lgorithm defined in [I-D.ietf-v6ops-siit-eam].

> [stateless/state= ful] IP/ICMP translators that are built specifically to
> implement s= uch a protocol, MAY forego implementing the above address
> mapping a= lgorithms.

Is this not a contradiction? MUST MUST then MAY.

E= ven in the stateless case, why are both mandatory?

Traditional SIIT = became an RFC without EAM and nobody complained. In addition, the EAMT can = hold 0.0.0.0/0 as an entry, which will mat= ch any IPv4 packets, thereby removing the need for 6052 translation. In fac= t, 0.0.0.0/0 can behave just like a /96 60= 52 prefix. (If the user doesn't need the other prefix lengths, why forc= e the implementation to support 6052?)

> Thanks to Tore Anderson = and Alberto Leiva Popper for the proposal of
> the explicit address m= apping (EAM) algorithm.

Can you please remove my second last name th= ere :-)? I'm the only one with two.

Thanks
--089e0160b884ade73f0520fda9d3--