From internet-drafts@ietf.org Tue Feb 4 03:54:22 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377081A03C4; Tue, 4 Feb 2014 03:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F95UT-Gvp6GW; Tue, 4 Feb 2014 03:54:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D91631A03F9; Tue, 4 Feb 2014 03:54:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204115419.28024.10834.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 03:54:19 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-dc-ipv6-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: Tue, 04 Feb 2014 11:54:22 -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 : IPv6 Operational Guidelines for Datacenters Authors : Diego R. Lopez Zhonghua Chen Tina Tsou Cathy Zhou Arturo Servin Filename : draft-ietf-v6ops-dc-ipv6-01.txt Pages : 22 Date : 2014-02-04 Abstract: This document is intended to provide operational guidelines for datacenter operators planning to deploy IPv6 in their infrastructures. It aims to offer a reference framework for evaluating different products and architectures, and therefore it is also addressed to manufacturers and solution providers, so they can use it to gauge their solutions. We believe this will translate in a smoother and faster IPv6 transition for datacenters of these infrastuctures. The document focuses on the DC infrastructure itself, its operation, and the aspects related to DC interconnection through IPv6. It does not consider the particular mechanisms for making Internet services provided by applications hosted in the DC available through IPv6 beyond the specific aspects related to how their deployment on the Data Center (DC) infrastructure. Apart from facilitating the transition to IPv6, the mechanisms outlined here are intended to make this transition as transparent as possible (if not completely transparent) to applications and services running on the DC infrastructure, as well as to take advantage of IPv6 features to simplify DC operations, internally and across the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-dc-ipv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-dc-ipv6-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dc-ipv6-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 diego@tid.es Tue Feb 4 04:46:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282221A03E5 for ; Tue, 4 Feb 2014 04:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 J6Z2Fe0RiG4M for ; Tue, 4 Feb 2014 04:46:10 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 736541A0383 for ; Tue, 4 Feb 2014 04:46:08 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0H00L0A24TDS@tid.hi.inet> for v6ops@ietf.org; Tue, 04 Feb 2014 13:46:05 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 46.22.03314.D01E0F25; Tue, 04 Feb 2014 13:46:05 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0H00L0724TDS@tid.hi.inet> for v6ops@ietf.org; Tue, 04 Feb 2014 13:46:05 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.159]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 04 Feb 2014 13:46:04 +0100 Date: Tue, 04 Feb 2014 12:46:04 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: "v6ops@ietf.org" Message-id: <8195E529-4BA4-4276-9096-34C8060B5E7A@tid.es> Content-id: <98F13785F5E92548B4B1AE0880424B51@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [v6ops] I-D Action: draft-ietf-v6ops-dc-ipv6-01.txt Thread-index: AQHPIZ/tPBljGZI7okCO1821IRIBaA== X-AuditID: 0a5f4068-b7fe58e000000cf2-a0-52f0e10d6b78 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsXCFe/Apcv78EOQwcnrPBanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoc/51gKejQrzl8vaGBs0ehi5OSQEDCRuL1wDQuELSZx4d56 ti5GLg4hgQOMEvOO3oNyvjNKHDpyDcqZySixqmkdG0gLi4CqxPt/t5hAbDYg+1Hzb/YuRg4O YQFHiWfbVSGmKkj8OfcYbIMIUMnpp5eZuxjZOXgFLCXeVIJEmQXMJI4c/MgKYvMKCEr8mHyP BWQIs4C6xJQpuRAl4hLNrTdZIGxFiWmLGhhBbEYBWYl38+ezQgx3lDi0bA+UrSfx6dQHqLcE JJbsOc8MYYtKvHz8jxVkvBBQ/dnHVhMYxWYhOWIWkiNmIRwxC8kRs5AcsYCRdRWjWHFSUWZ6 RkluYmZOuoGhXkamXmZeaskmRkjsZOxgXL5T5RCjAAejEg/vitkfgoRYE8uKK3MPMUpwMCuJ 8JpvAwrxpiRWVqUW5ccXleakFh9iZOLglGpgZPtlP2+6xu5/SfPP89uGBKjeWNtW9WbPId/p mrVON7vylVO/rvlZfb8oXGjbSq5lNy4bWnff1LS4mPP4pekb/Vk3RTw/K9ad07stVlSUJB7W n9Ed+Gfbbk7Z2b6cShm/NnBMK7ZaseRvQMubekb3sitblHcGOSr1nbKe5rk8ldP0dx7rpG/q SizFGYmGWsxFxYkAICpOU3sCAAA= References: <20140204115419.28024.10834.idtracker@ietfa.amsl.com> Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-dc-ipv6-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, 04 Feb 2014 12:46:13 -0000 SGksDQoNClRoaXMgbmV3IHZlcnNpb24gb2YgdGhlIERDIGRvY3VtZW50IGFkZHJlc3NlcyBzZXZl cmFsIGNvbW1lbnRzIHJlY2VpdmVkIG9uIHRoZSBzZWN0aW9uIGFib3V0IGFkZGl0aW9uYWwgb3Bl cmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgYW5kIGluY2x1ZGVzIGEgZGlzY3Vzc2lvbiBvbiB0aGUg YWR2YW50YWdlcyBvZiBhIGZ1bGwgSVB2Ni1iYXNlZCBEQyBmb3Igb3ZlcmxheSBtYW5hZ2VtZW50 IGFuZCBzZXJ2aWNlIGNoYWluaW5nLiBBcyB3ZWxsIGFzIHRoZSB1c3VhbCB0eXBvIGNvcnJlY3Rp b24gYW5kIHJlZmVyZW5jZSB0cmltbWluZy4NCg0KRm9yIHlvdXIgcmVhZGluZyBwbGVhc3VyZSBh bmQgY29tbWVudHMuLi4NCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCj4gRnJvbTogPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gU3ViamVjdDogW3Y2b3BzXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXY2b3BzLWRjLWlwdjYtMDEudHh0DQo+IERhdGU6IDQgRmVicnVhcnkgMjAxNCBh dCAxMjo1NDoxOS4wMDAgR01UKzENCj4gVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+IENj OiA8djZvcHNAaWV0Zi5vcmc+DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdvcmtpbmcgR3Jv dXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBJUHY2IE9wZXJh dGlvbmFsIEd1aWRlbGluZXMgZm9yIERhdGFjZW50ZXJzDQo+ICAgICAgICBBdXRob3JzICAgICAg ICAgOiBEaWVnbyBSLiBMb3Bleg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgWmhvbmdodWEg Q2hlbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgVGluYSBUc291DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICBDYXRoeSBaaG91DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBBcnR1 cm8gU2VydmluDQo+ICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtZGMt aXB2Ni0wMS50eHQNCj4gICAgICAgUGFnZXMgICAgICAgICAgIDogMjINCj4gICAgICAgRGF0ZSAg ICAgICAgICAgIDogMjAxNC0wMi0wNA0KPg0KPiBBYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50 IGlzIGludGVuZGVkIHRvIHByb3ZpZGUgb3BlcmF0aW9uYWwgZ3VpZGVsaW5lcyBmb3INCj4gICBk YXRhY2VudGVyIG9wZXJhdG9ycyBwbGFubmluZyB0byBkZXBsb3kgSVB2NiBpbiB0aGVpcg0KPiAg IGluZnJhc3RydWN0dXJlcy4gIEl0IGFpbXMgdG8gb2ZmZXIgYSByZWZlcmVuY2UgZnJhbWV3b3Jr IGZvcg0KPiAgIGV2YWx1YXRpbmcgZGlmZmVyZW50IHByb2R1Y3RzIGFuZCBhcmNoaXRlY3R1cmVz LCBhbmQgdGhlcmVmb3JlIGl0IGlzDQo+ICAgYWxzbyBhZGRyZXNzZWQgdG8gbWFudWZhY3R1cmVy cyBhbmQgc29sdXRpb24gcHJvdmlkZXJzLCBzbyB0aGV5IGNhbg0KPiAgIHVzZSBpdCB0byBnYXVn ZSB0aGVpciBzb2x1dGlvbnMuICBXZSBiZWxpZXZlIHRoaXMgd2lsbCB0cmFuc2xhdGUgaW4gYQ0K PiAgIHNtb290aGVyIGFuZCBmYXN0ZXIgSVB2NiB0cmFuc2l0aW9uIGZvciBkYXRhY2VudGVycyBv ZiB0aGVzZQ0KPiAgIGluZnJhc3R1Y3R1cmVzLg0KPg0KPiAgIFRoZSBkb2N1bWVudCBmb2N1c2Vz IG9uIHRoZSBEQyBpbmZyYXN0cnVjdHVyZSBpdHNlbGYsIGl0cyBvcGVyYXRpb24sDQo+ICAgYW5k IHRoZSBhc3BlY3RzIHJlbGF0ZWQgdG8gREMgaW50ZXJjb25uZWN0aW9uIHRocm91Z2ggSVB2Ni4g IEl0IGRvZXMNCj4gICBub3QgY29uc2lkZXIgdGhlIHBhcnRpY3VsYXIgbWVjaGFuaXNtcyBmb3Ig bWFraW5nIEludGVybmV0IHNlcnZpY2VzDQo+ICAgcHJvdmlkZWQgYnkgYXBwbGljYXRpb25zIGhv c3RlZCBpbiB0aGUgREMgYXZhaWxhYmxlIHRocm91Z2ggSVB2Ng0KPiAgIGJleW9uZCB0aGUgc3Bl Y2lmaWMgYXNwZWN0cyByZWxhdGVkIHRvIGhvdyB0aGVpciBkZXBsb3ltZW50IG9uIHRoZQ0KPiAg IERhdGEgQ2VudGVyIChEQykgaW5mcmFzdHJ1Y3R1cmUuDQo+DQo+ICAgQXBhcnQgZnJvbSBmYWNp bGl0YXRpbmcgdGhlIHRyYW5zaXRpb24gdG8gSVB2NiwgdGhlIG1lY2hhbmlzbXMNCj4gICBvdXRs aW5lZCBoZXJlIGFyZSBpbnRlbmRlZCB0byBtYWtlIHRoaXMgdHJhbnNpdGlvbiBhcyB0cmFuc3Bh cmVudCBhcw0KPiAgIHBvc3NpYmxlIChpZiBub3QgY29tcGxldGVseSB0cmFuc3BhcmVudCkgdG8g YXBwbGljYXRpb25zIGFuZCBzZXJ2aWNlcw0KPiAgIHJ1bm5pbmcgb24gdGhlIERDIGluZnJhc3Ry dWN0dXJlLCBhcyB3ZWxsIGFzIHRvIHRha2UgYWR2YW50YWdlIG9mDQo+ICAgSVB2NiBmZWF0dXJl cyB0byBzaW1wbGlmeSBEQyBvcGVyYXRpb25zLCBpbnRlcm5hbGx5IGFuZCBhY3Jvc3MgdGhlDQo+ ICAgSW50ZXJuZXQuDQo+DQo+DQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXY2b3BzLWRjLWlwdjYvDQo+DQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXY2b3BzLWRjLWlwdjYtMDENCj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXY2b3BzLWRjLWlwdjYtMDENCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2 b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9z LCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0K aHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVz DQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50 ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRl IGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ug c2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5 IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhl IGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFH SU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From iesg-secretary@ietf.org Fri Feb 7 07:20:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C81E1AC7F1; Fri, 7 Feb 2014 07:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcBsr_f_6IfR; Fri, 7 Feb 2014 07:20:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3C01A8034; Fri, 7 Feb 2014 07:20:42 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140207152042.31823.59103.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 07:20:42 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link) 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: Fri, 07 Feb 2014 15:20:45 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link' 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 2014-02-21. 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 requirements for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN link as well as two implementation examples. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/ballot/ No IPR declarations have been submitted directly on this I-D. From fred@cisco.com Fri Feb 7 18:21:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0401AD944 for ; Fri, 7 Feb 2014 18:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.036 X-Spam-Level: X-Spam-Status: No, score=-115.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i8v9Y9fodkZ for ; Fri, 7 Feb 2014 18:21:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5211AD8F7 for ; Fri, 7 Feb 2014 18:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1391826084; x=1393035684; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/1nZAkzGvwKKI14K+TFB16A2ur1BWTWjk2uUOU8h8wY=; b=fNoYy6F77jY5LKvS59G7QMsVJFrbl6/9LOW6i41O/ii9cKkQfJ4HoalP 93VNppySpgk1vORxhBCmQRTxVDIQnKmrOIJGbsYK0fgGwQwxH/o74Ij/6 ert3rNKgK2dTlRzayFzgP56vjTKqTlkkJcqpmpcnkFaYbFtqKpzoBHFNI E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAKmT9VKtJXHB/2dsb2JhbABZgww4V750gQsWdIIlAQEBAwFzCwsCAQhGMiUCBBMOh28IDcxPEwSOKVYFgySBFASQP4EyhjqSIYMtgio X-IronPort-AV: E=Sophos;i="4.95,804,1384300800"; d="asc'?scan'208";a="302496746" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 08 Feb 2014 02:21:24 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s182LOj3004697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 8 Feb 2014 02:21:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.227]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 20:21:23 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: IETF 89 Final Agenda Thread-Index: AQHPJFgvUZmCuEYLS0iZktlZisM/ppqrBMuA Date: Sat, 8 Feb 2014 02:21:23 +0000 Message-ID: <00759512-EB99-467F-A006-3D70FCE84705@cisco.com> References: <20140207225819.10526.35592.idtracker@ietfa.amsl.com> In-Reply-To: <20140207225819.10526.35592.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.120] Content-Type: multipart/signed; boundary="Apple-Mail=_1DEF47EA-B864-46D8-8314-39C15B6572F0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [v6ops] IETF 89 Final Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Feb 2014 02:21:26 -0000 --Apple-Mail=_1DEF47EA-B864-46D8-8314-39C15B6572F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The IETF 89 agenda has been finalized. We are meeting Wednesday morning = and Thursday after lunch. More details on the agenda after John and I = see the drafts and list discussion. On Feb 7, 2014, at 2:58 PM, IETF Agenda wrote: > 89th IETF Meeting - London, England > March 2 - 7, 2014 >=20 > The final agenda has been posted. >=20 > https://datatracker.ietf.org/meeting/89/agenda.html > https://datatracker.ietf.org/meeting/89/agenda.txt >=20 > While this is considered the final agenda for printing, changes may be = made to the agenda up until and during the meeting. Updates will be = reflected on the web version of the agenda.=20 >=20 > Information about the 89th IETF meeting in London, England can be = found here: https://www.ietf.org/meeting/89/index.html >=20 > Thank you and see you in London! >=20 > Sincerely, >=20 > The IETF Secretariat --Apple-Mail=_1DEF47EA-B864-46D8-8314-39C15B6572F0 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 iD8DBQFS9ZSfbjEdbHIsm0MRAt2pAKC2fxyYvT8uzG6nvvrAEn+BGDco2gCgjoK9 g0KteZ2R/xItQiCbyaTuJxs= =PS5d -----END PGP SIGNATURE----- --Apple-Mail=_1DEF47EA-B864-46D8-8314-39C15B6572F0-- From fred@cisco.com Tue Feb 11 13:27:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CDC1A06DD for ; Tue, 11 Feb 2014 13:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndChMw_EVztw for ; Tue, 11 Feb 2014 13:27:39 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id C19951A0743 for ; Tue, 11 Feb 2014 13:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1726; q=dns/txt; s=iport; t=1392154059; x=1393363659; h=from:to:subject:date:message-id:references:mime-version; bh=OUp4VGDyVpfq9DItWhwzx3auofgewo1LYebKmQOLLLs=; b=DKSGMYBx1FdXA7iXSjYfVnpaQ1C7DotpOVFN+4O8QlKAVyS6wWTdMNtQ lkxB7cz142gtPplpQlBjVOW98i6lkiL7bvGtXxYHbZ//WmF1MPbJ5GC8n liHzzqAjOeL2HGcU3M9Ei8qxj/vlc6TARMvxxaeCzv3gDOyJFQSWLk3aI k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FALKU+lKtJV2a/2dsb2JhbABAGoMMOFe/C4EXFnSCJQEBAQMBbRELAgEZAwECLzIUBwIIAgQTDodvCA02yCYXjQKBI0ODPIEUBJA+gTKGOoEykG6DLYIq X-IronPort-AV: E=Sophos;i="4.95,827,1384300800"; d="asc'?scan'208";a="19689904" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 11 Feb 2014 21:27:39 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1BLRd0Z028095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 21:27:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.227]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 15:27:38 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Meetecho at IETF 89 Thread-Index: AQHPJ2rgBr7G2kE7oESP95Es17MUOw== Date: Tue, 11 Feb 2014 21:27:37 +0000 Message-ID: <06ABA9DB-A213-4C21-A76C-CB49751477E5@cisco.com> References: <20140211204958.19185.65513.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_E730D52D-812E-40CD-94F6-820B3EBEB7E6"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: [v6ops] Fwd: Meetecho at IETF 89 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Feb 2014 21:27:41 -0000 --Apple-Mail=_E730D52D-812E-40CD-94F6-820B3EBEB7E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please advise: shall I request MeetEcho? > From: IETF Agenda > Subject: Meetecho at IETF 89 > Date: February 11, 2014 12:49:58 PM PST > To: Working Group Chairs > Cc: > Reply-To: IETF Agenda , >=20 >=20 > Hello Working Group Chairs! >=20 > Meetecho will be supporting four sessions simultaneously at the = upcoming meeting in London. If you have yet to request Meetecho but = would like to, please let me know by Friday, February 14th, 2014. If we = do not receive enough requests the Meetecho team will choose sessions = that will be supported. >=20 > Here are examples of sessions that Meetecho supported for IETF 88: =20= > http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions >=20 > Thank you! >=20 > Stephanie McCammon >=20 ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --Apple-Mail=_E730D52D-812E-40CD-94F6-820B3EBEB7E6 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 iD8DBQFS+pXJbjEdbHIsm0MRAka+AJ9aNCK9bemcLOlHuJrbBDLCb0Yg8gCdFjRf 0QvwwQIN5mI9Z/D3sVmIjU0= =sdUZ -----END PGP SIGNATURE----- --Apple-Mail=_E730D52D-812E-40CD-94F6-820B3EBEB7E6-- From wwwrun@rfc-editor.org Tue Feb 11 13:55:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0161A0770; Tue, 11 Feb 2014 13:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 aT-sM4uZ0NCg; Tue, 11 Feb 2014 13:55:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 91B501A076E; Tue, 11 Feb 2014 13:55:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1C5D47FC399; Tue, 11 Feb 2014 13:55:26 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140211215531.1C5D47FC399@rfc-editor.org> Date: Tue, 11 Feb 2014 13:55:26 -0800 (PST) Cc: drafts-update-ref@iana.org, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 7113 on Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Feb 2014 21:55:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7113 Title: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) Author: F. Gont Status: Informational Stream: IETF Date: February 2014 Mailbox: fgont@si6networks.com Pages: 13 Characters: 29272 Updates: RFC 6105 I-D Tag: draft-ietf-v6ops-ra-guard-implementation-07.txt URL: http://www.rfc-editor.org/rfc/rfc7113.txt The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From swmike@swm.pp.se Tue Feb 11 14:43:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60A01A07D5 for ; Tue, 11 Feb 2014 14:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, 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 lK2NAJYtLagE for ; Tue, 11 Feb 2014 14:43:22 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1AABF1A07CA for ; Tue, 11 Feb 2014 14:43:21 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D654C9C; Tue, 11 Feb 2014 23:43:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CF8F69A; Tue, 11 Feb 2014 23:43:20 +0100 (CET) Date: Tue, 11 Feb 2014 23:43:20 +0100 (CET) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: <06ABA9DB-A213-4C21-A76C-CB49751477E5@cisco.com> Message-ID: References: <20140211204958.19185.65513.idtracker@ietfa.amsl.com> <06ABA9DB-A213-4C21-A76C-CB49751477E5@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 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Meetecho at IETF 89 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Feb 2014 22:43:27 -0000 On Tue, 11 Feb 2014, Fred Baker (fred) wrote: > Please advise: shall I request MeetEcho? I love meetecho, so please do. HTML5 goodness. -- Mikael Abrahamsson email: swmike@swm.pp.se From sajjad_akr@yahoo.com Wed Feb 12 06:42:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07DA1A099B for ; Wed, 12 Feb 2014 06:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 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, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_f91fy2o6y8 for ; Wed, 12 Feb 2014 06:42:58 -0800 (PST) Received: from nm16-vm3.bullet.mail.ne1.yahoo.com (nm16-vm3.bullet.mail.ne1.yahoo.com [98.138.91.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2019C1A031B for ; Wed, 12 Feb 2014 06:42:58 -0800 (PST) Received: from [98.138.101.132] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 14:42:57 -0000 Received: from [98.138.87.10] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 14:42:56 -0000 Received: from [127.0.0.1] by omp1010.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 14:42:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 979481.67370.bm@omp1010.mail.ne1.yahoo.com Received: (qmail 55763 invoked by uid 60001); 12 Feb 2014 14:42:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392216176; bh=v4JBqGCnmZ912K8txxa3A49kSRQByvDTpOg2jOEwPe8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=PYQCkE53/zrOYOOpafTmCWZTNDQQLilpOBK3ie/X/65ycdm7+nEZTMgoL58hAr/oh+nMOyQ8TJNUA86p786tr0xdKLlgsgcMI1nWvErvddm2IiP9bsW1hB8Mla8EFNhskrc7qGwOyxs9nNGLNhLidFXNSGiVAw1NzQVmjp+iGUc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=n/UwGZW+k4bAZ32gM8h92hg3VEP876eFsGXY6JeVG6VGTghXsV82QxpNJK7RkVLu21ffbrRASiexOihkUaRXHbu8uZyS3K+g3G7TtMaHx2/5iPykyBL/f+5Adzvq1vgiBwO8vQtHF5WWNptBHKVw+AzWwKLilxZNRwUNDT7x1PU=; X-YMail-OSG: loidsHEVM1nkJgEDBGPWoU8NvmDx6AALCokHhI0F0cOwL9P IUGXWLP6NpkG4Jh7urbE_t33cFWht_OZOugApCxCOMITCm_vDd50xxDjyYvX CfkcB.JerVgcYNLA1rtQqtsBsc.ishYz4MAVyMgNcoT7XzFnTF8qVgYFTn9d WqTDJMOCkCZwN1k4hNwnz8hMikDLqTNI.augiv9w_1HPOYNnlwtcy4U3c5I3 JJF.OJXKiWIxnGNcTE327Venyy4PKOpgFTd5t_Q48mZqsi8njONWiZJzv77K CICvhM9ppBXjfu0nzyYb6SdS4uPh_xkj9CRNSW4nyrJ71AcxX91X2z_AxBKI cq5AZgUFxYzKxdQG00xYkFC1tkuiS_yE1SgYkoldU99gDmFO2MHjiuu7l9U6 nnTn2WgKvtSuF6NvwS6ZFVcj0vXa8ICEZvNSv9uuETLSQheJn6nXUgdn_tn5 jrUryqIp1kNAD_DVG7EhQC8xbLy.hhUGwC3_6tPgi68LI3mqiQyaiX1YD.f. QbTGSmqJcChAvni_wfUGjaPNBBsIgZ3fT.iu9xtUDrZTvFcYTdr17QLQRQwv HEAIgbBKWI9uHJbs5ay2KwPdkJJa9jGKdCpmiLW7OWQ4g39WdTN926HK6CkU 5Vnx8eqGgnc9DD3Bb.x_qE.Kelm7j Received: from [39.47.121.27] by web125102.mail.ne1.yahoo.com via HTTP; Wed, 12 Feb 2014 06:42:56 PST X-Rocket-MIMEInfo: 002.001, CgpEZWFyIGZlbGxvd3MKCldlIGFyZSB3b3JraW5nIG9uIDIgeWVhciBmdW5kZWQgcHJvamVjdCAiRGVzaWduIGFuZCBEZXZlbG9wbWVudCBvZiBIeWJyaWQgSVB2NCBhbmQgSVB2NiBOZXR3b3JrIGZvciBRb1MgRW5hYmxlZCBWaWRlbyBTdHJlYW1pbmcgTXVsdGljYXN0IEFwcGxpY2F0aW9uIiBpbiBQYWtpc3RhbiB1bmRlciByZXNlYXJjaCBncm91cCBDb1JlTmVUICh3d3cuY29yZW5ldC5lZHUucGspLiBsb3NzCkZsb3dsYWJlbCBpbmZvcm1hdGlvbiBsb3N0IGluIGNhc2Ugb2YgdHVubmVsaW5nIGFuZCB0cmEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.176.634 Message-ID: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Wed, 12 Feb 2014 06:42:56 -0800 (PST) From: sajjad akbar To: "v6ops@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-559651860-1219511993-1392216176=:40461" Subject: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:43:00 -0000 ---559651860-1219511993-1392216176=:40461 Content-Type: text/plain; charset=us-ascii Dear fellows We are working on 2 year funded project "Design and Development of Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Application" in Pakistan under research group CoReNeT (www.corenet.edu.pk). loss Flowlabel information lost in case of tunneling and translation as IPv4 header does not have such QoS field. We have design an algorithm which stores Flowlabel information in IPv4 header.For storage we use the OPTION field of IPv4(24 bit long).Further, each intermediate router (IPv4 only)will extract the Flowlable information and will provide flow base service to a long session of multimedia communication. Please guide us in this regard that either our direction is right or you suggest some modification. ---559651860-1219511993-1392216176=:40461 Content-Type: text/html; charset=us-ascii

Dear fellows

We are working on 2 year funded project "Design and Development of Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Application" in Pakistan under research group CoReNeT (www.corenet.edu.pk). loss

Flowlabel information lost in case of tunneling and translation as IPv4 header does not have such QoS field. We have design an algorithm which stores Flowlabel information in IPv4 header.For storage we use the OPTION field of IPv4(24 bit long).Further, each intermediate router (IPv4 only)will extract the Flowlable information and will provide flow base service to a long session of multimedia communication.

Please guide us in this regard that either our direction is right or you suggest some modification.
---559651860-1219511993-1392216176=:40461-- From alejandroacostaalamo@gmail.com Wed Feb 12 07:34:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B59E1A0342 for ; Wed, 12 Feb 2014 07:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0OaDlfWYVHL for ; Wed, 12 Feb 2014 07:34:47 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4891A02B0 for ; Wed, 12 Feb 2014 07:34:47 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so15647421ykr.9 for ; Wed, 12 Feb 2014 07:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DtsfF3+YuGu6nx51DfVYRODCwL+gsTzcwnNpZQxHhkI=; b=dYCLfuueYl3Yo8y2agoG88M7+XyMdhkPmcRWJq6zkLFJRi8pB7db2Faio2V06cUbdt GdMr+FRFnh2BZCCuO32m9X05SG9EFluqpJb+Pm443lws0bEPpv/fWq2TDIf8+MeKlmfh 4ax02uANJtPDZ+Hb8WOCBRPzFJtKZ7lPkYowBzedSG6IY+66YKs2RuBH3VvneriTDYk8 r4ZtirTyHfBTPdVMNNwAVpWRqPpfgmqb8fFE75j1+iuFj+jbuE5XjssdB/OGEkcFvFso 2HKxkV2Nw1e+85H+7ywirWiiiSEQ3Syc/2J9FPB8mXWrLMe5r3H5HdkKld8Zj4wT3NhN c/Xg== X-Received: by 10.236.134.48 with SMTP id r36mr1230274yhi.133.1392219286380; Wed, 12 Feb 2014 07:34:46 -0800 (PST) Received: from [192.168.124.103] ([186.88.7.220]) by mx.google.com with ESMTPSA id q9sm72643413yhk.16.2014.02.12.07.34.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 07:34:45 -0800 (PST) Message-ID: <52FB9495.6070609@gmail.com> Date: Wed, 12 Feb 2014 11:04:45 -0430 From: Alejandro Acosta User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <20140211204958.19185.65513.idtracker@ietfa.amsl.com> <06ABA9DB-A213-4C21-A76C-CB49751477E5@cisco.com> In-Reply-To: <06ABA9DB-A213-4C21-A76C-CB49751477E5@cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] Fwd: Meetecho at IETF 89 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Feb 2014 15:34:50 -0000 Hello, I think it's a good idea to request Meetecho Alejandro, El 2/11/2014 4:57 PM, Fred Baker (fred) escribió: > Please advise: shall I request MeetEcho? > >> From: IETF Agenda >> Subject: Meetecho at IETF 89 >> Date: February 11, 2014 12:49:58 PM PST >> To: Working Group Chairs >> Cc: >> Reply-To: IETF Agenda , >> >> >> Hello Working Group Chairs! >> >> Meetecho will be supporting four sessions simultaneously at the upcoming meeting in London. If you have yet to request Meetecho but would like to, please let me know by Friday, February 14th, 2014. If we do not receive enough requests the Meetecho team will choose sessions that will be supported. >> >> Here are examples of sessions that Meetecho supported for IETF 88: >> http://ietf88.conf.meetecho.com/index.php/Recorded_Sessions >> >> Thank you! >> >> Stephanie McCammon >> > > ----------------------------------- > "We are learning to do a great many clever things...The next great task > will be to learn not to do them." > > - G. K. Chesterton (1874-1936) > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Wed Feb 12 07:38:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FC21A0988 for ; Wed, 12 Feb 2014 07:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHmkwltv9Cu4 for ; Wed, 12 Feb 2014 07:38:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 67D451A0929 for ; Wed, 12 Feb 2014 07:38:26 -0800 (PST) Received: from [192.168.43.134] ([172.56.39.3]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1CFcO33099335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 12 Feb 2014 15:38:25 GMT (envelope-from joelja@bogus.com) Message-ID: <52FB956A.8010402@bogus.com> Date: Wed, 12 Feb 2014 07:38:18 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: sajjad akbar , "v6ops@ietf.org" References: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> In-Reply-To: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ho9lVkpvNd2Q3e3fNk27lWmmlxM3um8rv" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Wed, 12 Feb 2014 15:38:25 +0000 (UTC) Subject: Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Feb 2014 15:38:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ho9lVkpvNd2Q3e3fNk27lWmmlxM3um8rv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/12/14, 6:42 AM, sajjad akbar wrote: >=20 >=20 > Dear fellows >=20 > We are working on 2 year funded project "Design and Development of Hybr= id IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Applic= ation" in Pakistan under research group CoReNeT (www.corenet.edu.pk). los= s > Flowlabel information lost in case of tunneling and translation as IPv4= header does not have such QoS field. We have design an algorithm which s= tores Flowlabel information in IPv4 header.For storage we use the OPTION = field of IPv4(24 bit long).Further, each intermediate router (IPv4 only)w= ill extract the Flowlable information and will provide flow base service = to a long session of multimedia communication. >=20 > Please guide us in this regard that either our direction is right or yo= u suggest some modification. new IP options don't have a good history with respect to acceptance by the network. http://tools.ietf.org/html/rfc7126#section-3 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Ho9lVkpvNd2Q3e3fNk27lWmmlxM3um8rv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlL7lWoACgkQ8AA1q7Z/VrJ4sgCfYGmDLTQ0lqulIBQ22oeKmj7Q 80QAmwSs8vme544AckArRI7ghOyLyDod =D0ph -----END PGP SIGNATURE----- --Ho9lVkpvNd2Q3e3fNk27lWmmlxM3um8rv-- From sajjad_akr@yahoo.com Wed Feb 12 09:43:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3D51A09D2 for ; Wed, 12 Feb 2014 09:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 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, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRuu6eJtrhfK for ; Wed, 12 Feb 2014 09:43:48 -0800 (PST) Received: from nm23-vm5.bullet.mail.ne1.yahoo.com (nm23-vm5.bullet.mail.ne1.yahoo.com [98.138.91.245]) by ietfa.amsl.com (Postfix) with ESMTP id AAD281A09D0 for ; Wed, 12 Feb 2014 09:43:47 -0800 (PST) Received: from [98.138.226.177] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 17:43:46 -0000 Received: from [98.138.89.173] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 17:43:46 -0000 Received: from [127.0.0.1] by omp1029.mail.ne1.yahoo.com with NNFMP; 12 Feb 2014 17:43:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 508414.59155.bm@omp1029.mail.ne1.yahoo.com Received: (qmail 10290 invoked by uid 60001); 12 Feb 2014 17:43:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392227026; bh=7QDwqjAf0jEbTf5VX4MDrTeG131kLY6pB8ENLqMlLuA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xXxh6yIReaQXCqU4bCe+ZxAa1faSHtGHINDs0EIge5N4aD/nMQrZ5ocaNxvMi6qfVwm1wRv3KWMBO9vzJzRR2b3TAot76iVYfSKgxNAQtxYzHwaA4kfOOvgQfBt5zfWY90wvE9171/saUFIhgrXtBuzDeFoGQesIsYgTPE1TYpY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NhYcUancDkUPaVKhSTI4bfMKV76cdaMvx0ovuzool26EJgz9E/a3tdUUQDfSkI4AQiyyweWoVsu9NLU023Jvlnb0YXLhN3V2oBSzGfpkOPCQBrQLm8sxRowAps/o3zOxT4X06AwqcJm5CzrUnLjSeGGft+5vpWlnmdSTGw2I5k4=; X-YMail-OSG: 3WWLpTgVM1kfr9OFzNZh593qifB0a2uAQdb8uTJAwHLCafs w3jHGnz__2POSkFSJKkrp8sk3hA17u4gbcY0N9.nEdBAPSEAO4XcpIAlSupr NFhLb0BzAQGrc9x272pK1JVPPoJnlAfxl2eKVVCh3i6dCgH3gAgusrT8UmW6 85WOxJ.av7Z6ZaQi1rVk1X9rN28jF_tRV8rajg7kjBggU88eOIZ_uyIIGcNA cAr5iVPqiucxZ1KdnC.YmbXPDt7zB.r5Y7oBioLNtkNjpmoE0uAnOr.Gbv6u D0mxIx3.ahY4G.GafuGuhMhp16TgmLivPInoH9FqfSLTq1O.AanSuoXkgufl z.uCfhs74HwFuwEjBn5tZxqGTWEzZznuYR8mcFVvrb.RJ0s1sgrvM7XC1U3l ZCG9RR.hHJFi_rHhzXNuKcIockNUp3NxlrJeYKq.vk1QTAfCI7_2w6PgCjO4 xMoEVeuiLA20c0xGihsPjrnooXUg.Oyb2_QQT5W0Y8K.EZjXuHiavyhX4kqd hEw.vxMGGy7B2erYpYZY08PHRGy60K89U4ExeK7BUodBbIHI6rwlo6RwagLS VY2QMjZ1rVXZbEIKKpy7rt6wrH4b5hYpPPTkjAL4kiWgAzkuohbbcSpMMuYZ 8LRemq1mrnSyZ52LXbHJz9.2y Received: from [39.47.124.193] by web125106.mail.ne1.yahoo.com via HTTP; Wed, 12 Feb 2014 09:43:46 PST X-Rocket-MIMEInfo: 002.001, wqBUaGFua3MgZm9yIHJlZmVycmluZyB0aGUgUkZDLiBJIGp1c3QgZ28gdGhyb3VnaCB0byBpdCwgeWVzLCB0aGVyZSBtYXkgYmUgaXNzdWUgb2YgYWNjZXB0YWJpbGl0eSBmb3IgT1BUSU9OIGhlYWRlcnMuCgpIb3dldmVyLCBPUFRJT04gaGVhZGVycyBwcm92aWRlcyBvcHBvcnR1bml0eSB0byBwYXNzIHNvbWUgaW5mb3JtYXRpb24gdG8gdGhlIG5ldHdvcmtzLiBGb3IgdGhlIHByb29mIG9mIGNvbmNlcHRzLCB3ZSBjYW4gZG8gdGhpcyB1bnRpbCB0byBleHBsb3JlIGEgbmV3IHdheSA6KXRvIHN1cnZpdmUgRmwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.176.634 References: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> <52FB956A.8010402@bogus.com> Message-ID: <1392227026.8043.YahooMailNeo@web125106.mail.ne1.yahoo.com> Date: Wed, 12 Feb 2014 09:43:46 -0800 (PST) From: sajjad akbar To: joel jaeggli , "v6ops@ietf.org" In-Reply-To: <52FB956A.8010402@bogus.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1552829269-288359426-1392227026=:8043" Subject: Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:43:50 -0000 --1552829269-288359426-1392227026=:8043 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0Thanks for referring the RFC. I just go through to it, yes, there may be= issue of acceptability for OPTION headers.=0A=0AHowever, OPTION headers pr= ovides opportunity to pass some information to the networks. For the proof = of concepts, we can do this until to explore a new way :)to survive FlowLab= le information.=A0=0A=0Alooking forward for comments.=0A=0ARegards=0ASajjad= =A0=0ATeam Lead IPv6 Project=0APakistan=0A=0A=0A=0A=0A=0A=0AOn Wednesday, F= ebruary 12, 2014 8:38 PM, joel jaeggli wrote:=0A =0AOn 2= /12/14, 6:42 AM, sajjad akbar wrote:=0A>> =0A>> =0A>> Dear fellows=0A>> =0A= >> We are working on 2 year funded project "Design and Development of Hybri= d IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Applicati= on" in Pakistan under research group CoReNeT (www.corenet.edu.pk). loss=0A>= > Flowlabel information lost in case of tunneling and translation as IPv4 h= eader does not have such QoS field. We have design an algorithm which store= s Flowlabel information in IPv4 header.For storage we use the OPTION field = of IPv4(24 bit long).Further, each intermediate router (IPv4 only)will extr= act the Flowlable information and will provide flow base service to a long = session of multimedia communication.=0A>> =0A>> Please guide us in this reg= ard that either our direction is right or you suggest some modification.=0A= >=0A>new IP options don't have a good history with respect to acceptance by= =0A>the network.=0A>=0A>http://tools.ietf.org/html/rfc7126#section-3=0A>=0A= >=0A>> =0A>> =0A>> _______________________________________________=0A>> v6o= ps mailing list=0A>> v6ops@ietf.org=0A>> https://www.ietf.org/mailman/listi= nfo/v6ops=0A>> =0A>=0A>=0A>=0A> --1552829269-288359426-1392227026=:8043 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
 Thanks for referring the RFC. I just go through to it, yes, there m= ay be issue of acceptability for OPTION headers.

However, OPTION headers provides opportunity to pass some inf= ormation to the networks. For the proof of concepts, we can do this until t= o explore a new way :)to survive FlowLable information. 
<= div style=3D"color: rgb(0, 0, 0); font-size: 18.88888931274414px; font-family: 'Courier New', courier, monaco, monospace, sans-serif; backgr= ound-color: transparent; font-style: normal;">
looking forward for comments.

Regards
Sajjad 
Team Lead IPv6 Project
Pakistan





the= network.

http://tools.ietf.org/html/rfc7126#section-3


>
>
> ____________________= ___________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
&= gt;



--1552829269-288359426-1392227026=:8043-- From fred@cisco.com Wed Feb 12 14:06:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F671A0013 for ; Wed, 12 Feb 2014 14:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.449 X-Spam-Level: X-Spam-Status: No, score=-114.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyGcbLhl8sxA for ; Wed, 12 Feb 2014 14:06:30 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9B1A0010 for ; Wed, 12 Feb 2014 14:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3588; q=dns/txt; s=iport; t=1392242790; x=1393452390; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FsMHq6mtec25c/rJI5/i2PeZpR3up7MlwpDBPBlDyxU=; b=cNCOXY8rbflzW3GuMj62mWKMX43atLTNykH9+YYWbxbOBbtVwgmSdBH/ TwHI0GZQBeN5MEcF/BSGcqyQcL3BqM/jhpDDxsNajAg6MBgsj03tmAUru vZMA98iWr3/1/LRxiAjZRHU4g6hs2POLIk5K5BDF9G/VpShWe5hrP8c+q U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFHv+1KtJV2Z/2dsb2JhbABagww4V6oylH2BGRZ0giUBAQEDAQEBAWsLBQsCAQgYIwsnCxMSAgQOBQ6HYwMJCA3IcxeMX4FRSQcJgxuBFASQPoEyhFSBZoEyiSyCAIVDgW+BPoFpQQ X-IronPort-AV: E=Sophos;i="4.95,834,1384300800"; d="asc'?scan'208";a="303662058" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 12 Feb 2014 22:06:29 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1CM6TrX021991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 22:06:29 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.227]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 16:06:28 -0600 From: "Fred Baker (fred)" To: sajjad akbar Thread-Topic: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS Thread-Index: AQHPKD6t9oZ+mZGJNEud4/PBR13Xbg== Date: Wed, 12 Feb 2014 22:06:28 +0000 Message-ID: <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com> References: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> <52FB956A.8010402@bogus.com> <1392227026.8043.YahooMailNeo@web125106.mail.ne1.yahoo.com> In-Reply-To: <1392227026.8043.YahooMailNeo@web125106.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_E8676D66-DA1B-4F7A-A2B1-86E48629D768"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Feb 2014 22:06:33 -0000 --Apple-Mail=_E8676D66-DA1B-4F7A-A2B1-86E48629D768 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 12, 2014, at 9:43 AM, sajjad akbar wrote: > Thanks for referring the RFC. I just go through to it, yes, there may = be issue of acceptability for OPTION headers. >=20 > However, OPTION headers provides opportunity to pass some information = to the networks. For the proof of concepts, we can do this until to = explore a new way :)to survive FlowLable information.=20 I see no problem with specifying an experimental flow label option in = IPv4. I'd suggest that you write an 'experimental' internet draft and = get an option number from IANA using the usual procedures. It will = likely need to be run through the Independent Submissions Editor, as the = IETF is not currently working on significant enhancements to IPv4. It may be simpler for you to get IPv6 service on the network path in = question, however. If you're going to the effort to put the flow label = into a tunnel header, I have to believe that you plan to in some way use = that optional information, and you will need to specify and implement = that as well. It seems, frankly, like a diversion of effort; you have = more to show at the end of the experiment if it's in IPv6 and you can = recommend deployment. > looking forward for comments. >=20 > Regards > Sajjad=20 > Team Lead IPv6 Project > Pakistan >=20 >=20 >=20 >=20 >=20 > On Wednesday, February 12, 2014 8:38 PM, joel jaeggli = wrote: > On 2/12/14, 6:42 AM, sajjad akbar wrote: > >=20 > >=20 > > Dear fellows > >=20 > > We are working on 2 year funded project "Design and Development of = Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast = Application" in Pakistan under research group CoReNeT = (www.corenet.edu.pk). loss > > Flowlabel information lost in case of tunneling and translation as = IPv4 header does not have such QoS field. We have design an algorithm = which stores Flowlabel information in IPv4 header.For storage we use the = OPTION field of IPv4(24 bit long).Further, each intermediate router = (IPv4 only)will extract the Flowlable information and will provide flow = base service to a long session of multimedia communication. > >=20 > > Please guide us in this regard that either our direction is right or = you suggest some modification. >=20 > new IP options don't have a good history with respect to acceptance by > the network. >=20 > http://tools.ietf.org/html/rfc7126#section-3 >=20 >=20 > >=20 > >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein --Apple-Mail=_E8676D66-DA1B-4F7A-A2B1-86E48629D768 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 iD8DBQFS+/BibjEdbHIsm0MRAlAaAKDOO4dFS7vtlLEIjPOdA/ponFifZwCgoRv1 cu/Uy8G7vf3N7kvJjPjnN5o= =9n2Z -----END PGP SIGNATURE----- --Apple-Mail=_E8676D66-DA1B-4F7A-A2B1-86E48629D768-- From sajjad_akr@yahoo.com Thu Feb 13 04:09:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EBE1A01F8 for ; Thu, 13 Feb 2014 04:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_82=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, T_DKIM_INVALID=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 fV_bMya0IGzy for ; Thu, 13 Feb 2014 04:09:54 -0800 (PST) Received: from nm19-vm1.bullet.mail.ne1.yahoo.com (nm19-vm1.bullet.mail.ne1.yahoo.com [98.138.91.56]) by ietfa.amsl.com (Postfix) with ESMTP id AEF7F1A01E9 for ; Thu, 13 Feb 2014 04:09:53 -0800 (PST) Received: from [98.138.101.132] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 12:09:52 -0000 Received: from [98.138.89.195] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 12:09:52 -0000 Received: from [127.0.0.1] by omp1053.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 12:09:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 382281.94969.bm@omp1053.mail.ne1.yahoo.com Received: (qmail 14849 invoked by uid 60001); 13 Feb 2014 12:09:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392293392; bh=E/k/xYVzbDZwETpov21H0Deo/CzwRhMLqhrDOmX+8HI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ncNOYzUouzVZ68vBxzL4EjRvTL28TEEMrAtTsPeCLfRPCNkW8cckBT2FTzcFeIAahguX6SfOUJZ/TdTFlqYH71xDHS1Mt1OCyE787y0cV5lsq4wovzCnuo5+n2wNNfJqBbNCrUCXZ5bBof4FhifoSHTRKT2lRkq2dMuKqNKoMZc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jX9+pyveMT3gVP8d4ynfAGDDZfdXn/L3yDDEpp+zfU+D4g/TFfp7hLkfuIncGC13IRp64AV0sF5SyGPzDdX8bZ6mQesjE+oCm34m/sK1NwTQAGGXzj9zEkT6iXcUer1WIOhzWtcLa2l945JtATlDLZOPbMRNB5ow59s5ranqCkE=; X-YMail-OSG: ii7YCRQVM1npsLo7P8f2gj.irH7GOju_TpzUO6hhWhKFseI PGG5CKKrdZduVewSXgvSf.srx1i1HIfY6D69_g5lvpR1XI7rYjLCOAAHH5ye pljBDMtUux9Ld3GQBQ6RHfA9jdZNnC5C8WEWwJyte2s6FZ2GU.FDvtAhxPGn oaAB1sGpT3IcfyaP3Ec3.uiQD0qU1bFILp_JrvZz418PrmbaIXObMVbekw40 p_f3a63pnn.i_i_ay3LbMTlnGelptfbim7MMqH.INSeIpk7UiXF1xV6rS20z NlSMvwY0UAuxu2cFFFfiHuC2JffPwAuU52Wfdt.iDMGq.nP3_inucXfEh.JX LXGd0xk3RBW0gE.XweN5RtfnLfHuB.vhSiS2epqXum8aejL6.sHkZru4ftxc F77zEwz2flVd1Ld9lf0CBishK.vc0_7NHXNrWok20mhO0RfgjJ0YXA2nLJnq 125DqBdzwtYk4VGIsHumWLlaa3YS.tKjPbIlLCouTT9XYFMuYWNcIrfCHDcM v5_iUyZgTPo5bD66U1V2eVBmraraVlM6iqm9kZN_fdzcQy_lnmsYWetXIvXc W3TWpOwQZ9xCldNOchIRM1eMPThQyH0foh05zfGlyOIWbHgETxfyG_Vzke2. Bx.A47lzTUtY_XAcPwYs0GOJB Received: from [203.99.52.171] by web125103.mail.ne1.yahoo.com via HTTP; Thu, 13 Feb 2014 04:09:52 PST X-Rocket-MIMEInfo: 002.001, VGhhbmtzIGZvciBzaGFyaW5nIHlvdXIgY29uY2VybnMgYW5kIHN1Z2dlc3Rpb25zLiBJIGhhdmUgZGlzY3Vzc2VkIHlvdXIgZmVlZGJhY2sgd2l0aCBEci5BbWlyIFFheXl1bSAoUHJvamVjdCBEaXJlY3RvcilhcyB3ZWxsLiBZZXMsIGl0cyBub3QgYW4gZWFzeSB0YXNrIHRvIGRvIGFzIGN1cnJlbnRseSBJRVRGIGlzIG5vdCB3b3JraW5nIG9uIElQdjQgZW5oYW5jZW1lbnQuIFdlIGNhbiBnbyBmb3IgImV4cGVyaW1lbnRhbCIgSW50ZXJuZXQgZHJhZnQgYXMgd2VsbC4KCkZvbGxvd2luZyBpcyBhbm90aGVyIHcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> <52FB956A.8010402@bogus.com> <1392227026.8043.YahooMailNeo@web125106.mail.ne1.yahoo.com> <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com> Message-ID: <1392293392.96381.YahooMailNeo@web125103.mail.ne1.yahoo.com> Date: Thu, 13 Feb 2014 04:09:52 -0800 (PST) From: sajjad akbar To: "Fred Baker \(fred\)" In-Reply-To: <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="856753768-1653053286-1392293392=:96381" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sajjad akbar List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:09:56 -0000 --856753768-1653053286-1392293392=:96381 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for sharing your concerns and suggestions. I have discussed your fee= dback with Dr.Amir Qayyum (Project Director)as well. Yes, its not an easy t= ask to do as currently IETF is not working on IPv4 enhancement. We can go f= or "experimental" Internet draft as well.=0A=0AFollowing is another way to = do the same task=0A=0AAs for IPv6 transition phase, FlowLabel information i= s discarded for translation and tunneling. Here, we can use OPTION field pl= us take help from MPLS enable routers for flow base forwarding. So, this so= lution will work on MPLS enable routers. In this way, we may reduce the for= warding overheads. For such implementation, we may claim that for IPv6 tran= sition phase, the FlowLabel information will not lost in case of translatio= n and tunneling.=A0=0A=0ALooking forward for your comments.=0A=0ARegards=0A= Sajjad (IPv6 project)=0ACoReNeT research group=0A=0A=0A=0A=0A=0A=0A=0AOn Th= ursday, February 13, 2014 3:06 AM, Fred Baker (fred) wrote= :=0A =0A=0A>On Feb 12, 2014, at 9:43 AM, sajjad akbar wrote:=0A>=0A>>=A0 Thanks for referring the RFC. I just go through to it,= yes, there may be issue of acceptability for OPTION headers.=0A>> =0A>> Ho= wever, OPTION headers provides opportunity to pass some information to the = networks. For the proof of concepts, we can do this until to explore a new = way :)to survive FlowLable information. =0A>=0A>I see no problem with speci= fying an experimental flow label option in IPv4. I'd suggest that you write= an 'experimental' internet draft and get an option number from IANA using = the usual procedures. It will likely need to be run through the Independent= Submissions Editor, as the IETF is not currently working on significant en= hancements to IPv4.=0A>=0A>It may be simpler for you to get IPv6 service on= the network path in question, however. If you're going to the effort to pu= t the flow label into a tunnel header, I have to believe that you plan to i= n some way use that optional information, and you will need to specify and = implement that as well. It seems, frankly, like a diversion of effort; you = have more to show at the end of the experiment if it's in IPv6 and you can = recommend deployment.=0A>=0A>> looking forward for comments.=0A>> =0A>> Reg= ards=0A>> Sajjad =0A>> Team Lead IPv6 Project=0A>> Pakistan=0A>> =0A>> =0A>= > =0A>> =0A>> =0A>> On Wednesday, February 12, 2014 8:38 PM, joel jaeggli <= joelja@bogus.com> wrote:=0A>> On 2/12/14, 6:42 AM, sajjad akbar wrote:=0A>>= > =0A>> > =0A>> > Dear fellows=0A>> > =0A>> > We are working on 2 year fun= ded project "Design and Development of Hybrid IPv4 and IPv6 Network for QoS= Enabled Video Streaming Multicast Application" in Pakistan under research = group CoReNeT (www.corenet.edu.pk). loss=0A>> > Flowlabel information lost = in case of tunneling and translation as IPv4 header does not have such QoS = field. We have design an algorithm which stores Flowlabel information in IP= v4 header.For storage we use the OPTION field of IPv4(24 bit long).Further,= each intermediate router (IPv4 only)will extract the Flowlable information= and will provide flow base service to a long session of multimedia communi= cation.=0A>> > =0A>> > Please guide us in this regard that either our direc= tion is right or you suggest some modification.=0A>> =0A>> new IP options d= on't have a good history with respect to acceptance by=0A>> the network.=0A= >> =0A>> http://tools.ietf.org/html/rfc7126#section-3=0A>> =0A>> =0A>> > = =0A>> > =0A>> > _______________________________________________=0A>> > v6op= s mailing list=0A>> > v6ops@ietf.org=0A>> > https://www.ietf.org/mailman/li= stinfo/v6ops=0A>=0A>> > =0A>> =0A>> =0A>> =0A>> ___________________________= ____________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> https= ://www.ietf.org/mailman/listinfo/v6ops=0A>=0A>If at first the idea is not a= bsurd, then there is no hope for it.=A0 =0A>Albert Einstein=0A>=0A>=0A>=0A>= =0A>=0A>=0A> --856753768-1653053286-1392293392=:96381 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for sharing your concerns and suggestions. I have discussed your f= eedback with Dr.Amir Qayyum (Project Director)as well. Yes, its not an easy= task to do as currently IETF is not working on IPv4 enhancement. We can go= for "experimental" Internet draft as well.

Following is another way to do the same task

As for IPv6 transition phase, FlowLabel information= is discarded for translation and tunneling. Here, we can use OPTION field = plus take help from MPLS enable routers for flow base forwarding. So, this = solution will work on MPLS enable routers. In this way, we may reduce the f= orwarding overheads. For such implementation, we may claim that for IPv6 tr= ansition phase, the FlowLabel information will not lost in case of translat= ion and tunneling. 

Looki= ng forward for your comments.
Regards
Sajjad (IPv6 project)
CoReNeT research group
<= span>





On Thursday, February 13, 2014 3:06 = AM, Fred Baker (fred) <fred@cisco.com> wrote:

On Feb 12, 2014, at 9:43 AM, sajjad akbar <sajjad_akr@yahoo.com> wrote:

>  Thanks for referring the RFC. I just go through to it, yes, = there may be issue of acceptability for OPTION headers.
&= gt;
> However, OPTION headers provides opportunity to pass some information to t= he networks. For the proof of concepts, we can do this until to explore a n= ew way :)to survive FlowLable information.

I see no problem with specifying an experimental flow label option in= IPv4. I'd suggest that you write an 'experimental' internet draft and get = an option number from IANA using the usual procedures. It will likely need = to be run through the Independent Submissions Editor, as the IETF is not cu= rrently working on significant enhancements to IPv4.

It may be simpler for you to get IPv6 service on the network= path in question, however. If you're going to the effort to put the flow l= abel into a tunnel header, I have to believe that you plan to in some way u= se that optional information, and you will need to specify and implement th= at as well. It seems, frankly, like a diversion of effort; you have more to show at the end of the experiment if it's in IPv6 and you can recommend de= ployment.

> looking forward for com= ments.
>
> Regards
> Sajjad
> Team Lead IPv6 Project
> Pakistan
>
>
>
>
>
> On Wednesday, February 12, 2014 8:38 PM, joel jaeggli <joelja@bogus.com> wrote:
> On 2/12/14= , 6:42 AM, sajjad akbar wrote:
> >
> >
> > Dear fellows
&g= t; >
> > We are working on 2 year funded projec= t "Design and Development of Hybrid IPv4 and IPv6 Network for QoS Enabled V= ideo Streaming Multicast Application" in Pakistan under research group CoReNeT (www.corenet.edu.pk). loss
> > Flowlabel information lost in case of tunneling and t= ranslation as IPv4 header does not have such QoS field. We have design an a= lgorithm which stores Flowlabel information in IPv4 header.For storage we u= se the OPTION field of IPv4(24 bit long).Further, each intermediate router = (IPv4 only)will extract the Flowlable information and will provide flow bas= e service to a long session of multimedia communication.
= > >
> > Please guide us in this regard that = either our direction is right or you suggest some modification.
>
> new IP options don't have a good histor= y with respect to acceptance by
> the network.
>
> http://tools.ietf.org/html/rfc7126#section-3
>
>
> >
> >
> > _______________________= ________________________
> > v6ops mailing list
> > v6ops@ietf.org
> = > https://www.ietf.org/mailman/listinfo/v6ops

> >
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> htt= ps://www.ietf.org/mailman/listinfo/v6ops


If at first the idea is not absurd, then there is no hope for = it. 
Albert Einstein





=
--856753768-1653053286-1392293392=:96381-- From fred@cisco.com Thu Feb 13 05:45:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8411A0234 for ; Thu, 13 Feb 2014 05:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1vTeTpOFvt6 for ; Thu, 13 Feb 2014 05:45:03 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA311A0210 for ; Thu, 13 Feb 2014 05:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=130; q=dns/txt; s=iport; t=1392299102; x=1393508702; h=date:from:message-id:to:subject:cc; bh=oDJzmorGaMX/Hx0HherDP7vDuFtcLvrnLpQEX5yLh2Y=; b=T7dLLiMN0+JinZ1v8ofCsBWO1paEEbM0Kvm5dRtNtvkxErBlQLGaLpqq WDJ8Bw6xAQTNWT2VgjSaAHuD/fLA+Y+6BQlUApD/Gt0UTLJ8qsrwGnWX5 6zXWMi6NUCh0dCqyu94E4lBIOwWJfVP8Hy65j/FUGZRzAYriCiWiRV2rT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsLABfM/FKrRDoJ/2dsb2JhbABZgwY4q0oBlE8DBAKBFhZ0gyU8LQeIZQ7IKBeOeR2EIgSJSJAWkHGDTg X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="103080587" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 13 Feb 2014 13:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1DDj0k0017214; Thu, 13 Feb 2014 13:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1DDj0911080; Thu, 13 Feb 2014 05:45:00 -0800 (PST) Date: Thu, 13 Feb 2014 05:45:00 -0800 (PST) From: Message-Id: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-cui-v6ops-lte-lw4over6@tools.ietf.org Subject: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Feb 2014 13:45:06 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a look at it and comment. From cb.list6@gmail.com Thu Feb 13 05:53:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257C41A024D for ; Thu, 13 Feb 2014 05:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm3005ou17yp for ; Thu, 13 Feb 2014 05:53:57 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id E67AA1A0276 for ; Thu, 13 Feb 2014 05:53:55 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hi5so8620662wib.9 for ; Thu, 13 Feb 2014 05:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rmZBE8RTWKfq6b9y0xs5rE08Ln4g/3CKmX5MHqrEyRI=; b=J8ETxhwrbi6W3Bezh/ypsn/V5MLMsLlij/5I4kHVt/9LuhpJPYNAxduAwzx69lFfqa +LyszsZ3ImvuKJkfcMaMnqUebousFg9lin5okbF4gRZM1RFiu2p+ICYgIz71+yGlZJsG NsOr1q8mdCNSWU4XSbg8DIXUEVPgGi2VbeIKnqYlGeQlgoG0fClaQLJwFzfZdkdt6F86 KYVtm7dhZbq2zB0SHhKha8Ba81xomKAhFrjwMrQyTMOV5//sF4TTrWF9HwN3OMBx2A/q MbO/CiiVx3ca1Ojc6x3mXJ21WE47tjDYDY+u31lQt17sfSYZ/jNBns93yaR6BcCAY+sB r3AQ== MIME-Version: 1.0 X-Received: by 10.194.22.68 with SMTP id b4mr1511172wjf.6.1392299634210; Thu, 13 Feb 2014 05:53:54 -0800 (PST) Received: by 10.194.133.169 with HTTP; Thu, 13 Feb 2014 05:53:54 -0800 (PST) In-Reply-To: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> References: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> Date: Thu, 13 Feb 2014 05:53:54 -0800 Message-ID: From: Cb B To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-cui-v6ops-lte-lw4over6@tools.ietf.org Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Feb 2014 13:53:59 -0000 On Thu, Feb 13, 2014 at 5:45 AM, wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a look at it and comment. > This draft is suggesting modification to the 3GPP defined nodes such as the eNodeB and PGW. It would be better if these modifications to 3GPP defined nodes were examined in the 3GPP, not the IETF. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Thu Feb 13 05:59:00 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7297E1A027F for ; Thu, 13 Feb 2014 05:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 V7NL_5AsQU6F for ; Thu, 13 Feb 2014 05:58:57 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id B06BB1A025D for ; Thu, 13 Feb 2014 05:58:57 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 807D69C; Thu, 13 Feb 2014 14:58:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 761309A; Thu, 13 Feb 2014 14:58:55 +0100 (CET) Date: Thu, 13 Feb 2014 14:58:55 +0100 (CET) From: Mikael Abrahamsson To: fred@cisco.com In-Reply-To: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> Message-ID: References: <201402131345.s1DDj0911080@ftpeng-update.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 Cc: v6ops@ietf.org, draft-cui-v6ops-lte-lw4over6@tools.ietf.org Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Feb 2014 13:59:00 -0000 On Thu, 13 Feb 2014, fred@cisco.com wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a > look at it and comment. This document makes me very confused. Traditionally, the eNodeB has basically done GTP-RLC (or whatever protocol is used on the radio layer) conversion. All the setup has been done using 3GPP protocols. This document proposes to use DHCPv6oDHCPv4 with the eNodeB as a *client*. When I read the document, I don't understand what communication is done within the GTP tunnel, what is done outside the tunnel, and what role the eNodeB has in this. In 4 for instance: "The architecture described here addresses a typical use case, where an eNodeB's uplink supports IPv6 only and a UE using IPv4 in this eNodeB wants to access IPv4 Internet. The network architecture is shown in Figure 1. In this scenario, the UE can only use the IPv6 network to access IPv4 services, so IPv4 services must be configured over IPv6." I don't understand this statement. It's completely possible to set up an GTP tunnel over IPv6, which then can carry both IPv4 and IPv6 traffic. So it's not problem to support UEs with IPv4, IPv6 or DS uplinks, in current 3GPP architecture, over a pure IPv6 mobile backhaul network. I'm very confused what problem this document tries to solve. -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Thu Feb 13 09:22:58 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D751A0346 for ; Thu, 13 Feb 2014 09:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.049 X-Spam-Level: X-Spam-Status: No, score=-115.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxXmPWZ6KDXY for ; Thu, 13 Feb 2014 09:22:56 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA5D1A0323 for ; Thu, 13 Feb 2014 09:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2046; q=dns/txt; s=iport; t=1392312172; x=1393521772; h=from:to:cc:subject:date:message-id:mime-version; bh=ftBf0Kd2BtYP4xskUKSaycTfmwGZ49hhJ0Zo02uj1TU=; b=EuGrb8MpeQPtdpXmAIPPKwfO9ClGBvjfGK+/Y7M/Ud9SrU6QcqshrNA0 m63jnWZcRa8/FI77mqbBvObwUxFAUtQPCxqz6p8jKukHzrzjtwbKyICIg YOO3jAQEUxXFBB4iifbP9nH65bJYZCDH5PaV9qJRuns8ted9tbf1NsSJb U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FALr+/FKtJXG8/2dsb2JhbABZgwY4V79MgRgWdIIseRIBgQAnBA4TDYdqDcd6F455gyuBFASQQIEyhjqBMpBxgy2CKg X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="asc'?scan'208";a="303963065" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 13 Feb 2014 17:22:51 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DHMpsp014212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 17:22:51 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.227]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 11:22:51 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: BGP Identifier Thread-Index: AQHPKOA4MyipLngEZ0OWIYFcgQevoA== Date: Thu, 13 Feb 2014 17:22:50 +0000 Message-ID: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_3B84C374-1247-4779-85FE-CFD299D52498"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "draft-fan-idr-ipv6-bgp-id@tools.ietf.org" Subject: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Feb 2014 17:22:58 -0000 --Apple-Mail=_3B84C374-1247-4779-85FE-CFD299D52498 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The chairs have received a request from the authors of http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, 2014-02-12 who would like to discuss it with other operators in the coming meeting. = It is, of course, an idr draft and will be pursued there. But idr thinks = it has a solution for this problem in=20 https://tools.ietf.org/html/rfc6286 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4. E. Chen, J. Yuan. June 2011. (Format: TXT=3D7497 bytes) (Updates RFC4271) (Status: PROPOSED STANDARD) which relaxes the definition of the BGP Identifier to be a 4-octet, = unsigned, non-zero integer and relaxes the "uniqueness" requirement so = that only Autonomous-System-wide (AS-wide) uniqueness of the BGP = Identifiers is required. In other words, in an IPv6-only AS, the = operator may assign a 32 bit value as his BGP Identifier. China Mobile = finds this cumbersome, requiring what amounts to planning and manual = intervention in something that is automatic in IPv4 networks, and would = like to be able to use an IPv6 address as a BGP identifier directly. The question, post-discussion, is whether v6ops should advise idr that = the draft would be of operational interest and value. Do you want John and I to include it in the agenda? --Apple-Mail=_3B84C374-1247-4779-85FE-CFD299D52498 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 iD8DBQFS/P9objEdbHIsm0MRAjK5AKDLpGbNemaVNyPcKHGcJgcHSYNBNQCfeJ6x izbeP4Q38upzbmvOVZuj3ts= =wl3Y -----END PGP SIGNATURE----- --Apple-Mail=_3B84C374-1247-4779-85FE-CFD299D52498-- From nobody Thu Feb 13 10:52:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8741A03E4 for ; Thu, 13 Feb 2014 10:52:20 -0800 (PST) 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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, 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 bv5PxPMJvgxW for ; Thu, 13 Feb 2014 10:52:18 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B8AB21A03FA for ; Thu, 13 Feb 2014 10:52:15 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id lj1so11092156pab.26 for ; Thu, 13 Feb 2014 10:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RFBpBkQ4+2EERBJIzvEgExWDv2ssTItXZUZkKbPLbhY=; b=ZfmvCa33HZfmmcwNjiGB4KdrN7Y245QrWimgl9JL8RegtFqOHa+nAupc4RBCe7KMd5 D+t0Bk8Pjn3GE33b30d7hI+jg+o1s2PVXbQvBO2UlT32uKro0o5gFd2INtrDBQDirwpp OLyJ3zRbH7ZrYBfzySEcM42rl+a1iosJlJPWVZuTO4T3y2u/V9X51d4XuratA36BW3b4 Exp2XLPVU6pFdF42VM0yPKDrCn5gnZw6bc6j/+66uSwqG3OiYh1ih0z9v4xvMqQJbAg9 YTUizBel144IzljhU/RdzOnMJqGFhvfr3o6lrZ5jb4BpiciKbcgjhIWlrJOYvXEM7OOT IXWQ== X-Received: by 10.66.179.143 with SMTP id dg15mr3714914pac.52.1392317534644; Thu, 13 Feb 2014 10:52:14 -0800 (PST) Received: from [192.168.1.115] (222-154-169-111.jetstream.xtra.co.nz. [222.154.169.111]) by mx.google.com with ESMTPSA id vf7sm9060160pbc.5.2014.02.13.10.52.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 10:52:13 -0800 (PST) Message-ID: <52FD1464.2010803@gmail.com> Date: Fri, 14 Feb 2014 07:52:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> <52FB956A.8010402@bogus.com> <1392227026.8043.YahooMailNeo@web125106.mail.ne1.yahoo.com> <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com> In-Reply-To: <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4IIpXEfUm4qPacfcW0Wius3mlrI Cc: "v6ops@ietf.org" Subject: Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Feb 2014 18:52:20 -0000 There is already https://datatracker.ietf.org/doc/draft-dreibholz-ipv4-flowlabel/ However, RFC 6437 already makes it acceptable to apply a new flow label at a suitable point such as the exit from a v4 to v6 translator. Regards Brian On 13/02/2014 11:06, Fred Baker (fred) wrote: > On Feb 12, 2014, at 9:43 AM, sajjad akbar wrote: > >> Thanks for referring the RFC. I just go through to it, yes, there may be issue of acceptability for OPTION headers. >> >> However, OPTION headers provides opportunity to pass some information to the networks. For the proof of concepts, we can do this until to explore a new way :)to survive FlowLable information. > > I see no problem with specifying an experimental flow label option in IPv4. I'd suggest that you write an 'experimental' internet draft and get an option number from IANA using the usual procedures. It will likely need to be run through the Independent Submissions Editor, as the IETF is not currently working on significant enhancements to IPv4. > > It may be simpler for you to get IPv6 service on the network path in question, however. If you're going to the effort to put the flow label into a tunnel header, I have to believe that you plan to in some way use that optional information, and you will need to specify and implement that as well. It seems, frankly, like a diversion of effort; you have more to show at the end of the experiment if it's in IPv6 and you can recommend deployment. > >> looking forward for comments. >> >> Regards >> Sajjad >> Team Lead IPv6 Project >> Pakistan >> >> >> >> >> >> On Wednesday, February 12, 2014 8:38 PM, joel jaeggli wrote: >> On 2/12/14, 6:42 AM, sajjad akbar wrote: >>> >>> Dear fellows >>> >>> We are working on 2 year funded project "Design and Development of Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Application" in Pakistan under research group CoReNeT (www.corenet.edu.pk). loss >>> Flowlabel information lost in case of tunneling and translation as IPv4 header does not have such QoS field. We have design an algorithm which stores Flowlabel information in IPv4 header.For storage we use the OPTION field of IPv4(24 bit long).Further, each intermediate router (IPv4 only)will extract the Flowlable information and will provide flow base service to a long session of multimedia communication. >>> >>> Please guide us in this regard that either our direction is right or you suggest some modification. >> new IP options don't have a good history with respect to acceptance by >> the network. >> >> http://tools.ietf.org/html/rfc7126#section-3 >> >> >>> >>> _______________________________________________ >>> 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 > > If at first the idea is not absurd, then there is no hope for it. > Albert Einstein > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 13 18:10:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24DF1A003D for ; Thu, 13 Feb 2014 18:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.616 X-Spam-Level: X-Spam-Status: No, score=0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_NOBODY=2.616, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHm-hfIVtRri for ; Thu, 13 Feb 2014 18:10:39 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D7CA51A0035 for ; Thu, 13 Feb 2014 18:10:39 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id p10so11322655pdj.29 for ; Thu, 13 Feb 2014 18:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8stfzTrh7LtlmMw3ZOIm6ggGhRRvtQ3mMNJRb0xgQdM=; b=cz5b0xtfCLefxeHvmbYU+sxA5cAomv5XRMDZJ56iJbCaf6ZrXVG3tg1ynmjUyuN65X rDZvXF+IHNJL+Q89RlDB0UJsf9yKDwtJLFCeFwRwbbB8ENmz4hlmf1hqmqaAM24G4yTM p5/JkbmgoxIRid6NghoTXMkKSxDddsi92OAt1g5Y2xYz3Rl8DZRXkVcAJ/F1kKLf79dl Vg94tzuofK5SYf6J/xuT6KkI71itN/wg8XSbKG5820no5JOZfdTupY30dyJhim6EA3Ep 0xs5cNuyUYDlLO8SJqmipTBWSSCfBnGxZGUwk7f3zME2GCtWeO+Bznv/X8V4M8IhmTwP 2A0A== X-Received: by 10.68.201.97 with SMTP id jz1mr5809663pbc.26.1392343838584; Thu, 13 Feb 2014 18:10:38 -0800 (PST) Received: from [192.168.0.104] ([60.215.217.244]) by mx.google.com with ESMTPSA id sy10sm28054621pac.15.2014.02.13.18.10.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 18:10:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Fri, 14 Feb 2014 10:10:23 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8298F29C-A50E-459D-96B7-88C0ED2A44FF@gmail.com> References: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/90I3nkjvtEvJn5-9O69zVv9ZjUQ Cc: draft-cui-v6ops-lte-lw4over6@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 02:10:42 -0000 Hi Mikael, Thanks for your comments! Please see inline. Please don't hesitate to point out if there is any mistake. Thank you! //sorry for send it again (used an wrong mailbox previously) On 2014-2-13, at =E4=B8=8B=E5=8D=889:58, Mikael Abrahamsson wrote: > On Thu, 13 Feb 2014, fred@cisco.com wrote: >=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a = look at it and comment. >=20 > This document makes me very confused. >=20 > Traditionally, the eNodeB has basically done GTP-RLC (or whatever = protocol is used on the radio layer) conversion. All the setup has been = done using 3GPP protocols. [Qi] But the eNodeB still needs an IP address, which is allocated = through DHCP.=20 >=20 > This document proposes to use DHCPv6oDHCPv4 with the eNodeB as a = *client*. [Qi] When the eNodeB launches, it needs to setup the default bearer to = get configuration. In this process, DHCPv6 is used for IPv6 = configuration. So we are thinking if DHCPv4oDHCPv6 could be used to = configure the eNodeB with an IPv4 address over the IPv6 network. > When I read the document, I don't understand what communication is = done within the GTP tunnel, [Qi] Typically, it's the IPv4-GTP-IPv6 encapsulation and just data = forwarding within the GTP tunnel.=20 > what is done outside the tunnel, [Qi] We think it could be the private-public IPv4 address translation = (including source port mapping on the eNodeB), and the mapping lookup on = the PGW when there are packets back to the UE from the IPv4 Internet. > and what role the eNodeB has in this. [Qi] The eNodeB could play the role of the "gateway" for the UEs, i.e. = allocating private IPv4 addresses to the UEs and do the private-public = IPv4 translation within a restricted port range.=20 >=20 > In 4 for instance: >=20 > "The architecture described here addresses a typical use case, where > an eNodeB's uplink supports IPv6 only and a UE using IPv4 in this > eNodeB wants to access IPv4 Internet. The network architecture is > shown in Figure 1. In this scenario, the UE can only use the IPv6 > network to access IPv4 services, so IPv4 services must be configured > over IPv6." >=20 > I don't understand this statement. It's completely possible to set up = an GTP tunnel over IPv6, which then can carry both IPv4 and IPv6 = traffic. So it's not problem to support UEs with IPv4, IPv6 or DS = uplinks, in current 3GPP architecture, over a pure IPv6 mobile backhaul = network. >=20 > I'm very confused what problem this document tries to solve. [Qi] The proposal is trying to use tunneling mechanism (lw4over6) to = help LTE networks and users to transition to pure IPv6. We intend to = make use of the GTP tunnel for encapsulation and avoid modifications on = the UEs. In addition, the PGW can avoid large scale NAT at the cost of = assign shared public IPv4 addresses to the eNodeBs.=20 The difference to the usage of xlat464 in LTE would be: no changes to = UEs, and no large scale NAT (translation) on the PGW. Maybe we are not depict the purpose precisely. Please feel free to = comment. Thanks again. Best Regards, Qi >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops Dear , Best Regards, Qi Sun From nobody Thu Feb 13 18:10:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6A1A0035 for ; Thu, 13 Feb 2014 18:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qidnynHdGyWJ for ; Thu, 13 Feb 2014 18:10:52 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 16FB41A006A for ; Thu, 13 Feb 2014 18:10:52 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fa1so11678028pad.28 for ; Thu, 13 Feb 2014 18:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=769ObbmZ4v4OOPEZBpTOFon1j0kEzxXjbKCwYX8zo2U=; b=gduC1dmuFWFOrgxTm23qRKmoNvNRBEsJrjprhXH5khHWekeoq+ha2nRRqWpAMwX91L 94s/8zq5ytv7MuO6WwEFwKAC5lVP3OCHuwmlYe1yDk/lOBpPCOZnb99xnYNQ8gaxWW8Q KxNsj7hU6Dm7Nd9WxrVECJpy9vQrtVO77+IOUTkkqvkpw4RZ6R61/tC9bdEQxCG1ta+/ g53cHxLswmfCclplqP5+I5rJ3cBONCqNu5xdu/pZYjCCAnjTkm2EOgezWlmJfur8pvDG R+Ci+Q4w7xPknfe8Sg1eF8KvcU+DCnhnMFW+/G4mTN/CC56WBu7az10s7hquxDUEXEsb bIqg== X-Received: by 10.68.14.130 with SMTP id p2mr5723503pbc.17.1392343850928; Thu, 13 Feb 2014 18:10:50 -0800 (PST) Received: from [192.168.0.104] ([60.215.217.244]) by mx.google.com with ESMTPSA id sy10sm28054621pac.15.2014.02.13.18.10.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 18:10:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Fri, 14 Feb 2014 10:10:44 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <57221784-C0E3-47C0-898C-060AEE51C190@gmail.com> References: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> To: Cb B X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8TAAvUW0E2ggbRLP81slY2_Rlwk Cc: draft-cui-v6ops-lte-lw4over6@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 02:10:54 -0000 Hi, Thanks for comments! We are just trying to just add some existing functions (that are defined = in the IETF) to LTE nodes. Would that be OK to discuss it in the IETF? Best Regards, Qi //sorry for send it again (used an wrong mailbox previously) On 2014-2-13, at =E4=B8=8B=E5=8D=889:53, Cb B wrote: > On Thu, Feb 13, 2014 at 5:45 AM, wrote: >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a = look at it and comment. >>=20 >=20 >=20 > This draft is suggesting modification to the 3GPP defined nodes such > as the eNodeB and PGW. It would be better if these modifications to > 3GPP defined nodes were examined in the 3GPP, not the IETF. >=20 > CB >=20 >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 13 22:51:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0143A1A00C5; Thu, 13 Feb 2014 22:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuC2C2EGFuj0; Thu, 13 Feb 2014 22:51:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE5F1A0111; Thu, 13 Feb 2014 22:51:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WECcZ-0000cq-Mk; Fri, 14 Feb 2014 06:51:36 +0000 Date: Fri, 14 Feb 2014 15:51:34 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sk17pjVqGcgKT97rdHmRiDbHjgg Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 06:51:40 -0000 > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > 2014-02-12 please no. if you can not assign a unique four octet integer to each router in your network, then you have much bigger problems. and adding a capability and more complexity to try to patch over your inability to configure your routers will just compound your problems. randy From nobody Thu Feb 13 23:21:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270B41A0149 for ; Thu, 13 Feb 2014 23:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, 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 f_sRtqYEK7VR for ; Thu, 13 Feb 2014 23:21:49 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 691971A0116 for ; Thu, 13 Feb 2014 23:21:49 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CFC149C; Fri, 14 Feb 2014 08:21:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C944B9A; Fri, 14 Feb 2014 08:21:46 +0100 (CET) Date: Fri, 14 Feb 2014 08:21:46 +0100 (CET) From: Mikael Abrahamsson To: Qi Sun In-Reply-To: Message-ID: References: <201402131345.s1DDj0911080@ftpeng-update.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: http://mailarchive.ietf.org/arch/msg/v6ops/PvXLYRCnMFyUTxJ7wJ7plPPviUo Cc: draft-cui-v6ops-lte-lw4over6@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 07:21:52 -0000 On Fri, 14 Feb 2014, Qi Sun wrote: > [Qi] The eNodeB could play the role of the "gateway" for the UEs, i.e. > allocating private IPv4 addresses to the UEs and do the private-public > IPv4 translation within a restricted port range. This is a fundamental change of the role of the eNodeB. You can't make that change in the IETF, you need to go to 3GPP to do this. I imagine this has huge implications to how the control plane is handled, because now the eNodeB needs to intercept control plane messages to/from the UE to fake the bearer type of the GTP tunnel etc. Also, when doing handover, this information needs to follow. So while I am all for changing how LTE works to have things more distributed, I don't see how this way would work in the manner described. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 14 00:51:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D3C1A0115 for ; Fri, 14 Feb 2014 00:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, 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 kovmtgk6gtyu for ; Fri, 14 Feb 2014 00:51:37 -0800 (PST) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE011A0179 for ; Fri, 14 Feb 2014 00:51:36 -0800 (PST) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "v6ops@ietf.org" Date: Fri, 14 Feb 2014 09:51:32 +0100 Thread-Topic: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 Thread-Index: Ac8owd+2dNL6The/SDe7lo5wLYQoxAAnWaPQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA3256B25D@SRVHKE02.rdm.cz> References: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> In-Reply-To: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-loop: 2 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DclLCWjtWNlgLgqYY3C53z9B6xA Cc: "draft-cui-v6ops-lte-lw4over6@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 08:51:39 -0000 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Thursday, February 13, 2014 2:45 PM > To: v6ops@ietf.org > Cc: draft-cui-v6ops-lte-lw4over6@tools.ietf.org > Subject: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 >=20 >=20 > A new draft has been posted, at > http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. > Please take a look at it and comment. IETF V6OPS is not the right place for such an architectural change.=20 A problem statement may fit to start the discussion, but 3GPP SA1/SA2=20 is the place to get this kind of change done. Ales From nobody Fri Feb 14 01:06:10 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0841A01EA; Fri, 14 Feb 2014 01:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, 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 gMpiw22HdVKX; Fri, 14 Feb 2014 01:05:51 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id B81AD1A011E; Fri, 14 Feb 2014 01:05:50 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so8984619lbi.21 for ; Fri, 14 Feb 2014 01:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hXWYXiHxf5Rj3TRsYdaJkYsQPpWJIth5C23uVS+aR4U=; b=OxiGYeknqEnKEFBShxgNFllSUoJ3ilWua1YwfAq8zq0dpkcKjzh12s6zTOctZV37wL lnXo9wDEP4yOtE3WFRKr7AObXHOmK8/uqj1rkBojCrO9DplsUZnBn8uY6X4+vTrLlt3X Rc5sBLbO4r7SKmcT+1kQ33PcXj9Eu9WEshnk4SXPt7e9QuA2IwMOV2OG7W+yDCnO/Gcy Kp7SPjEGttcJEpH6YszHU40WLsfKa5nV5SfwHk1l7+a+i8ejDqUZrwUkOWMjFEJnQSOb 7YWCEDbjMJn98NJmuV1EmvSCvWdNU0jY9ZDZufZ3tbifzJmBW6qz/AiHCyFiLtY8coeb 6vTQ== MIME-Version: 1.0 X-Received: by 10.112.172.8 with SMTP id ay8mr1333531lbc.41.1392368748481; Fri, 14 Feb 2014 01:05:48 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Fri, 14 Feb 2014 01:05:48 -0800 (PST) In-Reply-To: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> Date: Fri, 14 Feb 2014 10:05:48 +0100 X-Google-Sender-Auth: 11kLKKNItesOtjQrTGQJuEnGBlo Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c2b3f0a651e304f25a1c03 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Crr56b7kPM4Zdlq_4rdjUQpoQvI Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 09:05:53 -0000 --001a11c2b3f0a651e304f25a1c03 Content-Type: text/plain; charset=ISO-8859-1 I agree with Randy'a point here. BGP rtr_id does not need to be a routable address - it just needs to be unique 32 bits within the domain scope. We have had this discussion already during RFC6286 and concluded that 4 octet is sufficient for any type of BGP mesh. If anything I would propose to go opposite and to ask your implementation to allow UTF-8 encoded BGP rtr_id format. Rgs, R. On Fri, Feb 14, 2014 at 7:51 AM, Randy Bush wrote: > > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > > 2014-02-12 > > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and adding > a capability and more complexity to try to patch over your inability to > configure your routers will just compound your problems. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a11c2b3f0a651e304f25a1c03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Randy'a point here.=A0

BGP rtr_id does not need to be a routable address -= it just needs to be unique 32 bits within the domain scope.=A0

We have had this discussion already during RFC6286 = and concluded that 4 octet is sufficient for any type of BGP mesh.=A0
=

If anything I would propose to go opposite and to a= sk your implementation to allow UTF-8 encoded BGP rtr_id format.=A0

Rgs,
R.

On Fri, Feb 14, 2014 at 7:51 AM, Randy Bus= h <= randy@psg.com> wrote:
> http://tools.ie= tf.org/html/draft-fan-idr-ipv6-bgp-id
> =A0 "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zh= enqiang Li,
> =A0 2014-02-12

please no. =A0if you can not assign a unique four octet integer to ea= ch
router in your network, then you have much bigger problems. =A0and adding a capability and more complexity to try to patch over your inability to
configure your routers will just compound your problems.

randy

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--001a11c2b3f0a651e304f25a1c03-- From nobody Fri Feb 14 01:13:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCBC1A01C8; Fri, 14 Feb 2014 01:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCT1dQxEnQFn; Fri, 14 Feb 2014 01:13:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D490C1A01C9; Fri, 14 Feb 2014 01:13:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 01:13:02 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z4ftiF3O_MEgUN0DcyWIYADxDiI Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.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: Fri, 14 Feb 2014 09:13:05 -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 : Recommendations of Using Unique Local Addresses Authors : Bing Liu Sheng Jiang Filename : draft-ietf-v6ops-ula-usage-recommendations-02.txt Pages : 15 Date : 2014-02-14 Abstract: This document provides guidance of how to use ULAs. It analyzes ULA usage scenarios and recommends use cases where ULA addresses might be beneficially used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendations/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-recommendations-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 01:34:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A041A010C for ; Fri, 14 Feb 2014 01:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxRLDmpa7Grc for ; Fri, 14 Feb 2014 01:34:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6BF1A00A8 for ; Fri, 14 Feb 2014 01:34:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WEFAM-0000xO-7J for v6ops@ietf.org; Fri, 14 Feb 2014 09:34:38 +0000 Date: Fri, 14 Feb 2014 18:34:36 +0900 Message-ID: From: Randy Bush To: V6 Ops List In-Reply-To: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3BCMauTyIY-M2SBWzGnVD6Mrzb4 Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:34:42 -0000 i expected this to be a short draft. "Don't" randy From nobody Fri Feb 14 02:00:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB90B1A010C for ; Fri, 14 Feb 2014 02:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phIgVvgGKjrc for ; Fri, 14 Feb 2014 02:00:26 -0800 (PST) Received: from sender1.zohomail.com (sender1.zohomail.com [72.5.230.100]) by ietfa.amsl.com (Postfix) with ESMTP id B80481A00F9 for ; Fri, 14 Feb 2014 02:00:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zoho; d=internetdraft.org; h=date:from:to:cc:message-id:in-reply-to:references:subject:mime-version:content-type:user-agent; b=aHZVqRi2joQBGMNuohHbcvn6swj2w9DuhcQd+NYw2gysMstpMinRbeFFQPpr/RCDamRXtAwU28Rw lhG1/oCQhWZFR9qkR0DdSuidipxYlofMGuzDKBpvWW++6UiBx+rkpAf52SKtAQi4BhNoST6ul7EY IipiHNm+mDstcR54ZV8= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1392372009043315.3477377331234; Fri, 14 Feb 2014 02:00:09 -0800 (PST) Date: Fri, 14 Feb 2014 19:00:08 +0900 From: ek To: Randy Bush Message-ID: <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> In-Reply-To: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_152525_2080981814.1392372008988" X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/it5nSIt2j3oi-zdXeFExlve7_4M Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 10:00:30 -0000 ------=_Part_152525_2080981814.1392372008988 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit +1 ---- On Fri, 14 Feb 2014 18:34:36 +0900 Randy Bush<randy@psg.com> wrote ---- i expected this to be a short draft. "Don't" randy _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_152525_2080981814.1392372008988 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit
+1

---- On Fri, 14 Feb 2014 18:34:36 +0900 Randy Bush<randy@psg.com> wrote ----

i expected this to be a short draft. "Don't"

randy

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

------=_Part_152525_2080981814.1392372008988-- From nobody Fri Feb 14 05:55:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D01A025A; Fri, 14 Feb 2014 05:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh7UGrlMzS0O; Fri, 14 Feb 2014 05:55:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 998951A0224; Fri, 14 Feb 2014 05:55:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214135513.1455.80834.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 05:55:13 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7hRlYu5vWnBJ5-PZVM4bXHDuAgE Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:55: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 : IPv6 Multihoming without Network Address Translation Authors : Ole Troan David Miles Satoru Matsushima Tadahisa Okimoto Dan Wing Filename : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.txt Pages : 21 Date : 2014-02-14 Abstract: Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of NPTv6. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 12:13:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2001A03D8; Fri, 14 Feb 2014 12:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GcW80BdPHxAF; Fri, 14 Feb 2014 12:13:24 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3471A03CD; Fri, 14 Feb 2014 12:13:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id B493A37; Fri, 14 Feb 2014 21:13:21 +0100 (CET) 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 10024) with ESMTP id ZDOeUIUaTBPJ; Fri, 14 Feb 2014 21:13:19 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id 69A4134; Fri, 14 Feb 2014 21:13:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: Date: Fri, 14 Feb 2014 21:13:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/92OkiGElGpzEhB5Rltdl4o_EN0w Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 20:13:26 -0000 Hi, >> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >> 2014-02-12 >=20 > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and = adding > a capability and more complexity to try to patch over your inability = to > configure your routers will just compound your problems. I agree. It's a shame that the router-id looks like an IPv4 address and = IPv4 addresses are used to auto-configure it when the operator doesn't = explicitly set it. There are too many people that think that a router-id = is more than a 32-bit number and must be an IPv4 address, but creating = more complexity to avoid educating router operators isn't the answer... Cheers, Sander From nobody Fri Feb 14 13:14:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2551A03DF; Fri, 14 Feb 2014 13:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 N8Jzirr7K6TP; Fri, 14 Feb 2014 13:14:38 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 30F451A043A; Fri, 14 Feb 2014 13:14:34 -0800 (PST) Received: from [IPv6:2601:4:2180:300:7ed1:c3ff:feec:5ab7] ([IPv6:2601:4:2180:300:7ed1:c3ff:feec:5ab7]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s1ELETrT000455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 16:14:29 -0500 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Fri, 14 Feb 2014 16:14:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [IPv6:2001:418:3f4::5]); Fri, 14 Feb 2014 16:14:30 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BZMoSE9Dhjy0TN-1Sjat3LwbDc4 Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 21:14:40 -0000 On Feb 14, 2014, at 3:13 PM, Sander Steffann wrote: > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and = adding >> a capability and more complexity to try to patch over your inability = to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer... +1 Perhaps this is another thing like ASDOT vs ASPLAIN where we can shift = the configuration on devices to accept a decimal number? - Jared= From nobody Fri Feb 14 13:17:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233BE1A0375; Fri, 14 Feb 2014 13:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 peTdDHRcEVU1; Fri, 14 Feb 2014 13:17:13 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id CE34E1A02C0; Fri, 14 Feb 2014 13:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1599; q=dns/txt; s=iport; t=1392412631; x=1393622231; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lymx2vxGX8hLLnnVSCeoveMxqGzTh1Z3qu2p4ufGTgs=; b=J/23bBPjJ6hIAfJj47X9DtT985vDbQcPyyj6JT6lh81gLbVGJX8ZnAVI qd+yWw8QM1sAdgHWUsJXFZFb9YowrMofiv29VpPnpndNx1bxNTjeXm9J4 d4kPupaym9v6hf7AgzM1qNXoF0obIet5iVLErGKTb4nruHlQDp6ur5wOc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAK+G/lKtJV2Y/2dsb2JhbABZgwY4wAaBGBZ0giUBAQEDAQEBATc0CwULAgEIGB4QJwslAgQOBYd9CA3ITxeORjMHgySBFASYLIEykHGDLQ X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208";a="20600500" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 14 Feb 2014 21:17:11 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1ELHBJT023416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 21:17:11 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.214]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 15:17:10 -0600 From: "Rajiv Asati (rajiva)" To: Sander Steffann Thread-Topic: [v6ops] BGP Identifier Thread-Index: AQHPKcE/TYiQMAjLk0S8LJu44RYd7Zq1QLyf Date: Fri, 14 Feb 2014 21:17:09 +0000 Message-ID: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rlwsy27F74hitBjLP4NeLPzTjwE Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 21:17:15 -0000 +1.=20 We had a bit of discussion on MPLS WG ~2yrs ago during LDP-ipv6 formulation= and we managed to quickly put the suggestion about LDP router-id being a 1= 28-bit entity in the back burner.=20 Good or bad - many vendor implementations historically tied router-id to an= interface in addition or instead of a 4-context entity. Thankfully, many h= ave already evolved to not continue with that model in the v6 paradigm. Jus= t a matter of time for others to catch up.=20 Cheers, Rajiv > On Feb 14, 2014, at 2:13 PM, "Sander Steffann" wrote= : >=20 > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and adding >> a capability and more complexity to try to patch over your inability to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address and I= Pv4 addresses are used to auto-configure it when the operator doesn't expli= citly set it. There are too many people that think that a router-id is more= than a 32-bit number and must be an IPv4 address, but creating more comple= xity to avoid educating router operators isn't the answer... >=20 > Cheers, > Sander >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 14 13:29:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685D61A0331 for ; Fri, 14 Feb 2014 13:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zppsJ3kTHofH for ; Fri, 14 Feb 2014 13:29:43 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 33CAA1A023F for ; Fri, 14 Feb 2014 13:29:37 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s1ELTKAD011979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Feb 2014 13:29:20 -0800 (PST) Message-ID: <52FE8AB0.8050501@isi.edu> Date: Fri, 14 Feb 2014 13:29:20 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , sajjad akbar References: <1392216176.40461.YahooMailNeo@web125102.mail.ne1.yahoo.com> <52FB956A.8010402@bogus.com> <1392227026.8043.YahooMailNeo@web125106.mail.ne1.yahoo.com> <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com> In-Reply-To: <42B119FE-01D7-4927-BB44-1AFCB681024C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/D_ZDMw40WFlIvrD0U6CqFN9hB_g Cc: "v6ops@ietf.org" Subject: Re: [v6ops] No loss of Flowlabel (IPv6 QoS) information in case of tunneling and translation: Astep forward to IPv6 QoS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 21:29:46 -0000 FWIW, there are already IPv4 option codepoints assigned for experiments, provided they're deployed in a controlled environment (i.e., can be cleaned up when the experiment is over). See RFC4727. If a more permanent option number is assigned, a standards-track doc might be required*, but this might need to go the route of a temporary, controlled experiment first anyway. Joe *IANA's registry doesn't talk about the level of review required for an IPv4 option codepoint, but I would assume it's at least as difficult to get as a persistent TCP option codepoint. On 2/12/2014 2:06 PM, Fred Baker (fred) wrote: > > On Feb 12, 2014, at 9:43 AM, sajjad akbar wrote: > >> Thanks for referring the RFC. I just go through to it, yes, there may be issue of acceptability for OPTION headers. >> >> However, OPTION headers provides opportunity to pass some information to the networks. For the proof of concepts, we can do this until to explore a new way :)to survive FlowLable information. > > I see no problem with specifying an experimental flow label option in IPv4. I'd suggest that you write an 'experimental' internet draft and get an option number from IANA using the usual procedures. It will likely need to be run through the Independent Submissions Editor, as the IETF is not currently working on significant enhancements to IPv4. > > It may be simpler for you to get IPv6 service on the network path in question, however. If you're going to the effort to put the flow label into a tunnel header, I have to believe that you plan to in some way use that optional information, and you will need to specify and implement that as well. It seems, frankly, like a diversion of effort; you have more to show at the end of the experiment if it's in IPv6 and you can recommend deployment. > >> looking forward for comments. >> >> Regards >> Sajjad >> Team Lead IPv6 Project >> Pakistan >> >> >> >> >> >> On Wednesday, February 12, 2014 8:38 PM, joel jaeggli wrote: >> On 2/12/14, 6:42 AM, sajjad akbar wrote: >>> >>> >>> Dear fellows >>> >>> We are working on 2 year funded project "Design and Development of Hybrid IPv4 and IPv6 Network for QoS Enabled Video Streaming Multicast Application" in Pakistan under research group CoReNeT (www.corenet.edu.pk). loss >>> Flowlabel information lost in case of tunneling and translation as IPv4 header does not have such QoS field. We have design an algorithm which stores Flowlabel information in IPv4 header.For storage we use the OPTION field of IPv4(24 bit long).Further, each intermediate router (IPv4 only)will extract the Flowlable information and will provide flow base service to a long session of multimedia communication. >>> >>> Please guide us in this regard that either our direction is right or you suggest some modification. >> >> new IP options don't have a good history with respect to acceptance by >> the network. >> >> http://tools.ietf.org/html/rfc7126#section-3 >> >> >>> >>> >>> _______________________________________________ >>> 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 > > If at first the idea is not absurd, then there is no hope for it. > Albert Einstein > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Feb 14 15:02:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2160A1A042B; Fri, 14 Feb 2014 15:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 1MXJ-kZfgb6a; Fri, 14 Feb 2014 15:02:39 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 533D31A040C; Fri, 14 Feb 2014 15:02:38 -0800 (PST) Received: from [10.5.16.25] (adsl-69-228-94-95.dsl.pltn13.pacbell.net [69.228.94.95]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1EN18vf004028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 14 Feb 2014 15:01:10 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1EN18vf004028 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392418874; bh=9VKPKi/fD0l3iDJlaXeAIalxwR4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=4DNLI8usxZsgsycbBikWEuADJdcqyxIXy9V84uMixRFEPnVTT160RrwCmUCw4H3yf ojrOKkYRWJWVZaeq/0Nn7Gwph9wuu83dYdWK3gFJV4CYQ6Ekz02hJt9ojqFnJgz2EA 2SrZqlxbHpTO0fDdSskxhRe8VLXP/D6jdUZVHQz8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Fri, 14 Feb 2014 15:01:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3DEC4213-8D0B-488C-AD90-9B26ED2F661E@delong.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 14 Feb 2014 15:01:14 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kJ-Tx3CqhpoFMfE16ExcN2KH4Bk Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 23:02:41 -0000 On Feb 14, 2014, at 12:13 PM, Sander Steffann = wrote: > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and = adding >> a capability and more complexity to try to patch over your inability = to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer=85 +1 Owen From nobody Fri Feb 14 16:09:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7C1A01DD; Fri, 14 Feb 2014 16:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_umKHDPaFTG; Fri, 14 Feb 2014 16:09:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 19CAA1A0140; Fri, 14 Feb 2014 16:09:26 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WESos-000322-Oh; Sat, 15 Feb 2014 00:09:23 +0000 Date: Sat, 15 Feb 2014 09:09:21 +0900 Message-ID: From: Randy Bush To: Mitchell Erblich In-Reply-To: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/69mCUh7xzEzsigWYl9HgvMrUQEo Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 00:09:27 -0000 > I think that some LAN protocols prefer a loopback (assume always up) > addr and then secondarily an interface addr. interesting. and what LAN protocols use the BGP RouterID? randy From nobody Fri Feb 14 17:09:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5755E1A00AE for ; Fri, 14 Feb 2014 17:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-I60DF5rY-5 for ; Fri, 14 Feb 2014 17:09:03 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 527451A0048 for ; Fri, 14 Feb 2014 17:08:48 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so13048146pbb.37 for ; Fri, 14 Feb 2014 17:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Fha6FBGRnFDYMwWZ0xPBMfN+0WxzdmKTqcbi1AzmQcg=; b=y2zCoIv7FPzGpIG4p2Ose+J+nn2fJ2Wg9UUsuD4bg62VHjD8Js9UKqp7imHw7Z/2Us HqEKoYHKSlJ2u2RgnVgt0TLv2gMKt6rIMqwPsnbowWlovs2fcJ+2uiZDxeVgJE8PzxIm 7z2REIeZ4UeEMHkBMOF44kfG34uI0OaUXZ9/CjblM8KuGOKArErOjZQazcfQGyrpVCv/ HolG2RS1BOkuhtvniFuR+y6BulE5DE7z1QIyeEeA2hJa54BarwCAHQK9Rm75HQptjmda WnqxcPqrEFr0IOw0NzDRtqaigNd6uNG9EZgiooBvXiNKNHYC+fH46ZBR9hzAyh8uw8pc ZX+w== X-Received: by 10.68.139.73 with SMTP id qw9mr12315387pbb.121.1392426526783; Fri, 14 Feb 2014 17:08:46 -0800 (PST) Received: from [192.168.178.23] (244.203.69.111.dynamic.snap.net.nz. [111.69.203.244]) by mx.google.com with ESMTPSA id n6sm21562939pbj.22.2014.02.14.17.08.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 17:08:46 -0800 (PST) Message-ID: <52FEBE28.1010006@gmail.com> Date: Sat, 15 Feb 2014 14:08:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ek References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> In-Reply-To: <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/imnst63SbXKqdsU-w0E4zCTbYqU Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:09:05 -0000 Well, there have always been some people against the existence of ULAs, but we did reach rough consensus to define them, since other people see value in them, for reasons that have been aired many times. So writing words about the best way to use them if you want to use them seems right to me. Brian On 14/02/2014 23:00, ek wrote: > +1 > > ---- On Fri, 14 Feb 2014 18:34:36 +0900 Randy Bush<randy@psg.com> wrote ---- > > > i expected this to be a short draft. "Don't" > > randy > > _______________________________________________ > 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 Feb 14 17:17:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4A1A002B for ; Thu, 13 Feb 2014 18:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 jRjtDr_VQqQu for ; Thu, 13 Feb 2014 18:01:08 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 579BF1A0016 for ; Thu, 13 Feb 2014 18:01:08 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id x10so11319167pdj.39 for ; Thu, 13 Feb 2014 18:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ke2SYmVpFVOgQXzp+FwqQQT86M7mp0dsNJ9h4EkOqZQ=; b=ajA/rTMLVa9/WTfxBp9tqenMtT6dh0RrRPwoThYHg3ETXvD/lE14VMH7FAsnH2LOcx j8YiXL5Cpl5HX7V3BV2R8gp10U5TGiaEQagxDK1MlQlGEi0YC/o6eSo1eeRHgiGOKKKe H2nycNro/+iWbBUEBPIsMlDu7lymmxUlb1lmZDyZe1YTDSHUHjzpZv6sp/i83Z6lrGkT pSG0JeT8l+ZO0kszgpqSRuO8XM164AzfF6mM6alV1H3FLsZAlmx8Co8mvHJ6RW090HHJ Pu+d63IgJ9b6E9nEx2tCG34zzNp4wuNmYQXvc0/QFiVEUvgABVzDH4WkMBw0T3FM9Pvx rRVA== X-Received: by 10.68.134.8 with SMTP id pg8mr5790694pbb.84.1392343267083; Thu, 13 Feb 2014 18:01:07 -0800 (PST) Received: from [192.168.0.104] ([60.215.217.244]) by mx.google.com with ESMTPSA id fk4sm27877263pab.23.2014.02.13.18.01.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 18:01:04 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Fri, 14 Feb 2014 10:00:50 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ERpfl9YzefHody_TJnUj6qSJbWM X-Mailman-Approved-At: Fri, 14 Feb 2014 17:17:48 -0800 Cc: draft-cui-v6ops-lte-lw4over6@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 02:01:10 -0000 Hi Mikael, Thanks for your comments! Please see inline. Please don't hesitate to point out if there is any mistake. Thank you! On 2014-2-13, at =E4=B8=8B=E5=8D=889:58, Mikael Abrahamsson wrote: > On Thu, 13 Feb 2014, fred@cisco.com wrote: >=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a = look at it and comment. >=20 > This document makes me very confused. >=20 > Traditionally, the eNodeB has basically done GTP-RLC (or whatever = protocol is used on the radio layer) conversion. All the setup has been = done using 3GPP protocols. [Qi] But the eNodeB still needs an IP address, which is allocated = through DHCP.=20 >=20 > This document proposes to use DHCPv6oDHCPv4 with the eNodeB as a = *client*. [Qi] When the eNodeB launches, it needs to setup the default bearer to = get configuration. In this process, DHCPv6 is used for IPv6 = configuration. So we are thinking if DHCPv4oDHCPv6 could be used to = configure the eNodeB with an IPv4 address over the IPv6 network. > When I read the document, I don't understand what communication is = done within the GTP tunnel, [Qi] Typically, it's the IPv4-GTP-IPv6 encapsulation and just data = forwarding within the GTP tunnel.=20 > what is done outside the tunnel, [Qi] We think it could be the private-public IPv4 address translation = (including source port mapping on the eNodeB), and the mapping lookup on = the PGW when there are packets back to the UE from the IPv4 Internet. > and what role the eNodeB has in this. [Qi] The eNodeB could play the role of the "gateway" for the UEs, i.e. = allocating private IPv4 addresses to the UEs and do the private-public = IPv4 translation within a restricted port range.=20 >=20 > In 4 for instance: >=20 > "The architecture described here addresses a typical use case, where > an eNodeB's uplink supports IPv6 only and a UE using IPv4 in this > eNodeB wants to access IPv4 Internet. The network architecture is > shown in Figure 1. In this scenario, the UE can only use the IPv6 > network to access IPv4 services, so IPv4 services must be configured > over IPv6." >=20 > I don't understand this statement. It's completely possible to set up = an GTP tunnel over IPv6, which then can carry both IPv4 and IPv6 = traffic. So it's not problem to support UEs with IPv4, IPv6 or DS = uplinks, in current 3GPP architecture, over a pure IPv6 mobile backhaul = network. >=20 > I'm very confused what problem this document tries to solve. [Qi] The proposal is trying to use tunneling mechanism (lw4over6) to = help LTE networks and users to transition to pure IPv6. We intend to = make use of the GTP tunnel for encapsulation and avoid modifications on = the UEs. In addition, the PGW can avoid large scale NAT at the cost of = assign shared public IPv4 addresses to the eNodeBs.=20 The difference to the usage of xlat464 in LTE would be: no changes to = UEs, and no large scale NAT (translation) on the PGW. Maybe we are not depict the purpose precisely. Please feel free to = comment. Thanks again. Best Regards, Qi >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 14 17:17:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E80C1A002B for ; Thu, 13 Feb 2014 18:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZY-Dg3PgShn for ; Thu, 13 Feb 2014 18:03:35 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A8C891A0016 for ; Thu, 13 Feb 2014 18:03:35 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id kl14so11716419pab.1 for ; Thu, 13 Feb 2014 18:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dQpM1scbuL+xyXwWHkqcML2lHr8AYinHIMb0nKtZjx0=; b=Eu8YW6artxrooL+MCMiVYPcjkMdmUVTIu9gKHpCehFjefFB3onDNZPY04ZElq9n0tA rKffDvRFVlkchu0FpY8az1YMOG+eo7rcn4sHv2zydApeLKZ4zW5LHrzSS1cCiYyg55qw H0cS9wYSwojDWeMjGaAyYMpXCUH8g0tK31JhyTVrCVjrJA/mR6YQ/SatL0hFQGu4MkGH zXm9U2ZKHuNzkrKjrgRpgFx2FVuKOWm52+IgrHBeBVUG5RjqQ0KPu2lW5da3AhQPC3ua 2uM6y1d7rUGTuql+J2dkOJ05kgrS6WrvsNCt7mavzw4CznjDySxn3J45ml8eXhReC6Uz rXHQ== X-Received: by 10.68.204.161 with SMTP id kz1mr5678523pbc.156.1392343414387; Thu, 13 Feb 2014 18:03:34 -0800 (PST) Received: from [192.168.0.104] ([60.215.217.244]) by mx.google.com with ESMTPSA id ix5sm11076396pbd.36.2014.02.13.18.03.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 18:03:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Fri, 14 Feb 2014 10:03:24 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5996C567-DACC-49F2-8E48-0B3DF7462C9E@gmail.com> References: <201402131345.s1DDj0911080@ftpeng-update.cisco.com> To: Cb B X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/y6tInSMR2UaAgJhNMFtxXzgwoCQ X-Mailman-Approved-At: Fri, 14 Feb 2014 17:17:48 -0800 Cc: draft-cui-v6ops-lte-lw4over6@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-cui-v6ops-lte-lw4over6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 02:03:37 -0000 Hi, Thanks for comments! We are just trying to just add some existing functions (that are defined = in the IETF) to LTE nodes. Would that be OK to discuss it in the IETF? Best Regards, Qi On 2014-2-13, at =E4=B8=8B=E5=8D=889:53, Cb B wrote: > On Thu, Feb 13, 2014 at 5:45 AM, wrote: >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-cui-v6ops-lte-lw4over6. Please take a = look at it and comment. >>=20 >=20 >=20 > This draft is suggesting modification to the 3GPP defined nodes such > as the eNodeB and PGW. It would be better if these modifications to > 3GPP defined nodes were examined in the 3GPP, not the IETF. >=20 > CB >=20 >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 14 17:17:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0681D1A03EA; Fri, 14 Feb 2014 13:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaGqxwrC-K5l; Fri, 14 Feb 2014 13:56:40 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 971891A041E; Fri, 14 Feb 2014 13:56:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XRGro/O9N76JkbeyYo57ODtPkn9zgsBefJXR/wIbrScpuHdLJP7coHF2oSy6UIHy; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [76.21.83.101] (helo=[10.0.1.2]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WEQkK-0002rt-1C; Fri, 14 Feb 2014 16:56:32 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Mitchell Erblich In-Reply-To: Date: Fri, 14 Feb 2014 13:56:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec798185fcf19880707e8156002497107ca4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.21.83.101 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WNfHzUR71cSTYhLkdRnL-kqcoxo X-Mailman-Approved-At: Fri, 14 Feb 2014 17:17:48 -0800 Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Feb 2014 21:56:43 -0000 For some minor consistency, =20 I think that some LAN protocols prefer a loopback (assume always up) = addr and then secondarily an interface addr. Mitchell Erblich On Feb 14, 2014, at 1:05 AM, Robert Raszuk wrote: > I agree with Randy'a point here.=20 >=20 > BGP rtr_id does not need to be a routable address - it just needs to = be unique 32 bits within the domain scope.=20 >=20 > We have had this discussion already during RFC6286 and concluded that = 4 octet is sufficient for any type of BGP mesh.=20 >=20 > If anything I would propose to go opposite and to ask your = implementation to allow UTF-8 encoded BGP rtr_id format.=20 >=20 > Rgs, > R. >=20 >=20 > On Fri, Feb 14, 2014 at 7:51 AM, Randy Bush wrote: > > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang = Li, > > 2014-02-12 >=20 > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and = adding > a capability and more complexity to try to patch over your inability = to > configure your routers will just compound your problems. >=20 > randy >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Fri Feb 14 17:17:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3520A1A01E2; Fri, 14 Feb 2014 16:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPoEd4F_jE1O; Fri, 14 Feb 2014 16:49:12 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 821371A0212; Fri, 14 Feb 2014 16:49:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gjwbHH3s5kyTCpfu1lnK7xTWZ9nYk/I6jx7H41WcfcSpHEAvk1ujB5flWQTPQGPz; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [76.21.83.101] (helo=[10.0.1.2]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WETRO-0000jL-8r; Fri, 14 Feb 2014 19:49:10 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Mitchell Erblich In-Reply-To: Date: Fri, 14 Feb 2014 16:49:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <916A3488-34C9-4A12-BE98-0465978CB41B@earthlink.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79792f28e0e5f181b2a3e71d40ce8c08c8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.21.83.101 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/BNNmyF-DenBRLK-s-do53Ljr3Gw X-Mailman-Approved-At: Fri, 14 Feb 2014 17:17:49 -0800 Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 00:49:14 -0000 Randy A router-id is a router-id. Do you think that every protocol that is enabled on the router = should have a different router-id? So, if you have enabled RIP, OSPFv2, OSPFv3, ISIS, BGP, etc, = then for consistency basis, I think the router SHOULD have 1 router-id.. Now=85 how many implementations have 1 and why shouldn't an = admin attempt to have a router with as few router-ids as possible? Best = 1 unique router-id accross all its enabled and not enabled protocols. So, if you redistributes OSPF routes into BGP (RFC 1403), = wouldn't is be easier to admin with each router having a single = router-id? Mitchell Erblich On Feb 14, 2014, at 4:09 PM, Randy Bush wrote: >> I think that some LAN protocols prefer a loopback (assume always up) >> addr and then secondarily an interface addr. >=20 > interesting. and what LAN protocols use the BGP RouterID?=20 >=20 > randy From nobody Fri Feb 14 17:45:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BA91A0020 for ; Fri, 14 Feb 2014 17:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHL4-96VCywB for ; Fri, 14 Feb 2014 17:44:57 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id AC1EE1A0018 for ; Fri, 14 Feb 2014 17:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4299; q=dns/txt; s=iport; t=1392428696; x=1393638296; h=from:to:cc:subject:date:message-id:mime-version; bh=1rmoCYN1nd6EqrWcc3vCYvJPRwTtNOBMgI/fG8n8y1U=; b=BICwwAKPoCJLDC5nJ4VnI1kmc5PHrokIfOcUxxAfIkKOMEucXinMCuYk GtY2vLx8yFsvUkqcJUGSDuhywmiX/v5uYKqYleswEHJk45TNTgAIPrahI A8ZJeY66yc30Gp75Y2KbtXuvHUwr8Ppo+whqf4nIKq2jZSSsUUNhupwNE Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAC7G/lKtJV2d/2dsb2JhbABZgwY4V780gRcWdIIsZRQSAYEAJwQOBQ6Hdw3IYReOGREBUIMrgRQEkECBMoY6gTKQcYMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,848,1384300800"; d="asc'?scan'208";a="20644829" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP; 15 Feb 2014 01:44:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1F1itZT006660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 01:44:55 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.202]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 19:44:55 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Proposed agenda Thread-Index: AQHPKe+GQ54cQ4Ch+0GNXdWWzntzpw== Date: Sat, 15 Feb 2014 01:44:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_375DAD77-1839-4B5E-8A5A-8AF2269308C8"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xtsPXRaCzMtqADZN-O_n2vMnlwA Subject: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 01:45:00 -0000 --Apple-Mail=_375DAD77-1839-4B5E-8A5A-8AF2269308C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As usual, John and I spoke Wednesday and have been watching drafts = posted today. The guideline we use, as usual, is that we want to look at = drafts that are in the "I-D exists" state, have been updated since the = previous IETF, and in which the working group has shown interest. As of = 23:59 UTC, the drafts targeting our working group, and our analysis of = them, include: RFC Ed Queue: Feb 14 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat IESG: Oct 6 draft-ietf-v6ops-64share Jan 13 draft-ietf-v6ops-nat64-experience Exiting WGLC; on its way to IESG: Jan 12 draft-ietf-v6ops-enterprise-incremental-ipv6 Working Group Document updated since IETF 88: Nov 26 draft-ietf-v6ops-dhcpv6-slaac-problem Dec 6 draft-ietf-v6ops-balanced-ipv6-security Jan 13 draft-ietf-v6ops-ipv6-roaming-analysis Feb 4 draft-ietf-v6ops-dc-ipv6 Feb 14 draft-ietf-v6ops-ula-usage-recommendations Individual Submission updated since IETF 88: Dec 3 draft-taylor-v6ops-fragdrop Dec 28 draft-byrne-v6ops-clatip Feb 14 draft-liu-v6ops-dhcpv6-slaac-guidance Individual Submission updated since IETF 88 but little/negtive interest = shown: Jan 11 draft-osamu-v6ops-ipv4-literal-in-url Feb 14 draft-cui-v6ops-lte-lw4over6 Feb 14 draft-foo-v6ops-6rdmtu Working Group Document NOT updated since IETF 88: Aug 14 draft-ietf-v6ops-monitor-ds-ipv6 Sep 10 draft-ietf-v6ops-mobile-device-profile Individual Submission NOT updated since IETF 88: Oct 3 draft-elkins-v6ops-ipv6-end-to-end-rt-needed Oct 3 draft-elkins-v6ops-ipv6-packet-sequence-needed Oct 3 draft-elkins-v6ops-ipv6-pdm-recommended-usage Oct 18 draft-ma-v6ops-router-test Oct 21 draft-moreiras-v6ops-rfc3849bis Oct 21 draft-rafiee-v6ops-iid-lifetime Oct 21 draft-sun-v6ops-openv6-address-pool-management Oct 21 draft-yang-v6ops-ipv6tran-select By that logic, the drafts on our agenda will include draft-ietf-v6ops-dhcpv6-slaac-problem draft-liu-v6ops-dhcpv6-slaac-guidance draft-ietf-v6ops-balanced-ipv6-security draft-ietf-v6ops-ipv6-roaming-analysis draft-ietf-v6ops-dc-ipv6 draft-ietf-v6ops-ula-usage-recommendations draft-taylor-v6ops-fragdrop draft-byrne-v6ops-clatip This is of course open to change; that's why it's called a "proposed = agenda". Please post to the list. Our meetings are Wednesday morning and Thursday afternoon. With 8 = drafts, I imagine we'll schedule 4 each day, or five and three.=20 Implications for people speaking: plan on about half hour sessions, with = ten or at most fifteen minutes in presentation and the difference in = discussion. People usually use slides, although that's far from a = requirement. Please email slides in ppt, pptx, or pdf format to = v6ops-chairs@tools.ietf.org no later than Saturday March 1, and tell us = who will be the speaker. Implications for the rest of us:=20 please read the drafts, and if you care to, comment to the list. http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-roaming-analysis http://tools.ietf.org/html/draft-ietf-v6ops-dc-ipv6 http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop http://tools.ietf.org/html/draft-byrne-v6ops-clatip The chairs have requested MeetEcho --Apple-Mail=_375DAD77-1839-4B5E-8A5A-8AF2269308C8 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 iD8DBQFS/saUbjEdbHIsm0MRAiq+AJ4opoBIXgM4UVlUT/slH4hJ3lxkdQCcC0WG LwrS2g0EO+mBIZpCVDkaW2Q= =SjiK -----END PGP SIGNATURE----- --Apple-Mail=_375DAD77-1839-4B5E-8A5A-8AF2269308C8-- From nobody Fri Feb 14 17:47:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C31A00A7; Fri, 14 Feb 2014 17:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 WqAZtsOpDN-u; Fri, 14 Feb 2014 17:47:40 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3881A1A0018; Fri, 14 Feb 2014 17:47:40 -0800 (PST) Received: from [192.168.1.7] (pool-72-73-23-184.clppva.fios.verizon.net [72.73.23.184]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s1F1lavc004489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 20:47:37 -0500 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <916A3488-34C9-4A12-BE98-0465978CB41B@earthlink.net> From: Jon Mitchell In-Reply-To: <916A3488-34C9-4A12-BE98-0465978CB41B@earthlink.net> Message-Id: <1954AEE5-C355-42DD-B102-F25488AFBD7F@puck.nether.net> Date: Fri, 14 Feb 2014 20:47:22 -0500 To: Mitchell Erblich Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11B554a) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Fri, 14 Feb 2014 20:47:37 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Qf1udhCQVOB7_kgNNf3OtTs38fs Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 01:47:41 -0000 > On Feb 14, 2014, at 7:49 PM, Mitchell Erblich wro= te: >=20 > Randy >=20 > A router-id is a router-id. >=20 > Do you think that every protocol that is enabled on the router should ha= ve a different router-id? >=20 > So, if you have enabled RIP, OSPFv2, OSPFv3, ISIS, BGP, etc, then for co= nsistency basis, I think the router SHOULD have 1 router-id.. Well, this seems an interesting argument. This capability is proposed as a p= roblem for IPv6 only networks needing a 128 bit identifier.=20 Randy argues for local assignment of 32 bit identifier as sufficient for BGP= and you say not good enough for consistency sake you want all protocols to c= hoose the same loopback based number naming 3 protocols that have 32 bit ide= ntifiers, 1 protocol with no identifier, and 1 protocol with 48 bit sys-id. = Since RIP is mentioned, why not throw in EIGRP (32 bit) as well, since this= supports IPv6 unlike OSPFv2... So looking at the list I think we can all say for consistency and simplicity= across protocols operator should prefer 32 bit values based on local loopba= ck if IPv4 enabled, or 32 bit self administered numbers if IPv6 only so they= can keep one identifier recognizable across all protocols for their routers= w/o extending every protocol in the list to support 128 bit identifiers... -Jon From nobody Fri Feb 14 19:05:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A65D1A0035 for ; Fri, 14 Feb 2014 19:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 Fpo86xGgd6Ge for ; Fri, 14 Feb 2014 19:05:36 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id CB15A1A001E for ; Fri, 14 Feb 2014 19:05:35 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id hl1so1932628igb.1 for ; Fri, 14 Feb 2014 19:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G5vPjYyQ7BYMWY9nCiMRossGdo9qUsPa1QlLGRzf0ms=; b=UL7jJITNhk0X8woG6ZA0HXa+Pm4DiQUuEacXaE0iQHhVXfa9vfGHfdbpMU5HlbtbG2 11azH8KWkaHNYafeZK3Qbtl1qdc7AtE8wEyFFhHm5zk6FAzdpjPYFG9/OboXOyA6eyeQ hL41/XzIPXmXyz3mNKUFTcnM8QZOlwza0N/+ETrIQ5K6d4nb1SohCgPmjenUyn7xJtPi 9Cx9wBFe9Sb2VVxap3G31qzmhmgjqmx2/98A7tUhs6JBOyViuLUCyl7vOtr+bYOs3m1k t1Mq31Ke4Sh0RFK6hineeNWqb8dqqPH0pGYjwi5KH8MVA4N3CWHZfUHqT0U2t6Kx/CNS dHcQ== 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=G5vPjYyQ7BYMWY9nCiMRossGdo9qUsPa1QlLGRzf0ms=; b=H/2g1sbXMMvwUs8v11MXF/BrzsfcAdystJWdb63P7wMyT0zgTFTYzpW6QIrXXqtSKx O45g76Ubte9D7hMJrFe10M1INSvH55etyA84JUxHfQU93XfkQOHoPZfXOYUTR4iodPdk sc6AfbTwoe8YQgACWZsvdi5Is0HWHh0u0Y2v0NxQ4G1NCZX/ACMCDiXY+TvEdnL0NNsw Kl9C+tbyNmlpFmh7oTyJ98Vhc8fgetSBJiAAcgqhkNOwA7I7bkEauqSo7VrcVbI/Nvm9 uA9n8DNaX2eorWIgQIf9NQPGduObAvlfCOtnwVlAkCtSsnRRrESjWw/4764LnS5Gd50Z j9iQ== X-Gm-Message-State: ALoCoQkYicUm09IJ6mBOfsprBOn/vpA+Px7HE2H/TNE0DGIrY5AF5a0mMIT7/IxMnSa89+Oh2sPCWJryNxZ2hv2q7VFKW1lgsXKGQRGu8DBRMerDdGaIGhmz1CwRrwIMg4Y9qzptw/1npi9TskSs9QEyyAsYV3jUTAZw5N89KFXuIXbqIZx4Sq0RUDvW3LYL7xXFEGh+/DP1 X-Received: by 10.50.164.233 with SMTP id yt9mr6075612igb.31.1392433533846; Fri, 14 Feb 2014 19:05:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Fri, 14 Feb 2014 19:05:13 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Sat, 15 Feb 2014 12:05:13 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=089e0149beac28f93004f26932a7 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/prq-QagRm38lvkKl9u-Zf-9O19M Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 03:05:38 -0000 --089e0149beac28f93004f26932a7 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) wrote: > This is of course open to change; that's why it's called a "proposed > agenda". Please post to the list. > Would there be time to briefly discuss: http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00? This will be presented in 6man during a session on the efficiency of the ND protocol, but I feel that it really belongs in v6ops, because it has no protocol changes. Of course, since it was posted only shortly before 23:59 UTC, it fails the "has been discussed on the list" test. :-) --089e0149beac28f93004f26932a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) <fred@cisco.com> wrote:
This is of course open to change; that's why it's = called a "proposed agenda". Please post to the list.

Would there be time to briefly discuss:


This will be presented in 6man during a session on the = efficiency of the ND protocol, but I feel that it really belongs in v6ops, = because it has no protocol changes.

Of course, sin= ce it was posted only shortly before 23:59 UTC, it fails the "has been= discussed on the list" test. :-)
--089e0149beac28f93004f26932a7-- From nobody Fri Feb 14 21:58:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213501A0041 for ; Fri, 14 Feb 2014 21:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fXu337V9B-c for ; Fri, 14 Feb 2014 21:57:55 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 657421A003B for ; Fri, 14 Feb 2014 21:57:55 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id B7ECA300083 for ; Sat, 15 Feb 2014 05:57:53 +0000 (UTC) Received: from [172.16.15.4] (97-122-112-90.hlrn.qwest.net [97.122.112.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id D281E300081; Fri, 14 Feb 2014 22:57:52 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: Date: Fri, 14 Feb 2014 19:58:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Feb 14 22:57:53 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52ff01e142071632719215 X-DSPAM-Factors: 27, within+#+#+of, 0.40000, is+#+#+#+32, 0.40000, complexity+#+#+educating, 0.40000, 32+#+number, 0.40000, please+#+#+#+can, 0.40000, Steffann+#+steffann, 0.40000, many+#+#+#+that, 0.40000, if+#+#+are, 0.40000, and+#+lose, 0.40000, casting+an, 0.40000, Hi+IPv6, 0.40000, you+#+shane, 0.40000, using+#+#+#+to, 0.40000, two+points, 0.40000, complexity+#+#+#+router, 0.40000, an+#+#+#+allows, 0.40000, availability+#+location, 0.40000, octet+#+#+each, 0.40000, unique+#+#+integer, 0.40000, many+people, 0.40000, the+#+I, 0.40000, future+#+#+ever, 0.40000, think+that, 0.40000, purporting+#+have, 0.40000, to+#+the, 0.40000, compound+#+problems, 0.40000, creating+#+#+#+avoid, 0.40000 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ORi91Gi6iej7mm5FNTtaindphw8 Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 05:57:57 -0000 Hi, I'm not casting an opinion either way wrt this specific draft; however, = I do wish to make two points below. On Feb 14, 2014, at 12:13 PM, Sander Steffann = wrote: > Hi, >=20 >>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>> 2014-02-12 >>=20 >> please no. if you can not assign a unique four octet integer to each >> router in your network, then you have much bigger problems. and = adding >> a capability and more complexity to try to patch over your inability = to >> configure your routers will just compound your problems. >=20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer... I would take exception to a ROUTER_ID being just a 32-bit integer. = Specifically, when a ROUTER_ID is an IP address that allows an operator = to quickly perform diagnosis & troubleshooting using = ping/traceroute/etc. to identify the availability and location within = the topology of the router purporting to have said ROUTER_ID. The other question I would raise is, in a far-off future, if we ever = manage to get networks converted away from dual-stack and back to a = single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you = lose those capabilities mentioned above ... would you care? -shane From nobody Sat Feb 15 00:58:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C009C1A0141; Sat, 15 Feb 2014 00:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw9--dg_uX_x; Sat, 15 Feb 2014 00:58:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4861A013C; Sat, 15 Feb 2014 00:58:17 -0800 (PST) Received: from [160.249.232.91] (helo=u1032091.xgsnun101.imtp.tachikawa.mopera.net) by psg.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WEb2m-0005dK-U6; Sat, 15 Feb 2014 08:58:09 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----OYZSPWB6ND83VK03DRYZFHV6VYZF6T" Content-Transfer-Encoding: 8bit From: Randy Bush Date: Sat, 15 Feb 2014 17:55:49 +0900 To: Shane Amante ,Sander Steffann Message-ID: <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fQq00xVD90WfHkjY6q0jnnJQa3I Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 08:58:21 -0000 ------OYZSPWB6ND83VK03DRYZFHV6VYZF6T Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I use this funny thing called DNS. -- Phones are not computers and suck for email On February 15, 2014 12:58:53 PM GMT+09:00, Shane Amante wrote: >Hi, > >I'm not casting an opinion either way wrt this specific draft; however, >I do wish to make two points below. > >On Feb 14, 2014, at 12:13 PM, Sander Steffann >wrote: >> Hi, >> >>>> http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id >>>> "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, >>>> 2014-02-12 >>> >>> please no. if you can not assign a unique four octet integer to >each >>> router in your network, then you have much bigger problems. and >adding >>> a capability and more complexity to try to patch over your inability >to >>> configure your routers will just compound your problems. >> >> I agree. It's a shame that the router-id looks like an IPv4 address >and IPv4 addresses are used to auto-configure it when the operator >doesn't explicitly set it. There are too many people that think that a >router-id is more than a 32-bit number and must be an IPv4 address, but >creating more complexity to avoid educating router operators isn't the >answer... > >I would take exception to a ROUTER_ID being just a 32-bit integer. >Specifically, when a ROUTER_ID is an IP address that allows an operator >to quickly perform diagnosis & troubleshooting using >ping/traceroute/etc. to identify the availability and location within >the topology of the router purporting to have said ROUTER_ID. > >The other question I would raise is, in a far-off future, if we ever >manage to get networks converted away from dual-stack and back to a >single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you >lose those capabilities mentioned above ... would you care? > >-shane ------OYZSPWB6ND83VK03DRYZFHV6VYZF6T Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I use this funny thing called DNS.
--
Phones are not computers and suck for email

On February 15, 2014 12:58:53 PM GMT+09:00, Shane Amante <shane@castlepoint.net> wrote:
Hi,

I'm not casting an opinion either way wrt this specific draft; however, I do wish to make two points below.

On Feb 14, 2014, at 12:13 PM, Sander Steffann <sander@steffann.nl> wrote:
 Hi,
 
 http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id
 "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li,
 2014-02-12
 
 please no.  if you can not assign a unique four octet integer to each
 router in your network, then you have much bigger problems.  and
adding
 a capability and more complexity to try to patch over your inability to
 configure your routers will just compound your problems.
 
 I agree. It's a shame that the router-id looks like an IPv4 address and IPv4 addresses are used to auto-configure it when the operator doesn't explicitly set it. There are too many people that think that a router-id is more than a 32-bit number and must be an IPv4 address, but creating more complexity to avoid educating router operators isn't the answer...

I would take exception to a ROUTER_ID being just a 32-bit integer.  Specifically, when a ROUTER_ID is an IP address that allows an operator to quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology of the router purporting to have said ROUTER_ID.

The other question I would raise is, in a far-off future, if we ever manage to get networks
converted away from dual-stack and back to a single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities mentioned above ... would you care?

-shane

------OYZSPWB6ND83VK03DRYZFHV6VYZF6T-- From nobody Sat Feb 15 03:15:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6F91A01AC; Sat, 15 Feb 2014 03:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Uop_LtO1jfNz; Sat, 15 Feb 2014 03:15:28 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) by ietfa.amsl.com (Postfix) with ESMTP id A720B1A013B; Sat, 15 Feb 2014 03:15:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id C03A737; Sat, 15 Feb 2014 12:15:25 +0100 (CET) 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 10024) with ESMTP id Qi4zyrteE+oJ; Sat, 15 Feb 2014 12:15:22 +0100 (CET) Received: from [IPv6:2a00:8640:1::c9aa:fdd:8b14:c42a] (unknown [IPv6:2a00:8640:1:0:c9aa:fdd:8b14:c42a]) by mail.sintact.nl (Postfix) with ESMTPSA id 6910034; Sat, 15 Feb 2014 12:15:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> Date: Sat, 15 Feb 2014 12:15:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <786C4EB0-B9FD-4A49-8F9E-B5A88CE91F76@steffann.nl> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Qx8GS7aPTOTu7DUtlsduWDkSiIc Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 11:15:31 -0000 Op 15 feb. 2014, om 04:58 heeft Shane Amante het = volgende geschreven: > I would take exception to a ROUTER_ID being just a 32-bit integer. = Specifically, when a ROUTER_ID is an IP address that allows an operator = to quickly perform diagnosis & troubleshooting using = ping/traceroute/etc. to identify the availability and location within = the topology of the router purporting to have said ROUTER_ID. If you try to ping a router-id then all bets are off. I have seen too = many cases with misconfigured router-ids to attach any value (except the = numerical one) to them. I also never try to ping OSPF area numbers ;) > The other question I would raise is, in a far-off future, if we ever = manage to get networks converted away from dual-stack and back to a = single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you = lose those capabilities mentioned above ... would you care? Not at all. And it I wanted to link IPv6 loopback addresses and = router-ids I probably would choose a router-id (say aaa.bbb.ccc.ddd) and = then use either 2001:db8::aaa.bbb.ccc.ddd/128 or = 2001:db8::aaa:bbb:ccc:ddd/128 as loopback address. Cheers, Sander From nobody Sat Feb 15 04:00:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF91A01BE for ; Sat, 15 Feb 2014 04:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C9FjiyWuM1y3 for ; Sat, 15 Feb 2014 04:00:25 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 99D721A01AD for ; Sat, 15 Feb 2014 04:00:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 01EA737; Sat, 15 Feb 2014 13:00:23 +0100 (CET) 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 10024) with ESMTP id 4CkiosVM1oix; Sat, 15 Feb 2014 13:00:21 +0100 (CET) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTPSA id F286334; Sat, 15 Feb 2014 13:00:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <52FEBE28.1010006@gmail.com> Date: Sat, 15 Feb 2014 13:00:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <994FFF76-CA4B-415E-896E-05D34F1D44BF@steffann.nl> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Or1Rp8NQh7mR7RRB2NlNP7En0oc Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 12:00:26 -0000 Hi, > Well, there have always been some people against the existence of = ULAs, > but we did reach rough consensus to define them, since other people > see value in them, for reasons that have been aired many times. > So writing words about the best way to use them if you want to use > them seems right to me. I think the document is a bit long, but as it describes all the = pros/cons in different usage scenarios I think it is necessary to give a = balanced view. I think this draft is going to be very useful for = operators (many who are new to IPv6 and addicted to RFC1918 addresses so = their first idea is ULA+NAT for the entire office) that are planning = their IPv6 deployment and need to understand if/how to use ULA. And more = importantly: how not to use it. That last bit might need some more = emphasis. I think section 3.2.1 is a bit too positive (even though it = mentions 'specific situations') Cheers, Sander From nobody Sat Feb 15 05:45:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0761A0219 for ; Sat, 15 Feb 2014 05:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu94T64bfVtY for ; Sat, 15 Feb 2014 05:45:12 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2E1A0212 for ; Sat, 15 Feb 2014 05:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392471911; x=1393681511; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=BCdnjqTXTAFHh4bNhxLhBuahqDunZoMIqLRDHXc8gZcxqnvvCE2fTSQ3 oHFvm3Jvd7S+doqZNeFeKWxLUWKC/oKCRJDMjBw77N/ekF9YAF7RyDIe7 CP1qwh+65cnNBITvO4D3cG5BA7pprQbRk5DI/Jv8uJfwDVVdBxS86cgnA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMKAG9u/1KrRDoH/2dsb2JhbABZgwY4qzYBlFMDBAKBDhZ0gyU8LQeIZQ7JDxePAR2EIgSJSJAWkHGDTg X-IronPort-AV: E=Sophos;i="4.95,850,1384300800"; d="scan'208";a="102557560" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 15 Feb 2014 13:45:11 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1FDj1pI011914; Sat, 15 Feb 2014 13:45:07 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1FDj1c19082; Sat, 15 Feb 2014 05:45:01 -0800 (PST) Date: Sat, 15 Feb 2014 05:45:01 -0800 (PST) From: Message-Id: <201402151345.s1FDj1c19082@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aBxFu66mtvUCV25Hd4ecCZy5lRM Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 13:45:15 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Sat Feb 15 05:45:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB82D1A0226 for ; Sat, 15 Feb 2014 05:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLXOqc0MRuNd for ; Sat, 15 Feb 2014 05:45:28 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBD01A0212 for ; Sat, 15 Feb 2014 05:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392471926; x=1393681526; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=GsOxFCp7Qx2/7agTRNvdlc2So2yCcPHDh0SVSx5GnGl/v5MPaDd578Cj mkyPHvYl8JeR9jZHfE97Iq51nlGzbcmYh0VJ0He+QhgS9gOkdMDsCcx8L /pAGLOOf+nKUml4nWbtasF+C6mtHJmg/7BaiUHx2BZRJDfUQKVWkrGEYz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMKAG9u/1KrRDoG/2dsb2JhbABZgwY4qzYBlFMDBAKBDhZ0gyU8NIhlDskPF48BHYQiBIlIkBaQcYNO X-IronPort-AV: E=Sophos;i="4.95,850,1384300800"; d="scan'208";a="102557596" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 15 Feb 2014 13:45:26 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1FDjOIi021580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Feb 2014 13:45:25 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s1FDjOVx008061; Sat, 15 Feb 2014 05:45:24 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s1FDjN9Q007939; Sat, 15 Feb 2014 05:45:23 -0800 (PST) Date: Sat, 15 Feb 2014 05:45:23 -0800 (PST) From: Fred Baker Message-Id: <201402151345.s1FDjN9Q007939@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rlK5d0AE7Wl_tsSvJzt_qnUzACY Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 13:45:29 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Sat Feb 15 07:13:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3B71A0256 for ; Sat, 15 Feb 2014 07:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgtuT72aK-5v for ; Sat, 15 Feb 2014 07:13:13 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id B6A831A0258 for ; Sat, 15 Feb 2014 07:13:13 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 0564730008A for ; Sat, 15 Feb 2014 15:13:11 +0000 (UTC) Received: from [172.16.15.4] (97-122-112-90.hlrn.qwest.net [97.122.112.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id A752330007B; Sat, 15 Feb 2014 08:13:10 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> Date: Sat, 15 Feb 2014 07:13:10 -0800 Message-Id: <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Feb 15 08:13:11 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52ff840742071548517406 X-DSPAM-Factors: 27, within+#+#+of, 0.40000, within+#+#+of, 0.40000, is+#+#+#+32, 0.40000, is+#+#+#+32, 0.40000, complexity+#+#+educating, 0.40000, complexity+#+#+educating, 0.40000, 32+#+number, 0.40000, 32+#+number, 0.40000, please+#+#+#+can, 0.40000, please+#+#+#+can, 0.40000, Steffann+#+steffann, 0.40000, Steffann+#+steffann, 0.40000, many+#+#+#+that, 0.40000, many+#+#+#+that, 0.40000, if+#+#+are, 0.40000, if+#+#+are, 0.40000, and+#+lose, 0.40000, and+#+lose, 0.40000, casting+an, 0.40000, casting+an, 0.40000, Hi+IPv6, 0.40000, Hi+IPv6, 0.40000, you+#+shane, 0.40000, you+#+shane, 0.40000, using+#+#+#+to, 0.40000, using+#+#+#+to, 0.40000, two+points, 0.40000 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Hauc9PhM0fPPCcN-I_zMcsltZIE Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 15:13:16 -0000 --Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: > I use this funny thing called DNS.=20 And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? -shane > --=20 > Phones are not computers and suck for email >=20 > On February 15, 2014 12:58:53 PM GMT+09:00, Shane Amante = wrote: > Hi, >=20 > I'm not casting an opinion either way wrt this specific draft; = however, I do wish to make two points below. >=20 > On Feb 14, 2014, at 12:13 PM, Sander Steffann = wrote: > Hi, > =20 > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > 2014-02-12 > =20 > please no. if you can not assign a unique four octet integer to each > router in your network, then you have much bigger problems. and > adding > a capability and more complexity to try to patch over your inability = to > configure your routers will just compound your problems. > =20 > I agree. It's a shame that the router-id looks like an IPv4 address = and IPv4 addresses are used to auto-configure it when the operator = doesn't explicitly set it. There are too many people that think that a = router-id is more than a 32-bit number and must be an IPv4 address, but = creating more complexity to avoid educating router operators isn't the = answer... >=20 > I would take exception to a ROUTER_ID being just a 32-bit integer. = Specifically, when a ROUTER_ID is an IP address that allows an operator = to quickly perform diagnosis & troubleshooting using = ping/traceroute/etc. to identify the availability and location within = the topology of the router purporting to have said ROUTER_ID. >=20 > The other question I would raise is, in a far-off future, if we ever = manage to get networks > converted away from dual-stack and back to a single AFI -- namely, = IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities = mentioned above ... would you care? >=20 > -shane >=20 --Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 15, 2014, at 12:55 AM, Randy = Bush <randy@psg.com> = wrote:
I use this funny thing called DNS. =

And that has what to do with the problem = of determining liveness or determining where in the topology is a = ROUTER_ID?

-shane


--
Phones are not computers and suck for email

On February 15, 2014 12:58:53 PM GMT+09:00, Shane = Amante <shane@castlepoint.net> = wrote:
Hi,

I'm not casting an opinion either way =
wrt this specific draft; however, I do wish to make two points =
below.

On Feb 14, 2014, at 12:13 PM, Sander Steffann <sander@steffann.nl> =
wrote:
 Hi,
 =

 http://tools=
.ietf.org/html/draft-fan-idr-ipv6-bgp-id
 "IPv6 BGP Identifier =
Capability for BGP-4", Peng Fan, Zhenqiang Li,
 =
2014-02-12
 
 please no.  if you can not assign a =
unique four octet integer to each
 router in your network, then you =
have much bigger problems.  and
adding
 a capability and more complexity to try to patch over your =
inability to
 configure your routers will just compound your =
problems.
 
 I agree. It's a shame that the router-id =
looks like an IPv4 address and IPv4 addresses are used to auto-configure =
it when the operator doesn't explicitly set it. There are too many =
people that think that a router-id is more than a 32-bit number and must =
be an IPv4 address, but creating more complexity to avoid educating =
router operators isn't the answer...

I would take =
exception to a ROUTER_ID being just a 32-bit integer.  Specifically, =
when a ROUTER_ID is an IP address that allows an operator to quickly =
perform diagnosis & troubleshooting using ping/traceroute/etc. to =
identify the availability and location within the topology of the router =
purporting to have said ROUTER_ID.

The other question I would =
raise is, in a far-off future, if we ever manage to get networks
converted away from dual-stack and back to a single AFI -- namely, IPv6 =
-- if ROUTER_ID's are only 32-bits and you lose those capabilities =
mentioned above ... would you =
care?

-shane

= --Apple-Mail=_2AC95F52-11F7-4B7E-9D1C-24D553E131F1-- From nobody Sat Feb 15 07:26:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CA31A0073; Sat, 15 Feb 2014 07:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.195 X-Spam-Level: X-Spam-Status: No, score=0.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, NORMAL_HTTP_TO_IP=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 mEK8B2I-Dgtw; Sat, 15 Feb 2014 07:26:18 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 849801A002C; Sat, 15 Feb 2014 07:26:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id BEB1B37; Sat, 15 Feb 2014 16:26:14 +0100 (CET) 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 10024) with ESMTP id uBxUYtsQyfhX; Sat, 15 Feb 2014 16:26:12 +0100 (CET) Received: from [IPv6:2a00:8640:1::b0e8:569d:2551:8a57] (unknown [IPv6:2a00:8640:1:0:b0e8:569d:2551:8a57]) by mail.sintact.nl (Postfix) with ESMTPSA id D975934; Sat, 15 Feb 2014 16:26:11 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> Date: Sat, 15 Feb 2014 16:26:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vngDOlwhiRk-kw54OIpiC8fjkQY Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 15:26:20 -0000 Op 15 feb. 2014, om 16:13 heeft Shane Amante het = volgende geschreven: > On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >> I use this funny thing called DNS.=20 >=20 > And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? And what does an integer called ROUTER_ID tell you about that? And hey, you can always create records like 1.2.3.4.router-id.castlepoint.net IN CNAME = router1.somewhere.castlepoint.net :-) Cheers, Sander From nobody Sat Feb 15 07:53:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B40A1A0040 for ; Sat, 15 Feb 2014 07:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=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 738oLU5-8Cxp for ; Sat, 15 Feb 2014 07:53:44 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0620E1A00EC for ; Sat, 15 Feb 2014 07:53:44 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 4F557300082 for ; Sat, 15 Feb 2014 15:53:42 +0000 (UTC) Received: from [172.16.15.4] (97-122-112-90.hlrn.qwest.net [97.122.112.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 67F8B30007A; Sat, 15 Feb 2014 08:53:41 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> Date: Sat, 15 Feb 2014 07:53:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> To: Sander Steffann X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Feb 15 08:53:42 2014 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 52ff8d8642078399820781 X-DSPAM-Factors: 27, records+#+#+#+3, 0.40000, in+networks, 0.40000, Steffann+#+steffann, 0.40000, unfamiliar+with, 0.40000, has+#+#+often, 0.40000, can+always, 0.40000, DNS+And, 0.40000, past+#+#+#+found, 0.40000, helpful+in, 0.40000, to+#+the, 0.40000, do+#+the, 0.40000, time+#+#+using, 0.40000, hey+#+#+always, 0.40000, isis+#+#+finding, 0.40000, it+#+#+#+in, 0.40000, wrote+#+use, 0.40000, is+#+#+#+i, 0.40000, do+#+#+problem, 0.40000, wrote+Op, 0.40000, more+#+than, 0.40000, networks+#+I've, 0.40000, that+#+#+#+out, 0.40000, tell+#+#+that, 0.40000, diagnosing+#+#+brokenness, 0.40000, where+#+#+#+is, 0.40000, where+#+#+#+is, 0.40000, in+#+#+#+duplicate, 0.40000 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DWcNoJvhMwzAKBw9uNHyG6rKYbY Cc: idr wg , V6 Ops List Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 15:53:45 -0000 On Feb 15, 2014, at 7:26 AM, Sander Steffann wrote: > Op 15 feb. 2014, om 16:13 heeft Shane Amante = het volgende geschreven: >> On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >>> I use this funny thing called DNS.=20 >>=20 >> And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? >=20 > And what does an integer called ROUTER_ID tell you about that? In my past experience, I have found that -- particularly in new networks = that I'm unfamiliar with -- looking at the output of "show (ospf|isis) = database extensive", finding a ROUTER_ID that originated the LSA/LSPDU = and performing a ping and/or traceroute to it to verify the sanity of = where in the topology that ROUTER_ID is located has been helpful in = rapidly diagnosing and fixing brokenness. Yes, I will admit that it is = not a panacea (i.e.: it does not help in the case of duplicate = ROUTER_ID's), but 99% of the time it's often using that information to = figure out where traffic is, or is not, going to. Look, it's your network, do whatever pleases you. But, in networks that = I've run, having congruency between the ROUTER_ID and a Loopback address = has helped more often than not. > And hey, you can always create records like > 1.2.3.4.router-id.castlepoint.net IN CNAME = router1.somewhere.castlepoint.net And, when your DNS server is unreachable because you've got a network = issue, what then? -shane= From nobody Sat Feb 15 10:27:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF10C1A0268 for ; Sat, 15 Feb 2014 10:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 e_byUDG1eaLX for ; Sat, 15 Feb 2014 10:27:48 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9E1A0259 for ; Sat, 15 Feb 2014 10:27:47 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1FIPgX9004774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Feb 2014 10:25:42 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1FIPgX9004774 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392488744; bh=AZWJy4zS3YtbdV7x8GQTu/MDMvo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=szSQUWY8JPTOD7Bh2/XAqhqCZuu2JJbAO4JBqWNJ1LBGmYz4oHwImHlSpoLeW0R/Z kyllZEhI1FQWRZZ1+2bKZGOENktfw76yRpVlfRaoJXebzU7RshKUNRBT6ZRbNpIZ7A JP1q6CrhAICEVrcICxC/oNXWIOsYu/V9q8LpkhMI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <52FEBE28.1010006@gmail.com> Date: Sat, 15 Feb 2014 10:16:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 15 Feb 2014 10:25:44 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yZQJZa93nWOi2HP1oBq9QPUIqSI Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 18:27:50 -0000 Indeed, the situations where ULA usage is detrimental vastly outnumbers = those where it is actually beneficial. If we're going to move something like this forward, that really should = be made clear. Owen On Feb 14, 2014, at 17:08 , Brian E Carpenter = wrote: > Well, there have always been some people against the existence of = ULAs, > but we did reach rough consensus to define them, since other people > see value in them, for reasons that have been aired many times. > So writing words about the best way to use them if you want to use > them seems right to me. >=20 > Brian >=20 > On 14/02/2014 23:00, ek wrote: >> +1 >>=20 >> ---- On Fri, 14 Feb 2014 18:34:36 +0900 Randy = Bush<randy@psg.com> wrote ----=20 >>=20 >>=20 >> i expected this to be a short draft. "Don't"=20 >>=20 >> randy=20 >>=20 >> _______________________________________________=20 >> v6ops mailing list=20 >> v6ops@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/v6ops=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Feb 15 10:49:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571A71A0275; Sat, 15 Feb 2014 10:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=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 vIIJTXfED3H5; Sat, 15 Feb 2014 10:49:35 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3171A0273; Sat, 15 Feb 2014 10:49:35 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::126]) (authenticated bits=0) by mail.netability.ie (8.14.7/8.14.5) with ESMTP id s1FInRkw057412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 15 Feb 2014 18:49:27 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::126] claimed to be cupcake.foobar.org Message-ID: <52FFB6B7.4090408@foobar.org> Date: Sat, 15 Feb 2014 18:49:27 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sander Steffann , Shane Amante References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> In-Reply-To: <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sl8xhSjvCFQVSGSnZWuQUL5LogM Cc: idr wg , V6 Ops List , draft-fan-idr-ipv6-bgp-id@tools.ietf.org Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 18:49:38 -0000 On 15/02/2014 15:26, Sander Steffann wrote: > Op 15 feb. 2014, om 16:13 heeft Shane Amante het volgende geschreven: >> On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >>> I use this funny thing called DNS. >> >> And that has what to do with the problem of determining liveness or determining where in the topology is a ROUTER_ID? > > And what does an integer called ROUTER_ID tell you about that? > > And hey, you can always create records like > 1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoint.net guys, we're all having a bit of an ietf moment here: within the space of 48 hours, the conversation has ratholed. Let's love up a bit. The authors of the draft have a simple operational desire to make their lives a little easier and as an operator I sympathise with this, particularly because they are using ipv6-only networks in anger which is more than I do. There are two advantages of having a 128 bit router-id (with the unstated convention of tying router-id == address of first loopback): - firstly it's easy to identify the location of prefix announcements on your network - secondly the router-id can be autoconfigured. On the other hand, implementing this will require that the authors define a transition mechanism to allow 128 bit router-id routers interoperate with 32 bit router-id routers in such a way that router-id collisions don't occur. If the authors want to progress this, they need to state a stronger use case and they need to create a transition mechanism. If they can do this in a reasonable way which doesn't break backwards compatibility, then it might be appropriate for idr / v6ops / etc to take another look at the draft. Also, I wish them well because everyone understands what a router ID is and everyone will want to paint theirs a different colour. Nick From nobody Sat Feb 15 11:26:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90131A0277 for ; Sat, 15 Feb 2014 11:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3yJHWgoZWlH for ; Sat, 15 Feb 2014 11:26:09 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id A33481A0214 for ; Sat, 15 Feb 2014 11:26:09 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Sat, 15 Feb 2014 13:26:04 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f177.google.com [209.85.213.177] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f177.google.com with SMTP id k19so2822473igc.4 for ; Sat, 15 Feb 2014 11:26:03 -0800 (PST) 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=plgJqSQ4/tOPyQ6PTC0ZHFKzNtrUs3Z5f92DWrNQYJM=; b=G64x6ac8S9bOeBaTPVTuwadaid/jGou7b/HaV2ghO5GNg2FZ2YJ/lYaLkKhNt3+DZq rFuC5TDsvGPI4ED850KD5WnWUf81/6AZAXOIgVo/JVTTSJH2f9AFwXxgZN5423MaBjS6 D88IxMG0dFcnnKndt8++MiUSnCZkUbY7fqtkwX4Y5mtO5kT9tbTUsulH/XSI0DXlUbpm v3EoPfJNNHPKmBtYBJMCdA7y7B3fFMk/37MpXcfx4xvMNm84aQ+NbsABz99bzsdtZDY3 Hu9hItIIjzhsbqFbUBOBhO+WKxT8z+QMhgyUxgJuPOQgbVIPQJH39clj5V11jTIStTHl WxpA== X-Gm-Message-State: ALoCoQkmRyaKilliErRU/9C34auzlCnry36hdakLRyUnRE3ofP1N5HxzZkRY7SH2t9FSZyKVM7WMfQfcAlc9/qrCPHGZRHlD+fNeYfk0rwZDwtAuBQReMkwJuyFSvax6myxt80ib3JAc X-Received: by 10.42.169.134 with SMTP id b6mr11223676icz.22.1392492363281; Sat, 15 Feb 2014 11:26:03 -0800 (PST) X-Received: by 10.42.169.134 with SMTP id b6mr11223668icz.22.1392492363130; Sat, 15 Feb 2014 11:26:03 -0800 (PST) Received: from [192.168.88.248] (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPSA id gd5sm15643872igd.5.2014.02.15.11.25.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Feb 2014 11:25:59 -0800 (PST) References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> In-Reply-To: <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> X-Mailer: iPad Mail (11B554a) From: David Farmer Date: Sat, 15 Feb 2014 13:25:59 -0600 To: Shane Amante Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YOUWte0fXJywQEcV0xb1cZQNBh0 Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 19:26:12 -0000 > On Feb 14, 2014, at 21:58, Shane Amante wrote: >=20 > I would take exception to a ROUTER_ID being just a 32-bit integer. Specif= ically, when a ROUTER_ID is an IP address that allows an operator to quickly= perform diagnosis & troubleshooting using ping/traceroute/etc. to identify t= he availability and location within the topology of the router purporting to= have said ROUTER_ID. >=20 > The other question I would raise is, in a far-off future, if we ever manag= e to get networks converted away from dual-stack and back to a single AFI --= namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabili= ties mentioned above ... would you care? I agree it is a very common and useful operational practice to use the IPv4 l= oopback address for the ROUTER_ID. This practice is strongly reinforced in t= hat most implementations represent the ROUTER_ID in dotted quad decimal nota= tion, the same way we represent IPv4 addresses. However, common practice does not make it a protocol requirement. I would s= uggest there are several possible new operational practices that could be de= veloped that don't require complicate changes to the protocol. =20 A very simple one would be to use a common IPv6 prefix for all your /128 IPv= 6 loopback addresses and embed the ROUTER_ID as the least significant 32 bit= s. Just as implementations reinforce the current operational practice, they= could also reinforce this possible new practice by representing the 32bit R= OUTER_ID in hex instead of dotted quad decimal, or even better both represen= tations next to each other. Maybe implementations could allow you to specif= y a /96 IPv6 prefix to be appended with the ROUTER_ID when it is output, giv= ing you the IPv6 address you wanted without changing the protocol. As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. Then yo= u can use an IPv6 loopback address of 2001:db8:1::c000:205, or you could eve= n used mixed notation 2001:db8:1::192.0.2.5. So, you do not loose the ability to "quickly perform diagnosis & troubleshoo= ting using ping/traceroute/etc. to identify the availability and location wi= thin the topology." There was also a DNS recommendation made in the thread, that would work too.= So, I'd prefer effort be put toward an informational draft suggesting operat= ional practices and maybe implementation suggestions that reinforce these su= ggestions rather than complicated protocol changes. =20 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 Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Sat Feb 15 12:58:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26F81A0112; Sat, 15 Feb 2014 12:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uWDdaiAZKNSv; Sat, 15 Feb 2014 12:58:23 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) by ietfa.amsl.com (Postfix) with ESMTP id 16F311A02FA; Sat, 15 Feb 2014 12:58:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 79ADB37; Sat, 15 Feb 2014 21:58:20 +0100 (CET) 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 10024) with ESMTP id Bo31xammLCOz; Sat, 15 Feb 2014 21:58:18 +0100 (CET) Received: from [IPv6:2a00:8640:1::b0e8:569d:2551:8a57] (unknown [IPv6:2a00:8640:1:0:b0e8:569d:2551:8a57]) by mail.sintact.nl (Postfix) with ESMTPSA id 6B0C734; Sat, 15 Feb 2014 21:58:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sander Steffann In-Reply-To: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> Date: Sat, 15 Feb 2014 21:58:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7596C74C-5DE5-4B44-BDCD-32AD755DF37E@steffann.nl> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HLWOXu5pPjiK_Jqs4vSq9gj5zqQ Cc: V6 Ops List , idr wg Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 20:58:24 -0000 Hi David, > As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. = Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or = you could even used mixed notation 2001:db8:1::192.0.2.5. >=20 > So, you do not loose the ability to "quickly perform diagnosis & = troubleshooting using ping/traceroute/etc. to identify the availability = and location within the topology." Yeah, this sounds about right :) > There was also a DNS recommendation made in the thread, that would = work too. >=20 > So, I'd prefer effort be put toward an informational draft suggesting = operational practices and maybe implementation suggestions that = reinforce these suggestions rather than complicated protocol changes. =20= I fully agree. I'd be willing to help write such a draft. Cheers, Sander From nobody Sat Feb 15 13:43:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848E81A02F1; Sat, 15 Feb 2014 13:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 LkHFeUZfyyiE; Sat, 15 Feb 2014 13:43:02 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6691A02B6; Sat, 15 Feb 2014 13:43:01 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1FLeBem010469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Feb 2014 13:40:13 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1FLeBem010469 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392500415; bh=py+2a5F2SF2/mXtnmOvVVLK8uBY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HnCAPca9T8TdpORsaTKLKyj2a4qz0KZKzDnt0wD7rov8tLJlYSPwwnWqGOYqhLQvw 8qrhS/SBU2u1gKKU+guv49kFNTXZSVxSebz+tBMaYEO7i1rkWZ3Cf+gI50k+c2gbhn HDxLstDfHapIL2l8lJe5ecysHEmXtOv1jQrl8rgY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <52FFB6B7.4090408@foobar.org> Date: Sat, 15 Feb 2014 13:31:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5E674C4B-E339-4622-88A1-254797721C1A@delong.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> <52FFB6B7.4090408@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 15 Feb 2014 13:40:15 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CgZS4-5AhnrpkiDeRb958279iUs Cc: V6 Ops List , draft-fan-idr-ipv6-bgp-id@tools.ietf.org, idr wg Subject: Re: [v6ops] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 21:43:04 -0000 If nothing else, if the authors intend to apply this to more routing = protocols than just BGP, they should change the proposal to reflect that = they seek to change ROUTER-IDs in general and not just the BGP = identifier. However, I believe that the idea of converting a router-id from 32 bits = to 128 bits is woefully misguided. I say this as an operator who has = operated IPv4 and IPv6 and dual-stack networks. It has always, IMHO, been unfortunate that OSPF Area numbers and = Router-IDs for various protocols have been tied to IPv4 address syntax = and, in the case of router-IDs, affiliated with interface (including = loopback) IP addresses. This has created no end of confusion among less = well trained operators. IPv6 gives us the opportunity to correct this problem and have IDs which = no longer match addresses. That is a "good thing=99" IMHO. As near as I can tell, this draft seeks to prevent that improvement from = occurring. Instead, I think that Sander and David are on a much better track and I = would be willing to join in on the efforts to write such an operational = draft. Owen On Feb 15, 2014, at 10:49 , Nick Hilliard wrote: > On 15/02/2014 15:26, Sander Steffann wrote: >> Op 15 feb. 2014, om 16:13 heeft Shane Amante = het volgende geschreven: >>> On Feb 15, 2014, at 12:55 AM, Randy Bush wrote: >>>> I use this funny thing called DNS.=20 >>>=20 >>> And that has what to do with the problem of determining liveness or = determining where in the topology is a ROUTER_ID? >>=20 >> And what does an integer called ROUTER_ID tell you about that? >>=20 >> And hey, you can always create records like >> 1.2.3.4.router-id.castlepoint.net IN CNAME = router1.somewhere.castlepoint.net >=20 > guys, we're all having a bit of an ietf moment here: within the space = of 48 > hours, the conversation has ratholed. Let's love up a bit. >=20 > The authors of the draft have a simple operational desire to make = their > lives a little easier and as an operator I sympathise with this, > particularly because they are using ipv6-only networks in anger which = is > more than I do. >=20 > There are two advantages of having a 128 bit router-id (with the = unstated > convention of tying router-id =3D=3D address of first loopback): >=20 > - firstly it's easy to identify the location of prefix announcements = on > your network > - secondly the router-id can be autoconfigured. >=20 > On the other hand, implementing this will require that the authors = define a > transition mechanism to allow 128 bit router-id routers interoperate = with > 32 bit router-id routers in such a way that router-id collisions don't = occur. >=20 > If the authors want to progress this, they need to state a stronger = use > case and they need to create a transition mechanism. If they can do = this > in a reasonable way which doesn't break backwards compatibility, then = it > might be appropriate for idr / v6ops / etc to take another look at the = draft. >=20 > Also, I wish them well because everyone understands what a router ID = is and > everyone will want to paint theirs a different colour. >=20 > Nick >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Feb 15 16:35:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E94D1A0305 for ; Sat, 15 Feb 2014 16:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scekdV2YrpaT for ; Sat, 15 Feb 2014 16:35:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EC6941A0304 for ; Sat, 15 Feb 2014 16:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6067; q=dns/txt; s=iport; t=1392510929; x=1393720529; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SgD4kQZH0fw1CeuYsDKnXGarn5hgSfz7qZmcs8qCBOk=; b=Z7/rK7ftLabT9xzCxilMjYbUaeqw3VXBOdyGTD8KN0/88a9508pWvkyg JJ5FZbLmMuxMaYnxwuDukENFOazoTzwlWG1BYoHgU6hoXeGXahS8ny925 wl39cvnKJFEmf96v0/kxSiAv9/lMt7p5D7fXZ8g/D6mG9R1jU/uJmNgbZ U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8GABcHAFOtJXG8/2dsb2JhbABZgwY4V7ZhiFWBDxZ0giUBAQEDAXkFCwIBCBguMiUCBA4FDodvCA3JORePAQeDJIEUBJBAgTKGOoEykHGDLYIq X-IronPort-AV: E=Sophos;i="4.95,852,1384300800"; d="asc'?scan'208,217";a="304336530" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 16 Feb 2014 00:35:29 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1G0ZSn2002238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Feb 2014 00:35:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.10]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Sat, 15 Feb 2014 18:35:28 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] Proposed agenda Thread-Index: AQHPKq79RIg7DaYQn0O5jbWXZ8Do1Q== Date: Sun, 16 Feb 2014 00:35:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_9F332094-8D24-4C9D-B942-84DA09485D77"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GO_71PsSCwVzS-kPD9dDzCPZj0Y Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Feb 2014 00:35:32 -0000 --Apple-Mail=_9F332094-8D24-4C9D-B942-84DA09485D77 Content-Type: multipart/alternative; boundary="Apple-Mail=_1A328DC4-79DA-4CB2-AF4B-76C63CABD679" --Apple-Mail=_1A328DC4-79DA-4CB2-AF4B-76C63CABD679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let me ask for comment on the list. Folks, would you like to discuss this? I have a half hour to spare in = the time we have suggested. On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti wrote: > On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) = wrote: > This is of course open to change; that's why it's called a "proposed = agenda". Please post to the list. >=20 > Would there be time to briefly discuss: >=20 > = http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-0= 0 ?=20 >=20 > This will be presented in 6man during a session on the efficiency of = the ND protocol, but I feel that it really belongs in v6ops, because it = has no protocol changes. >=20 > Of course, since it was posted only shortly before 23:59 UTC, it fails = the "has been discussed on the list" test. :-) ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan --Apple-Mail=_1A328DC4-79DA-4CB2-AF4B-76C63CABD679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Let = me ask for comment on the list.

Folks, would you like = to discuss this? I have a half hour to spare in the time we have = suggested.

On Feb 14, 2014, at 7:05 PM, Lorenzo = Colitti <lorenzo@google.com>
&n= bsp;wrote:

On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker = (fred) <fred@cisco.com> wrote:
This is of course open to change; that's = why it's called a "proposed agenda". Please post to the list.

Would there be time to briefly = discuss:


This will be presented in 6man during a session on = the efficiency of the ND protocol, but I feel that it really belongs in = v6ops, because it has no protocol changes.

Of = course, since it was posted only shortly before 23:59 UTC, it fails the = "has been discussed on the list" test. :-)

ignorance of how to use = new knowledge stockpiles exponentially X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAB31A0310 for ; Sat, 15 Feb 2014 16:52:04 -0800 (PST) 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 684LCGd0ZPmM for ; Sat, 15 Feb 2014 16:52:03 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 15B3C1A0305 for ; Sat, 15 Feb 2014 16:52:02 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t61so9827990wes.0 for ; Sat, 15 Feb 2014 16:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TtJlOKDAVAbdJbwybq7Jf6hD9XQVibca4jplbdhhPoo=; b=t2zBsEhOMWXGDT+sd65LzQFRGXG4yqG9IFnZKchSxy2mz48lthmJ43v0dZWRETqaT/ /Fs/XO3E91Yw5xz64zcrQzgO0J3LSfJ5mEauYF117aOSEm0035OA7KvDDjJhHL/tOfXM mxDcqVul9g+/btXtqq1hWcKirlHpPbqvzGvyLSdhhCnogw1lIjdBFekLVkmLlLXWoYt1 ot4J9yl4u8A/you9TIVUsuImoJWne0MQIwvsPris7QVIrzFYvh3kBlwTBdhNuPmcpmjj qaPg2RnlSmScWzwhnoqyrpy0st5AAXN91wK9lNd+gnkSeSiTCCZW5Rzk6QKoBagW4D1B HoUg== MIME-Version: 1.0 X-Received: by 10.194.119.230 with SMTP id kx6mr10074144wjb.13.1392511920684; Sat, 15 Feb 2014 16:52:00 -0800 (PST) Received: by 10.194.133.169 with HTTP; Sat, 15 Feb 2014 16:52:00 -0800 (PST) Received: by 10.194.133.169 with HTTP; Sat, 15 Feb 2014 16:52:00 -0800 (PST) In-Reply-To: References: Date: Sat, 15 Feb 2014 16:52:00 -0800 Message-ID: From: Cb B To: Fred Baker Content-Type: multipart/alternative; boundary=089e0115fe2e60c5da04f27b727e Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YM6741_TyY2Lb1Zl-TDP09HzFr8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Feb 2014 00:52:05 -0000 --089e0115fe2e60c5da04f27b727e Content-Type: text/plain; charset=ISO-8859-1 On Feb 15, 2014 4:35 PM, "Fred Baker (fred)" wrote: > > Let me ask for comment on the list. > > Folks, would you like to discuss this? I have a half hour to spare in the time we have suggested. > I think this is important to discuss. CB > On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti > wrote: > >> On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) wrote: >>> >>> This is of course open to change; that's why it's called a "proposed agenda". Please post to the list. >> >> >> Would there be time to briefly discuss: >> >> http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00? >> >> This will be presented in 6man during a session on the efficiency of the ND protocol, but I feel that it really belongs in v6ops, because it has no protocol changes. >> >> Of course, since it was posted only shortly before 23:59 UTC, it fails the "has been discussed on the list" test. :-) > > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e0115fe2e60c5da04f27b727e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 15, 2014 4:35 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
>
> Let me ask for comment on the list.
>
> Folks, would you like to discuss this? I have a half hour to spare in = the time we have suggested.
>

I think this is important to discuss.

CB

> On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti <lorenzo@google.com>
> =A0wrote:
>
>> On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) <fred@cisco.com> wrote:
>>>
>>> This is of course open to change; that's why it's call= ed a "proposed agenda". Please post to the list.
>>
>>
>> Would there be time to briefly discuss:
>>
>> http://tools.ietf.org/html/draft-yourtchenko-colitti-= nd-reduce-multicast-00 ?=A0
>>
>> This will be presented in 6man during a session on the efficiency = of the ND protocol, but I feel that it really belongs in v6ops, because it = has no protocol changes.
>>
>> Of course, since it was posted only shortly before 23:59 UTC, it f= ails the "has been discussed on the list" test. :-)
>
>
> ----------------------------------------------------
> The=A0ignorance=A0of how to=A0use new=A0knowledge=A0stockpiles exponen= tially.=A0
> =A0=A0 - Marshall McLuhan
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--089e0115fe2e60c5da04f27b727e-- From nobody Sat Feb 15 17:52:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016741A0327 for ; Sat, 15 Feb 2014 17:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cfhZjSk5-8Y for ; Sat, 15 Feb 2014 17:52:31 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 383F91A0310 for ; Sat, 15 Feb 2014 17:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5412; q=dns/txt; s=iport; t=1392515549; x=1393725149; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MYxKBsS40qvGbJVRzIKi/pOHY+0wE6fQn6Arrkhzw/0=; b=jJ7rESJB1uKEbXl6PKaQDU/zQk7RPLOFiyrXWiPY2mhyrPK7EsIqg6lU jaPCZCCEee2dqMInT+erg8vWEUtAv5ZI6RwP6mqI5Qa5av3IeK+YvFKwD c8FEfuDwX7BRfZx/ZOA/KakWWqxboPHWLPum8ZpduZi8qm1KhewbLZLf6 Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAGAFIZAFOtJV2c/2dsb2JhbABZgwY4V7ZiiFWBDxZ0giUBAQEDAQEBAWsLBQsCAQgEFC4hBgslAgQOBQ6HYwMJCA3BJA2IDxeMZ4IWBAeDJIEUBJBAgTKEToFsgTKLLIVFgy2CKg X-IronPort-AV: E=Sophos;i="4.95,852,1384300800"; d="asc'?scan'208,217";a="20775841" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 16 Feb 2014 01:52:28 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1G1qSvx024234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Feb 2014 01:52:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.10]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Sat, 15 Feb 2014 19:52:28 -0600 From: "Fred Baker (fred)" To: Cb B Thread-Topic: [v6ops] Proposed agenda Thread-Index: AQHPKrm+XVjT6Z9F10uE5Sji7NH8Yg== Date: Sun, 16 Feb 2014 01:52:27 +0000 Message-ID: <62600D0E-5034-41BC-A62C-176B082B964E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.119] Content-Type: multipart/signed; boundary="Apple-Mail=_9FF37393-7B71-4FA1-A2B7-56557E993B94"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0q3JDcikdR0Twjv3FByRADaA_TM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Feb 2014 01:52:34 -0000 --Apple-Mail=_9FF37393-7B71-4FA1-A2B7-56557E993B94 Content-Type: multipart/alternative; boundary="Apple-Mail=_455A9505-6B29-4A28-A85D-DD688E33BEEF" --Apple-Mail=_455A9505-6B29-4A28-A85D-DD688E33BEEF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ack. Thanks. On Feb 15, 2014, at 4:52 PM, Cb B wrote: >=20 > On Feb 15, 2014 4:35 PM, "Fred Baker (fred)" wrote: > > > > Let me ask for comment on the list. > > > > Folks, would you like to discuss this? I have a half hour to spare = in the time we have suggested. > > >=20 > I think this is important to discuss. >=20 > CB >=20 > > On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti > > wrote: > > > >> On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) = wrote: > >>> > >>> This is of course open to change; that's why it's called a = "proposed agenda". Please post to the list. > >> > >> > >> Would there be time to briefly discuss: > >> > >> = http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-0= 0 ?=20 > >> > >> This will be presented in 6man during a session on the efficiency = of the ND protocol, but I feel that it really belongs in v6ops, because = it has no protocol changes. > >> > >> Of course, since it was posted only shortly before 23:59 UTC, it = fails the "has been discussed on the list" test. :-) > > > > > > ---------------------------------------------------- > > The ignorance of how to use new knowledge stockpiles exponentially.=20= > > - Marshall McLuhan > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > ------------------------------------------------------ 8 issues in virtual infrastructure http://dcrocker.net/#fallacies --Apple-Mail=_455A9505-6B29-4A28-A85D-DD688E33BEEF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Ack. Thanks.

On Feb 15, 2014, at 4:52 PM, Cb B <cb.list6@gmail.com>
 wrote:


On Feb 15, 2014 4:35 PM, "Fred Baker (fred)" <fred@cisco.com> wrote:
>
> Let me ask for comment on the list.
>
> Folks, would you like to discuss this? I have a half hour to spare in the time we have suggested.
>

I think this is important to discuss.

CB

> On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti <lorenzo@google.com>
>  wrote:
>
>> On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) <fred@cisco.com> wrote:
>>>
>>> This is of course open to change; that's why it's called a "proposed agenda". Please post to the list.
>>
>>
>> Would there be time to briefly discuss:
>>
>> http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 ? 
>>
>> This will be presented in 6man during a session on the efficiency of the ND protocol, but I feel that it really belongs in v6ops, because it has no protocol changes.
>>
>> Of course, since it was posted only shortly before 23:59 UTC, it fails the "has been discussed on the list" test. :-)
>
>
> ----------------------------------------------------
> The ignorance of how to use new knowledge stockpiles exponentially. 
>    - Marshall McLuhan
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>


------------------------------------------------------
8 issues in virtual infrastructure

--Apple-Mail=_455A9505-6B29-4A28-A85D-DD688E33BEEF-- --Apple-Mail=_9FF37393-7B71-4FA1-A2B7-56557E993B94 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 iD8DBQFTABnZbjEdbHIsm0MRAmgAAJ4nZkBzqJR7i6w9dJMUM53znA/xvQCgiHPp FsqCZWUIUv21zMupRSkYtJ8= =C8+6 -----END PGP SIGNATURE----- --Apple-Mail=_9FF37393-7B71-4FA1-A2B7-56557E993B94-- From nobody Sun Feb 16 05:45:15 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E181A01FD for ; Sun, 16 Feb 2014 05:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQghnZxQ6ck5 for ; Sun, 16 Feb 2014 05:45:12 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B30261A01FB for ; Sun, 16 Feb 2014 05:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392558311; x=1393767911; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=HiLbEX0CR8YCVPC0l+zwMISVOEZGxDi6dnllocwYcd7IO54DiVKl2zns lNLKWYT/ecaDeQJveZf/4Z98lxx1BCO/mkzTzdPoDIGHxFkN3HkjxagvE ygjKuNjSe5d3tzxmASvqM1CALGUnaH2/UmLbScl2pbxTisNXfd7bw6g8E w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngKADfAAFOrRDoI/2dsb2JhbABZgwY4qzABlFMDBAKBDxZ0gyU8LQeIZQ7JdhePAR2EIgSJSJAWkHGDTg X-IronPort-AV: E=Sophos;i="4.95,855,1384300800"; d="scan'208";a="103328297" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 16 Feb 2014 13:45:10 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1GDj1s7020805; Sun, 16 Feb 2014 13:45:09 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1GDj0k22519; Sun, 16 Feb 2014 05:45:00 -0800 (PST) Date: Sun, 16 Feb 2014 05:45:00 -0800 (PST) From: Message-Id: <201402161345.s1GDj0k22519@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/L3cZd-JbC_ER1RcQr6lGgdOe3hE Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 13:45:14 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Sun Feb 16 05:45:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ED41A03EF for ; Sun, 16 Feb 2014 05:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.703 X-Spam-Level: X-Spam-Status: No, score=-106.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2YnGk-Na6xP for ; Sun, 16 Feb 2014 05:45:21 -0800 (PST) Received: from aer-iport-4.cisco.com (unknown [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 926AA1A03EB for ; Sun, 16 Feb 2014 05:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392558318; x=1393767918; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=Zxz2qaaObN+ebEVbsHpTNFQqBRyT9pGgwak22TetUZU3vZy+JSdI/5/H sJwh5TK6DYql2unrDATi362inN1lRXZoMukywfcQXwYlL41IBY1f964d1 fylKxmsqNoLaAtX3jJ7pqQeraKdQ2W5ARwhRLXe7IjVITwapWw1MLflYU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngKAHLAAFOQ/khL/2dsb2JhbABZgwY4qzABlFMDBAKBDxZ0gyU8NIhlAQ3JdhePAR2EIgSJSJAWkHGDTg X-IronPort-AV: E=Sophos;i="4.95,855,1384300800"; d="scan'208";a="478381" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 16 Feb 2014 13:45:17 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1GDjFn7008853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Feb 2014 13:45:17 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s1GDjFJM022591; Sun, 16 Feb 2014 05:45:15 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s1GDjECe022535; Sun, 16 Feb 2014 05:45:14 -0800 (PST) Date: Sun, 16 Feb 2014 05:45:14 -0800 (PST) From: Fred Baker Message-Id: <201402161345.s1GDjECe022535@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UgzOE8299V6Vl6XKcwWYn9U8r_k Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 13:45:22 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Sun Feb 16 06:42:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25AD1A020A for ; Sun, 16 Feb 2014 06:42:04 -0800 (PST) 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 ECtiAMzXzssq for ; Sun, 16 Feb 2014 06:42:02 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id F34651A0223 for ; Sun, 16 Feb 2014 06:42:01 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s1GEfw6u017344 for ; Sun, 16 Feb 2014 15:41:58 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5415620777F for ; Sun, 16 Feb 2014 15:42:36 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4C73D200D9B for ; Sun, 16 Feb 2014 15:42:36 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.5]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s1GEfsCw009884 for ; Sun, 16 Feb 2014 15:41:58 +0100 Message-ID: <5300CE32.1050808@gmail.com> Date: Sun, 16 Feb 2014 15:41:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> In-Reply-To: <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KbNpinTiLOgdFvilufQ4ffGNNDw Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 14:42:05 -0000 Le 15/02/2014 19:16, Owen DeLong a écrit : > Indeed, the situations where ULA usage is detrimental vastly > outnumbers those where it is actually beneficial. > > If we're going to move something like this forward, that really > should be made clear. Consider new deployments like IPv6 vehicular networks. There is an immediate direction to demonstrate an IPv6 vehicle if it used ULA. There is also the alternative to request PI or PA IPv6 addressing space for these vehicles from some registry, steps which may take time. These two directions are actually head and tail of same snake: it bites its end, or otherwise put it's a chicken and egg problem: if the deployer sees the prototype works then it may request IPv6 addressing space from registry, but not before it sees it works. At this point I think this draft is good to say that ULAs are useful. Later on maybe less so. But right now that's reflecting real-world situation. That's how I see it, and one's mileage may vary. But imposing to not do ULA is little reasonable for some test deployments. Alex PS: There are also some intermediary alternatives like IPv4 transitioning (6to4 and other tunnels), 64share. Each has some inconvenients (6to4 requires both IPv4 and IPv6 on cellular, whereas IPv6-only is easier with some operator; 64share only allows one subnet in vehicle). Also one would consider asking the cellular operator to implement DHCPv6 Prefix Delegation, which may also take time. > > Owen > > On Feb 14, 2014, at 17:08 , Brian E Carpenter > wrote: > >> Well, there have always been some people against the existence of >> ULAs, but we did reach rough consensus to define them, since other >> people see value in them, for reasons that have been aired many >> times. So writing words about the best way to use them if you want >> to use them seems right to me. >> >> Brian >> >> On 14/02/2014 23:00, ek wrote: >>> +1 >>> >>> ---- On Fri, 14 Feb 2014 18:34:36 +0900 Randy >>> Bush<randy@psg.com> wrote ---- >>> >>> >>> i expected this to be a short draft. "Don't" >>> >>> randy >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> v6ops mailing list v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Sun Feb 16 10:27:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA61A01B0 for ; Sun, 16 Feb 2014 10:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 vMbWh6EKW8QD for ; Sun, 16 Feb 2014 10:27:38 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9C49B1A0152 for ; Sun, 16 Feb 2014 10:27:37 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1GIMLKH029239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Feb 2014 10:22:22 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1GIMLKH029239 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392574943; bh=EXM7HuBRFNgEEcXVT1hby0SIWrM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ixlC696tkFLF1NVUinjO2mbfmj9vWf6gt+uhj1v/PeRqCULtLTl7M7ePJyO2T6KLM p1ibbaeO3e2smwDUur5ny3cybKWSZvxRdTWd+pxpy4xmq4s8LQxm8sWSHbz50sTNrH cApMt+MG5LHy1vUDlgSga0fapQjxj6iR+8ra2gBY= Content-Type: multipart/alternative; boundary="Apple-Mail=_C793EF96-E7CD-4496-8DD6-739C3D0BAB6A" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <5300CE32.1050808@gmail.com> Date: Sun, 16 Feb 2014 10:22:05 -0800 Message-Id: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 16 Feb 2014 10:22:23 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5bzI1tHFhVNcymys-KGxZ23dvKY Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 18:27:41 -0000 --Apple-Mail=_C793EF96-E7CD-4496-8DD6-739C3D0BAB6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 16, 2014, at 06:41 , Alexandru Petrescu = wrote: > Le 15/02/2014 19:16, Owen DeLong a =E9crit : >> Indeed, the situations where ULA usage is detrimental vastly >> outnumbers those where it is actually beneficial. >>=20 >> If we're going to move something like this forward, that really >> should be made clear. >=20 > Consider new deployments like IPv6 vehicular networks. >=20 > There is an immediate direction to demonstrate an IPv6 vehicle if it = used ULA. There is also the alternative to request PI or PA IPv6 = addressing space for these vehicles from some registry, steps which may = take time. >=20 It takes about 48 hours to get address space approved from a registry. = Even less time to get some from a provider in most cases. I do not at all buy your argument here. > These two directions are actually head and tail of same snake: it = bites its end, or otherwise put it's a chicken and egg problem: if the = deployer sees the prototype works then it may request IPv6 addressing = space from registry, but not before it sees it works. >=20 > At this point I think this draft is good to say that ULAs are useful. = Later on maybe less so. But right now that's reflecting real-world = situation. >=20 So we disagree. It is not the first time and probably not the last. > That's how I see it, and one's mileage may vary. >=20 > But imposing to not do ULA is little reasonable for some test = deployments. I did not say "don't do ULA". I said that the number of situations where = ULA is detrimental vastly outweighs the number where it is useful. Your description above is one of the few cases where it might not be = detrimental. It is not, however, particularly useful vs. PI or PA. As such, I think it is appropriate for the draft to make it clear that = use of ULA should be carefully considered as in most cases it provides = greater detriment. >=20 > Alex > PS: > There are also some intermediary alternatives like IPv4 transitioning = (6to4 and other tunnels), 64share. Each has some inconvenients (6to4 = requires both IPv4 and IPv6 on cellular, whereas IPv6-only is easier = with some operator; 64share only allows one subnet in vehicle). Also = one would consider asking the cellular operator to implement DHCPv6 = Prefix Delegation, which may also take time. I'm not sure how any of that relates to the ULA draft in question. ULA = certainly isn't useful in any of those scenarios. Owen --Apple-Mail=_C793EF96-E7CD-4496-8DD6-739C3D0BAB6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1





= --Apple-Mail=_C793EF96-E7CD-4496-8DD6-739C3D0BAB6A-- From nobody Sun Feb 16 10:34:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0791A01EC for ; Sun, 16 Feb 2014 10:34:45 -0800 (PST) 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 XdcrqWoVJyup for ; Sun, 16 Feb 2014 10:34:43 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 355EE1A01B9 for ; Sun, 16 Feb 2014 10:34:43 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s1GIYZaZ029516; Sun, 16 Feb 2014 19:34:35 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C9B8C200D9B; Sun, 16 Feb 2014 19:35:12 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BE100200C1C; Sun, 16 Feb 2014 19:35:12 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.5]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s1GIYRM2000399; Sun, 16 Feb 2014 19:34:34 +0100 Message-ID: <530104B3.3070205@gmail.com> Date: Sun, 16 Feb 2014 19:34:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Owen DeLong References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3jnAEF0uBh9K3uu1kvpcdEK1ek4 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 18:34:46 -0000 Le 16/02/2014 19:22, Owen DeLong a écrit : > > On Feb 16, 2014, at 06:41 , Alexandru Petrescu > > wrote: > >> Le 15/02/2014 19:16, Owen DeLong a écrit : >>> Indeed, the situations where ULA usage is detrimental vastly >>> outnumbers those where it is actually beneficial. >>> >>> If we're going to move something like this forward, that really >>> should be made clear. >> >> Consider new deployments like IPv6 vehicular networks. >> >> There is an immediate direction to demonstrate an IPv6 vehicle if it >> used ULA. There is also the alternative to request PI or PA IPv6 >> addressing space for these vehicles from some registry, steps which >> may take time. >> > > It takes about 48 hours to get address space approved from a registry. > Even less time to get some from a provider in most cases. Is that for free and does it include setting up IPv6 routing to it, in Europe? > I do not at all buy your argument here. Ok, I need to learn how to do it, so well as to be able to teach somebody else who'd do it. I am only in the middle. > >> These two directions are actually head and tail of same snake: it >> bites its end, or otherwise put it's a chicken and egg problem: if the >> deployer sees the prototype works then it may request IPv6 addressing >> space from registry, but not before it sees it works. >> >> At this point I think this draft is good to say that ULAs are useful. >> Later on maybe less so. But right now that's reflecting real-world >> situation. >> > > So we disagree. It is not the first time and probably not the last. > >> That's how I see it, and one's mileage may vary. >> >> But imposing to not do ULA is little reasonable for some test deployments. > > I did not say "don't do ULA". I said that the number of situations where > ULA is detrimental vastly outweighs the number where it is useful. > > Your description above is one of the few cases where it might not be > detrimental. It is not, however, particularly useful vs. PI or PA. > > As such, I think it is appropriate for the draft to make it clear that > use of ULA should be carefully considered as in most cases it provides > greater detriment. Also make it clear that any other alternative is not easy: it involves delays and money. > >> >> Alex >> PS: >> There are also some intermediary alternatives like IPv4 transitioning >> (6to4 and other tunnels), 64share. Each has some inconvenients (6to4 >> requires both IPv4 and IPv6 on cellular, whereas IPv6-only is easier >> with some operator; 64share only allows one subnet in vehicle). Also >> one would consider asking the cellular operator to implement DHCPv6 >> Prefix Delegation, which may also take time. > > I'm not sure how any of that relates to the ULA draft in question. ULA > certainly isn't useful in any of those scenarios. A vehicle holds a 'mobile router' which may act precisely the same as a smartphone and tethering when connecting on cellular. Except there are more subnets in a vehicle than the single subnet a user may carry. Similar comparisons apply to 6to4 and DHCP Prefix Delegation - it's just like a smartphone. Alex > > Owen > From nobody Sun Feb 16 11:16:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE7F1A025A for ; Sun, 16 Feb 2014 11:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPa0X40_ZQAm for ; Sun, 16 Feb 2014 11:16:08 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 142831A0242 for ; Sun, 16 Feb 2014 11:16:08 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so13526454pdb.24 for ; Sun, 16 Feb 2014 11:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yPwDNayP7SrBJfXrzwTWn1kN1QyVsX+pdBP76O9MjA4=; b=WusPHESJpZNeHmo5t6YukSXJZdATFBFWHMGszQrlxn0dEFgnjpGdQlCM5wxlk8iQry iDrixnPgGLj1PHsFiiInKo2W+qahslTAeO9gJQw+NHaterbPA4izZuSRcaLyRbdYIxzd Csgr/NwxuyH1dytvJA8O7fWTOM2NzGQFmQ5Ng36oqKSgH4sU2s2OVR9cVsMX1DtgaJpQ CQMcIK2g0Ov3SsfNTptQLGgo0uIC80DssbllE7DPAKEm6Ziqkt1YpenSwOl0MihgkoZe /jiqEOg/hDYZZib8PCGIiLe3w3/MsVkkJAtK1c54OtvOOEFrOgdwtkJKBguOfuiPFWrW yWpQ== X-Received: by 10.66.4.130 with SMTP id k2mr21743474pak.97.1392578165916; Sun, 16 Feb 2014 11:16:05 -0800 (PST) Received: from [192.168.178.23] (22.200.69.111.dynamic.snap.net.nz. [111.69.200.22]) by mx.google.com with ESMTPSA id jk16sm38241553pbb.34.2014.02.16.11.16.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 11:16:05 -0800 (PST) Message-ID: <53010E70.5000401@gmail.com> Date: Mon, 17 Feb 2014 08:16:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> In-Reply-To: <530104B3.3070205@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lgvtWXmEh2PvH5vV7rFj352n17U Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:16:10 -0000 >>> Le 15/02/2014 19:16, Owen DeLong a =C3=A9crit : >>>> Indeed, the situations where ULA usage is detrimental vastly >>>> outnumbers those where it is actually beneficial. That's an opinion, but it isn't an argument for abolishing ULAs. It's actually an argument for improving this draft so that it describes the cases in which ULAs are beneficial. Could we have a detailed conversation about whether those cases are correctly described in the draft? Brian From nobody Sun Feb 16 11:52:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 117D11A0282 for ; Sun, 16 Feb 2014 11:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 3XDY76xn1Axf for ; Sun, 16 Feb 2014 11:52:26 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 957331A0281 for ; Sun, 16 Feb 2014 11:52:25 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1GJqH3P001212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Feb 2014 11:52:17 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1GJqH3P001212 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392580338; bh=MVXmyL5HK4WNvS1NJJIc10BjeTY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MopHf9QIxPLZn0Hui65+nFN8Fgu0+ioQlbMk7w3UvK7RyM0Gz07mBpgw6ucraI1Nm Eh783C1V0OLJWjwQOB2woWEQ4MA48pISZJ5mZ1WXycZPgIxNWbimVYUtve1taAM/sS 9FzBgkxF29Z8MrjFFUga2agG0RGR8WOjPY8eDv0M= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <530104B3.3070205@gmail.com> Date: Sun, 16 Feb 2014 11:51:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0E7988A4-4C34-42B7-9151-4120B12E7869@delong.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 16 Feb 2014 11:52:18 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/AjCtBBhlt97VvDmBeNBdlG4KeEg Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:52:29 -0000 On Feb 16, 2014, at 10:34 , Alexandru Petrescu = wrote: > Le 16/02/2014 19:22, Owen DeLong a =E9crit : >>=20 >> On Feb 16, 2014, at 06:41 , Alexandru Petrescu >> > = wrote: >>=20 >>> Le 15/02/2014 19:16, Owen DeLong a =E9crit : >>>> Indeed, the situations where ULA usage is detrimental vastly >>>> outnumbers those where it is actually beneficial. >>>>=20 >>>> If we're going to move something like this forward, that really >>>> should be made clear. >>>=20 >>> Consider new deployments like IPv6 vehicular networks. >>>=20 >>> There is an immediate direction to demonstrate an IPv6 vehicle if it >>> used ULA. There is also the alternative to request PI or PA IPv6 >>> addressing space for these vehicles from some registry, steps which >>> may take time. >>>=20 >>=20 >> It takes about 48 hours to get address space approved from a = registry. >> Even less time to get some from a provider in most cases. >=20 > Is that for free and does it include setting up IPv6 routing to it, in = Europe? =46rom the RIR, you would have to pay RIR fees. =46rom an ISP, you = probably get it for free, yes. No. However, since you _CAN'T_ set up routing to ULA, I'm not sure how = that applies. >=20 >> I do not at all buy your argument here. >=20 > Ok, I need to learn how to do it, so well as to be able to teach = somebody else who'd do it. I am only in the middle. I don't think that trying to influence IETF standards is the best way to = avoid an education. >=20 >>=20 >>> These two directions are actually head and tail of same snake: it >>> bites its end, or otherwise put it's a chicken and egg problem: if = the >>> deployer sees the prototype works then it may request IPv6 = addressing >>> space from registry, but not before it sees it works. >>>=20 >>> At this point I think this draft is good to say that ULAs are = useful. >>> Later on maybe less so. But right now that's reflecting real-world >>> situation. >>>=20 >>=20 >> So we disagree. It is not the first time and probably not the last. >>=20 >>> That's how I see it, and one's mileage may vary. >>>=20 >>> But imposing to not do ULA is little reasonable for some test = deployments. >>=20 >> I did not say "don't do ULA". I said that the number of situations = where >> ULA is detrimental vastly outweighs the number where it is useful. >>=20 >> Your description above is one of the few cases where it might not be >> detrimental. It is not, however, particularly useful vs. PI or PA. >>=20 >> As such, I think it is appropriate for the draft to make it clear = that >> use of ULA should be carefully considered as in most cases it = provides >> greater detriment. >=20 > Also make it clear that any other alternative is not easy: it involves = delays and money. I don't buy that argument. Getting it routed is going to cost you money = regardless of what space you use. If you use ISP provided space, you = probably get the space for free. If you use ULA, then you have to get = space from the ISP, NAT the ULA, and still pay the same money. If you want PI space so that you can move amongst different ISPs, then, = you will need to pay the RIR fees for the PI space, but these are = relatively minimal. >=20 >=20 >>=20 >>>=20 >>> Alex >>> PS: >>> There are also some intermediary alternatives like IPv4 = transitioning >>> (6to4 and other tunnels), 64share. Each has some inconvenients = (6to4 >>> requires both IPv4 and IPv6 on cellular, whereas IPv6-only is easier >>> with some operator; 64share only allows one subnet in vehicle). = Also >>> one would consider asking the cellular operator to implement DHCPv6 >>> Prefix Delegation, which may also take time. >>=20 >> I'm not sure how any of that relates to the ULA draft in question. = ULA >> certainly isn't useful in any of those scenarios. >=20 > A vehicle holds a 'mobile router' which may act precisely the same as = a smartphone and tethering when connecting on cellular. Except there = are more subnets in a vehicle than the single subnet a user may carry. There are more subnets attached to cellular devices in the future, too. = I'm still not sure what any of this has to do with ULA. > Similar comparisons apply to 6to4 and DHCP Prefix Delegation - it's = just like a smartphone. But what does that have to do with ULA? ULA is _NOT_ useful in any of = those cases. Owen From nobody Sun Feb 16 11:57:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCCA1A027A for ; Sun, 16 Feb 2014 11:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 ogTx_1yPZQvZ for ; Sun, 16 Feb 2014 11:57:43 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 07F1E1A0277 for ; Sun, 16 Feb 2014 11:57:42 -0800 (PST) Received: from delong-dhcp227.delong.com (delong-dhcp27 [192.159.10.227]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1GJrZQn001247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 16 Feb 2014 11:53:36 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1GJrZQn001247 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392580416; bh=j+eJ0+CP0WWENFImdqDwjncTCqs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Zj48YhhAonUr6ed+sk4uia8+aJt17gj8ceR+WKpjKVx2Rgg2hagAas3Gu6z0Rh2Rg ElctH+qeqS40baFhTFzoKEsaMvtgqk4/+VssKWWo+9WgCmJvilMOZHdA3dvGHH/AoQ KApQyLlWkK4obhLxlApU8l0LzBlhU7GaxJ0HT8jE= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <53010E70.5000401@gmail.com> Date: Sun, 16 Feb 2014 11:53:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Sun, 16 Feb 2014 11:53:36 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rFLAlqpzOTo7cIJi8UfA_aU8fwk Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:57:44 -0000 On Feb 16, 2014, at 11:16 , Brian E Carpenter = wrote: >>>> Le 15/02/2014 19:16, Owen DeLong a =E9crit : >>>>> Indeed, the situations where ULA usage is detrimental vastly >>>>> outnumbers those where it is actually beneficial. >=20 > That's an opinion, but it isn't an argument for abolishing > ULAs. It's actually an argument for improving this draft so > that it describes the cases in which ULAs are beneficial. > Could we have a detailed conversation about whether those cases > are correctly described in the draft? >=20 > Brian I was arguing for an improvement to the draft, not for the abolishment = of ULA. While I would not be sad to see ULA deprecated, that's not a topic of = this discussion or even this WG. Owen From nobody Sun Feb 16 12:16:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A725E1A0274 for ; Sun, 16 Feb 2014 12:16:12 -0800 (PST) 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 1pjd7KviZ43M for ; Sun, 16 Feb 2014 12:16:09 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF8C1A0271 for ; Sun, 16 Feb 2014 12:16:09 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s1GKG24p024323; Sun, 16 Feb 2014 21:16:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2EEE82077BD; Sun, 16 Feb 2014 21:16:40 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 23549207A9A; Sun, 16 Feb 2014 21:16:40 +0100 (CET) Received: from [127.0.0.1] ([132.166.86.5]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s1GKFvng023534; Sun, 16 Feb 2014 21:16:02 +0100 Message-ID: <53011C7D.50109@gmail.com> Date: Sun, 16 Feb 2014 21:15:57 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Owen DeLong References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <0E7988A4-4C34-42B7-9151-4120B12E7869@delong.com> In-Reply-To: <0E7988A4-4C34-42B7-9151-4120B12E7869@delong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Ys8CfWYwbfpUwTUn6hXsfMPWqv8 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 20:16:12 -0000 Le 16/02/2014 20:51, Owen DeLong a écrit : > > On Feb 16, 2014, at 10:34 , Alexandru Petrescu > wrote: > >> Le 16/02/2014 19:22, Owen DeLong a écrit : >>> >>> On Feb 16, 2014, at 06:41 , Alexandru Petrescu >>> >> > wrote: >>> >>>> Le 15/02/2014 19:16, Owen DeLong a écrit : >>>>> Indeed, the situations where ULA usage is detrimental vastly >>>>> outnumbers those where it is actually beneficial. >>>>> >>>>> If we're going to move something like this forward, that >>>>> really should be made clear. >>>> >>>> Consider new deployments like IPv6 vehicular networks. >>>> >>>> There is an immediate direction to demonstrate an IPv6 vehicle >>>> if it used ULA. There is also the alternative to request PI >>>> or PA IPv6 addressing space for these vehicles from some >>>> registry, steps which may take time. >>>> >>> >>> It takes about 48 hours to get address space approved from a >>> registry. Even less time to get some from a provider in most >>> cases. >> >> Is that for free and does it include setting up IPv6 routing to >> it, in Europe? > >> From the RIR, you would have to pay RIR fees. From an ISP, you >> probably get it for free, yes. A-ha. But the ISP is this cellular operator. How long would it take me to persuade a cellular operator (which is not related to a vehicle manufacturer) to obtain so much address space as to give more than one /64 to a vehicle? And then to persuade all cellular operators in a certain country to do the same for all other vehicle? Talking to cellular operators I hear often this need to not give more than one 64 because of billing, and because of augmented security risks. > No. However, since you _CAN'T_ set up routing to ULA, I'm not sure > how that applies. In a sense yes and in another no. Certainly a ULA prefix unique per vehicle would not allow to set routing to them. (neither would it if that were a PI space). But a ULA in the vehicle in same space as a ULA in a separate infrastructure (not operator's), would allow to set up tunnelling, and query the services offered by that infrastructure. And yes, that would work with a PI space as well (instead of ULA). Also, a translating mechanism in the vehicle (from ULA prefix to the /64 publicly routable provided by the operator) would allow for this to work. This address translating mechanism may take various forms such as IPv6 NAT, NPT, and others which would allow network-layer reverse reachability. I am not proposing this mechanism here, but it would rely on the easiness to make up ULAs. >>> I do not at all buy your argument here. >> >> Ok, I need to learn how to do it, so well as to be able to teach >> somebody else who'd do it. I am only in the middle. > > I don't think that trying to influence IETF standards is the best > way to avoid an education. That is right. >>>> These two directions are actually head and tail of same snake: >>>> it bites its end, or otherwise put it's a chicken and egg >>>> problem: if the deployer sees the prototype works then it may >>>> request IPv6 addressing space from registry, but not before it >>>> sees it works. >>>> >>>> At this point I think this draft is good to say that ULAs are >>>> useful. Later on maybe less so. But right now that's >>>> reflecting real-world situation. >>>> >>> >>> So we disagree. It is not the first time and probably not the >>> last. >>> >>>> That's how I see it, and one's mileage may vary. >>>> >>>> But imposing to not do ULA is little reasonable for some test >>>> deployments. >>> >>> I did not say "don't do ULA". I said that the number of >>> situations where ULA is detrimental vastly outweighs the number >>> where it is useful. >>> >>> Your description above is one of the few cases where it might >>> not be detrimental. It is not, however, particularly useful vs. >>> PI or PA. >>> >>> As such, I think it is appropriate for the draft to make it >>> clear that use of ULA should be carefully considered as in most >>> cases it provides greater detriment. >> >> Also make it clear that any other alternative is not easy: it >> involves delays and money. > > I don't buy that argument. Getting it routed is going to cost you > money regardless of what space you use. In a sense yes, but one could plan for that, independently of any other organization. > If you use ISP provided space, you probably get the space for free. If this were ISP of 802.11p (WAVE) then yes, but these operators are in their very inceptive form these days. In a few years maybe yes. > If you use ULA, then you have to get space from the ISP, NAT the ULA, > and still pay the same money. Ok, again, this is a cellular operator, (not ADSL, not lab) which does give a /64 to an end user. I think it is very hard to persuade a cellular operator to give more than 1 64, not in the immediate future. 64share is there for this reason, no? > > If you want PI space so that you can move amongst different ISPs, > then, you will need to pay the RIR fees for the PI space, but these > are relatively minimal. If I get PI space from an organization, I doubt cellular operator will route it for me. So I end up with again a need to set an anchor somewhere else in the infrastructure. And, if I can do that, I can do it for an ULA as well. >>>> Alex PS: There are also some intermediary alternatives like >>>> IPv4 transitioning (6to4 and other tunnels), 64share. Each >>>> has some inconvenients (6to4 requires both IPv4 and IPv6 on >>>> cellular, whereas IPv6-only is easier with some operator; >>>> 64share only allows one subnet in vehicle). Also one would >>>> consider asking the cellular operator to implement DHCPv6 >>>> Prefix Delegation, which may also take time. >>> >>> I'm not sure how any of that relates to the ULA draft in >>> question. ULA certainly isn't useful in any of those scenarios. >> >> A vehicle holds a 'mobile router' which may act precisely the same >> as a smartphone and tethering when connecting on cellular. Except >> there are more subnets in a vehicle than the single subnet a user >> may carry. > > There are more subnets attached to cellular devices in the future, > too. I'm still not sure what any of this has to do with ULA. More subnets attached with a smartphone? I dont doubt the need exists, but 64share won't work there. >> Similar comparisons apply to 6to4 and DHCP Prefix Delegation - >> it's just like a smartphone. > > But what does that have to do with ULA? ULA is _NOT_ useful in any > of those cases. _If_ a smartphone can obtain more than one 64, with DHCP Prefix Delegation, then of course ULA is not needed, PI space is not needed, 64share is not needed. If a smartphone can not, then one of the above is needed. Among these: 64share does not work with multiple subnets, PI space requires time. Alex > > Owen > > > From nobody Sun Feb 16 12:26:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C4A1A0277 for ; Sun, 16 Feb 2014 12:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19rhkkOPmxOh for ; Sun, 16 Feb 2014 12:26:33 -0800 (PST) Received: from nm44.bullet.mail.ne1.yahoo.com (nm44.bullet.mail.ne1.yahoo.com [98.138.120.51]) by ietfa.amsl.com (Postfix) with SMTP id 571F61A0068 for ; Sun, 16 Feb 2014 12:26:33 -0800 (PST) Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2014 20:26:31 -0000 Received: from [98.138.100.117] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2014 20:26:10 -0000 Received: from [66.196.81.173] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2014 20:26:10 -0000 Received: from [98.139.212.221] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 16 Feb 2014 20:26:10 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 16 Feb 2014 20:26:10 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 679944.10078.bm@omp1030.mail.bf1.yahoo.com Received: (qmail 72939 invoked by uid 60001); 16 Feb 2014 20:26:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1392582370; bh=pwbOHLJ4IhOwoPengJVDNPH9mAzQqIlSqggHVMBNEI4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vag4dC1jWcqQE+ziDUdhX4MT8ijB1N59q0j5sAxV4cru0tbU1FMFHLX2zr523tn7sG1T5ijzuJMlsMMf6TtRDsM2qKzQcnsgnMZDChbWkoe1eO3sPKNzujWjFfeNIiSOtJe62hCrGlXvkepgtZEEzpKBUY67yAWwyih4c3W94qQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wwI3KpWMO8A/TuvErUjCRr+AdeHFp6q6DgNUk96sVAkE3rquWdqt0LnvQVrnU1M02CYu3k/hKkwvxIG2PFGHG2y3aNZTabrLUqlnHhQ4iawa9Tq/oZNdrNUWEjA451vWE90RdMpf/bQoLC5R4wTPIO336vionc2Y2GeLPipQ+5k=; X-YMail-OSG: xZWsM6AVM1lR9Ib_jvgdhDUMVi_BBaOqUjKQz.6v0dttNSE TKzZQd1W0aIpmLahsJguQSc7aZwIvix2Jbm7tXfMwTVrLmTH8jQ8moRKqVBK ZdTa.9q8p_9ldot_Rc5Vp4NE4TFYmtfLkXe4GsjZibW_0F7VF2G6VyQAwpcD VC9k6CQSzJtjMSXU1Q4Mw8ZABuSCpuJErTHB37vwaaZMe.S48lZDu47hv78b lDh7ZpAzuOZdeYCNJJPT2XsVS95H9zfbkelorKBFSd6ALiXBeljntI_9r084 kNlD9GJ8SRt4b9l5bLwSUoBgGMIhWA3yLu8XICwtvf6RieB0ZUkDwsiaHlDb m2NUBsAKBcPAi8lfaQdaM_._lVj4JIxBy4Z.aSzPQ28gWF7hUYL70eIyh1T2 HKlqZd2U9vqVC6_jnOmK1znxQr3vTR_0S75.CIX4ZDydHqVZBJqCNd5EdGfW X.DE13ofzZzO_Mwh9T7aO18EldeIxaj7xa_lHZRLnWtIUeA0.QYpGudNDH0w vFl5dRVoSVPO.rsogK3iEQKTAaRRu_BhCedueYTbrBEdMg9RTp6G31Gp59Rn 8oVd1jjyed0Py0XtEthcxjpXs4228JhY9I5hZpKzfopQTS7oW9dFV1T0lh8L 1dBBAPxp4lYRYOUBq09VBg6CPop3wRwPcoslt0goYz2RxLDgGjOpRIQ-- Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Sun, 16 Feb 2014 12:26:10 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.IFRvOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj4gQ2M6IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBNb25kYXksIDE3IEZlYnJ1YXJ5IDIwMTQgNjoxNiBBTQo.IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdWxhLXVzYWdlLXJlY29tbWUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> Message-ID: <1392582370.90081.YahooMailNeo@web162206.mail.bf1.yahoo.com> Date: Sun, 16 Feb 2014 12:26:10 -0800 (PST) From: Mark ZZZ Smith To: Brian E Carpenter , Alexandru Petrescu In-Reply-To: <53010E70.5000401@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UYzoKxxecivYuYsZVY3D2T--vZg Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 20:26:35 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Brian E Carpenter =0A> To: Alexandru Petrescu =0A> Cc: V6 Ops List =0A> Sent: Monday, 17 February 2= 014 6:16 AM=0A> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage= -recommendations-02.txt=0A> =0A>>>>=A0 Le 15/02/2014 19:16, Owen DeLong a = =E9crit :=0A>>>>>=A0 Indeed, the situations where ULA usage is detrimental = vastly=0A>>>>>=A0 outnumbers those where it is actually beneficial.=0A> =0A= > That's an opinion, but it isn't an argument for abolishing=0A> ULAs. It's= actually an argument for improving this draft so=0A> that it describes the= cases in which ULAs are beneficial.=0A> Could we have a detailed conversat= ion about whether those cases=0A> are correctly described in the draft?=0A= =0A>=A0=0A=0A+1=0A=0AA big drawback of Owen's global only model is that it = creates further disincentive to deploy IPv6, because to do so requires a co= mmercial arrangement with an IPv6 address provider and annual fees, in addi= tion to the costs of the equipment that can talk IPv6.=0A=0AIt would in eff= ect create an annual licencing fee for the use of IPv6 addresses and techno= logy. I don't know if that has been tried before, however for the popular l= ayer 3 protocols of the past, there has never been a mandatory fee for usin= g addresses. Their low or absent technology use costs are probably one of t= he reasons why they've been popular.=0A=0AThese annual IPv6 address use fee= s may make charitable projects which use donated networking equipment infea= sible, such as this sort of project - http://villagetelco.org/about/=A0- wh= en IPv6 might be better to use than IPv4.=0A=0A=0A=0ARegards,=0AMark. From nobody Sun Feb 16 12:50:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B6C1A02E7 for ; Sun, 16 Feb 2014 12:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkmDL6Zh_YFH for ; Sun, 16 Feb 2014 12:50:37 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A61A02A0 for ; Sun, 16 Feb 2014 12:50:36 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 974B21B817E for ; Sun, 16 Feb 2014 12:50:34 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5564D190052; Sun, 16 Feb 2014 12:50:34 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 16 Feb 2014 12:50:34 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Sun, 16 Feb 2014 15:50:29 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> To: Owen DeLong X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CDfFbYvUpSMUKGBNnmfykzMqwb0 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 20:50:38 -0000 On Feb 16, 2014, at 1:22 PM, Owen DeLong wrote: > I did not say "don't do ULA". I said that the number of situations = where ULA is detrimental vastly outweighs the number where it is useful. Can you give an example of a case where ULAs are detrimental? From nobody Sun Feb 16 13:47:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26231A02C4 for ; Sun, 16 Feb 2014 13:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOxrgjCzcGTl for ; Sun, 16 Feb 2014 13:47:44 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3F21B1A0045 for ; Sun, 16 Feb 2014 13:47:44 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so14037871pdj.17 for ; Sun, 16 Feb 2014 13:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QaraDF+r+n/1qJrYGkTAy+6JCsr/ANQGTkxlOLWmHQ8=; b=jFvGguSM4BMabgFEik0V1lnQ8AQLZ7VjoCBROLyGa405h2ug1WlmcJPpuYmeomzAiy hW7qkkakZxC8uav0IVPqSG9SF5LSRP8u70Vgaf/F/Sicq703X4spPqTdiFIolRZiioW+ s0D9nvnjfzvnsbHNKYYLXMOjWEy/qgCZvn/7y7bwhqxqrJp5vD0S0wn7VFUPy92LRiG2 fRg2mNknjFNn1v3Yw2FlOIb/ufP//zfrbPYZU1/5SLpP7ACXPGKx+rNcn/BJb65gxutZ FDDTbZj2vWB7eFoAejwEVX94gvTB9NkfdEq+T+OWtvk+GJ34EOr9Youl9d44OKq4bBJr i9cQ== X-Received: by 10.68.229.164 with SMTP id sr4mr22427230pbc.82.1392587260603; Sun, 16 Feb 2014 13:47:40 -0800 (PST) Received: from [192.168.178.23] (22.200.69.111.dynamic.snap.net.nz. [111.69.200.22]) by mx.google.com with ESMTPSA id db3sm38976743pbb.10.2014.02.16.13.47.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 13:47:39 -0800 (PST) Message-ID: <530131FA.4010909@gmail.com> Date: Mon, 17 Feb 2014 10:47:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <0E7988A4-4C34-42B7-9151-4120B12E7869@delong.com> <53011C7D.50109@gmail.com> In-Reply-To: <53011C7D.50109@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/1VwJ9ZwdvdEdE2C7-mWDSc-SUHw Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:47:45 -0000 On 17/02/2014 09:15, Alexandru Petrescu wrote: ... > Also, a translating mechanism in the vehicle (from ULA prefix to the /64 > publicly routable provided by the operator) would allow for this to > work. This address translating mechanism may take various forms such as > IPv6 NAT, NPT, and others which would allow network-layer reverse > reachability. I am not proposing this mechanism here, but it would rely > on the easiness to make up ULAs. That's exactly the use case we should be trying to block IMHO. An operator that only provides a single /64 shouldn't be used for any scenario, such as a vehicle, that needs subnets. Brian From nobody Sun Feb 16 17:45:25 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858C61A02C3; Sun, 16 Feb 2014 17:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuEMRZqa3InQ; Sun, 16 Feb 2014 17:45:20 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E11A020F; Sun, 16 Feb 2014 17:45:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFDGj-0000Vu-7k; Mon, 17 Feb 2014 01:45:14 +0000 Date: Mon, 17 Feb 2014 09:45:07 +0800 Message-ID: From: Randy Bush To: Peng Fan In-Reply-To: <006801cf2b34$22837cd0$678a7670$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> User-Agent: Wanderlust/2.15.9nreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/82fRNo2Y3zLLAErvoyT5FgJEbOk Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 01:45:21 -0000 > Thanks for the discussion and sorry for the late. Assigning an id is not a > difficult issue, especially on a single router. But what number is to be > assigned might be an issue, especially in an ISP's large network, in order > to guarantee the uniqueness of the ids. as i said, if you can not assign unique 32 bit integers to your routers, you have far bigger problems in your organization and network. and having them be 128 bit integers is not going to solve your problems. randy From nobody Sun Feb 16 18:51:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089971A0313; Sun, 16 Feb 2014 18:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 99FicC5pLZpA; Sun, 16 Feb 2014 18:51:38 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 080201A02FD; Sun, 16 Feb 2014 18:51:37 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2530178ae654-3a654; Mon, 17 Feb 2014 10:49:19 +0800 (CST) X-RM-TRANSID: 2ee2530178ae654-3a654 Received: from X6X8D79D8F49E2 (unknown[10.2.52.196]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3530178adfff-c0980; Mon, 17 Feb 2014 10:49:19 +0800 (CST) X-RM-TRANSID: 2ee3530178adfff-c0980 From: "Fan, Peng" To: "'Randy Bush'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> In-Reply-To: Date: Mon, 17 Feb 2014 10:51:26 +0800 Message-ID: <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaJkL6d1g Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/VK3DQ6n2pek24jvIT7E--ITKAVc Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 02:51:41 -0000 Hi Randy, Just to clarify. I am not complaining we cannot assign the unique integers, but the integers require additional planning, and that from operational perspective causes inconvenience. Following the experience in ipv4 enabled network would be a natural thought, especially when you want the IDs to be helpful in troubleshooting rather than just pure numbers. Peng > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 17, 2014 9:45 AM > To: Peng Fan > Cc: idr wg; V6 Ops List > Subject: Re: [Idr] [v6ops] BGP Identifier > > > Thanks for the discussion and sorry for the late. Assigning an id is > > not a difficult issue, especially on a single router. But what number > > is to be assigned might be an issue, especially in an ISP's large > > network, in order to guarantee the uniqueness of the ids. > > as i said, if you can not assign unique 32 bit integers to your routers, you have far > bigger problems in your organization and network. and having them be 128 bit > integers is not going to solve your problems. > > randy From nobody Mon Feb 17 00:01:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1558C1A044D for ; Mon, 17 Feb 2014 00:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSlh-9JNX0jp for ; Mon, 17 Feb 2014 00:01:27 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id C0FB31A0065 for ; Mon, 17 Feb 2014 00:01:27 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 7CD38300081 for ; Mon, 17 Feb 2014 08:01:25 +0000 (UTC) Received: from [10.0.1.5] (c-67-188-218-56.hsd1.ca.comcast.net [67.188.218.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id C5AB730007B; Mon, 17 Feb 2014 01:01:23 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> Date: Sun, 16 Feb 2014 21:39:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1DE461CB-84D5-4D69-9825-C2134E08EA67@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Feb 17 01:01:25 2014 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5301c1d542076859815077 X-DSPAM-Factors: 27, Mime-Version*OS+X, 0.01000, Mime-Version*X+#+#+1827, 0.01000, Cc*List+#+ietf.org, 0.01000, From*Amante+shane, 0.01000, Cc*List+v6ops, 0.01000, Cc*idr+wg, 0.01000, Subject*v6ops+BGP, 0.01000, Cc*Ops+#+v6ops, 0.01000, Mime-Version*OS+#+#+7.1, 0.01000, Cc*idr+ietf.org, 0.01000, Mime-Version*Mac+#+#+#+7.1, 0.01000, Cc*wg+#+ietf.org, 0.01000, Cc*V6+#+#+#+ietf.org, 0.01000, On+#+#+2014, 0.01000, Cc*Ops+List, 0.01000, Subject*BGP+Identifier, 0.01000, Cc*idr+#+#+ietf.org, 0.01000, Cc*V6+#+#+v6ops, 0.01000, Mime-Version*7.1+1827, 0.01000, Cc*V6+Ops, 0.01000, Mime-Version*1.0+Mac, 0.01000, From*Shane+#+shane, 0.01000, Cc*Ops+#+#+ietf.org, 0.01000, Cc*idr+#+idr, 0.01000, From*Shane Amante , 0.01000, 2014+at, 0.01000, Mime-Version*Mail+7.1, 0.01000 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aEeCtR4hE4p9EusReM3A6FaGekw Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 08:01:29 -0000 Hi David, On Feb 15, 2014, at 11:25 AM, David Farmer wrote: > So, I'd prefer effort be put toward an informational draft suggesting = operational practices and maybe implementation suggestions that = reinforce these suggestions rather than complicated protocol changes. =20= I agree and would be willing to help draft text and/or review such a = draft. -shane= From nobody Mon Feb 17 01:25:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDD91A045B; Mon, 17 Feb 2014 01:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVJp94NiWsDM; Mon, 17 Feb 2014 01:24:56 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7911A03A6; Mon, 17 Feb 2014 01:24:56 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hr17so10884731lab.20 for ; Mon, 17 Feb 2014 01:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yyEj7d47DDcyide0T1UhIFvCBHPW20RF9QCadId4EBs=; b=dy+hZvxJ13JF81yMwTGHNd/SbI/jPR8tmiForHDgcSDvOes/fH7ZlK9zmPRdQen5xa fhv7HEirlo67Q41Cd9foMqahQzuq4Nqq9Nft+f6J4Be00eW/stZRtj94OuesAK3Ws3W+ loM6ea/0yxMVzJyZdFYeind7ovAYnVbLoazC1OmCni57ALmWqPQWEdHk2G2OjBkMcWN7 PszjVAyEwVYLaHFrhrNxuOEbLoDiZTM+JSQVAGPYS25SXJNPO+rC7ADHPJyxzuFF7vxw 6slxLDUqbLOzdn58YCtwDpfycmHE2CTUh1C1yJb1ISQ8CGOeKSibyOCnTtIKMOL+bn4F CuKw== MIME-Version: 1.0 X-Received: by 10.152.27.133 with SMTP id t5mr130498lag.66.1392629093052; Mon, 17 Feb 2014 01:24:53 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.51.105 with HTTP; Mon, 17 Feb 2014 01:24:52 -0800 (PST) In-Reply-To: <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> Date: Mon, 17 Feb 2014 10:24:52 +0100 X-Google-Sender-Auth: _ozdho1IxeT31fW6UvE8HoRaWBU Message-ID: From: Robert Raszuk To: "Fan, Peng" Content-Type: multipart/alternative; boundary=089e0160c2ce6536da04f296ba65 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J0C2OO9s25uOT5sNTk1Oz6uLaLM Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 09:24:59 -0000 --089e0160c2ce6536da04f296ba65 Content-Type: text/plain; charset=ISO-8859-1 Hi Peng, Can't you just use ::a.b.c.d/96 for ping and troubleshooting 4 octet router_id in IPv6 only network? No protocol changes needed :) r. On Mon, Feb 17, 2014 at 3:51 AM, Fan, Peng wrote: > Hi Randy, > > Just to clarify. I am not complaining we cannot assign the unique integers, > but the integers require additional planning, and that from operational > perspective causes inconvenience. Following the experience in ipv4 enabled > network would be a natural thought, especially when you want the IDs to be > helpful in troubleshooting rather than just pure numbers. > > Peng > > > -----Original Message----- > > From: Randy Bush [mailto:randy@psg.com] > > Sent: Monday, February 17, 2014 9:45 AM > > To: Peng Fan > > Cc: idr wg; V6 Ops List > > Subject: Re: [Idr] [v6ops] BGP Identifier > > > > > Thanks for the discussion and sorry for the late. Assigning an id is > > > not a difficult issue, especially on a single router. But what number > > > is to be assigned might be an issue, especially in an ISP's large > > > network, in order to guarantee the uniqueness of the ids. > > > > as i said, if you can not assign unique 32 bit integers to your routers, > you have far > > bigger problems in your organization and network. and having them be 128 > bit > > integers is not going to solve your problems. > > > > randy > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --089e0160c2ce6536da04f296ba65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Peng,

= Can't you just use=A0::a.= b.c.d/96 for ping and troubleshooting 4 octet router_id in IPv6 only networ= k?=A0

No protocol changes needed :)=

r.


On Mon,= Feb 17, 2014 at 3:51 AM, Fan, Peng <fanpeng@chinamobile.com>= wrote:
Hi Randy,

Just to clarify. I am not complaining we cannot assign the unique integers,=
but the integers require additional planning, and that from operational
perspective causes inconvenience. Following the experience in ipv4 enabled<= br> network would be a natural thought, especially when you want the IDs to be<= br> helpful in troubleshooting rather than just pure numbers.

Peng

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.co= m]
> Sent: Monday, February 17, 2014 9:45 AM
> To: Peng Fan
> Cc: idr wg; V6 Ops List
> Subject: Re: [Idr] [v6ops] BGP Identifier
>
> > Thanks for the disc= ussion and sorry for the late. Assigning an id is
> > not a difficult issue, especially on a single router. But what nu= mber
> > is to be assigned might be an issue, especially in an ISP's l= arge
> > network, in order to guarantee the uniqueness of the ids.
>
> as i said, if you can not assign unique 32 bit integers to your router= s,
you have far
> bigger problems in your organization and network. =A0and having them b= e 128
bit
> integers is not going to solve your problems.
>
> randy



_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--089e0160c2ce6536da04f296ba65-- From nobody Mon Feb 17 01:48:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88D01A042C for ; Mon, 17 Feb 2014 01:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, 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 zq_r6hF6kh9i for ; Mon, 17 Feb 2014 01:48:54 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E85DE1A0392 for ; Mon, 17 Feb 2014 01:48:53 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 97A4EA2; Mon, 17 Feb 2014 10:48:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 907EB9C; Mon, 17 Feb 2014 10:48:46 +0100 (CET) Date: Mon, 17 Feb 2014 10:48:46 +0100 (CET) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: Message-ID: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@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; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TY4ItNnscVRQPydG65gc6mvg0J0 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:48:58 -0000 On Sun, 16 Feb 2014, Ted Lemon wrote: > On Feb 16, 2014, at 1:22 PM, Owen DeLong wrote: >> I did not say "don't do ULA". I said that the number of situations where ULA is detrimental vastly outweighs the number where it is useful. > > Can you give an example of a case where ULAs are detrimental? RFC3484 device with IPv4 connectivity but not IPv6 Internet connectivity. It will then try to use its ULA address to reach Internet addresses using IPv6. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Feb 17 02:10:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639D71A03C3; Mon, 17 Feb 2014 02:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 8CBR8jAa_Ir1; Mon, 17 Feb 2014 02:10:28 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id BF80B1A03AE; Mon, 17 Feb 2014 02:10:27 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15301df8a7cc-e37cc; Mon, 17 Feb 2014 18:08:10 +0800 (CST) X-RM-TRANSID: 2ee15301df8a7cc-e37cc Received: from X6X8D79D8F49E2 (unknown[10.2.52.196]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35301df89908-c9e11; Mon, 17 Feb 2014 18:08:10 +0800 (CST) X-RM-TRANSID: 2ee35301df89908-c9e11 From: "Fan, Peng" To: "'Robert Raszuk'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> In-Reply-To: Date: Mon, 17 Feb 2014 18:10:57 +0800 Message-ID: <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01CF2C0B.9B400440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaAGHMZlXAkZuM4GY7fbMQA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/val2UeY16Ru88Kep7Dzx0Dfekms Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 10:10:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0025_01CF2C0B.9B400440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Robert, Yes that is a possible solution for troubleshooting, once the router_id has been determined. But how do you determine at first the value of a.b.c.d when there is no ipv4 address to be referred to, especially in an automatic manner? Beforehand planning work for the ids for the entire network is something I am concerned with :) Regards, Peng From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk Sent: Monday, February 17, 2014 5:25 PM To: Fan, Peng Cc: Randy Bush; idr wg; V6 Ops List Subject: Re: [Idr] [v6ops] BGP Identifier Hi Peng, Can't you just use ::a.b.c.d/96 for ping and troubleshooting 4 octet router_id in IPv6 only network? No protocol changes needed :) r. On Mon, Feb 17, 2014 at 3:51 AM, Fan, Peng wrote: Hi Randy, Just to clarify. I am not complaining we cannot assign the unique integers, but the integers require additional planning, and that from operational perspective causes inconvenience. Following the experience in ipv4 enabled network would be a natural thought, especially when you want the IDs to be helpful in troubleshooting rather than just pure numbers. Peng > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 17, 2014 9:45 AM > To: Peng Fan > Cc: idr wg; V6 Ops List > Subject: Re: [Idr] [v6ops] BGP Identifier > > > Thanks for the discussion and sorry for the late. Assigning an id is > > not a difficult issue, especially on a single router. But what number > > is to be assigned might be an issue, especially in an ISP's large > > network, in order to guarantee the uniqueness of the ids. > > as i said, if you can not assign unique 32 bit integers to your routers, you have far > bigger problems in your organization and network. and having them be 128 bit > integers is not going to solve your problems. > > randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0025_01CF2C0B.9B400440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,

 

Yes that is a possible solution for troubleshooting, once the = router_id has been determined. But how do you determine at first the = value of a.b.c.d when there is no ipv4 address to be referred to, = especially in an automatic manner? Beforehand planning work for the ids = for the entire network is something I am concerned with = :)

 

Regards,

Peng

 

From:= = rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert = Raszuk
Sent: Monday, February 17, 2014 5:25 PM
To: = Fan, Peng
Cc: Randy Bush; idr wg; V6 Ops = List
Subject: Re: [Idr] [v6ops] BGP = Identifier

 

Hi Peng,

 

Can't you just use ::a.b.c.d/96 for ping and troubleshooting 4 octet = router_id in IPv6 only network? 

 

No protocol changes needed = :)

 

r.

 

On Mon, Feb 17, 2014 at 3:51 AM, Fan, Peng <fanpeng@chinamobile.com> = wrote:

Hi = Randy,

Just to clarify. I am not complaining we cannot assign the = unique integers,
but the integers require additional planning, and = that from operational
perspective causes inconvenience. Following the = experience in ipv4 enabled
network would be a natural thought, = especially when you want the IDs to be
helpful in troubleshooting = rather than just pure numbers.

Peng


> -----Original = Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Monday, = February 17, 2014 9:45 AM
> To: Peng Fan
> Cc: idr wg; V6 = Ops List
> Subject: Re: [Idr] [v6ops] BGP = Identifier
>

> > Thanks for the discussion = and sorry for the late. Assigning an id is
> > not a difficult = issue, especially on a single router. But what number
> > is to = be assigned might be an issue, especially in an ISP's large
> > = network, in order to guarantee the uniqueness of the = ids.
>
> as i said, if you can not assign unique 32 bit = integers to your routers,
you have far
> bigger problems in = your organization and network.  and having them be = 128
bit
> integers is not going to solve your = problems.
>
> = randy



_______________________________________________
I= dr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------=_NextPart_000_0025_01CF2C0B.9B400440-- From nobody Mon Feb 17 02:13:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CEA1A0477 for ; Mon, 17 Feb 2014 02:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 221fdNNcf3bv for ; Mon, 17 Feb 2014 02:13:25 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4931A03C7 for ; Mon, 17 Feb 2014 02:13:25 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CE10162EE1 for ; Mon, 17 Feb 2014 11:13:21 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A2C8962EDF for ; Mon, 17 Feb 2014 11:13:21 +0100 (CET) Received: (qmail 24575 invoked by uid 1007); 17 Feb 2014 11:13:21 +0100 Date: Mon, 17 Feb 2014 11:13:21 +0100 From: Gert Doering To: "Fan, Peng" Message-ID: <20140217101321.GI75390@Space.Net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lNTvbQVhk_7VDNheSHyc2IF5mLQ Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 10:13:27 -0000 Hi, On Mon, Feb 17, 2014 at 06:10:57PM +0800, Fan, Peng wrote: > Yes that is a possible solution for troubleshooting, once the router_id has > been determined. But how do you determine at first the value of a.b.c.d when > there is no ipv4 address to be referred to, especially in an automatic > manner? Beforehand planning work for the ids for the entire network is > something I am concerned with :) How do you plan transit network and loopback IP assignment? See, it's quite doable. (Assign loopback addresses in a way that you can use the last 32 bits as router ID, done) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 17 02:25:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0C21A03C3; Mon, 17 Feb 2014 02:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJojVpsLArH4; Mon, 17 Feb 2014 02:25:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id BB78F1A00DD; Mon, 17 Feb 2014 02:25:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFLOQ-00024C-SU; Mon, 17 Feb 2014 10:25:43 +0000 Date: Mon, 17 Feb 2014 18:25:40 +0800 Message-ID: From: Randy Bush To: "Fan, Peng" In-Reply-To: <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LKQxMYwgG2GeE_JbtV1rUzNLGO4 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 10:25:50 -0000 > Yes that is a possible solution for troubleshooting, once the router_id has > been determined. But how do you determine at first the value of a.b.c.d when > there is no ipv4 address to be referred to, especially in an automatic > manner? Beforehand planning work for the ids for the entire network is > something I am concerned with :) all your comments are symptoms of the insanity of trying to configure a large network manually. this went out of fashion in the last century, and we do not try to compensate for insanity through protocol modification. randy From nobody Mon Feb 17 03:00:21 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0843D1A010C for ; Mon, 17 Feb 2014 03:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gGR5pT7oWqla for ; Mon, 17 Feb 2014 03:00:19 -0800 (PST) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id DF6EE1A011E for ; Mon, 17 Feb 2014 03:00:18 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id b57so7033789eek.38 for ; Mon, 17 Feb 2014 03:00:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=p+TpS5Rkl55pxJXd0etePjpv8cTN5mWeriiAkqMOd7E=; b=T20xTG+FalA5UKuKQacGRpNtOFICENAZshzGF4tWIEwCSq0iUYC1PGF+lyNN+wQTDX N1E+jV4N7Aoryo67Dx55NwmyDHRMUgA4Ufw3ExDF1yDhXhKKs+dTi9TO2kbbUMHjXtX8 TRa4IQk5JhVDbXCGCOwtQrZJ8y7Hj2ItQllmi3aEMyDzqeBSrVp64d37eX5fUpO2BkCf EIeiNTo8e77kYtrgdIRHMtt77rBAstdyYuCmJGA79Ez+/t7Sa6GJ7eTd/S+Rk7CpgwZK 9qxJF0WyG+ARA2yAVMjZWGgs6HHV3fQai82lMlYBEJhcPFKYX7m2hD5kJpTBl8h1T06a H21w== X-Gm-Message-State: ALoCoQlSwcG0H705SfcJiNCnPva5i3Db7kAQZdyn5AMFxtpphNeUDoWVSzHzFtNL91gL3o4KxRbH X-Received: by 10.15.42.72 with SMTP id t48mr26930736eev.45.1392634815634; Mon, 17 Feb 2014 03:00:15 -0800 (PST) Received: from localhost ([81.167.37.170]) by mx.google.com with ESMTPSA id x2sm56010763eeo.8.2014.02.17.03.00.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Feb 2014 03:00:14 -0800 (PST) Date: Mon, 17 Feb 2014 12:00:13 +0100 From: Jan-Frode Myklebust To: Brian E Carpenter Message-ID: <20140217110013.GA31822@mushkin> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53010E70.5000401@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tOY4uEDWX_phQglQjJ9R57SvlK4 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:00:21 -0000 On Mon, Feb 17, 2014 at 08:16:00AM +1300, Brian E Carpenter wrote: > >>> Le 15/02/2014 19:16, Owen DeLong a écrit : > >>>> Indeed, the situations where ULA usage is detrimental vastly > >>>> outnumbers those where it is actually beneficial. > > That's an opinion, but it isn't an argument for abolishing > ULAs. It's actually an argument for improving this draft so > that it describes the cases in which ULAs are beneficial. > Could we have a detailed conversation about whether those cases > are correctly described in the draft? Yes please. My use case is that we have a set of datacenter internal services/servers that should *never* be routed out. When not using ULA we've had a couple of incidents where the routes did leak out and servers that shouldn't have been available on the Internet was. So we've decided to use ULA for the same set of servers as we previously used rfc1918-adresses for. No NAT involved. No servers should reach Internet directly. Yes we could achieve the same by putting proper ACLs in place on the borders, but since we've failed to do that in the past, the belt and suspenders approach is attractive. Is this a "valid" ULA usage? -jf From nobody Mon Feb 17 04:13:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8601A04BA for ; Mon, 17 Feb 2014 04:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS-LY8QHHKrX for ; Mon, 17 Feb 2014 04:13:26 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 714111A04B7 for ; Mon, 17 Feb 2014 04:13:25 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 5360F62EEA for ; Mon, 17 Feb 2014 13:13:22 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1F12962EDE for ; Mon, 17 Feb 2014 13:13:22 +0100 (CET) Received: (qmail 93696 invoked by uid 1007); 17 Feb 2014 13:13:22 +0100 Date: Mon, 17 Feb 2014 13:13:22 +0100 From: Gert Doering To: Jan-Frode Myklebust Message-ID: <20140217121322.GK75390@Space.Net> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140217110013.GA31822@mushkin> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/4nWpEdss0i7hIQYhTN7r_OnMW44 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 12:13:28 -0000 Hi, On Mon, Feb 17, 2014 at 12:00:13PM +0100, Jan-Frode Myklebust wrote: > Is this a "valid" ULA usage? I'd say so. Some of our network management stuff is done via ULAs, as it will ensure that machines will only be able to communicate with exactly our network, and nobody else. (There are ACLs in addition to that, before someone starts shouting at me) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 17 05:47:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEEF1A04E1 for ; Mon, 17 Feb 2014 05:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU-TYtZ7429X for ; Mon, 17 Feb 2014 05:47:19 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E15291A03E1 for ; Mon, 17 Feb 2014 05:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392644837; x=1393854437; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=HYNBlTc9bYw84+weF6miPHUY30rW0jRWvuC2ikcjBaQsZdOfhfKXEOf0 I+tAXFyr0MLH0nj+v7zdp26s2H/41vGeM3zY1I4HjSqSZXCYedfsMz28W AkE6KQyJl0IgbMeRIkd2xiZgal9t4zm1XTuNxCQGTK3gbd5aFXTS9t353 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkLACwSAlOrRDoI/2dsb2JhbABZgwY4qy4BlFcDBAKBHhZ0gyU8NIhlDstXF48BHYQiBIlIkBaQcYNO X-IronPort-AV: E=Sophos;i="4.95,860,1384300800"; d="scan'208";a="106090148" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 17 Feb 2014 13:45:15 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1HDjFNI031428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 13:45:15 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s1HDjEir020827; Mon, 17 Feb 2014 05:45:14 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s1HDjEmv020800; Mon, 17 Feb 2014 05:45:14 -0800 (PST) Date: Mon, 17 Feb 2014 05:45:14 -0800 (PST) From: Fred Baker Message-Id: <201402171345.s1HDjEmv020800@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UQcdPPIl4YGyVnGCKeX2jL7HEMY Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:47:22 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Mon Feb 17 05:47:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D4B1A03E1 for ; Mon, 17 Feb 2014 05:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWJZd4k_BzgG for ; Mon, 17 Feb 2014 05:47:20 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6A1A04CB for ; Mon, 17 Feb 2014 05:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392644837; x=1393854437; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=X7+ZuzIhWMevYihcBA2AT7s0IgmLp9/UBq+8Mz6IEucaI1pG+v4R++BS J+4cuMXqcOvr9m7RuMHTgvzivkzZLYq/J4DdWPjmG56XxZFvB5vH/J+fv iSCS8oMWnrStR4LlROliScZWzDemdRBDt5kDIgCqMuv0P29tR/nfXrkh0 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkLACwSAlOrRDoI/2dsb2JhbABZgwY4qy4BlFcDBAKBHhZ0gyU8LQeIZQ7LVxePAR2EIgSJSJAWkHGDTg X-IronPort-AV: E=Sophos;i="4.95,860,1384300800"; d="scan'208";a="106090162" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 17 Feb 2014 13:45:16 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1HDjGCv031461; Mon, 17 Feb 2014 13:45:16 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1HDjGa25983; Mon, 17 Feb 2014 05:45:16 -0800 (PST) Date: Mon, 17 Feb 2014 05:45:16 -0800 (PST) From: Message-Id: <201402171345.s1HDjGa25983@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hFpXmefPEhFCwT5mxR-t60fXleQ Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:47:22 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Mon Feb 17 06:02:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E141A03DC for ; Mon, 17 Feb 2014 06:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 u89aX_UImtzl for ; Mon, 17 Feb 2014 06:02:14 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CEC831A04CB for ; Mon, 17 Feb 2014 06:02:14 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A8EC1C9492; Mon, 17 Feb 2014 14:01:59 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1392645732; bh=CziWbgtKQ2UGeiV0B3m3w20hixMxE6ZVSXw+CYDLulU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=sfN1oKC6qoCcDIvxSXj8nZ6APQueKHTXxfxmMONB+cQpwSJnwIam+L86RQyUkFWnG oMEyMVB9dCctjQJn0qP9um+nJGO/DPop1mNj6Ehrwqq6ebxlKRGKaPsCY+RDj+Ngzu DCBwkomGH24ULWiNbW5gy1BeDMveAbiML2wf0xp0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 17 Feb 2014 14:01:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8973B160059; Mon, 17 Feb 2014 14:02:46 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5740B160052; Mon, 17 Feb 2014 14:02:46 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id D7B8CF79F6F; Tue, 18 Feb 2014 01:01:56 +1100 (EST) To: Mikael Abrahamsson From: Mark Andrews References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> In-reply-to: Your message of "Mon, 17 Feb 2014 10:48:46 +0100." Date: Tue, 18 Feb 2014 01:01:56 +1100 Message-Id: <20140217140156.D7B8CF79F6F@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/TMuJVoHQj8imgxvRyLkfBA3d9Vo Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:02:16 -0000 In message , Mikael Abrah amsson writes: > On Sun, 16 Feb 2014, Ted Lemon wrote: > > > On Feb 16, 2014, at 1:22 PM, Owen DeLong wrote: > >> I did not say "don't do ULA". I said that the number of situations where U > LA is detrimental vastly outweighs the number where it is useful. > > > > Can you give an example of a case where ULAs are detrimental? > > RFC3484 device with IPv4 connectivity but not IPv6 Internet connectivity. > It will then try to use its ULA address to reach Internet addresses using > IPv6. And it will still work pretty well. Longest match selects the right IPv6 address when you have GUA most of the time. If it doesn't the ICMPv6 admin prohibited message should cause the app to fall over to IPv4 as will HE apps or any well written multi-homed client. Mark > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Feb 17 06:16:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C51A04E6; Mon, 17 Feb 2014 06:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 Zjh76SfcEl3H; Mon, 17 Feb 2014 06:15:56 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id CBF551A04FB; Mon, 17 Feb 2014 06:15:54 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25302190dee3-45ee3; Mon, 17 Feb 2014 22:13:34 +0800 (CST) X-RM-TRANSID: 2ee25302190dee3-45ee3 Received: from X6X8D79D8F49E2 (unknown[125.97.45.50]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15302190c128-0b7cb; Mon, 17 Feb 2014 22:13:34 +0800 (CST) X-RM-TRANSID: 2ee15302190c128-0b7cb From: "Fan, Peng" To: "'Gert Doering'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <20140217101321.GI75390@Space.Net> In-Reply-To: <20140217101321.GI75390@Space.Net> Date: Mon, 17 Feb 2014 22:16:00 +0800 Message-ID: <009701cf2bea$c939be20$5bad3a60$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaAGHMZlXAkZuM4ECPpt9WQLDsJzGmMYV8zA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Uw1drKhYmlf1ilLd27JF56AjFkQ Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 14:15:59 -0000 Hi Gert, I see your point. We use a hierarchy in operating a large network, for example the headquarter assigns an address block to a province, and the province assigns a sub-block to a city, and administrators in the city assigns an address to a router. We cannot require an admin to assign an address with a unique id as they don't know what others use for ids. Operating the entire network by a single person would be easy but we can rarely see this case. Peng > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, February 17, 2014 6:13 PM > To: Fan, Peng > Cc: 'Robert Raszuk'; 'idr wg'; 'V6 Ops List' > Subject: Re: [v6ops] [Idr] BGP Identifier > > Hi, > > On Mon, Feb 17, 2014 at 06:10:57PM +0800, Fan, Peng wrote: > > Yes that is a possible solution for troubleshooting, once the > > router_id has been determined. But how do you determine at first the > > value of a.b.c.d when there is no ipv4 address to be referred to, > > especially in an automatic manner? Beforehand planning work for the > > ids for the entire network is something I am concerned with :) > > How do you plan transit network and loopback IP assignment? > > See, it's quite doable. > > (Assign loopback addresses in a way that you can use the last 32 bits as router ID, > done) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Feb 17 06:16:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B451A0503; Mon, 17 Feb 2014 06:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 1E8N2MqsIabO; Mon, 17 Feb 2014 06:15:58 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id CF39F1A04FF; Mon, 17 Feb 2014 06:15:54 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee253021913eea-45eea; Mon, 17 Feb 2014 22:13:40 +0800 (CST) X-RM-TRANSID: 2ee253021913eea-45eea Received: from X6X8D79D8F49E2 (unknown[125.97.45.50]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302191057b-ce04c; Mon, 17 Feb 2014 22:13:40 +0800 (CST) X-RM-TRANSID: 2ee35302191057b-ce04c From: "Fan, Peng" To: "'Randy Bush'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> In-Reply-To: Date: Mon, 17 Feb 2014 22:16:07 +0800 Message-ID: <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+AobGL2AB8SVRaAGHMZlXAkZuM4ECPpt9WQLwciK2mMS/IJA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FmSsznuTUfEF4fWLDQPl-PdCJAA Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 14:16:05 -0000 Randy, Would you please give me an example about how modern large ISPs manage their networks? > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Monday, February 17, 2014 6:26 PM > To: Fan, Peng > Cc: 'Robert Raszuk'; 'idr wg'; 'V6 Ops List' > Subject: Re: [Idr] [v6ops] BGP Identifier > > > Yes that is a possible solution for troubleshooting, once the > > router_id has been determined. But how do you determine at first the > > value of a.b.c.d when there is no ipv4 address to be referred to, > > especially in an automatic manner? Beforehand planning work for the > > ids for the entire network is something I am concerned with :) > > all your comments are symptoms of the insanity of trying to configure a large > network manually. this went out of fashion in the last century, and we do not > try to compensate for insanity through protocol modification. > > randy From nobody Mon Feb 17 06:38:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F581A04DC for ; Mon, 17 Feb 2014 06:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 2pkNRFUFCf-q for ; Mon, 17 Feb 2014 06:38:06 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDF21A04D6 for ; Mon, 17 Feb 2014 06:38:05 -0800 (PST) Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1HEZMOt007375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 06:35:23 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1HEZMOt007375 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392647723; bh=PCEFPiRJLAu6aTQdaXmu59g+70U=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Gbol9sl9m8xWH9mVsy8VXXTuwJp3n6pOmCErCBU9Y0JuTiV3swvZWDhkQplO+Dd39 mS7TucqEMqujE5tS+HgIoHV5DVp5ENvr91javZeXYAEL/lW+gGqYI+lRlHFCFTGVp0 CaDcWKIGYWfx6VuMURTfZXx2W46RMA+kfs1QLNpg= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <20140217110013.GA31822@mushkin> Date: Mon, 17 Feb 2014 06:35:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> To: Jan-Frode Myklebust X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Mon, 17 Feb 2014 06:35:23 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/QfNS20MbDtoAM57w4VEJuiApEL4 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:38:07 -0000 On Feb 17, 2014, at 03:00 , Jan-Frode Myklebust = wrote: > On Mon, Feb 17, 2014 at 08:16:00AM +1300, Brian E Carpenter wrote: >>>>> Le 15/02/2014 19:16, Owen DeLong a =E9crit : >>>>>> Indeed, the situations where ULA usage is detrimental vastly >>>>>> outnumbers those where it is actually beneficial. >>=20 >> That's an opinion, but it isn't an argument for abolishing >> ULAs. It's actually an argument for improving this draft so >> that it describes the cases in which ULAs are beneficial. >=20 >> Could we have a detailed conversation about whether those cases >> are correctly described in the draft? >=20 > Yes please. >=20 > My use case is that we have a set of datacenter internal = services/servers > that should *never* be routed out. When not using ULA we've had a = couple > of incidents where the routes did leak out and servers that shouldn't > have been available on the Internet was. So we've decided to use ULA = for > the same set of servers as we previously used rfc1918-adresses for. No > NAT involved. No servers should reach Internet directly. Yes we could > achieve the same by putting proper ACLs in place on the borders, but = since > we've failed to do that in the past, the belt and suspenders approach = is > attractive. >=20 > Is this a "valid" ULA usage?=20 >=20 Sure... As long as you don't mind renumbering when the connectedness (or = not) requirement changes, then that is one of the few cases where ULA is = not detrimental. Cases that propose NPT, NAT, or other translation mechanisms are = examples where it is detrimental. Cases where it ends up getting routed amongst "cooperating" parties are = likely to eventually lead to detrimental usage because the natural trend = is for them to become increasingly routed across more and more ASNs and = eventually to become a form of de facto registered address space not = administered by any structured or reliable registry and without any form = of community based policy process (such as the current RIRs). Owen From nobody Mon Feb 17 06:50:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640D31A0503; Mon, 17 Feb 2014 06:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTmyIYnwPwFx; Mon, 17 Feb 2014 06:50:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB51A0209; Mon, 17 Feb 2014 06:50:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFPWX-0000pc-BS; Mon, 17 Feb 2014 14:50:22 +0000 Date: Mon, 17 Feb 2014 22:50:18 +0800 Message-ID: From: Randy Bush To: "Fan, Peng" In-Reply-To: <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PJdUAIIEo9Fz0xc6WlSaXEbnl4U Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 14:50:29 -0000 > Would you please give me an example about how modern large ISPs manage their > networks? programmatic generation of configurations from databases. randy From nobody Mon Feb 17 08:30:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EED1A020A for ; Mon, 17 Feb 2014 08:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 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, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m-DaxisMBdp for ; Mon, 17 Feb 2014 08:30:08 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 69ED61A00B8 for ; Mon, 17 Feb 2014 08:30:08 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s1HGTqsc008692; Mon, 17 Feb 2014 16:29:52 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s1HGTqsc008692 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1392654593; bh=td+G1N5xGAMo3q4zLkMKDkBAsWU=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=UvzaEtLwZK2wYYRyscjnYxQzrUBbmIlm9mcVP9QQY6tvU6rcsqTFpPBAp4oQXKXRL fcE/k0sOg79dS3R1mYeCaZPdnBeqbebsxWRTjFlYREHnfp8DfQyOo+Wm74pbgELhWl oUdzCqP7PPO0CcznUXZFLb/8Cv8Q1jDGWrHKvFuI= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q1GGYq0959603512A0 ret-id none; Mon, 17 Feb 2014 16:29:53 +0000 Received: from dhcp-163-214.wireless.soton.ac.uk (dhcp-163-214.wireless.soton.ac.uk [152.78.163.214] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s1HGTpaI007086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 16:29:51 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_AC479C81-CEBD-470A-8FCE-B1A8B75ED464" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Chown In-Reply-To: Date: Mon, 17 Feb 2014 16:29:50 +0000 Message-ID: References: <78AAA6FC-F422-41D4-88A7-58066118C919@ecs.soton.ac.uk> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1827) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q1GGYq095960351200; tid=q1GGYq0959603512A0; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s1HGTqsc008692 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/FrCcyubO6GcC2GND0BR86KYsx8U Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 16:30:12 -0000 --Apple-Mail=_AC479C81-CEBD-470A-8FCE-B1A8B75ED464 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 16 Feb 2014, at 00:35, Fred Baker (fred) wrote: > Let me ask for comment on the list. >=20 > Folks, would you like to discuss this? I have a half hour to spare in = the time we have suggested. Yes, this is a worthwhile discussion to have, briefly. Tim >=20 > On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti > wrote: >=20 >> On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) = wrote: >> This is of course open to change; that's why it's called a "proposed = agenda". Please post to the list. >>=20 >> Would there be time to briefly discuss: >>=20 >> = http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-0= 0 ?=20 >>=20 >> This will be presented in 6man during a session on the efficiency of = the ND protocol, but I feel that it really belongs in v6ops, because it = has no protocol changes. >>=20 >> Of course, since it was posted only shortly before 23:59 UTC, it = fails the "has been discussed on the list" test. :-) >=20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_AC479C81-CEBD-470A-8FCE-B1A8B75ED464 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On 16 Feb 2014, at 00:35, Fred = Baker (fred) <fred@cisco.com> = wrote:

Let = me ask for comment on the list.

Folks, would you like = to discuss this? I have a half hour to spare in the time we have = suggested.

Yes, this is a = worthwhile discussion to have, = briefly.

Tim


On = Feb 14, 2014, at 7:05 PM, Lorenzo Colitti <lorenzo@google.com>
&n= bsp;wrote:

On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker = (fred) <fred@cisco.com> wrote:
This is of course open to change; that's = why it's called a "proposed agenda". Please post to the list.

Would there be time to briefly = discuss:


This will be presented in 6man during a session on = the efficiency of the ND protocol, but I feel that it really belongs in = v6ops, because it has no protocol changes.

Of = course, since it was posted only shortly before 23:59 UTC, it fails the = "has been discussed on the list" test. :-)

----------------------------------------------------
<= div>ignorance of how to use newstockpiles exponentiallyv6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_AC479C81-CEBD-470A-8FCE-B1A8B75ED464-- From nobody Mon Feb 17 08:38:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5421A0418 for ; Mon, 17 Feb 2014 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS6VetZ-ldkw for ; Mon, 17 Feb 2014 08:38:34 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 25A5D1A040C for ; Mon, 17 Feb 2014 08:38:34 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DD10A1B81D8 for ; Mon, 17 Feb 2014 08:38:31 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CF993190043; Mon, 17 Feb 2014 08:38:31 -0800 (PST) Received: from [10.0.1.29] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 08:38:25 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> Date: Mon, 17 Feb 2014 11:38:22 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> To: Owen DeLong X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/RS4lxcjAfQDLEYJoKX8HPFOmNEY Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:38:39 -0000 On Feb 17, 2014, at 9:35 AM, Owen DeLong wrote: > Cases that propose NPT, NAT, or other translation mechanisms are = examples where it is detrimental. This is clearly true, but we can't do much about it other than to = encourage people to avoid this, and help them to avoid it by giving them = alternatives. > Cases where it ends up getting routed amongst "cooperating" parties = are likely to eventually lead to detrimental usage because the natural = trend is for them to become increasingly routed across more and more = ASNs and eventually to become a form of de facto registered address = space not administered by any structured or reliable registry and = without any form of community based policy process (such as the current = RIRs). This is a fun doomsday scenario, but we don't have this with RFC 1918 = addresses today; why would we have it with ULAs tomorrow? In fact, = ULAs fix one of the really big problems with RFC 1918 addresses: there = are so few of the latter that when two corporations that use RFC 1918 = numbering internally merge, you have a really bad renumbering problem, = and wind up doing more NATs than you otherwise would have. So I think this use case is one where ULAs actually do really well. Do you have some reason for thinking that your doomsday scenario is = likely, or is it sufficient to you that it's possible, and therefore you = want to avoid it? From nobody Mon Feb 17 09:11:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FFB1A0207 for ; Mon, 17 Feb 2014 09:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzu8IW4oA7en for ; Mon, 17 Feb 2014 09:11:45 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 707A41A00FE for ; Mon, 17 Feb 2014 09:11:45 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1HHBaXY051333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 17:11:37 GMT (envelope-from joelja@bogus.com) Message-ID: <530242C3.4070108@bogus.com> Date: Mon, 17 Feb 2014 09:11:31 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Ted Lemon , Owen DeLong References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> In-Reply-To: <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oiHDoSsIdLf3JVLamc2Gu4Gfxqnq9Rs4F" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 17 Feb 2014 17:11:38 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vEZFsNQv7VHXtDEcx1Y83MbbA50 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:11:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oiHDoSsIdLf3JVLamc2Gu4Gfxqnq9Rs4F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/17/14, 8:38 AM, Ted Lemon wrote: > On Feb 17, 2014, at 9:35 AM, Owen DeLong wrote: >> Cases that propose NPT, NAT, or other translation mechanisms are >> examples where it is detrimental. >=20 > This is clearly true, but we can't do much about it other than to > encourage people to avoid this, and help them to avoid it by giving > them alternatives. >=20 >> Cases where it ends up getting routed amongst "cooperating" parties >> are likely to eventually lead to detrimental usage because the >> natural trend is for them to become increasingly routed across more >> and more ASNs and eventually to become a form of de facto >> registered address space not administered by any structured or >> reliable registry and without any form of community based policy >> process (such as the current RIRs). >=20 > This is a fun doomsday scenario, but we don't have this with RFC 1918 > addresses today; why would we have it with ULAs tomorrow? we route rfc 1918 between cooperating parties today. as noted it requires coordination and is painful. > In fact, > ULAs fix one of the really big problems with RFC 1918 addresses: > there are so few of the latter that when two corporations that use > RFC 1918 numbering internally merge, you have a really bad > renumbering problem, and wind up doing more NATs than you otherwise > would have. what consenting adults do within the privacy of their own asns is really none of my business. If widely deployed in an uncoordinated fashion it becomes toxic for globally coordinated use, which precludes owen's scenario. the fact that we have 41 bits instead of 23.5 doesn't really obviate that. > So I think this use case is one where ULAs actually do really well. >=20 > Do you have some reason for thinking that your doomsday scenario is > likely, or is it sufficient to you that it's possible, and therefore > you want to avoid it? >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --oiHDoSsIdLf3JVLamc2Gu4Gfxqnq9Rs4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMCQsMACgkQ8AA1q7Z/VrIbUwCfcUU4xnz4y7906tLmibJY8+4q DM0An0lF3mR/rqizWKLlru6z2dTKuS8b =xt1K -----END PGP SIGNATURE----- --oiHDoSsIdLf3JVLamc2Gu4Gfxqnq9Rs4F-- From nobody Mon Feb 17 11:24:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5905F1A0470 for ; Mon, 17 Feb 2014 11:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C2f2ZxW7Ad3 for ; Mon, 17 Feb 2014 11:24:31 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F71A053F for ; Mon, 17 Feb 2014 11:24:31 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so15850521pbc.27 for ; Mon, 17 Feb 2014 11:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z5oYxHg1dCrjKG40iVUxC/VINItEqEVcD5njX0DwUno=; b=ZgJXzE2p67MHd7mP3i+sBzyPUg3Kcjxlil5QbPZNruZ9p9DQQh7GOxpGf8qRr9eH0s giap2dM7frqhUq9Blpsc71WR12/T3EJKJkRcXbzTOpIvlBrWYPVPtjc7XEQxP0n+MJeT 3ae33RFgTncP6I7OfIhPw/vw0hAQ1X4JPCGunGYCu8qFOg/dgaVdtzjUlXhQOuTNkVKz oGHQW+CKePqhh4paTPzxNoUiR4bHQl9xZjDleiVg6dAdyt6smDCCkGQInYk1HPcK+YQx 7GxdGXEf+fmeAVeKSOLauo4zzKcd0tFoSKxpfN9QLswSE1VYMI58Si8aIzTl1ewoyG/w QWDw== X-Received: by 10.68.143.196 with SMTP id sg4mr5234701pbb.155.1392665069253; Mon, 17 Feb 2014 11:24:29 -0800 (PST) Received: from [192.168.178.23] (82.200.69.111.dynamic.snap.net.nz. [111.69.200.82]) by mx.google.com with ESMTPSA id db3sm48329515pbb.10.2014.02.17.11.24.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 11:24:28 -0800 (PST) Message-ID: <530261ED.8060605@gmail.com> Date: Tue, 18 Feb 2014 08:24:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> In-Reply-To: <530242C3.4070108@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/UUvjggGQOiv7R0bUs2B7dAK66Bc Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 19:24:34 -0000 On 18/02/2014 06:11, joel jaeggli wrote: > On 2/17/14, 8:38 AM, Ted Lemon wrote: >> On Feb 17, 2014, at 9:35 AM, Owen DeLong wrote: >>> Cases that propose NPT, NAT, or other translation mechanisms are >>> examples where it is detrimental. >> This is clearly true, but we can't do much about it other than to >> encourage people to avoid this, and help them to avoid it by giving >> them alternatives. >> >>> Cases where it ends up getting routed amongst "cooperating" parties >>> are likely to eventually lead to detrimental usage because the >>> natural trend is for them to become increasingly routed across more >>> and more ASNs and eventually to become a form of de facto >>> registered address space not administered by any structured or >>> reliable registry and without any form of community based policy >>> process (such as the current RIRs). >> This is a fun doomsday scenario, but we don't have this with RFC 1918 >> addresses today; why would we have it with ULAs tomorrow? > > we route rfc 1918 between cooperating parties today. as noted it > requires coordination and is painful. Yes, but it's painful because of ambiguity. With ULAs all you have to coordinate is which prefixes are announced between the cooperating parties. No coordination is needed for prefix assignment, which is the real hassle with RFC 1918. Brian > >> In fact, >> ULAs fix one of the really big problems with RFC 1918 addresses: >> there are so few of the latter that when two corporations that use >> RFC 1918 numbering internally merge, you have a really bad >> renumbering problem, and wind up doing more NATs than you otherwise >> would have. > > what consenting adults do within the privacy of their own asns is really > none of my business. > > If widely deployed in an uncoordinated fashion it becomes toxic for > globally coordinated use, which precludes owen's scenario. the fact that > we have 41 bits instead of 23.5 doesn't really obviate that. > >> So I think this use case is one where ULAs actually do really well. >> >> Do you have some reason for thinking that your doomsday scenario is >> likely, or is it sufficient to you that it's possible, and therefore >> you want to avoid it? >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 17 11:45:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311E61A0215 for ; Mon, 17 Feb 2014 11:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id berdAfwImQPL for ; Mon, 17 Feb 2014 11:45:38 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 672791A0177 for ; Mon, 17 Feb 2014 11:45:38 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1HJjUTN052397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 19:45:30 GMT (envelope-from joelja@bogus.com) Message-ID: <530266D5.9030401@bogus.com> Date: Mon, 17 Feb 2014 11:45:25 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <530261ED.8060605@gmail.com> In-Reply-To: <530261ED.8060605@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uD2oW9Vqc55raxDPvD3V5wVwnrVVVBw5m" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 17 Feb 2014 19:45:31 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3PfOmLwS-qGWNWA4qizdXdha98o Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 19:45:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uD2oW9Vqc55raxDPvD3V5wVwnrVVVBw5m Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2/17/14, 11:24 AM, Brian E Carpenter wrote: > On 18/02/2014 06:11, joel jaeggli wrote: >> On 2/17/14, 8:38 AM, Ted Lemon wrote: >>> On Feb 17, 2014, at 9:35 AM, Owen DeLong wrote: >>>> Cases that propose NPT, NAT, or other translation mechanisms are >>>> examples where it is detrimental. >>> This is clearly true, but we can't do much about it other than to >>> encourage people to avoid this, and help them to avoid it by giving >>> them alternatives. >>> >>>> Cases where it ends up getting routed amongst "cooperating" parties >>>> are likely to eventually lead to detrimental usage because the >>>> natural trend is for them to become increasingly routed across more >>>> and more ASNs and eventually to become a form of de facto >>>> registered address space not administered by any structured or >>>> reliable registry and without any form of community based policy >>>> process (such as the current RIRs). >>> This is a fun doomsday scenario, but we don't have this with RFC 1918= >>> addresses today; why would we have it with ULAs tomorrow? >> >> we route rfc 1918 between cooperating parties today. as noted it >> requires coordination and is painful. >=20 > Yes, but it's painful because of ambiguity. With ULAs all you have to > coordinate is which prefixes are announced between the cooperating > parties. No coordination is needed for prefix assignment, which > is the real hassle with RFC 1918. you're assuming that humans allocate prefixes via the procedures described in the rfc and that utlization of a sparse address space is sufficently difuse the you don't have to worry about collisions or that more specfic routes will win out when someone has the bad taste to use fc00::/7 or 8 in a routing policy contribution to aggregate and so on. I kinda have my doubts. operational considerations around internal aggregation and the human need to group things together in sets as well as semantic uses (which I continue to assert are a bad idea) are going to cause these things to be used inside organizations on boundries other than /48. My basic assertion is that if ula is widely and obiquitously employed, owen's scenario is unlikely to come to pass because the results are messy and risky. If it isn't widely employed then who cares? > Brian >=20 >> >>> In fact, >>> ULAs fix one of the really big problems with RFC 1918 addresses: >>> there are so few of the latter that when two corporations that use >>> RFC 1918 numbering internally merge, you have a really bad >>> renumbering problem, and wind up doing more NATs than you otherwise >>> would have. >> >> what consenting adults do within the privacy of their own asns is real= ly >> none of my business. >> >> If widely deployed in an uncoordinated fashion it becomes toxic for >> globally coordinated use, which precludes owen's scenario. the fact th= at >> we have 41 bits instead of 23.5 doesn't really obviate that. >> >>> So I think this use case is one where ULAs actually do really well. >>> >>> Do you have some reason for thinking that your doomsday scenario is >>> likely, or is it sufficient to you that it's possible, and therefore >>> you want to avoid it? >>> >>> _______________________________________________ v6ops mailing list=20 >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --uD2oW9Vqc55raxDPvD3V5wVwnrVVVBw5m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMCZtUACgkQ8AA1q7Z/VrLEnACdHnM7zMGbz9FsC+DcGBg48VxP PasAnA2p/zkrqIYB0TNhz1YWvh3ddext =7jr5 -----END PGP SIGNATURE----- --uD2oW9Vqc55raxDPvD3V5wVwnrVVVBw5m-- From nobody Mon Feb 17 12:28:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894031A04E5; Mon, 17 Feb 2014 12:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVmZ69kfcpH2; Mon, 17 Feb 2014 12:28:34 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C3E721A04D2; Mon, 17 Feb 2014 12:28:34 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1HKSTlG052575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 20:28:30 GMT (envelope-from joelja@bogus.com) Message-ID: <530270E8.5090603@bogus.com> Date: Mon, 17 Feb 2014 12:28:24 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: David Farmer , Shane Amante References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> In-Reply-To: <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 17 Feb 2014 20:28:30 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LE3PXi4ZYg9xCMsUP3WL3hoFVQU Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 20:28:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/15/14, 11:25 AM, David Farmer wrote: > As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. > Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or > you could even used mixed notation 2001:db8:1::192.0.2.5. You could, but you shouldn't whether it's merely shorthand or not because ipv6 mapped ipv4 addresses and accompanying notation are are sort of ugly representation that will be throwing junior network operators under the bus for years to come. http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00 --p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMCcOgACgkQ8AA1q7Z/VrLAzQCcCH4yqWdYtyWH7ldCuon32yn/ BnEAniES0Cc636YqsXpQZ0Dq6MC3Gz1B =XYHJ -----END PGP SIGNATURE----- --p6sDx158VsAp83MjGOIW8Tnpfjwd1SI67-- From nobody Mon Feb 17 12:42:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E637B1A0282 for ; Mon, 17 Feb 2014 12:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfvc56oWk2yI for ; Mon, 17 Feb 2014 12:42:51 -0800 (PST) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) by ietfa.amsl.com (Postfix) with ESMTP id 35BE21A027A for ; Mon, 17 Feb 2014 12:42:51 -0800 (PST) Received: from [98.139.212.151] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 20:42:48 -0000 Received: from [98.139.212.209] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 20:42:48 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 17 Feb 2014 20:42:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 418477.15020.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 12497 invoked by uid 60001); 17 Feb 2014 20:42:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1392669768; bh=NTQetp2w4zfhzr0iLP5A0MerDChsPF/ErWG3fMndozM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Dt38g6nhhNvrltdyNnOioFYXh8WFnwWP34SQrcLJWtI5oJ/Molmq5Py1A4kRjSr3HAiRc3mKxexWfbH21w8CjK9McT2BV5TsG9TDcglZNjmKxaTD02kqHfsIU9GqqIAkccUlS3/ETfx1saqYjOVcycW/fpd5karJYGuReRj69QU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bA+GIT/Exu6hCNANMZ2DwHOyfpQ/iqh9BWex/WgSpzy1fUXA2xzRKB1j0z9sm5ZPQ+LqIS30YD8MuGIozmk7jZRzzxVW2xFA0ejGjrQO159uJdyAbYscDVT6bUsQJEULnNHOBXKCJXPjE4SffElirF5mR06nZLljVmbQo+3gcy0=; X-YMail-OSG: UOWGfzwVM1nJtPXSF57PejeDMG19b8MHrPTMQyjEmMrujaH 6G8wMHiadd8AzgeoforEyCr2nVRQyXaiAQAPC2CyX0tkKU9.IuwkngKw7lF_ 3BWKhN6GBItWoinZmiDp5bcbRDwwFFBhchIsHbwlzdulzaAe.5hE_pNdChko DefdL9PIM8f8ixWsux66W.6g0PE3p8rVho4.IYv34D2yCWD5iQM4zcG28BsO KnBEuda.W8C198Vjia_H5kSS6zEkh1SYC4FpMUGUanO3bCTfCVvPpEAjKjPH 8qp38KqRA88lYIs.DzgEm814pCOmpz.PSamltvhC93hUIP6a1V6lwN5DzoQO tm.s_rzfhdeIYCkxUQPJIQn6G_EKyPMwfaH3hxCzDtSjLV3cHlRt.aPTafiZ tUrXUEKQG8RGgoQMdKKZXgQsaDrXe.UfrMhjPCVqJJ6JC0NWU81H_AZW8dZc ZYzORqHHS5c1gs6XIDkfCtvn5SzQ2XKH2bAYX9qZ.Ihe8LqqK5BusDrYkWjQ llwf9546tRwkTPmoDa1EF8BHpn0AyNBzvgjID_2rCTMeKeesSO0ZiPxKTYez wUkSqKRhBVfX1RZJy5b0- Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Mon, 17 Feb 2014 12:42:48 PST X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBHZXJ0IERvZXJpbmcgPGdlcnRAc3BhY2UubmV0Pgo.IFRvOiBKYW4tRnJvZGUgTXlrbGVidXN0IDxqYW5mcm9kZUB0YW5zby5uZXQ.Cj4gQ2M6IFY2IE9wcyBMaXN0IDx2Nm9wc0BpZXRmLm9yZz4KPiBTZW50OiBNb25kYXksIDE3IEZlYnJ1YXJ5IDIwMTQgMTE6MTMgUE0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVsYS11c2FnZS1yZWNvbW1lbmRhdGlvbnMtMDIudHh0Cj4gCj4gSGksCj4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <20140217121322.GK75390@Space.Net> Message-ID: <1392669768.94176.YahooMailNeo@web162204.mail.bf1.yahoo.com> Date: Mon, 17 Feb 2014 12:42:48 -0800 (PST) From: Mark ZZZ Smith To: Gert Doering , Jan-Frode Myklebust In-Reply-To: <20140217121322.GK75390@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wnSWgskP25VwdLBJisoqjIjADqw Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 20:42:53 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: Gert Doering =0A> To: Jan-Frode Myklebust =0A> Cc: V6 Ops List = =0A> Sent: Monday, 17 February 2014 11:13 PM=0A> Subject: R= e: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt=0A= > =0A> Hi,=0A> =0A> On Mon, Feb 17, 2014 at 12:00:13PM +0100, Jan-Frode Myk= lebust wrote:=0A>> Is this a "valid" ULA usage? =0A> =0A> I'd say so.=A0 S= ome of our network management stuff is done via ULAs, =0A> as it will ensur= e that machines will only be able to communicate with =0A> exactly our netw= ork, and nobody else.=A0 (There are ACLs in addition to=0A> that, before so= meone starts shouting at me)=0A>=A0=0A=0A+1=0A=0AIt would also reduce the l= ikelihood of loosing remote connectivity to devices when performing changes= to global prefixes, which are more likely to need be changed than ULAs (de= coupling ULA and global subnet allocation would be a good idea). Even more = robust management could be achieved by routing global and ULA prefixes in s= eparate IGP instances or IGPs, further lowering the likelihood of ULA disru= ption when global prefix changes are being made.=0A=0AI think that is one o= f the strong values of ULAs. It seems to me that reducing or avoiding exter= nal dependencies makes things more robust. Using ULAs internally means your= network's internal addressing and reachability isn't dependent on external= global prefix(es). This is actually one of the values of RFC1918 addresses= , however, the trouble with them is that they aren't globally unique and it= isn't easy to run concurrent RFC1918 and public addressing in an IPv4 netw= ork. ULAs and IPv6 overcome those drawbacks.=0A=0A=0ARegards,=0AMark. From nobody Mon Feb 17 13:56:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08E51A027C for ; Mon, 17 Feb 2014 13:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gybCav_A2LeB for ; Mon, 17 Feb 2014 13:56:29 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9D03E1A021E for ; Mon, 17 Feb 2014 13:56:29 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so15776544pbc.41 for ; Mon, 17 Feb 2014 13:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mho2CGR1JaPRBdHXnFOMUFHbHUu8aNBHMh96CFGO5L8=; b=qaNslgfb1yrPofMRxyJdQ7VoaehwuB5BzBcP3MFiLedVbU9a09agDCYanZVMcrf2Is 2MbLarOEvYT5o1BB1MkiFaYb0COTSx3KOAcNQqRXw9r5bT30bmSfL+dbvkhwhXKVRBc6 xo96e1xIQR0YYNfbOHC9ptnTyRRJKlPPc+kWTHHlX5k05NxIP1M53vUr7wXeO+5yqs5z dGsqskUCEFOLShN8ZgzwsaTrIb6L0TSMTOlGCzxaIqFAo7NT6Mf0ek6IydgZpG7Pm9MZ zi6i6dzPKYwCK4DKh5rle/q63I+uDYB+8p4UaVCvvuhe6Jqsxgx1xaoJbmN6xxST4FVR nGjg== X-Received: by 10.66.158.132 with SMTP id wu4mr29097644pab.66.1392674187069; Mon, 17 Feb 2014 13:56:27 -0800 (PST) Received: from [192.168.178.23] (82.200.69.111.dynamic.snap.net.nz. [111.69.200.82]) by mx.google.com with ESMTPSA id db3sm49055553pbb.10.2014.02.17.13.56.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 13:56:26 -0800 (PST) Message-ID: <53028586.9080208@gmail.com> Date: Tue, 18 Feb 2014 10:56:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <530261ED.8060605@gmail.com> <530266D5.9030401@bogus.com> In-Reply-To: <530266D5.9030401@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hPerQ1bwZ1Edprgx2WRjbW38pxY Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 21:56:31 -0000 On 18/02/2014 08:45, joel jaeggli wrote: > On 2/17/14, 11:24 AM, Brian E Carpenter wrote: >> On 18/02/2014 06:11, joel jaeggli wrote: >>> On 2/17/14, 8:38 AM, Ted Lemon wrote: >>>> On Feb 17, 2014, at 9:35 AM, Owen DeLong wrote: >>>>> Cases that propose NPT, NAT, or other translation mechanisms are >>>>> examples where it is detrimental. >>>> This is clearly true, but we can't do much about it other than to >>>> encourage people to avoid this, and help them to avoid it by giving >>>> them alternatives. >>>> >>>>> Cases where it ends up getting routed amongst "cooperating" parties >>>>> are likely to eventually lead to detrimental usage because the >>>>> natural trend is for them to become increasingly routed across more >>>>> and more ASNs and eventually to become a form of de facto >>>>> registered address space not administered by any structured or >>>>> reliable registry and without any form of community based policy >>>>> process (such as the current RIRs). >>>> This is a fun doomsday scenario, but we don't have this with RFC 1918 >>>> addresses today; why would we have it with ULAs tomorrow? >>> we route rfc 1918 between cooperating parties today. as noted it >>> requires coordination and is painful. >> Yes, but it's painful because of ambiguity. With ULAs all you have to >> coordinate is which prefixes are announced between the cooperating >> parties. No coordination is needed for prefix assignment, which >> is the real hassle with RFC 1918. > > you're assuming that humans allocate prefixes via the procedures > described in the rfc People who don't will be punished automatically. > and that utlization of a sparse address space is > sufficently difuse the you don't have to worry about collisions or that > more specfic routes will win out when someone has the bad taste to use > fc00::/7 or 8 in a routing policy contribution to aggregate and so on. People who do will be punished automatically. > I kinda have my doubts. operational considerations around internal > aggregation and the human need to group things together in sets as well > as semantic uses (which I continue to assert are a bad idea) are going > to cause these things to be used inside organizations on boundries other > than /48. > > My basic assertion is that if ula is widely and obiquitously employed, > owen's scenario is unlikely to come to pass because the results are > messy and risky. If it isn't widely employed then who cares? Exactly right. Brian From nobody Mon Feb 17 15:20:28 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0131A05AB for ; Mon, 17 Feb 2014 15:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdxRsOu7iyEF for ; Mon, 17 Feb 2014 15:20:18 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6826F1A055C for ; Mon, 17 Feb 2014 15:20:13 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 17 Feb 2014 17:20:10 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f169.google.com [209.85.223.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ie0-f169.google.com with SMTP id at1so1810122iec.0 for ; Mon, 17 Feb 2014 15:20:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xaHYmIquxH3u08ijAsPWjaTey4npX8ucO+pGHaL3k1Q=; b=aATsWCPWjP6CyVErHwkHRyNBg6UDyK2bMd+yVw3qDdbLlI1L9toyz+LyOViT7N/EwI I7PpO8Ud/MopVDrp8Qzkfw/cpG7Ji+vqKNcprAIVGedq/5uqJbZXxOTzK/rjHTd2qK2J s/4lbbDWhHRiYGd2isl48+5/FBalBPLbcNdmkWb8SGndQVSXU5yXltpKR+AOiE40sOLd WdbzHvmcIyz2oAKFGiilFeSj7LUK4qVsiUiJO7/3RKGty3I4SqwqdjT+utMYuRpoO6xs cP84oXes4xVjaRCyqQ4Hy+IQvFnwT0f+QO7GoVO3/IG0WnesjDS7R1Qbf96aQ+W17z2N YscA== X-Gm-Message-State: ALoCoQm2EOMjn59pmksFv+S7uXudxW/Sf1vFBdbw+vMurkCmjj2G0U0ljKkLKIE2HoRvnzaJ3hq3C0ChFirmzNGw62sxho2WdGg5RNIqXLrRh7zqTkdbwtr09r6LSr/EqcvMKzWluwq8 X-Received: by 10.50.122.8 with SMTP id lo8mr19178025igb.31.1392679210071; Mon, 17 Feb 2014 15:20:10 -0800 (PST) X-Received: by 10.50.122.8 with SMTP id lo8mr19178007igb.31.1392679209881; Mon, 17 Feb 2014 15:20:09 -0800 (PST) Received: from x-160-94-249-105.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:fd29:5012:9352:d3d6]) by mx.google.com with ESMTPSA id kb5sm35345728igb.1.2014.02.17.15.20.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 15:20:08 -0800 (PST) Message-ID: <53029926.5030002@umn.edu> Date: Mon, 17 Feb 2014 17:20:06 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: joel jaeggli , Shane Amante References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <5423C5E9-C6A4-4285-9349-F6928BA5D689@umn.edu> <530270E8.5090603@bogus.com> In-Reply-To: <530270E8.5090603@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jjgrfSVMcV3LmdFbulreC_V2kDk Cc: V6 Ops List , idr wg Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:20:22 -0000 On 2/17/14, 14:28 , joel jaeggli wrote: > On 2/15/14, 11:25 AM, David Farmer wrote: > >> As an example: let's say your ROUTER_ID is 192.0.2.5 or 0xC0000205. >> Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or >> you could even used mixed notation 2001:db8:1::192.0.2.5. > > You could, but you shouldn't whether it's merely shorthand or not > because ipv6 mapped ipv4 addresses and accompanying notation are are > sort of ugly representation that will be throwing junior network > operators under the bus for years to come. > > http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-00 I'd prefer to recommend that implementations include a hex representation of the ROUTER_ID, either in addition to or instead of the dotted quad decimal representation. I need to study it more closely, but I think what I'm suggesting is compatible with the recommendation in RFC5952 Section 5. However, I take your point, even if compatible with RFC5952 Section 5, its best to avoid the problem if possible. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Mon Feb 17 18:10:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7971A055B for ; Mon, 17 Feb 2014 18:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Ryp-maLoHYV2 for ; Mon, 17 Feb 2014 18:10:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4E1A02E4 for ; Mon, 17 Feb 2014 18:10:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDR63018; Tue, 18 Feb 2014 02:10:11 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 02:09:58 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 02:10:06 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 10:09:59 +0800 From: "Liubing (Leo)" To: Jan-Frode Myklebust Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt Thread-Index: AQHPKWgMo43RzbooVkmZSkAdeWvl75qz/igAgAD96wCAAR80gIABVkQAgAA9hYCAAAN1gIAAC5wAgAEHz4CAAX+1QA== Date: Tue, 18 Feb 2014 02:09:59 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D83577F@nkgeml506-mbx.china.huawei.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> In-Reply-To: <20140217110013.GA31822@mushkin> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sn6S8-6tmndcGx0xNihq70FyzyA Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:10:17 -0000 SGkgSmFuLA0KDQpUaGFua3MgZm9yIHNoYXJpbmcgdGhlIGluZm9ybWF0aW9uLiBQbGVhc2Ugc2Vl IGlubGluZS4NCg0KPiA+IENvdWxkIHdlIGhhdmUgYSBkZXRhaWxlZCBjb252ZXJzYXRpb24gYWJv dXQgd2hldGhlciB0aG9zZSBjYXNlcyBhcmUNCj4gPiBjb3JyZWN0bHkgZGVzY3JpYmVkIGluIHRo ZSBkcmFmdD8NCj4gDQo+IFllcyBwbGVhc2UuDQo+IA0KPiBNeSB1c2UgY2FzZSBpcyB0aGF0IHdl IGhhdmUgYSBzZXQgb2YgZGF0YWNlbnRlciBpbnRlcm5hbCBzZXJ2aWNlcy9zZXJ2ZXJzIHRoYXQN Cj4gc2hvdWxkICpuZXZlciogYmUgcm91dGVkIG91dC4gV2hlbiBub3QgdXNpbmcgVUxBIHdlJ3Zl IGhhZCBhIGNvdXBsZSBvZg0KPiBpbmNpZGVudHMgd2hlcmUgdGhlIHJvdXRlcyBkaWQgbGVhayBv dXQgYW5kIHNlcnZlcnMgdGhhdCBzaG91bGRuJ3QgaGF2ZSBiZWVuDQo+IGF2YWlsYWJsZSBvbiB0 aGUgSW50ZXJuZXQgd2FzLiBTbyB3ZSd2ZSBkZWNpZGVkIHRvIHVzZSBVTEEgZm9yIHRoZSBzYW1l IHNldA0KPiBvZiBzZXJ2ZXJzIGFzIHdlIHByZXZpb3VzbHkgdXNlZCByZmMxOTE4LWFkcmVzc2Vz IGZvci4gTm8gTkFUIGludm9sdmVkLiBObw0KPiBzZXJ2ZXJzIHNob3VsZCByZWFjaCBJbnRlcm5l dCBkaXJlY3RseS4gWWVzIHdlIGNvdWxkIGFjaGlldmUgdGhlIHNhbWUgYnkNCj4gcHV0dGluZyBw cm9wZXIgQUNMcyBpbiBwbGFjZSBvbiB0aGUgYm9yZGVycywgYnV0IHNpbmNlIHdlJ3ZlIGZhaWxl ZCB0byBkbyB0aGF0DQo+IGluIHRoZSBwYXN0LCB0aGUgYmVsdCBhbmQgc3VzcGVuZGVycyBhcHBy b2FjaCBpcyBhdHRyYWN0aXZlLg0KPiANCj4gSXMgdGhpcyBhICJ2YWxpZCIgVUxBIHVzYWdlPw0K W0JpbmddIFRoaXMgaXMgb25lIG9mIHRoZSBzY2VuYXJpb3MgZGVzY3JpYmVkIGluIFNlY3Rpb24g My4yLjIsIHdoZXJlIFVMQXMgYXJlIHVzZWQgYWxvbmcgd2l0aCBHVUFzIGluIGEgY29ubmVjdGVk IG5ldHdvcmsuIFRoZXJlIGFyZSB0d28gY2FzZXMgaW4gdGhpcyBzY2VuYXJpbzogDQoxKSBpbnRl cm5hbC1vbmx5IG5vZGVzLCBjb25maWd1cmVkIHdpdGggVUxBcyBvbmx5LiANCjIpIG5vZGVzIGNv bmZpZ3VyZWQgd2l0aCBib3RoIFVMQSBhbmQgR1VBLCBhbmQgVUxBIGlzIGZvciBpbnRlcm5hbCBj b21tdW5pY2F0aW9uIHdoaWxlIEdVQSBmb3IgdGhlIG91dHNpZGUuDQpJIHRoaW5rIHlvdXIgY2Fz ZSBmaXRzIHRoZSBmb3JtZXIgb25lLg0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCj4gDQo+IA0K PiAgIC1qZg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Mon Feb 17 18:32:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444D81A02F3; Mon, 17 Feb 2014 18:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.376 X-Spam-Level: X-Spam-Status: No, score=0.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 vAJqONNTp75F; Mon, 17 Feb 2014 18:32:08 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 090EC1A0164; Mon, 17 Feb 2014 18:32:07 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302c599b7f-f2b7f; Tue, 18 Feb 2014 10:29:46 +0800 (CST) X-RM-TRANSID: 2ee15302c599b7f-f2b7f Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302c599baf-db74a; Tue, 18 Feb 2014 10:29:46 +0800 (CST) X-RM-TRANSID: 2ee35302c599baf-db74a Date: Tue, 18 Feb 2014 10:31:57 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" , fanpeng References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402181031568885348@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart050641472535_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tw48gLwDvKAQ8FLzneLamVSIOnM Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 02:32:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart050641472535_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgoKCgoKSGkgUmFuZHksCkRvIHlvdSBoYXZlIHN1Y2ggdG9vbHMgdG8gY29uZmlnIHlvdXIgbmV0 d29yaz8gT3IgZG8geW91IGtub3cgdGhlIHZlbmRvciB0aGF0IHByb3ZpZGUgc3VjaCB0b29scz9J bmRlZWQsIHN1Y2jCoHByb2dyYW1tYXRpYyBnZW5lcmF0aW9uIHRvb2xzIGFyZSBnb29kIGZvciBu ZXR3b3JrIHBsYW4uIEJ1dCB0aGUgbG9naWMgaW4gdGhlIHRvb2xzIGlzIGNvbXBsZWNhdGVkIGVz cGVjaWFsbHkgZm9yIGEgdmVyeSBsYXJnZSBuZXR3b3JrIHdpdGjCoGhpZXJhcmNoaWNhbCBvcGVy YXRpb24gYXMgUGVuZyBGYW4gbWVudGlvbmVkLgoKWmhlbnFpYW5nIExpCgrCoEZyb206wqBSYW5k eSBCdXNoRGF0ZTrCoDIwMTQtMDItMTfCoDIyOjUwVG86wqBGYW4sIFBlbmdDQzrCoCdpZHIgd2cn OyAnVjYgT3BzIExpc3QnOyAnUm9iZXJ0IFJhc3p1aydTdWJqZWN0OsKgUmU6IFtJZHJdIFt2Nm9w c10gQkdQIElkZW50aWZpZXI+IFdvdWxkIHlvdSBwbGVhc2UgZ2l2ZSBtZSBhbiBleGFtcGxlIGFi b3V0IGhvdyBtb2Rlcm4gbGFyZ2UgSVNQcyBtYW5hZ2UgdGhlaXIKPiBuZXR3b3Jrcz8KwqAKcHJv Z3JhbW1hdGljIGdlbmVyYXRpb24gb2YgY29uZmlndXJhdGlvbnMgZnJvbSBkYXRhYmFzZXMuCsKg CnJhbmR5CsKgCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CklkciBtYWlsaW5nIGxpc3QKSWRyQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWRyCsKgCgo= ------=_001_NextPart050641472535_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
Hi Randy,

Do you have such tools to config you= r network? Or do you know the vendor that provide such tools?
In= deed, such programmatic generation tools are good for network pl= an. But the logic in the tools is complecated especially for a very large = network with hierarchical operation as Peng Fan mentioned.=0A

Zhenqiang Li

=0A
 
From: Randy Bush
Date: 2014-02-17 22:50
Subject: Re: = [Idr] [v6ops] BGP Identifier
> Would you ple= ase give me an example about how modern large ISPs manage their
=0A> networks?
=0A
 
=0A
programmatic generation= of configurations from databases.
=0A
 
=0A
randy<= /div>=0A
 
=0A
_________________________________________= ______
=0A
Idr mailing list
=0A
Idr@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/idr
=0A
 
=0A
=0A ------=_001_NextPart050641472535_=------ From nobody Mon Feb 17 18:33:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA83E1A030B; Mon, 17 Feb 2014 18:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 7R_Hq1LiDFZe; Mon, 17 Feb 2014 18:33:11 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id DB6201A0317; Mon, 17 Feb 2014 18:33:09 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302c5e3bd4-f2bd4; Tue, 18 Feb 2014 10:30:59 +0800 (CST) X-RM-TRANSID: 2ee15302c5e3bd4-f2bd4 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee25302c5e2c63-f48f9; Tue, 18 Feb 2014 10:30:59 +0800 (CST) X-RM-TRANSID: 2ee25302c5e2c63-f48f9 Date: Tue, 18 Feb 2014 10:33:09 +0800 From: "lizhenqiang@chinamobile.com" To: =?ISO-8859-1?B?VVRUQVJPLCBKQU1FUw==?= , "Randy Bush" , fanpeng References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402181033092475009@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart002576354625_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uVFeUvJbzkLqpOd-eXRKMGyUGFg Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 02:33:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart002576354625_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKWWVzIHdlIGRvIGlmIHdlIGNvdWxkLgoKWmhlbnFpYW5nIExpCgqgRnJvbTqgVVRUQVJP LCBKQU1FU0RhdGU6oDIwMTQtMDItMTegMjM6NTJUbzqgUmFuZHkgQnVzaDsgRmFuLCBQZW5nQ0M6 oCdpZHIgd2cnOyAnVjYgT3BzIExpc3QnOyAnUm9iZXJ0IFJhc3p1aydTdWJqZWN0OqBSZTogW0lk cl0gW3Y2b3BzXSBCR1AgSWRlbnRpZmllcldlIGVuZGVhdm9yIHRvIGF1dG9tYXRlIGFzIG11Y2gg YXMgcG9zc2libGUgYXMgbWFudWFsL2h1bWFuIG1hbmlwdWxhdGlvbiB1c3VhbGx5IHJlc3VsdHMg aW4gYSBiaWcgZXJyb3IgYXQgc29tZSBwb2ludC4uCqAKSmltIFV0dGFybwqgCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUmFuZHkgQnVzaApTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE3LCAyMDE0IDU6 MjYgQU0KVG86IEZhbiwgUGVuZwpDYzogJ2lkciB3Zyc7ICdWNiBPcHMgTGlzdCc7ICdSb2JlcnQg UmFzenVrJwpTdWJqZWN0OiBSZTogW0lkcl0gW3Y2b3BzXSBCR1AgSWRlbnRpZmllcgqgCj4gWWVz IHRoYXQgaXMgYSBwb3NzaWJsZSBzb2x1dGlvbiBmb3IgdHJvdWJsZXNob290aW5nLCBvbmNlIHRo ZSByb3V0ZXJfaWQgaGFzCj4gYmVlbiBkZXRlcm1pbmVkLiBCdXQgaG93IGRvIHlvdSBkZXRlcm1p bmUgYXQgZmlyc3QgdGhlIHZhbHVlIG9mIGEuYi5jLmQgd2hlbgo+IHRoZXJlIGlzIG5vIGlwdjQg YWRkcmVzcyB0byBiZSByZWZlcnJlZCB0bywgZXNwZWNpYWxseSBpbiBhbiBhdXRvbWF0aWMKPiBt YW5uZXI/IEJlZm9yZWhhbmQgcGxhbm5pbmcgd29yayBmb3IgdGhlIGlkcyBmb3IgdGhlIGVudGly ZSBuZXR3b3JrIGlzCj4gc29tZXRoaW5nIEkgYW0gY29uY2VybmVkIHdpdGggOikKoAphbGwgeW91 ciBjb21tZW50cyBhcmUgc3ltcHRvbXMgb2YgdGhlIGluc2FuaXR5IG9mIHRyeWluZyB0byBjb25m aWd1cmUgYQpsYXJnZSBuZXR3b3JrIG1hbnVhbGx5LqAgdGhpcyB3ZW50IG91dCBvZiBmYXNoaW9u IGluIHRoZSBsYXN0IGNlbnR1cnksCmFuZCB3ZSBkbyBub3QgdHJ5IHRvIGNvbXBlbnNhdGUgZm9y IGluc2FuaXR5IHRocm91Z2ggcHJvdG9jb2wKbW9kaWZpY2F0aW9uLgqgCnJhbmR5CqAKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSWRyIG1haWxpbmcgbGlz dApJZHJAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIK oApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpJZHIgbWFp bGluZyBsaXN0CklkckBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcgqgCgo= ------=_001_NextPart002576354625_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Yes we do if we could.=0A

Zhenqiang Li

=0A
 
=
Date: 2014-02-17 23:5= 2
Subject: Re: [Idr] [v6ops] BGP I= dentifier
We endeavor to automate as much as po= ssible as manual/human manipulation usually results in a big error at some= point..
=0A
 
=0A
Jim Uttaro
=0A
 =0A
-----Original Message-----
=0A
From: Idr [mailto:idr-= bounces@ietf.org] On Behalf Of Randy Bush
=0A
Sent: Monday, Febru= ary 17, 2014 5:26 AM
=0A
To: Fan, Peng
=0A
Cc: 'idr wg';= 'V6 Ops List'; 'Robert Raszuk'
=0A
Subject: Re: [Idr] [v6ops] BG= P Identifier
=0A
 
=0A
> Yes that is a possible = solution for troubleshooting, once the router_id has
=0A
> bee= n determined. But how do you determine at first the value of a.b.c.d when<= /div>=0A
> there is no ipv4 address to be referred to, especially i= n an automatic
=0A
> manner? Beforehand planning work for the = ids for the entire network is
=0A
> something I am concerned w= ith :)
=0A
 
=0A
all your comments are symptoms of = the insanity of trying to configure a
=0A
large network manually.=   this went out of fashion in the last century,
=0A
and we d= o not try to compensate for insanity through protocol
=0A
modific= ation.
=0A
 
=0A
randy
=0A
 
=0A=
_______________________________________________
=0A
Idr mail= ing list
=0A
Idr@ietf.org
=0A
https://www.ietf.org/mailm= an/listinfo/idr
=0A
 
=0A
_________________________= ______________________
=0A
Idr mailing list
=0A
Idr@ietf= .org
=0A
https://www.ietf.org/mailman/listinfo/idr
=0A
&= nbsp;
=0A
=0A ------=_001_NextPart002576354625_=------ From nobody Mon Feb 17 18:40:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047241A02E3; Mon, 17 Feb 2014 18:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_56=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvbYoOdg_F9g; Mon, 17 Feb 2014 18:40:24 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 766861A02DA; Mon, 17 Feb 2014 18:40:24 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFabY-0002qE-6a; Tue, 18 Feb 2014 02:40:16 +0000 Date: Tue, 18 Feb 2014 10:40:13 +0800 Message-ID: From: Randy Bush To: "lizhenqiang@chinamobile.com" In-Reply-To: <201402181031568885348@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/xrCcFhRThkEpjlZjuGq90VOWx7o Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 02:40:26 -0000 > Do you have such tools to config your network? Or do you know the > vendor that provide such tools?Indeed, such=A0programmatic generation > tools are good for network plan. But the logic in the tools is > complecated especially for a very large network with=A0hierarchical > operation as Peng Fan mentioned. there are products in the space, but the large providers i know who configure programatically developed their own. there are not enough large providers not suffering from 'not invented here' to make a reasonable customer base for serious software development. but it pays for itself, so smart folk who develop it. randy From nobody Mon Feb 17 18:45:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05601A0020; Mon, 17 Feb 2014 18:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.757 X-Spam-Level: X-Spam-Status: No, score=0.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 7pSzRF1Kbrl7; Mon, 17 Feb 2014 18:45:08 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A911F1A0314; Mon, 17 Feb 2014 18:45:07 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302c8b0f60-f2f60; Tue, 18 Feb 2014 10:42:56 +0800 (CST) X-RM-TRANSID: 2ee15302c8b0f60-f2f60 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302c8af046-dbc3d; Tue, 18 Feb 2014 10:42:56 +0800 (CST) X-RM-TRANSID: 2ee35302c8af046-dbc3d Date: Tue, 18 Feb 2014 10:45:07 +0800 From: "lizhenqiang@chinamobile.com" To: "Christopher Morrow" , "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com>, , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021810450694712020@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart726360527875_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_oHrAO8DP8_5iUvuw-MficEAum0 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 02:45:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart726360527875_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgoKCgoKVGhhbmsgeW91IHZlcnkgbXVjaCwgTXIuIE1vcnJvdy4KWWVzLCBpdCBpcyBhIGdvb2Qg c3RhcnQuIEkgd2lsbCBjb250YWN0IFZpamF5IGZvciBkZXRhaWwuIEhvd2V2ZXIsIEkgZG8gbm90 IHNlZSB0aGUgZnVuY3Rpb24gdGhhdCB3ZSB3YW50IGZyb20gdGhlIHNsaWRlcy4gSW4gZmFjdCwg d2UgYWxzbyB1c2Ugc29tZSB0b29scyB0byBhc3Npc3Qgb3VyIG5ldHdvcmsgcGxhbi4gSG93ZXZl ciwgdGhlIHRvb2xzIGNhbiBub3Qgc2F0aXNmeSBzdWNoIGNvbXBsZXggcmVxdWlyZW1lbnQuIElu IGHCoGhpZXJhcmNoaWNhbCBvcGVyYXRpb24gbmV0d29yaywgdGhlIHRvb2xzIHRvIGltcGxlbWVu dCB0aGUgbG9naWMgd2Ugd2FudCBpcyBub3QgYSBlYXN5IGpvYi4KWmhlbnFpYW5nIExpCgoKwqBG cm9tOsKgQ2hyaXN0b3BoZXIgTW9ycm93RGF0ZTrCoDIwMTQtMDItMTfCoDIzOjU5VG86wqBSYW5k eSBCdXNoQ0M6wqBpZHIgd2c7IFY2IE9wcyBMaXN0OyBSb2JlcnQgUmFzenVrU3ViamVjdDrCoFJl OiBbSWRyXSBbdjZvcHNdIEJHUCBJZGVudGlmaWVyaHR0cDovL3d3dy5uYW5vZy5vcmcvbWVldGlu Z3MvbmFub2c0NC9wcmVzZW50YXRpb25zL01vbmRheS9HaWxsX3Byb2dyYW1hdGljX040NC5wZGYK wqAKTWlrZSdzIHByZXNlbnRhdGlvbiAoZ2l2ZW4gYnkgdmlqYXkpIGlzIGEgZGVjZW50IHN0YXJ0 Li4uCsKgCk9uIE1vbiwgRmViIDE3LCAyMDE0IGF0IDk6NTAgQU0sIFJhbmR5IEJ1c2ggPHJhbmR5 QHBzZy5jb20+IHdyb3RlOgo+PiBXb3VsZCB5b3UgcGxlYXNlIGdpdmUgbWUgYW4gZXhhbXBsZSBh Ym91dCBob3cgbW9kZXJuIGxhcmdlIElTUHMgbWFuYWdlIHRoZWlyCj4+IG5ldHdvcmtzPwo+Cj4g cHJvZ3JhbW1hdGljIGdlbmVyYXRpb24gb2YgY29uZmlndXJhdGlvbnMgZnJvbSBkYXRhYmFzZXMu Cj4KPiByYW5keQo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiBJZHIgbWFpbGluZyBsaXN0Cj4gSWRyQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIKwqAKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KSWRyIG1haWxpbmcgbGlzdApJZHJAaWV0Zi5vcmcKaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHIKwqAKCg== ------=_001_NextPart726360527875_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
Thank you very much, Mr. Morrow.

Yes, it is a = good start. I will contact Vijay for detail. However, I do not see the fun= ction that we want from the slides. In fact, we also use some tools to ass= ist our network plan. However, the tools can not satisfy such complex requ= irement. In a hierarchical operation network, the tools to implement the log= ic we want is not a easy job.

Zhenqiang Li
=0A

=0A 
Date: 2014-02-17 23:59
Sub= ject: Re: [Idr] [v6ops] BGP Identifier
http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programat= ic_N44.pdf
=0A
 
=0A
Mike's presentation (given by = vijay) is a decent start...
=0A
 
=0A
On Mon, Feb 1= 7, 2014 at 9:50 AM, Randy Bush <randy@psg.com> wrote:
=0A
&= gt;> Would you please give me an example about how modern large ISPs ma= nage their
=0A
>> networks?
=0A
>
=0A
= > programmatic generation of configurations from databases.
=0A>
=0A
> randy
=0A
>
=0A
> _______= ________________________________________
=0A
> Idr mailing lis= t
=0A
> Idr@ietf.org
=0A
> https://www.ietf.org/ma= ilman/listinfo/idr
=0A
 
=0A
______________________= _________________________
=0A
Idr mailing list
=0A
Idr@i= etf.org
=0A
https://www.ietf.org/mailman/listinfo/idr
=0A 
=0A
=0A ------=_001_NextPart726360527875_=------ From nobody Mon Feb 17 18:51:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5687A1A02DA; Mon, 17 Feb 2014 18:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 PV8bRZ6zS4ib; Mon, 17 Feb 2014 18:51:41 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 630AB1A0309; Mon, 17 Feb 2014 18:51:39 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302ca3514f-f314f; Tue, 18 Feb 2014 10:49:26 +0800 (CST) X-RM-TRANSID: 2ee15302ca3514f-f314f Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15302ca357b8-15a94; Tue, 18 Feb 2014 10:49:26 +0800 (CST) X-RM-TRANSID: 2ee15302ca357b8-15a94 Date: Tue, 18 Feb 2014 10:51:37 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021810513701058825@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart260276176335_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sbdLbSGKwqKaOmFyxPEUqFIOPyw Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 02:51:43 -0000 This is a multi-part message in MIME format. ------=_001_NextPart260276176335_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKVGVsbCBtZSBwbGVhc2UgdGhlIGxhcmdlIHByb3ZpZGVyIHRoYXQgeW91IGtub3cgaGFz IGhpcyBvd24gYXV0b21hdGljIGNvbmZpZ3VyYXRpb24gdG9vbHMuIEkgd291bGQgbGlrZSB0byBj b250YWN0IGhpbSB0byBsZWFybiBmcm9tIGhpbS6gCgoKCmxpemhlbnFpYW5nQGNoaW5hbW9iaWxl LmNvbQqgRnJvbTqgUmFuZHkgQnVzaERhdGU6oDIwMTQtMDItMTigMTA6NDBUbzqgbGl6aGVucWlh bmdAY2hpbmFtb2JpbGUuY29tQ0M6oGZhbnBlbmc7ICdpZHIgd2cnOyAnVjYgT3BzIExpc3QnOyAn Um9iZXJ0IFJhc3p1aydTdWJqZWN0OqBSZTogW0lkcl0gW3Y2b3BzXSBCR1AgSWRlbnRpZmllcj4g RG8geW91IGhhdmUgc3VjaCB0b29scyB0byBjb25maWcgeW91ciBuZXR3b3JrPyBPciBkbyB5b3Ug a25vdyB0aGUKPiB2ZW5kb3IgdGhhdCBwcm92aWRlIHN1Y2ggdG9vbHM/SW5kZWVkLCBzdWNooHBy b2dyYW1tYXRpYyBnZW5lcmF0aW9uCj4gdG9vbHMgYXJlIGdvb2QgZm9yIG5ldHdvcmsgcGxhbi4g QnV0IHRoZSBsb2dpYyBpbiB0aGUgdG9vbHMgaXMKPiBjb21wbGVjYXRlZCBlc3BlY2lhbGx5IGZv ciBhIHZlcnkgbGFyZ2UgbmV0d29yayB3aXRooGhpZXJhcmNoaWNhbAo+IG9wZXJhdGlvbiBhcyBQ ZW5nIEZhbiBtZW50aW9uZWQuCqAKdGhlcmUgYXJlIHByb2R1Y3RzIGluIHRoZSBzcGFjZSwgYnV0 IHRoZSBsYXJnZSBwcm92aWRlcnMgaSBrbm93IHdobwpjb25maWd1cmUgcHJvZ3JhbWF0aWNhbGx5 IGRldmVsb3BlZCB0aGVpciBvd24uoCB0aGVyZSBhcmUgbm90IGVub3VnaApsYXJnZSBwcm92aWRl cnMgbm90IHN1ZmZlcmluZyBmcm9tICdub3QgaW52ZW50ZWQgaGVyZScgdG8gbWFrZSBhCnJlYXNv bmFibGUgY3VzdG9tZXIgYmFzZSBmb3Igc2VyaW91cyBzb2Z0d2FyZSBkZXZlbG9wbWVudC4KoApi dXQgaXQgcGF5cyBmb3IgaXRzZWxmLCBzbyBzbWFydCBmb2xrIHdobyBkZXZlbG9wIGl0LgqgCnJh bmR5CqAKCg== ------=_001_NextPart260276176335_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Tell me please the large= provider that you know has his own automatic configuration tools. I would= like to contact him to learn from him. 
=0A
=0A
=0A
lizhenqiang@chinamobile.com
=0A=
 
From: Randy Bush
Date: 20= 14-02-18 10:40
Subject: Re: [Idr] [v6ops] BGP Identifier
=
> Do you have such tools to config your network? Or do you kn= ow the
=0A
> vendor that provide such tools?Indeed, such = programmatic generation
=0A
> tools are good for network plan.= But the logic in the tools is
=0A
> complecated especially fo= r a very large network with hierarchical
=0A
> operation = as Peng Fan mentioned.
=0A
 
=0A
there are products= in the space, but the large providers i know who
=0A
configure p= rogramatically developed their own.  there are not enough
=0Alarge providers not suffering from 'not invented here' to make a
= =0A
reasonable customer base for serious software development.
= =0A
 
=0A
but it pays for itself, so smart folk who deve= lop it.
=0A
 
=0A
randy
=0A
 
= =0A=0A ------=_001_NextPart260276176335_=------ From nobody Mon Feb 17 19:17:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C791A1A0314 for ; Mon, 17 Feb 2014 19:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 DHeO7rCRM-fy for ; Mon, 17 Feb 2014 19:16:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 293061A030F for ; Mon, 17 Feb 2014 19:16:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBF78652; Tue, 18 Feb 2014 03:16:51 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 03:16:41 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 03:16:49 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 11:16:45 +0800 From: "Liubing (Leo)" To: Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt Thread-Index: AQHPKWgMo43RzbooVkmZSkAdeWvl75qz/igAgAD96wCAAR80gIAEMQZw Date: Tue, 18 Feb 2014 03:16:44 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8357DD@nkgeml506-mbx.china.huawei.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> In-Reply-To: <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yWWmreGisYaXfcozPQUMXuMSyEU Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:17:00 -0000 Hi Owen, Thanks for your suggestion. > Indeed, the situations where ULA usage is detrimental vastly outnumbers > those where it is actually beneficial. >=20 > If we're going to move something like this forward, that really should be > made clear. [Bing] The main content of the draft is:=20 - provide neutral pros/cons analysis and operational considerations for the= ULA usage cases. (I think the cons and some operational considerations cou= ld cover what you meant "detrimental") - eliminate the misunderstanding of ULA=3D1918 and recommend some use cases= that we thought ULAs could be mostly beneficial (that's the main goal of t= his draft) Best regards, Bing =20 > Owen >=20 > On Feb 14, 2014, at 17:08 , Brian E Carpenter > wrote: >=20 > > Well, there have always been some people against the existence of > > ULAs, but we did reach rough consensus to define them, since other > > people see value in them, for reasons that have been aired many times. > > So writing words about the best way to use them if you want to use > > them seems right to me. > > > > Brian > > > > On 14/02/2014 23:00, ek wrote: > >> +1 > >> > >> ---- On Fri, 14 Feb 2014 18:34:36 +0900 Randy > >> Bush<randy@psg.com> wrote ---- > >> > >> > >> i expected this to be a short draft. "Don't" > >> > >> randy > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 17 19:17:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD071A0324; Mon, 17 Feb 2014 19:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuA7PNieCAYV; Mon, 17 Feb 2014 19:17:21 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD551A0309; Mon, 17 Feb 2014 19:17:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFbBJ-0002xU-TQ; Tue, 18 Feb 2014 03:17:15 +0000 Date: Tue, 18 Feb 2014 11:17:11 +0800 Message-ID: From: Randy Bush To: "lizhenqiang@chinamobile.com" In-Reply-To: <2014021810513701058825@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8ii-pjPGrhrXq3F4JdPgxc6Am6k Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 03:17:23 -0000 > Tell me please the large provider that you know has his own automatic > configuration tools. l(3), ntt, ... > I would like to contact him to learn from him.=A0 it is considered secret sauce randy From nobody Mon Feb 17 19:33:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C6A1A0274; Sat, 15 Feb 2014 10:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_FROM=2.3, NORMAL_HTTP_TO_IP=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 SVxl5IRQVpbl; Sat, 15 Feb 2014 10:37:49 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD01A026E; Sat, 15 Feb 2014 10:37:49 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id l4so10138940lbv.38 for ; Sat, 15 Feb 2014 10:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=e03H8yrtuHfpXKfPuUMvx9LCVdLWHB5BjRQWsREgUE8=; b=MtsN1Po/2wz2aa5TnpcIQHr8qdJEvHqNOhBmaOQLZ5F15bxL0R1ZFHhNFtA5JZEm3Q 6TkhMBwQbNYkDmt+MCcyc3Mbml5mhOG/NTIVmIK96vEMwcXs4t0dj5B+q7duVJqb7IIH eJE/aQC+p37tc2ecaPFRJV6n9IPhVfOsQF1IRIEfo7151qHvFBxRQg8AAhFRGj5juJoj gKL4H0ai9Nov5d6cdyEmRJUUMYF4mEvWf9JOGEp8FKT8z6VUC7pCm2ZzxOdtTmkjvxTx 8yGwmVEJtFLqyJUVkRKVJsnP8HhEZB9IQ+JyzQS263S3LqB/NHjNS/fobfFc5KFmPE1/ 3+7Q== MIME-Version: 1.0 X-Received: by 10.112.114.228 with SMTP id jj4mr10121916lbb.13.1392489466570; Sat, 15 Feb 2014 10:37:46 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.203.167 with HTTP; Sat, 15 Feb 2014 10:37:46 -0800 (PST) In-Reply-To: <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net> Date: Sat, 15 Feb 2014 13:37:46 -0500 X-Google-Sender-Auth: GD4lSzvTplg_64EcysF3ZqR-_Wo Message-ID: From: Christopher Morrow To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z1hj64vsfZ5XJnskWSeRUdofyfI X-Mailman-Approved-At: Mon, 17 Feb 2014 19:33:44 -0800 Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Feb 2014 18:37:51 -0000 On Sat, Feb 15, 2014 at 10:53 AM, Shane Amante wrot= e: >> And what does an integer called ROUTER_ID tell you about that? > > In my past experience, I have found that -- particularly in new networks = that I'm unfamiliar with -- looking at the output of "show (ospf|isis) data= base extensive", finding a ROUTER_ID that originated the LSA/LSPDU and perf= orming a ping and/or traceroute to it to verify the sanity of where in the = topology that ROUTER_ID is located has been helpful in rapidly diagnosing a= nd fixing brokenness. Yes, I will admit that it is not a panacea (i.e.: it= does not help in the case of duplicate ROUTER_ID's), but 99% of the time i= t's often using that information to figure out where traffic is, or is not,= going to. > for isis I think unique router-id is important (at least inside the same level? or perhaps I'm just thinking that changing the router-id is a ted update event.) but for bgp it seems less important (aside from the troubleshooting you outline). I imagine it'd actually be nice to be able to set a router-id externally and a different one internally actually. This could have some fun implications really... 'my router-id everywhere is 1!' (or zero) >> And hey, you can always create records like >> 1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoin= t.net > > And, when your DNS server is unreachable because you've got a network iss= ue, what then? you could, of course, replace 'dns' with any other separated mapping system (say a text file in the least complex setup). This does add more work for O&M though, which is probably bad :( extra record keeping isn't particularly good... I wonder though what's going to happen if you don't have ipv4 on the network anylonger, and have no need for ipv4 identifiers? do you just keep numbering the router-id from "some ipv4 space" or do we have to look at updating bgp to have a router-id (and isis and ospf and...) that's more than just 32 random bits that happen to look like an ip address? -chris From nobody Mon Feb 17 19:33:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBCB1A00E6; Sun, 16 Feb 2014 08:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548, T_FILL_THIS_FORM_SHORT=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 bYvDWbuYyZtR; Sun, 16 Feb 2014 08:28:39 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id C56961A002C; Sun, 16 Feb 2014 08:28:38 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25300e6ac8e3-308e3; Mon, 17 Feb 2014 00:26:21 +0800 (CST) X-RM-TRANSID: 2ee25300e6ac8e3-308e3 Received: from X6X8D79D8F49E2 (unknown[125.97.246.90]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35300e6ac00d-b4a6e; Mon, 17 Feb 2014 00:26:21 +0800 (CST) X-RM-TRANSID: 2ee35300e6ac00d-b4a6e From: "Fan, Peng" To: "'Randy Bush'" , "'Fred Baker'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> In-Reply-To: Date: Mon, 17 Feb 2014 00:28:32 +0800 Message-ID: <006801cf2b34$22837cd0$678a7670$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QG64jb+mS7we9A= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/DF6_NV2Fk9I2Vjc2jAsAi9qbtcI X-Mailman-Approved-At: Mon, 17 Feb 2014 19:33:44 -0800 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Feb 2014 16:28:42 -0000 Hi Randy, and all, Thanks for the discussion and sorry for the late. Assigning an id is not a difficult issue, especially on a single router. But what number is to be assigned might be an issue, especially in an ISP's large network, in order to guarantee the uniqueness of the ids. In our network this kind of numeric resources, e.g. IP addresses and cell phone numbers, is planned in advance (usually with a careful designed numbering rule), and then delivered to admins who located at different parts of the network. In the IPv4 world, we take advantage of an IPv4 address, as it by nature an ideal id and fits into the 32-bit length, and could be helpful in OAM. So perhaps we can use a similar approach in an IPv6-only world, then the admins don't have to bother to worry how to choose the ids. An id is not necessarily an IP address, but IP address is a perfect candidate for an id. Thanks and regards, Peng > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush > Sent: Friday, February 14, 2014 2:52 PM > To: Fred Baker > Cc: idr wg; V6 Ops List > Subject: Re: [Idr] [v6ops] BGP Identifier > > > http://tools.ietf.org/html/draft-fan-idr-ipv6-bgp-id > > "IPv6 BGP Identifier Capability for BGP-4", Peng Fan, Zhenqiang Li, > > 2014-02-12 > > please no. if you can not assign a unique four octet integer to each router in > your network, then you have much bigger problems. and adding a capability > and more complexity to try to patch over your inability to configure your routers > will just compound your problems. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Feb 17 19:33:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C71A0502; Mon, 17 Feb 2014 07:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxV09VfoIYPE; Mon, 17 Feb 2014 07:53:49 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 818091A0507; Mon, 17 Feb 2014 07:53:49 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id b8032035.2ac0d0052940.2848596.00-2437.7947596.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:53:47 +0000 (UTC) X-MXL-Hash: 5302308b42ac272f-7ef366ae0b5dc6619311f68523019213c1665cb8 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id d6032035.0.2848356.00-2179.7946900.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 17 Feb 2014 15:53:18 +0000 (UTC) X-MXL-Hash: 5302306e628e96f1-88ebdcbe81aed40c2e5a9316f523ae7dd22fc697 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HFrGDv003001; Mon, 17 Feb 2014 10:53:16 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1HFr7cC002787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Feb 2014 10:53:12 -0500 Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 17 Feb 2014 15:52:55 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Mon, 17 Feb 2014 10:52:54 -0500 From: "UTTARO, JAMES" To: Randy Bush , "Fan, Peng" Thread-Topic: [Idr] [v6ops] BGP Identifier Thread-Index: AQHPK4HukH+sv9yQ+kSGj1ZIvBEoEZq5ExoAgABt7ACAAAzhgIAABBwAgAAHYcA= Date: Mon, 17 Feb 2014 15:52:53 +0000 Message-ID: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.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.53.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=Ml6WOlLKuc4A:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e_BCuZGg8] X-AnalysisOut: [NsA:10 a=48vgC7mUAAAA:8 a=yyzX4cs7Mzi1HQJBC4AA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=WEfm6-8eHTEN4XfZ:21 a=IFZ0Xh6] X-AnalysisOut: [NAL3Oz8jK:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-9hbeVRMPwjeuS9aF0koZK-mGJo X-Mailman-Approved-At: Mon, 17 Feb 2014 19:33:44 -0800 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 15:53:51 -0000 We endeavor to automate as much as possible as manual/human manipulation us= ually results in a big error at some point.. Jim Uttaro -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Monday, February 17, 2014 5:26 AM To: Fan, Peng Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier > Yes that is a possible solution for troubleshooting, once the router_id h= as > been determined. But how do you determine at first the value of a.b.c.d w= hen > there is no ipv4 address to be referred to, especially in an automatic > manner? Beforehand planning work for the ids for the entire network is > something I am concerned with :) all your comments are symptoms of the insanity of trying to configure a large network manually. this went out of fashion in the last century, and we do not try to compensate for insanity through protocol modification. randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Feb 17 19:33:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D1B1A03D2; Mon, 17 Feb 2014 07:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgYBXUeJEO21; Mon, 17 Feb 2014 07:59:55 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2101A022E; Mon, 17 Feb 2014 07:59:55 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id hr17so11388842lab.34 for ; Mon, 17 Feb 2014 07:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qOg25b84tv23NsrWm0J+cA8WIXJCWhmBtBifp+CXfSw=; b=BBmqz5JQ4cV4ko+ngmjh+jniK9K4tVc2ZXLnorBwqhSCDfnPTDEdiIua6Cd7G4XzmD ZCCZCWSnOV4FBzt9ckDnYkkbtIWxo5w+RMC0ZJPaiKLYlBeHGcbf1whS1qR4YG2odelB wfmM3xcTYzfcQf5riwM5X3ZvY/cApgA4Iqc//mxOvEP7K7++3FYnV1etoFoWZ15Hunys MwSDcvzBiYTN6IdUgHB/UOOxD2/AqIWyBGBfMsLlV8pURkHLChI/iI9jL5i8lqP5T6yp q/9C2DsF9ZsDI/++XSZKPkgXoqcxmHxYdjaY/pNF89NUQ5VjQhSZgz+wb3BJ0prkRXlT KP7g== MIME-Version: 1.0 X-Received: by 10.152.207.37 with SMTP id lt5mr25143lac.90.1392652791770; Mon, 17 Feb 2014 07:59:51 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.203.167 with HTTP; Mon, 17 Feb 2014 07:59:51 -0800 (PST) In-Reply-To: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> Date: Mon, 17 Feb 2014 10:59:51 -0500 X-Google-Sender-Auth: qEuZZACTHTb-pt1Uz43LiFphlcg Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Oc8FhAxPU7EEo_n0kmBbuRpiYdI X-Mailman-Approved-At: Mon, 17 Feb 2014 19:33:44 -0800 Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Feb 2014 15:59:57 -0000 http://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf Mike's presentation (given by vijay) is a decent start... On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: >> Would you please give me an example about how modern large ISPs manage their >> networks? > > programmatic generation of configurations from databases. > > randy > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Feb 17 19:33:54 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54C1A0324; Mon, 17 Feb 2014 19:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.224 X-Spam-Level: X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_BIG_TO_CC=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 DyOi0aeDQ55l; Mon, 17 Feb 2014 19:31:15 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 167E11A02CC; Mon, 17 Feb 2014 19:31:12 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302d371cc7-f3cc7; Tue, 18 Feb 2014 11:28:49 +0800 (CST) X-RM-TRANSID: 2ee15302d371cc7-f3cc7 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302d36ef31-dcc4e; Tue, 18 Feb 2014 11:28:49 +0800 (CST) X-RM-TRANSID: 2ee35302d36ef31-dcc4e Date: Tue, 18 Feb 2014 11:30:59 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" , Farmer , jaeggli , Amante , Morrow , JAMES , Doering , Raszuk' References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021811305909988540@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart655784812418_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tkQJ2s1XujnS_mgwpDqneqND1RM X-Mailman-Approved-At: Mon, 17 Feb 2014 19:33:44 -0800 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 03:31:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart655784812418_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKSGkgQWxsLApUaGFuayB5b3UgYWxsIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzIGFu ZCBpbnRlcmVzdHMgaW4gdGhpcyBkcmFmdC6gQW55IHRlY2huaWNhbCBjb25jZXJucyBhYm91dCB0 aGUgZHJhZnQ/IElzIHRoZXJlIHNvbWVvbmUgaW4gdGhlIG1haWwgbGlzdCBmcm9tIG9wZXJhdG9y cyB0aGF0IGhhcyB0aGUgc2FtZSBwcm9ibGVtIGFzIG1lPwpNYW55IFRoYW5rcyxaaGVucWlhbmcg TGkKCgoKCgoK ------=_001_NextPart655784812418_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi All,

Thank you all for your valuable comments and interests in this dr= aft. 
Any technical concerns about the draft? Is there some= one in the mail list from operators that has the same problem as me?
=

Many Thanks,
Zhenqiang Li
=0A

<= /div>
=0A
=0A

=0A
=0A ------=_001_NextPart655784812418_=------ From nobody Mon Feb 17 19:34:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417BA1A05E9; Mon, 17 Feb 2014 19:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 XFva6gkiYfFo; Mon, 17 Feb 2014 19:33:50 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 6570E1A0309; Mon, 17 Feb 2014 19:33:45 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25302d41574b-5274b; Tue, 18 Feb 2014 11:31:33 +0800 (CST) X-RM-TRANSID: 2ee25302d41574b-5274b Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15302d4101b3-1656d; Tue, 18 Feb 2014 11:31:33 +0800 (CST) X-RM-TRANSID: 2ee15302d4101b3-1656d Date: Tue, 18 Feb 2014 11:33:44 +0800 From: "lizhenqiang@chinamobile.com" To: "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <2014021811334398232342@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart745706857634_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/2vbbWVwmywLqeDRz2JxdaMiqhoE Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 03:33:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart745706857634_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKU28gSSBoYXZlIHRvIGxlYXJuIHRvIHByb2dyYW0gbm93LiBJIGhvcGUgd2UgY291bGQg ZGV2ZWxvcCBvdXIgb3duIHRvb2xzLgoKCgpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20KoEZy b206oFJhbmR5IEJ1c2hEYXRlOqAyMDE0LTAyLTE4oDExOjE3VG86oGxpemhlbnFpYW5nQGNoaW5h bW9iaWxlLmNvbUNDOqBmYW5wZW5nOyAnaWRyIHdnJzsgJ1Y2IE9wcyBMaXN0JzsgJ1JvYmVydCBS YXN6dWsnU3ViamVjdDqgUmU6IFtJZHJdIFt2Nm9wc10gQkdQIElkZW50aWZpZXI+IFRlbGwgbWUg cGxlYXNlIHRoZSBsYXJnZSBwcm92aWRlciB0aGF0IHlvdSBrbm93IGhhcyBoaXMgb3duIGF1dG9t YXRpYwo+IGNvbmZpZ3VyYXRpb24gdG9vbHMuCqAKbCgzKSwgbnR0LCAuLi4KoAo+IEkgd291bGQg bGlrZSB0byBjb250YWN0IGhpbSB0byBsZWFybiBmcm9tIGhpbS6gCqAKaXQgaXMgY29uc2lkZXJl ZCBzZWNyZXQgc2F1Y2UKoApyYW5keQqgCgo= ------=_001_NextPart745706857634_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
So I have to learn to pr= ogram now. I hope we could develop our own tools.
=0A

<= hr style=3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align= =3D"left">=0A
=0A
lizhenqiang@chinamobile.com
=0A 
From: Randy Bush
Date: 2014-02-18=  11:17
Su= bject: Re: [Idr] [v6ops] BGP Identifier
> Tell me please the large provider that you know has his own automat= ic
=0A
> configuration tools.
=0A
 
=0Al(3), ntt, ...
=0A
 
=0A
> I would like to cont= act him to learn from him. 
=0A
 
=0A
it is co= nsidered secret sauce
=0A
 
=0A
randy
=0A
=  
=0A=0A ------=_001_NextPart745706857634_=------ From nobody Mon Feb 17 19:42:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5771A02FD for ; Mon, 17 Feb 2014 19:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 TlCX8cIzutDf for ; Mon, 17 Feb 2014 19:42:30 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC31A02CC for ; Mon, 17 Feb 2014 19:42:29 -0800 (PST) Received: from [10.5.16.25] (adsl-69-228-83-127.dsl.pltn13.pacbell.net [69.228.83.127]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1I3d2Gj031150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Feb 2014 19:39:05 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1I3d2Gj031150 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392694748; bh=PnWfb/RhWJ6MQzXdrTgimScSivI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nepH5w8Phnclg7NLZ3I5ug1o8ibpj8ViuroN8xAJ5ZcplJe3+X+LEOCEMF2z5yyE1 jjdC95S7P6bjpM5286j+VnSSrH5pQjwVQ9rxFXowyAtsvUN9RudhUmyTqUlYTbrSoD 4xeZN198LcywkID9axvDMhHhkx5xYveM1pg0ri/k= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <530242C3.4070108@bogus.com> Date: Mon, 17 Feb 2014 19:39:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 17 Feb 2014 19:39:08 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/MT9Q8wg59f30rGplctPvN015fag Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 03:42:32 -0000 On Feb 17, 2014, at 9:11 AM, joel jaeggli wrote: > On 2/17/14, 8:38 AM, Ted Lemon wrote: >> On Feb 17, 2014, at 9:35 AM, Owen DeLong wrote: >>> Cases that propose NPT, NAT, or other translation mechanisms are >>> examples where it is detrimental. >>=20 >> This is clearly true, but we can't do much about it other than to >> encourage people to avoid this, and help them to avoid it by giving >> them alternatives. >>=20 >>> Cases where it ends up getting routed amongst "cooperating" parties >>> are likely to eventually lead to detrimental usage because the >>> natural trend is for them to become increasingly routed across more >>> and more ASNs and eventually to become a form of de facto >>> registered address space not administered by any structured or >>> reliable registry and without any form of community based policy >>> process (such as the current RIRs). >>=20 >> This is a fun doomsday scenario, but we don't have this with RFC 1918 >> addresses today; why would we have it with ULAs tomorrow? >=20 > we route rfc 1918 between cooperating parties today. as noted it > requires coordination and is painful. >=20 >> In fact, >> ULAs fix one of the really big problems with RFC 1918 addresses: >> there are so few of the latter that when two corporations that use >> RFC 1918 numbering internally merge, you have a really bad >> renumbering problem, and wind up doing more NATs than you otherwise >> would have. >=20 > what consenting adults do within the privacy of their own asns is = really > none of my business. >=20 > If widely deployed in an uncoordinated fashion it becomes toxic for > globally coordinated use, which precludes owen's scenario. the fact = that > we have 41 bits instead of 23.5 doesn't really obviate that. >=20 I would argue that the current situation with RFC-1918 proves that with additional bits (it=92s 105, not 41), it is, in fact possible for people = to do really bad things which later merge after it is too late. >> So I think this use case is one where ULAs actually do really well. >>=20 >> Do you have some reason for thinking that your doomsday scenario is >> likely, or is it sufficient to you that it's possible, and therefore >> you want to avoid it? Yes. Case in point, the observed leakage of RFC-1918 into various parts of = the internet, the deliberate routing of boron space among several cooperating entities = that I have observed over my career (I can=92t name names due to NDA, but a very = large Telco is using 100.0.0.0/8 for the VOIP interactions and demanding that their = suppliers route that network with them, for example). Given the history of what happens with uncoordinated space in IPv4, = legitimately or otherwise, I have no reason to believe that ULA isn=92t simply a larger, = less inconvenient opportunity to create a much larger problem of the same form without any = of the inherent drawbacks and limitations which prevented RFC-1918 from getting = truly out of hand. Owen From nobody Mon Feb 17 19:55:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9E81A030F; Mon, 17 Feb 2014 19:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_622q1Of9kl; Mon, 17 Feb 2014 19:55:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EF1A0129; Mon, 17 Feb 2014 19:55:09 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1I3t1Qa055188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 03:55:01 GMT (envelope-from joelja@bogus.com) Message-ID: <5302D994.1030801@bogus.com> Date: Mon, 17 Feb 2014 19:55:00 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: "lizhenqiang@chinamobile.com" , Christopher Morrow , Randy Bush References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, , <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, , <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, , <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com>, , <2014021810450694712020@chinamobile.com> In-Reply-To: <2014021810450694712020@chinamobile.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Feb 2014 03:55:02 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5WrBG9D7JnH7-rOwwRwKSSw33RY Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 03:55:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wrote: >=20 >=20 >=20 >=20 >=20 >=20 > Thank you very much, Mr. Morrow. Yes, it is a good start. I will > contact Vijay for detail. However, I do not see the function that we > want from the slides. In fact, we also use some tools to assist our > network plan. However, the tools can not satisfy such complex > requirement. In a hierarchical operation network, the tools to > implement the logic we want is not a easy job. Zhenqiang Li We allocate ipv4 addresses today presumably, which implies the existence of business logic in basically all isps that accounts for the hierarchic allocation of 32 bit numbers. A brief cruise over to http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xht= ml Reveals a pool of at least 28 bits (a /4 in ipv4 land) worth of 32bit numbers that will never overlap with ipv4 unicast address assignments that you traditionally use for router-ids. embedding those in family iso addresses if you like seems harmless and you'll never accidentally configure one as a unicast address on an interface. it'll be a little while before I need 268 million bgp speaking routers in the same AS. >=20 > From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr > wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP > Identifierhttp://www.nanog.org/meetings/nanog44/presentations/Monday/Gi= ll_programatic_N44.pdf > > Mike's presentation (given by vijay) is a decent start... >=20 > On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: >>> Would you please give me an example about how modern large ISPs >>> manage their networks? >>=20 >> programmatic generation of configurations from databases. >>=20 >> randy >>=20 >> _______________________________________________ Idr mailing list=20 >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ Idr mailing list=20 > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >=20 >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 --neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMC2ZQACgkQ8AA1q7Z/VrJvLQCZAQ/rXdlRwA0wXsWzmiyz52pu qf8AoIcznighze83qe+VZuha4D98VlTi =VZ2G -----END PGP SIGNATURE----- --neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk-- From nobody Mon Feb 17 20:12:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787351A0331 for ; Mon, 17 Feb 2014 20:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2_GDYSnsrB2 for ; Mon, 17 Feb 2014 20:12:19 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id E0BBB1A030F for ; Mon, 17 Feb 2014 20:12:18 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so16234172pbb.29 for ; Mon, 17 Feb 2014 20:12:16 -0800 (PST) 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=yqgmQL1h/TgQqpDFEudTHTmxRGOJk109/EUAFzkrvYk=; b=RmLhyJ2RWpvsuA75T7BflEiqn3ZZmMGhKdN+kgtSDlmcJnrxIZor+Pz3E20lUQ65hf n9v48N2tp4Nb2Jtmz9zhdq3hjwBbB9HAHheq2I5e5xiaEBZ5T1TFfkfF6bID1xzFR3+6 BYOpuNgvlNUPqWc1v0lSrJBFJ7BeySmQu1YL7ENiVWrJ0SnWIRdd5kes+II8BldxLgFT IkL/F7Cw1ByuLAK9e+cDIQdUSMJuiH/fw3usVFP+v4Y5+28rRHkdlqpIYUSdBx/nlTVp zYkRzRrj7ol9tc8L+3GdUfRSjiXcOkTedTYM7527SIfh5L0vw/o0hAF4QT6/eQLwZYaA yfCg== X-Gm-Message-State: ALoCoQl6ZK0PYH9Wv7VNiG4A546GXhjwNXU0FzjEtrRFbkalZZJAfqXUEdjTqN8B0sEcDOwAy1NA MIME-Version: 1.0 X-Received: by 10.66.176.143 with SMTP id ci15mr30390904pac.35.1392696736231; Mon, 17 Feb 2014 20:12:16 -0800 (PST) Received: by 10.70.88.203 with HTTP; Mon, 17 Feb 2014 20:12:16 -0800 (PST) X-Originating-IP: [2001:dc0:a000:4:7c40:c788:ae6f:c53c] In-Reply-To: <5302D994.1030801@bogus.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> <2014021810450694712020@chinamobile.com> <5302D994.1030801@bogus.com> Date: Tue, 18 Feb 2014 14:12:16 +1000 Message-ID: From: George Michaelson To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7bd751603e482e04f2a67a89 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7IuqM7vnSeEM99TcHe374fpx1iM Cc: idr wg , V6 Ops List , Christopher Morrow Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 04:12:21 -0000 --047d7bd751603e482e04f2a67a89 Content-Type: text/plain; charset=ISO-8859-1 240/4 had drafts against it. NEVER is alas, not a normative word in what Joel said. Juniper already includes a flag to use 240/4 in cloud, at the request of a cloud services company. On Tue, Feb 18, 2014 at 1:55 PM, joel jaeggli wrote: > On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wrote: > > > > > > > > > > > > > > Thank you very much, Mr. Morrow. Yes, it is a good start. I will > > contact Vijay for detail. However, I do not see the function that we > > want from the slides. In fact, we also use some tools to assist our > > network plan. However, the tools can not satisfy such complex > > requirement. In a hierarchical operation network, the tools to > > implement the logic we want is not a easy job. Zhenqiang Li > > We allocate ipv4 addresses today presumably, which implies the existence > of business logic in basically all isps that accounts for the hierarchic > allocation of 32 bit numbers. > > A brief cruise over to > > http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml > > Reveals a pool of at least 28 bits (a /4 in ipv4 land) worth of 32bit > numbers that will never overlap with ipv4 unicast address assignments > that you traditionally use for router-ids. embedding those in family iso > addresses if you like seems harmless and you'll never accidentally > configure one as a unicast address on an interface. it'll be a little > while before I need 268 million bgp speaking routers in the same AS. > > > > > > From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr > > wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP > > Identifierhttp:// > www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf > > > > Mike's presentation (given by vijay) is a decent start... > > > > On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: > >>> Would you please give me an example about how modern large ISPs > >>> manage their networks? > >> > >> programmatic generation of configurations from databases. > >> > >> randy > >> > >> _______________________________________________ Idr mailing list > >> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ Idr mailing list > > Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr > > > > > > > > > > _______________________________________________ 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 > > --047d7bd751603e482e04f2a67a89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
240/4 had drafts against it. NEVER is alas, not a normativ= e word in what Joel said.

Juniper already includes a fla= g to use 240/4 in cloud, at the request of a cloud services company.


On Tue,= Feb 18, 2014 at 1:55 PM, joel jaeggli <joelja@bogus.com> wro= te:
On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wro= te:
>
>
>
>
>
>
> Thank you very much, Mr. Morrow. Yes, it is a good start. I will
> contact Vijay for detail. However, I do not see the function that we > want from the slides. In fact, we also use some tools to assist our > network plan. However, the tools can not satisfy such complex
> requirement. In a hierarchical operation network, the tools to
> implement the logic we want is not a easy job. Zhenqiang Li

We allocate ipv4 addresses today presumably, which implies the existe= nce
of business logic in basically all isps that accounts for the hierarchic allocation of 32 bit numbers.

A brief cruise over to

http://www.iana.org/assignments/ipv4-address= -space/ipv4-address-space.xhtml

Reveals a pool of =A0at least 28 bits (a /4 in ipv4 land) worth of 32bit numbers that will never overlap with ipv4 unicast address assignments
that you traditionally use for router-ids. embedding those in family iso addresses if you like seems harmless and you'll never accidentally
configure one as a unicast address on an interface. it'll be a little while before I need 268 million bgp speaking routers in the same AS.


>
> From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr
> wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6op= s] BGP
> Identifierhttp://www.nano= g.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf
>
> =A0Mike's presentation (given by vijay) is a decent start...
>
> On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush <randy@psg.com> wrote:
>>> Would you please give me an example about how modern large ISP= s
>>> manage their networks?
>>
>> programmatic generation of configurations from databases.
>>
>> randy
>>
>> _______________________________________________ Idr mailing list >> Idr@ietf.org https://www.ietf.org= /mailman/listinfo/idr
>
> _______________________________________________ Idr mailing list
> Idr@ietf.org https://www.ietf.org/mai= lman/listinfo/idr
>
>
>
>
> ________________________= _______________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.o= rg/mailman/listinfo/v6ops
>



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


--047d7bd751603e482e04f2a67a89-- From nobody Mon Feb 17 20:35:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7861F1A055A; Mon, 17 Feb 2014 20:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0wtm_UtSavH; Mon, 17 Feb 2014 20:35:04 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07F7C1A04B7; Mon, 17 Feb 2014 20:35:04 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1I4LNtp055332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 04:21:23 GMT (envelope-from joelja@bogus.com) Message-ID: <5302DFBD.1090105@bogus.com> Date: Mon, 17 Feb 2014 20:21:17 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: George Michaelson References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com> <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com> <2014021810450694712020@chinamobile.com> <5302D994.1030801@bogus.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Feb 2014 04:21:24 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ERQbKGtIN5aIH-50vEbTNgBpFlk Cc: idr wg , V6 Ops List , Christopher Morrow Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 04:35:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/17/14, 8:12 PM, George Michaelson wrote: > 240/4 had drafts against it. NEVER is alas, not a normative word in wha= t > Joel said. I was refering to 224/4 which has a fairly toxic property with respect to it's reuse as ipv4 unicast... > Juniper already includes a flag to use 240/4 in cloud, at the request o= f a > cloud services company. yup... >=20 > On Tue, Feb 18, 2014 at 1:55 PM, joel jaeggli wrote:= >=20 >> On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wrote: >>> >>> >>> >>> >>> >>> >>> Thank you very much, Mr. Morrow. Yes, it is a good start. I will >>> contact Vijay for detail. However, I do not see the function that we >>> want from the slides. In fact, we also use some tools to assist our >>> network plan. However, the tools can not satisfy such complex >>> requirement. In a hierarchical operation network, the tools to >>> implement the logic we want is not a easy job. Zhenqiang Li >> >> We allocate ipv4 addresses today presumably, which implies the existen= ce >> of business logic in basically all isps that accounts for the hierarch= ic >> allocation of 32 bit numbers. >> >> A brief cruise over to >> >> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.= xhtml >> >> Reveals a pool of at least 28 bits (a /4 in ipv4 land) worth of 32bit= >> numbers that will never overlap with ipv4 unicast address assignments >> that you traditionally use for router-ids. embedding those in family i= so >> addresses if you like seems harmless and you'll never accidentally >> configure one as a unicast address on an interface. it'll be a little >> while before I need 268 million bgp speaking routers in the same AS. >> >> >>> >>> From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr >>> wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP >>> Identifierhttp:// >> www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N= 44.pdf >>> >>> Mike's presentation (given by vijay) is a decent start... >>> >>> On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush wrote: >>>>> Would you please give me an example about how modern large ISPs >>>>> manage their networks? >>>> >>>> programmatic generation of configurations from databases. >>>> >>>> randy >>>> >>>> _______________________________________________ Idr mailing list >>>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>> >>> _______________________________________________ Idr mailing list >>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr >>> >>> >>> >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >=20 --2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMC370ACgkQ8AA1q7Z/VrKl7gCfXwpsK0vHthY0GTmMUa8f67z+ /MAAnA+ETxIWnNC1kpzPUXbLuOx6GdxL =H9BK -----END PGP SIGNATURE----- --2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI-- From nobody Mon Feb 17 20:44:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FC11A05ED; Mon, 17 Feb 2014 20:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVPD9v2zT7ix; Mon, 17 Feb 2014 20:43:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A31A05EB; Mon, 17 Feb 2014 20:43:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFcX7-00038T-8F; Tue, 18 Feb 2014 04:43:49 +0000 Date: Tue, 18 Feb 2014 12:43:46 +0800 Message-ID: From: Randy Bush To: "Fan, Peng" In-Reply-To: <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <006801cf2b34$22837cd0$678a7670$@chinamobile.com> <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/n6NFzBEYzyeM1YBFDHnfLXPihE4 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 04:44:00 -0000 > Just to clarify. I am not complaining we cannot assign the unique integers, > but the integers require additional planning but 32 bit integers should require only 1/4 the planning as 128 bit integers :) you allocate v4/v6 addresses hierarchically. so take 240/whatever and allocate using the same system. randy From nobody Mon Feb 17 22:08:37 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8121A05FD; Mon, 17 Feb 2014 22:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 8GoVOyozubEa; Mon, 17 Feb 2014 22:08:22 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A58CC1A03E7; Mon, 17 Feb 2014 22:08:21 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15302f84b6ad-f66ad; Tue, 18 Feb 2014 14:06:03 +0800 (CST) X-RM-TRANSID: 2ee15302f84b6ad-f66ad Received: from X6X8D79D8F49E2 (unknown[10.2.43.104]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee25302f84b837-f786b; Tue, 18 Feb 2014 14:06:03 +0800 (CST) X-RM-TRANSID: 2ee25302f84b837-f786b From: "Fan, Peng" To: "'Christopher Morrow'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> In-Reply-To: Date: Tue, 18 Feb 2014 14:09:30 +0800 Message-ID: <00dc01cf2c6f$fcce3c40$f66ab4c0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QKQBeNnAdstUIkBXjGXJpkRA7Iw Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/IupipvShwk07h9Jb4-SJc10E5og Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 06:08:26 -0000 Hi Christopher, Normally it is easier to handle routers within the AS as we have full control over it. I think the key point is the ASBR, as we have no control of its eBGP peers. A simple approach is to enable both this extension and RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup purpose before we are aware of the capability of its peers. The ASBR prefers the 128-bit ID. Since the ID field of OPEN message sent by the ASBR is zero, which will result in a "bad bgp identifier" error message sent by the peer if it does not support the new 128-bit ID capability, the ASBR will know the type of its peer. The ASBR can initiate a second connection in the old way, and the connection falls back using 32-bit ID. Peng > -----Original Message----- > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] > On Behalf Of Christopher Morrow > Sent: Tuesday, February 18, 2014 11:42 AM > To: lizhenqiang@chinamobile.com > Cc: Randy Bush; Farmer; jaeggli; Amante; JAMES; Doering; Raszuk'; fanpeng; idr > wg; V6 Ops List > Subject: Re: Re: [Idr] [v6ops] BGP Identifier > > On Mon, Feb 17, 2014 at 10:30 PM, lizhenqiang@chinamobile.com > wrote: > > Hi All, > > > > Thank you all for your valuable comments and interests in this draft. > > Any technical concerns about the draft? Is there someone in the mail > > list from operators that has the same problem as me? > > > > i think shane's point about 'make a stab at transition technique' > still needs to be dealt with, yes? > > and really... I don't see a huge reason to do this anyway, yet. > > > Many Thanks, > > Zhenqiang Li > > > > ________________________________ > > From nobody Mon Feb 17 22:08:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DFC1A03E7; Mon, 17 Feb 2014 22:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jwl4FTH53gkH; Mon, 17 Feb 2014 22:08:29 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id A7C341A0358; Mon, 17 Feb 2014 22:08:29 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WFdqv-0003FJ-6J; Tue, 18 Feb 2014 06:08:22 +0000 Date: Tue, 18 Feb 2014 14:08:17 +0800 Message-ID: From: Randy Bush To: Peng Fan In-Reply-To: <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/3Kaqz5PEvfxfsM7oyzsRBgkrwFk Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 06:08:33 -0000 Christopher Morrow Farmer jaeggli Amante JAMES Doering > Normally it is easier to handle routers within the AS as we have full > control over it. I think the key point is the ASBR, as we have no > control of its eBGP peers. A simple approach is to enable both this > extension and RFC6286, and assign a 32-bit ID in addition to the > 128-bit one for backup purpose before we are aware of the capability > of its peers. The ASBR prefers the 128-bit ID. Since the ID field of > OPEN message sent by the ASBR is zero, which will result in a "bad bgp > identifier" error message sent by the peer if it does not support the > new 128-bit ID capability, the ASBR will know the type of its > peer. The ASBR can initiate a second connection in the old way, and > the connection falls back using 32-bit ID. what we have here is a bunch of network operators trying to help you design and configure your network. it may have gone past the amusing and educational for the non-op ietf folk on these lists. you may get wider and deeper free consulting, with 42 conflicting opinions, by moving this to nanog, apops, ... list(s). randy From nobody Mon Feb 17 23:57:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91421A0454 for ; Mon, 17 Feb 2014 23:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 DNwcoA_hiniK for ; Mon, 17 Feb 2014 23:57:21 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 732701A044B for ; Mon, 17 Feb 2014 23:57:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C51EE870078; Tue, 18 Feb 2014 08:57:17 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrgJwbl0p7oN; Tue, 18 Feb 2014 08:57:17 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A548B87006D; Tue, 18 Feb 2014 08:57:17 +0100 (CET) Message-ID: <5303125C.60303@globis.net> Date: Tue, 18 Feb 2014 08:57:16 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: "v6ops@ietf.org WG" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/aQRe4iTIlwz_sC5h2Nocp5kSBuI Cc: joelja@gmail.com Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problemv6op6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 07:57:23 -0000 > From: > To: v6ops at ietf.org > Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem at tools.ietf.org > Date: Mon, 17 Feb 2014 05:45:16 -0800 (PST) > A new draft has been posted, at > http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. > Please take a look at it and comment. I have read this draft. Isn't the obvious brute force mitigation to clamp all of your DC to IPv6 minimum MTU? And isn't it yet another hint that PMTUD really needs to be incorporated into the transport layer [if we needed another]? e.g. by referencing Packetization Layer Path MTU Discovery (PLPMTUD) http://tools.ietf.org/html/rfc4821 That should also be handled correctly by the load balancers, or not? -- Regards, RayH From nobody Tue Feb 18 02:08:57 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3A11A0466 for ; Tue, 18 Feb 2014 02:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG6IzXxER3SR for ; Tue, 18 Feb 2014 02:08:50 -0800 (PST) Received: from smtp04.msg.oleane.net (smtp04.msg.oleane.net [62.161.4.4]) by ietfa.amsl.com (Postfix) with ESMTP id 01E811A0656 for ; Tue, 18 Feb 2014 02:08:49 -0800 (PST) Received: from MGosseDellM6800 (LMontsouris-656-01-05-162.w80-12.abo.wanadoo.fr [80.12.94.162]) (authenticated) by smtp04.msg.oleane.net (MSA) with ESMTP id s1IA8jvk029887 for ; Tue, 18 Feb 2014 11:08:45 +0100 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 18 Feb 2014 11:08:43 +0100 Message-ID: <00bb01cf2c91$67f89c60$37e9d520$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01CF2C99.C9C19840" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac8skT/9MwNyDyoQTSuOoF+b7zjPAQ== Content-Language: fr X-Backend: vm-smtp-sophos06 X-PMX-Spam: Probability=10% X-PFSI-Info: PMX 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.18.95116 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZeFO6zpyTSsyRA2XCQoU_suv9Q8 Subject: [v6ops] V6 World 2014 Paris will start in one Month X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 10:08:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BC_01CF2C99.C9C19840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What about IPv6 at Facebook, Google and Linkedin? How carriers prepare the transition? What about IoT and transport intelligence? Responses during the fourth edition of V6 World from 18 to 21 March, 2014. More info: http://www.uppersideconferences.com/v6world2014/v6world2014introduction.html ------=_NextPart_000_00BC_01CF2C99.C9C19840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wh= at about IPv6 at Facebook, Google and Linkedin? How carriers prepare the transition? = What about IoT and transport = intelligence?

Re= sponses during the fourth edition of V6 World from 18 to 21 March, = 2014.

Mo= re info: = http://www.uppersideconferences.com/v6world2014/v6world2014introduction.h= tml

 

------=_NextPart_000_00BC_01CF2C99.C9C19840-- From nobody Tue Feb 18 03:36:46 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3A41A0480; Tue, 18 Feb 2014 03:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 Ew7284S6lqcU; Tue, 18 Feb 2014 03:36:42 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 936E51A060D; Tue, 18 Feb 2014 03:36:40 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee253034538c21-5ac21; Tue, 18 Feb 2014 19:34:16 +0800 (CST) X-RM-TRANSID: 2ee253034538c21-5ac21 Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee253034534311-fc8f6; Tue, 18 Feb 2014 19:34:16 +0800 (CST) X-RM-TRANSID: 2ee253034534311-fc8f6 Date: Tue, 18 Feb 2014 19:36:26 +0800 From: "lizhenqiang@chinamobile.com" To: =?utf-8?B?VVRUQVJPLCBKQU1FUw==?= , "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , <2014021810513701058825@chinamobile.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402181936265926758@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart620801886436_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/SHDXqh4WO4TxIDARgOU7Dg41amw Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 11:36:45 -0000 This is a multi-part message in MIME format. ------=_001_NextPart620801886436_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgoKCgoKCgoKClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgaW5mb3JtYXRpb24sIEppbS5X ZSBhbHNvIGhhdmUgc29tZSB0b29scyB0byBoZWxwIHVzIHRvIHBsYW4gYW5kIG9wZXJhdGUgb3Vy IG5ldHdvcmtzLiBIb3dldmVyIGF0IHByZXNlbnQgbm9uZSBvZiB0aGUgdG9vbHMgY2FuIHNhdGlz ZnkgdGhlIHJlcXVpcm1lbnQgb2YgdGhpcyBkcmFmdC4KQW55d2F5LCB5b3UgZG8gbm90IHRoaW5r IGl0IGlzIGEgcHJvYmxlbSB0byBwbGFuIHRoZSAzMi1iaXQgQkdQIElEIGZvciBhIHZlcnkgbGFy Z2Ugc2NhbGUgSVB2Ni1vbmx5IG5ldHdvcms/CgoKCmxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNv bQrCoEZyb206wqBVVFRBUk8sIEpBTUVTRGF0ZTrCoDIwMTQtMDItMTjCoDE5OjI3VG86wqBsaXpo ZW5xaWFuZ0BjaGluYW1vYmlsZS5jb207IFJhbmR5IEJ1c2hDQzrCoCdpZHIgd2cnOyAnVjYgT3Bz IExpc3QnOyAnUm9iZXJ0IFJhc3p1aydTdWJqZWN0OsKgUkU6IFtJZHJdIFt2Nm9wc10gQkdQIElk ZW50aWZpZXIKCgoKCgoKCldlIGhhdmUgZGV2ZWxvcGVkIG51bWVyb3VzIGNvbmZpZ3VyYXRpb24g dG9vbHMgdGhhdCBjcmVhdGUvbW9kIFBFLCBSUiBjb25maWdzLiBXZSBhbHNvIGhhdmUgbG90cyBv ZiB0b29scyB0aGF0IHNwZWFrIHRvIHRoZSBuZXR3b3JrIGluIGEgbGl2ZSBzZW5zZSB0byBnZXQg aGVhbHRoLAogc3RhdHMg4oCmIEFsbCBvZiB0aGUgcmF3IG1hdGVyaWFsIGlzIHJlYWRpbHkgYXZh aWxhYmxlLiBUQkggSSBjYW5ub3Qgc3BlYWsgdG8geW91IGFib3V0IG91ciBzb2x1dGlvbnMgaW4g YW55bW9yZSBkZXB0aC4uCsKgCkppbSBVdHRhcm8KwqAKCgpGcm9tOiBJZHIgW21haWx0bzppZHIt Ym91bmNlc0BpZXRmLm9yZ10KT24gQmVoYWxmIE9mIGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNv bQoKU2VudDogTW9uZGF5LCBGZWJydWFyeSAxNywgMjAxNCA5OjUyIFBNCgpUbzogUmFuZHkgQnVz aAoKQ2M6ICdpZHIgd2cnOyAnVjYgT3BzIExpc3QnOyAnUm9iZXJ0IFJhc3p1aycKClN1YmplY3Q6 IFJlOiBbSWRyXSBbdjZvcHNdIEJHUCBJZGVudGlmaWVyCgoKwqAKClRlbGwgbWUgcGxlYXNlIHRo ZSBsYXJnZSBwcm92aWRlciB0aGF0IHlvdSBrbm93IGhhcyBoaXMgb3duIGF1dG9tYXRpYyBjb25m aWd1cmF0aW9uIHRvb2xzLiBJIHdvdWxkIGxpa2UgdG8gY29udGFjdCBoaW0gdG8gbGVhcm4gZnJv bSBoaW0uwqAKCgrCoAoKCgoKCgoKbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tCgoKCgoKwqAK CgoKCkZyb206wqBSYW5keQogQnVzaAoKCkRhdGU6wqAyMDE0LTAyLTE4wqAxMDo0MAoKClRvOsKg bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tCgoKQ0M6wqBmYW5wZW5nOwonaWRyIHdnJzsgJ1Y2 IE9wcyBMaXN0JzsKJ1JvYmVydCBSYXN6dWsnCgoKU3ViamVjdDrCoFJlOiBbSWRyXSBbdjZvcHNd IEJHUCBJZGVudGlmaWVyCgoKCgoKPiBEbyB5b3UgaGF2ZSBzdWNoIHRvb2xzIHRvIGNvbmZpZyB5 b3VyIG5ldHdvcms/IE9yIGRvIHlvdSBrbm93IHRoZQoKCj4gdmVuZG9yIHRoYXQgcHJvdmlkZSBz dWNoIHRvb2xzP0luZGVlZCwgc3VjaMKgcHJvZ3JhbW1hdGljIGdlbmVyYXRpb24KCgo+IHRvb2xz IGFyZSBnb29kIGZvciBuZXR3b3JrIHBsYW4uIEJ1dCB0aGUgbG9naWMgaW4gdGhlIHRvb2xzIGlz CgoKPiBjb21wbGVjYXRlZCBlc3BlY2lhbGx5IGZvciBhIHZlcnkgbGFyZ2UgbmV0d29yayB3aXRo wqBoaWVyYXJjaGljYWwKCgo+IG9wZXJhdGlvbiBhcyBQZW5nIEZhbiBtZW50aW9uZWQuCgoKwqAK Cgp0aGVyZSBhcmUgcHJvZHVjdHMgaW4gdGhlIHNwYWNlLCBidXQgdGhlIGxhcmdlIHByb3ZpZGVy cyBpIGtub3cgd2hvCgoKY29uZmlndXJlIHByb2dyYW1hdGljYWxseSBkZXZlbG9wZWQgdGhlaXIg b3duLsKgIHRoZXJlIGFyZSBub3QgZW5vdWdoCgoKbGFyZ2UgcHJvdmlkZXJzIG5vdCBzdWZmZXJp bmcgZnJvbSAnbm90IGludmVudGVkIGhlcmUnIHRvIG1ha2UgYQoKCnJlYXNvbmFibGUgY3VzdG9t ZXIgYmFzZSBmb3Igc2VyaW91cyBzb2Z0d2FyZSBkZXZlbG9wbWVudC4KCgrCoAoKCmJ1dCBpdCBw YXlzIGZvciBpdHNlbGYsIHNvIHNtYXJ0IGZvbGsgd2hvIGRldmVsb3AgaXQuCgoKwqAKCgpyYW5k eQoKCsKgCgoKCgoKCgo= ------=_001_NextPart620801886436_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0AThank you very much for your information, Jim.
W= e also have some tools to help us to plan and operate our networks. Howeve= r at present none of the tools can satisfy the requirment of this draft.

Anyway, you do not think it is a problem to plan t= he 32-bit BGP ID for a very large scale IPv6-only network?
=0A
=0A
=0A
lizhenqiang@chinamobile.com
= =0A
 
From: <= a href=3D"mailto:ju1738@att.com" style=3D"color: blue; text-decoration: un= derline;">UTTARO, JAMES
Date: 2014-02-18 19= :27
=0A=0A
=0A

We have developed numerous configuration tools that create/mod P= E, RR configs. We also have lots of tools that speak to the network in a l= ive sense to get health,=0A stats =E2=80=A6 All of the raw material is rea= dily available. TBH I cannot speak to you about our solutions in anymore d= epth..

=0A

 

=0A

Jim Uttaro<= /span>

=0A

 

=0A
=0A
=0A

From: I= dr [mailto:idr-bounces@ietf.org]=0AOn Behalf Of lizhenqiang@chinamo= bile.com
=0ASent: Monday, February 17, 2014 9:52 PM
=0ATo:= Randy Bush
=0ACc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'<= br>=0ASubject: Re: [Idr] [v6ops] BGP Identifier=0A

=0A
=0A

 = ;

=0A
=0A

Tell me please the large provider that you know has his own automat= ic configuration tools. I would like to contact him to learn from him. 

=0A
= =0A
=0A

 

=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A

 

=0A
=0A
=0A
=0A=0A

From:Randy=0A Bush

=0A
=0A
= =0A

Date: 2014-02-18 10:40

=0A
=0A
=0A

To: lizhenqiang@chinamobile.com=0A

=0A=0A
=0A

Su= bject: Re: [Idr] [v6ops] BGP Ident= ifier

=0A
=0A
=0A
=0A
=0A
=0A<= p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; = font-family: 'Times New Roman', serif;">> Do you have= such tools to config your network? Or do you know the=0A
=0A
=0A

> vendor that provide such tools?Indeed, such programmatic = generation

=0A
=0A
=0A

> tools are good for network plan.= But the logic in the tools is

=0A
=0A
=0A> complecated = especially for a very large network with hierarchical

=0A
=0A
=0A

> operation as Peng Fan mentioned.

=0A<= /div>=0A
=0A

 

=0A
=0A
=0A

there are products in the space, but the= large providers i know who

=0A
=0A
=0A

configure programati= cally developed their own.  there are not enough=0A

=0A
=0A

large providers not suffering from 'not invented here' to make a

=0A
=0A
=0A

reasonable customer base for serious software deve= lopment.

=0A
=0A
=0A

 

=0A
= =0A
=0A

but = it pays for itself, so smart folk who develop it.

=0A=
=0A
=0A

randy

=0A
=0A=
=0A

 <= o:p>

=0A
=0A
=0A
=0A
=0A<= /div>=0A ------=_001_NextPart620801886436_=------ From nobody Tue Feb 18 05:45:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFAB1A01C2 for ; Tue, 18 Feb 2014 05:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E_sbZeK1ffP for ; Tue, 18 Feb 2014 05:45:11 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 28F001A01CB for ; Tue, 18 Feb 2014 05:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392731108; x=1393940708; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=OyYxWPY2HDOXK7vcBAkTVun6J0AElsPvtgmLZvqXAtwqHYnfvQHjT+6R MGY8QJ36pnV36Qe5PJT3MeyPJUoIC8Jy7F9m4wCnRsSsbcu3qJz0HD4OM 76hTIDRlPE+c37dzGaaeU8jP1jJ4cNiEMpCMFh/M6E8M89PakGcE120e9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkLAINiA1OrRDoI/2dsb2JhbABZgwY4q0YBlFcDBAKBFRZ0gyU8LQeIZQ7LYRePAR2DDoEUBIlIkBaQcYNO X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208";a="103082540" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 18 Feb 2014 13:45:08 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1IDj1jF031367; Tue, 18 Feb 2014 13:45:08 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1IDj1E00167; Tue, 18 Feb 2014 05:45:01 -0800 (PST) Date: Tue, 18 Feb 2014 05:45:01 -0800 (PST) From: Message-Id: <201402181345.s1IDj1E00167@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8ju9Y3p8lupYpTrFTeHrZZyhNmQ Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:45:17 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Tue Feb 18 05:45:27 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67FE1A060E for ; Tue, 18 Feb 2014 05:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXMkz1qtExwY for ; Tue, 18 Feb 2014 05:45:23 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADB11A0206 for ; Tue, 18 Feb 2014 05:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392731120; x=1393940720; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=AjR7ZreYPXBsCqo56FLeXyEBd9RQisMOvIwl7aG4PbdgvxB2c3o808in m2BsSfDwixDhBQc71JSoHQ0gJwPcGZFd9MH+dM2c/y/hNhCbKip4VUjFP eSZFo53vr/ftxmpezYYTicIW0ZopsSrIc/JrVsnlhY+ypc7sdBMz1pvBm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkLAINiA1OrRDoJ/2dsb2JhbABZgwY4q0YBlFcDBAKBFRZ0gyU8NIhlDsthF48BHYQiBIlIkBaQcYNO X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208";a="106362057" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 18 Feb 2014 13:45:20 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1IDjJGE018527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 13:45:20 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s1IDjJaG014803; Tue, 18 Feb 2014 05:45:19 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s1IDjJ8N014784; Tue, 18 Feb 2014 05:45:19 -0800 (PST) Date: Tue, 18 Feb 2014 05:45:19 -0800 (PST) From: Fred Baker Message-Id: <201402181345.s1IDjJ8N014784@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Dggzlr5gk-mo-4tyNjr8uAE9Vqk Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 13:45:25 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Tue Feb 18 07:22:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A366E1A0682 for ; Tue, 18 Feb 2014 07:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SmqjIPqziOT for ; Tue, 18 Feb 2014 07:22:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7991A03DC for ; Tue, 18 Feb 2014 07:22:30 -0800 (PST) Received: from [192.168.43.134] ([172.56.39.102]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1IFMKPq059587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 15:22:21 GMT (envelope-from joelja@bogus.com) Message-ID: <53037AA6.102@bogus.com> Date: Tue, 18 Feb 2014 07:22:14 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Ray Hunter , "v6ops@ietf.org WG" References: <5303125C.60303@globis.net> In-Reply-To: <5303125C.60303@globis.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HfAqrCStKNdVQ58W7CPGPMjVUpS5PK3in" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Feb 2014 15:22:21 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Go1CVy-9oHaZ1D5GmL97qNMiNfk Cc: joelja@gmail.com Subject: Re: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problemv6op6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 15:22:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HfAqrCStKNdVQ58W7CPGPMjVUpS5PK3in Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/17/14, 11:57 PM, Ray Hunter wrote: >> From: >> To: v6ops at ietf.org >> Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem at tools.ietf.org >> Date: Mon, 17 Feb 2014 05:45:16 -0800 (PST) >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. >> Please take a look at it and comment. >=20 > I have read this draft. >=20 > Isn't the obvious brute force mitigation to clamp all of your DC to IPv= 6 > minimum MTU? That is an obvious brute force mitigation. It does however doom ipv6 to the minimum mtu until I decide pmtu is no longer necessary, which may or may not be never. There wouldn't be much point if this happened frequently but as it is, it happens at a rate of a handful of packets per second out of a few gig's of v6 traffic. That says a lot I think about deployment. > And isn't it yet another hint that PMTUD really needs to be incorporate= d > into the transport layer [if we needed another]? >=20 > e.g. by referencing Packetization Layer Path MTU Discovery (PLPMTUD) > http://tools.ietf.org/html/rfc4821 Sure I agree that in-band signaling would be way less likely to interact badly with ecmp forwarding decisions. > That should also be handled correctly by the load balancers, or not? >=20 --HfAqrCStKNdVQ58W7CPGPMjVUpS5PK3in Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMDeqcACgkQ8AA1q7Z/VrIWqwCeM2XdLNSHD7FciiaeWJDDqqTq q7YAn2rc4+ajXIg5djje8o4rgc2qiMBf =YYNE -----END PGP SIGNATURE----- --HfAqrCStKNdVQ58W7CPGPMjVUpS5PK3in-- From nobody Tue Feb 18 09:16:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374C81A06B4; Tue, 18 Feb 2014 09:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 GCZw-hRfp_Jo; Tue, 18 Feb 2014 09:16:07 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0181A06A6; Tue, 18 Feb 2014 09:16:07 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id s1IHDsC1024246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Feb 2014 12:13:55 -0500 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: Date: Tue, 18 Feb 2014 12:13:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> To: Randy Bush X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [204.42.254.5]); Tue, 18 Feb 2014 12:13:56 -0500 (EST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vbidV2PsvRMVj9roU6MsYsuLfSU Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 17:16:09 -0000 On Feb 17, 2014, at 10:17 PM, Randy Bush wrote: >> Tell me please the large provider that you know has his own automatic >> configuration tools. >=20 > l(3), ntt, ... >=20 >> I would like to contact him to learn from him.=20 >=20 > it is considered secret sauce we (ntt) have presented about this automation in the past. google comes up with a few of these: http://www.nanog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf = http://www.us.ntt.net/news/viewFile.cfm/NTT_Editorial_Capacity_Magazine_no= v_2013.pdf?file_id=3D144 http://ptt.br/pttforum/7/doc/ptt_forum7_morris.pdf - Jared From nobody Tue Feb 18 09:52:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6628E1A0344; Mon, 17 Feb 2014 21:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 x0ybUTs4GxHT; Mon, 17 Feb 2014 21:27:46 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id A4DF31A0433; Mon, 17 Feb 2014 21:27:42 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25302eeaf544-54544; Tue, 18 Feb 2014 13:25:03 +0800 (CST) X-RM-TRANSID: 2ee25302eeaf544-54544 Received: from X6X8D79D8F49E2 (unknown[10.2.43.104]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee35302eeadce4-decf8; Tue, 18 Feb 2014 13:25:03 +0800 (CST) X-RM-TRANSID: 2ee35302eeadce4-decf8 From: "Fan, Peng" To: "'Christopher Morrow'" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> In-Reply-To: Date: Tue, 18 Feb 2014 13:28:10 +0800 Message-ID: <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMyHwF2uN/MFx2cQfT+KJLjKc69QKQBeNnAdstUIkBXjGXJpkQ3UEQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jXZJQD2z_aa7XdSmzqgAgiuflbw X-Mailman-Approved-At: Tue, 18 Feb 2014 09:52:41 -0800 Cc: 'V6 Ops List' , 'idr wg' , 'JAMES' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 05:27:48 -0000 Hi Christopher, Normally it is easier to handle routers within the AS as we have full control over it. I think the key point is the ASBR, as we have no control of its eBGP peers. A simple approach is to enable both this extension and RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup purpose before we are aware of the capability of its peers. The ASBR prefers the 128-bit ID. Since the ID field of OPEN message sent by the ASBR is zero, which will result in a "bad bgp identifier" error message sent by the peer if it does not support the new 128-bit ID capability, the ASBR will know the type of its peer. The ASBR can initiate a second connection in the old way, and the connection falls back using 32-bit ID. Peng > -----Original Message----- > From: christopher.morrow@gmail.com [mailto:christopher.morrow@gmail.com] > On Behalf Of Christopher Morrow > Sent: Tuesday, February 18, 2014 11:42 AM > To: lizhenqiang@chinamobile.com > Cc: Randy Bush; Farmer; jaeggli; Amante; JAMES; Doering; Raszuk'; fanpeng; idr > wg; V6 Ops List > Subject: Re: Re: [Idr] [v6ops] BGP Identifier > > On Mon, Feb 17, 2014 at 10:30 PM, lizhenqiang@chinamobile.com > wrote: > > Hi All, > > > > Thank you all for your valuable comments and interests in this draft. > > Any technical concerns about the draft? Is there someone in the mail > > list from operators that has the same problem as me? > > > > i think shane's point about 'make a stab at transition technique' > still needs to be dealt with, yes? > > and really... I don't see a huge reason to do this anyway, yet. > > > Many Thanks, > > Zhenqiang Li > > > > ________________________________ > > From nobody Tue Feb 18 09:52:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7791B1A0465; Tue, 18 Feb 2014 03:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.147 X-Spam-Level: X-Spam-Status: No, score=-4.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHLimx39XGwl; Tue, 18 Feb 2014 03:27:43 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 445301A032F; Tue, 18 Feb 2014 03:27:43 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id ca343035.2ac0a9e15940.3337058.00-2450.9318766.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 11:27:40 +0000 (UTC) X-MXL-Hash: 530343ac3a911ade-508fec8aad0a3c44fdb345807df4168738e7a646 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 9a343035.0.3337043.00-2065.9318731.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 18 Feb 2014 11:27:39 +0000 (UTC) X-MXL-Hash: 530343ab24a610f0-f0f231d518e35646c895d843c1f78424984fca40 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IBRbYE024965; Tue, 18 Feb 2014 06:27:37 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s1IBRSHZ024883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 06:27:29 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 18 Feb 2014 11:27:17 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0174.001; Tue, 18 Feb 2014 06:27:16 -0500 From: "UTTARO, JAMES" To: "lizhenqiang@chinamobile.com" , Randy Bush Thread-Topic: [Idr] [v6ops] BGP Identifier Thread-Index: AQHPLFRXkH+sv9yQ+kSGj1ZIvBEoEZq63y+g Date: Tue, 18 Feb 2014 11:27:16 +0000 Message-ID: References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, <2014021810513701058825@chinamobile.com> In-Reply-To: <2014021810513701058825@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.79.159] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=StMnHoy0 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ofMgfj31e3cA:10 a=k0ITYs5nkwcA:10 a=BLceEmwcHowA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=e_BCuZGg8NsA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=R5C9hjxsAAAA:8 a=No5EcEP4AAAA:8 a=2clOPd4PAAAA:8 a] X-AnalysisOut: [=dVGEDVYWMja6ID64LnkA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:1] X-AnalysisOut: [0 a=hFj-Mf0cM8IA:10 a=PKgchsl1YdkA:10 a=bDUki_mJ7DgA:10 a=] X-AnalysisOut: [yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L] X-AnalysisOut: [4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=OK47xdkk6A] X-AnalysisOut: [psxbyL:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/eAXyUQOJvmiBcKRtvKZ0eK_t3vs X-Mailman-Approved-At: Tue, 18 Feb 2014 09:52:41 -0800 Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 11:27:46 -0000 --_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have developed numerous configuration tools that create/mod PE, RR confi= gs. We also have lots of tools that speak to the network in a live sense to= get health, stats ... All of the raw material is readily available. TBH I = cannot speak to you about our solutions in anymore depth.. Jim Uttaro From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of lizhenqiang@chinamobil= e.com Sent: Monday, February 17, 2014 9:52 PM To: Randy Bush Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier Tell me please the large provider that you know has his own automatic confi= guration tools. I would like to contact him to learn from him. ________________________________ lizhenqiang@chinamobile.com From: Randy Bush Date: 2014-02-18 10:40 To: lizhenqiang@chinamobile.com CC: fanpeng; 'idr wg';= 'V6 Ops List'; 'Robert Raszuk' Subject: Re: [Idr] [v6ops] BGP Identifier > Do you have such tools to config your network? Or do you know the > vendor that provide such tools?Indeed, such programmatic generation > tools are good for network plan. But the logic in the tools is > complecated especially for a very large network with hierarchical > operation as Peng Fan mentioned. there are products in the space, but the large providers i know who configure programatically developed their own. there are not enough large providers not suffering from 'not invented here' to make a reasonable customer base for serious software development. but it pays for itself, so smart folk who develop it. randy --_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have developed numerou= s configuration tools that create/mod PE, RR configs. We also have lots of = tools that speak to the network in a live sense to get health, stats … All of the raw material is readily available. TBH I cannot s= peak to you about our solutions in anymore depth..

 <= /p>

Jim Uttaro

 <= /p>

From: Idr [mai= lto:idr-bounces@ietf.org] On Behalf Of lizhenqiang@chinamobile.com
Sent: Monday, February 17, 2014 9:52 PM
To: Randy Bush
Cc: 'idr wg'; 'V6 Ops List'; 'Robert Raszuk'
Subject: Re: [Idr] [v6ops] BGP Identifier

 

Tell me please the large provider t= hat you know has his own automatic configuration tools. I would like to con= tact him to learn from him. 

 

 

From: Randy Bush

Date: 2014-02-18 10:40<= /o:p>

Subject: Re: [Idr] [v6ops] BGP Id= entifier

> Do you have such tools to conf= ig your network? Or do you know the

> vendor that provide such tools= ?Indeed, such programmatic generation

> tools are good for network pla= n. But the logic in the tools is

> complecated especially for a v= ery large network with hierarchical

> operation as Peng Fan mentione= d.

 

there are products in the space, bu= t the large providers i know who

configure programatically developed= their own.  there are not enough

large providers not suffering from = 'not invented here' to make a

reasonable customer base for seriou= s software development.

 

but it pays for itself, so smart fo= lk who develop it.

 

randy

 

--_000_B17A6910EEDD1F45980687268941550F06341989MISOUT7MSGUSR9I_-- From nobody Tue Feb 18 09:52:48 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD31A069B; Tue, 18 Feb 2014 08:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, 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 0zfBeFPexa6C; Tue, 18 Feb 2014 08:06:42 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 741FD1A0693; Tue, 18 Feb 2014 08:06:42 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A02DC25C; Tue, 18 Feb 2014 11:06:39 -0500 (EST) Date: Tue, 18 Feb 2014 11:06:39 -0500 From: Jeffrey Haas To: "Fan, Peng" Message-ID: <20140218160639.GC12348@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oLhewjrjjnc-XgT5lMmD6EVEx_o X-Mailman-Approved-At: Tue, 18 Feb 2014 09:52:41 -0800 Cc: 'idr wg' , 'V6 Ops List' , 'Christopher Morrow' , 'JAMES' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 16:06:47 -0000 On Tue, Feb 18, 2014 at 01:28:10PM +0800, Fan, Peng wrote: > Normally it is easier to handle routers within the AS as we have full > control over it. I think the key point is the ASBR, as we have no control of > its eBGP peers. A simple approach is to enable both this extension and > RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup > purpose before we are aware of the capability of its peers. I am not in favor of this draft. While I understand the operational desire for it, what the routing protocols (not just BGP) require is just some magic number to be used to identify various protocol properties tied to a given router. I don't think we want to see a series of similar drafts updating every other protocol in an attempt to realize a consistent 128 bit router id throughout an AS. The fact that this number has been able to receive a mapping to a real address has been extremely operationally useful. What I would instead suggest is finding a mechanism by which the unique router-ID can be mapped easily to such addresses. I don't believe that BGP is the right place to do this. -- Jeff From nobody Tue Feb 18 09:52:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E0F1A0324; Mon, 17 Feb 2014 19:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, KHOP_BIG_TO_CC=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 hozu1y0uCpOd; Mon, 17 Feb 2014 19:41:59 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8928F1A030F; Mon, 17 Feb 2014 19:41:58 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so11654934lbi.7 for ; Mon, 17 Feb 2014 19:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QnvApghAhd02DHIa5tV4nmdNjz0c9Sy6k5zvfPVVg9o=; b=J1Y43M4WbeXczHq+X8xYKolqbAUVTcOZGUbkg6ow74GyfU9olgQ5Q0RGL1C8AJ5NLm oXoa+bhmTM85JgQ50iQMOaUQteMagvK41IbW1OF3Opd2tAugXv44ITBl3wZ/yweWaVBI kzYswGgfRkDKIXObTw5X7v+8PK1kUIiRb3115uaenI9Rtim55pQPhrpppM6HEa0vBe/A 4R1twDyiXx+sGc2AbnctyLRcdyjKjCGIzvNVAp0B+hZhK609yd0xW74iOrsctHH7mn8Q j2Dfm8gK5HEmgtzGa7ZsfwM1Ki3WIr4Q9jBojcYmY3h5zSC19w3Zke4NO5DYkSd4JswU U8Hg== MIME-Version: 1.0 X-Received: by 10.153.3.2 with SMTP id bs2mr19797812lad.5.1392694914957; Mon, 17 Feb 2014 19:41:54 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.203.167 with HTTP; Mon, 17 Feb 2014 19:41:54 -0800 (PST) In-Reply-To: <2014021811305909988540@chinamobile.com> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> Date: Mon, 17 Feb 2014 22:41:54 -0500 X-Google-Sender-Auth: NwdAWS6xWiKrFAHt_GdJYxxg0vc Message-ID: From: Christopher Morrow To: "lizhenqiang@chinamobile.com" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/phuwqJDoSSjUveqQfrwDj94sxO4 X-Mailman-Approved-At: Tue, 18 Feb 2014 09:52:50 -0800 Cc: V6 Ops List , idr wg , JAMES Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 03:42:00 -0000 On Mon, Feb 17, 2014 at 10:30 PM, lizhenqiang@chinamobile.com wrote: > Hi All, > > Thank you all for your valuable comments and interests in this draft. > Any technical concerns about the draft? Is there someone in the mail list > from operators that has the same problem as me? > i think shane's point about 'make a stab at transition technique' still needs to be dealt with, yes? and really... I don't see a huge reason to do this anyway, yet. > Many Thanks, > Zhenqiang Li > > ________________________________ > From nobody Tue Feb 18 11:12:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2111A0103 for ; Tue, 18 Feb 2014 11:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 SUUP0zWOuLWE for ; Tue, 18 Feb 2014 11:12:50 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 72B931A01B7 for ; Tue, 18 Feb 2014 11:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1743; q=dns/txt; s=iport; t=1392750765; x=1393960365; h=from:to:subject:date:message-id:mime-version; bh=3rORA+oxpA+kO5InMhRPe6iPB7f2aARLcB4vLiIk8l8=; b=P9zRTvBf7TJgkvHtM1Gwix91STMnDpkpJI2O6R9vdZAgl1fCVef5j1IL xpwierIGHm4d8PX2z1pjqx1RM38UWxyclRI/ExaR/kftbcNZ+97s+kbfc 0wLWTpwimBa8JlvvsrxpJ9BcybaIDWoDnDMdK8qGDluiT90d4WX6ntOgp Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMIAJqvA1OtJXG9/2dsb2JhbABZgkJEOFe3XhCJYhZ0ghwQgQsBCwF0JwQuh2oNmymwZBeTIwSJEI8ggTKQcoMtgio X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208,217";a="304856490" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 18 Feb 2014 19:12:44 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1IJCiof022615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Feb 2014 19:12:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 13:12:44 -0600 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org" Thread-Topic: IPv6 and multicast Thread-Index: AQHPLN1mpJ/4JwIP9kOwTSLAStnXTQ== Date: Tue, 18 Feb 2014 19:12:43 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.55.185.70] Content-Type: multipart/alternative; boundary="_000_CF296F3AD6A8evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uY-o6K4AXW97mPv6vBXULxaxwQ8 Subject: [v6ops] IPv6 and multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:12:53 -0000 --_000_CF296F3AD6A8evynckeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You may want to find http://tools.ietf.org/html/draft-vyncke-6man-mcast-not= -efficient-01 interesting to understand some challenges (actually wrong ass= umptions) posed by the use of layer-3 multicast by IPv6 (mainly for neighbo= r discovery) over a wired/wirelss infrastructure which has little link with= the layer-3 multicast This I-D could be the problem statement for solution I-D Hope it helps -=E9ric --_000_CF296F3AD6A8evynckeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <640212E1F88B6F4996CB8014A877D8DB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
You may want to find http://tools.ietf.org/html/draft-vyncke= -6man-mcast-not-efficient-01 interesting to understand some challe= nges (actually wrong assumptions) posed by the use of layer-3 multicast by IPv6 (mainly for neighbor discovery) over a wi= red/wirelss infrastructure which has little link with the layer-3 multicast=

This I-D could be the problem statement for solution I-D

Hope it helps

-=E9ric

--_000_CF296F3AD6A8evynckeciscocom_-- From nobody Tue Feb 18 11:57:42 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCEC1A04F2 for ; Tue, 18 Feb 2014 11:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 3qoEzYTNFh_s for ; Tue, 18 Feb 2014 11:57:38 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DEC761A020D for ; Tue, 18 Feb 2014 11:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=696; q=dns/txt; s=iport; t=1392753455; x=1393963055; h=date:from:to:cc:subject:message-id:mime-version; bh=uyi1Jloqei+DB3R6ZetTtm62AXHLvlKIcTaoKcvTdYY=; b=Jezq645Iq4z/cb5V7ktEPZPtHHl1SLYKKiWsqFy4fqbzncrv5Pq5I88Y kF1CGIBUxTQHHO2twhlBTgFFewMncJIXlluVg7e3q2GKxQqWUdOc2XPO8 EwiGL7Xi+VyCuNys7XRp/f/h0Qj3w1qnOG+GKY2IhWvG2toMGKN5Efien 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQKACO6A1OtJV2a/2dsb2JhbABZgwY4V6gtA5gHgR4WdIJkAi4RLoEQDogKDcwuF44TAQFPhD8EmWKFFYtdgy6BcDk X-IronPort-AV: E=Sophos;i="4.97,503,1389744000"; d="scan'208";a="304894224" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 18 Feb 2014 19:57:34 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1IJvYI7027832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 19:57:34 GMT Received: from [10.61.162.197] (10.61.162.197) by xhc-rcd-x02.cisco.com (173.37.183.76) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Feb 2014 13:57:32 -0600 Date: Tue, 18 Feb 2014 20:57:13 +0100 From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-mac To: "v6ops@ietf.org" Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [10.61.162.197] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/To7PG8Ub9I69nf_jMc6Fa8SD5oM Subject: [v6ops] Reducing Multicast in IPv6 Neighbor Discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Feb 2014 19:57:40 -0000 Following Eric Vyncke's mail, if you got interested by that draft, you may find this draft interesting too: http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 discusses some practical measures that can be taken "as is" to make IPv6 and WiFi better friends. If someone happened to be at this year's FOSDEM or my employer's conference, CiscoLive, the WiFi networks there ran most of the things specified in section 4. (for some background info, here's some stats from the ciscolive network: http://2014.ciscolive-ipv6.com/munin/ipv6noc/ipv6noc/index.html; FOSDEM was about the same ballpark number of hosts). --a From nobody Tue Feb 18 13:14:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E061A025A for ; Tue, 18 Feb 2014 13:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgS-MWFn1ZeW for ; Tue, 18 Feb 2014 13:14:41 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1C81A0081 for ; Tue, 18 Feb 2014 13:14:37 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so16613174pde.6 for ; Tue, 18 Feb 2014 13:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DlWRJ0P31p8ezIiOMDO0FsclW3hQMZYMKZNogD0ookw=; b=j7gHflj23X38Yf7Nn80955Q3fj/3i+y4X94oASdV6+0pOCqZjvx66oGfDNUjlR5FhN iYP9gd2zPh3hfkZ4sBitdG6aILRKvLRaaBkV9z+81ITnSlju9zLiM6UNmBEJVbp/0jp7 ZEY4N/fAEOmi0TvceM7P2jU0JERyAb8ZJXZk8bIQusJTQ1vDXxnerlYhIhm/LOuk1QEk mupYtKe6Yz3FIilijW/a4bTYo1RI9xqnPxYcMkuWRLwoq+PnqYBBx8815mbaS9owB0B+ 1N5t7NuEfb6BEX5YCltUrE6LDFr4jXJG48lxiNzjP9yH6aDuM90zhub+4H4iTNRS2WmC 7YKg== X-Received: by 10.68.223.9 with SMTP id qq9mr35526568pbc.58.1392758074580; Tue, 18 Feb 2014 13:14:34 -0800 (PST) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id y9sm150163431pas.10.2014.02.18.13.14.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Feb 2014 13:14:33 -0800 (PST) Message-ID: <5303CD3E.1010907@gmail.com> Date: Wed, 19 Feb 2014 10:14:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Owen DeLong References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/yIxYs2amP1hPK4OJnzw2LzQxggI Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:14:43 -0000 On 18/02/2014 16:39, Owen DeLong wrote: =2E.. > Given the history of what happens with uncoordinated space in IPv4, leg= itimately or > otherwise, I have no reason to believe that ULA isn=E2=80=99t simply a = larger, less inconvenient > opportunity to create a much larger problem of the same form without an= y of the > inherent drawbacks and limitations which prevented RFC-1918 from gettin= g truly > out of hand. But ULAs aren't bogons. They aren't supposed to be routed, but if some people break that rule, is a ULA prefix objectively any more harmful than an "official" PI prefix? I think we all realise that if you tell people not to stick beans up their noses, they will try it out to see what happens. I have no suggestion on how to prevent that. Brian From nobody Tue Feb 18 14:27:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE07B1A0470 for ; Tue, 18 Feb 2014 14:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STvLKy7Ugasj for ; Tue, 18 Feb 2014 14:27:28 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 534E81A026A for ; Tue, 18 Feb 2014 14:27:28 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 90EA71B8189 for ; Tue, 18 Feb 2014 14:27:25 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 71C5E190052; Tue, 18 Feb 2014 14:27:25 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 14:27:25 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <5303CD3E.1010907@gmail.com> Date: Tue, 18 Feb 2014 17:27:23 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <292269AF-CB65-4368-A4F3-9B4589CD5802@nominum.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kFwUMGCEhkjbXuVdBlZeoiHIq7Q Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:27:29 -0000 On Feb 18, 2014, at 4:14 PM, Brian E Carpenter = wrote: > But ULAs aren't bogons. They aren't supposed to be routed, but > if some people break that rule, is a ULA prefix objectively any > more harmful than an "official" PI prefix? To expand on that, one of the big problems with RFC 1918 bogons is that = the address might well wind up on some network on which it is valid, but = refers to a different host. This is _much_ less likely with ULAs. So the sense in which ULAs are less harmful than PIs is that in = principle at least, this cannot happen with PIs=97if they escape their = designated network, they are valid nowhere else. From nobody Tue Feb 18 18:20:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE541A042B; Tue, 18 Feb 2014 18:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] 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 uyOx0bk2gCj0; Tue, 18 Feb 2014 18:20:01 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id CA69C1A031B; Tue, 18 Feb 2014 18:19:59 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2530414436af-686af; Wed, 19 Feb 2014 10:17:40 +0800 (CST) X-RM-TRANSID: 2ee2530414436af-686af Received: from lizhenqiang (unknown[10.2.52.133]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee353041443628-f44cb; Wed, 19 Feb 2014 10:17:40 +0800 (CST) X-RM-TRANSID: 2ee353041443628-f44cb Date: Wed, 19 Feb 2014 10:19:51 +0800 From: "lizhenqiang@chinamobile.com" To: "Jared Mauch" , "Randy Bush" References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 108[cn] Mime-Version: 1.0 Message-ID: <201402191019510556831@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart373522705558_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/iUebGG9r4Xy5mrC7ikgw-db-Vxs Cc: 'idr wg' , 'V6 Ops List' Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2014 02:20:03 -0000 This is a multi-part message in MIME format. ------=_001_NextPart373522705558_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 CgoKCgoKVGhhbmsgeW91IHZlcnkgbXVjaCwgSmFyZWQuIEkgd2lsbCBzdHVkeSBhbGwgdGhlIG1h dGVyaWFsLgoKWmhlbnFpYW5nIExpCgpsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20KoEZyb206 oEphcmVkIE1hdWNoRGF0ZTqgMjAxNC0wMi0xOaAwMToxM1RvOqBSYW5keSBCdXNoQ0M6oGxpemhl bnFpYW5nQGNoaW5hbW9iaWxlLmNvbTsgaWRyIHdnOyBWNiBPcHMgTGlzdDsgUm9iZXJ0IFJhc3p1 a1N1YmplY3Q6oFJlOiBbSWRyXSBbdjZvcHNdIEJHUCBJZGVudGlmaWVyoApPbiBGZWIgMTcsIDIw MTQsIGF0IDEwOjE3IFBNLCBSYW5keSBCdXNoIDxyYW5keUBwc2cuY29tPiB3cm90ZToKoAo+PiBU ZWxsIG1lIHBsZWFzZSB0aGUgbGFyZ2UgcHJvdmlkZXIgdGhhdCB5b3Uga25vdyBoYXMgaGlzIG93 biBhdXRvbWF0aWMKPj4gY29uZmlndXJhdGlvbiB0b29scy4KPiAKPiBsKDMpLCBudHQsIC4uLgo+ IAo+PiBJIHdvdWxkIGxpa2UgdG8gY29udGFjdCBoaW0gdG8gbGVhcm4gZnJvbSBoaW0uIAo+IAo+ IGl0IGlzIGNvbnNpZGVyZWQgc2VjcmV0IHNhdWNlCqAKd2UgKG50dCkgaGF2ZSBwcmVzZW50ZWQg YWJvdXQgdGhpcyBhdXRvbWF0aW9uIGluIHRoZSBwYXN0LgqgCmdvb2dsZSBjb21lcyB1cCB3aXRo IGEgZmV3IG9mIHRoZXNlOgqgCmh0dHA6Ly93d3cubmFub2cub3JnL21lZXRpbmdzL25hbm9nNTQv cHJlc2VudGF0aW9ucy9UdWVzZGF5L01vcnJpcy5wZGYKaHR0cDovL3d3dy51cy5udHQubmV0L25l d3Mvdmlld0ZpbGUuY2ZtL05UVF9FZGl0b3JpYWxfQ2FwYWNpdHlfTWFnYXppbmVfbm92XzIwMTMu cGRmP2ZpbGVfaWQ9MTQ0Cmh0dHA6Ly9wdHQuYnIvcHR0Zm9ydW0vNy9kb2MvcHR0X2ZvcnVtN19t b3JyaXMucGRmCqAKLSBKYXJlZAqgCqAKCg== ------=_001_NextPart373522705558_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Thank you very much, Jar= ed. I will study all the material.
=0A

Zhenqiang L= i
=0A
=0A
lizhenqiang@chinamobile.com
=0A=
 
Date: 2014-02-19 01:13
<= b>Subject: Re: [Idr] [v6ops] BGP Identifier
 
=0A
On Feb 17, 2014, at 10:17 PM, Randy Bush <ran= dy@psg.com> wrote:
=0A
 
=0A
>> Tell me pl= ease the large provider that you know has his own automatic
=0A
&= gt;> configuration tools.
=0A
>
=0A
> l(3), nt= t, ...
=0A
>
=0A
>> I would like to contact hi= m to learn from him.
=0A
>
=0A
> it is considere= d secret sauce
=0A
 
=0A
we (ntt) have presented ab= out this automation in the past.
=0A
 
=0A
google c= omes up with a few of these:
=0A
 
=0A
http://www.n= anog.org/meetings/nanog54/presentations/Tuesday/Morris.pdf
=0A
ht= tp://www.us.ntt.net/news/viewFile.cfm/NTT_Editorial_Capacity_Magazine_nov_= 2013.pdf?file_id=3D144
=0A
http://ptt.br/pttforum/7/doc/ptt_forum= 7_morris.pdf
=0A
 
=0A
- Jared
=0A
 <= /div>=0A
 
=0A
=0A ------=_001_NextPart373522705558_=------ From nobody Tue Feb 18 22:30:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9191A00D3 for ; Tue, 18 Feb 2014 22:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrPFl413AEKo for ; Tue, 18 Feb 2014 22:30:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6E1A0550 for ; Tue, 18 Feb 2014 22:30:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WG0g5-0007IC-9m; Wed, 19 Feb 2014 06:30:41 +0000 Date: Wed, 19 Feb 2014 14:30:39 +0800 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <5303CD3E.1010907@gmail.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/V7xndi5kPqQCQ9WsGp9ne_DZiGU Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 06:30:48 -0000 > But ULAs aren't bogons. They aren't supposed to be routed, but > if some people break that rule, is a ULA prefix objectively any > more harmful than an "official" PI prefix? guatanteed no colision From nobody Wed Feb 19 05:45:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484C71A04B4 for ; Wed, 19 Feb 2014 05:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn94C6-x1K1R for ; Wed, 19 Feb 2014 05:45:11 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id DBA451A01D3 for ; Wed, 19 Feb 2014 05:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392817509; x=1394027109; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=LAdaK5TqwHY0nIaDW+gGbbzkO1XSAxbuffGACzd0LpB/GPAqmw/wmv5Y HuOlrzXYXq5eASzKWrggYtEhhUrE9/fBG6fA9vHAY0pccAmVNBuMBVmWU hYc+DidM10OmvSH62P3jEH2Y2b5Yl1oibjYAsT6lPQf8OSWybIcHVWfoB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4LAH+0BFOrRDoG/2dsb2JhbABZgwY4qxMBlTMDBAKBFhZ0gyU8LQeIZQ7NYheOZB2EIgSJSJAakHKDTg X-IronPort-AV: E=Sophos;i="4.97,505,1389744000"; d="scan'208";a="103893321" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 19 Feb 2014 13:45:08 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1JDj1FK006500; Wed, 19 Feb 2014 13:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1JDj0n04335; Wed, 19 Feb 2014 05:45:00 -0800 (PST) Date: Wed, 19 Feb 2014 05:45:00 -0800 (PST) From: Message-Id: <201402191345.s1JDj0n04335@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/R9qKfu8DYOuuQp8n_NuaCmyfWFE Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 13:45:13 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Wed Feb 19 05:45:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E01A04CF for ; Wed, 19 Feb 2014 05:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kw734FwnRIk for ; Wed, 19 Feb 2014 05:45:20 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DB9E31A01D3 for ; Wed, 19 Feb 2014 05:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392817517; x=1394027117; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=cSryAAZghWA/Wg2tP7Oq7thDxQflZuEF3sld7DB6RLsoGjI1tIklX4DS +sUyU478u2b1mT1QXN6jjKHEovBNfZeS0uebv4K9080Wn/ttIHI71PLl+ Di6hNkTbSsySnxIir88QVX+vAfwOW8NCLl8XHNY2SceiFwO6rtxGmRkMr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4LAH+0BFOrRDoG/2dsb2JhbABZgwY4qxMBlTMDBAKBFhZ0gyU8NIhlDs1iF45kHYQiBIlIkBqQcoNO X-IronPort-AV: E=Sophos;i="4.97,505,1389744000"; d="scan'208";a="106470379" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 19 Feb 2014 13:45:16 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1JDjFWw006780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Feb 2014 13:45:15 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s1JDjF1D002386; Wed, 19 Feb 2014 05:45:15 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s1JDjDHs002329; Wed, 19 Feb 2014 05:45:13 -0800 (PST) Date: Wed, 19 Feb 2014 05:45:13 -0800 (PST) From: Fred Baker Message-Id: <201402191345.s1JDjDHs002329@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YVkB4nPnX_WDCFLgmkILkW1Fl6I Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 13:45:21 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Wed Feb 19 06:07:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD121A05DF for ; Wed, 19 Feb 2014 06:07:54 -0800 (PST) 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 7a5345nA549Z for ; Wed, 19 Feb 2014 06:07:53 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9251A05D2 for ; Wed, 19 Feb 2014 06:07:51 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s1JE7ljj001326 for ; Wed, 19 Feb 2014 15:07:47 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BD80C202B1D for ; Wed, 19 Feb 2014 15:08:29 +0100 (CET) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AC11D2028C2 for ; Wed, 19 Feb 2014 15:08:29 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s1JE7h1H004963 for ; Wed, 19 Feb 2014 15:07:47 +0100 Message-ID: <5304BAAF.60608@gmail.com> Date: Wed, 19 Feb 2014 15:07:43 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wRCpyQhNUD__k47wzYWUf30X6oE Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 14:07:55 -0000 Le 19/02/2014 07:30, Randy Bush a écrit : >> But ULAs aren't bogons. They aren't supposed to be routed, but >> if some people break that rule, is a ULA prefix objectively any >> more harmful than an "official" PI prefix? > > guaranteed no colision ULA presence in the wild - a bad thing - may be detected faster if it were colliding with another. Whereas PI presence in the wild is not known whether it is a good or a bad thing in the first place. Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Feb 19 10:41:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37AA1A01FB for ; Wed, 19 Feb 2014 10:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n-0dDPsvBPd for ; Wed, 19 Feb 2014 10:41:38 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 620381A014C for ; Wed, 19 Feb 2014 10:41:38 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id 4334F30007A for ; Wed, 19 Feb 2014 18:41:35 +0000 (UTC) Received: from shanes-mbp-5.ciena.com (unknown [205.150.9.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id CC4FF300052; Wed, 19 Feb 2014 11:41:29 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Shane Amante In-Reply-To: <20140218160639.GC12348@pfrc> Date: Wed, 19 Feb 2014 10:41:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E7D0DA0-0CC0-465C-8BA1-81809B1FEF80@castlepoint.net> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1827) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Feb 19 11:41:35 2014 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5304fadf42071089216475 X-DSPAM-Factors: 27, Mime-Version*OS+X, 0.01000, Mime-Version*X+#+#+1827, 0.01000, Cc*List+#+ietf.org, 0.01000, From*Amante+shane, 0.01000, Cc*List+v6ops, 0.01000, Cc*idr+wg, 0.01000, Subject*v6ops+BGP, 0.01000, Cc*Ops+#+v6ops, 0.01000, Mime-Version*OS+#+#+7.1, 0.01000, Cc*idr+ietf.org, 0.01000, Mime-Version*Mac+#+#+#+7.1, 0.01000, Cc*wg+#+ietf.org, 0.01000, Cc*V6+#+#+#+ietf.org, 0.01000, On+#+#+2014, 0.01000, Cc*Ops+List, 0.01000, Subject*BGP+Identifier, 0.01000, Cc*idr+#+#+ietf.org, 0.01000, Cc*V6+#+#+v6ops, 0.01000, Mime-Version*7.1+1827, 0.01000, Cc*V6+Ops, 0.01000, Mime-Version*1.0+Mac, 0.01000, From*Shane+#+shane, 0.01000, Cc*Ops+#+#+ietf.org, 0.01000, Cc*idr+#+idr, 0.01000, From*Shane Amante , 0.01000, is+#+a, 0.01000, 2014+#+#+#+AM, 0.01000 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6Yb_t2c1WmDxpRGMLF3ZC-v0m1g Cc: idr wg , V6 Ops List , JAMES Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Feb 2014 18:41:40 -0000 On Feb 18, 2014, at 8:06 AM, Jeffrey Haas wrote: > The fact that this number has been able to receive a mapping to a real > address has been extremely operationally useful. >=20 > What I would instead suggest is finding a mechanism by which the = unique > router-ID can be mapped easily to such addresses. I don't believe = that BGP is > the right place to do this. +1 -shane From nobody Wed Feb 19 11:03:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206EC1A03F7 for ; Wed, 19 Feb 2014 11:03:29 -0800 (PST) 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 UF5OeRplVi3v for ; Wed, 19 Feb 2014 11:03:26 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 580381A01FB for ; Wed, 19 Feb 2014 11:03:26 -0800 (PST) Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.103]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1WGCQS-0000TU-46; Wed, 19 Feb 2014 20:03:20 +0100 Message-ID: <5304FFE1.3040403@si6networks.com> Date: Wed, 19 Feb 2014 16:02:57 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <201402191345.s1JDjDHs002329@irp-view13.cisco.com> In-Reply-To: <201402191345.s1JDjDHs002329@irp-view13.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/veza1uTHPGfXsSU-UCrqHXjJ5f4 Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: Re: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:03:29 -0000 Hi, Joel, Minor comment: While one would expect that a host implementation checks the packet embedded in the ICMPv6 payload, the ones that I recall checking do not. e.g., if you send an ICMPv6 error to a node that references a non-existent transport-protocol instance (e.g., a TCP connection that doesn't exist), they will honor the error message anyway. One might argue that that's not really harmful -- at the end of the day, you don't *raise* the assummed Path-MTU in response to ICMPv6 errors, but rather only lower it... so in the worst case scenario, you'd reduce the PMTUD for transport-protocol instances for which you didn't need to. Another one, which probably doesn't matter in practice: Even with RFC7112 in place, if a packet is emitted with a very long header chain, the ICMPv6 error might not not contain the transport header. (yes, I'm aware that packets with EHs are commonly filtered, etc.) Thanks, Fernando On 02/19/2014 10:45 AM, Fred Baker wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Feb 19 14:08:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863781A04C1 for ; Wed, 19 Feb 2014 14:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoV2IwAIH7Xe for ; Wed, 19 Feb 2014 14:07:59 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B3FC51A0276 for ; Wed, 19 Feb 2014 14:07:59 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id y10so930838pdj.32 for ; Wed, 19 Feb 2014 14:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qteziYr9zYOuFA8oqTde+3/SuoG3go2ZtHIIvnSfdio=; b=AZbrVppdQcAuyIX6zHJF7gDTAp/ORIxyzxKOYUWW5ieAeG5CutGN7Hozh1yr9+IIae ngUyUJMJNSrYF4RZvNmlK3QSZ/3y28caTF0g83/nhs4A2p0P8zBTTFSm43Z8xTG1BWQ/ csytQ2il/u4HSmUAAgI8AIC8opOtcaDewzGptdnOaTLtOB6yJY3+JBMFsiZaCTbG1HX2 dXAfKUV0vt4ZcBjpnY3PUlpO7alkZZ+1h0NMnjeL72TE9M0LOC+EpAKPGuFtcsTJ/fWa bJiPaCMA8bPVJac0Qq9IxFomEgSWwvbvpTKry7xr5SNniEYwxT12dI4uLp9BT2j8MyGQ BK1g== X-Received: by 10.66.27.107 with SMTP id s11mr4983164pag.64.1392847676463; Wed, 19 Feb 2014 14:07:56 -0800 (PST) Received: from [192.168.178.23] (150.198.69.111.dynamic.snap.net.nz. [111.69.198.150]) by mx.google.com with ESMTPSA id ix2sm856978pbc.45.2014.02.19.14.07.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 14:07:55 -0800 (PST) Message-ID: <53052B43.2070904@gmail.com> Date: Thu, 20 Feb 2014 11:08:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> In-Reply-To: <5304BAAF.60608@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XGXLRt7Bm32hUoNoK3_FhVSpq9Y Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:08:02 -0000 On 20/02/2014 03:07, Alexandru Petrescu wrote: > Le 19/02/2014 07:30, Randy Bush a =C3=A9crit : >>> But ULAs aren't bogons. They aren't supposed to be routed, but >>> if some people break that rule, is a ULA prefix objectively any >>> more harmful than an "official" PI prefix? >> >> guaranteed no colision >=20 > ULA presence in the wild - a bad thing - may be detected faster if it > were colliding with another. Whereas PI presence in the wild is not > known whether it is a good or a bad thing in the first place. ULA collisions can occur in two cases: 1. More than one party not following the spec on how to generate a ULA prefix - so they will be punished for their own mistakes. 2. A piece of remarkably bad luck, rather less likely than winning any lottery I'm aware of. Are we really going to worry about this? Especially since neither case applies in in wide-area routing, where ULAs should always be filtered anyway. Brian From nobody Wed Feb 19 17:18:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344E71A0423 for ; Wed, 19 Feb 2014 17:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 oAHtcUxL7_Sw for ; Wed, 19 Feb 2014 17:18:14 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8531A02BB for ; Wed, 19 Feb 2014 17:18:12 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id h3so2290739igd.5 for ; Wed, 19 Feb 2014 17:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yasgnoAni3AMJw18fh5fH6KQN7wl+fJf7oqgSDYTteU=; b=fS4W68k4o+t4NNIp0HEdYPXjpNWN+SiSj2BHk0vlPGcKU0ZRwGPwMi+DufPo0XSf1y FRckW/gh3AJHFIOxJUWj7twG81dky7c8Y5+Cs8h3cYbfBIZmDQqgLlCHrZfbyLSKyN4t sUZZIk25qTQigD0djiB+T16UjpQ00I+blee3++GU4XjffJwZJzmvTknueAiancVLb1gv G7TYllT6sfxtV6TcRrG72QHraCcQKkdYdFmgOYD3v+XbDrQeNpPD2lesl3NLceRiB7AN XA53ctVCm6wtJl/G7dooJzNB3/X71+pUllARRhIAvBnaLg1bONnZYwbBcJgiNkcJVJiG W2JA== 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=yasgnoAni3AMJw18fh5fH6KQN7wl+fJf7oqgSDYTteU=; b=EMChyzzR5xiOCdG0j8dIavmT/TGAdnhDp3zU8FVJeycpSHB6AY/knFNbLhSlMc32wA JjFzIZm/kGAy3mxbHYLoxg3t+Htn5bwO5pBYs06s0CMoVt+48Y7l/IMY1A7o9+ElF5uY Z+RFDwMLR3RZn69niruc0PXq00WPiY0xphCSEA3SDgnH6U2ZwCQ98zP1Rug8dGNYPEHS CakR9yCBGPjaR3jrYRC2AIG6p6K/nZFFUJ3ak4EawGJYXa2p0mT4dA9MgwAWMCEoIy1f n+pEoS8+nBq03ZCaXygmz0YvwQy4Vpj/HonvygGpghBx+QtavezjIokzpNUP2RGs589+ IpjQ== X-Gm-Message-State: ALoCoQmneB6oG+NuhtYsAEWxCU/LXtF/fgGjfilBx8KLHlxZ1WjbHKtbXR5w37TiSTVFdYxoqQ9LWm1sQJN5/i+umyHXqODIteiJlbj3onGSJf8nUzE9JWUI09DP4MfYjhvJtGXvqALZIroidZ+Yv/qy0Bx0UPxy5BcgEryY0AZC5Fnx/pb44DMLRpGdeEnWLjiT0vsJfcmK X-Received: by 10.43.153.68 with SMTP id kz4mr29071835icc.29.1392859088794; Wed, 19 Feb 2014 17:18:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 19 Feb 2014 17:17:48 -0800 (PST) In-Reply-To: <53052B43.2070904@gmail.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> From: Lorenzo Colitti Date: Thu, 20 Feb 2014 10:17:48 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a11c2ecd835d12004f2cc4784 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/z3MehxaeSXuhG9WKLL32aYdQdtw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:18:16 -0000 --001a11c2ecd835d12004f2cc4784 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 7:08 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > 1. More than one party not following the spec on how to generate > a ULA prefix - so they will be punished for their own mistakes. > How are they punished? And what will they do when they are punished? I guarantee that renumbering will not be the solution, NAT will be the solution. 2. A piece of remarkably bad luck, rather less likely than > winning any lottery I'm aware of. > You assume that people will actually follow the rules instead of saying "let's just do this like IPv4, and use NAT at the border". --001a11c2ecd835d12004f2cc4784 Content-Type: text/html; charset=UTF-8
On Thu, Feb 20, 2014 at 7:08 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
1. More than one party not following the spec on how to generate
a ULA prefix - so they will be punished for their own mistakes.

How are they punished? And what will they do when they are punished? I guarantee that renumbering will not be the solution, NAT will be the solution.

2. A piece of remarkably bad luck, rather less likely than
winning any lottery I'm aware of.

You assume that people will actually follow the rules instead of saying "let's just do this like IPv4, and use NAT at the border".
--001a11c2ecd835d12004f2cc4784-- From nobody Wed Feb 19 17:33:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC7D1A060C for ; Wed, 19 Feb 2014 17:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak1HKjs4BfA5 for ; Wed, 19 Feb 2014 17:33:05 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id F30591A0423 for ; Wed, 19 Feb 2014 17:33:04 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C2FD21B826F for ; Wed, 19 Feb 2014 17:33:01 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B2C39190052; Wed, 19 Feb 2014 17:33:01 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 17:33:01 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 19 Feb 2014 20:32:59 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <9878D4FB-9681-4EFC-A6EF-314F9DCB36DE@nominum.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5uwnVCzwTEcvQOg5jfMgc7llHm8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:33:06 -0000 On Feb 19, 2014, at 8:17 PM, Lorenzo Colitti wrote: > You assume that people will actually follow the rules instead of = saying "let's just do this like IPv4, and use NAT at the border". If they are having a collision between ULAs because they used a bad = algorithm for choosing their prefix, and if this is in any sense an = inconvenience for them, then they have already deployed IPv6 in a fairly = widespread fashion, and they aren't just going to back it out and go to = IPv4. Renumbering would be no more work. I agree that a NAT is another likely outcome, but come on, Lorenzo. = How realistic is this scenario? The RFC1918 collision/merger problem = is well enough known that I've heard of it, and I don't do corporate = numbering. Of course this could happen, but if it does it will happen = infrequently, and people will get fired over it, and it will ultimately = stop happening. From nobody Wed Feb 19 17:35:38 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB4F1A0423 for ; Wed, 19 Feb 2014 17:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 Piilc5s4my8p for ; Wed, 19 Feb 2014 17:35:35 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3441A00FA for ; Wed, 19 Feb 2014 17:35:35 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 16A8E2383D2; Thu, 20 Feb 2014 01:35:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E943E160060; Thu, 20 Feb 2014 01:36:07 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B316816005D; Thu, 20 Feb 2014 01:36:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DE278FD134B; Thu, 20 Feb 2014 12:35:16 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> In-reply-to: Your message of "Thu, 20 Feb 2014 10:17:48 +0900." Date: Thu, 20 Feb 2014 12:35:16 +1100 Message-Id: <20140220013516.DE278FD134B@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/I6dM3jIyeFakRgQJxgIC7erAvOo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:35:37 -0000 In message , Lorenzo Colitti writes: > > On Thu, Feb 20, 2014 at 7:08 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > 1. More than one party not following the spec on how to generate > > a ULA prefix - so they will be punished for their own mistakes. > > > > How are they punished? And what will they do when they are punished? I > guarantee that renumbering will not be the solution, NAT will be the > solution. Both sites just generate a NEW ULA prefixes. They can continue to use the collision prefix until the heat death of the universe if they wish to or they can migrate to the new prefix. IPv6 is NOT IPv4. Running parallel prefixes is *standard* proceedure. They just need to talk to each other using the NEW prefixes which should be no more complicated than pushing new address selection tables. If they really want to they can choose to use the same new prefix and create a site that covers both of the old sites splitting the address space. If they do that they don't even need to push new address selection tables. > 2. A piece of remarkably bad luck, rather less likely than > > winning any lottery I'm aware of. > > > > You assume that people will actually follow the rules instead of saying > "let's just do this like IPv4, and use NAT at the border". > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 19 17:40:41 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580E41A0423 for ; Wed, 19 Feb 2014 17:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 nyDcT0fzBkNu for ; Wed, 19 Feb 2014 17:40:36 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id C31291A0216 for ; Wed, 19 Feb 2014 17:40:36 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id m12so2517824iga.1 for ; Wed, 19 Feb 2014 17:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gvh4vq0Wz1ZFnS780ENzCaz/a+VxqpGJSzRUMPJMVUw=; b=FcjOF7giKOYDIYOUfOIBUIWR95IBBeYFIrGS/V4rStKp0vv+Vheys9zYhL5iIrf+nQ wJZyMkJmlX9jXKKd2XTPUmS4LUUvfebT1dx/Ak+c/9no14SlpkFCLF6iiyu2TWBqKt/B EY+104BIpS/0OSb7aUlQUCtWXmlD913OJ3QTsYDaXUTTrYfYuelVIpOdiVgIC3HS/uN6 yKpuE1SykBkJd+o63jwaEc85WPL461sXmvnCvwIDMeUvMLNFIB6Pj+HwU6NqKHaQiobe UELHNqGH9PfpGEgJIRKljCgXBMJGBcCkTyIJf3O3X7e2e2CR3H0nJqYQ5kI8tLbkQ4KR P8Sw== 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=gvh4vq0Wz1ZFnS780ENzCaz/a+VxqpGJSzRUMPJMVUw=; b=AVuej97nPYiYtynMwf8KzmSIUk+MjgRRtFIkcR39M+dlGanBK5uJSi+RPpKu0VKiJr aIFyyTjqJvZtCw4y0ayeJJLDHu9sSBgNtChmQyX3ovH+O4pBN/YzJ7pAJ/4SeaWFBUON 802K/xrZi6jZ/kcQi3yJZ5mbyCZH8EAoe77UDTrUXk8gkfPFSVz2asyKp3+Ktx7SP8C6 y1TN7LObS4L3VJSFMTgcbH85Xy8Rn2j1Qms4jqyION+hoK6EXY/UCap+8pDELvyUgQxN SsZry93yziVoOzOgcnu9IjWe5JKgvvxfBFVxaBWs2cTj2vPZxIRQtXqFOE/hdgIKZCai 8/XA== X-Gm-Message-State: ALoCoQkWe4/tQ3tImYVz8N0kdOBC3cp3xAusNyHvaBV4kHolM4ey1JZz0nwIgEo3C6Yu4gNTlMPjnqDSuyPn0gOpN2OoQhtRuCQE27ljdESGxSxxK1D7u0DbrCEDkOKeprXUk5tzCw0so8ksoJ9pSoLF6Z5EJOskXvIFDbIGQXocVH0G4TvLwSo//z6TyRjGIn6N4v1V1KSP X-Received: by 10.43.83.68 with SMTP id af4mr3558857icc.60.1392860433253; Wed, 19 Feb 2014 17:40:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 19 Feb 2014 17:40:13 -0800 (PST) In-Reply-To: <9878D4FB-9681-4EFC-A6EF-314F9DCB36DE@nominum.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <9878D4FB-9681-4EFC-A6EF-314F9DCB36DE@nominum.com> From: Lorenzo Colitti Date: Thu, 20 Feb 2014 10:40:13 +0900 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=f46d0447f0fe58ac7204f2cc97a7 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/jPzMTYU31NtyKpu128w9nwjytgo Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:40:39 -0000 --f46d0447f0fe58ac7204f2cc97a7 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 10:32 AM, Ted Lemon wrote: > I agree that a NAT is another likely outcome, but come on, Lorenzo. How > realistic is this scenario? The RFC1918 collision/merger problem is well > enough known that I've heard of it, and I don't do corporate numbering. > Of course this could happen, but if it does it will happen infrequently, > and people will get fired over it, and it will ultimately stop happening. > To paraphrase Owen, "you are ignoring the realities of modern corporate IT staffing". Saying that people will get fired for picking the wrong ULA range is simply ludicrous. --f46d0447f0fe58ac7204f2cc97a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 10:32 AM, Ted Lemon <ted.lemon@nominum.com>= wrote:
I agree that a NAT is anothe= r likely outcome, but come on, Lorenzo. =C2=A0 How realistic is this scenar= io? =C2=A0 The RFC1918 collision/merger problem is well enough known that I= 've heard of it, and I don't do corporate numbering. =C2=A0 Of cour= se this could happen, but if it does it will happen infrequently, and peopl= e will get fired over it, and it will ultimately stop happening.

To paraphrase Owen, "you are ignoring= the realities of modern corporate IT staffing". Saying that people wi= ll get fired for picking the wrong ULA range is simply ludicrous.
--f46d0447f0fe58ac7204f2cc97a7-- From nobody Wed Feb 19 17:46:52 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FCA1A0168 for ; Wed, 19 Feb 2014 17:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 TLP_hxazVtN9 for ; Wed, 19 Feb 2014 17:46:48 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E95BE1A0103 for ; Wed, 19 Feb 2014 17:46:47 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id uq10so10767904igb.2 for ; Wed, 19 Feb 2014 17:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Wr6tqeYsunPhpUPQPyX06MPWkt4SivWC/KxlU1tiImc=; b=WV8ww2Mq8wX2W0zrswbJux4/Y4c5MnF0fnpclSShNHDxvcLmg4mS7O1tSbJS+fuiDH mNxFrDJDwl4WNYWwi2t0G7v4v8lGFDbW0CHRKvM4MCwB4OZ663nTBskwjYZwHeXMd3BW wLAXwlmBxw2X9fnUm5+Gp3MrP/nyuGqSqIbpGd5iYMIf2c8pTnfy7XU0Ah9EgaPT/w5q YVL66YFYFRkN5hZN6B4Ek+kSN6rXY8wbGAmF4TGLcgCCtH0dg00jZl9yR9az+Z8KleG4 Tq/l2CsC3Ax8EGquB1B2SZKb+4LBBLDteMjjKu7U9KM+3BMUg9r1MqkBfKRC1KXkFjem FXbw== 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=Wr6tqeYsunPhpUPQPyX06MPWkt4SivWC/KxlU1tiImc=; b=UUt+1RIAUSTcDe4fR5Q1K/u7eOsmd2/3+Vtd9HVl4h1PTkf22aP+M79xp4McwfAy0w CwCTmRk4TlKLNfV91BwikHDi0iUe2e/RlZh1g3bd0+KgukUw42k4PXM2w8CFlmUG5Z2g GC1Ihwit7S7/8A8ArXijGnQjn5mtzFx6CAfzinwpJVhXHDY+Eeh04wRzxrrZFT/QFbp8 HBMp6sXK21TJcAdn5KzAeuilJVMroT7CciG+9fl6/+YB3iR7AbCd926aM1C85SN7FPMi kvIh/yF2310ve/RdkakETh0HrdVdvG+cjYlPIt9bGF1gs6UQGUMzEjp4dlDIXsBiK7be sZYw== X-Gm-Message-State: ALoCoQltoAP4SBHSjJBIy0wvtb17rWLt2Atoc8PoICOuuDVQ+O0ExU7M858p4kw58orKUf5eCKSqJZPLyWjapAGh0dzI5d1CJBQXuDy7wbY30x8XcuthagqW8hWjWwJZB26xEwMAs5mGaGyMF3RlP0i3hdvOARwkBVVaqVGmdtzWv4G9NJIHQujx2EY+OnGl+i+D2oo5DvM9 X-Received: by 10.50.143.12 with SMTP id sa12mr4257079igb.45.1392860804513; Wed, 19 Feb 2014 17:46:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 19 Feb 2014 17:46:24 -0800 (PST) In-Reply-To: <20140220013516.DE278FD134B@rock.dv.isc.org> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <20140220013516.DE278FD134B@rock.dv.isc.org> From: Lorenzo Colitti Date: Thu, 20 Feb 2014 10:46:24 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=001a1134cd0279f08004f2ccad8f Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/OGNS5CCg9lYTcD0iJjkjef5oTOk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:46:50 -0000 --001a1134cd0279f08004f2ccad8f Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 10:35 AM, Mark Andrews wrote: > > How are they punished? And what will they do when they are punished? I > > guarantee that renumbering will not be the solution, NAT will be the > > solution. > > Both sites just generate a NEW ULA prefixes. They can continue to > use the collision prefix until the heat death of the universe if > they wish to or they can migrate to the new prefix. IPv6 is NOT > IPv4. Running parallel prefixes is *standard* proceedure. They > just need to talk to each other using the NEW prefixes which should > be no more complicated than pushing new address selection tables. > No, sorry. One of the main reasons people are advocating ULAs here is "because we'll have stable space and will never have to renumber!!11". Once you buy into that mantra, you'll be hardcoding IP addresses into configuration again, exactly like we do in IPv4 today. And exactly like in IPv4 today, renumbering will be prohibitively expensive. As for multiple ULA prefixes... again, I think you're ignoring the realities of corporate IT staffing, corporate IT systems, and vendor capabilities. I think it's obvious that the path of least resistance (and thus, the solution that most admins would choose) will be NAT/NPT. After all, if you want to use ULAs to talk to the outside world (And why wouldn't you, right? It's what we do in IPv4, right?), you have to do NAT or NPT anyway. --001a1134cd0279f08004f2ccad8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 10:35 AM, Mark Andrews <marka@isc.org> wrote= :
> How are they punished? And what will they do when they= are punished? I
> guarantee that renumbering will not be the solution, NAT will be the > solution.

Both sites just generate a NEW ULA prefixes. =C2=A0They can continue = to
use the collision prefix until the heat death of the universe if
they wish to or they can migrate to the new prefix. =C2=A0IPv6 is NOT
IPv4. =C2=A0Running parallel prefixes is *standard* proceedure. =C2=A0They<= br> just need to talk to each other using the NEW prefixes which should
be no more complicated than pushing new address selection tables.

No, sorry. One of the main reasons people are ad= vocating ULAs here is "because we'll have stable space and will ne= ver have to renumber!!11". Once you buy into that mantra, you'll b= e hardcoding IP addresses into configuration again, exactly like we do in I= Pv4 today. And exactly like in IPv4 today, renumbering will be prohibitivel= y expensive.

As for multiple ULA prefixes... again, I think you'= re ignoring the realities of corporate IT staffing, corporate IT systems, a= nd vendor capabilities.

I think it's obvious t= hat the path of least resistance (and thus, the solution that most admins w= ould choose) will be NAT/NPT. After all, if you want to use ULAs to talk to= the outside world (And why wouldn't you, right? It's what we do in= IPv4, right?), you have to do NAT or NPT anyway.
--001a1134cd0279f08004f2ccad8f-- From nobody Wed Feb 19 17:52:59 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B77B1A0623 for ; Wed, 19 Feb 2014 17:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g38rpRmrEjT for ; Wed, 19 Feb 2014 17:52:50 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 61FFF1A0618 for ; Wed, 19 Feb 2014 17:52:50 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so1204448pbb.23 for ; Wed, 19 Feb 2014 17:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zk7Po++HD94qqRMWe7I09UmFGTak/DeNbsy6PlFMlZI=; b=smjLG4BaO58V+T72Pcbq65ObPY6atbKvcDRdU6DmF3+sk6lRfEHAMd0QBiSPMQWbrZ 6g7MRcw9nxPIyZ3LgmEkUylMtHdRpTnZtdGZgjMbnJIsu8/CHQZkdWPystDhmCFqOmBR 8hGuSyWCCN7H1U57CIgwm89hFtLYHYGN53hqFqzDv7Hfci9scSmNkrgeK0UDrspllYVw GkokvJyFszq/n+W4AAllNK4PE9YSkZTQy1MNCkGJe+6KgvkWBndEIWNYw6z67pJUTahf AYAxzrEHVDxQcYQy+xp5d4DtbdAOy3tqn6KV8KYo/UA3sDPFs/I0WpiKpuDzPPhZTz4u MB7w== X-Received: by 10.68.212.10 with SMTP id ng10mr5957149pbc.95.1392861167123; Wed, 19 Feb 2014 17:52:47 -0800 (PST) Received: from [192.168.178.23] (232.201.69.111.dynamic.snap.net.nz. [111.69.201.232]) by mx.google.com with ESMTPSA id db3sm5121948pbb.10.2014.02.19.17.52.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 17:52:46 -0800 (PST) Message-ID: <53055FF3.2040605@gmail.com> Date: Thu, 20 Feb 2014 14:52:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/WkHVlvDsFjib0I4MmLAbn-hciR8 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 01:52:56 -0000 On 20/02/2014 14:17, Lorenzo Colitti wrote: > On Thu, Feb 20, 2014 at 7:08 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> 1. More than one party not following the spec on how to generate >> a ULA prefix - so they will be punished for their own mistakes. >> > > How are they punished? They'll be punished because it won't work. Assuming this happens when a network attempts to route a new prefix that (in some limited domain) collides, then changing the new prefix shouldn't really be an issue. Remember this will only occur inside a domain, since I really think ISPs will filter these things (except for specific /48s if forced to route them by money). If they don't simply change the new prefix, ... > And what will they do when they are punished? I > guarantee that renumbering will not be the solution, NAT will be the > solution. Yes, they might go to the *extra* work of configuring NPTv6 or worse. Not a good thing. But we know we can't stop people doing bad things. By the time they've misconfigured their ULA prefix, they're already on a bad road. > 2. A piece of remarkably bad luck, rather less likely than >> winning any lottery I'm aware of. >> > > You assume that people will actually follow the rules instead of saying > "let's just do this like IPv4, and use NAT at the border". If CERs do the right thing the ULA prefix will be generated correctly. But you're right, there will be a generation of old-time IPv4 operators who will do exactly that whatever we put in RFCs. Brian From nobody Wed Feb 19 18:00:14 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9781A02CE for ; Wed, 19 Feb 2014 18:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, 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 fHf02kg91AVA for ; Wed, 19 Feb 2014 18:00:10 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C7CAF1A00F5 for ; Wed, 19 Feb 2014 18:00:09 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 8D86FC947E; Thu, 20 Feb 2014 01:59:53 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1392861606; bh=wGps/EAiIuqE2Dz4AD9fXbXzUNaLsixc9elM9joMrwY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=bhznc9lt0/96LnCJKNL/YIcaQ3i9cOBoyvLolhve3jDCAEnaCeX+SyaAF8yHRb5Xe ljhv0BTQq/XEQlfW119zhTWit3XNmeJSmyEKYRzAOYq2yZV9uS6beHu+D/ja3/ntQY arishnSK/Mi0ZhUPjFxPI7PhjL4VP5pKwD3z0Qrs= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 20 Feb 2014 01:59:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F23A616005B; Thu, 20 Feb 2014 02:00:41 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B8F74160056; Thu, 20 Feb 2014 02:00:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2A328FD160B; Thu, 20 Feb 2014 12:59:51 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <20140220013516.DE278FD134B@rock.dv.isc.org> In-reply-to: Your message of "Thu, 20 Feb 2014 10:46:24 +0900." Date: Thu, 20 Feb 2014 12:59:50 +1100 Message-Id: <20140220015951.2A328FD160B@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/fIs3MJ4h541MSjT38zkGz-KzSvk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:00:11 -0000 In message , Lorenzo Colitti writes: > On Thu, Feb 20, 2014 at 10:35 AM, Mark Andrews wrote: > > > > How are they punished? And what will they do when they are punished? I > > > guarantee that renumbering will not be the solution, NAT will be the > > > solution. > > > > Both sites just generate a NEW ULA prefixes. They can continue to > > use the collision prefix until the heat death of the universe if > > they wish to or they can migrate to the new prefix. IPv6 is NOT > > IPv4. Running parallel prefixes is *standard* proceedure. They > > just need to talk to each other using the NEW prefixes which should > > be no more complicated than pushing new address selection tables. > > > > No, sorry. One of the main reasons people are advocating ULAs here is > "because we'll have stable space and will never have to renumber!!11". Once > you buy into that mantra, you'll be hardcoding IP addresses into > configuration again, exactly like we do in IPv4 today. And exactly like in > IPv4 today, renumbering will be prohibitively expensive. > > As for multiple ULA prefixes... again, I think you're ignoring the > realities of corporate IT staffing, corporate IT systems, and vendor > capabilities. I already run multiple prefixes at home and have for years. Vendors *already* support multiple prefixes. Corperate IP systems will be supporting ULA1 + GUA1 (+ GUA2 + GUA3 for multi-homers). ULA1 + ULA2 + GUA1 (+ GUA2 + GUA3) is not a big streach. Now as for corporate IP staff you teach them what to do when teaching the how to run IPv6 networks. > I think it's obvious that the path of least resistance (and thus, the > solution that most admins would choose) will be NAT/NPT. After all, if you > want to use ULAs to talk to the outside world (And why wouldn't you, right? > It's what we do in IPv4, right?), you have to do NAT or NPT anyway. It's a matter of education. Adding "How to deal with a ULA prefix collisions" to this document would be a good first step. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 19 18:00:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8141A0623 for ; Wed, 19 Feb 2014 18:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 3mN_LANceQeV for ; Wed, 19 Feb 2014 18:00:40 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 941FF1A016A for ; Wed, 19 Feb 2014 18:00:40 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id uq10so2504605igb.5 for ; Wed, 19 Feb 2014 18:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QOa6JRpoCAEQ87MzeG1RpSHIT/eUXED9T82fP7u/7Dw=; b=Rj7Wm9eJzMtKgCM45ezq4dt//f8ip5msQ1V00/aOVD3luo9wx510lDZEH+UZALfGch Z+0yWF8tDvBKiOIoGFyAbfEiJr+rBvbNok3mNAixzatyWWTx7n1EPLFp7ra3EBsoZSGM ofRsl7jNymL/54z/ZNPyxTiTwwtE2NvMXhmvIzR201TNNkvwgLhwFqFKmIh0+1TwCGUg BGR5+LNYJT2a6B4/XdsqdZcI9lWK/x3UibP/mW0JEZ1dQ8ROmvPcMfFaaSxLlMzYAq/j /u43jpBCcyzB4uMgJC/rmSz+jvApXX7gnfJmXuwHlHaaG4OA2CgUqumGeMN7//8DOo7w uGwg== 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=QOa6JRpoCAEQ87MzeG1RpSHIT/eUXED9T82fP7u/7Dw=; b=lr+XLwTzoXvl0dTqesxbwZoflGxx+AFRgyqZDlw8Ek6P/sUO9w43W8hfw3wZqIRBMl 5y4SeBs+juvLlMUZNBOy57uZnT+pK2UPpzDmXeWAbhSEtfKaXSEnc9URXyrrHEp1DqLF iyMcFOenzUNrIeGyj6mhjp78CqB5rvWx6U2nVUZf/UkaCA5MLT1Lcsf5ZU8Auupq6L6z HaWx8Suz0ey9BWSG+QqCQmlolqoK9Ajrl6GqhhEcbjitYRV81KahCf2doELwaREd04nT OAXTu2jp9sPn2no+iC3TJH+BtqxBwc8UIb399lY38zZNqoeYGanm1akgKPNth9YqPBC5 WBtg== X-Gm-Message-State: ALoCoQl66lHay5gcNxBjA5ve0Hb1pNXyuGLuokonJLAEcyqM/LONIbJ7dweSXEUIXnSNSDJ+sA5QpC6tlNCoVM5weZU50B0B0Wan8rgav7EQNPFg0uOxdPdwgrQXFqNldxjN7tu0i3Ok0TZnzaMn/XA+rUWRuoPcV9gSu7i/tASgoWZYEluQtP5WV02jnPjUYKESxt/R00Bv X-Received: by 10.43.83.68 with SMTP id af4mr3605216icc.60.1392861637122; Wed, 19 Feb 2014 18:00:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 19 Feb 2014 18:00:17 -0800 (PST) In-Reply-To: <53055FF3.2040605@gmail.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> From: Lorenzo Colitti Date: Thu, 20 Feb 2014 11:00:17 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d0447f0fe1a3d8904f2ccdf93 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/YFmWT6-MIPF38w-fMhCleASno6M Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:00:42 -0000 --f46d0447f0fe1a3d8904f2ccdf93 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 10:52 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > 2. A piece of remarkably bad luck, rather less likely than > >> winning any lottery I'm aware of. > Can you elaborate on exactly how bad this luck is as a function of how many ULA prefixes you use your organization? For example - if two large organizations that each use 200 ULA /48s (one per site) merge, what is the chance that one of them will collide? I don't feel it's satisfactory to say "the probability of a collision is low" without saying how low it actually is. In fact, I think the draft should not be published without giving a few examples of these numbers. If *nobody* among the authors or on this list knows what the numbers actually are, then we should not advocate using ULAs. It is not good engineering practice to recommend something that you do not understand. > You assume that people will actually follow the rules instead of saying > > "let's just do this like IPv4, and use NAT at the border". > > If CERs do the right thing the ULA prefix will be generated > correctly. But you're right, there will be a generation of > old-time IPv4 operators who will do exactly that whatever we > put in RFCs. > I'm not talking about home networks here, I'm talking about corporate IT environments. --f46d0447f0fe1a3d8904f2ccdf93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 10:52 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
> 2. A piece of remarkabl= y bad luck, rather less likely than
>> winning any lottery I'm aware of.
<= br>
Can you elaborate on exactly how bad this luck is as a functi= on of how many ULA prefixes you use your organization?

For ex= ample - if two large organizations that each use 200 ULA /48s (one per site= ) merge, what is the chance that one of them will collide?

I don't feel it's satisfactory to say "the= probability of a collision is low" without saying how low it actually= is. In fact, I think the draft should not be published without giving a fe= w examples of these numbers. If *nobody* among the authors or on this list = knows what the numbers actually are, then we should not advocate using ULAs= . It is not good engineering practice to recommend something that you do no= t understand.

> You assu= me that people will actually follow the rules instead of saying
> "let's just do this like IPv4, and use NAT at the border"= ;.

If CERs do the right thing the ULA prefix will be generated
correctly. But you're right, there will be a generation of
old-time IPv4 operators who will do exactly that whatever we
put in RFCs.

I'm not talking about = home networks here, I'm talking about corporate IT environments.
<= /div>
--f46d0447f0fe1a3d8904f2ccdf93-- From nobody Wed Feb 19 18:03:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8BB1A016A for ; Wed, 19 Feb 2014 18:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 OU93C0rwxRsS for ; Wed, 19 Feb 2014 18:03:18 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id F3E591A00F5 for ; Wed, 19 Feb 2014 18:03:17 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id to1so867177ieb.38 for ; Wed, 19 Feb 2014 18:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ta2aGZ66VCk5o7ovbSJA67pQTXLPxqwg0JoDVW0JBrA=; b=a0mgxuwVv/oFCPNEIRIzDNgpnpR0mkKFOh1KH5hR5vCZbBFVCnyovGaAn4wSvb/z5r Kvp140vZAlwLSkmXUnm2fcXRjs/Sbj+ADK+p2hznFD381vY+uPnV7rACI+Ve3ks5VKoE GQrq63b42QLFfAWmHmOueB7DyVQKzzJpFS/qFjvIs/Fa7xU/w+T+thdxiPIIZpgjjohb 2M8hibFJQfaXqL5v49RSY3rwvhICzG4gt5T3sfVlsz+99VlJ5Ffk/2oGeqxRHa8b2R+s dErXq/0N9j7X8ODBgnekyBzCr6/AsgqNEevcHBQtCAfFeKDrJ1O2XmH3C9Z9UOhf83H0 A5pA== 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=ta2aGZ66VCk5o7ovbSJA67pQTXLPxqwg0JoDVW0JBrA=; b=WGvqaD3aDz1ieyYymrMdeuTy1rCTGaM18HQHtGsds64WjYJ6W5/hJRyBiX28Y+RPtG Dpm/vX5nuyhMnZyoLCGuxUYOSstZpOnVIVABOFgpItCbga2r2zUkcTxOTxhh2fkOlMze zyxVjMg4DPP3fuHZwJMaPnrTN4sR78bwVSpbCLvuLF5Ugi5v6LaPyA6o4dpPn12gejZ4 uEDP08aBmghyHThfbkB39NA9rHLmSl2q1TC1f94ZwnpE1qrpDH9qMRnwIGis5QDa4/TR 6ECFY+7W5fhlJdaXfk5hZJQP04Iu0EdwY7WD/nfyGvEiKGZheTtODXp4TIgjzjMlAKVe 1Hjg== X-Gm-Message-State: ALoCoQmwwSMrQbIk3VliI3+ZvvGDvEicHeyotXiDrdZDBwsHu7wPGitOmEdQNhNUdEuFmXmBoUK+uWT/6CXs103LOamaRlUR8uWOtaC56pWKOJFbtxH2pREmGus/wRzRI4HF/NDAhBrzsauDkZoLaxKJPOP67fz8e6H4XvUpSk8TUWJRzITXJGoxpq9M58Ml3BDzmPIoTxDj X-Received: by 10.50.79.166 with SMTP id k6mr4195291igx.47.1392861794517; Wed, 19 Feb 2014 18:03:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Wed, 19 Feb 2014 18:02:54 -0800 (PST) In-Reply-To: <20140220015951.2A328FD160B@rock.dv.isc.org> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <20140220013516.DE278FD134B@rock.dv.isc.org> <20140220015951.2A328FD160B@rock.dv.isc.org> From: Lorenzo Colitti Date: Thu, 20 Feb 2014 11:02:54 +0900 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=089e013a114e7bde2904f2cce89f Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z45ItDLKtnBav_ukEfMfbJGzFy0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:03:19 -0000 --089e013a114e7bde2904f2cce89f Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 10:59 AM, Mark Andrews wrote: > > As for multiple ULA prefixes... again, I think you're ignoring the > > realities of corporate IT staffing, corporate IT systems, and vendor > > capabilities. > > I already run multiple prefixes at home and have for years. Vendors > *already* support multiple prefixes. Corperate IP systems will be > supporting ULA1 + GUA1 (+ GUA2 + GUA3 for multi-homers). ULA1 + > ULA2 + GUA1 (+ GUA2 + GUA3) is not a big streach. Now as for > corporate IP staff you teach them what to do when teaching the how > to run IPv6 networks. > Frankly, I believe you are being hopelessly optimistic. What you are able to do and what a resource-constrained IT department in a small company will do are so many standard deviations apart that you might as well not be on the same planet. --089e013a114e7bde2904f2cce89f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 10:59 AM, Mark Andrews <marka@isc.org> wrote= :
> As for multiple ULA prefixes... again, I think you'= ;re ignoring the
> realities of corporate IT staffing, corporate IT systems, and vendor > capabilities.

I already run multiple prefixes at home and have for years. =C2=A0Ven= dors
*already* support multiple prefixes. =C2=A0Corperate IP systems will be
supporting ULA1 + GUA1 (+ GUA2 + GUA3 for multi-homers). =C2=A0ULA1 +
ULA2 + GUA1 (+ GUA2 + GUA3) is not a big streach. =C2=A0Now as for
corporate IP staff you teach them what to do when teaching the how
to run IPv6 networks.

Frankly, I believ= e you are being hopelessly optimistic. What you are able to do and what a r= esource-constrained IT department in a small company will do are so many st= andard deviations apart that you might as well not be on the same planet.
--089e013a114e7bde2904f2cce89f-- From nobody Wed Feb 19 18:36:03 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04951A0638; Wed, 19 Feb 2014 18:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: 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-WfykqtgEZL; Wed, 19 Feb 2014 18:35:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7881A0636; Wed, 19 Feb 2014 18:35:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WGJUN-00026h-Uy; Thu, 20 Feb 2014 02:35:53 +0000 Date: Thu, 20 Feb 2014 10:35:45 +0800 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20140218160639.GC12348@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/7NlMWPUN3SR3durvORINkhWW_fA Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Feb 2014 02:36:00 -0000 > What I would instead suggest is finding a mechanism by which the > unique router-ID can be mapped easily to such addresses. I don't > believe that BGP is the right place to do this. we need a name to address mapping mechanism. let's all think about that. randy From nobody Wed Feb 19 18:36:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399F51A063A for ; Wed, 19 Feb 2014 18:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 23xiGy8L-g0d for ; Wed, 19 Feb 2014 18:36:09 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BA2571A0646 for ; Wed, 19 Feb 2014 18:36:08 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 2F1602383BF; Thu, 20 Feb 2014 02:35:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 17C06160056; Thu, 20 Feb 2014 02:36:43 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A0CDE16004F; Thu, 20 Feb 2014 02:36:41 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9221BFD18EC; Thu, 20 Feb 2014 13:35:50 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> In-reply-to: Your message of "Thu, 20 Feb 2014 11:00:17 +0900." Date: Thu, 20 Feb 2014 13:35:50 +1100 Message-Id: <20140220023550.9221BFD18EC@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9SgLXEcQVaF2rTZ5UWp_BfTV6WA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:36:11 -0000 In message , Lorenzo Colitti writes: > On Thu, Feb 20, 2014 at 10:52 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > > > 2. A piece of remarkably bad luck, rather less likely than > > >> winning any lottery I'm aware of. > > > > Can you elaborate on exactly how bad this luck is as a function of how many > ULA prefixes you use your organization? >From RFC4193 (1 in x added by myself). Connections Probability of Collision 2 1.81*10^-12 (1 in 552486187845) 10 4.54*10^-11 (1 in 22026431718) 100 4.54*10^-09 (1 in 220264317) 1000 4.54*10^-07 (1 in 2202643) 10000 4.54*10^-05 (1 in 22026) > For example - if two large organizations that each use 200 ULA /48s (one > per site) merge, what is the chance that one of them will collide? > > I don't feel it's satisfactory to say "the probability of a collision is > low" without saying how low it actually is. In fact, I think the draft > should not be published without giving a few examples of these numbers. If > *nobody* among the authors or on this list knows what the numbers actually > are, then we should not advocate using ULAs. It is not good engineering > practice to recommend something that you do not understand. > > > You assume that people will actually follow the rules instead of saying > > > "let's just do this like IPv4, and use NAT at the border". > > > > If CERs do the right thing the ULA prefix will be generated > > correctly. But you're right, there will be a generation of > > old-time IPv4 operators who will do exactly that whatever we > > put in RFCs. > > I'm not talking about home networks here, I'm talking about corporate IT > environments. Which should have trained staff who should know better. If you have 200 odd sites pick the top 32 bits of the 40 bits randomly and allocate the bottom 8 bits sequentually. That doesn't change the probability of collision when connecting to other sites though the amount of work if there is a collision is likely to be more. It avoids the top 32 bits being zeros and helps with human factors like wanting address space to be clumped. fde9:4d65:f9XX:: is just as easy to work with as fd00:0:XX:: especially when you are likely to have +200 GUA prefixes as well to deal with which won't be sequentually assigned. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Feb 19 23:40:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EBB1A036E for ; Wed, 19 Feb 2014 23:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 CTsNGO82uIqS for ; Wed, 19 Feb 2014 23:40:16 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 994BD1A0355 for ; Wed, 19 Feb 2014 23:40:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 71BED87007A; Thu, 20 Feb 2014 08:40:11 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sucapNgJI8gB; Thu, 20 Feb 2014 08:40:11 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3CE8D87006D; Thu, 20 Feb 2014 08:40:11 +0100 (CET) Message-ID: <5305B159.2050402@globis.net> Date: Thu, 20 Feb 2014 08:40:09 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Lorenzo Colitti References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Py-VL_1jgJWgWGg0UtmQoOETv5c Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 07:40:17 -0000 Lorenzo Colitti wrote: > On Thu, Feb 20, 2014 at 10:52 AM, Brian E Carpenter > > wrote: > > > 2. A piece of remarkably bad luck, rather less likely than > >> winning any lottery I'm aware of. > > > Can you elaborate on exactly how bad this luck is as a function of how > many ULA prefixes you use your organization? > > For example - if two large organizations that each use 200 ULA /48s > (one per site) merge, what is the chance that one of them will collide? > > I don't feel it's satisfactory to say "the probability of a collision > is low" without saying how low it actually is. In fact, I think the > draft should not be published without giving a few examples of these > numbers. If *nobody* among the authors or on this list knows what the > numbers actually are, then we should not advocate using ULAs. It is > not good engineering practice to recommend something that you do not > understand. > > > You assume that people will actually follow the rules instead of > saying > > "let's just do this like IPv4, and use NAT at the border". > > If CERs do the right thing the ULA prefix will be generated > correctly. But you're right, there will be a generation of > old-time IPv4 operators who will do exactly that whatever we > put in RFCs. > > > I'm not talking about home networks here, I'm talking about corporate > IT environments. Having being involved in a number of mergers, de-mergers, and acquisitions, I suspect that a ULA clash will be the least of your worries. [Although I have to admit I've never actually merged or de-merged multiple IPv6 ULA's] IMHO I think the real worry would be any remaining hard coded addresses and ranges [in firewalls, load balancers, name servers, hot standby systems, WAN optimizers, Active Directory servers (which LANs does each DC serve), licence servers .... ] Is there any serious effort underway to solve how exactly you specify network security zones and firewall rules for ULA based systems, and for systems running multiple IPv6 prefixes? Does a ULA prefix need to map 1:1 to a network security zone? Do you also have to map the ULA space onto your GUA space(s) to ensure the classification and filtering rules for different prefixes remain in synch? When de-merging a single ULA into 2 enterprises, how do you draw a line in the sand to separate A from B? Does the "corporate firewall" function have to become distributed so that the filtering really does sit at the network security zone borders (rather than relying on anti-spoof filters, and a single centralised pair of firewalls) At this point, I'd much rather merge or de-merge two sets of GUA space, and have predictable behaviour during any transition. -- Regards, RayH From nobody Thu Feb 20 01:09:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3911A004B for ; Thu, 20 Feb 2014 01:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.049 X-Spam-Level: X-Spam-Status: No, score=-115.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lXhjXoAWX_v for ; Thu, 20 Feb 2014 01:09:15 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 30AB91A003D for ; Thu, 20 Feb 2014 01:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8391; q=dns/txt; s=iport; t=1392887352; x=1394096952; h=from:to:subject:date:message-id:references:mime-version; bh=gRTf7A7FKjlMWOvOK0+BZ5PkUXZj2afdN9reADHsG+U=; b=YruMw16LzhdT9GfVVCmqDqEcPdmAKyWrePXHYhHOrAcgFPSpujjI6pJh ZKjM7zneQk7J9mhi/pwrfX6Re87P0wNdNx9+A9gTzAbDZN78kTJXKU12l oZBn1eYXFNqxoyu94zfJxL3JeD7rISsNokP1Mh7KBXlu4HnTDKoUzLSrG 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIjFBVOtJXG9/2dsb2JhbABZgwY4V8AHgRUWdIIlAQEBAwEBAQFrEAsCARkDAQIWGScLGwIIAgQTDodvCA3OXRMEjhY9HgSDGoEUBJBBgTOGPJIkgy2CKg X-IronPort-AV: E=Sophos;i="4.97,511,1389744000"; d="asc'?scan'208";a="305320100" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 20 Feb 2014 09:09:11 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1K99Aan027514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Feb 2014 09:09:11 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 03:09:10 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Comments on draft-yourtchenko-colitti-nd-reduce-multicast Thread-Index: AQHPLg20ZXCyXVmrq0KARoHZZy3//w== Date: Thu, 20 Feb 2014 09:09:09 +0000 Message-ID: <48BEF39A-12C8-405E-83F8-CC14E313090B@cisco.com> References: <5305AF13.5060201@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.218] Content-Type: multipart/signed; boundary="Apple-Mail=_FE48A50C-462B-40B9-A8F2-489A87D5DA05"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GWRTwc_ws4A4szqY5UHdE0FB9Rc Subject: [v6ops] Fwd: Comments on draft-yourtchenko-colitti-nd-reduce-multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 09:09:18 -0000 --Apple-Mail=_FE48A50C-462B-40B9-A8F2-489A87D5DA05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Erik's note is sent to 6man. The general topic of ND multicast reduction = will also be discussed from an operational perspective, and the authors = have asked to briefly present this as background for it. Hence, I'm = forwarding Erik's excellent review. That particular conversation will = likely continue on 6man and not be cross-posted, for those interested. Begin forwarded message: > From: Erik Nordmark > Subject: Comments on draft-yourtchenko-colitti-nd-reduce-multicast > Date: February 20, 2014 8:30:27 PM GMT+13:00 > To: IETF IPv6 , Lorenzo Colitti , = "Andrew Yourtchenko (ayourtch)" >=20 >=20 > Thanks for putting this draft together. Some questions and comments = below. >=20 > In section 3 you have: > * One solicited RA per host joining the network (if solicited RAs are = sent using multicast) > That isn't entirely true. Because of the rate limiting of multicast = RAs if a lot of hosts join at the same time, then there will be less. >=20 > In section 4.2 we can suggest an implementation that does unicast: > If we believe that the flash crowd case is still important (when we = wrote ND the concern was around a building power failure and recovery - = today it might be a stadium setting), then one could implement a mix as = follows: > - When RS received start timer. > - If N additional RSs arrives before timer fires, then multicast one = RA. Otherwise when timer fires unicast RAs to the received RSs. > For N=3D1 this is trivial. >=20 > In section 4.3 there are two suggestions: MLD snooping and L2 unicast = or L3 multicast packets. I think there are some operational concerns = around MLD snooping - I hope others can fill in some information in that = space since I don't know the issues. > (Editorially it would be clearer if those two are separate = sub-sections.) >=20 > The multicast-over-unicast refers to SAVI as a way to collect the = state, but it doesn't specify where you see that state used. Presumably = for DAD (and NS in general unless you also do section 4.7)? But SAVI = doesn't claim to have all addresses since it is concerned with = conflicts. Thus a host can exist and be silent - but DAD would still = expect to reach it. Or a host could have moved to a different port and = SAVI having stale state - yet DAD should work. My point is that the = details of how the state is 1) maintained and 2) used to forward packets = are key to analyzing how the neighbor discovery functionality and = robustness would be affected by this idea. >=20 > I section 4.4 the document refers to proxy but without specifying = which of the different proxy approaches you have in mind. > There is the proxy ND RFC, and there is the DAD proxy internet-draft = in 6man. Are you referring to one of those, or some slightly different = form of proxy? (For example, ND proxy would respond with the LLA of the = router/AP, but that might result in host movement looking like a = duplicate address - again depends on the details.) >=20 > I don't have any issue with removing the somewhat arbitrary 9000 = second max AdvDefaultLifetime in section 5.1. However, the tradeoff for = what default lifetime to use in section 4.5 needs to take into account = one additional factor. > The default lifetime serves to garbage collect entries from the = default router list should a router silently disappear. Thus for links = that do not have a fixed (set of) link-local address(es) for the = router(s), having a high default lifetime means that after a failure the = hosts would have one entry in the default router list which us = unreachable - until that high lifetime expires. I don't know if there = has been a study on the performance impact of that would have on the = hosts e.g., how often they would re-probe the default router. >=20 > Section 4.6 has the same concern. But 4.5 and 4.6 makes lots of sense = e.g., in a VRRP deployment where the link-local address of the virtual = default router would always be the same. Ditto for networks with a = single point of failure single router at a fixed address (e.g., if the = router is always at fe80::1 or some other fixed address.) Thus I think = we should recommend 4.5 and 4.6 that within that applicability. Added = benefit is that the routers control it, hence the operator of the = network can set the values higher for VRRP or single router cases. >=20 > Section 4.7 talks about limiting the table space on the hosts. But = clearing the on-link bit in the advertised prefixes also has the benefit = of removing any multicast NS sent from hosts for non-link-local = destinations. And per RFC 4861 the table will be filled in by the router = sending redirects. Thus the router can be used to control which = addresses get in the tables on the hosts by choose whether and when to = send the redirects (redirects with target=3D=3Ddestination). >=20 > In think it would be good to separate out the second half of section = 4.7 (blocking link-locals) into a separate section, since it is quite = different than clearing the on-link bit. That idea has significant = implications since it changes the IP subnet model (RFC 4903 talks about = this.) I not saying that we shouldn't consider this, but I do think it = would fall in a very different category than the other ideas in this = draft. Might even be best to have a separate draft on this radical idea = so it can be explored fully. >=20 > 4.8 seems to conflate the address assignment with DAD. Just because we = might want to centralize the DAD checks doesn't imply that we want to = remove the ability for the host to pick its own privacy enhanced = interface-IDs to form its addresses. > =46rom a deployment perspective DHCPv6 is available for address = assignment, but don't think we want to require that for WiFi or other = links which have packet loss. (Packet loss occurs on wired networks as = well, but the drop distribution is different - might happen during = spanning tree reconvergence etc.) > Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the = addresses received from the DHCP server - needed since the server could = be confused. >=20 > In don't understand 4.9. Should I read it as a host shutting things = down if it goes to sleep even for a short time, and then waking up and = multicasting a few RSs to get RAs, then multicasting a DAD probe for = each assigned IPv6 address? If all the hosts did that then I think there = would be more multicasts. > Note that even if the host doesn't revert to multicasting RSs, it = still needs to be concerned about a duplicate address having arrived on = the link while it was asleep (and not responding to any DAD probes.) >=20 > The suggestion in section 5.2 is needs a lot more work. I tried to = work out some of these issues in section 8.9 in = draft-chakrabarti-nordmark-6man-efficient-nd-05. > But even if we figure out how to do that without causing lots of = unneeded RS load on the routers, in the case of your draft wouldn't the = router(s) still need to multicast RAs at the same frequency? The = router(s) have no way to know whether all the hosts on the link initiate = RS to refresh RA information. >=20 > Regards, > Erik >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- =95 Make things as simple as possible, but not simpler. Albert Einstein --Apple-Mail=_FE48A50C-462B-40B9-A8F2-489A87D5DA05 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 iD8DBQFTBcY0bjEdbHIsm0MRAmmaAJ4hsYG+9VuuXAhesPDsv2SG4tz2VwCeJRt6 hc9FYHg2eEcJfsG9nHOXmfQ= =GOJM -----END PGP SIGNATURE----- --Apple-Mail=_FE48A50C-462B-40B9-A8F2-489A87D5DA05-- From nobody Thu Feb 20 05:15:51 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7981A0141 for ; Thu, 20 Feb 2014 05:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQxTy-R8IFV2 for ; Thu, 20 Feb 2014 05:15:48 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C14F41A0056 for ; Thu, 20 Feb 2014 05:15:47 -0800 (PST) X-Envelope-To: Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.14.8/8.14.5) with ESMTP id s1KDFeJA043173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 20 Feb 2014 13:15:41 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <5305FFFD.5090708@foobar.org> Date: Thu, 20 Feb 2014 13:15:41 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sdepinoGENBMgYeX8nZRMLyaGoY Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:15:50 -0000 On 20/02/2014 01:17, Lorenzo Colitti wrote: > You assume that people will actually follow the rules instead of saying > "let's just do this like IPv4, and use NAT at the border". people will not just do this: they will assign everything from fd00::/48 and will view NAT as a feature. Nick From nobody Thu Feb 20 05:33:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648941A0169 for ; Thu, 20 Feb 2014 05:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CONSOL_YOUR=1.995, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmE4Sd2l1x4Z for ; Thu, 20 Feb 2014 05:33:41 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 542711A0163 for ; Thu, 20 Feb 2014 05:33:41 -0800 (PST) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Feb 2014 07:33:37 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ig0-f169.google.com [209.85.213.169] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ig0-f169.google.com with SMTP id h18so292587igc.0 for ; Thu, 20 Feb 2014 05:33:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0Uro/CpD+p/KGtoKjTUNjLlaRA+mNV8WYvQ64hkYOrU=; b=hUaE8R0Ny7Goir2In6MQ6dGbUaN4PCq641kz/oLnHOtqpxPgUd0SBWBZ4tKQASZ58K SY7kl2gKmfHFmDaKG9AYT7FFbYUljC0vyKv/yvt6uPC+lIE2njG9YJtzhEd54Qh7wjLZ ohYdL8PxvOaSVlMMES0yUx9x1CO8QZ5foLq48jVbxqSoq4XmPLj4nkEls4uTaTzMzNll 4kLclicGn8v4A9KcDm74edTc0LUjoBBJN65oSbvK9kGC3M+qifYia7ckrpOLi5x6j3uz A5W5zwwuUNZ2AusHNmbmkfglXhzwQyOI0KGzAwFqg/6ehnmBdLWOSaNUfaCv/sX+vu1d Qlvw== X-Gm-Message-State: ALoCoQlQOFd2U26v52iB/zTs2HIHhHKlD38PUrqaC3s+8Awam12loXC3EyRsObXeRK2Hca7XLBOHHvLUuY5Dn2q5h/N3+hxz+pIS7PEVeewbp40X7Wc5XW/0nfR2RAutmXko5SV9vI8W X-Received: by 10.50.138.72 with SMTP id qo8mr2198994igb.11.1392903212848; Thu, 20 Feb 2014 05:33:32 -0800 (PST) X-Received: by 10.50.138.72 with SMTP id qo8mr2198981igb.11.1392903212690; Thu, 20 Feb 2014 05:33:32 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPSA id f9sm10554661igz.3.2014.02.20.05.33.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 05:33:31 -0800 (PST) Message-ID: <5306042A.7070002@umn.edu> Date: Thu, 20 Feb 2014 07:33:30 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Lorenzo Colitti , Mark Andrews References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <20140220013516.DE278FD134B@rock.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/0Xz-za4bItmhPWLxc72N1ck_ry0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:33:46 -0000 On 2/19/14, 19:46 , Lorenzo Colitti wrote: > On Thu, Feb 20, 2014 at 10:35 AM, Mark Andrews > wrote: > > > How are they punished? And what will they do when they are > punished? I > > guarantee that renumbering will not be the solution, NAT will be the > > solution. > > Both sites just generate a NEW ULA prefixes. They can continue to > use the collision prefix until the heat death of the universe if > they wish to or they can migrate to the new prefix. IPv6 is NOT > IPv4. Running parallel prefixes is *standard* proceedure. They > just need to talk to each other using the NEW prefixes which should > be no more complicated than pushing new address selection tables. > > > No, sorry. One of the main reasons people are advocating ULAs here is > "because we'll have stable space and will never have to renumber!!11". > Once you buy into that mantra, you'll be hardcoding IP addresses into > configuration again, exactly like we do in IPv4 today. And exactly like > in IPv4 today, renumbering will be prohibitively expensive. I wouldn't say networks using ULAs will never need to be renumbered. But, they provide address stability independent of provider based GUA. You could get unlucky, you can screw up, but even if you don't, you will probably want to eventually consolidate your ULA prefixes just for simplicity of managing your networks. If you acquire enough other companies there will eventually be a big enough win to justify the work of consolidating your ULA prefixes. > As for multiple ULA prefixes... again, I think you're ignoring the > realities of corporate IT staffing, corporate IT systems, and vendor > capabilities. > > I think it's obvious that the path of least resistance (and thus, the > solution that most admins would choose) will be NAT/NPT. After all, if > you want to use ULAs to talk to the outside world (And why wouldn't you, > right? It's what we do in IPv4, right?), you have to do NAT or NPT anyway. The evolution to mobile devices and their transitory nature are chaining the dynamics of most client network. Fewer and fewer devices have even a semi-permanent relationships with an individual IP address. Mobility and the consumerization of IT is driving more and more dynamic configuration of devices loosening the bonds between most devices and their IP addresses. Further, the evolution toward cloud computing, elastic services models, and deployment orchestration are causing similar changes in server networks and data centers. Old school corporate IT models are by no means dead. But things are changing, you can't swing a dead cat without hitting a CIO who is talking about BYOD or Cloud Computing. Renumber is never going to happen without some pain, but between these fundamental changes in the way we use networks and the capabilities of IPv6, renumbering is much more doable. -- ================================================ 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 Thu Feb 20 05:45:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E271A0175 for ; Thu, 20 Feb 2014 05:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvX3fNrhBl-V for ; Thu, 20 Feb 2014 05:45:14 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6321A016D for ; Thu, 20 Feb 2014 05:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392903911; x=1394113511; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=S2FTPsl0e0eMxwmJyyXzalYq3NjRfi2mPDraPu+33PQO9AOv0EZML+NZ eBYSeCa9psj0kWuRBljElyQkLVmU00jiYwamyc+A6Ks+v2r/JiAVH8/4M uf5y9U+MsyCvrLuxGOIgVz51KqCL84EruHzXRonMMieaUuSsBpTRlMb9u o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4LADsGBlOrRDoH/2dsb2JhbABZgwY4qyQBlTMDBAKBDBZ0gyU8NIhlDs4+F45kHYQiBIlIkBqQcoNO X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="103347334" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 20 Feb 2014 13:45:10 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1KDj9u0004472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Feb 2014 13:45:10 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s1KDj9BW003858; Thu, 20 Feb 2014 05:45:09 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s1KDj8pr003838; Thu, 20 Feb 2014 05:45:08 -0800 (PST) Date: Thu, 20 Feb 2014 05:45:08 -0800 (PST) From: Fred Baker Message-Id: <201402201345.s1KDj8pr003838@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/XRIYY2qiG3aNaWo8Vfm4wgSVRgE Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:45:16 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Thu Feb 20 05:45:23 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080411A0165 for ; Thu, 20 Feb 2014 05:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b4FJH-73WWg for ; Thu, 20 Feb 2014 05:45:20 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C63EE1A0171 for ; Thu, 20 Feb 2014 05:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392903916; x=1394113516; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=N2lzcT3Ly2Pd1FqLukoTgRlC0Jl6sBtt7Mt28h93CZkeEBBzidZCpQiF Rl8VEwr3lMaXiDJ3uVhd/ZjDDsNIqNMFjXTZugyerq0LUSCShQsw3nMyq GezlQuNju+R2zPK+8MiLaiwUqtA8RSr5zLcC6SAyI+bj2F4HmXFnoPsCS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4LAHIGBlOrRDoG/2dsb2JhbABZgwY4qyQBlTMDBAKBDBZ0gyU8LQeIZQ7OPheOZB2EIgSJSJAakHKDTg X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="104049788" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Feb 2014 13:45:16 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1KDjGlB004983; Thu, 20 Feb 2014 13:45:16 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1KDjFg09702; Thu, 20 Feb 2014 05:45:15 -0800 (PST) Date: Thu, 20 Feb 2014 05:45:15 -0800 (PST) From: Message-Id: <201402201345.s1KDjFg09702@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-Vd1ZMkKm_K9Veay0rMOkBDr9cI Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:45:22 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Thu Feb 20 05:45:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8063A1A0173 for ; Thu, 20 Feb 2014 05:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn7GKDTle-Ev for ; Thu, 20 Feb 2014 05:45:42 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id DDC121A0187 for ; Thu, 20 Feb 2014 05:45:38 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 20 Feb 2014 07:45:35 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f182.google.com [209.85.214.182] #+LO+TS+TR X-Umn-Classification: local Received: by mail-ob0-f182.google.com with SMTP id wm4so2068371obc.27 for ; Thu, 20 Feb 2014 05:45:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XU0kb2Ht//bn/41QniagTqWDBFCp0DU3rdxxNNVMrro=; b=Zg80nUHh/pVNrV55QEvLcTxSrAnyRoArPiCA/5ptN5QWkoTS5+R3X+qu3PtjLlhRAz 9cTRUNp/ZiCaN6GrNChT7beCHbFNBSdsBTVqx9KEO/kO/nnCNERtYpALSujWGW5XKcTk aYjnruUoGfCy0qtR8oNVCKi7c1H5BA/IKAor36G5p2J6rtg/5HQxGjAiWaoJzW5NuT9G 9q/mpAzHU6yn3jDKB+wOlUh+LyQL1RwA3cN0t4AnfjSYStP8i60PI7AWXLSt/X9HM8rR QOtFMNYWEI+9FYoEt/rbNLnqaOHF1M+ItgPKmrxy156dkjxm22UQwU/VaN9PQCYxZkI2 Y7UA== X-Gm-Message-State: ALoCoQm+32s9AOsjSbcHlbOIzxi0An/JWRV7xO5yKcpEZ8/RXyMaJ9eYLhXDJJT7TY9JMYX2HoAhtso3S2wlJprh+ENsdv4JF+Rd2EYGTszpj/d1SU+4ifiPBOFd3jS7y2eXhFTZMAov X-Received: by 10.182.128.138 with SMTP id no10mr1569931obb.32.1392903934197; Thu, 20 Feb 2014 05:45:34 -0800 (PST) X-Received: by 10.182.128.138 with SMTP id no10mr1569914obb.32.1392903934013; Thu, 20 Feb 2014 05:45:34 -0800 (PST) Received: from oit201651646.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPSA id kn10sm23514555oeb.0.2014.02.20.05.45.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 05:45:33 -0800 (PST) Message-ID: <530606FB.9020707@umn.edu> Date: Thu, 20 Feb 2014 07:45:31 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nick Hilliard , v6ops@ietf.org References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> In-Reply-To: <5305FFFD.5090708@foobar.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LG34prqRoPMeg0bhNHAvKXXSDBk Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:45:43 -0000 On 2/20/14, 07:15 , Nick Hilliard wrote: > On 20/02/2014 01:17, Lorenzo Colitti wrote: >> You assume that people will actually follow the rules instead of saying >> "let's just do this like IPv4, and use NAT at the border". > > people will not just do this: they will assign everything from fd00::/48 > and will view NAT as a feature. Do we think not talking about ULA will stop people from doing NAT with ULA? Get over it. This draft is necessary, we need to tell people how to properly use ULA. It is not telling them to do NAT. I think it should more strongly tell them to NOT do NAT. However, they are going to do what they are going to do. But, if we don't tell them what the proper use cases for ULA are, then our silence is consent for them to go ahead and do NAT with ULA. -- ================================================ 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 Thu Feb 20 06:58:43 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC97A1A01D7 for ; Thu, 20 Feb 2014 06:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 pD5J07GFjUEl for ; Thu, 20 Feb 2014 06:58:39 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 01BDA1A01D1 for ; Thu, 20 Feb 2014 06:58:38 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rp18so1310498iec.22 for ; Thu, 20 Feb 2014 06:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/ocejsE6cTeBB4sEaQUBNwtgUODf/DoP9pcyirSK3qI=; b=ntf+yMyF6NvOrMW4418RegDHohY02r3TbGghCy+7sixkTc6j582FdIvONibwPD8X7e VgqtR6G+jbKMqU+I2Lktvy/YY9+OCT9cDxdu2vbM5tFNwKgCCMuAJ9cFVGdq9LfhXFNB t+jYYtE5Ps0QtCC84NdmLLc1oX5Pqe/6nAudQh+ouKs1T5cy9R1KJrcPqePXBoDrxPwA 3RXGadUywWDga4I2xqAfCeBzIa2EdKSC30xckapTe7UlUmzOw6vY1PXOawo2jm+5nRLV OKlFxMDOCZ1Bg1oWpi7ADUOXa1D5rjHlG8fz0o+MABpRJCzuc7GvRil1YOLabO6pAsRC BNTQ== 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=/ocejsE6cTeBB4sEaQUBNwtgUODf/DoP9pcyirSK3qI=; b=RcEwRPGtkMK8HFuf0eq70EFmksG9NpLmLBsd7a9vpO+o14qYyg5FTFERJB4+w8apt4 dqtagDuBLK6Nyeoq4BzVui/FWwBaLH9Kl+UKI0r0p07FrZN81Uw1QnX2qBa8TzPxBOEj IPNpVRI2R0yma+uwR4/XBYBuvARPawA8vjvfwGFs8BeRoLjvJ4LkKyJy12NMiDvP9xo6 D0h6oJiTY8Zbe/AHs0B9RuKJLPAYAp5fOnDhL2M3cmyV3o8yWQlOiTVUU9tI8u9DePqZ W78ypt0ObohOCC+kHDl0PkJc/boVoOC0VvF08M+bqozWKIEZ0Lb0egWxtT9jxohWPY0l UWPQ== X-Gm-Message-State: ALoCoQl/F0OY8WjTDoagI7X76vi+r2PFkHVyw5rXD+1dV7zYP18iScjSbIIqdy4IGmhxmiiNrb9+dTBIJmzc/WsFupsyASD8QrLAFCFMyKZoglEC0OM7Ge9I7AmZ9YdMHFLGODTRqgHna6uRCQFtWeaIHrLrFdTYDenarqu1zJ1eLIjBDmeD1Xtu8+2cIvDQhiF3s+arfJ1H X-Received: by 10.43.153.68 with SMTP id kz4mr1671210icc.29.1392908315250; Thu, 20 Feb 2014 06:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Thu, 20 Feb 2014 06:58:14 -0800 (PST) In-Reply-To: <530606FB.9020707@umn.edu> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> From: Lorenzo Colitti Date: Thu, 20 Feb 2014 23:58:14 +0900 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a11c2ecd855ef6c04f2d7bdc1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/uw7AzQ6QJWIXcd9HVQDFtFcyPVw Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:58:41 -0000 --001a11c2ecd855ef6c04f2d7bdc1 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 10:45 PM, David Farmer wrote: > Get over it. This draft is necessary, we need to tell people how to > properly use ULA. It is not telling them to do NAT. I think it should > more strongly tell them to NOT do NAT. However, they are going to do what > they are going to do. But, if we don't tell them what the proper use cases > for ULA are, then our silence is consent for them to go ahead and do NAT > with ULA. > We don't know what the use cases for ULAs are, because nobody has actually used them in real deployments. The people who are deploying IPv6 are saying "ugh, ULA sucks, let's do global instead" and the ones who aren't deploying IPv6 are using IPv4. I will be the first to support a draft that documents *real* experience of ULA in a *real* deployment. But documenting use cases without having actually used them for real... sorry, that's hubris. --001a11c2ecd855ef6c04f2d7bdc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 20, 2014 at 10:45 PM, David Farmer <farmer@umn.edu> wro= te:
Get over it. =C2=A0This draft is necessary, we need to tell= people how to properly use ULA. =C2=A0It is not telling them to do NAT. = =C2=A0I think it should more strongly tell them to NOT do NAT. =C2=A0Howeve= r, they are going to do what they are going to do. =C2=A0But, if we don'= ;t tell them what the proper use cases for ULA are, then our silence is con= sent for them to go ahead and do NAT with ULA.

We don't know what the use cases for U= LAs are, because nobody has actually used them in real deployments. The peo= ple who are deploying IPv6 are saying "ugh, ULA sucks, let's do gl= obal instead" and the ones who aren't deploying IPv6 are using IPv= 4.

I will be the first to support a draft that documents *= real* experience of ULA in a *real* deployment. But documenting use cases w= ithout having actually used them for real... sorry, that's hubris.
--001a11c2ecd855ef6c04f2d7bdc1-- From nobody Thu Feb 20 07:41:44 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE961A01C8 for ; Thu, 20 Feb 2014 07:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.049 X-Spam-Level: X-Spam-Status: No, score=-17.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 ai19HD1xuCIA for ; Thu, 20 Feb 2014 07:41:40 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C70E61A0170 for ; Thu, 20 Feb 2014 07:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2256; q=dns/txt; s=iport; t=1392910897; x=1394120497; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DBuohPPhKVsGd+BUYR+ARHqqxYPwQ77IHuwLgtBA4Yo=; b=CLvjbUPDJexaqkejDIlIEwJgcXgNuI2QL3cQjaJ7DyHrvBauIqOVf7Xh MyJAgMduKKS+pJ70iamQyoSNn1pvrnLlg+OHeqwG/iTALOIiEI7IQRUeb UkbpWWW0Sn75IeQ2VKX1pAEO40CGjb0zRFQ796jD02+fVJXYVWPzGfYB1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPQgBlOtJXG+/2dsb2JhbABZgwY4V8AMgRAWdIIlAQEBBAEBAWsLEAIBCBguJwslAgQBDQWIBQ3OKBMEjgxYB4Q4BIkQjyCSJIMtgWgjHw X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="305397458" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 20 Feb 2014 15:41:37 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1KFfb7k020273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 15:41:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 09:41:36 -0600 From: "Eric Vyncke (evyncke)" To: Jan-Frode Myklebust , Brian E Carpenter Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt Thread-Index: AQHPKWgFc33rJRWVT02NFletWRLbG5q06NoAgAD96gCAAR81gIABVkQAgAA9hYCAAAN0gIAAC5wAgAEH0ICABRZeAA== Date: Thu, 20 Feb 2014 15:41:35 +0000 Message-ID: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> In-Reply-To: <20140217110013.GA31822@mushkin> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.55.185.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <425CD688BC1C424FAA8788696B0839E6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/_aB7rAPzhJjrp-iYj1ZQW3gK2CY Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 15:41:43 -0000 To come back to the draft itself... Section 2.2 'globally unique', should stress that the randomization process MUST be followed to the letter. Also, as discussed in the list, the 40 bits of entropy are for a single /48, if hundreds of /48 need to be generated, this will reduce the entropy to 30 bits or so... (which is still 8 billions though). Section 4.2 'limited scope', as a security person, I would really love to read it clearly articulated that ULA does not provide isolation per se... Bi-directional ACL are required + route map to avoid polluting your BGP neighbors. Jan-Frode, I am sure that you know that strict policy routing (without anti-spoofing or ACL) will not prevent packets from you DC to leak to the Internet (to the NSA or any other 'interested' party ;-)) -=E9ric On 17/02/14 12:00, "Jan-Frode Myklebust" wrote: >On Mon, Feb 17, 2014 at 08:16:00AM +1300, Brian E Carpenter wrote: >> >>> Le 15/02/2014 19:16, Owen DeLong a =E9crit : >> >>>> Indeed, the situations where ULA usage is detrimental vastly >> >>>> outnumbers those where it is actually beneficial. >>=20 >> That's an opinion, but it isn't an argument for abolishing >> ULAs. It's actually an argument for improving this draft so >> that it describes the cases in which ULAs are beneficial. > >> Could we have a detailed conversation about whether those cases >> are correctly described in the draft? > >Yes please. > >My use case is that we have a set of datacenter internal services/servers >that should *never* be routed out. When not using ULA we've had a couple >of incidents where the routes did leak out and servers that shouldn't >have been available on the Internet was. So we've decided to use ULA for >the same set of servers as we previously used rfc1918-adresses for. No >NAT involved. No servers should reach Internet directly. Yes we could >achieve the same by putting proper ACLs in place on the borders, but since >we've failed to do that in the past, the belt and suspenders approach is >attractive. > >Is this a "valid" ULA usage? > > > -jf > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Feb 20 12:03:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7441A027F for ; Thu, 20 Feb 2014 12:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_aG3KfKIc_L for ; Thu, 20 Feb 2014 12:03:04 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC951A026E for ; Thu, 20 Feb 2014 12:03:04 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kp14so2355973pab.34 for ; Thu, 20 Feb 2014 12:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RtlaAgqJtUYowSrwx1SZd5vSCHwyLHLYb+nI4nkZqYw=; b=rLYRmGvq3WklRqTJSN5vorOU+NWRcJSmh2ZcjVgQK3Xdx/qdM6LPlpQ96M0kJV0JmV AkCDuqBPBHdScSvQ+R9ngIs9XSqkdkdtmV57G8usTjAP9kBDNV30KN0gp4Baa/Ro5i44 8aEpFwQySiVnX/OK1XY86JN1GfcnqkdIAWvI5Mgg3GxaBUzP9J3aNzpEvoEvbJ7LkDm6 uqoyK+78vs8yQlpwS9oaH7wetKNaBV7R1NpYlqu9xZX5Vl2zb05I0ERPuenpintkaRF5 sEiMB2AWwjx6b2a/1e28Mc+cHoFiPMf2f3qZlDY3TWo/9XnxfT48hnqwRfxB6+ujWbIv ERTw== X-Received: by 10.66.138.40 with SMTP id qn8mr4303322pab.154.1392926580649; Thu, 20 Feb 2014 12:03:00 -0800 (PST) Received: from [192.168.178.23] (189.201.69.111.dynamic.snap.net.nz. [111.69.201.189]) by mx.google.com with ESMTPSA id pp5sm13948005pbb.33.2014.02.20.12.02.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 12:02:59 -0800 (PST) Message-ID: <53065F7D.1010909@gmail.com> Date: Fri, 21 Feb 2014 09:03:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <5305B159.2050402@globis.net> In-Reply-To: <5305B159.2050402@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/c6Qz4VI9Xint1EXb6YqLQlAAFyU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:03:06 -0000 On 20/02/2014 20:40, Ray Hunter wrote: ... > At this point, I'd much rather merge or de-merge two sets of GUA space, > and have predictable behaviour during any transition. Ray, ULA prefixes *are* global unicast prefixes; their only special characteristic is that they are not routed outside a given administrative domain. Also, it is common for large enterprises to run multiple disjoint prefixes within the corporate network, and has been for many years. I think the issues you're concerned about are all due to the fact that in IPv6, it is bog standard to run more than one prefix on the same phsyical subnet. The fact that one of them might be delegated from a ULA /48 seems to me to be a side issue. Brian From nobody Thu Feb 20 12:20:11 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122F71A028B for ; Thu, 20 Feb 2014 12:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 DtQHJEg2wsGU for ; Thu, 20 Feb 2014 12:20:08 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 49A431A019F for ; Thu, 20 Feb 2014 12:20:08 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 511B39C; Thu, 20 Feb 2014 21:20:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 45F739A; Thu, 20 Feb 2014 21:20:04 +0100 (CET) Date: Thu, 20 Feb 2014 21:20:04 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@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: http://mailarchive.ietf.org/arch/msg/v6ops/ImxT-AKxwq-s9sZuZNw8diHk8wQ Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:20:10 -0000 On Thu, 20 Feb 2014, Lorenzo Colitti wrote: > I will be the first to support a draft that documents *real* experience > of ULA in a *real* deployment. But documenting use cases without having > actually used them for real... sorry, that's hubris. At least one of the top10 residential deployments on http://www.worldipv6launch.org/measurements/ uses ULAs and reportedly hasn't seen any customer complaints related to ULAs. This isn't really the corporate use case I believe we're discussing here but... Just to be clear, I am not a ULA fan, but I am all for documenting things. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Feb 20 13:45:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1AC1A02A5 for ; Thu, 20 Feb 2014 13:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm-SA6BgNBxI for ; Thu, 20 Feb 2014 13:45:02 -0800 (PST) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 115101A0150 for ; Thu, 20 Feb 2014 13:45:01 -0800 (PST) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8513160AE9 for ; Thu, 20 Feb 2014 22:44:56 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 4CE0560AE7 for ; Thu, 20 Feb 2014 22:44:56 +0100 (CET) Received: (qmail 47128 invoked by uid 1007); 20 Feb 2014 22:44:56 +0100 Date: Thu, 20 Feb 2014 22:44:56 +0100 From: Gert Doering To: Lorenzo Colitti Message-ID: <20140220214456.GC75390@Space.Net> References: <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hB5c79U-qMBtENpuJpL4pkPyEWI Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:45:05 -0000 Hi, On Thu, Feb 20, 2014 at 11:58:14PM +0900, Lorenzo Colitti wrote: > We don't know what the use cases for ULAs are, because nobody has actually > used them in real deployments. I have. To reach other people's RFC1918 IPv4 networks over VPNs... We assign a /64 out of "our" ULA /48 to each VPN partner, and NAT64 the last 32 bits at our IPSEC gateway into IPv4. So it really doesn't matter what they use inside their network, we can reach the full IPv4 range in there, nicely isolated into a single collision free prefix on our side... Now I agree that using ULAs as life support for IPv4 might not be the *best* use case, but you were asking for "real deployment". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Feb 20 13:54:02 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7981A0330 for ; Thu, 20 Feb 2014 13:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 n-a6YH6HMNP4 for ; Thu, 20 Feb 2014 13:53:59 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF9DC1A0326 for ; Thu, 20 Feb 2014 13:53:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D4F3D87006E; Thu, 20 Feb 2014 22:53:52 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCnllFFBMS1h; Thu, 20 Feb 2014 22:53:52 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id AE0EE87003E; Thu, 20 Feb 2014 22:53:52 +0100 (CET) Message-ID: <5306796F.5030709@globis.net> Date: Thu, 20 Feb 2014 22:53:51 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Brian E Carpenter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <5305B159.2050402@globis.net> <53065F7D.1010909@gmail.com> In-Reply-To: <53065F7D.1010909@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9Xk748UrSreTIAi5t2PZl0atIgM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:54:00 -0000 > Brian E Carpenter > 20 February 2014 21:03 > On 20/02/2014 20:40, Ray Hunter wrote: > ... > > Ray, ULA prefixes *are* global unicast prefixes; their only special > characteristic is that they are not routed outside a given administrative > domain. > > Also, it is common for large enterprises to run multiple disjoint prefixes > within the corporate network, and has been for many years. > So how do they set up firewall rules? > I think the issues you're concerned about are all due to the fact that > in IPv6, it is bog standard to run more than one prefix on the same > phsyical subnet. The fact that one of them might be delegated from > a ULA /48 seems to me to be a side issue. > > Brian So you see no problems with a machine running multiple prefixes, where the IID for each may also be different (stable privacy addresses), and each session may source from a different prefix depending on where it's terminating (address selection + address rotation of privacy addresses)? How will the firewall even know it's the same machine sending the packets, never mind the same user, so that the communication stream can be authorised or blocked? Will users have to re-authenticate for every prefix + IID combination? -- Regards, RayH From nobody Thu Feb 20 16:25:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452B21A0359 for ; Thu, 20 Feb 2014 16:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59PygYbKfVOF for ; Thu, 20 Feb 2014 16:25:05 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC141A034F for ; Thu, 20 Feb 2014 16:25:05 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id v10so2533079pde.14 for ; Thu, 20 Feb 2014 16:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wjsRCQ0+Ph1D+DtyjfK4f3tIUsdTRUKW3Vr5S3eQz/Y=; b=mwv5yl1cYFvZtuOG39WqDUSLxbV0Xi5ECjW9M7gwpbDj6HigDWYSr1Gt6HiKMJfo8G z72yMyzXj/u7KFIY7hgznmwTdLoWQtf+1+//njCHS8Du9fWucrosgqLPsQCCbWWU8bZE KhzNnDZ2pY1gZOR/PmooD5ML+uKQhLJ95ZzePOrSPd7YKM+G0KU617Rtb+2uGF4f3zeG t4p3lawWHL4+ewU/zscOQ76oDHWmiuKJsG33L6Bp1pU/JPI7TYyVpeko27fdrY5euVJ7 hXB/LRQ2IFBocEgsWClKNZjcX2QsDeJXsk2meZDYQoM3BdevWiUcMvEYoonAf6sReiBP WGvQ== X-Received: by 10.68.163.3 with SMTP id ye3mr5566519pbb.78.1392942301758; Thu, 20 Feb 2014 16:25:01 -0800 (PST) Received: from [192.168.178.23] (189.201.69.111.dynamic.snap.net.nz. [111.69.201.189]) by mx.google.com with ESMTPSA id fk4sm36155722pab.23.2014.02.20.16.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 16:25:01 -0800 (PST) Message-ID: <53069CE6.90009@gmail.com> Date: Fri, 21 Feb 2014 13:25:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <5305B159.2050402@globis.net> <53065F7D.1010909@gmail.com> <5306796F.5030709@globis.net> In-Reply-To: <5306796F.5030709@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/nWu71ok_P3LcnqirzO1nDRvGf4Q Cc: "v6ops@ietf.org WG" Subject: [v6ops] multiple prefixes [no longer draft-ietf-v6ops-ula-usage-recommendations-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 00:25:07 -0000 On 21/02/2014 10:53, Ray Hunter wrote: >> Brian E Carpenter >> 20 February 2014 21:03 >> On 20/02/2014 20:40, Ray Hunter wrote: >> ... >> >> Ray, ULA prefixes *are* global unicast prefixes; their only special >> characteristic is that they are not routed outside a given administrative >> domain. >> >> Also, it is common for large enterprises to run multiple disjoint >> prefixes >> within the corporate network, and has been for many years. >> > So how do they set up firewall rules? I'm not sure why you ask, and when I worked for such a company (IBM) it wasn't something I ever looked at. However, I assume that the filters for every border device to the Internet cited all the internal prefixes in use. Certainly the config file for the call-home VPN on my company laptop included a very long list of prefixes, and I guess that was pretty much the same list as they needed in the border firewalls. >> I think the issues you're concerned about are all due to the fact that >> in IPv6, it is bog standard to run more than one prefix on the same >> phsyical subnet. The fact that one of them might be delegated from >> a ULA /48 seems to me to be a side issue. >> >> Brian > > So you see no problems with a machine running multiple prefixes, where > the IID for each may also be different (stable privacy addresses), and > each session may source from a different prefix depending on where it's > terminating (address selection + address rotation of privacy addresses)? That's the design of IPv6. > How will the firewall even know it's the same machine sending the > packets, never mind the same user, so that the communication stream can > be authorised or blocked? You're talking about a firewall that censors outgoing sessions? Well, that's bound to be a pain. But you'll find the MAC address in the ND cache, so you could check that way. > Will users have to re-authenticate for every prefix + IID combination? If it's a firewall that authenticates users, yes, I would think so. But I don't see why that would require user action; it should just be automatic after the user's initial authentication. If not, the authentication mechanism is not well designed for IPv6. Brian From nobody Fri Feb 21 00:24:53 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DAB1A04C5 for ; Fri, 21 Feb 2014 00:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 Y7fgxUwM1dWS for ; Fri, 21 Feb 2014 00:24:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8C21A0009 for ; Fri, 21 Feb 2014 00:24:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBI85979; Fri, 21 Feb 2014 08:24:45 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:24:26 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:24:44 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 16:24:40 +0800 From: "Liubing (Leo)" To: David Farmer , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt Thread-Index: AQHPKWgMo43RzbooVkmZSkAdeWvl75qz/igAgAD96wCAAR80gIABVkQAgAA9hYCAAAN1gIAAC5wAgAEHz4CAADwWAIAAImUAgAAJQ4CAAK9RAIABJvEAgACbWYCAAH+0gIAAhjSAgAA1BACAAMiTgIAACFaAgAG2RyA= Date: Fri, 21 Feb 2014 08:24:39 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D836377@nkgeml506-mbx.china.huawei.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> In-Reply-To: <530606FB.9020707@umn.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PuNINkIcpZrr4tIhWVguxwckFrM Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 08:24:52 -0000 Hi David, Thank you for the comment. Please see replies below. > On 2/20/14, 07:15 , Nick Hilliard wrote: > > On 20/02/2014 01:17, Lorenzo Colitti wrote: > >> You assume that people will actually follow the rules instead of > >> saying "let's just do this like IPv4, and use NAT at the border". > > > > people will not just do this: they will assign everything from > > fd00::/48 and will view NAT as a feature. >=20 > Do we think not talking about ULA will stop people from doing NAT with > ULA? >=20 > Get over it. This draft is necessary, we need to tell people how to prop= erly > use ULA. It is not telling them to do NAT. I think it should more stron= gly > tell them to NOT do NAT. However, they are going to do what they are > going to do. But, if we don't tell them what the proper use cases for UL= A > are, then our silence is consent for them to go ahead and do NAT with ULA= . [Bing] The WG used to discuss ULA+NPTv6 use case a lot. Some people suggest= ed to clearly state in the draft "NOT recommended to do ULA+NAT"; while som= e argued "NOT recommended" was too strong, just provide pros/cons and cauti= ons on it. We agreed with the latter one, since we thought ULA+NPTv6 might = be a valid use case in some situations.=20 However, one of the main goals of this draft is to eliminate the mis-unders= tanding of ULA is supposed to be binding with NAT. This point is clearly de= scribed in Section 4. And the ULA+NPTv6 is not listed in the recommended us= e cases. We thought this is a way to strike the balance. Best regards, Bing > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 > 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=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 21 00:38:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EA31A04ED for ; Fri, 21 Feb 2014 00:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.749 X-Spam-Level: X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 WTI4Zct1mXbK for ; Fri, 21 Feb 2014 00:38:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 770F71A04E9 for ; Fri, 21 Feb 2014 00:38:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDU82179; Fri, 21 Feb 2014 08:38:20 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:38:01 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 08:38:19 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 16:38:15 +0800 From: "Liubing (Leo)" To: "Eric Vyncke (evyncke)" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt Thread-Index: AQHPKWgMo43RzbooVkmZSkAdeWvl75qz/igAgAD96wCAAR80gIABVkQAgAA9hYCAAAN1gIAAC5wAgAEHz4CABQWcgIABnniA Date: Fri, 21 Feb 2014 08:38:14 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D836393@nkgeml506-mbx.china.huawei.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/o-AGqzc7VL6vKoiGR15RWzTPkc0 Cc: V6 Ops List Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 08:38:27 -0000 Hi Eric, Thanks for your comments to draft itself. Please see replies below. > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Eric Vyncke > (evyncke) > Sent: Thursday, February 20, 2014 11:42 PM > To: Jan-Frode Myklebust; Brian E Carpenter > Cc: V6 Ops List > Subject: Re: [v6ops] I-D Action: > draft-ietf-v6ops-ula-usage-recommendations-02.txt >=20 > To come back to the draft itself... >=20 > Section 2.2 'globally unique', should stress that the randomization proce= ss > MUST be followed to the letter. Also, as discussed in the list, the 40 bi= ts of > entropy are for a single /48, if hundreds of /48 need to be generated, th= is > will reduce the entropy to 30 bits or so... (which is still 8 billions th= ough). [Bing] Yes, this is a good argument. Will do in the next version. Thanks. > Section 4.2 'limited scope', as a security person, I would really love to= read it > clearly articulated that ULA does not provide isolation per se... > Bi-directional ACL are required + route map to avoid polluting your BGP > neighbors.=20 [Bing] This could be a good point to add in the security considerations. Th= anks. Best regards, Bing > Jan-Frode, I am sure that you know that strict policy routing > (without anti-spoofing or ACL) will not prevent packets from you DC to le= ak > to the Internet (to the NSA or any other 'interested' party ;-)) > -=E9ric >=20 > On 17/02/14 12:00, "Jan-Frode Myklebust" wrote: >=20 > >On Mon, Feb 17, 2014 at 08:16:00AM +1300, Brian E Carpenter wrote: > >> >>> Le 15/02/2014 19:16, Owen DeLong a =E9crit : > >> >>>> Indeed, the situations where ULA usage is detrimental vastly > >> >>>> outnumbers those where it is actually beneficial. > >> > >> That's an opinion, but it isn't an argument for abolishing ULAs. It's > >> actually an argument for improving this draft so that it describes > >> the cases in which ULAs are beneficial. > > > >> Could we have a detailed conversation about whether those cases are > >> correctly described in the draft? > > > >Yes please. > > > >My use case is that we have a set of datacenter internal > >services/servers that should *never* be routed out. When not using ULA > >we've had a couple of incidents where the routes did leak out and > >servers that shouldn't have been available on the Internet was. So > >we've decided to use ULA for the same set of servers as we previously > >used rfc1918-adresses for. No NAT involved. No servers should reach > >Internet directly. Yes we could achieve the same by putting proper ACLs > >in place on the borders, but since we've failed to do that in the past, > >the belt and suspenders approach is attractive. > > > >Is this a "valid" ULA usage? > > > > > > -jf > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Feb 21 01:19:26 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34801A04FF for ; Fri, 21 Feb 2014 01:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 7Vb09sKrg-WC for ; Fri, 21 Feb 2014 01:19:19 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 046CD1A04F8 for ; Fri, 21 Feb 2014 01:19:17 -0800 (PST) Received: from [50.95.222.92] ([50.95.222.92]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1L9EVDV027694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 01:15:08 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1L9EVDV027694 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392974116; bh=SQhye6k1ha/htX1PoHrEZGOuP0E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sSbkZqVj4MJkktibjhySJ/kxCHEd3oUqKIM0T44iCWN8QG1WHso5HGx5bixzbHwNr u2/7VIy5bs/Y3A40IhpSn/5/MLprXfGi+vuV2MjKI06GZJFHELgWMIEdwD1X2EFGv6 mG9Eg4+NYwS3KJO3UCemRsDz3326wkypSDpQG6qk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <53055FF3.2040605@gmail.com> Date: Fri, 21 Feb 2014 01:14:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <57950400-DF71-4D36-BEEC-C8C2CC7D3D54@delong.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 21 Feb 2014 01:15:16 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rknqity6T4OFfGfiPWT5Rj6RfTM Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 09:19:20 -0000 >> You assume that people will actually follow the rules instead of = saying >> "let's just do this like IPv4, and use NAT at the border". >=20 > If CERs do the right thing the ULA prefix will be generated > correctly. But you're right, there will be a generation of > old-time IPv4 operators who will do exactly that whatever we > put in RFCs. That doesn=92t make giving them an RFC which tacitly allows or = recommends these actions a good thing. Owen From nobody Fri Feb 21 01:19:30 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CB11A0048 for ; Fri, 21 Feb 2014 01:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 vxrxbmgH7SNI for ; Fri, 21 Feb 2014 01:19:20 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4912E1A04FD for ; Fri, 21 Feb 2014 01:19:20 -0800 (PST) Received: from [50.95.222.92] ([50.95.222.92]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1L9EVDW027694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 01:16:17 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1L9EVDW027694 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392974178; bh=ezYjXHbJqnjCSa0E4LqxkHClwr4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ttnz2oC0ae2tMBMx3GjKSRE/w3xoogeDPQF/bb28iA3qVRFkAAaKerVnnkRHskkef mlIjXRdRgpcqsxe/wL/VvlArZEHoltwhoGetghN+dE8JCL+boiiePO8DHheTgJGMns fVMRI77YJLEsHS2wqXYe5+bUCgYVVMQlGIBHlkrY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <20140220015951.2A328FD160B@rock.dv.isc.org> Date: Fri, 21 Feb 2014 01:16:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0B276951-478D-49EA-99D8-30E0E0F63B7E@delong.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <20140220013516.DE278FD134B@rock.dv.isc.org> <20140220015951.2A328FD160B@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 21 Feb 2014 01:16:18 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6exepE-vQRGo9APtKMXJnFUE7ts Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 09:19:26 -0000 >> I think it's obvious that the path of least resistance (and thus, the >> solution that most admins would choose) will be NAT/NPT. After all, = if you >> want to use ULAs to talk to the outside world (And why wouldn't you, = right? >> It's what we do in IPv4, right?), you have to do NAT or NPT anyway. >=20 > It's a matter of education. Adding "How to deal with a ULA prefix > collisions" to this document would be a good first step. No, it=92s a good second or third or =85 step. A good first step is teaching them that the best way to avoid a ULA = collision is to use GUA in most circumstances and only use ULA where GUA = is infeasible. Owen From nobody Fri Feb 21 01:24:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D0B1A01B0 for ; Fri, 21 Feb 2014 01:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 u82IMkSiSxYW for ; Fri, 21 Feb 2014 01:24:08 -0800 (PST) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 72F431A0055 for ; Fri, 21 Feb 2014 01:24:08 -0800 (PST) Received: from [50.95.222.92] ([50.95.222.92]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1L9Klva027930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 01:21:24 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1L9Klva027930 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392974485; bh=4A7JqU08yic7tvLlpgReAHlrikU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cDARobvpH5ZziFMDfT2qRhKt7lJjt2JSZpIGIAQCc0nFj5fYVt/bbpB7sqZei4rsr jkmu9fLddJxFi5PIBhE1peBt9271ThN6JfadsT15u/GNv1qMX6E3wZjmmyoBosb3vF HRJO8wtw9xZKtVotnhgWgFRvy32/2M/br+PS1spU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <20140220023550.9221BFD18EC@rock.dv.isc.org> Date: Fri, 21 Feb 2014 01:20:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <20140220023550.9221BFD18EC@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 21 Feb 2014 01:21:25 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Dyqtl6hhqQopPjpqBvy_IUWqkTU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 09:24:11 -0000 On Feb 19, 2014, at 6:35 PM, Mark Andrews wrote: >=20 > In message = , = Lorenzo Colitti writes: >> On Thu, Feb 20, 2014 at 10:52 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >>=20 >>>> 2. A piece of remarkably bad luck, rather less likely than >>>>> winning any lottery I'm aware of. >>>=20 >>=20 >> Can you elaborate on exactly how bad this luck is as a function of = how many >> ULA prefixes you use your organization? >=20 >> =46rom RFC4193 (1 in x added by myself). >=20 > Connections Probability of Collision >=20 > 2 1.81*10^-12 (1 in 552486187845) > 10 4.54*10^-11 (1 in 22026431718) > 100 4.54*10^-09 (1 in 220264317) > 1000 4.54*10^-07 (1 in 2202643) > 10000 4.54*10^-05 (1 in 22026) >=20 >> For example - if two large organizations that each use 200 ULA /48s = (one >> per site) merge, what is the chance that one of them will collide? >>=20 >> I don't feel it's satisfactory to say "the probability of a collision = is >> low" without saying how low it actually is. In fact, I think the = draft >> should not be published without giving a few examples of these = numbers. If >> *nobody* among the authors or on this list knows what the numbers = actually >> are, then we should not advocate using ULAs. It is not good = engineering >> practice to recommend something that you do not understand. >>=20 >>> You assume that people will actually follow the rules instead of = saying >>>> "let's just do this like IPv4, and use NAT at the border". >>>=20 >>> If CERs do the right thing the ULA prefix will be generated >>> correctly. But you're right, there will be a generation of >>> old-time IPv4 operators who will do exactly that whatever we >>> put in RFCs. >>=20 >> I'm not talking about home networks here, I'm talking about corporate = IT >> environments. >=20 > Which should have trained staff who should know better. In an ideal world, sure=85 In the real world where some of us have to = live=85 I think Lorenzo=92s use of the term hopelessly optimistic is kind. I = would go so far as to say somewhat detached from reality. Owen From nobody Fri Feb 21 01:47:56 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268091A04A5 for ; Fri, 21 Feb 2014 01:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 44l9FmuP9_SE for ; Fri, 21 Feb 2014 01:47:51 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0021A04BD for ; Fri, 21 Feb 2014 01:47:50 -0800 (PST) Received: from [50.95.222.92] ([50.95.222.92]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1L9foR5028457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 01:42:27 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1L9foR5028457 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392975748; bh=A2cuzoBsHO638t960ZPyI9ZkEvI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MlC7ce4BeryZubrfHZCW8OQay1V8EgqbK8YHDVGkkpxh0N6tUT97s5OmL8mQ68QUt MTrQNUeLgMd6i9GKR03ng1PozM/gPpJUfIkR5WOicO9lFRrmY4LGF45URH3yhAuxv2 +ZO1glqwlSiZsNjDp5slpqOZC6thwqgb2gDFRHl8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <530606FB.9020707@umn.edu> Date: Fri, 21 Feb 2014 01:41:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 21 Feb 2014 01:42:28 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ve0twYxFMX-zSsVpvmhIeZ-7AE0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 09:47:53 -0000 On Feb 20, 2014, at 5:45 AM, David Farmer wrote: > On 2/20/14, 07:15 , Nick Hilliard wrote: >> On 20/02/2014 01:17, Lorenzo Colitti wrote: >>> You assume that people will actually follow the rules instead of = saying >>> "let's just do this like IPv4, and use NAT at the border". >>=20 >> people will not just do this: they will assign everything from = fd00::/48 >> and will view NAT as a feature. >=20 > Do we think not talking about ULA will stop people from doing NAT with = ULA? >=20 > Get over it. This draft is necessary, we need to tell people how to = properly use ULA. It is not telling them to do NAT. I think it should = more strongly tell them to NOT do NAT. However, they are going to do = what they are going to do. But, if we don't tell them what the proper = use cases for ULA are, then our silence is consent for them to go ahead = and do NAT with ULA. I don=92t think anyone is advocating not talking about ULA=85 I think = some of us just want to make sure that the drawbacks, pitfalls, and = problems it creates are explicitly mentioned in the draft rather than = painting an optimistic and unrealistically rosy picture. Owen From nobody Fri Feb 21 02:03:24 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F5C1A0488 for ; Fri, 21 Feb 2014 02:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 vc-LyTwvlui5 for ; Fri, 21 Feb 2014 02:03:19 -0800 (PST) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 57DCE1A0436 for ; Fri, 21 Feb 2014 02:03:19 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id i7so467605oag.24 for ; Fri, 21 Feb 2014 02:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F6aQKmt7YKJnZROUJu4OfeCt0AFifbVtceEkMu+H5d4=; b=dtWJBXgvua+2g+0mfoxTBvif4MIsWZQk4R/znKMBmL2yCtimKoxWIJl5XmcuTTdP0u eR6oFPO35Q5WHmlyCtg5I7XuSpzAoFq0FD3UU+5YpE5FWGRyy7KXgK5ZSlLlSLtx6koI OBLziQ+llSseG8LdOAxLNcCOJ6OnlE5JtB368uJKiLbwj0gOyQg0T6I8IR1kx57lh9yq S5EgZIV2W8MlD63NzBtUEUrUdPSooTDbaZd+OU6NM4386kZ7DdQUqOmGLGrRJi9wytQR PNDOSr32I4UUjrH5L+8lAPJJ62DisVQ33CZ0Y98VN5iBel6ZX31mdooiImNqssqgYlqE wpDA== 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=F6aQKmt7YKJnZROUJu4OfeCt0AFifbVtceEkMu+H5d4=; b=bBm8Y7GDWHKZCnueaS4HsZn7XVajSo/aeJ9FP2gS5UQGTeLuI/MJw271IogfOQtLNI A0CKa9ZqvAhKu8LfvnlJYL3RHOLRlKl+IU709GAE1OdkA/GCZQooiTQRCU9aAJo08RRh 5DwfyqAIcQYdE+VyOdhNqrwcdTGV6oqghIlVEn8djfThiNcGO72xnucYmP/SgWpiuNba KxqKYhBI+8OdD+0FRB/np3GcmXFx6+Himj6Jgg5iyFR8z7AaMD8ZianGXChT/rxP8B2I L6oRptCjrtQ0hP21j9SENnahdOTCduk2f9k5ZKUtSm/BU34jXtY/JXbNLEcxylroVlLi F2bA== X-Gm-Message-State: ALoCoQlQvktBMRUKt1WZKhy1lySo0hjjF3jOwafi7blz4JCN+g8J0CO4IAZLxY0wqbYZ8oTfXNtyt02mkFsNxDe5MMVRwxZMmKoeNvuNVd8yaMqYxBw+ERfx9vGLFosPjfzpACR22tCzSRxO5LOD25QtOmt1a3yB729ImvphCYu92MhkRJsG3/sabnUkIAKSmtyDO99jDIHe X-Received: by 10.60.115.68 with SMTP id jm4mr2325632oeb.45.1392976995348; Fri, 21 Feb 2014 02:03:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.89.229 with HTTP; Fri, 21 Feb 2014 02:02:54 -0800 (PST) In-Reply-To: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> From: Lorenzo Colitti Date: Fri, 21 Feb 2014 19:02:54 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e0115f368fd156804f2e7ba6c Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Fvh8xQjSk-pB-ckEZiCu45yrNXE Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 10:03:22 -0000 --089e0115f368fd156804f2e7ba6c Content-Type: text/plain; charset=UTF-8 On Fri, Feb 21, 2014 at 5:20 AM, Mikael Abrahamsson wrote: > I will be the first to support a draft that documents *real* experience of >> ULA in a *real* deployment. But documenting use cases without having >> actually used them for real... sorry, that's hubris. >> > > At least one of the top10 residential deployments on > http://www.worldipv6launch.org/measurements/ uses ULAs and reportedly > hasn't seen any customer complaints related to ULAs. > Yes, sorry. But they use ULA in addition to global addresses. I think we do understand that. The use cases I'm worried about (and I should have said this explicitly, sorry) are the ones which use ULA without global addresses. We don't know how those can be made to work. --089e0115f368fd156804f2e7ba6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 21, 2014 at 5:20 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
I will be the first to support a draft that documents *real* experience = of ULA in a *real* deployment. But documenting use cases without having act= ually used them for real... sorry, that's hubris.

At least one of the top10 residential deployments on http://www.worldipv6la= unch.org/measurements/ uses ULAs and reportedly hasn't seen = any customer complaints related to ULAs.

Yes, sorry. But they use ULA in addition t= o global addresses. I think we do understand that.

The use cases I'm worried about (and I should have said this explicitl= y, sorry) are the ones which use ULA without global addresses. We don't= know how those can be made to work.
--089e0115f368fd156804f2e7ba6c-- From nobody Fri Feb 21 02:07:33 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E46C1A0436 for ; Fri, 21 Feb 2014 02:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 bPYx_z8tLJ4H for ; Fri, 21 Feb 2014 02:07:27 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id A1E801A0052 for ; Fri, 21 Feb 2014 02:07:27 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 920F4A3; Fri, 21 Feb 2014 11:07:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8D10A9A; Fri, 21 Feb 2014 11:07:22 +0100 (CET) Date: Fri, 21 Feb 2014 11:07:22 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@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: http://mailarchive.ietf.org/arch/msg/v6ops/vGVz5ERxQbd0N4rBglZ_ffS1Ttg Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 10:07:30 -0000 On Fri, 21 Feb 2014, Lorenzo Colitti wrote: > The use cases I'm worried about (and I should have said this explicitly, > sorry) are the ones which use ULA without global addresses. We don't > know how those can be made to work. Do you mean which never has GUA addresses, even when the Internet connection is up? The use-case for ULA I have been told is "need to reach printer when Internet connection is down". I am worried about this as well, because old-style RFC3484 devices will probably rely on ICMP unreachables and happy eyeballs to avoid giving a super crappy user experience when accessing dual stack resources on the Internet. I welcome further research into this topic. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 21 02:13:32 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A201A0488 for ; Fri, 21 Feb 2014 02:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, 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 eHMQX9nXhzUy for ; Fri, 21 Feb 2014 02:13:29 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8751A0509 for ; Fri, 21 Feb 2014 02:13:06 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2BD879C; Fri, 21 Feb 2014 11:13:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 24A7A9A; Fri, 21 Feb 2014 11:13:02 +0100 (CET) Date: Fri, 21 Feb 2014 11:13:02 +0100 (CET) From: Mikael Abrahamsson To: Lorenzo Colitti In-Reply-To: Message-ID: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@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: http://mailarchive.ietf.org/arch/msg/v6ops/mJkH_IqBABor19JNnxCcEkOGP6g Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 10:13:30 -0000 On Fri, 21 Feb 2014, Mikael Abrahamsson wrote: > I am worried about this as well, because old-style RFC3484 devices will > probably rely on ICMP unreachables and happy eyeballs to avoid giving a > super crappy user experience when accessing dual stack resources on the > Internet. I welcome further research into this topic. Gah, clarification: I meant when IPv4 Internet connectivity is up, but IPv6 GUA isn't available, meaning RFC3484 style devices with RFC1918+ULA. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Feb 21 02:35:16 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D61A0091 for ; Fri, 21 Feb 2014 02:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBRv6hQvbB_a for ; Fri, 21 Feb 2014 02:35:13 -0800 (PST) Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) by ietfa.amsl.com (Postfix) with ESMTP id EBA7C1A0063 for ; Fri, 21 Feb 2014 02:35:12 -0800 (PST) Received: from [2a02:c0:2:4:6666:17:0:1000] (port=41105 helo=echo.linpro.no) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WGnRf-0007nI-DV; Fri, 21 Feb 2014 11:35:03 +0100 Message-ID: <53072BD7.2090903@fud.no> Date: Fri, 21 Feb 2014 11:35:03 +0100 From: Tore Anderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mikael Abrahamsson , Lorenzo Colitti References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/J5xBsKHhLAcB0JsZ1MTXX3t9lZk Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 10:35:14 -0000 * Mikael Abrahamsson >> I am worried about this as well, because old-style RFC3484 devices >> will probably rely on ICMP unreachables and happy eyeballs to avoid >> giving a super crappy user experience when accessing dual stack >> resources on the Internet. I welcome further research into this topic. > > Gah, clarification: I meant when IPv4 Internet connectivity is up, but > IPv6 GUA isn't available, meaning RFC3484 style devices with RFC1918+ULA. This should be fine as long RFC 7084 reqs G-4, G-5, and ULA-5 are implemented, as then the ULA-numbered hosts would be without a default route, and does a fast failover (happening entirely within the hosts' IP stack) to IPv4 when trying to communicate with internet destinations. If req L-3 is implemented it should even work if the printer is on a different link than the device trying to print to it (assuming both implement RFC 4191). Tore From nobody Fri Feb 21 02:43:55 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DF61A04E9 for ; Fri, 21 Feb 2014 02:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 Dru-UigGpwew for ; Fri, 21 Feb 2014 02:43:52 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 968191A0088 for ; Fri, 21 Feb 2014 02:43:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3B74A870078; Fri, 21 Feb 2014 11:43:47 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUjIkP1ke0RN; Fri, 21 Feb 2014 11:43:47 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0F2CE87006E; Fri, 21 Feb 2014 11:43:47 +0100 (CET) Message-ID: <53072DE0.1090702@globis.net> Date: Fri, 21 Feb 2014 11:43:44 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Brian E Carpenter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <5305B159.2050402@globis.net> <53065F7D.1010909@gmail.com> <5306796F.5030709@globis.net> <53069CE6.90009@gmail. com> In-Reply-To: <53069CE6.90009@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/NwQUVltHXrT04fINegyD-0ZzL5w Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] multiple prefixes [no longer draft-ietf-v6ops-ula-usage-recommendations-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 10:43:53 -0000 > Brian E Carpenter > 21 February 2014 01:25 > On 21/02/2014 10:53, Ray Hunter wrote: >>> Brian E Carpenter >>> 20 February 2014 21:03 >>> On 20/02/2014 20:40, Ray Hunter wrote: >>> ... >>> >>> Ray, ULA prefixes *are* global unicast prefixes; their only special >>> characteristic is that they are not routed outside a given administrative >>> domain. OK ULA = Globally unique with high probability of uniqueness, and limited reachability scope. RFC 6887 states "These IP addresses may have distinct reachability scopes (e.g., if IPv6, they might have global reachability scope as is the case for a Global Unicast Address (GUA) [RFC3587] or limited scope as is the case for a Unique Local Address (ULA) [RFC4193])." which suggests to me that they are distinct. And RFC 3587 refers to "The TLA/NLA scheme has been replaced by a coordinated allocation policy defined by the Regional Internet Registries (RIRs) [IPV6RIR]" which does not cover self-generated ULA. So I'm not the first to blur that particular boundary. >>> Also, it is common for large enterprises to run multiple disjoint >>> prefixes >>> within the corporate network, and has been for many years. >>> >> So how do they set up firewall rules? > > I'm not sure why you ask, and when I worked for such a company > (IBM) it wasn't something I ever looked at. However, I assume > that the filters for every border device to the Internet cited > all the internal prefixes in use. Nope. Especially at private NNI's, the enterprises have a duty to protect each other from attack by e.g. virus storms. Only authorised machines should communicate. > Certainly the config file for > the call-home VPN on my company laptop included a very long list of > prefixes, and I guess that was pretty much the same list as they > needed in the border firewalls. Nope. Many businesses have a requirement for controlled and tracked outbound access. e.g. to see which machine FTPed a copy of the corporate development code to the Internet, and when. >>> I think the issues you're concerned about are all due to the fact that >>> in IPv6, it is bog standard to run more than one prefix on the same >>> phsyical subnet. The fact that one of them might be delegated from >>> a ULA /48 seems to me to be a side issue. >>> >>> Brian >> So you see no problems with a machine running multiple prefixes, where >> the IID for each may also be different (stable privacy addresses), and >> each session may source from a different prefix depending on where it's >> terminating (address selection + address rotation of privacy addresses)? > > That's the design of IPv6. > >> How will the firewall even know it's the same machine sending the >> packets, never mind the same user, so that the communication stream can >> be authorised or blocked? > > You're talking about a firewall that censors outgoing sessions? Yes. > Well, that's bound to be a pain. But you'll find the MAC address > in the ND cache, so you could check that way. They are not connected at L2. > >> Will users have to re-authenticate for every prefix + IID combination? > > If it's a firewall that authenticates users, yes, I would think so. > But I don't see why that would require user action; it should just be > automatic after the user's initial authentication. If not, the > authentication mechanism is not well designed for IPv6. > > Brian > > Is there any IETF standard for this authentication? When I check PCP it doesn't seem to explicitly correlate requests from the same machine, and ULA's should not be used as the source of the PCP message. > IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be used as the source interface when generating a PCP request. What about internal firewalls within an enterprise? ULA only networks? Ignore the SHOULD? GUA prefix that arrives after the ULA is configured? Before ULA is configured? I still expect operational issues with synchronising access requests from a single machine across multiple prefixes: GUA rule times out, but the ULA rule doesn't or vice versa. It's going to be a nightmare to debug. To my mind, there definitely seems to be operational gaps in the assumptions made for GUA + ULA operation in parallel. -- Regards, RayH From nobody Fri Feb 21 04:01:36 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62AE1A052F for ; Fri, 21 Feb 2014 04:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqv53-HPJfoZ for ; Fri, 21 Feb 2014 04:01:33 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5681A0530 for ; Fri, 21 Feb 2014 04:01:33 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EE09F1B8058 for ; Fri, 21 Feb 2014 04:01:29 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E2EC9190052; Fri, 21 Feb 2014 04:01:29 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 04:01:29 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Fri, 21 Feb 2014 07:01:31 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6A86FF75-AC18-4A3E-B3BF-45A1819F5FC8@nominum.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> To: Owen DeLong X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Qg_Trryfeo2-iTw_BHoUtBsLq-I Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 12:01:35 -0000 On Feb 21, 2014, at 4:41 AM, Owen DeLong wrote: > I don=92t think anyone is advocating not talking about ULA=85 I think = some of us just want to make sure that the drawbacks, pitfalls, and = problems it creates are explicitly mentioned in the draft rather than = painting an optimistic and unrealistically rosy picture. Can you propose some text you'd like to see added, so that we can = discuss it? :) From nobody Fri Feb 21 05:45:35 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884D01A0148 for ; Fri, 21 Feb 2014 05:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdi9NtLnraym for ; Fri, 21 Feb 2014 05:45:31 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C62BF1A0141 for ; Fri, 21 Feb 2014 05:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1392990328; x=1394199928; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=Pk00cK4hAEwR/i18cC7PGygKaRR4r0u8liL43u97QrEX1a9pIbFN/3Lr qbBmEMG0clJu0mDPj9Gr4eK1xlU2PK+Zd9/aqvTLK77WF92HhQ9yCWxjI wwb9rwa8YJShp3XDo7T+kjQk5kQr/+iUsSEh7o6C6CV6m3eHKI6+sdoKZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYLAFVYB1OrRDoJ/2dsb2JhbABZgwY7qykBlWEDBAKBDBZ0gyU8LQeIZQ7LUBeOZB2EIgSJSJAekHWDTg X-IronPort-AV: E=Sophos;i="4.97,519,1389744000"; d="scan'208";a="104165146" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 21 Feb 2014 13:45:17 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1LDjGsH011737; Fri, 21 Feb 2014 13:45:16 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1LDjGR13445; Fri, 21 Feb 2014 05:45:16 -0800 (PST) Date: Fri, 21 Feb 2014 05:45:16 -0800 (PST) From: Message-Id: <201402211345.s1LDjGR13445@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/L_2aDseP7DHhJhFfQSTrDcp1-sU Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 13:45:33 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Fri Feb 21 09:09:04 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2DA1A047E for ; Fri, 21 Feb 2014 09:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=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 MGGxDYVW7dqn for ; Fri, 21 Feb 2014 09:09:00 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1901A0487 for ; Fri, 21 Feb 2014 09:08:59 -0800 (PST) Received: from [50.95.222.92] ([50.95.222.92]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1LH6ves012168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 09:07:12 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1LH6ves012168 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1393002442; bh=LKIo0CUZpIun4tuRScVZnICcW2g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=U1nv3r9wiseb4q5PnP0UjhxG7fp0qhJDiY6vyxW7NP5kwkG8fpflZjhKnyr1SgV0h iK1OUfSP2ezpx0Y222uuC4MfKVzJLG80jzi0naHPPWGyKprxMbGOd4CxHmtto5//Kc hhxjh/V7NqBw69ByUtcHxq+jIPBZYuw+MclXPEgo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: Date: Fri, 21 Feb 2014 09:06:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <96BC705C-266E-43F6-A336-78F2E0DFAFC2@delong.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Fri, 21 Feb 2014 09:07:22 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/T3N6uyW7BOjWcksW4NJ9WAUPcpc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:09:03 -0000 On Feb 20, 2014, at 12:20 PM, Mikael Abrahamsson = wrote: > On Thu, 20 Feb 2014, Lorenzo Colitti wrote: >=20 >> I will be the first to support a draft that documents *real* = experience of ULA in a *real* deployment. But documenting use cases = without having actually used them for real... sorry, that's hubris. >=20 > At least one of the top10 residential deployments on = http://www.worldipv6launch.org/measurements/ uses ULAs and reportedly = hasn't seen any customer complaints related to ULAs. >=20 Most residential customers don=92t even realize that an internet without = NAT is possible. Many ISPs run NAT IPv4 solutions with zero customer complaints. Lack of customer complaints, especially in residential, is really not = the bar I think we should be striving for here. A big part of the point = of IPv6 is to provide the ability to restore an end-to-end internet. = Aiming for an internet that merely avoids uninformed non-technical users = complaining about the service being worse than the degraded service they = have always experienced until now is not going to allow us to come = anywhere near that goal. > This isn't really the corporate use case I believe we're discussing = here but... >=20 > Just to be clear, I am not a ULA fan, but I am all for documenting = things. I=92m all for documenting reality. I=92m not for advocating solutions = that are unproven or discussing poor choices in a bizarrely positive = light which is, IMHO, the current state of this draft. Owen From nobody Fri Feb 21 11:37:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0457C1A059D for ; Fri, 21 Feb 2014 11:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 lsnD3i6xCZrP for ; Fri, 21 Feb 2014 11:37:15 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61D1A05AD for ; Fri, 21 Feb 2014 11:36:50 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id ma3so1225368pbc.12 for ; Fri, 21 Feb 2014 11:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JB8zgSszD/TyDjs17pP0welm2ujNTmsIOYBFx2bdH4E=; b=Vi5dGlBy7mh7kIAi+PucV4dPqhaDqs+VXxUlnVCR8mPMul/otU2+s4sGQmbe+A6OFc dTC7FZVloNhiIhey346i6XyffyvuDhoXDD5flu0HKRJtW3/+NNqY54C64LoXEaUpahyd o4D+xV6HO6rk1Qvc6jOvXtJaYemF7lwSCQAfl9XXOBZLDCzy+K2skbcs50ysWqzBIwzZ 9rnraAHvgVIbe8Ttr6Xf1PaR0B50KDstEpealWokwjXJKSOpZlrXl6EazgaINA44cSCa 5sQrsYxarmxd6A1K4LRA0iDGrqHdCjyawD6r0zEFLjGX3I9EmtjTAn3u31mSmSUpoq9F Xo3w== X-Received: by 10.66.146.199 with SMTP id te7mr11041571pab.106.1393011406429; Fri, 21 Feb 2014 11:36:46 -0800 (PST) Received: from [192.168.178.23] (130.192.69.111.dynamic.snap.net.nz. [111.69.192.130]) by mx.google.com with ESMTPSA id ug2sm55391792pac.21.2014.02.21.11.36.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 11:36:45 -0800 (PST) Message-ID: <5307AAD9.3060401@gmail.com> Date: Sat, 22 Feb 2014 08:36:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <5305B159.2050402@globis.net> <53065F7D.1010909@gmail.com> <5306796F.5030709@globis.net> <53069CE6.90009@gmail. com> <53072DE0.1090702@globis.net> In-Reply-To: <53072DE0.1090702@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ZvBK0mULbj3bzsPTdJ-fSHc_K1o Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] multiple prefixes [no longer draft-ietf-v6ops-ula-usage-recommendations-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 19:37:18 -0000 > Only authorised machines should communicate. In such a regime you're bound to have stateful or static address assignment, so if you have N prefixes each machine will need to have N stateful or static addresses. I understand that it's N times the hassle and that you might not want to do it. However, an address derived from a ULA prefix would never be authorised to communicate with the Internet. If you had a subclass of machines that were allowed to communicate with a business partner via ULA but not with the Internet, a ULA would just be one of the N. Regards Brian On 21/02/2014 23:43, Ray Hunter wrote: >> Brian E Carpenter >> 21 February 2014 01:25 >> On 21/02/2014 10:53, Ray Hunter wrote: >>>> Brian E Carpenter >>>> 20 February 2014 21:03 >>>> On 20/02/2014 20:40, Ray Hunter wrote: >>>> ... >>>> >>>> Ray, ULA prefixes *are* global unicast prefixes; their only special >>>> characteristic is that they are not routed outside a given >>>> administrative >>>> domain. > > OK ULA = Globally unique with high probability of uniqueness, and > limited reachability scope. > > RFC 6887 states "These IP addresses may have distinct reachability > scopes (e.g., if IPv6, they might have global reachability scope as is > the case for a Global Unicast Address (GUA) [RFC3587] or limited scope > as is the case for a Unique Local Address (ULA) [RFC4193])." which > suggests to me that they are distinct. > > And RFC 3587 refers to "The TLA/NLA scheme has been replaced by a > coordinated allocation policy defined by the Regional Internet > Registries (RIRs) [IPV6RIR]" which does not cover self-generated ULA. > > So I'm not the first to blur that particular boundary. >>>> Also, it is common for large enterprises to run multiple disjoint >>>> prefixes >>>> within the corporate network, and has been for many years. >>>> >>> So how do they set up firewall rules? >> >> I'm not sure why you ask, and when I worked for such a company >> (IBM) it wasn't something I ever looked at. However, I assume >> that the filters for every border device to the Internet cited >> all the internal prefixes in use. > Nope. Especially at private NNI's, the enterprises have a duty to > protect each other from attack by e.g. virus storms. > Only authorised machines should communicate. > >> Certainly the config file for >> the call-home VPN on my company laptop included a very long list of >> prefixes, and I guess that was pretty much the same list as they >> needed in the border firewalls. > Nope. Many businesses have a requirement for controlled and tracked > outbound access. e.g. to see which machine FTPed a copy of the corporate > development code to the Internet, and when. >>>> I think the issues you're concerned about are all due to the fact that >>>> in IPv6, it is bog standard to run more than one prefix on the same >>>> phsyical subnet. The fact that one of them might be delegated from >>>> a ULA /48 seems to me to be a side issue. >>>> >>>> Brian >>> So you see no problems with a machine running multiple prefixes, where >>> the IID for each may also be different (stable privacy addresses), and >>> each session may source from a different prefix depending on where it's >>> terminating (address selection + address rotation of privacy addresses)? >> >> That's the design of IPv6. >> >>> How will the firewall even know it's the same machine sending the >>> packets, never mind the same user, so that the communication stream can >>> be authorised or blocked? >> >> You're talking about a firewall that censors outgoing sessions? > Yes. >> Well, that's bound to be a pain. But you'll find the MAC address >> in the ND cache, so you could check that way. > They are not connected at L2. >> >>> Will users have to re-authenticate for every prefix + IID combination? >> >> If it's a firewall that authenticates users, yes, I would think so. >> But I don't see why that would require user action; it should just be >> automatic after the user's initial authentication. If not, the >> authentication mechanism is not well designed for IPv6. >> >> Brian >> >> > Is there any IETF standard for this authentication? > > When I check PCP it doesn't seem to explicitly correlate requests from > the same machine, and ULA's should not be used as the source of the PCP > message. >> IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be > used as the source interface when generating a PCP request. > > What about internal firewalls within an enterprise? ULA only networks? > Ignore the SHOULD? > GUA prefix that arrives after the ULA is configured? Before ULA is > configured? > > I still expect operational issues with synchronising access requests > from a single machine across multiple prefixes: > GUA rule times out, but the ULA rule doesn't or vice versa. It's going > to be a nightmare to debug. > > To my mind, there definitely seems to be operational gaps in the > assumptions made for GUA + ULA operation in parallel. > From nobody Fri Feb 21 13:48:29 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EF21A024F for ; Fri, 21 Feb 2014 13:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 L_-ZH3O3dOUD for ; Fri, 21 Feb 2014 13:48:25 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA31A0152 for ; Fri, 21 Feb 2014 13:48:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C0D6C870F92; Fri, 21 Feb 2014 22:48:20 +0100 (CET) Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9NCAamDnSYP; Fri, 21 Feb 2014 22:48:20 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9610E87003E; Fri, 21 Feb 2014 22:48:20 +0100 (CET) Message-ID: <5307C99A.9040400@globis.net> Date: Fri, 21 Feb 2014 22:48:10 +0100 From: Ray Hunter User-Agent: Postbox 3.0.9 (Macintosh/20140129) MIME-Version: 1.0 To: Brian E Carpenter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <5305B159.2050402@globis.net> <53065F7D.1010909@gmail.com> <5306796F.5030709@globis.net> <53069CE6.90009@gmail. com> <53072DE0.1090702@globis .net> <5307AAD9.3060401@gmail.com> In-Reply-To: <5307AAD9.3060401@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/h8FCWh9bB-sJG2Zt64_JJBpawDc Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] multiple prefixes [no longer draft-ietf-v6ops-ula-usage-recommendations-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:48:28 -0000 > Brian E Carpenter > 21 February 2014 20:36 >> Only authorised machines should communicate. > > In such a regime you're bound to have stateful or static address > assignment, so if you have N prefixes each machine will need to have > N stateful or static addresses. I understand that it's N times the > hassle and that you might not want to do it. > > However, an address derived from a ULA prefix would never be > authorised to communicate with the Internet. If you had a subclass > of machines that were allowed to communicate with a business > partner via ULA but not with the Internet, a ULA would just be > one of the N. > > Regards > Brian And then maintain correlation of Semantically Opaque Interface Identifiers to machine for each prefix? No thanks. I think the only sensible operational advice is "Do not split a ULA /48 prefix across a firewall or other network security zone boundary" That way the default address selection rules will ensure that no two nodes will use ULA's for communication across that boundary, and you can maintain a single ACL/firewall rule based on the GUA RIR registered addresses. > > On 21/02/2014 23:43, Ray Hunter wrote: >>> Brian E Carpenter >>> 21 February 2014 01:25 >>> On 21/02/2014 10:53, Ray Hunter wrote: >>>>> Brian E Carpenter >>>>> 20 February 2014 21:03 >>>>> On 20/02/2014 20:40, Ray Hunter wrote: >>>>> ... >>>>> >>>>> Ray, ULA prefixes *are* global unicast prefixes; their only special >>>>> characteristic is that they are not routed outside a given >>>>> administrative >>>>> domain. >> OK ULA = Globally unique with high probability of uniqueness, and >> limited reachability scope. >> >> RFC 6887 states "These IP addresses may have distinct reachability >> scopes (e.g., if IPv6, they might have global reachability scope as is >> the case for a Global Unicast Address (GUA) [RFC3587] or limited scope >> as is the case for a Unique Local Address (ULA) [RFC4193])." which >> suggests to me that they are distinct. >> >> And RFC 3587 refers to "The TLA/NLA scheme has been replaced by a >> coordinated allocation policy defined by the Regional Internet >> Registries (RIRs) [IPV6RIR]" which does not cover self-generated ULA. >> >> So I'm not the first to blur that particular boundary. >>>>> Also, it is common for large enterprises to run multiple disjoint >>>>> prefixes >>>>> within the corporate network, and has been for many years. >>>>> >>>> So how do they set up firewall rules? >>> I'm not sure why you ask, and when I worked for such a company >>> (IBM) it wasn't something I ever looked at. However, I assume >>> that the filters for every border device to the Internet cited >>> all the internal prefixes in use. >> Nope. Especially at private NNI's, the enterprises have a duty to >> protect each other from attack by e.g. virus storms. >> Only authorised machines should communicate. >> >>> Certainly the config file for >>> the call-home VPN on my company laptop included a very long list of >>> prefixes, and I guess that was pretty much the same list as they >>> needed in the border firewalls. >> Nope. Many businesses have a requirement for controlled and tracked >> outbound access. e.g. to see which machine FTPed a copy of the corporate >> development code to the Internet, and when. >>>>> I think the issues you're concerned about are all due to the fact that >>>>> in IPv6, it is bog standard to run more than one prefix on the same >>>>> phsyical subnet. The fact that one of them might be delegated from >>>>> a ULA /48 seems to me to be a side issue. >>>>> >>>>> Brian >>>> So you see no problems with a machine running multiple prefixes, where >>>> the IID for each may also be different (stable privacy addresses), and >>>> each session may source from a different prefix depending on where it's >>>> terminating (address selection + address rotation of privacy addresses)? >>> That's the design of IPv6. >>> >>>> How will the firewall even know it's the same machine sending the >>>> packets, never mind the same user, so that the communication stream can >>>> be authorised or blocked? >>> You're talking about a firewall that censors outgoing sessions? >> Yes. >>> Well, that's bound to be a pain. But you'll find the MAC address >>> in the ND cache, so you could check that way. >> They are not connected at L2. >>>> Will users have to re-authenticate for every prefix + IID combination? >>> If it's a firewall that authenticates users, yes, I would think so. >>> But I don't see why that would require user action; it should just be >>> automatic after the user's initial authentication. If not, the >>> authentication mechanism is not well designed for IPv6. >>> >>> Brian >>> >>> >> Is there any IETF standard for this authentication? >> >> When I check PCP it doesn't seem to explicitly correlate requests from >> the same machine, and ULA's should not be used as the source of the PCP >> message. >>> IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be >> used as the source interface when generating a PCP request. >> >> What about internal firewalls within an enterprise? ULA only networks? >> Ignore the SHOULD? >> GUA prefix that arrives after the ULA is configured? Before ULA is >> configured? >> >> I still expect operational issues with synchronising access requests >> from a single machine across multiple prefixes: >> GUA rule times out, but the ULA rule doesn't or vice versa. It's going >> to be a nightmare to debug. >> >> To my mind, there definitely seems to be operational gaps in the >> assumptions made for GUA + ULA operation in parallel. >> > > ------------------------------------------------------------------------ -- Regards, RayH From nobody Fri Feb 21 17:03:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5811A0343 for ; Fri, 21 Feb 2014 17:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBQmfuoF-Vea for ; Fri, 21 Feb 2014 17:03:27 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB391A030A for ; Fri, 21 Feb 2014 17:03:27 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y13so1439933pdi.26 for ; Fri, 21 Feb 2014 17:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mIly6OxpOZrUBbY6B5uwAtOWe8FCvsMoJ5JBEyvP5aY=; b=MET1JfYnc9PvjdCVc0b3SIT54XE0WqCM31HeEpSC+6od/l5ZfjGr34mSzKAMZUbUx8 uOpdXHudCjcY9c50dXwpO5a1ar0unbUikAIeKVxkWnPfe5nkLOU/EMiZ0AME4HSKpUXU b3qwx7jRFUAqwCwN8LPWT60RZBV2MEN2C31uKt4x9tsFop1dZj9PUow7Cp5NCbjVUzrf kY7qr/GXktDTddYIIGow7fwlQBD0iGLJShfRzx0iYeMNn5dqZfuoPpa+dpTtIES8VIx2 v4mmwL2veHfeCZRG+g8J7rOiKr2graqSKx9x+SbMaJkIsgGMLLyWkOSNPDfKILsSSkAt 2dLQ== X-Received: by 10.66.193.202 with SMTP id hq10mr12267208pac.57.1393031003268; Fri, 21 Feb 2014 17:03:23 -0800 (PST) Received: from [192.168.178.23] (130.192.69.111.dynamic.snap.net.nz. [111.69.192.130]) by mx.google.com with ESMTPSA id dk1sm25473988pbc.46.2014.02.21.17.03.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 17:03:22 -0800 (PST) Message-ID: <5307F766.7090504@gmail.com> Date: Sat, 22 Feb 2014 14:03:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <53055FF3.2040605@gmail.com> <5305B159.2050402@globis.net> <53065F7D.1010909@gmail.com> <5306796F.5030709@globis.net> <53069CE6.90009@gmail. com> <53072DE0.1090702@globis .net> <5307AAD9.3060401@gmail.com> <5307C99A.9040400@globis.net> In-Reply-To: <5307C99A.9040400@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/HJaE4nynQy6qDfjzHRcbX__CzBs Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] multiple prefixes [no longer draft-ietf-v6ops-ula-usage-recommendations-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 01:03:29 -0000 On 22/02/2014 10:48, Ray Hunter wrote: >> Brian E Carpenter >> 21 February 2014 20:36 >>> Only authorised machines should communicate. >> >> In such a regime you're bound to have stateful or static address >> assignment, so if you have N prefixes each machine will need to have >> N stateful or static addresses. I understand that it's N times the >> hassle and that you might not want to do it. >> >> However, an address derived from a ULA prefix would never be >> authorised to communicate with the Internet. If you had a subclass >> of machines that were allowed to communicate with a business >> partner via ULA but not with the Internet, a ULA would just be >> one of the N. >> >> Regards >> Brian > > And then maintain correlation of Semantically Opaque Interface > Identifiers to machine for each prefix? That seems to be the necessary implication of the restricted access model that Ray describes, regardless of what kind of prefix or how many of them you have. > > No thanks. > > I think the only sensible operational advice is "Do not split a ULA /48 > prefix across a firewall or other network security zone boundary" I agree. That's not the model. If company A has a prefix ULA-A and company B has a prefix ULA-B, then A announces a route to ULA-A on the private link between the companies, and B announces ULA-B. > > That way the default address selection rules will ensure that no two > nodes will use ULA's for communication across that boundary, and you can > maintain a single ACL/firewall rule based on the GUA RIR registered > addresses. You need different rules on the inter-company link. Brian >> >> On 21/02/2014 23:43, Ray Hunter wrote: >>>> Brian E Carpenter >>>> 21 February 2014 01:25 >>>> On 21/02/2014 10:53, Ray Hunter wrote: >>>>>> Brian E Carpenter >>>>>> 20 February 2014 21:03 >>>>>> On 20/02/2014 20:40, Ray Hunter wrote: >>>>>> ... >>>>>> >>>>>> Ray, ULA prefixes *are* global unicast prefixes; their only special >>>>>> characteristic is that they are not routed outside a given >>>>>> administrative >>>>>> domain. >>> OK ULA = Globally unique with high probability of uniqueness, and >>> limited reachability scope. >>> >>> RFC 6887 states "These IP addresses may have distinct reachability >>> scopes (e.g., if IPv6, they might have global reachability scope as is >>> the case for a Global Unicast Address (GUA) [RFC3587] or limited scope >>> as is the case for a Unique Local Address (ULA) [RFC4193])." which >>> suggests to me that they are distinct. >>> >>> And RFC 3587 refers to "The TLA/NLA scheme has been replaced by a >>> coordinated allocation policy defined by the Regional Internet >>> Registries (RIRs) [IPV6RIR]" which does not cover self-generated ULA. >>> >>> So I'm not the first to blur that particular boundary. >>>>>> Also, it is common for large enterprises to run multiple disjoint >>>>>> prefixes >>>>>> within the corporate network, and has been for many years. >>>>>> >>>>> So how do they set up firewall rules? >>>> I'm not sure why you ask, and when I worked for such a company >>>> (IBM) it wasn't something I ever looked at. However, I assume >>>> that the filters for every border device to the Internet cited >>>> all the internal prefixes in use. >>> Nope. Especially at private NNI's, the enterprises have a duty to >>> protect each other from attack by e.g. virus storms. >>> Only authorised machines should communicate. >>> >>>> Certainly the config file for >>>> the call-home VPN on my company laptop included a very long list of >>>> prefixes, and I guess that was pretty much the same list as they >>>> needed in the border firewalls. >>> Nope. Many businesses have a requirement for controlled and tracked >>> outbound access. e.g. to see which machine FTPed a copy of the corporate >>> development code to the Internet, and when. >>>>>> I think the issues you're concerned about are all due to the fact >>>>>> that >>>>>> in IPv6, it is bog standard to run more than one prefix on the same >>>>>> phsyical subnet. The fact that one of them might be delegated from >>>>>> a ULA /48 seems to me to be a side issue. >>>>>> >>>>>> Brian >>>>> So you see no problems with a machine running multiple prefixes, where >>>>> the IID for each may also be different (stable privacy addresses), and >>>>> each session may source from a different prefix depending on where >>>>> it's >>>>> terminating (address selection + address rotation of privacy >>>>> addresses)? >>>> That's the design of IPv6. >>>> >>>>> How will the firewall even know it's the same machine sending the >>>>> packets, never mind the same user, so that the communication stream >>>>> can >>>>> be authorised or blocked? >>>> You're talking about a firewall that censors outgoing sessions? >>> Yes. >>>> Well, that's bound to be a pain. But you'll find the MAC address >>>> in the ND cache, so you could check that way. >>> They are not connected at L2. >>>>> Will users have to re-authenticate for every prefix + IID combination? >>>> If it's a firewall that authenticates users, yes, I would think so. >>>> But I don't see why that would require user action; it should just be >>>> automatic after the user's initial authentication. If not, the >>>> authentication mechanism is not well designed for IPv6. >>>> >>>> Brian >>>> >>>> >>> Is there any IETF standard for this authentication? >>> >>> When I check PCP it doesn't seem to explicitly correlate requests from >>> the same machine, and ULA's should not be used as the source of the PCP >>> message. >>>> IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be >>> used as the source interface when generating a PCP request. >>> >>> What about internal firewalls within an enterprise? ULA only networks? >>> Ignore the SHOULD? >>> GUA prefix that arrives after the ULA is configured? Before ULA is >>> configured? >>> >>> I still expect operational issues with synchronising access requests >>> from a single machine across multiple prefixes: >>> GUA rule times out, but the ULA rule doesn't or vice versa. It's going >>> to be a nightmare to debug. >>> >>> To my mind, there definitely seems to be operational gaps in the >>> assumptions made for GUA + ULA operation in parallel. >>> >> >> ------------------------------------------------------------------------ > > From nobody Sat Feb 22 01:53:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23901A0051 for ; Sat, 22 Feb 2014 01:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 I4JxJSnAwNI9 for ; Sat, 22 Feb 2014 01:53:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FD1A0035 for ; Sat, 22 Feb 2014 01:53:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBJ70314; Sat, 22 Feb 2014 09:53:31 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 09:53:10 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 22 Feb 2014 09:53:31 +0000 Received: from NKGEML506-MBS.china.huawei.com ([169.254.4.237]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 17:53:26 +0800 From: "Liubing (Leo)" To: Owen DeLong Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt Thread-Index: AQHPKWgMo43RzbooVkmZSkAdeWvl75qz/igAgAD96wCAAR80gIABVkQAgAA9hYCAAAN1gIAAC5wAgAEHz4CAADwWAIAAImUAgAAJQ4CAAK9RAIABJvEAgACbWYCAAH+0gIAAhjSAgAA1BACAAMiTgIAACFaAgAAUUQCAAFnrAIABXEwAgAEohyA= Date: Sat, 22 Feb 2014 09:53:26 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D844C0A@nkgeml506-mbs.china.huawei.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> <96BC705C-266E-43F6-A336-78F2E0DFAFC2@delong.com> In-Reply-To: <96BC705C-266E-43F6-A336-78F2E0DFAFC2@delong.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/8KkaEEd6UI3Hsat0kZsGqRfpw6E Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 09:53:38 -0000 Hi Owen, > I'm all for documenting reality. I'm not for advocating solutions that ar= e > unproven or discussing poor choices in a bizarrely positive light which i= s, > IMHO, the current state of this draft. [Bing] There are several recommended use cases in the draft: 1. used in isolated networks 2. used along with GUA 3. some specific cases (as private routing prefixes, as up-layer identifier= s, as NAT64 prefixes) Would you mind providing more information about "bizarrely positive light"?= Do you mean the above recommended use cases, or some other things? Thanks, Bing > Owen >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Feb 22 05:45:09 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584B61A00E0 for ; Sat, 22 Feb 2014 05:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpKK1d-NJkC7 for ; Sat, 22 Feb 2014 05:45:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 384FB1A00E2 for ; Sat, 22 Feb 2014 05:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1393076701; x=1394286301; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=aDy6/0w+QTc8VE7GdLMYKPOMccycKl2EtWbiAYZMkw6IN4BTX1cbZWUI tzs458o6uE037cpsrX6cssbLCvCsGxLSzUFv2WkVjbBNMwCzOdZ6a/Ktp 0uwX536QyDIoQqBZTErVfuQOffP5SjnHU+zRsJ8GkrUCBnvepxilHMlim 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogLAOeoCFOrRDoG/2dsb2JhbABagwY7qzcBlV8DBAKBChZ0gyU8LQeIZQ7JTReOZB2EIgSJSJAekHWDTg X-IronPort-AV: E=Sophos;i="4.97,523,1389744000"; d="scan'208";a="104242371" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 Feb 2014 13:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1MDj0AG001298; Sat, 22 Feb 2014 13:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1MDj0v17772; Sat, 22 Feb 2014 05:45:00 -0800 (PST) Date: Sat, 22 Feb 2014 05:45:00 -0800 (PST) From: Message-Id: <201402221345.s1MDj0v17772@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/sC21RjC5iE4smVzO30eVuU_-Clg Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 13:45:07 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Sat Feb 22 06:14:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF86A1A00E4 for ; Sat, 22 Feb 2014 06:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 IOsIN7M-yu0N for ; Sat, 22 Feb 2014 06:14:04 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 342871A00E0 for ; Sat, 22 Feb 2014 06:14:04 -0800 (PST) Received: from ([24.40.56.122]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.118251669; Sat, 22 Feb 2014 07:13:52 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.53]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 09:13:57 -0500 From: "Brzozowski, John" To: Tim Chown , "Fred Baker (fred)" Thread-Topic: [v6ops] Proposed agenda Thread-Index: AQHPKe+GQ54cQ4Ch+0GNXdWWzntzpw== Date: Sat, 22 Feb 2014 14:13:52 +0000 Message-ID: References: <78AAA6FC-F422-41D4-88A7-58066118C919@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.247] Content-Type: multipart/alternative; boundary="_000_CF2E19391268BEjohnbrzozowskicablecomcastcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/dD_eREeZI0erpJRRn20qczcns6w Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Feb 2014 14:14:07 -0000 --_000_CF2E19391268BEjohnbrzozowskicablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkaW5nIHRoaXMgdG8gdGhlIGFnZW5kYSBtYWtlcyBzZW5zZS4gIFdlIGhhdmUgc2VlbiBldmlk ZW5jZSBvZiBpc3N1ZXMgcmVsYXRlZCB0byBJUHY2IG11bHRpY2FzdCwgc3BlY2lmaWNhbGx5IGxp bmsgbG9jYWwsIGluIGxhcmdlIGJyb2FkYmFuZCBkZXBsb3ltZW50cyB3aGVyZSBXaUZpIGlzIGFu ZCBpcyBub3QgaW4gdXNlLiAgSW4gbW9zdCBjYXNlcyB0byBkYXRlIHRoZXNlIGFwcGVhciB0byBi ZSBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMuICBJdCBkb2VzIG5vdCBodXJ0IHRvIGRpc2N1c3MgYWRk aXRpb25hbCBvcHRpbWl6YXRpb25zIG9yIGNsYXJpZmljYXRpb25zIHRvIGhlbHAgZ3VpZGUgaW1w bGVtZW50ZXJzLg0KDQpUaGlzIGRyYWZ0IGFuZCBvdGhlciByZWxhdGVkIHdvcmsgbXVzdCBjb25z aWRlciBob3cgYnJvYWRiYW5kIGRlcGxveW1lbnRzIGFyZSBlbmFibGluZyBJUHY2IGluIGN1c3Rv bWVyJ3MgcHJlbWlzZXMuICBEaXNjb3VudGluZyB0aGlzIG9yIG1ha2luZyBhc3N1bXB0aW9ucyBh Ym91dCBob3cgSVB2NiBzaG91bGQgZGVwbG95ZWQgZnJvbSBhY2FkZW1pYyBwZXJzcGVjdGl2ZSB3 aWxsIG5vdCBiZSBoZWxwZnVsIHRvIGltcGxlbWVudGVycyBvciBmb3IgdGhlIG92ZXJhbGwgYWRv cHRpb24gb2YgSVB2Ni4NCg0KSm9obg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCkpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KQ29tY2FzdCBDYWJsZQ0KbSkgNjA5LTM3 Ny02NTk0DQpvKSA0ODQtOTYyLTAwNjANCncpIHd3dy5jb21jYXN0Ni5uZXQNCmUpIGpvaG5fYnJ6 b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbTxtYWlsdG86am9obl9icnpvem93c2tpQGNhYmxlLmNv bWNhc3QuY29tPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K RnJvbTogVGltIENob3duIDx0amNAZWNzLnNvdG9uLmFjLnVrPG1haWx0bzp0amNAZWNzLnNvdG9u LmFjLnVrPj4NCkRhdGU6IE1vbmRheSwgRmVicnVhcnkgMTcsIDIwMTQgMTE6MjkgQU0NClRvOiBG cmVkIEJha2VyIDxmcmVkQGNpc2NvLmNvbTxtYWlsdG86ZnJlZEBjaXNjby5jb20+Pg0KQ2M6IHY2 b3BzIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFt2Nm9wc10gUHJvcG9zZWQgYWdlbmRhDQoNCkhpLA0KDQpPbiAxNiBGZWIgMjAxNCwgYXQgMDA6 MzUsIEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbTxtYWlsdG86ZnJlZEBjaXNjby5j b20+PiB3cm90ZToNCg0KTGV0IG1lIGFzayBmb3IgY29tbWVudCBvbiB0aGUgbGlzdC4NCg0KRm9s a3MsIHdvdWxkIHlvdSBsaWtlIHRvIGRpc2N1c3MgdGhpcz8gSSBoYXZlIGEgaGFsZiBob3VyIHRv IHNwYXJlIGluIHRoZSB0aW1lIHdlIGhhdmUgc3VnZ2VzdGVkLg0KDQpZZXMsIHRoaXMgaXMgYSB3 b3J0aHdoaWxlIGRpc2N1c3Npb24gdG8gaGF2ZSwgYnJpZWZseS4NCg0KVGltDQoNCg0KT24gRmVi IDE0LCAyMDE0LCBhdCA3OjA1IFBNLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNv bTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPj4NCiB3cm90ZToNCg0KT24gU2F0LCBGZWIgMTUs IDIwMTQgYXQgMTA6NDQgQU0sIEZyZWQgQmFrZXIgKGZyZWQpIDxmcmVkQGNpc2NvLmNvbTxtYWls dG86ZnJlZEBjaXNjby5jb20+PiB3cm90ZToNClRoaXMgaXMgb2YgY291cnNlIG9wZW4gdG8gY2hh bmdlOyB0aGF0J3Mgd2h5IGl0J3MgY2FsbGVkIGEgInByb3Bvc2VkIGFnZW5kYSIuIFBsZWFzZSBw b3N0IHRvIHRoZSBsaXN0Lg0KDQpXb3VsZCB0aGVyZSBiZSB0aW1lIHRvIGJyaWVmbHkgZGlzY3Vz czoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW91cnRjaGVua28tY29saXR0 aS1uZC1yZWR1Y2UtbXVsdGljYXN0LTAwID8NCg0KVGhpcyB3aWxsIGJlIHByZXNlbnRlZCBpbiA2 bWFuIGR1cmluZyBhIHNlc3Npb24gb24gdGhlIGVmZmljaWVuY3kgb2YgdGhlIE5EIHByb3RvY29s LCBidXQgSSBmZWVsIHRoYXQgaXQgcmVhbGx5IGJlbG9uZ3MgaW4gdjZvcHMsIGJlY2F1c2UgaXQg aGFzIG5vIHByb3RvY29sIGNoYW5nZXMuDQoNCk9mIGNvdXJzZSwgc2luY2UgaXQgd2FzIHBvc3Rl ZCBvbmx5IHNob3J0bHkgYmVmb3JlIDIzOjU5IFVUQywgaXQgZmFpbHMgdGhlICJoYXMgYmVlbiBk aXNjdXNzZWQgb24gdGhlIGxpc3QiIHRlc3QuIDotKQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgaWdub3JhbmNlIG9mIGhvdyB0byB1 c2UgbmV3IGtub3dsZWRnZSBzdG9ja3BpbGVzIGV4cG9uZW50aWFsbHkuDQogICAtIE1hcnNoYWxs IE1jTHVoYW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= --_000_CF2E19391268BEjohnbrzozowskicablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx OHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj5BZGRpbmcgdGhpcyB0byB0aGUgYWdlbmRhIG1ha2VzIHNlbnNlLiAmbmJzcDtXZSBoYXZl IHNlZW4gZXZpZGVuY2Ugb2YgaXNzdWVzIHJlbGF0ZWQgdG8gSVB2NiBtdWx0aWNhc3QsIHNwZWNp ZmljYWxseSBsaW5rIGxvY2FsLCBpbiBsYXJnZSBicm9hZGJhbmQgZGVwbG95bWVudHMgd2hlcmUg V2lGaSBpcyBhbmQgaXMgbm90IGluIHVzZS4gJm5ic3A7SW4gbW9zdCBjYXNlcyB0byBkYXRlIHRo ZXNlIGFwcGVhciB0byBiZSBpbXBsZW1lbnRhdGlvbiBpc3N1ZXMuDQogJm5ic3A7SXQgZG9lcyBu b3QgaHVydCB0byBkaXNjdXNzIGFkZGl0aW9uYWwgb3B0aW1pemF0aW9ucyBvciBjbGFyaWZpY2F0 aW9ucyB0byBoZWxwIGd1aWRlIGltcGxlbWVudGVycy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoaXMgZHJhZnQgYW5kIG90aGVyIHJlbGF0ZWQgd29yayBtdXN0IGNvbnNpZGVyIGhv dyBicm9hZGJhbmQgZGVwbG95bWVudHMgYXJlIGVuYWJsaW5nIElQdjYgaW4gY3VzdG9tZXIncyBw cmVtaXNlcy4gJm5ic3A7RGlzY291bnRpbmcgdGhpcyBvciBtYWtpbmcgYXNzdW1wdGlvbnMgYWJv dXQgaG93IElQdjYgc2hvdWxkIGRlcGxveWVkIGZyb20gYWNhZGVtaWMgcGVyc3BlY3RpdmUgd2ls bCBub3QgYmUgaGVscGZ1bCB0byBpbXBsZW1lbnRlcnMgb3INCiBmb3IgdGhlIG92ZXJhbGwgYWRv cHRpb24gb2YgSVB2Ni48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkpvaG48L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT08L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+Sm9obiBKYXNvbiBCcnpvem93c2tpPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTog bWVkaXVtOyAiPkNvbWNhc3QgQ2FibGU8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+bSkgNjA5LTM3Ny02NTk0PC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6 ZTogbWVkaXVtOyAiPm8pIDQ4NC05NjItMDA2MDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj53KSB3d3cuY29tY2Fz dDYubmV0PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7 IGZvbnQtc2l6ZTogbWVkaXVtOyAiPmUpJm5ic3A7PGEgaHJlZj0ibWFpbHRvOmpvaG5fYnJ6b3pv d3NraUBjYWJsZS5jb21jYXN0LmNvbSI+am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29t PC9hPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBm b250LXNpemU6IG1lZGl1bTsgIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsg Y29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVk aXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5H LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Gcm9tOiA8L3NwYW4+VGltIENob3duICZsdDs8YSBocmVmPSJtYWlsdG86dGpjQGVj cy5zb3Rvbi5hYy51ayI+dGpjQGVjcy5zb3Rvbi5hYy51azwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXksIEZlYnJ1YXJ5IDE3LCAy MDE0IDExOjI5IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+RnJlZCBCYWtlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZyZWRAY2lzY28uY29tIj5mcmVkQGNp c2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8 L3NwYW4+djZvcHMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 OiA8L3NwYW4+UmU6IFt2Nm9wc10gUHJvcG9zZWQgYWdlbmRhPGJyPg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NL UVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAw IDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7Ij4NCkhpLA0KPGRpdj48YnI+DQo8ZGl2Pg0KPGRpdj5PbiAxNiBGZWIg MjAxNCwgYXQgMDA6MzUsIEZyZWQgQmFrZXIgKGZyZWQpICZsdDs8YSBocmVmPSJtYWlsdG86ZnJl ZEBjaXNjby5jb20iPmZyZWRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkxldCBtZSBh c2sgZm9yIGNvbW1lbnQgb24gdGhlIGxpc3QuDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Gb2xr cywgd291bGQgeW91IGxpa2UgdG8gZGlzY3VzcyB0aGlzPyBJIGhhdmUgYSBoYWxmIGhvdXIgdG8g c3BhcmUgaW4gdGhlIHRpbWUgd2UgaGF2ZSBzdWdnZXN0ZWQuPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQpZZXMsIHRoaXMgaXMgYSB3b3J0aHdoaWxlIGRp c2N1c3Npb24gdG8gaGF2ZSwgYnJpZWZseS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlRpbTwvZGl2Pg0KPGRpdj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPg0KPGRpdj48YnI+DQo8ZGl2Pg0K PGRpdj5PbiBGZWIgMTQsIDIwMTQsIGF0IDc6MDUgUE0sIExvcmVuem8gQ29saXR0aSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbSI+bG9yZW56b0Bnb29nbGUuY29tPC9hPiZn dDs8L2Rpdj4NCjxkaXY+Jm5ic3A7d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRy Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P biBTYXQsIEZlYiAxNSwgMjAxNCBhdCAxMDo0NCBBTSwgRnJlZCBCYWtlciAoZnJlZCkgPHNwYW4g ZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkQGNpc2NvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmZyZWRAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTti b3JkZXItbGVmdC1zdHlsZTpzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClRoaXMgaXMgb2YgY291 cnNlIG9wZW4gdG8gY2hhbmdlOyB0aGF0J3Mgd2h5IGl0J3MgY2FsbGVkIGEgJnF1b3Q7cHJvcG9z ZWQgYWdlbmRhJnF1b3Q7LiBQbGVhc2UgcG9zdCB0byB0aGUgbGlzdC48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Xb3VsZCB0aGVyZSBiZSB0aW1lIHRvIGJyaWVm bHkgZGlzY3Vzczo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvdXJ0Y2hlbmtvLWNvbGl0dGktbmQtcmVkdWNl LW11bHRpY2FzdC0wMCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW91cnRjaGVu a28tY29saXR0aS1uZC1yZWR1Y2UtbXVsdGljYXN0LTAwPC9hPiA/Jm5ic3A7PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIHdpbGwgYmUgcHJlc2VudGVkIGluIDZtYW4gZHVyaW5n IGEgc2Vzc2lvbiBvbiB0aGUgZWZmaWNpZW5jeSBvZiB0aGUgTkQgcHJvdG9jb2wsIGJ1dCBJIGZl ZWwgdGhhdCBpdCByZWFsbHkgYmVsb25ncyBpbiB2Nm9wcywgYmVjYXVzZSBpdCBoYXMgbm8gcHJv dG9jb2wgY2hhbmdlcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9mIGNvdXJzZSwg c2luY2UgaXQgd2FzIHBvc3RlZCBvbmx5IHNob3J0bHkgYmVmb3JlIDIzOjU5IFVUQywgaXQgZmFp bHMgdGhlICZxdW90O2hhcyBiZWVuIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCZxdW90OyB0ZXN0LiA6 LSk8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogaW5oZXJpdDsgIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IGluaGVyaXQ7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJj b2xvcjogcmdiKDM0LCAzNCwgMzQpOyBsaW5lLWhlaWdodDogMTJweDsgZm9udC1zaXplOiBzbWFs bDsgZm9udC1mYW1pbHk6IGFyaWFsLCBzYW5zLXNlcmlmOyAiPlRoZSZuYnNwOzwvc3Bhbj48c3Bh biBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7 IGxpbmUtaGVpZ2h0OiAxMnB4OyBmb250LXNpemU6IHNtYWxsOyBmb250LWZhbWlseTogYXJpYWws IHNhbnMtc2VyaWY7ICI+PGVtIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7Ij5pZ25vcmFuY2U8 L2VtPjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImNvbG9yOiBy Z2IoMzQsIDM0LCAzNCk7IGxpbmUtaGVpZ2h0OiAxMnB4OyBmb250LXNpemU6IHNtYWxsOyBmb250 LWZhbWlseTogYXJpYWwsIHNhbnMtc2VyaWY7ICI+Jm5ic3A7b2YNCiBob3cgdG8mbmJzcDs8L3Nw YW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJjb2xvcjogcmdiKDM0LCAz NCwgMzQpOyBsaW5lLWhlaWdodDogMTJweDsgZm9udC1zaXplOiBzbWFsbDsgZm9udC1mYW1pbHk6 IGFyaWFsLCBzYW5zLXNlcmlmOyAiPjxlbSBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyI+dXNl IG5ldzwvZW0+PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iY29s b3I6IHJnYigzNCwgMzQsIDM0KTsgbGluZS1oZWlnaHQ6IDEycHg7IGZvbnQtc2l6ZTogc21hbGw7 IGZvbnQtZmFtaWx5OiBhcmlhbCwgc2Fucy1zZXJpZjsgIj4mbmJzcDtrbm93bGVkZ2UmbmJzcDs8 L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJjb2xvcjogcmdiKDM0 LCAzNCwgMzQpOyBsaW5lLWhlaWdodDogMTJweDsgZm9udC1zaXplOiBzbWFsbDsgZm9udC1mYW1p bHk6IGFyaWFsLCBzYW5zLXNlcmlmOyAiPjxlbSBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyI+ c3RvY2twaWxlcw0KIGV4cG9uZW50aWFsbHk8L2VtPjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgc3R5bGU9ImNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7IGxpbmUtaGVpZ2h0OiAx MnB4OyBmb250LXNpemU6IHNtYWxsOyBmb250LWZhbWlseTogYXJpYWwsIHNhbnMtc2VyaWY7ICI+ Ljwvc3Bhbj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogaW5oZXJpdDsgIj4mbmJzcDsmbmJzcDsgLSBNYXJzaGFsbCBNY0x1aGFuPC9k aXY+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CF2E19391268BEjohnbrzozowskicablecomcastcom_-- From nobody Sat Feb 22 06:43:20 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9F1A00FE for ; Sat, 22 Feb 2014 06:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 krArqjBcOn_K for ; Sat, 22 Feb 2014 06:43:15 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA21A00F9 for ; Sat, 22 Feb 2014 06:43:15 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.84183931; Sat, 22 Feb 2014 09:43:09 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.53]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 09:43:09 -0500 From: "Brzozowski, John" To: "Eric Vyncke (evyncke)" , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 and multicast Thread-Index: AQHPL9xn6zdtc1whnkayt02DLgQc8A== Date: Sat, 22 Feb 2014 14:43:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.248] Content-Type: multipart/alternative; boundary="_000_CF2E208E1268E9johnbrzozowskicablecomcastcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/9sDRIO9V_w4L8gO37hwSfC8bPSU Subject: Re: [v6ops] IPv6 and multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 14:43:17 -0000 --_000_CF2E208E1268E9johnbrzozowskicablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYyBhbmQgY29tcGFueSwNCg0KQXMgcGFydCBvZiB0aGlzIGRyYWZ0IGhhdmUgeW91IGNvbnNp ZGVyZWQgZG9jdW1lbnRpbmcgY2FzZXMgd2hlcmUgREhDUHY2IGlzIGluIHVzZT8gIFdoaWxlIHRo aXMgbWF5IG5vdCBtYXRlcmlhbGx5IGFsdGVyIHRoZSBzY29wZSBvZiB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQgdGhhdCBpcyBvdXRsaW5lZCBpdCBtYXkgaG93ZXZlciBvZmZlciBpbXBsZW1lbnRzIGEg bW9yZSBlZmZpY2llbnQgbmV0d29yayBldmVudCB0byB0cmlnZ2VyIHVwZGF0ZXMgZnJvbS4NCg0K QWxzbyB3aGVyZSB3b3VsZCBicm9hZGJhbmQgdGVjaG5vbG9naWVzIGZhbGwgd2l0aGluIHRoaXMg ZG9jdW1lbnQ/ICBXaXJlZCBldGhlcm5ldD8NCg0KRmluYWxseSwgaWYgdGhlIEwgYml0IGlzIHNl dCB0byAwIGZvciBvbiBsaW5rIHByZWZpeGVzIGl0IGlzIGNvbmNlaXZhYmxlIHRoYXQgdGhpcyBj b3VsZCBoZWxwIHRvIHJlZHVjZSBzb21lIGxpbmsgbG9jYWwgSVB2NiBtdWx0aWNhc3QgTkQgdHJh ZmZpYy4gIEhhcyB0aGlzIGJlZW4gY29uc2lkZXJlZD8NCg0KSm9obg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KQ29tY2Fz dCBDYWJsZQ0KbSkgNjA5LTM3Ny02NTk0DQpvKSA0ODQtOTYyLTAwNjANCncpIHd3dy5jb21jYXN0 Ni5uZXQNCmUpIGpvaG5fYnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbTxtYWlsdG86am9obl9i cnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCg0KRnJvbTogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPG1h aWx0bzpldnluY2tlQGNpc2NvLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAx NCAyOjEyIFBNDQpUbzogdjZvcHMgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBbdjZvcHNdIElQdjYgYW5kIG11bHRpY2FzdA0KDQpZb3UgbWF5IHdhbnQg dG8gZmluZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12eW5ja2UtNm1hbi1tY2Fz dC1ub3QtZWZmaWNpZW50LTAxIGludGVyZXN0aW5nIHRvIHVuZGVyc3RhbmQgc29tZSBjaGFsbGVu Z2VzIChhY3R1YWxseSB3cm9uZyBhc3N1bXB0aW9ucykgcG9zZWQgYnkgdGhlIHVzZSBvZiBsYXll ci0zIG11bHRpY2FzdCBieSBJUHY2IChtYWlubHkgZm9yIG5laWdoYm9yIGRpc2NvdmVyeSkgb3Zl ciBhIHdpcmVkL3dpcmVsc3MgaW5mcmFzdHJ1Y3R1cmUgd2hpY2ggaGFzIGxpdHRsZSBsaW5rIHdp dGggdGhlIGxheWVyLTMgbXVsdGljYXN0DQoNClRoaXMgSS1EIGNvdWxkIGJlIHRoZSBwcm9ibGVt IHN0YXRlbWVudCBmb3Igc29sdXRpb24gSS1EDQoNCkhvcGUgaXQgaGVscHMNCg0KLcOpcmljDQoN Cg== --_000_CF2E208E1268E9johnbrzozowskicablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0B947DE62312994DB437A9E567159A5D@cable.comcast.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx OHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj5FcmljIGFuZCBjb21wYW55LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXMg cGFydCBvZiB0aGlzIGRyYWZ0IGhhdmUgeW91IGNvbnNpZGVyZWQgZG9jdW1lbnRpbmcgY2FzZXMg d2hlcmUgREhDUHY2IGlzIGluIHVzZT8gJm5ic3A7V2hpbGUgdGhpcyBtYXkgbm90IG1hdGVyaWFs bHkgYWx0ZXIgdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB0aGF0IGlzIG91dGxp bmVkIGl0IG1heSBob3dldmVyIG9mZmVyIGltcGxlbWVudHMgYSBtb3JlIGVmZmljaWVudCBuZXR3 b3JrIGV2ZW50IHRvIHRyaWdnZXIgdXBkYXRlcw0KIGZyb20uICZuYnNwOzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+QWxzbyB3aGVyZSB3b3VsZCBicm9hZGJhbmQgdGVjaG5vbG9naWVz IGZhbGwgd2l0aGluIHRoaXMgZG9jdW1lbnQ/ICZuYnNwO1dpcmVkIGV0aGVybmV0PzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RmluYWxseSwgaWYgdGhlIEwgYml0IGlzIHNldCB0byAw IGZvciBvbiBsaW5rIHByZWZpeGVzIGl0IGlzIGNvbmNlaXZhYmxlIHRoYXQgdGhpcyBjb3VsZCBo ZWxwIHRvIHJlZHVjZSBzb21lIGxpbmsgbG9jYWwgSVB2NiBtdWx0aWNhc3QgTkQgdHJhZmZpYy4g Jm5ic3A7SGFzIHRoaXMgYmVlbiBjb25zaWRlcmVkPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Sm9objwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj5Kb2huIEphc29u IEJyem96b3dza2k8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+Q29tY2FzdCBDYWJsZTwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj5t KSA2MDktMzc3LTY1OTQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+bykgNDg0LTk2Mi0wMDYwPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTogbWVkaXVt OyAiPncpIHd3dy5jb21jYXN0Ni5uZXQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+ZSkmbmJzcDs8YSBocmVmPSJt YWlsdG86am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tIj5qb2huX2Jyem96b3dza2lA Y2FibGUuY29tY2FzdC5jb208L2E+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5FcmljIFZ5bmNrZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmV2eW5ja2VAY2lzY28uY29tIj5ldnluY2tlQGNpc2NvLmNvbTwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5 LCBGZWJydWFyeSAxOCwgMjAxNCAyOjEyIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlRvOiA8L3NwYW4+djZvcHMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9y ZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0OiA8L3NwYW4+W3Y2b3BzXSBJUHY2IGFuZCBtdWx0aWNhc3Q8YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklC VVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBB RERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5l LWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXpl OiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+WW91IG1h eSB3YW50IHRvIGZpbmQmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC12eW5ja2UtNm1hbi1tY2FzdC1ub3QtZWZmaWNpZW50LTAxIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC12eW5ja2UtNm1hbi1tY2FzdC1ub3QtZWZmaWNpZW50LTAxPC9hPiZu YnNwO2ludGVyZXN0aW5nIHRvIHVuZGVyc3RhbmQgc29tZSBjaGFsbGVuZ2VzIChhY3R1YWxseSB3 cm9uZyBhc3N1bXB0aW9ucykgcG9zZWQgYnkgdGhlDQogdXNlIG9mIGxheWVyLTMgbXVsdGljYXN0 IGJ5IElQdjYgKG1haW5seSBmb3IgbmVpZ2hib3IgZGlzY292ZXJ5KSBvdmVyIGEgd2lyZWQvd2ly ZWxzcyBpbmZyYXN0cnVjdHVyZSB3aGljaCBoYXMgbGl0dGxlIGxpbmsgd2l0aCB0aGUgbGF5ZXIt MyBtdWx0aWNhc3Q8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgSS1EIGNvdWxk IGJlIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3Igc29sdXRpb24gSS1EPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5Ib3BlIGl0IGhlbHBzPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4tw6lyaWM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CF2E208E1268E9johnbrzozowskicablecomcastcom_-- From nobody Sat Feb 22 07:05:50 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D191A0107 for ; Sat, 22 Feb 2014 07:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 ZHimQdzLHrRj for ; Sat, 22 Feb 2014 07:05:44 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 153A21A0102 for ; Sat, 22 Feb 2014 07:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8884; q=dns/txt; s=iport; t=1393081540; x=1394291140; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pRmIQLt4ajMqA9O34QpMmfFHa0T2ymcEp1r1M/Gp7pQ=; b=Zb+yI9BMJdg2XDSwJjnUGFiDsixwrlT9Ym8hyyHHbElz/VQZKy7PXGMa o23QoI31f85oX1+16I/28ZPIi/irGI6Eo5HZVB3TO7ozcYw8awvg8OjfR Auw8ROWNwCwAxTIE6InUiNrKsqCWtakDO3tC3oc2Ky1EWnfD+7PCI4Ec7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAPS7CFOtJV2c/2dsb2JhbABXA4JCRDtXt3OIVoEKFnSCJQEBAQRJQAIBCBEDAQIoBzIUCQgCBAESG4dqDclTF44QQwEXEYQnBIkQjySBMpB1gy2CKg X-IronPort-AV: E=Sophos;i="4.97,523,1389744000"; d="scan'208,217";a="305851936" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 22 Feb 2014 15:05:39 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1MF5dPi011183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Feb 2014 15:05:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Sat, 22 Feb 2014 09:05:39 -0600 From: "Eric Vyncke (evyncke)" To: "Brzozowski, John" , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 and multicast Thread-Index: AQHPL9xn6zdtc1whnkayt02DLgQc8JrB1LYA Date: Sat, 22 Feb 2014 15:05:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.55.185.70] Content-Type: multipart/alternative; boundary="_000_CF2E7AD5E991evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Nil1stYTTwHUOroSusQGKakVnrI Subject: Re: [v6ops] IPv6 and multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 15:05:47 -0000 --_000_CF2E7AD5E991evynckeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, This was mainly a first draft about problem statement. And, indeed your spe= cific settings are one way to reduce the impact and AFAIK they are parts of= Andrew Y. & Lorenzo C.'s I-D. The draft is also mainly about wireless where the 'mcast' inefficiencies ar= e most important. Wired Ethernet is partly mentioned in the I-D. Good idea about DHCP even if I wonder whether it would change anything exce= pt making it worse by adding yet another mcast packet. Let's talk in London And thanks for your comment :-) -=E9ric From: , John > Date: samedi 22 f=E9vrier 2014 15:43 To: Eric Vyncke >, "v6ops@ietf.= org" > Subject: Re: [v6ops] IPv6 and multicast Eric and company, As part of this draft have you considered documenting cases where DHCPv6 is= in use? While this may not materially alter the scope of the problem stat= ement that is outlined it may however offer implements a more efficient net= work event to trigger updates from. Also where would broadband technologies fall within this document? Wired e= thernet? Finally, if the L bit is set to 0 for on link prefixes it is conceivable th= at this could help to reduce some link local IPv6 multicast ND traffic. Ha= s this been considered? John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 609-377-6594 o) 484-962-0060 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Eric Vyncke > Date: Tuesday, February 18, 2014 2:12 PM To: v6ops > Subject: [v6ops] IPv6 and multicast You may want to find http://tools.ietf.org/html/draft-vyncke-6man-mcast-not= -efficient-01 interesting to understand some challenges (actually wrong ass= umptions) posed by the use of layer-3 multicast by IPv6 (mainly for neighbo= r discovery) over a wired/wirelss infrastructure which has little link with= the layer-3 multicast This I-D could be the problem statement for solution I-D Hope it helps -=E9ric --_000_CF2E7AD5E991evynckeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
John,

This was mainly a first draft about problem statement. And, indeed you= r specific settings are one way to reduce the impact and AFAIK they are par= ts of Andrew Y. & Lorenzo C.'s I-D.

The draft is also mainly about wireless where the 'mcast' inefficienci= es are most important. Wired Ethernet is partly mentioned in the I-D.

Good idea about DHCP even if I wonder whether it would change anything= except making it worse by adding yet another mcast packet. Let's talk in L= ondon

And thanks for your comment :-)

-=E9ric

From: <Brzozowski>, John <= John_Brzozowski@Cable.= Comcast.com>
Date: samedi 22 f=E9vrier 2014 15:4= 3
To: Eric Vyncke <evyncke@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] IPv6 and multi= cast

Eric and company,

As part of this draft have you considered documenting cases where DHCP= v6 is in use?  While this may not materially alter the scope of the pr= oblem statement that is outlined it may however offer implements a more eff= icient network event to trigger updates from.  

Also where would broadband technologies fall within this document? &nb= sp;Wired ethernet?

Finally, if the L bit is set to 0 for on link prefixes it is conceivab= le that this could help to reduce some link local IPv6 multicast ND traffic= .  Has this been considered?

John
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jas= on Brzozowski
Comcast = Cable
m) 609-3= 77-6594
o) 484-9= 62-0060
w) www.c= omcast6.net
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Eric Vyncke <evyncke@cisco.com>
Date: Tuesday, February 18, 2014 2:= 12 PM
To: v6ops <v6ops@ietf.org>
Subject: [v6ops] IPv6 and multicast=

You may want to find http://tools.ietf.org/html/draft-vyncke= -6man-mcast-not-efficient-01 interesting to understand some challe= nges (actually wrong assumptions) posed by the use of layer-3 multicast by IPv6 (mainly for neighbor discovery) over a wi= red/wirelss infrastructure which has little link with the layer-3 multicast=

This I-D could be the problem statement for solution I-D

Hope it helps

-=E9ric

 --_000_CF2E7AD5E991evynckeciscocom_-- From nobody Sat Feb 22 07:12:18 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709E31A0102 for ; Sat, 22 Feb 2014 07:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 zspFbEg85Paa for ; Sat, 22 Feb 2014 07:12:13 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id DA78D1A00ED for ; Sat, 22 Feb 2014 07:12:12 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.84185194; Sat, 22 Feb 2014 10:12:04 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.53]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 10:12:05 -0500 From: "Brzozowski, John" To: "Eric Vyncke (evyncke)" , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 and multicast Thread-Index: AQHPL9xn6zdtc1whnkayt02DLgQc8JrB1LYA//+McoA= Date: Sat, 22 Feb 2014 15:12:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.248] Content-Type: multipart/alternative; boundary="_000_CF2E280F12691Djohnbrzozowskicablecomcastcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/PNOrQChhgelRMqB6B4qnSi5f1DE Subject: Re: [v6ops] IPv6 and multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 15:12:15 -0000 --_000_CF2E280F12691Djohnbrzozowskicablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdG8gbWUgdGhlcmUgY291bGQgYmUgc29tZSBzeW5lcmdpZXMgd2l0aCB5b3VyIHdv cmsgYW5kIHRoZSBvdGhlciBkcmFmdCBmcm9tIEFuZHJldyBhbmQgTG9yZW56byBwZXJoYXBzIHdl IGFsbCBzaG91bGQgaGF2ZSBhIGRpc2N1c3Npb24uDQoNCjxjb21jYXN0IGhhdCBvbj4gV2UgaGF2 ZSBzZWVuIGFuZCBkZWFsdCB3aXRoIGEgbG90IG9mIHRoaXMgb3ZlciB0aGUgeWVhcnMsIHdlIHdv dWxkIGJlIGhhcHB5IHRvIGRpc2N1c3MgYW5kIGNvbnRyaWJ1dGUgaWYgdGhlcmUgaXMgaW50ZXJl c3QuDQoNCkpvaG4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpK b2huIEphc29uIEJyem96b3dza2kNCkNvbWNhc3QgQ2FibGUNCm0pIDYwOS0zNzctNjU5NA0Kbykg NDg0LTk2Mi0wMDYwDQp3KSB3d3cuY29tY2FzdDYubmV0DQplKSBqb2huX2Jyem96b3dza2lAY2Fi bGUuY29tY2FzdC5jb208bWFpbHRvOmpvaG5fYnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbT4N Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkZyb206IEVyaWMg VnluY2tlIDxldnluY2tlQGNpc2NvLmNvbTxtYWlsdG86ZXZ5bmNrZUBjaXNjby5jb20+Pg0KRGF0 ZTogU2F0dXJkYXksIEZlYnJ1YXJ5IDIyLCAyMDE0IDEwOjA1IEFNDQpUbzogSm9obiBCcnpvem93 c2tpIDxKb2huX0Jyem96b3dza2lAQ2FibGUuQ29tY2FzdC5jb208bWFpbHRvOkpvaG5fQnJ6b3pv d3NraUBDYWJsZS5Db21jYXN0LmNvbT4+LCB2Nm9wcyA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2 b3BzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgYW5kIG11bHRpY2FzdA0K DQpKb2huLA0KDQpUaGlzIHdhcyBtYWlubHkgYSBmaXJzdCBkcmFmdCBhYm91dCBwcm9ibGVtIHN0 YXRlbWVudC4gQW5kLCBpbmRlZWQgeW91ciBzcGVjaWZpYyBzZXR0aW5ncyBhcmUgb25lIHdheSB0 byByZWR1Y2UgdGhlIGltcGFjdCBhbmQgQUZBSUsgdGhleSBhcmUgcGFydHMgb2YgQW5kcmV3IFku ICYgTG9yZW56byBDLidzIEktRC4NCg0KVGhlIGRyYWZ0IGlzIGFsc28gbWFpbmx5IGFib3V0IHdp cmVsZXNzIHdoZXJlIHRoZSAnbWNhc3QnIGluZWZmaWNpZW5jaWVzIGFyZSBtb3N0IGltcG9ydGFu dC4gV2lyZWQgRXRoZXJuZXQgaXMgcGFydGx5IG1lbnRpb25lZCBpbiB0aGUgSS1ELg0KDQpHb29k IGlkZWEgYWJvdXQgREhDUCBldmVuIGlmIEkgd29uZGVyIHdoZXRoZXIgaXQgd291bGQgY2hhbmdl IGFueXRoaW5nIGV4Y2VwdCBtYWtpbmcgaXQgd29yc2UgYnkgYWRkaW5nIHlldCBhbm90aGVyIG1j YXN0IHBhY2tldC4gTGV0J3MgdGFsayBpbiBMb25kb24NCg0KQW5kIHRoYW5rcyBmb3IgeW91ciBj b21tZW50IDotKQ0KDQotw6lyaWMNCg0KRnJvbTogPEJyem96b3dza2k+LCBKb2huIDxKb2huX0Jy em96b3dza2lAQ2FibGUuQ29tY2FzdC5jb208bWFpbHRvOkpvaG5fQnJ6b3pvd3NraUBDYWJsZS5D b21jYXN0LmNvbT4+DQpEYXRlOiBzYW1lZGkgMjIgZsOpdnJpZXIgMjAxNCAxNTo0Mw0KVG86IEVy aWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbTxtYWlsdG86ZXZ5bmNrZUBjaXNjby5jb20+Piwg InY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4iIDx2Nm9wc0BpZXRmLm9yZzxt YWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gSVB2NiBhbmQgbXVs dGljYXN0DQoNCkVyaWMgYW5kIGNvbXBhbnksDQoNCkFzIHBhcnQgb2YgdGhpcyBkcmFmdCBoYXZl IHlvdSBjb25zaWRlcmVkIGRvY3VtZW50aW5nIGNhc2VzIHdoZXJlIERIQ1B2NiBpcyBpbiB1c2U/ ICBXaGlsZSB0aGlzIG1heSBub3QgbWF0ZXJpYWxseSBhbHRlciB0aGUgc2NvcGUgb2YgdGhlIHBy b2JsZW0gc3RhdGVtZW50IHRoYXQgaXMgb3V0bGluZWQgaXQgbWF5IGhvd2V2ZXIgb2ZmZXIgaW1w bGVtZW50cyBhIG1vcmUgZWZmaWNpZW50IG5ldHdvcmsgZXZlbnQgdG8gdHJpZ2dlciB1cGRhdGVz IGZyb20uDQoNCkFsc28gd2hlcmUgd291bGQgYnJvYWRiYW5kIHRlY2hub2xvZ2llcyBmYWxsIHdp dGhpbiB0aGlzIGRvY3VtZW50PyAgV2lyZWQgZXRoZXJuZXQ/DQoNCkZpbmFsbHksIGlmIHRoZSBM IGJpdCBpcyBzZXQgdG8gMCBmb3Igb24gbGluayBwcmVmaXhlcyBpdCBpcyBjb25jZWl2YWJsZSB0 aGF0IHRoaXMgY291bGQgaGVscCB0byByZWR1Y2Ugc29tZSBsaW5rIGxvY2FsIElQdjYgbXVsdGlj YXN0IE5EIHRyYWZmaWMuICBIYXMgdGhpcyBiZWVuIGNvbnNpZGVyZWQ/DQoNCkpvaG4NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpKb2huIEphc29uIEJyem96b3dz a2kNCkNvbWNhc3QgQ2FibGUNCm0pIDYwOS0zNzctNjU5NA0KbykgNDg0LTk2Mi0wMDYwDQp3KSB3 d3cuY29tY2FzdDYubmV0DQplKSBqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb208bWFp bHRvOmpvaG5fYnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbT4NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkZyb206IEVyaWMgVnluY2tlIDxldnluY2tlQGNp c2NvLmNvbTxtYWlsdG86ZXZ5bmNrZUBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgRmVicnVh cnkgMTgsIDIwMTQgMjoxMiBQTQ0KVG86IHY2b3BzIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZv cHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3Y2b3BzXSBJUHY2IGFuZCBtdWx0aWNhc3QNCg0KWW91 IG1heSB3YW50IHRvIGZpbmQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdnluY2tl LTZtYW4tbWNhc3Qtbm90LWVmZmljaWVudC0wMSBpbnRlcmVzdGluZyB0byB1bmRlcnN0YW5kIHNv bWUgY2hhbGxlbmdlcyAoYWN0dWFsbHkgd3JvbmcgYXNzdW1wdGlvbnMpIHBvc2VkIGJ5IHRoZSB1 c2Ugb2YgbGF5ZXItMyBtdWx0aWNhc3QgYnkgSVB2NiAobWFpbmx5IGZvciBuZWlnaGJvciBkaXNj b3ZlcnkpIG92ZXIgYSB3aXJlZC93aXJlbHNzIGluZnJhc3RydWN0dXJlIHdoaWNoIGhhcyBsaXR0 bGUgbGluayB3aXRoIHRoZSBsYXllci0zIG11bHRpY2FzdA0KDQpUaGlzIEktRCBjb3VsZCBiZSB0 aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZm9yIHNvbHV0aW9uIEktRA0KDQpIb3BlIGl0IGhlbHBzDQoN Ci3DqXJpYw0KDQo= --_000_CF2E280F12691Djohnbrzozowskicablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5FFED129AF5DFC42B6138A7AA557D14B@cable.comcast.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx OHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj5JdCBzZWVtcyB0byBtZSB0aGVyZSBjb3VsZCBiZSBzb21lIHN5bmVyZ2llcyB3aXRoIHlv dXIgd29yayBhbmQgdGhlIG90aGVyIGRyYWZ0IGZyb20gQW5kcmV3IGFuZCBMb3JlbnpvIHBlcmhh cHMgd2UgYWxsIHNob3VsZCBoYXZlIGEgZGlzY3Vzc2lvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PiZsdDtjb21jYXN0IGhhdCBvbiZndDsgV2UgaGF2ZSBzZWVuIGFuZCBkZWFsdCB3 aXRoIGEgbG90IG9mIHRoaXMgb3ZlciB0aGUgeWVhcnMsIHdlIHdvdWxkIGJlIGhhcHB5IHRvIGRp c2N1c3MgYW5kIGNvbnRyaWJ1dGUgaWYgdGhlcmUgaXMgaW50ZXJlc3QuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5Kb2huPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTogbWVkaXVtOyAi Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTogbWVkaXVtOyAi PkpvaG4gSmFzb24gQnJ6b3pvd3NraTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj5Db21jYXN0IENhYmxlPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTog bWVkaXVtOyAiPm0pIDYwOS0zNzctNjU5NDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj5vKSA0ODQtOTYyLTAwNjA8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgZm9udC1z aXplOiBtZWRpdW07ICI+dykgd3d3LmNvbWNhc3Q2Lm5ldDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj5lKSZuYnNw OzxhIGhyZWY9Im1haWx0bzpqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20iPmpvaG5f YnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbTwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQt c2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBt ZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGlu OyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVj NGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkVyaWMgVnlu Y2tlICZsdDs8YSBocmVmPSJtYWlsdG86ZXZ5bmNrZUBjaXNjby5jb20iPmV2eW5ja2VAY2lzY28u Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9z cGFuPlNhdHVyZGF5LCBGZWJydWFyeSAyMiwgMjAxNCAxMDowNSBBTTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkpvaG4gQnJ6b3pvd3NraSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkpvaG5fQnJ6b3pvd3NraUBDYWJsZS5Db21jYXN0LmNvbSI+Sm9obl9Ccnpvem93 c2tpQENhYmxlLkNvbWNhc3QuY29tPC9hPiZndDssIHY2b3BzICZsdDs8YSBocmVmPSJtYWlsdG86 djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbdjZvcHNdIElQdjYgYW5kIG11 bHRpY2FzdDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyAiPg0KPGRpdj5Kb2huLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyB3YXMg bWFpbmx5IGEgZmlyc3QgZHJhZnQgYWJvdXQgcHJvYmxlbSBzdGF0ZW1lbnQuIEFuZCwgaW5kZWVk IHlvdXIgc3BlY2lmaWMgc2V0dGluZ3MgYXJlIG9uZSB3YXkgdG8gcmVkdWNlIHRoZSBpbXBhY3Qg YW5kIEFGQUlLIHRoZXkgYXJlIHBhcnRzIG9mIEFuZHJldyBZLiAmYW1wOyBMb3JlbnpvIEMuJ3Mg SS1ELjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGRyYWZ0IGlzIGFsc28gbWFp bmx5IGFib3V0IHdpcmVsZXNzIHdoZXJlIHRoZSAnbWNhc3QnIGluZWZmaWNpZW5jaWVzIGFyZSBt b3N0IGltcG9ydGFudC4gV2lyZWQgRXRoZXJuZXQgaXMgcGFydGx5IG1lbnRpb25lZCBpbiB0aGUg SS1ELjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+R29vZCBpZGVhIGFib3V0IERIQ1Ag ZXZlbiBpZiBJIHdvbmRlciB3aGV0aGVyIGl0IHdvdWxkIGNoYW5nZSBhbnl0aGluZyBleGNlcHQg bWFraW5nIGl0IHdvcnNlIGJ5IGFkZGluZyB5ZXQgYW5vdGhlciBtY2FzdCBwYWNrZXQuIExldCdz IHRhbGsgaW4gTG9uZG9uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbmQgdGhhbmtz IGZvciB5b3VyIGNvbW1lbnQgOi0pPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tw6ly aWM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Jmx0O0Jyem96b3dza2kmZ3Q7LCBK b2huICZsdDs8YSBocmVmPSJtYWlsdG86Sm9obl9Ccnpvem93c2tpQENhYmxlLkNvbWNhc3QuY29t Ij5Kb2huX0Jyem96b3dza2lAQ2FibGUuQ29tY2FzdC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+c2FtZWRpIDIyIGbDqXZyaWVyIDIw MTQgMTU6NDM8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5F cmljIFZ5bmNrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2eW5ja2VAY2lzY28uY29tIj5ldnluY2tl QGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmci PnY2b3BzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYu b3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3Y2b3BzXSBJUHY2IGFuZCBtdWx0aWNhc3Q8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tf QVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29s aWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1zaXplOiAxOHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj5FcmljIGFuZCBjb21wYW55LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+QXMgcGFydCBvZiB0aGlzIGRyYWZ0IGhhdmUgeW91IGNvbnNpZGVyZWQgZG9jdW1lbnRp bmcgY2FzZXMgd2hlcmUgREhDUHY2IGlzIGluIHVzZT8gJm5ic3A7V2hpbGUgdGhpcyBtYXkgbm90 IG1hdGVyaWFsbHkgYWx0ZXIgdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB0aGF0 IGlzIG91dGxpbmVkIGl0IG1heSBob3dldmVyIG9mZmVyIGltcGxlbWVudHMgYSBtb3JlIGVmZmlj aWVudCBuZXR3b3JrIGV2ZW50IHRvIHRyaWdnZXIgdXBkYXRlcw0KIGZyb20uICZuYnNwOzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWxzbyB3aGVyZSB3b3VsZCBicm9hZGJhbmQgdGVj aG5vbG9naWVzIGZhbGwgd2l0aGluIHRoaXMgZG9jdW1lbnQ/ICZuYnNwO1dpcmVkIGV0aGVybmV0 PzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RmluYWxseSwgaWYgdGhlIEwgYml0IGlz IHNldCB0byAwIGZvciBvbiBsaW5rIHByZWZpeGVzIGl0IGlzIGNvbmNlaXZhYmxlIHRoYXQgdGhp cyBjb3VsZCBoZWxwIHRvIHJlZHVjZSBzb21lIGxpbmsgbG9jYWwgSVB2NiBtdWx0aWNhc3QgTkQg dHJhZmZpYy4gJm5ic3A7SGFzIHRoaXMgYmVlbiBjb25zaWRlcmVkPzwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+Sm9objwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1lZGl1bTsgIj5K b2huIEphc29uIEJyem96b3dza2k8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+Q29tY2FzdCBDYWJsZTwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemU6IG1l ZGl1bTsgIj5tKSA2MDktMzc3LTY1OTQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+bykgNDg0LTk2Mi0wMDYwPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6 ZTogbWVkaXVtOyAiPncpIHd3dy5jb21jYXN0Ni5uZXQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplOiBtZWRpdW07ICI+ZSkmbmJzcDs8 YSBocmVmPSJtYWlsdG86am9obl9icnpvem93c2tpQGNhYmxlLmNvbWNhc3QuY29tIj5qb2huX2Jy em96b3dza2lAY2FibGUuY29tY2FzdC5jb208L2E+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5FcmljIFZ5bmNr ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2eW5ja2VAY2lzY28uY29tIj5ldnluY2tlQGNpc2NvLmNv bTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bh bj5UdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNCAyOjEyIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+djZvcHMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9w c0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W3Y2b3BzXSBJUHY2IGFuZCBtdWx0aWNhc3Q8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdl YmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxk aXY+WW91IG1heSB3YW50IHRvIGZpbmQmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC12eW5ja2UtNm1hbi1tY2FzdC1ub3QtZWZmaWNpZW50LTAxIj5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC12eW5ja2UtNm1hbi1tY2FzdC1ub3QtZWZmaWNpZW50 LTAxPC9hPiZuYnNwO2ludGVyZXN0aW5nIHRvIHVuZGVyc3RhbmQgc29tZSBjaGFsbGVuZ2VzIChh Y3R1YWxseSB3cm9uZyBhc3N1bXB0aW9ucykgcG9zZWQgYnkgdGhlDQogdXNlIG9mIGxheWVyLTMg bXVsdGljYXN0IGJ5IElQdjYgKG1haW5seSBmb3IgbmVpZ2hib3IgZGlzY292ZXJ5KSBvdmVyIGEg d2lyZWQvd2lyZWxzcyBpbmZyYXN0cnVjdHVyZSB3aGljaCBoYXMgbGl0dGxlIGxpbmsgd2l0aCB0 aGUgbGF5ZXItMyBtdWx0aWNhc3Q8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMg SS1EIGNvdWxkIGJlIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3Igc29sdXRpb24gSS1EPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ib3BlIGl0IGhlbHBzPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4tw6lyaWM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_CF2E280F12691Djohnbrzozowskicablecomcastcom_-- From nobody Sat Feb 22 07:33:17 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A60A1A0108 for ; Sat, 22 Feb 2014 07:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 zdAABUgOGRLH for ; Sat, 22 Feb 2014 07:33:13 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9E48E1A00FB for ; Sat, 22 Feb 2014 07:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14958; q=dns/txt; s=iport; t=1393083189; x=1394292789; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=j+5lG16aKc/9GJNj09hsY0I5788bwv52wOPJ5+fIObU=; b=lGEcJv4e53qOLF99ZbRC77taccdGNTYdQr8WnfkTGyUaxEcUj0ortxBV TBoxVRuPKWVJNZEHYe4J+/jNyJQz26gM57QqQJztQiN2aNfNXhdYZ3oPI X1oXM6Taq+XzoddLfBQQuyxddunNxwO0v0vPmgcVuAUiZK+hnzE2oSThq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAPrBCFOtJXG8/2dsb2JhbABXA4JCRDtXt3OIVoEKFnSCJQEBAQRJQAIBCBEDAQIoBzIUCQgCBAESG4dqDclaF44QQwEXEYQnBJg0gTKQdYMtgio X-IronPort-AV: E=Sophos; i="4.97,523,1389744000"; d="scan'208,217"; a="22419272" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 22 Feb 2014 15:33:07 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1MFX7Cm004712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Feb 2014 15:33:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Sat, 22 Feb 2014 09:33:06 -0600 From: "Eric Vyncke (evyncke)" To: "Brzozowski, John" , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 and multicast Thread-Index: AQHPL9xn6zdtc1whnkayt02DLgQc8JrB1LYA//+McoCAAHs4AA== Date: Sat, 22 Feb 2014 15:33:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.55.185.70] Content-Type: multipart/alternative; boundary="_000_CF2E8181E9B1evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/hzFbf4Eh9IE55kvkxCK0xq1JtsM Subject: Re: [v6ops] IPv6 and multicast X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 15:33:16 -0000 --_000_CF2E8181E9B1evynckeciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable John The more, the merrier of course :-) The synergies are as usual: problem statement then 1 or more solution propo= sals. There should be a clear demarcation but also a lever effect (same voc= abulary, =85) -=E9ric From: , John > Date: samedi 22 f=E9vrier 2014 16:12 To: Eric Vyncke >, "v6ops@ietf.= org" > Subject: Re: [v6ops] IPv6 and multicast It seems to me there could be some synergies with your work and the other d= raft from Andrew and Lorenzo perhaps we all should have a discussion. We have seen and dealt with a lot of this over the years, = we would be happy to discuss and contribute if there is interest. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 609-377-6594 o) 484-962-0060 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Eric Vyncke > Date: Saturday, February 22, 2014 10:05 AM To: John Brzozowski >, v6ops > Subject: Re: [v6ops] IPv6 and multicast John, This was mainly a first draft about problem statement. And, indeed your spe= cific settings are one way to reduce the impact and AFAIK they are parts of= Andrew Y. & Lorenzo C.'s I-D. The draft is also mainly about wireless where the 'mcast' inefficiencies ar= e most important. Wired Ethernet is partly mentioned in the I-D. Good idea about DHCP even if I wonder whether it would change anything exce= pt making it worse by adding yet another mcast packet. Let's talk in London And thanks for your comment :-) -=E9ric From: , John > Date: samedi 22 f=E9vrier 2014 15:43 To: Eric Vyncke >, "v6ops@ietf.= org" > Subject: Re: [v6ops] IPv6 and multicast Eric and company, As part of this draft have you considered documenting cases where DHCPv6 is= in use? While this may not materially alter the scope of the problem stat= ement that is outlined it may however offer implements a more efficient net= work event to trigger updates from. Also where would broadband technologies fall within this document? Wired e= thernet? Finally, if the L bit is set to 0 for on link prefixes it is conceivable th= at this could help to reduce some link local IPv6 multicast ND traffic. Ha= s this been considered? John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 609-377-6594 o) 484-962-0060 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Eric Vyncke > Date: Tuesday, February 18, 2014 2:12 PM To: v6ops > Subject: [v6ops] IPv6 and multicast You may want to find http://tools.ietf.org/html/draft-vyncke-6man-mcast-not= -efficient-01 interesting to understand some challenges (actually wrong ass= umptions) posed by the use of layer-3 multicast by IPv6 (mainly for neighbo= r discovery) over a wired/wirelss infrastructure which has little link with= the layer-3 multicast This I-D could be the problem statement for solution I-D Hope it helps -=E9ric --_000_CF2E8181E9B1evynckeciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
John

The more, the merrier of course :-)

The synergies are as usual: problem statement then 1 or more solution = proposals. There should be a clear demarcation but also a lever effect (sam= e vocabulary, =85)

-=E9ric

From: <Brzozowski>, John <= John_Brzozowski@Cable.= Comcast.com>
Date: samedi 22 f=E9vrier 2014 16:1= 2
To: Eric Vyncke <evyncke@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] IPv6 and multi= cast

It seems to me there could be some synergies with your work and the ot= her draft from Andrew and Lorenzo perhaps we all should have a discussion.<= /div>

<comcast hat on> We have seen and dealt with a lot of this over = the years, we would be happy to discuss and contribute if there is interest= .

John
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jas= on Brzozowski
Comcast = Cable
m) 609-3= 77-6594
o) 484-9= 62-0060
w) www.c= omcast6.net
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Eric Vyncke <evyncke@cisco.com>
Date: Saturday, February 22, 2014 1= 0:05 AM
To: John Brzozowski <John_Brzozowski@Cable.Comcast.com= >, v6ops <v6ops@ietf.org>= ;
Subject: Re: [v6ops] IPv6 and multi= cast

John,

This was mainly a first draft about problem statement. And, indeed you= r specific settings are one way to reduce the impact and AFAIK they are par= ts of Andrew Y. & Lorenzo C.'s I-D.

The draft is also mainly about wireless where the 'mcast' inefficienci= es are most important. Wired Ethernet is partly mentioned in the I-D.

Good idea about DHCP even if I wonder whether it would change anything= except making it worse by adding yet another mcast packet. Let's talk in L= ondon

And thanks for your comment :-)

-=E9ric

From: <Brzozowski>, John <= John_Brzozowski@Cable.= Comcast.com>
Date: samedi 22 f=E9vrier 2014 15:4= 3
To: Eric Vyncke <evyncke@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] IPv6 and multi= cast

Eric and company,

As part of this draft have you considered documenting cases where DHCP= v6 is in use?  While this may not materially alter the scope of the pr= oblem statement that is outlined it may however offer implements a more eff= icient network event to trigger updates from.  

Also where would broadband technologies fall within this document? &nb= sp;Wired ethernet?

Finally, if the L bit is set to 0 for on link prefixes it is conceivab= le that this could help to reduce some link local IPv6 multicast ND traffic= .  Has this been considered?

John
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jas= on Brzozowski
Comcast = Cable
m) 609-3= 77-6594
o) 484-9= 62-0060
w) www.c= omcast6.net
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Eric Vyncke <evyncke@cisco.com>
Date: Tuesday, February 18, 2014 2:= 12 PM
To: v6ops <v6ops@ietf.org>
Subject: [v6ops] IPv6 and multicast=

You may want to find http://tools.ietf.org/html/draft-vyncke= -6man-mcast-not-efficient-01 interesting to understand some challe= nges (actually wrong assumptions) posed by the use of layer-3 multicast by IPv6 (mainly for neighbor discovery) over a wi= red/wirelss infrastructure which has little link with the layer-3 multicast=

This I-D could be the problem statement for solution I-D

Hope it helps

-=E9ric

 --_000_CF2E8181E9B1evynckeciscocom_-- From nobody Sat Feb 22 10:03:47 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4981A014F for ; Sat, 22 Feb 2014 10:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 oARjnEXgeY4l for ; Sat, 22 Feb 2014 10:03:44 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0D91A014E for ; Sat, 22 Feb 2014 10:03:44 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.118265629; Sat, 22 Feb 2014 11:03:36 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.53]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 13:03:36 -0500 From: "Brzozowski, John" To: Andrew Yourtchenko , "v6ops@ietf.org" Thread-Topic: [v6ops] Reducing Multicast in IPv6 Neighbor Discovery Thread-Index: AQHPL/hn8iPvA+aapkqMq1bssDZArQ== Date: Sat, 22 Feb 2014 18:03:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/lW6cbkwGQvAa-3jQ5PmlBuZeuQI Subject: Re: [v6ops] Reducing Multicast in IPv6 Neighbor Discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Feb 2014 18:03:46 -0000 QW5kcmV3LA0KDQpXYW50ZWQgdG8gb2ZmZXIgc29tZSBjb21tZW50cyBvbiB0aGUgZHJhZnQuICBT b21lIG9mIHRoaXMgbWF5IGJlIGEgcmVwZWF0DQpvZiB0ZXh0IEkgcmVjZW50bHkgc2VuZCB0byBF cmljIFZ5bmNrZSBpbiByZXNwb25zZSB0byBoaXMgZHJhZnQuICBXZSBoYXZlDQpzZWVuIHJlY2Vu dGx5IHRoYXQgZmxhd2VkIGltcGxlbWVudGF0aW9ucyBlaXRoZXIgZG8gbm90IGZpbHRlciBvcg0K aW5jb3JyZWN0bHkgdHJpZ2dlciB0aGUgdXNlIG9mIHNvbGljaXRlZCBub2RlIG11bHRpY2FzdCBv ciBVbmljYXN0DQpTb2xpY2l0ZWQgUm91dGVyIEFkdmVydGlzZW1lbnRzIHdoaWNoIGluIHR1cm4g cmVzdWx0IGluIGVpdGhlciBwb29yDQpiYXR0ZXJ5IHBlcmZvcm1hbmNlIGFuZCBvciBoaWdoIENQ VSB1dGlsaXphdGlvbiB3aGljaCBpbiB0dXJuIGFsc28gaW1wYWN0cw0KdGhlIG92ZXJhbGwgcGVy Zm9ybWFuY2Ugb2YgdGhlIGRldmljZS4gIFJGQ3MgdGhhdCBvdXRsaW5lIHRoZSBwcm9wZXINCmFw cHJvYWNoIGZvciBwcm9jZXNzaW5nIGFuZCBoYW5kbGluZyBORCBhbmQgUkQgbWVzc2FnZXMgYXJl IGF2YWlsYWJsZSBhbmQNCmdlbmVyYWxseSB3aGVuIGZvbGxvd2VkIGhhdmUgYSB2ZXJ5IHBvc2l0 aXZlIGltcGFjdCBvbiBwZXJmb3JtYW5jZS4gIFRoaXMNCmlzIHNwZWNpZmljIHRvIG5vbiBtb2Jp bGUgZGV2aWNlcyB3aGVyZSBiYXR0ZXJ5IGxpZmUgaXMgbGVzcyBvZiBhIGNvbmNlcm4uDQogSSBi ZWxpZXZlIHRoZXJlIGlzIGFuIG9wcG9ydHVuaXR5IHRvIHR1bmUgdGhlIG5ldHdvcmsgdG8gZnVy dGhlciBiZSBtb3JlDQpmcmllbmRseSBmb3IgcG93ZXIgc2Vuc2l0aXZlIGRldmljZXMuICBGcm9t IG91ciBleHBlcmllbmNlcyB3ZSBoYXZlIHR1bmVkDQphbmQgaW52ZXN0aWdhdGVkIGEgbnVtYmVy IG9mIHZhcmlhYmxlcy4gIFdlIGN1cnJlbnRseSBsZXZlcmFnZSB0aGUgTCBiaXQNCnRvIHRyeSBh bmQgbWluaW1pemUgaG93IExMIElQdjYgTUMgbWVzc2FnZXMgYXJlIHRyYW5zbWl0dGVkIGluIGNh YmxlDQpicm9hZGJhbmQgbmV0d29ya3MuICBUcnV0aGZ1bGx5IHdlIGhhZCB0byByZXF1aXJlIHRo YXQgbWFueSBvZg0KaW1wbGVtZW50YXRpb25zIGFsbG93IHRoZSBzZXR0aW5nIG9mIHRoZSBMIGJp dCBmb3IgY29ubmVjdGVkIHByZWZpeGVzLg0KRWFybHkgaW1wbGVtZW50YXRpb25zIGRpZCBub3Qg YWxsb3dzIHRoaXMgd2hpY2ggcmVzdWx0ZWQgaW4gdXMgbm90DQpkZXBsb3lpbmcgdGhlc2Ugc29s dXRpb25zIHVudGlsIHRoZXkgYmVjYW1lIGNvbXBsaWFudCB3aXRoIG91cg0KcmVxdWlyZW1lbnRz Lg0KDQpNb3JlIHJlY2VudGx5IHJlY2VudGx5IHdlIGludmVzdGlnYXRlZCBuZWlnaGJvciB0YWJs ZSBsaWZldGltZXMgdG8NCm1pbmltaXplIHJvdXRlciBvcmlnaW5hdGVkIE5EIG1lc3NhZ2luZy4g IEFzIHRoZSBkcmFmdCBzdGF0ZXMsIGluIGxhcmdlDQpkZXBsb3ltZW50cyB3aGVyZSB0aGVyZSBh cmUgdGhvdXNhbmRzIG9mIG5vZGVzIHRoaXMgcXVpY2tseSBiZWNvbWVzDQppbnRlcmVzdGluZyBh bmQgcmVzdWx0cyBpbiBhIGhpZ2ggcmF0ZSBvZiBMTCBORCBtZXNzYWdlcyB0aGF0IGFsbCBub2Rl cw0KaGF2ZSB0aGUgb3Bwb3J0dW5pdHkgdG8gc2VlIGFuZCBwZXJoYXBzIGluY29ycmVjdGx5IHBy b2Nlc3MuDQoNCkZvciBvdXIgV2lGaSB3b3JrIHRoZSB1c2Ugb2Ygc3RhdGVmdWwgREhDUHY2IGV4 Y2x1c2l2ZWx5IGlzIHNpbXBseSBub3QgYW4NCm9wdGlvbiB0b2RheSBhbmQgbWF5IG5ldmVyIGJl IGxhcmdlbHkgYmVjYXVzZSBub3QgYWxsIG5vZGVzIHVuaWZvcm1seQ0Kc3VwcG9ydCBESENQdjYu ICBBcyBzdWNoIG9wZXJhdG9ycyB3aG8gd2lzaCB0byBicmluZyBJUHY2IHRvIHRoZSBsYXJnZXN0 DQpwb3B1bGF0aW9uIG9mIGRldmljZXMgcmVxdWlyZSB0aGF0IHNldmVyYWwgYWRkcmVzc2luZyBh bmQgY29uZmlndXJhdGlvbg0KbWVjaGFuaXNtcyBiZSBlbmFibGVkIHNpbXVsdGFuZW91c2x5LiAg SW4gb3VyIGNhc2UgU0xBQUMgKyBSTkRTUyArDQpzdGF0ZWxlc3MgREhDUHY2IHdpbGwgYmUgbGV2 ZXJhZ2VkIGZvciBvdXIgV2lGaSBkZXBsb3ltZW50Lg0KDQpUaGFua3MsDQoNCkpvaG4NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpKb2huIEphc29uIEJyem96b3dz a2kNCkNvbWNhc3QgQ2FibGUNCm0pIDYwOS0zNzctNjU5NA0KbykgNDg0LTk2Mi0wMDYwDQp3KSB3 d3cuY29tY2FzdDYubmV0DQplKSBqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5kcmV3IFlvdXJ0Y2hlbmtvIDxheW91cnRj aEBjaXNjby5jb20+DQpEYXRlOiBUdWVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNCAyOjU3IFBNDQpU bzogdjZvcHMgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogW3Y2b3BzXSBSZWR1Y2luZyBNdWx0 aWNhc3QgaW4gSVB2NiBOZWlnaGJvciBEaXNjb3ZlcnkNCg0KPkZvbGxvd2luZyBFcmljIFZ5bmNr ZSdzIG1haWwsIGlmIHlvdSBnb3QgaW50ZXJlc3RlZCBieQ0KPnRoYXQgZHJhZnQsIHlvdSBtYXkg ZmluZCB0aGlzIGRyYWZ0IGludGVyZXN0aW5nIHRvbzoNCj4NCj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC15b3VydGNoZW5rby1jb2xpdHRpLW5kLXJlZHVjZS1tdWx0aWNhc3QtMA0K PjANCj4NCj5kaXNjdXNzZXMgc29tZSBwcmFjdGljYWwgbWVhc3VyZXMgdGhhdCBjYW4gYmUgdGFr ZW4gImFzIGlzIiB0byBtYWtlIElQdjYNCj5hbmQgV2lGaSBiZXR0ZXIgZnJpZW5kcy4NCj4NCj48 YmFja2dyb3VuZD4NCj4NCj5JZiBzb21lb25lIGhhcHBlbmVkIHRvIGJlIGF0IHRoaXMgeWVhcidz IEZPU0RFTSBvciBteSBlbXBsb3llcidzDQo+Y29uZmVyZW5jZSwgQ2lzY29MaXZlLCB0aGUgV2lG aSBuZXR3b3JrcyB0aGVyZSByYW4gbW9zdCBvZiB0aGUgdGhpbmdzDQo+c3BlY2lmaWVkIGluIHNl Y3Rpb24gNC4NCj4NCj4oZm9yIHNvbWUgYmFja2dyb3VuZCBpbmZvLCBoZXJlJ3Mgc29tZSBzdGF0 cyBmcm9tIHRoZSBjaXNjb2xpdmUgbmV0d29yazoNCj5odHRwOi8vMjAxNC5jaXNjb2xpdmUtaXB2 Ni5jb20vbXVuaW4vaXB2Nm5vYy9pcHY2bm9jL2luZGV4Lmh0bWw7IEZPU0RFTQ0KPndhcyBhYm91 dCB0aGUgc2FtZSBiYWxscGFyayBudW1iZXIgb2YgaG9zdHMpLg0KPg0KPjwvYmFja2dyb3VuZD4N Cj4NCj4tLWENCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPnY2b3BzIG1haWxpbmcgbGlzdA0KPnY2b3BzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Sat Feb 22 10:16:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC951A015E for ; Sat, 22 Feb 2014 10:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 8-1KHXHHm7Ie for ; Sat, 22 Feb 2014 10:16:01 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id D4C781A0156 for ; Sat, 22 Feb 2014 10:16:00 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.118266189; Sat, 22 Feb 2014 11:15:53 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.53]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.03.0158.001; Sat, 22 Feb 2014 13:15:53 -0500 From: "Brzozowski, John" To: Andrew Yourtchenko , "v6ops@ietf.org" Thread-Topic: [v6ops] Reducing Multicast in IPv6 Neighbor Discovery Thread-Index: AQHPL/hn8iPvA+aapkqMq1bssDZArZrBlEwA Date: Sat, 22 Feb 2014 18:15:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.248] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/v7leMroyd_xREa5fB-DtU4OR_tg Subject: Re: [v6ops] Reducing Multicast in IPv6 Neighbor Discovery X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Feb 2014 18:16:03 -0000 Rm9yZ290IHRvIG1lbnRpb24sIHRoYXQgaW4gaG9tZSBzY2VuYXJpb3Mgd2UgbmVlZCB0byBtYWtl IHN1cmUgdGhhdCB3ZSBkbw0Kbm90IG1ha2UgaW5hY2N1cmF0ZSBhc3N1bXB0aW9ucyBhcm91bmQg aW50ZXJ2YWwgc2V0dGluZ3MgaS5lLiBsZW5ndGhlbmluZw0Kcm91dGVyIGFkdmVydGlzZW1lbnQg aW50ZXJ2YWxzIC4gIEluIG1hbnkgY2FzZXMgdGhlc2UgYXJlIHNldCBhcyBzdWNoIHRvDQplbnN1 cmUgYSBwcm9wZXIgY3VzdG9tZXIgZXhwZXJpZW5jZS4NCg0KSm9obg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KQ29tY2Fz dCBDYWJsZQ0KbSkgNjA5LTM3Ny02NTk0DQpvKSA0ODQtOTYyLTAwNjANCncpIHd3dy5jb21jYXN0 Ni5uZXQNCmUpIGpvaG5fYnJ6b3pvd3NraUBjYWJsZS5jb21jYXN0LmNvbQ0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiA8QnJ6b3pvd3NraT4sIEpvaG4gQnJ6b3pvd3NraSA8Sm9obl9C cnpvem93c2tpQENhYmxlLkNvbWNhc3QuY29tPg0KRGF0ZTogU2F0dXJkYXksIEZlYnJ1YXJ5IDIy LCAyMDE0IDE6MDMgUE0NClRvOiBBbmRyZXcgWW91cnRjaGVua28gPGF5b3VydGNoQGNpc2NvLmNv bT4sIHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4NCkNjOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNj by5jb20+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBSZWR1Y2luZyBNdWx0aWNhc3QgaW4gSVB2NiBO ZWlnaGJvciBEaXNjb3ZlcnkNCg0KPkFuZHJldywNCj4NCj5XYW50ZWQgdG8gb2ZmZXIgc29tZSBj b21tZW50cyBvbiB0aGUgZHJhZnQuICBTb21lIG9mIHRoaXMgbWF5IGJlIGEgcmVwZWF0DQo+b2Yg dGV4dCBJIHJlY2VudGx5IHNlbmQgdG8gRXJpYyBWeW5ja2UgaW4gcmVzcG9uc2UgdG8gaGlzIGRy YWZ0LiAgV2UgaGF2ZQ0KPnNlZW4gcmVjZW50bHkgdGhhdCBmbGF3ZWQgaW1wbGVtZW50YXRpb25z IGVpdGhlciBkbyBub3QgZmlsdGVyIG9yDQo+aW5jb3JyZWN0bHkgdHJpZ2dlciB0aGUgdXNlIG9m IHNvbGljaXRlZCBub2RlIG11bHRpY2FzdCBvciBVbmljYXN0DQo+U29saWNpdGVkIFJvdXRlciBB ZHZlcnRpc2VtZW50cyB3aGljaCBpbiB0dXJuIHJlc3VsdCBpbiBlaXRoZXIgcG9vcg0KPmJhdHRl cnkgcGVyZm9ybWFuY2UgYW5kIG9yIGhpZ2ggQ1BVIHV0aWxpemF0aW9uIHdoaWNoIGluIHR1cm4g YWxzbyBpbXBhY3RzDQo+dGhlIG92ZXJhbGwgcGVyZm9ybWFuY2Ugb2YgdGhlIGRldmljZS4gIFJG Q3MgdGhhdCBvdXRsaW5lIHRoZSBwcm9wZXINCj5hcHByb2FjaCBmb3IgcHJvY2Vzc2luZyBhbmQg aGFuZGxpbmcgTkQgYW5kIFJEIG1lc3NhZ2VzIGFyZSBhdmFpbGFibGUgYW5kDQo+Z2VuZXJhbGx5 IHdoZW4gZm9sbG93ZWQgaGF2ZSBhIHZlcnkgcG9zaXRpdmUgaW1wYWN0IG9uIHBlcmZvcm1hbmNl LiAgVGhpcw0KPmlzIHNwZWNpZmljIHRvIG5vbiBtb2JpbGUgZGV2aWNlcyB3aGVyZSBiYXR0ZXJ5 IGxpZmUgaXMgbGVzcyBvZiBhIGNvbmNlcm4uDQo+IEkgYmVsaWV2ZSB0aGVyZSBpcyBhbiBvcHBv cnR1bml0eSB0byB0dW5lIHRoZSBuZXR3b3JrIHRvIGZ1cnRoZXIgYmUgbW9yZQ0KPmZyaWVuZGx5 IGZvciBwb3dlciBzZW5zaXRpdmUgZGV2aWNlcy4gIEZyb20gb3VyIGV4cGVyaWVuY2VzIHdlIGhh dmUgdHVuZWQNCj5hbmQgaW52ZXN0aWdhdGVkIGEgbnVtYmVyIG9mIHZhcmlhYmxlcy4gIFdlIGN1 cnJlbnRseSBsZXZlcmFnZSB0aGUgTCBiaXQNCj50byB0cnkgYW5kIG1pbmltaXplIGhvdyBMTCBJ UHY2IE1DIG1lc3NhZ2VzIGFyZSB0cmFuc21pdHRlZCBpbiBjYWJsZQ0KPmJyb2FkYmFuZCBuZXR3 b3Jrcy4gIFRydXRoZnVsbHkgd2UgaGFkIHRvIHJlcXVpcmUgdGhhdCBtYW55IG9mDQo+aW1wbGVt ZW50YXRpb25zIGFsbG93IHRoZSBzZXR0aW5nIG9mIHRoZSBMIGJpdCBmb3IgY29ubmVjdGVkIHBy ZWZpeGVzLg0KPkVhcmx5IGltcGxlbWVudGF0aW9ucyBkaWQgbm90IGFsbG93cyB0aGlzIHdoaWNo IHJlc3VsdGVkIGluIHVzIG5vdA0KPmRlcGxveWluZyB0aGVzZSBzb2x1dGlvbnMgdW50aWwgdGhl eSBiZWNhbWUgY29tcGxpYW50IHdpdGggb3VyDQo+cmVxdWlyZW1lbnRzLg0KPg0KPk1vcmUgcmVj ZW50bHkgcmVjZW50bHkgd2UgaW52ZXN0aWdhdGVkIG5laWdoYm9yIHRhYmxlIGxpZmV0aW1lcyB0 bw0KPm1pbmltaXplIHJvdXRlciBvcmlnaW5hdGVkIE5EIG1lc3NhZ2luZy4gIEFzIHRoZSBkcmFm dCBzdGF0ZXMsIGluIGxhcmdlDQo+ZGVwbG95bWVudHMgd2hlcmUgdGhlcmUgYXJlIHRob3VzYW5k cyBvZiBub2RlcyB0aGlzIHF1aWNrbHkgYmVjb21lcw0KPmludGVyZXN0aW5nIGFuZCByZXN1bHRz IGluIGEgaGlnaCByYXRlIG9mIExMIE5EIG1lc3NhZ2VzIHRoYXQgYWxsIG5vZGVzDQo+aGF2ZSB0 aGUgb3Bwb3J0dW5pdHkgdG8gc2VlIGFuZCBwZXJoYXBzIGluY29ycmVjdGx5IHByb2Nlc3MuDQo+ DQo+Rm9yIG91ciBXaUZpIHdvcmsgdGhlIHVzZSBvZiBzdGF0ZWZ1bCBESENQdjYgZXhjbHVzaXZl bHkgaXMgc2ltcGx5IG5vdCBhbg0KPm9wdGlvbiB0b2RheSBhbmQgbWF5IG5ldmVyIGJlIGxhcmdl bHkgYmVjYXVzZSBub3QgYWxsIG5vZGVzIHVuaWZvcm1seQ0KPnN1cHBvcnQgREhDUHY2LiAgQXMg c3VjaCBvcGVyYXRvcnMgd2hvIHdpc2ggdG8gYnJpbmcgSVB2NiB0byB0aGUgbGFyZ2VzdA0KPnBv cHVsYXRpb24gb2YgZGV2aWNlcyByZXF1aXJlIHRoYXQgc2V2ZXJhbCBhZGRyZXNzaW5nIGFuZCBj b25maWd1cmF0aW9uDQo+bWVjaGFuaXNtcyBiZSBlbmFibGVkIHNpbXVsdGFuZW91c2x5LiAgSW4g b3VyIGNhc2UgU0xBQUMgKyBSTkRTUyArDQo+c3RhdGVsZXNzIERIQ1B2NiB3aWxsIGJlIGxldmVy YWdlZCBmb3Igb3VyIFdpRmkgZGVwbG95bWVudC4NCj4NCj5UaGFua3MsDQo+DQo+Sm9obg0KPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Sm9obiBKYXNvbiBCcnpv em93c2tpDQo+Q29tY2FzdCBDYWJsZQ0KPm0pIDYwOS0zNzctNjU5NA0KPm8pIDQ4NC05NjItMDA2 MA0KPncpIHd3dy5jb21jYXN0Ni5uZXQNCj5lKSBqb2huX2Jyem96b3dza2lAY2FibGUuY29tY2Fz dC5jb20NCj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPg0K Pg0KPg0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQW5kcmV3IFlv dXJ0Y2hlbmtvIDxheW91cnRjaEBjaXNjby5jb20+DQo+RGF0ZTogVHVlc2RheSwgRmVicnVhcnkg MTgsIDIwMTQgMjo1NyBQTQ0KPlRvOiB2Nm9wcyA8djZvcHNAaWV0Zi5vcmc+DQo+U3ViamVjdDog W3Y2b3BzXSBSZWR1Y2luZyBNdWx0aWNhc3QgaW4gSVB2NiBOZWlnaGJvciBEaXNjb3ZlcnkNCj4N Cj4+Rm9sbG93aW5nIEVyaWMgVnluY2tlJ3MgbWFpbCwgaWYgeW91IGdvdCBpbnRlcmVzdGVkIGJ5 DQo+PnRoYXQgZHJhZnQsIHlvdSBtYXkgZmluZCB0aGlzIGRyYWZ0IGludGVyZXN0aW5nIHRvbzoN Cj4+DQo+Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvdXJ0Y2hlbmtvLWNvbGl0 dGktbmQtcmVkdWNlLW11bHRpY2FzdC0NCj4+MA0KPj4wDQo+Pg0KPj5kaXNjdXNzZXMgc29tZSBw cmFjdGljYWwgbWVhc3VyZXMgdGhhdCBjYW4gYmUgdGFrZW4gImFzIGlzIiB0byBtYWtlIElQdjYN Cj4+YW5kIFdpRmkgYmV0dGVyIGZyaWVuZHMuDQo+Pg0KPj48YmFja2dyb3VuZD4NCj4+DQo+Pklm IHNvbWVvbmUgaGFwcGVuZWQgdG8gYmUgYXQgdGhpcyB5ZWFyJ3MgRk9TREVNIG9yIG15IGVtcGxv eWVyJ3MNCj4+Y29uZmVyZW5jZSwgQ2lzY29MaXZlLCB0aGUgV2lGaSBuZXR3b3JrcyB0aGVyZSBy YW4gbW9zdCBvZiB0aGUgdGhpbmdzDQo+PnNwZWNpZmllZCBpbiBzZWN0aW9uIDQuDQo+Pg0KPj4o Zm9yIHNvbWUgYmFja2dyb3VuZCBpbmZvLCBoZXJlJ3Mgc29tZSBzdGF0cyBmcm9tIHRoZSBjaXNj b2xpdmUgbmV0d29yazoNCj4+aHR0cDovLzIwMTQuY2lzY29saXZlLWlwdjYuY29tL211bmluL2lw djZub2MvaXB2Nm5vYy9pbmRleC5odG1sOyBGT1NERU0NCj4+d2FzIGFib3V0IHRoZSBzYW1lIGJh bGxwYXJrIG51bWJlciBvZiBob3N0cykuDQo+Pg0KPj48L2JhY2tncm91bmQ+DQo+Pg0KPj4tLWEN Cj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PnY2b3BzIG1haWxpbmcgbGlzdA0KPj52Nm9wc0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+DQoNCg== From nobody Sun Feb 23 05:45:13 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5881A0640 for ; Sun, 23 Feb 2014 05:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.148 X-Spam-Level: X-Spam-Status: No, score=-113.148 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lazwtpek8Mw for ; Sun, 23 Feb 2014 05:45:11 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD2F1A063F for ; Sun, 23 Feb 2014 05:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1393163111; x=1394372711; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=P3/KczBqToznLyxCd8Eixj1aunKEEPVQrIqYP4mtbFn40mWw1sN2WCxZ nr8cEkV5G8q0ixkhpadgDSqd6j3I7d9l0D76acV5/pXSAR1eV4QL9J0Ii wNk3rvX2KltjyZ37k7USFk7g11duinzDesfafL2WnqODYFAb3ZPuQqI+l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscKAH36CVOrRDoG/2dsb2JhbABZgwY7q0IBlWgDBAKBBhZ0gyU8LQeIZQ7HTxeOZB2EIgSJSJAekHWDTg X-IronPort-AV: E=Sophos;i="4.97,529,1389744000"; d="scan'208";a="103598849" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 23 Feb 2014 13:45:09 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1NDj1Gx012237; Sun, 23 Feb 2014 13:45:08 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id s1NDj1W21432; Sun, 23 Feb 2014 05:45:01 -0800 (PST) Date: Sun, 23 Feb 2014 05:45:01 -0800 (PST) From: Message-Id: <201402231345.s1NDj1W21432@ftpeng-update.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tewY4fzA-xhWg_ig_mTzfdY432U Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 13:45:12 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment. From nobody Sun Feb 23 16:47:07 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C91A076E; Sun, 23 Feb 2014 16:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIDArSwrNb8W; Sun, 23 Feb 2014 16:47:02 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3491A019F; Sun, 23 Feb 2014 16:47:02 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1O0kxQh052366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 24 Feb 2014 00:47:01 GMT (envelope-from joelja@bogus.com) Message-ID: <530A967D.1080608@bogus.com> Date: Sun, 23 Feb 2014 16:46:53 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: Randy Bush , Jeffrey Haas References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 24 Feb 2014 00:47:02 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oFzme-awj_qk9WZNIOdDnXWmq1o Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Feb 2014 00:47:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/19/14, 6:35 PM, Randy Bush wrote: >> What I would instead suggest is finding a mechanism by which the >> unique router-ID can be mapped easily to such addresses. I don't >> believe that BGP is the right place to do this. >=20 > we need a name to address mapping mechanism. let's all think about > that. routerid rr-type anyone? that actually doesn't sound like a totally appalling idea. :p > randy >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMKln4ACgkQ8AA1q7Z/VrIC1wCfYAv+uIMS9aTpmLvQQuEpsrY8 ZxIAn0ENM4Z40aS5Bxsi1l7OwyaRVvOp =Fazj -----END PGP SIGNATURE----- --nfcj2iFS4m2ipnLAuuK0icEION5EKSHtj-- From nobody Sun Feb 23 22:32:12 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE351A0330 for ; Sun, 23 Feb 2014 22:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gTG3VPrujWb for ; Sun, 23 Feb 2014 22:32:09 -0800 (PST) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1B11A032F for ; Sun, 23 Feb 2014 22:32:09 -0800 (PST) Received: from [98.139.212.153] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 24 Feb 2014 06:32:08 -0000 Received: from [98.139.212.220] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 24 Feb 2014 06:32:08 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 24 Feb 2014 06:32:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 896006.14362.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 22641 invoked by uid 60001); 24 Feb 2014 06:32:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1393223528; bh=F6MgYzEycbPjW2AklhVfb0uS+zhokBgqnKw1s8KLjf0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=laXCLmWds7v1DIzOElxe4ZH7Bd0wQ1TtgyxcVvW4t3ZdmfpfHpzWP6hrGxwbEpuytn0dBVfuVPrbhEINCmF4KKkwRn5+HKTIqWmMwuXayUIsEhmXUDCUeZAmApqZjqeBXqv5AvolnjXf/Jx/VztE2Zq2hriXsPIPFVq3KVhOJg4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lX9w8CRiSoWstyiOfW6qq71+imi52fy7dw5DVpkIT80IhsTUI12ayJkvMbd07T348wfunn5wnekmvIMKjjSx7YzsLsFAfe/dJLrjIgeXjLz01SMXWdG6oATrwYgwsHF5/cpx99aPQlvr6XXIhALB5vhMPCHD336OFTEXF32iZZ4=; X-YMail-OSG: I4AIokYVM1lsbk9uxFnlSmQLqxfCAZGZ4Y3upS4yTbdH94m EkFMuSzPXDqIU0LHW5Wu24dLLOynN7XnuQ1D.BqOS52yKcsUAii4dLWw74dl 9bk3RWkRiFNAMgdu5LyOFFG3HApKzHT.iTjdS8IwTTnVaRfvtIx7hRg1Rv93 1gmCCmMhlvnkhsxBW.Tl6MatMGxHKHxqGNsvWOFk_Uu81QRDrCmyvcVpcDvf jrkLz0TEKD9mXyU8jY2_jhUjbD_qhDQeINwTZmTUlIpr_AUZyY4UYtQ5.F09 XNlwbPU685AnQsVI4lyKdyrMB8S9FgC4aPIR7EJcXdPGt4cnLxhPij2_rEHr T9BSu7WoYFGIWRmFOlxsSMtLap2BJMotApEYeeMzlzqv89m6MfC3xX2wHDfd js.w.Qa6cp6UIqk1HdICDxnhRiihtfDPFuWVScVorelXU9QPmSEEvdyM161_ VNNNeHmvy9nXLDWJeXRVeK791DS7NyIOi_gJCM4JIv90Aa69IrAQQxXsUfL8 gM8r3wnBjdEizX94fI.eAEQAKnc4lBAcD9OHhlU.AA6F5Kx73uwR9p6IUiSZ zXoXt9.eZ8verFI2aD.uCqg-- Received: from [150.101.221.237] by web162203.mail.bf1.yahoo.com via HTTP; Sun, 23 Feb 2014 22:32:08 PST X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4KPlRvOiBEYXZpZCBGYXJtZXIgPGZhcm1lckB1bW4uZWR1PiAKPkNjOiAidjZvcHNAaWV0Zi5vcmcgV0ciIDx2Nm9wc0BpZXRmLm9yZz4gCj5TZW50OiBGcmlkYXksIDIxIEZlYnJ1YXJ5IDIwMTQgMTo1OCBBTQo.U3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bGEtdXNhZ2UtcmVjb21tZW5kYXRpb25zLTAyLnR4dAo.IAoBMAEBAQE- X-Mailer: YahooMailWebService/0.8.177.636 References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> Message-ID: <1393223528.95862.YahooMailNeo@web162203.mail.bf1.yahoo.com> Date: Sun, 23 Feb 2014 22:32:08 -0800 (PST) From: Mark ZZZ Smith To: Lorenzo Colitti , David Farmer In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/f43vujNdCNC0ySK3f5hSvwGdaA0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 06:32:11 -0000 =0A=0A=0A=0A=0A>________________________________=0A> From: Lorenzo Colitti = =0A>To: David Farmer =0A>Cc: "v6ops@ie= tf.org WG" =0A>Sent: Friday, 21 February 2014 1:58 AM=0A>S= ubject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-= 02.txt=0A> =0A>=0A>=0A>On Thu, Feb 20, 2014 at 10:45 PM, David Farmer wrote:=0A>=0A>Get over it. =A0This draft is necessary, we need = to tell people how to properly use ULA. =A0It is not telling them to do NAT= . =A0I think it should more strongly tell them to NOT do NAT. =A0However, t= hey are going to do what they are going to do. =A0But, if we don't tell the= m what the proper use cases for ULA are, then our silence is consent for th= em to go ahead and do NAT with ULA.=0A>=0A>=0A>We don't know what the use c= ases for ULAs are, because nobody has actually used them in real deployment= s. The people who are deploying IPv6 are saying "ugh, ULA sucks, let's do g= lobal instead" and the ones who aren't deploying IPv6 are using IPv4.=0A>= =0A>=0A>I will be the first to support a draft that documents *real* experi= ence of ULA in a *real* deployment. But documenting use cases without havin= g actually used them for real... sorry, that's hubris.=0A>=0A=0AAnybody usi= ng the Apple "Back to my Mac" service is apparently using them:=0A=0A=0A"Un= derstanding Apple's Back to My Mac (BTMM) Service"=0Ahttps://tools.ietf.org= /html/rfc6281=0A=0A=0A=0A=0A=0A>___________________________________________= ____=0A>v6ops mailing list=0A>v6ops@ietf.org=0A>https://www.ietf.org/mailma= n/listinfo/v6ops=0A>=0A>=0A> From nobody Mon Feb 24 02:28:05 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F344F1A0440 for ; Mon, 24 Feb 2014 02:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_DKIM_INVALID=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 5UOoq-gJBu27 for ; Mon, 24 Feb 2014 02:28:00 -0800 (PST) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A19311A0442 for ; Mon, 24 Feb 2014 02:27:58 -0800 (PST) Received: from [50.95.222.92] ([50.95.222.92]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1OAMbAt023992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 24 Feb 2014 02:22:38 -0800 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1OAMbAt023992 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1393237359; bh=jmH9v4uQ8Q3CW4CVOKSyACn0JI4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DmPJSGBVA7zEYcvO2etmvPF3BQFUBIQaxUjzqFYJ8zRhyBPMeEPyha/5xrSIsP519 s3dsNIeRzQaNVGcSD48aEz0bCLVj8DtKO7mhCypOlEktE3qJ2NTO737T6viGIq0TTI wM+E+qtuS162VkwZTScgtetouuSb/yWJ2mAadP6U= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Owen DeLong In-Reply-To: <1393223528.95862.YahooMailNeo@web162203.mail.bf1.yahoo.com> Date: Mon, 24 Feb 2014 02:22:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31DFC8BD-8352-4AEB-BD18-1A3AA3619E7C@delong.com> References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> <1393223528.95862.YahooMailNeo@web162203.mail.bf1.yahoo.com> To: Mark ZZZ Smith X-Mailer: Apple Mail (2.1827) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Mon, 24 Feb 2014 02:22:39 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/KzC60M7Rzwf9FG_daj6arT_np0U Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:28:02 -0000 On Feb 23, 2014, at 10:32 PM, Mark ZZZ Smith = wrote: >=20 >=20 >=20 >=20 >=20 >> ________________________________ >> From: Lorenzo Colitti >> To: David Farmer =20 >> Cc: "v6ops@ietf.org WG" =20 >> Sent: Friday, 21 February 2014 1:58 AM >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-ula-usage-recommendations-02.txt >>=20 >>=20 >>=20 >> On Thu, Feb 20, 2014 at 10:45 PM, David Farmer = wrote: >>=20 >> Get over it. This draft is necessary, we need to tell people how to = properly use ULA. It is not telling them to do NAT. I think it should = more strongly tell them to NOT do NAT. However, they are going to do = what they are going to do. But, if we don't tell them what the proper = use cases for ULA are, then our silence is consent for them to go ahead = and do NAT with ULA. >>=20 >>=20 >> We don't know what the use cases for ULAs are, because nobody has = actually used them in real deployments. The people who are deploying = IPv6 are saying "ugh, ULA sucks, let's do global instead" and the ones = who aren't deploying IPv6 are using IPv4. >>=20 >>=20 >> I will be the first to support a draft that documents *real* = experience of ULA in a *real* deployment. But documenting use cases = without having actually used them for real... sorry, that's hubris. >>=20 >=20 > Anybody using the Apple "Back to my Mac" service is apparently using = them: Correction=85 Anybody using the Apple =93BTMM=94 service without native IPv6 is = apparently using them. People who have real IPv6 addresses, OTOH, do not = need ULA for BTMM. Owen >=20 >=20 > "Understanding Apple's Back to My Mac (BTMM) Service" > https://tools.ietf.org/html/rfc6281 >=20 >=20 >=20 >=20 >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 24 07:08:39 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04861A008E; Mon, 24 Feb 2014 07:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, 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 WIuGXG0EnHrw; Mon, 24 Feb 2014 07:08:36 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F51A009A; Mon, 24 Feb 2014 07:08:36 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 20D3CC307; Mon, 24 Feb 2014 10:08:36 -0500 (EST) Date: Mon, 24 Feb 2014 10:08:36 -0500 From: Jeffrey Haas To: joel jaeggli Message-ID: <20140224150836.GC21344@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> <530A967D.1080608@bogus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530A967D.1080608@bogus.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/wrt4fVnoOj9vGJXTAkbqFDFvaiQ Cc: Jeffrey Haas , V6 Ops List , idr wg Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Feb 2014 15:08:37 -0000 On Sun, Feb 23, 2014 at 04:46:53PM -0800, joel jaeggli wrote: > On 2/19/14, 6:35 PM, Randy Bush wrote: > > we need a name to address mapping mechanism. let's all think about > > that. > > routerid rr-type anyone? > > that actually doesn't sound like a totally appalling idea. The idea of requiring DNS to be working as a tool to manage your routing plane seems rather abhorrent to me. If routing isn't working well, neither will DNS. -- Jeff From nobody Mon Feb 24 07:18:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7459C1A00EC; Mon, 24 Feb 2014 07:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEBtyl8H2y9W; Mon, 24 Feb 2014 07:18:16 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 048541A00E8; Mon, 24 Feb 2014 07:18:11 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id at1so3551585iec.34 for ; Mon, 24 Feb 2014 07:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YMCBp4TEfzKMVnQZF1WvXLBDATvcJP4+kjxGW2M+mQg=; b=t1jNz/wjMyPYgmbUHR6TBV8pN+42w0Jtw/qiCjK/r0uiT9ZD+acNHRZedJmnwxdW5E HTSy/fiR5akO30yqUfElOIreWjBCBD6TzPbquYZf3JtCXsuRFRxGLUgc6RzZvQ5A2e+g RR4Uz+XBr1URqhLJLFuB/omzMT0A3t+1SkhO3BAFcgG2yZMRP1oSsS0vMdlYLDh0AeqE fLTNemAoHSdykhjtoPRBpxPPaBgdgXuNiLpPst5xlX42tGIDNb9bM0lmkwxjzc4KVaB9 WXeCS3+FNP5ShjVYfTTGcD2FwGzxUr6PBfO0yMitanhK4xraTLAibGVwR7DArEv8WpZC Lm6Q== MIME-Version: 1.0 X-Received: by 10.50.29.70 with SMTP id i6mr14013073igh.21.1393255091266; Mon, 24 Feb 2014 07:18:11 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.251.199 with HTTP; Mon, 24 Feb 2014 07:18:11 -0800 (PST) In-Reply-To: <20140224150836.GC21344@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> <530A967D.1080608@bogus.com> <20140224150836.GC21344@pfrc> Date: Mon, 24 Feb 2014 16:18:11 +0100 X-Google-Sender-Auth: vmhGmkr_y49wI_tgQCbZmPJOXY4 Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Sbm96omkAVv0_rp2eDvLBcz1ONo Cc: idr wg , V6 Ops List Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Feb 2014 15:18:17 -0000 Jeff, Even outside of BGP router_id topic for operational reasons resolving router's IP addresses (especially those v6) to hostnames and to interface names of the routers in anyone network would seem to me like rather a useful idea. And that not on a dedicated management linux station but on all routers. When you do show command do you prefer to see bunch of digits or much less and more meaningful ASCII strings ? Here you have a choice .. flood it by all protocols or push local hosts files. Since config is automated I do not see much issue in keep up to date hosts file of your network on all boxes. Thx, r. On Mon, Feb 24, 2014 at 4:08 PM, Jeffrey Haas wrote: > On Sun, Feb 23, 2014 at 04:46:53PM -0800, joel jaeggli wrote: >> On 2/19/14, 6:35 PM, Randy Bush wrote: >> > we need a name to address mapping mechanism. let's all think about >> > that. >> >> routerid rr-type anyone? >> >> that actually doesn't sound like a totally appalling idea. > > The idea of requiring DNS to be working as a tool to manage your routing > plane seems rather abhorrent to me. If routing isn't working well, neither > will DNS. > > -- Jeff > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Feb 24 07:51:31 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3CD1A015D; Mon, 24 Feb 2014 07:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.547, 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 QZ_T5uK788rl; Mon, 24 Feb 2014 07:51:28 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 590CD1A0140; Mon, 24 Feb 2014 07:51:28 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E9FEBC307; Mon, 24 Feb 2014 10:51:27 -0500 (EST) Date: Mon, 24 Feb 2014 10:51:27 -0500 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140224155127.GD21344@pfrc> References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <2014021811305909988540@chinamobile.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com> <20140218160639.GC12348@pfrc> <530A967D.1080608@bogus.com> <20140224150836.GC21344@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/vv5gIsf9C0pV3n1MsYRYPBXtJV8 Cc: Jeffrey Haas , V6 Ops List , idr wg Subject: Re: [v6ops] [Idr] BGP Identifier X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Feb 2014 15:51:30 -0000 Robert, On Mon, Feb 24, 2014 at 04:18:11PM +0100, Robert Raszuk wrote: > Here you have a choice .. flood it by all protocols or push local > hosts files. Since config is automated I do not see much issue in keep > up to date hosts file of your network on all boxes. I said DNS, not hosts files. Of course it's possible that rr-types are a more host-file like mechanism than they used to be. -- Jeff From nobody Mon Feb 24 16:19:06 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB0F1A0304 for ; Mon, 24 Feb 2014 16:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1Gb0aCcPmUI for ; Mon, 24 Feb 2014 16:19:00 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8462B1A022F for ; Mon, 24 Feb 2014 16:19:00 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so5343116wgh.7 for ; Mon, 24 Feb 2014 16:18:59 -0800 (PST) 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=MpD7T135nJujY4LHUVTHiiqRCi1RKxXJ0zeTGXFYFW4=; b=L6l6/6Ep3sR1yicP6fYYlbsGMlNsH6K7S4kFhETPEbAwDQ/1LTuk0Qtjuq7DWnKJ3A 9o9iuQpqFgO8LDprEvAajmHTC+HtSePwMXPQBYEvjiRgvl0gN9H+BrEUdhPVWQGPW5h3 4LOEzU3JE3hN7wfOflASuYe208IVwwp/JKmtALHY7KiF5RqK4lmGHSDISJ8b138FHAqI 5E1n33vOdVH0i2XeSiu3zzAxT3pFgZGJxE4Rn5GYaBGfHGcTfWT8s6lxcW9zI+ceYQ21 tDUc2yr1IMOy9w+nbQSFzOtNeUSplVkcDcBPFOUJz2IHhfONMKOoGtQOYsXd6yveFhuQ iszQ== X-Gm-Message-State: ALoCoQl240JmW/72hZG7TWrIZMUK05RFc9HO/aXOJ/MvHqVbRRkVxcBATt4/G1gBdBuxxP+4TcKB MIME-Version: 1.0 X-Received: by 10.194.2.70 with SMTP id 6mr21640706wjs.25.1393287539434; Mon, 24 Feb 2014 16:18:59 -0800 (PST) Received: by 10.216.168.71 with HTTP; Mon, 24 Feb 2014 16:18:59 -0800 (PST) In-Reply-To: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> Date: Mon, 24 Feb 2014 19:18:59 -0500 Message-ID: From: Victor Kuarsingh To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b3a8174dbbcba04f330081b Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/-Uywbkig2nztD3CyUCrT33K23gY Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 00:19:04 -0000 --047d7b3a8174dbbcba04f330081b Content-Type: text/plain; charset=ISO-8859-1 Lorenzo, On Thu, Feb 20, 2014 at 9:58 AM, Lorenzo Colitti wrote: > > > I will be the first to support a draft that documents *real* experience of > ULA in a *real* deployment. But documenting use cases without having > actually used them for real... sorry, that's hubris. > > I am aware of at least one use real case that I have experience with for ULA-only. This use case is for Cable Modem Management. I guess I should provide text to the draft on this (as it's a use case for "Connected Network: ULA-Only deployment"). In this case the IPv6 device as no global connectivity requirements and the use of the IP address for management purposes is very well scoped. Using ULAs in this case is quite safe since the devices will never need global connectivity (in fact its specifically guarded against). Using GUA in this case is possible, I know the blowing 1000s of /64s likely won't get anybody excited, but managing the filters on the modems is much easier with ULAs. Using GUAs, one may need to add a few filter lines in the modem config which is a precious resource (config file space). Whereas doing a deny FC00::/7 is easy and very clear. It's also visually obvious to the operator which is important in troubleshooting (where you have 100s of ops people) It's a clean use of the ULA space. As for documenting use cases, my input is 1) we should document real world use cases where we have real experience (I am a bit worried about what-if or no-experience areas) 2) I think we should soften the language of the draft to not "recommend" ULA usage, but more along the lines of if we use them, here is how they have been used, and here are the risks. regards, Victor K regards, Victor K > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b3a8174dbbcba04f330081b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Lorenzo,

=
On Thu, Feb 20, 2014 at 9:58 AM, Lorenzo Col= itti <lorenzo@google.com> wrote:


I will be the first to support a draft that documents *= real* experience of ULA in a *real* deployment. But documenting use cases w= ithout having actually used them for real... sorry, that's hubris.



I am aware of at l= east one use real case that I have experience with for ULA-only. =A0This us= e case is for Cable Modem Management. =A0 I guess I should provide text to = the draft on this (as it's a use case for "Connected Network: ULA-= Only deployment").

In this case the IPv6 device as no global connectivity = requirements and the use of the IP address for management purposes is very = well scoped. =A0Using ULAs in this case is quite safe since the devices wil= l never need global connectivity (in fact its specifically guarded against)= .

Using GUA in this case is possible, I know the blowing = 1000s of /64s likely won't get anybody excited, but managing the filter= s on the modems is much easier with ULAs. =A0Using GUAs, one may need to ad= d a few filter lines in the modem config which is a precious resource (conf= ig file space). =A0Whereas doing a deny FC00::/7 is easy and very clear. = =A0 It's also visually obvious to the operator which is important in tr= oubleshooting (where you have 100s of ops people) It's a clean use of t= he ULA space.

As for documenting use cases, my input is=A0
=
1) we should document real world use cases where we have rea= l experience (I am a bit worried about what-if or no-experience areas)

2) I think we should soften the language of the draft t= o not "recommend" ULA usage, but more along the lines of if we us= e them, here is how they have been used, and here =A0are the risks.

regards,

Victor K

regards,

Victor K

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


--047d7b3a8174dbbcba04f330081b-- From nobody Mon Feb 24 16:35:45 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135541A0313 for ; Mon, 24 Feb 2014 16:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 QPgLFklID5zv for ; Mon, 24 Feb 2014 16:35:42 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB811A0304 for ; Mon, 24 Feb 2014 16:35:42 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id hl1so6144097igb.2 for ; Mon, 24 Feb 2014 16:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5Vdk6O2Eo94NVPJTe+HtJNwipY2hBUQ53Dyu7w2khLk=; b=i6ceAFtDL09xSDuZPHKlXe5GCze8m71BuEaPgwMUXooLRTkzGWOxAirDuua9m6rdtz lj6/mOeAOM9mnWAN55AtRuP19p1Vnq7reDHKuDiQz4BADZaTqTrC3yeQwX+dhLQK6LPW ardFnVE02lOTijfihg9pl/93yJpst8UP5wD/dFaScosYyBb1i5e1/vhGg7MfAe0vW1CR /jHSY2cp3Lza3jczJH9prwM438r6Fo+L3UIdYwLKfygfUE3q1PPk7lHWdlas87lIibNW 82XdSfQ7nVr0cAC1QsnA1qNZlp2VHJBhr799JOSxHsVAMhrnx/w+fm2UktcWbMV5E8i1 ZIGg== 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=5Vdk6O2Eo94NVPJTe+HtJNwipY2hBUQ53Dyu7w2khLk=; b=AkYZg5CrIa/8eyyYP9RsNgaYjwpgHec7qBgRiEsn472agpfe62mBBK14hRgg/TjnpP KULeago4hguWjK0MTeIYKcZlo6Sp0x9b2E2sBS9ZS9r8NzmQ8cOBfrJNjbh+7lEnlWch qrwBmZFYSQQWbOfz2HFCwo5T9atdaX/GibPPWP/ltrGykZiWz4rf0m6519I61xlG5AiI JfaQVV1lwPqRQTqWosB3AyYwcxKnSbdQGYl/cao36sHcPx7OFuoJPXBpl2nwAcVQx9CB KEvssI9krX3owtdGXvskrHPRn4FZt5rPo8ODl/cUOs4jvO7iz62edobrYTZQXxlYPc7u eH1w== X-Gm-Message-State: ALoCoQml+oCn/XwI4IHuq3GlXkRbGhW7g6KiG86SHwlEpcZo1ZKbFK9QpjeW1MuQerYfq9xKQR280w25bh2KcQMr5OfpdBukwsozHCTjwaaaKFl14Cdyy5yihonGbWSRs0Rp3G/F//aI24PUuobjHSWpMIgWaiELcB3T/UFADjr5tws4YrjiGxqqcBSHDNiUL2SmyxjNiSc1 X-Received: by 10.50.143.12 with SMTP id sa12mr106258igb.45.1393288541543; Mon, 24 Feb 2014 16:35:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Mon, 24 Feb 2014 16:35:20 -0800 (PST) In-Reply-To: References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> From: Lorenzo Colitti Date: Tue, 25 Feb 2014 09:35:20 +0900 Message-ID: To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=001a1134cd0296c20a04f330441b Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/34CvG5Z59UX7EZouZWNlQazPjXU Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 00:35:44 -0000 --001a1134cd0296c20a04f330441b Content-Type: text/plain; charset=UTF-8 On Tue, Feb 25, 2014 at 9:18 AM, Victor Kuarsingh wrote: > I am aware of at least one use real case that I have experience with for > ULA-only. This use case is for Cable Modem Management. I guess I should > provide text to the draft on this (as it's a use case for "Connected > Network: ULA-Only deployment"). > > In this case the IPv6 device as no global connectivity requirements and > the use of the IP address for management purposes is very well scoped. > Using ULAs in this case is quite safe since the devices will never need > global connectivity (in fact its specifically guarded against). > That seems like a reasonable use case, yes. I think the draft should document it, perhaps also noting that often over time we tend to discover that devices need more connectivity that we previously think they needed, and in that case the devices have to be renumbered. > 1) we should document real world use cases where we have real experience > (I am a bit worried about what-if or no-experience areas) > > 2) I think we should soften the language of the draft to not "recommend" > ULA usage, but more along the lines of if we use them, here is how they > have been used, and here are the risks. > Agreed. What worries me about the current text is that few of the scenarios in the draft seem to come from real experience. In fact, one of the earlier versions of the draft documented a use case that doesn't even work as intended (the "use ULA as a NAT64 prefix"). --001a1134cd0296c20a04f330441b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 25, 2014 at 9:18 AM, Victor Kuarsingh <victor@jvknet.com> wrote:
=
I am aware of at least one use real ca= se that I have experience with for ULA-only. =C2=A0This use case is for Cab= le Modem Management. =C2=A0 I guess I should provide text to the draft on t= his (as it's a use case for "Connected Network: ULA-Only deploymen= t").

In this case the IPv6 device as no global connectivity = requirements and the use of the IP address for management purposes is very = well scoped. =C2=A0Using ULAs in this case is quite safe since the devices = will never need global connectivity (in fact its specifically guarded again= st).

That seems like a = reasonable use case, yes. I think the draft should document it, perhaps als= o noting that often over time we tend to discover that devices need more co= nnectivity that we previously think they needed, and in that case the devic= es have to be renumbered.
=C2=A0
1) we should document real world use cases where we have real experien= ce (I am a bit worried about what-if or no-experience areas)

2) I think we should soften the language of the draft t= o not "recommend" ULA usage, but more along the lines of if we us= e them, here is how they have been used, and here =C2=A0are the risks.

Agreed. What worri= es me about the current text is that few of the scenarios in the draft seem= to come from real experience. In fact, one of the earlier versions of the = draft documented a use case that doesn't even work as intended (the &qu= ot;use ULA as a NAT64 prefix").
--001a1134cd0296c20a04f330441b-- From nobody Mon Feb 24 17:35:40 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237171A0304 for ; Mon, 24 Feb 2014 17:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 Aa88Q8Ede2zr for ; Mon, 24 Feb 2014 17:35:36 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6801A02D7 for ; Mon, 24 Feb 2014 17:35:36 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 9BBFC2383C9; Tue, 25 Feb 2014 01:35:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8694516005B; Tue, 25 Feb 2014 01:36:14 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 54CE316004E; Tue, 25 Feb 2014 01:36:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5D56710401F0; Tue, 25 Feb 2014 12:35:20 +1100 (EST) To: Victor Kuarsingh From: Mark Andrews References: <20140214091302.13219.20624.idtracker@ietfa.amsl.com> <1442fd6c81e.5859224653900445752.5189762259388794287@internetdraft.org> <52FEBE28.1010006@gmail.com> <8E2A8B56-6F05-4F09-BE7E-651B9CA42458@delong.com> <5300CE32.1050808@gmail.com> <530104B3.3070205@gmail.com> <53010E70.5000401@gmail.com> <20140217110013.GA31822@mushkin> <62FF9B8A-2F21-4FDD-B1D2-82B8C02A21B3@delong.com> <37638184-17C6-4C8B-86B1-C596A5A5504A@nominum.com> <530242C3.4070108@bogus.com> <5303CD3E.1010907@gmail.com> <5304BAAF.60608@gmail.com> <53052B43.2070904@gmail.com> <5305FFFD.5090708@foobar.org> <530606FB.9020707@umn.edu> In-reply-to: Your message of "Mon, 24 Feb 2014 19:18:59 -0500." Date: Tue, 25 Feb 2014 12:35:20 +1100 Message-Id: <20140225013520.5D56710401F0@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Q0Z9IHmpoAF-D6TlK4AFUSYKuw0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 01:35:38 -0000 ULA along side GUA basically just works. In the last 69 days there have been ~800 packets that hit my firewall rules to stop ULA packets transiting the upstream link in either direction. This is with MacOS, IOS and Windows clients as well as what I daughter's friends bring along and connect to the net. I've been running like this for yonks now. bsdi# uptime 12:27PM up 69 days, 1:20, 1 user, load averages: 0.87, 0.90, 0.93 bsdi# ip6fw -a list | grep fc00 01600 1 306 unreach admin ipv6 from any to fc00::/7 via gif0 01700 794 42946 unreach admin ipv6 from fc00::/7 to any via gif0 bsdi# [rock:~] marka% traceroute6 -In -s fd92:7065:b8e::2acf:e9ff:fe1b:508f bikeshed.isc.org traceroute6 to bikeshed.isc.org (2001:4f8:3:d::19) from fd92:7065:b8e::2acf:e9ff:fe1b:508f, 64 hops max, 16 byte packets 1 fd92:7065:b8e::2e0:29ff:fe19:c02d 3.964 ms 1.228 ms 5.056 ms 2 fd92:7065:b8e::2e0:29ff:fe19:c02d 1.196 ms !P 1.180 ms !P 1.133 ms !P [rock:~] marka% -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Feb 25 06:21:08 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251F01A06F0 for ; Tue, 25 Feb 2014 06:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFmJIHGh5lFa for ; Tue, 25 Feb 2014 06:21:05 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 73F751A0716 for ; Tue, 25 Feb 2014 06:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1680; q=dns/txt; s=iport; t=1393338065; x=1394547665; h=from:to:subject:date:message-id:references:mime-version; bh=+1c6WUPLdqy+O0SpBaLkxTxZ6IbUcEatKfB27XYmh1s=; b=ljxsb+EdH+mSUGoSNQ9yYDfBqbiB369IFSr0bQNSt0YX+/o6fFjBCbhG 3SWRP46jmsPS1o9NEBPfhki2qGiYJDyrzheXlVdxu56zeeOj2VnyNg3dZ nT5cFtC5vfImv3ia/iRpylievivtXa3Hd0F3bSaXmnkkpF2llYDhiUnSL g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACGmDFOtJXG+/2dsb2JhbABZgwY7V8FRgRcWdIIlAQEBAwFJNQsCARkDAQIvMhsCCAIEEw6HbwjGbBeOAhEBPx6DHoEUBJBCgTOGP4EykHWDLYFxOQ X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="asc'?scan'208";a="23028212" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-8.cisco.com with ESMTP; 25 Feb 2014 14:21:04 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1PEL47K015444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Feb 2014 14:21:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 08:21:04 -0600 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Meetecho support at IETF89 Thread-Index: AQHPMhEpd7GFnYNuQ0OQKwEjYz/WzA== Date: Tue, 25 Feb 2014 14:21:03 +0000 Message-ID: References: <530C6AA5.4040004@meetecho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.240] Content-Type: multipart/signed; boundary="Apple-Mail=_38A18EFE-D1BD-4310-AF92-FC096938A474"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/rCVO3vhdTpXUWiUKOhn94KmjYdE Subject: [v6ops] Fwd: Meetecho support at IETF89 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Feb 2014 14:21:07 -0000 --Apple-Mail=_38A18EFE-D1BD-4310-AF92-FC096938A474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > Resent-From: > From: Meetecho IETF support > Subject: Meetecho support at IETF89 > Date: February 25, 2014 10:04:21 AM GMT > Resent-To: , > To: >=20 > Dear chair(s), >=20 > this email is to confirm Meetecho support for your WG/BOF meeting = session at IETF-89. >=20 > The agenda of supported sessions is available at: > http://ietf89.conf.meetecho.com. >=20 > If you plan to have remote presenters, you're kindly requested to = inform us in proper advance, since this needs special set-up and a = preliminary test with the remote speaker. >=20 > *The deadline for requesting remote presentation support is February = 28.* >=20 > Thanks, > the Meetecho team >=20 > --=20 > Meetecho s.r.l. > www.meetecho.com If at first the idea is not absurd, then there is no hope for it. =20 Albert Einstein --Apple-Mail=_38A18EFE-D1BD-4310-AF92-FC096938A474 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 iD8DBQFTDKbPbjEdbHIsm0MRAoEKAJ0YTZXZNfCTcsFXE3jdidXzLKMDVwCfXyGo btgP4/i0XyRcdm4kPKqM1ME= =HQUi -----END PGP SIGNATURE----- --Apple-Mail=_38A18EFE-D1BD-4310-AF92-FC096938A474-- From nobody Thu Feb 27 08:54:01 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49FA1A038C for ; Thu, 27 Feb 2014 08:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 j9PXDaor1ck2 for ; Thu, 27 Feb 2014 08:53:57 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87E1A0299 for ; Thu, 27 Feb 2014 08:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13337; q=dns/txt; s=iport; t=1393520035; x=1394729635; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yy6OtzMHZG0vhKgiglw1OyxPgnwkBFQf8x3YdXj2INs=; b=mxKYdVKwcyzr68/8voRfx4PH0Ic4vztzE2NQbfifLFLh6JJMySdvpCHA +0+RfFn8rdoq2Iq89pDL1gMIiaFudPNlJqOpzPQbhUifZV/nHuLt/UjhT +gz5h3ld3J2zdwDAhv7JfynWWGXLy7Qf8qldY6gdavdX1KZkD0ipyqsSs g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMFAHZsD1OtJXHA/2dsb2JhbABXAw6CNEQ7V7gyiFmBGxZ0giUBAQEEAQEBRiULEAIBCBEDAQIoBycLFAkIAgQBDQWHeQ3KVxeORAEMBAcJCIQmBIkSjyaBMpB4gm4/gio X-IronPort-AV: E=Sophos; i="4.97,555,1389744000"; d="scan'208,217"; a="23698495" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 27 Feb 2014 16:53:55 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1RGrtTq022286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 16:53:55 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 10:53:55 -0600 From: "Eric Vyncke (evyncke)" To: "Brzozowski, John" , Tim Chown , "Fred Baker (fred)" Thread-Topic: [v6ops] Proposed agenda Thread-Index: AQHPKe+GQ54cQ4Ch+0GNXdWWzntzp5rJQ5eA Date: Thu, 27 Feb 2014 16:53:54 +0000 Message-ID: References: <78AAA6FC-F422-41D4-88A7-58066118C919@ecs.soton.ac.uk> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.75.73] Content-Type: multipart/alternative; boundary="_000_CF34AD44F1B7evynckeciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/GcGnBH1AD0ynfCWlZodCELl9J7w Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2014 16:53:59 -0000 --_000_CF34AD44F1B7evynckeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the same vein, http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-ef= ficient-01 is related to Andrew & Lorenzo's I-D by explaining what is the p= roblem to be fixed. It will be presented in 6MAN and I had in mind that I a= lready proposed it as well for V6OPS but it is not on the official agenda. -=E9ric From: , John > Date: samedi 22 f=E9vrier 2014 06:13 To: Tim Chown >, Fred Baker= > Cc: "v6ops@ietf.org WG" > Subject: Re: [v6ops] Proposed agenda Adding this to the agenda makes sense. We have seen evidence of issues rel= ated to IPv6 multicast, specifically link local, in large broadband deploym= ents where WiFi is and is not in use. In most cases to date these appear t= o be implementation issues. It does not hurt to discuss additional optimiz= ations or clarifications to help guide implementers. This draft and other related work must consider how broadband deployments a= re enabling IPv6 in customer's premises. Discounting this or making assump= tions about how IPv6 should deployed from academic perspective will not be = helpful to implementers or for the overall adoption of IPv6. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 609-377-6594 o) 484-962-0060 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Tim Chown > Date: Monday, February 17, 2014 11:29 AM To: Fred Baker > Cc: v6ops > Subject: Re: [v6ops] Proposed agenda Hi, On 16 Feb 2014, at 00:35, Fred Baker (fred) > wrote: Let me ask for comment on the list. Folks, would you like to discuss this? I have a half hour to spare in the t= ime we have suggested. Yes, this is a worthwhile discussion to have, briefly. Tim On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti > wrote: On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) > wrote: This is of course open to change; that's why it's called a "proposed agenda= ". Please post to the list. Would there be time to briefly discuss: http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00= ? This will be presented in 6man during a session on the efficiency of the ND= protocol, but I feel that it really belongs in v6ops, because it has no pr= otocol changes. Of course, since it was posted only shortly before 23:59 UTC, it fails the = "has been discussed on the list" test. :-) ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_CF34AD44F1B7evynckeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
In the same vein, http://tools.ietf.org/html/draft-vyncke-6m= an-mcast-not-efficient-01 is related to Andrew & Lorenzo's I-D= by explaining what is the problem to be fixed. It will be presented in 6MAN and I had in mind that I already proposed it = as well for V6OPS but it is not on the official agenda.

-=E9ric

From: <Brzozowski>, John <= John_Brzozowski@Cable.= Comcast.com>
Date: samedi 22 f=E9vrier 2014 06:1= 3
To: Tim Chown <tjc@ecs.soton.ac.uk>, Fred Baker <fred@cisco.com>
Cc: "v6ops@ietf.org WG" <= v6ops@ietf.org>
Subject: Re: [v6ops] Proposed agend= a

Adding this to the agenda makes sense.  We have seen evidence of = issues related to IPv6 multicast, specifically link local, in large broadba= nd deployments where WiFi is and is not in use.  In most cases to date= these appear to be implementation issues.  It does not hurt to discuss additional optimizations or clarificatio= ns to help guide implementers.

This draft and other related work must consider how broadband deployme= nts are enabling IPv6 in customer's premises.  Discounting this or mak= ing assumptions about how IPv6 should deployed from academic perspective wi= ll not be helpful to implementers or for the overall adoption of IPv6.

John
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jas= on Brzozowski
Comcast = Cable
m) 609-3= 77-6594
o) 484-9= 62-0060
w) www.c= omcast6.net
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Monday, February 17, 2014 11:= 29 AM
To: Fred Baker <fred@cisco.com>
Cc: v6ops <v6ops@ietf.org>
Subject: Re: [v6ops] Proposed agend= a

Hi,

On 16 Feb 2014, at 00:35, Fred Baker (fred) <fred@cisco.com> wrote:

Let me ask for comment on the list.

Folks, would you like to discuss this? I have a half hour to spare in = the time we have suggested.

Yes, this is a worthwhile discussion to have, briefly.

Tim


On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti <lorenzo@google.com>
 wrote:

On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fr= ed) <fred@cisco.com&= gt; wrote:
This is of course open to change; that's why it's called a "proposed a= genda". Please post to the list.

Would there be time to briefly discuss:


This will be presented in 6man during a session on the efficiency of t= he ND protocol, but I feel that it really belongs in v6ops, because it has = no protocol changes.

Of course, since it was posted only shortly before 23:59 UTC, it fails= the "has been discussed on the list" test. :-)

---------------= -------------------------------------
The ignorance of how to use new knowledge = stockpiles exponentially. 
   - = Marshall McLuhan

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

 --_000_CF34AD44F1B7evynckeciscocom_-- From nobody Thu Feb 27 10:07:34 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0631A0115 for ; Thu, 27 Feb 2014 10:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.047 X-Spam-Level: X-Spam-Status: No, score=-115.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NccZOniFcajU for ; Thu, 27 Feb 2014 10:07:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 81CA31A0074 for ; Thu, 27 Feb 2014 10:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16824; q=dns/txt; s=iport; t=1393524449; x=1394734049; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O70Dvx1Ke3LnJoCEGG1wwNvX2rXiWJ3uQZooeAxlHuk=; b=bt+dvv4kzjUkRxGK19hpHjgHRgLEQXNUIkshV2aBF4YO/uarwtHBB60X FGlzVQc+rNiPLpIDNgdYjGDJwHwLGk6C1YS2PkSE2Io0xIJGDbdjpNQiK jlSAeo0AhmhI3d9ZpbJBSv3Fc8tLbcTqB6YoPviRTgsByRlOpAWmOaeVw 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFABx+D1OtJXG9/2dsb2JhbABXA4JCRDtLDLgyiFmBHRZ0giUBAQEDAQEBAUYkAQsFCwIBCBEDAQIBLicLHQgCBA4FDodjCA3KdheORAEMBAcJCIMSgRQEkEaBM4Y/gTKQeIMtgio X-IronPort-AV: E=Sophos;i="4.97,556,1389744000"; d="asc'?scan'208,217";a="306982904" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 27 Feb 2014 18:07:27 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1RI7R6P013554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 18:07:27 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 12:07:27 -0600 From: "Fred Baker (fred)" To: "Eric Vyncke (evyncke)" Thread-Topic: [v6ops] Proposed agenda Thread-Index: AQHPM+bFQVjG4CKMKkC9zxgds9Z4kA== Date: Thu, 27 Feb 2014 18:07:27 +0000 Message-ID: References: <78AAA6FC-F422-41D4-88A7-58066118C919@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.95.199] Content-Type: multipart/signed; boundary="Apple-Mail=_ABC5D0EA-3148-4DE5-A55E-593DF5DCFD7D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/6xPW-3_lgOMWukA_EMdU4I4k7B4 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Proposed agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Feb 2014 18:07:33 -0000 --Apple-Mail=_ABC5D0EA-3148-4DE5-A55E-593DF5DCFD7D Content-Type: multipart/alternative; boundary="Apple-Mail=_F14F5054-64A4-4219-9FED-2973CBA5A9F7" --Apple-Mail=_F14F5054-64A4-4219-9FED-2973CBA5A9F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 27, 2014, at 4:53 PM, Eric Vyncke (evyncke) = wrote: > In the same vein, = http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 is = related to Andrew & Lorenzo's I-D by explaining what is the problem to = be fixed. It will be presented in 6MAN and I had in mind that I already = proposed it as well for V6OPS but it is not on the official agenda. You did suggest it. OK, I have updated the agenda. While we're bashing it, are there other = comments on it? > -=E9ric >=20 > From: , John > Date: samedi 22 f=E9vrier 2014 06:13 > To: Tim Chown , Fred Baker > Cc: "v6ops@ietf.org WG" > Subject: Re: [v6ops] Proposed agenda >=20 >> Adding this to the agenda makes sense. We have seen evidence of = issues related to IPv6 multicast, specifically link local, in large = broadband deployments where WiFi is and is not in use. In most cases to = date these appear to be implementation issues. It does not hurt to = discuss additional optimizations or clarifications to help guide = implementers. >>=20 >> This draft and other related work must consider how broadband = deployments are enabling IPv6 in customer's premises. Discounting this = or making assumptions about how IPv6 should deployed from academic = perspective will not be helpful to implementers or for the overall = adoption of IPv6. >>=20 >> John >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> m) 609-377-6594 >> o) 484-962-0060 >> w) www.comcast6.net >> e) john_brzozowski@cable.comcast.com >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> From: Tim Chown >> Date: Monday, February 17, 2014 11:29 AM >> To: Fred Baker >> Cc: v6ops >> Subject: Re: [v6ops] Proposed agenda >>=20 >>> Hi, >>>=20 >>> On 16 Feb 2014, at 00:35, Fred Baker (fred) wrote: >>>=20 >>>> Let me ask for comment on the list. >>>>=20 >>>> Folks, would you like to discuss this? I have a half hour to spare = in the time we have suggested. >>>=20 >>> Yes, this is a worthwhile discussion to have, briefly. >>>=20 >>> Tim >>>=20 >>>>=20 >>>> On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti >>>> wrote: >>>>=20 >>>>> On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker (fred) = wrote: >>>>>> This is of course open to change; that's why it's called a = "proposed agenda". Please post to the list. >>>>>=20 >>>>> Would there be time to briefly discuss: >>>>>=20 >>>>> = http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-0= 0 ?=20 >>>>>=20 >>>>> This will be presented in 6man during a session on the efficiency = of the ND protocol, but I feel that it really belongs in v6ops, because = it has no protocol changes. >>>>>=20 >>>>> Of course, since it was posted only shortly before 23:59 UTC, it = fails the "has been discussed on the list" test. :-) >>>>=20 >>>> ---------------------------------------------------- >>>> The ignorance of how to use new knowledge stockpiles exponentially.=20= >>>> - Marshall McLuhan >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --Apple-Mail=_F14F5054-64A4-4219-9FED-2973CBA5A9F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 evyncke@cisco.com> = wrote:

In the same vein, http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01=  is related to Andrew & Lorenzo's I-D by explaining what is the = problem to be fixed. It will be presented in 6MAN and I had in mind that I already proposed = it as well for V6OPS but it is not on the official agenda.
-=E9ric

From: <Brzozowski>, John = <John_Brzozowski@Cable.Co= mcast.com>
Date: samedi 22 f=E9vrier 2014 = 06:13
To: Tim Chown <tjc@ecs.soton.ac.uk>, Fred = Baker <fred@cisco.com>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Proposed = agenda

Adding this to the agenda makes sense.  We have seen evidence = of issues related to IPv6 multicast, specifically link local, in large = broadband deployments where WiFi is and is not in use.  In most = cases to date these appear to be implementation issues.  It does not hurt to discuss additional optimizations or = clarifications to help guide implementers.

This draft and other related work must consider how broadband = deployments are enabling IPv6 in customer's premises.  Discounting = this or making assumptions about how IPv6 should deployed from academic = perspective will not be helpful to implementers or for the overall adoption of IPv6.

John
John = Jason Brzozowski
m) = 609-377-6594
o) = 484-962-0060
john_brzozowski@cable.co= mcast.com
From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Monday, February 17, 2014 = 11:29 AM
To: Fred Baker <fred@cisco.com>
Cc: v6ops <v6ops@ietf.org>
Subject: Re: [v6ops] Proposed = agenda

Hi,

On 16 Feb 2014, at 00:35, Fred Baker (fred) <fred@cisco.com> wrote:

Let me ask for comment on the list.

Folks, would you like to discuss this? I have a half hour to spare = in the time we have suggested.

Yes, this is a worthwhile discussion to have, briefly.

Tim


On Feb 14, 2014, at 7:05 PM, Lorenzo Colitti <lorenzo@google.com>
 wrote:

On Sat, Feb 15, 2014 at 10:44 AM, Fred Baker = (fred) <fred@cisco.com> wrote:
This is of course open to change; that's why it's called a "proposed = agenda". Please post to the list.

Would there be time to briefly discuss:


This will be presented in 6man during a session on the efficiency = of the ND protocol, but I feel that it really belongs in v6ops, because = it has no protocol changes.

Of course, since it was posted only shortly before 23:59 UTC, it = fails the "has been discussed on the list" test. :-)

ignorance of how to use = new knowledge stockpiles exponentially. 
   = - Marshall McLuhan

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

"We are learning to do a great many = clever things...The next great task
will be to learn not to do = them."

- G. K. Chesterton = (1874-1936)




= --Apple-Mail=_F14F5054-64A4-4219-9FED-2973CBA5A9F7-- --Apple-Mail=_ABC5D0EA-3148-4DE5-A55E-593DF5DCFD7D 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 iD8DBQFTD37WbjEdbHIsm0MRAvm9AJwKSjNG38SgUxRPw7L3s+f9tD10OACghDYc DZ0nzWz1r853yvugK8063Kk= =A3WJ -----END PGP SIGNATURE----- --Apple-Mail=_ABC5D0EA-3148-4DE5-A55E-593DF5DCFD7D-- From nobody Fri Feb 28 05:45:19 2014 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85351A027F for ; Fri, 28 Feb 2014 05:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASOF_YgdpMA8 for ; Fri, 28 Feb 2014 05:45:17 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 58AB71A0190 for ; Fri, 28 Feb 2014 05:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140; q=dns/txt; s=iport; t=1393595115; x=1394804715; h=date:from:message-id:to:subject:cc; bh=n3WgplZeNdl6iLLkwUuzUgj4qkv9OCdYGzhHbDma7i0=; b=GzKfT3AAZ6ZfVU3IhwsDL7ZJ8N57x6etiuDg7qTDgPJagNpFCFCZtocc S4g7bzDsJdTfz0buaHAmSs5CyjbMF3oGzkJf3q8+0iwE2kkYPKqAQ85Im HQafPmEVmBIzYNXkAhwicHNySTpOGH0gpa9jlErevLtBTZ/rYwVaJTVJR w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYLADiSEFOrRDoI/2dsb2JhbABagwY7q14BlgsDBAKBExZ0gyU8NIhZDsswF45VHYQhBIlKkCGQeYNO X-IronPort-AV: E=Sophos;i="4.97,561,1389744000"; d="scan'208";a="104020906" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 28 Feb 2014 13:45:15 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1SDjFOB017337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Feb 2014 13:45:15 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id s1SDjFQg016540; Fri, 28 Feb 2014 05:45:15 -0800 (PST) Received: (from fred@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id s1SDjENv016510; Fri, 28 Feb 2014 05:45:14 -0800 (PST) Date: Fri, 28 Feb 2014 05:45:14 -0800 (PST) From: Fred Baker Message-Id: <201402281345.s1SDjENv016510@irp-view13.cisco.com> To: v6ops@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Hrobg2B8cuFmkeuWz02_CUqmwQw Cc: draft-v6ops-jaeggli-pmtud-ecmp-problem@tools.ietf.org Subject: [v6ops] new draft: draft-v6ops-jaeggli-pmtud-ecmp-problem X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 13:45:19 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem. Please take a look at it and comment.