From zhou.sujing@zte.com.cn Thu Mar 1 01:31:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB5121F8690; Thu, 1 Mar 2012 01:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.035 X-Spam-Level: X-Spam-Status: No, score=-97.035 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxO+sqB2jYbF; Thu, 1 Mar 2012 01:31:17 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 521AE21F8681; Thu, 1 Mar 2012 01:31:16 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 523732306338276; Thu, 1 Mar 2012 15:54:19 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 35739.2306338276; Thu, 1 Mar 2012 16:00:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2180PfP023856; Thu, 1 Mar 2012 16:00:25 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4F4D2643.6050200@venaas.com> To: ipv6@ietf.org, ipv6-bounces@ietf.org Subject: Time slot at 83 meeting? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 1 Mar 2012 16:00:15 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-01 16:00:28, Serialize complete at 2012-03-01 16:00:28 Content-Type: multipart/alternative; boundary="=_alternative 002BFD08482579B4_=" X-MAIL: mse02.zte.com.cn q2180PfP023856 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 09:31:17 -0000 This is a multipart message in MIME format. --=_alternative 002BFD08482579B4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SG93IGNhbiBJIGFzayBmb3IgYSBwcmVzZW50YXRpb24gdGltZSBzbG90Pw0KDQpSZWdhcmRzfn5+ DQoNCi1TdWppbmcgWmhvdQ0KDQppcHY2LWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTAyLTI5 IDAzOjA4OjUxOg0KDQo+IE9uIDIvMjgvMjAxMiA1OjEyIEFNLCBKZXJvZW4gTWFzc2FyIHdyb3Rl Og0KPiA+IEhpLA0KPiA+DQo+ID4gSSB3YXMgd29uZGVyaW5nLCBpZiBhbnlib2R5IGhhZCBhIHJv dWdoIGlkZWEgaG93IG1hbnkgTUxEdjEtb25seQ0KPiA+IGxpc3RlbmVycyBhcmUgc3RpbGwgb3V0 IHRoZXJlIGluIHRoZSB3aWxkLiBNeSBhc3N1bXB0aW9uIGJ5IG5vdyBpcyANCnRoYXQNCj4gPiBj dXJyZW50IGNvZGUgb3V0IHRoZXJlICh0aHVzIG5vdCBzdHVmZiB0aGF0IGhhcyBiZWVuIHVwIGFu ZCBydW5uaW5nIA0KYW5kDQo+ID4gbmV2ZXIgdXBncmFkZWQgZm9yIHRoZSBsYXN0IDUgeWVhcnMg b3JzbyA7KSBhbGwgc3VwcG9ydHMgTUxEdjIuLi4gb3IgDQppcw0KPiA+IHRoZXJlIGEgbWFqb3Ig cGxhdGZvcm0gd2hpY2ggZG9lcyBub3QgZG8gTUxEdjI/DQo+IA0KPiBOb3Qgc3VyZSwgYnV0IEFw cGxlIG9ubHkganVzdCBub3cgc3RhcnRlZCBzdXBwb3J0aW5nIFNTTSwgYW5kIEkgdGhpbmsNCj4g cGVyaGFwcyBpdCB3YXMgYWxsIE1MRHYxIHVudGlsIHRoZW4uIFNvIHRoZXJlIG1pZ2h0IGJlIGEg bG90IG9mIE1MRHYxDQo+IEFwcGxlcyBvdXQgdGhlcmUgc3RpbGwuDQo+IA0KPiBTdGlnDQo+IA0K PiA+DQo+ID4gR3JlZXRzLA0KPiA+ICAgSmVyb2VuDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBJRVRG IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPiBpcHY2QGlldGYub3JnDQo+ID4g QWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXB2Ng0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQ djYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlz dHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KDQo= --=_alternative 002BFD08482579B4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvdyBjYW4gSSBhc2sgZm9yIGEg cHJlc2VudGF0aW9uIHRpbWUNCnNsb3Q/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzfn5+PGJyPg0KPGJyPg0KLVN1amluZyBaaG91PC9mb250 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+aXB2Ni1ib3VuY2VzQGlldGYub3JnINC009og MjAxMi0wMi0yOSAwMzowODo1MTo8YnI+DQo8YnI+DQomZ3Q7IE9uIDIvMjgvMjAxMiA1OjEyIEFN LCBKZXJvZW4gTWFzc2FyIHdyb3RlOjxicj4NCiZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgSSB3YXMgd29uZGVyaW5nLCBpZiBhbnlib2R5IGhhZCBhIHJvdWdoIGlk ZWEgaG93IG1hbnkgTUxEdjEtb25seTxicj4NCiZndDsgJmd0OyBsaXN0ZW5lcnMgYXJlIHN0aWxs IG91dCB0aGVyZSBpbiB0aGUgd2lsZC4gTXkgYXNzdW1wdGlvbiBieSBub3cNCmlzIHRoYXQ8YnI+ DQomZ3Q7ICZndDsgY3VycmVudCBjb2RlIG91dCB0aGVyZSAodGh1cyBub3Qgc3R1ZmYgdGhhdCBo YXMgYmVlbiB1cCBhbmQgcnVubmluZw0KYW5kPGJyPg0KJmd0OyAmZ3Q7IG5ldmVyIHVwZ3JhZGVk IGZvciB0aGUgbGFzdCA1IHllYXJzIG9yc28gOykgYWxsIHN1cHBvcnRzIE1MRHYyLi4uDQpvciBp czxicj4NCiZndDsgJmd0OyB0aGVyZSBhIG1ham9yIHBsYXRmb3JtIHdoaWNoIGRvZXMgbm90IGRv IE1MRHYyPzxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3Qgc3VyZSwgYnV0IEFwcGxlIG9ubHkganVz dCBub3cgc3RhcnRlZCBzdXBwb3J0aW5nIFNTTSwgYW5kIEkgdGhpbms8YnI+DQomZ3Q7IHBlcmhh cHMgaXQgd2FzIGFsbCBNTER2MSB1bnRpbCB0aGVuLiBTbyB0aGVyZSBtaWdodCBiZSBhIGxvdCBv ZiBNTER2MTxicj4NCiZndDsgQXBwbGVzIG91dCB0aGVyZSBzdGlsbC48YnI+DQomZ3Q7IDxicj4N CiZndDsgU3RpZzxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEdyZWV0 cyw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IEplcm9lbjxicj4NCiZndDsgJmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCiZndDsgJmd0OyBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7ICZndDsgaXB2NkBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBBZG1pbmlzdHJhdGl2ZSBS ZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PGJyPg0K Jmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KJmd0OyBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IGlw djZAaWV0Zi5vcmc8YnI+DQomZ3Q7IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 002BFD08482579B4_=-- From ichiroumakino@gmail.com Thu Mar 1 01:38:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFAD21F8663; Thu, 1 Mar 2012 01:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HitTqUA-wktE; Thu, 1 Mar 2012 01:38:50 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 968AB21F8690; Thu, 1 Mar 2012 01:38:45 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so225353wgb.13 for ; Thu, 01 Mar 2012 01:38:44 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.82.132 as permitted sender) client-ip=10.180.82.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.82.132 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.82.132]) by 10.180.82.132 with SMTP id i4mr311363wiy.12.1330594724644 (num_hops = 1); Thu, 01 Mar 2012 01:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+9MG+iki5YjFN/PD8spPFhh2pnjvtCDM1A60t82mC9M=; b=kkq2jgihauQWJIwM1q9VMA8FCTt/zcejZ/jyIaljcSB3HHIGNJeHj829YaWHYl+7i9 Qh6qjoxx7A6evuNOSK6BS0yVxsTS+Xj3jCZYEJ+kkFP6ygTBLtGrMMTmnjPuC92auYLR tDmcrcoJHYsk5x7chqcEULZlK8b/4Kn8eWA18= Received: by 10.180.82.132 with SMTP id i4mr253015wiy.12.1330594724492; Thu, 01 Mar 2012 01:38:44 -0800 (PST) Received: from [173.38.129.239] ([173.38.129.239]) by mx.google.com with ESMTPS id cc3sm7082118wib.7.2012.03.01.01.38.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 01:38:43 -0800 (PST) Sender: Ole Troan Subject: Re: Time slot at 83 meeting? Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=GB2312 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 1 Mar 2012 10:38:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E1DC7B0-2BB7-42EC-8BFB-E04F5CECD6C6@employees.org> References: To: zhou.sujing@zte.com.cn X-Mailer: Apple Mail (2.1257) Cc: ipv6-bounces@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 09:38:50 -0000 Zhou, > How can I ask for a presentation time slot?=20 send a request to the chairs. 6man-chairs@tools.ietf.org cheers, Ole >=20 > Regards~~~ >=20 > -Sujing Zhou=20 >=20 > ipv6-bounces@ietf.org =D0=B4=D3=DA 2012-02-29 03:08:51: >=20 > > On 2/28/2012 5:12 AM, Jeroen Massar wrote: > > > Hi, > > > > > > I was wondering, if anybody had a rough idea how many MLDv1-only > > > listeners are still out there in the wild. My assumption by now is = that > > > current code out there (thus not stuff that has been up and = running and > > > never upgraded for the last 5 years orso ;) all supports MLDv2... = or is > > > there a major platform which does not do MLDv2? > >=20 > > Not sure, but Apple only just now started supporting SSM, and I = think > > perhaps it was all MLDv1 until then. So there might be a lot of = MLDv1 > > Apples out there still. > >=20 > > Stig > >=20 > > > > > > Greets, > > > Jeroen > > > = -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > > > = -------------------------------------------------------------------- > >=20 > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From edj.etc@gmail.com Thu Mar 1 09:44:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA15821F8ACA for ; Thu, 1 Mar 2012 09:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdeZuFZP1Bke for ; Thu, 1 Mar 2012 09:44:43 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0121F8AB9 for ; Thu, 1 Mar 2012 09:44:29 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so800727vcb.31 for ; Thu, 01 Mar 2012 09:44:29 -0800 (PST) Received-SPF: pass (google.com: domain of edj.etc@gmail.com designates 10.52.179.10 as permitted sender) client-ip=10.52.179.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of edj.etc@gmail.com designates 10.52.179.10 as permitted sender) smtp.mail=edj.etc@gmail.com; dkim=pass header.i=edj.etc@gmail.com Received: from mr.google.com ([10.52.179.10]) by 10.52.179.10 with SMTP id dc10mr9667803vdc.118.1330623869127 (num_hops = 1); Thu, 01 Mar 2012 09:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cQYNjMEQx5GuD7WMA9Izb0fZ9g//bojY0SxkUFN0F6A=; b=MCHwqUmj7whYlebrmu8KjwkV1zJUDmB3ZmaQH6ysOlqBW1pX1AuEpxQbC4oirCWhVH wtW0Bfr8PgQQMzjwZSgsfgVnJ5KZuwAjQJGS5xItsIA8BETWEOOjsyK8CjrsNyvLRCpa JjTVpuhq+KX4UhmvWm6ConoZ0yrckTKkaer/A= MIME-Version: 1.0 Received: by 10.52.179.10 with SMTP id dc10mr8171339vdc.118.1330623869059; Thu, 01 Mar 2012 09:44:29 -0800 (PST) Received: by 10.52.170.174 with HTTP; Thu, 1 Mar 2012 09:44:29 -0800 (PST) Date: Thu, 1 Mar 2012 12:44:29 -0500 Message-ID: Subject: Question on Security Considerations for "draft-macaulay-6man-packet-stain" From: Ed Juskevicius To: tyson.macaulay@bell.ca Content-Type: multipart/alternative; boundary=bcaec51964670b842904ba320386 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:44:43 -0000 --bcaec51964670b842904ba320386 Content-Type: text/plain; charset=ISO-8859-1 Hello Tyson. I have a few questions on your I-D about "IPv6 packet staining". Let me start with one that concerns security considerations. In Section 7, the I-D mentions reputational algorithms for cyber intelligence and then it cautions implementers about unspecified hazards associated with the source of intelligence and the protection of the algorithms. Where are the algorithms (mentioned in Section 7) to be applied? In the PMDs? At the end points? In a different locations or element altogether?" Thanks in advance, Ed J. --bcaec51964670b842904ba320386 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Tyson.=A0 I have a few questions on your I-D=A0about "IPv6 = packet staining".=A0 Let me start with one that concerns security cons= iderations.
=A0
In Section 7, the I-D mentions reputati= onal algorithms=20 for cyber intelligence and then=A0it cautions implementers about unspecifie= d=20 hazards associated with the source of intelligence and the protection of th= e=20 algorithms.
=A0
Where=A0are the algorithms (mentioned= in Section 7) to be applied? In the PMDs? At the end=20 points? In a different locations or element altogether?"
=A0
=
Thanks in advance,
=A0
Ed=A0 J.
--bcaec51964670b842904ba320386-- From zhou.sujing@zte.com.cn Thu Mar 1 16:23:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D442A21E8235 for ; Thu, 1 Mar 2012 16:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.506 X-Spam-Level: X-Spam-Status: No, score=-94.506 tagged_above=-999 required=5 tests=[AWL=-1.716, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g-5ssUOBuNC for ; Thu, 1 Mar 2012 16:23:18 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A48B321E82D4 for ; Thu, 1 Mar 2012 16:23:17 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801320096835; Fri, 2 Mar 2012 07:52:32 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 49094.3611530093; Fri, 2 Mar 2012 08:22:50 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q220Mxmv078361; Fri, 2 Mar 2012 08:22:59 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <80F113C3-8DEA-4757-904E-92CBEECE9F7C@gmail.com> To: Bob Hinden , ipv6@ietf.org Subject: =?GB2312?B?tPC4tDogUmU6IHJlcXVlc3QgZm9yIGEgIHRpbWUgc2xvdCBmb3IgImRyYWZ0?= =?GB2312?B?LXpob3UtNm1hbi1taGFzaC1jZ2EtMDAudHh0Ig==?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 2 Mar 2012 08:22:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-02 08:23:00, Serialize complete at 2012-03-02 08:23:00 Content-Type: multipart/alternative; boundary="=_alternative 00021BCC482579B5_=" X-MAIL: mse02.zte.com.cn q220Mxmv078361 Cc: 6man-chairs@tools.ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 00:23:18 -0000 This is a multipart message in MIME format. --=_alternative 00021BCC482579B5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 dGhlICBwcm9ibGVtcyBpdCBzb2x2ZXM6DQogICAgICAgVGhlIGRyYWZ0IHByb3ZpZGVzIGEgc2lt cGxlIG1ldGhvZCBvZiBlbmNvZGluZyBtdWx0aXBsZSBoYXNoIA0KZnVuY3Rpb24gdHlwZXMgaW4g YSBDR0EgYWRkcmVzcywgaXQgY2FuIGJlIHRob3VnaHQgb2YgYXMgDQphbiBpbXByb3ZlbWVudCBv ciBhbiB1cGRhdGUgdG8gUkZDNDk4Mi4gDQogDQp0aGUgbW90aXZhdGlvbjoNCg0KICAgICAgIFJG QzM5NzIgZGVmaW5lZCBDR0EgKGNyeXB0b2dyYXBoaWNhbGx5IGdlbmVyYXRlZCBhZGRyZXNzKSBi dXQgb25seSANCnVzZSBvbmUgaGFzaDpTSEEtMSwgaXQgaXMgaGFyZGNvZGVkIGludG8gQ0dBLg0K ICAgICAgUkZDNDk4MiBwcm9wb3NlZCB0byBkZWZpbmUgbXVsdGlwbGUgaGFzaCBmdW5jdGlvbnMg aW4gYSBDR0EgYWRkcmVzcywgDQpieSByZXVzaW5nIDMgYml0cyBTZWN1cml0eSBwYXJhbWV0ZXIg aW4gYSBDR0EsIA0Kc28gcHJlc2VudGF0aW9uIG9mIHNlYyBhbmQgaGFzaCB0b3RhbGx5IG9jY3Vw eSAzIGJpdHMsIGFuZCBzZWMgc2hvdWxkIGJlIA0KMH43LCBldmVuIGlmIHdlIG9ubHkgdXNlIGxv dyB2YWx1ZSBvZiAgc2VjIDowLDEsMiwNCmhvdyBtdWNoIGlzIGxlZnQgZm9yIGhhc2ggZnVuY3Rp b24/IDgvMyA8MyANCiAgICBzbyB0aGUgbW90aXZhdGlvbiBpcyB0cnlpbmcgdG8gZW5jb2RlIG1v cmUgaGFzaCBmdW5jdGlvbiB0eXBlcyBpbiBhIA0KQ0dBIGFkZHJlc3Mgd2hpbGUgbm90IGRlZ3Jh ZGluZyB0aGUgc2VjdXJpdHkgYXQgdGhlIHNhbWUgdGltZS4gDQoNCg0KTWF5IGJlIGl0IGlzIG1v cmUgYXBwcm9wcmlhdGUgdG8gc3VibWl0IHRvIENTSSBXRywgYnV0IEkgZm91bmQgbm8gdGltZSAN CnNsb3QgZm9yIHRoYXQgV0cuIA0KDQoNCg0KQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5j b20+INC009ogMjAxMi0wMy0wMSAyMzo0Mjo0MzoNCg0KPiBUaGFua3MgZm9yIHRoZSBhZ2VuZGEg cmVxdWVzdC4gIEl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IHdvdWxkIA0KPiBhbHNvIGFubm91 bmNlIGl0IG9uIHRoZSBpcHY2QGlldGYub3JnIG1haWxpbmcgbGlzdCAoZXhwbGFpbiB0aGUgDQo+ IHByb2JsZW1zIGl0IHNvbHZlcywgdGhlIG1vdGl2YXRpb24sIGV0Yy4pIGFuZCBzZWUgd2hhdCBw ZW9wbGUgdGhpbmsuDQo+IA0KPiBUaGFua3MsDQo+IEJvYg0KPiANCj4gT24gTWFyIDEsIDIwMTIs IGF0IDE6NDMgQU0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPiA+IA0KPiA+ IERlYXIgQ2hhaXJzLCANCj4gPiANCj4gPiAgICAgIEknZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1l IHNsb3QgZm9yIG15IG5ld2x5IHN1Ym1pdHRlZCBkcmFmdCANCj4gZHJhZnQtemhvdS02bWFuLW1o YXNoLWNnYS0wMCwgNSBtaW51dGVzIGlzIGVub3VnaCwgDQo+ID4gICBUaGFuayB5b3UhIA0KPiA+ IFJlZ2FyZHN+fn4NCj4gPiANCj4gPiAtU3VqaW5nIFpob3UgDQo+ID4gLS0tLS0g16q3osjLINbc y9W+sjAwMTMyODMxL3VzZXIvenRlX2x0ZCDKsbzkIDIwMTItMDMtMDEgMTc6NDEgLS0tLS0gDQo+ ID4gDQo+ID4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009ogMjAxMi0wMy0wMSAxNTo1ODoz NDoNCj4gPiANCj4gPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aG91LTZtYW4tbWhh c2gtY2dhLTAwLnR4dCBoYXMgYmVlbiANCj4gPiA+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg U3VqaW5nIFpob3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiANCnJlcG9zaXRvcnkuDQo+ID4gPiAN Cj4gPiA+IEZpbGVuYW1lOiAgICBkcmFmdC16aG91LTZtYW4tbWhhc2gtY2dhDQo+ID4gPiBSZXZp c2lvbjogICAgMDANCj4gPiA+IFRpdGxlOiAgICAgICBBbm90aGVyIFN1cHBvcnQgZm9yIE11bHRp cGxlIEhhc2ggQWxnb3JpdGhtcyBpbiANCj4gPiA+IENyeXB0b2dyYXBoaWNhbGx5IEdlbmVyYXRl ZCBBZGRyZXNzZXMgKENHQXMpDQo+ID4gPiBDcmVhdGlvbiBkYXRlOiAgICAyMDEyLTAzLTAxDQo+ ID4gPiBXRyBJRDogICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gPiBOdW1iZXIgb2Yg cGFnZXM6IDgNCj4gPiA+IA0KPiA+ID4gQWJzdHJhY3Q6DQo+ID4gPiAgICBUaGlzIGRvY3VtZW50 IHByb3ZpZGVzIGEgc3VwcG9ydCBmb3IgbXVsdGlwbGUgaGFzaCBhbGdvcml0aG1zIGluDQo+ID4g PiAgICBDcnlwdG9ncmFwaGljYWxseSBHZW5lcmF0ZWQgQWRkcmVzc2VzIChDR0FzKSBkZWZpbmVk IGluIFJGQyAzOTcyLg0KPiA+ID4gDQo+ID4gPiAgDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gPiA+IA0KPiANCj4gDQoNCg== --=_alternative 00021BCC482579B5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj50aGUgJm5ic3A7cHJvYmxlbXMgaXQgc29sdmVzOjwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 VGhlIGRyYWZ0IHByb3ZpZGVzIGEgc2ltcGxlDQptZXRob2Qgb2YgZW5jb2RpbmcgbXVsdGlwbGUg aGFzaCBmdW5jdGlvbiB0eXBlcyBpbiBhIENHQSBhZGRyZXNzLCBpdCBjYW4NCmJlIHRob3VnaHQg b2YgYXMgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5hbiBpbXByb3ZlbWVudCBv ciBhbiB1cGRhdGUgdG8gUkZDNDk4Mi4gJm5ic3A7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPnRoZSBtb3RpdmF0aW9uOjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkZDMzk3MiBkZWZpbmVkIENHQSAoY3J5 cHRvZ3JhcGhpY2FsbHkNCmdlbmVyYXRlZCBhZGRyZXNzKSBidXQgb25seSB1c2Ugb25lIGhhc2g6 U0hBLTEsIGl0IGlzIGhhcmRjb2RlZCBpbnRvIENHQS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFJGQzQ5ODIgcHJvcG9zZWQgdG8gZGVmaW5l IG11bHRpcGxlDQpoYXNoIGZ1bmN0aW9ucyBpbiBhIENHQSBhZGRyZXNzLCBieSByZXVzaW5nIDMg Yml0cyBTZWN1cml0eSBwYXJhbWV0ZXIgaW4NCmEgQ0dBLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPnNvIHByZXNlbnRhdGlvbiBvZiBzZWMgYW5kIGhhc2ggdG90YWxseSBvY2N1 cHkgMyBiaXRzLA0KYW5kIHNlYyBzaG91bGQgYmUgMH43LCBldmVuIGlmIHdlIG9ubHkgdXNlIGxv dyB2YWx1ZSBvZiAmbmJzcDtzZWMgOjAsMSwyLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+aG93IG11Y2ggaXMgbGVmdCBmb3IgaGFzaCBmdW5jdGlvbj8gOC8zICZsdDszICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyBzbyB0aGUg bW90aXZhdGlvbiBpcyB0cnlpbmcgdG8gZW5jb2RlDQptb3JlIGhhc2ggZnVuY3Rpb24gdHlwZXMg aW4gYSBDR0EgYWRkcmVzcyB3aGlsZSBub3QgZGVncmFkaW5nIHRoZSBzZWN1cml0eQ0KYXQgdGhl IHNhbWUgdGltZS4gPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5NYXkgYmUgaXQgaXMgbW9yZSBhcHByb3ByaWF0ZSB0byBzdWJtaXQgdG8gQ1NJIFdHLA0KYnV0 IEkgZm91bmQgbm8gdGltZSBzbG90IGZvciB0aGF0IFdHLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkJvYiBIaW5kZW4gJmx0O2JvYi5oaW5kZW5A Z21haWwuY29tJmd0OyDQtNPaIDIwMTItMDMtMDENCjIzOjQyOjQzOjxicj4NCjxicj4NCiZndDsg VGhhbmtzIGZvciB0aGUgYWdlbmRhIHJlcXVlc3QuICZuYnNwO0l0IHdvdWxkIGJlIGhlbHBmdWwg aWYgeW91IHdvdWxkDQo8YnI+DQomZ3Q7IGFsc28gYW5ub3VuY2UgaXQgb24gdGhlIGlwdjZAaWV0 Zi5vcmcgbWFpbGluZyBsaXN0IChleHBsYWluIHRoZSA8YnI+DQomZ3Q7IHByb2JsZW1zIGl0IHNv bHZlcywgdGhlIG1vdGl2YXRpb24sIGV0Yy4pIGFuZCBzZWUgd2hhdCBwZW9wbGUgdGhpbmsuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7IEJvYjxicj4NCiZndDsgPGJyPg0K Jmd0OyBPbiBNYXIgMSwgMjAxMiwgYXQgMTo0MyBBTSwgemhvdS5zdWppbmdAenRlLmNvbS5jbiB3 cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgRGVhciBDaGFp cnMsIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0knZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1lIHNsb3QgZm9yIG15IG5ld2x5 DQpzdWJtaXR0ZWQgZHJhZnQgPGJyPg0KJmd0OyBkcmFmdC16aG91LTZtYW4tbWhhc2gtY2dhLTAw LCA1IG1pbnV0ZXMgaXMgZW5vdWdoLCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IFRoYW5rIHlvdSEg PGJyPg0KJmd0OyAmZ3Q7IFJlZ2FyZHN+fn48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IC1TdWppbmcgWmhvdSA8YnI+DQomZ3Q7ICZndDsgLS0tLS0g16q3osjLINbcy9W+sjAwMTMyODMx L3VzZXIvenRlX2x0ZCDKsbzkIDIwMTItMDMtMDENCjE3OjQxIC0tLS0tIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009ogMjAxMi0wMy0w MSAxNTo1ODozNDo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LXpob3UtNm1hbi1taGFzaC1jZ2EtMDAudHh0IGhhcw0KYmVlbiA8 YnI+DQomZ3Q7ICZndDsgJmd0OyBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN1amluZyBaaG91 IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDtkcmFmdC16aG91LTZt YW4tbWhhc2gtY2dhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmV2aXNpb246ICZuYnNwOyAmbmJzcDsw MDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbm90aGVy IFN1cHBvcnQgZm9yIE11bHRpcGxlDQpIYXNoIEFsZ29yaXRobXMgaW4gPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgQ3J5cHRvZ3JhcGhpY2FsbHkgR2VuZXJhdGVkIEFkZHJlc3NlcyAoQ0dBcyk8YnI+DQom Z3Q7ICZndDsgJmd0OyBDcmVhdGlvbiBkYXRlOiAmbmJzcDsgJm5ic3A7MjAxMi0wMy0wMTxicj4N CiZndDsgJmd0OyAmZ3Q7IFdHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1 Ym1pc3Npb248YnI+DQomZ3Q7ICZndDsgJmd0OyBOdW1iZXIgb2YgcGFnZXM6IDg8YnI+DQomZ3Q7 ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIHN1cHBvcnQgZm9yIG11 bHRpcGxlDQpoYXNoIGFsZ29yaXRobXMgaW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i c3A7Q3J5cHRvZ3JhcGhpY2FsbHkgR2VuZXJhdGVkIEFkZHJlc3NlcyAoQ0dBcykNCmRlZmluZWQg aW4gUkZDIDM5NzIuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPC9mb250Pjwv dHQ+DQo= --=_alternative 00021BCC482579B5_=-- From internet-drafts@ietf.org Fri Mar 2 05:20:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E63B21F8AA1; Fri, 2 Mar 2012 05:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utAGB+IMt+qq; Fri, 2 Mar 2012 05:20:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8655821F8AA4; Fri, 2 Mar 2012 05:20:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-lineid-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302132050.2321.52428.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 05:20:50 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 13:20:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : The Line Identification Destination Option Author(s) : Suresh Krishnan Alan Kavanagh Balazs Varga Sven Ooghe Erik Nordmark Filename : draft-ietf-6man-lineid-03.txt Pages : 15 Date : 2012-03-02 In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-lineid-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-lineid-03.txt From fgont@si6networks.com Sat Mar 3 16:10:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD4021F8605 for ; Sat, 3 Mar 2012 16:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEDeC25ut7Kl for ; Sat, 3 Mar 2012 16:10:24 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id C880E21F85FD for ; Sat, 3 Mar 2012 16:10:23 -0800 (PST) Received: from [2001:5c0:1000:a::1db] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S3z1p-0003Os-WE; Sun, 04 Mar 2012 01:10:23 +0100 Message-ID: <4F52B2E9.3020400@si6networks.com> Date: Sat, 03 Mar 2012 21:10:17 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Rev'd I-D: Security Implications of Predictable IPv6 Fragment Identification values X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 00:10:24 -0000 Folks, We have published a revision of the aforementioned IETF Internet-Draft. The revised document is available at: . A diff from the previous version is available at: . This version incorporates lots of detailed feedback sent by Ivan Arce (Thanks Ivan!). Any comments will be welcome. Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-6man-predictable-fragment-id-01.txt Date: Sat, 03 Mar 2012 15:02:10 -0800 From: internet-drafts@ietf.org To: fgont@si6networks.com A new version of I-D, draft-gont-6man-predictable-fragment-id-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-predictable-fragment-id Revision: 01 Title: Security Implications of Predictable Fragment Identification Values Creation date: 2012-03-03 WG ID: Individual Submission Number of pages: 21 Abstract: IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field which, together with the IPv6 Source Address and the IPv6 Destination Address of the packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together at the receiving host. The only requirement for setting the "Identification" value is that it must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations simply use a global counter for setting the Fragment Identification field, thus leading to predictable values. This document analyzes the security implications of predictable Identification values, and updates RFC 2460 specifying additional requirements for setting the Fragment Identification, such that the aforementioned security implications are mitigated. The IETF Secretariat From zhou.sujing@zte.com.cn Sun Mar 4 17:43:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3745321F868A for ; Sun, 4 Mar 2012 17:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.11 X-Spam-Level: X-Spam-Status: No, score=-97.11 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlxfBflBzwwK for ; Sun, 4 Mar 2012 17:42:59 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A114F21F8639 for ; Sun, 4 Mar 2012 17:42:58 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 523731320096835; Mon, 5 Mar 2012 09:36:09 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 35739.1320096835; Mon, 5 Mar 2012 09:42:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q251ghjI015149 for ; Mon, 5 Mar 2012 09:42:43 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: ipv6@ietf.org Subject: Request for a time slot for "draft-zhou-6man-mhash-cga-00.txt" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 5 Mar 2012 09:42:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-05 09:42:44, Serialize complete at 2012-03-05 09:42:44 Content-Type: multipart/alternative; boundary="=_alternative 00096840482579B8_=" X-MAIL: mse01.zte.com.cn q251ghjI015149 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 01:43:00 -0000 This is a multipart message in MIME format. --=_alternative 00096840482579B8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIGFsbA0KICAgSSByZXF1ZXN0ZWQgZm9yIGEgdGltZSBzbG90IChpbiBwZW5kaW5nIHN0YXR1 cyBub3cgKSBmb3IgbXkgbmV3bHkgDQpzdWJtaXR0ZWQgZHJhZnQgZHJhZnQtemhvdS02bWFuLW1o YXNoLWNnYS0wMCwgDQppbiByZXNwb25zZSB0byByZXF1ZXN0ICBvZiBjaGFpcnMsIEkgZ2l2ZSBh IHNob3J0IGRlc2NyaXB0aW9pbiBoZXJlLCBhbnkgDQpjb21tZW50cyBhcmUgd2VsY29tZS4gDQoN CnRoZSAgcHJvYmxlbXMgaXQgc29sdmVzOiANCiAgICAgICAgVGhlIGRyYWZ0IHByb3ZpZGVzIGEg c2ltcGxlIG1ldGhvZCBvZiBlbmNvZGluZyBtdWx0aXBsZSBoYXNoIA0KIGZ1bmN0aW9uIHR5cGVz IGluIGEgQ0dBIGFkZHJlc3MsIGl0IGNhbiBiZSB0aG91Z2h0IG9mIGFzIA0KIGFuIGltcHJvdmVt ZW50IG9yIGFuIHVwZGF0ZSB0byBSRkM0OTgyLiANCiANCiB0aGUgbW90aXZhdGlvbjogDQogDQog ICAgICAgIFJGQzM5NzIgZGVmaW5lZCBDR0EgKGNyeXB0b2dyYXBoaWNhbGx5IGdlbmVyYXRlZCBh ZGRyZXNzKSBidXQNCiBvbmx5IHVzZSBvbmUgaGFzaDpTSEEtMSwgaXQgaXMgaGFyZGNvZGVkIGlu dG8gQ0dBLiANCiAgICAgICBSRkM0OTgyIHByb3Bvc2VkIHRvIGRlZmluZSBtdWx0aXBsZSBoYXNo IGZ1bmN0aW9ucyBpbiBhIENHQSANCiBhZGRyZXNzLCBieSByZXVzaW5nIDMgYml0cyBTZWN1cml0 eSBwYXJhbWV0ZXIgaW4gYSBDR0EsIA0KIHNvIHByZXNlbnRhdGlvbiBvZiBzZWMgYW5kIGhhc2gg dG90YWxseSBvY2N1cHkgMyBiaXRzLCBhbmQgc2VjIA0KIHNob3VsZCBiZSAwfjcsIGV2ZW4gaWYg d2Ugb25seSB1c2UgbG93IHZhbHVlIG9mICBzZWMgOjAsMSwyLCANCiBob3cgbXVjaCBpcyBsZWZ0 IGZvciBoYXNoIGZ1bmN0aW9uPyA4LzMgPDMgDQogICAgIHNvIHRoZSBtb3RpdmF0aW9uIGlzIHRy eWluZyB0byBlbmNvZGUgbW9yZSBoYXNoIGZ1bmN0aW9uIHR5cGVzIA0KIGluIGEgQ0dBIGFkZHJl c3Mgd2hpbGUgbm90IGRlZ3JhZGluZyB0aGUgc2VjdXJpdHkgYXQgdGhlIHNhbWUgdGltZS4gDQog DQogDQogTWF5IGJlIGl0IGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8gc3VibWl0IHRvIENTSSBXRywg YnV0IEkgZm91bmQgbm8gDQogdGltZSBzbG90IGZvciB0aGF0IFdHLiANCg0KQXJlIHlvdSBpbnRl cmVzdGVkIGluIGl0PyANCg0KIA0KPiANCj4gDQo+IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5AZ21h aWwuY29tPiDQtNPaIDIwMTItMDMtMDEgMjM6NDI6NDM6DQo+IA0KPiA+IFRoYW5rcyBmb3IgdGhl IGFnZW5kYSByZXF1ZXN0LiAgSXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3Ugd291bGQgDQo+ID4g YWxzbyBhbm5vdW5jZSBpdCBvbiB0aGUgaXB2NkBpZXRmLm9yZyBtYWlsaW5nIGxpc3QgKGV4cGxh aW4gdGhlIA0KPiA+IHByb2JsZW1zIGl0IHNvbHZlcywgdGhlIG1vdGl2YXRpb24sIGV0Yy4pIGFu ZCBzZWUgd2hhdCBwZW9wbGUgdGhpbmsuDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IEJvYg0KPiA+ IA0KPiA+IE9uIE1hciAxLCAyMDEyLCBhdCAxOjQzIEFNLCB6aG91LnN1amluZ0B6dGUuY29tLmNu IHdyb3RlOg0KPiA+IA0KPiA+ID4gDQo+ID4gPiBEZWFyIENoYWlycywgDQo+ID4gPiANCj4gPiA+ ICAgICAgSSdkIGxpa2UgdG8gcmVxdWVzdCBhIHRpbWUgc2xvdCBmb3IgbXkgbmV3bHkgc3VibWl0 dGVkIGRyYWZ0IA0KPiA+IGRyYWZ0LXpob3UtNm1hbi1taGFzaC1jZ2EtMDAsIDUgbWludXRlcyBp cyBlbm91Z2gsIA0KPiA+ID4gICBUaGFuayB5b3UhIA0KPiA+ID4gUmVnYXJkc35+fg0KPiA+ID4g DQo+ID4gPiAtU3VqaW5nIFpob3UgDQo+ID4gPiAtLS0tLSDXqreiyMsg1tzL1b6yMDAxMzI4MzEv dXNlci96dGVfbHRkIMqxvOQgMjAxMi0wMy0wMSAxNzo0MSAtLS0tLSANCg0KPiA+ID4gDQo+ID4g PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg0LTT2iAyMDEyLTAzLTAxIDE1OjU4OjM0Og0KPiA+ ID4gDQo+ID4gPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aG91LTZtYW4tbWhhc2gt Y2dhLTAwLnR4dCBoYXMgYmVlbiANCj4gPiA+ID4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBT dWppbmcgWmhvdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0KcmVwb3NpdG9yeS4NCj4gPiA+ID4g DQo+ID4gPiA+IEZpbGVuYW1lOiAgICBkcmFmdC16aG91LTZtYW4tbWhhc2gtY2dhDQo+ID4gPiA+ IFJldmlzaW9uOiAgICAwMA0KPiA+ID4gPiBUaXRsZTogICAgICAgQW5vdGhlciBTdXBwb3J0IGZv ciBNdWx0aXBsZSBIYXNoIEFsZ29yaXRobXMgaW4gDQo+ID4gPiA+IENyeXB0b2dyYXBoaWNhbGx5 IEdlbmVyYXRlZCBBZGRyZXNzZXMgKENHQXMpDQo+ID4gPiA+IENyZWF0aW9uIGRhdGU6ICAgIDIw MTItMDMtMDENCj4gPiA+ID4gV0cgSUQ6ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+ ID4gPiBOdW1iZXIgb2YgcGFnZXM6IDgNCj4gPiA+ID4gDQo+ID4gPiA+IEFic3RyYWN0Og0KPiA+ ID4gPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgc3VwcG9ydCBmb3IgbXVsdGlwbGUgaGFz aCBhbGdvcml0aG1zIA0KaW4NCj4gPiA+ID4gICAgQ3J5cHRvZ3JhcGhpY2FsbHkgR2VuZXJhdGVk IEFkZHJlc3NlcyAoQ0dBcykgZGVmaW5lZCBpbiBSRkMgDQozOTcyLg0KPiA+ID4gPiANCj4gPiA+ ID4gIA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ ID4gPiA+IA0KPiA+IA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0K --=_alternative 00096840482579B8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSwgYWxsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mbmJzcDsgJm5ic3A7SSByZXF1ZXN0ZWQgZm9yIGEgdGltZSBzbG90IChpbiBwZW5k aW5nDQpzdGF0dXMgbm93ICkgZm9yIG15IG5ld2x5IHN1Ym1pdHRlZCBkcmFmdCBkcmFmdC16aG91 LTZtYW4tbWhhc2gtY2dhLTAwLA0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5p biByZXNwb25zZSB0byByZXF1ZXN0ICZuYnNwO29mIGNoYWlycywgSSBnaXZlIGEgc2hvcnQNCmRl c2NyaXB0aW9pbiBoZXJlLCBhbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuIDwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dGhlICZuYnNwO3Byb2JsZW1zIGl0IHNvbHZlczog PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBkcmFmdCBwcm92aWRlcyBhIHNp bXBsZSBtZXRob2Qgb2YgZW5jb2RpbmcNCm11bHRpcGxlIGhhc2ggPGJyPg0KIGZ1bmN0aW9uIHR5 cGVzIGluIGEgQ0dBIGFkZHJlc3MsIGl0IGNhbiBiZSB0aG91Z2h0IG9mIGFzIDxicj4NCiBhbiBp bXByb3ZlbWVudCBvciBhbiB1cGRhdGUgdG8gUkZDNDk4Mi4gJm5ic3A7IDxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8YnI+DQogdGhlIG1vdGl2YXRpb246IDxicj4NCiA8YnI+DQogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkZDMzk3MiBkZWZpbmVkIENHQSAoY3J5cHRvZ3JhcGhpY2Fs bHkgZ2VuZXJhdGVkDQphZGRyZXNzKSBidXQ8YnI+DQogb25seSB1c2Ugb25lIGhhc2g6U0hBLTEs IGl0IGlzIGhhcmRjb2RlZCBpbnRvIENHQS4gPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJG QzQ5ODIgcHJvcG9zZWQgdG8gZGVmaW5lIG11bHRpcGxlIGhhc2ggZnVuY3Rpb25zDQppbiBhIENH QSA8YnI+DQogYWRkcmVzcywgYnkgcmV1c2luZyAzIGJpdHMgU2VjdXJpdHkgcGFyYW1ldGVyIGlu IGEgQ0dBLCA8YnI+DQogc28gcHJlc2VudGF0aW9uIG9mIHNlYyBhbmQgaGFzaCB0b3RhbGx5IG9j Y3VweSAzIGJpdHMsIGFuZCBzZWMgPGJyPg0KIHNob3VsZCBiZSAwfjcsIGV2ZW4gaWYgd2Ugb25s eSB1c2UgbG93IHZhbHVlIG9mICZuYnNwO3NlYyA6MCwxLDIsIDxicj4NCiBob3cgbXVjaCBpcyBs ZWZ0IGZvciBoYXNoIGZ1bmN0aW9uPyA4LzMgJmx0OzMgJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5i c3A7IHNvIHRoZSBtb3RpdmF0aW9uIGlzIHRyeWluZyB0byBlbmNvZGUgbW9yZSBoYXNoIGZ1bmN0 aW9uDQp0eXBlcyA8YnI+DQogaW4gYSBDR0EgYWRkcmVzcyB3aGlsZSBub3QgZGVncmFkaW5nIHRo ZSBzZWN1cml0eSBhdCB0aGUgc2FtZSB0aW1lLiA8YnI+DQogPGJyPg0KIDxicj4NCiBNYXkgYmUg aXQgaXMgbW9yZSBhcHByb3ByaWF0ZSB0byBzdWJtaXQgdG8gQ1NJIFdHLCBidXQgSSBmb3VuZCBu byA8YnI+DQogdGltZSBzbG90IGZvciB0aGF0IFdHLiA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkFyZSB5b3UgaW50ZXJlc3RlZCBpbiBpdD8gPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBCb2IgSGluZGVuICZsdDtib2IuaGluZGVuQGdtYWlsLmNvbSZndDsg0LTT2iAyMDEy LTAzLTAxIDIzOjQyOjQzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyBmb3IgdGhl IGFnZW5kYSByZXF1ZXN0LiAmbmJzcDtJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdQ0Kd291bGQg PGJyPg0KJmd0OyAmZ3Q7IGFsc28gYW5ub3VuY2UgaXQgb24gdGhlIGlwdjZAaWV0Zi5vcmcgbWFp bGluZyBsaXN0IChleHBsYWluIHRoZQ0KPGJyPg0KJmd0OyAmZ3Q7IHByb2JsZW1zIGl0IHNvbHZl cywgdGhlIG1vdGl2YXRpb24sIGV0Yy4pIGFuZCBzZWUgd2hhdCBwZW9wbGUNCnRoaW5rLjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhhbmtzLDxicj4NCiZndDsgJmd0OyBCb2I8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIE1hciAxLCAyMDEyLCBhdCAxOjQzIEFNLCB6 aG91LnN1amluZ0B6dGUuY29tLmNuIHdyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBEZWFyIENoYWlycywgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwO0knZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1lIHNsb3QgZm9yDQpteSBuZXdseSBzdWJtaXR0 ZWQgZHJhZnQgPGJyPg0KJmd0OyAmZ3Q7IGRyYWZ0LXpob3UtNm1hbi1taGFzaC1jZ2EtMDAsIDUg bWludXRlcyBpcyBlbm91Z2gsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBUaGFuayB5b3Uh IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlZ2FyZHN+fn48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAtU3VqaW5nIFpob3UgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0tLS0g 16q3osjLINbcy9W+sjAwMTMyODMxL3VzZXIvenRlX2x0ZCDKsbzkIDIwMTItMDMtMDENCjE3OjQx IC0tLS0tIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyDQtNPaIDIwMTItMDMtMDEgMTU6NTg6MzQ6PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtemhvdS02bWFuLW1oYXNoLWNnYS0wMC50eHQNCmhhcyBiZWVuIDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdWppbmcgWmhvdSBhbmQgcG9zdGVk IHRvDQp0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBGaWxlbmFtZTogJm5ic3A7ICZuYnNwO2RyYWZ0LXpob3UtNm1h bi1taGFzaC1jZ2E8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJldmlzaW9uOiAmbmJzcDsgJm5i c3A7MDA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyBBbm90aGVyIFN1cHBvcnQgZm9yIE11bHRpcGxlDQpIYXNoIEFsZ29yaXRobXMgaW4gPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBDcnlwdG9ncmFwaGljYWxseSBHZW5lcmF0ZWQgQWRkcmVzc2Vz IChDR0FzKTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZu YnNwOzIwMTItMDMtMDE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFdHIElEOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IE51bWJlciBvZiBwYWdlczogODxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDtUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgc3VwcG9ydCBmb3IgbXVsdGlwbGUNCmhhc2gg YWxnb3JpdGhtcyBpbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0NyeXB0 b2dyYXBoaWNhbGx5IEdlbmVyYXRlZCBBZGRyZXNzZXMNCihDR0FzKSBkZWZpbmVkIGluIFJGQyAz OTcyLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBJRVRGIFNl Y3JldGFyaWF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IGlwdjZAaWV0Zi5vcmc8YnI+DQomZ3Q7IEFkbWluaXN0cmF0 aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 00096840482579B8_=-- From Tina.Tsou.Zouting@huawei.com Sun Mar 4 20:48:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8529521F861C for ; Sun, 4 Mar 2012 20:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35KDAzmJyZQN for ; Sun, 4 Mar 2012 20:48:47 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E053A21F8605 for ; Sun, 4 Mar 2012 20:48:46 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0E00E7AAP7KT@szxga05-in.huawei.com> for ipv6@ietf.org; Mon, 05 Mar 2012 12:48:43 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0E00MY4AOO09@szxga05-in.huawei.com> for ipv6@ietf.org; Mon, 05 Mar 2012 12:48:43 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHO75090; Mon, 05 Mar 2012 12:48:42 +0800 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 05 Mar 2012 12:48:41 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.28]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Mon, 05 Mar 2012 12:48:32 +0800 Date: Mon, 05 Mar 2012 04:48:31 +0000 From: Tina TSOU Subject: FW: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt X-Originating-IP: [10.212.246.119] To: "ipv6@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt Thread-index: AQHM+oq3FVyzTTZNpkeA0Zu/u1EQ1pZbIHqg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 04:48:47 -0000 For your comment. http://datatracker.ietf.org/doc/draft-tsou-6man-hbh-header-update/ > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, March 04, 2012 8:45 PM > To: Tina TSOU > Cc: Sreenatha setty b > Subject: New Version Notification for draft-tsou-6man-hbh-header-update- > 00.txt > > A new version of I-D, draft-tsou-6man-hbh-header-update-00.txt has been > successfully submitted by Tina Tsou and posted to the IETF repository. > > Filename: draft-tsou-6man-hbh-header-update > Revision: 00 > Title: Update to the processing of the Hop-by-Hop Options extension > header > Creation date: 2012-03-04 > WG ID: Individual Submission > Number of pages: 5 > > Abstract: > The Hop-by-Hop Options header is used to convey optional information > that must be examined by every node along a packet's delivery path. > This document updates RFC2460, removing the requirement that source > nodes must process the Hop-by-Hop extension header, on the basis that > it imposes a performance impact with no advantages. > > > > > The IETF Secretariat From jeroen@unfix.org Mon Mar 5 01:41:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5621F86A2 for ; Mon, 5 Mar 2012 01:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsURtI4DmHW5 for ; Mon, 5 Mar 2012 01:41:18 -0800 (PST) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 23F0421F8690 for ; Mon, 5 Mar 2012 01:41:18 -0800 (PST) Received: from yomi.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id ABBF0801C2A0; Mon, 5 Mar 2012 10:40:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1330940475; bh=Q1iHS7mr++pAZWE+sMmkKFs3JFjPYlK+LZoXS8u7YvE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fHhq/XNza3AExYtUkzZ0pHLen5/vuyaS5hCuLbtEaJOj3xQzm4+wNI/k4pIPPA8NA 2cn54PsX85wVyEyKHzORpdNrcGffQZr6/5Ez4H7Ku4xhzEWCDDKwHe/aZrNZZy7s4t 5gvAbvVQl1vSVVlrbyU4iamBhv9oCyH8gcgdYtYSQIHK1D3ZmpkwqqdVZF/v87JCUh 5YCFedu0CAhGWPvt2SS6RWARYFCqOPEssF3uUqC8Z+/h/8ANFiwh9F1lmTqqljZY4v 09AOsscIUzbwVPXus5zv4Kc1rwoJwosj/e2mdDzD3gO5/hYI/f6x8maAFj3ibhg+Mi Jk0G5Xez9WxHg== Message-ID: <4F548A27.5030709@unfix.org> Date: Mon, 05 Mar 2012 10:40:55 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Stig Venaas Subject: Re: MLDv1 still in the wild? References: <4F4CD2CB.9010604@unfix.org> <4F4E3857.6000403@viagenie.ca> <4F4E8DD0.2040802@si6networks.com> <4F4EA253.4000408@venaas.com> In-Reply-To: <4F4EA253.4000408@venaas.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Behcet Sarikaya X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:41:19 -0000 On 2012-02-29 23:10 , Stig Venaas wrote: [..] > I think the main reason OpenBSD and NetBSD don't support SSM is > Apple's IPR claim. Without SSM support, there is little reason to > support MLDv2. > > I'm a bit curious about the reason for the question. At least MLDv2 > routers are supposed to support MLDv1 compatibility mode. It was mostly curiosity as for ecmh on request I added the option to disable MLDv1 handling completely, but I didn't recall anymore if there was really an upshot to it, though it makes the code smaller a little bit. >> However, RFC 5790, on Lightweight IGMP/MLD makes it easy to support >> SSM. I think there is open source support for 5790 somewhere. > > What it does is basically removing exclude mode for a non-empty > source list. It is still a lot of work compared to IGMPv2/MLDv1. > Apart from hosts in general, I can imagine a lot of special purpose > devices that never needs SSM to only implement MLDv1. MLDv1 is indeed quite easy, MLDv2 makes things a lot more complex, but given a bit more testing I should have it all baked into sixxsd v4 and then I finally can turn it on on all the SixXS PoPs instead of only a select few of them. Greets, Jeroen From tmacaulay@2keys.ca Mon Mar 5 04:34:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E54F21F86DD for ; Mon, 5 Mar 2012 04:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-D5aJD-yddO for ; Mon, 5 Mar 2012 04:34:18 -0800 (PST) Received: from mail.2keys.ca (mail.2keys.ca [72.1.200.74]) by ietfa.amsl.com (Postfix) with ESMTP id C233C21F86B9 for ; Mon, 5 Mar 2012 04:34:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.2keys.ca (Postfix) with ESMTP id 7098228110B for ; Mon, 5 Mar 2012 07:30:59 -0500 (EST) X-Virus-Scanned: amavisd-new at 2keys.ca Received: from mail.2keys.ca ([127.0.0.1]) by localhost (mail.2keys.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ja2e8dEUodT for ; Mon, 5 Mar 2012 07:30:55 -0500 (EST) Received: from mail.2keys.ca (mail.2keys.ca [192.168.1.103]) by mail.2keys.ca (Postfix) with ESMTP id 045D3281109 for ; Mon, 5 Mar 2012 07:30:55 -0500 (EST) Date: Mon, 05 Mar 2012 07:30:54 -0500 (EST) From: Tyson Macaulay To: ipv6@ietf.org Subject: Re: Question on Security Considerations for draft-macaulay-6man-packet-stain Message-ID: <7ecb96b9-0d53-4e21-a0e3-d2c2f7cc652c@Tysons-MacBook-Air.local> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Originating-IP: [99.241.179.111] X-Mailer: Zimbra 7.1.3_GA_3374 (Zimbra Desktop/7.1.2_10978_Mac) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 12:34:19 -0000 > > Hello Tyson. I have a few questions on your I-D about "IPv6 packet > staining". Let me start with one that concerns security > considerations. > > In Section 7, the I-D mentions reputational algorithms for cyber > intelligence and then it cautions implementers about unspecified > hazards > associated with the source of intelligence and the protection of the > algorithms. > > Where are the algorithms (mentioned in Section 7) to be applied? In > the > PMDs? At the end points? In a different locations or element > altogether?" HI Ed, The reputation algorithms used to derive reputation score for staining within Destination Options (DOs) would reside in an security application or service distinct from the packet manipulation device (PMD) used to apply the DOs. For instance, many security vendors currently have on-line repositories of intelligence available for query by their deployed products. Their algorithms reside close to, or possibly within, these service-delivery-points on the 'net. NOT within the vendor products deployed in the field. Similarly, the PMDs are probably not going to actually contain the algorithms used to obtain reputation scores from the correlation and aggregation of intelligence source. PMD will, however, need to consume the finished intelligence in as close to a real-time manner as possible, so reputation stains are as accurate as possible. Have said this - it is possible that a PMD vendor may elect to implement the algorithms within a PMD itself. For instance, for clients that need PMDs on the borders of different zones (for internal deployments), and want unique intelligence and reputations scores in each zone. > > Thanks in advance, > > Ed J. From jmh@joelhalpern.com Mon Mar 5 05:04:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD95621F86CA for ; Mon, 5 Mar 2012 05:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYlWwY+UkE7U for ; Mon, 5 Mar 2012 05:04:13 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 363E921F8546 for ; Mon, 5 Mar 2012 05:04:13 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 185B8CAED3 for ; Mon, 5 Mar 2012 05:04:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 662D91C3680; Mon, 5 Mar 2012 05:04:11 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-50-170.clppva.btas.verizon.net [71.161.50.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BF7EF1C367E; Mon, 5 Mar 2012 05:04:10 -0800 (PST) Message-ID: <4F54B9D1.4020302@joelhalpern.com> Date: Mon, 05 Mar 2012 08:04:17 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tina TSOU Subject: Re: FW: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 13:04:14 -0000 It seems likely to me that an efficient host implementation can meet the existing requirement relative to sourcing a packet with such options without noticeable load. So there does not seem any point in relaxing the requirement. And technically, if the host puts ina strict source route, and the first hop is not directly reachable, it really does need to drop it. So keeping the existing text has a minor benefit. Yours, Joel On 3/4/2012 11:48 PM, Tina TSOU wrote: > For your comment. > http://datatracker.ietf.org/doc/draft-tsou-6man-hbh-header-update/ > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Sunday, March 04, 2012 8:45 PM >> To: Tina TSOU >> Cc: Sreenatha setty b >> Subject: New Version Notification for draft-tsou-6man-hbh-header-update- >> 00.txt >> >> A new version of I-D, draft-tsou-6man-hbh-header-update-00.txt has been >> successfully submitted by Tina Tsou and posted to the IETF repository. >> >> Filename: draft-tsou-6man-hbh-header-update >> Revision: 00 >> Title: Update to the processing of the Hop-by-Hop Options extension >> header >> Creation date: 2012-03-04 >> WG ID: Individual Submission >> Number of pages: 5 >> >> Abstract: >> The Hop-by-Hop Options header is used to convey optional information >> that must be examined by every node along a packet's delivery path. >> This document updates RFC2460, removing the requirement that source >> nodes must process the Hop-by-Hop extension header, on the basis that >> it imposes a performance impact with no advantages. >> >> >> >> >> The IETF Secretariat > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From internet-drafts@ietf.org Mon Mar 5 12:25:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6907A11E80A3; Mon, 5 Mar 2012 12:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXQVeDuGaR90; Mon, 5 Mar 2012 12:25:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E251421F888B; Mon, 5 Mar 2012 12:25:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-6lobac-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305202558.26437.13093.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 12:25:58 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:25:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Transmission of IPv6 over MS/TP Networks Author(s) : Kerry Lynn Jerry Martocci Carl Neilson Stuart Donaldson Filename : draft-ietf-6man-6lobac-00.txt Pages : 17 Date : 2012-03-05 MS/TP (Master-Slave/Token-Passing) is a contention-free access method for the RS-485 physical layer that is used extensively in building automation networks. This document describes the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-6lobac-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-00.txt From brian@innovationslab.net Mon Mar 5 13:05:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BB521F8970 for ; Mon, 5 Mar 2012 13:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM2XAJnYCsot for ; Mon, 5 Mar 2012 13:05:23 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 34D0621F8971 for ; Mon, 5 Mar 2012 13:05:23 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 25C0288117; Mon, 5 Mar 2012 13:05:23 -0800 (PST) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id B39BC130017; Mon, 5 Mar 2012 13:05:22 -0800 (PST) Message-ID: <4F552A91.706@innovationslab.net> Date: Mon, 05 Mar 2012 16:05:21 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:05:23 -0000 All, This message starts a two-week 6MAN Working Group Last Call on advancing: Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-00.txt Pages : 7 Date : 2012-02-17 as a Proposed Standard. Substantive comments should be directed to the mailing list or the co-chairs. Editorial suggestions can be sent to the authors. This last call will end on March 19, 2012. Regards, Brian, Bob, & Ole From stig@venaas.com Mon Mar 5 13:26:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB4C21E803C for ; Mon, 5 Mar 2012 13:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7bxU6HvIfDX for ; Mon, 5 Mar 2012 13:26:07 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 1444B21F8901 for ; Mon, 5 Mar 2012 13:26:07 -0800 (PST) Received: from [10.33.12.84] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 828247FC4; Mon, 5 Mar 2012 22:26:05 +0100 (CET) Message-ID: <4F552F6B.9020204@venaas.com> Date: Mon, 05 Mar 2012 13:26:03 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: MLDv1 still in the wild? References: <4F4CD2CB.9010604@unfix.org> <4F4E3857.6000403@viagenie.ca> <4F4E8DD0.2040802@si6networks.com> <4F4EA253.4000408@venaas.com> In-Reply-To: <4F4EA253.4000408@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:26:08 -0000 On 2/29/2012 2:10 PM, Stig Venaas wrote: [...] > I think the main reason OpenBSD and NetBSD don't support SSM is > Apple's IPR claim. Without SSM support, there is little reason to > support MLDv2. I got some questions about this. See http://www.ietf.org/ietf-ftp/IPR/APPLE-SSM.txt See also e.g. http://marc.info/?l=snap-users&m=120819051424142 KAME did not add IGMPv3/MLDv2 to *BSD because of this. And as a result Mac OS X did not have IGMPv3/MLDv2 until recently. I'm not totally sure of the latter, but it is my understanding the latest OS X has full support. Stig > I'm a bit curious about the reason for the question. At least MLDv2 > routers are supposed to support MLDv1 compatibility mode. > >> However, RFC 5790, on Lightweight IGMP/MLD makes it easy to support >> SSM. I think there is open source support for 5790 somewhere. > > What it does is basically removing exclude mode for a non-empty > source list. It is still a lot of work compared to IGMPv2/MLDv1. > Apart from hosts in general, I can imagine a lot of special purpose > devices that never needs SSM to only implement MLDv1. > > Stig > >> Behcet >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From internet-drafts@ietf.org Mon Mar 5 13:51:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0377921F87BF; Mon, 5 Mar 2012 13:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhU7oiOOXP4r; Mon, 5 Mar 2012 13:51:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1B21F87D0; Mon, 5 Mar 2012 13:51:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-rfc3484bis-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305215134.21097.64257.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 13:51:34 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:51:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Default Address Selection for Internet Protocol version = 6 (IPv6) Author(s) : Dave Thaler Richard Draves Arifumi Matsumoto Tim Chown Filename : draft-ietf-6man-rfc3484bis-01.txt Pages : 30 Date : 2012-03-05 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484bis-01.txt From cabo@tzi.org Mon Mar 5 14:16:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1421F87F4 for ; Mon, 5 Mar 2012 14:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.342 X-Spam-Level: X-Spam-Status: No, score=-106.342 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIwoKTOqHWne for ; Mon, 5 Mar 2012 14:16:05 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 08CA321F87EE for ; Mon, 5 Mar 2012 14:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q25MFi4P017761; Mon, 5 Mar 2012 23:15:45 +0100 (CET) Received: from [192.168.217.105] (p54899EE6.dip.t-dialin.net [84.137.158.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 351B13EF; Mon, 5 Mar 2012 23:15:44 +0100 (CET) Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F552A91.706@innovationslab.net> Date: Mon, 5 Mar 2012 23:15:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> References: <4F552A91.706@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1257) Cc: ipv6@ietf.org, "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:16:05 -0000 This leaves me thoroughly confused. While the text seems to indicate the contrary, the ABNF makes it clear = that coap://[fe80::a%25en1]/.well-known/core is intended to indicate the zone ID of "25en1". This is the only place in a URI where a percent is proposed to be used = in stand-alone fashion -- everywhere else it occurs as part of = pct-encoded. For a good reason. E.g., this works perfectly to talk to localhost in Safari and Chrome: http://[%3a%3a1]/ Any other character but % (or []A-Fa-f0-9:] of course) would be less = confusing for indicating zone-ids. I'd recommend choosing one from = sub-delims, such as * or &. Gr=FC=DFe, Carsten From brian.e.carpenter@gmail.com Mon Mar 5 15:00:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C5521F87DA for ; Mon, 5 Mar 2012 15:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.364 X-Spam-Level: X-Spam-Status: No, score=-103.364 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyYlb9r+s5Hm for ; Mon, 5 Mar 2012 15:00:43 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6AC21F87B6 for ; Mon, 5 Mar 2012 15:00:43 -0800 (PST) Received: by iazz13 with SMTP id z13so7206443iaz.31 for ; Mon, 05 Mar 2012 15:00:42 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.42.162.194 as permitted sender) client-ip=10.42.162.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.42.162.194 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.42.162.194]) by 10.42.162.194 with SMTP id z2mr14536111icx.37.1330988442838 (num_hops = 1); Mon, 05 Mar 2012 15:00: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=fEd4cshkah2rADtqPXln/1vMGUoT8Ot32uSXqWeLlOw=; b=p09Eg92u53QgPFKQwfE6zPXFZGcE/MS734KkC1ce6l4iv2zd07EXlkTZOP2B/dUev6 AXHxlI9UBI9wyLVIcr/aGDFqpVo/FxThy0fIlU5EF/uCUPBnWJdnXuECm05Nqp8VOMBh AYpSmPQ00izXu04UNuBBvWJ6dCso4vA8Oq43XOH4j6r8irt//yJgT9NvI+gL303+Fdsk Rj5o+1SWm3RozwoNwtfzjuGR7fE/IXePv7YVrZKXRjzlU8DbMlhNNuHPq4ss9TlUYxoj ZxyooSHw7+3auxDj/71TD8cZeV9wl/e0OSHTn7FRfRH+pGTzgY8QvHmZAwckgLXZY+P9 HUvQ== Received: by 10.42.162.194 with SMTP id z2mr11981981icx.37.1330988442789; Mon, 05 Mar 2012 15:00:42 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id a9sm12773907igd.3.2012.03.05.15.00.39 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 15:00:41 -0800 (PST) Message-ID: <4F554595.7040801@gmail.com> Date: Tue, 06 Mar 2012 12:00:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> In-Reply-To: <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , ipv6@ietf.org, "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:00:44 -0000 No, I think it's exactly *not* confused on this point. There's a distinction between the idealised URI and the produced URI; in the produced URI, "%25" stands for "%" in the idealised URI. We have no real choice but to use % since that was chosen years ago, and that means that the produced URI contains %25. Brian On 2012-03-06 11:15, Carsten Bormann wrote: > This leaves me thoroughly confused. >=20 > While the text seems to indicate the contrary, the ABNF makes it clear = that >=20 > coap://[fe80::a%25en1]/.well-known/core >=20 > is intended to indicate the zone ID of "25en1". >=20 > This is the only place in a URI where a percent is proposed to be used = in stand-alone fashion -- everywhere else it occurs as part of pct-encode= d. For a good reason. >=20 > E.g., this works perfectly to talk to localhost in Safari and Chrome: > http://[%3a%3a1]/ >=20 > Any other character but % (or []A-Fa-f0-9:] of course) would be less co= nfusing for indicating zone-ids. I'd recommend choosing one from sub-del= ims, such as * or &. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From cabo@tzi.org Mon Mar 5 15:23:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910CB21E8035 for ; Mon, 5 Mar 2012 15:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2t+9NKAOjLd for ; Mon, 5 Mar 2012 15:23:29 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E366921E802D for ; Mon, 5 Mar 2012 15:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q25NMvL4011530; Tue, 6 Mar 2012 00:22:57 +0100 (CET) Received: from [192.168.217.105] (p54899EE6.dip.t-dialin.net [84.137.158.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D05CB419; Tue, 6 Mar 2012 00:22:56 +0100 (CET) Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F554595.7040801@gmail.com> Date: Tue, 6 Mar 2012 00:22:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) Cc: Brian Haberman , ipv6@ietf.org, "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:23:29 -0000 On Mar 6, 2012, at 00:00, Brian E Carpenter wrote: > No, I think it's exactly *not* confused on this point. There's > a distinction between the idealised URI and the produced URI; > in the produced URI, "%25" stands for "%" in the idealised URI. Ah, so the ABNF is wrong and the (vague) text is meant as I read it = first (it can be read in other ways). Replace IPv6addrz =3D IPv6address [ "%" ZoneID ] by IPv6addrz =3D IPv6address [ "%25" ZoneID ] > We have no real choice but to use % since that was chosen years > ago, and that means that the produced URI contains %25. I don't know that. You could use "percent" and that would work, too. Gr=FC=DFe, Carsten From brian.e.carpenter@gmail.com Mon Mar 5 16:15:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1673C21F881F for ; Mon, 5 Mar 2012 16:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.833 X-Spam-Level: X-Spam-Status: No, score=-102.833 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 385QB2SpnkKh for ; Mon, 5 Mar 2012 16:15:41 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 442FE21F881C for ; Mon, 5 Mar 2012 16:15:41 -0800 (PST) Received: by iazz13 with SMTP id z13so7294473iaz.31 for ; Mon, 05 Mar 2012 16:15:41 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.207.42 as permitted sender) client-ip=10.50.207.42; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.207.42 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.50.207.42]) by 10.50.207.42 with SMTP id lt10mr8851025igc.1.1330992941008 (num_hops = 1); Mon, 05 Mar 2012 16:15:41 -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=oynZouqhcqKppWpe2LDzC7VBvb400nDz8JtZnzGTbCQ=; b=F54jSJ8ZMUGTwTt4nvka7PzBMWRU4DOIl6dE8cHCMUvKzdOZXWGN7ICwLxiJHj5Gmh hLIFZYoZ168cEg0YDlVN5vhjvsi+/KPMqr3ALf2UUTSDujaz2qxLmhYyIukNQH9StDY0 H3J2KhXfot1/cOQLCT7CPhfCq3t2PAbjd8LcOBr3u6Rj+pnRSsHdZDAY8cronLB6ixaQ VVbu+XXYxOvIz70pvxuS00m3XY4NKtPqwRSVlCodmZrhbZLqEBWMJzmUj0bUN/1G3Qdk 27OGPaSqjawRXUhW4uVjGI+JE/rODuWOTNN5S7L0e+A44VyvbsASm4RiHEmSubYRLui0 Ie/Q== Received: by 10.50.207.42 with SMTP id lt10mr7337684igc.1.1330992940945; Mon, 05 Mar 2012 16:15:40 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id cx9sm12924898igc.12.2012.03.05.16.15.36 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 16:15:40 -0800 (PST) Message-ID: <4F55572F.50806@gmail.com> Date: Tue, 06 Mar 2012 13:15:43 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org, "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 00:15:42 -0000 Carsten, On 2012-03-06 12:22, Carsten Bormann wrote: > On Mar 6, 2012, at 00:00, Brian E Carpenter wrote: > >> No, I think it's exactly *not* confused on this point. There's >> a distinction between the idealised URI and the produced URI; >> in the produced URI, "%25" stands for "%" in the idealised URI. > > Ah, so the ABNF is wrong I don't believe so. The ABNF does not describe the produced (encoded) URI. I have read sections 2.2 and 2.4 of RFC 3986 several times before asserting this. Of course I could be wrong, but we are waiting for a review from uri-review@ietf.org who will hopefully give a definitive answer. > and the (vague) text is meant as I read it first (it can be read in other ways). Please indicate exactly which part of the text is ambiguous, and we'll change it. > > Replace > > IPv6addrz = IPv6address [ "%" ZoneID ] > > by > > IPv6addrz = IPv6address [ "%25" ZoneID ] No. In the encoded URI that would end up as %2525. That's exactly the trap that RFC 3986 warns against. > > >> We have no real choice but to use % since that was chosen years >> ago, and that means that the produced URI contains %25. > > I don't know that. You could use "percent" and that would work, too. We could use any unreserved symbol, but that would need translation from the RFC 4007 format. For example we could just use Z, as in http://[fe80::aZen1]. Or we could use ~: http://[fe80::a~en1]. Would that be less confusing? Brian From sreenatha.b@huawei.com Mon Mar 5 20:46:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C490921E8089 for ; Mon, 5 Mar 2012 20:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ReQ5BEb2Skd for ; Mon, 5 Mar 2012 20:46:19 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1721E808B for ; Mon, 5 Mar 2012 20:46:19 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G005CC57NTW@szxga04-in.huawei.com> for ipv6@ietf.org; Tue, 06 Mar 2012 12:45:23 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0G00JS057NIU@szxga04-in.huawei.com> for ipv6@ietf.org; Tue, 06 Mar 2012 12:45:23 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHG44201; Tue, 06 Mar 2012 12:45:10 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 12:44:30 +0800 Received: from blrprnc08ns (10.18.96.97) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server id 14.1.323.3; Tue, 06 Mar 2012 12:45:03 +0800 Date: Tue, 06 Mar 2012 10:15:02 +0530 From: sreenatha Subject: Re: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt In-reply-to: X-Originating-IP: [10.18.96.97] To: ipv6@ietf.org Message-id: <000701ccfb53$e5517540$aff45fc0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acz7CsMyCzhywqySRESYGC60ZG02FQARToKg X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Mon, 05 Mar 2012 23:47:27 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 04:46:19 -0000 Hi Joel, I am co-author of the draft. I will try to answer your query. "It seems likely to me that an efficient host implementation can meet the existing requirement relative to sourcing a packet with such options without noticeable load. So there does not seem any point in relaxing the requirement." As you said, efficient host implantation can meet the existing the requirement. But not all host will meet the requirement. So we suggesting solution, so that all host can be efficient in processing of the Hop-By-Hop header in source node. "And technically, if the host puts in a strict source route, and the first hop is not directly reachable, it really does need to drop it. So keeping the existing text has a minor benefit." Currently Strict Source route option will not come under Hop-by-Hop header. As we mentioned in the draft, only Jumbo-gram and MLd options apart from the padding options can be inserted in Hop-By-Hop header. Routing header will deal the Source route functionality. So our solution will not affect if host puts in a strict source route mode. Thanks- B.Sreenatha Setty Message: 5 Date: Mon, 05 Mar 2012 08:04:17 -0500 From: "Joel M. Halpern" To: Tina TSOU Cc: "ipv6@ietf.org" Subject: Re: FW: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt Message-ID: <4F54B9D1.4020302@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed It seems likely to me that an efficient host implementation can meet the existing requirement relative to sourcing a packet with such options without noticeable load. So there does not seem any point in relaxing the requirement. And technically, if the host puts ina strict source route, and the first hop is not directly reachable, it really does need to drop it. So keeping the existing text has a minor benefit. Yours, Joel From fenner@fenron.com Tue Mar 6 04:08:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456CA21F87DF for ; Tue, 6 Mar 2012 04:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.777 X-Spam-Level: X-Spam-Status: No, score=-101.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klRIdErEu+az for ; Tue, 6 Mar 2012 04:08:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A81E421F8901 for ; Tue, 6 Mar 2012 04:08:51 -0800 (PST) Received: by obbta4 with SMTP id ta4so3970815obb.31 for ; Tue, 06 Mar 2012 04:08:51 -0800 (PST) Received-SPF: pass (google.com: domain of fenner@fenron.com designates 10.182.141.9 as permitted sender) client-ip=10.182.141.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fenner@fenron.com designates 10.182.141.9 as permitted sender) smtp.mail=fenner@fenron.com Received: from mr.google.com ([10.182.141.9]) by 10.182.141.9 with SMTP id rk9mr9653189obb.50.1331035731329 (num_hops = 1); Tue, 06 Mar 2012 04:08:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.141.9 with SMTP id rk9mr8488297obb.50.1331035731230; Tue, 06 Mar 2012 04:08:51 -0800 (PST) Sender: fenner@fenron.com Received: by 10.182.125.70 with HTTP; Tue, 6 Mar 2012 04:08:51 -0800 (PST) In-Reply-To: <4F55572F.50806@gmail.com> References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> Date: Tue, 6 Mar 2012 07:08:51 -0500 X-Google-Sender-Auth: 51X6kgIJpTgiG3YE0WsMum7KR4w Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Bill Fenner To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl7Pcdg1g6NKYtnW3kHZ+sWmsnYDZv7HTg5jQgLRuEfyju3GqKoIq+7MQdwiOGh2GxaDLhl Cc: ipv6@ietf.org, Brian Haberman , S Moonesamy , "ipv6-chairs@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 12:08:52 -0000 On Mon, Mar 5, 2012 at 7:15 PM, Brian E Carpenter wrote: > Carsten, > > On 2012-03-06 12:22, Carsten Bormann wrote: >> On Mar 6, 2012, at 00:00, Brian E Carpenter wrote: >> >>> No, I think it's exactly *not* confused on this point. There's >>> a distinction between the idealised URI and the produced URI; >>> in the produced URI, "%25" stands for "%" in the idealised URI. >> >> Ah, so the ABNF is wrong > > I don't believe so. The ABNF does not describe the produced (encoded) > URI. I have read sections 2.2 and 2.4 of RFC 3986 several times > before asserting this. Of course I could be wrong, but we are waiting > for a review from uri-review@ietf.org who will hopefully give a > definitive answer. > >> and the (vague) text is meant as I read it first (it can be read in othe= r ways). > > Please indicate exactly which part of the text is ambiguous, and we'll > change it. > >> >> Replace >> >> =A0 =A0 =A0 IPv6addrz =3D IPv6address [ "%" ZoneID ] >> >> by >> >> =A0 =A0 =A0 IPv6addrz =3D IPv6address [ "%25" ZoneID ] > > No. In the encoded URI that would end up as %2525. That's exactly the > trap that RFC 3986 warns against. > >> >> >>> We have no real choice but to use % since that was chosen years >>> ago, and that means that the produced URI contains %25. >> >> I don't know that. =A0You could use "percent" and that would work, too. > > We could use any unreserved symbol, but that would need translation from > the RFC 4007 format. For example we could just use Z, as in > http://[fe80::aZen1]. > Or we could use ~: http://[fe80::a~en1]. > > Would that be less confusing? Previous joint work between the ipv6 working group and the W3C URI working group resulted in a decision that did not change the ABNF at all, in 2 ways: 1. It used the IPvFuture extension mechanism; 2. It used a non-percent character for the separator. At the time, the URI working group was very concerned about the change in the ABNF and the use of percent where percent had not previously been allowed. Have they changed their position here, or have they not had a chance to comment on this change yet? This work was accepted as an ipv6 wg work item around IETF63 (Paris, 2005), but the authors never pushed the document forward due to a lack of interest in the broader community. The draft that was adopted by the wg was http://tools.ietf.org/html/draft-fenner-literal-zone-01 Bill From brian.e.carpenter@gmail.com Tue Mar 6 13:08:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9097B21E80BF for ; Tue, 6 Mar 2012 13:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrW0pTO0mhC5 for ; Tue, 6 Mar 2012 13:08:38 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0D21E802A for ; Tue, 6 Mar 2012 13:08:17 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so3481258wgb.13 for ; Tue, 06 Mar 2012 13:08:16 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.180.86.105 as permitted sender) client-ip=10.180.86.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.180.86.105 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.180.86.105]) by 10.180.86.105 with SMTP id o9mr27285375wiz.4.1331068096121 (num_hops = 1); Tue, 06 Mar 2012 13:08:16 -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=U1VFWVKvtlaxAxBvm09SY/pZA+xF+qrkK1+QGKVbRqM=; b=vKXfuAqQHqAVUN8w3ckFLiT2kpb2KStEJ2h0t08ygrNLgpIR8tdGnO7A7Q7hgdZKwN JlRashxfaJQ/ZXzAzfxYtNsgkK5KZpU0Ntyfey7aKeirXSgjegtf8SrHWSaO7vXdF8f1 ojPQKT05O5FbyapzZq4OFDEBTTyVKXaA/1FVdD9+x7EkUHggFjyhQ9aPgmoavps4w3Tu NZhydQrg5LxJey8HK+a2+9dgyt1sVi+Cti0F+9eNEVm9O4uF32hEwrW9xEHqsbujhp3R tsFDHDb5QAr1snmu8Da+FFDEoaYeA7Xh/ZRBuS5Pvsbr2qL5SdbNOcaD1d6BMPCdsAOg fKOw== Received: by 10.180.86.105 with SMTP id o9mr21615383wiz.4.1331068096078; Tue, 06 Mar 2012 13:08:16 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id fl2sm84312305wib.4.2012.03.06.13.08.13 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 13:08:15 -0800 (PST) Message-ID: <4F567CB8.6000902@gmail.com> Date: Wed, 07 Mar 2012 10:08:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sreenatha Subject: Re: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt References: <000701ccfb53$e5517540$aff45fc0$@com> In-Reply-To: <000701ccfb53$e5517540$aff45fc0$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:08:38 -0000 Hi, > As we mentioned in the draft, only Jumbo-gram and MLd options apart > from the padding options can be inserted in Hop-By-Hop header. I don't understand this statement. MLD is a subset of Router Alert, and various other HbH options are defined: 0x26 Quick-Start [RFC4782] 0x7 CALIPSO [RFC5570] 0x63 RPL [RFC-to-be draft-ietf-6man-rpl-option] 0x1e (etc.) Experimental [RFC4727] I don't think we can assert that none of these need to be processed at the source without analysis, which is of course impossible for the experimental values or for unknown future options. I also think that stating that Router Alert doesn't need to be processed at the source is dubious. If the source is acting as both a host and a router (e.g. in an Internet Connection Sharing scenario), you would be courageous to state that there is no case in which node in its role as a router should look at a Router Alert that it set in its role as a host. It seems reasonable to state that implementors MAY omit processing at the source, if and only if they know by construction that no HbH option that requires local processing is created elsewhere in the host stack. But even so, they need the code to skip over the HbH extension header if present. We cannot replace if HbH header present, skip to next header by No-op Regards Brian Carpenter From brian.e.carpenter@gmail.com Tue Mar 6 14:08:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8786011E8072 for ; Tue, 6 Mar 2012 14:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.831 X-Spam-Level: X-Spam-Status: No, score=-102.831 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skck-yhwv-HV for ; Tue, 6 Mar 2012 14:08:30 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDA221F8621 for ; Tue, 6 Mar 2012 14:08:30 -0800 (PST) Received: by ggmi1 with SMTP id i1so2886430ggm.31 for ; Tue, 06 Mar 2012 14:08:30 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.236.181.233 as permitted sender) client-ip=10.236.181.233; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.236.181.233 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.236.181.233]) by 10.236.181.233 with SMTP id l69mr37703324yhm.32.1331071710003 (num_hops = 1); Tue, 06 Mar 2012 14:08:30 -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=Lwd0jn860xANgMtP/WYbgCOCrdRlAMZmVdBhV9PHdDY=; b=iD4ES/ZkSHTL8LRKOMO10FvLcxe4Dsa8QeoyEK9WPMIX3hlYtuJI5tq6PgfyMJMJMM EKg1TkhwDje15QhzlqvamKtnKnMMh9UM2ZYIpKgEnLVaIcCkjipFysDMkrZBd6MkYpXe 6yhhEW+iMdNbHo/j1yrGgDg7Pb6CJaTem7urlZIHnaZzgC3fSalruNP6Tz7BwAJ2ocOq QY4bBeR7VS9ZqHftuRHJOK1blM+AX4r9thMxWTEgc3STAJ9JLZ/sZkv0c3QHmxr5vX3/ OvJFfwgo5sZwTJUIWcjopEWwX+T0gZmynhY1RDvS49sX7oHCmVkPwRUQCZwKiqVmvL8F B0JA== Received: by 10.236.181.233 with SMTP id l69mr29947879yhm.32.1331071709862; Tue, 06 Mar 2012 14:08:29 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id j22sm32854563ann.0.2012.03.06.14.08.25 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 14:08:28 -0800 (PST) Message-ID: <4F568AD6.6070602@gmail.com> Date: Wed, 07 Mar 2012 11:08:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bill Fenner Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Brian Haberman , S Moonesamy , "ipv6-chairs@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:08:31 -0000 Hi Bill, On 2012-03-07 01:08, Bill Fenner wrote: > On Mon, Mar 5, 2012 at 7:15 PM, Brian E Carpenter > wrote: >> Carsten, >> >> On 2012-03-06 12:22, Carsten Bormann wrote: >>> On Mar 6, 2012, at 00:00, Brian E Carpenter wrote: >>> >>>> No, I think it's exactly *not* confused on this point. There's >>>> a distinction between the idealised URI and the produced URI; >>>> in the produced URI, "%25" stands for "%" in the idealised URI. >>> Ah, so the ABNF is wrong >> I don't believe so. The ABNF does not describe the produced (encoded) >> URI. I have read sections 2.2 and 2.4 of RFC 3986 several times >> before asserting this. Of course I could be wrong, but we are waiting >> for a review from uri-review@ietf.org who will hopefully give a >> definitive answer. >> >>> and the (vague) text is meant as I read it first (it can be read in other ways). >> Please indicate exactly which part of the text is ambiguous, and we'll >> change it. >> >>> Replace >>> >>> IPv6addrz = IPv6address [ "%" ZoneID ] >>> >>> by >>> >>> IPv6addrz = IPv6address [ "%25" ZoneID ] >> No. In the encoded URI that would end up as %2525. That's exactly the >> trap that RFC 3986 warns against. >> >>> >>>> We have no real choice but to use % since that was chosen years >>>> ago, and that means that the produced URI contains %25. >>> I don't know that. You could use "percent" and that would work, too. >> We could use any unreserved symbol, but that would need translation from >> the RFC 4007 format. For example we could just use Z, as in >> http://[fe80::aZen1]. >> Or we could use ~: http://[fe80::a~en1]. >> >> Would that be less confusing? > > Previous joint work between the ipv6 working group and the W3C URI > working group resulted in a decision that did not change the ABNF at > all, in 2 ways: > > 1. It used the IPvFuture extension mechanism; Hmm. I'm not sure that was a good choice. It certainly doesn't seem natural to me. Also it seems like more work for implementors than a small extension to the existing ABNF. What's so sacred? > 2. It used a non-percent character for the separator. Yes, and I have almost convinced myself that is better. The % is certainly the worst possible choice from a clarity viewpoint. > At the time, the URI working group was very concerned about the change > in the ABNF and the use of percent where percent had not previously > been allowed. Have they changed their position here, or have they not > had a chance to comment on this change yet? It's been sent for URI review but no reply so far. > > This work was accepted as an ipv6 wg work item around IETF63 (Paris, > 2005), but the authors never pushed the document forward due to a lack > of interest in the broader community. The draft that was adopted by > the wg was > > http://tools.ietf.org/html/draft-fenner-literal-zone-01 Recently there's been definite interest in this as an operational convenience. I was pretty much unaware of the 2005 work, since that was just when I joined the IESG and life was too busy, especially during the first Paris IETF. Was there a real reason that you went for this? IPv6zone-id = 1*( unreserved / sub-delims / ":" ) We have ZoneID = 1*( unreserved / pct-encoded ) which allows anything, having noted that some operating systems use all sorts of characters in interface names. Thanks Brian From cabo@tzi.org Tue Mar 6 14:26:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACFE21E80E6 for ; Tue, 6 Mar 2012 14:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIGrzOgtxv96 for ; Tue, 6 Mar 2012 14:26:30 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1B38421E8013 for ; Tue, 6 Mar 2012 14:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q26MQ8Lj010103; Tue, 6 Mar 2012 23:26:08 +0100 (CET) Received: from [192.168.217.105] (p5B3E6A25.dip.t-dialin.net [91.62.106.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DFA78991; Tue, 6 Mar 2012 23:26:07 +0100 (CET) Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F568AD6.6070602@gmail.com> Date: Tue, 6 Mar 2012 23:26:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) Cc: ipv6@ietf.org, Brian Haberman , Bill Fenner , "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:26:31 -0000 On Mar 6, 2012, at 23:08, Brian E Carpenter wrote: > Was there a real reason that you went for this? > IPv6zone-id =3D 1*( unreserved / sub-delims / ":" ) I'm not Bill, but RFC 3986 says: IPvFuture =3D "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" = ) So you can't go outside that space without updating RFC3986. I think the 2005 work hit the mark. Resurrect, publish, done. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Mar 6 14:43:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6394621E80DF for ; Tue, 6 Mar 2012 14:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.236 X-Spam-Level: X-Spam-Status: No, score=-106.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfi5QKFMUu+0 for ; Tue, 6 Mar 2012 14:43:39 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6337E21E80E3 for ; Tue, 6 Mar 2012 14:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q26MhMCx015773; Tue, 6 Mar 2012 23:43:23 +0100 (CET) Received: from [192.168.217.105] (p5B3E6A25.dip.t-dialin.net [91.62.106.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CCFBA994; Tue, 6 Mar 2012 23:43:21 +0100 (CET) Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F55572F.50806@gmail.com> Date: Tue, 6 Mar 2012 23:43:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F18ADF2-E7A2-4796-8D4A-850DE86107A7@tzi.org> References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) Cc: Brian Haberman , ipv6@ietf.org, "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:43:40 -0000 Given Bill's draft, we may not have to argue this, but: On Mar 6, 2012, at 01:15, Brian E Carpenter wrote: > The ABNF does not describe the produced (encoded) > URI. That is certainly *not* my understanding of RFC 3986. (It is true that a number of real-word implementations allow pct-encoded = in more places than the ABNF does. But being liberal in what you accept = is a rather usual way of non-compliance. Challenge: Find a real-world = URI not matched by the 3986 ABNF!) Gr=FC=DFe, Carsten From brian.e.carpenter@gmail.com Tue Mar 6 14:44:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8933621E8057 for ; Tue, 6 Mar 2012 14:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.427 X-Spam-Level: X-Spam-Status: No, score=-103.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dpdnnJvwX-7 for ; Tue, 6 Mar 2012 14:44:41 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1C5921E8014 for ; Tue, 6 Mar 2012 14:44:41 -0800 (PST) Received: by yenm5 with SMTP id m5so2897447yen.31 for ; Tue, 06 Mar 2012 14:44:41 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.236.155.6 as permitted sender) client-ip=10.236.155.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.236.155.6 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.236.155.6]) by 10.236.155.6 with SMTP id i6mr37017824yhk.87.1331073881458 (num_hops = 1); Tue, 06 Mar 2012 14:44:41 -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=K4tZyjmvVYIYgqHIZrveJIRMkkrWzyf0r/Ge+9+Stgw=; b=HxS8SesA+SgTh6f6rSaWb5MAg6lMWypslYc4zHNP3Scq6xnR/8t1/hO1V/Q5gJMm9F cyug3VFxzSMQ6piJS/RU5c/JHouCeMwLKrUHXGw2qe/sfHA9Mtsr++ah9OJLZYqPkU2T jrcsZ29aQqPAjHqCQTjijH7cyRwP5nQxOhhH3xw8ngGxE1nzmuYAHCZzkniPxAYH1pEA A1UsmQpWuKbgv8q1csOjzJjfdBrQ50ZZM4mqLYUKTieXpUHPT3aaYrplaW065fACGzoq WuS5LJcNWx/D4GgeIheJSsf+svZa8mTHw6UlwzXI3ENXF6UMEd+UZdiUFpUhks5tvLYH OEVQ== Received: by 10.236.155.6 with SMTP id i6mr29383794yhk.87.1331073881401; Tue, 06 Mar 2012 14:44:41 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id q5sm20614083anm.21.2012.03.06.14.44.37 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 14:44:40 -0800 (PST) Message-ID: <4F569353.3010603@gmail.com> Date: Wed, 07 Mar 2012 11:44:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> In-Reply-To: <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Brian Haberman , Bill Fenner , "ipv6-chairs@tools.ietf.org" , S Moonesamy X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:44:42 -0000 On 2012-03-07 11:26, Carsten Bormann wrote: > On Mar 6, 2012, at 23:08, Brian E Carpenter wrote: >=20 >> Was there a real reason that you went for this? >> IPv6zone-id =3D 1*( unreserved / sub-delims / ":" ) >=20 > I'm not Bill, but RFC 3986 says: >=20 > IPvFuture =3D "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":"= ) >=20 > So you can't go outside that space without updating RFC3986. That inserts a very ugly v6. at the front, which is definitely not what people want. The point is practical: we want to stick a zone ID on the end of an IPv6 literal. RFC 3986 is not sacred. Brian > I think the 2005 work hit the mark. Resurrect, publish, done. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 From kerlyn2001@gmail.com Tue Mar 6 16:25:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8228321E801F for ; Tue, 6 Mar 2012 16:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6-jn3OQrmwQ for ; Tue, 6 Mar 2012 16:25:53 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DECD21E800F for ; Tue, 6 Mar 2012 16:25:53 -0800 (PST) Received: by lagj5 with SMTP id j5so8128490lag.31 for ; Tue, 06 Mar 2012 16:25:52 -0800 (PST) Received-SPF: pass (google.com: domain of kerlyn2001@gmail.com designates 10.152.147.202 as permitted sender) client-ip=10.152.147.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kerlyn2001@gmail.com designates 10.152.147.202 as permitted sender) smtp.mail=kerlyn2001@gmail.com; dkim=pass header.i=kerlyn2001@gmail.com Received: from mr.google.com ([10.152.147.202]) by 10.152.147.202 with SMTP id tm10mr26306948lab.49.1331079952492 (num_hops = 1); Tue, 06 Mar 2012 16:25:52 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qR8XRntNT82bRj5Zkqeyz5WIt3m+IEhOPccHE+JjuEo=; b=WahF18ohMwiHRrt1CSkBpST8fyGYokh1OXP8G4kfhuDGk02eDDxWAwhB2bFiZpCQfZ YsdZ6R5oGA6ubRFouZltJofka9j/JWJ8WdDXQn1ckQYs9ts8mI9f2Cvma43pbPENGSIG b96CH/NIkAD3b1VJqX1zhoptodhtgLXyScNRv06uAg4H7AkhZxuYPZOqG5WBaGJGbPub NalBw4+G9CafRLEcs74+7e0uqrlRfWOk34/ql/6RmFhids9U7mpIsGB0zqMi77gLcLtl Y+85sZ7+oWPNxPexhNyMHQo9hjCGaRTR+d/Ze3am4m6ONruF2VOBB8eoiN7o1ru3D37L sPpw== MIME-Version: 1.0 Received: by 10.152.147.202 with SMTP id tm10mr21562785lab.49.1331079952397; Tue, 06 Mar 2012 16:25:52 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.86.196 with HTTP; Tue, 6 Mar 2012 16:25:52 -0800 (PST) In-Reply-To: <1F18ADF2-E7A2-4796-8D4A-850DE86107A7@tzi.org> References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <1F18ADF2-E7A2-4796-8D4A-850DE86107A7@tzi.org> Date: Tue, 6 Mar 2012 16:25:52 -0800 X-Google-Sender-Auth: vmdlkhREG4y2QHxZyorM2QT1MzQ Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Kerry Lynn To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 00:25:54 -0000 On Tue, Mar 6, 2012 at 2:43 PM, Carsten Bormann wrote: > Given Bill's draft, we may not have to argue this, but: > > On Mar 6, 2012, at 01:15, Brian E Carpenter wrote: > >> The ABNF does not describe the produced (encoded) >> URI. > > That is certainly *not* my understanding of RFC 3986. > > (It is true that a number of real-word implementations allow pct-encoded = in more places than the ABNF does. =A0But being liberal in what you accept = is a rather usual way of non-compliance. =A0Challenge: Find a real-world UR= I not matched by the 3986 ABNF!) > Not sure what you mean by a "real-world URI", but http://[fe80::206:98ff:fe00:232%tap0] *used* to work in Firefox, and probably still does in 3.6.x. They ripped out the capability specifically because it wasn't supported by the ABNF in 3986. -K- > Gr=FC=DFe, Carsten > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Mar 6 18:09:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8921E8048 for ; Tue, 6 Mar 2012 18:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.43 X-Spam-Level: X-Spam-Status: No, score=-103.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv6He4qBpEqx for ; Tue, 6 Mar 2012 18:09:22 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D607F21E8043 for ; Tue, 6 Mar 2012 18:09:21 -0800 (PST) Received: by yhpp34 with SMTP id p34so2981200yhp.31 for ; Tue, 06 Mar 2012 18:09:21 -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 :subject:content-type:content-transfer-encoding; bh=2aWFCCwmuh09Zz22yose5QthYdJXJAwy8KYdBulErlc=; b=i2Gdq+9sWbtKM5FMcIE6qNF0TVxxAIldWnbHVvsqNiNxtJiTA2WM+URM450yy/eByC 1e8mrfzsoESFRjY4zlYhQAfphGE4Kwtt8tZkrfiNZ9xHBd5W9Ke4X5PR4yCkGBShVNnp weCB3Iy1bNhB2pnn0Oin8opJWDWAqNXXjXxUuSOav5Ajz6IN6dNfjO/sguCj3asTQHc+ YJA0lNwzWIaO1sN+XevJYn4DZjKcK0/WKm5rh8wFBFed5dq2FZDPkeYt7zx9OUzHrl46 keTFgflgp3qjDDKWWXlw842NJ8ssTFcMVg2oc7/PJhRrPCIYVBTotNC3E6kMQ0ojgFbl /7bw== Received: by 10.236.170.163 with SMTP id p23mr690119yhl.36.1331086161522; Tue, 06 Mar 2012 18:09:21 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id p49sm3908052yhj.6.2012.03.06.18.09.19 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 18:09:20 -0800 (PST) Message-ID: <4F56C34C.3090708@gmail.com> Date: Wed, 07 Mar 2012 15:09:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Hash function comparisons for flow label generation Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 02:09:23 -0000 Hi 6man, I've just filed a technical report on some work we've done on actual performance of certain non-cryptographic hash functions, when used to generate flow labels for real-world IPv6 traffic traces from four different sites. It will get an official library handle soon, but here is an ad hoc URL to be going on with: http://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf If you don't want to read it, here's the conclusion: the FNV1a-32 algorithm, with the result XOR-folded to 20 bits, works very well for this purpose. -- Regards Brian Carpenter From fgont@si6networks.com Tue Mar 6 18:33:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F6121F8545 for ; Tue, 6 Mar 2012 18:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIwC4wqyCyL8 for ; Tue, 6 Mar 2012 18:33:30 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id C819F21F853B for ; Tue, 6 Mar 2012 18:33:30 -0800 (PST) Received: from [186.134.8.162] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S56gy-0003Pt-E0; Wed, 07 Mar 2012 03:33:28 +0100 Message-ID: <4F56C8E7.4000205@si6networks.com> Date: Tue, 06 Mar 2012 23:33:11 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Hash function comparisons for flow label generation References: <4F56C34C.3090708@gmail.com> In-Reply-To: <4F56C34C.3090708@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 02:33:31 -0000 Hi, Brian, On 03/06/2012 11:09 PM, Brian E Carpenter wrote: > It will get an official library handle soon, but here is an ad hoc > URL to be going on with: > > http://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf > > If you don't want to read it, here's the conclusion: the > FNV1a-32 algorithm, with the result XOR-folded to 20 bits, > works very well for this purpose. As noted on-list a while ago, I expected this to be the case for most "reasonable" algorithms. However, I personally think that one should simply set the FL to rand() (assuming a good PRNG), or use a hash based scheme as described in draft-gont-6man-flowlabel-security (if one is concerned about the reuse frequency) -- I'll be updating the forementioned I-D in that direction. As stated in RFC6437, the algorithm described in that document that not solve the problem of predictable FL, which I personally think should be a priority for any candidate algorithm. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From wesley.george@twcable.com Wed Mar 7 05:51:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF0321F87A0 for ; Wed, 7 Mar 2012 05:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEd6XAEKC02x for ; Wed, 7 Mar 2012 05:51:32 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A12521F879D for ; Wed, 7 Mar 2012 05:51:31 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,545,1325480400"; d="scan'208";a="333597765" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Mar 2012 08:51:05 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 7 Mar 2012 08:51:31 -0500 From: "George, Wes" To: "zhou.sujing@zte.com.cn" , "ipv6@ietf.org" Date: Wed, 7 Mar 2012 08:51:31 -0500 Subject: RE: Request for a time slot for "draft-zhou-6man-mhash-cga-00.txt" Thread-Topic: Request for a time slot for "draft-zhou-6man-mhash-cga-00.txt" Thread-Index: Acz6cVYiXR35DHh7RqaNTq9trelqfAB9nysg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 13:51:35 -0000 Tm90IGdvaW5nIHRvIGNvbW1lbnQgb24gdGhlIHByb3Bvc2VkIHByb3RvY29sIGNoYW5nZSBpdHNl bGYgeWV0LCBidXQgdGhpcyBkcmFmdCBpcyBtaXNzaW5nIHNvbWV0aGluZyB0aGF0IEkgdGhpbmsg aXMgZnVuZGFtZW50YWxseSBnYXRpbmcgdG8gaXQgbW92aW5nIGZvcndhcmQg4oCTDQoNCiAgIFRv IHByb3ZpZGUgYSBzdXBwb3J0IGZvcg0KICAgbXVsdGlwbGUgaGFzaCAqYWxnb3JpdGhtcywgYSBt ZXRob2Qgb2YgcmV1c2luZyB0aGUgc2VjdXJpdHkgcGFyYW1ldGVyDQogICBiaXRzIGluIHRoZSBh ZGRyZXNzIGlzICpzcGVjaWZpZWQgW1JGQyA0OTgyXSAuICBUaGlzIG1ldGhvZCBjYW4gb25seQ0K ICAgc3VwcG9ydCB0aHJlZSBoYXNoIGFsZ29yaXRobSBhdCBtb3N0LCBhbmQgYXQgdGhlIHNhbWUg dGltZSBsaW1pdGluZw0KICAgc2VjdXJpdHkgcGFyYW1ldGVyIHRvIGEgZmV3IHZhbHVlcy4NCg0K UGxlYXNlIGV4cGxhaW4gd2h5IOKAnG9ubHkgMyBoYXNoIGFsZ29yaXRobXMgYXQgbW9zdOKAnSBp cyB1bmFjY2VwdGFibGUsIHBsZWFzZSBleHBsYWluIHdoYXQgeW91IG1lYW4gYnkg4oCcbGltaXRp bmcgc2VjdXJpdHkgcGFyYW1ldGVyIHRvIGEgZmV3IHZhbHVlc+KAnSBhbmQgd2h5IHRoaXMgaXMg dW5kZXNpcmFibGUuIEluIG90aGVyIHdvcmRzLCB3aGF04oCZcyBhY3R1YWxseSBicm9rZW4gYW5k IHdoeSBzaG91bGQgd2Ug4oCcZml44oCdIGl0IHVzaW5nIHRoaXMgcHJvcG9zYWw/DQoNClRoaXMg aXMgY2xhaW1pbmcgdG8gbWFrZSBjaGFuZ2VzIHRvIENHQXMgaW4gYSB3YXkgdGhhdCBkb2VzIG5v dCBkb3duZ3JhZGUgdGhlIHNlY3VyaXR5IGxldmVsIG9mIENHQXMuIFRoZXJlIGlzIGEgYnVyZGVu IG9mIHByb29mIG5lY2Vzc2FyeSB0byBzdXBwb3J0IHRoYXQgYXNzZXJ0aW9uIHdoaWNoIGlzIGFs c28gY3VycmVudGx5IG1pc3NpbmcuDQoNClRoZXJlIGlzIGFsc28gbm8gZGlzY3Vzc2lvbiBvZiB3 aGV0aGVyIHRoZXJlIGFyZSBhbnkgZm9yd2FyZC9iYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3Vl cyBiZXR3ZWVuIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG9yIGRvIG5vdCBzdXBwb3J0IHRoaXMg cHJvcG9zZWQgY2hhbmdlLg0KDQpUaGUgKiBhYm92ZSByZXByZXNlbnRzIHNwZWxsaW5nIG5pdHMg dGhhdCBJIGNvcnJlY3RlZCBpbmxpbmUuDQoNClRoYW5rcywNCg0KV2VzIEdlb3JnZQ0KDQoNCkZy b206IGlwdjYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24NClNlbnQ6IFN1bmRheSwgTWFyY2gg MDQsIDIwMTIgODo0MyBQTQ0KVG86IGlwdjZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlcXVlc3QgZm9y IGEgdGltZSBzbG90IGZvciAiZHJhZnQtemhvdS02bWFuLW1oYXNoLWNnYS0wMC50eHQiDQoNCg0K SGksIGFsbA0KICAgSSByZXF1ZXN0ZWQgZm9yIGEgdGltZSBzbG90IChpbiBwZW5kaW5nIHN0YXR1 cyBub3cgKSBmb3IgbXkgbmV3bHkgc3VibWl0dGVkIGRyYWZ0IGRyYWZ0LXpob3UtNm1hbi1taGFz aC1jZ2EtMDAsDQppbiByZXNwb25zZSB0byByZXF1ZXN0ICBvZiBjaGFpcnMsIEkgZ2l2ZSBhIHNo b3J0IGRlc2NyaXB0aW9pbiBoZXJlLCBhbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCnRoZSAg cHJvYmxlbXMgaXQgc29sdmVzOg0KICAgICAgIFRoZSBkcmFmdCBwcm92aWRlcyBhIHNpbXBsZSBt ZXRob2Qgb2YgZW5jb2RpbmcgbXVsdGlwbGUgaGFzaA0KZnVuY3Rpb24gdHlwZXMgaW4gYSBDR0Eg YWRkcmVzcywgaXQgY2FuIGJlIHRob3VnaHQgb2YgYXMNCmFuIGltcHJvdmVtZW50IG9yIGFuIHVw ZGF0ZSB0byBSRkM0OTgyLg0KDQp0aGUgbW90aXZhdGlvbjoNCg0KICAgICAgIFJGQzM5NzIgZGVm aW5lZCBDR0EgKGNyeXB0b2dyYXBoaWNhbGx5IGdlbmVyYXRlZCBhZGRyZXNzKSBidXQNCm9ubHkg dXNlIG9uZSBoYXNoOlNIQS0xLCBpdCBpcyBoYXJkY29kZWQgaW50byBDR0EuDQogICAgICBSRkM0 OTgyIHByb3Bvc2VkIHRvIGRlZmluZSBtdWx0aXBsZSBoYXNoIGZ1bmN0aW9ucyBpbiBhIENHQQ0K YWRkcmVzcywgYnkgcmV1c2luZyAzIGJpdHMgU2VjdXJpdHkgcGFyYW1ldGVyIGluIGEgQ0dBLA0K c28gcHJlc2VudGF0aW9uIG9mIHNlYyBhbmQgaGFzaCB0b3RhbGx5IG9jY3VweSAzIGJpdHMsIGFu ZCBzZWMNCnNob3VsZCBiZSAwfjcsIGV2ZW4gaWYgd2Ugb25seSB1c2UgbG93IHZhbHVlIG9mICBz ZWMgOjAsMSwyLA0KaG93IG11Y2ggaXMgbGVmdCBmb3IgaGFzaCBmdW5jdGlvbj8gOC8zIDwzDQog ICAgc28gdGhlIG1vdGl2YXRpb24gaXMgdHJ5aW5nIHRvIGVuY29kZSBtb3JlIGhhc2ggZnVuY3Rp b24gdHlwZXMNCmluIGEgQ0dBIGFkZHJlc3Mgd2hpbGUgbm90IGRlZ3JhZGluZyB0aGUgc2VjdXJp dHkgYXQgdGhlIHNhbWUgdGltZS4NCg0KDQpNYXkgYmUgaXQgaXMgbW9yZSBhcHByb3ByaWF0ZSB0 byBzdWJtaXQgdG8gQ1NJIFdHLCBidXQgSSBmb3VuZCBubw0KdGltZSBzbG90IGZvciB0aGF0IFdH Lg0KDQpBcmUgeW91IGludGVyZXN0ZWQgaW4gaXQ/DQoNCg0KPg0KPg0KPiBCb2IgSGluZGVuIDxi b2IuaGluZGVuQGdtYWlsLmNvbT4g5YaZ5LqOIDIwMTItMDMtMDEgMjM6NDI6NDM6DQo+DQo+ID4g VGhhbmtzIGZvciB0aGUgYWdlbmRhIHJlcXVlc3QuICBJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlv dSB3b3VsZA0KPiA+IGFsc28gYW5ub3VuY2UgaXQgb24gdGhlIGlwdjZAaWV0Zi5vcmcgbWFpbGlu ZyBsaXN0IChleHBsYWluIHRoZQ0KPiA+IHByb2JsZW1zIGl0IHNvbHZlcywgdGhlIG1vdGl2YXRp b24sIGV0Yy4pIGFuZCBzZWUgd2hhdCBwZW9wbGUgdGhpbmsuDQo+ID4NCj4gPiBUaGFua3MsDQo+ ID4gQm9iDQo+ID4NCj4gPiBPbiBNYXIgMSwgMjAxMiwgYXQgMTo0MyBBTSwgemhvdS5zdWppbmdA enRlLmNvbS5jbiB3cm90ZToNCj4gPg0KPiA+ID4NCj4gPiA+IERlYXIgQ2hhaXJzLA0KPiA+ID4N Cj4gPiA+ICAgICAgSSdkIGxpa2UgdG8gcmVxdWVzdCBhIHRpbWUgc2xvdCBmb3IgbXkgbmV3bHkg c3VibWl0dGVkIGRyYWZ0DQo+ID4gZHJhZnQtemhvdS02bWFuLW1oYXNoLWNnYS0wMCwgNSBtaW51 dGVzIGlzIGVub3VnaCwNCj4gPiA+ICAgVGhhbmsgeW91IQ0KPiA+ID4gUmVnYXJkc35+fg0KPiA+ ID4NCj4gPiA+IC1TdWppbmcgWmhvdQ0KPiA+ID4gLS0tLS0g6L2s5Y+R5Lq6IOWRqOiLj+mdmTAw MTMyODMxL3VzZXIvenRlX2x0ZCDml7bpl7QgMjAxMi0wMy0wMSAxNzo0MSAtLS0tLQ0KPiA+ID4N Cj4gPiA+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyDlhpnkuo4gMjAxMi0wMy0wMSAxNTo1ODoz NDoNCj4gPiA+DQo+ID4gPiA+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aG91LTZtYW4t bWhhc2gtY2dhLTAwLnR4dCBoYXMgYmVlbg0KPiA+ID4gPiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFN1amluZyBaaG91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gPiA+ ID4NCj4gPiA+ID4gRmlsZW5hbWU6ICAgIGRyYWZ0LXpob3UtNm1hbi1taGFzaC1jZ2ENCj4gPiA+ ID4gUmV2aXNpb246ICAgIDAwDQo+ID4gPiA+IFRpdGxlOiAgICAgICBBbm90aGVyIFN1cHBvcnQg Zm9yIE11bHRpcGxlIEhhc2ggQWxnb3JpdGhtcyBpbg0KPiA+ID4gPiBDcnlwdG9ncmFwaGljYWxs eSBHZW5lcmF0ZWQgQWRkcmVzc2VzIChDR0FzKQ0KPiA+ID4gPiBDcmVhdGlvbiBkYXRlOiAgICAy MDEyLTAzLTAxDQo+ID4gPiA+IFdHIElEOiAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g PiA+ID4gTnVtYmVyIG9mIHBhZ2VzOiA4DQo+ID4gPiA+DQo+ID4gPiA+IEFic3RyYWN0Og0KPiA+ ID4gPiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgc3VwcG9ydCBmb3IgbXVsdGlwbGUgaGFz aCBhbGdvcml0aG1zIGluDQo+ID4gPiA+ICAgIENyeXB0b2dyYXBoaWNhbGx5IEdlbmVyYXRlZCBB ZGRyZXNzZXMgKENHQXMpIGRlZmluZWQgaW4gUkZDIDM5NzIuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4gPiA+DQo+ ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWlu Zywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0 Lg0K From fenner@fenron.com Wed Mar 7 06:22:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650A421F867D for ; Wed, 7 Mar 2012 06:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmmqGD7DMWJV for ; Wed, 7 Mar 2012 06:22:46 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D376121F84F2 for ; Wed, 7 Mar 2012 06:22:45 -0800 (PST) Received: by yenm5 with SMTP id m5so3243592yen.31 for ; Wed, 07 Mar 2012 06:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.25.41 with SMTP id z9mr905219oef.70.1331130165080; Wed, 07 Mar 2012 06:22:45 -0800 (PST) Sender: fenner@fenron.com Received: by 10.182.125.70 with HTTP; Wed, 7 Mar 2012 06:22:45 -0800 (PST) In-Reply-To: <4F569353.3010603@gmail.com> References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> <4F569353.3010603@gmail.com> Date: Wed, 7 Mar 2012 09:22:45 -0500 X-Google-Sender-Auth: uBbawUIybTtq-wwL_uXaSXh6QdI Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Bill Fenner To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm/mHxdE5602+tunhwVb0LfTHyuZyElfHYbJ3Ue6MFllawFTVvmikGXtaTzOKiUh56KNFWL Cc: "ipv6@ietf.org" , Brian Haberman , S Moonesamy , "ipv6-chairs@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 14:22:46 -0000 On Mar 6, 2012, at 5:44 PM, Brian E Carpenter wrote: > On 2012-03-07 11:26, Carsten Bormann wrote: >> On Mar 6, 2012, at 23:08, Brian E Carpenter wrote: >> >>> Was there a real reason that you went for this? >>> IPv6zone-id = 1*( unreserved / sub-delims / ":" ) >> >> I'm not Bill, but RFC 3986 says: >> >> IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) >> >> So you can't go outside that space without updating RFC3986. > > That inserts a very ugly v6. at the front, which is definitely not > what people want. You're not going to give people what they want. What people want is to use http://[v6addr%foo0]/, which I think we all agree is right out. Once you've strayed from that, you're not giving people what they want. > The point is practical: we want to stick a zone ID > on the end of an IPv6 literal. Yup. We wanted to do that in 2004 too. > RFC 3986 is not sacred. Of course it's not sacred. That doesn't mean we should change it without fully considering the ramifications. I think there are two issues here: 1. Should we use "%", "%25" or "something else"? These were the 3 options in http://tools.ietf.org/html/draft-fenner-literal-zone-01, and between the ipv6 working group and the URI working group we came to rough consensus on the "something else" side. 2. Should we use the IPvFuture ABNF or modify the IPv6address ABNF? I think there are much weaker feelings here - obviously it's easier to do something that matches a Full Standard rather than modify it, and for me personally the use case for this is so narrow (e.g., configuring a home gateway for the first time via HTTP) that it is not worth spending lots of cycles on it. On the concern of hosts using a scope ID that does not fit in the IPvFuture grammar, RFC4007 says that you SHOULD support a fully-numeric scope ID, so hopefully users will be able to use the fully-numeric form. (Again, this goes to the rare use case to me.) (Just a note about the use of "v6": the intent was to actually use "v1"; the change log at the end of -02 claims that it changed from "v6" to "v1" but the text didn't actually change. The version number is meant to be the version of the IPvFuture, not the version of the address inside it.) Bill From cabo@tzi.org Wed Mar 7 07:11:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6421F8631 for ; Wed, 7 Mar 2012 07:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.061 X-Spam-Level: X-Spam-Status: No, score=-107.061 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPff8cxLh5oN for ; Wed, 7 Mar 2012 07:11:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0E30421F861F for ; Wed, 7 Mar 2012 07:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q27FBPYH015542; Wed, 7 Mar 2012 16:11:26 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A8AA2DB6; Wed, 7 Mar 2012 16:11:25 +0100 (CET) Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 7 Mar 2012 16:11:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B0FFBFF-6660-4D32-9C27-1CDF35139FE0@tzi.org> References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> <4F569353.3010603@gmail.com> To: Bill Fenner X-Mailer: Apple Mail (2.1257) Cc: Brian Haberman , "ipv6@ietf.org" , S Moonesamy , "ipv6-chairs@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:11:47 -0000 On Mar 7, 2012, at 15:22, Bill Fenner wrote: >> RFC 3986 is not sacred. >=20 > Of course it's not sacred. =20 Not sacred, but is is also not open for gratuitous changes. I don't see a technical reason to do anything else than what you = proposed (i.e., not to stay within the confines of the standard). > On the concern of hosts using a > scope ID that does not fit in the IPvFuture grammar, RFC4007 says that > you SHOULD support a fully-numeric scope ID, so hopefully users will > be able to use the fully-numeric form. (Again, this goes to the rare > use case to me.) We could spec that fe80::1%foo\/bar is translated into fe80::1_foo_5c_2fbar if that is a real concern (i.e., do our own hex coding of unsupported = characters [and "_" then of course]). (I hope it isn't.) People who think they can build a URI with printf() are in for a = surprise in any case... > (Just a note about the use of "v6": the intent was to actually use > "v1"; the change log at the end of -02 claims that it changed from > "v6" to "v1" but the text didn't actually change. The version number > is meant to be the version of the IPvFuture, not the version of the > address inside it.) (I like v6 much better... (Would be v0, anyway, otherwise :-)) There doesn't seem to be a registry for these things, which should be = created in the process; IANA can allocate that number then, which would = move it out of the bike shed cycle. To make this all more concrete: The address: fe80::1%en1 becomes part of a URI like this: coap://[v6.fe80::1_en1]/... which is really easy to explain and document. Gr=FC=DFe, Carsten PS.: unfortunately, it also is cOAp://[V6.fe80::1_en1]/... Add a copy of 3986 3.1 An implementation should accept uppercase letters as equivalent to lowercase in ___ names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency. for good measure. From kerlyn2001@gmail.com Wed Mar 7 07:15:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA6A21F86D0 for ; Wed, 7 Mar 2012 07:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMopAHC-xvLn for ; Wed, 7 Mar 2012 07:15:19 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3620A21F86D7 for ; Wed, 7 Mar 2012 07:15:19 -0800 (PST) Received: by lagj5 with SMTP id j5so9013760lag.31 for ; Wed, 07 Mar 2012 07:15:18 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lkmAONhcXOeB3MEGMukORiux3gete+NFIZ4Kl8H5kbA=; b=I++JuMacO0c6DeIxUs6C9qjKnVWi3fT03w04Z/JSaAAXhCwLO1H66oF0i4snS79OTo H6Ic25O6/AZmVprN5/cnZdvUUd1l8AtSHaHjFOuzlSRMEVlSoB4ImkwruWfKo4hRa0CG +Kxsrdr4/TF28vpAf7OfaljYfQog3GQKT78a2wo5PuxxqK7Ngi/bdnBdMlxK3Ym9Oyzl DQe81IR//2tEleX8J2kZC70Yel6Lpax4+H2yuLrw+axYVeFyYdmRIUDJ5wwd1iJ0Ocki hD0MtzMouB6Synx09gnwGn19YRczvUSszmybU5P02YCMhrO8M1NLLPuQhh4F/prV4CZp bTOA== MIME-Version: 1.0 Received: by 10.152.130.234 with SMTP id oh10mr1755008lab.35.1331131665390; Wed, 07 Mar 2012 06:47:45 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.86.196 with HTTP; Wed, 7 Mar 2012 06:47:45 -0800 (PST) In-Reply-To: References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> <4F569353.3010603@gmail.com> Date: Wed, 7 Mar 2012 06:47:45 -0800 X-Google-Sender-Auth: ePgrY9wbvaw7b4CGkZTFh8ayfr4 Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Kerry Lynn To: Bill Fenner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:15:20 -0000 On Wed, Mar 7, 2012 at 6:22 AM, Bill Fenner wrote: > On Mar 6, 2012, at 5:44 PM, Brian E Carpenter > wrote: > >> On 2012-03-07 11:26, Carsten Bormann wrote: >>> On Mar 6, 2012, at 23:08, Brian E Carpenter wrote: >>> >>>> Was there a real reason that you went for this? >>>> IPv6zone-id =3D 1*( unreserved / sub-delims / ":" ) >>> >>> I'm not Bill, but RFC 3986 says: >>> >>> =A0 =A0 =A0IPvFuture =A0=3D "v" 1*HEXDIG "." 1*( unreserved / sub-delim= s / ":" ) >>> >>> So you can't go outside that space without updating RFC3986. >> >> That inserts a very ugly v6. at the front, which is definitely not >> what people want. > > You're not going to give people what they want. =A0What people want is > to use http://[v6addr%foo0]/, which I think we all agree is right out. > =A0Once you've strayed from that, you're not giving people what they > want. > >> The point is practical: we want to stick a zone ID >> on the end of an IPv6 literal. > > Yup. =A0We wanted to do that in 2004 too. > >> RFC 3986 is not sacred. > > Of course it's not sacred. =A0That doesn't mean we should change it > without fully considering the ramifications. > > I think there are two issues here: > > 1. Should we use "%", "%25" or "something else"? =A0These were the 3 > options in http://tools.ietf.org/html/draft-fenner-literal-zone-01, > and between the ipv6 working group and the URI working group we came > to rough consensus on the "something else" side. > What about "%%"? At least it's very close to the user's intention and models other ESC_ESC patterns (as in the C string "An escape sequence begins with a backslash \\"). > 2. Should we use the IPvFuture ABNF or modify the IPv6address ABNF? =A0I > think there are much weaker feelings here - obviously it's easier to > do something that matches a Full Standard rather than modify it, and > for me personally the use case for this is so narrow (e.g., > configuring a home gateway for the first time via HTTP) that it is not > worth spending lots of cycles on it. =A0On the concern of hosts using a > scope ID that does not fit in the IPvFuture grammar, RFC4007 says that > you SHOULD support a fully-numeric scope ID, so hopefully users will > be able to use the fully-numeric form. =A0(Again, this goes to the rare > use case to me.) > It's perhaps not as rare as you believe going forward. We're supposed to be adding 50B (pick your favorite number) devices to the Internet in the next ten years (pick your favorite timeframe) and not all of them will have, nor be configurable through, a global IPv6 address. -K- > (Just a note about the use of "v6": the intent was to actually use > "v1"; the change log at the end of -02 claims that it changed from > "v6" to "v1" but the text didn't actually change. =A0The version number > is meant to be the version of the IPvFuture, not the version of the > address inside it.) > > =A0Bill > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From kerlyn2001@gmail.com Wed Mar 7 07:29:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFCB21F878E for ; Wed, 7 Mar 2012 07:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3NaerzQ5FaC for ; Wed, 7 Mar 2012 07:29:10 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCDC21F872F for ; Wed, 7 Mar 2012 07:29:10 -0800 (PST) Received: by eeke51 with SMTP id e51so2349776eek.31 for ; Wed, 07 Mar 2012 07:29:09 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A+4QW/FBsNjqezHqZBUSguuxBKeb4VkPm4gJhqsCC54=; b=FWOJd8U5Ct4Wh7H8RmiiDZBBZVlOh1CAPsja4N/1Fm+IgDjfPnChbJ7cfGTVJRblwP 0TmxYtO4sKiIR6KBLnSMNBD6nbik2RoPtJEQFC17qMO60hapzVqJw8Gsw48n8Tuez8sp rgZfNHKh6Ey8PM4tMXLcu7M5d/6S/6t5sl3eMFSnJ8JquY9WwR5KoGVDhYTuyrGI3wpu GS5i4YwXkt8wTikjXzraFYu0Blg2HBvE3xWT2vgFQeQb55Uw3eafbk4DyDwRWpr2I43d hU9fOPQ+FHl6l5wydw/d+ujYNrt7H3iCbkYFoyuJeySI4yrKnS7SxTtY+a+2N56Rx/tK YT7w== MIME-Version: 1.0 Received: by 10.112.102.68 with SMTP id fm4mr896797lbb.7.1331134149690; Wed, 07 Mar 2012 07:29:09 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.86.196 with HTTP; Wed, 7 Mar 2012 07:29:09 -0800 (PST) In-Reply-To: <7B0FFBFF-6660-4D32-9C27-1CDF35139FE0@tzi.org> References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> <4F569353.3010603@gmail.com> <7B0FFBFF-6660-4D32-9C27-1CDF35139FE0@tzi.org> Date: Wed, 7 Mar 2012 07:29:09 -0800 X-Google-Sender-Auth: ouWcHU-vh0PnGbFXSOTS-YeCQVg Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Kerry Lynn To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:29:11 -0000 On Wed, Mar 7, 2012 at 7:11 AM, Carsten Bormann wrote: > On Mar 7, 2012, at 15:22, Bill Fenner wrote: > >>> RFC 3986 is not sacred. >> >> Of course it's not sacred. > > Not sacred, but is is also not open for gratuitous changes. > > I don't see a technical reason to do anything else than what you proposed= (i.e., not to stay within the confines of the standard). > Apparently this is why we all still use QWERTY keyboards :-) > To make this all more concrete: The address: > > =A0 =A0 =A0 =A0fe80::1%en1 > > becomes part of a URI like this: > > =A0 =A0 =A0 =A0coap://[v6.fe80::1_en1]/... > And hopefully coap://[v6.fdfd::1]/... would work as well? > which is really easy to explain and document. > > Gr=FC=DFe, Carsten From cabo@tzi.org Wed Mar 7 08:50:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9E221F8764 for ; Wed, 7 Mar 2012 08:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.835 X-Spam-Level: X-Spam-Status: No, score=-105.835 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uEihBrqSHFN for ; Wed, 7 Mar 2012 08:50:32 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id D330B21F8757 for ; Wed, 7 Mar 2012 08:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q27GoIur000448; Wed, 7 Mar 2012 17:50:18 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ECA30E50; Wed, 7 Mar 2012 17:50:17 +0100 (CET) Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 7 Mar 2012 17:50:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> <4F569353.3010603@gmail.com> <7B0FFBFF-6660-4D32-9C27-1CDF35139FE0@tzi.org> To: Kerry Lynn X-Mailer: Apple Mail (2.1257) Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:50:32 -0000 On Mar 7, 2012, at 16:29, Kerry Lynn wrote: > And hopefully coap://[v6.fdfd::1]/... would work as well? Oh. That may be a reason to go with v1, not v6... I don't think the idea is to *replace* IPv6address with IPvFuture. So I was thinking that this version of IPvFuture would be specifically = done for the zone_id case. So the v6 (or v1) serves as a kind of = advance warning "there will be a zone_id later). Gr=FC=DFe, Carsten From kerlyn2001@gmail.com Wed Mar 7 09:03:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADA121E80B6 for ; Wed, 7 Mar 2012 09:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiF4avN0mqHS for ; Wed, 7 Mar 2012 09:03:46 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAAF21E80B2 for ; Wed, 7 Mar 2012 09:03:45 -0800 (PST) Received: by eeke51 with SMTP id e51so2403265eek.31 for ; Wed, 07 Mar 2012 09:03:44 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OBVW+ElRUndT67rfUgsqgHf1G6y9wg2lloc9cAlZBHI=; b=yP3aOfKzuzODBX+LCTNUQwrQ6Fa88SYhWkZtmYki9HONrQmL7gfMCgTSyJzpYnjwS6 JB2Tq+8QuLD9wjD6r1tzgAVcACipJuklFr+wGFMDmjGyP4e0qm/OkM5F1fpmHrfhFJyi wVKOitZMczafjjaorVQzUwBD63Btkh/EvtdF08uFLGbIAmFzYRJwd+3R6ogmETsP0hKb IbJd3opZjHVO0P0yAZqITwTJPNE2rWTeDIeTY6ivAXAZGnTTCkMGaEdqok6mJdgNNP02 hyBkeECfa2I1HX30aTKMasgLi5FclihSW1D1jymXrxlDlmtrtAeY+e0BIKZlsvO38jFF LqsA== MIME-Version: 1.0 Received: by 10.112.102.68 with SMTP id fm4mr1022738lbb.7.1331139824481; Wed, 07 Mar 2012 09:03:44 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.86.196 with HTTP; Wed, 7 Mar 2012 09:03:44 -0800 (PST) In-Reply-To: References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> <4F569353.3010603@gmail.com> <7B0FFBFF-6660-4D32-9C27-1CDF35139FE0@tzi.org> Date: Wed, 7 Mar 2012 09:03:44 -0800 X-Google-Sender-Auth: cyV2vEE1nY6a0QWKidOa8AnP_pQ Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Kerry Lynn To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:03:46 -0000 On Wed, Mar 7, 2012 at 8:50 AM, Carsten Bormann wrote: > On Mar 7, 2012, at 16:29, Kerry Lynn wrote: > >> And hopefully coap://[v6.fdfd::1]/... would work as well? > > Oh. =A0That may be a reason to go with v1, not v6... > > I don't think the idea is to *replace* IPv6address with IPvFuture. > So I was thinking that this version of IPvFuture would be specifically do= ne for the zone_id case. > So the v6 (or v1) serves as a kind of advance warning "there will be a zo= ne_id later). > As an implementor, I'd prefer a solution that works for all legal IPv6 addresses going forward. It's not outside the realm of possibility that these URIs may be constructed by constrained devices with multiple interfaces (maybe that begins to test the definition of "constrained") and I'd prefer not to have to special case link-local addresses. My $0.02, -K- > Gr=FC=DFe, Carsten > From j.schoenwaelder@jacobs-university.de Wed Mar 7 09:07:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9C121E801B for ; Wed, 7 Mar 2012 09:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEu-zLoEmA+N for ; Wed, 7 Mar 2012 09:07:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7326321E80B2 for ; Wed, 7 Mar 2012 09:07:12 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5C0120D13; Wed, 7 Mar 2012 18:07:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e4EwJO5SbOdu; Wed, 7 Mar 2012 18:07:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED90420D14; Wed, 7 Mar 2012 18:07:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0EDF21DA870F; Wed, 7 Mar 2012 18:07:09 +0100 (CET) Date: Wed, 7 Mar 2012 18:07:08 +0100 From: Juergen Schoenwaelder To: Carsten Bormann Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt Message-ID: <20120307170708.GA6113@elstar.local> Mail-Followup-To: Carsten Bormann , Brian E Carpenter , ipv6@ietf.org, Brian Haberman , Bill Fenner , "ipv6-chairs@tools.ietf.org" , S Moonesamy References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brian Haberman , ipv6@ietf.org, Bill Fenner , S Moonesamy , "ipv6-chairs@tools.ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:07:13 -0000 On Tue, Mar 06, 2012 at 11:26:06PM +0100, Carsten Bormann wrote: > On Mar 6, 2012, at 23:08, Brian E Carpenter wrote: > > > Was there a real reason that you went for this? > > IPv6zone-id = 1*( unreserved / sub-delims / ":" ) > > I'm not Bill, but RFC 3986 says: > > IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) > > So you can't go outside that space without updating RFC3986. > At least Juniper boxes use interface names such as fe-0/0/1 (that is they include forward slashes) and my understanding is that those names won't fit into IPvFuture: IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" RFC 4007 does not really restrict the characters allowed in zone identifiers and hence it seems to me that we can't simply assume zone identifiers are always consistent with IPvFuture. (But I might as well be missing something.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From brian.e.carpenter@gmail.com Wed Mar 7 11:27:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A5C11E8086 for ; Wed, 7 Mar 2012 11:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9LS1-+lUnpT for ; Wed, 7 Mar 2012 11:27:03 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2411E807F for ; Wed, 7 Mar 2012 11:27:02 -0800 (PST) Received: by werb10 with SMTP id b10so5238087wer.31 for ; Wed, 07 Mar 2012 11:27:02 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HQNxBe+Ha/gYBmj0x1f5sWlpCgZttnPMeIZ3DGqBl4g=; b=UktJgjvaGHy5v7sjcaVLb8lVd/sAwAFLDxkBnVpWJCIWbhfClmhxdp85I8JiKEjPPJ VN7uEEG9sY/OukAz6WYJHUyCqJEebQUkNYAHhBAa8E0Sw0HPyxfPHzo3ClFDe2q1NnL7 g2B77yuF7Cbh22t3xOF6NXty+sgmFOa3RmPFr6PDQV4qqs+TSyOV1FsECav2vtnsmBWZ FXy4uMet2GCNL6e+lD5a2QaR6Pl9m6s3AWJZSPkJlBLXSOEjovemOUCdgwzqusICKotA QhGcgSfRkRv7gzl7EDQePEYwVXZEZHD2TaeVZK0V+W5KBCM9Y8cRllqnuWfNxh9fzGKD 8NFQ== Received: by 10.180.99.100 with SMTP id ep4mr6394242wib.7.1331148422287; Wed, 07 Mar 2012 11:27:02 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id gf3sm37969780wib.6.2012.03.07.11.26.56 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 11:27:00 -0800 (PST) Message-ID: <4F57B678.30000@gmail.com> Date: Thu, 08 Mar 2012 08:26:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Carsten Bormann , ipv6@ietf.org, Brian Haberman , Bill Fenner , "ipv6-chairs@tools.ietf.org" , S Moonesamy Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt References: <4F552A91.706@innovationslab.net> <491511B4-6EF7-4052-9A54-9C5A7DF5CC5C@tzi.org> <4F554595.7040801@gmail.com> <4F55572F.50806@gmail.com> <4F568AD6.6070602@gmail.com> <0C883703-1F07-495D-A043-602AA9E83405@tzi.org> <20120307170708.GA6113@elstar.local> In-Reply-To: <20120307170708.GA6113@elstar.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:27:03 -0000 On 2012-03-08 06:07, Juergen Schoenwaelder wrote: > On Tue, Mar 06, 2012 at 11:26:06PM +0100, Carsten Bormann wrote: >> On Mar 6, 2012, at 23:08, Brian E Carpenter wrote: >> >>> Was there a real reason that you went for this? >>> IPv6zone-id = 1*( unreserved / sub-delims / ":" ) >> I'm not Bill, but RFC 3986 says: >> >> IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) >> >> So you can't go outside that space without updating RFC3986. >> > > At least Juniper boxes use interface names such as fe-0/0/1 (that is > they include forward slashes) and my understanding is that those names > won't fit into IPvFuture: > > IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) > > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > sub-delims = "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=" > > RFC 4007 does not really restrict the characters allowed in zone > identifiers and hence it seems to me that we can't simply assume zone > identifiers are always consistent with IPvFuture. (But I might as > well be missing something.) What this discussion seems to be missing is that normal, sane operational people do not want one format for literal addresses without a zone index and another format for literal addresses with a zone index. I fully agree to replacing the ugly %25 with _. But I can't see a single argument from the user point of view for the IPvFuture construct. This change is for users (specialists, but they are still users), not for URI theorists. I'm not sure we can accommodate names such as the Juniper ones without including pct-encoded. Brian From ted.ietf@gmail.com Wed Mar 7 12:06:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0657411E80A1 for ; Wed, 7 Mar 2012 12:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz7kMW6Ve9qn for ; Wed, 7 Mar 2012 12:06:58 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7611E809D for ; Wed, 7 Mar 2012 12:06:58 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so6667178vcb.31 for ; Wed, 07 Mar 2012 12:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yp8DWac9QjqbjgFOECD1vli2kWoZdrDYSaqKshgw3X8=; b=dDMfEMIgyQ1xqWAR2+LjrvMZg7ueP+gGLjn6LqBWpDzMRl0tBfef1tNcV1mpScgnJl CDZRCaUx+QwkQ1oP6r97bu06h+7lJj4RGhHwykWVlXfdUKVr3mplNnNYhy6cVXRO8WgZ NuNyCaexUAgAD0W1zRSxoPY89j54twqhuD96okQV9UwzFCFV+qApB2Y+I3zJ1ejlYBbo jmv+GDC7hS2iYbrHYtZsMnWnod+kXci0/9BRTWEReCuo/6/VVpRwD+CVBNc6QW4xgNoT FiGsGArwblr0zEX+PiGOZ3X/FJGcmTINI+MLLq/ZDRnPl/wJb9xNBv2kL3+uSkQ1NNB/ 128w== MIME-Version: 1.0 Received: by 10.52.180.38 with SMTP id dl6mr3979100vdc.105.1331150817617; Wed, 07 Mar 2012 12:06:57 -0800 (PST) Received: by 10.52.115.66 with HTTP; Wed, 7 Mar 2012 12:06:57 -0800 (PST) Date: Wed, 7 Mar 2012 12:06:57 -0800 Message-ID: Subject: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Ted Hardie To: ipv6@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:06:59 -0000 Howdy, Jumping a bit late on this, my apologies. I've tried to keep the attributions below, but if I got them wrong, please correct them. My own text is prefaced with Brian Carpenter wrote: >Bill Fenner wrote: > > Previous joint work between the ipv6 working group and the W3C URI Just as a side note, the URI mailing list is hosted by the W3C, but the working group was an IETF working group and that list is still used by the IETF and W3C jointly for discussions in this area. > working group resulted in a decision that did not change the ABNF at > all, in 2 ways: > > 1. It used the IPvFuture extension mechanism; Hmm. I'm not sure that was a good choice. It certainly doesn't seem natural to me. Also it seems like more work for implementors than a small extension to the existing ABNF. What's so sacred? This actually doesn't turn out to be a small change. The draft gives this production IPv6addrz = IPv6address [ "%" ZoneID ] but the use of a "%" that is not used in escaping is contrary to the basic URI syntax--this is made clear in Section 2.4 of RFC 3986; changing that would require a major re-write to URI parsers. > 2. It used a non-percent character for the separator. Yes, and I have almost convinced myself that is better. The % is certainly the worst possible choice from a clarity viewpoint. > At the time, the URI working group was very concerned about the change > in the ABNF and the use of percent where percent had not previously > been allowed. Have they changed their position here, or have they not > had a chance to comment on this change yet? It's been sent for URI review but no reply so far. I'm on the relevant list (uri-review@ietf.org) and I have not seen this document there. Can you resend the request for review? > > This work was accepted as an ipv6 wg work item around IETF63 (Paris, > 2005), but the authors never pushed the document forward due to a lack > of interest in the broader community. The draft that was adopted by > the wg was > > http://tools.ietf.org/html/draft-fenner-literal-zone-01 Recently there's been definite interest in this as an operational convenience. I was pretty much unaware of the 2005 work, since that was just when I joined the IESG and life was too busy, especially during the first Paris IETF. Was there a real reason that you went for this? IPv6zone-id = 1*( unreserved / sub-delims / ":" ) We have ZoneID = 1*( unreserved / pct-encoded ) which allows anything, having noted that some operating systems use all sorts of characters in interface names. If there is a fundamental change in the limitations which are set out in Bill's draft's section 3, it would be useful to set them out. As it stands, I haven't seen any changes that would cause a change, but this would be useful to describe them if they have happened. regards, Ted Hardie From brian.e.carpenter@gmail.com Wed Mar 7 13:47:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0811E80AE for ; Wed, 7 Mar 2012 13:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdPah7OmKeAJ for ; Wed, 7 Mar 2012 13:47:20 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7988911E80A3 for ; Wed, 7 Mar 2012 13:47:20 -0800 (PST) Received: by yenm5 with SMTP id m5so3621519yen.31 for ; Wed, 07 Mar 2012 13:47:20 -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=hZN78t2/06fHePvMpjC9X8CsRnqPA+eV/anrYM7Ibjc=; b=TCZLvA6hVHiIvqKV/iGKe9VaKteUwKH72nEhMzxSYrTNY9qdLO/XKqYqs3VqqD9cGy XlvoPQeuPrDi0QFjXS8hSi/DzRoG3cxR6WFhEyqVKynKTy362MBSFQ6lh6wF9ownUDzn y9+/OXl9YTNn6EbxeVNlK1cykIWYM1TaFHFk3SQidD1R16A1K1v1LWkoJPyS8U6T26iY ML0v6NgQqUT5+oAk9HnDWpbH5KWeSWLhL+oIsl8vwvfIWi/2TJvxxMsExRcREsTPpdHQ fA3VI/koPlPiqO9s8Qh0jScuE85juUtA2CLs0RWv2dczpw84jXyv8jiNbLjYFDd4059w fz3Q== Received: by 10.236.154.168 with SMTP id h28mr7191798yhk.59.1331156840070; Wed, 07 Mar 2012 13:47:20 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n10sm38942354ani.8.2012.03.07.13.47.16 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 13:47:18 -0800 (PST) Message-ID: <4F57D760.8080508@gmail.com> Date: Thu, 08 Mar 2012 10:47:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Hardie Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:47:21 -0000 Hi Ted, On 2012-03-08 09:06, Ted Hardie wrote: > Howdy, > > Jumping a bit late on this, my apologies. I've tried to keep the > attributions below, but if I got them wrong, please correct them. > My own text is prefaced with > > Brian Carpenter wrote: >> Bill Fenner wrote: >> >> Previous joint work between the ipv6 working group and the W3C URI > > Just as a side note, the URI mailing list is hosted by the W3C, but the > working group was an IETF working group and that list is still used by the IETF > and W3C jointly for discussions in this area. > >> working group resulted in a decision that did not change the ABNF at >> all, in 2 ways: >> >> 1. It used the IPvFuture extension mechanism; > > Hmm. I'm not sure that was a good choice. It certainly doesn't > seem natural to me. Also it seems like more work for implementors > than a small extension to the existing ABNF. What's so sacred? > > This actually doesn't turn out to be a small change. The draft gives > this production > > IPv6addrz = IPv6address [ "%" ZoneID ] > > but the use of a "%" that is not used in escaping is contrary to the basic URI > syntax--this is made clear in Section 2.4 of RFC 3986; changing that would > require a major re-write to URI parsers. I am probably stupid, but that wasn't clear to me when reading 3986. Of course it's clear that an actual URI on the wire needs to contain %25. Anyway, I am completely convinced that the downside of using %25 is much greater than the upside, so I believe we should revert to "_" as in Bill's draft. > > >> 2. It used a non-percent character for the separator. > > Yes, and I have almost convinced myself that is better. The % is > certainly the worst possible choice from a clarity viewpoint. > >> At the time, the URI working group was very concerned about the change >> in the ABNF and the use of percent where percent had not previously >> been allowed. Have they changed their position here, or have they not >> had a chance to comment on this change yet? > > It's been sent for URI review but no reply so far. > > > I'm on the relevant list (uri-review@ietf.org) and I have not seen this document > there. Can you resend the request for review? It has presumably never been released by the list moderator. But in any case, I suggest delaying the review until we have a new version after the recent discussion. > >> This work was accepted as an ipv6 wg work item around IETF63 (Paris, >> 2005), but the authors never pushed the document forward due to a lack >> of interest in the broader community. The draft that was adopted by >> the wg was >> >> http://tools.ietf.org/html/draft-fenner-literal-zone-01 > > Recently there's been definite interest in this as an operational > convenience. I was pretty much unaware of the 2005 work, since that was > just when I joined the IESG and life was too busy, especially > during the first Paris IETF. > > Was there a real reason that you went for this? > IPv6zone-id = 1*( unreserved / sub-delims / ":" ) > > We have > ZoneID = 1*( unreserved / pct-encoded ) > which allows anything, having noted that some operating systems use all > sorts of characters in interface names. > > If there is a fundamental change in the limitations which are set out in > Bill's draft's section 3, it would be useful to set them out. As it stands, > I haven't seen any changes that would cause a change, but this would be > useful to describe them if they have happened. No, I think that is still exactly true, and the Security Considerations in the recent draft intend to say much the same thing. It's clear that the next draft needs to include all salient points from the 2005 draft, not to mention the authors of that draft if they want, but we need to conclude on the IPvFuture issue first. I don't think we'll have a new draft before the cutoff. Thanks Brian From ted.ietf@gmail.com Wed Mar 7 14:11:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C1C11E80BC for ; Wed, 7 Mar 2012 14:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xw223SwzAa8 for ; Wed, 7 Mar 2012 14:11:20 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6D11E80AF for ; Wed, 7 Mar 2012 14:11:19 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so6786884vcb.31 for ; Wed, 07 Mar 2012 14:11:19 -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=4kePFTBzu9DMkTyZJWsm70KZ43jaIe0DOApuB4JTaBI=; b=oKnMdr5wcJbFArxmKbieXOOXgknDT6eZsE7pOTPXSaqU6yOt6XdJTlI4Y34zWHexPh NhyYCVMkoKFAIJ9j+fB5HRFYQZs90ZEcd6DdK8+1uvGu7wM5nWte+mu+0bSvFeUAtzfu bs0RMALLz7h8AmhKb9P6IQRfU1NXhSuUG6OLwGM27v/utWEdDIWJC1fZ1cPFuaQrv12G 0fXfp6oVKArWUUFqTNQ3HbguDgS3V3sIpecEznPnww3vqqhfygpdbQXiC5hzZoFb1Hpx Nf9FS0vkAZFGatiKIT5JyH4U4NksCjq4LrNxT8cCFUvztxifCjItfTcyxQb1Ycr8b46Z 4mWQ== MIME-Version: 1.0 Received: by 10.52.26.20 with SMTP id h20mr6193560vdg.3.1331158279429; Wed, 07 Mar 2012 14:11:19 -0800 (PST) Received: by 10.52.115.66 with HTTP; Wed, 7 Mar 2012 14:11:19 -0800 (PST) In-Reply-To: <4F57D760.8080508@gmail.com> References: <4F57D760.8080508@gmail.com> Date: Wed, 7 Mar 2012 14:11:19 -0800 Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt From: Ted Hardie To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:11:20 -0000 On Wed, Mar 7, 2012 at 1:47 PM, Brian E Carpenter wrote: >> but the use of a "%" that is not used in escaping is contrary to the basic URI >> syntax--this is made clear in Section 2.4 of RFC 3986; changing that would >> require a major re-write to URI parsers. > > I am probably stupid, but that wasn't clear to me when reading 3986. > Of course it's clear that an actual URI on the wire needs to contain %25. > Anyway, I am completely convinced that the downside of using %25 is much > greater than the upside, so I believe we should revert to "_" as in > Bill's draft. I think "_" will cause much less heartburn; it may still require special casing, but of a much simpler type. > It has presumably never been released by the list moderator. But in any > case, I suggest delaying the review until we have a new version after the > recent discussion. > Makes sense to delay the formal review. You might want to give a short heads-up to the APPS area meeting/working group on Monday of the IETF week, if you have a candidate solution based on a combination of your and Bill's drafts. That will likely catch the right folks to look for other URI gotchas. regards, Ted From internet-drafts@ietf.org Thu Mar 8 10:10:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA7E21F867D; Thu, 8 Mar 2012 10:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO7IO4GHzkZN; Thu, 8 Mar 2012 10:10:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1B921F8679; Thu, 8 Mar 2012 10:10:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-dad-proxy-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308181033.17473.25338.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 10:10:33 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:10:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Duplicate Address Detection Proxy Author(s) : Fabio Costa Xavier Pougnard Hongyu Li Jean-Michel Combes Filename : draft-ietf-6man-dad-proxy-02.txt Pages : 13 Date : 2012-03-08 The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-dad-proxy-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-dad-proxy-02.txt From rja.lists@gmail.com Thu Mar 8 11:43:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6BC21E800C for ; Thu, 8 Mar 2012 11:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZEYKDTmJtQu for ; Thu, 8 Mar 2012 11:43:00 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C85021F8454 for ; Thu, 8 Mar 2012 11:43:00 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so836425vcb.31 for ; Thu, 08 Mar 2012 11:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=b9Ms0UTlW3weEhaUOGOnGf0qoh1aZaG9PWWXk7nzquA=; b=KT4OWyGomjXzlVwMh2SE+41h4cL2Uu/2ffQaGwN3hvbhW7MS9qjKuC+cmDbts79Bq9 ObE3K54X7/Fpp2M2LcgXotTKajhlSlnzhdV7h/xCekIJNWY+fp15t9luk1qFfdcvkUIn 7tm2xiJwKeudcdBDp33+kQYQgy1NgZS0QauVhsk56SjR8/kYbPprMpdfiQuq6+uHX6q9 Xhf580xO7Y/kkSouAmwe2CQBcXd9TFwyv9w1qwbfvxu8O2/7ytaCoafQPqfEf7wLjkrN OU73HG65jkfwUXXM61YZz2wYldALU59VVcOX5EefdDtwgOdmAFd4zKVoBdYyHGarHizl FoJw== Received: by 10.52.93.74 with SMTP id cs10mr12069235vdb.42.1331235779860; Thu, 08 Mar 2012 11:42:59 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id ew2sm5514226vdc.16.2012.03.08.11.42.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 11:42:59 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FW: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt Date: Thu, 8 Mar 2012 14:42:57 -0500 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:43:01 -0000 I agree with Joel H's note here: I also agree with Brian C's note here: I think it important that we do not make changes that effectively close the door on Quick-Start. Also, mindful of Brian's scenario, where a single device is acting both as host and as relay/router, it is very likely that a CALIPSO-enabled host function would emit a packet that the CALIPSO-enabled router function would be required to at least parse, lex, and compare with the allowed CALIPSO label ranges on the candidate output interface. While CALIPSO is only deployed in selected networks, I understand that those networks often are built out of off-the-shelf equipment and software. Yours, Ran From sreenatha.b@huawei.com Thu Mar 8 20:56:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44B21F855D for ; Thu, 8 Mar 2012 20:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.59 X-Spam-Level: X-Spam-Status: No, score=-5.59 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 974kWy3Zh12M for ; Thu, 8 Mar 2012 20:56:14 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 571FA21F855A for ; Thu, 8 Mar 2012 20:56:13 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0L0022TPLMIE@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 09 Mar 2012 12:53:46 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0L00DA6PLMU4@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 09 Mar 2012 12:53:46 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHS10126; Fri, 09 Mar 2012 12:53:39 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 09 Mar 2012 12:52:56 +0800 Received: from blrprnc08ns (10.18.96.97) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server id 14.1.323.3; Fri, 09 Mar 2012 12:53:37 +0800 Date: Fri, 09 Mar 2012 10:23:36 +0530 From: sreenatha Subject: Re: FW: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt X-Originating-IP: [10.18.96.97] To: rja.lists@gmail.com Message-id: <003001ccfdb0$96c8b870$c45a2950$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RQqeSzXKOXZ0NHOdM/hXWQ)" Content-language: en-us Thread-index: Acz9sJX7WxZMBmY/Thmb6WEWroFKyg== X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 08 Mar 2012 23:50:41 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:56:17 -0000 --Boundary_(ID_RQqeSzXKOXZ0NHOdM/hXWQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Ran, I went through the RFC's which Brian mentioned. For Quick Start option, while inserting the option only they can do whatever processing need to be done.(Decrementing TTL value in the option. If Application is inserting the Quick Start option means, node is supporting for Quick Start, so it can decrement the TTL and insert the option.) In most of the ipv6 stack implementation currently exist(It includes FreeBSD), ip6_output_function implementation is like this: Ip6_output_function() { ---- ---- ---- ---- If (HopByHop header need to be insert(any options in under HopByHop need to insert)) Insert the options. ---- ---- ---- /*Since RFC 2460 mandates even source should process the HopByHop header, do the processing.*/ If (HopByHop header is present) Process the options. ---- ---- ---- ---- } So here what is the advantage we will get by inserting the header and immediately processing the header? If we inserting the header correctly, always Processing of the header will be valid. This only I suggested no need to process in source. And in case of node which is acting as both Host and Router: Node behaves differently for Packets which are originated from itself and for packets which are need to be forwarded. For packets originated by itself, Ip6_output_function will be called to send out the packets. HopByHop header insertion and processing is explained above. For packets need to be forwarded: Ip6_input_function followed by Ip6_forward_function is called. HopByHop header processing will be done in Ip6_input_function during forwarding. So no question of skipping HopByHop header processing by Node which is acting both as Host/Router. In draft we just saying that source node which is inserting the HopByHop header no need to process it again. It might be any options under HopByHop header, while inserting only it will insert correctly(If implementation follows correct specification of that Options!) So again processing the header is unnecessary what I am feeling. (As in ip6_output_function) Thanks- B.Sreenatha Setty, Message: 5 Date: Thu, 8 Mar 2012 14:42:57 -0500 From: RJ Atkinson To: ipv6@ietf.org Subject: Re: FW: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt Message-ID: Content-Type: text/plain; charset=us-ascii I agree with Joel H's note here: I also agree with Brian C's note here: I think it important that we do not make changes that effectively close the door on Quick-Start. Also, mindful of Brian's scenario, where a single device is acting both as host and as relay/router, it is very likely that a CALIPSO-enabled host function would emit a packet that the CALIPSO-enabled router function would be required to at least parse, lex, and compare with the allowed CALIPSO label ranges on the candidate output interface. While CALIPSO is only deployed in selected networks, I understand that those networks often are built out of off-the-shelf equipment and software. Yours, Ran --Boundary_(ID_RQqeSzXKOXZ0NHOdM/hXWQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Ran,

   I went through the RFC’s which Brian mentioned. For Quick Start option, while inserting the option only they can do whatever processing need to be done.(Decrementing TTL value in the option. If Application is inserting the Quick Start option means, node is supporting for Quick Start, so it can decrement the TTL and insert the option.)

  

   In most of the ipv6 stack implementation currently exist(It includes FreeBSD), ip6_output_function implementation is like this:

  

   Ip6_output_function()

   {

     &n p class=MsoPlainText>      ----

      ----

      ----

      If (HopByHop header need to be insert(any options in under HopByHop need to insert))

           Insert the options.

 

      ----

      ----

      ----

      /*Since RFC 2460 mandates even source should process the HopByHop header, do the processing.*/

      If (HopByHop header is present)< o:p>           Process the options.

      ----

      ----

      ----

      ----

   }

  

   So here what is the advantage we will get by inserting the header and immediately processing the header? If we inserting the header correctly, always Processing of the header will be valid. This only I suggested no need to process in source.

 

  And in case of node which is acting as both Host and Router:

    Node behaves diff erently ginated from itself and for packets which are need to be forwarded.

 

    For packets originated by itself,

    Ip6_output_function  will be called to send out the packets. HopByHop header insertion and processing is explained above.

 

    For packets need to be forwarded:

    Ip6_input_function followed by Ip6_forward_function is called.

    HopByHop header processing will be done in Ip6_input_function during forwarding.

 

   So no question of skipping HopByHop header processing by Node which is acting both as Host/Router.

In draft we just saying that source node which is inserting the HopByHop header no need to process it again. It might be any options under HopByHop header, while inserting only it will insert correctly(If implementation follows correct specification of that Options!) So again processing the header is unnecessary what I am feeling. (As in ip6_output_function)

 

 

 

Thanks-

B.Sreenatha Setty,

 

 

Message: 5

Date: Thu, 8 Mar 2012 14:42:57 -0500

From: RJ Atkinson <rja.lists@gmail .com ss=MsoPlainText>To: ipv6@ietf.org

Subject: Re: FW: New Version Notification for

      draft-tsou-6man-hbh-header-update-00.txt

Message-ID: <F3B52779-6332-46D2-AC50-D27061F9ADC9@gmail.com>

Content-Type: text/plain; charset=us-ascii

 

I agree with Joel H's note here:

      <http://www.ietf.org/mail-archive/web/ipv6/current/msg15503.html>

 

I also agree with Brian C's note here:

  <http://www.ietf.org/mail-archive/web/ipv6/current/msg15514.html>

 

I think it important that we do not make changes that effectively close the door on Quick-Start.

 

Also, mindful of Brian's scenario, where a single device is acting both as host and as relay/router, it is very likely that a CALIPSO-enabled host function would emit a packet that the CALIPSO-enabled router function would be required to at least parse, lex, and compare with the allowed CALIPSO label ranges on the candidate output interface.

While CALIPSO is only deployed in selected networks, I understand that those networks often are built out of off-the-shelf equipment and software.

 

< p class= /o:p>

 

Ran

 

 

--Boundary_(ID_RQqeSzXKOXZ0NHOdM/hXWQ)-- From rja.lists@gmail.com Fri Mar 9 04:38:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC321F84CF for ; Fri, 9 Mar 2012 04:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ova8MzGCgQre for ; Fri, 9 Mar 2012 04:38:51 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 038B021F84C9 for ; Fri, 9 Mar 2012 04:38:50 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1532379vcb.31 for ; Fri, 09 Mar 2012 04:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=VY3er6/NTZ1lAh+5LlXS/9H6PoIMzw/3qIU6vrBfhZA=; b=qO23SxHci+ysyZUzC8fDw7Sck9fGDhPFTbMJv8lVL6YXtf4CKg5CjUubE2eOvKuMJS cdlCMsXfxuF5ZsXeNEwJ8OTUfB5oJ5YiZTn/7XbemLkwkQ3IVsZG7+3qGeYUV3tVIqyE wiDRUUlqhs1dAM0l8SptfntX46DFRy7xrRgcdFo2eHiQoKInRi2L5vEw7m+DUUSQOh0J 10eBctVvxG9pFUGjD1ZVXxYOfybJM44VwHGtOV6Mbr3dVbvjcwdS50qZA4G9FLIiCrYP eENc8O5nq4YFk5CfaRB+JOmAHtmosDMkK384O0qM6f4umlCpRswY8mkGQVYNjQ99aY5v z8Fg== Received: by 10.52.35.99 with SMTP id g3mr3113729vdj.65.1331296730408; Fri, 09 Mar 2012 04:38:50 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id h5sm10404093vdk.0.2012.03.09.04.38.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 04:38:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt From: RJ Atkinson In-Reply-To: <003001ccfdb0$96c8b870$c45a2950$@com> Date: Fri, 9 Mar 2012 07:38:51 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <003001ccfdb0$96c8b870$c45a2950$@com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1257) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:38:51 -0000 On 08 Mar 2012, at 23:53 , sreenatha wrote: > So here what is the advantage we will get by > inserting the header and immediately processing the header? Correct IPv6 protocol behaviour in *all* cases, instead of being correct only in some cases. > In draft we just saying that source node which is > inserting the HopByHop header no need to process it again. That can lead to incorrect IPv6 protocol behaviour in some cases, as others have explained already. Note well that the existing IPv6 specifications do NOT place constraints on the internal implementation details of a particular IPv6 implementation, but instead the IPv6 specifications place constraints on the externally visible IPv6 packet processing behaviour that the particular IPv6 implementation provides/demonstrates. By contrast, this draft actually proposes to change the requirements on the *externally visible* packet processing behaviour, and the proposal will cause incorrect IPv6 operation in several identified real-world cases. IF (and this is a critical important IF) one's implementation provides the correct packet processing behaviour in *all* cases, and one's implementation is fully interoperable in *all* cases, then no one else cares how one's implementation internals are organised or executed. So if the authors' concern was flexibility in implementation strategy, and provided the chosen implementation strategy provides the correct IPv6 packet processing behaviours in *all* cases, then there is no need for this draft to exist at all. [Credit where due: most or all of those cases that would be harmed by this I-D were originally identified by folks other than me.] I continue to object to this draft on grounds that it will create interoperability problems and will allow incorrect IPv6 packet processing behaviours in several identified real-world situations. (begin new topic) More generally, the IPv6 WG appears to be receiving too many proposals to make IPv6 specification changes. In broad terms, those proposals HARM and DELAY the current deployment of IPv6. One of the most serious criticisms about IPv6 from users and network operators (e.g. educational, research, commercial, governmental, residential, home, or other network operators) is that *the IPv6 specifications keep changing* without there being an absolute need to change the specifications. IPv6 needs specification stability, ideally zero changes and at most bug-fixes for well-documented, current, real-world, operational issues, if IPv6 is going to be deployed globally in time. Yours, Ran From internet-drafts@ietf.org Fri Mar 9 06:56:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA7421F86A1; Fri, 9 Mar 2012 06:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPURdPUdhTdV; Fri, 9 Mar 2012 06:56:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8121F8646; Fri, 9 Mar 2012 06:56:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-lineid-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309145608.4353.23125.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 06:56:08 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:56:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : The Line Identification Destination Option Author(s) : Suresh Krishnan Alan Kavanagh Balazs Varga Sven Ooghe Erik Nordmark Filename : draft-ietf-6man-lineid-04.txt Pages : 15 Date : 2012-03-09 In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-lineid-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-lineid-04.txt From zhou.sujing@zte.com.cn Mon Mar 12 00:24:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF6721F8592 for ; Mon, 12 Mar 2012 00:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[AWL=1.604, BAYES_50=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srZMW0+uPVOz for ; Mon, 12 Mar 2012 00:24:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9DABF21F856A for ; Mon, 12 Mar 2012 00:24:01 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801320096835; Mon, 12 Mar 2012 14:51:06 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 96551.1320096835; Mon, 12 Mar 2012 15:23:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2C7NgVF009345 for ; Mon, 12 Mar 2012 15:23:42 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: ipv6@ietf.org Subject: hi, the adenda of 5man at ietf 83 decided? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 12 Mar 2012 15:23:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-12 15:23:44, Serialize complete at 2012-03-12 15:23:44 Content-Type: multipart/alternative; boundary="=_alternative 0028A11B482579BF_=" X-MAIL: mse01.zte.com.cn q2C7NgVF009345 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 07:24:03 -0000 This is a multipart message in MIME format. --=_alternative 0028A11B482579BF_= Content-Type: text/plain; charset="US-ASCII" --=_alternative 0028A11B482579BF_= Content-Type: text/html; charset="US-ASCII" --=_alternative 0028A11B482579BF_=-- From internet-drafts@ietf.org Mon Mar 12 10:06:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB7221F87F2; Mon, 12 Mar 2012 10:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipvXsmP7sl6n; Mon, 12 Mar 2012 10:06:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC621F87CF; Mon, 12 Mar 2012 10:06:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-6lobac-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312170644.5201.85558.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 10:06:44 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:06:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Transmission of IPv6 over MS/TP Networks Author(s) : Kerry Lynn Jerry Martocci Carl Neilson Stuart Donaldson Filename : draft-ietf-6man-6lobac-01.txt Pages : 20 Date : 2012-03-12 MS/TP (Master-Slave/Token-Passing) is a contention-free access method for the RS-485 physical layer that is used extensively in building automation networks. This document describes the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt From brian@innovationslab.net Mon Mar 12 14:08:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF55721F8976 for ; Mon, 12 Mar 2012 14:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4zudyBNKy4w for ; Mon, 12 Mar 2012 14:08:21 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id B266421F8975 for ; Mon, 12 Mar 2012 14:08:21 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 48FA588120 for ; Mon, 12 Mar 2012 14:08:21 -0700 (PDT) Received: from clemson.local (c-68-33-164-105.hsd1.dc.comcast.net [68.33.164.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0DB35130015 for ; Mon, 12 Mar 2012 14:08:20 -0700 (PDT) Message-ID: <4F5E65C4.4070009@innovationslab.net> Date: Mon, 12 Mar 2012 17:08:20 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Consensus call on adopting: draft-hsingh-6man-enhance-dad References: <4F478EEC.1020203@innovationslab.net> In-Reply-To: <4F478EEC.1020203@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:08:22 -0000 All, There is consensus to adopt this document as a 6MAN draft. The authors are instructed to post the next version as a 6MAN draft. Regards, Brian, Bob, & Ole On 2/24/12 8:21 AM, Brian Haberman wrote: > All, > This is a consensus call on adopting: > > Filename: draft-hsingh-6man-enhanced-dad > Revision: 04 > Title: Enhanced Duplicate Address Detection > > as a 6MAN WG document. Statements of support or opposition should be > sent to the mailing list. This last call will end on March 9, 2012. > > Regards, > Brian, Bob, & Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From internet-drafts@ietf.org Mon Mar 12 14:55:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9204021F89F0; Mon, 12 Mar 2012 14:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kubVS20UaMjp; Mon, 12 Mar 2012 14:55:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0C921F89CA; Mon, 12 Mar 2012 14:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-udpchecksums-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312215502.31217.61044.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:55:02 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:55:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks P.F. Chimento Filename : draft-ietf-6man-udpchecksums-02.txt Pages : 12 Date : 2012-03-12 This document provides an update of RFC 2460[RFC2460] in order to improve the performance of IPv6 in an increasingly important use case, the use of tunneling to carry new transport protocols. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums on tunneled IPv6 packets and thereby improves the efficiency of the traversal of firewalls and other network middleware by such new protocols. We describe how the IPv6 UDP checksum requirement can be relaxed in the situation where the encapsulated packet itself contains a checksum, the limitations and risks of this approach, and provides restrictions on the use of this relaxation to mitigate these risks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-udpchecksums-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-udpchecksums-02.txt From internet-drafts@ietf.org Mon Mar 12 16:39:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA7C21E822F; Mon, 12 Mar 2012 16:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMopy1AD1eoW; Mon, 12 Mar 2012 16:39:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55EF21E8228; Mon, 12 Mar 2012 16:39:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-impatient-nud-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312233939.25159.90842.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:39:39 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:39:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Neighbor Unreachability Detection is too impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-01.txt Pages : 8 Date : 2012-03-12 IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-impatient-nud-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-impatient-nud-01.txt From brian.e.carpenter@gmail.com Mon Mar 12 17:44:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD121E80F7 for ; Mon, 12 Mar 2012 17:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+P8+qhUJ1fE for ; Mon, 12 Mar 2012 17:44:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE9721E80C0 for ; Mon, 12 Mar 2012 17:44:57 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3669133ghb.31 for ; Mon, 12 Mar 2012 17:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OMgA3IZrqg4fj86UJ/E2zdHfpgw1RC+SQBJcuhKN0VE=; b=0lEQ0eesP6YSdsYmf2db+trITIX56lUI0S6lQyu6X+Vwpxqj6Pz3X/8MN8rzACYTId OULWQVTfmz0rU7Lihkf9yO+7Uiuxr6GS5zMIkTvAkjj5u29LX53fcyUoIX+N/PEkwQBr pTefBIpLHSBXQlCArSJPf+e36dGYPqFxBBR3uaTeefuRrxoLZEnG64IU4apkUruUbl4G 8zN9wnwGti6cpjQ/86qEtXwKm1SjHdHpINtX0BkHIBS9KjAQLkBzcvffZc8bnf3h0rJX bqdKYKAszkJSkvhpzLlUv3h0vnPBs5FkQvJ35r5pEjLkAZTUwBIxq6lZb2aI5kAssVoV pidQ== Received: by 10.236.144.134 with SMTP id n6mr15610049yhj.50.1331599496835; Mon, 12 Mar 2012 17:44:56 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id e8sm42151505yhk.0.2012.03.12.17.44.54 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 17:44:56 -0700 (PDT) Message-ID: <4F5E9883.9020703@gmail.com> Date: Tue, 13 Mar 2012 13:44:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: Hash function comparisons for flow label generation References: <4F56C34C.3090708@gmail.com> In-Reply-To: <4F56C34C.3090708@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:44:57 -0000 The official handle for this is http://hdl.handle.net/2292/13240 Brian On 2012-03-07 15:09, Brian E Carpenter wrote: > Hi 6man, > > I've just filed a technical report on some work we've done on actual > performance of certain non-cryptographic hash functions, when used to > generate flow labels for real-world IPv6 traffic traces from four > different sites. > > It will get an official library handle soon, but here is an ad hoc > URL to be going on with: > > http://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf > > If you don't want to read it, here's the conclusion: the > FNV1a-32 algorithm, with the result XOR-folded to 20 bits, > works very well for this purpose. > From samita.chakrabarti@ericsson.com Mon Mar 12 18:36:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5119321F888E; Mon, 12 Mar 2012 18:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WixE86siSuWB; Mon, 12 Mar 2012 18:36:26 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 28BED21F885F; Mon, 12 Mar 2012 18:36:26 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2D1aPiQ002438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Mar 2012 20:36:25 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.2.76]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 12 Mar 2012 21:36:24 -0400 From: Samita Chakrabarti To: 6man Mailing List , "int-area@ietf.org" Date: Mon, 12 Mar 2012 21:36:22 -0400 Subject: FW: draft-chakrabarti-nordmark-energy-aware-nd-02.txt Thread-Topic: draft-chakrabarti-nordmark-energy-aware-nd-02.txt Thread-Index: Ac0AqzZ6GqXlCyK9SASIyLAz+Cyl8QAB5DhAAAEsgUA= Message-ID: <16D60F43CA0B724F8052D7E9323565D72AAFFD9169@EUSAACMS0715.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 01:36:27 -0000 =20 Hello: =20 A draft on the efficient ipv6 neighbor discovery has been submitted with ed= itorial modification to address some of the comments from last IETF. We exp= ect to have another revision right after IETF to change the name from 'ener= gy-aware' to 'efficient'. In version 02: * Fixed the abstract to focus on the optimization * Applicability section mentions that the optimization is for IPv6 ND messa= ging and further optimization for energy-saving is possible at the upper la= yers * Added a section (section 17) to discuss its relationship with DNA solutio= n and that it does not affect nodes joining musticast groups and does not a= ffect multicast traffic and queries in the network. The authors of this draft request a review and comments from the wg members= . We presented the draft in last IETFs (@Taiwan+QC) and had many positive f= eedbacks from Data Center networking and ipv6 mobile-handset representative= s.=20 http://tools.ietf.org/html/draft-chakrabarti-nordmark-energy-aware-nd-02 Thanks, -Samita -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, March 12, 2012 4:52 PM To: Samita Chakrabarti Cc: mrw@lilacglade.org; nordmark@cisco.com Subject: New Version Notification for draft-chakrabarti-nordmark-energy-awa= re-nd-02.txt A new version of I-D, draft-chakrabarti-nordmark-energy-aware-nd-02.txt has= been successfully submitted by Samita Chakrabarti and posted to the IETF r= epository. Filename: draft-chakrabarti-nordmark-energy-aware-nd Revision: 02 Title: Energy Aware IPv6 Neighbor Discovery Optimizations Creation date: 2012-03-13 WG ID: Individual Submission Number of pages: 23 Abstract: IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless and machine-to-machine communications, there is a desire for optimizing legacy IPv6 Neighbor Discovery protocol to be more efficient in terms of number of signaling messages in the network. Efficient IPv6 Neighbor Discovery is useful for energy-efficient networks and as well for overlay networks such as VLANs with large number of nodes. This document describes a method of optimizations by reducing periodic multicast messages, frequent Neighbor Solicitation messages and discusses interoperability with legacy IPv6 nodes. It also addresses the ND denial of service issues by introducing node Registration procedure. = =20 The IETF Secretariat _______________________________________________ eriietf mailing list eriietf@mailman.lmera.ericsson.se http://mailman.lmera.ericsson.se/mailman/listinfo/eriietf From brian.e.carpenter@gmail.com Mon Mar 12 19:00:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7911E8072 for ; Mon, 12 Mar 2012 19:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.437 X-Spam-Level: X-Spam-Status: No, score=-103.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnk15hbbxVZ5 for ; Mon, 12 Mar 2012 19:00:55 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4947421F88DC for ; Mon, 12 Mar 2012 19:00:53 -0700 (PDT) Received: by yenm5 with SMTP id m5so44680yen.31 for ; Mon, 12 Mar 2012 19:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=C64cqO07yNvIK99nlBIb02GAVXTXlECgkXzNqcLL2Cw=; b=dzD3tlg7aP1y1QP5JtLM98IyCwHlMewvVF09MzOmsSv/vPlj+FjW3OeQDbz2ZzTPxi 3V2s/CCDxHLva9/nuBzUSgTCTHl5QiJhH64MOoRBCYG50FWKP6b3eJA/LI3Dja7Y3YTG vCWw0t4KoNVsjN8txMSka4lcxrpRV4/Vj6H2ky4WVCtjMKCPkZ3BTzjZ4FQNonHiQ3By +qRMKnbAuOMoxTanpll/S/QL7zdMdiQIQ9640dMfxPsm7P+ARBr+plL0JpYOhk6peDYt 1zFPLNoC4Cpqnw8SmPx+bUp4fGe1kLxh3Pwe34bim8cgOTHSpB0eSDkbeEJA8uhIBPl+ MitQ== Received: by 10.182.141.9 with SMTP id rk9mr9781022obb.50.1331604051199; Mon, 12 Mar 2012 19:00:51 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id j9sm22413516obl.21.2012.03.12.19.00.49 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 19:00:50 -0700 (PDT) Message-ID: <4F5EAA4E.7000006@gmail.com> Date: Tue, 13 Mar 2012 15:00:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: FYI [Fwd: RFC 6563 on Moving A6 to Historic Status] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 02:00:56 -0000 -------- Original Message -------- Subject: RFC 6563 on Moving A6 to Historic Status Date: Mon, 12 Mar 2012 15:55:06 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6563 Title: Moving A6 to Historic Status Author: S. Jiang, D. Conrad, B. Carpenter Status: Informational Stream: IETF Date: March 2012 Mailbox: jiangsheng@huawei.com, drc@cloudflare.com, brian.e.carpenter@gmail.com Pages: 8 Characters: 16654 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-jiang-a6-to-historic-00.txt URL: http://www.rfc-editor.org/rfc/rfc6563.txt This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. This document is not an Internet Standards Track specification; it is published for informational purposes. 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/rfcsearch.html. 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 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From kerlyn2001@gmail.com Tue Mar 13 04:47:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CD021F883B for ; Tue, 13 Mar 2012 04:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwaM8qcLFanK for ; Tue, 13 Mar 2012 04:47:56 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9121F8839 for ; Tue, 13 Mar 2012 04:47:56 -0700 (PDT) Received: by lbol12 with SMTP id l12so224334lbo.31 for ; Tue, 13 Mar 2012 04:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6A2Dv973QsJne+5bx4A2spyN6DfQIOX6K8nmH4FSR1o=; b=GpyIBfLqdWIByCkBiuN/d6EiRsrv4PRAc6lMLbA4IqbMpd4XO1b0+SgQMvFHb6amME /7zSWBLr3YQ07DsRqH6qGHCfbz+8vy+JovtkRD6lw+3+cGoJuWAv6zvsx8JXwSVIZPxs 1zXqXHPoMM6i7AVYA5mHIMbu4DjUv4xRfB8TuOEEItlzUDeP7x2uvJVrV0Wxkw4XM1rE WRASroHVIQzHNE2/iGDo/9TK/6alC1yF4X+tV7fzcX0vdYljiI0F1L+8qR9UwDtXTU6M vpXTP1p8UEcH6UedrTuBzq2hzJkS3a3fJdILl7PC4HrdihX8S0RRLl+4InPl3/4lahnS GkLQ== MIME-Version: 1.0 Received: by 10.152.147.202 with SMTP id tm10mr13080973lab.49.1331639275211; Tue, 13 Mar 2012 04:47:55 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Tue, 13 Mar 2012 04:47:55 -0700 (PDT) In-Reply-To: <20120312170644.5201.85558.idtracker@ietfa.amsl.com> References: <20120312170644.5201.85558.idtracker@ietfa.amsl.com> Date: Tue, 13 Mar 2012 07:47:55 -0400 X-Google-Sender-Auth: ZXGkxYik_6s_B1JFHSWYbA9SbuE Message-ID: Subject: Re: I-D Action: draft-ietf-6man-6lobac-01.txt From: Kerry Lynn To: 6man Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Donaldson, Stuart \(WA26\)" , Carl Neilson , Jerry Martocci X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 11:47:57 -0000 Greetings, The main changes to the WG version of this draft are: a) tweaks that resulted from the initial public review of the BACnet MS/TP change proposal, the most significant being the COBS encoding of data and data crc fields to remove preamble sequences; and b) addition of two informative appendices to provide code examples for the data crc and COBS encoder/decoder. These appendices are insufficient to implement the data link, but are provided e.g. for those writing Wireshark dissectors or otherwise wanting more detail about over- the-wire format. I'd like to solicit specific comments on what is needed to move this draft forward - IOW, what would you like to see added in order for this draft to be ready for WGLC? For anyone who'd like to view the details of data link state machines, etc., I can provide the relevant clause (9) of the ASHRAE 135-2010 (BACnet) spec, as well as the MS/TP change proposal (Addendum an). Thanks, -K- On Mon, Mar 12, 2012 at 1:06 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Transmission of IPv6 over MS/T= P Networks > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Kerry Lynn > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jerry Martocci > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Carl Neilson > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stuart Donaldson > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-6man-6lobac-01.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 20 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 > > =A0 MS/TP (Master-Slave/Token-Passing) is a contention-free access method > =A0 for the RS-485 physical layer that is used extensively in building > =A0 automation networks. =A0This document describes the frame format for > =A0 transmission of IPv6 packets and the method of forming link-local and > =A0 statelessly autoconfigured IPv6 addresses on MS/TP networks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From alexandru.petrescu@gmail.com Tue Mar 13 10:54:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5447D21F878E for ; Tue, 13 Mar 2012 10:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.318 X-Spam-Level: X-Spam-Status: No, score=-8.318 tagged_above=-999 required=5 tests=[AWL=1.931, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMR-fAnmSfEb for ; Tue, 13 Mar 2012 10:54:27 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id ED69221F878B for ; Tue, 13 Mar 2012 10:54:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2DHsP26002464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Mar 2012 18:54:25 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2DHsOCa022479 for ; Tue, 13 Mar 2012 18:54:25 +0100 (envelope-from alexandru.petrescu@gmail.com) 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 q2DHsL3B013439 for ; Tue, 13 Mar 2012 18:54:24 +0100 Message-ID: <4F5F89CD.10207@gmail.com> Date: Tue, 13 Mar 2012 18:54:21 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-6lobac-01.txt References: <20120312170644.5201.85558.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 17:54:28 -0000 HEllo, A side note about this. It is not a request for modification, just a thought. I wonder why do we want the Interface Identifier to be of length 64 when the MS/TP node address seems to be 8bit only. In a sense, it may be because SLAAC over Ethernet (802) is used to use 64bit IIDs. But in another sense, this is not Ethernet and hence the IID could be of length 8bit of MS/TP, right? I am asking this because of other contexts (non-MS/TP) whereby the link-layer addresses are shorter than 48bit and yet the Interface ID is still 64bit, "to make SLAAC work". In some contexts too, the ISP delivers a 64bit prefix to a leaf network and if that IID is almost always 64bit it means that it's hard next to impossible to form sub-prefixes of that ISP 64bit prefix and still use SLAAC. In a sense, it would be better to define the IIDs of MS/TP (or other link) to be of length 8, allow the ISP to assign 64bit prefix to leaf network, and let the gateway in between to derive prefixes out of that 64bit (up to 120) and still use SLAAC. This is just a thought, not a request to modify. Yours, Alex Le 13/03/2012 12:47, Kerry Lynn a écrit : > Greetings, > > The main changes to the WG version of this draft are: a) tweaks that > resulted from the initial public review of the BACnet MS/TP change > proposal, the most significant being the COBS encoding of data and > data crc fields to remove preamble sequences; and b) addition of two > informative appendices to provide code examples for the data crc and > COBS encoder/decoder. These appendices are insufficient to implement > the data link, but are provided e.g. for those writing Wireshark > dissectors or otherwise wanting more detail about over- the-wire > format. > > I'd like to solicit specific comments on what is needed to move this > draft forward - IOW, what would you like to see added in order for > this draft to be ready for WGLC? > > For anyone who'd like to view the details of data link state > machines, etc., I can provide the relevant clause (9) of the ASHRAE > 135-2010 (BACnet) spec, as well as the MS/TP change proposal > (Addendum an). > > Thanks, -K- > > > On Mon, Mar 12, 2012 at 1:06 PM, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the IPv6 Maintenance >> Working Group of the IETF. >> >> Title : Transmission of IPv6 over MS/TP Networks >> Author(s) : Kerry Lynn Jerry Martocci Carl Neilson Stuart >> Donaldson Filename : draft-ietf-6man-6lobac-01.txt Pages >> : 20 Date : 2012-03-12 >> >> MS/TP (Master-Slave/Token-Passing) is a contention-free access >> method for the RS-485 physical layer that is used extensively in >> building automation networks. This document describes the frame >> format for transmission of IPv6 packets and the method of forming >> link-local and statelessly autoconfigured IPv6 addresses on MS/TP >> networks. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt >> >> -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list >> ipv6@ietf.org Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >> -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From kerlyn2001@gmail.com Tue Mar 13 11:51:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480B621F86FA for ; Tue, 13 Mar 2012 11:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M+qv+msULwh for ; Tue, 13 Mar 2012 11:51:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEF0F21F86F8 for ; Tue, 13 Mar 2012 11:51:33 -0700 (PDT) Received: by lagj5 with SMTP id j5so909595lag.31 for ; Tue, 13 Mar 2012 11:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BtsKTxIB5rdVgC8y6tLcv2lNVZscDnnznBK2qSAoJhE=; b=ivZNS3b+dUvktrs+1Hhk6tC+0BVH/5z/rOgoE1Zzn2ig03MqABQyEIdG/Rsq00vDA5 l2OS4H5/kyh+I9Zj642gVJ8DMRFR+Iu7IeCh47Zt1/mH2VpHTKXb2qDVXWMqP9xD0IM4 y9k+gdbFr8R/aF6/V4hkZGZBo9NoOiXsJEcVjFHRfLVAttz3nP+9XhfzdfEr7jCjCjCl rwmt26wpIulnoFQgyx0n9z/qWcyLmXlQkz2/W6wdFoh6G+Yo3FOtf20g7cEGrAy3YsD+ 5VpvmajMJzD5F0hhEwMFNQHHpLbg14x6u3KHhoxOl9IdMjyFe2U+LnSeF3DCOoUfc4nn T/Aw== MIME-Version: 1.0 Received: by 10.112.40.72 with SMTP id v8mr6703689lbk.49.1331664692997; Tue, 13 Mar 2012 11:51:32 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Tue, 13 Mar 2012 11:51:32 -0700 (PDT) In-Reply-To: <4F5F89CD.10207@gmail.com> References: <20120312170644.5201.85558.idtracker@ietfa.amsl.com> <4F5F89CD.10207@gmail.com> Date: Tue, 13 Mar 2012 14:51:32 -0400 X-Google-Sender-Auth: LkdtJn8vcWCNfogmrg_xHW9rBIs Message-ID: Subject: Re: I-D Action: draft-ietf-6man-6lobac-01.txt From: Kerry Lynn To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 18:51:43 -0000 Hi Alex, Thanks for your comment. I was following the method of generating IIDs used by 6LoWPAN [RFC 4944]. I note that RFC 4291 states in section 2.5.1 "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." Technically, locally assigned MS/TP IIDs could be shorter than 64 bits. However, if EUI-64s become popular for MS/TP devices there might then be a situation where some devices have 64-bit IIDs and others have shorter. I am also not sure how a numbering scheme that uses prefixes longer than 64 bits would work in the general case (given that many other data links use 64-bit IIDs). -K- On Tue, Mar 13, 2012 at 1:54 PM, Alexandru Petrescu wrote: > HEllo, > > A side note about this. =A0It is not a request for modification, just a > thought. > > I wonder why do we want the Interface Identifier to be of length 64 when > the MS/TP node address seems to be 8bit only. > > In a sense, it may be because SLAAC over Ethernet (802) is used to use > 64bit IIDs. > > But in another sense, this is not Ethernet and hence the IID could be of > length 8bit of MS/TP, right? > > I am asking this because of other contexts (non-MS/TP) whereby the > link-layer addresses are shorter than 48bit and yet the Interface ID is > still 64bit, "to make SLAAC work". > > In some contexts too, the ISP delivers a 64bit prefix to a leaf network > and if that IID is almost always 64bit it means that it's hard next to > impossible to form sub-prefixes of that ISP 64bit prefix and still use > SLAAC. > > In a sense, it would be better to define the IIDs of MS/TP (or other > link) to be of length 8, allow the ISP to assign 64bit prefix to leaf > network, and let the gateway in between to derive prefixes out of that > 64bit (up to 120) and still use SLAAC. > > This is just a thought, not a request to modify. > > Yours, > > Alex > > Le 13/03/2012 12:47, Kerry Lynn a =E9crit : > >> Greetings, >> >> The main changes to the WG version of this draft are: a) tweaks that >> resulted from the initial public review of the BACnet MS/TP change >> proposal, the most significant being the COBS encoding of data and >> data crc fields to remove preamble sequences; and b) addition of two >> informative appendices to provide code examples for the data crc and >> COBS encoder/decoder. =A0These appendices are insufficient to implement >> the data link, but are provided e.g. for those writing Wireshark >> dissectors or otherwise wanting more detail about over- the-wire >> format. >> >> I'd like to solicit specific comments on what is needed to move this >> draft forward - IOW, what would you like to see added in order for >> this draft to be ready for WGLC? >> >> For anyone who'd like to view the details of data link state >> machines, etc., I can provide the relevant clause (9) of the ASHRAE >> 135-2010 (BACnet) spec, as well as the MS/TP change proposal >> (Addendum an). >> >> Thanks, -K- >> >> >> On Mon, Mar 12, 2012 at 1:06 PM, =A0wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the IPv6 Maintenance >>> Working Group of the IETF. >>> >>> Title =A0 =A0 =A0 =A0 =A0 : Transmission of IPv6 over MS/TP Networks >>> Author(s) =A0 =A0 =A0 : Kerry Lynn Jerry Martocci Carl Neilson Stuart >>> Donaldson Filename =A0 =A0 =A0 =A0: draft-ietf-6man-6lobac-01.txt Pages >>> : 20 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-03-12 >>> >>> MS/TP (Master-Slave/Token-Passing) is a contention-free access >>> method for the RS-485 physical layer that is used extensively in >>> building automation networks. =A0This document describes the frame >>> format for transmission of IPv6 packets and the method of forming >>> link-local and statelessly autoconfigured IPv6 addresses on MS/TP >>> networks. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt >>> >>> -------------------------------------------------------------------- >>> >>> > IETF IPv6 working group mailing list >>> >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >>> > -------------------------------------------------------------------- >> >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From gorry@erg.abdn.ac.uk Tue Mar 13 13:47:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDB821F86D7 for ; Tue, 13 Mar 2012 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlM2Z-Uvtiys for ; Tue, 13 Mar 2012 13:47:14 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id D46AD21F86D8 for <6man@ietf.org>; Tue, 13 Mar 2012 13:47:10 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q2DKl1oX001998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2012 20:47:01 GMT Message-ID: <4F5FB248.6030407@erg.abdn.ac.uk> Date: Tue, 13 Mar 2012 20:47:04 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: 6man@ietf.org Subject: draft-ietf-6man-udpchecksums-02.txt References: <4F5F0B41.8070705@erg.abdn.ac.uk> In-Reply-To: <4F5F0B41.8070705@erg.abdn.ac.uk> X-Forwarded-Message-Id: <4F5F0B41.8070705@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Mailman-Approved-At: Tue, 13 Mar 2012 13:48:00 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:47:15 -0000 Marshall & Philip, I've read the new draft, and have a few new comments. Hope these are helpful - happy to discuss if this seems useful. Best wishes, Gorry ---- BOILER PLATE: - Please an Updates line:goprry "Updates RFC2460 (if approved)" ---- Section 3: "there is no additional benefit and indeed some cost to nodes to both compute and check the UDP checksum of the outer (encapsulating) header." - I do not think this sentence is really true, and I think it's important that we do get this right. I suggest there ARE benefits in performing a UDP integrity check for IPv6, see Section 3 of I-D.ietf-6man-udpzero. However, I agree that omitting this check can reduce the forwarding cost for systems that perform the check in software. ---- Section 3: "to set the checksum field of the outer header only to 0 and skip both the sender and receiver computation." - Could we insert a "UDP transport" between "outer" and "header" above, so there can be no confusion with the network layer headers. ---- Section 4: "In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine (9) constraints on the usage of a zero checksum for UDP over IPv6. We agree with the restrictions proposed, and in fact proposed some of those restrictions ourselves in the previous version of the current draft. These restrictions are incorporated into the proposed changes below." - This reads rather like a paper. ietf-6man-udpzero is also a working group document, and I would like to think we can find better language. I suggest something like: "Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements that introduce constraints on the usage of a zero checksum for UDP over IPv6. This document is intended to satisfy these requirements." ---- Section 4: "inspection firewall devices or other middleboxes actually checking" - remove "actually"? ---- Section 4: "This is would be an issue also for legacy systems which have not implemented the change in the IPv6 specification. So in any case, there may be packet loss of lightweight tunneling packets because of mixed new-rule and old-rule nodes." - Seems like it could be improved. I suggest: "This would be an issue also for any legacy IPv6 system that has not implemented the change to the IPv6 specification. In this case, the system will discard the zero-checksum UDP packets, and should log this as an error." ---- Section 4: " As an example, we discuss how can errors be detected and " ^^^ - remove "can" ---- Section 4: "Note that other (non-tunneling) protocols may have different approaches." - suggest replace add: ", but these are not the topic of this update." ---- Section 4: "The control packets can also contain any negotiation that is necessary to set up the endpoint/adapters to accept UDP packets with a zero checksum." - this needs to be enabled for each flow, so please add: "The control packets may also carry any negotiation that is necessary to set up the endpoint/adapters to identify the set of ports that need to enable reception UDP datagrams with a zero checksum." ---- Section 4: "Only UDP packets containing tunneled packets should have a UDP checksum equal to zero." - Please use keywords. e.g. "A system MUST NOT set the UDP checksum to zero in packets that do not contain tunneled packets." ---- Section 4: "We note that these outcomes not equally likely, as most require multiple bit errors with errored bits in separate fields. " - It seems wrong to suggest that single bit inversions are a likely cause of residual errors at the transport layer. I do not think this is the case. I suggest direct replacement of a sequence of bytes is a likely form of corruption. Suggest you omit the second part of the sentence? ---- Section 4: " If it is some other application, with very high probability, the application will not recognize the contents of the packet." - I disagree - it all comes down to applications design. The detection is only if the app is defined this way, since the transport does not know, etc. RFC 5405 provides recommended best current practice for applications in general. ---- Section 4: - I think the wording of this section needs to be tightened.It would be good to see more of a focus on what needs to be implemented, rather than discussing the guidance provided in the other working group document. If the guidance itself needs to be updated, then it would be good to explore this - We'd be happy to update the text and guidance if there is something more that should be said. ---- Section 5: " outer encapsulating packet of a lightweight tunneling protocol." - is it intentional to permit this only for *lightweight* tunneling protocols? - The initial request was for *any* tunneling protocol that meets the requirements. ---- Section 5: "UDP endpoints that implement this solution MUST change their behavior and not discard UDP packets received with a 0 checksum on the outer packet of tunneling protocols." - I think we really should add a few words about being enabled only for the set of ports that are supported by system for use by tunneling protocol(s). ---- Section 5: "its behavior should be as specified originally." - replace "should be as specified originally", by "is not updated and uses the method specified in RFC2460". ---- Section 6: " The persistence of this issue among a significant number of protocols being developed in the IETF requires a definitive policy." - Is this a recommendation for more work, or a statement of the motivation for this document. I was not sure. ---- Section 6: - I think it could be useful to include the points in section 6 possibly also as a part of ietf-6man-udpzero. What do you think? ---- I'd suggest we add a normative citation to RFC 5405, stating that this provides the IETF guidance on the design of applications using UDP and includes guidelines on the usage of checksums by application designers. - Possibly best placed in the introduction, indicating that this document adds to this for the case of tunneling applications. ---- -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683. From marshall.eubanks@gmail.com Tue Mar 13 14:40:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD1F21E8015 for ; Tue, 13 Mar 2012 14:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.233 X-Spam-Level: X-Spam-Status: No, score=-103.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXgPM0N3ZmZZ for ; Tue, 13 Mar 2012 14:40:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72621F864A for <6man@ietf.org>; Tue, 13 Mar 2012 14:40:43 -0700 (PDT) Received: by lagj5 with SMTP id j5so1063983lag.31 for <6man@ietf.org>; Tue, 13 Mar 2012 14:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PuRjyhKV+NcNkBKfmdtMhZedw1OpCcLn2Pkil8rmMjE=; b=QH5JdtJILgpoLMV4OtABAwxerbjheZ3OYoi6HmUUWFE6/An9KrjbK7Dtp32Lc4hjlZ nQUY+xl5FH3PoQEV4Mb2QTfjuUqy/uhoex/y8feNJ1Q5fcIzuTHJXEp3q34FIEC/TBxL X8+W+R8hkG6w+yLjmEX/qPbaSLiSdCvDupC9zBzPlNAWNZ86IZCDpzujM47JVgspaKrb FAszueMy4/FVEJfK5PaC/uUNVeRkbYiQjiZcEbK4kie5DSKCociStP3SFPwt0t1F9rw4 Wljx3n1Uw3W4AtK7QiME5ewYhwU3T8SANDGMp4P8K9y5ImeyANkMhczHGWy11+90xI6l V2lw== MIME-Version: 1.0 Received: by 10.112.83.105 with SMTP id p9mr51387lby.43.1331674843106; Tue, 13 Mar 2012 14:40:43 -0700 (PDT) Received: by 10.112.115.98 with HTTP; Tue, 13 Mar 2012 14:40:43 -0700 (PDT) In-Reply-To: <4F5FB248.6030407@erg.abdn.ac.uk> References: <4F5F0B41.8070705@erg.abdn.ac.uk> <4F5FB248.6030407@erg.abdn.ac.uk> Date: Tue, 13 Mar 2012 17:40:43 -0400 Message-ID: Subject: Re: draft-ietf-6man-udpchecksums-02.txt From: Marshall Eubanks To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 13 Mar 2012 15:06:41 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 21:40:45 -0000 Dear Gorry; Thanks for the read. On Tue, Mar 13, 2012 at 4:47 PM, Gorry Fairhurst wro= te: > > Marshall & =A0Philip, I've read the new draft, and have a few new comment= s. > Hope these are helpful - happy to discuss if this seems useful. > > Best wishes, > > Gorry > > ---- > BOILER PLATE: > - Please an Updates line:goprry > "Updates RFC2460 (if approved)" > > ---- > Section 3: > =A0"there is no additional > =A0 benefit and indeed some cost to nodes to both compute and check the > =A0 UDP checksum of the outer (encapsulating) header." > > - I do not think this sentence is really true, and I think it's > important that we do get this right. I suggest there ARE benefits in > performing a UDP integrity check for IPv6, see Section 3 of > I-D.ietf-6man-udpzero. However, I agree that omitting this check can > reduce the forwarding cost for systems that perform the check in software= . How about there is both a benefit and a cost to compute and check the =A0 UDP checksum of the outer (encapsulating) header. In certain cases, where reducing the forwarding cost is important, such as for systems that perform the check in software, the cost may outweigh the benefit; this document describes a means to avoid that cost, in the case where there is an inner header with a checksum. > > ---- > Section 3: > =A0"to set the checksum field of the > =A0 outer header only to 0 and skip both the sender and receiver > =A0 computation." > > - Could we insert a "UDP transport" between "outer" and "header" above, > so there can be no confusion with the network layer headers. OK > > ---- > Section 4: > =A0 "In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine > =A0 (9) constraints on the usage of a zero checksum for UDP over IPv6. > =A0 We agree with the restrictions proposed, and in fact proposed some of > =A0 those restrictions ourselves in the previous version of the current > =A0 draft. =A0These restrictions are incorporated into the proposed chang= es > =A0 below." > > - This reads rather like a paper. ietf-6man-udpzero is also a working > group document, and I would like to think we can find better language. > I suggest something like: > > =A0 "Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements > =A0 that introduce constraints on the usage of a zero checksum for > =A0 UDP over IPv6. This document is intended to satisfy these > =A0 requirements." > This WFM, > ---- > Section 4: > =A0"inspection firewall devices or other middleboxes actually checking" > - remove "actually"? WFM > > ---- > Section 4: > =A0"This is would be an issue also for legacy systems > =A0 which have not implemented the change in the IPv6 specification. =A0S= o > =A0 in any case, there may be packet loss of lightweight tunneling > =A0 packets because of mixed new-rule and old-rule nodes." > > - Seems like it could be improved. I suggest: > =A0"This would be an issue also for any legacy IPv6 system > =A0 that has not implemented the change to the IPv6 specification. In > =A0 this case, the system will discard the zero-checksum UDP > =A0 packets, and should log this as an error." > This is not a prescription, but an observation (i.e. we can't say SHOULD log this as an error here). How about =A0"This would be an issue also for any legacy IPv6 system =A0 that has not implemented the change to the IPv6 specification. In =A0 this case, the system should discard the zero-checksum UDP =A0 packets, and log this as an error." > ---- > Section 4: > " =A0 As an example, we discuss how can errors be detected and " > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^ > - remove "can" ACK > > ---- > Section 4: > =A0"Note that other (non-tunneling) protocols may have > =A0 different approaches." > - suggest replace add: > =A0", but these are not the topic of this update." > WFM > ---- > Section 4: > =A0"The control packets can > =A0 also contain any negotiation that is necessary to set up the > =A0 endpoint/adapters to accept UDP packets with a zero checksum." > - this needs to be enabled for each flow, so please add: > "The control packets may > =A0 =A0 =A0also carry any negotiation that is necessary to set up the how about s/that is necessary to set up the/required to enable the/ > =A0 =A0 =A0endpoint/adapters to identify the set of ports that > =A0 =A0 =A0need to enable reception UDP datagrams with a zero > =A0 =A0 =A0 checksum." > > ---- > Section 4: > "Only UDP packets containing tunneled packets should have a UDP > =A0 =A0 =A0checksum equal to zero." > - Please use keywords. e.g. > =A0"A system MUST NOT set the UDP checksum to zero in packets that do > not contain tunneled packets." > OK > ---- > Section 4: > "We note that > =A0 =A0 =A0these outcomes not equally likely, as most require multiple bi= t > =A0 =A0 =A0errors with errored bits in separate fields. " > - It seems wrong to suggest that single bit inversions are a likely > cause of residual errors at the transport layer. I do not think this is > the case. I suggest direct replacement of a sequence of bytes is a > likely form of corruption. Suggest you omit the second part of the senten= ce? OK. Note that there is a missing "are" before "not," which I have also fixe= d. > > ---- > Section 4: > " If it is some > =A0 =A0 =A0 =A0 other application, with very high probability, the applic= ation > =A0 =A0 =A0 =A0 will not recognize the contents of the packet." > - I disagree - it all comes down to applications design. The detection > is only if the app is defined this way, since the transport does not > know, etc. RFC 5405 provides recommended best current practice for > applications in general. Do you have alternate text ? How about s/will not/may not/ ? > > ---- > Section 4: > - I think the wording of this section needs to be tightened.It would be > good to see more of a focus on what needs to be implemented, rather than > discussing the guidance provided in the other working group document. > > If the guidance itself needs to be updated, then it would be good to > explore this - We'd be happy to update the text and guidance if there is > something more that should be said. > > ---- > Section 5: > " =A0 outer encapsulating packet of a lightweight tunneling protocol." > - is it intentional to permit this only for *lightweight* tunneling > protocols? - The initial request was for *any* tunneling protocol that > meets the requirements. s/lightweight // I am not sure why we say "lightweight tunneling protocols" - I think that is a legacy from previous discussions. I don't think that there is a definition of what "lightweight" means , and propose changing most occurrences of it to simple "tunneling protocols." > > ---- > Section 5: > "UDP > =A0 endpoints that implement this solution MUST change their behavior and > =A0 not discard UDP packets received with a 0 checksum on the outer > =A0 packet of tunneling protocols." > - I think we really should add a few words about being enabled only for > the set of ports that are supported by system for use by tunneling > protocol(s). > OK > ---- > > Section 5: > "its behavior should be as specified originally." > - replace "should be as specified originally", by "is not updated and > uses the method specified in RFC2460". > OK > ---- > Section 6: > " =A0 The persistence of this issue among a significant number of > protocols being developed in the IETF requires a definitive policy." > - Is this a recommendation for more work, or a statement of the > motivation for this document. I was not sure. The latter. I will adjust the text to make that clear. > > ---- > Section 6: > - I think it could be useful to include the points in section 6 possibly > also as a part of ietf-6man-udpzero. What do you think? > OK by me. > > ---- > I'd suggest we add a normative citation to RFC 5405, stating that this > provides the IETF guidance on the design of applications using UDP and > includes guidelines on the usage of checksums by application designers. > > - Possibly best placed in the introduction, indicating that this > document adds to this for the case of tunneling applications. OK. I will reference section 3.4 Thanks again ! Regards Marshall > > ---- > > > -- > Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. > The University of Aberdeen is a charity registered in Scotland, > No SC013683. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Mar 13 16:24:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62A21E806D for ; Tue, 13 Mar 2012 16:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.438 X-Spam-Level: X-Spam-Status: No, score=-103.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq1xpKZz02hV for ; Tue, 13 Mar 2012 16:24:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3E2F21E805E for ; Tue, 13 Mar 2012 16:24:19 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1341379ggm.31 for ; Tue, 13 Mar 2012 16:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=fKOaKC/MHjypG1RozhY796j8VPIqwEaN+XOZdge58vE=; b=Pn9N8snevzFwH5Q3tSrkzfc1/AGn9/N20mlcXFG2t0jwOa48gwGfbkLRYhqO3VKXEU a4nav/SMjh31ztUU8iZgH8jPjS7kWXuq1IimAM98E9la1J0oWAVlghYf8c/rdthPx1H9 4dKPGGwdCTNX+td10Dytx3wEXpIKTVtH6vpNoFPsWAhLy+pKZUFmqxXtMpzHG8aGsFYa mwj8+/XUxldutVhq5vPPAF7YcBnqTitDgVNx4QN3xQSrk4gmT8igxdTNsN6FlUmwq4rv ueu0hr7k3GBYgsVFYNGUuWGeNRBmcH/mdgojiQoS0L4aUAM8p+RGWplTWUR7hul0ZsaI RcVw== Received: by 10.182.1.104 with SMTP id 8mr521647obl.19.1331681054737; Tue, 13 Mar 2012 16:24:14 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id c2sm2179233oeb.13.2012.03.13.16.24.13 (version=SSLv3 cipher=OTHER); Tue, 13 Mar 2012 16:24:14 -0700 (PDT) Message-ID: <4F5FD71A.9030703@gmail.com> Date: Wed, 14 Mar 2012 12:24:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: draft-gont-6man-flowlabel-security-03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 23:24:20 -0000 Here are my comments on this draft. > 1. Introduction > > The flow label is a 20-bit field that allows a source to label > sequences of packets for which it requests special handling by IPv6 > routers (e.g., non-default quality of service). I think the clause starting "for which" should be deleted. It really refers to the description in Appendix A of RFC 2460, which is obsolete (and see further comments below). > 2. Vulnerability analysis > > 2.1. RFC3697-compliant implementations Are there any of those? I've seen very little evidence that they exist. More seriously, this section mixes up issues that derive from Appendix A of RFC 2460 with issues that derive from RFC 3697. RFC 2460 says this about the flow label: >> This aspect of IPv6 is, at the time of >> writing, still experimental and subject to change as the requirements >> for flow support in the Internet become clearer. Hosts or routers >> that do not support the functions of the Flow Label field are >> required to set the field to zero when originating a packet, pass the >> field on unchanged when forwarding a packet, and ignore the field >> when receiving a packet. >> >> Appendix A describes the current intended semantics and usage of the >> Flow Label field. This makes it clear (to me, at least) that Appendix A was not normative; it had experimental status. It was a mistake that RFC 3697 did not obsolete Appendix A. That doesn't invalidate the security analysis of Appendix A, but is there any evidence that the rules quoted from Appendix A were ever implemented? > 2.1.1. DoS resulting from verification of Flow Label consistency This section is entirely based on Appendix A rules, not RFC 3697. ... > Therefore, while this verification might be of help to mitigate some > blind attacks by obfuscation, we believe the drawbacks of performing > such verification outweigh the potential benefits, and thus recommend > systems to not perform such verification. Agreed - that is one of the reasons that RFC 6437 obsoleted Appendix A. > 2.1.2. Covert channels > > As virtually every protocol header field, the Flow Label could be > used to implement a covert channel. In those network environments in > which the Flow Label is not used, middle-boxes such as packet > scrubbers could eliminate this covert channel by resetting the Flow > Label with zero... Since the flow label is supposed to be sent end-to-end, in all three models (RFC 2460, RFC 3697, RFC 6437), middleboxes must not do this. The possible exception case is explained carefully in Section 6.1 of RFC 6437. That text was the result of a tremendous discussion in 6man, and we don't want to repeat it, do we? > 2.1.4. Information Leaking > > If a host selects the Flow Label values of outgoing packets such that > the resulting sequence of Flow Label values is predictable, this > could result in an information leakage. Specifically, if a host sets > the Flow Label value of outgoing packets from a system-wide counter, > the number of "outgoing flows" would be leaked. That behaviour would be an explicit violation of Appendix A of RFC 2460, but unfortunately it was explicitly allowed by RFC 3697. It is again a violation of RFC 6437, fortunately. In general: given that RFC 2460 Appendix A and RFC 3697 are both obsolete and probably unimplemented, I am not sure what we gain from this security analysis, compared to the analysis included in RFC 6437. > 3.1. Recommended algorithm >From my experiences testing out some algorithms, I am convinced that we should not recommend an algorithm, but simply leave implementors of RFC 6437 to make their choices. Of course there is no harm in publishing suggested algorithms, as we've done in the tech report I announced recently. But I really think there's nothing to gain by formally recommending a specific algorithm. That said, > ...we RECOMMEND that the Flow > Label of each flo be selected acording to a PRNG. That is, each Flow > Label would be selected with: > > Flow Label = random() It should be made clear that this is a stateful algorithm for use in the source host, which has to keep some state for each flow anyway. We don't expect routers that are setting the flow label to use a stateful method. > where: > > random(): > Is a a Pseudo-Random Number Generator (PRNG). It needs to be a PRNG with good properties - whatever random function shows up in a typical C library may not be good enough. > 3.2. Alternative Algorithm > > Implemenatations concerned with the Flow Label reuse frequency of the > algorithm specified in Section 3.1 MAY use the following alternative > scheme, which aims at minimizing the Flow Label reuse frequency by > producing per-destination monotonically-increasing Flow Label values. That concern is pretty much irrelevant unless you have a very bad PRNG. In a space of one million values, reuse (by a given source) is rare, and doesn't matter as far as load balancing goes (as discussed on the thread for draft-carpenter-v6ops-label-balance). Also, I believe that this approach conflicts with RFC 6437: >> ...If a hash >> algorithm is used, as suggested in Section 3, it SHOULD include a >> step that makes the flow label value significantly difficult to >> predict [RFC4086], even with knowledge of the algorithm being used. The monotonic increase allows observers to predict future values with some probability of success. It also works against the goal of a uniform distribution of values, which wanted for load balancing anyway. Brian From fgont@si6networks.com Tue Mar 13 18:24:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2FE21E802A for ; Tue, 13 Mar 2012 18:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP3s31SJG4zt for ; Tue, 13 Mar 2012 18:24:26 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 286E421E801B for ; Tue, 13 Mar 2012 18:24:25 -0700 (PDT) Received: from [2001:5c0:1400:a::3fb] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S7cwy-0000Ev-8U; Wed, 14 Mar 2012 02:24:24 +0100 Message-ID: <4F5FF342.9050906@si6networks.com> Date: Tue, 13 Mar 2012 22:24:18 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: draft-gont-6man-flowlabel-security-03 References: <4F5FD71A.9030703@gmail.com> In-Reply-To: <4F5FD71A.9030703@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 01:24:35 -0000 Hi, Brian, Thanks so much for your review! Please find my comments inline... On 03/13/2012 08:24 PM, Brian E Carpenter wrote: >> 1. Introduction >> >> The flow label is a 20-bit field that allows a source to label >> sequences of packets for which it requests special handling by IPv6 >> routers (e.g., non-default quality of service). > > I think the clause starting "for which" should be deleted. It really refers > to the description in Appendix A of RFC 2460, which is obsolete (and see > further comments below). Agreed. -- I will fix this in the next rev. >> 2. Vulnerability analysis >> >> 2.1. RFC3697-compliant implementations > > Are there any of those? I've seen very little evidence that they > exist. Well, any implementation that existed before the recent RFC3697 update were most likely RFC3696-compliant... > More seriously, this section mixes up issues that derive > from Appendix A of RFC 2460 with issues that derive from RFC 3697. > RFC 2460 says this about the flow label: > >>> This aspect of IPv6 is, at the time of >>> writing, still experimental and subject to change as the requirements >>> for flow support in the Internet become clearer. Hosts or routers >>> that do not support the functions of the Flow Label field are >>> required to set the field to zero when originating a packet, pass the >>> field on unchanged when forwarding a packet, and ignore the field >>> when receiving a packet. >>> >>> Appendix A describes the current intended semantics and usage of the >>> Flow Label field. > > This makes it clear (to me, at least) that Appendix A was not normative; > it had experimental status. It was a mistake that RFC 3697 did not > obsolete Appendix A. Well, if it was not obsoleted, it was still valid. > That doesn't invalidate the security analysis of Appendix A, but is > there any evidence that the rules quoted from Appendix A were ever > implemented? You mean that of validating that all packets have the same extension headers? >> 2.1.2. Covert channels >> >> As virtually every protocol header field, the Flow Label could be >> used to implement a covert channel. In those network environments in >> which the Flow Label is not used, middle-boxes such as packet >> scrubbers could eliminate this covert channel by resetting the Flow >> Label with zero... > > Since the flow label is supposed to be sent end-to-end, in all three > models (RFC 2460, RFC 3697, RFC 6437), middleboxes must not do this. > The possible exception case is explained carefully in Section 6.1 of > RFC 6437. That text was the result of a tremendous discussion in 6man, > and we don't want to repeat it, do we? I certainly wouldn't want to repeat such discussion.SHould I keep the first sentence of the above paragraph, and then provide a pointer to Section 6.1 of RFC 6437? (I should note, though, that if we wanted the FL to "MUST NOT be changed en route", it should at the very least be covered by a checksum... which is not) >> 2.1.4. Information Leaking >> >> If a host selects the Flow Label values of outgoing packets such that >> the resulting sequence of Flow Label values is predictable, this >> could result in an information leakage. Specifically, if a host sets >> the Flow Label value of outgoing packets from a system-wide counter, >> the number of "outgoing flows" would be leaked. > > That behaviour would be an explicit violation of Appendix A of RFC 2460, > but unfortunately it was explicitly allowed by RFC 3697. It is again > a violation of RFC 6437, fortunately. I don't follow how this would be a violation of Appendix A of RFC 2460.... > In general: given that RFC 2460 Appendix A and RFC 3697 are both > obsolete and probably unimplemented, I am not sure what we gain from > this security analysis, compared to the analysis included in RFC 6437. It's the specification we had for more than ten years, which might be implemented and deployed? >> 3.1. Recommended algorithm > >>From my experiences testing out some algorithms, I am convinced that we > should not recommend an algorithm, but simply leave implementors of > RFC 6437 to make their choices. Of course there is no harm in publishing > suggested algorithms, as we've done in the tech report I announced > recently. But I really think there's nothing to gain by formally > recommending a specific algorithm. I've no objections to that. I can remove the "RECOMMNEDED" (etc) language if deemed appropriate.... > That said, > >> ...we RECOMMEND that the Flow >> Label of each flo be selected acording to a PRNG. That is, each Flow >> Label would be selected with: >> >> Flow Label = random() > > It should be made clear that this is a stateful algorithm for use in the > source host, which has to keep some state for each flow anyway. We don't > expect routers that are setting the flow label to use a stateful method. I don't follow. Are you referring to the fact that the host should "record" the selected random number, or to something else? >> where: >> >> random(): >> Is a a Pseudo-Random Number Generator (PRNG). > > It needs to be a PRNG with good properties - whatever random function > shows up in a typical C library may not be good enough. Agreed ("random()" wasn't mean to be C's random() function) -- I should propbably add a reference to the "random numbers" RFC here... >> 3.2. Alternative Algorithm >> >> Implemenatations concerned with the Flow Label reuse frequency of the >> algorithm specified in Section 3.1 MAY use the following alternative >> scheme, which aims at minimizing the Flow Label reuse frequency by >> producing per-destination monotonically-increasing Flow Label values. > > That concern is pretty much irrelevant unless you have a very bad PRNG. There's also the concern of processing cycles, which I didn't mention, but should. > Also, I believe that this approach conflicts with RFC 6437: > >>> ...If a hash >>> algorithm is used, as suggested in Section 3, it SHOULD include a >>> step that makes the flow label value significantly difficult to >>> predict [RFC4086], even with knowledge of the algorithm being used. > > The monotonic increase allows observers to predict future values with > some probability of success. I'd argue that RFC 6437 is underspecified. Certainly, the ability of an attacker guessing the next number depends on what he's able to see. For off-path attackers, it is virtually equally difficult to guess the next FL produced by this algorithm, as it is to guess the next FL that would be produced by "random()". If you now argue "but if the attacker sees the previous FL...", I could answer "if the attacker sees the state variables of the PRNG implementation/instance you're using, he'd be able to guess the FL, too". RFC 6437 is underspecified as to what we can expect the attacker to see, and what's the threat model we have in mind. Me, I think that we should be concerned about off-path attackers, but shouldn't care about on-path attackers: if they are on path, game over (they *see* the FLs... and also would probably launch other -- much more devastating -- attacks). > It also works against the goal of a uniform > distribution of values, which wanted for load balancing anyway. How come that a counter could have a non-uniform distribution?? --- actually, I'd argue that most PRNGs won't give you such a uniform distribution! Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gorry@erg.abdn.ac.uk Wed Mar 14 01:31:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90D321F8688 for ; Wed, 14 Mar 2012 01:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-gRlmhoNm7S for ; Wed, 14 Mar 2012 01:31:14 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5A21F8615 for <6man@ietf.org>; Wed, 14 Mar 2012 01:31:14 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q2E8VAY6012307; Wed, 14 Mar 2012 08:31:10 GMT Received: from localhost (gorry@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) with ESMTP id q2E8VA85012304; Wed, 14 Mar 2012 08:31:10 GMT Date: Wed, 14 Mar 2012 08:31:09 +0000 (GMT) From: gorry@erg.abdn.ac.uk To: Marshall Eubanks Subject: Re: draft-ietf-6man-udpchecksums-02.txt In-Reply-To: Message-ID: References: <4F5F0B41.8070705@erg.abdn.ac.uk> <4F5FB248.6030407@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1331713869=:11981" X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@dee.erg.abdn.ac.uk X-Mailman-Approved-At: Wed, 14 Mar 2012 03:08:36 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 08:31:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1331713869=:11981 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE See in-line: On Tue, 13 Mar 2012, Marshall Eubanks wrote: > Dear Gorry; > > Thanks for the read. > > On Tue, Mar 13, 2012 at 4:47 PM, Gorry Fairhurst w= rote: >> >> Marshall & =A0Philip, I've read the new draft, and have a few new commen= ts. >> Hope these are helpful - happy to discuss if this seems useful. >> >> Best wishes, >> >> Gorry >> >> ---- >> BOILER PLATE: >> - Please an Updates line:goprry >> "Updates RFC2460 (if approved)" >> >> ---- >> Section 3: >> =A0"there is no additional >> =A0 benefit and indeed some cost to nodes to both compute and check the >> =A0 UDP checksum of the outer (encapsulating) header." >> >> - I do not think this sentence is really true, and I think it's >> important that we do get this right. I suggest there ARE benefits in >> performing a UDP integrity check for IPv6, see Section 3 of >> I-D.ietf-6man-udpzero. However, I agree that omitting this check can >> reduce the forwarding cost for systems that perform the check in softwar= e. > > How about > > there is both a benefit and a cost to compute and check the > UDP checksum of the outer (encapsulating) header. In certain cases, > where reducing > the forwarding cost is important, such as for systems that perform the > check in software, > the cost may outweigh the benefit; this document describes a means to > avoid that cost, in > the case where there is an inner header with a checksum. > > Looks good. > >> ---- >> Section 3: >> =A0"to set the checksum field of the >> =A0 outer header only to 0 and skip both the sender and receiver >> =A0 computation." >> >> - Could we insert a "UDP transport" between "outer" and "header" above, >> so there can be no confusion with the network layer headers. > > OK > >> >> ---- >> Section 4: >> =A0 "In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine >> =A0 (9) constraints on the usage of a zero checksum for UDP over IPv6. >> =A0 We agree with the restrictions proposed, and in fact proposed some o= f >> =A0 those restrictions ourselves in the previous version of the current >> =A0 draft. =A0These restrictions are incorporated into the proposed chan= ges >> =A0 below." >> >> - This reads rather like a paper. ietf-6man-udpzero is also a working >> group document, and I would like to think we can find better language. >> I suggest something like: >> >> =A0 "Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements >> =A0 that introduce constraints on the usage of a zero checksum for >> =A0 UDP over IPv6. This document is intended to satisfy these >> =A0 requirements." >> > > This WFM, > >> ---- >> Section 4: >> =A0"inspection firewall devices or other middleboxes actually checking" >> - remove "actually"? > > WFM > >> >> ---- >> Section 4: >> =A0"This is would be an issue also for legacy systems >> =A0 which have not implemented the change in the IPv6 specification. =A0= So >> =A0 in any case, there may be packet loss of lightweight tunneling >> =A0 packets because of mixed new-rule and old-rule nodes." >> >> - Seems like it could be improved. I suggest: >> =A0"This would be an issue also for any legacy IPv6 system >> =A0 that has not implemented the change to the IPv6 specification. In >> =A0 this case, the system will discard the zero-checksum UDP >> =A0 packets, and should log this as an error." >> > > This is not a prescription, but an observation (i.e. we can't say > SHOULD log this as an error here). > The existing spec says systems should log it as an error. > How about > > =A0"This would be an issue also for any legacy IPv6 system > =A0 that has not implemented the change to the IPv6 specification. In > =A0 this case, the system should discard the zero-checksum UDP > =A0 packets, and log this as an error." > OK > >> ---- >> Section 4: >> " =A0 As an example, we discuss how can errors be detected and " >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^ >> - remove "can" > > ACK > >> >> ---- >> Section 4: >> =A0"Note that other (non-tunneling) protocols may have >> =A0 different approaches." >> - suggest replace add: >> =A0", but these are not the topic of this update." >> > > WFM > >> ---- >> Section 4: >> =A0"The control packets can >> =A0 also contain any negotiation that is necessary to set up the >> =A0 endpoint/adapters to accept UDP packets with a zero checksum." >> - this needs to be enabled for each flow, so please add: >> "The control packets may >> =A0 =A0 =A0also carry any negotiation that is necessary to set up the > > how about > > s/that is necessary to set up the/required to enable the/ > >> =A0 =A0 =A0endpoint/adapters to identify the set of ports that >> =A0 =A0 =A0need to enable reception UDP datagrams with a zero >> =A0 =A0 =A0 checksum." >> Better. >> ---- >> Section 4: >> "Only UDP packets containing tunneled packets should have a UDP >> =A0 =A0 =A0checksum equal to zero." >> - Please use keywords. e.g. >> =A0"A system MUST NOT set the UDP checksum to zero in packets that do >> not contain tunneled packets." >> > > OK > >> ---- >> Section 4: >> "We note that >> =A0 =A0 =A0these outcomes not equally likely, as most require multiple b= it >> =A0 =A0 =A0errors with errored bits in separate fields. " >> - It seems wrong to suggest that single bit inversions are a likely >> cause of residual errors at the transport layer. I do not think this is >> the case. I suggest direct replacement of a sequence of bytes is a >> likely form of corruption. Suggest you omit the second part of the sente= nce? > > OK. Note that there is a missing "are" before "not," which I have also fi= xed. > Thanks >> >> ---- >> Section 4: >> " If it is some >> =A0 =A0 =A0 =A0 other application, with very high probability, the appli= cation >> =A0 =A0 =A0 =A0 will not recognize the contents of the packet." >> - I disagree - it all comes down to applications design. The detection >> is only if the app is defined this way, since the transport does not >> know, etc. RFC 5405 provides recommended best current practice for >> applications in general. > > Do you have alternate text ? How about s/will not/may not/ ? > Applications are recommended to verfiy the context of the packets they=20 receive using UDP, as described in RFC 5405. Applications that verify the= =20 context of a datagram are expected to have a high probability of=20 discarding corrupted data. [I-D.ietf-6man-udpzero] presents examples of=20 cases where corruption can inadvertantly impact application state. >> >> ---- >> Section 4: >> - I think the wording of this section needs to be tightened.It would be >> good to see more of a focus on what needs to be implemented, rather than >> discussing the guidance provided in the other working group document. >> >> If the guidance itself needs to be updated, then it would be good to >> explore this - We'd be happy to update the text and guidance if there is >> something more that should be said. >> >> ---- >> Section 5: >> " =A0 outer encapsulating packet of a lightweight tunneling protocol." >> - is it intentional to permit this only for *lightweight* tunneling >> protocols? - The initial request was for *any* tunneling protocol that >> meets the requirements. > > s/lightweight // > > I am not sure why we say "lightweight tunneling protocols" - I think > that is a legacy from previous discussions. I don't think that there > is a definition of what "lightweight" means , and propose changing > most occurrences of it to simple "tunneling protocols." > Seems good. >> >> ---- >> Section 5: >> "UDP >> =A0 endpoints that implement this solution MUST change their behavior an= d >> =A0 not discard UDP packets received with a 0 checksum on the outer >> =A0 packet of tunneling protocols." >> - I think we really should add a few words about being enabled only for >> the set of ports that are supported by system for use by tunneling >> protocol(s). >> > > OK > >> ---- >> >> Section 5: >> "its behavior should be as specified originally." >> - replace "should be as specified originally", by "is not updated and >> uses the method specified in RFC2460". >> > > OK > >> ---- >> Section 6: >> " =A0 The persistence of this issue among a significant number of >> protocols being developed in the IETF requires a definitive policy." >> - Is this a recommendation for more work, or a statement of the >> motivation for this document. I was not sure. > > The latter. I will adjust the text to make that clear. > >> >> ---- >> Section 6: >> - I think it could be useful to include the points in section 6 possibly >> also as a part of ietf-6man-udpzero. What do you think? >> > > OK by me. > >> >> ---- >> I'd suggest we add a normative citation to RFC 5405, stating that this >> provides the IETF guidance on the design of applications using UDP and >> includes guidelines on the usage of checksums by application designers. >> >> - Possibly best placed in the introduction, indicating that this >> document adds to this for the case of tunneling applications. > > OK. I will reference section 3.4 > > Thanks again ! > > Regards > Marshall > >> >> ---- >> >> >> -- >> Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. >> The University of Aberdeen is a charity registered in Scotland, >> No SC013683. >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > Looks like we agree on all the important points, which may be a sign that= =20 it is worth polishing the text and asking for WG accepatnce? Gorry ---559023410-851401618-1331713869=:11981-- From marshall.eubanks@gmail.com Wed Mar 14 07:57:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303B721F87B0 for ; Wed, 14 Mar 2012 07:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.233 X-Spam-Level: X-Spam-Status: No, score=-103.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+rlJcktEklg for ; Wed, 14 Mar 2012 07:57:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A2D1E21F864C for <6man@ietf.org>; Wed, 14 Mar 2012 07:57:25 -0700 (PDT) Received: by lbol12 with SMTP id l12so1007815lbo.31 for <6man@ietf.org>; Wed, 14 Mar 2012 07:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9ddrJtMrSrjpXhnrP7TGYVEUVqBfNt1grl5uuLao/x4=; b=LGet0cO0VCy/p+SHN14pud7zA7+H3PMiLfy2eMQE7/YzO2szn9BLf5QuYe8JFVcMDt 2VuLnb2VNGRPhHTtyHhgGmfQjBMFQ0shh89w8TOAKzCViUZv1iZG6qGoBxGbVJpI8k43 bJ8pE9rCuKhFZWjY86pVHQwL0yYvxzxR0+5AMfxiHTh7MuENdMRyTu3giBevT1r6S+sl r6jdMMb8jg6p1rXNqka8H7jjZmF7gw+Z3ewQuLH6eyDKOzNg48geoHH8WCKP5szRSgfO mqkT04SmqjjJcPc9gdvDaQ5gl46/xx3VnGC1l4KNSb5vRrB+rkqCufuOQb2tCZu7f9kP kOxg== MIME-Version: 1.0 Received: by 10.112.84.233 with SMTP id c9mr1101406lbz.1.1331737044515; Wed, 14 Mar 2012 07:57:24 -0700 (PDT) Received: by 10.112.115.98 with HTTP; Wed, 14 Mar 2012 07:57:24 -0700 (PDT) In-Reply-To: References: <4F5F0B41.8070705@erg.abdn.ac.uk> <4F5FB248.6030407@erg.abdn.ac.uk> Date: Wed, 14 Mar 2012 10:57:24 -0400 Message-ID: Subject: Re: draft-ietf-6man-udpchecksums-02.txt From: Marshall Eubanks To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 14 Mar 2012 08:12:03 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:57:27 -0000 Dear Gorry; A few matters in-line. On Wed, Mar 14, 2012 at 4:31 AM, wrote: > > See in-line: > > > On Tue, 13 Mar 2012, Marshall Eubanks wrote: > >> Dear Gorry; >> >> Thanks for the read. >> >> On Tue, Mar 13, 2012 at 4:47 PM, Gorry Fairhurst >> wrote: >>> >>> >>> Marshall & =A0Philip, I've read the new draft, and have a few new comme= nts. >>> Hope these are helpful - happy to discuss if this seems useful. >>> >>> Best wishes, >>> >>> Gorry >>> >>> ---- >>> BOILER PLATE: >>> - Please an Updates line:goprry >>> "Updates RFC2460 (if approved)" >>> >>> ---- >>> Section 3: >>> =A0"there is no additional >>> =A0 benefit and indeed some cost to nodes to both compute and check the >>> =A0 UDP checksum of the outer (encapsulating) header." >>> >>> - I do not think this sentence is really true, and I think it's >>> important that we do get this right. I suggest there ARE benefits in >>> performing a UDP integrity check for IPv6, see Section 3 of >>> I-D.ietf-6man-udpzero. However, I agree that omitting this check can >>> reduce the forwarding cost for systems that perform the check in >>> software. >> >> >> How about >> >> there is both a benefit and a cost to =A0compute and check the >> UDP checksum of the outer (encapsulating) header. In certain cases, >> where reducing >> the forwarding cost is important, such as for systems that perform the >> check in software, >> the cost may outweigh the benefit; this document describes a means to >> avoid that cost, in >> the case where there is an inner header with a checksum. >> >> > Looks good. > >> >>> ---- >>> Section 3: >>> =A0"to set the checksum field of the >>> =A0 outer header only to 0 and skip both the sender and receiver >>> =A0 computation." >>> >>> - Could we insert a "UDP transport" between "outer" and "header" above, >>> so there can be no confusion with the network layer headers. >> >> >> OK >> >>> >>> ---- >>> Section 4: >>> =A0 "In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nin= e >>> =A0 (9) constraints on the usage of a zero checksum for UDP over IPv6. >>> =A0 We agree with the restrictions proposed, and in fact proposed some = of >>> =A0 those restrictions ourselves in the previous version of the current >>> =A0 draft. =A0These restrictions are incorporated into the proposed cha= nges >>> =A0 below." >>> >>> - This reads rather like a paper. ietf-6man-udpzero is also a working >>> group document, and I would like to think we can find better language. >>> I suggest something like: >>> >>> =A0 "Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements >>> =A0 that introduce constraints on the usage of a zero checksum for >>> =A0 UDP over IPv6. This document is intended to satisfy these >>> =A0 requirements." >>> >> >> This WFM, >> >>> ---- >>> Section 4: >>> =A0"inspection firewall devices or other middleboxes actually checking" >>> - remove "actually"? >> >> >> WFM >> >>> >>> ---- >>> Section 4: >>> =A0"This is would be an issue also for legacy systems >>> =A0 which have not implemented the change in the IPv6 specification. = =A0So >>> =A0 in any case, there may be packet loss of lightweight tunneling >>> =A0 packets because of mixed new-rule and old-rule nodes." >>> >>> - Seems like it could be improved. I suggest: >>> =A0"This would be an issue also for any legacy IPv6 system >>> =A0 that has not implemented the change to the IPv6 specification. In >>> =A0 this case, the system will discard the zero-checksum UDP >>> =A0 packets, and should log this as an error." >>> >> >> This is not a prescription, but an observation (i.e. we can't say >> SHOULD log this as an error here). >> > The existing spec says systems should log it as an error. > Yes. My point was just that I didn't want to say >>> =A0 packets, and SHOULD log this as an error." as we are not prescribing anything for systems that have not been updated. If they are going to update, they should update to the new standard. > >> How about >> >> =A0"This would be an issue also for any legacy IPv6 system >> =A0 that has not implemented the change to the IPv6 specification. In >> =A0 this case, the system should discard the zero-checksum UDP How about s/system/system (according to RFC 2460)/ just to make the point clear. >> =A0 packets, and log this as an error." >> > OK > >> >>> ---- >>> Section 4: >>> " =A0 As an example, we discuss how can errors be detected and " >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^ >>> - remove "can" >> >> >> ACK >> >>> >>> ---- >>> Section 4: >>> =A0"Note that other (non-tunneling) protocols may have >>> =A0 different approaches." >>> - suggest replace add: >>> =A0", but these are not the topic of this update." >>> >> >> WFM >> >>> ---- >>> Section 4: >>> =A0"The control packets can >>> =A0 also contain any negotiation that is necessary to set up the >>> =A0 endpoint/adapters to accept UDP packets with a zero checksum." >>> - this needs to be enabled for each flow, so please add: >>> "The control packets may >>> =A0 =A0 =A0also carry any negotiation that is necessary to set up the >> >> >> how about >> >> s/that is necessary to set up the/required to enable the/ >> >>> =A0 =A0 =A0endpoint/adapters to identify the set of ports that >>> =A0 =A0 =A0need to enable reception UDP datagrams with a zero >>> =A0 =A0 =A0 checksum." >>> > Better. > > >>> ---- >>> Section 4: >>> "Only UDP packets containing tunneled packets should have a UDP >>> =A0 =A0 =A0checksum equal to zero." >>> - Please use keywords. e.g. >>> =A0"A system MUST NOT set the UDP checksum to zero in packets that do >>> not contain tunneled packets." >>> >> >> OK >> >>> ---- >>> Section 4: >>> "We note that >>> =A0 =A0 =A0these outcomes not equally likely, as most require multiple = bit >>> =A0 =A0 =A0errors with errored bits in separate fields. " >>> - It seems wrong to suggest that single bit inversions are a likely >>> cause of residual errors at the transport layer. I do not think this is >>> the case. I suggest direct replacement of a sequence of bytes is a >>> likely form of corruption. Suggest you omit the second part of the >>> sentence? >> >> >> OK. Note that there is a missing "are" before "not," which I have also >> fixed. >> > Thanks > > >>> >>> ---- >>> Section 4: >>> " If it is some >>> =A0 =A0 =A0 =A0 other application, with very high probability, the appl= ication >>> =A0 =A0 =A0 =A0 will not recognize the contents of the packet." >>> - I disagree - it all comes down to applications design. The detection >>> is only if the app is defined this way, since the transport does not >>> know, etc. RFC 5405 provides recommended best current practice for >>> applications in general. >> >> >> Do you have alternate text ? How about s/will not/may not/ ? >> > Applications are recommended to verfiy the context of the packets they > receive using UDP, as described in RFC 5405. Applications that verify the > context of a datagram are expected to have a high probability of discardi= ng > corrupted data. [I-D.ietf-6man-udpzero] presents examples of cases where > corruption can inadvertantly impact application state. > > WFM > >>> >>> ---- >>> Section 4: >>> - I think the wording of this section needs to be tightened.It would be >>> good to see more of a focus on what needs to be implemented, rather tha= n >>> discussing the guidance provided in the other working group document. >>> >>> If the guidance itself needs to be updated, then it would be good to >>> explore this - We'd be happy to update the text and guidance if there i= s >>> something more that should be said. >>> >>> ---- >>> Section 5: >>> " =A0 outer encapsulating packet of a lightweight tunneling protocol." >>> - is it intentional to permit this only for *lightweight* tunneling >>> protocols? - The initial request was for *any* tunneling protocol that >>> meets the requirements. >> >> >> s/lightweight // >> >> I am not sure why we =A0say "lightweight tunneling protocols" - I think >> that is a legacy from previous discussions. I don't think that there >> is a definition of what "lightweight" means , and propose changing >> most occurrences of it to simple "tunneling protocols." >> > Seems good. > >>> >>> ---- >>> Section 5: >>> "UDP >>> =A0 endpoints that implement this solution MUST change their behavior a= nd >>> =A0 not discard UDP packets received with a 0 checksum on the outer >>> =A0 packet of tunneling protocols." >>> - I think we really should add a few words about being enabled only for >>> the set of ports that are supported by system for use by tunneling >>> protocol(s). >>> >> >> OK >> >>> ---- >>> >>> Section 5: >>> "its behavior should be as specified originally." >>> - replace "should be as specified originally", by "is not updated and >>> uses the method specified in RFC2460". >>> >> >> OK >> >>> ---- >>> Section 6: >>> " =A0 The persistence of this issue among a significant number of >>> protocols being developed in the IETF requires a definitive policy." >>> - Is this a recommendation for more work, or a statement of the >>> motivation for this document. I was not sure. >> >> >> The latter. I will adjust the text to =A0make that clear. >> >>> >>> ---- >>> Section 6: >>> - I think it could be useful to include the points in section 6 possibl= y >>> also as a part of ietf-6man-udpzero. What do you think? >>> >> >> OK by me. >> >>> >>> ---- >>> I'd suggest we add a normative citation to RFC 5405, stating that this >>> provides the IETF guidance on the design of applications using UDP and >>> includes guidelines on the usage of checksums by application designers. >>> >>> - Possibly best placed in the introduction, indicating that this >>> document adds to this for the case of tunneling applications. >> >> >> OK. I will reference section 3.4 >> >> Thanks again ! >> >> Regards >> Marshall >> >>> >>> ---- >>> >>> >>> -- >>> Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. >>> The University of Aberdeen is a charity registered in Scotland, >>> No SC013683. >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> > > Looks like we agree on all the important points, which may be a sign that= it > is worth polishing the text and asking for WG accepatnce? > That was my intention. I can get a revision out early in IETF week. Thanks again. Regards Marshall > Gorry From gorry@erg.abdn.ac.uk Wed Mar 14 09:16:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55F21F8738 for ; Wed, 14 Mar 2012 09:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q9zJOlGXaPD for ; Wed, 14 Mar 2012 09:16:20 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBB021F85D3 for <6man@ietf.org>; Wed, 14 Mar 2012 09:16:20 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q2EGGB3A019790; Wed, 14 Mar 2012 16:16:11 GMT Received: from localhost (gorry@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) with ESMTP id q2EGGBjF019787; Wed, 14 Mar 2012 16:16:11 GMT Date: Wed, 14 Mar 2012 16:16:11 +0000 (GMT) From: gorry@erg.abdn.ac.uk To: Marshall Eubanks Subject: Re: draft-ietf-6man-udpchecksums-02.txt In-Reply-To: Message-ID: References: <4F5F0B41.8070705@erg.abdn.ac.uk> <4F5FB248.6030407@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-1331741771=:19528" X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@dee.erg.abdn.ac.uk X-Mailman-Approved-At: Wed, 14 Mar 2012 09:47:26 -0700 Cc: 6man@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:16:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-684387517-1331741771=:19528 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE This all sounds good to me. I like the idea of a new rev. next week,=20 thanks Marshall, Gorry On Wed, 14 Mar 2012, Marshall Eubanks wrote: > Dear Gorry; > > A few matters in-line. > > On Wed, Mar 14, 2012 at 4:31 AM, wrote: >> >> See in-line: >> >> >> On Tue, 13 Mar 2012, Marshall Eubanks wrote: >> >>> Dear Gorry; >>> >>> Thanks for the read. >>> >>> On Tue, Mar 13, 2012 at 4:47 PM, Gorry Fairhurst >>> wrote: >>>> >>>> >>>> Marshall & =A0Philip, I've read the new draft, and have a few new comm= ents. >>>> Hope these are helpful - happy to discuss if this seems useful. >>>> >>>> Best wishes, >>>> >>>> Gorry >>>> >>>> ---- >>>> BOILER PLATE: >>>> - Please an Updates line:goprry >>>> "Updates RFC2460 (if approved)" >>>> >>>> ---- >>>> Section 3: >>>> =A0"there is no additional >>>> =A0 benefit and indeed some cost to nodes to both compute and check th= e >>>> =A0 UDP checksum of the outer (encapsulating) header." >>>> >>>> - I do not think this sentence is really true, and I think it's >>>> important that we do get this right. I suggest there ARE benefits in >>>> performing a UDP integrity check for IPv6, see Section 3 of >>>> I-D.ietf-6man-udpzero. However, I agree that omitting this check can >>>> reduce the forwarding cost for systems that perform the check in >>>> software. >>> >>> >>> How about >>> >>> there is both a benefit and a cost to =A0compute and check the >>> UDP checksum of the outer (encapsulating) header. In certain cases, >>> where reducing >>> the forwarding cost is important, such as for systems that perform the >>> check in software, >>> the cost may outweigh the benefit; this document describes a means to >>> avoid that cost, in >>> the case where there is an inner header with a checksum. >>> >>> >> Looks good. >> >>> >>>> ---- >>>> Section 3: >>>> =A0"to set the checksum field of the >>>> =A0 outer header only to 0 and skip both the sender and receiver >>>> =A0 computation." >>>> >>>> - Could we insert a "UDP transport" between "outer" and "header" above= , >>>> so there can be no confusion with the network layer headers. >>> >>> >>> OK >>> >>>> >>>> ---- >>>> Section 4: >>>> =A0 "In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose ni= ne >>>> =A0 (9) constraints on the usage of a zero checksum for UDP over IPv6. >>>> =A0 We agree with the restrictions proposed, and in fact proposed some= of >>>> =A0 those restrictions ourselves in the previous version of the curren= t >>>> =A0 draft. =A0These restrictions are incorporated into the proposed ch= anges >>>> =A0 below." >>>> >>>> - This reads rather like a paper. ietf-6man-udpzero is also a working >>>> group document, and I would like to think we can find better language. >>>> I suggest something like: >>>> >>>> =A0 "Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements >>>> =A0 that introduce constraints on the usage of a zero checksum for >>>> =A0 UDP over IPv6. This document is intended to satisfy these >>>> =A0 requirements." >>>> >>> >>> This WFM, >>> >>>> ---- >>>> Section 4: >>>> =A0"inspection firewall devices or other middleboxes actually checking= " >>>> - remove "actually"? >>> >>> >>> WFM >>> >>>> >>>> ---- >>>> Section 4: >>>> =A0"This is would be an issue also for legacy systems >>>> =A0 which have not implemented the change in the IPv6 specification. = =A0So >>>> =A0 in any case, there may be packet loss of lightweight tunneling >>>> =A0 packets because of mixed new-rule and old-rule nodes." >>>> >>>> - Seems like it could be improved. I suggest: >>>> =A0"This would be an issue also for any legacy IPv6 system >>>> =A0 that has not implemented the change to the IPv6 specification. In >>>> =A0 this case, the system will discard the zero-checksum UDP >>>> =A0 packets, and should log this as an error." >>>> >>> >>> This is not a prescription, but an observation (i.e. we can't say >>> SHOULD log this as an error here). >>> >> The existing spec says systems should log it as an error. >> > > Yes. My point was just that I didn't want to say > >>>> =A0 packets, and SHOULD log this as an error." > > as we are not prescribing anything for systems that have not been updated= =2E > If they are going to update, they should update to the new standard. > >> >>> How about >>> >>> =A0"This would be an issue also for any legacy IPv6 system >>> =A0 that has not implemented the change to the IPv6 specification. In >>> =A0 this case, the system should discard the zero-checksum UDP > > How about > > s/system/system (according to RFC 2460)/ > > just to make the point clear. > >>> =A0 packets, and log this as an error." >>> >> OK >> >>> >>>> ---- >>>> Section 4: >>>> " =A0 As an example, we discuss how can errors be detected and " >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^ >>>> - remove "can" >>> >>> >>> ACK >>> >>>> >>>> ---- >>>> Section 4: >>>> =A0"Note that other (non-tunneling) protocols may have >>>> =A0 different approaches." >>>> - suggest replace add: >>>> =A0", but these are not the topic of this update." >>>> >>> >>> WFM >>> >>>> ---- >>>> Section 4: >>>> =A0"The control packets can >>>> =A0 also contain any negotiation that is necessary to set up the >>>> =A0 endpoint/adapters to accept UDP packets with a zero checksum." >>>> - this needs to be enabled for each flow, so please add: >>>> "The control packets may >>>> =A0 =A0 =A0also carry any negotiation that is necessary to set up the >>> >>> >>> how about >>> >>> s/that is necessary to set up the/required to enable the/ >>> >>>> =A0 =A0 =A0endpoint/adapters to identify the set of ports that >>>> =A0 =A0 =A0need to enable reception UDP datagrams with a zero >>>> =A0 =A0 =A0 checksum." >>>> >> Better. >> >> >>>> ---- >>>> Section 4: >>>> "Only UDP packets containing tunneled packets should have a UDP >>>> =A0 =A0 =A0checksum equal to zero." >>>> - Please use keywords. e.g. >>>> =A0"A system MUST NOT set the UDP checksum to zero in packets that do >>>> not contain tunneled packets." >>>> >>> >>> OK >>> >>>> ---- >>>> Section 4: >>>> "We note that >>>> =A0 =A0 =A0these outcomes not equally likely, as most require multiple= bit >>>> =A0 =A0 =A0errors with errored bits in separate fields. " >>>> - It seems wrong to suggest that single bit inversions are a likely >>>> cause of residual errors at the transport layer. I do not think this i= s >>>> the case. I suggest direct replacement of a sequence of bytes is a >>>> likely form of corruption. Suggest you omit the second part of the >>>> sentence? >>> >>> >>> OK. Note that there is a missing "are" before "not," which I have also >>> fixed. >>> >> Thanks >> >> >>>> >>>> ---- >>>> Section 4: >>>> " If it is some >>>> =A0 =A0 =A0 =A0 other application, with very high probability, the app= lication >>>> =A0 =A0 =A0 =A0 will not recognize the contents of the packet." >>>> - I disagree - it all comes down to applications design. The detection >>>> is only if the app is defined this way, since the transport does not >>>> know, etc. RFC 5405 provides recommended best current practice for >>>> applications in general. >>> >>> >>> Do you have alternate text ? How about s/will not/may not/ ? >>> >> Applications are recommended to verfiy the context of the packets they >> receive using UDP, as described in RFC 5405. Applications that verify th= e >> context of a datagram are expected to have a high probability of discard= ing >> corrupted data. [I-D.ietf-6man-udpzero] presents examples of cases where >> corruption can inadvertantly impact application state. >> >> > > WFM > > >> >>>> >>>> ---- >>>> Section 4: >>>> - I think the wording of this section needs to be tightened.It would b= e >>>> good to see more of a focus on what needs to be implemented, rather th= an >>>> discussing the guidance provided in the other working group document. >>>> >>>> If the guidance itself needs to be updated, then it would be good to >>>> explore this - We'd be happy to update the text and guidance if there = is >>>> something more that should be said. >>>> >>>> ---- >>>> Section 5: >>>> " =A0 outer encapsulating packet of a lightweight tunneling protocol." >>>> - is it intentional to permit this only for *lightweight* tunneling >>>> protocols? - The initial request was for *any* tunneling protocol that >>>> meets the requirements. >>> >>> >>> s/lightweight // >>> >>> I am not sure why we =A0say "lightweight tunneling protocols" - I think >>> that is a legacy from previous discussions. I don't think that there >>> is a definition of what "lightweight" means , and propose changing >>> most occurrences of it to simple "tunneling protocols." >>> >> Seems good. >> >>>> >>>> ---- >>>> Section 5: >>>> "UDP >>>> =A0 endpoints that implement this solution MUST change their behavior = and >>>> =A0 not discard UDP packets received with a 0 checksum on the outer >>>> =A0 packet of tunneling protocols." >>>> - I think we really should add a few words about being enabled only fo= r >>>> the set of ports that are supported by system for use by tunneling >>>> protocol(s). >>>> >>> >>> OK >>> >>>> ---- >>>> >>>> Section 5: >>>> "its behavior should be as specified originally." >>>> - replace "should be as specified originally", by "is not updated and >>>> uses the method specified in RFC2460". >>>> >>> >>> OK >>> >>>> ---- >>>> Section 6: >>>> " =A0 The persistence of this issue among a significant number of >>>> protocols being developed in the IETF requires a definitive policy." >>>> - Is this a recommendation for more work, or a statement of the >>>> motivation for this document. I was not sure. >>> >>> >>> The latter. I will adjust the text to =A0make that clear. >>> >>>> >>>> ---- >>>> Section 6: >>>> - I think it could be useful to include the points in section 6 possib= ly >>>> also as a part of ietf-6man-udpzero. What do you think? >>>> >>> >>> OK by me. >>> >>>> >>>> ---- >>>> I'd suggest we add a normative citation to RFC 5405, stating that this >>>> provides the IETF guidance on the design of applications using UDP and >>>> includes guidelines on the usage of checksums by application designers= =2E >>>> >>>> - Possibly best placed in the introduction, indicating that this >>>> document adds to this for the case of tunneling applications. >>> >>> >>> OK. I will reference section 3.4 >>> >>> Thanks again ! >>> >>> Regards >>> Marshall >>> >>>> >>>> ---- >>>> >>>> >>>> -- >>>> Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. >>>> The University of Aberdeen is a charity registered in Scotland, >>>> No SC013683. >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> >> >> Looks like we agree on all the important points, which may be a sign tha= t it >> is worth polishing the text and asking for WG accepatnce? >> > > That was my intention. I can get a revision out early in IETF week. > > Thanks again. > > Regards > Marshall > >> Gorry > ---559023410-684387517-1331741771=:19528-- From brian.e.carpenter@gmail.com Wed Mar 14 12:17:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DA521F8720 for ; Wed, 14 Mar 2012 12:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx0VgUs3JlYG for ; Wed, 14 Mar 2012 12:17:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E83DC21F8712 for ; Wed, 14 Mar 2012 12:17:56 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1346075eaa.31 for ; Wed, 14 Mar 2012 12:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/UuZVmf2j3Yem7m2Gk9snscX0aejYpE7zOdYcVG148o=; b=QZzX0nkwq5aI3Wh57aRGXDz9B4S2ixpRHfFZh55l3FB17OztaF/ZjeJfqU8yZVxDhr zLgAA5kIZ+lC9EbKoex64a5CrDAdC2NxHgpv5TCvVUy7f7r6Gv02Qk5SzknF7McAZ+CY g17K63koRH2bkqn49HG301nMJk6ftX2OUT4mCqCqylhRBRDq+y2sZu3ng9B3LOIjMv68 /P/bCduz6xJp2iBxmWeptqPc5yfefSpWq4GJByg45i5u+cJG57clMlHplItlAOUxcJ21 NvZrep3vez39gvNiemzTxlOPaXTkJzmhctlfT+noVZlErY86d7mSLaZNpF1mkqqNdZkf lKiQ== Received: by 10.14.101.141 with SMTP id b13mr552450eeg.92.1331752676138; Wed, 14 Mar 2012 12:17:56 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n55sm16570899eef.6.2012.03.14.12.17.53 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 12:17:55 -0700 (PDT) Message-ID: <4F60EED4.7050601@gmail.com> Date: Thu, 15 Mar 2012 08:17:40 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: List name? [Re: draft-ietf-6man-udpchecksums-02.txt] References: <4F5F0B41.8070705@erg.abdn.ac.uk> <4F5FB248.6030407@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:17:57 -0000 How come email addressed to 6man@ietf.org is getting delivered to ipv6@ietf.org, which is the correct list for the 6man WG? This confused my filters considerably. (Before anyone suggests the obvious, I have updated them appropriately.) Regards Brian From brian@innovationslab.net Wed Mar 14 12:33:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9F321F84EB for ; Wed, 14 Mar 2012 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaLNt9J9lFt2 for ; Wed, 14 Mar 2012 12:33:54 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 76B4F21F84E6 for ; Wed, 14 Mar 2012 12:33:54 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7BF8A881CE for ; Wed, 14 Mar 2012 12:33:54 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2E086130015 for ; Wed, 14 Mar 2012 12:33:53 -0700 (PDT) Message-ID: <4F60F29F.50507@innovationslab.net> Date: Wed, 14 Mar 2012 15:33:51 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: List name? [Re: draft-ietf-6man-udpchecksums-02.txt] References: <4F5F0B41.8070705@erg.abdn.ac.uk> <4F5FB248.6030407@erg.abdn.ac.uk> <4F60EED4.7050601@gmail.com> In-Reply-To: <4F60EED4.7050601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:33:55 -0000 On 3/14/12 3:17 PM, Brian E Carpenter wrote: > How come email addressed to 6man@ietf.org is getting delivered > to ipv6@ietf.org, which is the correct list for the 6man WG? When we concluded the IPv6 WG and formed 6MAN, the decision was made to keep using the ipv6@ietf.org mailing list. This allowed list members to retain all of their existing filters and reduced the amount of work needed by the list administrators. A few months ago an AD who shall remain nameless assumed that the WG name and the mailing list name were the same and complained when e-mail sent to 6man@ietf.org bounced. We then asked Glen to create an alias that would re-direct any mail sent to 6man@ to ipv6@ to avoid such events from occurring. > > This confused my filters considerably. (Before anyone suggests > the obvious, I have updated them appropriately.) Apologies for the inconvenience. It never dawned on me to send mail to the list explaining the existence of this alias. I am curious as to what message caused the problem. My filters have not failed on any recent message to the list. Regards, Brian From alexandru.petrescu@gmail.com Thu Mar 15 01:58:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E0921F863B for ; Thu, 15 Mar 2012 01:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[AWL=1.717, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVIXP9HJtZHM for ; Thu, 15 Mar 2012 01:58:45 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C786B21F8639 for ; Thu, 15 Mar 2012 01:58:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2F8wgLj012161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Mar 2012 09:58:42 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2F8wgiW015097 for ; Thu, 15 Mar 2012 09:58:42 +0100 (envelope-from alexandru.petrescu@gmail.com) 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 q2F8wccO021208 for ; Thu, 15 Mar 2012 09:58:42 +0100 Message-ID: <4F61AF3E.1060402@gmail.com> Date: Thu, 15 Mar 2012 09:58:38 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ipv Subject: New ITS email list for discussing IPv6 and vehicular communications Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 08:58:45 -0000 Dear participants in 6MAN WG, A new email list ITS Intelligent Transportation Systems has been set up at IETF. It is intended for discussions of IP and vehicular communications. https://www.ietf.org/mailman/listinfo/its Earlier in 2010, 2011, several discussions in 6MAN mentioned the use of IP in vehicular communications (ULA, VIN). Let us discuss IPv6 and vehicular on the ITS email list. Let us meet in Paris about this as well. Alex From brian@innovationslab.net Thu Mar 15 04:32:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6211721F85F0 for ; Thu, 15 Mar 2012 04:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJUSnEL7xCFx for ; Thu, 15 Mar 2012 04:32:41 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id B940A21F85EE for ; Thu, 15 Mar 2012 04:32:41 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 3697B881D3 for ; Thu, 15 Mar 2012 04:32:41 -0700 (PDT) Received: from clemson.local (c-68-33-164-105.hsd1.dc.comcast.net [68.33.164.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E0B04130015 for ; Thu, 15 Mar 2012 04:32:40 -0700 (PDT) Message-ID: <4F61D359.9060204@innovationslab.net> Date: Thu, 15 Mar 2012 07:32:41 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Scribes and minutes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: 6man Chairs <6man-chairs@tools.ietf.org> List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:32:42 -0000 All, The preliminary agenda has been posted for the 6MAN meeting in Paris. We have the 0900-1130 slot on Tuesday morning. If you are willing to serve as a Jabber scribe or take minutes, please let the chairs know. Any and all assistance with these tasks is greatly appreciated. Presenters are asked to send their slides to the chairs NO LATER THAN March 26th at 2100. This allows us to upload the slides to the meeting materials site so that they are available to remote participants. Regards, Brian, Bob, & Ole From zhou.sujing@zte.com.cn Thu Mar 15 17:09:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146E121E8049; Thu, 15 Mar 2012 17:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.746 X-Spam-Level: X-Spam-Status: No, score=-94.746 tagged_above=-999 required=5 tests=[AWL=-1.956, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idwGD+gyYXZF; Thu, 15 Mar 2012 17:09:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 98ACD21E8044; Thu, 15 Mar 2012 17:09:48 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 523732306338276; Fri, 16 Mar 2012 08:02:15 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 65905.4421576356; Fri, 16 Mar 2012 08:09:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2G09ehn063625; Fri, 16 Mar 2012 08:09:40 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4F61D359.9060204@innovationslab.net> To: 6man Chairs <6man-chairs@tools.ietf.org> Subject: =?GB2312?B?tPC4tDogU2NyaWJlcyBhbmQgbWludXRlcw==?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 16 Mar 2012 08:09:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-16 08:09:41, Serialize complete at 2012-03-16 08:09:41 Content-Type: multipart/alternative; boundary="=_alternative 0000E472482579C3_=" X-MAIL: mse02.zte.com.cn q2G09ehn063625 Cc: ipv6-bounces@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:09:50 -0000 This is a multipart message in MIME format. --=_alternative 0000E472482579C3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksDQogICB3aGF0IGlzIHRoZSBhZ2VuZGEgZm9yIHRoZSA2bWFuPyANCiANClJlZ2FyZHN+fn4N Cg0KLVN1amluZyBaaG91DQoNCmlwdjYtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMDMtMTUg MTk6MzI6NDE6DQoNCj4gQWxsLA0KPiAgICAgICBUaGUgcHJlbGltaW5hcnkgYWdlbmRhIGhhcyBi ZWVuIHBvc3RlZCBmb3IgdGhlIDZNQU4gbWVldGluZyBpbiANCj4gUGFyaXMuICBXZSBoYXZlIHRo ZSAwOTAwLTExMzAgc2xvdCBvbiBUdWVzZGF5IG1vcm5pbmcuDQo+IA0KPiAgICAgICBJZiB5b3Ug YXJlIHdpbGxpbmcgdG8gc2VydmUgYXMgYSBKYWJiZXIgc2NyaWJlIG9yIHRha2UgbWludXRlcywg DQo+IHBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93LiAgQW55IGFuZCBhbGwgYXNzaXN0YW5jZSB3 aXRoIHRoZXNlIHRhc2tzIGlzIA0KPiBncmVhdGx5IGFwcHJlY2lhdGVkLg0KPiANCj4gICAgICAg UHJlc2VudGVycyBhcmUgYXNrZWQgdG8gc2VuZCB0aGVpciBzbGlkZXMgdG8gdGhlIGNoYWlycyBO TyBMQVRFUiANCj4gVEhBTiBNYXJjaCAyNnRoIGF0IDIxMDAuICBUaGlzIGFsbG93cyB1cyB0byB1 cGxvYWQgdGhlIHNsaWRlcyB0byB0aGUgDQo+IG1lZXRpbmcgbWF0ZXJpYWxzIHNpdGUgc28gdGhh dCB0aGV5IGFyZSBhdmFpbGFibGUgdG8gcmVtb3RlIA0KcGFydGljaXBhbnRzLg0KPiANCj4gUmVn YXJkcywNCj4gQnJpYW4sIEJvYiwgJiBPbGUNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiANCg0K --=_alternative 0000E472482579C3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3doYXQgaXMgdGhlIGFnZW5k YSBmb3INCnRoZSA2bWFuPyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5pcHY2LWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTAzLTE1IDE5 OjMyOjQxOjxicj4NCjxicj4NCiZndDsgQWxsLDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgVGhlIHByZWxpbWluYXJ5IGFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQgZm9yIHRoZQ0KNk1BTiBt ZWV0aW5nIGluIDxicj4NCiZndDsgUGFyaXMuICZuYnNwO1dlIGhhdmUgdGhlIDA5MDAtMTEzMCBz bG90IG9uIFR1ZXNkYXkgbW9ybmluZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgSWYgeW91IGFyZSB3aWxsaW5nIHRvIHNlcnZlIGFzIGEgSmFiYmVyIHNjcmliZQ0K b3IgdGFrZSBtaW51dGVzLCA8YnI+DQomZ3Q7IHBsZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93LiAm bmJzcDtBbnkgYW5kIGFsbCBhc3Npc3RhbmNlIHdpdGggdGhlc2UNCnRhc2tzIGlzIDxicj4NCiZn dDsgZ3JlYXRseSBhcHByZWNpYXRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgUHJlc2VudGVycyBhcmUgYXNrZWQgdG8gc2VuZCB0aGVpciBzbGlkZXMgdG8NCnRo ZSBjaGFpcnMgTk8gTEFURVIgPGJyPg0KJmd0OyBUSEFOIE1hcmNoIDI2dGggYXQgMjEwMC4gJm5i c3A7VGhpcyBhbGxvd3MgdXMgdG8gdXBsb2FkIHRoZSBzbGlkZXMNCnRvIHRoZSA8YnI+DQomZ3Q7 IG1lZXRpbmcgbWF0ZXJpYWxzIHNpdGUgc28gdGhhdCB0aGV5IGFyZSBhdmFpbGFibGUgdG8gcmVt b3RlIHBhcnRpY2lwYW50cy48YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7 IEJyaWFuLCBCb2IsICZhbXA7IE9sZTxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IElF VEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgaXB2NkBpZXRmLm9y Zzxicj4NCiZndDsgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2Njxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IDxi cj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0000E472482579C3_=-- From bob.hinden@gmail.com Thu Mar 15 18:15:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F3821F85AC for ; Thu, 15 Mar 2012 18:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.826 X-Spam-Level: X-Spam-Status: No, score=-99.826 tagged_above=-999 required=5 tests=[AWL=-3.522, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKw4LM6+k1V5 for ; Thu, 15 Mar 2012 18:15:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9ADA21F85A8 for ; Thu, 15 Mar 2012 18:15:34 -0700 (PDT) Received: by iazz13 with SMTP id z13so5395159iaz.31 for ; Thu, 15 Mar 2012 18:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=g3lVFJI885fUP3CBZWL3tfvKbanp0SSN6BQH4ci96bE=; b=I2LognYtFnbObdHSEQR6R0swUZ86/Lvcr2fZ29mkLXqIqnb5E5oWPVGxL4/p6Ayv4M DAewqhPZFePuwHA18l53Uagblwfx8MljGbQ2yhPPFO3nxmcce6QOU/V4Pfp8hI7xYbQp LbTkJeU3+xoekjI+RUyH95HWvbi0h7WALrtdF1kbXyKZmjS1UhVCJnXRXgJTfrkNPT2f BElADY0GtY/5c+G5yt7aGnaSFU6na4Ky7NLaWzxQGRUVQwLaxU2N40Gd13x3NXBYdio+ Uk9ssCZ1N9/FnKo4BivhkuMZbUp/yY5VmOtROOYwZioZeUeaMh0g5b6f1RGCrcjkeuaf S8eg== MIME-Version: 1.0 Received: by 10.50.149.163 with SMTP id ub3mr18916721igb.30.1331860534357; Thu, 15 Mar 2012 18:15:34 -0700 (PDT) Received: by 10.231.21.198 with HTTP; Thu, 15 Mar 2012 18:15:34 -0700 (PDT) In-Reply-To: References: <4F61D359.9060204@innovationslab.net> Date: Thu, 15 Mar 2012 18:15:34 -0700 Message-ID: Subject: =?GB2312?B?UmU6ILTwuLQ6IFNjcmliZXMgYW5kIG1pbnV0ZXM=?= From: Bob Hinden To: zhou.sujing@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: 6man Chairs <6man-chairs@tools.ietf.org>, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:15:35 -0000 Sujing Zhou, > what is the agenda for the 6man? It's linked on the meeting agenda page. See: http://www.ietf.org/proceedings/83/agenda/agenda-83-6man.pdf Bob > > Regards~~~ > > -Sujing Zhou > > ipv6-bounces@ietf.org =D0=B4=D3=DA 2012-03-15 19:32:41: > > >> All, >> The preliminary agenda has been posted for the 6MAN meeting in >> Paris. We have the 0900-1130 slot on Tuesday morning. >> >> If you are willing to serve as a Jabber scribe or take minutes, >> please let the chairs know. Any and all assistance with these tasks is >> greatly appreciated. >> >> Presenters are asked to send their slides to the chairs NO LATER >> THAN March 26th at 2100. This allows us to upload the slides to the >> meeting materials site so that they are available to remote participants= . >> >> Regards, >> Brian, Bob, & Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From arifumi@nttv6.net Fri Mar 16 03:31:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC85421F8601 for ; Fri, 16 Mar 2012 03:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skEmoM98eq9r for ; Fri, 16 Mar 2012 03:31:23 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1D05721F85F9 for ; Fri, 16 Mar 2012 03:31:23 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q2GAW577065556; Fri, 16 Mar 2012 19:32:05 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 16 Mar 2012 19:30:07 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1257) Cc: "ipv6@ietf.org" , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 10:31:24 -0000 Dave, On 2012/03/01, at 11:20, Dave Thaler wrote: >> -----Original Message----- >> From: Arifumi Matsumoto [mailto:arifumi@nttv6.net] >> Sent: Thursday, February 23, 2012 10:14 PM >> To: Brian E Carpenter >> Cc: Dave Thaler; Chris Grundemann; ipv6@ietf.org; Brian Haberman; Bob >> Hinden >> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] >>=20 >> Dave, >>=20 >> in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found the = response to >> this issue of ULA scope. >>=20 >> 10.6. Configuring ULA Preference >> ... >> Since ULAs are defined to have a /48 site prefix, an implementation >> might choose to add such a row automatically on a machine with a = ULA. >>=20 >> It is also worth noting that ULAs are assigned global scope. As >> such, the existence of one or more rows in the prefix policy table = is >> important so that source address selection does not choose a ULA >> purely based on longest match: >>=20 >> Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 >> Destination Address List: ff00:1 >> Result: 2001:db8:1::1 (prefer matching label) >>=20 >>=20 >> IMO, this implicit specification causes several problems. >>=20 >> First of all, if you leave it to implementation, this creates an = interoperability >> problem. In the sense that a site administrator, an application = developer, a >> network designer, have to take care of the nodes with different = address >> selection behavior. >=20 > Are you arguing it should be mandatory, not optional? (I'm guessing = so based > on the previous discussion of "macros" in the table.) >=20 > But still, you have to take care of nodes with different address = selection behavior > anyway if you allow heterogeneous hosts, since you'll have > a) hosts that don't do RFC 3484 > b) hosts that do RFC 3484 > c) hosts that do 3484bis >=20 > And even within a category above, the IPv4 source address selection = behavior > will vary since that's not specified. >=20 > At best you can argue to minimize the problem as much as possible, but > you can't make it go away. Rather, my question was about the design choice. Regarding the design of ULA and how to use the ULA, can we agree that=20 ULA-to-ULA communication within the same /48 prefix is not always = preferred over other communications using IPv4 or IPv6 global addresses ? >> Second, >> when a user configures his policy table, the configured table is = overwritten by >> this implementation dependent policy injection behavior ? >> Can the user suppress this behavior of policy injection ? >> This issue should arise also when a policy distributing mechanism is = ready. >=20 > Good questions. Do you have suggested answers to those questions? > I might throw out a strawman of: >=20 > Any automatic rows added by the implementation as a result of address > acquisition MUST NOT override a row for the same prefix configured > via other means. That is, rows can be added but never updated > automatically. An implementation SHOULD provide a means for > an administrator to disable automatic row additions. My suggested answer for this was to use macros, which can be added/deleted by a user, and interpreted as the actual prefix attached to the hosts. Best regards, -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From brian.e.carpenter@gmail.com Fri Mar 16 11:42:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5BF21E8068 for ; Fri, 16 Mar 2012 11:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2Z7Ejax8uiO for ; Fri, 16 Mar 2012 11:42:16 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83B8121F85BB for ; Fri, 16 Mar 2012 11:42:13 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2468158eaa.31 for ; Fri, 16 Mar 2012 11:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b9WX1N4hXoDPXzGrCQdPH5y/rkNH+k9AXZN3Oo45zm4=; b=M52NAAZ061xSxqItEwX0jyNNV5Xb4aLUb9dw4FA+vJQgJuHOjpqna0o14a92z5mHja 5G0B1T+KnrDpHS+6QlHxCHtuphckAdXSHSj69rB2CyGhmuQFdvTvxLTyoAZF8YLts57m y06fpldK+rmzd4Ky2A98vYfdfpV7hG8y390hNqRblbjgGQbklF23yRz9v7XucFZXg4f8 ZdZr4fLcMuVJA4Ew4IAR7XfovOhALqDI6XvTaAZqQWcb4skTtMoL9MnQTQoose9UIoir uh8I4o8FgslEYs3ZJPyaJAOah9dwUPYp6SiaNrqG7ARLLa3u5tbk+/CXgbTyWEtdTuvD 9Cqg== Received: by 10.14.32.139 with SMTP id o11mr512050eea.10.1331923332646; Fri, 16 Mar 2012 11:42:12 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id s48sm21221504eem.0.2012.03.16.11.42.05 (version=SSLv3 cipher=OTHER); Fri, 16 Mar 2012 11:42:11 -0700 (PDT) Message-ID: <4F63896E.10607@gmail.com> Date: Sat, 17 Mar 2012 07:41:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bob Hinden , "ipv6@ietf.org" , Brian Haberman , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:42:17 -0000 On 2012-03-16 23:30, Arifumi Matsumoto wrote: ... > Rather, my question was about the design choice. > > Regarding the design of ULA and how to use the ULA, can we agree that > ULA-to-ULA communication within the same /48 prefix is not always preferred > over other communications using IPv4 or IPv6 global addresses ? I would expect it to be preferred as a result of longest match; I would not expect it to be a special case in the default policy for global scope addresses, if that is the question. >>> Second, >>> when a user configures his policy table, the configured table is overwritten by >>> this implementation dependent policy injection behavior ? >>> Can the user suppress this behavior of policy injection ? >>> This issue should arise also when a policy distributing mechanism is ready. >> Good questions. Do you have suggested answers to those questions? >> I might throw out a strawman of: >> >> Any automatic rows added by the implementation as a result of address >> acquisition MUST NOT override a row for the same prefix configured >> via other means. That is, rows can be added but never updated >> automatically. An implementation SHOULD provide a means for >> an administrator to disable automatic row additions. > > > My suggested answer for this was to use macros, which can be > added/deleted by a user, and interpreted as the actual prefix > attached to the hosts. That's an implementation method. I think Dave's proposed rule is correct. Brian From marka@isc.org Fri Mar 16 17:13:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B92321E807B for ; Fri, 16 Mar 2012 17:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVe3i-JTPpwE for ; Fri, 16 Mar 2012 17:13:19 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBAF21E8042 for ; Fri, 16 Mar 2012 17:13:18 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C8A215F98AF; Sat, 17 Mar 2012 00:12:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d1fb:f2c0:5ce0:8d7d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CA992216C33; Sat, 17 Mar 2012 00:12:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D5A711E9FC42; Sat, 17 Mar 2012 11:12:52 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-reply-to: Your message of "Sat, 17 Mar 2012 07:41:50 +1300." <4F63896E.10607@gmail.com> Date: Sat, 17 Mar 2012 11:12:52 +1100 Message-Id: <20120317001252.D5A711E9FC42@drugs.dv.isc.org> Cc: "ipv6@ietf.org" , Brian Haberman , Bob Hinden , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 00:13:19 -0000 In message <4F63896E.10607@gmail.com>, Brian E Carpenter writes: > On 2012-03-16 23:30, Arifumi Matsumoto wrote: > ... > > Rather, my question was about the design choice. > > > > Regarding the design of ULA and how to use the ULA, can we agree that > > ULA-to-ULA communication within the same /48 prefix is not always preferred > > over other communications using IPv4 or IPv6 global addresses ? > > I would expect it to be preferred as a result of longest match; I would > not expect it to be a special case in the default policy for global > scope addresses, if that is the question. > > >>> Second, > >>> when a user configures his policy table, the configured table is overwrit > ten by > >>> this implementation dependent policy injection behavior ? > >>> Can the user suppress this behavior of policy injection ? > >>> This issue should arise also when a policy distributing mechanism is read > y. > >> Good questions. Do you have suggested answers to those questions? > >> I might throw out a strawman of: > >> > >> Any automatic rows added by the implementation as a result of address > >> acquisition MUST NOT override a row for the same prefix configured > >> via other means. That is, rows can be added but never updated > >> automatically. An implementation SHOULD provide a means for > >> an administrator to disable automatic row additions. > > > > > > My suggested answer for this was to use macros, which can be > > added/deleted by a user, and interpreted as the actual prefix > > attached to the hosts. > > That's an implementation method. I think Dave's proposed rule is > correct. > > Brian What I see missing is a way for a node to know what the site boundaries are with respect to address selection. Adding a site prefix length to RA Prefix Information would provide a 99.99% solution to this. If the Site Prefix field is non-zero it is valid. e.g. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A| Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Site Prefix | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dthaler@microsoft.com Fri Mar 16 17:25:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85FA21E8042 for ; Fri, 16 Mar 2012 17:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-sVNxJoTZK1 for ; Fri, 16 Mar 2012 17:25:30 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 090E021E8014 for ; Fri, 16 Mar 2012 17:25:28 -0700 (PDT) Received: from mail39-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Sat, 17 Mar 2012 00:25:27 +0000 Received: from mail39-db3 (localhost [127.0.0.1]) by mail39-db3-R.bigfish.com (Postfix) with ESMTP id C5C184400A1; Sat, 17 Mar 2012 00:25:26 +0000 (UTC) X-SpamScore: -45 X-BigFish: VS-45(zz9371I936eK542M1432N98dKdf7Ozz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail39-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail39-db3 (localhost.localdomain [127.0.0.1]) by mail39-db3 (MessageSwitch) id 1331943924291582_2779; Sat, 17 Mar 2012 00:25:24 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.233]) by mail39-db3.bigfish.com (Postfix) with ESMTP id 385B7380045; Sat, 17 Mar 2012 00:25:24 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 17 Mar 2012 00:25:23 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sat, 17 Mar 2012 00:25:23 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.57]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Fri, 16 Mar 2012 17:25:22 -0700 From: Dave Thaler To: Mark Andrews Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Topic: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHM61TBqpyDXQSHVE+cgiqvxUSI2pZMJnCAgAiknaCAGJMlgIAAiWIA///nSa2AAAM+gA== Date: Sat, 17 Mar 2012 00:25:22 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4A58D6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <20120317001252.D5A711E9FC42@drugs.dv.isc.org> In-Reply-To: <20120317001252.D5A711E9FC42@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org" , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 00:25:30 -0000 See http://tools.ietf.org/html/draft-ietf-ipngwg-site-prefixes-05 -Dave > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org] > Sent: Friday, March 16, 2012 5:13 PM > To: Brian E Carpenter > Cc: Arifumi Matsumoto; Bob Hinden; ipv6@ietf.org; Brian Haberman; Dave > Thaler > Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] >=20 >=20 > In message <4F63896E.10607@gmail.com>, Brian E Carpenter writes: > > On 2012-03-16 23:30, Arifumi Matsumoto wrote: > > ... > > > Rather, my question was about the design choice. > > > > > > Regarding the design of ULA and how to use the ULA, can we agree > > > that ULA-to-ULA communication within the same /48 prefix is not > > > always preferred over other communications using IPv4 or IPv6 global > addresses ? > > > > I would expect it to be preferred as a result of longest match; I > > would not expect it to be a special case in the default policy for > > global scope addresses, if that is the question. > > > > >>> Second, > > >>> when a user configures his policy table, the configured table is > > >>> overwrit > > ten by > > >>> this implementation dependent policy injection behavior ? > > >>> Can the user suppress this behavior of policy injection ? > > >>> This issue should arise also when a policy distributing mechanism > > >>> is read > > y. > > >> Good questions. Do you have suggested answers to those questions? > > >> I might throw out a strawman of: > > >> > > >> Any automatic rows added by the implementation as a result of > > >> address acquisition MUST NOT override a row for the same prefix > configured > > >> via other means. That is, rows can be added but never updated > > >> automatically. An implementation SHOULD provide a means for > > >> an administrator to disable automatic row additions. > > > > > > > > > My suggested answer for this was to use macros, which can be > > > added/deleted by a user, and interpreted as the actual prefix > > > attached to the hosts. > > > > That's an implementation method. I think Dave's proposed rule is > > correct. > > > > Brian >=20 > What I see missing is a way for a node to know what the site boundaries > are with respect to address selection. Adding a site prefix length > to RA Prefix Information would provide a 99.99% solution to this. If the= Site > Prefix field is non-zero it is valid. >=20 > e.g. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Prefix Length |L|A| Reserved1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Valid Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Preferred Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Site Prefix | Reserved2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Prefix + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From a@arifumi.net Fri Mar 16 17:29:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EE421F856A for ; Fri, 16 Mar 2012 17:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkpQlApXKG0J for ; Fri, 16 Mar 2012 17:29:39 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E263D21F8569 for ; Fri, 16 Mar 2012 17:29:38 -0700 (PDT) Received: by lagj5 with SMTP id j5so4346139lag.31 for ; Fri, 16 Mar 2012 17:29:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=90yFSoWLE3epGNiLl6R8Wp95hZpMr9ksIkULpV+ORVw=; b=EQ/DZePzHNgLDNerNq/XChvAyuwoqTCCV1i1v2FOWMHFOO71vqiLg+gHJps4SC54pp Hw4EBVu9evuE9BIpRV+xotk7cGdrcT8UPG4RNyt1Wm2gfJLMIF7qB1HYzq6HfngOdTYO oayQ8/z7dbDCta90y3paJHyZ1aWjKPiHI7aaK5VK0qFDXAo7svwp3R2c3DVGOSKB4HCX nchvwEu/8CFIA8R+SoGleLIpVllNaFIuogpWN9T8FOgcI4+sgfBG0FzOEtlsRL4eoxhv lOAXTMCkQrHB3N/XRsd1e/5i1oXBi+Dc/wrtnmrOqflArZhz2MWPoX5oWXEstCSG9/vk Ip8A== MIME-Version: 1.0 Received: by 10.152.131.3 with SMTP id oi3mr3682548lab.35.1331944177864; Fri, 16 Mar 2012 17:29:37 -0700 (PDT) Received: by 10.112.109.68 with HTTP; Fri, 16 Mar 2012 17:29:37 -0700 (PDT) X-Originating-IP: [118.21.146.144] In-Reply-To: <4F63896E.10607@gmail.com> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> Date: Sat, 17 Mar 2012 09:29:37 +0900 Message-ID: Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] From: Arifumi Matsumoto To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl0TMUjm+aWEuhgEc94kmLojyj27Y1mzU6+JFgEVzsuShbz5a5uNqkjvnHabbJblJEL9fCn Cc: "ipv6@ietf.org" , Brian Haberman , Bob Hinden , Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 00:29:39 -0000 Brian, 2012/3/17 Brian E Carpenter : > On 2012-03-16 23:30, Arifumi Matsumoto wrote: > ... >> Rather, my question was about the design choice. >> >> Regarding the design of ULA and how to use the ULA, can we agree that >> ULA-to-ULA communication within the same /48 prefix is not always prefer= red >> over other communications using IPv4 or IPv6 global addresses ? > > I would expect it to be preferred as a result of longest match; I would > not expect it to be a special case in the default policy for global > scope addresses, if that is the question. ULA-to-ULA will not be preferred, because ULAs are assigned lower precedence value in the policy table than those of IPv4 and IPv6 global addresses. Best, >>>> Second, >>>> when a user configures his policy table, the configured table is overw= ritten by >>>> this implementation dependent policy injection behavior ? >>>> Can the user suppress this behavior of policy injection ? >>>> This issue should arise also when a policy distributing mechanism is r= eady. >>> Good questions. =A0Do you have suggested answers to those questions? >>> I might throw out a strawman of: >>> >>> Any automatic rows added by the implementation as a result of address >>> acquisition MUST NOT override a row for the same prefix configured >>> via other means. =A0 That is, rows can be added but never updated >>> automatically. =A0 An implementation SHOULD provide a means for >>> an administrator to disable automatic row additions. >> >> >> My suggested answer for this was to use macros, which can be >> added/deleted by a user, and interpreted as the actual prefix >> attached to the hosts. > > That's an implementation method. I think Dave's proposed rule is > correct. > > =A0 =A0Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From marka@isc.org Fri Mar 16 17:52:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEE821E807B for ; Fri, 16 Mar 2012 17:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJL3eElCOzcM for ; Fri, 16 Mar 2012 17:52:49 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C7F7021E8014 for ; Fri, 16 Mar 2012 17:52:48 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 612675F98AF; Sat, 17 Mar 2012 00:52:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d1fb:f2c0:5ce0:8d7d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 68907216C36; Sat, 17 Mar 2012 00:52:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B44751EA0840; Sat, 17 Mar 2012 11:52:26 +1100 (EST) To: Dave Thaler From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <20120317001252.D5A711E9FC42@drugs.dv.isc.org> <9B57C850BB53634CACEC56EF4 853FF653B4A58D6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-reply-to: Your message of "Sat, 17 Mar 2012 00:25:22 -0000." <9B57C850BB53634CACEC56EF4853FF653B4A58D6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Sat, 17 Mar 2012 11:52:26 +1100 Message-Id: <20120317005226.B44751EA0840@drugs.dv.isc.org> Cc: "ipv6@ietf.org" , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 00:52:49 -0000 In message <9B57C850BB53634CACEC56EF4853FF653B4A58D6@TK5EX14MBXW603.wingroup.wi ndeploy.ntdev.microsoft.com>, Dave Thaler writes: > See > http://tools.ietf.org/html/draft-ietf-ipngwg-site-prefixes-05 > > -Dave Essentially the same thing with a wasted bit. No site is "the world" so you don't need the S bit if you make valid site prefix lengths 1..128. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From shemant@cisco.com Fri Mar 16 18:37:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6736121E8026 for ; Fri, 16 Mar 2012 18:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUJ3rjzLJ-Ta for ; Fri, 16 Mar 2012 18:37:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7A33F21E800F for ; Fri, 16 Mar 2012 18:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9258; q=dns/txt; s=iport; t=1331948230; x=1333157830; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=mqOCrnVWXQ3V2n/StjEYwKeTGCoAPdJPHHhW1d9Jy1A=; b=PnKzdFrlATwiSKliUKOIo3AL07k0QZAgtp8P/pSzIYcvok32ao22grnl 3FJrcHG6hxfn+NHW17Sj6EZaLIbtX6Etfnhrz9YFOu7fXfPjmN4XNdr3s H2B+Qvv5fcRRtc8sau43FZLseN0GZzLGbBeeaBK93OBC8+CXuRt5C1r1/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAXqY0+tJXHB/2dsb2JhbABCgkazeYEHggkBAQEEEgEJEQNJDAQCAQgOAwQBAQsGFwEGAUUJCAEBBAESCBqHaJpZnyOQFmMEiFabT4FogwQ X-IronPort-AV: E=Sophos;i="4.73,601,1325462400"; d="scan'208,217";a="64181232" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 17 Mar 2012 01:37:08 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2H1b8HE027769; Sat, 17 Mar 2012 01:37:08 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 20:37:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD03DE.77744378" Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Date: Fri, 16 Mar 2012 20:37:08 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: Ac0D1Q6ZSJeeXn6lS+egM5tNTGvddgACCeug References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> From: "Hemant Singh (shemant)" To: "Arifumi Matsumoto" , "Brian E Carpenter" X-OriginalArrivalTime: 17 Mar 2012 01:37:08.0789 (UTC) FILETIME=[779B1E50:01CD03DE] Cc: Bob Hinden , Brian Haberman , ipv6@ietf.org, Dave Thaler X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 01:37:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD03DE.77744378 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Arifumi, =20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Arifumi Matsumoto Sent: Friday, March 16, 2012 8:30 PM To: Brian E Carpenter Cc: ipv6@ietf.org; Brian Haberman; Bob Hinden; Dave Thaler Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] =20 >ULA-to-ULA will not be preferred, because ULAs are assigned lower >precedence value in the policy table than those of IPv4 and IPv6 >global addresses. =20 I certainly understand if a host has an IPv4 and a ULA assigned, the policy table prefers the IPv4 over the ULA otherwise Internet connectivity for the host breaks down. Likewise if the host has an IPv6 global and a ULA (which is also globally scoped), the IPv6 global is preferred or Internet connectivity breaks down. However, the issue that Brian raised needs some thought. The host has an IPv4, IPv6 global, and a ULA address. What if the packet destination is a ULA for local communication, so why not use a longest-prefix match and use a ULA source? How does a longest-prefix match relate to the policy table? Do we have a mode where the policy table is the only entity used for source address selection (SAS)? If yes, then how does the ULA to ULA communication above work? =20 Best back, =20 Hemant =20 =20 ------_=_NextPart_001_01CD03DE.77744378 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Arifumi,

 

-----Original Message-----
From: = ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Arifumi Matsumoto
Sent: Friday, March 16, 2012 8:30 PM
To: Brian E = Carpenter
Cc: ipv6@ietf.org; Brian Haberman; Bob Hinden; Dave = Thaler
Subject: Re: ULA scope = [draft-ietf-6man-rfc3484-revise-05.txt]

 

>ULA-to-ULA will not be = preferred, because ULAs are assigned lower

>precedence value in the policy table than those of IPv4 and = IPv6

>global = addresses.

 

I certainly understand if a host has an IPv4 and a ULA = assigned, the policy table prefers the IPv4 over the ULA otherwise = Internet connectivity for the host breaks down.  Likewise if the = host has an IPv6 global and a ULA (which is also globally scoped), the = IPv6 global is preferred or Internet connectivity breaks = down.   However, the issue that Brian raised needs some = thought.  The host has an IPv4, IPv6 global, and a ULA address. = What if the packet destination is a ULA for local communication, so why = not use a longest-prefix match and use a ULA source?  How does a = longest-prefix match relate to the policy table?  Do we have a mode = where the policy table is the only entity used for source address = selection (SAS)? If yes, then how does the ULA to ULA communication = above work?

 

Best back,

 

Hemant

 

 

------_=_NextPart_001_01CD03DE.77744378-- From brian.e.carpenter@gmail.com Fri Mar 16 20:18:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5564521F84E7 for ; Fri, 16 Mar 2012 20:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3eI5Esaf536 for ; Fri, 16 Mar 2012 20:18:14 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75D8021F84E4 for ; Fri, 16 Mar 2012 20:18:14 -0700 (PDT) Received: by eeke51 with SMTP id e51so2548058eek.31 for ; Fri, 16 Mar 2012 20:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WaYDo8PxFBwixTQ6ERowmdDS94yZgzKUopQuBZ2mXyQ=; b=WqypiMnFKVJH9oRYl7iGSHYQGiX1qqUE6AMPuuByi98Fl6Xiw1nyxqzCPQxrN6SX+Y fyATBhNth5nM07QQyO+QO40byKCbEnKH5CKrhZ4ACHZICgmca1JF3UC1xLjWApldo9Be sLE7dlcpKoW3fTcyHI2VmwVVfOfObKfNIKDYPlpRz+MCCobMt5HLaHc/N6nvRoyZ9sg9 BnKAZkK+Kzrb4fFsVli2x1dFknvSn0pyI3htHrPjoHqSLZmMNZvA14H0/8NR06ZGo0tG JQGnSVVCyZckjEQMoTd0EvQuC+HbhODGsY63MhcKlMJ+Zkg5AsPzTI4F7gjgtGfQk2Dl 1ymw== Received: by 10.14.96.6 with SMTP id q6mr614580eef.6.1331954293655; Fri, 16 Mar 2012 20:18:13 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id r44sm24671152eef.2.2012.03.16.20.18.08 (version=SSLv3 cipher=OTHER); Fri, 16 Mar 2012 20:18:12 -0700 (PDT) Message-ID: <4F64026B.8080308@gmail.com> Date: Sat, 17 Mar 2012 16:18:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, Brian Haberman , Arifumi Matsumoto , Dave Thaler , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 03:18:15 -0000 On 2012-03-17 14:37, Hemant Singh (shemant) wrote: > Arifumi, > > > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Arifumi Matsumoto > Sent: Friday, March 16, 2012 8:30 PM > To: Brian E Carpenter > Cc: ipv6@ietf.org; Brian Haberman; Bob Hinden; Dave Thaler > Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] > > > >> ULA-to-ULA will not be preferred, because ULAs are assigned lower > >> precedence value in the policy table than those of IPv4 and IPv6 > >> global addresses. > > > > I certainly understand if a host has an IPv4 and a ULA assigned, the > policy table prefers the IPv4 over the ULA otherwise Internet > connectivity for the host breaks down. Likewise if the host has an IPv6 > global and a ULA (which is also globally scoped), the IPv6 global is > preferred or Internet connectivity breaks down. However, the issue > that Brian raised needs some thought. The host has an IPv4, IPv6 > global, and a ULA address. What if the packet destination is a ULA for > local communication, so why not use a longest-prefix match and use a ULA > source? How does a longest-prefix match relate to the policy table? Do > we have a mode where the policy table is the only entity used for source > address selection (SAS)? If yes, then how does the ULA to ULA > communication above work? Let me be clear. If a local service has (for some reason) both a ULA and a non-ULA global address, and the host has both, I think the correct default behaviour is for the ULA address pair to be used. This is a matter of address-pair selection, however, not of source or destination selection alone. Brian From dthaler@microsoft.com Fri Mar 16 23:22:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2281321F8642 for ; Fri, 16 Mar 2012 23:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.846 X-Spam-Level: X-Spam-Status: No, score=-103.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf9wQ90ska08 for ; Fri, 16 Mar 2012 23:22:43 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 20B8C21F862B for ; Fri, 16 Mar 2012 23:22:43 -0700 (PDT) Received: from mail78-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 17 Mar 2012 06:22:40 +0000 Received: from mail78-db3 (localhost [127.0.0.1]) by mail78-db3-R.bigfish.com (Postfix) with ESMTP id 700424E01FF; Sat, 17 Mar 2012 06:22:40 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail78-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail78-db3 (localhost.localdomain [127.0.0.1]) by mail78-db3 (MessageSwitch) id 1331965358466438_4352; Sat, 17 Mar 2012 06:22:38 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.227]) by mail78-db3.bigfish.com (Postfix) with ESMTP id 63BEF18004B; Sat, 17 Mar 2012 06:22:38 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 17 Mar 2012 06:22:38 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sat, 17 Mar 2012 06:22:37 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 16 Mar 2012 23:22:37 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.57]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Fri, 16 Mar 2012 23:22:36 -0700 From: Dave Thaler To: Brian E Carpenter , "Hemant Singh (shemant)" Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Topic: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHM61TBqpyDXQSHVE+cgiqvxUSI2pZMJnCAgAiknaCAGJMlgIAAiWIAgABhLICAABLdAIAAHDKA//+81MA= Date: Sat, 17 Mar 2012 06:22:36 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> In-Reply-To: <4F64026B.8080308@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org" , Brian Haberman , Arifumi Matsumoto , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 06:22:44 -0000 QnJpYW4gQ2FycGVudGVyIHdyaXRlczoNClsuLi5dDQo+IExldCBtZSBiZSBjbGVhci4gSWYgYSBs b2NhbCBzZXJ2aWNlIGhhcyAoZm9yIHNvbWUgcmVhc29uKSBib3RoIGEgVUxBIGFuZCBhIG5vbi0N Cj4gVUxBIGdsb2JhbCBhZGRyZXNzLCBhbmQgdGhlIGhvc3QgaGFzIGJvdGgsIEkgdGhpbmsgdGhl IGNvcnJlY3QgZGVmYXVsdA0KPiBiZWhhdmlvdXIgaXMgZm9yIHRoZSBVTEEgYWRkcmVzcyBwYWly IHRvIGJlIHVzZWQuDQoNCkFzIEkgcHV0IGludG8gdGhlIGRvYywgSSBkb24ndCB0aGluayB0aGF0 J3MgcXVpdGUgcmlnaHQuDQoNCklmIGJvdGggdGhlIHNvdXJjZSBhbmQgZGVzdCBVTEFzIGFyZSBp biB0aGUgc2FtZSAvNDggdGhlbiBJIHRoaW5rIHRoZSBjb3JyZWN0DQpkZWZhdWx0IGlzIGFzIHlv dSBzYXkgKHVzZSBVTEEpLg0KDQpJZiB0aGUgc291cmNlIGFuZCBkZXN0IFVMQXMgYXJlIGluIGRp ZmZlcmVudCAvNDgncyB0aGVuIEkgdGhpbmsgdGhlIGNvcnJlY3QNCmRlZmF1bHQgaXMgaW5zdGVh ZCB0byB1c2UgdGhlIG5vbi1VTEEgZ2xvYmFsLCBzaW5jZSB0aGVyZSdzIG5vIGd1YXJhbnRlZSBv Zg0Kcm91dGFiaWxpdHkgYmV0d2VlbiBkaWZmZXJlbnQgLzQ4cy4gIFNvIHVubGVzcyBjb25maWd1 cmVkIG90aGVyd2lzZSwgb25lDQpoYXMgdG8gYXNzdW1lIGl0J3MgZmFyIG1vcmUgcHJvYmxlbWF0 aWMgdGhhbiBhIG5vbi1VTEEgZ2xvYmFsLg0KDQpZb3UnbGwgZmluZCB0aGUgYWJvdmUgbG9naWMg aW4gdGhlIGN1cnJlbnQgMzQ4NGJpcyBkcmFmdC4NCg0KLURhdmUNCg== From ehudoron@gmail.com Sat Mar 17 03:46:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6506921F86BB for ; Sat, 17 Mar 2012 03:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwn5hjx5iM4G for ; Sat, 17 Mar 2012 03:46:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCCC21F86B9 for ; Sat, 17 Mar 2012 03:46:39 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so6147664vcb.31 for ; Sat, 17 Mar 2012 03:46:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=egTNAouYovJNZr8c7G14KthyNxK0+T5eVk/v+Uk14h4=; b=VJ8zhRJ7yDBtAFOKax1UhQtL3qWSzpFaezHOiqcc2kepJq0U7lpZvuv/IfmlbEFcax +Yzg9iQ8SdrfdPlpkf6DMNHnfpJ6+ikReXfFJuw3/+3jeQtFfSe6ohgcg8qBpKOmwTru As/9d0Gsud7vFXnS5aPgDlJAeZe7Y2Bu+BXVWmIiTOtQ1MEwblrskG4ECf/8ZUbvp6/E 835ZWSAk/ncSge9bBTA1jw8aV2/hNbtCO5al0zPIBg8wA4XThHgV171PqkY4tE13jH14 kn8gbZ01Xf4C59xXHAj6s8IDv1lNeBOLj8JAz6XnQLgpzelYcFWeuoVNFbWOktCuuYAf BOow== MIME-Version: 1.0 Received: by 10.52.69.4 with SMTP id a4mr2633712vdu.87.1331981198937; Sat, 17 Mar 2012 03:46:38 -0700 (PDT) Received: by 10.220.17.208 with HTTP; Sat, 17 Mar 2012 03:46:38 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Mar 2012 12:46:38 +0200 Message-ID: Subject: Re: draft-macaulay-6man-packet-stain-00 --- Issues to consider From: Ehud Doron To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=20cf30780b4e35ccf904bb6e0ae8 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 10:46:40 -0000 --20cf30780b4e35ccf904bb6e0ae8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > Hello Tyson > > > > Indeed a very good and interesting work!! > > > > I would like to suggest a few issues for you and the WG to consider: > > > > 1. In chapter 5 you proposed the PSDO structure. I think you must > consider the addition of Stain structure and semantics to be part of the > draft. Make the Stain semantics be vendor or security managers dependent > can be problematic. We must consider enterprise connecting to multiple IS= Ps > and vice versa. For Stain provider, define a Stain per customer might be > difficult to manage. The Stain provider cannot impose Stain structure > because his customers might be connected to multiple ISPs, thus to multip= le > Stain provider. > > 2. Page 4, chapter 3, item #3 : I think that major concern here is > *scalability*. The client must deal with huge number of security > intelligence, this imposes relatively complicated and expensive hardware > and software. In chapter 3.1, it might be reasonable to add the scalabili= ty > benefit. In system view and in general, the IP Staining approach introduc= es > a genuine and efficient architecture with relatively *small number* of > high scale devices (PMDs) and *large number* of simple and low scale > devices all over the network, mainly in costumers networks. I think this > can be emphasized also in chapter 3, and helps to better understand the > huge benefit of the proposed architecture. > > > > 3. Page 8 =96 The S and U bits shall be better explained. There > usages are not clear enough. Also please consider to add a requirement i= n > the Option Type to allow the PSDO to be silently ignored by any nodes don= =92t > supporting staining, specified by the 2 high order bits in the Option Typ= e . > > > > Best wishes, > > > > > > Ehud Doron > > Senior Architect, CTO office > > Radware Ltd. > > www.radware.com > > T:+972 (3) 7674655 > > M:+972 (54) 7575503 > > F:+972 (3) 7668997 > --20cf30780b4e35ccf904bb6e0ae8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello Tyson

=A0

Indeed a very good and= interesting work!!

=A0

I would like to sugges= t a few issues for you and the WG to consider:

=A0

1.=A0=A0=A0=A0=A0=A0 In chapter 5 you proposed the PSDO structu= re. I think you must consider the addition of Stain structure and semantics= to be part of the draft. Make the Stain semantics be vendor or security ma= nagers dependent can be problematic. We must consider enterprise connecting= to multiple ISPs and vice versa. For Stain provider, define a Stain per cu= stomer might be difficult to manage. The Stain provider cannot impose Stain= structure because his customers might be connected to multiple ISPs, thus = to multiple Stain provider.

2.=A0=A0=A0=A0=A0=A0 Page 4, chapter 3, item #3 :=A0 I = think that major concern here is scalability. The client must deal w= ith huge number of security intelligence, this imposes relatively complicat= ed and expensive hardware and software. In chapter 3.1, it might be reasona= ble to add the scalability benefit. In system view and in general, the IP S= taining approach introduces a genuine and efficient architecture with relat= ively small number of high scale devices (PMDs) and large number<= /b> of simple and low scale devices all over the network, mainly in costume= rs networks. I think this can be emphasized also in chapter 3, and helps to= better understand the huge benefit of the proposed architecture. =A0

=A0

3.=A0=A0=A0=A0=A0=A0 Page 8 =96 The S and U bits shall = be better explained. There usages are not clear enough. =A0Also please cons= ider to add a requirement in the Option Type to allow the PSDO to be silent= ly ignored by any nodes don=92t supporting staining, specified by the 2 hig= h order bits in the Option Type .

=A0

Best wishes,=A0=

=A0=A0

=A0

Ehud Doron

Senior Architect, CTO = office

Radware Ltd.

www.radware.com

T:+972 (3) 76= 74655

M:+972 (54)= 7575503

F:+972 (3) 76= 68997



--20cf30780b4e35ccf904bb6e0ae8-- From kerlyn2001@gmail.com Sat Mar 17 10:02:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD3621F855B; Sat, 17 Mar 2012 10:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHjY3FIqDTvs; Sat, 17 Mar 2012 10:02:08 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2C621F851C; Sat, 17 Mar 2012 10:02:07 -0700 (PDT) Received: by lbol12 with SMTP id l12so3017015lbo.31 for ; Sat, 17 Mar 2012 10:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nDCqmtwCBE9KSOH9MiptdcK7cfS3mizeJsLWmQSzYXM=; b=v8t2aGG8RQFhAgwwIvi+O9J2N0c5FbrraJN6G5M+kPTHo/XN6nq/6l8FwHbqjXF1RP a7b3ZzNdfKAJ8zIr+LJjuOeyhZtCfK+W5vAQtekjRGwxZxhI4bLeEYKYud9Qm18YFV3O bXTSYTSx6jqFGZAytcc++tN0zE7raLWGrKEEvnsTAfJI8paj6hjUBBLzDBJFif7lqwDn KCeAojA0R9WKNTYHkd4t3tlqRbOaYaj7eCU0PAqQpFebzGQdqnIoauZZazymR2sb4dSr CF04grJo7x6AvTdxSeKT/+fB3w3albhQjvCOWxpJet9+tdT/015+fpM3vhaYz4JaXgrn q0VQ== MIME-Version: 1.0 Received: by 10.152.147.202 with SMTP id tm10mr5350122lab.49.1332003726278; Sat, 17 Mar 2012 10:02:06 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Sat, 17 Mar 2012 10:02:06 -0700 (PDT) In-Reply-To: References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Sat, 17 Mar 2012 13:02:06 -0400 X-Google-Sender-Auth: INHGq7o-CvCWzd3hGwVNkW4bzRw Message-ID: Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] From: Kerry Lynn To: 6man , "homenet@ietf.org Group" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 17:02:09 -0000 On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler wrote: > Brian Carpenter writes: > [...] >> Let me be clear. If a local service has (for some reason) both a ULA and= a non- >> ULA global address, and the host has both, I think the correct default >> behaviour is for the ULA address pair to be used. > > As I put into the doc, I don't think that's quite right. > > If both the source and dest ULAs are in the same /48 then I think the cor= rect > default is as you say (use ULA). > > If the source and dest ULAs are in different /48's then I think the corre= ct > default is instead to use the non-ULA global, since there's no guarantee = of > routability between different /48s. =A0So unless configured otherwise, on= e > has to assume it's far more problematic than a non-ULA global. > Do you mean "no guarantee of symmetric routability"? =A0The fact that the packet arrived in the first place seems to indicate earlier policy choices (e.g. the sender may not have a non-ULA global address, and the two /48s already seem to share a common definition of "site"). I am still relatively new to homenet and I am surely missing a lot of background. =A0Has anyone discussed dealing with multiple /48 ULA prefixes in a single site? Thanks, -K- > You'll find the above logic in the current 3484bis draft. > > -Dave > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Sat Mar 17 12:04:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3721F85A1 for ; Sat, 17 Mar 2012 12:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAt64CbjCHLu for ; Sat, 17 Mar 2012 12:04:18 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDA321F8596 for ; Sat, 17 Mar 2012 12:04:14 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2609766eaa.31 for ; Sat, 17 Mar 2012 12:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5bfsBZfBUIjcO6N5orMQGaI9Aem2PpzgfMTaiPJTiyQ=; b=UhoifZ61xp5KnVmugGZfk2NHCMChD2ycMP//O1MxyUz/TQrByDq9MtziZjIJYGIU2b C2vd6xgBh9vJrSTJeukqxIY/OeO+epFny/srNoNbQ/4RaxXD0Df/6p/v7DO5eRds99gI 94Y5U748GlZh/aEvb85oYo+Q7+ftRPF59U60EH1kYrXKeL9Z54f889FdWaJfv0j5oZT4 /ltQNSl6ZcBaY3U9UoWrP0JNqYvTajzLAnpZLD15/7omCSxyvkCkc0LZB26qvNs8bBhC gABWs93S4lFMDGP9t39I0GjM6gA+llcTrSPr/vYY3EQhDk/d/cfyCopU+8i+lBynRqdR 7pUA== Received: by 10.213.20.12 with SMTP id d12mr413038ebb.278.1332011053646; Sat, 17 Mar 2012 12:04:13 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u9sm31176020eem.11.2012.03.17.12.04.08 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 12:04:12 -0700 (PDT) Message-ID: <4F64E01C.8060103@gmail.com> Date: Sun, 18 Mar 2012 08:03:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: <4EB3F3D6.4090302@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian Haberman , Arifumi Matsumoto , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 19:04:19 -0000 On 2012-03-17 19:22, Dave Thaler wrote: > Brian Carpenter writes: > [...] >> Let me be clear. If a local service has (for some reason) both a ULA and a non- >> ULA global address, and the host has both, I think the correct default >> behaviour is for the ULA address pair to be used. > > As I put into the doc, I don't think that's quite right. > > If both the source and dest ULAs are in the same /48 then I think the correct > default is as you say (use ULA). > > If the source and dest ULAs are in different /48's then I think the correct > default is instead to use the non-ULA global, since there's no guarantee of > routability between different /48s. So unless configured otherwise, one > has to assume it's far more problematic than a non-ULA global. Yes, I agree, that is a case that would need to be handled by locally installed rules if it was required to work (e.g. after a merger of two intranets using different ULA prefixes). I doubt that default rules can cover it. Brian > > You'll find the above logic in the current 3484bis draft. > > -Dave From arifumi@nttv6.net Sun Mar 18 21:09:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E3221F8478 for ; Sun, 18 Mar 2012 21:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNKixRGt4Hcz for ; Sun, 18 Mar 2012 21:09:34 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id F326821F854E for ; Sun, 18 Mar 2012 21:09:33 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q2J4AE2O091226; Mon, 19 Mar 2012 13:10:14 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 19 Mar 2012 13:08:27 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmai! l.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1257) Cc: Brian Haberman , "ipv6@ietf.org" , Bob Hinden , Arifumi Matsumoto X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 04:09:35 -0000 Dave, On 2012/03/17, at 15:22, Dave Thaler wrote: > Brian Carpenter writes: > [...] >> Let me be clear. If a local service has (for some reason) both a ULA = and a non- >> ULA global address, and the host has both, I think the correct = default >> behaviour is for the ULA address pair to be used. >=20 > As I put into the doc, I don't think that's quite right. >=20 > If both the source and dest ULAs are in the same /48 then I think the = correct > default is as you say (use ULA). What I see a possible problem is that, in the current bis-01, this is = not implemented as a required behavior. That is, the logic to prefer ULA in the same /48 is in the Example = section, and is not explicitly preferred/required/mandated in the document. >=20 > If the source and dest ULAs are in different /48's then I think the = correct > default is instead to use the non-ULA global, since there's no = guarantee of > routability between different /48s. So unless configured otherwise, = one > has to assume it's far more problematic than a non-ULA global. I do not see any problem about this point. Best regards, >=20 > You'll find the above logic in the current 3484bis draft. >=20 > -Dave > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From marc.lampo@eurid.eu Mon Mar 19 00:34:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9569E21F8542 for ; Mon, 19 Mar 2012 00:34:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...\t<4F64026B.8080308@gmail\n \n .com> <9B57C8[...] X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY7y-NUTSItL for ; Mon, 19 Mar 2012 00:34:14 -0700 (PDT) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB421F8527 for ; Mon, 19 Mar 2012 00:34:13 -0700 (PDT) X-ASG-Debug-ID: 1332142449-02dadd066727e4c0001-WbpaHM Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id t5outr4DExQ2tTay; Mon, 19 Mar 2012 08:34:09 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id BEB17E408C; Mon, 19 Mar 2012 08:34:09 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTi7OtOwX5PW; Mon, 19 Mar 2012 08:34:09 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 5931DE406A; Mon, 19 Mar 2012 08:34:09 +0100 (CET) From: "Marc Lampo" To: "'Dave Thaler'" , "'Brian E Carpenter'" , "'Hemant Singh \(shemant\)'" References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail .com> <9B57C850BB53634 CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Date: Mon, 19 Mar 2012 08:34:09 +0100 (CET) X-ASG-Orig-Subj: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Message-ID: <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0EBlg4CTZbFvOmSu+SqQr1HpgKeQBm3qpg Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1332142449 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: 'Arifumi Matsumoto' , 'Brian Haberman' , ipv6@ietf.org, 'Bob Hinden' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 07:34:14 -0000 Hello, +1 for Brian's statement : ULA within same /48, prefer ULA. For ULA not within same /48 : Please do not forget VPN ! In the IPv4 world, numerous devices, with private address space, Communicate through site-to-site VPN's. I'd assume this is equivalent to "ULA not in same /48". How could an end-device decide whether or not VPN is in place ? Wouldn't it be preferable to let "name resolving" decide which address to return to a client ? And if name resolving returns ULA, let end-device use ULA as well. (If there is no VPN in place, it would be a configuration error in the name resolving infrastructure) That way, network admins decide centrally, trough name resolving, how some party is can be reached. Any errors there would be name resolving which can, through DNS, be centrally solved. As opposed to some "smart" algorithm on end nodes that mistakingly choses the wrong address (and requiring some update on all of them ...) Kind regards, Marc Lampo -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: 17 March 2012 07:23 AM To: Brian E Carpenter; Hemant Singh (shemant) Cc: ipv6@ietf.org; Brian Haberman; Arifumi Matsumoto; Bob Hinden Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Brian Carpenter writes: [...] > Let me be clear. If a local service has (for some reason) both a ULA > and a non- ULA global address, and the host has both, I think the > correct default behaviour is for the ULA address pair to be used. As I put into the doc, I don't think that's quite right. If both the source and dest ULAs are in the same /48 then I think the correct default is as you say (use ULA). If the source and dest ULAs are in different /48's then I think the correct default is instead to use the non-ULA global, since there's no guarantee of routability between different /48s. So unless configured otherwise, one has to assume it's far more problematic than a non-ULA global. You'll find the above logic in the current 3484bis draft. -Dave From marka@isc.org Mon Mar 19 07:14:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CA821F8657 for ; Mon, 19 Mar 2012 07:14:25 -0700 (PDT) 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=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhwfOf7eXoUs for ; Mon, 19 Mar 2012 07:14:24 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 25C8A21F85F0 for ; Mon, 19 Mar 2012 07:14:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id B06D5C9423; Mon, 19 Mar 2012 14:14:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b172:9370:5751:49ec]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4E7D7216C31; Mon, 19 Mar 2012 14:14:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id DAECF1EAC06D; Tue, 20 Mar 2012 01:14:02 +1100 (EST) To: "Marc Lampo" From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail .com> <9B57C850BB53634 CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-reply-to: Your message of "Mon, 19 Mar 2012 08:34:09 BST." <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> Date: Tue, 20 Mar 2012 01:14:02 +1100 Message-Id: <20120319141402.DAECF1EAC06D@drugs.dv.isc.org> Cc: 'Brian Haberman' , ipv6@ietf.org, 'Bob Hinden' , 'Arifumi Matsumoto' , 'Dave Thaler' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:14:26 -0000 In message <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu>, "Marc Lampo" write s: > Hello, > > +1 for Brian's statement : ULA within same /48, prefer ULA. > > For ULA not within same /48 : > Please do not forget VPN ! > In the IPv4 world, numerous devices, with private address space, > Communicate through site-to-site VPN's. > I'd assume this is equivalent to "ULA not in same /48". > How could an end-device decide whether or not VPN is in place ? > > Wouldn't it be preferable to let "name resolving" decide which address > to return to a client ? > And if name resolving returns ULA, let end-device use ULA as well. > (If there is no VPN in place, it would be a configuration error > in the name resolving infrastructure) > That way, network admins decide centrally, trough name resolving, > how some party is can be reached. > > Any errors there would be name resolving which can, through DNS, > be centrally solved. > As opposed to some "smart" algorithm on end nodes that mistakingly > choses the wrong address (and requiring some update on all of them ...) > > Kind regards, > > Marc Lampo Are connecting a node or a net over the VPN? For a node this is a non-issue as the VPN's interface will be in one ULA and home net in the other ULA. The node is a site boundary. If you are connecting a net then you can do PD request(s) and advertise the returned prefixes. If the upstream starts to run out of prefixes they just generate a additional ULA prefix and number all the servers from it. Different VPN use different ULA but all can reach the central servers. By the time a organisation reaches this level of complexity they are a small ISP in their own right and should be able to get /32. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marc.lampo@eurid.eu Mon Mar 19 07:25:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA921F8746 for ; Mon, 19 Mar 2012 07:25:30 -0700 (PDT) X-Quarantine-ID: <08PLhydsU5hw> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ... <4F64026B.8080308@gmail\n \n .com> <9B[...] X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08PLhydsU5hw for ; Mon, 19 Mar 2012 07:25:29 -0700 (PDT) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2319321F8701 for ; Mon, 19 Mar 2012 07:25:29 -0700 (PDT) X-ASG-Debug-ID: 1332167482-0369490e9c6b030001-WbpaHM Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id Jp8XjLunn7abs6gq; Mon, 19 Mar 2012 15:31:22 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 9B94DE405E; Mon, 19 Mar 2012 15:25:26 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAK7p+kxuufe; Mon, 19 Mar 2012 15:25:26 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 819A1E4050; Mon, 19 Mar 2012 15:25:26 +0100 (CET) From: "Marc Lampo" To: "'Mark Andrews'" References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail .com> <9B57C850BB5 3634 CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> <20120319141402.DAECF1EAC06D@drugs.dv.isc.org> In-Reply-To: <20120319141402.DAECF1EAC06D@drugs.dv.isc.org> Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Date: Mon, 19 Mar 2012 15:25:26 +0100 (CET) X-ASG-Orig-Subj: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Message-ID: <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0F2tZN64OIsijHRtandW17ZXs4dgAAHsGg Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1332167482 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: 'Brian Haberman' , ipv6@ietf.org, 'Bob Hinden' , 'Arifumi Matsumoto' , 'Dave Thaler' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:25:30 -0000 Allow me to clarify with an example. In my IP(v4) experience, I have a customer with offices over multiple Continents - private address space in use everywhere - site-to-site VPN's (== connecting networks) connect the offices. If I map to IPv6 this might be one /48 ULA range; Some networks in central HQ, others remotely, behind site-to-site VPN. --> if one end-node in one network wants to reach another, in another network, its traffic must travel through the VPN. Please observe that using public addresses (not using ULA) might do away with address selection "challenges" but would imply that networks on all continents will have to be renumbered if the central HQ changes ISP (and hence : public IPv6 addresses). Something I'd like to avoid ... Kind regards, Marc Lampo -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: 19 March 2012 03:14 PM To: Marc Lampo Cc: 'Dave Thaler'; 'Brian E Carpenter'; 'Hemant Singh (shemant)'; 'Arifumi Matsumoto'; 'Brian Haberman'; ipv6@ietf.org; 'Bob Hinden' Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In message <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu>, "Marc Lampo" write s: > Hello, > > +1 for Brian's statement : ULA within same /48, prefer ULA. > > For ULA not within same /48 : > Please do not forget VPN ! > In the IPv4 world, numerous devices, with private address space, > Communicate through site-to-site VPN's. > I'd assume this is equivalent to "ULA not in same /48". > How could an end-device decide whether or not VPN is in place ? > > Wouldn't it be preferable to let "name resolving" decide which address > to return to a client ? > And if name resolving returns ULA, let end-device use ULA as well. > (If there is no VPN in place, it would be a configuration error in > the name resolving infrastructure) That way, network admins decide > centrally, trough name resolving, how some party is can be reached. > > Any errors there would be name resolving which can, through DNS, be > centrally solved. > As opposed to some "smart" algorithm on end nodes that mistakingly > choses the wrong address (and requiring some update on all of them > ...) > > Kind regards, > > Marc Lampo Are connecting a node or a net over the VPN? For a node this is a non-issue as the VPN's interface will be in one ULA and home net in the other ULA. The node is a site boundary. If you are connecting a net then you can do PD request(s) and advertise the returned prefixes. If the upstream starts to run out of prefixes they just generate a additional ULA prefix and number all the servers from it. Different VPN use different ULA but all can reach the central servers. By the time a organisation reaches this level of complexity they are a small ISP in their own right and should be able to get /32. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Mar 19 15:08:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3707A21F8702 for ; Mon, 19 Mar 2012 15:08:19 -0700 (PDT) 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=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etn4vOXSDnKB for ; Mon, 19 Mar 2012 15:08:18 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 629A121F86EA for ; Mon, 19 Mar 2012 15:08:18 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 655BFC942D; Mon, 19 Mar 2012 22:08:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:645b:31fe:90c7:4d73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0F0AA216C36; Mon, 19 Mar 2012 22:08:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 964E91EAD466; Tue, 20 Mar 2012 09:08:01 +1100 (EST) To: "Marc Lampo" From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail .com> <9B57C850BB5 3634 CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> <20120319141402.DAECF1EAC06D@drugs.dv.isc.org> <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-reply-to: Your message of "Mon, 19 Mar 2012 15:25:26 BST." <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu> Date: Tue, 20 Mar 2012 09:08:01 +1100 Message-Id: <20120319220801.964E91EAD466@drugs.dv.isc.org> Cc: 'Bob Hinden' , 'Brian Haberman' , ipv6@ietf.org, 'Arifumi Matsumoto' , 'Dave Thaler' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:08:20 -0000 In message <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu>, "Marc Lampo" write s: > Allow me to clarify with an example. > > In my IP(v4) experience, I have a customer with offices over multiple > Continents - private address space in use everywhere - > site-to-site VPN's (== connecting networks) connect the offices. > > If I map to IPv6 this might be one /48 ULA range; > Some networks in central HQ, others remotely, behind site-to-site VPN. > > --> if one end-node in one network wants to reach another, > in another network, its traffic must travel through the VPN. > > Please observe that using public addresses (not using ULA) > might do away with address selection "challenges" > but would imply that networks on all continents will have to be > renumbered if the central HQ changes ISP (and hence : public IPv6 > addresses). > Something I'd like to avoid ... > > Kind regards, > > Marc Lampo Well with a single ULA you have 65536 /64 sized networks to use where ever you want. You have ULA:0000/56 in Paris, ULA:0100/55 in New York. You don't have to keep things bit aligned but it helps. 65536 prefixes isn't a lot of routing information. Think of it in IPv4 terms as 10/8 and you are handing out /24 for each subnet except you know you won't need more than /24 ever. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Mar 19 15:29:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6950F21E8012 for ; Mon, 19 Mar 2012 15:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIle4w57zlJk for ; Mon, 19 Mar 2012 15:29:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CE47321E800C for ; Mon, 19 Mar 2012 15:29:22 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id B2DF6C944A; Mon, 19 Mar 2012 22:29:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:645b:31fe:90c7:4d73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 332FE216C36; Mon, 19 Mar 2012 22:29:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 843801EAD52B; Tue, 20 Mar 2012 09:29:06 +1100 (EST) From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail .com> <9B57C850BB5 3634 CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> <20120319141402.DAECF1EAC06D@drugs.dv.isc.org> <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu> <20120319220801.964E91EAD466@drugs.dv.isc.org> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-reply-to: Your message of "Tue, 20 Mar 2012 09:08:01 +1100." <20120319220801.964E91EAD466@drugs.dv.isc.org> Date: Tue, 20 Mar 2012 09:29:06 +1100 Message-Id: <20120319222906.843801EAD52B@drugs.dv.isc.org> Cc: 'Brian Haberman' , ipv6@ietf.org, 'Arifumi Matsumoto' , 'Bob Hinden' , 'Dave Thaler' , Marc Lampo X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:29:23 -0000 In message <20120319220801.964E91EAD466@drugs.dv.isc.org>, Mark Andrews writes: > > In message <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu>, "Marc Lampo" wri > te > s: > > Allow me to clarify with an example. > > > > In my IP(v4) experience, I have a customer with offices over multiple > > Continents - private address space in use everywhere - > > site-to-site VPN's (== connecting networks) connect the offices. > > > > If I map to IPv6 this might be one /48 ULA range; > > Some networks in central HQ, others remotely, behind site-to-site VPN. > > > > --> if one end-node in one network wants to reach another, > > in another network, its traffic must travel through the VPN. > > > > Please observe that using public addresses (not using ULA) > > might do away with address selection "challenges" > > but would imply that networks on all continents will have to be > > renumbered if the central HQ changes ISP (and hence : public IPv6 > > addresses). > > Something I'd like to avoid ... > > > > Kind regards, > > > > Marc Lampo > > Well with a single ULA you have 65536 /64 sized networks to use > where ever you want. You have ULA:0000/56 in Paris, ULA:0100/55 > in New York. You don't have to keep things bit aligned but it > helps. 65536 prefixes isn't a lot of routing information. Think > of it in IPv4 terms as 10/8 and you are handing out /24 for each > subnet except you know you won't need more than /24 ever. Alternatively you can give each site its own ULA and you use non default address selection rules. Remember we are talking about the default rules here. There are billions of more homes than there are businesses. They would use rules like the follow which give all the sites a common label: ::1 50 0 ULA1:/48 45 100 ULA2:/48 45 100 ULA3:/48 45 100 ::/0 40 1 2002:: 30 2 fc00:: 0 3 Whereas the default rules generate a table like if it was multi-homed to three sites: ::1 50 0 ULA1:/48 45 4 ULA2:/48 45 5 ULA3:/48 45 6 ::/0 40 1 2002:: 30 2 fc00:: 0 3 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marc.lampo@eurid.eu Tue Mar 20 00:10:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EADF21F86D8 for ; Tue, 20 Mar 2012 00:10:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ... <4F64026B.8080308@gmail\n \n .com> <9B[...] X-Spam-Flag: NO X-Spam-Score: -0.995 X-Spam-Level: X-Spam-Status: No, score=-0.995 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8qWB9gaJwsU for ; Tue, 20 Mar 2012 00:10:35 -0700 (PDT) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5D67D21F8674 for ; Tue, 20 Mar 2012 00:10:34 -0700 (PDT) X-ASG-Debug-ID: 1332227432-02dadd0668282af0001-WbpaHM Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id cN06LaCuC5v7ETWr; Tue, 20 Mar 2012 08:10:32 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id EDA72E406D; Tue, 20 Mar 2012 08:10:31 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M41oV2-uW3kI; Tue, 20 Mar 2012 08:10:31 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id D8065E4050; Tue, 20 Mar 2012 08:10:31 +0100 (CET) From: "Marc Lampo" To: "'Mark Andrews'" References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail .com> <9B57C850BB5 3634 CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> <20120319141402.DAECF1EAC06D@drugs.dv.isc.org> <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu> <20120319220801.964E91EAD466@drugs.dv.isc.org> <20120319222906.843801EAD52B@drugs.dv.isc.org> In-Reply-To: <20120319222906.843801EAD52B@drugs.dv.isc.org> Subject: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Date: Tue, 20 Mar 2012 08:10:31 +0100 (CET) X-ASG-Orig-Subj: RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Message-ID: <006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Ac0GH/uwppb/WtccT6KyG8n4hmMrNgASBh/g Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1332227432 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: ipv6@ietf.org, 'Brian Haberman' , 'Bob Hinden' , 'Arifumi Matsumoto' , 'Dave Thaler' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 07:10:36 -0000 Hello, I understand what you are writing, but is this the right way ? The address selection table is, as far as I understand, statically defined - not dynamically configurable (SLAAC or DHCPv6). So, the suggestion is to adapt the table on every node of the organisation. In other words, every node in the organisation is somehow - via the address selection table - aware of the organisations network topology (VPN's and so). Is this desired ? Kind regards, Marc Lampo -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: 19 March 2012 11:29 PM Cc: Marc Lampo; 'Bob Hinden'; 'Brian Haberman'; ipv6@ietf.org; 'Arifumi Matsumoto'; 'Dave Thaler' Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In message <20120319220801.964E91EAD466@drugs.dv.isc.org>, Mark Andrews writes: > > In message <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu>, "Marc > Lampo" wri te > s: > > Allow me to clarify with an example. > > > > In my IP(v4) experience, I have a customer with offices over > > multiple Continents - private address space in use everywhere - > > site-to-site VPN's (== connecting networks) connect the offices. > > > > If I map to IPv6 this might be one /48 ULA range; Some networks in > > central HQ, others remotely, behind site-to-site VPN. > > > > --> if one end-node in one network wants to reach another, > > in another network, its traffic must travel through the VPN. > > > > Please observe that using public addresses (not using ULA) might do > > away with address selection "challenges" > > but would imply that networks on all continents will have to be > > renumbered if the central HQ changes ISP (and hence : public IPv6 > > addresses). > > Something I'd like to avoid ... > > > > Kind regards, > > > > Marc Lampo > > Well with a single ULA you have 65536 /64 sized networks to use where > ever you want. You have ULA:0000/56 in Paris, ULA:0100/55 in New > York. You don't have to keep things bit aligned but it helps. 65536 > prefixes isn't a lot of routing information. Think of it in IPv4 > terms as 10/8 and you are handing out /24 for each subnet except you > know you won't need more than /24 ever. Alternatively you can give each site its own ULA and you use non default address selection rules. Remember we are talking about the default rules here. There are billions of more homes than there are businesses. They would use rules like the follow which give all the sites a common label: ::1 50 0 ULA1:/48 45 100 ULA2:/48 45 100 ULA3:/48 45 100 ::/0 40 1 2002:: 30 2 fc00:: 0 3 Whereas the default rules generate a table like if it was multi-homed to three sites: ::1 50 0 ULA1:/48 45 4 ULA2:/48 45 5 ULA3:/48 45 6 ::/0 40 1 2002:: 30 2 fc00:: 0 3 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Anders_Brandt@sigmadesigns.com Tue Mar 20 01:51:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4532821F87D2; Tue, 20 Mar 2012 01:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1cHnv7Fpen9; Tue, 20 Mar 2012 01:51:36 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id E00D121F87EF; Tue, 20 Mar 2012 01:51:35 -0700 (PDT) From: Anders Brandt To: Kerry Lynn , 6man , "homenet@ietf.org Group" Subject: RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkA Date: Tue, 20 Mar 2012 08:51:31 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-ex1> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-Mailman-Approved-At: Tue, 20 Mar 2012 02:05:47 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 08:51:37 -0000 Kerry Lynn writes: > On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler > wrote: > > Brian Carpenter writes: > > [...] > >> Let me be clear. If a local service has (for some reason) both a ULA > >> and a non- ULA global address, and the host has both, I think the > >> correct default behaviour is for the ULA address pair to be used. > > > > As I put into the doc, I don't think that's quite right. > > > > If both the source and dest ULAs are in the same /48 then I think the > > correct default is as you say (use ULA). > > > > If the source and dest ULAs are in different /48's then I think the > > correct default is instead to use the non-ULA global, since there's no > > guarantee of routability between different /48s. =A0So unless configure= d > > otherwise, one has to assume it's far more problematic than a non-ULA > global. > > > Do you mean "no guarantee of symmetric routability"? =A0The fact that the > packet arrived in the first place seems to indicate earlier policy choice= s (e.g. > the sender may not have a non-ULA global address, and the two /48s alread= y > seem to share a common definition of "site"). >=20 > I am still relatively new to homenet and I am surely missing a lot of > background. =A0Has anyone discussed dealing with multiple /48 ULA prefixe= s > in a single site? I would like to second Kerry. It is a surprise to me that ULA addresses are not by default routable withi= n the site. I can easily imagine a number of LLN border routers which autonomously allo= cate different ULA prefixes for use within their individual LLN subnets. Meeting a ULA address outside the local prefix will cause the LLN node to f= orward its IP packets to the default gateway (border router) of the LLN subnet. Th= is way packets can travel between LLN subnets using normal routing with long-term = stable ULA addresses. We need the stable addresses for control-style applications = in LLNs. Obviously it requires a routing protocol in the (homenet) LAN but are there= other issues? Thanks, Anders >=20 > > You'll find the above logic in the current 3484bis draft. > > > > -Dave > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From marka@isc.org Tue Mar 20 04:04:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1222421F8671 for ; Tue, 20 Mar 2012 04:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K5VNqsnKYpZ for ; Tue, 20 Mar 2012 04:04:55 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 464DB21F8669 for ; Tue, 20 Mar 2012 04:04:53 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 8A5DB5F984C; Tue, 20 Mar 2012 11:04:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3015:bcfd:6560:14fd]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 778DD216C31; Tue, 20 Mar 2012 11:04:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 580611EB7252; Tue, 20 Mar 2012 22:04:16 +1100 (EST) To: "Marc Lampo" From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net><4EEA3D20.7020603@innovationslab.net><4EEA5793.8080800@gmail.com><4EEA7AF8.2090508@gmail.com><9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com><4F3ABFBA.8060605@gmail.com><29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net><9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail .com> <9B57C850BB5 3634 CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu> <20120319141402.DAECF1EAC06D@drugs.dv.isc.org> <01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu> <20120319220801.964E91EAD466@drugs.dv.isc.org> <20120319222906.843801EAD52B@drugs.dv.isc.org> <006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-reply-to: Your message of "Tue, 20 Mar 2012 08:10:31 BST." <006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu> Date: Tue, 20 Mar 2012 22:04:15 +1100 Message-Id: <20120320110416.580611EB7252@drugs.dv.isc.org> Cc: ipv6@ietf.org, 'Brian Haberman' , 'Bob Hinden' , 'Arifumi Matsumoto' , 'Dave Thaler' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 11:04:56 -0000 In message <006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu>, "Marc Lampo" write s: > Hello, > > I understand what you are writing, but is this the right way ? Yes. It was always intended that this be updatable network wide. http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 > The address selection table is, as far as I understand, > statically defined - not dynamically configurable (SLAAC or DHCPv6). > So, the suggestion is to adapt the table on every node of > the organisation. Yep. DHCP does this sort of thing very well. > In other words, every node in the organisation is somehow > - via the address selection table - aware of the organisations > network topology (VPN's and so). > Is this desired ? Sure, why not? Lots of equipment won't need to know it but they are all capable of processing. > Kind regards, > > Marc Lampo -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Tue Mar 20 14:26:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3D221F85A4; Tue, 20 Mar 2012 14:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16yX3SqEj7r1; Tue, 20 Mar 2012 14:26:04 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5A21F85A3; Tue, 20 Mar 2012 14:26:04 -0700 (PDT) Received: by dakl33 with SMTP id l33so561573dak.31 for ; Tue, 20 Mar 2012 14:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4pCWAxuWl6tggh0bkdZ2roAwi+dvY+9087L0JG+PAfA=; b=Og8ueXzfTLFfROY+7k6xqbHH8DOGqMFfFNsqv0Nw7XjQaSVOduo6dtBl0Mytmt5ixw orqXgypU6/0DBshkn6IGCtrfaoWJoUXf9yUBG+ffU9lNbGMW0DOj7SoTuLjaOATmvy/h oaBkodjq2UG9PJMNK3bxXeAE5vvMpXv+n3Pa3dMtaVhgsN+pHmu8aGDD9gOQtO9eao7E dLpA79sAAx3jEulZZeQZsTW/Jq2BMwTyUt7DQRH92bFFAANeu5ozefc1Sn6o1xaKWbTD SzOAU3sXR7tz/yFDUn9m+UroUf3pMcER+ev4Xtq2TUkDYHdjKFH5Q99AIZSoizqgBGaw XPUg== Received: by 10.68.203.202 with SMTP id ks10mr4787714pbc.84.1332278763734; Tue, 20 Mar 2012 14:26:03 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id y9sm2067366pbu.40.2012.03.20.14.26.01 (version=SSLv3 cipher=OTHER); Tue, 20 Mar 2012 14:26:03 -0700 (PDT) Message-ID: <4F68F5E5.7060901@gmail.com> Date: Wed, 21 Mar 2012 10:25:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anders Brandt Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-ex 1> In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-ex1> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man , "homenet@ietf.org Group" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:26:05 -0000 On 2012-03-20 21:51, Anders Brandt wrote: > Kerry Lynn writes: > >> On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler >> wrote: >>> Brian Carpenter writes: >>> [...] >>>> Let me be clear. If a local service has (for some reason) both a ULA >>>> and a non- ULA global address, and the host has both, I think the >>>> correct default behaviour is for the ULA address pair to be used. >>> As I put into the doc, I don't think that's quite right. >>> >>> If both the source and dest ULAs are in the same /48 then I think the >>> correct default is as you say (use ULA). >>> >>> If the source and dest ULAs are in different /48's then I think the >>> correct default is instead to use the non-ULA global, since there's no >>> guarantee of routability between different /48s. So unless configured >>> otherwise, one has to assume it's far more problematic than a non-ULA >> global. >> Do you mean "no guarantee of symmetric routability"? The fact that the >> packet arrived in the first place seems to indicate earlier policy choices (e.g. >> the sender may not have a non-ULA global address, and the two /48s already >> seem to share a common definition of "site"). >> >> I am still relatively new to homenet and I am surely missing a lot of >> background. Has anyone discussed dealing with multiple /48 ULA prefixes >> in a single site? > > I would like to second Kerry. > > It is a surprise to me that ULA addresses are not by default routable within the site. > I can easily imagine a number of LLN border routers which autonomously allocate > different ULA prefixes for use within their individual LLN subnets. IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they cover an entire enterprise or home network, but not if they cover a subset. > Meeting a ULA address outside the local prefix will cause the LLN node to forward > its IP packets to the default gateway (border router) of the LLN subnet. This way > packets can travel between LLN subnets using normal routing with long-term stable > ULA addresses. We need the stable addresses for control-style applications in LLNs. > > Obviously it requires a routing protocol in the (homenet) LAN but are there other issues? It doesn't just require a routing protocol; it also requires a routing policy that knows which routers have to block the ULAs (plural). That seems a lot more complex that a rule that says only a border router originates and delegates a ULA prefix, because that border router would also know to block the prefix across the border. Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis and discuss it over on v6ops. Brian > > Thanks, > Anders >>> You'll find the above logic in the current 3484bis draft. >>> >>> -Dave >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From tjc@ecs.soton.ac.uk Wed Mar 21 04:55:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53A21F8690; Wed, 21 Mar 2012 04:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLnpZ+vOuMz6; Wed, 21 Mar 2012 04:55:10 -0700 (PDT) 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 5790421F8684; Wed, 21 Mar 2012 04:55:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LBt8cd023194; Wed, 21 Mar 2012 11:55:08 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2LBt8cd023194 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1332330908; bh=OZyVavRXXgFMTOe/6uSYjVc03KQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=TUr8NETdAGCqFmm/1sUl3kiypA4ZmgQi0JPtZzgmEHAZ4xumB6h4Zw4ix+eQqpX/L 8gQ8SB/Avrntj/zh+wHgf4idOS7nJL4as8BKcAKdzgdPKo4VYldk+K0Txl71gif8ym 2y+8H4P40v+iUULM40/xVC3Op0QtYSWXIVBFU/rI= 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 id o2KBy80543741358O3 ret-id none; Wed, 21 Mar 2012 11:55:08 +0000 Received: from [IPv6:2001:630:d0:ed03:c41f:eca9:3eba:be1c] ([IPv6:2001:630:d0:ed03:c41f:eca9:3eba:be1c]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LBt4Jn031716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Mar 2012 11:55:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] From: Tim Chown In-Reply-To: <4F68F5E5.7060901@gmail.com> Date: Wed, 21 Mar 2012 11:55:05 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-e! x 1> <4F68F5E5.7060901@gmail.com> <031E46EC-73ED-44A4-B966-B249DCAD367C@ecs.soton.ac.uk> To: 6man , "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2KBy8054374135800; tid=o2KBy80543741358O3; 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: q2LBt8cd023194 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:55:11 -0000 On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: > On 2012-03-20 21:51, Anders Brandt wrote: >>=20 >> It is a surprise to me that ULA addresses are not by default routable = within the site. >> I can easily imagine a number of LLN border routers which = autonomously allocate >> different ULA prefixes for use within their individual LLN subnets. >=20 > IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if = they > cover an entire enterprise or home network, but not if they cover a = subset. >=20 >> Meeting a ULA address outside the local prefix will cause the LLN = node to forward >> its IP packets to the default gateway (border router) of the LLN = subnet. This way >> packets can travel between LLN subnets using normal routing with = long-term stable >> ULA addresses. We need the stable addresses for control-style = applications in LLNs. >>=20 >> Obviously it requires a routing protocol in the (homenet) LAN but are = there other issues? >=20 > It doesn't just require a routing protocol; it also requires a routing = policy > that knows which routers have to block the ULAs (plural). That seems a = lot > more complex that a rule that says only a border router originates and = delegates > a ULA prefix, because that border router would also know to block the > prefix across the border. So we need to determine what the homenet arch text will say on this.=20 I think the assumption so far has been that, as per PD8 in = draft-ietf-homenet-arch-02,=20 one router would be elected the "master" to delegate /64 ULA prefixes = within the homenet, both to ULA-only LLNs and to links that also have a GUA prefix. = If there's=20 an assumption an LLN router will not support that, and instead generate = its own /48=20 ULA, we need to talk about that, or any other scenario that will lead to = multiple /48 ULAs=20 in a single homenet site. The arch text currently says that ULAs should be used (CN1) and that = ULAs should be=20 preferred for internal communications to GUAs (section 2.4). It doesn't = say how connections=20 from outside the homenet can be made to internal ULA-only devices. The 3484-bis text has changed the default ULA preference to protect = against ULA leakage, so if you now want ULAs preferred you need to somehow inject the = specific site /48 ULA being used with high precedence into the policy table (and as also = pointed out here if your=20 site is using less than a /48, you should also have some way to learn = what the site prefix=20 length is). In the homenet case is that injection achieved on receipt of = an RA, or would it=20 require the proposed DHCPv6 option to be used (which may not be widely = implemented=20 for some time, and the DHCPv6 server still needs to learn the ULA to put = in the option)?=20 On the one hand homenet is saying "we'd prefer to use ULAs by default = without needing some magic to achieve it" while 6man is saying "we need to protect = against ULA leakage,=20 so if you want to prefer ULA for internal connection stability figure = out the magic". =20 This needs to be mapped to words for the homenet arch text. Tim >=20 > Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis > and discuss it over on v6ops. >=20 > Brian >=20 >>=20 >> Thanks, >> Anders >>>> You'll find the above logic in the current 3484bis draft. >>>>=20 >>>> -Dave >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From d.sturek@att.net Wed Mar 21 05:25:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC8821F8617 for ; Wed, 21 Mar 2012 05:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai-8VqrpuETf for ; Wed, 21 Mar 2012 05:25:12 -0700 (PDT) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with SMTP id 7C15521F860D for ; Wed, 21 Mar 2012 05:25:11 -0700 (PDT) Received: from [98.139.215.142] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 Received: from [68.142.200.226] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 Received: from [66.94.237.105] by t7.bullet.mud.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 Received: from [127.0.0.1] by omp1010.access.mail.mud.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 X-Yahoo-Newman-Id: 169536.329.bm@omp1010.access.mail.mud.yahoo.com Received: (qmail 35076 invoked from network); 21 Mar 2012 12:25:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1332332708; bh=mjY9BrCMTYTSJpsfwDlbOVVC/JKH0bYL8c3rayzfqxk=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=FeMdTyxF/eK5bVCUXIR3/46PQo+M2/MIBr1mXkjMznoDdnHdiRwTHC11hF88s+GyU7PbKfulAVwWsAhaGIjWbP83L/34i/f57nMe7vEnFuZulMgA89+Vpl6TQw2+rBBgUVWJDNVuBSKrnioFWQ6Yn8SYFF2S87P08ywlvygYru0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: adGvrmIVM1n2jKNXQTMb6KZywrB8DRd8CRXDuqJbTiwlZjX x_70IDUQUbEJo32BbXaMXk_VHvFpzalwihCImdC3GZmXwgHcBZTT9uCnECIW aLzaJb6149_nxCEGKyXQBaFY3LA00_aCAnXNoF9A3E0xaOya_QTWlK55muLx R6bxPU7xMwBF7C5cuR1tFdub6BQnjFqi8qEeTYtAlkVWQj2WdmMIcFh_SBeB DFyIFN9gEkSKGtA11Oid4.XWAHXo6xNz.2meb2mRYHHs7y5JkpxbMCveJPaz aU8DxISadgsVyNhJ_M3H1P.yBVGWj3X.XJysr0HzajST.2FmWOCi8DMgTJ3N hrm25kbpMRml.G1X2OHX9..fwZLODcBD5UOHH362Q_A1hM1huKzUieyY.MuP TiZjO5XuhGUxukc0OYLBymTQ_M.iDIw1VzPG5 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.0.0.234] (d.sturek@12.201.251.253 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Mar 2012 05:25:07 -0700 PDT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 21 Mar 2012 05:24:55 -0700 Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] From: Don Sturek To: Tim Chown , 6man , "homenet@ietf.org Group" Message-ID: Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:25:12 -0000 Hi Tim, One more consideration: In the home, it is possible that multiple independent subnets could be combined, each with their own ULA prefix. This would happen in cases where the homeowner buys multiple silo'ed solutions (like a home automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a cross connect device that integrates these solutions. Don On 3/21/12 4:55 AM, "Tim Chown" wrote: > >On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: > >> On 2012-03-20 21:51, Anders Brandt wrote: >>> >>> It is a surprise to me that ULA addresses are not by default routable >>>within the site. >>> I can easily imagine a number of LLN border routers which autonomously >>>allocate >>> different ULA prefixes for use within their individual LLN subnets. >> >> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they >> cover an entire enterprise or home network, but not if they cover a >>subset. >> >>> Meeting a ULA address outside the local prefix will cause the LLN node >>>to forward >>> its IP packets to the default gateway (border router) of the LLN >>>subnet. This way >>> packets can travel between LLN subnets using normal routing with >>>long-term stable >>> ULA addresses. We need the stable addresses for control-style >>>applications in LLNs. >>> >>> Obviously it requires a routing protocol in the (homenet) LAN but are >>>there other issues? >> >> It doesn't just require a routing protocol; it also requires a routing >>policy >> that knows which routers have to block the ULAs (plural). That seems a >>lot >> more complex that a rule that says only a border router originates and >>delegates >> a ULA prefix, because that border router would also know to block the >> prefix across the border. > >So we need to determine what the homenet arch text will say on this. > >I think the assumption so far has been that, as per PD8 in >draft-ietf-homenet-arch-02, >one router would be elected the "master" to delegate /64 ULA prefixes >within the >homenet, both to ULA-only LLNs and to links that also have a GUA prefix. >If there's >an assumption an LLN router will not support that, and instead generate >its own /48 >ULA, we need to talk about that, or any other scenario that will lead to >multiple /48 ULAs >in a single homenet site. > >The arch text currently says that ULAs should be used (CN1) and that ULAs >should be >preferred for internal communications to GUAs (section 2.4). It doesn't >say how connections >from outside the homenet can be made to internal ULA-only devices. > >The 3484-bis text has changed the default ULA preference to protect >against ULA leakage, >so if you now want ULAs preferred you need to somehow inject the specific >site /48 ULA >being used with high precedence into the policy table (and as also >pointed out here if your >site is using less than a /48, you should also have some way to learn >what the site prefix >length is). In the homenet case is that injection achieved on receipt of >an RA, or would it >require the proposed DHCPv6 option to be used (which may not be widely >implemented >for some time, and the DHCPv6 server still needs to learn the ULA to put >in the option)? > >On the one hand homenet is saying "we'd prefer to use ULAs by default >without needing >some magic to achieve it" while 6man is saying "we need to protect >against ULA leakage, >so if you want to prefer ULA for internal connection stability figure out >the magic". > >This needs to be mapped to words for the homenet arch text. > >Tim > >> >> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis >> and discuss it over on v6ops. >> >> Brian >> >>> >>> Thanks, >>> Anders >>>>> You'll find the above logic in the current 3484bis draft. >>>>> >>>>> -Dave >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From ietfc@btconnect.com Wed Mar 21 05:37:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1421F85A1 for ; Wed, 21 Mar 2012 05:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EagyeowfstIU for ; Wed, 21 Mar 2012 05:37:20 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2921F859F for ; Wed, 21 Mar 2012 05:37:19 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr06.btconnect.com with SMTP id GYP34341; Wed, 21 Mar 2012 12:37:01 +0000 (GMT) Message-ID: <007101cd0756$cb990f00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Mark Andrews" References: .com> <9B57C850BB5 3634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com><00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu><20120319141402.DAECF1EAC06D@drugs.dv.isc.org><01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu><20120319220801.964E91EAD466@drugs.dv.isc.org><20120319222906.843801EAD52B@drugs.dv.isc.org><006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu> <20120320110416.580611EB7252@drugs.dv.isc.org> Subject: IPv6 zone index was Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Date: Wed, 21 Mar 2012 12:35:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F69CB6D.00BB, actions=TAG X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2012.3.21.121218:17:8.317, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __FRAUD_MONEY_VALUE, __CP_URI_IN_BODY, __STOCK_PHRASE_7, __OEM_PRICE, __HAS_HTML, HTML_NO_HTTP, BODY_SIZE_1300_1399, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, __FRAUD_MONEY, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020D.4F69CB6E.00AF,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: 'Bob Hinden' , 'Brian Haberman' , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:37:21 -0000 ----- Original Message ----- From: "Mark Andrews" To: "Marc Lampo" Cc: ; "'Brian Haberman'" ; "'Bob Hinden'" ; "'Arifumi Matsumoto'" ; "'Dave Thaler'" Sent: Tuesday, March 20, 2012 12:04 PM > > In message <006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu>, "Marc Lampo" writes: > > > > I understand what you are writing, but is this the right way ? > > Yes. It was always intended that this be updatable network wide. > > http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 > > > The address selection table is, as far as I understand, > > statically defined - not dynamically configurable (SLAAC or DHCPv6). > > So, the suggestion is to adapt the table on every node of > > the organisation. > > Yep. DHCP does this sort of thing very well. I note that the I-D referenced above allocates 32 bit for the zone index which will suit a few implementations and not suit many, unless the intention is to use the SNMP ifIndex and map from that to the string used by such implementations. Hopefully, 6man will be invited to review this as and when it progresses, otherwise it will have to be at IETF Last Call:-( Tom Petch From Anders_Brandt@sigmadesigns.com Wed Mar 21 05:13:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0B921F86A5; Wed, 21 Mar 2012 05:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z5kHnEx8PP3; Wed, 21 Mar 2012 05:13:28 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD321F86A1; Wed, 21 Mar 2012 05:13:27 -0700 (PDT) From: Anders Brandt To: Brian E Carpenter Subject: RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkAgADEt4CAAQHN4A== Date: Wed, 21 Mar 2012 12:13:19 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC1B71@cph-ex1> References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-e x1> <4F68F5E5.7060901@gmail.com> In-Reply-To: <4F68F5E5.7060901@gmail.com> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-Mailman-Approved-At: Wed, 21 Mar 2012 05:41:43 -0700 Cc: 6man , "homenet@ietf.org Group" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:13:28 -0000 QnJpYW4gQ2FycGVudGVyIHdyaXRlczoNCj4gT24gMjAxMi0wMy0yMCAyMTo1MSwgQW5kZXJzIEJy YW5kdCB3cm90ZToNCj4gPiBLZXJyeSBMeW5uIHdyaXRlczoNCj4gPg0KPiA+PiBPbiBTYXQsIE1h ciAxNywgMjAxMiBhdCAyOjIyIEFNLCBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29t Pg0KPiA+PiB3cm90ZToNCj4gPj4+IEJyaWFuIENhcnBlbnRlciB3cml0ZXM6DQo+ID4+PiBbLi4u XQ0KPiA+DQo+ID4gSXQgaXMgYSBzdXJwcmlzZSB0byBtZSB0aGF0IFVMQSBhZGRyZXNzZXMgYXJl IG5vdCBieSBkZWZhdWx0IHJvdXRhYmxlIHdpdGhpbg0KPiB0aGUgc2l0ZS4NCj4gPiBJIGNhbiBl YXNpbHkgaW1hZ2luZSBhIG51bWJlciBvZiBMTE4gYm9yZGVyIHJvdXRlcnMgd2hpY2ggYXV0b25v bW91c2x5DQo+ID4gYWxsb2NhdGUgZGlmZmVyZW50IFVMQSBwcmVmaXhlcyBmb3IgdXNlIHdpdGhp biB0aGVpciBpbmRpdmlkdWFsIExMTiBzdWJuZXRzLg0KPiANCj4gSU1ITyB0aGF0IHNob3VsZCBi ZSBhIE5PVCBSRUNPTU1FTkRFRCBiZWhhdmlvdXIuIFVMQXMgbWFrZSBzZW5zZSBpZg0KPiB0aGV5 IGNvdmVyIGFuIGVudGlyZSBlbnRlcnByaXNlIG9yIGhvbWUgbmV0d29yaywgYnV0IG5vdCBpZiB0 aGV5IGNvdmVyIGENCj4gc3Vic2V0Lg0KDQpJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUgYXJndW1l bnRzIGZvciB0aGF0IG9waW5pb24/DQoNClRvIG1lIHN1Ym5ldCBVTEFzIG1ha2UgYSBsb3Qgc2Vu c2UgdG8gbWUgaW4gZW52aXJvbm1lbnRzIHdoZXJlDQoxMDAlIGF1dG9jb25maWd1cmF0aW9uIGlz IHJlcXVpcmVkIHdoaWxlIHJlbWFpbmluZyByb2J1c3QgdG93YXJkcw0KY2hhbmdpbmcgSVNQIHBy ZWZpeGVzIGFuZCBiYWNrYm9uZSB0b3BvbG9naWVzLg0KDQpUaGUgYmFzaWMgcHJlbWlzZSBmb3Ig dGhlIGF2ZXJhZ2UgaG9tZW5ldCB1c2VyIGlzIHRoYXQgaGUvc2hlIGhhcw0KYWJzb2x1dGVseSBu byBjbHVlIHdoYXQgZ29lcyBvbiBpbiB0aGUgbmV0d29yay4gQW5kIHNob3VsZCBub3QgaGF2ZS4N CiANCj4gPiBNZWV0aW5nIGEgVUxBIGFkZHJlc3Mgb3V0c2lkZSB0aGUgbG9jYWwgcHJlZml4IHdp bGwgY2F1c2UgdGhlIExMTiBub2RlDQo+ID4gdG8gZm9yd2FyZCBpdHMgSVAgcGFja2V0cyB0byB0 aGUgZGVmYXVsdCBnYXRld2F5IChib3JkZXIgcm91dGVyKSBvZg0KPiA+IHRoZSBMTE4gc3VibmV0 LiBUaGlzIHdheSBwYWNrZXRzIGNhbiB0cmF2ZWwgYmV0d2VlbiBMTE4gc3VibmV0cyB1c2luZw0K PiA+IG5vcm1hbCByb3V0aW5nIHdpdGggbG9uZy10ZXJtIHN0YWJsZSBVTEEgYWRkcmVzc2VzLiBX ZSBuZWVkIHRoZSBzdGFibGUNCj4gYWRkcmVzc2VzIGZvciBjb250cm9sLXN0eWxlIGFwcGxpY2F0 aW9ucyBpbiBMTE5zLg0KPiA+DQo+ID4gT2J2aW91c2x5IGl0IHJlcXVpcmVzIGEgcm91dGluZyBw cm90b2NvbCBpbiB0aGUgKGhvbWVuZXQpIExBTiBidXQgYXJlDQo+IHRoZXJlIG90aGVyIGlzc3Vl cz8NCj4gDQo+IEl0IGRvZXNuJ3QganVzdCByZXF1aXJlIGEgcm91dGluZyBwcm90b2NvbDsgaXQg YWxzbyByZXF1aXJlcyBhIHJvdXRpbmcgcG9saWN5DQo+IHRoYXQga25vd3Mgd2hpY2ggcm91dGVy cyBoYXZlIHRvIGJsb2NrIHRoZSBVTEFzIChwbHVyYWwpLiBUaGF0IHNlZW1zIGEgbG90DQo+IG1v cmUgY29tcGxleCB0aGF0IGEgcnVsZSB0aGF0IHNheXMgb25seSBhIGJvcmRlciByb3V0ZXIgb3Jp Z2luYXRlcyBhbmQNCj4gZGVsZWdhdGVzIGEgVUxBIHByZWZpeCwgYmVjYXVzZSB0aGF0IGJvcmRl ciByb3V0ZXIgd291bGQgYWxzbyBrbm93IHRvIGJsb2NrDQo+IHRoZSBwcmVmaXggYWNyb3NzIHRo ZSBib3JkZXIuDQoNClRoaXMgIm1hc3RlciIgcm91dGVyIG1heSBiZSBhZGRlZCB0byB0aGUgaG9t ZW5ldCBhdCBhIGxhdGVyIHN0YWdlIC0gZS5nLiB3aGVuDQpjaGFuZ2luZyBJU1AuIE15IGxpZ2h0 c3dpdGNoLXRvLWxhbXAgYWRkcmVzcyBhc3NvY2lhdGlvbnMgYmV0d2VlbiB0d28gc3VibmV0cw0K aGF2ZSB0byBzdXJ2aXZlIHN1Y2ggY2hhbmdlcy4NCkkgY2Fubm90IHJlbHkgb24gYW55IHByZWZp eCBkZWxlZ2F0ZWQgZnJvbSBhbiB1bnJlbGlhYmxlIHNvdXJjZSBzdWNoIGFzIGFuIElTUCByb3V0 ZXIuDQoNCkkgY2Fubm90IHJlbHkgb24gbXkgdXNlciBoYW5kLWNhcnJ5aW5nIGEgVUxBIHByZWZp eCBkZWxlZ2F0ZWQgYnkgdGhlIG9sZCBJU1ANCnJvdXRlciBpbnRvIHRoZSBuZXcgSVNQIHJvdXRl ci4gVGhpcyBJU1Agcm91dGVyIG1heSBldmVuIGJlIGJsb2NrZWQgZm9yIHVzZXINCm1hbmlwdWxh dGlvbi4gQW5kIGFnYWluLCBteSB1c2VyIGhhcyBubyBxdWFsaWZpY2F0aW9ucyBmb3IgZG9pbmcg dGhpcy4NCg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgaG9tZW5ldCBDRVIgaXMgdGhhdCBpdCBi eSBkZWZhdWx0IHdpbGwgZmlsdGVyIGFueQ0KVUxBIGFkZHJlc3NlZCB0cmFmZmljICg/KS4gVGh1 cywgbm8gVUxBcyBsZWF2ZSBvciBlbnRlciBpbnRvIHRoZSBJbnRlcm5ldC4NCg0KPiBBbnl3YXkg LSBtYXliZSB5b3Ugc2hvdWxkIGxvb2sgYXQgZHJhZnQtbGl1LXY2b3BzLXVsYS11c2FnZS1hbmFs eXNpcw0KPiBhbmQgZGlzY3VzcyBpdCBvdmVyIG9uIHY2b3BzLg0KDQpJIGFtIGZhbWlsaWFyIHdp dGggQmluZyBMaXUncyBkcmFmdC4gQWN0dWFsbHkgSSBzZWUgbm8gb2JqZWN0aW9ucyBhZ2FpbnN0 DQptdWx0aXBsZSBVTEEgcHJlZml4ZXMgaW4gaG9tZW5ldHMgaW4gdGhpcyBkcmFmdC4NCkNvbnRy YXJ5LCB0aGUgZHJhZnQgc2F5cyANCg0KPHF1b3RlPmhvc3RzIGFzc2lnbmVkIHdpdGggVUxBIG1h eSBvY2Nhc2lvbmFsbHkgYmUgbWVyZ2VkIGludG8gb25lDQogIG5ldHdvcms8L3F1b3RlPi4uLi4N CjxxdW90ZT5tYWtlIG1lcmdpbmcgb2YgbmV0d29ya3Mgc2ltcGxlIGFuZA0KICB3aXRob3V0IHRo ZSBuZWVkIHRvIHJlbnVtYmVyaW5nIG92ZXJsYXBwaW5nIElQIGFkZHJlc3Mgc3BhY2UuIDwvcXVv dGU+DQoNCkkgYWdyZWUgaW4gdGhpcyB0ZXh0Lg0KDQpJIGFncmVlIHRoYXQgdGhlIGRpc2N1c3Np b24gaXMgYWxzbyBpbnRlcmVzdGluZyB0byB2Nm9wcyBidXQgSSB3b3VsZCBsaWtlIHRvDQpjb252 ZXJnZSBvbiB0aGUgYXBwbGljYWJpbGl0eSB3aXRoaW4gaG9tZW5ldHMgYmVmb3JlICJ0YWtpbmcg aXQgdG8gdGhlIG5leHQgbGV2ZWwiLg0KDQpBbmRlcnMNCiANCj4gICAgIEJyaWFuDQo+IA0KPiA+ DQo+ID4gVGhhbmtzLA0KPiA+ICAgQW5kZXJzDQo+ID4+PiBZb3UnbGwgZmluZCB0aGUgYWJvdmUg bG9naWMgaW4gdGhlIGN1cnJlbnQgMzQ4NGJpcyBkcmFmdC4NCj4gPj4+DQo+ID4+PiAtRGF2ZQ0K PiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdCBpcHY2QGlldGYub3JnIEFkbWluaXN0cmF0aXZlDQo+ID4+PiBSZXF1ZXN0czogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ PiBob21lbmV0IG1haWxpbmcgbGlzdA0KPiA+PiBob21lbmV0QGlldGYub3JnDQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldA0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gaG9tZW5ldCBtYWlsaW5n IGxpc3QNCj4gPiBob21lbmV0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ob21lbmV0DQo+ID4NCg== From Anders_Brandt@sigmadesigns.com Wed Mar 21 05:19:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5336D21F84CD; Wed, 21 Mar 2012 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muemSxaGI02d; Wed, 21 Mar 2012 05:19:10 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7114321F84B4; Wed, 21 Mar 2012 05:19:10 -0700 (PDT) From: Anders Brandt To: Tim Chown , 6man , "homenet@ietf.org Group" Subject: RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkAgADEt4CAAPLVgIAAFlFA Date: Wed, 21 Mar 2012 12:18:36 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC1B91@cph-ex1> References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-e! x 1> <4F68F5E5.7060901@gmail.com> <031E46EC-73ED-44A4-B966-B249DCAD367C@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-Mailman-Approved-At: Wed, 21 Mar 2012 05:41:43 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:19:11 -0000 Tim Chown wrote: >Wednesday, March 21, 2012 12:55 > On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: >=20 > > On 2012-03-20 21:51, Anders Brandt wrote: > >> > >> It is a surprise to me that ULA addresses are not by default routable > within the site. > >> I can easily imagine a number of LLN border routers which > >> autonomously allocate different ULA prefixes for use within their > individual LLN subnets. > > > > IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if > > they cover an entire enterprise or home network, but not if they cover = a > subset. > > > >> Meeting a ULA address outside the local prefix will cause the LLN > >> node to forward its IP packets to the default gateway (border router) > >> of the LLN subnet. This way packets can travel between LLN subnets > >> using normal routing with long-term stable ULA addresses. We need the > stable addresses for control-style applications in LLNs. > >> > >> Obviously it requires a routing protocol in the (homenet) LAN but are > there other issues? > > > > It doesn't just require a routing protocol; it also requires a routing > > policy that knows which routers have to block the ULAs (plural). That > > seems a lot more complex that a rule that says only a border router > > originates and delegates a ULA prefix, because that border router > > would also know to block the prefix across the border. >=20 > So we need to determine what the homenet arch text will say on this. >=20 > I think the assumption so far has been that, as per PD8 in draft-ietf- > homenet-arch-02, one router would be elected the "master" to delegate /64 > ULA prefixes within the homenet, both to ULA-only LLNs and to links that > also have a GUA prefix. If there's an assumption an LLN router will not > support that, and instead generate its own /48 ULA, we need to talk about > that, or any other scenario that will lead to multiple /48 ULAs in a sing= le > homenet site. >=20 > The arch text currently says that ULAs should be used (CN1) and that ULAs > should be preferred for internal communications to GUAs (section 2.4). I= t > doesn't say how connections from outside the homenet can be made to > internal ULA-only devices. Is it obvious that you want to do that? I thought the entire ULA discussion was homenet internal only? Access from the outside will require tunneling or an additional global address, I guess? - Anders > The 3484-bis text has changed the default ULA preference to protect again= st > ULA leakage, so if you now want ULAs preferred you need to somehow > inject the specific site /48 ULA being used with high precedence into the > policy table (and as also pointed out here if your site is using less tha= n a /48, > you should also have some way to learn what the site prefix length is). I= n > the homenet case is that injection achieved on receipt of an RA, or would= it > require the proposed DHCPv6 option to be used (which may not be widely > implemented for some time, and the DHCPv6 server still needs to learn the > ULA to put in the option)? >=20 > On the one hand homenet is saying "we'd prefer to use ULAs by default > without needing some magic to achieve it" while 6man is saying "we need > to protect against ULA leakage, so if you want to prefer ULA for internal > connection stability figure out the magic". >=20 > This needs to be mapped to words for the homenet arch text. >=20 > Tim >=20 > > > > Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis > > and discuss it over on v6ops. > > > > Brian > > > >> > >> Thanks, > >> Anders > >>>> You'll find the above logic in the current 3484bis draft. > >>>> > >>>> -Dave > >>>> ------------------------------------------------------------------- > >>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> ------------------------------------------------------------------- > >>>> - > >>> _______________________________________________ > >>> homenet mailing list > >>> homenet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/homenet > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > >> > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Wed Mar 21 12:29:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1921E80AC for ; Wed, 21 Mar 2012 12:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRnwatEdlcFM for ; Wed, 21 Mar 2012 12:29:04 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7B421E805A for ; Wed, 21 Mar 2012 12:29:04 -0700 (PDT) Received: by eeke51 with SMTP id e51so475409eek.31 for ; Wed, 21 Mar 2012 12:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Gv+iKejHlgjXxshN4RUbfhVfVW7aLRSvWcViKuzUVTQ=; b=A8amG3SCVA/TjRzC1J/mYBcebjrVr6o1Pt9lYmaf/xvozUWF9ZXh4fo/cvuw7N1+FG iKi77QKnWRdNlc/drMqm2SvMyE10Jxf34aqPIrRnNFgtEJCyASp3bgxib2diyNJ703Uc jkKVZP0IMLh+tOyIaKt9jbVEuCjha1ab8hnEnTUpwKmrn5F2shBv08aEfpteOULwz+Hz u1tfnEdCcU037+lquEzVrkKfgvIqYCe/o2jmJvcyXda14qF/lCWYjhssIGfgBfbLsWV/ dG1NrLuDzvVguuMhGmXYZSt+Ts3y7CY4U6NwMwoiFD0aVSNifVZ5Y4o/p53YdZfUz8vu Bbuw== Received: by 10.213.13.215 with SMTP id d23mr415244eba.74.1332358143705; Wed, 21 Mar 2012 12:29:03 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id m42sm9203369eef.0.2012.03.21.12.28.59 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:29:02 -0700 (PDT) Message-ID: <4F6A2BF2.8010400@gmail.com> Date: Thu, 22 Mar 2012 08:28:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "t.petch" Subject: Re: IPv6 zone index was Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: .com> <9B57C850BB5 3634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com><00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu><20120319141402.DAECF1EAC06D@drugs.dv.isc.org><01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu><20120319220801.964E91EAD466@drugs.dv.isc.org><20120319222906.843801EAD52B@drugs.dv.isc.org><006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu> <20120320110416.580611EB7252@drugs.dv.isc.org> <007101cd0756$cb990f00$4001a8c0@gateway.2wire.net> In-Reply-To: <007101cd0756$cb990f00$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Brian Haberman' , 'Bob Hinden' , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:29:05 -0000 On 2012-03-22 00:35, t.petch wrote: > ----- Original Message ----- > From: "Mark Andrews" > To: "Marc Lampo" > Cc: ; "'Brian Haberman'" ; "'Bob > Hinden'" ; "'Arifumi Matsumoto'" ; "'Dave > Thaler'" > Sent: Tuesday, March 20, 2012 12:04 PM >> In message <006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu>, "Marc Lampo" > writes: >>> I understand what you are writing, but is this the right way ? >> Yes. It was always intended that this be updatable network wide. >> >> http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 >> >>> The address selection table is, as far as I understand, >>> statically defined - not dynamically configurable (SLAAC or DHCPv6). >>> So, the suggestion is to adapt the table on every node of >>> the organisation. >> Yep. DHCP does this sort of thing very well. > > I note that the I-D referenced above allocates 32 bit for the zone index which > will suit a few implementations and not suit many, unless the intention is to > use > the SNMP ifIndex and map from that to the string used by such implementations. Of course that is how it works. The socket API uses a uint32_t for the zone index; only the user interface uses a string. It seems appropriate to use the uint32_t also in the MIB and the DHCP option. We already covered this on another thread: http://www.ietf.org/mail-archive/web/ipv6/current/msg15424.html I agree this should be made very clear in the text. Brian > > Hopefully, 6man will be invited to review this as and when it progresses, > otherwise it will have to be at IETF Last Call:-( > > Tom Petch > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Wed Mar 21 12:35:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E85721E80A9; Wed, 21 Mar 2012 12:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1zYvnFmpipN; Wed, 21 Mar 2012 12:35:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C44521E8092; Wed, 21 Mar 2012 12:35:41 -0700 (PDT) Received: by eeke51 with SMTP id e51so476723eek.31 for ; Wed, 21 Mar 2012 12:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f3exOZNW9KF5ruyhsYTnE6Y7FVk6+R4WwtbcCrNs35k=; b=GJhH1pPak7Z6LH4vcc8q2eJdXyzPvF7yzakTzs1U9QRYuDAoZop9ZQTusZMcjAVueR pb2E1RwtSZaerPZByV2tQUDrPWshCR3VBSQEh7CjuOaRO2+xxKxj+2OJfdi4/3nYYuuJ 08fKyQgrZHt/QBe7Mbq7GGKjXb96uIKCwz8bEBhOtsjBTXpI2uiTDNUun3OtM24ICi/P E9eEbKOmQPJRKRlnSi4xpud0nkdQfbhwWNFL3eB09Net9q0cdtBPCnX+YfTBkRuFRQwr BDEXroSDUL6LwLoZ59wTamv3qAqawhnxr6WtXTZHLdc68mETtcdC8icD7EayFRnY8tyI wtiA== Received: by 10.14.136.16 with SMTP id v16mr696553eei.126.1332358540487; Wed, 21 Mar 2012 12:35:40 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x8sm9192394eea.10.2012.03.21.12.35.36 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:35:39 -0700 (PDT) Message-ID: <4F6A2D7F.1030901@gmail.com> Date: Thu, 22 Mar 2012 08:35:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Don Sturek Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , 6man , "homenet@ietf.org Group" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:35:42 -0000 Don, On 2012-03-22 01:24, Don Sturek wrote: > Hi Tim, > > One more consideration: > In the home, it is possible that multiple independent subnets could be > combined, each with their own ULA prefix. This would happen in cases > where the homeowner buys multiple silo'ed solutions (like a home > automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a > cross connect device that integrates these solutions. Yes, anything could happen and probably will. So while a single ULA per site is the simple and obvious case (and I don't have any argument for Anders except KISS), there *will* be cases where several ULAs pop up, and I think resolving routing issues in that situation is likely to be troublesome. We can't resolve it as we do for enterprise networks by saying that the network's manager will manually configure appropriate routes. Brian > Don > > > > > > On 3/21/12 4:55 AM, "Tim Chown" wrote: > >> On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: >> >>> On 2012-03-20 21:51, Anders Brandt wrote: >>>> It is a surprise to me that ULA addresses are not by default routable >>>> within the site. >>>> I can easily imagine a number of LLN border routers which autonomously >>>> allocate >>>> different ULA prefixes for use within their individual LLN subnets. >>> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they >>> cover an entire enterprise or home network, but not if they cover a >>> subset. >>> >>>> Meeting a ULA address outside the local prefix will cause the LLN node >>>> to forward >>>> its IP packets to the default gateway (border router) of the LLN >>>> subnet. This way >>>> packets can travel between LLN subnets using normal routing with >>>> long-term stable >>>> ULA addresses. We need the stable addresses for control-style >>>> applications in LLNs. >>>> >>>> Obviously it requires a routing protocol in the (homenet) LAN but are >>>> there other issues? >>> It doesn't just require a routing protocol; it also requires a routing >>> policy >>> that knows which routers have to block the ULAs (plural). That seems a >>> lot >>> more complex that a rule that says only a border router originates and >>> delegates >>> a ULA prefix, because that border router would also know to block the >>> prefix across the border. >> So we need to determine what the homenet arch text will say on this. >> >> I think the assumption so far has been that, as per PD8 in >> draft-ietf-homenet-arch-02, >> one router would be elected the "master" to delegate /64 ULA prefixes >> within the >> homenet, both to ULA-only LLNs and to links that also have a GUA prefix. >> If there's >> an assumption an LLN router will not support that, and instead generate >> its own /48 >> ULA, we need to talk about that, or any other scenario that will lead to >> multiple /48 ULAs >> in a single homenet site. >> >> The arch text currently says that ULAs should be used (CN1) and that ULAs >> should be >> preferred for internal communications to GUAs (section 2.4). It doesn't >> say how connections >>from outside the homenet can be made to internal ULA-only devices. >> The 3484-bis text has changed the default ULA preference to protect >> against ULA leakage, >> so if you now want ULAs preferred you need to somehow inject the specific >> site /48 ULA >> being used with high precedence into the policy table (and as also >> pointed out here if your >> site is using less than a /48, you should also have some way to learn >> what the site prefix >> length is). In the homenet case is that injection achieved on receipt of >> an RA, or would it >> require the proposed DHCPv6 option to be used (which may not be widely >> implemented >> for some time, and the DHCPv6 server still needs to learn the ULA to put >> in the option)? >> >> On the one hand homenet is saying "we'd prefer to use ULAs by default >> without needing >> some magic to achieve it" while 6man is saying "we need to protect >> against ULA leakage, >> so if you want to prefer ULA for internal connection stability figure out >> the magic". >> >> This needs to be mapped to words for the homenet arch text. >> >> Tim >> >>> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis >>> and discuss it over on v6ops. >>> >>> Brian >>> >>>> Thanks, >>>> Anders >>>>>> You'll find the above logic in the current 3484bis draft. >>>>>> >>>>>> -Dave >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> homenet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/homenet >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From arifumi@nttv6.net Thu Mar 22 01:23:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23C21F860F for ; Thu, 22 Mar 2012 01:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VsUJrEvAk8E for ; Thu, 22 Mar 2012 01:23:50 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9F53B21F8611 for ; Thu, 22 Mar 2012 01:23:50 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q2M8OOYd021583; Thu, 22 Mar 2012 17:24:24 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: IPv6 zone index was Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <4F6A2BF2.8010400@gmail.com> Date: Thu, 22 Mar 2012 17:22:45 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <768E273B-0DAC-4589-B780-D684A0B50CEE@nttv6.net> References: .com> <9B57C850BB5 3634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com><00f801cd05a2$abfce190$03f6a4b0$@lampo@eurid.eu><20120319141402.DAECF1EAC06D@drugs.dv.isc.org><01f401cd05dc$20914df0$61b3e9d0$@lampo@eurid.eu><20120319220801.964E91EAD466@drugs.dv.isc.org><20120319222906.843801EAD52B@drugs.dv.isc.org><006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu> <20120320110416.580611EB7252@drugs.dv.isc.org> <007101cd0756$cb990f00$4001a8c0@gateway.2wire.net> <4F6A2BF2.8010400@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) Cc: 'Bob Hinden' , 'Brian Haberman' , ipv6@ietf.org, "t.petch" , Mark Andrews X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 08:23:51 -0000 Hi, On 2012/03/22, at 4:28, Brian E Carpenter wrote: > On 2012-03-22 00:35, t.petch wrote: >> ----- Original Message ----- >> From: "Mark Andrews" >> To: "Marc Lampo" >> Cc: ; "'Brian Haberman'" ; = "'Bob >> Hinden'" ; "'Arifumi Matsumoto'" = ; "'Dave >> Thaler'" >> Sent: Tuesday, March 20, 2012 12:04 PM >>> In message <006e01cd0668$898f0770$9cad1650$@lampo@eurid.eu>, "Marc = Lampo" >> writes: >>>> I understand what you are writing, but is this the right way ? >>> Yes. It was always intended that this be updatable network wide. >>>=20 >>> http://tools.ietf.org/html/draft-fujisaki-dhc-addr-select-opt-09 >>>=20 >>>> The address selection table is, as far as I understand, >>>> statically defined - not dynamically configurable (SLAAC or = DHCPv6). >>>> So, the suggestion is to adapt the table on every node of >>>> the organisation. >>> Yep. DHCP does this sort of thing very well. >>=20 >> I note that the I-D referenced above allocates 32 bit for the zone = index which >> will suit a few implementations and not suit many, unless the = intention is to >> use >> the SNMP ifIndex and map from that to the string used by such = implementations. >=20 > Of course that is how it works. The socket API uses a uint32_t for > the zone index; only the user interface uses a string. It seems = appropriate > to use the uint32_t also in the MIB and the DHCP option. >=20 > We already covered this on another thread: > http://www.ietf.org/mail-archive/web/ipv6/current/msg15424.html >=20 > I agree this should be made very clear in the text. Brian, thank you for answering this question. BTW, this draft was now adopted as 6man wg item, and WGLCed by dhcwg. The WGLC in 6man about this draft should happen soon after 3484bis discussion is settled. http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-03 Thanks, >=20 > Brian >=20 >>=20 >> Hopefully, 6man will be invited to review this as and when it = progresses, >> otherwise it will have to be at IETF Last Call:-( >>=20 >> Tom Petch >> >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From v6ops@globis.net Thu Mar 22 01:29:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910F121F8613; Thu, 22 Mar 2012 01:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=-2.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, MANGLED_PAIN=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B3mtXNr6kxn; Thu, 22 Mar 2012 01:29:31 -0700 (PDT) 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 6A90221F8604; Thu, 22 Mar 2012 01:29:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 226428700EA; Thu, 22 Mar 2012 09:29:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yROnIobVxZ3; Thu, 22 Mar 2012 09:29:16 +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 2068C8700E7; Thu, 22 Mar 2012 09:29:16 +0100 (CET) Message-ID: <4F6AE2DB.2000007@globis.net> Date: Thu, 22 Mar 2012 09:29:15 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] References: <4F6A2D7F.1030901@gmail.com> In-Reply-To: <4F6A2D7F.1030901@gmail.com> Content-Type: multipart/alternative; boundary="------------070607050602030603040503" Cc: 6man , Tim Chown , "homenet@ietf.org Group" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 08:29:32 -0000 This is a multi-part message in MIME format. --------------070607050602030603040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 Firstly, I have been lurking on the 3484-revise discussion in 6man for a long time. I agree with Brian's proposal: [source & destination of a /48 ULA prefix match => prefer over 2000:/3 space. Otherwise don't (by default).] Secondly, I think Homenet still has a lot of work to do, especially due to the autoconfig requirements. Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + invariant addresses is likely going to be tough, if not downright impossible. So why do we think we really need concurrent ULA+PA in Homenet as a base requirement? I'm not entirely convinced yet. One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks." I don't see how "complete time-invariance of addressing" is achievable together with autoconfig, even if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywhere. We've been down that rathole before. Site-local has been deprecated in RFC3879. And realistically speaking, any time someone replaces or adds or re-plugs any router hardware, the LAN's /64 prefix will change when using autoconfig. I think it would be useful for the Homenet WG to propose a scheme for sensor networks to be able to maintain simple peerings despite the presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it would seem to me that a peering solution should use something that is long-term invariant as an identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invariant identifier could be automatically registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to the current IPv6 address and then verify the peering using their own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would trigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specific (and has to be solved anyway even with fixed addresses). I have an asterisk hardware phone that does something similar to this, so it can't require much code. A reason concurrent ULA+PA seems to be required was that "intra-homenet communication should survive a long term ISP outage, and must be able to be established without any ISP connection present." The first linkage would appear to be when ISP PA-derived prefixes within Homenet timeout via DHCPv6 PD meaning that a long-running session based on this address would drop. That has nothing directly to do with ULA, and may have other solutions. Question: How long are ISP's setting their DHCPv6 PD timers in practice? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix might be a practical solution. How often has your ISP connection been down for say 10 days? Another solution might be for the application to reconnect using another PA-derived address (if the user has two providers). The second linkage may also have other solutions, such as only configuring a ULA prefix when no PA-derived prefixes are present. That would mean at any one time the Homenet could potentially be running either ULA or multiple PA, but not both, which completely avoids any address selection conflicts and having to redistribute new RFC3484 address selection rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems." So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements, rather than on ULA in and of itself. regards, RayH Brian E Carpenter wrote: > Don, > > On 2012-03-22 01:24, Don Sturek wrote: > >> Hi Tim, >> >> One more consideration: >> In the home, it is possible that multiple independent subnets could be >> combined, each with their own ULA prefix. This would happen in cases >> where the homeowner buys multiple silo'ed solutions (like a home >> automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a >> cross connect device that integrates these solutions. >> > > Yes, anything could happen and probably will. So while a single ULA per > site is the simple and obvious case (and I don't have any argument for > Anders except KISS), there *will* be cases where several ULAs pop > up, and I think resolving routing issues in that situation is likely > to be troublesome. We can't resolve it as we do for enterprise networks > by saying that the network's manager will manually configure appropriate > routes. > > Brian > > >> Don >> >> >> >> >> >> On 3/21/12 4:55 AM, "Tim Chown" wrote: >> >> >>> On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: >>> >>> >>>> On 2012-03-20 21:51, Anders Brandt wrote: >>>> >>>>> It is a surprise to me that ULA addresses are not by default routable >>>>> within the site. >>>>> I can easily imagine a number of LLN border routers which autonomously >>>>> allocate >>>>> different ULA prefixes for use within their individual LLN subnets. >>>>> >>>> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they >>>> cover an entire enterprise or home network, but not if they cover a >>>> subset. >>>> >>>> >>>>> Meeting a ULA address outside the local prefix will cause the LLN node >>>>> to forward >>>>> its IP packets to the default gateway (border router) of the LLN >>>>> subnet. This way >>>>> packets can travel between LLN subnets using normal routing with >>>>> long-term stable >>>>> ULA addresses. We need the stable addresses for control-style >>>>> applications in LLNs. >>>>> >>>>> Obviously it requires a routing protocol in the (homenet) LAN but are >>>>> there other issues? >>>>> >>>> It doesn't just require a routing protocol; it also requires a routing >>>> policy >>>> that knows which routers have to block the ULAs (plural). That seems a >>>> lot >>>> more complex that a rule that says only a border router originates and >>>> delegates >>>> a ULA prefix, because that border router would also know to block the >>>> prefix across the border. >>>> >>> So we need to determine what the homenet arch text will say on this. >>> >>> I think the assumption so far has been that, as per PD8 in >>> draft-ietf-homenet-arch-02, >>> one router would be elected the "master" to delegate /64 ULA prefixes >>> within the >>> homenet, both to ULA-only LLNs and to links that also have a GUA prefix. >>> If there's >>> an assumption an LLN router will not support that, and instead generate >>> its own /48 >>> ULA, we need to talk about that, or any other scenario that will lead to >>> multiple /48 ULAs >>> in a single homenet site. >>> >>> The arch text currently says that ULAs should be used (CN1) and that ULAs >>> should be >>> preferred for internal communications to GUAs (section 2.4). It doesn't >>> say how connections >>> >> >from outside the homenet can be made to internal ULA-only devices. >> >>> The 3484-bis text has changed the default ULA preference to protect >>> against ULA leakage, >>> so if you now want ULAs preferred you need to somehow inject the specific >>> site /48 ULA >>> being used with high precedence into the policy table (and as also >>> pointed out here if your >>> site is using less than a /48, you should also have some way to learn >>> what the site prefix >>> length is). In the homenet case is that injection achieved on receipt of >>> an RA, or would it >>> require the proposed DHCPv6 option to be used (which may not be widely >>> implemented >>> for some time, and the DHCPv6 server still needs to learn the ULA to put >>> in the option)? >>> >>> On the one hand homenet is saying "we'd prefer to use ULAs by default >>> without needing >>> some magic to achieve it" while 6man is saying "we need to protect >>> against ULA leakage, >>> so if you want to prefer ULA for internal connection stability figure out >>> the magic". >>> >>> This needs to be mapped to words for the homenet arch text. >>> >>> Tim >>> >>> >>>> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis >>>> and discuss it over on v6ops. >>>> >>>> Brian >>>> >>>> >>>>> Thanks, >>>>> Anders >>>>> >>>>>>> You'll find the above logic in the current 3484bis draft. >>>>>>> >>>>>>> -Dave >>>>>>> -------------------------------------------------------------------- >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>>>> >>>>>> _______________________________________________ >>>>>> homenet mailing list >>>>>> homenet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>>> >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> homenet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>> >>>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > --------------070607050602030603040503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Firstly, I have been lurking on the 3484-revise discussion in 6man for a long time. I agree with Brian's proposal:
[source & destination of a /48 ULA prefix match => prefer over 2000:/3 space. Otherwise don't (by default).]



Secondly, I think Homenet still has a lot of work to do, especially due to the autoconfig requirements.
Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + invariant addresses is likely going to be tough, if not downright impossible.

So why do we think we really need concurrent ULA+PA in Homenet as a base requirement? I'm not entirely convinced yet.

One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks." I don't see how "complete time-invariance of addressing"  is achievable together with autoconfig, even if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywhere. We've been down that rathole before. Site-local has been deprecated in RFC3879. And realistically speaking, any time someone replaces or adds or re-plugs any router hardware, the LAN's /64 prefix will change when using autoconfig.

I think it would be useful for the Homenet WG to propose a scheme for sensor networks to be able to maintain simple peerings despite the presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it would seem to me that a peering solution should use something that is long-term invariant as an identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invariant identifier could be automatically registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to the current IPv6 address and then verify the peering using their own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would trigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specific (and has to be solved anyway even with fixed addresses). I have an asterisk hardware phone that does something similar to this, so it can't require much code.


A reason concurrent ULA+PA seems to be required was that "intra-homenet communication should survive a long term ISP outage, and must be able to be established without any ISP connection present."

The first linkage would appear to be when ISP PA-derived prefixes within Homenet timeout via DHCPv6 PD meaning that a long-running session based on this address would drop. That has nothing directly to do with ULA, and may have other solutions.

Question: How long are ISP's setting their DHCPv6 PD timers in practice? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix might be a practical solution. How often has your ISP connection been down for say 10 days?

Another solution might be for the application to reconnect using another PA-derived address (if the user has two providers).


The second linkage may also have other solutions, such as only configuring a ULA prefix when no PA-derived prefixes are present.

That would mean at any one time the Homenet could potentially be running either ULA or multiple PA, but not both, which completely avoids any address selection conflicts and having to redistribute new RFC3484 address selection rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems."

So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements, rather than on ULA in and of itself.

regards,
RayH


Brian E Carpenter wrote: 
Don,

On 2012-03-22 01:24, Don Sturek wrote:
  
Hi Tim,

One more consideration:
In the home, it is possible that multiple independent subnets could be
combined, each with their own ULA prefix.  This would happen in cases
where the homeowner buys multiple silo'ed solutions (like a home
automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a
cross connect device that integrates these solutions.
    

Yes, anything could happen and probably will. So while a single ULA per
site is the simple and obvious case (and I don't have any argument for
Anders except KISS), there *will* be cases where several ULAs pop
up, and I think resolving routing issues in that situation is likely
to be troublesome. We can't resolve it as we do for enterprise networks
by saying that the network's manager will manually configure appropriate
routes.

    Brian

  
Don





On 3/21/12 4:55 AM, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:

    
On 20 Mar 2012, at 21:25, Brian E Carpenter wrote:

      
On 2012-03-20 21:51, Anders Brandt wrote:
        
It is a surprise to me that ULA addresses are not by default routable
within the site.
I can easily imagine a number of LLN border routers which autonomously
allocate
different ULA prefixes for use within their individual LLN subnets.
          
IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they
cover an entire enterprise or home network, but not if they cover a
subset.

        
Meeting a ULA address outside the local prefix will cause the LLN node
to forward
its IP packets to the default gateway (border router) of the LLN
subnet. This way
packets can travel between LLN subnets using normal routing with
long-term stable
ULA addresses. We need the stable addresses for control-style
applications in LLNs.

Obviously it requires a routing protocol in the (homenet) LAN but are
there other issues?
          
It doesn't just require a routing protocol; it also requires a routing
policy
that knows which routers have to block the ULAs (plural). That seems a
lot
more complex that a rule that says only a border router originates and
delegates
a ULA prefix, because that border router would also know to block the
prefix across the border.
        
So we need to determine what the homenet arch text will say on this.

I think the assumption so far has been that, as per PD8 in
draft-ietf-homenet-arch-02,
one router would be elected the "master" to delegate /64 ULA prefixes
within the
homenet, both to ULA-only LLNs and to links that also have a GUA prefix.
If there's 
an assumption an LLN router will not support that, and instead generate
its own /48 
ULA, we need to talk about that, or any other scenario that will lead to
multiple /48 ULAs 
in a single homenet site.

The arch text currently says that ULAs should be used (CN1) and that ULAs
should be 
preferred for internal communications to GUAs (section 2.4).  It doesn't
say how connections
      
>from outside the homenet can be made to internal ULA-only devices.
    
The 3484-bis text has changed the default ULA preference to protect
against ULA leakage,
so if you now want ULAs preferred you need to somehow inject the specific
site /48 ULA
being used with high precedence into the policy table (and as also
pointed out here if your
site is using less than a /48, you should also have some way to learn
what the site prefix
length is). In the homenet case is that injection achieved on receipt of
an RA, or would it
require the proposed DHCPv6 option to be used (which may not be widely
implemented 
for some time, and the DHCPv6 server still needs to learn the ULA to put
in the option)? 

On the one hand homenet is saying "we'd prefer to use ULAs by default
without needing
some magic to achieve it" while 6man is saying "we need to protect
against ULA leakage,
so if you want to prefer ULA for internal connection stability figure out
the magic".  

This needs to be mapped to words for the homenet arch text.

Tim

      
Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
and discuss it over on v6ops.

   Brian

        
Thanks,
 Anders
          
You'll find the above logic in the current 3484bis draft.

-Dave
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
              
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
            
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

          
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
        
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
      
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------070607050602030603040503-- From Anders_Brandt@sigmadesigns.com Thu Mar 22 02:07:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BCF21F85EF; Thu, 22 Mar 2012 02:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, MANGLED_PAIN=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXQP2oz-no5g; Thu, 22 Mar 2012 02:07:14 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 20B6221F85BD; Thu, 22 Mar 2012 02:07:08 -0700 (PDT) From: Anders Brandt To: Ray Hunter , Brian E Carpenter Subject: RE: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkAgADEt4CAAPLVgIAACFaAgAB4SoCAANgzgIAAGDFg Date: Thu, 22 Mar 2012 09:06:22 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053@cph-ex1> References: <4F6A2D7F.1030901@gmail.com> <4F6AE2DB.2000007@globis.net> In-Reply-To: <4F6AE2DB.2000007@globis.net> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: multipart/alternative; boundary="_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-Mailman-Approved-At: Thu, 22 Mar 2012 02:11:03 -0700 Cc: Tim Chown , 6man , "homenet@ietf.org Group" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:07:16 -0000 --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, > So I humbly suggest the WG should first concentrate on properly formulati= ng and clarifying the high level architectural requirements, > rather than on ULA in and of itself. I agree that we must concentrate on the architecture requirements first. It would however be unfortunate if these requirements ruled out the case of= routing between homenet subnets based on stable addresses when we have a couple of use cases for LLNs that call such functionality. Maybe I should provide some use cases to Bing's draft to outline why this m= atters to us LLN guys. I think I need some education on ULA routing - starting new thread... - Anders From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Ray Hunter Sent: Thursday, March 22, 2012 09:29 To: Brian E Carpenter Cc: 6man; Tim Chown; Don Sturek; homenet@ietf.org Group Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] +1 Firstly, I have been lurking on the 3484-revise discussion in 6man for a lo= ng time. I agree with Brian's proposal: [source & destination of a /48 ULA prefix match =3D> prefer over 2000:/3 sp= ace. Otherwise don't (by default).] Secondly, I think Homenet still has a lot of work to do, especially due to = the autoconfig requirements. Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + inv= ariant addresses is likely going to be tough, if not downright impossible. So why do we think we really need concurrent ULA+PA in Homenet as a base re= quirement? I'm not entirely convinced yet. One reason ULA seems to be mentioned is "time-invariance of addressing for = use by sensor networks." I don't see how "complete time-invariance of addre= ssing" is achievable together with autoconfig, even if we call for an equi= valent site-local addressing with a fixed /48 prefix that is common to all = Homenet implementations everywhere. We've been down that rathole before. Si= te-local has been deprecated in RFC3879. And realistically speaking, any ti= me someone replaces or adds or re-plugs any router hardware, the LAN's /64 = prefix will change when using autoconfig. I think it would be useful for the Homenet WG to propose a scheme for senso= r networks to be able to maintain simple peerings despite the presence of t= ime-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. I= n fact, it would seem to me that a peering solution should use something th= at is long-term invariant as an identifier for keying the peering e.g. EUI-= 64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invari= ant identifier could be automatically registered by each sensor as a name i= n the Homenet naming service. Peers could resolve that name to the current = IPv6 address and then verify the peering using their own protocol like HMAC= _MD5 with a shared secret (RFC2104). Loss of connection would trigger a new= address resolution, reconnection, and peer check. Agreeing the shared secr= et is peering specific (and has to be solved anyway even with fixed address= es). I have an asterisk hardware phone that does something similar to this,= so it can't require much code. A reason concurrent ULA+PA seems to be required was that "intra-homenet com= munication should survive a long term ISP outage, and must be able to be es= tablished without any ISP connection present." The first linkage would appear to be when ISP PA-derived prefixes within Ho= menet timeout via DHCPv6 PD meaning that a long-running session based on th= is address would drop. That has nothing directly to do with ULA, and may ha= ve other solutions. Question: How long are ISP's setting their DHCPv6 PD timers in practice? Si= mply recommending very long timers for the DHCPv6 PD PA-derived prefix migh= t be a practical solution. How often has your ISP connection been down for = say 10 days? Another solution might be for the application to reconnect using another PA= -derived address (if the user has two providers). The second linkage may also have other solutions, such as only configuring = a ULA prefix when no PA-derived prefixes are present. That would mean at any one time the Homenet could potentially be running ei= ther ULA or multiple PA, but not both, which completely avoids any address = selection conflicts and having to redistribute new RFC3484 address selectio= n rules to all nodes. Simply put: "Please reboot or reconnect to fix any pr= oblems." So I humbly suggest the WG should first concentrate on properly formulating= and clarifying the high level architectural requirements, rather than on U= LA in and of itself. regards, RayH Brian E Carpenter wrote: Don, On 2012-03-22 01:24, Don Sturek wrote: Hi Tim, One more consideration: In the home, it is possible that multiple independent subnets could be combined, each with their own ULA prefix. This would happen in cases where the homeowner buys multiple silo'ed solutions (like a home automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a cross connect device that integrates these solutions. Yes, anything could happen and probably will. So while a single ULA per site is the simple and obvious case (and I don't have any argument for Anders except KISS), there *will* be cases where several ULAs pop up, and I think resolving routing issues in that situation is likely to be troublesome. We can't resolve it as we do for enterprise networks by saying that the network's manager will manually configure appropriate routes. Brian Don On 3/21/12 4:55 AM, "Tim Chown" wrote: On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: On 2012-03-20 21:51, Anders Brandt wrote: It is a surprise to me that ULA addresses are not by default routable within the site. I can easily imagine a number of LLN border routers which autonomously allocate different ULA prefixes for use within their individual LLN subnets. IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they cover an entire enterprise or home network, but not if they cover a subset. Meeting a ULA address outside the local prefix will cause the LLN node to forward its IP packets to the default gateway (border router) of the LLN subnet. This way packets can travel between LLN subnets using normal routing with long-term stable ULA addresses. We need the stable addresses for control-style applications in LLNs. Obviously it requires a routing protocol in the (homenet) LAN but are there other issues? It doesn't just require a routing protocol; it also requires a routing policy that knows which routers have to block the ULAs (plural). That seems a lot more complex that a rule that says only a border router originates and delegates a ULA prefix, because that border router would also know to block the prefix across the border. So we need to determine what the homenet arch text will say on this. I think the assumption so far has been that, as per PD8 in draft-ietf-homenet-arch-02, one router would be elected the "master" to delegate /64 ULA prefixes within the homenet, both to ULA-only LLNs and to links that also have a GUA prefix. If there's an assumption an LLN router will not support that, and instead generate its own /48 ULA, we need to talk about that, or any other scenario that will lead to multiple /48 ULAs in a single homenet site. The arch text currently says that ULAs should be used (CN1) and that ULAs should be preferred for internal communications to GUAs (section 2.4). It doesn't say how connections >from outside the homenet can be made to internal ULA-only devices. The 3484-bis text has changed the default ULA preference to protect against ULA leakage, so if you now want ULAs preferred you need to somehow inject the specific site /48 ULA being used with high precedence into the policy table (and as also pointed out here if your site is using less than a /48, you should also have some way to learn what the site prefix length is). In the homenet case is that injection achieved on receipt of an RA, or would it require the proposed DHCPv6 option to be used (which may not be widely implemented for some time, and the DHCPv6 server still needs to learn the ULA to put in the option)? On the one hand homenet is saying "we'd prefer to use ULAs by default without needing some magic to achieve it" while 6man is saying "we need to protect against ULA leakage, so if you want to prefer ULA for internal connection stability figure out the magic". This needs to be mapped to words for the homenet arch text. Tim Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis and discuss it over on v6ops. Brian Thanks, Anders You'll find the above logic in the current 3484bis draft. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,

 

> So I humbly suggest the WG should first concent= rate on properly formulating and clarifying the high level architectural re= quirements,

> rather than on ULA in and of itself.

 

I agree that we must concentrate on the architecture= requirements first.
It would however be unfortunate if these requirements ruled out the case of= routing between homenet subnets based on stable addresses when<= /p>

we have a couple of use cases for LLNs that call suc= h functionality.

Maybe I should provide some use cases to Bing's draf= t to outline why this matters to us LLN guys.


I think I need some education on ULA routing - s= tarting new thread...

 <= /p>

- Anders

 <= /p>

From: homenet-bounces@ietf.org [mailto:homenet-bounces@= ietf.org] On Behalf Of Ray Hunter
Sent: Thursday, March 22, 2012 09:29
To: Brian E Carpenter
Cc: 6man; Tim Chown; Don Sturek; homenet@ietf.org Group
Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.= txt]

 

+1

Firstly, I have been lurking on the 3484-revise discussion in 6man for a lo= ng time. I agree with Brian's proposal:
[source & destination of a /48 ULA prefix match =3D> prefer over 200= 0:/3 space. Otherwise don't (by default).]



Secondly, I think Homenet still has a lot of work to do, especially due to = the autoconfig requirements.
Everyone wants autoconfig. Concurrent ULA + PA + both with autoconf= ig + invariant addresses is likely going to be tough, if not downright = impossible.

So why do we think we really need concurrent ULA+PA in Homenet as a bas= e requirement? I'm not entirely convinced yet.

One reason ULA seems to be mentioned is "time-invariance of addressing= for use by sensor networks." I don't see how "complete time-inva= riance of addressing"  is achievable together with autoconfig, ev= en if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywher= e. We've been down that rathole before. Site-local has been deprecated in R= FC3879. And realistically speaking, any time someone replaces or adds or re= -plugs any router hardware, the LAN's /64 prefix will change when using autoconfig.

I think it would be useful for the Homenet WG to propose a scheme for senso= r networks to be able to maintain simple peerings despite the presence of t= ime-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. I= n fact, it would seem to me that a peering solution should use something that is long-term invariant as an = identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, = and not the IPv6 address at all. The invariant identifier could be automati= cally registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to = the current IPv6 address and then verify the peering using their own protoc= ol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would t= rigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specif= ic (and has to be solved anyway even with fixed addresses). I have an aster= isk hardware phone that does something similar to this, so it can't require= much code.


A reason concurrent ULA+PA seems to be required was that "intra-ho= menet communication should survive a long term ISP outage, and must be able= to be established without any ISP connection present."

The first linkage would appear to be when ISP PA-derived prefixes within Ho= menet timeout via DHCPv6 PD meaning that a long-running session based on th= is address would drop. That has nothing directly to do with ULA, and may ha= ve other solutions.

Question: How long are ISP's setting their DHCPv6 PD timers in practice? Si= mply recommending very long timers for the DHCPv6 PD PA-derived prefix migh= t be a practical solution. How often has your ISP connection been down for = say 10 days?

Another solution might be for the application to reconnect using another PA= -derived address (if the user has two providers).


The second linkage may also have other solutions, such as only configuring = a ULA prefix when no PA-derived prefixes are present.

That would mean at any one time the Homenet could potentially be running ei= ther ULA or multiple PA, but not both, which completely avoids any address = selection conflicts and having to redistribute new RFC3484 address selectio= n rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems."

So I humbly suggest the WG should first concentrate on properly formulating= and clarifying the high level architectural requirements, rather than on U= LA in and of itself.

regards,
RayH


Brian E Carpenter wrote: 

Don,
 
On 2012-03-22 01:24, Don Sturek wrote:
  
Hi Tim,
 
One more consideration:
In the home, it is possible that multiple independent subnets could be=

combined, each with their own ULA prefix.  This would happen in c=
ases
where the homeowner buys multiple silo'ed solutions (like a home<=
/o:p>
automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchas=
es a
cross connect device that integrates these solutions.
    
 
Yes, anything could happen and probably will. So while a single ULA pe=
r
site is the simple and obvious case (and I don't have any argument for=

Anders except KISS), there *will* be cases where several ULAs pop=

up, and I think resolving routing issues in that situation is likely
to be troublesome. We can't resolve it as we do for enterprise network=
s
by saying that the network's manager will manually configure appropria=
te
routes.
 
    Brian
 
  
Don
 
 
 
 
 
On 3/21/12 4:55 AM, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:
 
    
On 20 Mar 2012, at 21:25, Brian E Carpenter wrote:
 
      
On 2012-03-20 21:51, Anders Brandt wrote:
        
It is a surprise to me that ULA addresses are not by default routable<=
o:p>
within the site.
I can easily imagine a number of LLN border routers which autonomously=

allocate
different ULA prefixes for use within their individual LLN subnets.
          

IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if th=
ey
cover an entire enterprise or home network, but not if they cover a
subset.
 
        
Meeting a ULA address outside the local prefix will cause the LLN node=

to forward
its IP packets to the default gateway (border router) of the LLN<=
/o:p>
subnet. This way
packets can travel between LLN subnets using normal routing with<=
/o:p>
long-term stable
ULA addresses. We need the stable addresses for control-style
applications in LLNs.
 
Obviously it requires a routing protocol in the (homenet) LAN but are<=
o:p>
there other issues?
          

It doesn't just require a routing protocol; it also requires a routing=

policy
that knows which routers have to block the ULAs (plural). That seems a=

lot
more complex that a rule that says only a border router originates and=

delegates
a ULA prefix, because that border router would also know to block the<=
o:p>
prefix across the border.
        
So we need to determine what the homenet arch text will say on this.
 
I think the assumption so far has been that, as per PD8 in<=
/pre>

draft-ietf-homenet-arch-02,


one router would be elected the "master" to delegate /64 ULA=
 prefixes


within the


homenet, both to ULA-only LLNs and to links that also have a GUA prefi=
x.


If there's 


an assumption an LLN router will not support that, and instead generat=
e


its own /48 


ULA, we need to talk about that, or any other scenario that will lead =
to


multiple /48 ULAs 


in a single homenet site.


 


The arch text currently says that ULAs should be used (CN1) and that U=
LAs


should be 


preferred for internal communications to GUAs (section 2.4).  It =
doesn't


say how connections


      


>from outside the homenet can be made to internal ULA-only devices.=

    
The 3484-bis text has changed the default ULA preference to protect
against ULA leakage,
so if you now want ULAs preferred you need to somehow inject the speci=
fic
site /48 ULA
being used with high precedence into the policy table (and as also
pointed out here if your
site is using less than a /48, you should also have some way to learn<=
o:p>
what the site prefix
length is). In the homenet case is that injection achieved on receipt =
of
an RA, or would it
require the proposed DHCPv6 option to be used (which may not be widely=

implemented 
for some time, and the DHCPv6 server still needs to learn the ULA to p=
ut
in the option)? 
 
On the one hand homenet is saying "we'd prefer to use ULAs by def=
ault
without needing
some magic to achieve it" while 6man is saying "we need to p=
rotect
against ULA leakage,
so if you want to prefer ULA for internal connection stability figure =
out
the magic".  
 
This needs to be mapped to words for the homenet arch text.=

 
Tim
 
      
Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
and discuss it over on v6ops.
 
   Brian
 
        
Thanks,
 Anders
          





You'll find the above logic in the current 3484bis draft.

 


-Dave


--------------------------------------------------------------------


IETF IPv6 working group mailing list


ipv6@ietf.org


Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6


--------------------------------------------------------------------


           &nbs=
p;  




_______________________________________________


homenet mailing list


homenet@ietf.org

https://www.=
ietf.org/mailman/listinfo/homenet


            




_______________________________________________


homenet mailing list


homenet@ietf.org

https://www.=
ietf.org/mailman/listinfo/homenet


 


          

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
        
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
      
 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
 
    
 
 
--_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_-- From Anders_Brandt@sigmadesigns.com Thu Mar 22 03:01:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3026121F8656; Thu, 22 Mar 2012 03:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUpP+F+-zZcq; Thu, 22 Mar 2012 03:01:39 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 40EEB21F8650; Thu, 22 Mar 2012 03:01:39 -0700 (PDT) From: Anders Brandt To: 6man , Tim Chown , Don Sturek , "homenet@ietf.org Group" , Ray Hunter , Brian E Carpenter , Thomas Herbst Subject: Routing between hosts in ULA subnets Thread-Topic: Routing between hosts in ULA subnets Thread-Index: Ac0ICzMLeb6p7jSYSAG4znR5jr2Gqw== Date: Thu, 22 Mar 2012 10:00:56 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: multipart/alternative; boundary="_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-Mailman-Approved-At: Thu, 22 Mar 2012 03:30:49 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:01:40 -0000 --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a branch of the discussion [homenet] ULA scope [draft-ietf-6man-rfc3484-= revise-05.txt], I would like some clear explanation of the actual issues related to routing= between hosts in ULA subnets. Some people seems to be concerned for a reason that seems pretty unclear to= me. Here is my use case: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have a new house. The electrician installs lighting devices from two vend= ors using different LLN technologies, e.g. power line and RF. The ISP has not installed a CER router yet, so there is no central source o= f prefixes or naming service. The electrician completes his installation by including devices with their = respective border routers and testing with a stand-alone tool that all devices communicate correctly. Now a technician sets up advanced rules for how timers and sensors control = lights and window blinds. He plugs a cable between the two LLN border routers and connects a PC. He uses mDNS to discover the devices via Resource Directories in the LLN bo= rder routers. Devices are configured to control other devices using some application prot= ocol. Everything works when the technician leaves the house. A week later the ISP installs the CER router. Everything still works. Here is my question(s): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Why should homenet require the subnet ULAs to be distributed from another r= outer? It works without extra routers in the scenario described above. (Actually, the technician's configuration would break if new ULAs were dist= ributed by another router later on). Why cannot two border routers connected to the homenet LAN make routing pro= tocol announcements for two different ULA prefixes - such as: "I am the router with LAN link-local address X and you can use me to reach = ULA subnet XX" ? In a homenet case, why cannot the default ULA policy be boiled down to "Dis= card ULA packets trying to pass the CER"? Thanks, Anders --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As a branch of the discussion [homenet] ULA scope [draft-ietf-6man-rfc= 3484-revise-05.txt],
I would like some clear explanation of the actual issues related to ro= uting between hosts in ULA subnets.
Some people seems to be concerned for a reason that seems pretty uncle= ar to me.
 
Here is my use case:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
I have a new house. The electrician installs lighting devices from two= vendors using different LLN technologies,
e.g. power line and RF.
The ISP has not installed a CER router yet, so there is no central sou= rce of prefixes or naming service.
 
The electrician completes his installation by including devices with t= heir respective border routers and testing
with a stand-alone tool that all devices communicate correctly.
 
Now a technician sets up advanced rules for how timers and sensors con= trol lights and window blinds.
He plugs a cable between the two LLN border routers and connects a PC.=
He uses mDNS to discover the devices via Resource Directories in the L= LN border routers.
Devices are configured to control other devices using some application= protocol.
Everything works when the technician leaves the house.
 
A week later the ISP installs the CER router. Everything still works.<= /div>
 
 
Here is my question(s):
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Why should homenet require the subnet ULAs to be distributed from anot= her router?
It works without extra routers in the scenario described above.
(Actually, the technician's configuration would break if new ULAs were dist= ributed by another router later on).
 
Why cannot two border routers connected to the homenet LAN make routin= g protocol announcements
for two different ULA prefixes - such as:
"I am the router with LAN link-local address X and you can use me= to reach ULA subnet XX"  ?
 
In a homenet case, why cannot the default ULA policy be boiled down to= "Discard ULA packets trying to pass the CER"?
 
 
Thanks,
  Anders
 
 
 --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_-- From leo.liubing@huawei.com Thu Mar 22 22:34:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6BE21F8469; Thu, 22 Mar 2012 22:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfIR8Qw9lA09; Thu, 22 Mar 2012 22:34:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B9DA521F8468; Thu, 22 Mar 2012 22:34:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP96741; Fri, 23 Mar 2012 01:34:01 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:31:02 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:31:09 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 13:31:03 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , IPv6 Operations Subject: RE: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 Thread-Index: AQHNCKO8Z4KSGk/lHk+mkdEjskALJpZ3UmnA Date: Fri, 23 Mar 2012 05:31:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F4524A26650@szxeml509-mbs> References: <4F6BEB95.60608@gmail.com> In-Reply-To: <4F6BEB95.60608@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 23 Mar 2012 00:46:43 -0700 Cc: "homenet@ietf.org" , "6man@ietf.org" <6man@ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:34:02 -0000 SGksIEJyaWFuDQoNClRoZXJlIGNvbWVzIGNvbW1lbnRzIGZpbmFsbHkgOi0pIFRoYW5rcyBmb3Ig eW91ciBjb25jZXJuIGFib3V0IHRoZSBkcmFmdC4gIA0KDQpJJ3ZlIG5vdGljZWQgdGhlIGRpc2N1 c3Npb24gaW4gNm1hbiBhbmQgaG9tZW5ldCwgd2hpY2ggaXMgbW9yZSBpbi1kZXB0aCB0ZWNobmlj YWwgaXNzdWUgd2hpbGUgdGhlIFVMQSB1c2FnZSBkcmFmdCBpcyBtb3JlIGdlbmVyYWwgdXNlIGNh c2VzLiBCdXQgSSB0aGluayBpdCBpcyBleGFjdGx5IHZhbHVhYmxlIGlucHV0IGFuZCBjb25zaWRl cmF0aW9uIHRvIHRoZSBVTEEgZHJhZnQgZm9yIHRoZSBmdXJ0aGVyIHN0ZXAuICANCg0KSSBhbSBh bHNvIGNvbmZ1c2VkIGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZGlzY3Vzc2lv biBpbiB2YXJpb3VzIFdHcyBhbmQgdGhlIFVMQSBkcmFmdC4NCldlIHNob3VsZCBjb3ZlciBhbGwg dGhlIHNwZWNpZmljIGlzc3VlcyBpbiB0aGUgZHJhZnQsIG9yIGp1c3QgbGltaXQgdGhlIGRpc2N1 c3Npb24gd2l0aGluIGVhY2ggV0cgd2hpbGUgdGhlIGRyYWZ0IG9ubHkgZm9jdXMgb24gZ2VuZXJh bCB1c2UgY2FzZXOjvw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog djZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZg0KPiBCcmlhbiBFIENhcnBlbnRlcg0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDIz LCAyMDEyIDExOjE5IEFNDQo+IFRvOiBJUHY2IE9wZXJhdGlvbnMNCj4gU3ViamVjdDogW3Y2b3Bz XSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzLTAyDQo+IA0KPiBIaSwNCj4gDQo+ IEkgdGhpbmsgdGhpcyBkcmFmdCBpcyBhIGNvbnNpZGVyYWJsZSBpbXByb3ZlbWVudCBvbiB0aGUg LTAwIHZlcnNpb24uDQo+IEl0IHN0aWxsIG5lZWRzIHNvbWUgd29yayBvbiB0aGUgRW5nbGlzaCwg YnV0IEkgdGhpbmsgdGhlIG1haW4gcG9pbnRzDQo+IGFyZSBjb3ZlcmVkIG5vdyBhbmQgdGhlIHdv cmsgc2hvdWxkIGNvbnRpbnVlLg0KPiANCj4gSG93ZXZlciwgdGhlcmUgaXMgY2xlYXJseSBhIGNv bXBsaWNhdGlvbiwgd2hpY2ggaXMgdGhhdCB0aGlzIGRvY3VtZW50DQo+IG5lZWRzIHRvIGJlIGFs aWduZWQgd2l0aCB3aGF0ZXZlciBjb25zZW5zdXMgYXBwZWFycyBpbiBob21lbmV0IGFib3V0DQo+ IFVMQXMsIGFuZCB3aXRoIHdoYXRldmVyIGNvbnNlbnN1cyBhcHBlYXJzIGluIDZtYW4gYWJvdXQg UkZDMzQ4NGJpcy4NCj4gDQo+IEluIHBhcnRpY3VsYXIsIGhvbWVuZXQgaXMgaGl0dGluZyB0aGUg cHJvYmxlbSBvZiB3aGF0IGhhcHBlbnMgd2hlbg0KPiBtdWx0aXBsZSBVTEEgcHJlZml4ZXMgc2hv dyB1cCBhdXRvbWF0aWNhbGx5IGluIHRoZSBzYW1lIG5ldHdvcmsuIFRoYXQNCj4gbWF5IG5vdCBi ZSByZWNvbW1lbmRlZCBwcmFjdGljZSwgYnV0IGl0IHNlZW1zIHZlcnkgbGlrZWx5IHRvIGhhcHBl biwNCj4gYW5kIHJhaXNlcyByb3V0aW5nIGFuZCBhZGRyZXNzLXNlbGVjdGlvbiBxdWVzdGlvbnMu DQo+IA0KPiBJIHRoaW5rIHRoZSB2YXJpb3VzIFdHIENoYWlycyBuZWVkIHRvIGFncmVlIGhvdyB0 aGUgZGlzY3Vzc2lvbiBzaG91bGQNCj4gYmUgbWFuYWdlZCwgYmVjYXVzZSBpdCBtaWdodCBnZXQg Y29tcGxpY2F0ZWQgd2l0aCB0aHJlZSBXR3MgaW52b2x2ZWQNCj4gKG9yIGZvdXIsIGlmIHlvdSBj b3VudCA2cmVudW0pLg0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg== From brian@innovationslab.net Fri Mar 23 05:38:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC48C21F851A for ; Fri, 23 Mar 2012 05:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mewi1b2O++MF for ; Fri, 23 Mar 2012 05:38:09 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id ED5DE21F8452 for ; Fri, 23 Mar 2012 05:38:08 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 76FD78816D for ; Fri, 23 Mar 2012 05:38:08 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3DCBC130015 for ; Fri, 23 Mar 2012 05:38:08 -0700 (PDT) Message-ID: <4F6C6EB0.3070708@innovationslab.net> Date: Fri, 23 Mar 2012 08:38:08 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Scribes and minutes References: <4F61D359.9060204@innovationslab.net> In-Reply-To: <4F61D359.9060204@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:38:13 -0000 We are still in need of people to take minutes and act as Jabber scribes. I am working on getting etherpad setup for the 6man session so that minute taking can be a collaborative effort between multiple people. Regards, Brian On 3/15/12 7:32 AM, Brian Haberman wrote: > All, > The preliminary agenda has been posted for the 6MAN meeting in Paris. We > have the 0900-1130 slot on Tuesday morning. > > If you are willing to serve as a Jabber scribe or take minutes, please > let the chairs know. Any and all assistance with these tasks is greatly > appreciated. > > Presenters are asked to send their slides to the chairs NO LATER THAN > March 26th at 2100. This allows us to upload the slides to the meeting > materials site so that they are available to remote participants. > > Regards, > Brian, Bob, & Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rajiva@cisco.com Fri Mar 23 12:51:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367121F85F0; Fri, 23 Mar 2012 12:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHwP36VLueK0; Fri, 23 Mar 2012 12:51:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8721F85E3; Fri, 23 Mar 2012 12:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3136; q=dns/txt; s=iport; t=1332532313; x=1333741913; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=1DXCX6PY58i2PiFDy9FzkyAbthXoZ+mX6U7JiAnSCmU=; b=MGadmurNjOYViTaoqe7NMB0re9M5rWxy5A2JyY7IJ0bCs+doqZstz9Wt PqlXyRXDCkzZ0eDY3qEB4Arpxuz6xoRtOMdN61CPYNQofHyWWZEo0TGBT n74gqcDVza2D1eh+EuZr+bu2rOU7N6+9KXyUX7VH9E1dd0FJFZXyWr8sF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOPTbE+tJV2Z/2dsb2JhbABFDrgHgQeCCQEBAQMBAQEBDwEnAgExEAcHCBEDAQJQBigIBgESIodjBQuZeJ51BIlthxgElWCFboVCgxSBaIIwUw X-IronPort-AV: E=Sophos;i="4.73,637,1325462400"; d="scan'208";a="68994671" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 23 Mar 2012 19:51:53 +0000 Received: from [64.102.202.94] (dhcp-64-102-202-94.cisco.com [64.102.202.94]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NJpjKl006982; Fri, 23 Mar 2012 19:51:48 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 15:51:43 -0400 Subject: Re: Routing between hosts in ULA subnets From: Rajiv Asati To: Anders Brandt , 6man , Tim Chown , Don Sturek , "homenet@ietf.org Group" , Ray Hunter , Brian E Carpenter , Thomas Herbst Message-ID: Thread-Topic: Routing between hosts in ULA subnets In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 19:51:57 -0000 Andres, Thanks for writing up this use-case. Quick Q - What global ID would get used in the ULA (assuming GUA is not known yet)? > In a homenet case, why cannot the default ULA policy be boiled down to >"Discard > ULA packets trying to pass the CER"? That would be reasonable. Perhaps, just deny forwarding any traffic over an interface that doesn't have any ULA assigned. Cheers, Rajiv -----Original Message----- From: Anders Brandt Date: Thu, 22 Mar 2012 10:00:56 +0000 To: 6man , Tim Chown , Don Sturek , "homenet@ietf.org Group" , Ray Hunter , Brian E Carpenter , Thomas Herbst Subject: Routing between hosts in ULA subnets >As a branch of the discussion [homenet] ULA scope >[draft-ietf-6man-rfc3484-revise-05.txt], >I would like some clear explanation of the actual issues related to >routing between hosts in ULA subnets. >Some people seems to be concerned for a reason that seems pretty unclear >to me. > >Here is my use case: >================= > >I have a new house. The electrician installs lighting devices from two >vendors using different LLN technologies, >e.g. power line and RF. >The ISP has not installed a CER router yet, so there is no central source >of prefixes or naming service. > >The electrician completes his installation by including devices with >their respective border routers and testing > >with a stand-alone tool that all devices communicate correctly. > >Now a technician sets up advanced rules for how timers and sensors >control lights and window blinds. >He plugs a cable between the two LLN border routers and connects a PC. >He uses mDNS to discover the devices via Resource Directories in the LLN >border routers. >Devices are configured to control other devices using some application >protocol. >Everything works when the technician leaves the house. > >A week later the ISP installs the CER router. Everything still works. > > >Here is my question(s): >================== > >Why should homenet require the subnet ULAs to be distributed from another >router? > >It works without extra routers in the scenario described above. > >(Actually, the technician's configuration would break if new ULAs were >distributed by another router later on). > >Why cannot two border routers connected to the homenet LAN make routing >protocol announcements > >for two different ULA prefixes - such as: >"I am the router with LAN link-local address X and you can use me to >reach ULA subnet XX" ? > >In a homenet case, why cannot the default ULA policy be boiled down to >"Discard ULA packets trying to pass the CER"? > > >Thanks, > Anders > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From fred@cisco.com Fri Mar 23 16:18:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8272321F8552; Fri, 23 Mar 2012 16:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BC2PrSTAhPT; Fri, 23 Mar 2012 16:18:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3E78221F854D; Fri, 23 Mar 2012 16:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4543; q=dns/txt; s=iport; t=1332544716; x=1333754316; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=iIxCD6vq29ipb7Ter8Hain3bjR/qPW2STxKbrZl5Eto=; b=caLFMCTSr60QibdS5c+cDUPOn+GAG+uI29MImd6SoGdj65X/9dmlc2vZ X8R2im5FuFb6iDKxVr+8Q7uNa2UdTGv94MDGShs3JoCl/7LCZTjE2Gk1G o9aea/HlQghTwm7d5sntxPaMvVATDgOmsHlQTpPlNZRo4ZrBSoRpQInQn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACcEbU+Q/khL/2dsb2JhbABEuBqBB4IJAQEBAwESASc/BQsLEjRJDgYuBQKHYwWZZ55skCJjBJVghW6IVoFogmg X-IronPort-AV: E=Sophos;i="4.73,639,1325462400"; d="scan'208";a="69228948" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 23 Mar 2012 23:18:34 +0000 Received: from Freds-Computer.local (ams3-vpn-dhcp4219.cisco.com [10.61.80.122]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NNIXBg026352; Fri, 23 Mar 2012 23:18:34 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 24 Mar 2012 00:18:34 +0100 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 24 Mar 2012 00:18:34 +0100 Subject: Re: [homenet] Routing between hosts in ULA subnets Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> Date: Sat, 24 Mar 2012 00:18:18 +0100 Message-Id: <2834C1C8-DCCB-4D91-8CD4-B5E48EB6AC0A@cisco.com> References: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> To: Anders Brandt X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 6man , Ray Hunter , Tim Chown , Thomas Herbst , "homenet@ietf.org Group" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 23:18:37 -0000 On Mar 22, 2012, at 11:00 AM, Anders Brandt wrote: > As a branch of the discussion [homenet] ULA scope = [draft-ietf-6man-rfc3484-revise-05.txt], > I would like some clear explanation of the actual issues related to = routing between hosts in ULA subnets. > Some people seems to be concerned for a reason that seems pretty = unclear to me. Speaking strictly for myself here... =46rom my perspective, you need at least one prefix for use for = addressing systems in your home/SOHO/whatever. Multiple prefixes are = explicitly supported by the architecture. If you have multiple LANs = within the home, they should under normal circumstances be separate /64s = taken out of a common less specific prefix, such as a /48, /56, /60, = etc. There are arguments for link-local (fe80::/10) as *the* prefix if you = have no upstream and and exactly one LAN. I'm not sure I would recommend = it for the long term, because it can be unmanagable. But for the special = case in which one is configuring a router that has never been connected = to another network, I could well imagine finding a way to address it = using its link-local address. You could use mDNS to translate it from a = well-known name like BRAND-SPANKING-NEW-BRAND-X-ROUTER. If the network has no global prefix (has not ever, or not recently, been = connected to an IPv6 upstream), and either you WANT to have a = non-link-local prefix or you have more than one LAN, ULAs are your = friend, and I'm not sure what else you would use. A ULA is a /48 prefix. If you do have an assigned prefix from one or more upstreams (or, I = suppose, have a PI prefix, which would surprise me), you have at least = one prefix to use that isn't a ULA. It might be a /48, a /56, a /60, or = whatever you were assigned. So, you have one of three obvious prefixes: link-local, a /48 ULA, and s = globally-routed prefix. Each of those, BTW, has a lifetime. The = link-local prefix has an infinite lifetime (infinity is still a number), = you got a lifetime when you got the PA/PI prefix, and you can pick one = for your ULA. Given a prefix, I expect you to allocate a /64 from it for each LAN in = your home. True whether you are using link-local on one LAN, a ULA, or a = global prefix. I can think of error conditions - race conditions - in which a home = might get two or more /48 ULAs floating around in it. I would expect = that the lifetime you place on a ULA eventually clears that up. Until it = does, every LAN in your home has a /64 from each ULA. However, a = persistent condition in which your home has more than one /48 ULA = floating around in it is a bug. Someone needs to fix their code. The $64,000 question is how /64s will be allocated from the prefix(es) = in question. If you use DHCP/DHCPv6 (Ralph and my DHCP draft), a system = is somehow chosen to be the place that DHCP server application runs, and = I would suggest the CPE router that received the DHCP-PD prefix from the = upstream ISP. If you're running ZOSPF, some router (and I would suggest = the same one) is generating an LSA that informs the routers in the home = of the prefix they should allocate from. If you're doing it manually, do = it manually. Whatever the mechanism, and whatever the prefix is (or = prefixes are), the expectation is the same. Speaking strictly for myself, I think the reason we have had so much = trouble getting 3484bis right is that it depends on the host to make = what amounts to a routing decision. The destination address you pick for = your peer system forces the packet to be delivered to that ISP and to = your peer through that ISP's interface to the remote network. In a BCP = 38 world, the source address you pick says that the only exit from your = network that actually works is through the ISP that allocated that = prefix to you (RFC 3704). So, the choice of a source and a destination = address fixes two points on a line connecting your two systems, and that = line is a route. But hosts know little to nothing about routing, and = cannot even predict which egress (if there are more than one) a given = packet will take. So the host fundamentally lacks the information to = make an informed choice. RFC 3484 can't be fixed without changing that. So to my way of thinking, the right solution is Happy Eyeballs, for all = applications (or, preferably, as an OS API service). It will try routes = (source/destination pairs) until it finds a pair that works or runs out = of options.= From wwwrun@rfc-editor.org Mon Mar 26 04:39:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E919021F866B; Mon, 26 Mar 2012 04:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.3 X-Spam-Level: X-Spam-Status: No, score=-104.3 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uWGlJaxrr4d; Mon, 26 Mar 2012 04:39:17 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 297FC21F866A; Mon, 26 Mar 2012 04:39:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 40C36B1E007; Mon, 26 Mar 2012 04:38:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6553 on The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams From: rfc-editor@rfc-editor.org Message-Id: <20120326113800.40C36B1E007@rfc-editor.org> Date: Mon, 26 Mar 2012 04:38:00 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:39:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6553 Title: The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams Author: J. Hui, JP. Vasseur Status: Standards Track Stream: IETF Date: March 2012 Mailbox: jonhui@cisco.com, jpv@cisco.com Pages: 9 Characters: 19093 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-rpl-option-06.txt URL: http://www.rfc-editor.org/rfc/rfc6553.txt The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK] This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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/rfcsearch.html. 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 wwwrun@rfc-editor.org Mon Mar 26 04:52:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E599C21F85C6; Mon, 26 Mar 2012 04:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOyrSuIPAE-y; Mon, 26 Mar 2012 04:52:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1148021F85B8; Mon, 26 Mar 2012 04:52:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E7A42B1E003; Mon, 26 Mar 2012 04:38:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6554 on An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) From: rfc-editor@rfc-editor.org Message-Id: <20120326113812.E7A42B1E003@rfc-editor.org> Date: Mon, 26 Mar 2012 04:38:12 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:52:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6554 Title: An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) Author: J. Hui, JP. Vasseur, D. Culler, V. Manral Status: Standards Track Stream: IETF Date: March 2012 Mailbox: jonhui@cisco.com, jpv@cisco.com, culler@cs.berkeley.edu, vishwas.manral@hp.com Pages: 13 Characters: 30270 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-6man-rpl-routing-header-07.txt URL: http://www.rfc-editor.org/rfc/rfc6554.txt In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK] This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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/rfcsearch.html. 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 brian@innovationslab.net Mon Mar 26 05:27:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0238C21F86D5 for ; Mon, 26 Mar 2012 05:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWnN043WVPPO for ; Mon, 26 Mar 2012 05:27:54 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7F92D21F86D9 for ; Mon, 26 Mar 2012 05:27:54 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6859B88153 for ; Mon, 26 Mar 2012 05:27:54 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (unknown [IPv6:2001:df8:0:80:fc3f:6daa:ea1b:6ba5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 02F84130017 for ; Mon, 26 Mar 2012 05:27:53 -0700 (PDT) Message-ID: <4F7060C8.3070002@innovationslab.net> Date: Mon, 26 Mar 2012 08:27:52 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Scribes and minutes References: <4F61D359.9060204@innovationslab.net> <4F6C6EB0.3070708@innovationslab.net> In-Reply-To: <4F6C6EB0.3070708@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:27:55 -0000 All, Scribes and Jabber liaisons are still needed. We will have Etherpad available which should allow for multiple scribes to collaborate on the minutes in real-time. Please consider volunteering. If no one volunteers, the meeting cannot go on. Regards, Brian On 3/23/12 8:38 AM, Brian Haberman wrote: > We are still in need of people to take minutes and act as Jabber > scribes. I am working on getting etherpad setup for the 6man session so > that minute taking can be a collaborative effort between multiple people. > > Regards, > Brian > > On 3/15/12 7:32 AM, Brian Haberman wrote: >> All, >> The preliminary agenda has been posted for the 6MAN meeting in Paris. We >> have the 0900-1130 slot on Tuesday morning. >> >> If you are willing to serve as a Jabber scribe or take minutes, please >> let the chairs know. Any and all assistance with these tasks is greatly >> appreciated. >> >> Presenters are asked to send their slides to the chairs NO LATER THAN >> March 26th at 2100. This allows us to upload the slides to the meeting >> materials site so that they are available to remote participants. >> >> Regards, >> Brian, Bob, & Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian@innovationslab.net Tue Mar 27 00:33:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A07721F8483 for ; Tue, 27 Mar 2012 00:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZKNgOatwD5C for ; Tue, 27 Mar 2012 00:33:50 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id B458A21F8702 for ; Tue, 27 Mar 2012 00:33:50 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7B3548816D for ; Tue, 27 Mar 2012 00:33:50 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (dhcp-5588.meeting.ietf.org [130.129.85.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 1B3CF130017 for ; Tue, 27 Mar 2012 00:33:49 -0700 (PDT) Message-ID: <4F716D5C.40402@innovationslab.net> Date: Tue, 27 Mar 2012 03:33:48 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: 3484bis and privacy addresses Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:33:51 -0000 All, The chairs would like to get a sense of the working group on changing the current (defined 3484) model of preferring public addresses over privacy addresses during the address selection process. RFC 3484 prefers public addresses with the ability (MAY) of an implementation to reverse the preference. The suggestion has been made to reverse that preference in 3484bis (prefer privacy addresses over public ones). Regardless, the document will allow implementers/users to reverse the default preference. Please state your preference for one of the following default options : A. Prefer public addresses over privacy addresses B. Prefer privacy addresses over public addresses Regards, Brian, Bob, & Ole From prvs=1433caa07d=jordi.palet@consulintel.es Tue Mar 27 00:41:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DFF21F87A1 for ; Tue, 27 Mar 2012 00:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwKz-IOE-ISp for ; Tue, 27 Mar 2012 00:41:48 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfa.amsl.com (Postfix) with ESMTP id B19C421F879F for ; Tue, 27 Mar 2012 00:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1332833932; x=1333438732; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=/0OBYj4eygpJokKIDtdMOjpOSA2ECkp6mX1QGtlKgac=; b=Bg+ 9JWxMLaXQ8uDKt74OZnWGqv4p7mvYLgIdMFp0oxoIv31uQUPe5ITvX9/0xE01T1c oiN0lI77uufiEzfdbanVuV4nay3WZWZWI2Y8zwft+u/X+EVROmZnRpTCxtsddNet XoyEg7aLmLkppMDIVy5sSt2BUvzexk5KmcG2Q3oY= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=D/MqnHwfGd/3NzpQVafjUjEma4SqcccN3/3ImEFCVGA66g6LpQ8n/+aMBR2E DJCFviA74NdHGvGC2tcldbsO5b50pY2LpLUq9f8f6ghEUb3K4+RWdZifJ NbW/s4BQIOK/l1yy5vUwRRZ3Pp6ukwBorDe/eS0uNapIQ/WpseI8oY=; X-MDAV-Processed: consulintel.es, Tue, 27 Mar 2012 09:38:52 +0200 Received: from [130.129.81.5] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50004132522.msg for ; Tue, 27 Mar 2012 09:38:52 +0200 X-Spam-Processed: consulintel.es, Tue, 27 Mar 2012 09:38:52 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=dhcp-5105.meeting.ietf.org (ip=130.129.81.5) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:120327:md50004132522::xaoUmskn1EtPNtzd:00003lec X-MDRemoteIP: 130.129.81.5 X-Return-Path: prvs=1433caa07d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 27 Mar 2012 09:41:37 +0200 Subject: Re: 3484bis and privacy addresses From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: 3484bis and privacy addresses In-Reply-To: <4F716D5C.40402@innovationslab.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:41:49 -0000 Hi Brian, I think by default privacy addresses (option B) should be selected. It is up to applications that require "stable" addresses to force the other way around, and a quick guess is that this kind of applications already do it by means of selecting a DNS name that should typically have already a global stable address. Regards, Jordi -----Mensaje original----- De: Brian Haberman Responder a: Fecha: Tue, 27 Mar 2012 03:33:48 -0400 Para: Asunto: 3484bis and privacy addresses >All, > The chairs would like to get a sense of the working group on >changing the current (defined 3484) model of preferring public addresses >over privacy addresses during the address selection process. RFC 3484 >prefers public addresses with the ability (MAY) of an implementation to >reverse the preference. The suggestion has been made to reverse that >preference in 3484bis (prefer privacy addresses over public ones). >Regardless, the document will allow implementers/users to reverse the >default preference. > > Please state your preference for one of the following default >options : > >A. Prefer public addresses over privacy addresses > >B. Prefer privacy addresses over public addresses > >Regards, >Brian, Bob, & Ole >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From arifumi@nttv6.net Tue Mar 27 00:47:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE3921F84FA for ; Tue, 27 Mar 2012 00:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fryO03XDaL56 for ; Tue, 27 Mar 2012 00:47:32 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 184FB21F84FC for ; Tue, 27 Mar 2012 00:47:31 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q2R7mFgL070207; Tue, 27 Mar 2012 16:48:16 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: 3484bis and privacy addresses Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D779564-4228-47F8-AC72-68043349C5DC" From: Arifumi Matsumoto In-Reply-To: <4F716D5C.40402@innovationslab.net> Date: Tue, 27 Mar 2012 16:46:11 +0900 Message-Id: <2E3D06A6-1196-43F5-B7EC-DEDD803C5D78@nttv6.net> References: <4F716D5C.40402@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1257) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:47:35 -0000 --Apple-Mail=_1D779564-4228-47F8-AC72-68043349C5DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, if an co-author has a right to vote :) I like B. If privacy address is attached, then it should mean it should be = preferred. On 2012/03/27, at 16:33, Brian Haberman wrote: > All, > The chairs would like to get a sense of the working group on = changing the current (defined 3484) model of preferring public addresses = over privacy addresses during the address selection process. RFC 3484 = prefers public addresses with the ability (MAY) of an implementation to = reverse the preference. The suggestion has been made to reverse that = preference in 3484bis (prefer privacy addresses over public ones). = Regardless, the document will allow implementers/users to reverse the = default preference. >=20 > Please state your preference for one of the following default = options : >=20 > A. Prefer public addresses over privacy addresses >=20 > B. Prefer privacy addresses over public addresses >=20 > Regards, > Brian, Bob, & Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_1D779564-4228-47F8-AC72-68043349C5DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,
    The chairs would = like to get a sense of the working group on changing the current = (defined 3484) model of preferring public addresses over privacy = addresses during the address selection process.  RFC 3484 prefers = public addresses with the ability (MAY) of an implementation to reverse = the preference.  The suggestion has been made to reverse that = preference in 3484bis (prefer privacy addresses over public ones). = Regardless, the document will allow implementers/users to reverse the = default preference.

    Please state your = preference for one of the following default options :

A. Prefer = public addresses over privacy addresses

B. Prefer privacy = addresses over public addresses

Regards,
Brian, Bob, & = Ole
-------------------------------------------------------------------= -
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
----------------------------------------------= ----------------------

= = --Apple-Mail=_1D779564-4228-47F8-AC72-68043349C5DC-- From Basavaraj.Patil@nokia.com Tue Mar 27 01:03:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EBE21F8820 for ; Tue, 27 Mar 2012 01:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt9LnBmvZhK4 for ; Tue, 27 Mar 2012 01:03:22 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0470C21F859F for ; Tue, 27 Mar 2012 01:03:21 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2R82cOh031060; Tue, 27 Mar 2012 11:03:15 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 11:02:58 +0300 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.150]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Tue, 27 Mar 2012 10:02:57 +0200 From: To: , Subject: Re: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNC+wEu8NCxkDfTUqV7Z3zsBFou5Z9yECA Date: Tue, 27 Mar 2012 08:02:57 +0000 Message-ID: In-Reply-To: <4F716D5C.40402@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [130.129.21.136] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Mar 2012 08:02:58.0427 (UTC) FILETIME=[05FF0CB0:01CD0BF0] X-Nokia-AV: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:03:23 -0000 Support option B. -Raj On 3/27/12 9:33 AM, "ext Brian Haberman" wrote: >All, > The chairs would like to get a sense of the working group on >changing the current (defined 3484) model of preferring public addresses >over privacy addresses during the address selection process. RFC 3484 >prefers public addresses with the ability (MAY) of an implementation to >reverse the preference. The suggestion has been made to reverse that >preference in 3484bis (prefer privacy addresses over public ones). >Regardless, the document will allow implementers/users to reverse the >default preference. > > Please state your preference for one of the following default >options : > >A. Prefer public addresses over privacy addresses > >B. Prefer privacy addresses over public addresses > >Regards, >Brian, Bob, & Ole >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From alexandru.petrescu@gmail.com Tue Mar 27 01:08:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626E821F87A2 for ; Tue, 27 Mar 2012 01:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbtzqwcP7dBz for ; Tue, 27 Mar 2012 01:08:33 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E938821F8799 for ; Tue, 27 Mar 2012 01:08:32 -0700 (PDT) Received: by werb10 with SMTP id b10so5683927wer.31 for ; Tue, 27 Mar 2012 01:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=tduvfmDHFVqwDImieUN1PNRCSPq2cx0DH/jmKKt4Z88=; b=X8TgE1s9tBMadDdiW4pIkprpAbaEwrnzKV0xxOqN8f5dGZAXOeQ7WMGTPvGyf7QMw8 +MqHdmnRh5PUcln9wNXTTuSEVTl9ONNKH7K3HmJMVxCkVxLi1fKC4azaT1cKbT3QvVyv yEoEhLNAlWA0Xb4BMYKlkQVlye8QMYLzmAK6iK0fqSNlexoz0Sa/KWATr88vQLQzjI93 MlO1q7a9BcACgRmYT/hvvMh4BWADbX/EbV+MVQ+Lax51bHnc/qFHBCUzenGKEF8TzAeZ +dw3hG6rjk1XObwVEK2V9Ti1v9u+b9lL/rjqaY+g2YJGYLCvsCZYN6zeKrJgbu9tgYZW rSUw== Received: by 10.216.131.206 with SMTP id m56mr13522777wei.92.1332835712013; Tue, 27 Mar 2012 01:08:32 -0700 (PDT) Received: from [130.129.22.135] (dhcp-1687.meeting.ietf.org. [130.129.22.135]) by mx.google.com with ESMTPS id n15sm47590449wiw.6.2012.03.27.01.08.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 01:08:31 -0700 (PDT) Message-ID: <4F717578.5050008@gmail.com> Date: Tue, 27 Mar 2012 10:08:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: IPv6 Subject: MS/TP distinction host vs router? MS/TP device pingable? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:08:34 -0000 Just some comments on the MS/TP draft, of which I support advancement. Does MS/TP have any distinction between classes of devices? Something like Host vs Router? Something like multiply-interfaced machine vs. singly-interfaced? More powerful machine vs less powerful? Maybe this distinction could guide reservation of more than just 255 broadcast address (e.g. 254 all-hosts, 253 all-routers) further mapped into IPv6 multicast addresses. Another comment I had related to similarity to 6lowpan, which is good in general. But would it be possible to ping an MS/TP device from the Internet (ping end-to-end, no header compression). Just some comments. Alex From achatz@forthnetgroup.gr Tue Mar 27 01:09:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DFF21F8667 for ; Tue, 27 Mar 2012 01:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjdyOek1oHdo for ; Tue, 27 Mar 2012 01:09:34 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2B21F8664 for ; Tue, 27 Mar 2012 01:09:33 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2R89Sdl031026; Tue, 27 Mar 2012 11:09:28 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2R89Sh7005145; Tue, 27 Mar 2012 11:09:28 +0300 Received: from [130.129.21.212] (dhcp-15d4.meeting.ietf.org [130.129.21.212]) (authenticated bits=0) by MX-IN-02.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2R89ElE032287; Tue, 27 Mar 2012 11:09:15 +0300 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4F7175AC.3000501@forthnetgroup.gr> Date: Tue, 27 Mar 2012 10:09:16 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: jordi.palet@consulintel.es X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:09:35 -0000 Maybe i have misunderstood something, but how does DNS interfere with source address selection? I would go with option A. I would even prefer to limit even more the usage of temporary addresses, but that's another talk. -- Tassos On 27/3/2012 9:41 πμ, JORDI PALET MARTINEZ wrote: > Hi Brian, > > I think by default privacy addresses (option B) should be selected. > > It is up to applications that require "stable" addresses to force the > other way around, and a quick guess is that this kind of applications > already do it by means of selecting a DNS name that should typically have > already a global stable address. > > Regards, > Jordi > > > > > > > -----Mensaje original----- > De: Brian Haberman > Responder a: > Fecha: Tue, 27 Mar 2012 03:33:48 -0400 > Para: > Asunto: 3484bis and privacy addresses > >> All, >> The chairs would like to get a sense of the working group on >> changing the current (defined 3484) model of preferring public addresses >> over privacy addresses during the address selection process. RFC 3484 >> prefers public addresses with the ability (MAY) of an implementation to >> reverse the preference. The suggestion has been made to reverse that >> preference in 3484bis (prefer privacy addresses over public ones). >> Regardless, the document will allow implementers/users to reverse the >> default preference. >> >> Please state your preference for one of the following default >> options : >> >> A. Prefer public addresses over privacy addresses >> >> B. Prefer privacy addresses over public addresses >> >> Regards, >> Brian, Bob,& Ole >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From tsavo.stds@gmail.com Tue Mar 27 01:13:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276C521F8767 for ; Tue, 27 Mar 2012 01:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K82KpZdXts+7 for ; Tue, 27 Mar 2012 01:13:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7770121F879B for ; Tue, 27 Mar 2012 01:13:16 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so7401072pbb.31 for ; Tue, 27 Mar 2012 01:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Th6QlONf2IW7CDWrY5Nl0QqsODzkT14+HeOVw2urdMM=; b=KPsUZogL0hNbCDSOabFlMBbrtl6Fiw3F2UX7arvzjeeqzIqan6ai8iwo4R1Yem5XU8 ZBvtLbT71pr8noGuKKGK8cTWX9+rtVBn7foxVaGvf6+R1HocL+c6NltKhtBvCOeIdPcl yju+wcSsTtm3SjMFhC0V3QZ5aUZnj9Z/BY+zQ3dUB6t0phNL71/hXkSCVLAHNVosfBGP HLHPcNSqx7fqspP3a4xyVr2Pdx77hdnSJCBPFgjsryhrZuKfE6KvoOfIqFbLv6wUy5xc 1ZjtMyp4SeM/WsM3VIoQYPRWJ4Pa7eWTaB/xN/8DnBkhaYVORYMenWOG5QHbZPwEIBqL dvDw== MIME-Version: 1.0 Received: by 10.68.241.131 with SMTP id wi3mr60194000pbc.1.1332835996097; Tue, 27 Mar 2012 01:13:16 -0700 (PDT) Received: by 10.68.35.9 with HTTP; Tue, 27 Mar 2012 01:13:16 -0700 (PDT) In-Reply-To: <4F716D5C.40402@innovationslab.net> References: <4F716D5C.40402@innovationslab.net> Date: Tue, 27 Mar 2012 10:13:16 +0200 Message-ID: Subject: Re: 3484bis and privacy addresses From: Teemu Savolainen To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b3395af175c1804bc351061 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:13:17 -0000 --047d7b3395af175c1804bc351061 Content-Type: text/plain; charset=ISO-8859-1 Hi, I prefer B for reasons of avoiding privacy issues arising from using HW-based identifiers. Best regards, Teemu 27. maaliskuuta 2012 9.33 Brian Haberman kirjoitti: > All, > The chairs would like to get a sense of the working group on changing > the current (defined 3484) model of preferring public addresses over > privacy addresses during the address selection process. RFC 3484 prefers > public addresses with the ability (MAY) of an implementation to reverse the > preference. The suggestion has been made to reverse that preference in > 3484bis (prefer privacy addresses over public ones). Regardless, the > document will allow implementers/users to reverse the default preference. > > Please state your preference for one of the following default options : > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses > > Regards, > Brian, Bob, & Ole > ------------------------------**------------------------------**-------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/**listinfo/ipv6 > ------------------------------**------------------------------**-------- > --047d7b3395af175c1804bc351061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I prefer B for reasons of avoiding privacy issues arising from u= sing HW-based identifiers.

Best regards,

Teemu

27. maaliskuuta 2012 9.33 Brian Haberman <brian@innovationslab.ne= t> kirjoitti:
All,
=A0 =A0 The chairs would like to get a sense of the working group on chang= ing the current (defined 3484) model of preferring public addresses over pr= ivacy addresses during the address selection process. =A0RFC 3484 prefers p= ublic addresses with the ability (MAY) of an implementation to reverse the = preference. =A0The suggestion has been made to reverse that preference in 3= 484bis (prefer privacy addresses over public ones). Regardless, the documen= t will allow implementers/users to reverse the default preference.

=A0 =A0 Please state your preference for one of the following default opti= ons :

A. Prefer public addresses over privacy addresses

B. Prefer privacy addresses over public addresses

Regards,
Brian, Bob, & Ole
-------------------------------------------------------------= -------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------= -------

--047d7b3395af175c1804bc351061-- From Francis.Dupont@fdupont.fr Tue Mar 27 01:15:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5FD21F883B for ; Tue, 27 Mar 2012 01:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQLKczVuAgRN for ; Tue, 27 Mar 2012 01:15:03 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 7B03421F883A for ; Tue, 27 Mar 2012 01:15:02 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2R8F1Rf003030; Tue, 27 Mar 2012 10:15:01 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203270815.q2R8F1Rf003030@givry.fdupont.fr> From: Francis Dupont To: Brian Haberman Subject: Re: 3484bis and privacy addresses In-reply-to: Your message of Tue, 27 Mar 2012 03:33:48 EDT. <4F716D5C.40402@innovationslab.net> Date: Tue, 27 Mar 2012 10:15:01 +0200 Sender: Francis.Dupont@fdupont.fr Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:15:05 -0000 In your previous mail you wrote: > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses => I voted A but I have no strong opinion (I think the privacy addresses is a silly response to a silly concern. BTW as using the Free ISP 6rd I get a fixed /64 prefix with my fixed IPv4 address embedded in it, so privacy addresses can only bring trouble to me :-). My question is different and more for you as an IAB member: is this a chance to get the address selection document (currently RFC 3484) downgraded as a BCP (from its current standard track) so it will take less years to be updated the next time? Note it was known from beginning the RFC 3484 should have never been in the standard track, and it was obsolete as soon as being published... Thanks Francis.Dupont@fdupont.fr From prvs=1433caa07d=jordi.palet@consulintel.es Tue Mar 27 01:15:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0430B21F883D for ; Tue, 27 Mar 2012 01:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqOqDcgp1-oi for ; Tue, 27 Mar 2012 01:15:25 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by ietfa.amsl.com (Postfix) with ESMTP id 23DA921F8844 for ; Tue, 27 Mar 2012 01:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1332835950; x=1333440750; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=kKijG5L9Tfl2roUkGsC2uR1DG49KunXIOUmAbMlmCIU=; b=oYO 00Nd5UmnKhYj1ogEkMlyDsfOS41Kv7pkpV6YoRmlvBlnwXpCb/Gfm2m8miKvHdHv 7Tok1ApoB0PaPqr3LYq2bmwRj/NjWoJp+iHpXa+PvGtsE0IjG+9BnGWdA6An03Dl dGZT8/7tReo2ZDFN6UKcPyMgKUhhO6RVTGEOSkq0= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Ld5W+1o3qn+iy3jcv8BnvVPztpdbEV4DZMlKR/ZFBrb7r4Oqu4jTA/NkNUg4 RNBnD86hbS08qcQ8oMoHltJH1LjZYxtSj2cqIzXrprnRh2gxOBq/TD9bI Qyy6YO2KtRlDj3arC8p3B1TRQwf5b7shJioeqf+lB8f5SQMbXzKea8=; X-MDAV-Processed: consulintel.es, Tue, 27 Mar 2012 10:12:30 +0200 Received: from [130.129.81.5] by consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50004132570.msg for ; Tue, 27 Mar 2012 10:12:29 +0200 X-Spam-Processed: consulintel.es, Tue, 27 Mar 2012 10:12:29 +0200 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=dhcp-5105.meeting.ietf.org (ip=130.129.81.5) (consulintel.es) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:120327:md50004132570::NYpbKzLBBLDiWgLY:00001Gad X-MDRemoteIP: 130.129.81.5 X-Return-Path: prvs=1433caa07d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipv6@ietf.org User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 27 Mar 2012 10:15:14 +0200 Subject: Re: 3484bis and privacy addresses From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: 3484bis and privacy addresses In-Reply-To: <4F7175AC.3000501@forthnetgroup.gr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:15:26 -0000 That was my point, just to make sure that it is not misunderstood, I added the DNS comment as my expectation for apps requiring stable public addresses. Regards, Jordi -----Mensaje original----- De: Tassos Chatzithomaoglou Responder a: Fecha: Tue, 27 Mar 2012 10:09:16 +0200 Para: CC: Jordi Palet Martinez Asunto: Re: 3484bis and privacy addresses >Maybe i have misunderstood something, but how does DNS interfere with >source address selection? > >I would go with option A. >I would even prefer to limit even more the usage of temporary addresses, >but that's another talk. > >-- >Tassos > > >On 27/3/2012 9:41 $B&P&L(B, JORDI PALET MARTINEZ wrote: >> Hi Brian, >> >> I think by default privacy addresses (option B) should be selected. >> >> It is up to applications that require "stable" addresses to force the >> other way around, and a quick guess is that this kind of applications >> already do it by means of selecting a DNS name that should typically >>have >> already a global stable address. >> >> Regards, >> Jordi >> >> >> >> >> >> >> -----Mensaje original----- >> De: Brian Haberman >> Responder a: >> Fecha: Tue, 27 Mar 2012 03:33:48 -0400 >> Para: >> Asunto: 3484bis and privacy addresses >> >>> All, >>> The chairs would like to get a sense of the working group on >>> changing the current (defined 3484) model of preferring public >>>addresses >>> over privacy addresses during the address selection process. RFC 3484 >>> prefers public addresses with the ability (MAY) of an implementation to >>> reverse the preference. The suggestion has been made to reverse that >>> preference in 3484bis (prefer privacy addresses over public ones). >>> Regardless, the document will allow implementers/users to reverse the >>> default preference. >>> >>> Please state your preference for one of the following default >>> options : >>> >>> A. Prefer public addresses over privacy addresses >>> >>> B. Prefer privacy addresses over public addresses >>> >>> Regards, >>> Brian, Bob,& Ole >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >>confidential. The information is intended to be for the use of the >>individual(s) named above. If you are not the intended recipient be >>aware that any disclosure, copying, distribution or use of the contents >>of this information, including attached files, is prohibited. >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From mohacsi@niif.hu Tue Mar 27 01:17:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D4621F8542 for ; Tue, 27 Mar 2012 01:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCWlDchpiNwt for ; Tue, 27 Mar 2012 01:17:35 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id A334B21F8551 for ; Tue, 27 Mar 2012 01:17:31 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 7513A8794A; Tue, 27 Mar 2012 10:17:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id amfoui7DCNiD; Tue, 27 Mar 2012 10:17:24 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 4995887A84; Tue, 27 Mar 2012 10:17:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 483E887A81; Tue, 27 Mar 2012 10:17:24 +0200 (CEST) Date: Tue, 27 Mar 2012 10:17:24 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Brian Haberman Subject: Re: 3484bis and privacy addresses In-Reply-To: <4F716D5C.40402@innovationslab.net> Message-ID: References: <4F716D5C.40402@innovationslab.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:17:36 -0000 Dear All, option B prefered with RFC 4941 section 3.6 properly implemented as: " Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. .... Additionally, sites might wish to selectively enable or disable the use of temporary addresses for some prefixes. .... implementations SHOULD provide a way to enable and disable generation of temporary addresses for specific prefix subranges. This per- prefix setting SHOULD override the global settings on the node with respect to the specified prefix subranges. Note that the pre-prefix setting can be applied at any granularity, and not necessarily on a per-subnet basis. " Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director Network and Multimedia NIIF/HUNGARNET, HUNGARY Co-chair of Hungarian IPv6 Forum Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Tue, 27 Mar 2012, Brian Haberman wrote: > All, > The chairs would like to get a sense of the working group on changing > the current (defined 3484) model of preferring public addresses over privacy > addresses during the address selection process. RFC 3484 prefers public > addresses with the ability (MAY) of an implementation to reverse the > preference. The suggestion has been made to reverse that preference in > 3484bis (prefer privacy addresses over public ones). Regardless, the document > will allow implementers/users to reverse the default preference. > > Please state your preference for one of the following default options : > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses > > Regards, > Brian, Bob, & Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From tjc@ecs.soton.ac.uk Tue Mar 27 01:18:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68BD21F887F for ; Tue, 27 Mar 2012 01:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdZMj-ejTECE for ; Tue, 27 Mar 2012 01:18:07 -0700 (PDT) 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 1454D21F8880 for ; Tue, 27 Mar 2012 01:18:04 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2R8I1i8022774 for ; Tue, 27 Mar 2012 09:18:01 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2R8I1i8022774 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1332836281; bh=NfFPFRQLA9FnBqdiMEduzfJ+kqs=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=xJCu5IhI53TtpPQn20hkybA4XjZ5aebBnTYkHcsEqTvdscFnLR21RvMFlYjI9Q1ov F/YEdDK11OwjiEcJfqUoa15/JamVlivHEmNlfE7vjKXBza0Cy5hPwsmH9barNUDPuG XqdAylEa0uuycae5+IVmzSbC7qEUvY7D9BgMwpyM= 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 id o2Q9I10543714744Ck ret-id none; Tue, 27 Mar 2012 09:18:01 +0100 Received: from dhcp-11e4.meeting.ietf.org (dhcp-11e4.meeting.ietf.org [130.129.17.228]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2R8HXwx029481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 27 Mar 2012 09:17:33 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: 3484bis and privacy addresses From: Tim Chown In-Reply-To: <4F7175AC.3000501@forthnetgroup.gr> Date: Tue, 27 Mar 2012 09:17:32 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4F7175AC.3000501@forthnetgroup.gr> <5AE55220-0A3A-44C1-BC20-A502FF252E52@ecs.soton.ac.uk> To: 6man Mailing List X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2Q9I1054371474400; tid=o2Q9I10543714744Ck; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2R8I1i8022774 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:18:10 -0000 I would like to see B; which would reflect common practice in the -bis = RFC, but allow the default to be changed. Nothing precludes a host using privacy addresses also having a = static/DNS registered address it's reachable by, but as Tassos says = that's not the topic for the vote. Tim On 27 Mar 2012, at 09:09, Tassos Chatzithomaoglou wrote: > Maybe i have misunderstood something, but how does DNS interfere with = source address selection? >=20 > I would go with option A. > I would even prefer to limit even more the usage of temporary = addresses, but that's another talk. >=20 > -- > Tassos >=20 >=20 > On 27/3/2012 9:41 =CF=80=CE=BC, JORDI PALET MARTINEZ wrote: >> Hi Brian, >>=20 >> I think by default privacy addresses (option B) should be selected. >>=20 >> It is up to applications that require "stable" addresses to force the >> other way around, and a quick guess is that this kind of applications >> already do it by means of selecting a DNS name that should typically = have >> already a global stable address. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Mensaje original----- >> De: Brian Haberman >> Responder a: >> Fecha: Tue, 27 Mar 2012 03:33:48 -0400 >> Para: >> Asunto: 3484bis and privacy addresses >>=20 >>> All, >>> The chairs would like to get a sense of the working group on >>> changing the current (defined 3484) model of preferring public = addresses >>> over privacy addresses during the address selection process. RFC = 3484 >>> prefers public addresses with the ability (MAY) of an implementation = to >>> reverse the preference. The suggestion has been made to reverse = that >>> preference in 3484bis (prefer privacy addresses over public ones). >>> Regardless, the document will allow implementers/users to reverse = the >>> default preference. >>>=20 >>> Please state your preference for one of the following default >>> options : >>>=20 >>> A. Prefer public addresses over privacy addresses >>>=20 >>> B. Prefer privacy addresses over public addresses >>>=20 >>> Regards, >>> Brian, Bob,& Ole >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From roland.bless@kit.edu Tue Mar 27 01:29:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1C21F8847 for ; Tue, 27 Mar 2012 01:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o17LfWW6VL4y for ; Tue, 27 Mar 2012 01:29:27 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 784D621F87EF for ; Tue, 27 Mar 2012 01:29:27 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1SCRm4-0000Xi-6g for ; Tue, 27 Mar 2012 10:29:26 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 for id 1SCRm4-0003Rp-2r; Tue, 27 Mar 2012 10:29:04 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id DC462A806A8 for ; Tue, 27 Mar 2012 10:29:03 +0200 (CEST) Message-ID: <4F717A4F.8020802@kit.edu> Date: Tue, 27 Mar 2012 10:29:03 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> In-Reply-To: <4F716D5C.40402@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1332836966.624989000 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:29:28 -0000 Hi, On 27.03.2012 09:33, Brian Haberman wrote: > Please state your preference for one of the following default options : > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses I prefer option B. Regards, Roland From samita.chakrabarti@ericsson.com Tue Mar 27 01:34:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1921F88DA for ; Tue, 27 Mar 2012 01:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5dv0C1KSeFo for ; Tue, 27 Mar 2012 01:34:46 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8181E21F88D9 for ; Tue, 27 Mar 2012 01:34:46 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2R8Yj2S028291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Mar 2012 03:34:45 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 27 Mar 2012 04:34:44 -0400 From: Samita Chakrabarti To: Brian Haberman , "ipv6@ietf.org" Date: Tue, 27 Mar 2012 04:34:42 -0400 Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: Ac0L6/qu7UcGfdbCSQ6t3Mduua528wAB575w Message-ID: <16D60F43CA0B724F8052D7E9323565D72AB0B33D6D@EUSAACMS0715.eamcs.ericsson.se> References: <4F716D5C.40402@innovationslab.net> In-Reply-To: <4F716D5C.40402@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:34:47 -0000 Option A (with ability to configure privacy as preferred). -Samita=20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bri= an Haberman Sent: Tuesday, March 27, 2012 12:34 AM To: ipv6@ietf.org Subject: 3484bis and privacy addresses All, The chairs would like to get a sense of the working group on changing= the current (defined 3484) model of preferring public addresses over priva= cy addresses during the address selection process. RFC 3484 prefers public= addresses with the ability (MAY) of an implementation to reverse the prefe= rence. The suggestion has been made to reverse that preference in 3484bis = (prefer privacy addresses over public ones).=20 Regardless, the document will allow implementers/users to reverse the defau= lt preference. Please state your preference for one of the following default options= : A. Prefer public addresses over privacy addresses B. Prefer privacy addresses over public addresses Regards, Brian, Bob, & Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From evyncke@cisco.com Tue Mar 27 01:38:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAFC21F890C for ; Tue, 27 Mar 2012 01:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.442 X-Spam-Level: X-Spam-Status: No, score=-10.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKavYMmvEgax for ; Tue, 27 Mar 2012 01:38:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6E21F889D for ; Tue, 27 Mar 2012 01:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=1647; q=dns/txt; s=iport; t=1332837492; x=1334047092; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=PFb4M+MYSSz60lyq54m6XUqjKN5OdfWyGUiKr4PsBcc=; b=TZ3/v76lrLmKnWVFyaunQBVWi9BylKD4izEbe8ZX2sFDUYEDiOI6CCB9 +B6CHhJ5ZDpnQeERUpYhS5SVjgQbOQtHs5rWzmTXvudcuEdVjUd8JpUUw Nb17zjseX43wynUqIC/A/pU4Ob6onQlGU9rvYvLWGhVTL1CVXOldpXQPu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEF8cU+Q/khL/2dsb2JhbABFuEiBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHaAuaOZ8TBJAsYwSkJoFogmk X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="133446531" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 08:37:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2R8bmU8020999; Tue, 27 Mar 2012 08:37:48 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 10:37:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3484bis and privacy addresses Date: Tue, 27 Mar 2012 10:37:45 +0200 Message-ID: <317616CE96204D49B5A1811098BA895006F34568@XMB-AMS-110.cisco.com> In-Reply-To: <4F716D5C.40402@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3484bis and privacy addresses Thread-Index: Ac0L6/6W1tDhCkkBQKmDG+Sxn7XumQACE+Cw References: <4F716D5C.40402@innovationslab.net> From: "Eric Vyncke (evyncke)" To: "Brian Haberman" , X-OriginalArrivalTime: 27 Mar 2012 08:37:48.0698 (UTC) FILETIME=[E3E517A0:01CD0BF4] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:38:13 -0000 I prefer A. (public address is to be preferred) Whatever the final choice will be, I would like 3484bis to allow the policy setting to be reversed. BTW, my choice is based on: - privacy is anyway given away with cookies, HTTP headers such as User-Agent string - stable address is key for audit-trail (so Fernando's proposal is useful here) > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian Haberman > Sent: mardi 27 mars 2012 09:34 > To: ipv6@ietf.org > Subject: 3484bis and privacy addresses >=20 > All, > The chairs would like to get a sense of the working group on changing > the current (defined 3484) model of preferring public addresses over privacy > addresses during the address selection process. RFC 3484 prefers public > addresses with the ability (MAY) of an implementation to reverse the > preference. The suggestion has been made to reverse that preference in > 3484bis (prefer privacy addresses over public ones). > Regardless, the document will allow implementers/users to reverse the > default preference. >=20 > Please state your preference for one of the following default options > : >=20 > A. Prefer public addresses over privacy addresses >=20 > B. Prefer privacy addresses over public addresses >=20 > Regards, > Brian, Bob, & Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From simon.perreault@viagenie.ca Tue Mar 27 01:44:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF9F21F87EF for ; Tue, 27 Mar 2012 01:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQaUWwIgnzmA for ; Tue, 27 Mar 2012 01:44:06 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CD93521F88C2 for ; Tue, 27 Mar 2012 01:44:05 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2001:df8:0:16:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E662840054 for ; Tue, 27 Mar 2012 04:44:04 -0400 (EDT) Message-ID: <4F717DD3.7030907@viagenie.ca> Date: Tue, 27 Mar 2012 10:44:03 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> In-Reply-To: <4F716D5C.40402@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:44:06 -0000 Brian Haberman wrote, on 03/27/2012 09:33 AM: > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses I prefer B. I don't buy the "HTTP cookies already give us away" argument. Privacy at all levels of the stack is good. (I randomize my L2 MAC at boot time, lots of fun!) If we have good privacy at L3, then we "only" have L7 left to fix. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alex@technicalenlightenment.com Tue Mar 27 02:28:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3226321F8841 for ; Tue, 27 Mar 2012 02:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIfNGsXnJ6Lq for ; Tue, 27 Mar 2012 02:28:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8757821F853B for ; Tue, 27 Mar 2012 02:28:58 -0700 (PDT) Received: by iazz13 with SMTP id z13so11308237iaz.31 for ; Tue, 27 Mar 2012 02:28:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=XKVlAb2iYmXVt0AA8BlKwsV+LqOSy3ETOV+h2PXR69k=; b=dy00HSZoz0W4JWGV1yBWxuAnFd/ukUKELbT38+oNsk1uqDUDsD8lRkSA8CsNs7j1Nc M5IXM/lf0kIjVi+R09TqmzMZfmd5TggiZgKq6yxFQp468K3xOAMiwMF9ccalzL7jVaXx yzWMUU+o9HzTHzAk/XVwA/dzlRvhafn13kJixBtLrnf809aRCsSG6oxNNUYDeCEiXfDD SimR8U5o41mZESbMoKMfOdmIEhaYmLRp7x9DlspZ5p5OajgseUmYhgjURgCMkr+Lwx0m VHLG2iprwschqBp4a4xVW+ht5NEzYJN54E1snIWPS1Y9jB6/rub9Nbi6xn4dtO68Btjp fz6g== MIME-Version: 1.0 Received: by 10.50.222.162 with SMTP id qn2mr7950991igc.65.1332840538127; Tue, 27 Mar 2012 02:28:58 -0700 (PDT) Received: by 10.42.247.198 with HTTP; Tue, 27 Mar 2012 02:28:58 -0700 (PDT) X-Originating-IP: [94.193.97.134] In-Reply-To: <4F717DD3.7030907@viagenie.ca> References: <4F716D5C.40402@innovationslab.net> <4F717DD3.7030907@viagenie.ca> Date: Tue, 27 Mar 2012 05:28:58 -0400 Message-ID: Subject: Re: 3484bis and privacy addresses From: Alex Abrahams To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=14dae9340fbfd13e1804bc361e0a X-Gm-Message-State: ALoCoQlKFRuvk6ZX5JYY+tEvJsnUggIMGdbYvBMJ6mnUX/S86rYpKrA6Z3zywQQZqKf5tsOcOo5a X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:28:59 -0000 --14dae9340fbfd13e1804bc361e0a Content-Type: text/plain; charset=ISO-8859-1 I also prefer B. I haven't decided if I'll use privacy addresses myself, but I think: a) I don't want to assume the working life of cookies and even http is the same as ipv6, don't want it to drive this decision (I'm not advocating a return to gopher ;) ) b) I'd like IP logs to be just that, something to be looked after, but not something I have law after law to think about, changing country to country, because .gov think I am tracking people. (e.g. You can't log IPs centrally because that is personal data, which can't leave the country) I'm not saying tracking people is good or bad (not going there), just that I want to be free of that kind of oversight as much as possible. Alex --14dae9340fbfd13e1804bc361e0a Content-Type: text/html; charset=ISO-8859-1 I also prefer B. I haven't decided if I'll use privacy addresses myself, but I think:
a) I don't want to assume the working life of cookies and even http is the same as ipv6, don't want it to drive this decision (I'm not advocating a return to gopher ;) )

b) I'd like IP logs to be just that, something to be looked after, but not something I have law after law to think about, changing country to country, because .gov think I am tracking people. (e.g. You can't log IPs centrally because that is personal data, which can't leave the country) I'm not saying tracking people is good or bad (not going there), just that I want to be free of that kind of oversight as much as possible.

Alex
--14dae9340fbfd13e1804bc361e0a-- From achatz@forthnetgroup.gr Tue Mar 27 02:30:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7221E8104 for ; Tue, 27 Mar 2012 02:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3BYOkCq1hvx for ; Tue, 27 Mar 2012 02:30:36 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAE921F8891 for ; Tue, 27 Mar 2012 02:30:35 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2R9UYH9029083 for ; Tue, 27 Mar 2012 12:30:34 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2R9UY1e019531 for ; Tue, 27 Mar 2012 12:30:34 +0300 Received: from [130.129.21.212] (dhcp-15d4.meeting.ietf.org [130.129.21.212]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2R9UJoa018274; Tue, 27 Mar 2012 12:30:21 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4F71889D.6030208@forthnetgroup.gr> Date: Tue, 27 Mar 2012 11:30:05 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: question about draft-gont-6man-oversized-header-chain-00 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:30:36 -0000 i was wondering, is there any actual (from a production network, not created on purpose in a lab) sample ipv6 traffic showing an ipv6 header comprising of two or more packets? -- Tassos From Tina.Tsou.Zouting@huawei.com Tue Mar 27 02:30:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3498721E8114 for ; Tue, 27 Mar 2012 02:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+e4AQIpYujH for ; Tue, 27 Mar 2012 02:30:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6094321E8103 for ; Tue, 27 Mar 2012 02:30:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AES61558; Tue, 27 Mar 2012 05:30:37 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Mar 2012 02:27:39 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Mar 2012 02:27:41 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 27 Mar 2012 17:27:35 +0800 From: Tina TSOU To: Simon Perreault Subject: Re: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNC+wAYL2lbsoodEGxVsz4QJU2+JZ9TZGAgACSRb8= Date: Tue, 27 Mar 2012 09:27:35 +0000 Message-ID: <7D8AB830-FA51-4E1B-BFF3-E525A7C9D3B2@huawei.com> References: <4F716D5C.40402@innovationslab.net>, <4F717DD3.7030907@viagenie.ca> In-Reply-To: <4F717DD3.7030907@viagenie.ca> Accept-Language: en-US, zh-CN 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 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:30:38 -0000 B for me. Sent from my iPad On Mar 27, 2012, at 10:44 AM, "Simon Perreault" wrote: > Brian Haberman wrote, on 03/27/2012 09:33 AM: >> A. Prefer public addresses over privacy addresses >>=20 >> B. Prefer privacy addresses over public addresses >=20 > I prefer B. >=20 > I don't buy the "HTTP cookies already give us away" argument. Privacy at = all > levels of the stack is good. (I randomize my L2 MAC at boot time, lots of= fun!) > If we have good privacy at L3, then we "only" have L7 left to fix. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Carl.Wuyts@technicolor.com Tue Mar 27 01:49:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F36921F880B for ; Tue, 27 Mar 2012 01:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Uw7iab-SPg2 for ; Tue, 27 Mar 2012 01:49:06 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3E21F8802 for ; Tue, 27 Mar 2012 01:49:03 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT3F+/insiscQuzxbznnRJPifmfw1X+lT@postini.com; Tue, 27 Mar 2012 01:49:06 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 27 Mar 2012 10:48:18 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Tue, 27 Mar 2012 10:48:27 +0200 From: Wuyts Carl To: Francis Dupont , Brian Haberman Date: Tue, 27 Mar 2012 10:48:25 +0200 Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: Ac0L8buKnXhzFC3+TUqmnxG4+ZJ/+wABJyjg Message-ID: <867F4B6A1672E541A94676D556793ACD0EB9995616@MOPESMBX01.eu.thmulti.com> References: Your message of Tue, 27 Mar 2012 03:33:48 EDT. <4F716D5C.40402@innovationslab.net> <201203270815.q2R8F1Rf003030@givry.fdupont.fr> In-Reply-To: <201203270815.q2R8F1Rf003030@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 27 Mar 2012 02:45:40 -0700 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:49:07 -0000 +1 for option A Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Fra= ncis Dupont Sent: dinsdag 27 maart 2012 10:15 To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses=20 In your previous mail you wrote: > A. Prefer public addresses over privacy addresses > =20 > B. Prefer privacy addresses over public addresses =3D> I voted A but I have no strong opinion (I think the privacy addresses = is a silly response to a silly concern. BTW as using the Free ISP 6rd I get= a fixed /64 prefix with my fixed IPv4 address embedded in it, so privacy a= ddresses can only bring trouble to me :-). My question is different and more for you as an IAB member: is this a chanc= e to get the address selection document (currently RFC 3484) downgraded as = a BCP (from its current standard track) so it will take less years to be up= dated the next time? Note it was known from beginning the RFC 3484 should have never been in the= standard track, and it was obsolete as soon as being published... Thanks Francis.Dupont@fdupont.fr -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From kauer@biplane.com.au Tue Mar 27 03:23:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1A821F8959 for ; Tue, 27 Mar 2012 03:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o41Nbb4wVMXd for ; Tue, 27 Mar 2012 03:23:16 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id B3EE921F8964 for ; Tue, 27 Mar 2012 03:23:14 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAHeUcU+WZX+7/2dsb2JhbAANN4VAthgBAQEEI2YLGCoCAlcZr1mSC41rggyBGAShFYd0 Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.207]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 27 Mar 2012 20:53:12 +1030 Subject: Re: 3484bis and privacy addresses From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F716D5C.40402@innovationslab.net> References: <4F716D5C.40402@innovationslab.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tke+2BqxZ+4pF/Ekp0KM" Date: Tue, 27 Mar 2012 21:23:10 +1100 Message-ID: <1332843790.2641.779.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:23:16 -0000 --=-tke+2BqxZ+4pF/Ekp0KM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-03-27 at 03:33 -0400, Brian Haberman wrote: > Please state your preference for one of the following default=20 > options : >=20 > A. Prefer public addresses over privacy addresses >=20 > B. Prefer privacy addresses over public addresses B. While I realise that the Argument From Personal Ignorance is not very convincing, I am having a very hard time imagining why anyone would turn on privacy addresses, then prefer non-privacy addresses... Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-tke+2BqxZ+4pF/Ekp0KM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk9xlQcACgkQFpl7eE7uYBczzQD9EUlMgmWTLCguK4OfrhmveyCY H0FEZdXvBBiNK7HjjGoA/0XNlkD+f+kubsfCue2B90VU+tHhzkTSxbaPxfW5dByI =D7Lt -----END PGP SIGNATURE----- --=-tke+2BqxZ+4pF/Ekp0KM-- From kauer@biplane.com.au Tue Mar 27 03:40:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953D921E814E for ; Tue, 27 Mar 2012 03:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da-nG8t7oDjx for ; Tue, 27 Mar 2012 03:40:55 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id A831321F89BD for ; Tue, 27 Mar 2012 03:40:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAPGXcU+WZX+7/2dsb2JhbAANN4VAthkBAQEEI2YLGCoCAlcZr1eSDY1rggyBGAShFYd0 Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.207]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 27 Mar 2012 21:10:53 +1030 Subject: Re: 3484bis and privacy addresses From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F716D5C.40402@innovationslab.net> References: <4F716D5C.40402@innovationslab.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tke+2BqxZ+4pF/Ekp0KM" Date: Tue, 27 Mar 2012 21:23:10 +1100 Message-ID: <1332843790.2641.779.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:40:55 -0000 --=-tke+2BqxZ+4pF/Ekp0KM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-03-27 at 03:33 -0400, Brian Haberman wrote: > Please state your preference for one of the following default=20 > options : >=20 > A. Prefer public addresses over privacy addresses >=20 > B. Prefer privacy addresses over public addresses B. While I realise that the Argument From Personal Ignorance is not very convincing, I am having a very hard time imagining why anyone would turn on privacy addresses, then prefer non-privacy addresses... Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-tke+2BqxZ+4pF/Ekp0KM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk9xlQcACgkQFpl7eE7uYBczzQD9EUlMgmWTLCguK4OfrhmveyCY H0FEZdXvBBiNK7HjjGoA/0XNlkD+f+kubsfCue2B90VU+tHhzkTSxbaPxfW5dByI =D7Lt -----END PGP SIGNATURE----- --=-tke+2BqxZ+4pF/Ekp0KM-- From kauer@biplane.com.au Tue Mar 27 03:40:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C1321E814E for ; Tue, 27 Mar 2012 03:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjuIjNTYMkan for ; Tue, 27 Mar 2012 03:40:55 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDE321E8143 for ; Tue, 27 Mar 2012 03:40:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAPGXcU+WZX+7/2dsb2JhbAANN4VAthkBAQEEI2YLGCoCAlcZr1eSDY1rggyBGAShFYd0 Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.207]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 27 Mar 2012 21:10:55 +1030 Subject: Re: 3484bis and privacy addresses From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F716D5C.40402@innovationslab.net> References: <4F716D5C.40402@innovationslab.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UZzI3c+7OF8bep1NWitY" Date: Tue, 27 Mar 2012 21:40:49 +1100 Message-ID: <1332844849.2641.800.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:40:56 -0000 --=-UZzI3c+7OF8bep1NWitY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-03-27 at 03:33 -0400, Brian Haberman wrote: > Please state your preference for one of the following default=20 > options : >=20 > A. Prefer public addresses over privacy addresses >=20 > B. Prefer privacy addresses over public addresses B. While I realise that the Argument From Personal Ignorance is not very convincing, I am having a very hard time imagining why anyone would turn on privacy addresses, then prefer non-privacy addresses... Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-UZzI3c+7OF8bep1NWitY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk9xmTEACgkQFpl7eE7uYBfgfwEAnUPBlSne0u1XcGTRHx9osBQC 5ULBbR+G75nHkG+kL/QBAInl6ste3KLkRQUflDSjao8d6deSRn0XiaY+hoBOCEsy =tmr5 -----END PGP SIGNATURE----- --=-UZzI3c+7OF8bep1NWitY-- From achatz@forthnetgroup.gr Tue Mar 27 04:47:11 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346CC21F8967 for ; Tue, 27 Mar 2012 04:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH5vmC3e0B1d for ; Tue, 27 Mar 2012 04:47:10 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA6621F8955 for ; Tue, 27 Mar 2012 04:47:09 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2RBl8xR002395 for ; Tue, 27 Mar 2012 14:47:08 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q2RBl8HQ020718 for ; Tue, 27 Mar 2012 14:47:08 +0300 Received: from [130.129.21.212] (dhcp-15d4.meeting.ietf.org [130.129.21.212]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2RBksfZ010655; Tue, 27 Mar 2012 14:46:56 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4F71A8AF.2020905@forthnetgroup.gr> Date: Tue, 27 Mar 2012 13:46:55 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: comments about draft-ietf-6man-dad-proxy-02 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:47:11 -0000 Some questions/comments about this draft: 1) I think it should be better to provide an alternative terminology in order to better describe the topology, like hub and spokes or root and leaf(s). 2) IPv6 over PPP is not affected and should probably be mentioned. 3) Under 4.2.2, i believe there is a mixup of CPE states. i.e. according to the following, CPE1 has already a cache entry The BNG then has to verify whether there is a real conflict by checking if the CPE whose IPv6 address is in the entry is still connected. In the following, we will call IPv6-CPE1 the IPv6 address of the existing entry, Link- layer-CPE1 the Link-layer address of that entry and Link-layer-CPE2 the Link-layer address of the CPE which is performing DAD, which is different from Link-layer-CPE1. but then, the following paragraphs talk about different CPE1 cache states. If IPv6-CPE1 is in the Neighbor Cache, but it is associated with another Link-layer address than Link-layer-CPE1... If IPv6-CPE1 is not in the Neighbor Cache... The last one surely contradicts the "we will call IPv6-CPE1 the IPv6 address of the existing entry" statement. It also seems a little bit confusing to me. 4) If IPv6-CPE1 is in the Neighbor Cache, but it is associated with another Link-layer address than Link-layer-CPE1, that means that there is possibly a conflict with another CPE, but that CPE did not perform DAD. This situation is out of the scope of this document, since one assumption made above is that all the nodes of a point-to-multipoint domain (except the DAD proxy itself) perform DAD. This case could be covered in the future by additional solutions that work in conjunction with the DAD proxy. Would it be an intermediate solution to delete all "possibly wrong" entries and/or log an error message? -- Tassos From fgont@si6networks.com Tue Mar 27 05:43:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F22A21E8170 for ; Tue, 27 Mar 2012 05:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS+PcL5msCEN for ; Tue, 27 Mar 2012 05:43:20 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7A64F21F895D for ; Tue, 27 Mar 2012 05:43:20 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCVk0-0002n3-9w; Tue, 27 Mar 2012 14:43:12 +0200 Message-ID: <4F71B5E2.5000400@si6networks.com> Date: Tue, 27 Mar 2012 14:43:14 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Brian Haberman Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> In-Reply-To: <4F716D5C.40402@innovationslab.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:43:21 -0000 On 03/27/2012 09:33 AM, Brian Haberman wrote: > All, > The chairs would like to get a sense of the working group on > changing the current (defined 3484) model of preferring public addresses > over privacy addresses during the address selection process. Brian: Terminology issue here: Are "public addresses" a short hand for "IPv6 addresses with Modified EUI-64 format identifiers"? -- I ask because all of these addresses are public. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Francis.Dupont@fdupont.fr Tue Mar 27 05:48:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CC221F87D1 for ; Tue, 27 Mar 2012 05:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEAzZiFm99u7 for ; Tue, 27 Mar 2012 05:48:15 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id C9DC321F87CD for ; Tue, 27 Mar 2012 05:48:14 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2RCmDLE021381; Tue, 27 Mar 2012 14:48:13 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203271248.q2RCmDLE021381@givry.fdupont.fr> From: Francis Dupont To: Fernando Gont Subject: Re: 3484bis and privacy addresses In-reply-to: Your message of Tue, 27 Mar 2012 14:43:14 +0200. <4F71B5E2.5000400@si6networks.com> Date: Tue, 27 Mar 2012 14:48:13 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:48:15 -0000 In your previous mail you wrote: > Brian: Terminology issue here: Are "public addresses" a short hand for > "IPv6 addresses with Modified EUI-64 format identifiers"? -- I ask > because all of these addresses are public. => IMHO public is not RFC 4941 "private". The draft is clearer... Regards Francis.Dupont@fdupont.fr From fgont@si6networks.com Tue Mar 27 05:57:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC621E8098 for ; Tue, 27 Mar 2012 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ+DWtxoA+io for ; Tue, 27 Mar 2012 05:57:51 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8493E21E81F0 for ; Tue, 27 Mar 2012 05:57:31 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCVxk-0002tn-N6; Tue, 27 Mar 2012 14:57:24 +0200 Message-ID: <4F71B938.7030300@si6networks.com> Date: Tue, 27 Mar 2012 14:57:28 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Meta comment about "3484bis and privacy addresses" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:57:52 -0000 Folks, I think that one error in which we have incurred at least in the couple of years (myself included) is that we focus our discussion on "mac-derived addresses vs privacy addresses" when the question should really be about "stable addresses vs. temporary addresses". Clearly, we don't want any privacy issues (whether temporary or not), and we should do something such that all addresses do not have any privacy issues. (FWIW, this is my proposal to tackle the problem of the privacy issues arising from our current "stable" mac-derived addresses). It is also clear that some folks may be arguing in favor of temporary addresses (RFC 4941) for the wrong reasons (albeit understandable): because we lack of stable addresses that do not have privacy issues. So I tend to think that our debate should probably be about "stable vs. temporary addresses", but our discussion is kind of blinded by the fact that we currently only have "stable but privacy-harmful addresses" on one hand, and "temporary and privacy-improved addresses" on the other. *This* fact is what has turned our discussion into being about "public versus privacy address", when it shouldn't: privacy should never be compromised. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Mar 27 06:26:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D020B21E8088 for ; Tue, 27 Mar 2012 06:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ-8yFjfoBvX for ; Tue, 27 Mar 2012 06:26:19 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 442FA21E809D for ; Tue, 27 Mar 2012 06:26:19 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCWPa-00037T-CV; Tue, 27 Mar 2012 15:26:10 +0200 Message-ID: <4F71BFF6.2080904@si6networks.com> Date: Tue, 27 Mar 2012 15:26:14 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Tassos Chatzithomaoglou Subject: Re: question about draft-gont-6man-oversized-header-chain-00 References: <4F71889D.6030208@forthnetgroup.gr> In-Reply-To: <4F71889D.6030208@forthnetgroup.gr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:26:19 -0000 On 03/27/2012 11:30 AM, Tassos Chatzithomaoglou wrote: > i was wondering, is there any actual (from a production network, not > created on purpose in a lab) sample ipv6 traffic showing an ipv6 header > comprising of two or more packets? No. That's exactly the point: such traffic does not occur in practice, but since it is allowed by the specifications, can still be used by attacker for malicious purposes (that is, evading security controls). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Mar 27 06:27:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B47A21E808E for ; Tue, 27 Mar 2012 06:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMQaJFuZl7cy for ; Tue, 27 Mar 2012 06:27:52 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BCBD321E808A for ; Tue, 27 Mar 2012 06:27:52 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCWR2-00038Z-3W; Tue, 27 Mar 2012 15:27:40 +0200 Message-ID: <4F71C050.3010208@si6networks.com> Date: Tue, 27 Mar 2012 15:27:44 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Karl Auer Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <1332844849.2641.800.camel@karl> In-Reply-To: <1332844849.2641.800.camel@karl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:27:53 -0000 On 03/27/2012 12:40 PM, Karl Auer wrote: > While I realise that the Argument From Personal Ignorance is not very > convincing, I am having a very hard time imagining why anyone would turn > on privacy addresses, then prefer non-privacy addresses... They don't. Some operating systems enable them by default. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From zhou.sujing@zte.com.cn Tue Mar 27 06:52:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D612221F897F for ; Tue, 27 Mar 2012 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.046 X-Spam-Level: X-Spam-Status: No, score=-99.046 tagged_above=-999 required=5 tests=[AWL=2.792, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+ng4MM9SvRD for ; Tue, 27 Mar 2012 06:52:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFB621F88C8 for ; Tue, 27 Mar 2012 06:52:36 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801320096835; Tue, 27 Mar 2012 21:16:32 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 34335.1881878302; Tue, 27 Mar 2012 21:52:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2RDqGB0025801; Tue, 27 Mar 2012 21:52:16 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4F71B938.7030300@si6networks.com> To: "ipv6@ietf.org" Subject: about security level evaluation of draft-zhou-6man-mhash-cga-00 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 27 Mar 2012 14:52:13 +0100 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-27 21:52:20, Serialize complete at 2012-03-27 21:52:20 Content-Type: multipart/alternative; boundary="=_alternative 004C335CC12579CE_=" X-MAIL: mse02.zte.com.cn q2RDqGB0025801 Cc: jari.arkko@ericsson.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:52:39 -0000 This is a multipart message in MIME format. --=_alternative 004C335CC12579CE_= Content-Type: text/plain; charset="US-ASCII" In response to coments on draft draft-zhou-6man-mhash-cga-00 1. It can be referred to RFC3972 section 7.2 "This increases the cost of address generation approximately by a factor of 2^(16*Sec). It also increases the cost of brute-force attacks by the same factor. That is, the cost of creating a CGA Parameters data structure that binds the attacker's public key with somebody else's address is increased from O(2^59) to O(2^(59+16*Sec)). The address generator may choose the security parameter Sec depending on its own computational capacity, the perceived risk of attacks, and the expected lifetime of the address. Currently, Sec values between 0 and 2 are sufficient for most IPv6 nodes. As computers become faster, higher Sec values will slowly become useful." So though hash output length and sec parameter are two different things, they can be added together to evaluate as a whole. If have doubts, I suggest ask CFRG people to consider it. 2. when consider computation part for good guys, since it has been suggested to use high sec value, 2^(16*sec) is already to big work to do (when sec=3, cost thousands of hours ), so it is not distinguish with plus 3. And it has already been proposed to delegate the generation of CGA to a third party when using high sec. --=_alternative 004C335CC12579CE_= Content-Type: text/html; charset="US-ASCII"
In response to coments on draft draft-zhou-6man-mhash-cga-00

1. It can be referred to RFC3972 section 7.2
"This increases the cost of address generation approximately by
   a factor of 2^(16*Sec).  It also increases the cost of brute-force
   attacks by the same factor.  That is, the cost of creating a CGA
   Parameters data structure that binds the attacker's public key with
   somebody else's address is increased from O(2^59) to
   O(2^(59+16*Sec)).  The address generator may choose the security
   parameter Sec depending on its own computational capacity, the
   perceived risk of attacks, and the expected lifetime of the address.
   Currently, Sec values between 0 and 2 are sufficient for most IPv6
   nodes.  As computers become faster, higher Sec values will slowly
   become useful."

So though hash output length and sec parameter are two different things, they
can be added together to evaluate as a whole.

If have doubts, I suggest ask CFRG people to consider it.

2. when consider computation part for good guys, since it has been suggested to use high sec
value, 2^(16*sec) is already to big work to do
(when sec=3, cost thousands of hours ), so it is not distinguish with plus 3.
And it has already been proposed to delegate the generation of CGA to a third party when using high sec.
 
--=_alternative 004C335CC12579CE_=-- From jonghyouk@gmail.com Tue Mar 27 07:16:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2F21F881B for ; Tue, 27 Mar 2012 07:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvR0TtTM59kC for ; Tue, 27 Mar 2012 07:16:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10DFD21F8817 for ; Tue, 27 Mar 2012 07:16:45 -0700 (PDT) Received: by iazz13 with SMTP id z13so11703348iaz.31 for ; Tue, 27 Mar 2012 07:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CEn4bkKAXsL2fQiwb0ZcFznPWT8rw6EX28ykWvpgqNw=; b=jRIQJ4qXZu+au02zTRvdWgrAC79xNcU7cv69NjmdWTSJ9tngzIg0K75Hl22tsBUVGq NH1hqEOfiDgInMjm0fgq4CrMjCMAs8Rgu8SdHOdOiGc9EVGF1qHBET0/zLIau1VeGsi6 LzhiWnn9lZUlZRISlHlFx6PGxQfdEBzXq26aIS27eCWR7HuFuR0VCPUUqT6nOHU1EFGP YE51XKAsB85SvAqENKm6zst82PW/IpgK2PEKbxpc197OUi5PsnQnE/zfGM3b4V7ZUB9I ulrJydzP0NDR24SqOBdPt5Vgfp2uTwjyE5/kUVFaZUl2Ed3yHS2Wg7VnryOPECD1owwe 2gBA== MIME-Version: 1.0 Received: by 10.50.195.131 with SMTP id ie3mr8704135igc.52.1332857805664; Tue, 27 Mar 2012 07:16:45 -0700 (PDT) Received: by 10.64.30.200 with HTTP; Tue, 27 Mar 2012 07:16:45 -0700 (PDT) In-Reply-To: <4F71C050.3010208@si6networks.com> References: <4F716D5C.40402@innovationslab.net> <1332844849.2641.800.camel@karl> <4F71C050.3010208@si6networks.com> Date: Tue, 27 Mar 2012 16:16:45 +0200 Message-ID: Subject: Re: 3484bis and privacy addresses From: Jong-Hyouk Lee To: Fernando Gont Content-Type: multipart/alternative; boundary=14dae9340fc90af23e04bc3a240f Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:16:47 -0000 --14dae9340fc90af23e04bc3a240f Content-Type: text/plain; charset=UTF-8 Hi, all To me, the option "A. Prefer public addresses over privacy addresses". Cheers. On Tue, Mar 27, 2012 at 3:27 PM, Fernando Gont wrote: > On 03/27/2012 12:40 PM, Karl Auer wrote: > > While I realise that the Argument From Personal Ignorance is not very > > convincing, I am having a very hard time imagining why anyone would turn > > on privacy addresses, then prefer non-privacy addresses... > > They don't. Some operating systems enable them by default. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --14dae9340fc90af23e04bc3a240f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, all

To me, the option "A. Prefer pu= blic addresses over privacy addresses".

Cheers.

On Tue, Mar 27, 2012 at 3:27 PM, Fern= ando Gont <fg= ont@si6networks.com> wrote:
On 03/27/2012 12:40 PM, Karl Auer wrote:
> While I realise that the Argument From Personal Ignorance is not very<= br> > convincing, I am having a very hard time imagining why anyone would tu= rn
> on privacy addresses, then prefer non-privacy addresses...

They don't. Some operating systems enable them by default.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



-----------------------------= ---------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--
=
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, liv= ing somewhere between /dev/null and /dev/random

#email:=C2=A0jonghyouk (at) gmail (dot) com

--14dae9340fc90af23e04bc3a240f-- From jari.arkko@piuha.net Tue Mar 27 07:21:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED61F21F88AC for ; Tue, 27 Mar 2012 07:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5YJAkzIkajd for ; Tue, 27 Mar 2012 07:21:55 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 413D921F88AB for ; Tue, 27 Mar 2012 07:21:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1C7FC2D35A; Tue, 27 Mar 2012 17:21:54 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZNEiMvVCTPM; Tue, 27 Mar 2012 17:21:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 748B42CC56; Tue, 27 Mar 2012 17:21:52 +0300 (EEST) Message-ID: <4F71CD00.8000208@piuha.net> Date: Tue, 27 Mar 2012 16:21:52 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: zhou.sujing@zte.com.cn Subject: Re: about security level evaluation of draft-zhou-6man-mhash-cga-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:21:57 -0000 Well, I think it is quite a simple trade-off. Increasing Sec increases computational effort on both sides by equal amount. Increasing the length of the hash increases computational effort only on the attacker side. As a result, the hash bits are relatively valuable. The trade-off that we have in front of us is to choose between: 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits of hash length after accommodating for u and g bits as well. The good with this is that it leaves maximum size for hash. The bad is that it is less flexible for adding many new hash algorithms. 2) The proposed new approach: Eat a total of six bits, for Sec and the hash algorithm identifier. 56 bits remain. The good is that this gives more flexibility to allocate hash algorithms, including the ability to independently choose Sec and the algorithm. The bad is that the hash size is decreased. FWIW, I'm personally in the camp that #1 is still the right approach. We've have 5 entries left: http://www.iana.org/assignments/cga-message-types/cga-message-types.xml#cga-message-types-3 and even if we some day would run out, there would always be an opportunity to use the last bit combination (111) to denote that the algorithm value would be elsewhere in the address. I admit that my preferences are affected by my view that 59 bits is only borderline secure. So I wouldn't want to reduce it, if it can be avoided. Jari From dominik.elsbroek@gmail.com Tue Mar 27 07:44:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BFB21E81E8 for ; Tue, 27 Mar 2012 07:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgOon+GqqmF8 for ; Tue, 27 Mar 2012 07:44:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42C21F898B for ; Tue, 27 Mar 2012 07:44:54 -0700 (PDT) Received: by iazz13 with SMTP id z13so11740819iaz.31 for ; Tue, 27 Mar 2012 07:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S/5UrdolacFmfBJJ1VaH+hxlS8P1sOezUsd2r3OSHVg=; b=UbYxcP5zu+YZDKYizKeU+djRZFR+l9gXjzBG1ZebiXXwAMf9XwKSSBYsryvJDupK1z 8njwZGiiW+gbbZ6ovloAL8nWcnZ/ZQ/DSgqgAmOAXC3sNxIJAHSq+pEdS4sFlq2ndvgD zPaE+JPa5yMBP5c/tJy8ZJdlvGK6RGCKOS25Baxs7BQCHW0CnM75anUGPcCY1GG+47DR NosZv4ZxWXamRaEUdAKSmWZv6k2/Z0A8KJijLgEKlBMZ674W3U9/dwdPJKPeejsUrbkY em2FsxEVtSgXs1L9ER5OoIX0T8XtUzylsqqn7tAcNCPmaykhGkMUYpJ5WC1qEXbFjs5z QS0Q== MIME-Version: 1.0 Received: by 10.50.77.201 with SMTP id u9mr2013306igw.21.1332859493481; Tue, 27 Mar 2012 07:44:53 -0700 (PDT) Received: by 10.50.33.74 with HTTP; Tue, 27 Mar 2012 07:44:53 -0700 (PDT) In-Reply-To: <4F71B938.7030300@si6networks.com> References: <4F71B938.7030300@si6networks.com> Date: Tue, 27 Mar 2012 16:44:53 +0200 Message-ID: Subject: Re: Meta comment about "3484bis and privacy addresses" From: Dominik Elsbroek To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:44:55 -0000 Hi Fernando, since I got confused on the discussion in the plenary this morning: I think we have to consider that having a temporary address like defined in RFC 4941 does not prevent from or even mitigates the scanning problem mentioned this morning in discussion. Scanning MAC-address derived addresses on hosts using privacy extension keeps possible and feasible since the privacy address is only an additional address. The address derived by the MAC address is still reachable and a valid address (like a have just tested on my macbook just to be sure). Thus it is still possible to scan an IPv6 network by iterating over the changing 24 bits. So I don't agree with the sentence: "Clearly, temporary addresses can help reduce the attack exposure window, since the lifetime of each IPv6 address is reduced when compared to that of addresses generated with the method specified in this document." in draft-gont-6man-stable-privacy-addresses-00.txt. The only goal achieved by using a temporary address (_and_ using it) is privacy in that way, a website, or any other third party service, cannot track a user also in case of prefix changes. In my opinion there is no security related reason to use privacy extension. Cheers, Dominik On Tue, Mar 27, 2012 at 14:57, Fernando Gont wrote: > Folks, > > I think that one error in which we have incurred at least in the couple > of years (myself included) is that we focus our discussion on > "mac-derived addresses vs privacy addresses" when the question should > really be about "stable addresses vs. temporary addresses". > > Clearly, we don't want any privacy issues (whether temporary or not), > and we should do something such that all addresses do not have any > privacy issues. (FWIW, this > is > my proposal to tackle the problem of the privacy issues arising from our > current "stable" mac-derived addresses). > > It is also clear that some folks may be arguing in favor of temporary > addresses (RFC 4941) for the wrong reasons (albeit understandable): > because we lack of stable addresses that do not have privacy issues. > > So I tend to think that our debate should probably be about "stable vs. > temporary addresses", but our discussion is kind of blinded by the fact > that we currently only have "stable but privacy-harmful addresses" on > one hand, and "temporary and privacy-improved addresses" on the other. > > *This* fact is what has turned our discussion into being about "public > versus privacy address", when it shouldn't: privacy should never be > compromised. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From zhou.sujing@zte.com.cn Tue Mar 27 07:54:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39E721E816B for ; Tue, 27 Mar 2012 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.633 X-Spam-Level: X-Spam-Status: No, score=-94.633 tagged_above=-999 required=5 tests=[AWL=-1.843, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CF7VTjdI4qX for ; Tue, 27 Mar 2012 07:54:29 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 08E5E21E80C3 for ; Tue, 27 Mar 2012 07:54:25 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801320096835; Tue, 27 Mar 2012 22:19:16 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 34335.3379131713; Tue, 27 Mar 2012 22:54:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2REsDfc071787; Tue, 27 Mar 2012 22:54:13 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4F71CD00.8000208@piuha.net> To: Jari Arkko Subject: =?GB2312?B?tPC4tDogUmU6IGFib3V0IHNlY3VyaXR5IGxldmVsIGV2YWx1YXRpb24gb2Y=?= =?GB2312?B?ICBkcmFmdC16aG91LTZtYW4tbWhhc2gtY2dhLTAw?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 27 Mar 2012 15:54:08 +0100 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-27 22:54:17, Serialize complete at 2012-03-27 22:54:17 Content-Type: multipart/alternative; boundary="=_alternative 0051DE01C12579CE_=" X-MAIL: mse02.zte.com.cn q2REsDfc071787 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:54:30 -0000 This is a multipart message in MIME format. --=_alternative 0051DE01C12579CE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVo YS5uZXQ+INC009ogMjAxMi0wMy0yNyAxNjoyMTo1MjoNCg0KPiBXZWxsLCBJIHRoaW5rIGl0IGlz IHF1aXRlIGEgc2ltcGxlIHRyYWRlLW9mZi4gSW5jcmVhc2luZyBTZWMgDQo+IGluY3JlYXNlcyBj b21wdXRhdGlvbmFsIGVmZm9ydCBvbiBib3RoIHNpZGVzIGJ5IGVxdWFsIGFtb3VudC4gDQo+IElu Y3JlYXNpbmcgdGhlIGxlbmd0aCBvZiB0aGUgaGFzaCBpbmNyZWFzZXMgY29tcHV0YXRpb25hbCBl ZmZvcnQgDQo+IG9ubHkgb24gdGhlIGF0dGFja2VyIHNpZGUuIEFzIGEgcmVzdWx0LCB0aGUgaGFz aCBiaXRzIGFyZSANCnJlbGF0aXZlbHl2YWx1YWJsZS4NCj4gDQo+IFRoZSB0cmFkZS1vZmYgdGhh dCB3ZSBoYXZlIGluIGZyb250IG9mIHVzIGlzIHRvIGNob29zZSBiZXR3ZWVuOg0KPiANCj4gMSkg U3RhdHVzIHF1bzogUkZDIDQ5ODIgZWF0cyB0aHJlZSBiaXRzIGZvciBTZWMsIGxlYXZpbmcgNTkg Yml0cyBvZiANCj4gaGFzaCBsZW5ndGggYWZ0ZXIgYWNjb21tb2RhdGluZyBmb3IgdSBhbmQgZyBi aXRzIGFzIHdlbGwuIFRoZSBnb29kIA0KPiB3aXRoIHRoaXMgaXMgdGhhdCBpdCBsZWF2ZXMgbWF4 aW11bSBzaXplIGZvciBoYXNoLiBUaGUgYmFkIGlzIHRoYXQgDQo+IGl0IGlzIGxlc3MgZmxleGli bGUgZm9yIGFkZGluZyBtYW55IG5ldyBoYXNoIGFsZ29yaXRobXMuDQo+IA0KPiAyKSBUaGUgcHJv cG9zZWQgbmV3IGFwcHJvYWNoOiBFYXQgYSB0b3RhbCBvZiBzaXggYml0cywgZm9yIFNlYyBhbmQg DQo+IHRoZSBoYXNoIGFsZ29yaXRobSBpZGVudGlmaWVyLiA1NiBiaXRzIHJlbWFpbi4gVGhlIGdv b2QgaXMgdGhhdCB0aGlzDQo+IGdpdmVzIG1vcmUgZmxleGliaWxpdHkgdG8gYWxsb2NhdGUgaGFz aCBhbGdvcml0aG1zLCBpbmNsdWRpbmcgdGhlIA0KPiBhYmlsaXR5IHRvIGluZGVwZW5kZW50bHkg Y2hvb3NlIFNlYyBhbmQgdGhlIGFsZ29yaXRobS4gVGhlIGJhZCBpcyANCj4gdGhhdCB0aGUgaGFz aCBzaXplIGlzIGRlY3JlYXNlZC4NCj4gDQo+IEZXSVcsIEknbSBwZXJzb25hbGx5IGluIHRoZSBj YW1wIHRoYXQgIzEgaXMgc3RpbGwgdGhlIHJpZ2h0IA0KPiBhcHByb2FjaC4gV2UndmUgaGF2ZSA1 IGVudHJpZXMgbGVmdDoNCj4gDQo+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY2dh LW1lc3NhZ2UtdHlwZXMvY2dhLW1lc3NhZ2UtdHlwZXMuDQo+IHhtbCNjZ2EtbWVzc2FnZS10eXBl cy0zDQo+IA0KPiBhbmQgZXZlbiBpZiB3ZSBzb21lIGRheSB3b3VsZCBydW4gb3V0LCB0aGVyZSB3 b3VsZCBhbHdheXMgYmUgYW4gDQo+IG9wcG9ydHVuaXR5IHRvIHVzZSB0aGUgbGFzdCBiaXQgY29t YmluYXRpb24gKDExMSkgdG8gZGVub3RlIHRoYXQgdGhlDQo+IGFsZ29yaXRobSB2YWx1ZSB3b3Vs ZCBiZSBlbHNld2hlcmUgaW4gdGhlIGFkZHJlc3MuIEkgYWRtaXQgdGhhdCBteSANCg0KdXNlIDEx MSB0byBkZW5vdGUgaGFzaCBhbGdvcml0aG0gaXMgc29tZXdoZXJlIGluIHRoZSBhZGRyZXNzLCB0 aGVuIHdoZXJlIA0KdGhleSB3b3VsZCBiZSwNCmluIHRoZSBzdWJuZXQgcHJlZml4LCBvciBpbiB0 aGUgaGFzaCBvdXRwdXQ/IGFuZCBob3cgbWFueSBiaXRzIHdpbGwgaXQgDQpvY2N1cHk/DQp0aGF0 IHdpbGwgYnJpbmcgdXMgYmFjayB0byB0aGUgY3VycmVudCBzaXR1Y2F0aW9uIEkgdGhpbmssIGFu ZCB3b3JzZSwgd2l0aCANCjMgIGFkZGl0aW9uYWwgYml0cw0KZWF0ZW4ganVzdCBpbmRpY2F0aW5n IHRoYXQgImhhc2ggYWxnbyBpcyBzb21ld2hlcmUiLiANCg0KDQo+IHByZWZlcmVuY2VzIGFyZSBh ZmZlY3RlZCBieSBteSB2aWV3IHRoYXQgNTkgYml0cyBpcyBvbmx5IGJvcmRlcmxpbmUgDQo+IHNl Y3VyZS4gU28gSSB3b3VsZG4ndCB3YW50IHRvIHJlZHVjZSBpdCwgaWYgaXQgY2FuIGJlIGF2b2lk ZWQuDQoNCjU5IGJpdHMgaXMgbm90IGVub3VnaCBmb3IgYSBoYXNoLCB0aGF0IGlzIHdoeSBzaGEt MSBoYXMgMTI4IGJpdHMgYW5kIGV2ZW4gDQpsb25nZXIsDQp0aGF0IGlzIHdoeSBIQVNIMiBpcyBp bnRyb2R1Y2VkIHRvIGNvbXBlbnNhdGUgZm9yIHRoZSBzaG9ydCBoYXNoIGxlbmd0aCANCm9jY3Vw aWVkLg0KU2luY2UgdGhlbiwgd2h5IGNhbm4ndCB3ZSBkbyBiZXR0ZXI/DQoNCj4gDQo+IEphcmkN Cj4gDQo+IA0KDQo= --=_alternative 0051DE01C12579CE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5KYXJpIEFy a2tvICZsdDtqYXJpLmFya2tvQHBpdWhhLm5ldCZndDsg0LTT2iAyMDEyLTAzLTI3DQoxNjoyMTo1 Mjo8YnI+DQo8YnI+DQomZ3Q7IFdlbGwsIEkgdGhpbmsgaXQgaXMgcXVpdGUgYSBzaW1wbGUgdHJh ZGUtb2ZmLiBJbmNyZWFzaW5nIFNlYyA8YnI+DQomZ3Q7IGluY3JlYXNlcyBjb21wdXRhdGlvbmFs IGVmZm9ydCBvbiBib3RoIHNpZGVzIGJ5IGVxdWFsIGFtb3VudC4gPGJyPg0KJmd0OyBJbmNyZWFz aW5nIHRoZSBsZW5ndGggb2YgdGhlIGhhc2ggaW5jcmVhc2VzIGNvbXB1dGF0aW9uYWwgZWZmb3J0 IDxicj4NCiZndDsgb25seSBvbiB0aGUgYXR0YWNrZXIgc2lkZS4gQXMgYSByZXN1bHQsIHRoZSBo YXNoIGJpdHMgYXJlIHJlbGF0aXZlbHl2YWx1YWJsZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhl IHRyYWRlLW9mZiB0aGF0IHdlIGhhdmUgaW4gZnJvbnQgb2YgdXMgaXMgdG8gY2hvb3NlIGJldHdl ZW46PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEpIFN0YXR1cyBxdW86IFJGQyA0OTgyIGVhdHMgdGhy ZWUgYml0cyBmb3IgU2VjLCBsZWF2aW5nIDU5IGJpdHMgb2YNCjxicj4NCiZndDsgaGFzaCBsZW5n dGggYWZ0ZXIgYWNjb21tb2RhdGluZyBmb3IgdSBhbmQgZyBiaXRzIGFzIHdlbGwuIFRoZSBnb29k DQo8YnI+DQomZ3Q7IHdpdGggdGhpcyBpcyB0aGF0IGl0IGxlYXZlcyBtYXhpbXVtIHNpemUgZm9y IGhhc2guIFRoZSBiYWQgaXMgdGhhdA0KPGJyPg0KJmd0OyBpdCBpcyBsZXNzIGZsZXhpYmxlIGZv ciBhZGRpbmcgbWFueSBuZXcgaGFzaCBhbGdvcml0aG1zLjxicj4NCiZndDsgPGJyPg0KJmd0OyAy KSBUaGUgcHJvcG9zZWQgbmV3IGFwcHJvYWNoOiBFYXQgYSB0b3RhbCBvZiBzaXggYml0cywgZm9y IFNlYyBhbmQNCjxicj4NCiZndDsgdGhlIGhhc2ggYWxnb3JpdGhtIGlkZW50aWZpZXIuIDU2IGJp dHMgcmVtYWluLiBUaGUgZ29vZCBpcyB0aGF0IHRoaXM8YnI+DQomZ3Q7IGdpdmVzIG1vcmUgZmxl eGliaWxpdHkgdG8gYWxsb2NhdGUgaGFzaCBhbGdvcml0aG1zLCBpbmNsdWRpbmcgdGhlDQo8YnI+ DQomZ3Q7IGFiaWxpdHkgdG8gaW5kZXBlbmRlbnRseSBjaG9vc2UgU2VjIGFuZCB0aGUgYWxnb3Jp dGhtLiBUaGUgYmFkIGlzDQo8YnI+DQomZ3Q7IHRoYXQgdGhlIGhhc2ggc2l6ZSBpcyBkZWNyZWFz ZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZXSVcsIEknbSBwZXJzb25hbGx5IGluIHRoZSBjYW1w IHRoYXQgIzEgaXMgc3RpbGwgdGhlIHJpZ2h0IDxicj4NCiZndDsgYXBwcm9hY2guIFdlJ3ZlIGhh dmUgNSBlbnRyaWVzIGxlZnQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvY2dhLW1lc3NhZ2UtdHlwZXMvY2dhLW1lc3NhZ2UtdHlwZXMuPGJyPg0K Jmd0OyB4bWwjY2dhLW1lc3NhZ2UtdHlwZXMtMzxicj4NCiZndDsgPGJyPg0KJmd0OyBhbmQgZXZl biBpZiB3ZSBzb21lIGRheSB3b3VsZCBydW4gb3V0LCB0aGVyZSB3b3VsZCBhbHdheXMgYmUgYW4g PGJyPg0KJmd0OyBvcHBvcnR1bml0eSB0byB1c2UgdGhlIGxhc3QgYml0IGNvbWJpbmF0aW9uICgx MTEpIHRvIGRlbm90ZSB0aGF0IHRoZTxicj4NCiZndDsgYWxnb3JpdGhtIHZhbHVlIHdvdWxkIGJl IGVsc2V3aGVyZSBpbiB0aGUgYWRkcmVzcy4gSSBhZG1pdCB0aGF0IG15DQo8L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnVzZSAxMTEgdG8gZGVub3RlIGhhc2ggYWxnb3Jp dGhtIGlzIHNvbWV3aGVyZSBpbiB0aGUNCmFkZHJlc3MsIHRoZW4gd2hlcmUgdGhleSB3b3VsZCBi ZSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmluIHRoZSBzdWJuZXQgcHJlZml4 LCBvciBpbiB0aGUgaGFzaCBvdXRwdXQ/IGFuZCBob3cNCm1hbnkgYml0cyB3aWxsIGl0IG9jY3Vw eT88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnRoYXQgd2lsbCBicmluZyB1cyBi YWNrIHRvIHRoZSBjdXJyZW50IHNpdHVjYXRpb24NCkkgdGhpbmssIGFuZCB3b3JzZSwgd2l0aCAz ICZuYnNwO2FkZGl0aW9uYWwgYml0czwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ ZWF0ZW4ganVzdCBpbmRpY2F0aW5nIHRoYXQgJnF1b3Q7aGFzaCBhbGdvIGlzIHNvbWV3aGVyZSZx dW90Oy4NCiZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJy Pg0KJmd0OyBwcmVmZXJlbmNlcyBhcmUgYWZmZWN0ZWQgYnkgbXkgdmlldyB0aGF0IDU5IGJpdHMg aXMgb25seSBib3JkZXJsaW5lDQo8YnI+DQomZ3Q7IHNlY3VyZS4gU28gSSB3b3VsZG4ndCB3YW50 IHRvIHJlZHVjZSBpdCwgaWYgaXQgY2FuIGJlIGF2b2lkZWQuPC9mb250PjwvdHQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj41OSBiaXRzIGlzIG5vdCBlbm91Z2ggZm9yIGEgaGFzaCwgdGhh dCBpcyB3aHkgc2hhLTENCmhhcyAxMjggYml0cyBhbmQgZXZlbiBsb25nZXIsPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj50aGF0IGlzIHdoeSBIQVNIMiBpcyBpbnRyb2R1Y2VkIHRv IGNvbXBlbnNhdGUgZm9yDQp0aGUgc2hvcnQgaGFzaCBsZW5ndGggb2NjdXBpZWQuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5TaW5jZSB0aGVuLCB3aHkgY2Fubid0IHdlIGRvIGJl dHRlcj88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0K Jmd0OyBKYXJpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0051DE01C12579CE_=-- From fgont@si6networks.com Tue Mar 27 07:59:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9EC21E8217 for ; Tue, 27 Mar 2012 07:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzcU8ZUrdH3N for ; Tue, 27 Mar 2012 07:59:54 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 09BD821E81D1 for ; Tue, 27 Mar 2012 07:59:54 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCXs9-00042Y-9y; Tue, 27 Mar 2012 16:59:47 +0200 Message-ID: <4F71D5DE.1050900@si6networks.com> Date: Tue, 27 Mar 2012 16:59:42 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Dominik Elsbroek Subject: draft-gont-6man-stable-privacy-addresses (was: Re: Meta comment about "3484bis and privacy addresses") References: <4F71B938.7030300@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:59:54 -0000 On 03/27/2012 04:44 PM, Dominik Elsbroek wrote: > since I got confused on the discussion in the plenary this morning: I > think we have to consider that having a temporary address like defined > in RFC 4941 does not prevent from or even mitigates the scanning > problem mentioned this morning in discussion. Exactly. That's why we need stable privacy-enhanced addresses regardless of whether one implements RFC 4941. > Scanning MAC-address > derived addresses on hosts using privacy extension keeps possible and > feasible since the privacy address is only an additional address. The > address derived by the MAC address is still reachable and a valid > address (like a have just tested on my macbook just to be sure). Thus > it is still possible to scan an IPv6 network by iterating over the > changing 24 bits. Agreed. > So I don't agree with the sentence: "Clearly, temporary addresses can > help reduce the attack exposure window, since the lifetime of each > IPv6 address is reduced when compared to that of addresses generated > with the method specified in this document." in > draft-gont-6man-stable-privacy-addresses-00.txt. What I meant is that if the attacker knows the host adresess, then attack exposure is a bit reduced for the temporary addresses, simply because their lifetime is shorter. But yes, this "reduced exposure" is really debatable. The lifetime of temporary addresses is usually long enough that, in practice, they don't really reduce exposure. I will try to fix this in the next rev. (thanks for pointing this out!) > The only goal achieved by using a temporary address (_and_ using it) > is privacy in that way, a website, or any other third party service, > cannot track a user also in case of prefix changes. Well, draft-gont-6man-stable-privacy-addresses addresses this point, without the management burden usually implied by temporary addresses. Temporary addresses could, in some sense, prevent correlation of different activities of the same node from the same network... but unless you use an insanely short lifetime, the lifetime is long enough that these addresses do not prevent much of this possible "correlation". > In my opinion > there is no security related reason to use privacy extension. So far, there is/was, because we didn't/don't have yet standardized stable privacy addresses... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian@innovationslab.net Tue Mar 27 08:20:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13D421F8913 for ; Tue, 27 Mar 2012 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aht3T09YsyhK for ; Tue, 27 Mar 2012 08:20:14 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3701D21F8905 for ; Tue, 27 Mar 2012 08:20:14 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 276AE88181 for ; Tue, 27 Mar 2012 08:20:14 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (dhcp-5588.meeting.ietf.org [130.129.85.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C2C68130017 for ; Tue, 27 Mar 2012 08:20:13 -0700 (PDT) Message-ID: <4F71DAAB.601@innovationslab.net> Date: Tue, 27 Mar 2012 11:20:11 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71B5E2.5000400@si6networks.com> In-Reply-To: <4F71B5E2.5000400@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:20:14 -0000 On 3/27/12 8:43 AM, Fernando Gont wrote: > On 03/27/2012 09:33 AM, Brian Haberman wrote: >> All, >> The chairs would like to get a sense of the working group on >> changing the current (defined 3484) model of preferring public addresses >> over privacy addresses during the address selection process. > > Brian: Terminology issue here: Are "public addresses" a short hand for > "IPv6 addresses with Modified EUI-64 format identifiers"? -- I ask > because all of these addresses are public. Based on the terminology in 3484 and 3484bis, I am asking for the WG's view of preferring public over temporary (rather than private) addresses as defined in RFC 4941. Regards, Brian From jonghyouk@gmail.com Tue Mar 27 08:25:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F8221E801F for ; Tue, 27 Mar 2012 08:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBDX9fd-MdpC for ; Tue, 27 Mar 2012 08:25:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19DD221F8618 for ; Tue, 27 Mar 2012 08:25:11 -0700 (PDT) Received: by yenm5 with SMTP id m5so8826yen.31 for ; Tue, 27 Mar 2012 08:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oqSnkNzS+ji+TddTOZPGHh0zoLAVRpVZkal1ITnUC50=; b=l0Xt+Y8gfHa1mdYRovMVCZEotMRkXt6QB46RczQlewH3QMJU7pu9C74aLeim92fOLd FKHMaogf/6tYTl+T4HYpcdrYOFQ3jOcRoOyoe2exqPUWTqXJXkiWX45xnRpBVOIT1TIT OClmpsHAG9whaekiI3utjj7J0OmV0sKzq62j+gMpO7fUmvLjIi/6ofWeuGCGrYiPGPat Ihfw71KQ9Ja9Nt8N8gBoTtNBVrmzo56vVCEHKEshPdlZN4LHbSbijBbzr9NXYtMrGxrP Krdzjsbs2lLXWWthCSl/t6DXnwN9avLKqTwwKIbG2l20Vdau1A0f9m/1Jkjk54x6j7xt oPtw== MIME-Version: 1.0 Received: by 10.50.45.202 with SMTP id p10mr8873409igm.52.1332861910365; Tue, 27 Mar 2012 08:25:10 -0700 (PDT) Received: by 10.64.30.200 with HTTP; Tue, 27 Mar 2012 08:25:10 -0700 (PDT) In-Reply-To: <4F71D5DE.1050900@si6networks.com> References: <4F71B938.7030300@si6networks.com> <4F71D5DE.1050900@si6networks.com> Date: Tue, 27 Mar 2012 17:25:10 +0200 Message-ID: Subject: Re: draft-gont-6man-stable-privacy-addresses (was: Re: Meta comment about "3484bis and privacy addresses") From: Jong-Hyouk Lee To: Fernando Gont Content-Type: multipart/alternative; boundary=14dae9340605b3b8bf04bc3b18fb Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:25:14 -0000 --14dae9340605b3b8bf04bc3b18fb Content-Type: text/plain; charset=UTF-8 Dear all I'm working on ETSI and ISO standardization for ITS (vehicular communication) where location privacy at the IPv6 layer is one of big concerns. From the viewpoint of IPv6 ITS communication, we definitely need to preserve location privacy. Accordingly, I strongly support the method described in this document even if the document should be improved. Cheers. On Tue, Mar 27, 2012 at 4:59 PM, Fernando Gont wrote: > On 03/27/2012 04:44 PM, Dominik Elsbroek wrote: > > since I got confused on the discussion in the plenary this morning: I > > think we have to consider that having a temporary address like defined > > in RFC 4941 does not prevent from or even mitigates the scanning > > problem mentioned this morning in discussion. > > Exactly. That's why we need stable privacy-enhanced addresses regardless > of whether one implements RFC 4941. > > > > Scanning MAC-address > > derived addresses on hosts using privacy extension keeps possible and > > feasible since the privacy address is only an additional address. The > > address derived by the MAC address is still reachable and a valid > > address (like a have just tested on my macbook just to be sure). Thus > > it is still possible to scan an IPv6 network by iterating over the > > changing 24 bits. > > Agreed. > > > > So I don't agree with the sentence: "Clearly, temporary addresses can > > help reduce the attack exposure window, since the lifetime of each > > IPv6 address is reduced when compared to that of addresses generated > > with the method specified in this document." in > > draft-gont-6man-stable-privacy-addresses-00.txt. > > What I meant is that if the attacker knows the host adresess, then > attack exposure is a bit reduced for the temporary addresses, simply > because their lifetime is shorter. But yes, this "reduced exposure" is > really debatable. The lifetime of temporary addresses is usually long > enough that, in practice, they don't really reduce exposure. > > I will try to fix this in the next rev. (thanks for pointing this out!) > > > > > > The only goal achieved by using a temporary address (_and_ using it) > > is privacy in that way, a website, or any other third party service, > > cannot track a user also in case of prefix changes. > > Well, draft-gont-6man-stable-privacy-addresses addresses this point, > without the management burden usually implied by temporary addresses. > > Temporary addresses could, in some sense, prevent correlation of > different activities of the same node from the same network... but > unless you use an insanely short lifetime, the lifetime is long enough > that these addresses do not prevent much of this possible "correlation". > > > > In my opinion > > there is no security related reason to use privacy extension. > > So far, there is/was, because we didn't/don't have yet standardized > stable privacy addresses... > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jonghyouk (at) gmail (dot) com #webpage: http://sites.google.com/site/hurryon/ --14dae9340605b3b8bf04bc3b18fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all

I'm working on ETSI and ISO standardization= for ITS (vehicular communication) where location privacy at the IPv6 layer= is one of big concerns. From the viewpoint of IPv6 ITS communication, we= =C2=A0definitely need to preserve location privacy. Accordingly,=C2=A0I str= ongly support the method described in this document even if the document sh= ould be improved.

Cheers.

On Tue= , Mar 27, 2012 at 4:59 PM, Fernando Gont <fgont@si6networks.com> wrote:
On 03/27/2012 04:44 PM, Dominik Elsbroek wrote:
> since I got confused on the discussion in the plenary this morning: I<= br> > think we have to consider that having a temporary address like defined=
> in RFC 4941 does not prevent from or even mitigates the scanning
> problem mentioned this morning in discussion.

Exactly. That's why we need stable privacy-enhanced addresses regardles= s
of whether one implements RFC 4941.


> Scanning MAC-address
> derived addresses on hosts using privacy extension keeps possible and<= br> > feasible since the privacy address is only an additional address. The<= br> > address derived by the MAC address is still reachable and a valid
> address (like a have just tested on my macbook just to be sure). Thus<= br> > it is still possible to scan an IPv6 network by iterating over the
> changing 24 bits.

Agreed.


> So I don't agree with the sentence: "Clearly, temporary addre= sses can
> help reduce the attack exposure =C2=A0 window, since the lifetime of e= ach
> IPv6 address is reduced when compared to that of addresses generated > with the method specified in this document." in
> draft-gont-6man-stable-privacy-addresses-00.txt.

What I meant is that if the attacker knows the host adresess, then
attack exposure is a bit reduced for the temporary addresses, simply
because their lifetime is shorter. But yes, this "reduced exposure&quo= t; is
really debatable. The lifetime of temporary addresses is usually long
enough that, in practice, they don't really reduce exposure.

I will try to fix this in the next rev. (thanks for pointing this out!)




> The only goal achieved by using a temporary address (_and_ using it) > is privacy in that way, a website, or any other third party service, > cannot track a user also in case of prefix changes.

Well, draft-gont-6man-stable-privacy-addresses addresses this point,
without the management burden usually implied by temporary addresses.

Temporary addresses could, in some sense, prevent correlation of
different activities of the same node from the same network... but
unless you use an insanely short lifetime, the lifetime is long enough
that these addresses do not prevent much of this possible "correlation= ".


> In my opinion
> there is no security related reason to use privacy extension.

So far, there is/was, because we didn't/don't have yet standardized=
stable privacy addresses...

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--
RSM Dep= artment, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewher= e between /dev/null and /dev/random

#email:=C2=A0j= onghyouk (at) gmail (dot) com

--14dae9340605b3b8bf04bc3b18fb-- From brian@innovationslab.net Tue Mar 27 08:33:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB021E8157 for ; Tue, 27 Mar 2012 08:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN50-QdbC4KX for ; Tue, 27 Mar 2012 08:33:51 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9561821E814E for ; Tue, 27 Mar 2012 08:33:51 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5C08D88181 for ; Tue, 27 Mar 2012 08:33:51 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (dhcp-5588.meeting.ietf.org [130.129.85.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 008A2130017 for ; Tue, 27 Mar 2012 08:33:50 -0700 (PDT) Message-ID: <4F71DDDD.7020602@innovationslab.net> Date: Tue, 27 Mar 2012 11:33:49 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Meta comment about "3484bis and privacy addresses" References: <4F71B938.7030300@si6networks.com> In-Reply-To: <4F71B938.7030300@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:33:52 -0000 Fernando, On 3/27/12 8:57 AM, Fernando Gont wrote: > Folks, > > I think that one error in which we have incurred at least in the couple > of years (myself included) is that we focus our discussion on > "mac-derived addresses vs privacy addresses" when the question should > really be about "stable addresses vs. temporary addresses". Given that the question is being driven by the work going into 3484bis, I disagree. The question I asked is querying people's choice for preferring temporary (RFC 4941) addresses over public addresses when performing address selection. The discussion of defining a new form of stable address as opposed to the current EUI-64-derived addressing is a separate topic. This is especially relevant given the state of 3484bis (ready for WGLC). Regards, Brian From evyncke@cisco.com Tue Mar 27 09:21:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8139121F89EF for ; Tue, 27 Mar 2012 09:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccj8WuhSHoLk for ; Tue, 27 Mar 2012 09:21:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 915C121F89EE for ; Tue, 27 Mar 2012 09:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=1216; q=dns/txt; s=iport; t=1332865302; x=1334074902; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LDDAENIsC3xQUJPZtL1GHynrEAesLAJKqk8y+DUq1Cg=; b=VX1aW1w+mFP/ER8FGwkaTcS5CV96w/lOTLysWFn7uulIPO11BBFNlaJw agQbCHz5nmhMZICmCWI99CgFQDAhEYiEeZLuTPj4hMm0GAUMyl94uC38g SfKVAEEWFBIn97H0KXj7xl6HAJJrjaCNvk+x1tb4/+qTfVF8tFjzRy7FH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFbocU+Q/khR/2dsb2JhbABFuEaBB4IJAQEBBAEBAQ8BHQo0CwwEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAESCBqHaAubH58QBIpnhUVjBKQmgWiCaYFa X-IronPort-AV: E=Sophos;i="4.73,658,1325462400"; d="scan'208";a="133511689" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 16:21:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2RGLZeC020045; Tue, 27 Mar 2012 16:21:35 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 18:21:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: question about draft-gont-6man-oversized-header-chain-00 Date: Tue, 27 Mar 2012 18:21:32 +0200 Message-ID: <317616CE96204D49B5A1811098BA895006F347ED@XMB-AMS-110.cisco.com> In-Reply-To: <4F71BFF6.2080904@si6networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question about draft-gont-6man-oversized-header-chain-00 Thread-Index: Ac0MHTnFWj78y4gmTMq5wBb56WbJoQAGHC5g References: <4F71889D.6030208@forthnetgroup.gr> <4F71BFF6.2080904@si6networks.com> From: "Eric Vyncke (evyncke)" To: "Fernando Gont" , "Tassos Chatzithomaoglou" X-OriginalArrivalTime: 27 Mar 2012 16:21:34.0985 (UTC) FILETIME=[ADA78790:01CD0C35] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:21:43 -0000 +1 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: mardi 27 mars 2012 15:26 > To: Tassos Chatzithomaoglou > Cc: ipv6@ietf.org > Subject: Re: question about draft-gont-6man-oversized-header-chain-00 >=20 > On 03/27/2012 11:30 AM, Tassos Chatzithomaoglou wrote: > > i was wondering, is there any actual (from a production network, not > > created on purpose in a lab) sample ipv6 traffic showing an ipv6 > > header comprising of two or more packets? >=20 > No. That's exactly the point: such traffic does not occur in practice, > but since it is allowed by the specifications, can still be used by > attacker for malicious purposes (that is, evading security controls). >=20 > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Tue Mar 27 09:30:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EEA21E80DD for ; Tue, 27 Mar 2012 09:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRd0KHbn4H1O for ; Tue, 27 Mar 2012 09:30:29 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id D9CC921E80D0 for ; Tue, 27 Mar 2012 09:30:28 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCZHo-0005Xg-TE; Tue, 27 Mar 2012 18:30:21 +0200 Message-ID: <4F71EB20.8020908@si6networks.com> Date: Tue, 27 Mar 2012 18:30:24 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Brian Haberman Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> In-Reply-To: <4F716D5C.40402@innovationslab.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:30:29 -0000 On 03/27/2012 09:33 AM, Brian Haberman wrote: > Please state your preference for one of the following default > options : > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses Having to choose between these two, I'd go with B. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From zhou.sujing@zte.com.cn Tue Mar 27 09:43:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B2621E80CD for ; Tue, 27 Mar 2012 09:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.777 X-Spam-Level: X-Spam-Status: No, score=-98.777 tagged_above=-999 required=5 tests=[AWL=3.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY3nSFxghu6N for ; Tue, 27 Mar 2012 09:43:51 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D23BB21F88A6 for ; Tue, 27 Mar 2012 09:43:50 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 523731320096835; Tue, 27 Mar 2012 21:03:57 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 96035.1881878302; Tue, 27 Mar 2012 21:12:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2RDC3ku023925; Tue, 27 Mar 2012 21:12:04 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) MIME-Version: 1.0 To: ipv6@ietf.org Subject: about the secrurity evalutaion in CGAs X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 27 Mar 2012 14:11:54 +0100 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-27 21:12:06, Serialize complete at 2012-03-27 21:12:06 Content-Type: multipart/alternative; boundary="=_alternative 0048827FC12579CE_=" X-MAIL: mse01.zte.com.cn q2RDC3ku023925 Cc: jari.arkko@ericsson.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:43:52 -0000 This is a multipart message in MIME format. --=_alternative 0048827FC12579CE_= Content-Type: text/plain; charset="US-ASCII" In response to coments on draft draft-zhou-6man-mhash-cga-00 It can be referred to RFC3972 section 7.2 "This increases the cost of address generation approximately by a factor of 2^(16*Sec). It also increases the cost of brute-force attacks by the same factor. That is, the cost of creating a CGA Parameters data structure that binds the attacker's public key with somebody else's address is increased from O(2^59) to O(2^(59+16*Sec)). The address generator may choose the security parameter Sec depending on its own computational capacity, the perceived risk of attacks, and the expected lifetime of the address. Currently, Sec values between 0 and 2 are sufficient for most IPv6 nodes. As computers become faster, higher Sec values will slowly become useful. " Regards~~~ -Sujing Zhou --=_alternative 0048827FC12579CE_= Content-Type: text/html; charset="US-ASCII"
In response to coments on draft draft-zhou-6man-mhash-cga-00

It can be referred to RFC3972 section 7.2
"This increases the cost of address generation approximately by
  a factor of 2^(16*Sec).  It also increases the cost of brute-force
  attacks by the same factor.  That is, the cost of creating a CGA
  Parameters data structure that binds the attacker's public key with
  somebody else's address is increased from O(2^59) to
  O(2^(59+16*Sec)).  The address generator may choose the security
  parameter Sec depending on its own computational capacity, the
  perceived risk of attacks, and the expected lifetime of the address.
  Currently, Sec values between 0 and 2 are sufficient for most IPv6
  nodes.  As computers become faster, higher Sec values will slowly
  become useful.
"


Regards~~~

-Sujing Zhou --=_alternative 0048827FC12579CE_=-- From Ray.Hunter@globis.net Tue Mar 27 10:00:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83AC621E8048 for ; Tue, 27 Mar 2012 10:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTI6D73tSBSa for ; Tue, 27 Mar 2012 10:00:15 -0700 (PDT) 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 2DB2B21E8222 for ; Tue, 27 Mar 2012 10:00:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D57BA8700DB; Tue, 27 Mar 2012 19:00:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yzMArS6PMZf; Tue, 27 Mar 2012 19:00:07 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 1971A8700B7; Tue, 27 Mar 2012 19:00:07 +0200 (CEST) Message-ID: <4F71F217.7000209@globis.net> Date: Tue, 27 Mar 2012 19:00:07 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian Haberman Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> In-Reply-To: <4F716D5C.40402@innovationslab.net> Content-Type: multipart/mixed; boundary="------------040303040402070009020405" X-Mailman-Approved-At: Tue, 27 Mar 2012 10:23:53 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:00:16 -0000 This is a multi-part message in MIME format. --------------040303040402070009020405 Content-Type: multipart/alternative; boundary="------------080003050205030601080800" --------------080003050205030601080800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From the corporate World: option A as default, with local user controlled option to override. RFC3484 (which references RFC3041) "Temporary addresses" are a menace to fault finding, audit, logging, firewall rules, filtering, QoS matching, conformance: anywhere where an ACL or stable address is used today. Sure we shouldn't use fixed/stable IP literals, but we do. And in many cases there aren't any practical alternatives in today's products, so the IP address is the lowest common denominator used to identify a machine (and dare I say even "a user" in some circumstances). Also not sure if any DHCPv6 server implementations actually provide DHCPv6 assigned temporary addresses in practice. My take on this is that a set of a few hundred individual persons who are worried about privacy are more likely to be able to control their own particular machines to correctly override the "default off" setting than a single corporate network manager is to be able to guarantee overriding a "default on" setting on 100% of 10000 machines attached to their network. regards, RayH Brian Haberman wrote: >
All, > The chairs would like to get a sense of the working group on > changing the current (defined 3484) model of preferring public > addresses over privacy addresses during the address selection > process. RFC 3484 prefers public addresses with the ability (MAY) of > an implementation to reverse the preference. The suggestion has been > made to reverse that preference in 3484bis (prefer privacy addresses > over public ones). Regardless, the document will allow > implementers/users to reverse the default preference. > > Please state your preference for one of the following default > options : > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses > > Regards, > Brian, Bob, & Ole > >
-- Ray Hunter Ray.Hunter@globis.net Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL, Registered at the KvK, Eindhoven, under number BV 17098279 mobile: +31 620 363864 --------------080003050205030601080800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >From the corporate World: option A as default, with local user controlled option to override.

RFC3484 (which references RFC3041) "Temporary addresses" are a menace to fault finding, audit, logging, firewall rules, filtering, QoS matching, conformance: anywhere where an ACL or stable address is used today. Sure we shouldn't use fixed/stable IP literals, but we do. And in many cases there aren't any practical alternatives in today's products, so the IP address is the lowest common denominator used to identify a machine (and dare I say even "a user" in some circumstances).

Also not sure if any DHCPv6 server implementations actually provide DHCPv6 assigned temporary addresses in practice.

My take on this is that a set of a few hundred individual persons who are worried about privacy are more likely to be able to control their own particular machines to correctly override the "default off" setting than a single corporate network manager is to be able to guarantee overriding a "default on" setting on 100% of 10000 machines attached to their network.

regards,
RayH

Brian Haberman wrote:
<div class="moz-text-flowed">All,
     The chairs would like to get a sense of the working group on changing the current (defined 3484) model of preferring public addresses over privacy addresses during the address selection process.  RFC 3484 prefers public addresses with the ability (MAY) of an implementation to reverse the preference.  The suggestion has been made to reverse that preference in 3484bis (prefer privacy addresses over public ones). Regardless, the document will allow implementers/users to reverse the default preference.

     Please state your preference for one of the following default options :

A. Prefer public addresses over privacy addresses

B. Prefer privacy addresses over public addresses

Regards,
Brian, Bob, & Ole

</div>

--
Ray Hunter
Ray.Hunter@globis.net
Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
Registered at the KvK, Eindhoven, under number BV 17098279
mobile: +31 620 363864

--------------080003050205030601080800-- --------------040303040402070009020405 Content-Type: text/x-vcard; charset=utf-8; name="Ray_Hunter.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Ray_Hunter.vcf" begin:vcard fn:Ray Hunter n:Hunter;Ray org:Globis Consulting BV adr:;;Fazantlaan23;Eindhoven;;5613CB;The Netherlands email;internet:Ray.Hunter@globis.net tel;cell:+31 620 363864 x-mozilla-html:FALSE url:http://www.globis.net version:2.1 end:vcard --------------040303040402070009020405-- From fgont@si6networks.com Tue Mar 27 10:42:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4961C21F8666 for ; Tue, 27 Mar 2012 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3GObTtQ1o0h for ; Tue, 27 Mar 2012 10:42:35 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id A7FB021F864C for ; Tue, 27 Mar 2012 10:42:35 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCaPZ-0006l7-4K; Tue, 27 Mar 2012 19:42:25 +0200 Message-ID: <4F71FC03.90403@si6networks.com> Date: Tue, 27 Mar 2012 19:42:27 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Ray Hunter Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> In-Reply-To: <4F71F217.7000209@globis.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 17:42:36 -0000 On 03/27/2012 07:00 PM, Ray Hunter wrote: > My take on this is that a set of a few hundred individual persons who > are worried about privacy are more likely to be able to control their > own particular machines to correctly override the "default off" setting > than a single corporate network manager is to be able to guarantee > overriding a "default on" setting on 100% of 10000 machines attached to > their network. Well, that's because we should probably do something like this: While I understand the "procedural constraints" (i.e., document in WGLC), I think that much of the discussion that we're having is because we have limited choices in a number of areas. Namely: 1) Inability to convey address-generation policy in RA messages. 2) Stable privacy-enhanced addresses So we worry about selecting the right default because: 1) We have no mechanism to change that default dynamically 2) If we were to use stable addresses, in msot cases that implies "privacy-harmful" addresses. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Tue Mar 27 12:05:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAAC21E80A1 for ; Tue, 27 Mar 2012 12:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHh1Hr1UZwIw for ; Tue, 27 Mar 2012 12:05:51 -0700 (PDT) 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 6B51621E8089 for ; Tue, 27 Mar 2012 12:05:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 714198700DB; Tue, 27 Mar 2012 21:05:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPR-Tr1VlhUK; Tue, 27 Mar 2012 21:05:35 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 361298700D8; Tue, 27 Mar 2012 21:05:35 +0200 (CEST) Message-ID: <4F720F7F.2090108@globis.net> Date: Tue, 27 Mar 2012 21:05:35 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fernando Gont Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> In-Reply-To: <4F71FC03.90403@si6networks.com> Content-Type: multipart/alternative; boundary="------------030502060503080600040602" Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:05:52 -0000 This is a multi-part message in MIME format. --------------030502060503080600040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I happen to like your draft. But even in the presence of a mechanism to distribute an advisory address-generation policy (which may or may not not be supported by all end-node implementations for another 10 years) IMHO the proper *default* behavior is still "off" = option A. In other words, default = IPv4-like behavior, at least until we really figure out how to operate all of these fancy new features of IPv6. regards, RayH Fernando Gont wrote: > On 03/27/2012 07:00 PM, Ray Hunter wrote: > >> My take on this is that a set of a few hundred individual persons who >> are worried about privacy are more likely to be able to control their >> own particular machines to correctly override the "default off" setting >> than a single corporate network manager is to be able to guarantee >> overriding a "default on" setting on 100% of 10000 machines attached to >> their network. >> > > Well, that's because we should probably do something like this: > > > While I understand the "procedural constraints" (i.e., document in > WGLC), I think that much of the discussion that we're having is because > we have limited choices in a number of areas. Namely: > > 1) Inability to convey address-generation policy in RA messages. > 2) Stable privacy-enhanced addresses > > So we worry about selecting the right default because: > > 1) We have no mechanism to change that default dynamically > 2) If we were to use stable addresses, in msot cases that implies > "privacy-harmful" addresses. > > Thanks, > --------------030502060503080600040602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I happen to like your draft. But even in the presence of a mechanism to distribute an advisory address-generation policy (which may or may not not be supported by all end-node implementations for another 10 years) IMHO the proper *default* behavior is still "off" = option A. In other words, default = IPv4-like behavior, at least until we really figure out how to operate all of these fancy new features of IPv6.

regards,
RayH

Fernando Gont wrote: 
On 03/27/2012 07:00 PM, Ray Hunter wrote:
  
My take on this is that a set of a few hundred individual persons who
are worried about privacy are more likely to be able to control their
own particular machines to correctly override the "default off" setting
than a single corporate network manager is to be able to guarantee
overriding a "default on" setting on 100% of 10000 machines attached to
their network.
    

Well, that's because we should probably do something like this:
<http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>

While I understand the "procedural constraints" (i.e., document in
WGLC), I think that much of the discussion that we're having is because
we have limited choices in a number of areas. Namely:

1) Inability to convey address-generation policy in RA messages.
2) Stable privacy-enhanced addresses

So we worry about selecting the right default because:

1) We have no mechanism to change that default dynamically
2) If we were to use stable addresses, in msot cases that implies
"privacy-harmful" addresses.

Thanks,
--------------030502060503080600040602-- From albert.e.manfredi@boeing.com Tue Mar 27 12:08:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462ED21E80D8 for ; Tue, 27 Mar 2012 12:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcJyU+jr3Htz for ; Tue, 27 Mar 2012 12:08:07 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 490B321E8094 for ; Tue, 27 Mar 2012 12:08:07 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q2RJ7uVL020507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 27 Mar 2012 12:07:57 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q2RJ7uAK016716; Tue, 27 Mar 2012 12:07:56 -0700 (PDT) Received: from XCH-MWHT-06.mw.nos.boeing.com (xch-mwht-06.mw.nos.boeing.com [134.57.113.166]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q2RJ7u2u016646 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 27 Mar 2012 12:07:56 -0700 (PDT) Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-06.mw.nos.boeing.com (134.57.113.166) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Mar 2012 14:07:55 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Tue, 27 Mar 2012 14:07:54 -0500 From: "Manfredi, Albert E" To: Karl Auer , "ipv6@ietf.org" Date: Tue, 27 Mar 2012 14:07:51 -0500 Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: Ac0MBi53mq2w+zd5Qse3WqZhALzzagARlHvw Message-ID: References: <4F716D5C.40402@innovationslab.net> <1332844849.2641.800.camel@karl> In-Reply-To: <1332844849.2641.800.camel@karl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18800.007 x-tm-as-result: No--47.117100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:08:08 -0000 PiBGcm9tOiBpcHY2LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZg0KPiBLYXJsIEF1ZXINCg0KDQo+ID4gICAgICAgUGxlYXNlIHN0YXRl IHlvdXIgcHJlZmVyZW5jZSBmb3Igb25lIG9mIHRoZSBmb2xsb3dpbmcgZGVmYXVsdA0KPiA+IG9w dGlvbnMgOg0KPiA+DQo+ID4gQS4gUHJlZmVyIHB1YmxpYyBhZGRyZXNzZXMgb3ZlciBwcml2YWN5 IGFkZHJlc3Nlcw0KPiA+DQo+ID4gQi4gUHJlZmVyIHByaXZhY3kgYWRkcmVzc2VzIG92ZXIgcHVi bGljIGFkZHJlc3Nlcw0KPiANCj4gQi4NCj4gDQo+IFdoaWxlIEkgcmVhbGlzZSB0aGF0IHRoZSBB cmd1bWVudCBGcm9tIFBlcnNvbmFsIElnbm9yYW5jZSBpcyBub3QgdmVyeQ0KPiBjb252aW5jaW5n LCBJIGFtIGhhdmluZyBhIHZlcnkgaGFyZCB0aW1lIGltYWdpbmluZyB3aHkgYW55b25lIHdvdWxk DQo+IHR1cm4NCj4gb24gcHJpdmFjeSBhZGRyZXNzZXMsIHRoZW4gcHJlZmVyIG5vbi1wcml2YWN5 IGFkZHJlc3Nlcy4uLg0KDQorMS4NCg0KSSBhbSBnZW5lcmFsbHkgaW4gZmF2b3Igb2YgdXNpbmcg cHVibGljIGFkZHJlc3NlcyBhbHdheXMsIGJ1dCBJIGhhdmUgdG8gYWdyZWUgd2l0aCBLYXJsJ3Mg cG9pbnQuIE1heWJlIHRoaXMgbG9naWMgc2hvdWxkIGJlIHN0YXRlZCBleHBsaWNpdGx5IGluIGEg MzQ4NGJpcy4NCg0KQmVydA0KDQo= From sander@steffann.nl Tue Mar 27 13:02:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC9221F8624 for ; Tue, 27 Mar 2012 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.604 X-Spam-Level: ** X-Spam-Status: No, score=2.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDF86FvF6mQ8 for ; Tue, 27 Mar 2012 13:02:12 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 705F721F861F for ; Tue, 27 Mar 2012 13:02:12 -0700 (PDT) Received: from [10.125.133.90] (unknown [213.42.125.99]) by mail.sintact.nl (Postfix) with ESMTP id BFC28204A; Tue, 27 Mar 2012 22:02:10 +0200 (CEST) Subject: Re: 3484bis and privacy addresses Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <4F716D5C.40402@innovationslab.net> Date: Wed, 28 Mar 2012 00:02:09 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F716D5C.40402@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1257) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:02:13 -0000 Hi Brian, > Please state your preference for one of the following default = options : >=20 > A. Prefer public addresses over privacy addresses > B. Prefer privacy addresses over public addresses B. If an application wants to use the public address it will bind to it. = Applications that don't explicitly choose don't seem to care, and then = privacy addresses as default seems the best solution. - Sander From dominik.elsbroek@gmail.com Tue Mar 27 13:22:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D374521F874F for ; Tue, 27 Mar 2012 13:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA8QqIyJiVY7 for ; Tue, 27 Mar 2012 13:22:23 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 868B921F8653 for ; Tue, 27 Mar 2012 13:22:22 -0700 (PDT) Received: by yhkk25 with SMTP id k25so312083yhk.31 for ; Tue, 27 Mar 2012 13:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fNEExI2OlQxH6WKSTsNCycdgruAqq35ixdaRyBNxY1c=; b=AvJHwMQiloXDRjZuvkw6avCYTPPOQQfQQE+SFpBpgz9x3okc9PpyKulWCb9m4Kn4Hw v/dzpJgBwGFyhawq4Ls6epLnBSmPaZU6+IgOwXbedhkABQpFXdL5bCvh6jlQehvtOaWq l0a+ggU3mpv+lFQ/pd7ygBwFtFjQoyGrXU0uaTQv7/JYbqZCjjTlCqm/xwBSkjDz8z/U pMCV9lDROThbiTjJiLraKZKI9Jyb/6L+53aVTWFJfGYpi5CFHriQgbxiMlRYL+/p1RZx H+kKN6eeYOko/ptJ1HcCqfbdCYq9Egh6pCf/mL8KUVvKhYDgqHIUoyqfdCsKucseppJn nvJQ== MIME-Version: 1.0 Received: by 10.50.158.227 with SMTP id wx3mr305588igb.31.1332879741900; Tue, 27 Mar 2012 13:22:21 -0700 (PDT) Received: by 10.50.33.74 with HTTP; Tue, 27 Mar 2012 13:22:21 -0700 (PDT) In-Reply-To: References: <4F716D5C.40402@innovationslab.net> Date: Tue, 27 Mar 2012 22:22:21 +0200 Message-ID: Subject: Re: 3484bis and privacy addresses From: Dominik Elsbroek To: Sander Steffann Content-Type: text/plain; charset=ISO-8859-1 Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:22:23 -0000 > B. If an application wants to use the public address it will bind to it. Applications that don't explicitly choose don't seem to care, and then privacy addresses as default seems the best solution. > +1 From huitema@microsoft.com Tue Mar 27 14:00:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B04121E8026 for ; Tue, 27 Mar 2012 14:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56CfF3G12IOu for ; Tue, 27 Mar 2012 14:00:34 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2B86121E801E for ; Tue, 27 Mar 2012 14:00:34 -0700 (PDT) Received: from mail72-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Mar 2012 21:00:19 +0000 Received: from mail72-va3 (localhost [127.0.0.1]) by mail72-va3-R.bigfish.com (Postfix) with ESMTP id 7C5E42201E8; Tue, 27 Mar 2012 21:00:19 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail72-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=huitema@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail72-va3 (localhost.localdomain [127.0.0.1]) by mail72-va3 (MessageSwitch) id 1332882016692996_12976; Tue, 27 Mar 2012 21:00:16 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.249]) by mail72-va3.bigfish.com (Postfix) with ESMTP id A303136006F; Tue, 27 Mar 2012 21:00:16 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Mar 2012 21:00:14 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.3]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Tue, 27 Mar 2012 21:00:11 +0000 From: Christian Huitema To: Jari Arkko , "zhou.sujing@zte.com.cn" Subject: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00 Thread-Topic: about security level evaluation of draft-zhou-6man-mhash-cga-00 Thread-Index: AQHNDCUWKLxARtLzBUSojhXcXZo3xpZ+nkYw Date: Tue, 27 Mar 2012 21:00:09 +0000 Message-ID: References: <4F71CD00.8000208@piuha.net> In-Reply-To: <4F71CD00.8000208@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:00:35 -0000 > Well, I think it is quite a simple trade-off. Increasing Sec increases co= mputational effort on both sides by equal amount. Increasing the length of= =20 > the hash increases computational effort only on the attacker side. As a r= esult, the hash bits are relatively valuable. Jari, the effect of sec is different on both sides. The effort is not incre= ased "by equal amount" but rather "in the same proportion." Suppose that an= attacker could crack the 59 bit hash in a day with sec=3D0. Adding sec =3D= 1 means that the attacker will have to try 65536 times as many keys. The t= ime to crack becomes 65536 hours, i.e. about 7 years. The defender will hav= e to try 65536 instead of one to get the right sec, taking only a fraction= of a second.=20 > 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits of hash = length after accommodating for u and g bits as well. The good with this is= =20 > that it leaves maximum size for hash. The bad is that it is less flexible= for adding many new hash algorithms. I kind of like the status quo. > 2) The proposed new approach: Eat a total of six bits, for Sec and the ha= sh algorithm identifier. 56 bits remain. The good is that this gives more=20 > flexibility to allocate hash algorithms, including the ability to indepen= dently choose Sec and the algorithm. The bad is that the hash size is=20 > decreased. Decreased a lot. On the other hand, if we do gain the flexibility to define= new algorithms, then we can define a mandatory-to-implement algorithm that= incorporates the equivalent of the "sec" strengthening. -- Christian Huitema =20 From jari.arkko@piuha.net Tue Mar 27 14:23:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E091E21F8513 for ; Tue, 27 Mar 2012 14:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC3Bvz9ML-uE for ; Tue, 27 Mar 2012 14:23:01 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 576F021F8510 for ; Tue, 27 Mar 2012 14:23:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A87F12D35A; Wed, 28 Mar 2012 00:23:00 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymR3tl-r19jP; Wed, 28 Mar 2012 00:23:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id EE9F02CC56; Wed, 28 Mar 2012 00:22:59 +0300 (EEST) Message-ID: <4F722FB3.1010606@piuha.net> Date: Tue, 27 Mar 2012 23:22:59 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Christian Huitema Subject: Re: about security level evaluation of draft-zhou-6man-mhash-cga-00 References: <4F71CD00.8000208@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:23:02 -0000 Christian, >> Well, I think it is quite a simple trade-off. Increasing Sec increases computational effort on both sides by equal amount. Increasing the length of >> the hash increases computational effort only on the attacker side. As a result, the hash bits are relatively valuable. > Jari, the effect of sec is different on both sides. The effort is not increased "by equal amount" but rather "in the same proportion." Suppose that an attacker could crack the 59 bit hash in a day with sec=0. Adding sec = 1 means that the attacker will have to try 65536 times as many keys. The time to crack becomes 65536 hours, i.e. about 7 years. The defender will have to try 65536 instead of one to get the right sec, taking only a fraction of a second. Right. I was imprecise in what I said. In the same proportion is right. Jari From kauer@biplane.com.au Tue Mar 27 14:43:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272E121F85FC for ; Tue, 27 Mar 2012 14:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTTf7KcARDVf for ; Tue, 27 Mar 2012 14:43:41 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 5663621F85FB for ; Tue, 27 Mar 2012 14:43:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAN4zck+WZX+7/2dsb2JhbAANOIVAtjYBAQEEI2YLGCoCAlcZsDOSAI1rggyBGAShFYd0gUAX Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.207]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 28 Mar 2012 08:13:32 +1030 Subject: Re: 3484bis and privacy addresses From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F720F7F.2090108@globis.net> References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> <4F720F7F.2090108@globis.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HXbm1wWBOrLvwRZwy8Hg" Date: Wed, 28 Mar 2012 08:43:29 +1100 Message-ID: <1332884609.2633.22.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:43:42 -0000 --=-HXbm1wWBOrLvwRZwy8Hg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote: > IMHO the proper *default* behavior is still "off" =3D option A. In other > words, default =3D IPv4-like behavior, at least until we really figure > out how to operate all of these fancy new features of IPv6. The question is not whether the use of privacy addresses (temporary addresses) should be enabled by default. Though some OSes do that, I believe. The question is, where a host *does* have both a temporary and a non-temporary addresses, which one it should prefer by default. "Prefer by default" in this case means "select as the source address for new outbound connections in the absence of specific instructions to do otherwise". Regards, K. =20 --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-HXbm1wWBOrLvwRZwy8Hg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk9yNHkACgkQFpl7eE7uYBc3sAEAqEaaUg33kAZ5ymFSb7FaP5Wa aZRNyNEK/WM9eGVF+EMA/3wAlsFTwhFsuDi+JVXg7BoSRQPN0gvphfDed+erYV5Q =J8L1 -----END PGP SIGNATURE----- --=-HXbm1wWBOrLvwRZwy8Hg-- From bs7652@att.com Tue Mar 27 16:12:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1C921E8024 for ; Tue, 27 Mar 2012 16:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.363 X-Spam-Level: X-Spam-Status: No, score=-104.363 tagged_above=-999 required=5 tests=[AWL=-1.764, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoUWEnfi+r4c for ; Tue, 27 Mar 2012 16:12:37 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1021E800C for ; Tue, 27 Mar 2012 16:12:36 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 269427f4.0.921387.00-266.2575014.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 27 Mar 2012 23:12:37 +0000 (UTC) X-MXL-Hash: 4f7249650391d845-2a68fbd045dd68bdb330d3723e7b46deb4d61efa Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2RNCYvu007926 for ; Tue, 27 Mar 2012 19:12:34 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2RNCTeZ007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Mar 2012 19:12:29 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint03.pst.cso.att.com (RSA Interceptor) for ; Tue, 27 Mar 2012 19:12:06 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.156]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 19:12:05 -0400 From: "STARK, BARBARA H" To: "ipv6@ietf.org" Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNC+v+2U4M41ZD9E+yTBxtVxQMXJZ+oVWAgAAL1ICAABc6gIAALB6A///Pe+A= Date: Tue, 27 Mar 2012 23:12:04 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611078EFB@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> <4F720F7F.2090108@globis.net> <1332884609.2633.22.camel@karl> In-Reply-To: <1332884609.2633.22.camel@karl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.181.125] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=-zmdt4OLJFcA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=IkcTkHD0fZMA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=vF] X-AnalysisOut: [e4QFSVHcmGuUoLv0EA:9 a=sUXQSeghq9yqauk1UVgA:7 a=QEXdDO2ut3] X-AnalysisOut: [YA:10 a=PWP-GHiY0KrSVWbz:21 a=b8Ss305SxOfTd1gq:21] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 23:12:38 -0000 SSB0aGluayB0aGUgcnVsZXMgZm9yIHdoaWNoICh0ZW1wb3JhcnkgdnMgbm90IHRlbXBvcmFyeSkg dG8gdXNlIHNob3VsZCBiZSBhcHBsaWNhdGlvbi1zcGVjaWZpYy4gQW5kIHRoZSBwZW9wbGUgd2hv IGFyZSBiZXN0LXBvc2l0aW9uZWQgdG8gZGV0ZXJtaW5lIHdoYXQncyByaWdodCBmb3IgdGhlIGFw cCBhcmUgdGhlIGFwcCBkZXZlbG9wZXJzIG9yIGRlc2lnbmVycy4gTm90IElFVEYuDQoNCkkgdm90 ZSBmb3IgMzQ4NGJpcyB0byByZW1haW4gc2lsZW50IGFzIHRvIGEgcHJlZmVyZW5jZSwgYnV0IHRv IHByb3ZpZGUgZ3VpZGFuY2UgYXMgdG8gd2hhdCBtaWdodCBjYXVzZSBhbiBhcHAgdG8gc2VsZWN0 IG9uZSBhZGRyZXNzIG92ZXIgdGhlIG90aGVyLg0KDQpBcHBzIHRoYXQgYXJlbid0IGRlc2lnbmVk IGZvciBJbnRlcm5ldCBhY2Nlc3MgKGUuZy4sIFVQblAsIGVudGVycHJpc2UgYXBwbGljYXRpb25z IHRvIHJ1biBvbiBjb3Jwb3JhdGUgZGV2aWNlcyBpbnNpZGUgdGhlIGNvcnBvcmF0ZSBuZXR3b3Jr KSBoYXZlIG5vIG5lZWQgZm9yIHRlbXBvcmFyeSBhZGRyZXNzZXMsIGFuZCBtYXkgZmluZCB0aGF0 IHRoZXkgY2F1c2UgYSBiYWQgdXNlciBleHBlcmllbmNlLiBBcHBzIHRoYXQgcmVnaXN0ZXIgdGhl aXIgcHJlc2VuY2Ugd2l0aCBhIHNlcnZlciAobGlrZSBhIFNJUCByZWdpc3RyYXRpb24gc2VydmVy KSBhcmUgaWxsLXNlcnZlZCBieSB0ZW1wb3JhcnkgYWRkcmVzc2VzLiBBcHBzIHRoYXQgbmVlZCB0 byBiZSBhYmxlIHRvIHJlY2VpdmUgdW5zb2xpY2l0ZWQgdHJhZmZpYyBzaG91bGRuJ3QgdXNlIHRl bXBvcmFyeSBhZGRyZXNzZXMuIE9uIHRoZSBvdGhlciBoYW5kLCBJIHRoaW5rIEknZCBwcmVmZXIg aWYgbXkgd2ViIGJyb3dzZXIgZGlkIHVzZSBhIHRlbXBvcmFyeSBhZGRyZXNzLCBpZiB0aGF0IGZl YXR1cmUgd2VyZSBlbmFibGVkIG9uIG15IGRldmljZS4NCkJhcmJhcmENCg== From kauer@biplane.com.au Tue Mar 27 16:26:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1775D21E80AD for ; Tue, 27 Mar 2012 16:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7Dmswu-6Cmu for ; Tue, 27 Mar 2012 16:26:38 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 428BD21E800C for ; Tue, 27 Mar 2012 16:26:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFpLck+WZX+7/2dsb2JhbAANOIVAtjYBAQEDASNbCwsYKgICVxmIBagmkXmNa4IMgRgEoRWHdIFAFw Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.207]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 28 Mar 2012 09:56:36 +1030 Subject: RE: 3484bis and privacy addresses From: Karl Auer To: ipv6@ietf.org In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611078EFB@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> <4F720F7F.2090108@globis.net> <1332884609.2633.22.camel@karl> <2D09D61DDFA73D4C884805CC7865E611078EFB@GAALPA1MSGUSR9N.ITServices.sbc.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-cuyu1Z7ItruxShYdmCoW" Date: Wed, 28 Mar 2012 10:26:32 +1100 Message-ID: <1332890792.2633.84.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 23:26:39 -0000 --=-cuyu1Z7ItruxShYdmCoW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-03-27 at 23:12 +0000, STARK, BARBARA H wrote: > I think the rules for which (temporary vs not temporary) to use should > be application-specific. And the people who are best-positioned to > determine what's right for the app are the app developers or > designers. Not IETF. The application always has that control anyway. The very first source address selection rule is "use the source address the application specifies". The other source address selection rules apply only if the application does not specify a source address. > I vote for 3484bis to remain silent as to a preference, Leaving the source address preference unspecified won't change anything for applications, but will lead to some implementations preferring privacy addresses and some implementations preferring non-privacy addresses. In general, standards should be deterministic - given the same circumstances, all implementations should behave the same way. Hence the need for a default position. Regards, K. =20 --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-cuyu1Z7ItruxShYdmCoW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk9yTKIACgkQFpl7eE7uYBf9qgEAi3/1hZvuJj/N+U0FJtcNzwru 6k7HoNcvAkVIlPOMeXUBALSHi1rfFCH9yMvu05x0NPcIHo7vUP+Q96UV6XCl7uTS =S1On -----END PGP SIGNATURE----- --=-cuyu1Z7ItruxShYdmCoW-- From brian.e.carpenter@gmail.com Tue Mar 27 18:43:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35021E8018 for ; Tue, 27 Mar 2012 18:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J93QZOIfGDz6 for ; Tue, 27 Mar 2012 18:43:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9C21E8012 for ; Tue, 27 Mar 2012 18:43:05 -0700 (PDT) Received: by iazz13 with SMTP id z13so765949iaz.31 for ; Tue, 27 Mar 2012 18:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BE0eEqt8CpS2txisS06Flmbcx9WUH2LH+rrsb/00AjA=; b=QL5ROw6mNM/id06V54JqZET20J1z28Pc5QeaXxkEDydvPFXnWIvx+Kq9x6aR1IuXZL 6PlZu1ztNLroQFfjTeaild7aj3FotxnIQNon+BLYpFbCE+UeESAU8cU9niZNwN/nJ1jD 6DdampjX/BsLMSNSVeliZdm0eG1Be2gfDs0UY+Xy+cg+zCs2D454OxJwy0cNoVlbwHRB +jPB2t5dpGP44kGzRb5oYIoIolUitYEoff3UJXF0LB++8rI1JYyACeNk1xB6E78UmPnB HISSPjrZidQPgyFBlXzwaTfb8xOzkqg4NkbRnnJhwm0sFjloUpLjwpiP7cda0aZnxdLV Fr4w== Received: by 10.50.51.197 with SMTP id m5mr804836igo.38.1332898984983; Tue, 27 Mar 2012 18:43:04 -0700 (PDT) Received: from [192.168.182.50] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id cw5sm13871014igc.17.2012.03.27.18.43.02 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 18:43:04 -0700 (PDT) Message-ID: <4F726C9E.50107@gmail.com> Date: Wed, 28 Mar 2012 14:42:54 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> In-Reply-To: <4F716D5C.40402@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 01:43:06 -0000 On 2012-03-27 20:33, Brian Haberman wrote: ... > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses In terms of a general default in shipped IPv6 stacks, I prefer B, but it has to be qualified: There MUST be a user option to change this preference. There SHOULD be a network manager option to change this preference. The rationale for this is that we need privacy by default in shipped products, with the ability for the person deploying the product to override this. Brian C From rogerj@gmail.com Tue Mar 27 23:43:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F6F21F8798 for ; Tue, 27 Mar 2012 23:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6rKE9qXxK2C for ; Tue, 27 Mar 2012 23:43:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9857321F8796 for ; Tue, 27 Mar 2012 23:43:41 -0700 (PDT) Received: by iazz13 with SMTP id z13so1154358iaz.31 for ; Tue, 27 Mar 2012 23:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wwfgHs+rpMhrk6ecyJZ0vZEuNqlJZLXTA9/P0Xd0ZA4=; b=wWJyAS5XKi8jAba4wPSMTNkrpVdVxbx8NFASFAhjhKkjEb8z0f8Rb3h4pPIKdRODBD kvK52/ynxnAg2KE6rEWxzKWca7/iIKvvwzDhKS7gmVfRKbw8Zr3NRYuIwsuBRoM4eDnu zKoSdgW2a26L8Tx1ZTZMB0lpJgueWBxvSzjSzGTJzo0gCWBZTAyO0kiZ3JkrOnRi5pit mI8O9XTClUKdD+2t08um5obWhPlg6pt2o6Ho0q/L0KLICtQLid76BFC9jBWf0WLDvNHr uuefv8Xzb7AZFlOmNSF6LhwDIxIPlKVDTToJ1lIhOudVo/Zp53whTexDtmEKD85CtRHg 7E6A== MIME-Version: 1.0 Received: by 10.50.194.163 with SMTP id hx3mr1194395igc.49.1332917021210; Tue, 27 Mar 2012 23:43:41 -0700 (PDT) Received: by 10.42.117.200 with HTTP; Tue, 27 Mar 2012 23:43:41 -0700 (PDT) In-Reply-To: <4F716D5C.40402@innovationslab.net> References: <4F716D5C.40402@innovationslab.net> Date: Wed, 28 Mar 2012 08:43:41 +0200 Message-ID: Subject: Re: 3484bis and privacy addresses From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:43:42 -0000 On Tue, Mar 27, 2012 at 9:33 AM, Brian Haberman wrote: > All, > =A0 =A0 The chairs would like to get a sense of the working group on chan= ging > the current (defined 3484) model of preferring public addresses over priv= acy > addresses during the address selection process. =A0RFC 3484 prefers publi= c > addresses with the ability (MAY) of an implementation to reverse the > preference. =A0The suggestion has been made to reverse that preference in > 3484bis (prefer privacy addresses over public ones). Regardless, the > document will allow implementers/users to reverse the default preference. > > =A0 =A0 Please state your preference for one of the following default opt= ions : > > A. Prefer public addresses over privacy addresses > > B. Prefer privacy addresses over public addresses If it also is stated that there _should_ be an options to override it either by policy (Enterprise/Corp) or by manual (typical end-user), then I would say options B over A. --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From Francis.Dupont@fdupont.fr Wed Mar 28 00:04:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D414921E8150 for ; Wed, 28 Mar 2012 00:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcnzMSSwrnYu for ; Wed, 28 Mar 2012 00:04:11 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 24FE621E80E7 for ; Wed, 28 Mar 2012 00:04:10 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2S748P3088148; Wed, 28 Mar 2012 09:04:08 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203280704.q2S748P3088148@givry.fdupont.fr> From: Francis Dupont To: Ray Hunter Subject: Re: 3484bis and privacy addresses In-reply-to: Your message of Tue, 27 Mar 2012 19:00:07 +0200. <4F71F217.7000209@globis.net> Date: Wed, 28 Mar 2012 09:04:08 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:04:13 -0000 In your previous mail you wrote: > Also not sure if any DHCPv6 server implementations actually provide > DHCPv6 assigned temporary addresses in practice. => I coded this for the ISC DHCP some years ago so I am sure there is at least one. Regards Francis.Dupont@fdupont.fr From jonne.soininen@renesasmobile.com Wed Mar 28 01:52:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E17521F88A9 for ; Wed, 28 Mar 2012 01:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVo3mTcfx+NL for ; Wed, 28 Mar 2012 01:52:49 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id DD31521F88CC for ; Wed, 28 Mar 2012 01:52:47 -0700 (PDT) Received: from [85.158.143.99:19241] by server-2.bemta-4.messagelabs.com id 4F/3A-17550-E51D27F4; Wed, 28 Mar 2012 08:52:46 +0000 X-Env-Sender: jonne.soininen@renesasmobile.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1332924766!17806822!1 X-Originating-IP: [213.174.82.10] X-StarScan-Version: 6.5.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10194 invoked from network); 28 Mar 2012 08:52:46 -0000 Received: from renexfe01.roe2.renesasmobile.com (HELO renexfe01.roe2.renesasmobile.com) (213.174.82.10) by server-7.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 28 Mar 2012 08:52:46 -0000 Received: from RENEXMB02.roe2.renesasmobile.com ([fe80::b101:43e1:dd7b:2fbb]) by renexfe01.roe2.renesasmobile.com ([fe80::ec94:bbb3:68e:a94a%18]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 11:52:45 +0300 From: To: , Subject: Re: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNDMAkZl0Y/ANQ6EeFzZa0VBEByg== Date: Wed, 28 Mar 2012 08:52:45 +0000 Message-ID: In-Reply-To: <4F716D5C.40402@innovationslab.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.22.171] Content-Type: text/plain; charset="us-ascii" Content-ID: <263142BA71F2894DA6EA6750760964E5@renesasmobile.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:52:50 -0000 Hello, I vote for B. I think it makes sense for applications get privacy by default and applications that need the more persistent addresses will explicitly ask for one. Cheers, Jonne. --=20 Jonne Soininen Renesas Mobile Tel: +358 40 527 4634 E-mail: jonne.soininen@renesasmobile.com On 3/27/12 10:33 AM, "Brian Haberman" wrote: >All, > The chairs would like to get a sense of the working group on >changing the current (defined 3484) model of preferring public addresses >over privacy addresses during the address selection process. RFC 3484 >prefers public addresses with the ability (MAY) of an implementation to >reverse the preference. The suggestion has been made to reverse that >preference in 3484bis (prefer privacy addresses over public ones). >Regardless, the document will allow implementers/users to reverse the >default preference. > > Please state your preference for one of the following default >options : > >A. Prefer public addresses over privacy addresses > >B. Prefer privacy addresses over public addresses > >Regards, >Brian, Bob, & Ole >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From v6ops@globis.net Wed Mar 28 02:14:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEAB21E8028 for ; Wed, 28 Mar 2012 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM-7cAMWXeDj for ; Wed, 28 Mar 2012 02:14:41 -0700 (PDT) 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 DA3F521E801A for ; Wed, 28 Mar 2012 02:14:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C4FC18700BB; Wed, 28 Mar 2012 11:14:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAVRcW0vmiJZ; Wed, 28 Mar 2012 11:14:31 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 03E6D8700B8; Wed, 28 Mar 2012 11:14:30 +0200 (CEST) Message-ID: <4F72D676.7060803@globis.net> Date: Wed, 28 Mar 2012 11:14:30 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Karl Auer Subject: Re: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> <4F720F7F.2090108@globis.net> <1332884609.2633.22.camel@karl> In-Reply-To: <1332884609.2633.22.camel@karl> Content-Type: multipart/alternative; boundary="------------060901050305070303070006" Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:14:42 -0000 This is a multi-part message in MIME format. --------------060901050305070303070006 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Draft RFC3484bis-01 currently references RFC4941 as a normative reference in Section 11.1: > Privacy considerations have introduced the concepts of "public > addresses" and "temporary addresses" [RFC4941 ]. So I think we have to assume that a node will have such addresses present by default when considering RFC3484bis. I could completely agree with your logic if RFC3484bis did not have RFC4941 as a normative reference, or if 3484bis was coupled with draft-gont-6man-managing-slaac-policy-00, or draft-ietf-6man-addr-select-opt-03 was already deployed in the field, or the M&O bits of RA were defined to force use of DHCPv6, or there was a common proprietary cross-OS mechanism available or indeed anything else that would allow a network manager to reliably control use of temporary addresses. But there isn't AFAIK. Unless you also intentionally break SLAAC. So IMHO, in the absence of any other reliable OFF switch, RFC3484-bis itself currently really is the only place where a reliable default "OFF" can be specified at this time. I don't mind how this is achieved: either in the preference rules themselves, or in other clarification text that describes safe default backwards-compatible end-node behavior that will not break other systems that currently rely on IPv4-like behavior. regards, RayH Karl Auer wrote: > On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote: > >> IMHO the proper *default* behavior is still "off" = option A. In other >> words, default = IPv4-like behavior, at least until we really figure >> out how to operate all of these fancy new features of IPv6. >> > > The question is not whether the use of privacy addresses (temporary > addresses) should be enabled by default. Though some OSes do that, I > believe. > > The question is, where a host *does* have both a temporary and a > non-temporary addresses, which one it should prefer by default. "Prefer > by default" in this case means "select as the source address for new > outbound connections in the absence of specific instructions to do > otherwise". > > Regards, K. > > --------------060901050305070303070006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Draft RFC3484bis-01 currently references RFC4941 as a normative reference in Section 11.1: 
Privacy considerations have introduced the concepts of "public
   addresses" and "temporary addresses" [RFC4941].
So I think we have to assume that a node will have such addresses present by default when considering RFC3484bis.

I could completely agree with your logic if RFC3484bis did not have RFC4941 as a normative reference, or if 3484bis was coupled with draft-gont-6man-managing-slaac-policy-00, or draft-ietf-6man-addr-select-opt-03 was already deployed in the field,  or the M&O bits of RA were defined to force use of DHCPv6, or there was a common proprietary cross-OS mechanism available or indeed anything else that would allow a network manager to reliably control use of temporary addresses. But there isn't AFAIK. Unless you also intentionally break SLAAC.

So IMHO, in the absence of any other reliable OFF switch, RFC3484-bis itself currently really is the only place where a reliable default "OFF" can be specified at this time. I don't mind how this is achieved: either in the preference rules themselves, or in other clarification text that describes safe default backwards-compatible end-node behavior that will not break other systems that currently rely on IPv4-like behavior.

regards,
RayH


Karl Auer wrote: 
On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote:
  
IMHO the proper *default* behavior is still "off" = option A. In other
words, default = IPv4-like behavior, at least until we really figure
out how to operate all of these fancy new features of IPv6.
    

The question is not whether the use of privacy addresses (temporary
addresses) should be enabled by default. Though some OSes do that, I
believe.

The question is, where a host *does* have both a temporary and a
non-temporary addresses, which one it should prefer by default. "Prefer
by default" in this case means "select as the source address for new
outbound connections in the absence of specific instructions to do
otherwise".

Regards, K.
--------------060901050305070303070006-- From zhou.sujing@zte.com.cn Wed Mar 28 04:46:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D1021F8973 for ; Wed, 28 Mar 2012 04:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.562 X-Spam-Level: X-Spam-Status: No, score=-94.562 tagged_above=-999 required=5 tests=[AWL=-1.772, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyM1ViC0VeMg for ; Wed, 28 Mar 2012 04:46:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A91AC21F896D for ; Wed, 28 Mar 2012 04:46:06 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201320096835; Wed, 28 Mar 2012 19:10:43 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 93082.5338359427; Wed, 28 Mar 2012 19:45:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2SBji2d057872; Wed, 28 Mar 2012 19:45:44 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Christian Huitema Subject: =?GB2312?B?tPC4tDogUkU6IGFib3V0IHNlY3VyaXR5IGxldmVsIGV2YWx1YXRpb24gb2Y=?= =?GB2312?B?ICBkcmFmdC16aG91LTZtYW4tbWhhc2gtY2dhLTAw?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 28 Mar 2012 12:45:33 +0100 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-28 19:45:47, Serialize complete at 2012-03-28 19:45:47 Content-Type: multipart/alternative; boundary="=_alternative 00409BA7C12579CF_=" X-MAIL: mse02.zte.com.cn q2SBji2d057872 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:46:08 -0000 This is a multipart message in MIME format. --=_alternative 00409BA7C12579CF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFA bWljcm9zb2Z0LmNvbT4g0LTT2iAyMDEyLTAzLTI3IDIzOjAwOjA5Og0KDQo+ID4gV2VsbCwgSSB0 aGluayBpdCBpcyBxdWl0ZSBhIHNpbXBsZSB0cmFkZS1vZmYuIEluY3JlYXNpbmcgU2VjIA0KPiBp bmNyZWFzZXMgY29tcHV0YXRpb25hbCBlZmZvcnQgb24gYm90aCBzaWRlcyBieSBlcXVhbCBhbW91 bnQuIA0KPiBJbmNyZWFzaW5nIHRoZSBsZW5ndGggb2YgDQo+ID4gdGhlIGhhc2ggaW5jcmVhc2Vz IGNvbXB1dGF0aW9uYWwgZWZmb3J0IG9ubHkgb24gdGhlIGF0dGFja2VyIHNpZGUuDQo+IEFzIGEg cmVzdWx0LCB0aGUgaGFzaCBiaXRzIGFyZSByZWxhdGl2ZWx5IHZhbHVhYmxlLg0KPiANCj4gSmFy aSwgdGhlIGVmZmVjdCBvZiBzZWMgaXMgZGlmZmVyZW50IG9uIGJvdGggc2lkZXMuIFRoZSBlZmZv cnQgaXMgDQo+IG5vdCBpbmNyZWFzZWQgImJ5IGVxdWFsIGFtb3VudCIgYnV0IHJhdGhlciAiaW4g dGhlIHNhbWUgcHJvcG9ydGlvbi4iDQo+IFN1cHBvc2UgdGhhdCBhbiBhdHRhY2tlciBjb3VsZCBj cmFjayB0aGUgNTkgYml0IGhhc2ggaW4gYSBkYXkgd2l0aCANCj4gc2VjPTAuIEFkZGluZyBzZWMg PSAxIG1lYW5zIHRoYXQgdGhlIGF0dGFja2VyIHdpbGwgaGF2ZSB0byB0cnkgNjU1MzYNCj4gdGlt ZXMgYXMgbWFueSBrZXlzLiBUaGUgdGltZSB0byBjcmFjayBiZWNvbWVzIDY1NTM2IGhvdXJzLCBp LmUuIA0KPiBhYm91dCA3IHllYXJzLiBUaGUgZGVmZW5kZXIgd2lsbCBoYXZlIHRvIHRyeSA2NTUz NiBpbnN0ZWFkIG9mIG9uZSB0bw0KPiBnZXQgdGhlIHJpZ2h0IHNlYywgdGFraW5nIG9ubHkgIGEg ZnJhY3Rpb24gb2YgYSBzZWNvbmQuIA0KDQphZnRlciBhdHRhY2tlciBoYXMgY3JhY2tlZCBhIENH QSBhZGRyZXNzLCB0aGVuIGl0IGlzIGluIHRoZSBzYW1lIHN0YW5kIGFzIA0KdGhlIGRlZmVuZGVy Lg0KZGVmZW5kZXIsIGFzIHdlbGwgYXMgYXR0YWNrZXIsIGhhcyB0byB0cnkgb25lIGJ5IG9uZSB0 byBnZXQgdGhlIHJpZ2h0IHNlYywgDQppLmUuLCB0byBnZXQgYSBtYXRjaGluZyBsZW5ndGggb2Yg emVyb3MsDQpob3cgY29tZSBhdHRhY2tlciBuZWVkIGV4dHJhIDY1NTM2IGhvdXJzIGJ1dCBkZWZl bmRlciBvbmx5IG5lZWRzIGEgDQpmcmFjdGlvbiBvZiBhIHNlY29uZD8NCiANCj4gPiAxKSBTdGF0 dXMgcXVvOiBSRkMgNDk4MiBlYXRzIHRocmVlIGJpdHMgZm9yIFNlYywgbGVhdmluZyA1OSBiaXRz IA0KPiBvZiBoYXNoIGxlbmd0aCBhZnRlciBhY2NvbW1vZGF0aW5nIGZvciB1IGFuZCBnIGJpdHMg YXMgd2VsbC4gVGhlIA0KPiBnb29kIHdpdGggdGhpcyBpcyANCj4gPiB0aGF0IGl0IGxlYXZlcyBt YXhpbXVtIHNpemUgZm9yIGhhc2guIFRoZSBiYWQgaXMgdGhhdCBpdCBpcyBsZXNzIA0KPiBmbGV4 aWJsZSBmb3IgYWRkaW5nIG1hbnkgbmV3IGhhc2ggYWxnb3JpdGhtcy4NCj4gDQo+IEkga2luZCBv ZiBsaWtlIHRoZSBzdGF0dXMgcXVvLg0KPiANCj4gPiAyKSBUaGUgcHJvcG9zZWQgbmV3IGFwcHJv YWNoOiBFYXQgYSB0b3RhbCBvZiBzaXggYml0cywgZm9yIFNlYyBhbmQNCj4gdGhlIGhhc2ggYWxn b3JpdGhtIGlkZW50aWZpZXIuIDU2IGJpdHMgcmVtYWluLiBUaGUgZ29vZCBpcyB0aGF0IHRoaXMN Cj4gZ2l2ZXMgbW9yZSANCj4gPiBmbGV4aWJpbGl0eSB0byBhbGxvY2F0ZSBoYXNoIGFsZ29yaXRo bXMsIGluY2x1ZGluZyB0aGUgYWJpbGl0eSB0byANCj4gaW5kZXBlbmRlbnRseSBjaG9vc2UgU2Vj IGFuZCB0aGUgYWxnb3JpdGhtLiBUaGUgYmFkIGlzIHRoYXQgdGhlIGhhc2ggDQpzaXplIGlzIA0K PiA+IGRlY3JlYXNlZC4NCj4gDQo+IERlY3JlYXNlZCBhIGxvdC4gT24gdGhlIG90aGVyIGhhbmQs IGlmIHdlIGRvIGdhaW4gdGhlIGZsZXhpYmlsaXR5IHRvDQo+IGRlZmluZSBuZXcgYWxnb3JpdGht cywgdGhlbiB3ZSBjYW4gZGVmaW5lIGEgbWFuZGF0b3J5LXRvLWltcGxlbWVudCANCj4gYWxnb3Jp dGhtIHRoYXQgaW5jb3Jwb3JhdGVzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSAic2VjIiBzdHJlbmd0 aGVuaW5nLg0KDQp0aGUgc2VjdXJpdHkgb2YgYSBoYXNoIGFsZ28gY2FuIGJlIHJvdWdobHkgZXN0 aW1hdGVkIGJ5IGxlbmd0aCBvZiBpdHMgDQpvdXRwdXQsDQpmcm9tIGJpcnRoZGF5IGF0dGFjaywg dGhhdCBpcyBhYm91dCAyXig1OS8yKSBvciAyXig1Ni8yKSh0aGVvcmljYWwgDQplc3RpbWF0ZSks IG9yIGxlc3MsDQpjYW4geW91IGdpdmUgYSBtb3JlIHByZWNpc2Ugb2YgdmFsdWUgb2YgImEgbG90 Ij8NCkkgZG9uJ3Qgc2VlIGZsZXhpYmlsaXR5IGluIGRlZmluaW5nIG1hbmRhdG9yeS10by1pbXBs ZW1lbnRpbmcgaGFzaCBhbGcgDQogDQo+IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+IA0KPiANCj4g DQo+IA0KDQo= --=_alternative 00409BA7C12579CF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5DaHJpc3Rp YW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBtaWNyb3NvZnQuY29tJmd0OyDQtNPaDQoyMDEyLTAzLTI3 IDIzOjAwOjA5Ojxicj4NCjxicj4NCiZndDsgJmd0OyBXZWxsLCBJIHRoaW5rIGl0IGlzIHF1aXRl IGEgc2ltcGxlIHRyYWRlLW9mZi4gSW5jcmVhc2luZyBTZWMNCjxicj4NCiZndDsgaW5jcmVhc2Vz IGNvbXB1dGF0aW9uYWwgZWZmb3J0IG9uIGJvdGggc2lkZXMgYnkgZXF1YWwgYW1vdW50LiA8YnI+ DQomZ3Q7IEluY3JlYXNpbmcgdGhlIGxlbmd0aCBvZiA8YnI+DQomZ3Q7ICZndDsgdGhlIGhhc2gg aW5jcmVhc2VzIGNvbXB1dGF0aW9uYWwgZWZmb3J0IG9ubHkgb24gdGhlIGF0dGFja2VyDQpzaWRl Ljxicj4NCiZndDsgQXMgYSByZXN1bHQsIHRoZSBoYXNoIGJpdHMgYXJlIHJlbGF0aXZlbHkgdmFs dWFibGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEphcmksIHRoZSBlZmZlY3Qgb2Ygc2VjIGlzIGRp ZmZlcmVudCBvbiBib3RoIHNpZGVzLiBUaGUgZWZmb3J0IGlzDQo8YnI+DQomZ3Q7IG5vdCBpbmNy ZWFzZWQgJnF1b3Q7YnkgZXF1YWwgYW1vdW50JnF1b3Q7IGJ1dCByYXRoZXIgJnF1b3Q7aW4gdGhl DQpzYW1lIHByb3BvcnRpb24uJnF1b3Q7PGJyPg0KJmd0OyBTdXBwb3NlIHRoYXQgYW4gYXR0YWNr ZXIgY291bGQgY3JhY2sgdGhlIDU5IGJpdCBoYXNoIGluIGEgZGF5IHdpdGgNCjxicj4NCiZndDsg c2VjPTAuIEFkZGluZyBzZWMgPSAxIG1lYW5zIHRoYXQgdGhlIGF0dGFja2VyIHdpbGwgaGF2ZSB0 byB0cnkgNjU1MzY8YnI+DQomZ3Q7IHRpbWVzIGFzIG1hbnkga2V5cy4gVGhlIHRpbWUgdG8gY3Jh Y2sgYmVjb21lcyA2NTUzNiBob3VycywgaS5lLiA8YnI+DQomZ3Q7IGFib3V0IDcgeWVhcnMuIFRo ZSBkZWZlbmRlciB3aWxsIGhhdmUgdG8gdHJ5IDY1NTM2IGluc3RlYWQgb2Ygb25lDQp0bzxicj4N CiZndDsgZ2V0IHRoZSByaWdodCBzZWMsIHRha2luZyBvbmx5ICZuYnNwO2EgZnJhY3Rpb24gb2Yg YSBzZWNvbmQuIDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+YWZ0ZXIg YXR0YWNrZXIgaGFzIGNyYWNrZWQgYSBDR0EgYWRkcmVzcywgdGhlbiBpdA0KaXMgaW4gdGhlIHNh bWUgc3RhbmQgYXMgdGhlIGRlZmVuZGVyLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+ZGVmZW5kZXIsIGFzIHdlbGwgYXMgYXR0YWNrZXIsIGhhcyB0byB0cnkgb25lIGJ5IG9uZQ0K dG8gZ2V0IHRoZSByaWdodCBzZWMsIGkuZS4sIHRvIGdldCBhIG1hdGNoaW5nIGxlbmd0aCBvZiB6 ZXJvcyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmhvdyBjb21lIGF0dGFja2Vy IG5lZWQgZXh0cmEgNjU1MzYgaG91cnMgYnV0IGRlZmVuZGVyDQpvbmx5IG5lZWRzIGEgZnJhY3Rp b24gb2YgYSBzZWNvbmQ/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDs8 YnI+DQomZ3Q7ICZndDsgMSkgU3RhdHVzIHF1bzogUkZDIDQ5ODIgZWF0cyB0aHJlZSBiaXRzIGZv ciBTZWMsIGxlYXZpbmcgNTkgYml0cw0KPGJyPg0KJmd0OyBvZiBoYXNoIGxlbmd0aCBhZnRlciBh Y2NvbW1vZGF0aW5nIGZvciB1IGFuZCBnIGJpdHMgYXMgd2VsbC4gVGhlIDxicj4NCiZndDsgZ29v ZCB3aXRoIHRoaXMgaXMgPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgaXQgbGVhdmVzIG1heGltdW0gc2l6 ZSBmb3IgaGFzaC4gVGhlIGJhZCBpcyB0aGF0IGl0IGlzIGxlc3MNCjxicj4NCiZndDsgZmxleGli bGUgZm9yIGFkZGluZyBtYW55IG5ldyBoYXNoIGFsZ29yaXRobXMuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEkga2luZCBvZiBsaWtlIHRoZSBzdGF0dXMgcXVvLjxicj4NCiZndDsgPGJyPg0KJmd0OyAm Z3Q7IDIpIFRoZSBwcm9wb3NlZCBuZXcgYXBwcm9hY2g6IEVhdCBhIHRvdGFsIG9mIHNpeCBiaXRz LCBmb3IgU2VjDQphbmQ8YnI+DQomZ3Q7IHRoZSBoYXNoIGFsZ29yaXRobSBpZGVudGlmaWVyLiA1 NiBiaXRzIHJlbWFpbi4gVGhlIGdvb2QgaXMgdGhhdCB0aGlzPGJyPg0KJmd0OyBnaXZlcyBtb3Jl IDxicj4NCiZndDsgJmd0OyBmbGV4aWJpbGl0eSB0byBhbGxvY2F0ZSBoYXNoIGFsZ29yaXRobXMs IGluY2x1ZGluZyB0aGUgYWJpbGl0eQ0KdG8gPGJyPg0KJmd0OyBpbmRlcGVuZGVudGx5IGNob29z ZSBTZWMgYW5kIHRoZSBhbGdvcml0aG0uIFRoZSBiYWQgaXMgdGhhdCB0aGUgaGFzaA0Kc2l6ZSBp cyA8YnI+DQomZ3Q7ICZndDsgZGVjcmVhc2VkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBEZWNyZWFz ZWQgYSBsb3QuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSBkbyBnYWluIHRoZSBmbGV4aWJpbGl0 eQ0KdG88YnI+DQomZ3Q7IGRlZmluZSBuZXcgYWxnb3JpdGhtcywgdGhlbiB3ZSBjYW4gZGVmaW5l IGEgbWFuZGF0b3J5LXRvLWltcGxlbWVudA0KPGJyPg0KJmd0OyBhbGdvcml0aG0gdGhhdCBpbmNv cnBvcmF0ZXMgdGhlIGVxdWl2YWxlbnQgb2YgdGhlICZxdW90O3NlYyZxdW90Ow0Kc3RyZW5ndGhl bmluZy48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnRoZSBzZWN1cml0 eSBvZiBhIGhhc2ggYWxnbyBjYW4gYmUgcm91Z2hseSBlc3RpbWF0ZWQNCmJ5IGxlbmd0aCBvZiBp dHMgb3V0cHV0LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ZnJvbSBiaXJ0aGRh eSBhdHRhY2ssIHRoYXQgaXMgYWJvdXQgMl4oNTkvMikgb3IgMl4oNTYvMikodGhlb3JpY2FsDQpl c3RpbWF0ZSksIG9yIGxlc3MsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5jYW4g eW91IGdpdmUgYSBtb3JlIHByZWNpc2Ugb2YgdmFsdWUgb2YgJnF1b3Q7YSBsb3QmcXVvdDs/PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JIGRvbid0IHNlZSBmbGV4aWJpbGl0eSBp biBkZWZpbmluZyBtYW5kYXRvcnktdG8taW1wbGVtZW50aW5nDQpoYXNoIGFsZyAmbmJzcDs8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOzxicj4NCiZndDsgLS0gQ2hyaXN0 aWFuIEh1aXRlbWE8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 00409BA7C12579CF_=-- From fgont@si6networks.com Wed Mar 28 08:53:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36CC21E8234 for ; Wed, 28 Mar 2012 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKgKLSpMVDNd for ; Wed, 28 Mar 2012 08:53:34 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC621E80B8 for ; Wed, 28 Mar 2012 08:53:33 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SCvBd-00031t-1T; Wed, 28 Mar 2012 17:53:25 +0200 Message-ID: <4F7333F9.9090007@si6networks.com> Date: Wed, 28 Mar 2012 17:53:29 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Stable privacy addresses (upcoming rev) X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:53:35 -0000 Folks, Probably the only objection that I got for draft-gont-6man-stable-privacy-addresses is that the prefix shouldn't be included in F() (the hash function). I'd like to clarify the motivation for that, and also trigger some discussion on the topic such that I can produce a revision of this docuement that addresses any remaining concerns. * Motivation for including the SLAAC Prefix in F() (the hash function) The essential rationale for including the prefix in the hash function is that, if we don't, then we'd be leaking more information than we should. If we don't include the prefix as part of the data to be hashed, then the Interface-ID will be exactly the same no matter whether the devices moves from one network to another, and hence the node could be tracked, even if it implements RFC 4941. For example, think about the following scenario: Attack scenario #1 A host configures the stable addresses without including the Prefix in the hash function. Let's say the host employs any application that needs to perform a server-like function (P2P, or whatever). As a result of that, an attacker attacker participating in that application (e.g., P2P) would learn the Interface-ID used for the stable address. Now the same host moves to a completely different network, and uses the same P2P application, probably even with a different user. The attacker now interacts with the same node again, and hence can learn the "new" stable address. Since the interface ID is the same as the one above, he can infer that it is communicating with the same device as before. Had the host included the Prefix when computing the Interface-ID (with the hash function F()), the Interface-ID would have been different, and this wouldn't have been made possible. This is just *one* possible attack scenario, which should remind us that one shouldn't disclose more than it is really needed (and a static Interface-ID across many different networks does exactly that). * Use of draft-gont-6man-stable-privacy-addresses without RFC 4941 Temporary addresses are painful to manage. They make painful to correlate the activities of your own nodes. FOr example, one host gets infeceted will malware, you logged the IPv6 address, but then you don't know which node was using that address at that point in time. This is the reason for which in many deployments temporary addresses (RFC 4941) are disabled (e.g., look at any presentation by Ron Broersma). When you disable temporary addresses, all you're left with is whatever stable addresses your host uses. If you don't include the Prefix in F() (the hash function) then, while you may be resistant to host scanning attacks (your addresses is not predictable anymore), you're still trackable, since your interface ID doesn't change as you move from one network to another. So yes, there are cases in which you may want privacy, without necessarily be willing to deal with the burden of temporary addresses. And if you're just going to have stable addresses, you do not really want the Interface ID to be constant across networks. * Concerns about CPU impact Other folks have expressed concerns (in corridor meetings) that if the Prefix is included in the hash function, they may need to recompute the hash every time they attach to a network (assuming the SLAAC prefix changes), and that would be expensive. I personally think this shouldn't be an issue for most implementations (for instance, we do MD5 for every single new TCP connection! -- see RFC 6528). And, in any case, we do not really specify which hash function to use. -- If you're concerned about CPU, you may want to use a (CPU-wise) cheaper function. That said, I'd have no problem with making the inclusion of the Prefix a SHOULD (i.e., do it, unless you have very good reasons not to do so (such as CPU-constraints)), or even a MAY (if inclusion of the Prefix in the hash function turns out to be the show-stopper here). If you have any feedback/comments, I'd be glad to hear. I'm planning to rev the document asap, clarifying and incorporating many of the things explained throughout this e-mail. So if you send your feedback shortly, the next rev could reflect your comments. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From achatz@forthnetgroup.gr Wed Mar 28 12:26:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343CC21E801F for ; Wed, 28 Mar 2012 12:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn0kbe8HLSGy for ; Wed, 28 Mar 2012 12:26:34 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id D459321E8019 for ; Wed, 28 Mar 2012 12:26:33 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2SJQVNA026785; Wed, 28 Mar 2012 22:26:31 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2SJQVjq006318; Wed, 28 Mar 2012 22:26:31 +0300 Received: from [10.216.7.249] ([93.158.42.52]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2SJQHJg010841; Wed, 28 Mar 2012 22:26:19 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4F7365DF.1060001@forthnetgroup.gr> Date: Wed, 28 Mar 2012 21:26:23 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Stable privacy addresses (upcoming rev) References: <4F7333F9.9090007@si6networks.com> In-Reply-To: <4F7333F9.9090007@si6networks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:26:35 -0000 I like & support the idea, but it's not clear to me the randomness/stableness of the created identifiers. Is there a guarantee, that after rebooting or powering-off/on the host, the produced RID will remain the same if Prefix remains the same? Is there a way to change the secret key in case someone discovers it or for whatever reason? I would like more examples (and probably a better definition) of the network_id. i.e. the SSID is something that is not exactly local to the host. Are all the usage cases like this? i.e. in case of fixed network, would it be the directly attached router's mac? Extra question/idea.. If this address creation functionality can be transferred to a dhcp server too (which i don't see why not, since the critical input fields are already there), maybe the text regarding SLAAC should be replaced with something more appropriate. Or just add a note regarding this extra option (someone mentioned about a dhcp server creating temporary addresses). Finally, I would prefer to keep the prefix as mandatory to the algorithm for the exact reason that you wrote. PS: should there be any paragraph about the source address selection (rfc3484/bis) RFCs and these stable privacy addresses and how they should be handled, especially in comparison to the temporary ones? -- Tassos On 28/3/2012 5:53 ÎĽÎĽ, Fernando Gont wrote: > Folks, > > Probably the only objection that I got for > draft-gont-6man-stable-privacy-addresses is that the prefix shouldn't be > included in F() (the hash function). > > I'd like to clarify the motivation for that, and also trigger some > discussion on the topic such that I can produce a revision of this > docuement that addresses any remaining concerns. > > > * Motivation for including the SLAAC Prefix in F() (the hash function) > > The essential rationale for including the prefix in the hash function is > that, if we don't, then we'd be leaking more information than we should. > > If we don't include the prefix as part of the data to be hashed, then > the Interface-ID will be exactly the same no matter whether the devices > moves from one network to another, and hence the node could be tracked, > even if it implements RFC 4941. > > For example, think about the following scenario: > > Attack scenario #1 > > A host configures the stable addresses without including the Prefix in > the hash function. Let's say the host employs any application that needs > to perform a server-like function (P2P, or whatever). As a result of > that, an attacker attacker participating in that application (e.g., P2P) > would learn the Interface-ID used for the stable address. > > Now the same host moves to a completely different network, and uses the > same P2P application, probably even with a different user. The attacker > now interacts with the same node again, and hence can learn the "new" > stable address. Since the interface ID is the same as the one above, he > can infer that it is communicating with the same device as before. > > Had the host included the Prefix when computing the Interface-ID (with > the hash function F()), the Interface-ID would have been different, and > this wouldn't have been made possible. > > This is just *one* possible attack scenario, which should remind us that > one shouldn't disclose more than it is really needed (and a static > Interface-ID across many different networks does exactly that). > > > * Use of draft-gont-6man-stable-privacy-addresses without RFC 4941 > > Temporary addresses are painful to manage. They make painful to > correlate the activities of your own nodes. FOr example, one host gets > infeceted will malware, you logged the IPv6 address, but then you don't > know which node was using that address at that point in time. > > This is the reason for which in many deployments temporary addresses > (RFC 4941) are disabled (e.g., look at any presentation by Ron Broersma). > > When you disable temporary addresses, all you're left with is whatever > stable addresses your host uses. If you don't include the Prefix in F() > (the hash function) then, while you may be resistant to host scanning > attacks (your addresses is not predictable anymore), you're still > trackable, since your interface ID doesn't change as you move from one > network to another. > > So yes, there are cases in which you may want privacy, without > necessarily be willing to deal with the burden of temporary addresses. > And if you're just going to have stable addresses, you do not really > want the Interface ID to be constant across networks. > > > * Concerns about CPU impact > > Other folks have expressed concerns (in corridor meetings) that if the > Prefix is included in the hash function, they may need to recompute the > hash every time they attach to a network (assuming the SLAAC prefix > changes), and that would be expensive. I personally think this shouldn't > be an issue for most implementations (for instance, we do MD5 for every > single new TCP connection! -- see RFC 6528). And, in any case, we do not > really specify which hash function to use. -- If you're concerned about > CPU, you may want to use a (CPU-wise) cheaper function. > > That said, I'd have no problem with making the inclusion of the Prefix a > SHOULD (i.e., do it, unless you have very good reasons not to do so > (such as CPU-constraints)), or even a MAY (if inclusion of the Prefix in > the hash function turns out to be the show-stopper here). > > > If you have any feedback/comments, I'd be glad to hear. I'm planning to > rev the document asap, clarifying and incorporating many of the things > explained throughout this e-mail. So if you send your feedback shortly, > the next rev could reflect your comments. > > Thanks, From huitema@microsoft.com Wed Mar 28 17:23:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A6021E80F1 for ; Wed, 28 Mar 2012 17:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2rD5yJ+qjUn for ; Wed, 28 Mar 2012 17:23:55 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEEB21E80B9 for ; Wed, 28 Mar 2012 17:23:54 -0700 (PDT) Received: from mail54-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 00:23:52 +0000 Received: from mail54-db3 (localhost [127.0.0.1]) by mail54-db3-R.bigfish.com (Postfix) with ESMTP id 6C6D016047C; Thu, 29 Mar 2012 00:23:52 +0000 (UTC) X-SpamScore: -30 X-BigFish: VS-30(zz9371Ic89bh936eKc85bh1432Nzz1202hzz1033IL6d524h8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail54-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=huitema@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3 (MessageSwitch) id 1332980630260111_12277; Thu, 29 Mar 2012 00:23:50 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.226]) by mail54-db3.bigfish.com (Postfix) with ESMTP id 3CC321E0165; Thu, 29 Mar 2012 00:23:50 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 00:23:49 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.3]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 00:23:39 +0000 From: Christian Huitema To: "zhou.sujing@zte.com.cn" Subject: RE: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00 Thread-Topic: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00 Thread-Index: AQHNDCUWKLxARtLzBUSojhXcXZo3xpZ+nkYwgAD6AICAANIHoA== Date: Thu, 29 Mar 2012 00:23:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA03CD1BAEtk5ex14mbxc272r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 00:23:55 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA03CD1BAEtk5ex14mbxc272r_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VqaW4sDQoNCllvdXIgc3RhdGVtZW50ICChsGFmdGVyIGF0dGFja2VyIGhhcyBjcmFja2VkIGEg Q0dBIGFkZHJlc3MsIHRoZW4gaXQgaXMgaW4gdGhlIHNhbWUgc3RhbmQgYXMgdGhlIGRlZmVuZGVy obEgaXMgaW5jb3JyZWN0LiBUaGUgYXR0YWNrZXIgd2lsbCBub3QgbmVlZCA2NTUzNiBhZGRpdGlv bmFsIHRyaWFsczsgaGUgd2lsbCBuZWVkIHRvIGZpbmQgYSBtYXRjaGluZyBDR0EgYWRkcmVzcyA2 NTUzNiB0aW1lcywgYW5kIGVhY2ggdHJpYWwgaXMganVzdCBhcyBjb21wbGV4IGFzIGZpbmRpbmcg YSBtYXRjaGluZyBDR0EgYWRkcmVzcy4gVGhlIGRlZmVuZGVyIG9uIHRoZSBvdGhlciBoYW5kIGNh biBwaWNrIGFueSBDR0EgYWRkcmVzcyBoZSB3YW50cywgc28gaGUgaGFzIHRvIHBlcmZvcm0ganVz dCA2NTUzNiB0cmlhbHMuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0KDQpGcm9tOiB6aG91 LnN1amluZ0B6dGUuY29tLmNuIFttYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbl0NClNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMjgsIDIwMTIgNDo0NiBBTQ0KVG86IENocmlzdGlhbiBIdWl0ZW1h DQpDYzogaXB2NkBpZXRmLm9yZzsgSmFyaSBBcmtrbw0KU3ViamVjdDogtPC4tDogUkU6IGFib3V0 IHNlY3VyaXR5IGxldmVsIGV2YWx1YXRpb24gb2YgZHJhZnQtemhvdS02bWFuLW1oYXNoLWNnYS0w MA0KDQoNClJlZ2FyZHN+fn4NCg0KLVN1amluZyBaaG91DQoNCkNocmlzdGlhbiBIdWl0ZW1hIDxo dWl0ZW1hQG1pY3Jvc29mdC5jb208bWFpbHRvOmh1aXRlbWFAbWljcm9zb2Z0LmNvbT4+INC009og MjAxMi0wMy0yNyAyMzowMDowOToNCg0KPiA+IFdlbGwsIEkgdGhpbmsgaXQgaXMgcXVpdGUgYSBz aW1wbGUgdHJhZGUtb2ZmLiBJbmNyZWFzaW5nIFNlYw0KPiBpbmNyZWFzZXMgY29tcHV0YXRpb25h bCBlZmZvcnQgb24gYm90aCBzaWRlcyBieSBlcXVhbCBhbW91bnQuDQo+IEluY3JlYXNpbmcgdGhl IGxlbmd0aCBvZg0KPiA+IHRoZSBoYXNoIGluY3JlYXNlcyBjb21wdXRhdGlvbmFsIGVmZm9ydCBv bmx5IG9uIHRoZSBhdHRhY2tlciBzaWRlLg0KPiBBcyBhIHJlc3VsdCwgdGhlIGhhc2ggYml0cyBh cmUgcmVsYXRpdmVseSB2YWx1YWJsZS4NCj4NCj4gSmFyaSwgdGhlIGVmZmVjdCBvZiBzZWMgaXMg ZGlmZmVyZW50IG9uIGJvdGggc2lkZXMuIFRoZSBlZmZvcnQgaXMNCj4gbm90IGluY3JlYXNlZCAi YnkgZXF1YWwgYW1vdW50IiBidXQgcmF0aGVyICJpbiB0aGUgc2FtZSBwcm9wb3J0aW9uLiINCj4g U3VwcG9zZSB0aGF0IGFuIGF0dGFja2VyIGNvdWxkIGNyYWNrIHRoZSA1OSBiaXQgaGFzaCBpbiBh IGRheSB3aXRoDQo+IHNlYz0wLiBBZGRpbmcgc2VjID0gMSBtZWFucyB0aGF0IHRoZSBhdHRhY2tl ciB3aWxsIGhhdmUgdG8gdHJ5IDY1NTM2DQo+IHRpbWVzIGFzIG1hbnkga2V5cy4gVGhlIHRpbWUg dG8gY3JhY2sgYmVjb21lcyA2NTUzNiBob3VycywgaS5lLg0KPiBhYm91dCA3IHllYXJzLiBUaGUg ZGVmZW5kZXIgd2lsbCBoYXZlIHRvIHRyeSA2NTUzNiBpbnN0ZWFkIG9mIG9uZSB0bw0KPiBnZXQg dGhlIHJpZ2h0IHNlYywgdGFraW5nIG9ubHkgIGEgZnJhY3Rpb24gb2YgYSBzZWNvbmQuDQoNCmFm dGVyIGF0dGFja2VyIGhhcyBjcmFja2VkIGEgQ0dBIGFkZHJlc3MsIHRoZW4gaXQgaXMgaW4gdGhl IHNhbWUgc3RhbmQgYXMgdGhlIGRlZmVuZGVyLg0KZGVmZW5kZXIsIGFzIHdlbGwgYXMgYXR0YWNr ZXIsIGhhcyB0byB0cnkgb25lIGJ5IG9uZSB0byBnZXQgdGhlIHJpZ2h0IHNlYywgaS5lLiwgdG8g Z2V0IGEgbWF0Y2hpbmcgbGVuZ3RoIG9mIHplcm9zLA0KaG93IGNvbWUgYXR0YWNrZXIgbmVlZCBl eHRyYSA2NTUzNiBob3VycyBidXQgZGVmZW5kZXIgb25seSBuZWVkcyBhIGZyYWN0aW9uIG9mIGEg c2Vjb25kPw0KDQo+ID4gMSkgU3RhdHVzIHF1bzogUkZDIDQ5ODIgZWF0cyB0aHJlZSBiaXRzIGZv ciBTZWMsIGxlYXZpbmcgNTkgYml0cw0KPiBvZiBoYXNoIGxlbmd0aCBhZnRlciBhY2NvbW1vZGF0 aW5nIGZvciB1IGFuZCBnIGJpdHMgYXMgd2VsbC4gVGhlDQo+IGdvb2Qgd2l0aCB0aGlzIGlzDQo+ ID4gdGhhdCBpdCBsZWF2ZXMgbWF4aW11bSBzaXplIGZvciBoYXNoLiBUaGUgYmFkIGlzIHRoYXQg aXQgaXMgbGVzcw0KPiBmbGV4aWJsZSBmb3IgYWRkaW5nIG1hbnkgbmV3IGhhc2ggYWxnb3JpdGht cy4NCj4NCj4gSSBraW5kIG9mIGxpa2UgdGhlIHN0YXR1cyBxdW8uDQo+DQo+ID4gMikgVGhlIHBy b3Bvc2VkIG5ldyBhcHByb2FjaDogRWF0IGEgdG90YWwgb2Ygc2l4IGJpdHMsIGZvciBTZWMgYW5k DQo+IHRoZSBoYXNoIGFsZ29yaXRobSBpZGVudGlmaWVyLiA1NiBiaXRzIHJlbWFpbi4gVGhlIGdv b2QgaXMgdGhhdCB0aGlzDQo+IGdpdmVzIG1vcmUNCj4gPiBmbGV4aWJpbGl0eSB0byBhbGxvY2F0 ZSBoYXNoIGFsZ29yaXRobXMsIGluY2x1ZGluZyB0aGUgYWJpbGl0eSB0bw0KPiBpbmRlcGVuZGVu dGx5IGNob29zZSBTZWMgYW5kIHRoZSBhbGdvcml0aG0uIFRoZSBiYWQgaXMgdGhhdCB0aGUgaGFz aCBzaXplIGlzDQo+ID4gZGVjcmVhc2VkLg0KPg0KPiBEZWNyZWFzZWQgYSBsb3QuIE9uIHRoZSBv dGhlciBoYW5kLCBpZiB3ZSBkbyBnYWluIHRoZSBmbGV4aWJpbGl0eSB0bw0KPiBkZWZpbmUgbmV3 IGFsZ29yaXRobXMsIHRoZW4gd2UgY2FuIGRlZmluZSBhIG1hbmRhdG9yeS10by1pbXBsZW1lbnQN Cj4gYWxnb3JpdGhtIHRoYXQgaW5jb3Jwb3JhdGVzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSAic2Vj IiBzdHJlbmd0aGVuaW5nLg0KDQp0aGUgc2VjdXJpdHkgb2YgYSBoYXNoIGFsZ28gY2FuIGJlIHJv dWdobHkgZXN0aW1hdGVkIGJ5IGxlbmd0aCBvZiBpdHMgb3V0cHV0LA0KZnJvbSBiaXJ0aGRheSBh dHRhY2ssIHRoYXQgaXMgYWJvdXQgMl4oNTkvMikgb3IgMl4oNTYvMikodGhlb3JpY2FsIGVzdGlt YXRlKSwgb3IgbGVzcywNCmNhbiB5b3UgZ2l2ZSBhIG1vcmUgcHJlY2lzZSBvZiB2YWx1ZSBvZiAi YSBsb3QiPw0KSSBkb24ndCBzZWUgZmxleGliaWxpdHkgaW4gZGVmaW5pbmcgbWFuZGF0b3J5LXRv LWltcGxlbWVudGluZyBoYXNoIGFsZw0KDQo+IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+DQo+DQo+ DQo+DQo= --_000_C91E67751B1EFF41B857DE2FE1F68ABA03CD1BAEtk5ex14mbxc272r_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Sujin,<= /p>

 <= /p>

Your statement  =A1= =B0after attacker has cracked a CGA address, then it is in the same stand a= s the defender=A1=B1 is incorrect. The attacker will not need 65536 additio= nal trials; he will need to find a matching CGA address 65536 times, and each = trial is just as complex as finding a matching CGA address. The defender on= the other hand can pick any CGA address he wants, so he has to perform jus= t 65536 trials.

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: zhou.suj= ing@zte.com.cn [mailto:zhou.sujing@zte.com.cn]
Sent: Wednesday, March 28, 2012 4:46 AM
To: Christian Huitema
Cc: ipv6@ietf.org; Jari Arkko
Subject: =B4= =F0=B8=B4: RE: about security level evaluation of draft-= zhou-6man-mhash-cga-00

 


Regards~~~

-Sujing Zhou

Christian Huitema <huitema@microsoft.com> =D0=B4=D3=DA 2012-03-27 23:00:09:

> > Well, I think it is quite a simple trade-off. Increasing Sec =
> increases computational effort on both sides by equal amount.
> Increasing the length of
> > the hash increases computational effort only on the attacker = side.
> As a result, the hash bits are relatively valuable.
>
> Jari, the effect of sec is different on both sides. The effort is =
> not increased "by equal amount" but rather "in the = same proportion."
> Suppose that an attacker could crack the 59 bit hash in a day with=
> sec=3D0. Adding sec =3D 1 means that the attacker will have to try= 65536
> times as many keys. The time to crack becomes 65536 hours, i.e.
> about 7 years. The defender will have to try 65536 instead of one = to
> get the right sec, taking only  a fraction of a second. =

after attacker has cracked a CGA addre= ss, then it is in the same stand as the defender.
defender, as well as attacker, has to = try one by one to get the right sec, i.e., to get a matching length of zero= s,
how come attacker need extra 65536 hou= rs but defender only needs a fraction of a second?
 
> > 1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 b= its
> of hash length after accommodating for u and g bits as well. The <= /tt>
> good with this is
> > that it leaves maximum size for hash. The bad is that it is l= ess
> flexible for adding many new hash algorithms.
>
> I kind of like the status quo.
>
> > 2) The proposed new approach: Eat a total of six bits, for Se= c and
> the hash algorithm identifier. 56 bits remain. The good is that th= is
> gives more
> > flexibility to allocate hash algorithms, including the abilit= y to
> independently choose Sec and the algorithm. The bad is that the ha= sh size is
> > decreased.
>
> Decreased a lot. On the other hand, if we do gain the flexibility = to
> define new algorithms, then we can define a mandatory-to-implement=
> algorithm that incorporates the equivalent of the "sec" = strengthening.

the security of a hash algo can be rou= ghly estimated by length of its output,
from birthday attack, that is about 2^= (59/2) or 2^(56/2)(theorical estimate), or less,
can you give a more precise of value o= f "a lot"?
I don't see flexibility in defining ma= ndatory-to-implementing hash alg  
 
> -- Christian Huitema
>
>  
>
>

--_000_C91E67751B1EFF41B857DE2FE1F68ABA03CD1BAEtk5ex14mbxc272r_-- From dougb@dougbarton.us Wed Mar 28 23:42:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C679121E80B5 for ; Wed, 28 Mar 2012 23:42:57 -0700 (PDT) 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=[AWL=-1.262, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kPsKnoc3qnM for ; Wed, 28 Mar 2012 23:42:56 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 805F421E805D for ; Wed, 28 Mar 2012 23:42:56 -0700 (PDT) Received: (qmail 21406 invoked by uid 399); 29 Mar 2012 06:42:52 -0000 Received: from unknown (HELO ?172.17.198.146?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 29 Mar 2012 06:42:52 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F74046A.5000201@dougbarton.us> Date: Wed, 28 Mar 2012 23:42:50 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Karl Auer Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <4F71FC03.90403@si6networks.com> <4F720F7F.2090108@globis.net> <1332884609.2633.22.camel@karl> In-Reply-To: <1332884609.2633.22.camel@karl> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 06:42:57 -0000 On 3/27/2012 2:43 PM, Karl Auer wrote: > On Tue, 2012-03-27 at 21:05 +0200, Ray Hunter wrote: >> IMHO the proper *default* behavior is still "off" = option A. In other >> words, default = IPv4-like behavior, at least until we really figure >> out how to operate all of these fancy new features of IPv6. > > The question is not whether the use of privacy addresses (temporary > addresses) should be enabled by default. Though some OSes do that, I > believe. > > The question is, where a host *does* have both a temporary and a > non-temporary addresses, which one it should prefer by default. "Prefer > by default" in this case means "select as the source address for new > outbound connections in the absence of specific instructions to do > otherwise". Thanks for clarifying this Karl, I thought I was confused about the question when I saw the answers that people were giving. :) FWIW, my personal preference is for 4941 addresses *both* on by default, *and* chosen first by default. But I definitely think that if 4941 addresses are enabled, they should be used by default. (So, my answer to Brian H's question is B.) Longer, but hopefully useful answer from an implementor ... Some time ago I looked at changing the default for both on FreeBSD to "On" with the thinking that if it's good enough for Uncle Bill, it's good enough for us. (Well, really with the thinking that it would be the right thing to do, help protect FreeBSD users' privacy, etc.) I even floated a trial-balloon about making the change, and got generally positive responses. Eventually I lost interest because of a non-zero number of replies to the effect that "The RFC says use should be off by default, so we shouldn't enable it by default." Given that I only have so much time to push so many rocks up so many hills, I took a different approach. Rather than enabling it by default, I made it much easier to enable at all by adding a knob to the default rc.conf file: ipv6_privacy="NO" # Use privacy address on RA-receiving IFs (RFC 4941) When implementing the guts to make that knob effective I turned on both the sysctls to create the addresses, and to prefer them, without giving users a knob to turn off the latter. That was 2 years ago in HEAD (our bleeding edge development branch) and no one has ever complained. That knob shipped in our 9.0-RELEASE (January 2012). Regarding the topic of privacy generally, I agree with the sentiments that just because we're losing the war doesn't mean that we shouldn't fight the battles that we can. However, if you want to get really depressed about browser privacy, take a look at these 2 sites. The first one is sort of scary, the second one should really terrify you: http://www.b2knet.com/ https://panopticlick.eff.org/ Regarding the second one, I am ULTRA paranoid about my browser privacy ... I have numerous firefox plugins to enhance it, including cookies off by default and selectively enabled with CookieMonster, super-tight whitelist settings for RequestPolicy, BetterPrivacy, wipe out everything when the browser exits, etc. And I still get the result that my fingerprint is unique (out of over 2 million users). and so it goes, Doug From iljitsch@muada.com Thu Mar 29 03:02:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E36421F87CB; Thu, 29 Mar 2012 03:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qItYPN3koyCU; Thu, 29 Mar 2012 03:02:53 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id DEEB021F87C7; Thu, 29 Mar 2012 03:02:52 -0700 (PDT) Received: from [IPv6:2001:df8::16:d9d6:7795:a05d:df7f] ([IPv6:2001:df8:0:16:d9d6:7795:a05d:df7f]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id q2TA2U6I095722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2012 12:02:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: You asked about multicast scope Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> Date: Thu, 29 Mar 2012 12:02:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1257) Cc: pcp@ietf.org, 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:02:53 -0000 On 28 Mar 2012, at 12:08 , Fred Baker wrote: >> I haven't read the spec yet, but isn't PCP supposed to work in the = service provider run NAT64/CGN case, too? In that case, the multicasts = need to escape out of the site or even organization to reach the service = provider at least in the SOHO case. So this would be a scope just shy of = global, maybe a new "service provider" scope? > I personally rarely use "zero configuration" and "service provider" in = the same sentence... Am I understanding you correctly when I take that to mean that the admin = (value 4) scope is appropriate because then the people running the = multicast routing can determine exactly how far these packets travel? That makes sense, but there is one potential issue, that I think some = people who are well-steeped in IPv6 multicast should look at: in this = situation, the scope value 4 may need wider distribution than side-wide, = which is scope 5. I can't find any documentation on whether that's ok or = not between sessions right now, but I'm reluctant to assume that a lower = scope value can have wider distribution than a higher one without having = a spec that explicitly says so or hearing from some implementers. Iljitsch= From kerlyn2001@gmail.com Thu Mar 29 03:39:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3521F8890; Thu, 29 Mar 2012 03:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zMPf4d3+Ztv; Thu, 29 Mar 2012 03:39:09 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA721F887D; Thu, 29 Mar 2012 03:39:08 -0700 (PDT) Received: by lagj5 with SMTP id j5so2740677lag.31 for ; Thu, 29 Mar 2012 03:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fmeJKMiYuIzPEF6pD4RU7OzNKvpaKA6ygZzS+vcoJrk=; b=kWTH8hajyyOAOi1cAewpMsazbsvHLvyskl0zhJSOpL5M1DFtdgTCjsD9yoy+7QsV08 aTimzqD4HlUrTF3xhhsK11IwxtZvHPiEZIz+TE70NPVY7jVy9N3GFFd2pWx6GM0N6jyl ir69+rP5J08dOJVaMqeov5cFMbXhm5KM8Pk5PRrFi0QzZd2MgDHzWyUtTr5N8FxlJXJJ 95zLN3RvBzqzqDQpj0EFxG7c32v8HpHY5Zww1QNVUGFopGYUyKZ/5XozdIXp4+UA4p8B 7xHbYOOBz9Uq0QvigDDZA8bStd382GePz62vDouo/56jcpvdVt/FHzU+SBjwhoTXZfYS vSaw== MIME-Version: 1.0 Received: by 10.152.115.38 with SMTP id jl6mr27404776lab.24.1333017535020; Thu, 29 Mar 2012 03:38:55 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Thu, 29 Mar 2012 03:38:54 -0700 (PDT) In-Reply-To: <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> Date: Thu, 29 Mar 2012 12:38:54 +0200 X-Google-Sender-Auth: KfHYk_qfKrUYVLUApbejnqSWXzI Message-ID: Subject: Re: You asked about multicast scope From: Kerry Lynn To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=f46d040891eba77ce304bc5f5455 Cc: pcp@ietf.org, 6man 6man , Fred Baker X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:39:09 -0000 --f46d040891eba77ce304bc5f5455 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 29, 2012 at 12:02 PM, Iljitsch van Beijnum wrote: > On 28 Mar 2012, at 12:08 , Fred Baker wrote: > > >> I haven't read the spec yet, but isn't PCP supposed to work in the > service provider run NAT64/CGN case, too? In that case, the multicasts need > to escape out of the site or even organization to reach the service > provider at least in the SOHO case. So this would be a scope just shy of > global, maybe a new "service provider" scope? > > > I personally rarely use "zero configuration" and "service provider" in > the same sentence... > > Am I understanding you correctly when I take that to mean that the admin > (value 4) scope is appropriate because then the people running the > multicast routing can determine exactly how far these packets travel? > > That makes sense, but there is one potential issue, that I think some > people who are well-steeped in IPv6 multicast should look at: in this > situation, the scope value 4 may need wider distribution than side-wide, > which is scope 5. I can't find any documentation on whether that's ok or > not between sessions right now, but I'm reluctant to assume that a lower > scope value can have wider distribution than a higher one without having a > spec that explicitly says so or hearing from some implementers. > > Correct me if I'm wrong, but isn't Admin Scoped multicast defined on a per- port, per-application basis? That would suggest that some multicast group addresses can (selectively) be forwarded through the CER uplink to the ISP. -K- Iljitsch > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --f46d040891eba77ce304bc5f5455 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2012 at 12:02 PM, Iljitsch van Beijnum &l= t;iljitsch@muada.com> w= rote:
On 28 Mar 2012, at 12:08 , Fred Baker wrote:

>> I haven't read the spec yet, but isn't PCP supposed to wor= k in the service provider run NAT64/CGN case, too? In that case, the multic= asts need to escape out of the site or even organization to reach the servi= ce provider at least in the SOHO case. So this would be a scope just shy of= global, maybe a new "service provider" scope?

> I personally rarely use "zero configuration" and "servi= ce provider" in the same sentence...

Am I understanding you correctly when I take that to mean that the admin (v= alue 4) scope is appropriate because then the people running the multicast = routing can determine exactly how far these packets travel?

That makes sense, but there is one potential issue, that I think some peopl= e who are well-steeped in IPv6 multicast should look at: in this situation,= the scope value 4 may need wider distribution than side-wide, which is sco= pe 5. I can't find any documentation on whether that's ok or not be= tween sessions right now, but I'm reluctant to assume that a lower scop= e value can have wider distribution than a higher one without having a spec= that explicitly says so or hearing from some implementers.

Correct me if I'm wrong, but isn't Admin Scop= ed multicast defined on a per-
port, per-application basis? =A0Th= at would suggest that some multicast group
addresses can (selecti= vely) be forwarded through the CER uplink to the ISP.

-K-

Iljitsch
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--f46d040891eba77ce304bc5f5455-- From fred@cisco.com Thu Mar 29 04:13:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9B21F8918; Thu, 29 Mar 2012 04:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muV7EBu9VOPs; Thu, 29 Mar 2012 04:13:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C22F121F8915; Thu, 29 Mar 2012 04:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2650; q=dns/txt; s=iport; t=1333019626; x=1334229226; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=eiEEpiBhFrq15oDM8tu/rU6PEsE+27cz0e/Y2w1quRg=; b=SatdF+mJwiYjnLDgBcWxQKkIUSKUIYrDl0BJqQsHGyJUUuUoOH7fNiWe jOldwv0IttHKzjHlk3PdKTO7iI658cnOFlw8WMb57YXODqx5pWJ89LydX QjHBJ7xpOovKdXtre6U3Gd2iHrKdPAV0593qBwFVs/R1v6gAyUtS0GSQp c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOdCdE+Q/khN/2dsb2JhbABEuQ+BB4IJAQEBAwESASc/BQsLEgYuSQ4GNYdjBZtpnx+QPGMElWGFb4hWgWiCaQ X-IronPort-AV: E=Sophos;i="4.73,667,1325462400"; d="scan'208";a="133709869" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 29 Mar 2012 11:13:43 +0000 Received: from dhcp-5155.meeting.ietf.org (dhcp-10-55-81-200.cisco.com [10.55.81.200]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2TBDgcm031225; Thu, 29 Mar 2012 11:13:42 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Thu, 29 Mar 2012 13:13:43 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Thu, 29 Mar 2012 13:13:43 +0200 Subject: Re: You asked about multicast scope Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> Date: Thu, 29 Mar 2012 13:13:28 +0200 Message-Id: <947EA806-8E8B-47FF-9662-83210441C19E@cisco.com> References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org, 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:13:47 -0000 On Mar 29, 2012, at 12:02 PM, Iljitsch van Beijnum wrote: > On 28 Mar 2012, at 12:08 , Fred Baker wrote: >=20 >>> I haven't read the spec yet, but isn't PCP supposed to work in the = service provider run NAT64/CGN case, too? In that case, the multicasts = need to escape out of the site or even organization to reach the service = provider at least in the SOHO case. So this would be a scope just shy of = global, maybe a new "service provider" scope? >=20 >> I personally rarely use "zero configuration" and "service provider" = in the same sentence... >=20 > Am I understanding you correctly when I take that to mean that the = admin (value 4) scope is appropriate because then the people running the = multicast routing can determine exactly how far these packets travel? >=20 > That makes sense, but there is one potential issue, that I think some = people who are well-steeped in IPv6 multicast should look at: in this = situation, the scope value 4 may need wider distribution than side-wide, = which is scope 5. I can't find any documentation on whether that's ok or = not between sessions right now, but I'm reluctant to assume that a lower = scope value can have wider distribution than a higher one without having = a spec that explicitly says so or hearing from some implementers. I imagine. Note that the document actually says "organization scope". The non-boilerplate part of the document contains 44 sentences; three of = them, in sections 4 and 5, mention the specifics of the scope. Is it = fair to assume that you have no issue with the remaining sentences? 4. IANA Considerations This note requests of the IANA the assignment of a set of multicast addresses as described in Section 2.7 of the IP Version 6 Addressing Architecture [RFC4291] from the registry [v6mult]. This set of addresses is referred to as "ALL-NPTv6-TRANSLATORS". One address should be assigned for each of the following scopes: Link-Local, Admin-Local, Site-Local, and Organization-Local. 5. Operational Considerations This document defines a set of multicast addresses in several scopes. Operationally, the choice of which scope is appropriate is made by the administration. A reasonable default value in system configurations might be Organization-Local (e.g., all NPTv6 Translators operated by the organization). However, a large organization might well choose Site-Local or Admin-Local, and consider that "site" or "administrative" domain to include the set of NPTv6 Translators advertising a default route into a specific part of its network. From stig@venaas.com Thu Mar 29 04:16:28 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5360221F88ED; Thu, 29 Mar 2012 04:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBQSuJ6BGJxt; Thu, 29 Mar 2012 04:16:27 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 37C5121F86E1; Thu, 29 Mar 2012 04:16:27 -0700 (PDT) Received: from [10.21.80.149] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id A90D7803F; Thu, 29 Mar 2012 13:16:23 +0200 (CEST) Message-ID: <4F74447E.6020506@venaas.com> Date: Thu, 29 Mar 2012 04:16:14 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Kerry Lynn Subject: Re: You asked about multicast scope References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Iljitsch van Beijnum , 6man 6man , Fred Baker , pcp@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:16:28 -0000 On 3/29/2012 3:38 AM, Kerry Lynn wrote: > On Thu, Mar 29, 2012 at 12:02 PM, Iljitsch van Beijnum > > wrote: > > On 28 Mar 2012, at 12:08 , Fred Baker wrote: > > >> I haven't read the spec yet, but isn't PCP supposed to work in > the service provider run NAT64/CGN case, too? In that case, the > multicasts need to escape out of the site or even organization to > reach the service provider at least in the SOHO case. So this would > be a scope just shy of global, maybe a new "service provider" scope? > > > I personally rarely use "zero configuration" and "service > provider" in the same sentence... > > Am I understanding you correctly when I take that to mean that the > admin (value 4) scope is appropriate because then the people running > the multicast routing can determine exactly how far these packets > travel? > > That makes sense, but there is one potential issue, that I think > some people who are well-steeped in IPv6 multicast should look at: > in this situation, the scope value 4 may need wider distribution > than side-wide, which is scope 5. I can't find any documentation on IMO you cannot do that. The higher scope value, the wider distribution. If you have scopes X and Y where X < Y, then the distribution of X should be a subset (can be the same) of the distribution of Y. There are implementations making such assumptions. > whether that's ok or not between sessions right now, but I'm > reluctant to assume that a lower scope value can have wider > distribution than a higher one without having a spec that explicitly > says so or hearing from some implementers. > > Correct me if I'm wrong, but isn't Admin Scoped multicast defined on a per- > port, per-application basis? That would suggest that some multicast group > addresses can (selectively) be forwarded through the CER uplink to the ISP. There is nothing magical with scope 4. It is wider than link-local, and you need to configure routers to limit the distribution according to your policy. Stig > -K- > > Iljitsch > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ietfc@btconnect.com Thu Mar 29 04:37:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E5221F89A3 for ; Thu, 29 Mar 2012 04:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqliLZYt4zIS for ; Thu, 29 Mar 2012 04:37:03 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id 64EC121F8992 for ; Thu, 29 Mar 2012 04:37:02 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr10.btconnect.com with SMTP id GUV31907; Thu, 29 Mar 2012 12:36:57 +0100 (BST) Message-ID: <03d301cd0d97$b3361060$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ray Hunter" , "Brian Haberman" References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> Subject: Re: 3484bis and privacy addresses Date: Thu, 29 Mar 2012 12:03:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F744959.0013, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.29.105416:17:7.944, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_7, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0208.4F744959.01A4,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:37:05 -0000 A categorically. I think that Ray summarises the arguments well below. I only disagree with him in that I see the arguments applying outside the corporate world as well. I think too that Ray is spot on with a later post about "how to operate all of these fancy new features of IPv6." Yup, we really need to start rolling out IPv6 and find out what works. Tom Petch ----- Original Message ----- From: "Ray Hunter" To: "Brian Haberman" Cc: Sent: Tuesday, March 27, 2012 7:00 PM Subject: Re: 3484bis and privacy addresses > From the corporate World: option A as default, with local user > controlled option to override. > > RFC3484 (which references RFC3041) "Temporary addresses" are a menace to > fault finding, audit, logging, firewall rules, filtering, QoS matching, > conformance: anywhere where an ACL or stable address is used today. Sure > we shouldn't use fixed/stable IP literals, but we do. And in many cases > there aren't any practical alternatives in today's products, so the IP > address is the lowest common denominator used to identify a machine (and > dare I say even "a user" in some circumstances). > > Also not sure if any DHCPv6 server implementations actually provide > DHCPv6 assigned temporary addresses in practice. > > My take on this is that a set of a few hundred individual persons who > are worried about privacy are more likely to be able to control their > own particular machines to correctly override the "default off" setting > than a single corporate network manager is to be able to guarantee > overriding a "default on" setting on 100% of 10000 machines attached to > their network. > > regards, > RayH > > Brian Haberman wrote: > >
All, > > The chairs would like to get a sense of the working group on > > changing the current (defined 3484) model of preferring public > > addresses over privacy addresses during the address selection > > process. RFC 3484 prefers public addresses with the ability (MAY) of > > an implementation to reverse the preference. The suggestion has been > > made to reverse that preference in 3484bis (prefer privacy addresses > > over public ones). Regardless, the document will allow > > implementers/users to reverse the default preference. > > > > Please state your preference for one of the following default > > options : > > > > A. Prefer public addresses over privacy addresses > > > > B. Prefer privacy addresses over public addresses > > > > Regards, > > Brian, Bob, & Ole > > > >
> > -- > Ray Hunter > Ray.Hunter@globis.net > Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL, > Registered at the KvK, Eindhoven, under number BV 17098279 > mobile: +31 620 363864 > > -------------------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fgont@si6networks.com Thu Mar 29 04:44:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204DD21F8913 for ; Thu, 29 Mar 2012 04:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 118Wqvfl3TXj for ; Thu, 29 Mar 2012 04:44:26 -0700 (PDT) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 08C0321F8892 for ; Thu, 29 Mar 2012 04:44:26 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SDDlx-0005Sv-JM; Thu, 29 Mar 2012 13:44:09 +0200 Message-ID: <4F744B10.7030104@si6networks.com> Date: Thu, 29 Mar 2012 13:44:16 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Tassos Chatzithomaoglou Subject: Re: Stable privacy addresses (upcoming rev) References: <4F7333F9.9090007@si6networks.com> <4F7365DF.1060001@forthnetgroup.gr> In-Reply-To: <4F7365DF.1060001@forthnetgroup.gr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:44:46 -0000 Hi, Tassos, Thanks so much for your comments. Please find my responses inline.... On 03/28/2012 09:26 PM, Tassos Chatzithomaoglou wrote: > I like & support the idea, but it's not clear to me the > randomness/stableness of the created identifiers. > > Is there a guarantee, that after rebooting or powering-off/on the host, > the produced RID will remain the same if Prefix remains the same? Well, yes: As long as all the values you use for computing the hash are the same, the resulting Interface-ID will be the same. > Is there a way to change the secret key in case someone discovers it or > for whatever reason? If you change the key, the interface ID changes. That's implicit, since the hash function is expected to be cryptographically secure. (and one would argue that this is also desired, since once the key has been compromised, an attacker could use it to predict the Interface-ID that you'd use in other networks). > I would like more examples (and probably a better definition) of the > network_id. i.e. the SSID is something that is not exactly local to the > host. Are all the usage cases like this? i.e. in case of fixed network, > would it be the directly attached router's mac? The "Network_ID" is anything that would let you differentiate from one network to another, even if the same SLAAC prefix is being advertised. For example, you're connecting to a number of wifi networks, and the router advertises the same ULA prefix, including the SSID would result in different interface identifiers. In principle, the same thing would be true for link-local addresses: you could use some sort of Network_ID when generating the Interface-ID for link-local addresses, such that the address changes when you move from one network to another. (This is useful since sometimes this link-local addresses may leak out). > Extra question/idea.. > If this address creation functionality can be transferred to a dhcp > server too (which i don't see why not, since the critical input fields > are already there), maybe the text regarding SLAAC should be replaced > with something more appropriate. Or just add a note regarding this extra > option (someone mentioned about a dhcp server creating temporary > addresses). It could be transferred. So this is a good point. -- I will try to address this in the next rev of the document. > Finally, I would prefer to keep the prefix as mandatory to the algorithm > for the exact reason that you wrote. I fully agree with you, and think it would be a bad idea to remove the prefix from the hash. Some folks have argued against including the prefix, and hence I just want to hear comments from others. > PS: should there be any paragraph about the source address selection > (rfc3484/bis) RFCs and these stable privacy addresses and how they > should be handled, especially in comparison to the temporary ones? Not sure what you mean.... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian@innovationslab.net Thu Mar 29 05:15:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7119421F8A81 for ; Thu, 29 Mar 2012 05:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVpM6xwP7E34 for ; Thu, 29 Mar 2012 05:15:43 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8A921F8A80 for ; Thu, 29 Mar 2012 05:15:43 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 5D59288122 for ; Thu, 29 Mar 2012 05:15:43 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (dhcp-5588.meeting.ietf.org [130.129.85.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id F0F0A130017 for ; Thu, 29 Mar 2012 05:15:42 -0700 (PDT) Message-ID: <4F74526D.6070003@innovationslab.net> Date: Thu, 29 Mar 2012 08:15:41 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: You asked about multicast scope References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> <4F74447E.6020506@venaas.com> In-Reply-To: <4F74447E.6020506@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:15:44 -0000 On 3/29/12 7:16 AM, Stig Venaas wrote: > On 3/29/2012 3:38 AM, Kerry Lynn wrote: >> On Thu, Mar 29, 2012 at 12:02 PM, Iljitsch van Beijnum >> > wrote: >> >> On 28 Mar 2012, at 12:08 , Fred Baker wrote: >> >> >> I haven't read the spec yet, but isn't PCP supposed to work in >> the service provider run NAT64/CGN case, too? In that case, the >> multicasts need to escape out of the site or even organization to >> reach the service provider at least in the SOHO case. So this would >> be a scope just shy of global, maybe a new "service provider" scope? >> >> > I personally rarely use "zero configuration" and "service >> provider" in the same sentence... >> >> Am I understanding you correctly when I take that to mean that the >> admin (value 4) scope is appropriate because then the people running >> the multicast routing can determine exactly how far these packets >> travel? >> >> That makes sense, but there is one potential issue, that I think >> some people who are well-steeped in IPv6 multicast should look at: >> in this situation, the scope value 4 may need wider distribution >> than side-wide, which is scope 5. I can't find any documentation on > > IMO you cannot do that. The higher scope value, the wider distribution. > If you have scopes X and Y where X < Y, then the distribution of X > should be a subset (can be the same) of the distribution of Y. > > There are implementations making such assumptions. It is not an assumption, it is stately quite clearly in the Scoped Addressing Architecture (RFC 4007). From Section 5 : A zone of a given scope (less than global) falls completely within zones of larger scope. That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces. > >> whether that's ok or not between sessions right now, but I'm >> reluctant to assume that a lower scope value can have wider >> distribution than a higher one without having a spec that explicitly >> says so or hearing from some implementers. >> >> Correct me if I'm wrong, but isn't Admin Scoped multicast defined on a >> per- >> port, per-application basis? That would suggest that some multicast group >> addresses can (selectively) be forwarded through the CER uplink to the >> ISP. > > There is nothing magical with scope 4. It is wider than link-local, and > you need to configure routers to limit the distribution according to > your policy. RFC 4007 lays out all the rules you need to adhere to for scoped addressing boundaries. Regards, Brian From iljitsch@muada.com Thu Mar 29 05:52:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1AD21F85D3; Thu, 29 Mar 2012 05:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+l4eI7e1H3q; Thu, 29 Mar 2012 05:52:35 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 26CE421F85CF; Thu, 29 Mar 2012 05:52:33 -0700 (PDT) Received: from [IPv6:2001:df8::80:4c8c:40e7:73c:3dc6] ([IPv6:2001:df8:0:80:4c8c:40e7:73c:3dc6]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id q2TCqDwR097139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2012 14:52:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: You asked about multicast scope Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4F74526D.6070003@innovationslab.net> Date: Thu, 29 Mar 2012 14:52:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com> References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> <4F74447E.6020506@venaas.com> <4F74526D.6070003@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1257) Cc: pcp@ietf.org, 6man 6man , Fred Baker X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:52:35 -0000 On 29 Mar 2012, at 14:15 , Brian Haberman wrote: > It is not an assumption, it is stately quite clearly in the Scoped = Addressing Architecture (RFC 4007). =46rom Section 5 : > A zone of a given scope (less than global) falls completely = within > zones of larger scope. That is, a smaller scope zone cannot > include more topology than would any larger scope zone with which > it shares any links or interfaces. Brian, Stig, thanks for the help. Fred: I think what would be best is to define a "service provider" scope = that is smaller than global, and larger than organization. These would = be defined to be forwarded to ISPs by default, although organizations = that don't want that can always filter them at the desired boundary. That way, the clients can always use a fixed scope =3D fixed multicast = group, avoiding the need for discovery or configuration here.= From brian@innovationslab.net Thu Mar 29 05:57:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAB721F87E4; Thu, 29 Mar 2012 05:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy1wZRne6QH9; Thu, 29 Mar 2012 05:57:22 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id E26B621F877C; Thu, 29 Mar 2012 05:57:10 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D141088116; Thu, 29 Mar 2012 05:57:10 -0700 (PDT) Received: from dhcp-5588.meeting.ietf.org (dhcp-5588.meeting.ietf.org [130.129.85.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0A6E4130017; Thu, 29 Mar 2012 05:57:09 -0700 (PDT) Message-ID: <4F745C25.3090009@innovationslab.net> Date: Thu, 29 Mar 2012 08:57:09 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: You asked about multicast scope References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> <4F74447E.6020506@venaas.com> <4F74526D.6070003@innovationslab.net> <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com> In-Reply-To: <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org, 6man 6man , Fred Baker X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:57:23 -0000 On 3/29/12 8:52 AM, Iljitsch van Beijnum wrote: > On 29 Mar 2012, at 14:15 , Brian Haberman wrote: > >> It is not an assumption, it is stately quite clearly in the Scoped >> Addressing Architecture (RFC 4007). From Section 5 : > >> A zone of a given scope (less than global) falls completely within >> zones of larger scope. That is, a smaller scope zone cannot >> include more topology than would any larger scope zone with which >> it shares any links or interfaces. > > Brian, Stig, thanks for the help. > > Fred: I think what would be best is to define a "service provider" > scope that is smaller than global, and larger than organization. > These would be defined to be forwarded to ISPs by default, although > organizations that don't want that can always filter them at the > desired boundary. > RFC 3513 describes the multicast scopes and there are some that are not currently defined. Regards, Brian From alex@technicalenlightenment.com Thu Mar 29 06:13:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A72921F8B3B for ; Thu, 29 Mar 2012 06:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gazjL79vqCVn for ; Thu, 29 Mar 2012 06:13:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1EA21F8B39 for ; Thu, 29 Mar 2012 06:13:24 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1569797ggm.31 for ; Thu, 29 Mar 2012 06:13:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:x-gm-message-state:content-type; bh=EDSSTBKH8duuLbqz5oVdVxxQtW5DgkFETelX/9/ca2U=; b=BkgM4+1OviAsTZhFjFqo35NZkr6VeDxZq59CaQ1z87i05aAQCAfBG7bLXBPLmXSr0Y oyeyqhF10Er/wHvaJLkb9v+6cDL0ZSVQquXoNOaJB7qelHVPxZmX2E2aG0fcDPAQbAR8 /d3UXKHaAwM0SeLFtG8U4ILohlY/c2aauNXWhuWUY3AeAekN40XJiZWCgcwYZhn6eUeH ZpY2Zr2oaLli1TelrTbyXGRst8E5uoJAAPLN8ineDKH4+Pas8OvHd2rhyYuYpr2BtEkJ iQvnvslQDnPAQxE4p6NfIeP+YzfbKcZWWfGnb2EZKOt7PXowK2FPc7/1STDHryje+eoM 6wIg== Received: by 10.50.104.137 with SMTP id ge9mr1511290igb.0.1333026803840; Thu, 29 Mar 2012 06:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.247.198 with HTTP; Thu, 29 Mar 2012 06:13:03 -0700 (PDT) X-Originating-IP: [94.193.97.134] In-Reply-To: <03d301cd0d97$b3361060$4001a8c0@gateway.2wire.net> References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <03d301cd0d97$b3361060$4001a8c0@gateway.2wire.net> From: Alex Abrahams Date: Thu, 29 Mar 2012 14:13:03 +0100 Message-ID: Subject: Re: 3484bis and privacy addresses To: ipv6@ietf.org X-Gm-Message-State: ALoCoQnHNe7wP1mH+GQc1/kiBorDWUlE6lI64JoC2VrDgvlVNT1Iw1nTI+v9TNcSEzCmNxm/FShC Content-Type: multipart/alternative; boundary=e89a8f23585f1e751104bc617d92 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:13:26 -0000 --e89a8f23585f1e751104bc617d92 Content-Type: text/plain; charset=ISO-8859-1 I'm sorry, but while I agree we have to think outside the corporate environment, I think we have to think way outside and we need to remember the kind of reasons why privacy exists, before saying the privacy extensions are only to keep a few hundred people happy. To give just one example, homosexuality still carries the death penalty in 9 countries. While I know there are other ways of tracking people online, I'd really prefer it if we didn't make it too easy for someone enforcing those laws to see who had used their pay-as-you-go smart phone to visit websites where guys would like to meet other guys, then a day later renewed their state car tax/insurance with the same phone. So while I agree from a technical stand point a network will be much easier to run if addresses are static, I think that not everyone that requires privacy have technically knowledge to understand the difference or make the change. My take is, if available, default to using the privacy address extensions, with corporations using group policy, or other tools to change as needed. I also think OS implementations SHOULD inform the user when a change from the privacy extensions has been enforced on the network. Alex --e89a8f23585f1e751104bc617d92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm sorry, but while I agree we have to think outside the=A0corporate= =A0environment, I think we have to think way outside and we need to=A0remem= ber=A0the kind of reasons why privacy=A0exists, before saying the privacy e= xtensions are only to keep a few hundred people happy.

To give just one example, homosexuality still carries the de= ath penalty in 9 countries. While I know there are other ways of tracking p= eople online, I'd really prefer it if we didn't make it too easy fo= r someone enforcing those laws to see who had used their pay-as-you-go smar= t phone to visit websites where guys would like to meet other guys, then a = day later renewed their state car tax/insurance with the same phone.=A0

So while I agree from a technical stand point a network= will be much easier to run if addresses are static, I think that not every= one that requires privacy have=A0technically=A0knowledge=A0to understand th= e difference or make the change.

My take is, if=A0available, default to using the = privacy address extensions, with=A0corporations=A0using group=A0policy, or = other tools to change as needed. I also think OS=A0implementations=A0SHOULD= inform the user when a change from the privacy=A0extensions=A0has been enf= orced on the network.

Alex
--e89a8f23585f1e751104bc617d92-- From alexandru.petrescu@gmail.com Thu Mar 29 06:49:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0887021F8B2A for ; Thu, 29 Mar 2012 06:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuTLrqXA6ZOs for ; Thu, 29 Mar 2012 06:49:24 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id A5D1921F8B18 for ; Thu, 29 Mar 2012 06:49:23 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so132757wgb.1 for ; Thu, 29 Mar 2012 06:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FtpHu01ziY4X2QSc0HK2FF1zEE/rBzK5eFlH/XPbrAw=; b=ZFpDdxPrTH/iCiZyRlDY3UT9jYPj4GhioiNz+PoyjGWsPeN2Mg9Z40D7nAgDee5xF3 RV9XH6Qadzt2Ch98nl0EykTQJ11ppYMEa0ABY7QhAiz+oifeyeAyfxlKNH6Az1Gm5zKO KNz69QpDnPQTwqxyqESbOdvyWKFAwRWE3JMbFZt2fhZCvrgTdQCM1EhF7YFJP/Py/TjR FXoBGxd4ejKljlWMih3eTPbrQ28dMfzZ2DMrjJlV9GW5V5YbsXj3GXGh76eMLA1HFlKE 3jkiUHuoRR+j82Dok2ohxMXdSHm8ARWm9AuGYxH2Z8aJOXd0ZzE6XSFKOEPHRw7CzBxZ t5Ng== Received: by 10.180.84.164 with SMTP id a4mr5929902wiz.2.1333028962842; Thu, 29 Mar 2012 06:49:22 -0700 (PDT) Received: from [130.129.17.29] (dhcp-111d.meeting.ietf.org. [130.129.17.29]) by mx.google.com with ESMTPS id fl2sm29043505wib.4.2012.03.29.06.49.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 06:49:21 -0700 (PDT) Message-ID: <4F746858.3010405@gmail.com> Date: Thu, 29 Mar 2012 15:49:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Kerry Lynn Subject: Re: I-D Action: draft-ietf-6man-6lobac-01.txt References: <20120312170644.5201.85558.idtracker@ietfa.amsl.com> <4F5F89CD.10207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:49:25 -0000 Le 13/03/2012 19:51, Kerry Lynn a écrit : > Hi Alex, > > Thanks for your comment. > > I was following the method of generating IIDs used by 6LoWPAN [RFC > 4944]. > > I note that RFC 4291 states in section 2.5.1 "For all unicast > addresses, except those that start with the binary value 000, > Interface IDs are required to be 64 bits long and to be constructed > in Modified EUI-64 format." That would mean that addresses prefixed by 000 (instead of 001) could have interface ids with lengths larger than 64, no? That RFC says "There are a number of types of links that have link-layer interface identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples include LocalTalk and Arcnet." Is MS/TP a link with IEEE tag on it now or in the future? (if not then one would be free to have Interface IDs wiht lengths shorter than 64 and thus maybe with an easier to implement one-to-one mapping between the link address and the IP address). > Technically, locally assigned MS/TP IIDs could be shorter than 64 > bits. However, if EUI-64s become popular for MS/TP devices there > might then be a situation where some devices have 64-bit IIDs and > others have shorter. Yes, I listen to that. I do not know about that tendency, maybe you see whether EUI-64s are becoming popular for MS/TP. > I am also not sure how a numbering scheme that uses prefixes longer > than 64 bits would work in the general case (given that many other > data links use 64-bit IIDs). I believe it may work with DHCP and RAs. Off of the top of my head I'd say that implementations don't impose this prefix length max 64 for assigned prefix, or for interface identifier. Alex > > -K- > > On Tue, Mar 13, 2012 at 1:54 PM, Alexandru Petrescu > wrote: >> HEllo, >> >> A side note about this. It is not a request for modification, >> just a thought. >> >> I wonder why do we want the Interface Identifier to be of length >> 64 when the MS/TP node address seems to be 8bit only. >> >> In a sense, it may be because SLAAC over Ethernet (802) is used to >> use 64bit IIDs. >> >> But in another sense, this is not Ethernet and hence the IID could >> be of length 8bit of MS/TP, right? >> >> I am asking this because of other contexts (non-MS/TP) whereby the >> link-layer addresses are shorter than 48bit and yet the Interface >> ID is still 64bit, "to make SLAAC work". >> >> In some contexts too, the ISP delivers a 64bit prefix to a leaf >> network and if that IID is almost always 64bit it means that it's >> hard next to impossible to form sub-prefixes of that ISP 64bit >> prefix and still use SLAAC. >> >> In a sense, it would be better to define the IIDs of MS/TP (or >> other link) to be of length 8, allow the ISP to assign 64bit >> prefix to leaf network, and let the gateway in between to derive >> prefixes out of that 64bit (up to 120) and still use SLAAC. >> >> This is just a thought, not a request to modify. >> >> Yours, >> >> Alex >> >> Le 13/03/2012 12:47, Kerry Lynn a écrit : >> >>> Greetings, >>> >>> The main changes to the WG version of this draft are: a) tweaks >>> that resulted from the initial public review of the BACnet MS/TP >>> change proposal, the most significant being the COBS encoding of >>> data and data crc fields to remove preamble sequences; and b) >>> addition of two informative appendices to provide code examples >>> for the data crc and COBS encoder/decoder. These appendices are >>> insufficient to implement the data link, but are provided e.g. >>> for those writing Wireshark dissectors or otherwise wanting more >>> detail about over- the-wire format. >>> >>> I'd like to solicit specific comments on what is needed to move >>> this draft forward - IOW, what would you like to see added in >>> order for this draft to be ready for WGLC? >>> >>> For anyone who'd like to view the details of data link state >>> machines, etc., I can provide the relevant clause (9) of the >>> ASHRAE 135-2010 (BACnet) spec, as well as the MS/TP change >>> proposal (Addendum an). >>> >>> Thanks, -K- >>> >>> >>> On Mon, Mar 12, 2012 at 1:06 PM, >>> wrote: >>>> >>>> >>>> A New Internet-Draft is available from the on-line >>>> Internet-Drafts directories. This draft is a work item of the >>>> IPv6 Maintenance Working Group of the IETF. >>>> >>>> Title : Transmission of IPv6 over MS/TP Networks >>>> Author(s) : Kerry Lynn Jerry Martocci Carl Neilson Stuart >>>> Donaldson Filename : draft-ietf-6man-6lobac-01.txt Pages >>>> : 20 Date : 2012-03-12 >>>> >>>> MS/TP (Master-Slave/Token-Passing) is a contention-free access >>>> method for the RS-485 physical layer that is used extensively >>>> in building automation networks. This document describes the >>>> frame format for transmission of IPv6 packets and the method >>>> of forming link-local and statelessly autoconfigured IPv6 >>>> addresses on MS/TP networks. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt >>>> >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> >>>> >> IETF IPv6 working group mailing list >>>> >>>> ipv6@ietf.org Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> >>>> >> >>>> >>>> -------------------------------------------------------------------- >>> >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> >> >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From fred@cisco.com Thu Mar 29 14:31:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846CE21E8082; Thu, 29 Mar 2012 14:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONWmINEC-KkN; Thu, 29 Mar 2012 14:31:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0221E801F; Thu, 29 Mar 2012 14:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1069; q=dns/txt; s=iport; t=1333056674; x=1334266274; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=y92Sah817gY/LhuwhElPkN5uduQx8daL4nB9DW1riII=; b=gpBrOTbJ6dJltPNM1sasHzIg74PItp2bHq6IpD8PlILzjjjvqG8ueh3O vUOuLGMU7/WMIx/sUUT4uaTHRyFLeNtISxyFdwAuXlOI+VyVKxzdqX8P8 DQT810DNNY6peaw7Km4RzFEwyY/zy7biaLt9kh0g/3OMkMm3bVcUosPG+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIHTdE+Q/khL/2dsb2JhbABCuSWBB4IJAQEBAwESASc/BQsLEgYuSQ4GNYdjBZ9Tlz+QKmMElWGFcIhWgWiCaQ X-IronPort-AV: E=Sophos;i="4.75,339,1330905600"; d="scan'208";a="69692796" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2012 21:31:08 +0000 Received: from dhcp-478d.meeting.ietf.org (ams3-vpn-dhcp4703.cisco.com [10.61.82.94]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2TLQWuE023974; Thu, 29 Mar 2012 21:31:08 GMT Received: from [127.0.0.1] by dhcp-478d.meeting.ietf.org (PGP Universal service); Thu, 29 Mar 2012 23:31:08 +0200 X-PGP-Universal: processed; by dhcp-478d.meeting.ietf.org on Thu, 29 Mar 2012 23:31:08 +0200 Subject: Re: You asked about multicast scope Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com> Date: Thu, 29 Mar 2012 23:31:07 +0200 Message-Id: References: <00B02ED4-4D6F-4B67-B548-D186C1B3B2CA@muada.com> <2AA4DD9C-DD38-422C-8483-FF295C086E11@cisco.com> <848F4FFF-2303-4E49-81CB-A0BD9180F31D@muada.com> <4F74447E.6020506@venaas.com> <4F74526D.6070003@innovationslab.net> <3042ADDB-95B9-4160-8BF1-F2E9E6C5A2A8@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , pcp@ietf.org, 6man 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 21:31:15 -0000 On Mar 29, 2012, at 2:52 PM, Iljitsch van Beijnum wrote: > On 29 Mar 2012, at 14:15 , Brian Haberman wrote: >=20 >> It is not an assumption, it is stately quite clearly in the Scoped = Addressing Architecture (RFC 4007). =46rom Section 5 : >=20 >> A zone of a given scope (less than global) falls completely = within >> zones of larger scope. That is, a smaller scope zone cannot >> include more topology than would any larger scope zone with which >> it shares any links or interfaces. >=20 > Brian, Stig, thanks for the help. >=20 > Fred: I think what would be best is to define a "service provider" = scope that is smaller than global, and larger than organization. These = would be defined to be forwarded to ISPs by default, although = organizations that don't want that can always filter them at the desired = boundary. >=20 > That way, the clients can always use a fixed scope =3D fixed multicast = group, avoiding the need for discovery or configuration here. I don't think this is a service provider discussion.= From dougb@dougbarton.us Thu Mar 29 17:00:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0141221F8503 for ; Thu, 29 Mar 2012 17:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpIabeC2qA44 for ; Thu, 29 Mar 2012 17:00:23 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4182E21F8501 for ; Thu, 29 Mar 2012 17:00:23 -0700 (PDT) Received: (qmail 18611 invoked by uid 399); 30 Mar 2012 00:00:16 -0000 Received: from unknown (HELO ?172.17.198.146?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 30 Mar 2012 00:00:16 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F74F78F.1020002@dougbarton.us> Date: Thu, 29 Mar 2012 17:00:15 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Alex Abrahams Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <03d301cd0d97$b3361060$4001a8c0@gateway.2wire.net> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 00:00:24 -0000 On 3/29/2012 6:13 AM, Alex Abrahams wrote: > I'm sorry, but while I agree we have to think outside > the corporate environment, I think we have to think way outside and we > need to remember the kind of reasons why privacy exists, before saying > the privacy extensions are only to keep a few hundred people happy. I agree that the "few hundred people" thing was grating, and unfortunate. But I think there is still a bit of a misunderstanding about what problem 4941 (and its predecessor) was designed to address. If you're in a corporate environment (at least in most of the western world) you have ZERO expectation of privacy, and should act accordingly. I anticipate that corporate IT departments who are concerned about the problems presented by 4941 addresses are going to disable them as a matter of policy. Period, end of discussion. Also, if you're on a home network, it doesn't matter what the bottom 64 bits are, your network prefix is enough information for the bad guys to use as ICBM targeting coordinates. All that said, the real problem that 4941 was designed to fix was that if you take the same system (think laptop, and now mobile phones, iThing, etc.) and connect it to multiple different networks (as in, the top 64 bits of your address are different) without 4941 or a similar mechanism it is still possible to uniquely identify that host. For that particular part of the problem, 4941 does very nicely, and end-user devices don't (or shouldn't) care what address is being used for their *outbound* connections, as long as their device and its applications handle the situation correctly. hth, Doug From marka@isc.org Thu Mar 29 17:25:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC25B21F8547 for ; Thu, 29 Mar 2012 17:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9xwwkhapyOl for ; Thu, 29 Mar 2012 17:25:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2D83321E8054 for ; Thu, 29 Mar 2012 17:25:03 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 66C0AC941E; Fri, 30 Mar 2012 00:24:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b9d2:d2a7:a07b:5597]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 111AF216C31; Fri, 30 Mar 2012 00:24:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id F30DA1F3C24B; Fri, 30 Mar 2012 11:24:34 +1100 (EST) To: Doug Barton From: Mark Andrews References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <03d301cd0d97$b3361060$4001a8c0@gateway.2wire.net> <4F74F78F.1020002@dougbarton.us> Subject: Re: 3484bis and privacy addresses In-reply-to: Your message of "Thu, 29 Mar 2012 17:00:15 PDT." <4F74F78F.1020002@dougbarton.us> Date: Fri, 30 Mar 2012 11:24:34 +1100 Message-Id: <20120330002434.F30DA1F3C24B@drugs.dv.isc.org> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 00:25:04 -0000 In message <4F74F78F.1020002@dougbarton.us>, Doug Barton writes: > > Also, if you're on a home network, it doesn't matter what the bottom 64 > bits are, your network prefix is enough information for the bad guys to > use as ICBM targeting coordinates. And if we want to address home networks then we need a way to signal that we want both stable and temporary prefixes with PD and a way to differentiate them when advertising them via RA. DHCPv6 already has IA_NA and IA_TA. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From v6ops@globis.net Fri Mar 30 06:04:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBFB21F84F8 for ; Fri, 30 Mar 2012 06:04:29 -0700 (PDT) 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=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqUHrtsxikJX for ; Fri, 30 Mar 2012 06:04:28 -0700 (PDT) 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 BD46721F8673 for ; Fri, 30 Mar 2012 06:04:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C2FFA8700D5; Fri, 30 Mar 2012 15:04:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5D5Y8XG3xMn; Fri, 30 Mar 2012 15:04:16 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 5BC38870064; Fri, 30 Mar 2012 15:04:16 +0200 (CEST) Message-ID: <4F75AF50.5000308@globis.net> Date: Fri, 30 Mar 2012 15:04:16 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fernando Gont Subject: Re: [6man] Stable privacy addresses (upcoming rev) References: <4F7333F9.9090007@si6networks.com> In-Reply-To: <4F7333F9.9090007@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:04:29 -0000 I have reviewed draft-gont-6man-stable-privacy-addresses and have already sent some nits direct to the author. I like this draft. One of my biggest criticisms of RFC4941 today is that end nodes act unilaterally, and that due consideration was not made of the needs of organizations (such as Enterprises or ISPs), where logging is perfectly legal, desirable, and has compliance issues. If I were to write the design goal for interface identifier privacy myself I'd write: o It should be easy for an authorized person to be able to reliably predict the interface identifiers that will be generated by the algorithm, provided that the authorized person has access to the algorithm and the secret keying material used in generating the interface identifiers, but not otherwise. The idea being that authorized persons e.g. law enforcement and network managers SHOULD be able to correlate activity at a later date (for legal compliance, logging, fault finding etc.) whilst an attacker or unauthorized person SHOULD NOT. I have no objection per se to the time variance of temporary addresses of RFC4941, provided that the rotation of addresses happens in a controlled manner. Again, a common criticism of 4941 is that long-lived sessions may be broken, and there's no way of knowing when authorized persons should relearn/re-correlate private addresses to native EUI64's/machines. I can think of 2 mechanisms to achieve controlled time-variance using your draft: 1. If controlled renumbering is ever widely implemented, it would be possible for a network manager to regularly rotate the /64 subnet prefixes in a controlled manner (add new prefix, deprecate old prefix) to generate new Random Interface Identifiers (RIDs), rather than this being an unilateral choice of the end nodes as in 4941. An end node would generate a new RID and use this for new sessions, whilst existing sessions would continue to use the RID generated from the deprecated prefix. This would mean that the time-variant aspect of user privacy in 4941 could be maintained, whilst end node activity could still also be tracked and correlated by the authorized person/network manager (but not as easily by an attacker who does not have access to the secret key). Some might say that this is a weakness, in that a node connected to a 3rd party LAN could be tricked into giving away a few bits of information every time a RID is regenerated. However, I don't consider that a major issue, because the 3rd party LAN manager could anyway track usage directly, either based on the /64 parent prefix or some other means like EUI64 media address. A remote passive attacker might also have difficulty working out exactly how a new /64 prefix is correlated to the existing /64 prefix (provided there was enough variance in users and all other things/information leaks being equal.) 2. If the implementation provided a mechanism for the secret_key to be changed, it would also be possible for a network manager to regularly update the secret_keys in a controlled manner so that an end node would generate a new RID when an interface was re-initialised. For these reasons, I feel that all implementations SHOULD include a mechanism for the secret_key to be updated (to repair a potentially compromised node where the secret_key has been learned by an unauthorized person, complicate long-term snooping of RID changes when prefixes change, and to allow a manager to trigger a RID rotation per node) I make no comment on the mechanism by which the secret_key should be updated. Some environments may require specialist hardware, or use of an existing Security Association to create a secure channel to a secure node, whilst others might consider a DHCPv6 option sufficient. These mechanisms could be defined in related drafts. This secret_key could then also be stored somewhere in a central (secure) log for use in cross-referencing obfuscated addresses from various logs at a later date. Some switches or other devices that limit access to a single IPv6 link local address per port may have problems with RIDs. RFC4941 Sections 3.6 & 4 are certainly pertinent. regards, RayH Fernando Gont wrote: > Folks, > > Probably the only objection that I got for > draft-gont-6man-stable-privacy-addresses is that the prefix shouldn't be > included in F() (the hash function). > > I'd like to clarify the motivation for that, and also trigger some > discussion on the topic such that I can produce a revision of this > docuement that addresses any remaining concerns. > > > * Motivation for including the SLAAC Prefix in F() (the hash function) > > The essential rationale for including the prefix in the hash function is > that, if we don't, then we'd be leaking more information than we should. > > If we don't include the prefix as part of the data to be hashed, then > the Interface-ID will be exactly the same no matter whether the devices > moves from one network to another, and hence the node could be tracked, > even if it implements RFC 4941. > > For example, think about the following scenario: > > Attack scenario #1 > > A host configures the stable addresses without including the Prefix in > the hash function. Let's say the host employs any application that needs > to perform a server-like function (P2P, or whatever). As a result of > that, an attacker attacker participating in that application (e.g., P2P) > would learn the Interface-ID used for the stable address. > > Now the same host moves to a completely different network, and uses the > same P2P application, probably even with a different user. The attacker > now interacts with the same node again, and hence can learn the "new" > stable address. Since the interface ID is the same as the one above, he > can infer that it is communicating with the same device as before. > > Had the host included the Prefix when computing the Interface-ID (with > the hash function F()), the Interface-ID would have been different, and > this wouldn't have been made possible. > > This is just *one* possible attack scenario, which should remind us that > one shouldn't disclose more than it is really needed (and a static > Interface-ID across many different networks does exactly that). > > > * Use of draft-gont-6man-stable-privacy-addresses without RFC 4941 > > Temporary addresses are painful to manage. They make painful to > correlate the activities of your own nodes. FOr example, one host gets > infeceted will malware, you logged the IPv6 address, but then you don't > know which node was using that address at that point in time. > > This is the reason for which in many deployments temporary addresses > (RFC 4941) are disabled (e.g., look at any presentation by Ron Broersma). > > When you disable temporary addresses, all you're left with is whatever > stable addresses your host uses. If you don't include the Prefix in F() > (the hash function) then, while you may be resistant to host scanning > attacks (your addresses is not predictable anymore), you're still > trackable, since your interface ID doesn't change as you move from one > network to another. > > So yes, there are cases in which you may want privacy, without > necessarily be willing to deal with the burden of temporary addresses. > And if you're just going to have stable addresses, you do not really > want the Interface ID to be constant across networks. > > > * Concerns about CPU impact > > Other folks have expressed concerns (in corridor meetings) that if the > Prefix is included in the hash function, they may need to recompute the > hash every time they attach to a network (assuming the SLAAC prefix > changes), and that would be expensive. I personally think this shouldn't > be an issue for most implementations (for instance, we do MD5 for every > single new TCP connection! -- see RFC 6528). And, in any case, we do not > really specify which hash function to use. -- If you're concerned about > CPU, you may want to use a (CPU-wise) cheaper function. > > That said, I'd have no problem with making the inclusion of the Prefix a > SHOULD (i.e., do it, unless you have very good reasons not to do so > (such as CPU-constraints)), or even a MAY (if inclusion of the Prefix in > the hash function turns out to be the show-stopper here). > > > If you have any feedback/comments, I'd be glad to hear. I'm planning to > rev the document asap, clarifying and incorporating many of the things > explained throughout this e-mail. So if you send your feedback shortly, > the next rev could reflect your comments. > > Thanks, > From fgont@si6networks.com Fri Mar 30 09:47:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F62F21F850D for ; Fri, 30 Mar 2012 09:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE1BzbJZmvBU for ; Fri, 30 Mar 2012 09:47:16 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2E07521F84E7 for ; Fri, 30 Mar 2012 09:47:16 -0700 (PDT) Received: from lputeaux-156-15-30-250.w82-127.abo.wanadoo.fr ([82.127.29.250] helo=[192.168.101.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SDeyZ-0004VF-NU; Fri, 30 Mar 2012 18:46:59 +0200 Message-ID: <4F75E38C.4060008@si6networks.com> Date: Fri, 30 Mar 2012 18:47:08 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Mark Andrews Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <03d301cd0d97$b3361060$4001a8c0@gateway.2wire.net> <4F74F78F.1020002@dougbarton.us> <20120330002434.F30DA1F3C24B@drugs.dv.isc.org> In-Reply-To: <20120330002434.F30DA1F3C24B@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 16:47:38 -0000 On 03/30/2012 02:24 AM, Mark Andrews wrote: > In message <4F74F78F.1020002@dougbarton.us>, Doug Barton writes: >> >> Also, if you're on a home network, it doesn't matter what the bottom 64 >> bits are, your network prefix is enough information for the bad guys to >> use as ICBM targeting coordinates. > > And if we want to address home networks then we need a way to signal > that we want both stable and temporary prefixes with PD and a way > to differentiate them when advertising them via RA. Please see: Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Fri Mar 30 12:47:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6BE21F84AE for ; Fri, 30 Mar 2012 12:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCx8-bNB77Sk for ; Fri, 30 Mar 2012 12:47:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAEA21F84F0 for ; Fri, 30 Mar 2012 12:47:31 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2186648pbb.31 for ; Fri, 30 Mar 2012 12:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rkI5xv/p/wQ7Zh/sCPNzZ+ZiqodVtfIWTYlvjU77HYQ=; b=hXFlrUE7fI9hm58EhAu6Fj6ivxO4O9uvIS1WSbR9CNMqMrsl/MAMVkY3lMjaARKPhV 6mmdUFQ2/M7UJvjJsH7gzvErxHe50+PWlsoIG8qO1xkj2AaXaObFODwDIs/1KFF7Mdvh bRH2RfBuOOZjWE2Sr/vhlNcJRDCnvsSmI7US1wUCV4X8Oi/Myen/8CRCD9yC3lEyDdav IsuFZXlUnB0hA1xjb7qF+lPX/SZMAb22nDMkFpMrxjOk2TPSf7STIbx52bp3JuUBONw4 Eg1KFOo/5mNM4QXHznpEptr7OKqodj7PrAXWVCtqZ0tdqgvrGpQOnuD66Z7rq+5v94c+ 50CQ== Received: by 10.68.189.138 with SMTP id gi10mr116129pbc.89.1333136850912; Fri, 30 Mar 2012 12:47:30 -0700 (PDT) Received: from [192.168.110.51] (koruout.airnz.co.nz. [162.112.38.5]) by mx.google.com with ESMTPS id f5sm8006378pbe.26.2012.03.30.12.47.23 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 12:47:25 -0700 (PDT) Message-ID: <4F760DC9.8090109@gmail.com> Date: Sat, 31 Mar 2012 08:47:21 +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 Subject: Re: [6man] Stable privacy addresses (upcoming rev) References: <4F7333F9.9090007@si6networks.com> <4F75AF50.5000308@globis.net> In-Reply-To: <4F75AF50.5000308@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:47:31 -0000 Ray, On 2012-03-31 02:04, Ray Hunter wrote: ... > The idea being that authorized persons e.g. law enforcement and network > managers SHOULD be able to correlate activity at a later date (for legal > compliance, logging, fault finding etc.) whilst an attacker or > unauthorized person SHOULD NOT. If you were a blogger sitting in an Internet cafe in a country governed by a repressive regime, you would probably hold a different view. Brian From fgont@si6networks.com Fri Mar 30 13:20:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6E821F866A for ; Fri, 30 Mar 2012 13:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNief0e4rdYi for ; Fri, 30 Mar 2012 13:20:34 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id A975721F861D for ; Fri, 30 Mar 2012 13:20:34 -0700 (PDT) Received: from static-qvn-qvu-166143.business.bouyguestelecom.com ([89.81.166.143] helo=[192.168.101.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SDiIz-0006Jn-JQ; Fri, 30 Mar 2012 22:20:17 +0200 Message-ID: <4F761589.7090800@si6networks.com> Date: Fri, 30 Mar 2012 22:20:25 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [6man] Stable privacy addresses (upcoming rev) References: <4F7333F9.9090007@si6networks.com> <4F75AF50.5000308@globis.net> <4F760DC9.8090109@gmail.com> In-Reply-To: <4F760DC9.8090109@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:20:35 -0000 Brian, On 03/30/2012 09:47 PM, Brian E Carpenter wrote: > On 2012-03-31 02:04, Ray Hunter wrote: > ... >> The idea being that authorized persons e.g. law enforcement and network >> managers SHOULD be able to correlate activity at a later date (for legal >> compliance, logging, fault finding etc.) whilst an attacker or >> unauthorized person SHOULD NOT. > > If you were a blogger sitting in an Internet cafe in a country governed > by a repressive regime, you would probably hold a different view. If the regime controls the local-link, then as far as address-tracking is concerned, you're toast. -- They could sniff the network and log the address->MAC mappings, have RAs require you to do DHCPv6 and then have DHCPv6 assign you a constant address, etc. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Fri Mar 30 13:50:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B921F8642 for ; Fri, 30 Mar 2012 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIznmOetxjDI for ; Fri, 30 Mar 2012 13:50:49 -0700 (PDT) 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 D195A21F85FD for ; Fri, 30 Mar 2012 13:50:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E17808700E7; Fri, 30 Mar 2012 22:50:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jV1YxkhTClz; Fri, 30 Mar 2012 22:50:35 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id ADFF9870064; Fri, 30 Mar 2012 22:50:35 +0200 (CEST) Message-ID: <4F761C9B.8010409@globis.net> Date: Fri, 30 Mar 2012 22:50:35 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [6man] Stable privacy addresses (upcoming rev) References: <4F7333F9.9090007@si6networks.com> <4F75AF50.5000308@globis.net> <4F760DC9.8090109@gmail.com> In-Reply-To: <4F760DC9.8090109@gmail.com> Content-Type: multipart/alternative; boundary="------------040404070401020705030803" Cc: Fernando Gont , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:50:49 -0000 This is a multi-part message in MIME format. --------------040404070401020705030803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Ray, > > On 2012-03-31 02:04, Ray Hunter wrote: > ... > >> The idea being that authorized persons e.g. law enforcement and network >> managers SHOULD be able to correlate activity at a later date (for legal >> compliance, logging, fault finding etc.) whilst an attacker or >> unauthorized person SHOULD NOT. >> > > If you were a blogger sitting in an Internet cafe in a country governed > by a repressive regime, you would probably hold a different view. > > Brian > Please let's not take this out of context. We're talking about obfuscating interface identifiers. If I'm sat in an Internet cafe in a repressive regime (and I have visited and worked in various countries around the World, including one that fingerprinted me on entry, one that took a full body scan capable of looking through clothes, and one which is known to operate firewalls and passive monitoring on all International links), obfuscating an interface identifier is not going to protect my rights. That repressive regime would anyway likely have access to a copy of my passport or ID card, my network login credentials, the time I entered the Internet cafe, which seat I was sat on, a report from my neighbors, details of my phone's SIM card, man in the middle HTTPS monitoring, my MAC address, the /64 prefix I was using, a key logger running on the ISP host, a camera pointed at the screen ..... I do not attempt to define "authorized persons" any further than providing an example. I express no preference whatsoever on the question of whether privacy is desirable or not on this list, nor to what standard, nor where the balance lies between rights of the state or corporation and the rights of the individual, nor whether particular laws are sensible or not. I'm just trying to comply with local laws when giving advice to companies operating in countries where I provide consultancy. And many of those local laws include a requirement for corporations to retain a log of IP addresses, network communications, and user credentials for several months, and to provide access to this information to "authorized persons" when necessary, even though they are some of the most liberal regimes in the World. regards, RayH --------------040404070401020705030803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Brian E Carpenter wrote: 
Ray,

On 2012-03-31 02:04, Ray Hunter wrote:
...
  
The idea being that authorized persons e.g. law enforcement and network
managers SHOULD be able to correlate activity at a later date (for legal
compliance, logging, fault finding etc.) whilst an attacker or
unauthorized person SHOULD NOT.
    

If you were a blogger sitting in an Internet cafe in a country governed
by a repressive regime, you would probably hold a different view.

    Brian
Please let's not take this out of context. We're talking about obfuscating interface identifiers. If I'm sat in an Internet cafe in a repressive regime (and I have visited and worked in various countries around the World, including one that fingerprinted me on entry, one that took a full body scan capable of looking through clothes, and one which is known to operate firewalls and passive monitoring on all International links), obfuscating an interface identifier is not going to protect my rights. That repressive regime would anyway likely have access to a copy of my passport or ID card, my network login credentials, the time I entered the Internet cafe, which seat I was sat on, a report from my neighbors, details of my phone's SIM card, man in the middle HTTPS monitoring, my MAC address, the /64 prefix I was using, a key logger running on the ISP host, a camera pointed at the screen  .....

I do not attempt to define "authorized persons" any further than providing an example. I express no preference whatsoever on the question of whether privacy is desirable or not on this list, nor to what standard, nor where the balance lies between rights of the state or corporation and the rights of the individual, nor whether particular laws are sensible or not.

I'm just trying to comply with local laws when giving advice to companies operating in countries where I provide consultancy. And many of those local laws include a requirement for corporations to retain a log of IP addresses, network communications, and user credentials for several months, and to provide access to this information to "authorized persons" when necessary, even though they are some of the most liberal regimes in the World.

regards,
RayH
--------------040404070401020705030803-- From kauer@biplane.com.au Fri Mar 30 15:57:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18BE21F84CE for ; Fri, 30 Mar 2012 15:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqFFA7YfiyNG for ; Fri, 30 Mar 2012 15:57:36 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id AF25C21F84C4 for ; Fri, 30 Mar 2012 15:57:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBABg6dk+WZX+7/2dsb2JhbAANNoVWtmeBMwJfE7UTigOPdIEYBKEWh3Q Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 31 Mar 2012 09:27:32 +1030 Subject: RA "requires" DHCPv6 ? From: Karl Auer To: "ipv6@ietf.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bzpq7gKFbcl4zHthfzmw" Date: Sat, 31 Mar 2012 09:57:28 +1100 Message-ID: <1333148248.2624.187.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:57:36 -0000 --=-bzpq7gKFbcl4zHthfzmw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In a discussion titled "Stable privacy addresses (upcoming rev)", Fernando Gont said: > They could [...] have RAs require you to do DHCPv6 and then have > DHCPv6 assign you a constant address, etc. What interests me here is the phrase "have RAs require you to do DHCPv6". When, if ever, are hosts "required" to obtain an address via DHCPv6? When the "M" flag is set in an RA? There was a bunch of stuff about the M and O flags in RFC2462, almost all of which was removed in RFC4862. In RFC2462, the word "should" (*not* capitalised) was used, along with phrases like "is to be". Then there is RFC 4861 (neighbor discovery) which says: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. [...] O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Anyway, I've been working on the basis that the M and O flags are advisory and not prescriptive. That is, they do not *require* the host to do anything. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-bzpq7gKFbcl4zHthfzmw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk92OlIACgkQFpl7eE7uYBdeEAD8CohHIG+E7SYahagzNpT+kwW9 5Eu0SAqI+/aRiRp/B00A/Rx/Bchm1A2zXr+f2o/55Av7Ca0hsgLzkqpPJxbnO/Tf =ZR0F -----END PGP SIGNATURE----- --=-bzpq7gKFbcl4zHthfzmw-- From huitema@microsoft.com Fri Mar 30 22:32:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3DA21F846B for ; Fri, 30 Mar 2012 22:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.048 X-Spam-Level: X-Spam-Status: No, score=-4.048 tagged_above=-999 required=5 tests=[AWL=2.551, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqMSyD7X-Kwe for ; Fri, 30 Mar 2012 22:32:09 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id E382F21F85A3 for ; Fri, 30 Mar 2012 22:32:06 -0700 (PDT) Received: from mail49-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Sat, 31 Mar 2012 05:32:04 +0000 Received: from mail49-tx2 (localhost [127.0.0.1]) by mail49-tx2-R.bigfish.com (Postfix) with ESMTP id A624C6024E; Sat, 31 Mar 2012 05:32:04 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail49-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=huitema@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail49-tx2 (localhost.localdomain [127.0.0.1]) by mail49-tx2 (MessageSwitch) id 1333171923364055_30861; Sat, 31 Mar 2012 05:32:03 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.240]) by mail49-tx2.bigfish.com (Postfix) with ESMTP id 536972C004E; Sat, 31 Mar 2012 05:32:03 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 31 Mar 2012 05:32:03 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.3]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Sat, 31 Mar 2012 05:32:03 +0000 From: Christian Huitema To: Fernando Gont , Brian E Carpenter Subject: RE: [6man] Stable privacy addresses (upcoming rev) Thread-Topic: [6man] Stable privacy addresses (upcoming rev) Thread-Index: AQHNDPsLlDIhpBxAmkyyyMolypoNkZaC0UIAgABwn4CAAAk9gIAAmOCQ Date: Sat, 31 Mar 2012 05:32:02 +0000 Message-ID: References: <4F7333F9.9090007@si6networks.com> <4F75AF50.5000308@globis.net> <4F760DC9.8090109@gmail.com> <4F761589.7090800@si6networks.com> In-Reply-To: <4F761589.7090800@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Ray Hunter , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 05:32:13 -0000 > If the regime controls the local-link, then as far as address-tracking is= concerned, you're toast. -- They could sniff the=20 >network and log the address->MAC mappings, have RAs require you to do DHCP= v6 and then have DHCPv6 assign you a > constant address, etc. The obvious solution is to randomize the MAC address, and I would definitel= y want to do that when visiting untrusted networks.=20 Of course, randomizing the MAC address is necessary but not sufficient. The= re are many other ways in which our computer leak information. DHCP message= s, for example, contains names and other identifiers. Computers connecting = to a network issue a flurry of DNS lookups that can make for good signature= s. Etc. -- Christian Huitema From hesham@elevatemobile.com Sat Mar 31 05:03:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC8A21F86B6 for ; Sat, 31 Mar 2012 05:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkMj4ka2LFMq for ; Sat, 31 Mar 2012 05:03:45 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2421F86A3 for ; Sat, 31 Mar 2012 05:03:44 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1SDx1Q-00054q-8Q; Sat, 31 Mar 2012 23:03:18 +1100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 31 Mar 2012 23:03:04 +1100 Subject: Re: RA "requires" DHCPv6 ? From: Hesham Soliman To: Karl Auer , "ipv6@ietf.org" Message-ID: Thread-Topic: RA "requires" DHCPv6 ? In-Reply-To: <1333148248.2624.187.camel@karl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 12:03:46 -0000 Just a quick comment below >There was a bunch of stuff about the M and O flags in RFC2462, almost >all of which was removed in RFC4862. In RFC2462, the word >"should" (*not* capitalised) was used, along with phrases like "is to >be". => "should" does not need to be capitalised to indicate that it's a keyword. It's a common misunderstanding. Hesham > >Then there is RFC 4861 (neighbor discovery) which says: > > M 1-bit "Managed address configuration" flag. When > set, it indicates that addresses are available via > Dynamic Host Configuration Protocol [DHCPv6]. >[...] > O 1-bit "Other configuration" flag. When set, it > indicates that other configuration information is > available via DHCPv6. > >Anyway, I've been working on the basis that the M and O flags are >advisory and not prescriptive. That is, they do not *require* the host >to do anything. > >Regards, K. > >-- >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Karl Auer (kauer@biplane.com.au) >http://www.biplane.com.au/kauer > >GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 >Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From kauer@biplane.com.au Sat Mar 31 05:12:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7070C21F848A for ; Sat, 31 Mar 2012 05:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2lfEUcs0RSk for ; Sat, 31 Mar 2012 05:12:11 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 8119921F8478 for ; Sat, 31 Mar 2012 05:12:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACj0dk+WZX+7/2dsb2JhbAANNoVUtkcBAQEEI2YLGCoCAlcGE7URig2QBIEYBKEXh3Q Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 31 Mar 2012 22:42:08 +1030 Subject: Re: RA "requires" DHCPv6 ? From: Karl Auer To: "ipv6@ietf.org" In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AIlDD9+d0xExncbKQUvB" Date: Sat, 31 Mar 2012 23:12:05 +1100 Message-ID: <1333195925.11943.10.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 12:12:12 -0000 --=-AIlDD9+d0xExncbKQUvB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-03-31 at 23:03 +1100, Hesham Soliman wrote: > >There was a bunch of stuff about the M and O flags in RFC2462, almost > >all of which was removed in RFC4862. In RFC2462, the word > >"should" (*not* capitalised) was used, along with phrases like "is to > >be". >=20 > =3D> "should" does not need to be capitalised to indicate that it's a > keyword. It's a common misunderstanding. Oh, I don't misunderstand that point. But reading RFC2462, and seeing things like "is to be" and seeing how the word "should" was used in context, I got the feeling that it was not being treated with the respect it deserved - i.e., that sometimes it was not being used prescriptively. In any case, that's all gone from RFC4862, which obsoletes RFC2462. Leaving me still wondering. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-AIlDD9+d0xExncbKQUvB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk929I0ACgkQFpl7eE7uYBcaqgEAqFrjqgeZO4PvVG/20BLxV8T2 ADLK7xx+X8sb+m3tCGoA/09Et1tUbVA3M9BIZCste4KZVl9jfghtdvUlKqoaWRrl =7X04 -----END PGP SIGNATURE----- --=-AIlDD9+d0xExncbKQUvB-- From fgont@si6networks.com Sat Mar 31 05:50:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C877B21F8595 for ; Sat, 31 Mar 2012 05:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2N0KE+lCNCx for ; Sat, 31 Mar 2012 05:50:53 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 43F2921F858E for ; Sat, 31 Mar 2012 05:50:53 -0700 (PDT) Received: from laubervilliers-151-13-4-225.w217-128.abo.wanadoo.fr ([217.128.3.225] helo=[192.168.101.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SDxlJ-00075U-TU; Sat, 31 Mar 2012 14:50:34 +0200 Message-ID: <4F76F41C.1000904@si6networks.com> Date: Sat, 31 Mar 2012 14:10:04 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Karl Auer Subject: Re: RA "requires" DHCPv6 ? References: <1333148248.2624.187.camel@karl> In-Reply-To: <1333148248.2624.187.camel@karl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 12:50:53 -0000 Hi, Karl, On 03/31/2012 12:57 AM, Karl Auer wrote: > In a discussion titled "Stable privacy addresses (upcoming rev)", > Fernando Gont said: >> They could [...] have RAs require you to do DHCPv6 and then have >> DHCPv6 assign you a constant address, etc. > > What interests me here is the phrase "have RAs require you to do DHCPv6". If the RAs do not include PIOs, and have the "M" bit set, what are your options: 1) Do DHCPv6, or, 2) Go to the park, and enjoy some sun, because "no internet today". > There was a bunch of stuff about the M and O flags in RFC2462, almost > all of which was removed in RFC4862. In RFC2462, the word > "should" (*not* capitalised) was used, along with phrases like "is to > be". > > Then there is RFC 4861 (neighbor discovery) which says: > > M 1-bit "Managed address configuration" flag. When > set, it indicates that addresses are available via > Dynamic Host Configuration Protocol [DHCPv6]. > [...] > O 1-bit "Other configuration" flag. When set, it > indicates that other configuration information is > available via DHCPv6. > > Anyway, I've been working on the basis that the M and O flags are > advisory and not prescriptive. That is, they do not *require* the host > to do anything. Exactly: They do not REQUIRE you to do DHCPv6. You MAY want not to do it, and just not use the Internet for the day. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sat Mar 31 05:50:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BD721F867D for ; Sat, 31 Mar 2012 05:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWus5oBzDmMg for ; Sat, 31 Mar 2012 05:50:56 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7AD21F8663 for ; Sat, 31 Mar 2012 05:50:56 -0700 (PDT) Received: from laubervilliers-151-13-4-225.w217-128.abo.wanadoo.fr ([217.128.3.225] helo=[192.168.101.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SDxlR-00075b-9w; Sat, 31 Mar 2012 14:50:41 +0200 Message-ID: <4F76F830.7030408@si6networks.com> Date: Sat, 31 Mar 2012 14:27:28 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Christian Huitema Subject: Re: [6man] Stable privacy addresses (upcoming rev) References: <4F7333F9.9090007@si6networks.com> <4F75AF50.5000308@globis.net> <4F760DC9.8090109@gmail.com> <4F761589.7090800@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 12:50:57 -0000 On 03/31/2012 07:32 AM, Christian Huitema wrote: >> If the regime controls the local-link, then as far as >> address-tracking is concerned, you're toast. -- They could sniff >> the network and log the address->MAC mappings, have RAs require you >> to do DHCPv6 and then have DHCPv6 assign you a constant address, >> etc. > > The obvious solution is to randomize the MAC address, and I would > definitely want to do that when visiting untrusted networks. Or use an external card or even a different system, use it, and destroy and throw away. :-) In any case, as noted by Ray, if you're really into the aforementioned "regime" situation, randomizing the mac address is probably *not* #1 in your set of priorities. > Of course, randomizing the MAC address is necessary but not > sufficient. There are many other ways in which our computer leak > information. DHCP messages, for example, contains names and other > identifiers. Computers connecting to a network issue a flurry of DNS > lookups that can make for good signatures. Etc. Exactly. That's why I said that if the regime controls the local link, then, for the most part "game over". - If they don't, you can usually tunnel somewhere else. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From kauer@biplane.com.au Sat Mar 31 06:13:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5687621F8668 for ; Sat, 31 Mar 2012 06:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwT8w8AbCN4U for ; Sat, 31 Mar 2012 06:13:09 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 7499F21F8659 for ; Sat, 31 Mar 2012 06:13:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEQCd0+WZX+7/2dsb2JhbAANOIVHtkcBAQEEI2YLGCoCAlcGE7ApkXeQBIEYBKEXh3Q Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 31 Mar 2012 23:43:04 +1030 Subject: Re: RA "requires" DHCPv6 ? From: Karl Auer To: "ipv6@ietf.org" In-Reply-To: <4F76F41C.1000904@si6networks.com> References: <1333148248.2624.187.camel@karl> <4F76F41C.1000904@si6networks.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-t54vF8wgzHJvll4BoEtj" Date: Sun, 01 Apr 2012 00:12:55 +1100 Message-ID: <1333199575.11943.16.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 13:13:10 -0000 --=-t54vF8wgzHJvll4BoEtj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-03-31 at 14:10 +0200, Fernando Gont wrote: > > Anyway, I've been working on the basis that the M and O flags are > > advisory and not prescriptive. That is, they do not *require* the > > host to do anything. >=20 > Exactly: They do not REQUIRE you to do DHCPv6. You MAY want not to do > it, and just not use the Internet for the day. Or you could use one's statically assigned address. Or you could make addresses using other available prefixes, from the same or other routers. Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-t54vF8wgzHJvll4BoEtj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk93Ar4ACgkQFpl7eE7uYBcU3QD+InTqa2GoSf4/RR2mOzEiikh4 7w32ko46vgkY27rmHisBAK8FJDj7zs9d33scw+LBPxQ2jly8gvriQQEgzJROnaJ4 =xqZl -----END PGP SIGNATURE----- --=-t54vF8wgzHJvll4BoEtj-- From fgont@si6networks.com Sat Mar 31 12:43:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5374221F8622 for ; Sat, 31 Mar 2012 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1bf5rLbC2u8 for ; Sat, 31 Mar 2012 12:43:33 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id C48CE21F861D for ; Sat, 31 Mar 2012 12:43:33 -0700 (PDT) Received: from static-qvn-qvu-166143.business.bouyguestelecom.com ([89.81.166.143] helo=[192.168.101.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SE4Cd-0001jr-Ev; Sat, 31 Mar 2012 21:43:13 +0200 Message-ID: <4F775E55.3050905@si6networks.com> Date: Sat, 31 Mar 2012 21:43:17 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Karl Auer Subject: Re: RA "requires" DHCPv6 ? References: <1333148248.2624.187.camel@karl> <4F76F41C.1000904@si6networks.com> <1333199575.11943.16.camel@karl> In-Reply-To: <1333199575.11943.16.camel@karl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 19:43:34 -0000 On 03/31/2012 03:12 PM, Karl Auer wrote: > On Sat, 2012-03-31 at 14:10 +0200, Fernando Gont wrote: >>> Anyway, I've been working on the basis that the M and O flags are >>> advisory and not prescriptive. That is, they do not *require* the >>> host to do anything. >> >> Exactly: They do not REQUIRE you to do DHCPv6. You MAY want not to do >> it, and just not use the Internet for the day. > > Or you could use one's statically assigned address. Oh, yeah. And you could have opted to not send the RS in the first place... and what? :-) -- However, particularly in the case in which the local router wants you to use DHCPv6, they could easily block addresses that have not been leased by the DHCPv6 server. SO, at the end of the day, you're at its mercy. > Or you could make > addresses using other available prefixes, from the same or other > routers. We were assuming the "regime" was controlling the local link. If they do, its up to them whether there are other routers on the link and/or whether RAs are allowed to flow on that link. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sat Mar 31 14:24:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A6A21F872A for ; Sat, 31 Mar 2012 14:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3D-D0GL7X68 for ; Sat, 31 Mar 2012 14:24:52 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6CED521F8726 for ; Sat, 31 Mar 2012 14:24:52 -0700 (PDT) Received: from static-qvn-qvu-166143.business.bouyguestelecom.com ([89.81.166.143] helo=[192.168.101.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SE5mp-0002TD-86; Sat, 31 Mar 2012 23:24:39 +0200 Message-ID: <4F777621.3040200@si6networks.com> Date: Sat, 31 Mar 2012 23:24:49 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: New revision of draft-gont-6man-stable-privacy-addresses X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 21:24:53 -0000 Folks, I've just posted a revision of the aforementioned I-D. It is available at: It contains a number of improvements and clarifications, based on the questions received during the 6man wg meeting, but also thanks to a number of comments and reviews received off-list (thanks!). Section 7 contains a discussion of privacy issues still present when temporary addresses (RFC 4941) are employed, to make it pretty clear that this scheme is needed, even if temporary addresses (RFC 4941) are employed. Any feedback will be welcome. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From kauer@biplane.com.au Sat Mar 31 15:46:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4F821F8617 for ; Sat, 31 Mar 2012 15:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO8fMD6xDwgq for ; Sat, 31 Mar 2012 15:46:17 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C821F8596 for ; Sat, 31 Mar 2012 15:46:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABeId0+WZX+7/2dsb2JhbAANNYVUtkYBAQEDASNbCwsYKgICVwYTiAStHYlPkASBGAShF4dygUIH Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Apr 2012 08:16:04 +0930 Subject: Re: RA "requires" DHCPv6 ? From: Karl Auer To: "ipv6@ietf.org" In-Reply-To: <4F775E55.3050905@si6networks.com> References: <1333148248.2624.187.camel@karl> <4F76F41C.1000904@si6networks.com> <1333199575.11943.16.camel@karl> <4F775E55.3050905@si6networks.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TgQKnYcvMi2v+lh2+HID" Date: Sun, 01 Apr 2012 08:46:02 +1000 Message-ID: <1333233962.11943.30.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 22:46:18 -0000 --=-TgQKnYcvMi2v+lh2+HID Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-03-31 at 21:43 +0200, Fernando Gont wrote: > > Or you could use one's statically assigned address.=20 >=20 > Oh, yeah. And you could have opted to not send the RS in the first > place... and what? :-) Um, I'm not sure why we're arguing. I'll still see unsolicited RAs at regular intervals, and I'll see RAs sent because of other hosts' RSes. Also, the RA contains lots of useful stuff even if I am not doing DHCPv6 - for example if I want to do SLAAC I'll still be sending an RS. I don't think my question was stupid. I'm sorry you do. > -- However, particularly in the case in which the local router wants > you to use DHCPv6, they could easily block addresses that have not > been leased by the DHCPv6 server. SO, at the end of the day, you're at > its mercy. Absolutely. The question was just whether or not a host was *required* "O" flags and do DHCPv6, not whether it would be practical or appropriate to do so. > We were assuming the "regime" was controlling the local link. If they > do, its up to them whether there are other routers on the link and/or > whether RAs are allowed to flow on that link. My question was unrelated to the discussion about "the regime". That's why I started a new thread with a new subject line, and quoted only that exact part of your statement where you said "requires you to do DHCPv6".=20 And I was not saying you were wrong - I was seeking clarification (from you or anyone), because IMHO it is not clear from the RFCs whether a host SHOULD or MUST honour the "M" and "O" flags (obviously it MAY :-).=20 Regards, K. --=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 --=-TgQKnYcvMi2v+lh2+HID Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk93iSQACgkQFpl7eE7uYBdrrwD/eb30hL3TAkUgb83fsh32kajh en4GmY4/r1WTg924RukA+gLZ+AUuMQKQXSIyAhGHfGRoqfHXHTlHbqjgJ64jvMTb =zL/g -----END PGP SIGNATURE----- --=-TgQKnYcvMi2v+lh2+HID--