From fgont@si6networks.com Sun Apr 1 05:57: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 CD73C21F962F for ; Sun, 1 Apr 2012 05:57:43 -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 ip0MjLjM-dPb for ; Sun, 1 Apr 2012 05:57:43 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 111F321F99C4 for ; Sun, 1 Apr 2012 05:57:43 -0700 (PDT) Received: from llagny-156-34-49-113.w217-128.abo.wanadoo.fr ([217.128.158.113] helo=[192.168.101.212]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SEKLT-0000GN-4x; Sun, 01 Apr 2012 14:57:23 +0200 Message-ID: <4F7850B9.3050504@si6networks.com> Date: Sun, 01 Apr 2012 14:57: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: Karl Auer Subject: Re: RA "requires" DHCPv6 ? References: <1333148248.2624.187.camel@karl> <4F76F41C.1000904@si6networks.com> <1333199575.11943.16.camel@karl> <4F775E55.3050905@si6networks.com> <1333233962.11943.30.camel@karl> In-Reply-To: <1333233962.11943.30.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: Sun, 01 Apr 2012 12:57:43 -0000 On 04/01/2012 12:46 AM, Karl Auer wrote: > On Sat, 2012-03-31 at 21:43 +0200, Fernando Gont wrote: >>> 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? :-) > > 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. I'm not saying that your question is stupid. I'm just saying that regardless of whether there's a SHOULD/MUST in the RFCs regarding doing DHCPv6, truth is that you should be prepared to do it, because if the local router wants you to do DHCPv6, you essentially have no option. >> -- 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. Well, if you mean "required" in the sense of MUST, then probably not. But if you mean "required" as in "do you need to do DHCPv6 to get Internet connectivity?", then the answer is "Most likely, Yes". > 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 :-). I should double-check that. But if the RA has the "M" bit, then at least in that case you should do DHCPv6, even if the RFCs do not say so. If there's no "MUST" or "SHOULD" for that (which I don't recall of the top of my head), I guess that MUST/SHOULD has more to do with whether there's a formal requirement for every host to implement DHCPv6, than anything else. BUt then, as with the requirement to implement IPsec, that's, IMO, mostly "words on paper". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dthaler@microsoft.com Mon Apr 2 16:44: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 E10E121F865C for ; Mon, 2 Apr 2012 16:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-1.501, 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 VBh4JAVqQJn3 for ; Mon, 2 Apr 2012 16:44:18 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1B82921F85BD for ; Mon, 2 Apr 2012 16:44:17 -0700 (PDT) Received: from mail64-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Apr 2012 23:44:17 +0000 Received: from mail64-ch1 (localhost [127.0.0.1]) by mail64-ch1-R.bigfish.com (Postfix) with ESMTP id 5A1101E0371; Mon, 2 Apr 2012 23:44:17 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic85fh98dKzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25h) 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 (mail64-ch1: 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 mail64-ch1 (localhost.localdomain [127.0.0.1]) by mail64-ch1 (MessageSwitch) id 1333410254467378_19573; Mon, 2 Apr 2012 23:44:14 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail64-ch1.bigfish.com (Postfix) with ESMTP id 647E1440062; Mon, 2 Apr 2012 23:44:14 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Apr 2012 23:44:13 +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; Mon, 2 Apr 2012 23:43:57 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Mon, 2 Apr 2012 16:43:57 -0700 From: Dave Thaler To: Ray Hunter Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNC+wBSVlewb1jE0uYOWOUBxq41JZ+06CAgAlncxA= Date: Mon, 2 Apr 2012 23:43:57 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4F1217@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> In-Reply-To: <4F71F217.7000209@globis.net> 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: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B4F1217TK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com 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: Mon, 02 Apr 2012 23:44:21 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B4F1217TK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I prefer B, and this is what most existing implementations of RFC 3484 seem= to already do (i.e., they follow the MAY not the SHOULD) whenever privacy = addresses are enabled. I have yet to hear of an implementation of RFC 3484= that actually follows the SHOULD (A) rather than the MAY (B), but maybe so= meone on this list knows of one. To respond to Ray's "From the corporate World: option A as default, with lo= cal user controlled option to override": In the corporate world, one requirement we've heard is to disable privacy a= ddresses all together, not just depreference them. This is consistent with Brian Carpenter's res= ponse. As such, the Windows implementation of RFC 3484 has always preferred privac= y addresses when enabled, and lets the administrator enable/disable them. = Client OS's (Vista, Windows 7, etc.) have them enabled by default, but can= be disabled by an enterprise administrator either manually or across the e= nterprise via Group Policy. Server OS's (Server 2003, Server 2008, etc.) = have them disabled by default, but can be enabled by an administrator. -Dave From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray= Hunter Sent: Tuesday, March 27, 2012 10:00 AM To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses >From the corporate World: option A as default, with local user controlled o= ption to override. RFC3484 (which references RFC3041) "Temporary addresses" are a menace to fa= ult finding, audit, logging, firewall rules, filtering, QoS matching, confo= rmance: anywhere where an ACL or stable address is used today. Sure we shou= ldn'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 w= orried about privacy are more likely to be able to control their own partic= ular 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 privac= y addresses during the address selection process. RFC 3484 prefers public = addresses with the ability (MAY) of an implementation to reverse the prefer= ence. The suggestion has been made to reverse that preference in 3484bis (= prefer privacy addresses over public ones). Regardless, the document will a= llow 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 --_000_9B57C850BB53634CACEC56EF4853FF653B4F1217TK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I prefer B, and this is w= hat most existing implementations of RFC 3484 seem to already do (i.e., the= y follow the MAY not the SHOULD) whenever privacy addresses are enabled.  I have yet to hear of an implementation of RFC 3484 tha= t actually follows the SHOULD (A) rather than the MAY (B), but maybe someon= e on this list knows of one.

 <= /p>

To respond to Ray’s= “From the corporate World: option A as default, with local us= er controlled option to override”:

 

In the corporate world= , one requirement we’ve heard is to disable privacy addresses all tog= ether,

not just depreference = them.   This is consistent with Brian Carpenter’s response.=

 

As such, the Windows i= mplementation of RFC 3484 has always preferred privacy addresses when enabl= ed, and lets the administrator enable/disable them.   Client OS&#= 8217;s (Vista, Windows 7, etc.) have them enabled by default, but can be disabled by an enterprise administrator either manuall= y or across the enterprise via Group Policy.   Server OS’s = (Server 2003, Server 2008, etc.) have them disabled by default, but can be = enabled by an administrator.

 

-Dave

 <= /p>

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.o= rg] On Behalf Of Ray Hunter
Sent: Tuesday, March 27, 2012 10:00 AM
To: Brian Haberman
Cc: ipv6@ietf.org
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 me= nace to fault finding, audit, logging, firewall rules, filtering, QoS match= ing, conformance: anywhere where an ACL or stable address is used today. Su= re we shouldn't use fixed/stable IP literals, but we do. And in many cases there aren't any practical alternatives in to= day'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 circumst= ances).

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 w= orried about privacy are more likely to be able to control their own partic= ular machines to correctly override the "default off" setting tha= n a single corporate network manager is to be able to guarantee overriding a "default on" setting on 100% o= f 10000 machines attached to their network.

regards,
RayH

Brian Haberman wrote:

<div class=3D"moz-text-flowed">All, =
     The chairs would like to get a sense of the workin= g group on changing the current (defined 3484) model of preferring public a= ddresses 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 b= een made to reverse that preference in 3484bis (prefer privacy addresses ov= er public ones). Regardless, the document will allow implementers/users to = reverse the default preference.

     Please state your preference for one of the follow= ing 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

--_000_9B57C850BB53634CACEC56EF4853FF653B4F1217TK5EX14MBXW604w_-- From v6ops@globis.net Mon Apr 2 23:53: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 84ADF11E8073 for ; Mon, 2 Apr 2012 23:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 7qvVypQqxVwA for ; Mon, 2 Apr 2012 23:53:03 -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 45BE211E8072 for ; Mon, 2 Apr 2012 23:53:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 20120870130; Tue, 3 Apr 2012 08:53:01 +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 HeNiGVoH3C4W; Tue, 3 Apr 2012 08:52:53 +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 321B58700D7; Tue, 3 Apr 2012 08:52:53 +0200 (CEST) Message-ID: <4F7A9E44.6060905@globis.net> Date: Tue, 03 Apr 2012 08:52:52 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Dave Thaler Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <9B57C850BB53634CACEC56EF4853FF653B4F1217@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4F1217@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: multipart/alternative; boundary="------------080504030203070807070400" 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, 03 Apr 2012 06:53:05 -0000 This is a multi-part message in MIME format. --------------080504030203070807070400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I can also live with Brian Carpenter's response. > 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 > Windows may have got it pretty much right for allowing network operators to control privacy addresses, and turning them off by default at least on servers. But with all due respect, the control mechanism mentioned by Dave only covers machines that are members of a (proprietary) Active Directory domain: It does not cover guest LANs, outsourced services, other operating systems, nor Bring Your Own Device, which are all increasing trends in the corporate World. Network managers need that switch. Can anyone show me where that's defined in an RFC? regards, RayH Dave Thaler wrote: > > I prefer B, and this is what most existing implementations of RFC 3484 > seem to already do (i.e., they follow the MAY not the SHOULD) whenever > privacy addresses are enabled. I have yet to hear of an > implementation of RFC 3484 that actually follows the SHOULD (A) rather > than the MAY (B), but maybe someone on this list knows of one. > > To respond to Ray's "From the corporate World: option A as default, > with local user controlled option to override": > > In the corporate world, one requirement we've heard is to disable > privacy addresses all together, > > not just depreference them. This is consistent with Brian > Carpenter's response. > > As such, the Windows implementation of RFC 3484 has always preferred > privacy addresses when enabled, and lets the administrator > enable/disable them. Client OS's (Vista, Windows 7, etc.) have them > enabled by default, but can be disabled by an enterprise administrator > either manually or across the enterprise via Group Policy. Server > OS's (Server 2003, Server 2008, etc.) have them disabled by default, > but can be enabled by an administrator. > > -Dave > > *From:* ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] *On > Behalf Of *Ray Hunter > *Sent:* Tuesday, March 27, 2012 10:00 AM > *To:* Brian Haberman > *Cc:* ipv6@ietf.org > *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 > --------------080504030203070807070400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I can also live with Brian Carpenter's response.

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

Windows may have got it pretty much right for allowing network operators to control privacy addresses, and turning them off by default at least on servers. But with all due respect, the control mechanism mentioned by Dave only covers machines that are members of a (proprietary) Active Directory domain: It does not cover guest LANs, outsourced services, other operating systems, nor Bring Your Own Device, which are all increasing trends in the corporate World.

Network managers need that switch.

Can anyone show me where that's defined in an RFC?

regards,
RayH

Dave Thaler wrote:

I prefer B, and this is what most existing implementations of RFC 3484 seem to already do (i.e., they follow the MAY not the SHOULD) whenever privacy addresses are enabled.  I have yet to hear of an implementation of RFC 3484 that actually follows the SHOULD (A) rather than the MAY (B), but maybe someone on this list knows of one.

 

To respond to Ray’s “From the corporate World: option A as default, with local user controlled option to override”:

 

In the corporate world, one requirement we’ve heard is to disable privacy addresses all together,

not just depreference them.   This is consistent with Brian Carpenter’s response.

 

As such, the Windows implementation of RFC 3484 has always preferred privacy addresses when enabled, and lets the administrator enable/disable them.   Client OS’s (Vista, Windows 7, etc.) have them enabled by default, but can be disabled by an enterprise administrator either manually or across the enterprise via Group Policy.   Server OS’s (Server 2003, Server 2008, etc.) have them disabled by default, but can be enabled by an administrator.

 

-Dave

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray Hunter
Sent: Tuesday, March 27, 2012 10:00 AM
To: Brian Haberman
Cc: ipv6@ietf.org
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:

<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

--------------080504030203070807070400-- From fred@cisco.com Tue Apr 3 00:37: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 25FDA21F852B for ; Tue, 3 Apr 2012 00:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 NsajNyNVWBnI for ; Tue, 3 Apr 2012 00:37:41 -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 6C51521F855B for ; Tue, 3 Apr 2012 00:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=461; q=dns/txt; s=iport; t=1333438661; x=1334648261; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=YN51Qk/0N2J1wdE2w+gyQpD9/42bBSljpX+4uRn0t8Q=; b=buezdxy51AS1Q3+n5tBpzubMpe6Xdgc602WLxLHEOXvvaMNs0/KYPe8z 581G9es1cmeJAIJz1WBDKemkcMAJcAFUIQLLHXU3i2u3114sVv0rGreEV aLbA0K1CKAFd55bVBAwD0TqyCF5gIvzjxYftOqIvt6HMQ/5nnqVDLoiKr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI2oek+Q/khR/2dsb2JhbABCuAaBB4IJAQEBAwESARQTPwULCw44VwY1h2IFoCuXIJALYwSVYYVwiFeBaIJo X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="134104378" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2012 07:37:22 +0000 Received: from Freds-Computer.local (dhcp-10-55-88-88.cisco.com [10.55.88.88]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q337bL74016961; Tue, 3 Apr 2012 07:37:22 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 03 Apr 2012 08:37:22 +0100 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 03 Apr 2012 08:37:22 +0100 Subject: Re: [6man] Stable privacy addresses (upcoming rev) Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F761589.7090800@si6networks.com> Date: Tue, 3 Apr 2012 08:37:11 +0100 Message-Id: <9266DEAD-848B-4577-AF33-B4A34B049458@cisco.com> References: <4F7333F9.9090007@si6networks.com> <4F75AF50.5000308@globis.net> <4F760DC9.8090109@gmail.com> <4F761589.7090800@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: Tue, 03 Apr 2012 07:37:42 -0000 On Mar 30, 2012, at 9:20 PM, Fernando Gont 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. If they don't control the link, they can (as I'm told the Netherlands = does) require a daily upload of who used what address when.= From jinmei@isc.org Tue Apr 3 10:44: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 5739921F8608 for ; Tue, 3 Apr 2012 10:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] 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 AmmQm5HEV8yz for ; Tue, 3 Apr 2012 10:44:46 -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 D461E21F8606 for ; Tue, 3 Apr 2012 10:44:46 -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 14D69C9428; Tue, 3 Apr 2012 17:44:37 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (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 95EBA216C31; Tue, 3 Apr 2012 17:44:36 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Tue, 03 Apr 2012 10:44:35 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Dave Thaler Subject: Re: 3484bis and privacy addresses In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4F1217@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <9B57C850BB53634CACEC56EF4853FF653B4F1217@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Ray Hunter , 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, 03 Apr 2012 17:44:47 -0000 At Mon, 2 Apr 2012 23:43:57 +0000, Dave Thaler wrote: > I prefer B, and this is what most existing implementations of RFC 3484 seem to already do (i.e., they follow the MAY not the SHOULD) whenever privacy addresses are enabled. I have yet to hear of an implementation of RFC 3484 that actually follows the SHOULD (A) rather than the MAY (B), but maybe someone on this list knows of one. When we first implemented RFC3484 for BSD variants at the KAME project we followed the SHOULD and preferred public (non temporary) addresses by default. From a quick look it doesn't change, e.g., in the most recent version of FreeBSD: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_src.c?rev=1.87;content-type=text%2Fx-cvsweb-markup /* * Rule 7: Prefer public addresses. * We allow users to reverse the logic by configuring * a sysctl variable, so that privacy conscious users can * always prefer temporary addresses. */ --- JINMEI, Tatuya Internet Systems Consortium, Inc. From jhw@apple.com Tue Apr 3 15:50: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 712E011E809D for ; Tue, 3 Apr 2012 15:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.203 X-Spam-Level: X-Spam-Status: No, score=-109.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 lFjie36AD+g0 for ; Tue, 3 Apr 2012 15:50:29 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id DFDC711E8086 for ; Tue, 3 Apr 2012 15:50:29 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M1X00MRNE3XBU01@mail-out.apple.com> for ipv6@ietf.org; Tue, 03 Apr 2012 15:50:29 -0700 (PDT) X-AuditID: 11807136-b7f376d000001394-02-4f7b7eb5f518 Received: from [17.151.73.147] (Unknown_Domain [17.151.73.147]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 5A.89.05012.5BE7B7F4; Tue, 03 Apr 2012 15:50:29 -0700 (PDT) Subject: Re: 3484bis and privacy addresses From: james woodyatt In-reply-to: Date: Tue, 03 Apr 2012 15:50:28 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <9B57C850BB53634CACEC56EF4853FF653B4F1217@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1444) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42IRnO45WXdrXbW/wbF33BYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqyzTYwFK/kq2n6eZGpg3MDdxcjJISFgInH6wjJ2CFtM4sK9 9WxdjFwcQgJTmSQu3LjJCJJgFlCX+DPvEjOIzSugJ3H82lsmEFtYQEti6aqTYDabgIrEt8t3 wWxOAW2JZ7OOs3YxcnCwAMU3tCpAjNGWWLbwNdQYG4kT61uZIHadZZQ4e/c1C0hCREBQYvuD HywQB8lKnD16gnECI98sJGfMQnLGLCRzFzAyr2IULErNSaw0NNVLLCjISdVLzs/dxAgKpYZC sx2MO/7KHWIU4GBU4uFddarSX4g1say4MvcQowQHs5IIb29Qtb8Qb0piZVVqUX58UWlOavEh RmkOFiVx3nDtKn8hgfTEktTs1NSC1CKYLBMHp1QDY+XGR6xfjz/SaT50oWSJ2K0SQ9kfC9f8 tv3mHLHVPuxz9sZJzaax9k2TTLzZm+Kb9395ka95YWeaX+tk1SOvnk3wt3rl7v9G8lCOZsvO mVFZlrc3le2RFSsq2rVqWeiuLv39MqaFnl7bDd4zpO8rnF7ilG25RelHwDL53MIruV1OaUnT +892KrEUZyQaajEXFScCAGXK2pQhAgAA 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, 03 Apr 2012 22:50:30 -0000 On Apr 3, 2012, at 10:44 , JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93= =89 wrote: > At Mon, 2 Apr 2012 23:43:57 +0000, Dave Thaler = wrote: >>=20 >> I prefer B, and this is what most existing implementations of RFC = 3484 seem to already do (i.e., they follow the MAY not the SHOULD) = whenever privacy addresses are enabled. I have yet to hear of an = implementation of RFC 3484 that actually follows the SHOULD (A) rather = than the MAY (B), but maybe someone on this list knows of one. >=20 > When we first implemented RFC3484 for BSD variants at the KAME project > we followed the SHOULD and preferred public (non temporary) addresses > by default. =46rom a quick look it doesn't change, e.g., in the most > recent version of FreeBSD: > = http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/in6_src.c?rev=3D1.8= 7;content-type=3Dtext%2Fx-cvsweb-markup > /* > * Rule 7: Prefer public addresses. > * We allow users to reverse the logic by configuring > * a sysctl variable, so that privacy conscious users = can > * always prefer temporary addresses. > */ It may be worth noting here what I see on my Mac OS X 10.7 system at = home (which exhibits basically the same behavior as recent iOS releases = do): zeece ~ 508$ sysctl net.inet6.ip6 | egrep tempaddr net.inet6.ip6.use_tempaddr: 1 net.inet6.ip6.prefer_tempaddr: 1 In other words, it deliberately diverges from the "SHOULD" = recommendation here in RFC 3484, despite having been derived from the = KAME stack which had zeroes as the default values here, not ones. I = have yet to see a persuasive reason to conform strictly to the = recommended behavior. -- james woodyatt member of technical staff, core os networking From dominik.elsbroek@gmail.com Wed Apr 4 06:55:04 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 D911821F8795 for ; Wed, 4 Apr 2012 06:55:04 -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 q4sMH+V2qRCs for ; Wed, 4 Apr 2012 06:55:04 -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 59C5E21F8470 for ; Wed, 4 Apr 2012 06:55:04 -0700 (PDT) Received: by ggmi1 with SMTP id i1so159054ggm.31 for ; Wed, 04 Apr 2012 06:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4DMbw4E7dbnHBYNsgxyQF2xcUgSrhyHRc/Sk35/x1Po=; b=jDP15O9CGMXu+I4KFWfCbw5xFt/uXv+/Qrxbs+SnWo3IfugOqgv4Ai39oRCBn0UAeI W6Xvp97kdXp6BTIQAI8Z3HGgzE1QKmg77MJcIhVToIyxR/PHIuQS+Fvn99+oH5sV+w+8 gbygWzGd92+HWJsC+ZpNv+IAzSzeQLecB/wNKUlwLrKKqcTJEwt4FZwj6DLgQTqWooUP /CxX1s5qKnKnZdr3VLYcDLu2QiKt4boDZPoVXHdAOJ/GxZa94xQtf9cxnWDIaJipVeGq SkpJ4ptpHiV/MoCaiY4Wk04T+Ynaog5qU4yO9KaSk8SL0KoojW7d6sJhyOT9LcsAbQQt IQnw== MIME-Version: 1.0 Received: by 10.50.217.137 with SMTP id oy9mr1654424igc.31.1333547703305; Wed, 04 Apr 2012 06:55:03 -0700 (PDT) Received: by 10.50.33.74 with HTTP; Wed, 4 Apr 2012 06:55:03 -0700 (PDT) Date: Wed, 4 Apr 2012 15:55:03 +0200 Message-ID: Subject: DHCPv6 address used when M or O bit is set From: Dominik Elsbroek 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, 04 Apr 2012 13:55:04 -0000 Hi all, the discussion on the mailing list titled "RA "requires" DHCPv6 ?" is quite confusingto me since RFC 4862 states, the flags M and O are removed, but not deprecated. They don't even longer exist, but still exist? But what should a client do now? Is a client asked to request further information from a DHCPv6 server if it receives a router advertisement with these bits set? And if, which address should the client use? The link local FF02:0:0:0:0:0:1:2 (All-dhcp-agents) or the site-local FF05:0:0:0:0:0:1:3 (All-dhcp-servers)? Kind regards, Dominik From fgont@si6networks.com Wed Apr 4 07:12: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 E260821F8711 for ; Wed, 4 Apr 2012 07:12:19 -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 1N2waPpMbo0C for ; Wed, 4 Apr 2012 07:12:19 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0C21F8575 for ; Wed, 4 Apr 2012 07:12:19 -0700 (PDT) Received: from static-qvn-qvu-163098.business.bouyguestelecom.com ([89.81.163.98] helo=[192.168.101.214]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SFQwb-0004IF-1A; Wed, 04 Apr 2012 16:12:17 +0200 Message-ID: <4F7C56BE.6010507@si6networks.com> Date: Wed, 04 Apr 2012 16:12: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: Dominik Elsbroek Subject: Re: DHCPv6 address used when M or O bit is set References: 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: Wed, 04 Apr 2012 14:12:20 -0000 Hi, Dominik, On 04/04/2012 03:55 PM, Dominik Elsbroek wrote: > the discussion on the mailing list titled "RA "requires" DHCPv6 ?" is > quite confusingto me since RFC 4862 states, the flags M and O are > removed, but not deprecated. What's removed is the corresponding text, not the bits. See page 19 of RFC 4861: the bits are still there. > They don't even longer exist, but still > exist? I'm curious about why the corresponding text was removed. In particular when at the time (2007) the DNS options was not yet widely implemented, and hence you *needed* DHCPv6 to learn the addresses of recursive DNS servers dynamically. 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 Wed Apr 4 07:14: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 3C42621F881F for ; Wed, 4 Apr 2012 07:14:30 -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 oCKH1abLukKT for ; Wed, 4 Apr 2012 07:14:29 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BA5C021F881E for ; Wed, 4 Apr 2012 07:14:29 -0700 (PDT) Received: from static-qvn-qvu-163098.business.bouyguestelecom.com ([89.81.163.98] helo=[192.168.101.214]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SFQyf-0004Iw-2x; Wed, 04 Apr 2012 16:14:25 +0200 Message-ID: <4F7C570D.8070805@si6networks.com> Date: Wed, 04 Apr 2012 16:13:33 +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: Fred Baker 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> <9266DEAD-848B-4577-AF33-B4A34B049458@cisco.com> In-Reply-To: <9266DEAD-848B-4577-AF33-B4A34B049458@cisco.com> 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: Wed, 04 Apr 2012 14:14:30 -0000 On 04/03/2012 09:37 AM, Fred Baker 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. > > If they don't control the link, they can (as I'm told the Netherlands > does) require a daily upload of who used what address when. Well, if they are able to require that, in practice they still control the link. :-) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dominik.elsbroek@gmail.com Wed Apr 4 07:38: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 74B7821F8657 for ; Wed, 4 Apr 2012 07:38:47 -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 H49bR-9D3veT for ; Wed, 4 Apr 2012 07:38: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 4332221F86B0 for ; Wed, 4 Apr 2012 07:38:46 -0700 (PDT) Received: by iazz13 with SMTP id z13so526808iaz.31 for ; Wed, 04 Apr 2012 07:38:46 -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=LisaTDjUXDEiMCv2XT3RL6gvbOJ9aipZN5cwQgmMtdY=; b=ol4RTH5+LMuBh9RYZ0+VbeYXBm0Nc9vcqZubSFKNxdzPbayK28TzsNDguOSXuwnchj iqjVj5pRrl+jl25YXQz7cWi3lpONXBlsOfGUhLCHEIvNWQJKC6k7qza/ly0pqDuAvqar tuuMyQY8PfO24KM/gQaMGeyD2LGLH83KcRCKX857tHTMhO5FPqrWTk3GdwFd5d16MUBw 2sPTflYLrLxJBqcD+2KdkECJeIEKeNxVpzjhZDbHW7QkAMLhKuuB1mlb7RhvjCCKMoLa DpR2iARKDEDCOIH6l4wd6m7ulVDNNpy4mw94V+2f9oXctdIyKCzOlGBA/ym7i+wkZ9we dkhQ== MIME-Version: 1.0 Received: by 10.50.104.133 with SMTP id ge5mr1795875igb.21.1333550325954; Wed, 04 Apr 2012 07:38:45 -0700 (PDT) Received: by 10.50.33.74 with HTTP; Wed, 4 Apr 2012 07:38:45 -0700 (PDT) In-Reply-To: <4F7C56BE.6010507@si6networks.com> References: <4F7C56BE.6010507@si6networks.com> Date: Wed, 4 Apr 2012 16:38:45 +0200 Message-ID: Subject: Re: DHCPv6 address used when M or O bit is set 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: Wed, 04 Apr 2012 14:38:47 -0000 Hi Fernando, > What's removed is the corresponding text, not the bits. See page 19 of > RFC 4861: the bits are still there. > In RFC4862, Appendix C there is one point: Removed the text regarding the M and O flags, considering the maturity of implementations and operational experiences. ManagedFlag and OtherConfigFlag were removed accordingly. (Note that this change does not mean the use of these flags is deprecated.) Not sure how to interprete this. Perhapts I am just missing a link, but M and O flag in RFC 4861 doesn't tell how to do SLAAC, e.g. when the nameserver should be determined by DHCPv6-server. > >> They don't even longer exist, but still >> exist? > > I'm curious about why the corresponding text was removed. In particular > when at the time (2007) the DNS options was not yet widely implemented, > and hence you *needed* DHCPv6 to learn the addresses of recursive DNS > servers dynamically. > I am still very curious which address a client should use, if the O or M flag is set, to find a DHCPv6 server. Cheers, Dominik From jeremy.duncan@salientfed.com Wed Apr 4 07:50:58 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 9C7EC21F87F4 for ; Wed, 4 Apr 2012 07:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.157 X-Spam-Level: X-Spam-Status: No, score=0.157 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] 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 pAkePZZA-83R for ; Wed, 4 Apr 2012 07:50:57 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id B8E5521F87EB for ; Wed, 4 Apr 2012 07:50:57 -0700 (PDT) Received: from mail53-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Wed, 4 Apr 2012 14:50:57 +0000 Received: from mail53-ch1 (localhost [127.0.0.1]) by mail53-ch1-R.bigfish.com (Postfix) with ESMTP id D1CD93600F8; Wed, 4 Apr 2012 14:50:56 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzz8275bhz2dh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:65.55.171.153; KIP:(null); UIP:(null); IPV:NLI; H:VA3DIAHUB068.RED001.local; RD:smtp801.microsoftonline.com; EFVD:NLI Received: from mail53-ch1 (localhost.localdomain [127.0.0.1]) by mail53-ch1 (MessageSwitch) id 1333551054523980_29472; Wed, 4 Apr 2012 14:50:54 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail53-ch1.bigfish.com (Postfix) with ESMTP id 7A4B32C004D; Wed, 4 Apr 2012 14:50:54 +0000 (UTC) Received: from VA3DIAHUB068.RED001.local (65.55.171.153) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 4 Apr 2012 14:50:52 +0000 Received: from VA3DIAXVS7F1.RED001.local ([10.16.21.132]) by VA3DIAHUB068.RED001.local ([10.8.230.162]) with mapi; Wed, 4 Apr 2012 07:50:51 -0700 From: "Duncan, Jeremy" To: Dominik Elsbroek , Fernando Gont Date: Wed, 4 Apr 2012 07:50:05 -0700 Subject: RE: DHCPv6 address used when M or O bit is set Thread-Topic: DHCPv6 address used when M or O bit is set Thread-Index: Ac0ScK75lu9TKRx1SN2Mp8k/gHxPPAAAYoN9 Message-ID: <236CD5C26786804285D413A8021D8A34043B22E7CF@VA3DIAXVS7F1.RED001.local> References: <4F7C56BE.6010507@si6networks.com>, 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="us-ascii" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: salientfed.com X-Mailman-Approved-At: Wed, 04 Apr 2012 08:00:38 -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: Wed, 04 Apr 2012 14:52:29 -0000 LS0tSSBhbSBzdGlsbCB2ZXJ5IGN1cmlvdXMgd2hpY2ggYWRkcmVzcyBhIGNsaWVudCBzaG91bGQg dXNlLCBpZiB0aGUgTyBvcg0KTSBmbGFnIGlzIHNldCwgdG8gZmluZCBhIERIQ1B2NiBzZXJ2ZXIu DQoNCg0KVGhlIHNlcnZlciBsaXN0ZW5zIG9uIGZmMDI6OjE6MiBhbmQvb3IgZmYwMjo6MTozDQoN Cg0KDQowMTAxMDAxMTAxMTAwMTAxMDExMDExMDEwMTExMDAwMDAxMTAwMTAxMDExMTAwMTAwMDEw MDAwMDAxMDAwMTEwMDExMDEwMDENCg0KSmVyZW15IER1bmNhbg0KU2VuaW9yIERpcmVjdG9yLCBJ UHY2IE5ldHdvcmsgQXJjaGl0ZWN0IFNhbGllbnQgRmVkZXJhbCBTb2x1dGlvbnMsIEluYy4NCihO b3cgaW5jbHVkaW5nIFNHSVMgJiBDb21tYW5kIEluZm9ybWF0aW9uIEluYy4pDQo0MDAwIExlZ2F0 byBSb2FkLCBTdWl0ZSA2MDAgRmFpcmZheCwgVkEgMjIwMzMNCkdvb2dsZSBWb2ljZTogIDU0MC40 NDAuMTE5Mw0KamVyZW15LmR1bmNhbkBzYWxpZW50ZmVkLmNvbQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCg== From bob.hinden@gmail.com Wed Apr 4 08:08: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 6602221F86AD for ; Wed, 4 Apr 2012 08:08:55 -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 PbGrflkLJgDh for ; Wed, 4 Apr 2012 08:08:54 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id ACFB821F8569 for ; Wed, 4 Apr 2012 08:08:54 -0700 (PDT) Received: by dady13 with SMTP id y13so536213dad.27 for ; Wed, 04 Apr 2012 08:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=I63SW+dmWMH+WqQgZ4SJAAun+KvbyQvlR9tzgm3bdtI=; b=b/1VH6CyWNnOF+9ZOPmnGCxyTgBzmXzcUV7KU/Ieo0OvxTrf1pDvQQcsdNOZYk52GR wvyYuW9JvJVy9GNgskW8NjKnqf1g5oUy49OgnR8ED6GHTSG6Kj7RE3pEainxeYS7rKEn mimJQX6OlLbprCWYFuVgJZwQo4m4Ie1wphhf59747ZOpvTu6uPSWaDqkIqdVagv7rsAj QCH2S9FuG4OiTpSYgpkCawLPxNAR9EjOWEHjHuBci88lCXwEHTlXFF72drg6jgzPGKi/ JbxybjHz8ZTXrKewoS74wy9Ni/yWWYkdD3XjFpZ6OfIL9M+M+mduCX5fTXA6/52L9vGB kS7A== Received: by 10.68.203.4 with SMTP id km4mr37865863pbc.53.1333552127572; Wed, 04 Apr 2012 08:08:47 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id o9sm809161pbe.60.2012.04.04.08.08.46 (version=SSLv3 cipher=OTHER); Wed, 04 Apr 2012 08:08:46 -0700 (PDT) Subject: Re: DHCPv6 address used when M or O bit is set Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Wed, 4 Apr 2012 08:08:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04C9057D-F455-4B31-AD9C-8488042CE572@gmail.com> References: To: Dominik Elsbroek X-Mailer: Apple Mail (2.1084) Cc: 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: Wed, 04 Apr 2012 15:08:55 -0000 Dominik, The M and O flags are defined in RFC4861. They are not removed (or = deprecated). Bob On Apr 4, 2012, at 6:55 AM, Dominik Elsbroek wrote: > Hi all, >=20 > the discussion on the mailing list titled "RA "requires" DHCPv6 ?" is > quite confusingto me since RFC 4862 states, the flags M and O are > removed, but not deprecated. They don't even longer exist, but still > exist? >=20 > But what should a client do now? Is a client asked to request further > information from a DHCPv6 server if it receives a router advertisement > with these bits set? And if, which address should the client use? The > link local FF02:0:0:0:0:0:1:2 (All-dhcp-agents) or the site-local > FF05:0:0:0:0:0:1:3 (All-dhcp-servers)? >=20 > Kind regards, > Dominik > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Wed Apr 4 08:43: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 4DDAC21F881C for ; Wed, 4 Apr 2012 08:43:09 -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 rAAi0D0x6+dw for ; Wed, 4 Apr 2012 08:43:08 -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 2BB4D21F85DD for ; Wed, 4 Apr 2012 08:43:08 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so406688pbb.31 for ; Wed, 04 Apr 2012 08:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jkzUvyA2N8429aj7rATxUyl7AO0XQfSgCUHKwqaURK4=; b=x+cywDiM6UubmI3wdEqZTWZA436Q8pkodmsJbLExZigSKyEVZAtiQnrAgXOV/i1M+H J6oC+mHyFQ+2vSHGMoURT2iuQ4PmEGERVeChC4P+6SwuRSkAyBIxKeNS3dIZnglE7DMV 0ikLn+E/Znvs6ashncinFDR8HJl7U2K6jzsszeu9parpHVV1KKCBQq2EvAnpixWP0AKg NSiO5KREpzzwx8wQ6YywGWerpkWzg0ezioDBwiWTbzTQpRMzlwqODNcRhFcz4e04JJj/ 8TbWd5XevnR8tGZ6DnGugeeuKPde9qNMmBtOQ1dwg68/8m/pVuu4csTeD4w3W9hicxZn FQUA== Received: by 10.68.226.5 with SMTP id ro5mr37896392pbc.138.1333554174204; Wed, 04 Apr 2012 08:42:54 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id h10sm861870pbh.69.2012.04.04.08.42.52 (version=SSLv3 cipher=OTHER); Wed, 04 Apr 2012 08:42:53 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) Subject: Fwd: IPv6 over Bluetooth Low-Energy (BT-LE): Please review draft-ietf-6lowpan-btle-06.txt From: Bob Hinden Date: Wed, 4 Apr 2012 08:42:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "ipv6@ietf.org Mailing List" X-Mailer: Apple Mail (2.1084) Cc: 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: Wed, 04 Apr 2012 15:43:09 -0000 Please review. Quoting Carsten: > ( > Bluetooth Low-Energy is also known as Bluetooth Smart, a part of = Bluetooth 4. =20 > The iPhone 4S has it. Zillions of IPv6 packets will flow over it. > So you really want to review this draft! > ) Bob Begin forwarded message: > From: Carsten Bormann > Date: March 30, 2012 5:43:05 AM PDT > To: int-area@ietf.org > Subject: [Int-area] Fwd: IPv6 over Bluetooth Low-Energy (BT-LE): = Please review draft-ietf-6lowpan-btle-06.txt >=20 > From: Carsten Bormann > Subject: IPv6 over Bluetooth Low-Energy (BT-LE): Please review = draft-ietf-6lowpan-btle-06.txt > Date: March 30, 2012 14:35:37 +0200 > To: 6lowpan@ietf.org, intarea@ietf.org >=20 > draft-ietf-6lowpan-btle has passed working-group last call in the = 6LoWPAN Working Group in January. > While preparing IESG submission, I noticed a few more things that = needed to be taken care of. > This led to draft-ietf-6lowpan-btle-06.txt, which should have all = these items fixed. > However, I believe the draft would benefit from a bit more eyeballs = before I send it on to the IESG. >=20 > -- could you implement IPv6 over BT-LE from this draft (and its = normative references),=20 > or is anything that would be important for interoperability left = unspecified? > -- general comments about draft quality and the technical decisions = taken are also welcome. >=20 > I'm asking for feedback from the intarea working group as well as the = 6lowpan working group. > The draft is only 12 pages, so this can be done quickly. > Please reply until Friday, April 13, 2012. >=20 > ( > Bluetooth Low-Energy is also known as Bluetooth Smart, a part of = Bluetooth 4. =20 > The iPhone 4S has it. Zillions of IPv6 packets will flow over it. > So you really want to review this draft! > ) >=20 > Gr=FC=DFe, Carsten >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From suresh.krishnan@ericsson.com Wed Apr 4 08:51: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 A1E4B21F86B2 for ; Wed, 4 Apr 2012 08:51:46 -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 TSjjZwqB8Dkw for ; Wed, 4 Apr 2012 08:51:45 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1121F86A7 for ; Wed, 4 Apr 2012 08:51:45 -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 q34FpK8R003591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Apr 2012 10:51:43 -0500 Received: from [142.133.112.66] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 11:51:33 -0400 Message-ID: <4F7C6E05.9010603@ericsson.com> Date: Wed, 4 Apr 2012 11:51:33 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "Duncan, Jeremy" Subject: Re: DHCPv6 address used when M or O bit is set References: <4F7C56BE.6010507@si6networks.com>, <236CD5C26786804285D413A8021D8A34043B22E7CF@VA3DIAXVS7F1.RED001.local> In-Reply-To: <236CD5C26786804285D413A8021D8A34043B22E7CF@VA3DIAXVS7F1.RED001.local> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" 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: Wed, 04 Apr 2012 15:51:46 -0000 Hi Jeremy, The DHCPv6 client on a host will use its link-local address as the source address and ff02::1:2 as the destination address. Cheers Suresh On 04/04/2012 10:50 AM, Duncan, Jeremy wrote: > ---I am still very curious which address a client should use, if the O or > M flag is set, to find a DHCPv6 server. > > > The server listens on ff02::1:2 and/or ff02::1:3 > > > > 010100110110010101101101011100000110010101110010001000000100011001101001 > > Jeremy Duncan > Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc. > (Now including SGIS & Command Information Inc.) > 4000 Legato Road, Suite 600 Fairfax, VA 22033 > Google Voice: 540.440.1193 > jeremy.duncan@salientfed.com > > ________________________________________ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jinmei@isc.org Wed Apr 4 13:53: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 ADF4211E810B for ; Wed, 4 Apr 2012 13:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, 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 MOENv6U06YrO for ; Wed, 4 Apr 2012 13:53:07 -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 CC5E211E8099 for ; Wed, 4 Apr 2012 13:53:05 -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 4ED335F9899; Wed, 4 Apr 2012 20:53:00 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:29b5:717e:cb39:df80]) (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 6CB87216C33; Wed, 4 Apr 2012 20:52:58 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Wed, 04 Apr 2012 13:52:57 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Dominik Elsbroek Subject: Re: DHCPv6 address used when M or O bit is set In-Reply-To: References: <4F7C56BE.6010507@si6networks.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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: Wed, 04 Apr 2012 20:53:07 -0000 At Wed, 4 Apr 2012 16:38:45 +0200, Dominik Elsbroek wrote: > > What's removed is the corresponding text, not the bits. See page 19 of > > RFC 4861: the bits are still there. > > In RFC4862, Appendix C there is one point: > > Removed the text regarding the M and O flags, considering the > maturity of implementations and operational experiences. > ManagedFlag and OtherConfigFlag were removed accordingly. (Note > that this change does not mean the use of these flags is > deprecated.) > > Not sure how to interprete this. Perhapts I am just missing a link, > but M and O flag in RFC 4861 doesn't tell how to do SLAAC, e.g. when > the nameserver should be determined by DHCPv6-server. As clearly noted, "removed" doesn't mean these flags were deprecated in the protocol. They were simply removed from the RFC4862 text as an out-of-scope item for that particular RFC (and the assumption was they should be standardized in other documents). --- JINMEI, Tatuya Internet Systems Consortium, Inc. From kauer@biplane.com.au Wed Apr 4 15:41: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 E7A7521F84FF for ; Wed, 4 Apr 2012 15:41:51 -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 XYCNpu9Ep4Ki for ; Wed, 4 Apr 2012 15:41:51 -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 8189521F84F4 for ; Wed, 4 Apr 2012 15:41:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBANrMfE+WZX+7/2dsb2JhbAANOIVNtW4BAQEEI2YLGCoCAlcZsESRTo0rggyBGAShGYdz Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.204]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 05 Apr 2012 08:11:45 +0930 Subject: Re: DHCPv6 address used when M or O bit is set From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F7C56BE.6010507@si6networks.com> References: <4F7C56BE.6010507@si6networks.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1+KZZxJrI1uEvVbRsZ/e" Date: Thu, 05 Apr 2012 08:41:38 +1000 Message-ID: <1333579298.11943.532.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: Wed, 04 Apr 2012 22:41:52 -0000 --=-1+KZZxJrI1uEvVbRsZ/e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-04-04 at 16:12 +0200, Fernando Gont wrote: > I'm curious about why the corresponding text was removed. In particular > when at the time (2007) the DNS options was not yet widely implemented, > and hence you *needed* DHCPv6 to learn the addresses of recursive DNS > servers dynamically. Me too! The RFC4862 says "Removed the text regarding the M and O flags, considering the maturity of implementations and operational experiences. ManagedFlag and OtherConfigFlag were removed accordingly. (Note that this change does not mean the use of these flags is deprecated.)" The only way I can interpret this is "people are doing whatever the hell they like with these flags, and some of those implementations are pretty well-established, so we are not going to try to define how the flags should be used because no matter what we say, it will conflict with the way someone out there is doing things. However, people should definitely still use these flags! We aren't taking them away, we're just refusing to define how they should be used." It seems a strange thing to say, so maybe my interpretation is wrong :-) 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 --=-1+KZZxJrI1uEvVbRsZ/e 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) iF4EABEIAAYFAk98zhwACgkQFpl7eE7uYBfiIwEAodmRAP7SP7NT0p+a+5pgNSa5 aaB2AKyWdFD8MU3yMBAA/jC1d8SV1Cn7EsTOyw54RBHy2wpFI3HJzDdYPJS9LIX7 =Q45K -----END PGP SIGNATURE----- --=-1+KZZxJrI1uEvVbRsZ/e-- From albert.e.manfredi@boeing.com Wed Apr 4 15:58: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 1A20511E80C5 for ; Wed, 4 Apr 2012 15:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 2S7RAdLJss4Q for ; Wed, 4 Apr 2012 15:58:48 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 327FF11E808C for ; Wed, 4 Apr 2012 15:58:48 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q34N080X022204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Apr 2012 18:00:10 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q34Mx0vq021113; Wed, 4 Apr 2012 17:59:00 -0500 (CDT) Received: from XCH-MWHT-02.mw.nos.boeing.com (xch-mwht-02.mw.nos.boeing.com [134.57.113.20]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q34Mx0Vl021108 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 4 Apr 2012 17:59:00 -0500 (CDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-02.mw.nos.boeing.com ([134.57.113.20]) with mapi; Wed, 4 Apr 2012 17:58:29 -0500 From: "Manfredi, Albert E" To: Karl Auer , "ipv6@ietf.org" Date: Wed, 4 Apr 2012 17:58:27 -0500 Subject: RE: DHCPv6 address used when M or O bit is set Thread-Topic: DHCPv6 address used when M or O bit is set Thread-Index: Ac0StCvDtFd14Uc3R2W4TpPMOgTY6AAAioUg Message-ID: References: <4F7C56BE.6010507@si6networks.com> <1333579298.11943.532.camel@karl> In-Reply-To: <1333579298.11943.532.camel@karl> 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, 04 Apr 2012 22:58:49 -0000 Q2FuIHdlIHZvdGUgdG8gaGF2ZSB5b3VyIGludGVycHJldGF0aW9uIHBhc3RlZCBpbnRvIFJGQyA0 ODYyYmlzPw0KDQpIb25lc3RseSwgdGhhdCBJIGdldCwgYXQgbGVhc3QuDQoNCkJlcnQNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthcmwgQXVlcg0KU2VudDog V2VkbmVzZGF5LCBBcHJpbCAwNCwgMjAxMiA2OjQyIFBNDQpUbzogaXB2NkBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IERIQ1B2NiBhZGRyZXNzIHVzZWQgd2hlbiBNIG9yIE8gYml0IGlzIHNldA0KDQpP biBXZWQsIDIwMTItMDQtMDQgYXQgMTY6MTIgKzAyMDAsIEZlcm5hbmRvIEdvbnQgd3JvdGU6DQo+ IEknbSBjdXJpb3VzIGFib3V0IHdoeSB0aGUgY29ycmVzcG9uZGluZyB0ZXh0IHdhcyByZW1vdmVk LiBJbiBwYXJ0aWN1bGFyDQo+IHdoZW4gYXQgdGhlIHRpbWUgKDIwMDcpIHRoZSBETlMgb3B0aW9u cyB3YXMgbm90IHlldCB3aWRlbHkgaW1wbGVtZW50ZWQsDQo+IGFuZCBoZW5jZSB5b3UgKm5lZWRl ZCogREhDUHY2IHRvIGxlYXJuIHRoZSBhZGRyZXNzZXMgb2YgcmVjdXJzaXZlIEROUw0KPiBzZXJ2 ZXJzIGR5bmFtaWNhbGx5Lg0KDQpNZSB0b28hDQoNClRoZSBSRkM0ODYyIHNheXMNCg0KICAgIlJl bW92ZWQgdGhlIHRleHQgcmVnYXJkaW5nIHRoZSBNIGFuZCBPIGZsYWdzLCBjb25zaWRlcmluZyB0 aGUNCiAgICBtYXR1cml0eSBvZiBpbXBsZW1lbnRhdGlvbnMgYW5kIG9wZXJhdGlvbmFsIGV4cGVy aWVuY2VzLg0KICAgIE1hbmFnZWRGbGFnIGFuZCBPdGhlckNvbmZpZ0ZsYWcgd2VyZSByZW1vdmVk IGFjY29yZGluZ2x5LiAoTm90ZQ0KICAgIHRoYXQgdGhpcyBjaGFuZ2UgZG9lcyBub3QgbWVhbiB0 aGUgdXNlIG9mIHRoZXNlIGZsYWdzIGlzDQogICAgZGVwcmVjYXRlZC4pIg0KDQpUaGUgb25seSB3 YXkgSSBjYW4gaW50ZXJwcmV0IHRoaXMgaXMgInBlb3BsZSBhcmUgZG9pbmcgd2hhdGV2ZXIgdGhl IGhlbGwNCnRoZXkgbGlrZSB3aXRoIHRoZXNlIGZsYWdzLCBhbmQgc29tZSBvZiB0aG9zZSBpbXBs ZW1lbnRhdGlvbnMgYXJlIHByZXR0eQ0Kd2VsbC1lc3RhYmxpc2hlZCwgc28gd2UgYXJlIG5vdCBn b2luZyB0byB0cnkgdG8gZGVmaW5lIGhvdyB0aGUgZmxhZ3MNCnNob3VsZCBiZSB1c2VkIGJlY2F1 c2Ugbm8gbWF0dGVyIHdoYXQgd2Ugc2F5LCBpdCB3aWxsIGNvbmZsaWN0IHdpdGggdGhlDQp3YXkg c29tZW9uZSBvdXQgdGhlcmUgaXMgZG9pbmcgdGhpbmdzLiBIb3dldmVyLCBwZW9wbGUgc2hvdWxk IGRlZmluaXRlbHkNCnN0aWxsIHVzZSB0aGVzZSBmbGFncyEgV2UgYXJlbid0IHRha2luZyB0aGVt IGF3YXksIHdlJ3JlIGp1c3QgcmVmdXNpbmcNCnRvIGRlZmluZSBob3cgdGhleSBzaG91bGQgYmUg dXNlZC4iDQoNCkl0IHNlZW1zIGEgc3RyYW5nZSB0aGluZyB0byBzYXksIHNvIG1heWJlIG15IGlu dGVycHJldGF0aW9uIGlzIHdyb25nIDotKQ0KDQpSZWdhcmRzLCBLLg0KDQotLSANCn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+DQpLYXJsIEF1ZXIgKGthdWVyQGJpcGxhbmUuY29tLmF1KQ0KaHR0cDovL3d3dy5iaXBs YW5lLmNvbS5hdS9rYXVlcg0KDQpHUEcgZmluZ2VycHJpbnQ6IEFFMUQgNDg2OCA2NDIwIEFEOUEg QTY5OCA1MjUxIDE2OTkgN0I3OCA0RUVFIDYwMTcNCk9sZCBmaW5nZXJwcmludDogREE0MSA1MUIx IDE0ODEgMTZFMSBGN0UyIEIyRTkgMzAwNyAxNEVEIDU3MzYgRjY4Nw0K From tireddy@cisco.com Thu Apr 5 00:01: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 ADC9911E80F8 for ; Thu, 5 Apr 2012 00:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 1oZMLMIuuvDT for ; Thu, 5 Apr 2012 00:01:39 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 583D011E80AB for ; Thu, 5 Apr 2012 00:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=10136; q=dns/txt; s=iport; t=1333609298; x=1334818898; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Prx8nTOFJYivrW0wbXQUym+j4gTvnz+IVd2vV/PoWvM=; b=HoREjPc7qH9DhEdVg/a/H/vdO1RyU8uufHcPtYeSxN529J7mJHLp5orc A4OtH8BXJA9mvxT/o0wDSvQF6BAX4+swa0SChpy1sQ2j4UZxXZew28f4d bnYEB2Y2aAs1D4iD2/4Yv6v/gZ5oOdW+zFC31L+28s33YdvBnBWC8+Z8P g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAF5CfU9Io8UY/2dsb2JhbAA7AQmCRrcZggkBAQEEEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQBCgYCCBqHbAubQJ9kiwkBhGJjBIhXjiKNOYFpgm82gRYX X-IronPort-AV: E=Sophos;i="4.75,374,1330905600"; d="scan'208,217";a="9329834" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 05 Apr 2012 07:01:36 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3571ast016278; Thu, 5 Apr 2012 07:01:36 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 12:31:36 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: CB5M CQ0H ELko EVSi Ejxt G0BQ HtRS IXOw RY25 RzWc R7ow Wxtg Xlqh Ydil ZrKk aPKt; 3; YgByAGkAYQBuAEAAaQBuAG4AbwB2AGEAdABpAG8AbgBzAGwAYQBiAC4AbgBlAHQAOwBpAHAAdgA2AEAAaQBlAHQAZgAuAG8AcgBnADsAcgBhAHkALgBoAHUAbgB0AGUAcgBAAGcAbABvAGIAaQBzAC4AbgBlAHQA; Sosha1_v1; 7; {6906F1D6-4174-4B4B-A023-D68BE76C5779}; dABpAHIAZQBkAGQAeQBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 05 Apr 2012 06:59:12 GMT; UgBFADoAIAAzADQAOAA0AGIAaQBzACAAYQBuAGQAIABwAHIAaQB2AGEAYwB5ACAAYQBkAGQAcgBlAHMAcwBlAHMA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD12F9.F0E426DA" x-cr-puzzleid: {6906F1D6-4174-4B4B-A023-D68BE76C5779} Content-class: urn:content-classes:message Subject: RE: 3484bis and privacy addresses Date: Thu, 5 Apr 2012 12:29:12 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC0180796978B@XMB-BGL-41B.cisco.com> In-Reply-To: <4F71F217.7000209@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3484bis and privacy addresses Thread-Index: Ac0MPnpod08JiVUiTzCsLTHstD7KwwGtnTkA References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> From: "Tirumaleswar Reddy (tireddy)" To: "Ray Hunter" , "Brian Haberman" X-OriginalArrivalTime: 05 Apr 2012 07:01:36.0415 (UTC) FILETIME=[F1105AF0:01CD12F9] Cc: "Prashanth Patil \(praspati\)" , 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, 05 Apr 2012 07:01:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD12F9.F0E426DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Firewall policies are moving towards identity (user, user-group) + context (location, Bring your Own Device (BYOD)) attributes to enforce appropriate policies. In enterprises hosts with EAP kind of supplicants can be tracked even when the IP changes but for guests, BYOD without such supplicants IP address based authentication is still required and for such users, switches acting as DHCP relay agent can influence the DHCP server not to assign temporary addresses (http://tools.ietf.org/html/draft-reddy-mif-dhcpv6-precedence-ops-00) =20 Regards Tiru. =20 From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray Hunter Sent: Tuesday, March 27, 2012 10:30 PM To: Brian Haberman Cc: ipv6@ietf.org Subject: Re: 3484bis and privacy addresses =20 >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:=20
All,=20 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,=20 Brian, Bob, & Ole=20
=20 =20 --=20 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 ------_=_NextPart_001_01CD12F9.F0E426DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Firewall policies are moving towards identity (user, = user-group) + context (location, Bring your Own Device (BYOD)) attributes to enforce appropriate policies. In enterprises hosts with EAP kind of supplicants = can be tracked even when the IP changes but for guests, BYOD without such = supplicants IP address based authentication is still required and for such users, = switches acting as DHCP relay agent can influence the DHCP server not to assign = temporary addresses (http://tools.ietf.org/html/draft-reddy-mif-dhcpv6-precedence-ops-00)

 

Regards

Tiru.

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray Hunter
Sent: Tuesday, March 27, 2012 10:30 PM
To: Brian Haberman
Cc: ipv6@ietf.org
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:

<div class=3D"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

------_=_NextPart_001_01CD12F9.F0E426DA-- From v6ops@globis.net Fri Apr 6 02:30: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 C6B3821F863E for ; Fri, 6 Apr 2012 02:30:20 -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 Rg-fZBsMGaNJ for ; Fri, 6 Apr 2012 02:30:20 -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 0B07C21F8603 for ; Fri, 6 Apr 2012 02:30:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8EF398700EE; Fri, 6 Apr 2012 11:30:16 +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 7HsXijrLkx3G; Fri, 6 Apr 2012 11:30: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 E278E8700EA; Fri, 6 Apr 2012 11:30:06 +0200 (CEST) Message-ID: <4F7EB79D.8010207@globis.net> Date: Fri, 06 Apr 2012 11:30:05 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F71F217.7000209@globis.net> <454A16E4DA86094EB66BB2C1DBBBC0180796978B@XMB-BGL-41B.cisco.com> In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC0180796978B@XMB-BGL-41B.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Prashanth Patil \(praspati\)" , 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: Fri, 06 Apr 2012 09:30:20 -0000 Interesting draft. Thanks. The elephant in the room is that DHCPv6 clients are still not deployed on all end nodes that would benefit from it. Many other 6man drafts, such as draft-ietf-6man-addr-select-opt-03 also rely on DHCPv6. Let's hope that the market now manages toquickly resolve what the IETF has not managed to resolve in over 10 years of discussion, and selects a universally available communication channel for passing configuration hints between the network and end nodes that move between networks. Otherwise changing default behavior (like being discussed in the update from 3484 to 3484bis), or implementing new features in 6man, will likely make migration to IPv6 duringdual stack operation harder, or break existing stuff, or both. regards, RayH > Tirumaleswar Reddy (tireddy) > 5 April 2012 08:59 > > Firewall policies are moving towards identity (user, user-group) + > context (location, Bring your Own Device (BYOD)) attributes to enforce > appropriate policies. In enterprises hosts with EAP kind of > supplicants can be tracked even when the IP changes but for guests, > BYOD without such supplicants IP address based authentication is still > required and for such users, switches acting as DHCP relay agent can > influence the DHCP server not to assign temporary addresses > (http://tools.ietf.org/html/draft-reddy-mif-dhcpv6-precedence-ops-00) > > Regards > > Tiru. > > *From:*ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] *On Behalf > Of *Ray Hunter > *Sent:* Tuesday, March 27, 2012 10:30 PM > *To:* Brian Haberman > *Cc:* ipv6@ietf.org > *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 > 27 March 2012 19:00 > 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 > > From albert.e.manfredi@boeing.com Fri Apr 6 14:16: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 29F5311E80AE for ; Fri, 6 Apr 2012 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 9vlxkJnsrvS9 for ; Fri, 6 Apr 2012 14:16:58 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 746C611E809B for ; Fri, 6 Apr 2012 14:16:58 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q36LIZsB019653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Apr 2012 16:18:36 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q36LGsJF010188 for ; Fri, 6 Apr 2012 14:16:54 -0700 (PDT) Received: from XCH-MWHT-04.mw.nos.boeing.com (xch-mwht-04.mw.nos.boeing.com [134.57.113.164]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q36LGsgS010181 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 6 Apr 2012 14:16:54 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-04.mw.nos.boeing.com ([134.57.113.164]) with mapi; Fri, 6 Apr 2012 16:16:54 -0500 From: "Manfredi, Albert E" To: "ipv6@ietf.org" Date: Fri, 6 Apr 2012 16:16:53 -0500 Subject: Real world ULA prefix Thread-Topic: Real world ULA prefix Thread-Index: Ac0UOpaJz/FE3PY4QoKvbgyyGZSrqg== Message-ID: 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: Fri, 06 Apr 2012 21:16:59 -0000 Just obsessing over this: In the ULA RFC and postings, people always use the fc00:: prefix as an exam= ple, it seems. But according to RFC 4193, the 8th bit in the first octet mu= st be set to 1, to indicate "local," at least until someone figures out how= to use a non-local ULA scheme. So in fact, the first octet will always be fd, yes? Just obsessing on a Good Friday. Thanks. Bert From brian.e.carpenter@gmail.com Sat Apr 7 00:14: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 6935021F852A for ; Sat, 7 Apr 2012 00:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 Lue8mvgXZdpS for ; Sat, 7 Apr 2012 00:14:08 -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 B4C8521F8528 for ; Sat, 7 Apr 2012 00:14:07 -0700 (PDT) Received: by werb10 with SMTP id b10so2100247wer.31 for ; Sat, 07 Apr 2012 00:14:06 -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=+zGJlhtJDCyKW79T5XXkMG/QaavOfK4ZnclqI86wCZc=; b=0O1QXw4kX5iNmmLQjo+BMFs2lixUAGSEPBDX9Wzb+taEND+EgHdwBinOvixDLd15yR 3dm97zsQx90pqJYTQlbBj7zsIaMfQ5MouFStwDbXUz8qTNWk28Py1IPiZmJQP54l4T3Y 9hME3PvyE1c3+OPXEX0LUzHWbu7VkFjUY8WZ79DkQwweQurVdqqHd8YJ0pHeg32awDIB 81JxPZgTW8LVPtOGAejWSlO3jV3y7s+maWp05Yl/3f41MXAoTjYgMArMAMHRcIr4L47z iqV9EJ2q90o0nSK2X1PJPRtE3dILxQNjyxD8Rq3c8ZoxaH+JRkaYUqL4ihOpHvai+Wgd qwXw== Received: by 10.216.133.72 with SMTP id p50mr361102wei.78.1333782846765; Sat, 07 Apr 2012 00:14:06 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-217-51.as13285.net. [2.102.217.51]) by mx.google.com with ESMTPS id fn2sm20439909wib.0.2012.04.07.00.14.05 (version=SSLv3 cipher=OTHER); Sat, 07 Apr 2012 00:14:05 -0700 (PDT) Message-ID: <4F7FE939.7040405@gmail.com> Date: Sat, 07 Apr 2012 08:14:01 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: Real world ULA prefix 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: Sat, 07 Apr 2012 07:14:08 -0000 On 2012-04-06 22:16, Manfredi, Albert E wrote: > Just obsessing over this: > > In the ULA RFC and postings, people always use the fc00:: prefix as an example, it seems. But according to RFC 4193, the 8th bit in the first octet must be set to 1, to indicate "local," at least until someone figures out how to use a non-local ULA scheme. > > So in fact, the first octet will always be fd, yes? > > Just obsessing on a Good Friday. The ULA prefix is fc00::/7 but indeed all prefixes created under RFC 4193 are under fd00::/8. The filtering rule in a border router needs to be on fc00::/7 to include a hypothetical future ULA scheme under fc00::/8. Quoting prefixes without the prefix length isn't such a good idea. Brian From joelja@bogus.com Sat Apr 7 09:17: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 3F1CF21F84F7 for ; Sat, 7 Apr 2012 09:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.322 X-Spam-Level: X-Spam-Status: No, score=-100.322 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_40=-0.185, 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 SEzY5xRocmm5 for ; Sat, 7 Apr 2012 09:17:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B318021F84D9 for ; Sat, 7 Apr 2012 09:17:28 -0700 (PDT) Received: from Joels-MacBook-Pro.local (21.sub-166-250-46.myvzw.com [166.250.46.21]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q37GHRI5041065 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 7 Apr 2012 16:17:28 GMT (envelope-from joelja@bogus.com) Message-ID: <4F806891.8090403@bogus.com> Date: Sat, 07 Apr 2012 09:17:21 -0700 From: Joel jaeggli 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 deployment prevention Subject: RE: draft-macaulay-6man-packet-stain-00 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 07 Apr 2012 16:17:28 +0000 (UTC) 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, 07 Apr 2012 16:17:29 -0000 I hesitate to suggest this because I'll probably turn into a pillar of salt at some point for harping on it. however... Getting new extension headers generally parsed is a high bar to get over. That said within one domain of control you might be able to fit a subset of the information you're looking to carry into the 20 bits available in flow label. 6437 probably provides enough cover/instruction to allow for that. From brian.e.carpenter@gmail.com Sun Apr 8 00:10: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 5D00221F857F for ; Sun, 8 Apr 2012 00:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.648 X-Spam-Level: X-Spam-Status: No, score=-101.648 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 Pof7ZQJpr7k2 for ; Sun, 8 Apr 2012 00:10:56 -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 6699821F8522 for ; Sun, 8 Apr 2012 00:10:50 -0700 (PDT) Received: by werb10 with SMTP id b10so2491957wer.31 for ; Sun, 08 Apr 2012 00:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8DcuG8gmyASOT1on2cE+YvXpVuPbZ7O30hRc91P6KSc=; b=JlEkmgQ4P3kdblVSXKYinyDxuN2KQh/lBB8g1wHpo5ijCQNCWhkmfNL95IpG4fvk4c n7pZnMAbH+Tgq9mM9bQdyhqDrzhzV8LUWsRAVw5VQ42a230tdLIIoHWGeVIpjbg+xm+I dLpKhDoDaXLwYfD6GWyzV93vc3d7MTLEgU1E/zFgeA5NsqP8WNEBWFDiqDDfX79Qu1VU WKCxjuQXhGcLFZ4nLww1tauyESWCmdkdBCwcLBd6q24T3OQ/lIPZR3xhJ84JFfSnlS5p aT+x+bpVr2mZ256Z6dmOCQ8nkNDuwisEOiYRi3XzvBz8I3WfvC+rLIBcXH4a8T6wb9Hc iZAA== Received: by 10.180.88.199 with SMTP id bi7mr7487384wib.12.1333869049426; Sun, 08 Apr 2012 00:10:49 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-219-159.as13285.net. [2.102.219.159]) by mx.google.com with ESMTPS id n8sm32955978wix.10.2012.04.08.00.10.47 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 00:10:48 -0700 (PDT) Message-ID: <4F8139F4.6030508@gmail.com> Date: Sun, 08 Apr 2012 08:10:44 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli Subject: Re: draft-macaulay-6man-packet-stain-00 References: <4F806891.8090403@bogus.com> In-Reply-To: <4F806891.8090403@bogus.com> Content-Type: text/plain; charset=UTF-8 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: Sun, 08 Apr 2012 07:10:57 -0000 On 2012-04-07 17:17, Joel jaeggli wrote: > I hesitate to suggest this because I'll probably turn into a pillar of > salt at some point for harping on it. however... Just don't look back (towards IPv4). > > Getting new extension headers generally parsed is a high bar to get > over. I have another concern; this draft appears to state that some middlebox inserts an extension header into a packet on the fly: "IPv6 packet staining support consists of labeling datagrams with security reputation information through the addition of an IPv6 destination option in the packet header by packet manipulation devices (PMDs) in the carrier or enterprise network." I'm not aware of any provision in RFC 2460 allowing this, or of any other extension header that is inserted by a middlebox. The implications for MTU size and fragmentation are clear. > That said within one domain of control you might be able to fit a > subset of the information you're looking to carry into the 20 bits > available in flow label. 6437 probably provides enough cover/instruction > to allow for that. Given that the first paragraph of the Introduction to the draft is almost identical to the same paragraph in 6437, you may be on to something. However, it's only conformant if (a) the resulting values belong to a reasonably uniform distribution and are hard to predict and (b) the method MUST NOT be used for packets whose flow label is already non-zero. Brian From joelja@bogus.com Sun Apr 8 07:25: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 1934B21F852A for ; Sun, 8 Apr 2012 07:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.676 X-Spam-Level: X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=0.923, 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 HBViUBCB+thi for ; Sun, 8 Apr 2012 07:25:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 296F621F84FE for ; Sun, 8 Apr 2012 07:25:25 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q38EPNbK063471 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 8 Apr 2012 14:25:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4F819FD2.4000401@bogus.com> Date: Sun, 08 Apr 2012 07:25:22 -0700 From: Joel jaeggli 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: Brian E Carpenter Subject: Re: draft-macaulay-6man-packet-stain-00 References: <4F806891.8090403@bogus.com> <4F8139F4.6030508@gmail.com> In-Reply-To: <4F8139F4.6030508@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 08 Apr 2012 14:25:23 +0000 (UTC) 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: Sun, 08 Apr 2012 14:25:28 -0000 On 4/8/12 00:10 , Brian E Carpenter wrote: > On 2012-04-07 17:17, Joel jaeggli wrote: >> I hesitate to suggest this because I'll probably turn into a pillar of >> salt at some point for harping on it. however... > > Just don't look back (towards IPv4). > >> >> Getting new extension headers generally parsed is a high bar to get >> over. > > I have another concern; this draft appears to state that some > middlebox inserts an extension header into a packet on the fly: > "IPv6 packet staining support consists of labeling datagrams with > security reputation information through the addition of an IPv6 > destination option in the packet header by packet manipulation > devices (PMDs) in the carrier or enterprise network." > > I'm not aware of any provision in RFC 2460 allowing this, or of any > other extension header that is inserted by a middlebox. The implications > for MTU size and fragmentation are clear. yes, it occured to me that an alternate approach eg encapsulation would also necessitate the generation fragmented outer packets (which would be legal) >> That said within one domain of control you might be able to fit a >> subset of the information you're looking to carry into the 20 bits >> available in flow label. 6437 probably provides enough cover/instruction >> to allow for that. > > Given that the first paragraph of the Introduction to the draft is almost > identical to the same paragraph in 6437, you may be on to something. > However, it's only conformant if (a) the resulting values belong to a > reasonably uniform distribution and are hard to predict and (b) the method > MUST NOT be used for packets whose flow label is already non-zero. If one reset the flow label at ingress due to security considerations (namely in this case that the contents of the flow label cannot be trusted since they contain information) then all flow labels you encounter when it comes time to stain them, will be zero. > Brian > From victor.kuarsingh@gmail.com Sun Apr 8 09:33: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 7CAC521F853A for ; Sun, 8 Apr 2012 09:33:59 -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 t5R3R88sxBro for ; Sun, 8 Apr 2012 09:33: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 A50FC21F8525 for ; Sun, 8 Apr 2012 09:33:58 -0700 (PDT) Received: by iazz13 with SMTP id z13so6013652iaz.31 for ; Sun, 08 Apr 2012 09:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=p0bvhvpKLzzjUEbENDVVvFzeG3eZeBNKVh6RJsrmtug=; b=Kvz50mbdjPJiicAKpLKP4OPDgMFSHZwVHRiwOlatlS214JLjbcurwOT/v8yy/Z5MLW 1gEo7c4z0LICsQz8bowqjGg0sPokESKr85xxOlGNO+P+8xhW9iZRmD95oCaM+ANUngLM DEBMgeByqLpYFYdD5LZ8cBTKd9IuEZ7uhBNsf2agALLHE8j//V6FAp3RdmoiihXWl1E6 fyxoaWw0OtHDL9ee73rgpVi0EGItmj6bXkYJ2fLTGV1KFBzYEYljDcyt5mLrBjqDdVEW QRUKv5kauG/cOjL2dEg7SfoYAFHlkYCTUbAeyQWSu7JgjYN5qcIAzeWkjD2EKxDeEPO7 Jq9Q== Received: by 10.50.36.193 with SMTP id s1mr3030745igj.45.1333902838333; Sun, 08 Apr 2012 09:33:58 -0700 (PDT) Received: from [192.168.100.235] (CPE84c9b2590d49-CM80c6ab7f57ed.cpe.net.cable.rogers.com. [72.139.26.169]) by mx.google.com with ESMTPS id df1sm12112659igb.12.2012.04.08.09.33.56 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 09:33:57 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 08 Apr 2012 12:33:59 -0400 Subject: Re: draft-macaulay-6man-packet-stain-00 From: Victor Kuarsingh To: Brian E Carpenter , Joel jaeggli Message-ID: Thread-Topic: draft-macaulay-6man-packet-stain-00 In-Reply-To: <4F8139F4.6030508@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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: Sun, 08 Apr 2012 16:33:59 -0000 On 12-04-08 3:10 AM, "Brian E Carpenter" wrote: >On 2012-04-07 17:17, Joel jaeggli wrote: >> I hesitate to suggest this because I'll probably turn into a pillar of >> salt at some point for harping on it. however... > >Just don't look back (towards IPv4). > >> >> Getting new extension headers generally parsed is a high bar to get >> over. > >I have another concern; this draft appears to state that some >middlebox inserts an extension header into a packet on the fly: > "IPv6 packet staining support consists of labeling datagrams with > security reputation information through the addition of an IPv6 > destination option in the packet header by packet manipulation > devices (PMDs) in the carrier or enterprise network." > >I'm not aware of any provision in RFC 2460 allowing this, or of any >other extension header that is inserted by a middlebox. The implications >for MTU size and fragmentation are clear. This point was brought up in the WG meeting which noted issues with fragmentation. I think it was clear based on numbers folks at the mic that inserting an extension header mid-stream would result in negative behaviours. > >> That said within one domain of control you might be able to fit a >> subset of the information you're looking to carry into the 20 bits >> available in flow label. 6437 probably provides enough cover/instruction >> to allow for that. > >Given that the first paragraph of the Introduction to the draft is almost >identical to the same paragraph in 6437, you may be on to something. >However, it's only conformant if (a) the resulting values belong to a >reasonably uniform distribution and are hard to predict and (b) the method >MUST NOT be used for packets whose flow label is already non-zero. The point of using the flow label seems valid. The author will need to re-evaluate the requirements as I believe it was noted in the WG presentation that the Flow Label seemed to be too restrictive (size) for this function (packet staining). If the staining can be bounded by the size of the flow label then perhaps the author can re-focus on using it for this function (packet staining). Victor K > > Brian >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From zhou.sujing@zte.com.cn Sun Apr 8 22:30: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 A8A7E21F85DF for ; Sun, 8 Apr 2012 22:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.19 X-Spam-Level: X-Spam-Status: No, score=-92.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, 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 RhMYU3-mc-hT for ; Sun, 8 Apr 2012 22:30:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8D21F8608 for ; Sun, 8 Apr 2012 22:30:02 -0700 (PDT) Received: from [192.168.164.15] by mx5.zte.com.cn with surfront esmtp id 621291320096835; Mon, 9 Apr 2012 13:29:43 +0800 (CST) Received: from [10.30.3.21] by [192.168.164.15] with StormMail ESMTP id 14085.5338359427; Mon, 9 Apr 2012 13:14:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q395TnIW093117; Mon, 9 Apr 2012 13:29:49 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Christian Huitema Subject: =?GB2312?B?tPC4tDogUkU6IFJFOiBhYm91dCBzZWN1cml0eSBsZXZlbCBldmFsdWF0aW9u?= =?GB2312?B?IG9mICBkcmFmdC16aG91LTZtYW4tbWhhc2gtY2dhLTAw?= 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, 9 Apr 2012 13:29:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-09 13:29:51, Serialize complete at 2012-04-09 13:29:51 Content-Type: multipart/alternative; boundary="=_alternative 001E383B482579DB_=" X-MAIL: mse02.zte.com.cn q395TnIW093117 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, 09 Apr 2012 05:30:08 -0000 This is a multipart message in MIME format. --=_alternative 001E383B482579DB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrEh1aXRlbWGjrA0KDQoNClJlZ2FyZHN+fn4NCg0KLVN1amluZyBaaG91DQoNCkNocmlzdGlh biBIdWl0ZW1hIDxodWl0ZW1hQG1pY3Jvc29mdC5jb20+INC009ogMjAxMi0wMy0yOSAwODoyMzoz ODoNCg0KPiBTdWppbiwNCj4gDQo+IFlvdXIgc3RhdGVtZW50ICChsGFmdGVyIGF0dGFja2VyIGhh cyBjcmFja2VkIGEgQ0dBIGFkZHJlc3MsIHRoZW4gaXQgDQo+IGlzIGluIHRoZSBzYW1lIHN0YW5k IGFzIHRoZSBkZWZlbmRlcqGxIGlzIGluY29ycmVjdC4gVGhlIGF0dGFja2VyIA0KDQpUaGFuayB5 b3VyIGZvciBwb2ludGluZyBvdXQgb25lIG9mIG15IG9taXNzaW9uIHRoYXQgZmFpbGluZyB0byBy ZWNhbGwgdGhlIA0Kc2FtZSB2YWx1ZSAibW9kaWZpZXIiIGlzIHVzZWQgaW4gYm90aCBIQVNIMSBh bmQgSEFTSDIuIA0KDQo+IHdpbGwgbm90IG5lZWQgNjU1MzYgYWRkaXRpb25hbCB0cmlhbHM7IGhl IHdpbGwgbmVlZCB0byBmaW5kIGEgDQo+IG1hdGNoaW5nIENHQSBhZGRyZXNzIDY1NTM2IHRpbWVz LCBhbmQgZWFjaCB0cmlhbCBpcyBqdXN0IGFzIGNvbXBsZXggDQo+IGFzIGZpbmRpbmcgYSBtYXRj aGluZyBDR0EgYWRkcmVzcy4gVGhlIGRlZmVuZGVyIG9uIHRoZSBvdGhlciBoYW5kIA0KPiBjYW4g cGljayBhbnkgQ0dBIGFkZHJlc3MgaGUgd2FudHMsIHNvIGhlIGhhcyB0byBwZXJmb3JtIGp1c3Qg NjU1MzYgDQp0cmlhbHMuDQo+IA0KDQpZb3UgbWF5IGhhdmUgYSBtaXN1bmRlcnRhbmQgYWJvdXQg bXkgd29yZHMuDQpCeSAiY3JhY2tlZCBhIENHQSBhZGRyZXNzIiwgSSBtZWFuIHRoZSBhdHRhY2tl ciBoYXMgb2J0YWluZWQgYW5vdGhlciBwYWlyIA0Kb2YgcHVibGljIGtleSBhbmQgcHJpdmF0ZSBr ZXkgb2YgaGlzIG93biwgYW5kIGhhcyBtYW5hZ2VkIHRvIA0KZmluZCBhIHN1aXRhYmxlICJtb2Rp ZmVyICIgc28gdGhhdCB0aGUgY29tcHV0YXRlZCBDR0EgYWRkcmVzcyBlcXVhbHMgdGhlIA0KQ0dB IGFkZHJlc3MgdW5kZXIgYXR0YWNrLg0KWWVzLCBJoaFkaWQgbm90IHJlY2FsbCB0aGF0IHRoZSBz YW1lIG1vZGlmaWVyIHZhbHVlIGlzIHRvIGJlIHVzZWQgaW4gdGhlIA0KY29tcHV0YXRpb24gb2Yg SEFTSDIsIHNvIHRoZXJlIGlzIGxpdHRsZSBtYW5pcHVsYXRpb24gc3BhY2UgZm9yIHRoZSANCmF0 dGFja2VyIHRvIHRyeSBhIG5ldyBtb2RpZmllci4NCg0KQnV0IEkgZG9uJ3QgYWdyZWUgd2l0aCB5 b3UgaW4gICJlYWNoIHRyaWFsIGlzIGp1c3QgYXMgY29tcGxleCBhcyBmaW5kaW5nIGEgDQptYXRj aGluZyBDR0EgYWRkcmVzcy4iDQpzdXBwb3NlIHdlIGRlZmluZSBhIG5ldyBoYXNoIGFsZ29yaXRo bToNCkgnKG1vZGlmaWVyLHB1YmxpYyBrZXksIGV4dGVuc2lvbiBmaWVsZHMsIHN1Ym5ldC1wcmVm aXgsY29sbGlzaW9uIGNvdW50KQ0KPUhBU0gyKG1vZGlmaWVyLDAscHVibGljIGtleSxleHRlbnNp b24gDQpmaWVsZHMpfHxIQVNIMShtb2RpZmVyLHN1Ym5ldC1wcmVmaXgsY29sbGlzaW9uLWNvdW50 LCBwdWJsaWMga2V5LCANCmV4dGVuc2lvbiBmaWVsZHMpDQpJcyB0aGlzIG5ldyBoYXNoIGFsZ29y aXRobSBtdWNoIG11Y2ggbW9yZSBzZWN1cmUgdGhhbiBhbnkgb25lIG9mIGl0cyANCmNvbXBvbmVu dHM/DQpJZiBpdCBpcyAsdGhlbiB3ZSBoYXZlIGZvdW5kIGEgZ29vZCBkZXNpZ24gbWV0aG9kIG9m IGhhc2ggYWxnb3JpdGhtLg0KDQpBcyBwb2ludGVkIG91dCAgYnkgVGltIFBvbGsoPykgd2hlbiBp bnRyb2R1Y2luZyBTSEEtMyBwcm9ncmVzcyBhdCBTQUFHIA0KbWVldGluZyB0aGlzIHRpbWUsIGl0 IGlzIGJldHRlciB0byBiZSBhbGdvcml0aG0gYWdpbGUgYmVmb3JlIGl0IGlzIHRvbyANCmxhdGUs IA0KdG9vIG11Y2ggcmVwbGFjZSBjb3N0IHdpbGwgYmUgcmVxdWlyZWQuDQoNClNvLCBJIHN1Z2dl c3QgdGhlIGVhcmxpZXIgdGhlIHByb2JsZW0gcmVzb2x2ZWQsIHRoZSBiZXR0ZXIuIA0KDQoNCj4g LS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQoNCg0KDQo+IA0KPiANCj4gDQo+IEZyb206IHpob3Uu c3VqaW5nQHp0ZS5jb20uY24gW21haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuXSANCj4gU2Vu dDogV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAxMiA0OjQ2IEFNDQo+IFRvOiBDaHJpc3RpYW4gSHVp dGVtYQ0KPiBDYzogaXB2NkBpZXRmLm9yZzsgSmFyaSBBcmtrbw0KPiBTdWJqZWN0OiC08Li0OiBS RTogYWJvdXQgc2VjdXJpdHkgbGV2ZWwgZXZhbHVhdGlvbiBvZiBkcmFmdC0NCj4gemhvdS02bWFu LW1oYXNoLWNnYS0wMA0KPiANCj4gDQo+IFJlZ2FyZHN+fn4NCj4gDQo+IC1TdWppbmcgWmhvdSAN Cj4gDQo+IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQG1pY3Jvc29mdC5jb20+INC009ogMjAx Mi0wMy0yNyAyMzowMDowOToNCj4gDQo+ID4gPiBXZWxsLCBJIHRoaW5rIGl0IGlzIHF1aXRlIGEg c2ltcGxlIHRyYWRlLW9mZi4gSW5jcmVhc2luZyBTZWMgDQo+ID4gaW5jcmVhc2VzIGNvbXB1dGF0 aW9uYWwgZWZmb3J0IG9uIGJvdGggc2lkZXMgYnkgZXF1YWwgYW1vdW50LiANCj4gPiBJbmNyZWFz aW5nIHRoZSBsZW5ndGggb2YgDQo+ID4gPiB0aGUgaGFzaCBpbmNyZWFzZXMgY29tcHV0YXRpb25h bCBlZmZvcnQgb25seSBvbiB0aGUgYXR0YWNrZXIgc2lkZS4NCj4gPiBBcyBhIHJlc3VsdCwgdGhl IGhhc2ggYml0cyBhcmUgcmVsYXRpdmVseSB2YWx1YWJsZS4NCj4gPiANCj4gPiBKYXJpLCB0aGUg ZWZmZWN0IG9mIHNlYyBpcyBkaWZmZXJlbnQgb24gYm90aCBzaWRlcy4gVGhlIGVmZm9ydCBpcyAN Cj4gPiBub3QgaW5jcmVhc2VkICJieSBlcXVhbCBhbW91bnQiIGJ1dCByYXRoZXIgImluIHRoZSBz YW1lIHByb3BvcnRpb24uIg0KPiA+IFN1cHBvc2UgdGhhdCBhbiBhdHRhY2tlciBjb3VsZCBjcmFj ayB0aGUgNTkgYml0IGhhc2ggaW4gYSBkYXkgd2l0aCANCj4gPiBzZWM9MC4gQWRkaW5nIHNlYyA9 IDEgbWVhbnMgdGhhdCB0aGUgYXR0YWNrZXIgd2lsbCBoYXZlIHRvIHRyeSA2NTUzNg0KPiA+IHRp bWVzIGFzIG1hbnkga2V5cy4gVGhlIHRpbWUgdG8gY3JhY2sgYmVjb21lcyA2NTUzNiBob3Vycywg aS5lLiANCj4gPiBhYm91dCA3IHllYXJzLiBUaGUgZGVmZW5kZXIgd2lsbCBoYXZlIHRvIHRyeSA2 NTUzNiBpbnN0ZWFkIG9mIG9uZSB0bw0KPiA+IGdldCB0aGUgcmlnaHQgc2VjLCB0YWtpbmcgb25s eSAgYSBmcmFjdGlvbiBvZiBhIHNlY29uZC4gDQo+IA0KPiBhZnRlciBhdHRhY2tlciBoYXMgY3Jh Y2tlZCBhIENHQSBhZGRyZXNzLCB0aGVuIGl0IGlzIGluIHRoZSBzYW1lIA0KPiBzdGFuZCBhcyB0 aGUgZGVmZW5kZXIuIA0KPiBkZWZlbmRlciwgYXMgd2VsbCBhcyBhdHRhY2tlciwgaGFzIHRvIHRy eSBvbmUgYnkgb25lIHRvIGdldCB0aGUgDQo+IHJpZ2h0IHNlYywgaS5lLiwgdG8gZ2V0IGEgbWF0 Y2hpbmcgbGVuZ3RoIG9mIHplcm9zLCANCj4gaG93IGNvbWUgYXR0YWNrZXIgbmVlZCBleHRyYSA2 NTUzNiBob3VycyBidXQgZGVmZW5kZXIgb25seSBuZWVkcyBhIA0KPiBmcmFjdGlvbiBvZiBhIHNl Y29uZD8gDQo+IA0KPiA+ID4gMSkgU3RhdHVzIHF1bzogUkZDIDQ5ODIgZWF0cyB0aHJlZSBiaXRz IGZvciBTZWMsIGxlYXZpbmcgNTkgYml0cyANCj4gPiBvZiBoYXNoIGxlbmd0aCBhZnRlciBhY2Nv bW1vZGF0aW5nIGZvciB1IGFuZCBnIGJpdHMgYXMgd2VsbC4gVGhlIA0KPiA+IGdvb2Qgd2l0aCB0 aGlzIGlzIA0KPiA+ID4gdGhhdCBpdCBsZWF2ZXMgbWF4aW11bSBzaXplIGZvciBoYXNoLiBUaGUg YmFkIGlzIHRoYXQgaXQgaXMgbGVzcyANCj4gPiBmbGV4aWJsZSBmb3IgYWRkaW5nIG1hbnkgbmV3 IGhhc2ggYWxnb3JpdGhtcy4NCj4gPiANCj4gPiBJIGtpbmQgb2YgbGlrZSB0aGUgc3RhdHVzIHF1 by4NCj4gPiANCj4gPiA+IDIpIFRoZSBwcm9wb3NlZCBuZXcgYXBwcm9hY2g6IEVhdCBhIHRvdGFs IG9mIHNpeCBiaXRzLCBmb3IgU2VjIGFuZA0KPiA+IHRoZSBoYXNoIGFsZ29yaXRobSBpZGVudGlm aWVyLiA1NiBiaXRzIHJlbWFpbi4gVGhlIGdvb2QgaXMgdGhhdCB0aGlzDQo+ID4gZ2l2ZXMgbW9y ZSANCj4gPiA+IGZsZXhpYmlsaXR5IHRvIGFsbG9jYXRlIGhhc2ggYWxnb3JpdGhtcywgaW5jbHVk aW5nIHRoZSBhYmlsaXR5IHRvIA0KPiA+IGluZGVwZW5kZW50bHkgY2hvb3NlIFNlYyBhbmQgdGhl IGFsZ29yaXRobS4gVGhlIGJhZCBpcyB0aGF0IHRoZSANCj4gaGFzaCBzaXplIGlzIA0KPiA+ID4g ZGVjcmVhc2VkLg0KPiA+IA0KPiA+IERlY3JlYXNlZCBhIGxvdC4gT24gdGhlIG90aGVyIGhhbmQs IGlmIHdlIGRvIGdhaW4gdGhlIGZsZXhpYmlsaXR5IHRvDQo+ID4gZGVmaW5lIG5ldyBhbGdvcml0 aG1zLCB0aGVuIHdlIGNhbiBkZWZpbmUgYSBtYW5kYXRvcnktdG8taW1wbGVtZW50IA0KPiA+IGFs Z29yaXRobSB0aGF0IGluY29ycG9yYXRlcyB0aGUgZXF1aXZhbGVudCBvZiB0aGUgInNlYyIgc3Ry ZW5ndGhlbmluZy4NCj4gDQo+IHRoZSBzZWN1cml0eSBvZiBhIGhhc2ggYWxnbyBjYW4gYmUgcm91 Z2hseSBlc3RpbWF0ZWQgYnkgbGVuZ3RoIG9mIGl0cyANCm91dHB1dCwNCj4gZnJvbSBiaXJ0aGRh eSBhdHRhY2ssIHRoYXQgaXMgYWJvdXQgMl4oNTkvMikgb3IgMl4oNTYvMikodGhlb3JpY2FsIA0K PiBlc3RpbWF0ZSksIG9yIGxlc3MsIA0KPiBjYW4geW91IGdpdmUgYSBtb3JlIHByZWNpc2Ugb2Yg dmFsdWUgb2YgImEgbG90Ij8gDQo+IEkgZG9uJ3Qgc2VlIGZsZXhpYmlsaXR5IGluIGRlZmluaW5n IG1hbmRhdG9yeS10by1pbXBsZW1lbnRpbmcgaGFzaCBhbGcgDQo+IA0KPiA+IC0tIENocmlzdGlh biBIdWl0ZW1hDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo= --=_alternative 001E383B482579DB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6xIdWl0ZW1ho6w8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+ fn48YnI+DQo8YnI+DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5DaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBtaWNyb3NvZnQuY29tJmd0OyDQtNPa DQoyMDEyLTAzLTI5IDA4OjIzOjM4Ojxicj4NCjxicj4NCiZndDsgU3VqaW4sPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBZb3VyIHN0YXRlbWVudCAmbmJzcDuhsGFmdGVyIGF0dGFja2VyIGhh cyBjcmFja2VkDQphIENHQSBhZGRyZXNzLCB0aGVuIGl0IDxicj4NCiZndDsgaXMgaW4gdGhlIHNh bWUgc3RhbmQgYXMgdGhlIGRlZmVuZGVyobEgaXMgaW5jb3JyZWN0LiBUaGUgYXR0YWNrZXINCjwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmsgeW91ciBmb3IgcG9p bnRpbmcgb3V0IG9uZSBvZiBteSBvbWlzc2lvbiB0aGF0DQpmYWlsaW5nIHRvIHJlY2FsbCB0aGUg c2FtZSB2YWx1ZSAmcXVvdDttb2RpZmllciZxdW90OyBpcyB1c2VkIGluIGJvdGggSEFTSDENCmFu ZCBIQVNIMi4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IHdp bGwgbm90IG5lZWQgNjU1MzYgYWRkaXRpb25hbCB0cmlhbHM7IGhlIHdpbGwgbmVlZCB0byBmaW5k IGEgPGJyPg0KJmd0OyBtYXRjaGluZyBDR0EgYWRkcmVzcyA2NTUzNiB0aW1lcywgYW5kIGVhY2gg dHJpYWwgaXMganVzdCBhcyBjb21wbGV4DQo8YnI+DQomZ3Q7IGFzIGZpbmRpbmcgYSBtYXRjaGlu ZyBDR0EgYWRkcmVzcy4gVGhlIGRlZmVuZGVyIG9uIHRoZSBvdGhlciBoYW5kDQo8YnI+DQomZ3Q7 IGNhbiBwaWNrIGFueSBDR0EgYWRkcmVzcyBoZSB3YW50cywgc28gaGUgaGFzIHRvIHBlcmZvcm0g anVzdCA2NTUzNg0KdHJpYWxzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPllvdSBtYXkg aGF2ZSBhIG1pc3VuZGVydGFuZCBhYm91dCBteSB3b3Jkcy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPkJ5ICZxdW90O2NyYWNrZWQgYSBDR0EgYWRkcmVzcyZxdW90OywgSSBtZWFu IHRoZSBhdHRhY2tlcg0KaGFzIG9idGFpbmVkIGFub3RoZXIgcGFpciBvZiBwdWJsaWMga2V5IGFu ZCBwcml2YXRlIGtleSBvZiBoaXMgb3duLCBhbmQNCmhhcyBtYW5hZ2VkIHRvIDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ZmluZCBhIHN1aXRhYmxlICZxdW90O21vZGlmZXIgJnF1 b3Q7IHNvIHRoYXQgdGhlIGNvbXB1dGF0ZWQNCkNHQSBhZGRyZXNzIGVxdWFscyB0aGUgQ0dBIGFk ZHJlc3MgdW5kZXIgYXR0YWNrLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WWVz LCBJoaFkaWQgbm90IHJlY2FsbCB0aGF0IHRoZSBzYW1lIG1vZGlmaWVyIHZhbHVlDQppcyB0byBi ZSB1c2VkIGluIHRoZSBjb21wdXRhdGlvbiBvZiBIQVNIMiwgc28gdGhlcmUgaXMgbGl0dGxlIG1h bmlwdWxhdGlvbg0Kc3BhY2UgZm9yIHRoZSBhdHRhY2tlciB0byB0cnkgYSBuZXcgbW9kaWZpZXIu PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CdXQgSSBkb24ndCBhZ3Jl ZSB3aXRoIHlvdSBpbiAmbmJzcDsmcXVvdDtlYWNoIHRyaWFsDQppcyBqdXN0IGFzIGNvbXBsZXgg YXMgZmluZGluZyBhIG1hdGNoaW5nIENHQSBhZGRyZXNzLiZxdW90OzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+c3VwcG9zZSB3ZSBkZWZpbmUgYSBuZXcgaGFzaCBhbGdvcml0aG06 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IJyhtb2RpZmllcixwdWJsaWMga2V5 LCBleHRlbnNpb24gZmllbGRzLCBzdWJuZXQtcHJlZml4LGNvbGxpc2lvbg0KY291bnQpPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj49SEFTSDIobW9kaWZpZXIsMCxwdWJsaWMga2V5 LGV4dGVuc2lvbiBmaWVsZHMpfHxIQVNIMShtb2RpZmVyLHN1Ym5ldC1wcmVmaXgsY29sbGlzaW9u LWNvdW50LA0KcHVibGljIGtleSwgZXh0ZW5zaW9uIGZpZWxkcyk8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPklzIHRoaXMgbmV3IGhhc2ggYWxnb3JpdGhtIG11Y2ggbXVjaCBtb3Jl IHNlY3VyZSB0aGFuDQphbnkgb25lIG9mIGl0cyBjb21wb25lbnRzPzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+SWYgaXQgaXMgLHRoZW4gd2UgaGF2ZSBmb3VuZCBhIGdvb2QgZGVz aWduIG1ldGhvZA0Kb2YgaGFzaCBhbGdvcml0aG0uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5BcyBwb2ludGVkIG91dCAmbmJzcDtieSBUaW0gUG9sayg/KSB3aGVuIGlu dHJvZHVjaW5nDQpTSEEtMyBwcm9ncmVzcyBhdCBTQUFHIG1lZXRpbmcgdGhpcyB0aW1lLCBpdCBp cyBiZXR0ZXIgdG8gYmUgYWxnb3JpdGhtDQphZ2lsZSBiZWZvcmUgaXQgaXMgdG9vIGxhdGUsIDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+dG9vIG11Y2ggcmVwbGFjZSBjb3N0IHdp bGwgYmUgcmVxdWlyZWQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5T bywgSSBzdWdnZXN0IHRoZSBlYXJsaWVyIHRoZSBwcm9ibGVtIHJlc29sdmVkLCB0aGUNCmJldHRl ci4gJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IC0tIENocmlzdGlhbiBIdWl0ZW1hPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IEZyb206IHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gW21haWx0bzp6aG91LnN1amluZ0B6dGUu Y29tLmNuXQ0KPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI4LCAyMDEyIDQ6NDYg QU08YnI+DQomZ3Q7IFRvOiBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCiZndDsgQ2M6IGlwdjZAaWV0 Zi5vcmc7IEphcmkgQXJra288YnI+DQomZ3Q7IFN1YmplY3Q6ILTwuLQ6IFJFOiBhYm91dCBzZWN1 cml0eSBsZXZlbCBldmFsdWF0aW9uIG9mIGRyYWZ0LTxicj4NCiZndDsgemhvdS02bWFuLW1oYXNo LWNnYS0wMDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzfn5+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC1TdWppbmcgWmhvdSA8YnI+DQomZ3Q7IDxicj4NCiZndDsg Q2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAbWljcm9zb2Z0LmNvbSZndDsg0LTT2iAyMDEy LTAzLTI3DQoyMzowMDowOTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFdlbGwsIEkg dGhpbmsgaXQgaXMgcXVpdGUgYSBzaW1wbGUgdHJhZGUtb2ZmLiBJbmNyZWFzaW5nDQpTZWMgPGJy Pg0KJmd0OyAmZ3Q7IGluY3JlYXNlcyBjb21wdXRhdGlvbmFsIGVmZm9ydCBvbiBib3RoIHNpZGVz IGJ5IGVxdWFsIGFtb3VudC4NCjxicj4NCiZndDsgJmd0OyBJbmNyZWFzaW5nIHRoZSBsZW5ndGgg b2YgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIGhhc2ggaW5jcmVhc2VzIGNvbXB1dGF0aW9uYWwg ZWZmb3J0IG9ubHkgb24gdGhlIGF0dGFja2VyDQpzaWRlLjxicj4NCiZndDsgJmd0OyBBcyBhIHJl c3VsdCwgdGhlIGhhc2ggYml0cyBhcmUgcmVsYXRpdmVseSB2YWx1YWJsZS48YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IEphcmksIHRoZSBlZmZlY3Qgb2Ygc2VjIGlzIGRpZmZlcmVudCBv biBib3RoIHNpZGVzLiBUaGUgZWZmb3J0DQppcyA8YnI+DQomZ3Q7ICZndDsgbm90IGluY3JlYXNl ZCAmcXVvdDtieSBlcXVhbCBhbW91bnQmcXVvdDsgYnV0IHJhdGhlciAmcXVvdDtpbg0KdGhlIHNh bWUgcHJvcG9ydGlvbi4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgU3VwcG9zZSB0aGF0IGFuIGF0dGFj a2VyIGNvdWxkIGNyYWNrIHRoZSA1OSBiaXQgaGFzaCBpbiBhIGRheQ0Kd2l0aCA8YnI+DQomZ3Q7 ICZndDsgc2VjPTAuIEFkZGluZyBzZWMgPSAxIG1lYW5zIHRoYXQgdGhlIGF0dGFja2VyIHdpbGwg aGF2ZSB0byB0cnkNCjY1NTM2PGJyPg0KJmd0OyAmZ3Q7IHRpbWVzIGFzIG1hbnkga2V5cy4gVGhl IHRpbWUgdG8gY3JhY2sgYmVjb21lcyA2NTUzNiBob3VycywgaS5lLg0KPGJyPg0KJmd0OyAmZ3Q7 IGFib3V0IDcgeWVhcnMuIFRoZSBkZWZlbmRlciB3aWxsIGhhdmUgdG8gdHJ5IDY1NTM2IGluc3Rl YWQgb2YNCm9uZSB0bzxicj4NCiZndDsgJmd0OyBnZXQgdGhlIHJpZ2h0IHNlYywgdGFraW5nIG9u bHkgJm5ic3A7YSBmcmFjdGlvbiBvZiBhIHNlY29uZC4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBh ZnRlciBhdHRhY2tlciBoYXMgY3JhY2tlZCBhIENHQSBhZGRyZXNzLCB0aGVuIGl0IGlzIGluIHRo ZSBzYW1lIDxicj4NCiZndDsgc3RhbmQgYXMgdGhlIGRlZmVuZGVyLiA8YnI+DQomZ3Q7IGRlZmVu ZGVyLCBhcyB3ZWxsIGFzIGF0dGFja2VyLCBoYXMgdG8gdHJ5IG9uZSBieSBvbmUgdG8gZ2V0IHRo ZSA8YnI+DQomZ3Q7IHJpZ2h0IHNlYywgaS5lLiwgdG8gZ2V0IGEgbWF0Y2hpbmcgbGVuZ3RoIG9m IHplcm9zLCA8YnI+DQomZ3Q7IGhvdyBjb21lIGF0dGFja2VyIG5lZWQgZXh0cmEgNjU1MzYgaG91 cnMgYnV0IGRlZmVuZGVyIG9ubHkgbmVlZHMgYQ0KPGJyPg0KJmd0OyBmcmFjdGlvbiBvZiBhIHNl Y29uZD8gPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAxKSBTdGF0dXMgcXVv OiBSRkMgNDk4MiBlYXRzIHRocmVlIGJpdHMgZm9yIFNlYywgbGVhdmluZw0KNTkgYml0cyA8YnI+ DQomZ3Q7ICZndDsgb2YgaGFzaCBsZW5ndGggYWZ0ZXIgYWNjb21tb2RhdGluZyBmb3IgdSBhbmQg ZyBiaXRzIGFzIHdlbGwuDQpUaGUgPGJyPg0KJmd0OyAmZ3Q7IGdvb2Qgd2l0aCB0aGlzIGlzIDxi cj4NCiZndDsgJmd0OyAmZ3Q7IHRoYXQgaXQgbGVhdmVzIG1heGltdW0gc2l6ZSBmb3IgaGFzaC4g VGhlIGJhZCBpcyB0aGF0IGl0DQppcyBsZXNzIDxicj4NCiZndDsgJmd0OyBmbGV4aWJsZSBmb3Ig YWRkaW5nIG1hbnkgbmV3IGhhc2ggYWxnb3JpdGhtcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEkga2luZCBvZiBsaWtlIHRoZSBzdGF0dXMgcXVvLjxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyAyKSBUaGUgcHJvcG9zZWQgbmV3IGFwcHJvYWNoOiBFYXQgYSB0b3Rh bCBvZiBzaXggYml0cywgZm9yDQpTZWMgYW5kPGJyPg0KJmd0OyAmZ3Q7IHRoZSBoYXNoIGFsZ29y aXRobSBpZGVudGlmaWVyLiA1NiBiaXRzIHJlbWFpbi4gVGhlIGdvb2QgaXMgdGhhdA0KdGhpczxi cj4NCiZndDsgJmd0OyBnaXZlcyBtb3JlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGZsZXhpYmlsaXR5 IHRvIGFsbG9jYXRlIGhhc2ggYWxnb3JpdGhtcywgaW5jbHVkaW5nIHRoZSBhYmlsaXR5DQp0byA8 YnI+DQomZ3Q7ICZndDsgaW5kZXBlbmRlbnRseSBjaG9vc2UgU2VjIGFuZCB0aGUgYWxnb3JpdGht LiBUaGUgYmFkIGlzIHRoYXQgdGhlDQo8YnI+DQomZ3Q7IGhhc2ggc2l6ZSBpcyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBkZWNyZWFzZWQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBEZWNy ZWFzZWQgYSBsb3QuIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB3ZSBkbyBnYWluIHRoZSBmbGV4aWJp bGl0eQ0KdG88YnI+DQomZ3Q7ICZndDsgZGVmaW5lIG5ldyBhbGdvcml0aG1zLCB0aGVuIHdlIGNh biBkZWZpbmUgYSBtYW5kYXRvcnktdG8taW1wbGVtZW50DQo8YnI+DQomZ3Q7ICZndDsgYWxnb3Jp dGhtIHRoYXQgaW5jb3Jwb3JhdGVzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSAmcXVvdDtzZWMmcXVv dDsNCnN0cmVuZ3RoZW5pbmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHRoZSBzZWN1cml0eSBvZiBh IGhhc2ggYWxnbyBjYW4gYmUgcm91Z2hseSBlc3RpbWF0ZWQgYnkgbGVuZ3RoIG9mDQppdHMgb3V0 cHV0LDxicj4NCiZndDsgZnJvbSBiaXJ0aGRheSBhdHRhY2ssIHRoYXQgaXMgYWJvdXQgMl4oNTkv Mikgb3IgMl4oNTYvMikodGhlb3JpY2FsDQo8YnI+DQomZ3Q7IGVzdGltYXRlKSwgb3IgbGVzcywg PGJyPg0KJmd0OyBjYW4geW91IGdpdmUgYSBtb3JlIHByZWNpc2Ugb2YgdmFsdWUgb2YgJnF1b3Q7 YSBsb3QmcXVvdDs/IDxicj4NCiZndDsgSSBkb24ndCBzZWUgZmxleGliaWxpdHkgaW4gZGVmaW5p bmcgbWFuZGF0b3J5LXRvLWltcGxlbWVudGluZyBoYXNoDQphbGcgJm5ic3A7IDxicj4NCiZndDsg Jm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IC0tIENocmlzdGlhbiBIdWl0ZW1hPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDwv Zm9udD48L3R0Pg0K --=_alternative 001E383B482579DB_=-- From huitema@microsoft.com Sun Apr 8 23:13: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 D645611E8076 for ; Sun, 8 Apr 2012 23:13:08 -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 jXtaU1gfk-PA for ; Sun, 8 Apr 2012 23:13:08 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id A324111E8074 for ; Sun, 8 Apr 2012 23:12:50 -0700 (PDT) Received: from mail115-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Apr 2012 06:12:49 +0000 Received: from mail115-db3 (localhost [127.0.0.1]) by mail115-db3-R.bigfish.com (Postfix) with ESMTP id 764C24E03CF; Mon, 9 Apr 2012 06:12:49 +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:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail115-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=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3 (MessageSwitch) id 1333951967579891_16120; Mon, 9 Apr 2012 06:12:47 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.226]) by mail115-db3.bigfish.com (Postfix) with ESMTP id 8881AC0053; Mon, 9 Apr 2012 06:12:47 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Apr 2012 06:12:47 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.3]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0283.004; Mon, 9 Apr 2012 06:12:43 +0000 From: Christian Huitema To: "zhou.sujing@zte.com.cn" Subject: RE: RE: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00 Thread-Topic: RE: RE: about security level evaluation of draft-zhou-6man-mhash-cga-00 Thread-Index: AQHNDCUWKLxARtLzBUSojhXcXZo3xpZ+nkYwgAD6AICAANIHoIARoPiAgAAKz4A= Date: Mon, 9 Apr 2012 06:12:42 +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.37] 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: Mon, 09 Apr 2012 06:13:09 -0000 > But I don't agree with you in "each trial is just as complex as finding = a matching CGA address." It is just as complex -- unless of course someone cracks the hash algorithm= . Absent a published crack, we have to assume that the best method for the = attacker is an exhaustive search of salt values. Of course, we have no guarantee that the hash algorithm will not be cracked= at some point in the future, and algorithm agility is indeed a desirable p= roperty. -- Christian Huitema From Tina.Tsou.Zouting@huawei.com Mon Apr 9 11:08: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 39B5C21F8767 for ; Mon, 9 Apr 2012 11:08:20 -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 0DCov4SoRFud for ; Mon, 9 Apr 2012 11:08:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A62A321F8762 for ; Mon, 9 Apr 2012 11:08:19 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB75073; Mon, 09 Apr 2012 14:08:16 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 11:06:41 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 11:06:40 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Tue, 10 Apr 2012 02:06:32 +0800 From: Tina TSOU To: "ipv6@ietf.org" Subject: FW: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Topic: [pim] Comment on draft-lts-pim-hello-mtu? Thread-Index: Ac0TbPRReFB8+MLJQ6Wly2HsnKucXQCys0+AABDgVYA= Date: Mon, 9 Apr 2012 18:06:32 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 09 Apr 2012 18:08:20 -0000 > For IPv6 one could perhaps use RAs? Tina > -----Original Message----- > From: Stig Venaas [mailto:stig@venaas.com] > Sent: Monday, April 09, 2012 11:02 AM > To: Tina TSOU > Cc: pim@ietf.org > Subject: Re: [pim] Comment on draft-lts-pim-hello-mtu? >=20 > On 4/5/2012 1:44 PM, Tina TSOU wrote: > > Dear all, > > May the author of draft-lts-pim-hello-mtu ask people to read the > draft and provide comments? > > > > http://datatracker.ietf.org/doc/draft-lts-pim-hello-mtu/ > > > > Thank you in advance. >=20 > See the minutes I just posted if you like. >=20 > My main comment is that MTU is important for other protocols too, and > also for traffic/data, so I'm wondering if it would be better to do it > with some more general protocol. Maybe BFD or in the IGP? > For IPv6 one could perhaps use RAs? >=20 > Stig >=20 > > > > > > Best Regards, > > Tina TSOU > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim From dthaler@microsoft.com Mon Apr 9 17:08: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 277D321F8758 for ; Mon, 9 Apr 2012 17:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.659 X-Spam-Level: X-Spam-Status: No, score=-103.659 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 Q5rgzwRmROwY for ; Mon, 9 Apr 2012 17:08:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 79E2121F8757 for ; Mon, 9 Apr 2012 17:08:50 -0700 (PDT) Received: from mail105-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 00:08:49 +0000 Received: from mail105-va3 (localhost [127.0.0.1]) by mail105-va3-R.bigfish.com (Postfix) with ESMTP id 2F1D5A04AD; Tue, 10 Apr 2012 00:08:49 +0000 (UTC) X-SpamScore: -12 X-BigFish: VS-12(zz936eK1432N98dKzz1202hzzz2fh2a8h668h839h944hd25h) 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 (mail105-va3: 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 mail105-va3 (localhost.localdomain [127.0.0.1]) by mail105-va3 (MessageSwitch) id 1334016526628864_22868; Tue, 10 Apr 2012 00:08:46 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.250]) by mail105-va3.bigfish.com (Postfix) with ESMTP id 94118260071; Tue, 10 Apr 2012 00:08:46 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 00:08:46 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 10 Apr 2012 00:08:45 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 9 Apr 2012 17:08:45 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Mon, 9 Apr 2012 17:08:45 -0700 From: Dave Thaler To: Brian E Carpenter Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNC+wBSVlewb1jE0uYOWOUBxq41JZ/ZbAAgBPdqEA= Date: Tue, 10 Apr 2012 00:08:45 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> In-Reply-To: <4F726C9E.50107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] 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, 10 Apr 2012 00:08:51 -0000 Brian Carpenter writes: > On 2012-03-27 20:33, Brian Haberman wrote: > ... > >=20 > > A. Prefer public addresses over privacy addresses > >=20 > > 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. That wording would be confusing, as there's a distinction between an (unprivileged) user and a (privileged) admin. It would be a security vulnerability if an unprivileged user could change a system-wide setting. > There SHOULD be a network manager option to change this preference. Similarly, the term "network manager" is also confusing. It would be a sec= urity vulnerability if an untrusted user on the network could change a system-wide setting loca= lly. > The rationale for this is that we need privacy by default in shipped prod= ucts, with the > ability for the person deploying the product to override this. I (and I gather from the +1's that many others) agree with having a config = knob to reverse the preference. The doc already has text about that on a *per-app= * basis, but not system-wide. The wording I propose to add is: "There SHOULD be an administrative option to change this preference, if= the=20 implementation supports privacy addresses. If there is no such option,= there=20 MUST be an administrative option to disable privacy addresses." -Dave From tmacaulay@2keys.ca Mon Apr 9 18:52:48 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 8205811E8073 for ; Mon, 9 Apr 2012 18:52:48 -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 wCnfM7+ttDLU for ; Mon, 9 Apr 2012 18:52:47 -0700 (PDT) Received: from mail.2keys.ca (mail.2keys.ca [72.1.200.74]) by ietfa.amsl.com (Postfix) with ESMTP id B8F6C21F863F for ; Mon, 9 Apr 2012 18:52:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.2keys.ca (Postfix) with ESMTP id DFBCF281160 for ; Mon, 9 Apr 2012 21:47:26 -0400 (EDT) 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 wIacpijitaG0 for ; Mon, 9 Apr 2012 21:47:22 -0400 (EDT) Received: from [192.168.1.6] (CPE002436bad7a9-CM001868e60058.cpe.net.cable.rogers.com [99.241.179.111]) by mail.2keys.ca (Postfix) with ESMTPSA id 3C9EA281136 for ; Mon, 9 Apr 2012 21:47:22 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Apr 2012 21:52:40 -0400 Subject: Re: draft-macaulay-6man-packet-stain-00 From: Tyson Macaulay To: ipv6 Message-ID: Thread-Topic: draft-macaulay-6man-packet-stain-00 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: Tue, 10 Apr 2012 01:52:48 -0000 Indeed, when I presented in Paris there were excellent comments about fragmentation. The draft is being revised to express that the approach (staining) is intended for use within a "domain of control" as Joel put it, or from a domain, such as a carrier domain, downstream to a subscribing enterprise domain. The intent was not to stain packets, let them find their way across the internet, and expect nothing to break. I acknowledge that the current draft, and my even presentation, lends itself to that interpretation. As for the flow label option within a domain of control, that is certainly another possibility we considered but then rejected because of the move towards using the flow label for load balancing. Within an Enterprise domain (all flows based on ULAs?), then perhaps the flow label could be re-purposed for either threat/reputation intelligence or as a form of very light-weight layer 3 authentication for end-points with little memory or processing power.(?) For instance, if the value (stain) in the flow label (or Destination Option) is not the expected value - reject the packet. At this time I am considering extracting and clarifying the problem statement (timely delivery of threat/reputation intelligence) from the draft, and re-issuing it as an informational draft. Just see get that part clear. There appears to be more than one way that IPv6 can address this matter, assuming we agree on the problem. Tyson > > > > >Message: 3 >Date: Sun, 08 Apr 2012 12:33:59 -0400 >From: Victor Kuarsingh >To: Brian E Carpenter , Joel jaeggli > >Cc: 6man >Subject: Re: draft-macaulay-6man-packet-stain-00 >Message-ID: >Content-Type: text/plain; charset="US-ASCII" > > > >On 12-04-08 3:10 AM, "Brian E Carpenter" >wrote: > >>On 2012-04-07 17:17, Joel jaeggli wrote: >>> I hesitate to suggest this because I'll probably turn into a pillar of >>> salt at some point for harping on it. however... >> >>Just don't look back (towards IPv4). >> >>> >>> Getting new extension headers generally parsed is a high bar to get >>> over. >> >>I have another concern; this draft appears to state that some >>middlebox inserts an extension header into a packet on the fly: >> "IPv6 packet staining support consists of labeling datagrams with >> security reputation information through the addition of an IPv6 >> destination option in the packet header by packet manipulation >> devices (PMDs) in the carrier or enterprise network." >> >>I'm not aware of any provision in RFC 2460 allowing this, or of any >>other extension header that is inserted by a middlebox. The implications >>for MTU size and fragmentation are clear. > >This point was brought up in the WG meeting which noted issues with >fragmentation. I think it was clear based on numbers folks at the mic >that inserting an extension header mid-stream would result in negative >behaviours. > >> >>> That said within one domain of control you might be able to fit a >>> subset of the information you're looking to carry into the 20 bits >>> available in flow label. 6437 probably provides enough >>>cover/instruction >>> to allow for that. >> >>Given that the first paragraph of the Introduction to the draft is almost >>identical to the same paragraph in 6437, you may be on to something. >>However, it's only conformant if (a) the resulting values belong to a >>reasonably uniform distribution and are hard to predict and (b) the >>method >>MUST NOT be used for packets whose flow label is already non-zero. > >The point of using the flow label seems valid. The author will need to >re-evaluate the requirements as I believe it was noted in the WG >presentation that the Flow Label seemed to be too restrictive (size) for >this function (packet staining). If the staining can be bounded by the >size of the flow label then perhaps the author can re-focus on using it >for this function (packet staining). > > >Victor K > From wwwrun@rfc-editor.org Mon Apr 9 19:31: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 7E9EB11E8099; Mon, 9 Apr 2012 19:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.15 X-Spam-Level: X-Spam-Status: No, score=-102.15 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 aIFfcV9nkh+a; Mon, 9 Apr 2012 19:31:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E2AB511E8074; Mon, 9 Apr 2012 19:31:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ADC596218A; Mon, 9 Apr 2012 19:31:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6564 on A Uniform Format for IPv6 Extension Headers From: rfc-editor@rfc-editor.org Message-Id: <20120410023119.ADC596218A@rfc-editor.org> Date: Mon, 9 Apr 2012 19:31:19 -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: Tue, 10 Apr 2012 02:31:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6564 Title: A Uniform Format for IPv6 Extension Headers Author: S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia Status: Standards Track Stream: IETF Date: April 2012 Mailbox: suresh.krishnan@ericsson.com, jhw@apple.com, ek@google.com, Jim_Hoagland@symantec.com, manav.bhatia@alcatel-lucent.com Pages: 6 Characters: 12879 Updates: RFC2460 I-D Tag: draft-ietf-6man-exthdr-06.txt URL: http://www.rfc-editor.org/rfc/rfc6564.txt In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. [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.e.carpenter@gmail.com Mon Apr 9 23:53: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 E3AC621F8745 for ; Mon, 9 Apr 2012 23:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.654 X-Spam-Level: X-Spam-Status: No, score=-101.654 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 yMWLy-CuqaXk for ; Mon, 9 Apr 2012 23:53:11 -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 BBA2021F8741 for ; Mon, 9 Apr 2012 23:53:10 -0700 (PDT) Received: by werb10 with SMTP id b10so3635274wer.31 for ; Mon, 09 Apr 2012 23:53:10 -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=88Vowe5NWEjZoLui+6wedd2SYyveUH3F6WMwqyKtRsk=; b=by/HXxRtMBHcBFsbiZyUZ8pt6+OtntIesGiBwp0MlJDFlq3XBgXZyypRn2EvFLAPP7 3MqUrSn6b94VzHKZeR7iE0K8MLNe2chFC3Sj8CPukEw/xwD8ONzqkotJXF03Slnqi6+S yBllHFBkuobWzkHcFQpt2i6l+KG2WAVlVVVkZLRvxSOChSyw6EXE9K5x5CRxbk2ds+GZ RXYAyD5J9ji2CpHKktYkffnjwX9AXSnvEI0Vr0goDhgUL/l9LU3P6Ww+FKjKCwwxQ/x5 G13D1EDiJKSyEFcxkb1Xb7WSEfPaOm8avXAj3ioetK/SLABIZmlj520+IBBnEG0ra6ef iYwg== Received: by 10.180.82.136 with SMTP id i8mr4067586wiy.19.1334040789997; Mon, 09 Apr 2012 23:53:09 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-219-159.as13285.net. [2.102.219.159]) by mx.google.com with ESMTPS id k6sm35673765wiy.7.2012.04.09.23.53.08 (version=SSLv3 cipher=OTHER); Mon, 09 Apr 2012 23:53:09 -0700 (PDT) Message-ID: <4F83D8D0.5030402@gmail.com> Date: Tue, 10 Apr 2012 07:53:04 +0100 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: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.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, 10 Apr 2012 06:53:13 -0000 below... On 2012-04-10 01:08, Dave Thaler wrote: > Brian Carpenter writes: >> 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. > > That wording would be confusing, as there's a distinction between an > (unprivileged) user and a (privileged) admin. It would be a security > vulnerability if an unprivileged user could change a system-wide setting. > >> There SHOULD be a network manager option to change this preference. > > Similarly, the term "network manager" is also confusing. It would be a security vulnerability > if an untrusted user on the network could change a system-wide setting locally. > >> 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. > > I (and I gather from the +1's that many others) agree with having a config knob to > reverse the preference. The doc already has text about that on a *per-app* basis, > but not system-wide. The wording I propose to add is: > > "There SHOULD be an administrative option to change this preference, if the > implementation supports privacy addresses. If there is no such option, there > MUST be an administrative option to disable privacy addresses." > > -Dave That works for me. Perhaps there also needs to be a general statement in the security considerations that all administrative changes and options MUST be secured against illicit use. Brian From internet-drafts@ietf.org Tue Apr 10 00:12: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 067BA11E8074; Tue, 10 Apr 2012 00:12: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 4F2ztYNxsCMg; Tue, 10 Apr 2012 00:12:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C5011E8072; Tue, 10 Apr 2012 00:12:43 -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-enhanced-dad-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410071243.558.78218.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 00:12:43 -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, 10 Apr 2012 07:12:44 -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 : Enhanced Duplicate Address Detection Author(s) : Rajiv Asati Hemant Singh Wes Beebee Eli Dart Wes George Carlos Pignataro Filename : draft-ietf-6man-enhanced-dad-00.txt Pages : 11 Date : 2012-04-06 Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-enhanced-dad-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-enhanced-dad-00.txt From pars.mutaf@gmail.com Tue Apr 10 06:24: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 D706E21F85D0 for ; Tue, 10 Apr 2012 06:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.331 X-Spam-Level: X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[AWL=0.267, 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 83Guk-ey0D1C for ; Tue, 10 Apr 2012 06:24:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0822E21F85B6 for ; Tue, 10 Apr 2012 06:24:34 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8220220obb.31 for ; Tue, 10 Apr 2012 06:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qFFhVqDid4xEpZaTiDJJUUe+BZAK74VJqMp7lD7ysIQ=; b=IfVAVpKRyJNRlKmb0kritN32FkxTddXnZhUEbVZe5KJ/0gvnIoqd3K3lg6xyVPXRxP 7xpsV6OlP3WQfsxMtRvsk3aFshAzLGeb9iGTCqbgsoBwXX3XIMf5qPYoa5ZejCHwofdb +wgEucCklFhzhgs0sHLsvIGH7r8gIld0DWt5ot20oK7/HBopuEn54RlllDTkVJs6mXyB 270PId8fS7KUYY7VeaSJA1oKdXvvULX644+ck6g6ZKl4MwqCB6OkE8EjJs7tnidaN6XU u8i2CcE/htvGMvG+vQv3T3P2k4QW6Z+azLNest2y2G6Ot9JEUOxsMZRtS3oVqgnkl2Wm zMIw== MIME-Version: 1.0 Received: by 10.182.77.167 with SMTP id t7mr16075193obw.10.1334064274657; Tue, 10 Apr 2012 06:24:34 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 06:24:34 -0700 (PDT) Date: Tue, 10 Apr 2012 16:24:34 +0300 Message-ID: Subject: Why one Internet? From: Pars Mutaf To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=f46d0444721332d31504bd530b52 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, 10 Apr 2012 13:24:36 -0000 --f46d0444721332d31504bd530b52 Content-Type: text/plain; charset=ISO-8859-1 Hi, In my opinion, we can add one more Internet when necessary, then another one etc. We can have as many Internets as we need, all different. We just need a *network of Internets*. The first (current) Internet is an IPv4 Internet. The second Internet can be an IPv4 Internet too. In this case we would have 2 IPv4 Internets. Obviously, in this case, we would have the same addresses used by two different nodes in the two Internets. I think it is possible to locate the node we need. I am not here to discuss these details. The second Internet can be an IPv6 Internet. The second Internet can be a IPv7 Internet. The second Internet can be IPv6 but we may have a third one which is IPv7 etc. We just need a network of Internets, all possibly different. Pars http://content-based-science.org/ --f46d0444721332d31504bd530b52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

In my opinion, we can= add one more Internet when necessary, then another one etc.=A0

We can have as many Internets as we need, all dif= ferent.=A0

We just need a *network of Internets*.=A0

The first (current) Internet is an IPv4= Internet.
The second Internet can be an IPv4 Internet too.= In this case we would have 2 IPv4 Internets.=A0
Obviously, in this case, we would have the same addresses used b= y two different nodes in=A0
the=A0two Internets. I think it= is possible to locate the node we need. I am not here to discuss=A0
<= div style> these details.=A0

The second Internet = can be an IPv6 Internet.=A0

The second= Internet can be a IPv7 Internet.=A0

T= he second Internet can be IPv6 but we may have a third one which is IPv7 et= c.=A0

We just need a network of Internets, all po= ssibly different.=A0

Pars
--f46d0444721332d31504bd530b52-- From randy@psg.com Tue Apr 10 06:50: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 9A6A021F863F for ; Tue, 10 Apr 2012 06:50: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 o8j15RWZDhU6 for ; Tue, 10 Apr 2012 06:50:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1D21F85F4 for ; Tue, 10 Apr 2012 06:50:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHbST-0001t2-P7; Tue, 10 Apr 2012 13:50:09 +0000 Date: Tue, 10 Apr 2012 22:50:08 +0900 Message-ID: From: Randy Bush To: Pars Mutaf Subject: Re: Why one Internet? In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 10 Apr 2012 13:50:11 -0000 > In my opinion, we can add one more Internet when necessary, then another > one etc. > > We can have as many Internets as we need, all different. > ... in the words of vince perriello, send code randy From pars.mutaf@gmail.com Tue Apr 10 06:51: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 0989111E80AF for ; Tue, 10 Apr 2012 06:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.240, 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 QvOq4oKd9YQs for ; Tue, 10 Apr 2012 06:51:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8889F21F863E for ; Tue, 10 Apr 2012 06:51:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8253553obb.31 for ; Tue, 10 Apr 2012 06:51:23 -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=pCw2TQYSYVsO/s5PXyvkI8rtESTAzKDyztvq6DPcWSM=; b=LmRKaxrkP7NV/KRzJHdE/GyluRiqJCjYI+5cXmXrySRaC/Ogtm9YETzkHlCq1FKdsw 5Rpd2vWwDMvNMFBKXHhxpRxcqya+nKvdlLpfduF0GMSizsZ+qysSwPe+oqaLN5DYayJm lz47KWtqhRdGB19PGX6EjZwFlzaLq6/53HHkcUQPFx9KHpL+JqxLIyjKHNSOEn2xjCdY zKyju+pQtkz8m8j+TBg5ZHUjRGoDQM6lWnLAkx7g3D29+Lm/yIKFbGQRL5wZvgdPdsxH e2HW9bo+eThsWvLtfV8pRISaL54/TK3wESVEMNqXL1yrwFsfSF4c2698oC3y2UyKZgPg fGXA== MIME-Version: 1.0 Received: by 10.182.174.101 with SMTP id br5mr16490387obc.0.1334065883204; Tue, 10 Apr 2012 06:51:23 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 06:51:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 16:51:23 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: Randy Bush Content-Type: multipart/alternative; boundary=e89a8f646729134d6304bd536bc6 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, 10 Apr 2012 13:51:24 -0000 --e89a8f646729134d6304bd536bc6 Content-Type: text/plain; charset=ISO-8859-1 Why me? On Tue, Apr 10, 2012 at 4:50 PM, Randy Bush wrote: > > In my opinion, we can add one more Internet when necessary, then another > > one etc. > > > > We can have as many Internets as we need, all different. > > ... > > in the words of vince perriello, send code > > randy > --e89a8f646729134d6304bd536bc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why me?

On Tue, Apr 10, 2012 at 4:50 PM, = Randy Bush <randy@psg= .com> wrote:
> In my opinion, we can add one more Internet when nec= essary, then another
> one etc.
>
> We can have as many Internets as we need, all different.
> ...

in the words of vince perriello, send code

randy

--e89a8f646729134d6304bd536bc6-- From randy@psg.com Tue Apr 10 06:53: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 8E50D21F85FD for ; Tue, 10 Apr 2012 06:53:29 -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 jtcNM6koDzix for ; Tue, 10 Apr 2012 06:53:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C79EF21F85DB for ; Tue, 10 Apr 2012 06:53:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHbVg-0001tj-HT; Tue, 10 Apr 2012 13:53:28 +0000 Date: Tue, 10 Apr 2012 22:53:27 +0900 Message-ID: From: Randy Bush To: Pars Mutaf Subject: Re: Why one Internet? In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 10 Apr 2012 13:53:29 -0000 > Why me? because you are the nut case who proposed it > > On Tue, Apr 10, 2012 at 4:50 PM, Randy Bush wrote: > > > > In my opinion, we can add one more Internet when necessary, then another > > > one etc. > > > > > > We can have as many Internets as we need, all different. > > > ... > > > > in the words of vince perriello, send code > > > > randy > > From pars.mutaf@gmail.com Tue Apr 10 06:58: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 8116F21F865C for ; Tue, 10 Apr 2012 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.218, 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 lCndldp2oHvQ for ; Tue, 10 Apr 2012 06:58:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D23DD21F865B for ; Tue, 10 Apr 2012 06:58:50 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8262368obb.31 for ; Tue, 10 Apr 2012 06:58:50 -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=Um99f9YLJhVikwFE/8DUXOJYm50proBYmmy00UubVrk=; b=wQFZKWjSfDPjdF7ma964GeyS8OIrE2T5+nkLrfchEGxTyS78hw4W1zVQTH0OP3v477 vJNyBGDiJBh73WUhc1aogw6+As/gBD5KC1AFDq8jONFN0eBz7kFB+i1tVNflvo06ZmMb ymC0bXDvrN8jiejSWnyohAq08mvso3snaBJ3ntrknATrXBloHT/OJrmxBCgGp67xa6RO qhnZ1LJdeqph5SWnVF0wmgIRsuUuXkcCqyelCHO6jnmANR0YQa8EVg4TYvUlhYFK02b8 C0ieQ8WdkidexKh3Gczv5+RbkHcuOCI2sVlQZ8LaVELF5sm9xnjfH7UdDYdbuDH30bFT m6tw== MIME-Version: 1.0 Received: by 10.182.86.200 with SMTP id r8mr16480304obz.20.1334066330531; Tue, 10 Apr 2012 06:58:50 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 06:58:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 16:58:50 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: Randy Bush Content-Type: multipart/alternative; boundary=f46d0444e9a3bcf83904bd53857f 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, 10 Apr 2012 13:58:57 -0000 --f46d0444e9a3bcf83904bd53857f Content-Type: text/plain; charset=ISO-8859-1 No sir "not questioning" is being the nut case. Sorry. On Tue, Apr 10, 2012 at 4:53 PM, Randy Bush wrote: > > Why me? > > because you are the nut case who proposed it > > > > On Tue, Apr 10, 2012 at 4:50 PM, Randy Bush wrote: > > > > > > In my opinion, we can add one more Internet when necessary, then > another > > > > one etc. > > > > > > > > We can have as many Internets as we need, all different. > > > > ... > > > > > > in the words of vince perriello, send code > > > > > > randy > > > > --f46d0444e9a3bcf83904bd53857f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No sir "not questioning" is being the nut case. Sorry.=A0

=
On Tue, Apr 10, 2012 at 4:53 PM, Randy Bush <randy@psg.com> wrote:
> Why me?

because you are the nut case who proposed it
>
> On Tue, Apr 10, 2012 at 4:50 PM, Randy Bush <randy@psg.com> wrote:
>
> > > In my opinion, we can add one more Internet when necessary, = then another
> > > one etc.
> > >
> > > We can have as many Internets as we need, all different.
> > > ...
> >
> > in the words of vince perriello, send code
> >
> > randy
> >

--f46d0444e9a3bcf83904bd53857f-- From christopher.morrow@gmail.com Tue Apr 10 07: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 B91E611E80D5 for ; Tue, 10 Apr 2012 07:04:13 -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 fWNuyTKjeFaM for ; Tue, 10 Apr 2012 07:04:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3496D11E80CA for ; Tue, 10 Apr 2012 07:04:13 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8268300obb.31 for ; Tue, 10 Apr 2012 07:04:12 -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=nFM07+qf5ILTEbffeVAo7odnIJS9vAW8F305S0UMhNk=; b=VPsQhwn/UV5LgOAAGBEc3oG9xzZrr6KYWSravBzTignb5myvIG1PQhTG3tdlf1uR5A Oe0spNU3zPv0kDb605OKeoTfnxpsdWzEiCm4cEYNQrphiosyFFFgz2QPFMMQiKqL8tEZ Y1QYnQ1j5FPnOtfZK6821SMF7UCmAxAKdJLb9Op8VqYrE8mbyiel6tQitN9HTjysykaw dBWYclWg+iAPGUv2d4aH3m6T0QITT6852nvBFJC4iKJ3w8x/uhFch/yFBBTvtSXJE6jD fwTFdJzqCxePMVkaMlEQ0drozGVeyaUxa8/bU1OFfDX3ACLRAzQQszDVA1nuWFoRspSz hZqw== MIME-Version: 1.0 Received: by 10.182.159.41 with SMTP id wz9mr15973555obb.69.1334066652790; Tue, 10 Apr 2012 07:04:12 -0700 (PDT) Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 07:04:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 10:04:12 -0400 Message-ID: Subject: Re: Why one Internet? From: Christopher Morrow To: Pars Mutaf 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, 10 Apr 2012 14:04:13 -0000 plonk On Tue, Apr 10, 2012 at 9:58 AM, Pars Mutaf wrote: > No sir "not questioning" is being the nut case. Sorry. > > > On Tue, Apr 10, 2012 at 4:53 PM, Randy Bush wrote: >> >> > Why me? >> >> because you are the nut case who proposed it >> > >> > On Tue, Apr 10, 2012 at 4:50 PM, Randy Bush wrote: >> > >> > > > In my opinion, we can add one more Internet when necessary, then >> > > > another >> > > > one etc. >> > > > >> > > > We can have as many Internets as we need, all different. >> > > > ... >> > > >> > > in the words of vince perriello, send code >> > > >> > > randy >> > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From lixia@cs.ucla.edu Tue Apr 10 07:09: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 6AA2A11E80D9 for ; Tue, 10 Apr 2012 07:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 C7tM1qupihoX for ; Tue, 10 Apr 2012 07:09:21 -0700 (PDT) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id A609411E80D6 for ; Tue, 10 Apr 2012 07:09:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 7194C39E800C; Tue, 10 Apr 2012 07:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F8cayJKZg2B; Tue, 10 Apr 2012 07:09:20 -0700 (PDT) Received: from [10.0.1.2] (cpe-98-154-15-232.socal.res.rr.com [98.154.15.232]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 40C0639E8008; Tue, 10 Apr 2012 07:09:20 -0700 (PDT) Subject: Re: Why one Internet? Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_038FF8A8-BDD5-4BE3-863B-60FEDADDBFC7" From: Lixia Zhang In-Reply-To: Date: Tue, 10 Apr 2012 07:09:19 -0700 Message-Id: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> References: To: Pars Mutaf 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, 10 Apr 2012 14:09:22 -0000 --Apple-Mail=_038FF8A8-BDD5-4BE3-863B-60FEDADDBFC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 the Internet is a means to communicate. and the market drives for most effective/efficient/economical = communication systems (there are tradeoffs between the adjectives) wonder if you could help explain how your picture of "network of = Internets" would be more effective and economical (than what we have = now) Lixia On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: > Hi, >=20 > In my opinion, we can add one more Internet when necessary, then = another one etc.=20 >=20 > We can have as many Internets as we need, all different.=20 >=20 > We just need a *network of Internets*.=20 >=20 > The first (current) Internet is an IPv4 Internet. > The second Internet can be an IPv4 Internet too. In this case we would = have 2 IPv4 Internets.=20 > Obviously, in this case, we would have the same addresses used by two = different nodes in=20 > the two Internets. I think it is possible to locate the node we need. = I am not here to discuss=20 > these details.=20 >=20 > The second Internet can be an IPv6 Internet.=20 >=20 > The second Internet can be a IPv7 Internet.=20 >=20 > The second Internet can be IPv6 but we may have a third one which is = IPv7 etc.=20 >=20 > We just need a network of Internets, all possibly different.=20 >=20 > Pars > http://content-based-science.org/ > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_038FF8A8-BDD5-4BE3-863B-60FEDADDBFC7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 the Internet is a means to communicate.
and the market drives for most effective/efficient/economical communication systems (there are tradeoffs between the adjectives)
wonder if you could help explain how your picture of "network of Internets" would be more effective and economical (than what we have now)

Lixia

On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote:

Hi,

In my opinion, we can add one more Internet when necessary, then another one etc. 

We can have as many Internets as we need, all different. 

We just need a *network of Internets*. 

The first (current) Internet is an IPv4 Internet.
The second Internet can be an IPv4 Internet too. In this case we would have 2 IPv4 Internets. 
Obviously, in this case, we would have the same addresses used by two different nodes in 
the two Internets. I think it is possible to locate the node we need. I am not here to discuss 
these details. 

The second Internet can be an IPv6 Internet. 

The second Internet can be a IPv7 Internet. 

The second Internet can be IPv6 but we may have a third one which is IPv7 etc. 

We just need a network of Internets, all possibly different. 

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

--Apple-Mail=_038FF8A8-BDD5-4BE3-863B-60FEDADDBFC7-- From brian.e.carpenter@gmail.com Tue Apr 10 07:31: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 17AC911E80C9 for ; Tue, 10 Apr 2012 07:31:16 -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 CZGuOAoqLMyZ for ; Tue, 10 Apr 2012 07:31:15 -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 E372611E80BE for ; Tue, 10 Apr 2012 07:31:14 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1318685eaa.31 for ; Tue, 10 Apr 2012 07:31: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gjWGAwred3mh16L1DC2vAvJzSYYt0Z5owwVSdUrgteo=; b=JJTbBQTeirt4G3+Tza8Pk41S1Ik68FixKLulHrgel2mGNetTHhz2gogrvlcq+tPvRt JhM2ibXkPJd/PrAk1vCiUiX59YUNnqaciA+uU8kd4+SJ/ieTwprBy/IzaoLKIJk4Sg5N m83LnJ88Ll7w79L+6xZDGdxxVUedq3Ftyaf4pkgrPMjecY9NAS56SzxlZGRUuxV2DkVp EBfBupvFvIX7iQrWh0/ZbjngySFize+ewFgNkrO/r9gLln27EeU2NhcFgvI/P54uHcv6 Vf0euVuhJPK+ygtMMHcLapJY8yuSbhWt+Z7K8l8FuK7e3qX4iXbSP2zziTg4YXDCF7Ql IZaA== Received: by 10.213.32.5 with SMTP id a5mr731237ebd.35.1334068274008; Tue, 10 Apr 2012 07:31:14 -0700 (PDT) Received: from [192.168.33.230] (lapwing-gw-1.csx.cam.ac.uk. [131.111.1.66]) by mx.google.com with ESMTPS id x4sm47536335eef.10.2012.04.10.07.31.12 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 07:31:13 -0700 (PDT) Message-ID: <4F844428.7050408@gmail.com> Date: Tue, 10 Apr 2012 15:31:04 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lixia Zhang Subject: Re: Why one Internet? References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> In-Reply-To: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> 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, 10 Apr 2012 14:31:16 -0000 Lixia, The original note says "I think it is possible to locate the node we need." So, the idea is apparently not to divide the Internet - it is simply to deal with the fact that addresses would be ambiguous. Since we have 15 years experience of the pain caused by ambiguous addresses, and a perfectly good 128 bit address space that avoids any need for ambiguous addresses, I don't see the point. It isn't even worth sending the code. Pars, Your original note also says "I am not here to discuss these details." Sorry, but in the IETF it's *exactly* the details that we must discuss; that's our job. We've been doing so since 1992 to my personal knowledge. Regards Brian On 2012-04-10 15:09, Lixia Zhang wrote: > the Internet is a means to communicate. > and the market drives for most effective/efficient/economical communication systems (there are tradeoffs between the adjectives) > wonder if you could help explain how your picture of "network of Internets" would be more effective and economical (than what we have now) > > Lixia > > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: > >> Hi, >> >> In my opinion, we can add one more Internet when necessary, then another one etc. >> >> We can have as many Internets as we need, all different. >> >> We just need a *network of Internets*. >> >> The first (current) Internet is an IPv4 Internet. >> The second Internet can be an IPv4 Internet too. In this case we would have 2 IPv4 Internets. >> Obviously, in this case, we would have the same addresses used by two different nodes in >> the two Internets. I think it is possible to locate the node we need. I am not here to discuss >> these details. >> >> The second Internet can be an IPv6 Internet. >> >> The second Internet can be a IPv7 Internet. >> >> The second Internet can be IPv6 but we may have a third one which is IPv7 etc. >> >> We just need a network of Internets, all possibly different. >> >> Pars >> http://content-based-science.org/ >> -------------------------------------------------------------------- >> 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 hagen@jauu.net Tue Apr 10 07:45: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 D42D821F8699 for ; Tue, 10 Apr 2012 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_ENC_UTF8=0.152] 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 K8STdvOPBBKs for ; Tue, 10 Apr 2012 07:45:20 -0700 (PDT) Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF3721F869E for ; Tue, 10 Apr 2012 07:45:19 -0700 (PDT) Received: by geheimer.internetendpunkt.de (Postfix, from userid 33) id 96A09F44181; Tue, 10 Apr 2012 16:45:17 +0200 (CEST) To: Brian E Carpenter Subject: Re: Why one =?UTF-8?Q?Internet=3F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 10 Apr 2012 16:45:17 +0200 From: Hagen Paul Pfeifer In-Reply-To: <4F844428.7050408@gmail.com> References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> Message-ID: X-Sender: hagen@jauu.net User-Agent: RoundCube Webmail/0.1-rc1 Cc: ipv6@ietf.org, Lixia Zhang 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, 10 Apr 2012 14:45:20 -0000 On Tue, 10 Apr 2012 15:31:04 +0100, Brian E Carpenter wrote: > Your original note also says "I am not here to discuss these details." > Sorry, > but in the IETF it's *exactly* the details that we must discuss; that's our > job. We've been doing so since 1992 to my personal knowledge. > > Regards > Brian Brian: Pars is a troll, don't feed him. See MANET WG postings ... Hagen From pars.mutaf@gmail.com Tue Apr 10 07:57: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 8242F21F867A for ; Tue, 10 Apr 2012 07:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 Tx04Il0-eTdC for ; Tue, 10 Apr 2012 07:57:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8321F866E for ; Tue, 10 Apr 2012 07:57:25 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8332273obb.31 for ; Tue, 10 Apr 2012 07:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BnnQBucAZ5uqnNMbl9wn7nIZNJJLjMaIFpmjZm4uquU=; b=fUdeLEsvlOJBZQazzfiWUNUI4fBMS/VnlsI2LrGqwMGITj5ZtOerR1mxnGek5XYeZv cat0CrhUR2tRroJ+ElfSyyBOlie878rkMtT5acmRi5F5yck0ceypY0b3aupCXlfyHhr7 gtOZCn7PosD4149v5sH8Rc9u0fqt9bphqFIH4TphP9NYvU0c5Aderw3Iw08TrZX23kU3 rSOXhBIrXedGZQU1oqlitnIZfJQxcC5nt5MAIQJIYiLQ9PKmwOrvtQTNZ0xPXGs+dmEz DNIe3vpyo4bcOuGdOYgMI5Tv0oPGZPlDH+JNOMHYOqX98w8FQt/MT/VOrQlTWln8WQKA Rdyg== MIME-Version: 1.0 Received: by 10.182.114.70 with SMTP id je6mr16769446obb.30.1334069843231; Tue, 10 Apr 2012 07:57:23 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 07:57:23 -0700 (PDT) In-Reply-To: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> Date: Tue, 10 Apr 2012 17:57:23 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: Lixia Zhang Content-Type: multipart/alternative; boundary=f46d0444746b1c845704bd5457cb 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, 10 Apr 2012 14:57:26 -0000 --f46d0444746b1c845704bd5457cb Content-Type: text/plain; charset=ISO-8859-1 I am here to question: My question is why IPv6 is the end of the road. We shouldn't give all the responsibility to a few persons. We should not be dependent on their decisions. If the transition to a complete IPv6 network is not possible, then we can add a new Internet. It can be IPv4, IPv6, or even IPv7. Pars On Tue, Apr 10, 2012 at 5:09 PM, Lixia Zhang wrote: > the Internet is a means to communicate. > and the market drives for most effective/efficient/economical > communication systems (there are tradeoffs between the adjectives) > wonder if you could help explain how your picture of "network of > Internets" would be more effective and economical (than what we have now) > > Lixia > > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: > > Hi, > > In my opinion, we can add one more Internet when necessary, then another > one etc. > > We can have as many Internets as we need, all different. > > We just need a *network of Internets*. > > The first (current) Internet is an IPv4 Internet. > The second Internet can be an IPv4 Internet too. In this case we would > have 2 IPv4 Internets. > Obviously, in this case, we would have the same addresses used by two > different nodes in > the two Internets. I think it is possible to locate the node we need. I am > not here to discuss > these details. > > The second Internet can be an IPv6 Internet. > > The second Internet can be a IPv7 Internet. > > The second Internet can be IPv6 but we may have a third one which is IPv7 > etc. > > We just need a network of Internets, all possibly different. > > Pars > http://content-based-science.org/ > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > --f46d0444746b1c845704bd5457cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am here to question:=A0

My question is why IPv6 is the= end of the road.=A0

We shouldn't give all the= responsibility to a few persons.
We should not be dependent on t= heir decisions.=A0

If the transition to a complete IPv6 network is not pos= sible, then we can add a new Internet.=A0It can be IPv4, IPv6, or even IPv7= .=A0

Pars

On Tue, Apr 10, 2012 at 5:09 PM, Lixia Zhang <lixia@cs.ucla.edu> wrote:
the Internet is a means to communicate.=
and the market drives for most effective/efficient/economical communic= ation systems (there are tradeoffs between the adjectives)
wonder if you could help explain how your picture of "network of Inter= nets" would be more effective and economical (than what we have now)

Lixi= a

On Apr 10, 2012, at= 6:24 AM, Pars Mutaf wrote:

=
Hi,

In my opinion, w= e can add one more Internet when necessary, then another one etc.=A0

We can have as many Internets as we need, all different= .=A0

We just need a *network of Internets*.=A0
The first (current) Internet is an IPv4 Internet.
The= second Internet can be an IPv4 Internet too. In this case we would have 2 = IPv4 Internets.=A0
Obviously, in this case, we would have the same addresses used by two = different nodes in=A0
the=A0two Internets. I think it is possible= to locate the node we need. I am not here to discuss=A0
these details.=A0

The second Internet can be an IP= v6 Internet.=A0

The second Internet can be a IPv7 = Internet.=A0

The second Internet can be IPv6 but w= e may have a third one which is IPv7 etc.=A0

We just need a network of Internets, all possibly diffe= rent.=A0

Pars
--------------------------------------------------------------------
IET= F IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6
--------------------------------------------------------------------


--f46d0444746b1c845704bd5457cb-- From bob.hinden@gmail.com Tue Apr 10 08:01: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 19DDF11E80CF for ; Tue, 10 Apr 2012 08:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 LtDObRCJ+l0t for ; Tue, 10 Apr 2012 08:01:21 -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 3DE4011E80B5 for ; Tue, 10 Apr 2012 08:01:21 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so68034pbb.31 for ; Tue, 10 Apr 2012 08:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=soVPm9bwRkuLeA72nRp0y3xwGXmwVuXwIA0+ErUFbZY=; b=iTNwK/dbgDkUSuIsXy3/gBMjAYKXCMO8uqUwCyw2+scaL7ZlGnC2ScOsd3gvdv4evV kCjMplDVKVA2UUiVcrHP5a/rxMKfA2eFq7LZESRBngDL7sotpqn8sp8hL8bqC2khTIrf OdEiF78+8w0JixHstCDs7xtkyujzQqtwAr8J/wbt5xIM9HTmykFd23ivJ1jqlgcTjQWq rA/Ebu6k4DUVNv0f2eiesD0HJ/CgVaSjimDsoy4AJ5M6H5qnvDioIgVn72fG/fNDZnJt 1NrP6YteEGkHg57vOcUYDpcQ0iMXHDKlf4nIOmNcWvLOTbk0xGftwU+Qpj+HrCV4kS+8 CPWw== Received: by 10.68.200.225 with SMTP id jv1mr8450130pbc.120.1334070080936; Tue, 10 Apr 2012 08:01:20 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id b7sm104964pba.2.2012.04.10.08.01.19 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 08:01:19 -0700 (PDT) Subject: Re: Why one Internet? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Tue, 10 Apr 2012 08:01:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B73C6B1-35AF-49BF-BA0F-2D663D0EDD1B@gmail.com> References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> To: Pars Mutaf X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org Mailing List" , 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: Tue, 10 Apr 2012 15:01:22 -0000 Pars, This discussion is out of scope for the ipv6@ietf.org mailing list. = Please take it elsewhere. Bob & Ole 6man w.g. Chairs On Apr 10, 2012, at 7:57 AM, Pars Mutaf wrote: > I am here to question:=20 >=20 > My question is why IPv6 is the end of the road.=20 >=20 > We shouldn't give all the responsibility to a few persons. > We should not be dependent on their decisions.=20 >=20 > If the transition to a complete IPv6 network is not possible, then we = can add a new Internet. It can be IPv4, IPv6, or even IPv7.=20 >=20 > Pars >=20 > On Tue, Apr 10, 2012 at 5:09 PM, Lixia Zhang = wrote: > the Internet is a means to communicate. > and the market drives for most effective/efficient/economical = communication systems (there are tradeoffs between the adjectives) > wonder if you could help explain how your picture of "network of = Internets" would be more effective and economical (than what we have = now) >=20 > Lixia >=20 > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: >=20 >> Hi, >>=20 >> In my opinion, we can add one more Internet when necessary, then = another one etc.=20 >>=20 >> We can have as many Internets as we need, all different.=20 >>=20 >> We just need a *network of Internets*.=20 >>=20 >> The first (current) Internet is an IPv4 Internet. >> The second Internet can be an IPv4 Internet too. In this case we = would have 2 IPv4 Internets.=20 >> Obviously, in this case, we would have the same addresses used by two = different nodes in=20 >> the two Internets. I think it is possible to locate the node we need. = I am not here to discuss=20 >> these details.=20 >>=20 >> The second Internet can be an IPv6 Internet.=20 >>=20 >> The second Internet can be a IPv7 Internet.=20 >>=20 >> The second Internet can be IPv6 but we may have a third one which is = IPv7 etc.=20 >>=20 >> We just need a network of Internets, all possibly different.=20 >>=20 >> Pars >> http://content-based-science.org/ >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pars.mutaf@gmail.com Tue Apr 10 08:03: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 B8F5921F86F3 for ; Tue, 10 Apr 2012 08:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.185, 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 4PIDYomy5qmv for ; Tue, 10 Apr 2012 08:03:05 -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 6DAB421F86C7 for ; Tue, 10 Apr 2012 08:03:05 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2665863ghb.31 for ; Tue, 10 Apr 2012 08:03:03 -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=rLZXfdb80QX/HsKBvdi2XxdcMWYBZAKhdp2u9GlSPQs=; b=yRHJRVOUr/sgAsBYCmHjziVBTAURbypjwHX5U1PR5niUQuEBZKn695zQKrDBsR08My 985vlUSNs9pKaKhUR6V6PIvqCefX3Rp1/eW5SSdKRnOySWvF9TeuMkZmeilv8KcjVHCT qFBdWjkNrvmL8hRiuXN83f2iY+UXleqh8kx8YOqa2FuJvQdVx/F4zgHVJMPe/EGXOydB KUpwrv5L6j14jDAKkITiQn7aQqlCl018mFYIuMhceVq9gl7FBYRo3vaMbqtsi4JL6mCx MeZgylvoaIHCxD7+hkHo4PgG5A9aRzr+tiEsjNtzy7oHtPk492cNeRUTTTOIsrJenuJN WyyQ== MIME-Version: 1.0 Received: by 10.60.20.100 with SMTP id m4mr17209330oee.10.1334070183173; Tue, 10 Apr 2012 08:03:03 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 08:03:03 -0700 (PDT) In-Reply-To: <4F844428.7050408@gmail.com> References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> Date: Tue, 10 Apr 2012 18:03:03 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8fb1ef4c5f9ec104bd546b70 Cc: ipv6@ietf.org, Lixia Zhang 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, 10 Apr 2012 15:03:06 -0000 --e89a8fb1ef4c5f9ec104bd546b70 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 5:31 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Lixia, > > The original note says "I think it is possible to locate the node we need." > > So, the idea is apparently not to divide the Internet - it is simply to > deal > with the fact that addresses would be ambiguous. Since we have 15 years > experience of the pain caused by ambiguous addresses, and a perfectly good > 128 bit address space that avoids any need for ambiguous addresses, I don't > see the point. It isn't even worth sending the code. > > Pars, > > Your original note also says "I am not here to discuss these details." > Sorry, > but in the IETF it's *exactly* the details that we must discuss; that's our > job. We've been doing so since 1992 to my personal knowledge. > > I propose have a network of Internets: Internet1 Internet2 Internet3 ... Interntet_n In Internet 1 and 2 we may have two nodes with the same address. The goal is to route the packet to the right Internet. I don't think it is impossible. Pars > Regards > Brian > > On 2012-04-10 15:09, Lixia Zhang wrote: > > the Internet is a means to communicate. > > and the market drives for most effective/efficient/economical > communication systems (there are tradeoffs between the adjectives) > > wonder if you could help explain how your picture of "network of > Internets" would be more effective and economical (than what we have now) > > > > Lixia > > > > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: > > > >> Hi, > >> > >> In my opinion, we can add one more Internet when necessary, then > another one etc. > >> > >> We can have as many Internets as we need, all different. > >> > >> We just need a *network of Internets*. > >> > >> The first (current) Internet is an IPv4 Internet. > >> The second Internet can be an IPv4 Internet too. In this case we would > have 2 IPv4 Internets. > >> Obviously, in this case, we would have the same addresses used by two > different nodes in > >> the two Internets. I think it is possible to locate the node we need. I > am not here to discuss > >> these details. > >> > >> The second Internet can be an IPv6 Internet. > >> > >> The second Internet can be a IPv7 Internet. > >> > >> The second Internet can be IPv6 but we may have a third one which is > IPv7 etc. > >> > >> We just need a network of Internets, all possibly different. > >> > >> Pars > >> http://content-based-science.org/ > >> -------------------------------------------------------------------- > >> 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 > > -------------------------------------------------------------------- > --e89a8fb1ef4c5f9ec104bd546b70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 5:31 PM, Brian E= Carpenter <brian.e.carpenter@gmail.com> wrote:
Lixia,

The original note says "I think it is possible to locate the node we n= eed."

So, the idea is apparently not to divide the Internet - it is simply to dea= l
with the fact that addresses would be ambiguous. Since we have 15 years
experience of the pain caused by ambiguous addresses, and a perfectly good<= br> 128 bit address space that avoids any need for ambiguous addresses, I don&#= 39;t
see the point. It isn't even worth sending the code.

Pars,

Your original note also says "I am not here to discuss these details.&= quot; Sorry,
but in the IETF it's *exactly* the details that we must discuss; that&#= 39;s our
job. We've been doing so since 1992 to my personal knowledge.


I propose have a network of Internets:=

Internet1
Internet2
Internet3=
...
Interntet_n

In Internet 1= and 2 we may have two nodes with the same address.=A0
The goal is to route the packet to the right Internet. I don't thi= nk it is impossible.

Pars


=A0
Regards
=A0 Brian

On 2012-04-10 15:09, Lixia Zhang wrote:
> the Internet is a means to communicate.
> and the market drives for most effective/efficient/economical communic= ation systems (there are tradeoffs between the adjectives)
> wonder if you could help explain how your picture of "network of = Internets" would be more effective and economical (than what we have n= ow)
>
> Lixia
>
> On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote:
>
>> Hi,
>>
>> In my opinion, we can add one more Internet when necessary, then a= nother one etc.
>>
>> We can have as many Internets as we need, all different.
>>
>> We just need a *network of Internets*.
>>
>> The first (current) Internet is an IPv4 Internet.
>> The second Internet can be an IPv4 Internet too. In this case we w= ould have 2 IPv4 Internets.
>> Obviously, in this case, we would have the same addresses used by = two different nodes in
>> the two Internets. I think it is possible to locate the node we ne= ed. I am not here to discuss
>> these details.
>>
>> The second Internet can be an IPv6 Internet.
>>
>> The second Internet can be a IPv7 Internet.
>>
>> The second Internet can be IPv6 but we may have a third one which = is IPv7 etc.
>>
>> We just need a network of Internets, all possibly different.
>>
>> Pars
>> ht= tp://content-based-science.org/
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= /a>
>> ------------------------------------------------------------------= --
>
>
>
> ----------------------------------------------------------= --------------
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<= br> > --------------------------------------------------------------------

--e89a8fb1ef4c5f9ec104bd546b70-- From pars.mutaf@gmail.com Tue Apr 10 08:04: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 2E9B111E80FC for ; Tue, 10 Apr 2012 08:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.172, 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 OUiRXZu4QHIP for ; Tue, 10 Apr 2012 08:04:13 -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 6705211E80EF for ; Tue, 10 Apr 2012 08:04:13 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2649319yhk.31 for ; Tue, 10 Apr 2012 08:04: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=6Qs7IJf1qL5TSUZu1Qw9pAoUD+uO+sYR49Ul9ENZ8p8=; b=FneH4qXKVOd6smmnd72o72+llPW5oGCn8MJov/NcByqbNlXfb+XDfMKlTk0dOaA1RX 0AYn7FBISvW6wY3R93x8ntygRGpCkN5ohtJabbraI8uGHtI8sk9hqNRZFubFkULYBCfN JazjsIZqJnzWVwWdBzKN5euQzDX7+AWhSS7qGsr/bcWSEem1yuAj1kwIr+rWkTu09ahN YGRASQeKTV6P7j2krAHJ5uS4T3kuRrdEXYZCe9UVNLcQPjHAAYLTWDhARZC1PnJBsZfY mNKfXwJnsbpaJSbpCXtg4TE8a4Nr6AqOxPYnsZ19j3NpCxxd9FSS8Q+ydXfucCIfDohY 4W2Q== MIME-Version: 1.0 Received: by 10.60.27.38 with SMTP id q6mr17206723oeg.20.1334070250441; Tue, 10 Apr 2012 08:04:10 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 08:04:10 -0700 (PDT) In-Reply-To: References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> Date: Tue, 10 Apr 2012 18:04:10 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: Hagen Paul Pfeifer Content-Type: multipart/alternative; boundary=e89a8ff1c634620b4504bd546f9b Cc: ipv6@ietf.org, Lixia Zhang 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, 10 Apr 2012 15:04:14 -0000 --e89a8ff1c634620b4504bd546f9b Content-Type: text/plain; charset=ISO-8859-1 I am not a troll I worked on IPv6 and MANET for longtime. Now I choose to wake up and question. Pars On Tue, Apr 10, 2012 at 5:45 PM, Hagen Paul Pfeifer wrote: > > On Tue, 10 Apr 2012 15:31:04 +0100, Brian E Carpenter wrote: > > > Your original note also says "I am not here to discuss these details." > > Sorry, > > but in the IETF it's *exactly* the details that we must discuss; that's > our > > job. We've been doing so since 1992 to my personal knowledge. > > > > Regards > > Brian > > Brian: Pars is a troll, don't feed him. See MANET WG postings ... > > Hagen > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --e89a8ff1c634620b4504bd546f9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not a troll I worked on IPv6 and MANET for longtime.=A0

=
Now I choose to wake up and question.=A0

Pars= =A0

On Tue, Apr 10, 2012 at 5= :45 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:

On Tue, 10 Apr 2012 15:31:04 +0100, Brian E Carpenter wrote:

> Your original note also says "I am not here to discuss these deta= ils."
> Sorry,
> but in the IETF it's *exactly* the details that we must discuss; t= hat's
our
> job. We've been doing so since 1992 to my personal knowledge.
>
> Regards
> =A0 =A0Brian

Brian: Pars is a troll, don't feed him. See MANET WG postings ...=

Hagen



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

--e89a8ff1c634620b4504bd546f9b-- From lixia@cs.ucla.edu Tue Apr 10 08:12: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 1F18F21F85B9 for ; Tue, 10 Apr 2012 08:12: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=[AWL=0.001, 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 Aj7KksebkYHX for ; Tue, 10 Apr 2012 08:12:51 -0700 (PDT) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5B21F85A8 for ; Tue, 10 Apr 2012 08:12:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 489FE39E800B; Tue, 10 Apr 2012 08:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBirG0Dp4N8C; Tue, 10 Apr 2012 08:12:43 -0700 (PDT) Received: from [10.0.1.2] (cpe-98-154-15-232.socal.res.rr.com [98.154.15.232]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D17DD39E8008; Tue, 10 Apr 2012 08:12:43 -0700 (PDT) Subject: Re: Why one Internet? Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Lixia Zhang In-Reply-To: <4F844428.7050408@gmail.com> Date: Tue, 10 Apr 2012 08:12:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> To: Brian E Carpenter 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, 10 Apr 2012 15:12:52 -0000 Hi Brian,=20 I was not questioning about connectivity (or divide Internet). I was just looking for an explanation of how the proposal could be MORE = effective *and* more economical. Lixia On Apr 10, 2012, at 7:31 AM, Brian E Carpenter wrote: > Lixia, >=20 > The original note says "I think it is possible to locate the node we = need." >=20 > So, the idea is apparently not to divide the Internet - it is simply = to deal > with the fact that addresses would be ambiguous. Since we have 15 = years > experience of the pain caused by ambiguous addresses, and a perfectly = good > 128 bit address space that avoids any need for ambiguous addresses, I = don't > see the point. It isn't even worth sending the code. >=20 > Pars, >=20 > Your original note also says "I am not here to discuss these details." = Sorry, > but in the IETF it's *exactly* the details that we must discuss; = that's our > job. We've been doing so since 1992 to my personal knowledge. >=20 > Regards > Brian From cb.list6@gmail.com Tue Apr 10 08:25: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 49F0C11E80F3 for ; Tue, 10 Apr 2012 08:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 hFRW9GnLUlB4 for ; Tue, 10 Apr 2012 08:25:20 -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 1FDD911E80F7 for ; Tue, 10 Apr 2012 08:25:20 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so93903pbb.31 for ; Tue, 10 Apr 2012 08:25:20 -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=cNRbIAwW1h9J9NdQnnv563fPo/D3wqV1WLENSq7EIUI=; b=OLWdZmP8W6yT0sEVvHezsjgzQhxfkvba+178p5jzNCthuoJJFklXpiRsdbpw0Un469 EFWmHDaekEokk4ixJcJtzoTfaZ0Mncrv7aj1uGizzQITCfvK4deMPoOhVdq5Tb6XGMhC byZLcQqol6EMKPbdLTGBEcqyCA1IOW2hUQryyuYRvhpyeHRww+jRo13hdj7JPUxMjnWC ErKVDlcxZQweQLRtslt7DRlMqjQBS0oQQJsqwQx1985g7YHnGm1q+7mdvvpSiXfGWRa1 r3q1DSsFe3Jd8IP9F3zQvdQldO2qKB//AFxpJu3Al2dDyZ1xqvFG3fVuePxt28c8YuwK aYVQ== MIME-Version: 1.0 Received: by 10.68.201.169 with SMTP id kb9mr29203554pbc.146.1334071519788; Tue, 10 Apr 2012 08:25:19 -0700 (PDT) Received: by 10.143.16.3 with HTTP; Tue, 10 Apr 2012 08:25:19 -0700 (PDT) In-Reply-To: References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> Date: Tue, 10 Apr 2012 08:25:19 -0700 Message-ID: Subject: Re: Why one Internet? From: Cameron Byrne To: Pars Mutaf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, Lixia Zhang 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, 10 Apr 2012 15:25:21 -0000 On Tue, Apr 10, 2012 at 8:03 AM, Pars Mutaf wrote: > > > On Tue, Apr 10, 2012 at 5:31 PM, Brian E Carpenter > wrote: >> >> Lixia, >> >> The original note says "I think it is possible to locate the node we >> need." >> >> So, the idea is apparently not to divide the Internet - it is simply to >> deal >> with the fact that addresses would be ambiguous. Since we have 15 years >> experience of the pain caused by ambiguous addresses, and a perfectly go= od >> 128 bit address space that avoids any need for ambiguous addresses, I >> don't >> see the point. It isn't even worth sending the code. >> >> Pars, >> >> Your original note also says "I am not here to discuss these details." >> Sorry, >> but in the IETF it's *exactly* the details that we must discuss; that's >> our >> job. We've been doing so since 1992 to my personal knowledge. >> > > I propose have a network of Internets: > > Internet1 > Internet2 > Internet3 > ... > Interntet_n > > In Internet 1 and 2 we may have two nodes with the same address. > The goal is to route the packet to the right Internet. I don't think it i= s > impossible. > Quite possible. Most people call it CGN. In fact, the IETF granted a /10 of IPv4 for this purpose. CB > Pars > > > >> >> Regards >> =A0 Brian >> >> On 2012-04-10 15:09, Lixia Zhang wrote: >> > the Internet is a means to communicate. >> > and the market drives for most effective/efficient/economical >> > communication systems (there are tradeoffs between the adjectives) >> > wonder if you could help explain how your picture of "network of >> > Internets" would be more effective and economical (than what we have n= ow) >> > >> > Lixia >> > >> > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: >> > >> >> Hi, >> >> >> >> In my opinion, we can add one more Internet when necessary, then >> >> another one etc. >> >> >> >> We can have as many Internets as we need, all different. >> >> >> >> We just need a *network of Internets*. >> >> >> >> The first (current) Internet is an IPv4 Internet. >> >> The second Internet can be an IPv4 Internet too. In this case we woul= d >> >> have 2 IPv4 Internets. >> >> Obviously, in this case, we would have the same addresses used by two >> >> different nodes in >> >> the two Internets. I think it is possible to locate the node we need.= I >> >> am not here to discuss >> >> these details. >> >> >> >> The second Internet can be an IPv6 Internet. >> >> >> >> The second Internet can be a IPv7 Internet. >> >> >> >> The second Internet can be IPv6 but we may have a third one which is >> >> IPv7 etc. >> >> >> >> We just need a network of Internets, all possibly different. >> >> >> >> Pars >> >> http://content-based-science.org/ >> >> -------------------------------------------------------------------- >> >> 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 bill.jouris@insidethestack.com Tue Apr 10 08:29: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 4A7FE11E8101 for ; Tue, 10 Apr 2012 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.501 X-Spam-Level: *** X-Spam-Status: No, score=3.501 tagged_above=-999 required=5 tests=[BAYES_99=3.5, 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 AyaxNd+7-+5B for ; Tue, 10 Apr 2012 08:29:51 -0700 (PDT) Received: from nm14.bullet.mail.sp2.yahoo.com (nm14.bullet.mail.sp2.yahoo.com [98.139.91.84]) by ietfa.amsl.com (Postfix) with SMTP id A875211E80FC for ; Tue, 10 Apr 2012 08:29:51 -0700 (PDT) Received: from [98.139.91.63] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 15:29:48 -0000 Received: from [98.139.44.80] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 15:29:48 -0000 Received: from [127.0.0.1] by omp1017.access.mail.sp2.yahoo.com with NNFMP; 10 Apr 2012 15:29:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 44275.52625.bm@omp1017.access.mail.sp2.yahoo.com Received: (qmail 64736 invoked by uid 60001); 10 Apr 2012 15:29:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334071787; bh=X6J7SBK0gpVR3YKbDywMWF8WtEJ2l7PpQKkYgsnaBE8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=Br9tW9BQ0z4vwTZBUnNDcQvX4QZA68r0UvQ+xwhHOeD87qLtZ4PqvfVLltKVLUZY0KYwTrCn3pZBhqtxgX5jG9kzhSmBPXc9TLiwgxQwQs+vgzEZqhW9NjI8k6P+wJZft+73SwYMojTvRZXPZaQwU7QcW9bpzTAYVPVwL6NDQ24= X-YMail-OSG: yPLdzgAVM1lbsKakAsJf5UiYIYoAJVzckZ0aMSky8NxIj.i nJhIG0SsH6XirqJr4Yp52tPbczB5ZxGAeSAZLQI6KgczGqdyR2a7.DM3KpHU UJ7eObec8Gs9mK6GYi2fT1F.zTGqh2kVWA78rnYFvta_2bvRmL5_4KwSbNwR yjBa1_v2lhbGk1gRZ0n7GyFxhZf6ZhykWzhaiGwjTgqsHA3HqyjvYfLSdUD4 e.37aashUdMdtcZAOGFQrYvgglAEqQup8c0sqmsWhN7IUc4ebvVZPPKdKrFR Qy8KjNvgX4ylhsxLHOtOY16uLUc5CbtD2AvAPr_Xn3aPHO571X4b0ROVfgb8 7m5N4XIkQcakYMBKwlq04WbwIgljlxv24qNEvJvgsF9diulXB9w6IVXbBLjN .WnJyZcN66L6BeAgmvnKxIj.YhvAraN0nDnD698nXHdvymZkdQDRaiDHmCf3 p3cmoU7ewmshpR2vAo9MFz7ys7__fgFNncJPBrSm1NZjIhTRWA5WZuOJpyV6 5_q2Y8C4L1eT14DvmX9wKyMREib0UZn7DJm6MvVDnu8GXYUc- Received: from [24.23.149.201] by web2817.biz.mail.ne1.yahoo.com via HTTP; Tue, 10 Apr 2012 08:29:47 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334071787.62402.YahooMailClassic@web2817.biz.mail.ne1.yahoo.com> Date: Tue, 10 Apr 2012 08:29:47 -0700 (PDT) From: Bill Jouris Subject: Re: Why one Internet? To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="186841555-2114570601-1334071787=:62402" 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, 10 Apr 2012 15:29:52 -0000 --186841555-2114570601-1334071787=:62402 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Why *not* one Internet?=A0=20 If someone wants to create multiple ones (or, more accurately, break the ex= isting one into multiple pieces), it seems incumbent on them to make a soli= d case for doing so.=A0 That is, to show a specific problem, and a technica= l case why a drastic architectural change is the *only* effective way to ad= dress it. Bill Jouris Inside Products, Inc. www.insidethestack.com 831-659-8360 925-855-9512 (direct) --186841555-2114570601-1334071787=:62402 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Why *not* one Internet? 

If some= one wants to create multiple ones (or, more accurately, break the existing = one into multiple pieces), it seems incumbent on them to make a solid case = for doing so.  That is, to show a specific problem, and a technical ca= se why a drastic architectural change is the *only* effective way to addres= s it.

Bill Jouris
Inside= Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (= direct)

--186841555-2114570601-1334071787=:62402-- From lordmwesh@gmail.com Tue Apr 10 08:30: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 A8A1211E80FC for ; Tue, 10 Apr 2012 08:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 d-8vgW3cRF4B for ; Tue, 10 Apr 2012 08:30:15 -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 B934A11E80DF for ; Tue, 10 Apr 2012 08:30:14 -0700 (PDT) Received: by lagj5 with SMTP id j5so3173750lag.31 for ; Tue, 10 Apr 2012 08:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=XJaa4N/78l/OvwgEXFJseSX+oueyJc9ND/MgBDVVC9I=; b=orRkReL7okdsiNIAGOovagGcM662Qole0rKNmaASTdNGcczX5WDsJQ7LDvr7NK6WkE y3AulSdNvi7+PCI+mZGDSmUOdIrOPN1Baqi8nQa7pj/lmYc11cwIXUwzLl8yEcrkJgo9 QHNWaqo6xLr6FxMnccu1sQ8MER/iChNrrgTlQ3M9ZscRaSguKeMe38UL7aL/rSpBjVAw jO37/ggrpJ3XaVZGWp1hXQNXNANWx5KnjNEvYpUgSdWKx8/b0m9vN8a2uczDk58bnlmN DluK2p1ZhSn4DVhn1aXjn4dTKetfSPwMJHwlnig2kyxZv9Oi7Qsh/lkGvRr8Wr3UyaNR IJxA== Received: by 10.112.49.5 with SMTP id q5mr1445611lbn.7.1334071813575; Tue, 10 Apr 2012 08:30:13 -0700 (PDT) MIME-Version: 1.0 Sender: lordmwesh@gmail.com Received: by 10.152.145.133 with HTTP; Tue, 10 Apr 2012 08:29:52 -0700 (PDT) From: Kivuva Date: Tue, 10 Apr 2012 18:29:52 +0300 X-Google-Sender-Auth: qBMA_CGsnWaci6CdGeudTLHkD_M Message-ID: Subject: Re: Why one Internet? To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=90e6ba308e808d931804bd54cc56 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, 10 Apr 2012 15:36:31 -0000 --90e6ba308e808d931804bd54cc56 Content-Type: text/plain; charset=ISO-8859-1 If we created the two or three Internets, then linked them together by physical network nodes or layer 3 devices, would the multiple Internets revert to one? -- ______________________ Mwendwa Kivuva For Business Development Transworld Computer Channels twitter.com/lordmwesh www.transworldAfrica.com | Fluent in computing kenya.or.ke | The Kenya we know --90e6ba308e808d931804bd54cc56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we created the two or three=A0Internets,= then linked them together by=A0 physical network nodes or layer 3 devices, would the multiple=A0Internets=A0revert to one?


--
______________________
Mwendwa Kivuva
For
Bu= siness Development
Transworld Computer Channels
twitter.com/lordmwesh
www.transworldAfrica= .com=A0 | Fluent in computing
kenya.or.ke | The Keny= a we know

--90e6ba308e808d931804bd54cc56-- From lordmwesh@gmail.com Tue Apr 10 08:35: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 5B50711E80FC for ; Tue, 10 Apr 2012 08:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=1.300, 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 OdlzU4hZeIWr for ; Tue, 10 Apr 2012 08:35:58 -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 6DBC311E80F6 for ; Tue, 10 Apr 2012 08:35:58 -0700 (PDT) Received: by lagj5 with SMTP id j5so3179017lag.31 for ; Tue, 10 Apr 2012 08:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=q+VuMVV+a41OEbs4wxsBZRIxZPZgZehb9ousl/2gymk=; b=rncNyhS1sZFWP6E45fFd5Kw4CsDJTQJvxC9MLFQr7e/p3y1xwhapG9sbvDKtzZRwPL ubbrfHAyB6swnjP1VktqEf9+MQBP+D0uY8niDhxbpHJBtwgVs3MfKdeIix7Ys2Okz5MK /feOzBPRWvYzLlt8wfFYZcIfYTD5Kc3tpbaEplYr0LmsuAxTOQpCW9EJxQ995xqJwkRq RfhnDGExu2Qv8lT0TcxcInSwWgNgkTmVlI6S2nIs2Pez/p4oAkD8oEWstTKXGvpu8ZK6 IX30XCm6sZgmIhdhjXQMhdJKzWRfHjCzQQ0yIDxN88FwjhcSnFTv1S+LtNPz94DXgzkb 1Vhg== Received: by 10.152.103.239 with SMTP id fz15mr15109076lab.42.1334072157286; Tue, 10 Apr 2012 08:35:57 -0700 (PDT) MIME-Version: 1.0 Sender: lordmwesh@gmail.com Received: by 10.152.145.133 with HTTP; Tue, 10 Apr 2012 08:35:37 -0700 (PDT) From: Kivuva Date: Tue, 10 Apr 2012 18:35:37 +0300 X-Google-Sender-Auth: RKCzqo-kvlzgsy1ZU6YhZozLTtc Message-ID: Subject: Re: Why one Internet? To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=f46d04088e9f0a311c04bd54e162 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, 10 Apr 2012 15:37:34 -0000 --f46d04088e9f0a311c04bd54e162 Content-Type: text/plain; charset=ISO-8859-1 If we created the two or three Internets, then linked them together by physical network nodes or layer 3 devices, would the multiple Internets revert to one? 10rdmwesh -- ______________________ Mwendwa Kivuva For Business Development Transworld Computer Channels twitter.com/lordmwesh www.transworldAfrica.com | Fluent in computing kenya.or.ke | The Kenya we know --f46d04088e9f0a311c04bd54e162 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we created the two or three=A0Internets, then linked the= m together by=A0=A0physical network nodes or layer 3 dev= ices, would the multiple=A0Internets=A0revert to one?=A0

10rdmwesh

--
______________________=
Mwendwa Kivuva
For
Business Development
Transworld Computer Ch= annels
twitte= r.com/lordmwesh
www.transworl= dAfrica.com=A0 | Fluent in computing
kenya.or.ke | The Kenya we know

--f46d04088e9f0a311c04bd54e162-- From pars.mutaf@gmail.com Tue Apr 10 08:46: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 BB3C911E810F for ; Tue, 10 Apr 2012 08:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.160, 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 gkVxWsS3c63L for ; Tue, 10 Apr 2012 08:45:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32B9B11E80CB for ; Tue, 10 Apr 2012 08:45:52 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8390722obb.31 for ; Tue, 10 Apr 2012 08:45:51 -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=QvtgKtKlaUigRlzXC1tn4P3ljsv9fhy//74dXWLMJ8U=; b=wFCmnp78cHw5/ZYS/wvbeWvtlmWK2SUiImqcUxt7xhiJViEH88QzOCxw4+p1Cy3/jm BpA4+4rtJrJNJiFFxF7KeBfyXoCOo4pkgldZiqxazzx1Ylj2sEfxYVNRILBVH9Nkj1Ns mmXj1ryY//RfWMbQIEjQF1Xw/SG4+arArN49Q5cyXDBWFzszMgkc9+JBAVF8w1tyj1nK 49JtZbBURTRHNYc+nqvL7RmUuBIGsO5foE8ccybB2Irnr2m9o9TABkEKa231OL1y9uu0 xGzFkSkLN8coLPZrgVB0KD2FP/Ptwp/YTVy0b57Bvj4exRyD5MScxOuBkLuef7hrCp/Z 3bCw== MIME-Version: 1.0 Received: by 10.182.174.101 with SMTP id br5mr17102202obc.0.1334072751796; Tue, 10 Apr 2012 08:45:51 -0700 (PDT) Received: by 10.182.117.34 with HTTP; Tue, 10 Apr 2012 08:45:51 -0700 (PDT) In-Reply-To: References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> Date: Tue, 10 Apr 2012 18:45:51 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8f64672979b0ff04bd550426 Cc: ipv6@ietf.org, Lixia Zhang 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, 10 Apr 2012 15:46:00 -0000 --e89a8f64672979b0ff04bd550426 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 10, 2012 at 6:25 PM, Cameron Byrne wrote: > On Tue, Apr 10, 2012 at 8:03 AM, Pars Mutaf wrote: > > > > > > On Tue, Apr 10, 2012 at 5:31 PM, Brian E Carpenter > > wrote: > >> > >> Lixia, > >> > >> The original note says "I think it is possible to locate the node we > >> need." > >> > >> So, the idea is apparently not to divide the Internet - it is simply to > >> deal > >> with the fact that addresses would be ambiguous. Since we have 15 years > >> experience of the pain caused by ambiguous addresses, and a perfectly > good > >> 128 bit address space that avoids any need for ambiguous addresses, I > >> don't > >> see the point. It isn't even worth sending the code. > >> > >> Pars, > >> > >> Your original note also says "I am not here to discuss these details." > >> Sorry, > >> but in the IETF it's *exactly* the details that we must discuss; that's > >> our > >> job. We've been doing so since 1992 to my personal knowledge. > >> > > > > I propose have a network of Internets: > > > > Internet1 > > Internet2 > > Internet3 > > ... > > Interntet_n > > > > In Internet 1 and 2 we may have two nodes with the same address. > > The goal is to route the packet to the right Internet. I don't think it > is > > impossible. > > > > Quite possible. Most people call it CGN. In fact, the IETF granted a > /10 of IPv4 for this purpose. > > You mean this one? http://tools.ietf.org/html/rfc6264 Figure 1 looks like what I am proposing. Right? If so, we can also have a IPv7 with is, in addition to IPv6 (or directly IPv7). I have no idea what IPv7 would be and why it would be needed, but it looks like we should be flexible (to me at least). Pars CB > > > Pars > > > > > > > >> > >> Regards > >> Brian > >> > >> On 2012-04-10 15:09, Lixia Zhang wrote: > >> > the Internet is a means to communicate. > >> > and the market drives for most effective/efficient/economical > >> > communication systems (there are tradeoffs between the adjectives) > >> > wonder if you could help explain how your picture of "network of > >> > Internets" would be more effective and economical (than what we have > now) > >> > > >> > Lixia > >> > > >> > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: > >> > > >> >> Hi, > >> >> > >> >> In my opinion, we can add one more Internet when necessary, then > >> >> another one etc. > >> >> > >> >> We can have as many Internets as we need, all different. > >> >> > >> >> We just need a *network of Internets*. > >> >> > >> >> The first (current) Internet is an IPv4 Internet. > >> >> The second Internet can be an IPv4 Internet too. In this case we > would > >> >> have 2 IPv4 Internets. > >> >> Obviously, in this case, we would have the same addresses used by two > >> >> different nodes in > >> >> the two Internets. I think it is possible to locate the node we > need. I > >> >> am not here to discuss > >> >> these details. > >> >> > >> >> The second Internet can be an IPv6 Internet. > >> >> > >> >> The second Internet can be a IPv7 Internet. > >> >> > >> >> The second Internet can be IPv6 but we may have a third one which is > >> >> IPv7 etc. > >> >> > >> >> We just need a network of Internets, all possibly different. > >> >> > >> >> Pars > >> >> http://content-based-science.org/ > >> >> -------------------------------------------------------------------- > >> >> 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 > > -------------------------------------------------------------------- > > > --e89a8f64672979b0ff04bd550426 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 6:25 PM, Cameron= Byrne <cb.list6= @gmail.com> wrote:
On Tue, Apr 10, 2012 at 8:03 AM, Pa= rs Mutaf <pars.mutaf@gmail.com> wrote:
>
>
> On Tue, Apr 10, 2012 at 5:31 PM, Brian E Carpenter
> <brian.e.carpenter@g= mail.com> wrote:
>>
>> Lixia,
>>
>> The original note says "I think it is possible to locate the = node we
>> need."
>>
>> So, the idea is apparently not to divide the Internet - it is simp= ly to
>> deal
>> with the fact that addresses would be ambiguous. Since we have 15 = years
>> experience of the pain caused by ambiguous addresses, and a perfec= tly good
>> 128 bit address space that avoids any need for ambiguous addresses= , I
>> don't
>> see the point. It isn't even worth sending the code.
>>
>> Pars,
>>
>> Your original note also says "I am not here to discuss these = details."
>> Sorry,
>> but in the IETF it's *exactly* the details that we must discus= s; that's
>> our
>> job. We've been doing so since 1992 to my personal knowledge.<= br> >>
>
> I propose have a network of Internets:
>
> Internet1
> Internet2
> Internet3
> ...
> Interntet_n
>
> In Internet 1 and 2 we may have two nodes with the same address.
> The goal is to route the packet to the right Internet. I don't thi= nk it is
> impossible.
>

Quite possible. Most people call it CGN. =A0In fact, the IETF g= ranted a
/10 of IPv4 for this purpose.


You mean this one?
Figure 1 looks like what I am proposing. Right?

If so, we can also have a IPv7 with is, in addition to IPv6 (or di= rectly IPv7). I have no idea what IPv7=A0
would=A0be and why it w= ould be needed,=A0but it looks like=A0we should be flexible (to me at least= ).

Pars=A0

CB

> Pars
>
>
>
>>
>> Regards
>> =A0 Brian
>>
>> On 2012-04-10 15:09, Lixia Zhang wrote:
>> > the Internet is a means to communicate.
>> > and the market drives for most effective/efficient/economical=
>> > communication systems (there are tradeoffs between the adject= ives)
>> > wonder if you could help explain how your picture of "ne= twork of
>> > Internets" would be more effective and economical (than = what we have now)
>> >
>> > Lixia
>> >
>> > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote:
>> >
>> >> Hi,
>> >>
>> >> In my opinion, we can add one more Internet when necessar= y, then
>> >> another one etc.
>> >>
>> >> We can have as many Internets as we need, all different.<= br> >> >>
>> >> We just need a *network of Internets*.
>> >>
>> >> The first (current) Internet is an IPv4 Internet.
>> >> The second Internet can be an IPv4 Internet too. In this = case we would
>> >> have 2 IPv4 Internets.
>> >> Obviously, in this case, we would have the same addresses= used by two
>> >> different nodes in
>> >> the two Internets. I think it is possible to locate the n= ode we need. I
>> >> am not here to discuss
>> >> these details.
>> >>
>> >> The second Internet can be an IPv6 Internet.
>> >>
>> >> The second Internet can be a IPv7 Internet.
>> >>
>> >> The second Internet can be IPv6 but we may have a third o= ne which is
>> >> IPv7 etc.
>> >>
>> >> We just need a network of Internets, all possibly differe= nt.
>> >>
>> >> Pars
>> >> http://content-based-science.org/
>> >> ---------------------------------------------------------= -----------
>> >> IETF IPv6 working group mailing list
>> >> ipv6@ietf.org
>> >> Administrative Requests: https://www.ietf.org/mailman/listi= nfo/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<= br> > -------------------------------------------------------------------- >

--e89a8f64672979b0ff04bd550426-- From turchanyi.geza@gmail.com Tue Apr 10 09:01: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 6DB6221F859A for ; Tue, 10 Apr 2012 09:01:17 -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 lnNIezmimxIg for ; Tue, 10 Apr 2012 09:01:16 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2455C21F85AA for ; Tue, 10 Apr 2012 09:01:16 -0700 (PDT) Received: by qcsq13 with SMTP id q13so3772371qcs.31 for ; Tue, 10 Apr 2012 09:01:15 -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=qRENBr3vKBctB0mSBVHricFYpKJI5p38u1Gz5uZv5aE=; b=d6u4jobuqtjp2S3N8Nqu0F12telYSSi/aT7g/QoiKn+KEY0kVKKqC23Gu/CNJ4RnzS 2hKh5qXRa5h0E3N8aSAL7EDbI5e/EG9qx/PAXe6VZ+DpEGcoIhOEm8K4YnfYYIIEyVWl hbRpq0gGXmR7I8/DmpcEq3wxuZUFZjZyMukSOGYhEwn/2nrU3Nw5JHqny1zDH3sTMt/q HyL8S5eUustSMUYNOXs2EEEy2KUTbizZrwV2/yJ7ggLi5obdlOF0DNLLgKVpyVBBPP1X 3MU+k9hmfU7HQcC2p8bSQXPDz0ZIGY909NMtNlbs+zPJ86znpt7oLqJ9m0/QygnIA3Vq P0PA== MIME-Version: 1.0 Received: by 10.224.180.141 with SMTP id bu13mr15157328qab.93.1334073675493; Tue, 10 Apr 2012 09:01:15 -0700 (PDT) Received: by 10.229.36.203 with HTTP; Tue, 10 Apr 2012 09:01:15 -0700 (PDT) In-Reply-To: References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> Date: Tue, 10 Apr 2012 18:01:15 +0200 Message-ID: Subject: Re: Why one Internet? From: Turchanyi Geza To: Pars Mutaf Content-Type: multipart/alternative; boundary=485b397dce8388307f04bd553bbd Cc: ipv6@ietf.org, Lixia Zhang 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, 10 Apr 2012 16:01:17 -0000 --485b397dce8388307f04bd553bbd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, yes, address translator and higher level gateways are tools to cope with the difficulties caused by the address shortage, but it is difficult to scale these tools and we can rid of them with the large scale deployment of IPv6 based Internet. Less energy consumption, clearer architecture... I thought this is clear for all of us... G=E9za On Tue, Apr 10, 2012 at 5:45 PM, Pars Mutaf wrote: > > > On Tue, Apr 10, 2012 at 6:25 PM, Cameron Byrne wrote= : > >> On Tue, Apr 10, 2012 at 8:03 AM, Pars Mutaf wrote= : >> > >> > >> > On Tue, Apr 10, 2012 at 5:31 PM, Brian E Carpenter >> > wrote: >> >> >> >> Lixia, >> >> >> >> The original note says "I think it is possible to locate the node we >> >> need." >> >> >> >> So, the idea is apparently not to divide the Internet - it is simply = to >> >> deal >> >> with the fact that addresses would be ambiguous. Since we have 15 yea= rs >> >> experience of the pain caused by ambiguous addresses, and a perfectly >> good >> >> 128 bit address space that avoids any need for ambiguous addresses, I >> >> don't >> >> see the point. It isn't even worth sending the code. >> >> >> >> Pars, >> >> >> >> Your original note also says "I am not here to discuss these details.= " >> >> Sorry, >> >> but in the IETF it's *exactly* the details that we must discuss; that= 's >> >> our >> >> job. We've been doing so since 1992 to my personal knowledge. >> >> >> > >> > I propose have a network of Internets: >> > >> > Internet1 >> > Internet2 >> > Internet3 >> > ... >> > Interntet_n >> > >> > In Internet 1 and 2 we may have two nodes with the same address. >> > The goal is to route the packet to the right Internet. I don't think i= t >> is >> > impossible. >> > >> >> Quite possible. Most people call it CGN. In fact, the IETF granted a >> /10 of IPv4 for this purpose. >> >> > You mean this one? > http://tools.ietf.org/html/rfc6264 > > Figure 1 looks like what I am proposing. Right? > > If so, we can also have a IPv7 with is, in addition to IPv6 (or directly > IPv7). I have no idea what IPv7 > would be and why it would be needed, but it looks like we should be > flexible (to me at least). > > Pars > > CB >> >> > Pars >> > >> > >> > >> >> >> >> Regards >> >> Brian >> >> >> >> On 2012-04-10 15:09, Lixia Zhang wrote: >> >> > the Internet is a means to communicate. >> >> > and the market drives for most effective/efficient/economical >> >> > communication systems (there are tradeoffs between the adjectives) >> >> > wonder if you could help explain how your picture of "network of >> >> > Internets" would be more effective and economical (than what we hav= e >> now) >> >> > >> >> > Lixia >> >> > >> >> > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> In my opinion, we can add one more Internet when necessary, then >> >> >> another one etc. >> >> >> >> >> >> We can have as many Internets as we need, all different. >> >> >> >> >> >> We just need a *network of Internets*. >> >> >> >> >> >> The first (current) Internet is an IPv4 Internet. >> >> >> The second Internet can be an IPv4 Internet too. In this case we >> would >> >> >> have 2 IPv4 Internets. >> >> >> Obviously, in this case, we would have the same addresses used by >> two >> >> >> different nodes in >> >> >> the two Internets. I think it is possible to locate the node we >> need. I >> >> >> am not here to discuss >> >> >> these details. >> >> >> >> >> >> The second Internet can be an IPv6 Internet. >> >> >> >> >> >> The second Internet can be a IPv7 Internet. >> >> >> >> >> >> The second Internet can be IPv6 but we may have a third one which = is >> >> >> IPv7 etc. >> >> >> >> >> >> We just need a network of Internets, all possibly different. >> >> >> >> >> >> Pars >> >> >> http://content-based-science.org/ >> >> >> ------------------------------------------------------------------= -- >> >> >> IETF IPv6 working group mailing list >> >> >> ipv6@ietf.org >> >> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >> >> >> ------------------------------------------------------------------= -- >> >> > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------ >> >> > >> >> > -------------------------------------------------------------------= - >> >> > 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 > -------------------------------------------------------------------- > > --485b397dce8388307f04bd553bbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

yes, address translator and higher level gateways are tools t= o cope with the difficulties caused by the address shortage, but

it = is difficult to scale these tools

and we can rid of them with the la= rge scale deployment of IPv6 based Internet.

Less energy consumption, clearer architecture...

I thought this = is clear for all of us...

G=E9za

O= n Tue, Apr 10, 2012 at 5:45 PM, Pars Mutaf <pars.mutaf@gmail.com> wrote:


On Tue, Apr 10, 2012 at 6:25 PM, Cameron Byrne <cb.list6@gm= ail.com> wrote:
On Tue, Apr 10, 2012 at 8:03 AM, Pars Mutaf <pars.mutaf@gmail.com> wrote= :
>
>
> On Tue, Apr 10, 2012 at 5:31 PM, Brian E Carpenter
> <b= rian.e.carpenter@gmail.com> wrote:
>>
>> Lixia,
>>
>> The original note says "I think it is possible to locate the = node we
>> need."
>>
>> So, the idea is apparently not to divide the Internet - it is simp= ly to
>> deal
>> with the fact that addresses would be ambiguous. Since we have 15 = years
>> experience of the pain caused by ambiguous addresses, and a perfec= tly good
>> 128 bit address space that avoids any need for ambiguous addresses= , I
>> don't
>> see the point. It isn't even worth sending the code.
>>
>> Pars,
>>
>> Your original note also says "I am not here to discuss these = details."
>> Sorry,
>> but in the IETF it's *exactly* the details that we must discus= s; that's
>> our
>> job. We've been doing so since 1992 to my personal knowledge.<= br> >>
>
> I propose have a network of Internets:
>
> Internet1
> Internet2
> Internet3
> ...
> Interntet_n
>
> In Internet 1 and 2 we may have two nodes with the same address.
> The goal is to route the packet to the right Internet. I don't thi= nk it is
> impossible.
>

Quite possible. Most people call it CGN. =A0In fact, the IETF g= ranted a
/10 of IPv4 for this purpose.


You mean this one?

Figure 1 looks like what I am proposing. Right?

If so, we can also have a IPv7 with is, in addition to IPv6 (or di= rectly IPv7). I have no idea what IPv7=A0
would=A0be and why it w= ould be needed,=A0but it looks like=A0we should be flexible (to me at least= ).

Pars=A0
=
CB

> Pars
>
>
>
>>
>> Regards
>> =A0 Brian
>>
>> On 2012-04-10 15:09, Lixia Zhang wrote:
>> > the Internet is a means to communicate.
>> > and the market drives for most effective/efficient/economical=
>> > communication systems (there are tradeoffs between the adject= ives)
>> > wonder if you could help explain how your picture of "ne= twork of
>> > Internets" would be more effective and economical (than = what we have now)
>> >
>> > Lixia
>> >
>> > On Apr 10, 2012, at 6:24 AM, Pars Mutaf wrote:
>> >
>> >> Hi,
>> >>
>> >> In my opinion, we can add one more Internet when necessar= y, then
>> >> another one etc.
>> >>
>> >> We can have as many Internets as we need, all different.<= br> >> >>
>> >> We just need a *network of Internets*.
>> >>
>> >> The first (current) Internet is an IPv4 Internet.
>> >> The second Internet can be an IPv4 Internet too. In this = case we would
>> >> have 2 IPv4 Internets.
>> >> Obviously, in this case, we would have the same addresses= used by two
>> >> different nodes in
>> >> the two Internets. I think it is possible to locate the n= ode we need. I
>> >> am not here to discuss
>> >> these details.
>> >>
>> >> The second Internet can be an IPv6 Internet.
>> >>
>> >> The second Internet can be a IPv7 Internet.
>> >>
>> >> The second Internet can be IPv6 but we may have a third o= ne which is
>> >> IPv7 etc.
>> >>
>> >> We just need a network of Internets, all possibly differe= nt.
>> >>
>> >> Pars
>> >> http://content-based-science.org/
>> >> ---------------------------------------------------------= -----------
>> >> IETF IPv6 working group mailing list
>> >> ipv6@i= etf.org
>> >> Administrative Requests: https://www.ietf.org/mailman/listi= nfo/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<= br> > -------------------------------------------------------------------- >


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


--485b397dce8388307f04bd553bbd-- From sander@steffann.nl Tue Apr 10 11:49: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 810F211E80D9 for ; Tue, 10 Apr 2012 11:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SARE_MILLIONSOF=0.315] 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 2zEXf8x9Wo6F for ; Tue, 10 Apr 2012 11:49:16 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5711E80B8 for ; Tue, 10 Apr 2012 11:49:16 -0700 (PDT) Received: from macpro.10ww.steffann.nl (macpro.10ww.steffann.nl [37.77.56.75]) by mail.sintact.nl (Postfix) with ESMTP id 7047D2023; Tue, 10 Apr 2012 20:49:15 +0200 (CEST) Subject: Re: Why one Internet? Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Sander Steffann In-Reply-To: Date: Tue, 10 Apr 2012 20:49:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A473079-6CF0-49B9-93CD-F0BA27500CEF@cs.ucla.edu> <4F844428.7050408@gmail.com> To: Pars Mutaf 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, 10 Apr 2012 18:49:17 -0000 Hi Pars, > I propose have a network of Internets: >=20 > Internet1 > Internet2 > Internet3 > ... > Interntet_n >=20 > In Internet 1 and 2 we may have two nodes with the same address.=20 > The goal is to route the packet to the right Internet. I don't think = it is impossible. You should talk to Jos Vrancken. He has been talking about such ideas = for years. See = http://www.nextgenerationinfrastructures.eu/index.php?pageID=3D17&itemID=3D= 449455 I think you'll get along with him. He also says things like "I am not = here to discuss these details." and "I don't think it is impossible." = when people ask him about how his ideas could possibly work... It can be = fun for theoretical research, but not for running a real world wide = network with millions of users... - Sander From carlosm3011@gmail.com Tue Apr 10 11:53: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 AEB2211E80B8 for ; Tue, 10 Apr 2012 11:53:44 -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 Ce1RbhPx4453 for ; Tue, 10 Apr 2012 11:53:43 -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 A08A611E80FD for ; Tue, 10 Apr 2012 11:53:43 -0700 (PDT) Received: by ggmi1 with SMTP id i1so101129ggm.31 for ; Tue, 10 Apr 2012 11:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=IfO/n+F6cVuZ9MN58awN/FJPZ4IisnnVr64KB0Vz6iM=; b=IKancV0dlWZlmIrlmuUClmz4yzoDMMz56j7rJ11aPx/NVPBvriAROSU/mTElwajcAo bYePWra86IOdoesO7NLGeyPcJRshw5JLUjIjoYjxEiVdynBMCe5uQrdx7lDbLK7NYHWX qmC2X8xsLq5+TCDpmsVlGMzo2AD0MpJzi4wOJ4LvlJcleNZEdV8Tqz/B9BYSb6Vspci2 ahFsk7tLBjkMO8SjWneqoxDHTACotQTLbwQf5uFC13uQQ/Gt6qTO9K0d7FCqwOvlBhv7 GwQBaOCsXTW3Gfuw2zgAxoAO1xeHrsSNIde7UtB3w3W8B/bvfx9H/6uQOAENz1DETpdr 9cvg== Received: by 10.236.175.164 with SMTP id z24mr10717321yhl.101.1334084023298; Tue, 10 Apr 2012 11:53:43 -0700 (PDT) Received: from europa.local ([200.7.85.168]) by mx.google.com with ESMTPS id e45sm608109yhk.2.2012.04.10.11.53.40 (version=SSLv3 cipher=OTHER); Tue, 10 Apr 2012 11:53:41 -0700 (PDT) Message-ID: <4F8481B1.2000101@gmail.com> Date: Tue, 10 Apr 2012 15:53:37 -0300 From: Carlos Martinez-Cagnazzo 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: Pars Mutaf Subject: Re: Why one Internet? References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070302060303030602040104" Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:53:44 -0000 This is a multi-part message in MIME format. --------------070302060303030602040104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wasn't this what the Internet was supposed to be? I'm tempted to ask how old you are, but I don't want to be rude. As the Monty Python would put it: 'You see, the key is in the name - Inter - net(work)' :-) cheers Carlos On 4/10/12 10:24 AM, Pars Mutaf wrote: > Hi, > > In my opinion, we can add one more Internet when necessary, then > another one etc. > > We can have as many Internets as we need, all different. > > We just need a *network of Internets*. > > The first (current) Internet is an IPv4 Internet. > The second Internet can be an IPv4 Internet too. In this case we would > have 2 IPv4 Internets. > Obviously, in this case, we would have the same addresses used by two > different nodes in > the two Internets. I think it is possible to locate the node we need. > I am not here to discuss > these details. > > The second Internet can be an IPv6 Internet. > > The second Internet can be a IPv7 Internet. > > The second Internet can be IPv6 but we may have a third one which is > IPv7 etc. > > We just need a network of Internets, all possibly different. > > Pars > http://content-based-science.org/ > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --------------070302060303030602040104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wasn't this what the Internet was supposed to be? I'm tempted to ask how old you are, but I don't want to be rude.

As the Monty Python would put it: 'You see, the key is in the name - Inter - net(work)'

:-)

cheers

Carlos

On 4/10/12 10:24 AM, Pars Mutaf wrote:
Hi,

In my opinion, we can add one more Internet when necessary, then another one etc. 

We can have as many Internets as we need, all different. 

We just need a *network of Internets*. 

The first (current) Internet is an IPv4 Internet.
The second Internet can be an IPv4 Internet too. In this case we would have 2 IPv4 Internets. 
Obviously, in this case, we would have the same addresses used by two different nodes in 
the two Internets. I think it is possible to locate the node we need. I am not here to discuss 
these details. 

The second Internet can be an IPv6 Internet. 

The second Internet can be a IPv7 Internet. 

The second Internet can be IPv6 but we may have a third one which is IPv7 etc. 

We just need a network of Internets, all possibly different. 

Pars


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------070302060303030602040104-- From albert.e.manfredi@boeing.com Tue Apr 10 12:49: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 1885A11E813B for ; Tue, 10 Apr 2012 12:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 lIVU65nIt+-n for ; Tue, 10 Apr 2012 12:49:36 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB2911E8139 for ; Tue, 10 Apr 2012 12:49:36 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q3AJEgmk027444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Apr 2012 14:20:52 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q3AJCxIj009246 for ; Tue, 10 Apr 2012 12:13:00 -0700 (PDT) Received: from XCH-MWHT-04.mw.nos.boeing.com (xch-mwht-04.mw.nos.boeing.com [134.57.113.164]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q3AJCvLr009145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 10 Apr 2012 12:12:57 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-04.mw.nos.boeing.com ([134.57.113.164]) with mapi; Tue, 10 Apr 2012 14:12:57 -0500 From: "Manfredi, Albert E" To: Pars Mutaf Date: Tue, 10 Apr 2012 14:12:55 -0500 Subject: RE: Why one Internet? Thread-Topic: Why one Internet? Thread-Index: Ac0XS0ldI6Z/UYJDTLqbd2XkZU6yvQAAadgw Message-ID: References: <4F8481B1.2000101@gmail.com> In-Reply-To: <4F8481B1.2000101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B0147C3DD45E42478038FC347CCB65FE02BB7026F4XCHMW08Vmwnos_" MIME-Version: 1.0 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, 10 Apr 2012 19:49:37 -0000 --_000_B0147C3DD45E42478038FC347CCB65FE02BB7026F4XCHMW08Vmwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that was also my reaction. Why one Internet? Because Internet means ty= ing together multiple separate networks. Of course you can have the same ad= dresses on the different networks. Nothing new there either. That's why we = have NATs, NAPTs, and IPv6 NPTs. No one is forcing an ISP or an enterprise network to use a combination of p= rotocols. They can already opt to be IPv4 only, or IPv6 only, or dual stack= , or eventually IPv7. Matter of fact, years ago, our enterprise had an asso= rtment of different networks, tied together by Softswitch gateways. IPv4, S= NA, DECnet. Bert From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Car= los Martinez-Cagnazzo Sent: Tuesday, April 10, 2012 2:54 PM To: Pars Mutaf Cc: ipv6@ietf.org Subject: Re: Why one Internet? Wasn't this what the Internet was supposed to be? I'm tempted to ask how ol= d you are, but I don't want to be rude. As the Monty Python would put it: 'You see, the key is in the name - Inter = - net(work)' :-) cheers Carlos --_000_B0147C3DD45E42478038FC347CCB65FE02BB7026F4XCHMW08Vmwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Yes, that was also my reaction. Why one Internet= ? Because Internet means tying together multiple separate networks. Of cour= se you can have the same addresses on the different networks. Nothing new t= here either. That’s why we have NATs, NAPTs, and IPv6 NPTs.

 

No one is forc= ing an ISP or an enterprise network to use a combination of protocols. They= can already opt to be IPv4 only, or IPv6 only, or dual stack, or eventuall= y IPv7. Matter of fact, years ago, our enterprise had an assortment of diff= erent networks, tied together by Softswitch gateways. IPv4, SNA, DECnet.

&nb= sp;

Bert

&nb= sp;

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] O= n Behalf Of Carlos Martinez-Cagnazzo
Sent: Tuesday, April 10,= 2012 2:54 PM
To: Pars Mutaf
Cc: ipv6@ietf.org
Su= bject: Re: Why one Internet?

 

Wasn't this what the= Internet was supposed to be? I'm tempted to ask how old you are, but I don= 't want to be rude.

As the Monty Python would put it: 'You see, the = key is in the name - Inter - net(work)'

:-)

cheers

Car= los

= --_000_B0147C3DD45E42478038FC347CCB65FE02BB7026F4XCHMW08Vmwnos_-- From internet-drafts@ietf.org Tue Apr 10 15:27: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 B3E6C11E8141; Tue, 10 Apr 2012 15:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 DGbQxqAXv7hM; Tue, 10 Apr 2012 15:27:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C03011E8119; Tue, 10 Apr 2012 15:27:46 -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-rfc3484bis-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120410222746.31449.76472.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 15:27:46 -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, 10 Apr 2012 22:27:46 -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-02.txt Pages : 30 Date : 2012-04-10 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-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-rfc3484bis-02.txt From dthaler@microsoft.com Tue Apr 10 15:32: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 DAD2911E80F4 for ; Tue, 10 Apr 2012 15:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.649 X-Spam-Level: X-Spam-Status: No, score=-103.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 9JZ2nSPA4cEh for ; Tue, 10 Apr 2012 15:32:55 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 186AF11E8081 for ; Tue, 10 Apr 2012 15:32:55 -0700 (PDT) Received: from mail85-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Apr 2012 22:32:54 +0000 Received: from mail85-va3 (localhost [127.0.0.1]) by mail85-va3-R.bigfish.com (Postfix) with ESMTP id 75CC3100330; Tue, 10 Apr 2012 22:32:54 +0000 (UTC) X-SpamScore: -6 X-BigFish: VS-6(zz1432Nzz1202hzzz2fh2a8h668h839h93fhd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail85-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail85-va3 (localhost.localdomain [127.0.0.1]) by mail85-va3 (MessageSwitch) id 1334097173595748_32721; Tue, 10 Apr 2012 22:32:53 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.243]) by mail85-va3.bigfish.com (Postfix) with ESMTP id 8BF7B2C0046; Tue, 10 Apr 2012 22:32:53 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Apr 2012 22:32:49 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 10 Apr 2012 22:32:47 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0283.004; Tue, 10 Apr 2012 15:32:47 -0700 From: Dave Thaler To: Brian E Carpenter Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNC+wBSVlewb1jE0uYOWOUBxq41JZ/ZbAAgBPdqECAAOdQAIAAkKBA Date: Tue, 10 Apr 2012 22:32:46 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F83D8D0.5030402@gmail.com> In-Reply-To: <4F83D8D0.5030402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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, 10 Apr 2012 22:32:56 -0000 QnJpYW4gQ2FycGVudGVyIHdyaXRlczoNCj4gPiBUaGUgd29yZGluZyBJIHByb3Bvc2UgdG8gYWRk IGlzOg0KPiA+IA0KPiA+ICAgICAiVGhlcmUgU0hPVUxEIGJlIGFuIGFkbWluaXN0cmF0aXZlIG9w dGlvbiB0byBjaGFuZ2UgdGhpcyBwcmVmZXJlbmNlLCBpZiB0aGUgDQo+ID4gICAgIGltcGxlbWVu dGF0aW9uIHN1cHBvcnRzIHByaXZhY3kgYWRkcmVzc2VzLiAgSWYgdGhlcmUgaXMgbm8gc3VjaCBv cHRpb24sIHRoZXJlIA0KPiA+ICAgICBNVVNUIGJlIGFuIGFkbWluaXN0cmF0aXZlIG9wdGlvbiB0 byBkaXNhYmxlIHByaXZhY3kgYWRkcmVzc2VzLiINCj4gPiANCj4gPiAtRGF2ZQ0KPg0KPiBUaGF0 IHdvcmtzIGZvciBtZS4gUGVyaGFwcyB0aGVyZSBhbHNvIG5lZWRzIHRvIGJlIGEgZ2VuZXJhbCBz dGF0ZW1lbnQgaW4gdGhlIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIHRoYXQgYWxsIGFkbWlu aXN0cmF0aXZlIGNoYW5nZXMgYW5kIG9wdGlvbnMgTVVTVCBiZSBzZWN1cmVkIGFnYWluc3QgaWxs aWNpdCB1c2UuDQoNCkRvbmUuICAgRHJhZnQgLTAyIG5vdyBpbmNsdWRlcyB0aGUgd29yZGluZyBh Ym92ZSwgYW5kIGFkZHMgYSBnZW5lcmFsIHN0YXRlbWVudCBpbiB0aGUNCnNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24gYXMgeW91IHN1Z2dlc3RlZC4NCg0KLURhdmUNCg== From pars.mutaf@gmail.com Wed Apr 11 00:29: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 A510821F866D for ; Wed, 11 Apr 2012 00:29:03 -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 XWgMos8jFa3Q for ; Wed, 11 Apr 2012 00:29:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A80B521F851B for ; Wed, 11 Apr 2012 00:29:02 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so985663obb.31 for ; Wed, 11 Apr 2012 00:29:02 -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=+/U2iHXH7KxAWVVwOWGF6/IJGjR9eDzsjSHfMR/CdqQ=; b=QWeb9m5mgoIfxIW8b10T59LzpXyAns3M4iaHL88XIzP7fiXKrbh90P1SFuWZy/GbE2 ZequOuvhLWAe71Ts5wGTyxM7bCPvECcOa7EpZaDj0Ks9lbiLjSKo3eEYqUkA+t+mriRz v5ziCvnG46IGL4lsm5isaUZ6lgkAqN2de8Zy3DSBJ1XdoG8W6Ip2c4Gy2FxVr5kkXqi6 2cuvBdpsRLEW2gvbSBrl2EZz9W3gPJcnPz0so04lYtwpD+llRXx2EPUAcGthEkLsUW2o Mw1xWWUoDWmwN7Tp6jaAgMPnDotnqfsjf48rheqH8DvrdnxSekkLTtZs0EpHxc4Ttxh5 rhkA== MIME-Version: 1.0 Received: by 10.182.114.70 with SMTP id je6mr20402619obb.30.1334129342182; Wed, 11 Apr 2012 00:29:02 -0700 (PDT) Received: by 10.182.44.104 with HTTP; Wed, 11 Apr 2012 00:29:02 -0700 (PDT) In-Reply-To: References: <4F8481B1.2000101@gmail.com> Date: Wed, 11 Apr 2012 10:29:02 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: "Manfredi, Albert E" Content-Type: multipart/alternative; boundary=f46d0444746b86745904bd623118 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, 11 Apr 2012 07:29:03 -0000 --f46d0444746b86745904bd623118 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Apr 10, 2012 at 10:12 PM, Manfredi, Albert E < albert.e.manfredi@boeing.com> wrote: > Yes, that was also my reaction. Why one Internet? Because Internet means > tying together multiple separate networks. Of course you can have the sam= e > addresses on the different networks. Nothing new there either. That=92s w= hy > we have NATs, NAPTs, and IPv6 NPTs.**** > > ** ** > > No one is forcing an ISP or an enterprise network to use a combination of > protocols. They can already opt to be IPv4 only, or IPv6 only, or dual > stack, or eventually IPv7. Matter of fact, years ago, our enterprise had = an > assortment of different networks, tied together by Softswitch gateways. > IPv4, SNA, DECnet.**** > > ** > I have no problem with anyone. I am facing my own illusions. Here is my conclusion after years of work on IPv6. IPv6 guy is just a salesman. But the salesman thought the entire world should buy his product. The product cannot change. There is no other product. Not even sure the product was really needed. Complete delusion. Pars > ** > > Bert**** > > ** ** > > *From:* ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] *On Behalf > Of *Carlos Martinez-Cagnazzo > *Sent:* Tuesday, April 10, 2012 2:54 PM > *To:* Pars Mutaf > *Cc:* ipv6@ietf.org > *Subject:* Re: Why one Internet?**** > > ** ** > > Wasn't this what the Internet was supposed to be? I'm tempted to ask how > old you are, but I don't want to be rude. > > As the Monty Python would put it: 'You see, the key is in the name - Inte= r > - net(work)' > > :-) > > cheers > > Carlos > > **** > --f46d0444746b86745904bd623118 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Apr 10, 2012 at 10:12 PM, Manfre= di, Albert E <albert.e.manfredi@boeing.com> wrote:
<= p class=3D"MsoNormal">Yes, that was also my reac= tion. Why one Internet? Because Internet means tying together multiple sepa= rate networks. Of course you can have the same addresses on the different n= etworks. Nothing new there either. That=92s why we have NATs, NAPTs, and IP= v6 NPTs.

=A0<= /p>

No one is forcing an I= SP or an enterprise network to use a combination of protocols. They can alr= eady opt to be IPv4 only, or IPv6 only, or dual stack, or eventually IPv7. = Matter of fact, years ago, our enterprise had an assortment of different ne= tworks, tied together by Softswitch gateways. IPv4, SNA, DECnet.<= /u>

=A0


I have no problem with anyone. I a= m facing my own illusions.=A0

Here is my conclusio= n after years of work on IPv6.=A0

IPv6 guy is just a salesman.=A0

But the salesman thought the entire world should buy his product.=A0=

The product cannot change.

There is no other product.=A0

Not even sure the pr= oduct was really needed.=A0

Complete delusion.=A0<= /div>

Pars

=A0

--f46d0444746b86745904bd623118-- From mohacsi@niif.hu Wed Apr 11 00:53: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 E7BBB11E8096 for ; Wed, 11 Apr 2012 00:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_41=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 hUSWQvGTcISo for ; Wed, 11 Apr 2012 00:53:39 -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 BEF5D11E808C for ; Wed, 11 Apr 2012 00:53:38 -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 B798387ACB; Wed, 11 Apr 2012 09:53:36 +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 PlhjOWLLpD5P; Wed, 11 Apr 2012 09:53:32 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id D52C687AC2; Wed, 11 Apr 2012 09:53:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id D377487AA7; Wed, 11 Apr 2012 09:53:32 +0200 (CEST) Date: Wed, 11 Apr 2012 09:53:32 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Pars Mutaf Subject: Re: Why one Internet? In-Reply-To: Message-ID: References: <4F8481B1.2000101@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2049064918-1334130692=:40024" Content-ID: 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, 11 Apr 2012 07:53:40 -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. --0-2049064918-1334130692=:40024 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Wed, 11 Apr 2012, Pars Mutaf wrote: > > > On Tue, Apr 10, 2012 at 10:12 PM, Manfredi, Albert E wrote: > > Yes, that was also my reaction. Why one Internet? Because Internet means tying together multiple separate networks. Of course you can have the same > addresses on the different networks. Nothing new there either. That?s why we have NATs, NAPTs, and IPv6 NPTs. > >   > > No one is forcing an ISP or an enterprise network to use a combination of protocols. They can already opt to be IPv4 only, or IPv6 only, or dual > stack, or eventually IPv7. Matter of fact, years ago, our enterprise had an assortment of different networks, tied together by Softswitch gateways. > IPv4, SNA, DECnet. > >   > > > I have no problem with anyone. I am facing my own illusions.  > > Here is my conclusion after years of work on IPv6.  > > IPv6 guy is just a salesman.  > > But the salesman thought the entire world should buy his product.  Not, but a reasonable technology for go forward with. > > The product cannot change. Wrong, See evolution of IPv6 in the past 10 years - lot has been changed - due to better understanding of requirements and drawback of certain solutions. > > There is no other product.  Yes there are, but ipv6 seems to be most reasonable at the moment. > > Not even sure the product was really needed.  See ipng work in the late 90's - it was requirement driven. > > Complete delusion.  Please describe your conception in details - we can compare solutions based on technical merits. Best Regards, Janos Mohacsi > > Pars > >   > > Bert > >   > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Carlos Martinez-Cagnazzo > Sent: Tuesday, April 10, 2012 2:54 PM > To: Pars Mutaf > Cc: ipv6@ietf.org > Subject: Re: Why one Internet? > >   > > Wasn't this what the Internet was supposed to be? I'm tempted to ask how old you are, but I don't want to be rude. > > As the Monty Python would put it: 'You see, the key is in the name - Inter - net(work)' > > :-) > > cheers > > Carlos > > > > --0-2049064918-1334130692=:40024-- From pars.mutaf@gmail.com Wed Apr 11 01:05: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 A5DAC21F866B for ; Wed, 11 Apr 2012 01:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=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 LYmZFfcWSiEY for ; Wed, 11 Apr 2012 01:05:41 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5C2721F866A for ; Wed, 11 Apr 2012 01:05:40 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1025282obb.31 for ; Wed, 11 Apr 2012 01:05:40 -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=j/vT+Pnhfq1Kx/cwLWv6EZJ3qdp5q8CT5Ucmx66Tsok=; b=CmkEDhThVLvDxMdtcb+1XuZvMNKr03hwg/4yEzPJeH736kh9b0NtzwWbYKiH8uw3ww qxKMzYhcN3reUsVHdDF6KOAqCURvIEPtlPbOoECP/F8zRMZ16pbragABjXT/NDlkNFFs 0JhgPSwGFZn6559yHGTCHxoy/jEsH/ALjI4Pigwe67RJNg9lJ23XtmnccVF8Xg98L52d YhTfKnPNHlAAtzWuwg8Ki9/tZJkWoOxc6swTSrcAhyaw8jflgHDIvIaXWc/8zmXR3x9e gtPB9stWhStwDEfUOQ/35aMPsDc0fkaiDPNhmxtCHPpcp7mx5h8S4MHGI8N14jBK2hdV 3Akg== MIME-Version: 1.0 Received: by 10.60.27.170 with SMTP id u10mr20698615oeg.50.1334131540475; Wed, 11 Apr 2012 01:05:40 -0700 (PDT) Received: by 10.182.44.104 with HTTP; Wed, 11 Apr 2012 01:05:40 -0700 (PDT) In-Reply-To: References: <4F8481B1.2000101@gmail.com> Date: Wed, 11 Apr 2012 11:05:40 +0300 Message-ID: Subject: Re: Why one Internet? From: Pars Mutaf To: Mohacsi Janos Content-Type: multipart/alternative; boundary=e89a8f6433168dbd8c04bd62b4fe 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, 11 Apr 2012 08:05:41 -0000 --e89a8f6433168dbd8c04bd62b4fe Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 11, 2012 at 10:53 AM, Mohacsi Janos wrote: > > > > On Wed, 11 Apr 2012, Pars Mutaf wrote: > > >> >> On Tue, Apr 10, 2012 at 10:12 PM, Manfredi, Albert E < >> albert.e.manfredi@boeing.com> wrote: >> >> Yes, that was also my reaction. Why one Internet? Because Internet >> means tying together multiple separate networks. Of course you can have the >> same >> addresses on the different networks. Nothing new there either. >> That?s why we have NATs, NAPTs, and IPv6 NPTs. >> >> >> >> >> No one is forcing an ISP or an enterprise network to use a >> combination of protocols. They can already opt to be IPv4 only, or IPv6 >> only, or dual >> stack, or eventually IPv7. Matter of fact, years ago, our enterprise >> had an assortment of different networks, tied together by Softswitch >> gateways. >> IPv4, SNA, DECnet. >> >> >> >> >> I have no problem with anyone. I am facing my own illusions. >> >> Here is my conclusion after years of work on IPv6. >> >> IPv6 guy is just a salesman. >> >> But the salesman thought the entire world should buy his product. >> > > Not, but a reasonable technology for go forward with. > > >> The product cannot change. >> > > Wrong, See evolution of IPv6 in the past 10 years - lot has been changed - > due to better understanding of requirements and drawback of certain > solutions. > > > >> There is no other product. >> > > Yes there are, but ipv6 seems to be most reasonable at the moment. > > > >> Not even sure the product was really needed. >> > > See ipng work in the late 90's - it was requirement driven. > > >> Complete delusion. >> > > > Please describe your conception in details - we can compare solutions > based on technical merits. > Sorry I don't see the problem yet. I wouldn't design a solution nor discuss its details. Designing the future makes me suffer. Pars > Best Regards, > Janos Mohacsi > > > >> Pars >> >> >> >> Bert >> >> >> >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >> Behalf Of Carlos Martinez-Cagnazzo >> Sent: Tuesday, April 10, 2012 2:54 PM >> To: Pars Mutaf >> Cc: ipv6@ietf.org >> Subject: Re: Why one Internet? >> >> >> >> Wasn't this what the Internet was supposed to be? I'm tempted to ask how >> old you are, but I don't want to be rude. >> >> As the Monty Python would put it: 'You see, the key is in the name - >> Inter - net(work)' >> >> :-) >> >> cheers >> >> Carlos >> >> >> >> --e89a8f6433168dbd8c04bd62b4fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 11, 2012 at 10:53 AM, Mohacs= i Janos <mohacsi@ni= if.hu> wrote:



On Wed, 11 Apr 2012, Pars Mutaf wrote:



On Tue, Apr 10, 2012 at 10:12 PM, Manfredi, Albert E <albert.e.manfredi@boeing.co= m> wrote:

=A0 =A0 =A0Yes, that was also my reaction. Why one Internet? Because Inter= net means tying together multiple separate networks. Of course you can have= the same
=A0 =A0 =A0addresses on the different networks. Nothing new there either. = That?s why we have NATs, NAPTs, and IPv6 NPTs.


=A0 =A0 =A0=A0

=A0 =A0 =A0No one is forcing an ISP or an enterprise network to use a comb= ination of protocols. They can already opt to be IPv4 only, or IPv6 only, o= r dual
=A0 =A0 =A0stack, or eventually IPv7. Matter of fact, years ago, our enter= prise had an assortment of different networks, tied together by Softswitch = gateways.
=A0 =A0 =A0IPv4, SNA, DECnet.

=A0 =A0 =A0=A0


I have no problem with anyone. I am facing my own illusions.=A0

Here is my conclusion after years of work on IPv6.=A0

IPv6 guy is just a salesman.=A0

But the salesman thought the entire world should buy his product.=A0

Not, but a reasonable technology for go forward with.


The product cannot change.

Wrong, See evolution of IPv6 in the past 10 years - lot has been changed - = due to better understanding of requirements and drawback of certain solutio= ns.



There is no other product.=A0

Yes there are, but ipv6 seems to be most reasonable at the moment.



Not even sure the product was really needed.=A0

See ipng work in the late 90's - it was requirement driven.


Complete delusion.=A0


Please describe your conception in details - we can compare solutions based= on technical merits.

Sorry I don't= see the problem yet. I wouldn't design a solution nor discuss its deta= ils.=A0

Designing the future makes me suffer.=A0

=
Pars

=A0
=A0 =A0 =A0 =A0Best Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Janos Mohacsi



Pars

=A0

=A0 =A0 =A0Bert

=A0 =A0 =A0=A0

=A0 =A0 =A0From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Carlos Martinez= -Cagnazzo
=A0 =A0 =A0Sent: Tuesday, April 10, 2012 2:54 PM
=A0 =A0 =A0To: Pars Mutaf
=A0 =A0 =A0Cc: ipv6@iet= f.org
=A0 =A0 =A0Subject: Re: Why one Internet?

=A0

Wasn't this what the Internet was supposed to be? I'm tempted to as= k how old you are, but I don't want to be rude.

As the Monty Python would put it: 'You see, the key is in the name - In= ter - net(work)'

:-)

cheers

Carlos




--e89a8f6433168dbd8c04bd62b4fe-- From mohacsi@niif.hu Wed Apr 11 01:11:58 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 D90E821F850D for ; Wed, 11 Apr 2012 01:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=0.300, 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 yoiNzPwxlRCW for ; Wed, 11 Apr 2012 01:11:58 -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 CF91121F8507 for ; Wed, 11 Apr 2012 01:11:56 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id D2C4887AAF; Wed, 11 Apr 2012 10:11:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id jIdOmDFqP4Oo; Wed, 11 Apr 2012 10:11:46 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id A8A1C87916; Wed, 11 Apr 2012 10:11:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id A67ED8781F; Wed, 11 Apr 2012 10:11:46 +0200 (CEST) Date: Wed, 11 Apr 2012 10:11:46 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Pars Mutaf Subject: Re: Why one Internet? In-Reply-To: Message-ID: References: <4F8481B1.2000101@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1623292962-1334131906=:40024" 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, 11 Apr 2012 08:11:59 -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. --0-1623292962-1334131906=:40024 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 Apr 2012, Pars Mutaf wrote: > > Sorry I don't see the problem yet. I wouldn't design a solution nor discuss its details.  > > Designing the future makes me suffer.  Then, you are probably on a wrong mailing list. Regards, Janos Mohacsi --0-1623292962-1334131906=:40024-- From v6ops@globis.net Wed Apr 11 06: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 DCF3011E816E for ; Wed, 11 Apr 2012 06: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=[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 hVD2pngJjeGM for ; Wed, 11 Apr 2012 06:50:53 -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 0CA2611E816B for ; Wed, 11 Apr 2012 06:50:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6F5AA8700F3; Wed, 11 Apr 2012 15:50:51 +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 IqmpYcGw+ENw; Wed, 11 Apr 2012 15:50:43 +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 528C48700EC; Wed, 11 Apr 2012 15:50:43 +0200 (CEST) Message-ID: <4F858C32.6060709@globis.net> Date: Wed, 11 Apr 2012 15:50:42 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Dave Thaler Subject: Re: RE: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F83D8D0.5030402@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-15; 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: Wed, 11 Apr 2012 13:50:54 -0000 With all due respect to everyone concerned, there's no way an end user or IT department can buy a bunch of machines based on the text currently contained in this proposed Standard Track document and 1) be able to predict how each machine will behave by defaultin advance of actually plugging it in. 2) be able to effectively manage a machine's behaviour remotely via an IETF defined control mechanism, because the various MAYs and SHOULDs cannot be overridden by the two things that are actually reasonably well defined by the IETF i.e. the prefix policy table + draft-ietf-6man-addr-select-opt-03 for transporting that policy table. That suggests to me that we're not yet completely on the right track. IMHO If there's an implementation option in 3484bis, there should always be a corresponding control option in the (prefix) policy table, plus a way to effectively transport that policy table in e.g. draft-ietf-6man-addr-select-opt-03. Align and package all 3 together, and you have a far better solution. regards, RayH Dave Thaler wrote: > Brian Carpenter writes: >>> > > The wording I propose to add is: >>> > > >>> > > "There SHOULD be an administrative option to change this preference, if the >>> > > implementation supports privacy addresses. If there is no such option, there >>> > > MUST be an administrative option to disable privacy addresses." >>> > > >>> > > -Dave >> > >> > That works for me. Perhaps there also needs to be a general statement in the security >> > considerations that all administrative changes and options MUST be secured against illicit use. > > Done. Draft-02 now includes the wording above, and adds a general statement in the > security considerations section as you suggested. > > -Dave From Kavalec@bswa.com Wed Apr 11 07:53: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 853D611E80A5 for ; Wed, 11 Apr 2012 07:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 9c1rnIofHEMM for ; Wed, 11 Apr 2012 07:53:08 -0700 (PDT) Received: from mail.bswa.com (unknown [12.185.92.2]) by ietfa.amsl.com (Postfix) with ESMTP id D267B11E80C2 for ; Wed, 11 Apr 2012 07:53:07 -0700 (PDT) Subject: RE: Why one Internet? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD17F2.97BDC556" Date: Wed, 11 Apr 2012 09:51:34 -0500 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why one Internet? Thread-Index: Ac0XHOCkb1c9LfmSRD63PCFAB6YAKQA1XXSw References: From: "Greg Kavalec" To: "Pars Mutaf" , 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, 11 Apr 2012 14:53:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD17F2.97BDC556 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Avoiding the situation you describe is exactly why "The Internet" was commercially adopted. =20 Without One Internet, we will have commercial walled gardens; open exchange of information will suffer. =20 =20 =20 From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Pars Mutaf Sent: Tuesday, April 10, 2012 8:25 AM To: ipv6@ietf.org Subject: Why one Internet? =20 Hi, =20 In my opinion, we can add one more Internet when necessary, then another one etc.=20 =20 We can have as many Internets as we need, all different.=20 =20 We just need a *network of Internets*.=20 =20 The first (current) Internet is an IPv4 Internet. The second Internet can be an IPv4 Internet too. In this case we would have 2 IPv4 Internets.=20 Obviously, in this case, we would have the same addresses used by two different nodes in=20 the two Internets. I think it is possible to locate the node we need. I am not here to discuss=20 these details.=20 =20 The second Internet can be an IPv6 Internet.=20 =20 The second Internet can be a IPv7 Internet.=20 =20 The second Internet can be IPv6 but we may have a third one which is IPv7 etc.=20 =20 We just need a network of Internets, all possibly different.=20 =20 Pars http://content-based-science.org/ =20 ------_=_NextPart_001_01CD17F2.97BDC556 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Avoiding the situation you describe is exactly why “The = Internet” was commercially adopted.

 

Without One Internet, we will have commercial walled gardens; open = exchange of information will suffer.

 

 

 

From:= = ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Pars Mutaf
Sent: Tuesday, April 10, 2012 8:25 = AM
To: ipv6@ietf.org
Subject: Why one = Internet?

 

Hi,

 

In my opinion, we can add one more Internet when = necessary, then another one etc. 

 

We can have as many Internets as we need, all = different. 

 

We just need a *network of = Internets*. 

 

The first (current) Internet is an IPv4 = Internet.

The second = Internet can be an IPv4 Internet too. In this case we would have 2 IPv4 = Internets. 

Obviously, in this case, we would have the same = addresses used by two different nodes = in 

the two = Internets. I think it is possible to locate the node we need. I am not = here to discuss 

these details. 

 

The second Internet can be an IPv6 = Internet. 

 

The second Internet can be a IPv7 = Internet. 

 

The second Internet can be IPv6 but we may have a = third one which is IPv7 etc. 

 

We just need a network of Internets, all possibly = different. 

 

Pars

------_=_NextPart_001_01CD17F2.97BDC556-- From bob.hinden@gmail.com Wed Apr 11 09:09: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 8D2A521F854A for ; Wed, 11 Apr 2012 09:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_41=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 bpblwsaIDBWW for ; Wed, 11 Apr 2012 09:09:42 -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 B82B121F8549 for ; Wed, 11 Apr 2012 09:09:42 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1415592pbb.31 for ; Wed, 11 Apr 2012 09:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a/vbFttYbeokcnFWfqhw6p69EFN0TIxR/qxMnzXmrKs=; b=OLTXI1KZBVNQNU8VsSJaIls4RiHdn4nIZh1dG5ic88awlFoMxTiIEuy0f7qtN+fgYF Gwr/+pdzMZ38ReKhKdYLVPO51iFaU+zc4TLJN8EWauJr6j85YfT7zRlw+97yhjeA4Pu7 jCJRat2fyHBD3B+HXs6U1a4nPD/p5ZPjpLJlvODUP+zfWLRDjQp0PPGMj6lkdxJr7Ip8 ZTnRJAigk3Dxxy5IEGFduNH34ryndw1EmlqOjN3EjxEaf6pxcqFhGUnZKbATPWQI4Ceq C7fHUrcd8kA/tnZ6HbOXhv09uLMA7PxS2cNRRU7//zCsIhEcH4aCT5R9GONPxmTxFE2n k6Mw== Received: by 10.68.73.138 with SMTP id l10mr39186398pbv.22.1334160582346; Wed, 11 Apr 2012 09:09:42 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id qb10sm3222586pbb.75.2012.04.11.09.09.41 (version=SSLv3 cipher=OTHER); Wed, 11 Apr 2012 09:09:41 -0700 (PDT) Subject: Re: Why one Internet? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Wed, 11 Apr 2012 09:09:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DAC3250-61B5-43D0-8943-01EA00B45720@gmail.com> References: <4F8481B1.2000101@gmail.com> To: Pars Mutaf X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org Mailing List" , Bob Hinden , Brian Haberman , Mohacsi Janos 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, 11 Apr 2012 16:09:43 -0000 Pars, OK, last warning (w/ Area director copied). If we see any further posts = on this (or similar out of scope topics on this list) from you, we will = remove your ability to send email to this mailing list. We also request others to stop responding to this thread. Bob On Apr 11, 2012, at 1:05 AM, Pars Mutaf wrote: >=20 >=20 > On Wed, Apr 11, 2012 at 10:53 AM, Mohacsi Janos = wrote: >=20 >=20 >=20 > On Wed, 11 Apr 2012, Pars Mutaf wrote: >=20 >=20 >=20 > On Tue, Apr 10, 2012 at 10:12 PM, Manfredi, Albert E = wrote: >=20 > Yes, that was also my reaction. Why one Internet? Because = Internet means tying together multiple separate networks. Of course you = can have the same > addresses on the different networks. Nothing new there either. = That?s why we have NATs, NAPTs, and IPv6 NPTs. >=20 >=20 > =20 >=20 > No one is forcing an ISP or an enterprise network to use a = combination of protocols. They can already opt to be IPv4 only, or IPv6 = only, or dual > stack, or eventually IPv7. Matter of fact, years ago, our = enterprise had an assortment of different networks, tied together by = Softswitch gateways. > IPv4, SNA, DECnet. >=20 > =20 >=20 >=20 > I have no problem with anyone. I am facing my own illusions.=20 >=20 > Here is my conclusion after years of work on IPv6.=20 >=20 > IPv6 guy is just a salesman.=20 >=20 > But the salesman thought the entire world should buy his product.=20 >=20 > Not, but a reasonable technology for go forward with. >=20 >=20 > The product cannot change. >=20 > Wrong, See evolution of IPv6 in the past 10 years - lot has been = changed - due to better understanding of requirements and drawback of = certain solutions. >=20 >=20 >=20 > There is no other product.=20 >=20 > Yes there are, but ipv6 seems to be most reasonable at the moment. >=20 >=20 >=20 > Not even sure the product was really needed.=20 >=20 > See ipng work in the late 90's - it was requirement driven. >=20 >=20 > Complete delusion.=20 >=20 >=20 > Please describe your conception in details - we can compare solutions = based on technical merits. >=20 > Sorry I don't see the problem yet. I wouldn't design a solution nor = discuss its details.=20 >=20 > Designing the future makes me suffer.=20 >=20 > Pars >=20 > =20 > Best Regards, > Janos Mohacsi >=20 >=20 >=20 > Pars >=20 > =20 >=20 > Bert >=20 > =20 >=20 > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf Of Carlos Martinez-Cagnazzo > Sent: Tuesday, April 10, 2012 2:54 PM > To: Pars Mutaf > Cc: ipv6@ietf.org > Subject: Re: Why one Internet? >=20 > =20 >=20 > Wasn't this what the Internet was supposed to be? I'm tempted to ask = how old you are, but I don't want to be rude. >=20 > As the Monty Python would put it: 'You see, the key is in the name - = Inter - net(work)' >=20 > :-) >=20 > cheers >=20 > Carlos >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dthaler@microsoft.com Wed Apr 11 12:18: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 3A65D21F850F for ; Wed, 11 Apr 2012 12:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.636 X-Spam-Level: X-Spam-Status: No, score=-103.636 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 0KxG51I1s4R5 for ; Wed, 11 Apr 2012 12:18:02 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0E35E21F84F4 for ; Wed, 11 Apr 2012 12:18:01 -0700 (PDT) Received: from mail13-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 19:17:54 +0000 Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id 7FA3620296; Wed, 11 Apr 2012 19:17:54 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail13-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 1334171872988970_18704; Wed, 11 Apr 2012 19:17:52 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.250]) by mail13-am1.bigfish.com (Postfix) with ESMTP id EBB2310004F; Wed, 11 Apr 2012 19:17:52 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 19:17:50 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 11 Apr 2012 19:17:24 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Wed, 11 Apr 2012 12:17:23 -0700 From: Dave Thaler To: Ray Hunter Subject: RE: RE: 3484bis and privacy addresses Thread-Topic: RE: 3484bis and privacy addresses Thread-Index: AQHNC+wBSVlewb1jE0uYOWOUBxq41JZ/ZbAAgBPdqECAAOdQAIAAkKBAgAF2ZAD//+UuwA== Date: Wed, 11 Apr 2012 19:17:23 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B50CBC2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F83D8D0.5030402@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F858C32.6060709@globis.net> In-Reply-To: <4F858C32.6060709@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] 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: Wed, 11 Apr 2012 19:18:03 -0000 > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Wednesday, April 11, 2012 6:51 AM > To: Dave Thaler > Cc: Brian E Carpenter; ipv6@ietf.org > Subject: Re: RE: 3484bis and privacy addresses >=20 > With all due respect to everyone concerned, there's no way an end user or= IT > department can buy a bunch of machines based on the text currently contai= ned > in this proposed Standard Track document and >=20 > 1) be able to predict how each machine will behave by defaultin advance o= f > actually plugging it in. >=20 > 2) be able to effectively manage a machine's behaviour remotely via an IE= TF > defined control mechanism, because the various MAYs and SHOULDs cannot be > overridden by the two things that are actually reasonably well defined by= the > IETF i.e. > the prefix policy table + draft-ietf-6man-addr-select-opt-03 for transpor= ting that > policy table. I don't follow. Can you provide a specific example of something you are co= ncerned about? >=20 > That suggests to me that we're not yet completely on the right track. >=20 > IMHO If there's an implementation option in 3484bis, there should always = be a > corresponding control option in the (prefix) policy table, plus a way to > effectively transport that policy table in e.g. > draft-ietf-6man-addr-select-opt-03. No, the prefix policy table is for configuring a specific subset of rules (= the ones using labels and preference). Configurability for other rules isn't part o= f the "prefix policy table", but is still configurable.=20 -Dave >=20 > Align and package all 3 together, and you have a far better solution. >=20 > regards, > RayH >=20 > Dave Thaler wrote: > > Brian Carpenter writes: > >>> > > The wording I propose to add is: > >>> > > > >>> > > "There SHOULD be an administrative option to change this > preference, if the > >>> > > implementation supports privacy addresses. If there is no= such > option, there > >>> > > MUST be an administrative option to disable privacy addres= ses." > >>> > > > >>> > > -Dave > >> > > >> > That works for me. Perhaps there also needs to be a general > >> > statement in the security considerations that all administrative ch= anges > and options MUST be secured against illicit use. > > > > Done. Draft-02 now includes the wording above, and adds a general > statement in the > > security considerations section as you suggested. > > > > -Dave >=20 From bob.hinden@gmail.com Thu Apr 12 13: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 0F3E321F866D for ; Thu, 12 Apr 2012 13:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Se9HzdyljBul for ; Thu, 12 Apr 2012 13:57:26 -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 9428A21F865C for ; Thu, 12 Apr 2012 13:57:26 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so908237pbb.31 for ; Thu, 12 Apr 2012 13:57:26 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=RjljsdjMsPB+czM2pnkdau+4rM0QcZkd/5kO0P0TdmM=; b=WdIuVWu+omh/duGXKB5ECboCD9EmGjT38W1xCMBvxjb6LMvblQ3nD9NoNAFBjkII5A kgHg2OHBSBou3Disgc5DygX7jAtJlbT/w6S9tCPQZSCwU5Fmcos2SfmbBWWJtx1o60by NJ+UfOGtIpRYJM4/6O34KLgrspj5DXBdeEEUiMZE8av0aAN0Jv2/zGLEw8kqFrFMZOML MjpuyjODu6foOQqFSaoQgRIm7QeE54OlIhH6tACObqRs0iatBWo7pdjKGObiYUfOo2tV 9OGuU1Z1Cz0/yRkLNqpHKJeBu4xuMz0GzupF5F/s2nuunNaEkjgCTn8ddBPynE3s3nUU TthQ== Received: by 10.68.237.198 with SMTP id ve6mr5512257pbc.125.1334264246336; Thu, 12 Apr 2012 13:57:26 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id f7sm6636578pbr.3.2012.04.12.13.57.23 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 13:57:24 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN Minutes, Actions, and Document Status Date: Thu, 12 Apr 2012 13:57:21 -0700 Message-Id: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 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: Thu, 12 Apr 2012 20:57:27 -0000 The minutes are available at: http://www.ietf.org/proceedings/83/minutes/minutes-83-6man.txt At the end of the 6MAN session at the Paris IETF the chairs believe the = following actions are forthcoming:=20 Ready for Working Group Last Call: draft-ietf-6man-rfc3484bis draft-ietf-6man-lineid draft-ietf-6man-dad-proxy draft-ietf-6man-udpchecksum draft-ietf-6man-udpzero draft-ietf-6man-ipv6-atomic-fragments =09 Ready for Working Group call for adoption as a w.g. document draft-gont-6man-stable-privacy-addresses draft-gont-6man-nd-extension-headers Given the number of actions, we think it would be inappropriate to send = them all at once. We plan to send them out in small batches. Once we = see the discussion slow down, we will start the next batch. This should = strike a reasonable balance at getting them done, not overwhelming the = working group, and giving each document a reasonable review. Other w.g. documents that are not ready for any actions are listed = below. Please let us know if we missed anything. Bob and Ole --------------- draft-ietf-6man-addr-select-considerations On hold; pending 3484bis draft-ietf-6man-addr-select-opt On hold; pending 3484bis draft-ietf-6man-rfc3484-revise On hold; pending 3484bis draft-ietf-6man-uri-zoneid Passed WGLC (2012-03-19). draft-ietf-6man-6lobac On hold; pending other SDO work draft-ietf-6man-impatient-nud Awaiting new revision draft-ietf-6man-enhanced-dad Recently published as w.g. draft From bob.hinden@gmail.com Thu Apr 12 14:28: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 063CC21F86FD for ; Thu, 12 Apr 2012 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 joQy6KQy2GUc for ; Thu, 12 Apr 2012 14:28:25 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8604921F8549 for ; Thu, 12 Apr 2012 14:28:25 -0700 (PDT) Received: by dady13 with SMTP id y13so4193832dad.27 for ; Thu, 12 Apr 2012 14:28:25 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=VbQTpB9fRrwXyJ1dVy3uBDOkZxc1GkARYJ/3KqE0MZ0=; b=xPKTK6oPPVOAC5xFeHlkPH+UUoqSsZ3reSdrywAqePOgvNrZFgfq8CwKmug3vIPyrX euhFtK2RCUhg+eSiKnS1I1xwgFWa8Ay0wLlIlHdnwnOPNgh0cSiUJyBaBtwSx54NE6oj Wi/Z64WU8uCh+5hI4P9e7dHmGTXvjH24bvfcDdCeIjElWgHa4Lyixx5zhRblPIix1+jn OspiEBMfw2aSyx6W2mqzvN5DT5biESYsIQ0Iw15iBxn7XfR4I+6bTTKxE7leqGcIFpcz AE58523CN4YIVuKvZUZJzTSHu22mgk0C/4yxeXTmtW/8odwb8pvfdqQQG7QGDnxGRgug XYvw== Received: by 10.68.240.42 with SMTP id vx10mr381819pbc.21.1334266105305; Thu, 12 Apr 2012 14:28:25 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id l1sm6691458pbs.34.2012.04.12.14.28.24 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 14:28:24 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Thu, 12 Apr 2012 14:28:23 -0700 Message-Id: To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 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: Thu, 12 Apr 2012 21:28:27 -0000 All, This message starts a two week 6MAN Working Group on advancing: 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-02.txt Pages : 30 Date : 2012-04-11 http://tools.ietf.org/html/draft-ietf-6man-rfc3484bis-02 as Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on April 26, 2012. Regards, Ole Troan & Bob Hinden From bob.hinden@gmail.com Thu Apr 12 14:28: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 04BEF21F8766 for ; Thu, 12 Apr 2012 14:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.537 X-Spam-Level: X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 0OgRRlqX23J6 for ; Thu, 12 Apr 2012 14:28:27 -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 866F921F8762 for ; Thu, 12 Apr 2012 14:28:27 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so932041pbb.31 for ; Thu, 12 Apr 2012 14:28:27 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=f/NY5qCOti8l05POASutpKapDjXCN4YIEfkrXI52Eyk=; b=RV/3qdX1JS40EpQShqBHPW5U9ikVxDcoT67xdvBd43FvxpVazbw3u0BwSis3MibLWz SfwOxinbyKZgHFoHJWXMnC0kFbLFnX+7JZIaGIoklAUroVLAfUqX997ujeUUDv9bwCgf B1iw8Q8sFR4aGTgd9gEkLFEqSVryU/RA4GMCwZb5/5wIEspcwaWh5gArDC0+jysUoO+l fSxwHS5dN3A8se/dNEZ7zFtu28USIhXT7D+1UVG6qbb78nLTCBYhEDxDrW0qoF/vqxtm fcGnINBovJg1241RmKS15XlPE3O1CUwy70pdaCNrofQvK/fdmO4DVpFHzJtjisYGhbuq 5vjg== Received: by 10.68.234.167 with SMTP id uf7mr133684pbc.138.1334266107323; Thu, 12 Apr 2012 14:28:27 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id l1sm6691458pbs.34.2012.04.12.14.28.26 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 14:28:26 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 6MAN WG Last Call: Date: Thu, 12 Apr 2012 14:28:26 -0700 Message-Id: <19742BF3-DA9B-4DEC-9D48-6C41B6CC73A8@gmail.com> To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 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: Thu, 12 Apr 2012 21:28:28 -0000 All, This message starts a one week 6MAN Working Group on advancing: 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 http://tools.ietf.org/html/draft-ietf-6man-lineid-04 as an Experimental RFC. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on April 19, 2012. Regards, Bob Hinden & Ole Troan From bob.hinden@gmail.com Thu Apr 12 14:28: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 766A021F8789 for ; Thu, 12 Apr 2012 14:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 uga0z7FRo-L6 for ; Thu, 12 Apr 2012 14:28:34 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id DB3EB21F878E for ; Thu, 12 Apr 2012 14:28:33 -0700 (PDT) Received: by mail-pz0-f54.google.com with SMTP id y13so4193832dad.27 for ; Thu, 12 Apr 2012 14:28:33 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=AZmGbVNwSMEMc0r+wogX95xENmbaoVf50vE2r6UUrK0=; b=fUGNlacX25BQOBQ4xWhU7S7kVwDBb9v7FbGP9OZdxf6FeLOaKQ9jLJQZLi9Q9dVg7t MOuopZCgWbN2vwk0NSMx1tRDLkb2VOh/YbZHbcNg2fGPs60ok9EIHJgFLP2JorxmXzSa 95n3zVtkGJU+3hSGgmQoOpEmXlnaHyTtIzdFUHfW49FBO7oWyrWieomyxBedesvKB2Zf uFByFcZYbg9RSDtH1o7j+eiOichFHuEEy9+8aGvJwP7s4ORqKiGQ/RzRRU6Gl/PdEt9d U06LtfpY2gwknIIsB3kHlmQLC9KBRT5CskQ/NrQJpw/3JDDBQt1LJjk6c9Ied/husp5F 1pVg== Received: by 10.68.132.41 with SMTP id or9mr422349pbb.8.1334266113806; Thu, 12 Apr 2012 14:28:33 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id l1sm6691458pbs.34.2012.04.12.14.28.32 (version=SSLv3 cipher=OTHER); Thu, 12 Apr 2012 14:28:33 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Consensus call on adopting: Date: Thu, 12 Apr 2012 14:28:32 -0700 Message-Id: To: IPv6 WG Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 6man Chairs <6man-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: Thu, 12 Apr 2012 21:28:34 -0000 All, This is a consensus call on adopting: Title : A method for Generating Stable Privacy-Enhanced = Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-gont-6man-stable-privacy-addresses-01 Pages : 15 Date : 2012-12-31 = http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses-01 as a 6MAN working group document. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on April 26, 2012. Regards, Ole Troan & Bob Hinden= From albert.e.manfredi@boeing.com Thu Apr 12 15:05: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 2B12121F875D for ; Thu, 12 Apr 2012 15:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=-1.900, 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 XyEOC0MLy0AY for ; Thu, 12 Apr 2012 15:05:17 -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 AE52C21F8758 for ; Thu, 12 Apr 2012 15:05:17 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q3CM58l9024708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Apr 2012 15:05:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q3CM5Orf008309; Thu, 12 Apr 2012 17:05:33 -0500 (CDT) Received: from XCH-MWHT-02.mw.nos.boeing.com (xch-mwht-02.mw.nos.boeing.com [134.57.113.20]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q3CM5DCE008083 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 Apr 2012 17:05:14 -0500 (CDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-02.mw.nos.boeing.com ([134.57.113.20]) with mapi; Thu, 12 Apr 2012 17:04:40 -0500 From: "Manfredi, Albert E" To: Bob Hinden , IPv6 WG Mailing List Date: Thu, 12 Apr 2012 17:04:39 -0500 Subject: RE: Consensus call on adopting: Thread-Topic: Consensus call on adopting: Thread-Index: Ac0Y81j5HXjJ3QinSoayM6ZkOiZFCQAA5eXQ 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6man Chairs <6man-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: Thu, 12 Apr 2012 22:05:18 -0000 Maybe I missed it in the I-D, but this mechanism appears most useful for mo= bile devices, which roam among different networks. The stable Interface ID = is only stable as long as the portable device stays connected to one access= point, which presumably would not be very long. With that in mind, I'd be in favor of pursuing this. Bert -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob= Hinden Sent: Thursday, April 12, 2012 5:29 PM To: IPv6 WG Mailing List Cc: 6man Chairs Subject: Consensus call on adopting: All, This is a consensus call on adopting: Title : A method for Generating Stable Privacy-Enhanced Addresses w= ith IPv6 Stateless Address Autoconfiguration (SLAAC) Author(s) : Fernando Gont Filename : draft-gont-6man-stable-privacy-addresses-01 Pages : 15 Date : 2012-12-31 http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses-01 as a 6MAN working group document. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on April 26, 2012. Regards, Ole Troan & Bob Hinden -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From kauer@biplane.com.au Thu Apr 12 17:14: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 17EDF21F8638 for ; Thu, 12 Apr 2012 17:14:35 -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 vQ0ijK04LW1D for ; Thu, 12 Apr 2012 17:14:34 -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 05BC721F85D1 for ; Thu, 12 Apr 2012 17:14:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACJvh0+WZX+7/2dsb2JhbAANNoVytyYBAQEEI0sbCxgqAgJXGbQCiw6QO4EYBKEoh3M Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.205]) ([150.101.127.187]) by ipmail06.adl6.internode.on.net with ESMTP; 13 Apr 2012 09:44:30 +0930 Subject: Re: Consensus call on adopting: From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-9r76ynRjHdTUHGcSdXz4" Date: Fri, 13 Apr 2012 10:14:28 +1000 Message-ID: <1334276068.3945.408.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, 13 Apr 2012 00:14:35 -0000 --=-9r76ynRjHdTUHGcSdXz4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-04-12 at 14:28 -0700, Bob Hinden wrote: > This is a consensus call on adopting: >=20 > Title : A method for Generating Stable Privacy-Enhanced Addresses= with > IPv6 Stateless Address Autoconfiguration (SLAAC) > Author(s) : Fernando Gont > Filename : draft-gont-6man-stable-privacy-addresses-01 > Pages : 15 > Date : 2012-12-31 > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. Positive. That said, I have some comments. My apologies if I have missed some discussion where these were covered already: 1: I'm unsure about this bit: IPv6 implementations conforming to this specification MUST generate interface identifiers using the algorithm specified in this section. While this does not explicitly *say* that other interface identifiers MUST NOT be used, that interpretation seems to be possible. A hint that stable addresses may be used alongside privacy addresses, is found in the sentence: On the other hand, in scenarios in which "Privacy Extensions" are employed, implementation of the mechanism described in this document would [...] Section five does mention replacing IEEE-based interface IDs, but I think it needs to be stronger, one way or the other. The document should make clear which other mechanisms it excludes, if any - for example, that a host using this mechanism SHOULD NOT (MUST NOT?) also generate interface IDs based on IEEE identifiers but MAY also use privacy extensions. See also point 4 below. 2: What exactly is a "serial number"? Do all machines, even small/embedded etc machines, have a serial number? Seems to me that the algorithm should use a default value, such as zero, for the "serial number" if none is available OR should fail to generate a secret key (and thus fail to generate interface IDs later). My preference would be for the first of these - i.e., a default. 3: Related to the previous point, if it is possible to fail to generate a secret key, there needs to be a defined value for "secret key" that indicates an invalid secret key - perhaps zero. If the secret key has this value, the host MUST NOT autoconfigure a stable address. 4: Assuming point 1 above has relevance, and a host using this algorithm MUST NOT also use IEEE-based interface IDs, then a host which fails to generate a stable address for any reason MUST NOT fall back to the use of IEEE-based interface IDs. Why? Because that would expose the host to precisely the disadvantages that the stable addresses were supposed to prevent. 5: Duplicate address detection is not mentioned explicitly, but probably should be - what happens if a host does DAD and determines that its stable address is already in use? 6: The interface IDs generated are 64 bits long. I think it should be stated explicitly that this algorithm MUST NOT be used where the prefix is not 64 bits long. 7: Add "An implementation SHOULD provide the means for the user to enable and disable the use of stable addresses." =20 8: This may be a bit out of scope, but it occurs to me that being able to specify a static interface identifier and have it used in any (64-bit) prefix would also be useful in some contexts. That is, have an address which is stable, but explicitly specified. =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 --=-9r76ynRjHdTUHGcSdXz4 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) iF4EABEIAAYFAk+Hb94ACgkQFpl7eE7uYBe5sQD+PIfKZWAdLptCijj86hEerpG9 4iYOSV517s+A5vyJu/cBAK+noeZhInSqQjqYzJ9nRerF2vhkyCHvhr9Td95PmtC4 =aNui -----END PGP SIGNATURE----- --=-9r76ynRjHdTUHGcSdXz4-- From brian.e.carpenter@gmail.com Fri Apr 13 00:14: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 3B46E21F86B4 for ; Fri, 13 Apr 2012 00:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.661 X-Spam-Level: X-Spam-Status: No, score=-101.661 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 JX3+1C3m3unD for ; Fri, 13 Apr 2012 00:14:16 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8243121F86B0 for ; Fri, 13 Apr 2012 00:14:16 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1858736wgb.13 for ; Fri, 13 Apr 2012 00:14:15 -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=ZzfbM/p5G0ifFc9VeLisTTqRFiF+rabV2TN9r8Uxju4=; b=aIiYN6v/DL5i7fgYBt5fiimA5gOEwZoPc1vvTjDqpLs9+NhIZTGtnClRhj1+3rSm1v DDc4CQkMzOWK9oPm1yeWinULh7cHMGsrKE4I2/S71X5aEChbuqep5uFM+d5o+/FnRUpU OvZBPdPGwgW4rg8yiknDqlp2ViJBDYI+ukkpzOD6op5cTU69KUNFrFpUy5B9BjB13RWe DZjYKq+rRbKPoGR+CsMT5LdI3VO25BrdYyMwi9FNHzjIeaP0v9YheN/Gk6iWMaU9QS4F TnTdGp4Khtswm8qK0fu7Ayf/0xeN1sX9Ujav82GEmAGjTPCiP3yAMbk2rs30JR+9Hsc4 YXug== Received: by 10.180.102.100 with SMTP id fn4mr2106411wib.1.1334301255737; Fri, 13 Apr 2012 00:14:15 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-219-159.as13285.net. [2.102.219.159]) by mx.google.com with ESMTPS id ca3sm2771729wib.6.2012.04.13.00.14.14 (version=SSLv3 cipher=OTHER); Fri, 13 Apr 2012 00:14:15 -0700 (PDT) Message-ID: <4F87D245.4000102@gmail.com> Date: Fri, 13 Apr 2012 08:14:13 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bob Hinden Subject: Re: Consensus call on adopting: References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List 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, 13 Apr 2012 07:14:17 -0000 On 2012-04-12 22:28, Bob Hinden wrote: > All, > > This is a consensus call on adopting: > > Title : A method for Generating Stable Privacy-Enhanced Addresses with > IPv6 Stateless Address Autoconfiguration (SLAAC) > Author(s) : Fernando Gont > Filename : draft-gont-6man-stable-privacy-addresses-01 > Pages : 15 > Date : 2012-12-31 > > http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses-01 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus call > will end on April 26, 2012. Yes to adoption. Karl Auer's points all need discussion, and I think we also need to consider the impact on 3484bis. Brian From v6ops@globis.net Fri Apr 13 00:25: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 A138C21F8615 for ; Fri, 13 Apr 2012 00:25:44 -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 08bI-iqW6eVh for ; Fri, 13 Apr 2012 00:25:43 -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 F299021F8608 for ; Fri, 13 Apr 2012 00:25:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 77C848700CD; Fri, 13 Apr 2012 09:25:40 +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 ME23fj+JCnu9; Fri, 13 Apr 2012 09:25:32 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 7BD5D870047; Fri, 13 Apr 2012 09:25:32 +0200 (CEST) Message-ID: <4F87D4EA.4040801@globis.net> Date: Fri, 13 Apr 2012 09:25:30 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Dave Thaler Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F83D8D0.5030402@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F858C32.6060709@globis.net> <9B57C850BB53634CACEC56EF4853FF653B50CBC2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B50CBC2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.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, 13 Apr 2012 07:25:44 -0000 inline IMVHO [long answer] > Dave Thaler > 11 April 2012 21:17 >> -----Original Message----- >> From: Ray Hunter [mailto:v6ops@globis.net] >> Sent: Wednesday, April 11, 2012 6:51 AM >> To: Dave Thaler >> Cc: Brian E Carpenter; ipv6@ietf.org >> Subject: Re: RE: 3484bis and privacy addresses >> >> With all due respect to everyone concerned, there's no way an end user or IT >> department can buy a bunch of machines based on the text currently contained >> in this proposed Standard Track document and >> >> 1) be able to predict how each machine will behave by defaultin advance of >> actually plugging it in. >> >> 2) be able to effectively manage a machine's behaviour remotely via an IETF >> defined control mechanism, because the various MAYs and SHOULDs cannot be >> overridden by the two things that are actually reasonably well defined by the >> IETF i.e. >> the prefix policy table + draft-ietf-6man-addr-select-opt-03 for transporting that >> policy table. > > I don't follow. Can you provide a specific example of something you are concerned > about? Yes. The new text: If SA is a temporary address and SB is a public address, then prefer SA. Similarly, if SB is a temporary address and SA is a public address, then prefer SB. Sessions originated from a server on today's implementations e.g. Windows server OS currently do NOT use temporary addresses to source sessions. RFC3484 does NOT prefer temporary addresses as default behaviour today. The current text does not make a distinction between a server and a client node, and says a machine should always prefer temporary addresses. If an implementor follows the current text, this would change default behaviour of some current implementations e.g. Windows Server. That will almost certainly break stuff in production when new software versions are introduced. Example: firewall access between a management server and a bunch of machines it manages in a data centre environment. Example: DSCP bit setting based on ACL in MPLS environments. Example: PCI credit card processing standards (Fixed IP address or static DHCP must be used for computers involved in credit card processing) Example: helpdesk procedures for correlating long term problems via logs Implementations for which application compatibility considerations outweigh these privacy concerns MAY reverse the sense of this rule and by default prefer public addresses over temporary addresses. Ah: but now there is a MAY which effectively allows the implementor to do anything they like if the implementor doesn't think Rule 7 is appropriate. Now imagine that I (as an end user) buy a machine of brand X that complies 100% with the RFC3484bis Standards Track document (or update an existing operating system version that implemented RFC3484 but now implements RFC3484bis). Does the new version use temporary addresses by default? No idea. That was left up to the individual implementor. Does the new version exhibit the same default behaviour as the previous version based on RFC3484? No idea. Does the implementor have any idea what my or my employer's view is on privacy addresses (either default ON or default OFF)? Nope. Does the implementor have any idea what my or my employer's operational requirements are? e.g. ACLs? Nope. Is there a very good chance of taking the incorrect setting as default (in either direction)? Yes. Is there a switch to reverse behaviour: either to turn it on when it should be off or off when it should be on? Sure, but the end user or system manager has to dig around in Brand X's proprietary mechanism to figure out how to change it. In mobile environments, they may not even have direct management access. Can the system manager change this setting remotely for machines that hop between networks e.g. a laptop that moves between work and home and various company networks? Undefined. >> That suggests to me that we're not yet completely on the right track. >> >> IMHO If there's an implementation option in 3484bis, there should always be a >> corresponding control option in the (prefix) policy table, plus a way to >> effectively transport that policy table in e.g. >> draft-ietf-6man-addr-select-opt-03. > > No, the prefix policy table is for configuring a specific subset of rules (the ones > using labels and preference). Configurability for other rules isn't part of > the "prefix policy table", but is still configurable. > > -Dave Yes. That's exactly my problem. As you say, the prefix policy table can only control a specific subset of the end node's behaviour. The current text effectively gives complete freedom for implementors to do what they like on Rule 7: either Default ON or default OFF. So why have Rule 7 at all? The current text also only provides a subset of that freedom to system managers and end users (the policy table does not effect rule 7). Especially for influencing the setting by remote configuration e.g. from a trusted DHCPv6 server. The prefix policy table could be updated by DHCPv6 via draft-ietf-6man-addr-select-opt-03, but the behaviour of rule 7 can't be. Meanwhile the implementor has zero idea of what policies an end user or system manager has to comply with, nor an end user's other production requirements (including compliance laws, firewalls, ACLs, help desk processes, or log processing). Why should implementors have more freedom to decide on what is appropriate behaviour for address selection than the machine's system manager or end user? On the flip side, why even bother with the prefix policy table if an end user or system manager still cannot make the machine behave according to their local operational requirements? All I'm saying is that if you define a switch in a standard that an implementor can throw, give that same switch to the end user/system manager, and make sure the switch setting can also be transported over a commonly implemented non-proprietary management mechanism like DHCPv6. The end user can still decide whether he or she trusts the DHCPv6 server or the content of the DHCPv6 option as a local management preference. >> Align and package all 3 together, and you have a far better solution. >> >> regards, >> RayH >> >> Dave Thaler wrote: >>> Brian Carpenter writes: >>>>>> > The wording I propose to add is: >>>>>> > >>>>>> > "There SHOULD be an administrative option to change this >> preference, if the >>>>>> > implementation supports privacy addresses. If there is no such >> option, there >>>>>> > MUST be an administrative option to disable privacy addresses." >>>>>> > >>>>>> > -Dave >>>>> That works for me. Perhaps there also needs to be a general >>>>> statement in the security considerations that all administrative changes >> and options MUST be secured against illicit use. >>> Done. Draft-02 now includes the wording above, and adds a general >> statement in the >>> security considerations section as you suggested. >>> >>> -Dave > > > Ray Hunter > 11 April 2012 15:50 > With all due respect to everyone concerned, there's no way an end user > or IT department can buy a bunch of machines based on the text > currently contained in this proposed Standard Track document and > > 1) be able to predict how each machine will behave by defaultin > advance of actually plugging it in. > > 2) be able to effectively manage a machine's behaviour remotely via an > IETF defined control mechanism, because the various MAYs and SHOULDs > cannot be overridden by the two things that are actually reasonably > well defined by the IETF i.e. > the prefix policy table + draft-ietf-6man-addr-select-opt-03 for > transporting that policy table. > > That suggests to me that we're not yet completely on the right track. > > IMHO If there's an implementation option in 3484bis, there should > always be a corresponding control option in the (prefix) policy table, > plus a way to effectively transport that policy table in e.g. > draft-ietf-6man-addr-select-opt-03. > > Align and package all 3 together, and you have a far better solution. > > regards, > RayH > > > > ------------------------------------------------------------------------ From lear@cisco.com Fri Apr 13 01:09: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 E8C7A21F8744 for ; Fri, 13 Apr 2012 01:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.045, 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 bj1Zm4djysrg for ; Fri, 13 Apr 2012 01:09: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 036AD21F873A for ; Fri, 13 Apr 2012 01:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=371; q=dns/txt; s=iport; t=1334304586; x=1335514186; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gc4kq6IRp+Kz2njmDOrKfLBgPiMqGhse9nZFCV7kig4=; b=Ms/p88UmZ6olygRhbZz6UpQdNGwN/2TxteP6QgU034dl+Ianjb9WU9Qe Xf7syC0qpZY6QYx3Dcsr5y8GprJJNYlBDXQOhmcT/s8Vx81biAT6oevuU BrsfAlMMHLNdvdERsBEd63k0TgD3dORhMmHtzsarsY7ASjIVXa6oCPYjG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL3eh0+Q/khM/2dsb2JhbABFhWa0C4EHggoBAQQSARBVARALGgIFFgsCAgkDAgECAUUGDQEHAQEeh2yaBI0QkmyBL48QgRgElWyOTYFpgmk X-IronPort-AV: E=Sophos;i="4.75,415,1330905600"; d="scan'208";a="135035182" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 08:09:45 +0000 Received: from elear-mac.local (dhcp-10-55-82-252.cisco.com [10.55.82.252]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3D89iJN025124; Fri, 13 Apr 2012 08:09:44 GMT Message-ID: <4F87DF53.7030009@cisco.com> Date: Fri, 13 Apr 2012 10:09:55 +0200 From: Eliot Lear 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: Bob Hinden Subject: Re: Consensus call on adopting: References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List 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, 13 Apr 2012 08:09:47 -0000 A question for the draft author: At one point you write that the intent is to replace EUI-64-based addresses (Section 5). But that doesn't seem to jibe with what you write in the intro about RFC-4941. I am concerned that adopting this mechanism will make matters worse if this mechanism is being used as an alternative to CGAs, as opposed to EUI-64s.. Eliot From tjc@ecs.soton.ac.uk Fri Apr 13 03:37: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 6B59721F8627 for ; Fri, 13 Apr 2012 03:37:50 -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 kMXFBnaJyikQ for ; Fri, 13 Apr 2012 03:37:49 -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 7400C21F8624 for ; Fri, 13 Apr 2012 03:37:49 -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 q3DAbjws022172; Fri, 13 Apr 2012 11:37:45 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q3DAbjws022172 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1334313465; bh=AEZZPIixvFyd5T/fMBOfnxl0Qw8=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=uANqzG1FJkqvMA3VKUGZ+tRG6Zju3OH0cZXJm5amUAJfkXboYwgIBRTLQBCvLtQGy b+fzHKlTYn5DKgo2TSwyWvQG5+KDqdP9Il+DCqANz5/ajyMgZ+Dw2reFUeOIHRgIHj J8cKkMC5cXaecPeAKZf+Kh/cs34F+LL10ovGox0A= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o3CBbj0543760396p0 ret-id none; Fri, 13 Apr 2012 11:37:45 +0100 Received: from ip-205-201.eduroam.soton.ac.uk (ip-205-201.eduroam.soton.ac.uk [152.78.205.201]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q3DAbdrZ019129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2012 11:37:39 +0100 Subject: Re: Consensus call on adopting: Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Chown In-Reply-To: <4F87D245.4000102@gmail.com> Date: Fri, 13 Apr 2012 11:37:39 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4F87D245.4000102@gmail.com> <95F65935-A316-4CFB-9A79-9B0AB7E33A10@ecs.soton.ac.uk> To: IPv6 WG Mailing List X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o3CBbj054376039600; tid=o3CBbj0543760396p0; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q3DAbjws022172 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: 6man Chairs <6man-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: Fri, 13 Apr 2012 10:37:50 -0000 On 13 Apr 2012, at 08:14, Brian E Carpenter wrote: > On 2012-04-12 22:28, Bob Hinden wrote: >> All, >>=20 >> This is a consensus call on adopting: >>=20 >> Title : A method for Generating Stable Privacy-Enhanced = Addresses with >> IPv6 Stateless Address Autoconfiguration (SLAAC) >> Author(s) : Fernando Gont >> Filename : draft-gont-6man-stable-privacy-addresses-01 >> Pages : 15 >> Date : 2012-12-31 >>=20 >> = http://tools.ietf.org/html/draft-gont-6man-stable-privacy-addresses-01 >>=20 >> as a 6MAN working group document. Please state your opinion, = positive >> or negative, on the mailing list or to the chairs. This consensus = call >> will end on April 26, 2012. >=20 > Yes to adoption. Karl Auer's points all need discussion, and I think > we also need to consider the impact on 3484bis. Yes, let's adopt. Personally I think a different name for these types of addresses would = be more appropriate, to avoid confusion with RFC4941 Privacy Extensions. = If I understand it correctly, essentially what you are defining is = randomised stable-per-prefix public interface identifiers, but that's = not a catchy term :) On 3484bis, if stable privacy addresses are alternative public (not = temporary) identifiers for hosts then is there anything more to say? = What impact are you considering Brian, other than would exist if two = other public addresses existed on an interface? Note that RFC4941 temporary addresses can also be stable, in that they = do not change if the host stays on the same network; the specification = only says identifiers SHOULD be regenerated at some defined interval. =20= Finally, it would be interesting to know what algorithm Windows uses to = generate its identifiers; they are randomised, public and stable. I had = thought they were based on the prefix, but Fernando's tests suggest not.=20= Tim= From fgont@si6networks.com Fri Apr 13 14:09: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 1A55311E8101 for ; Fri, 13 Apr 2012 14:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 x5vo1qgm6+Bj for ; Fri, 13 Apr 2012 14:09:14 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 877F211E8100 for ; Fri, 13 Apr 2012 14:09:13 -0700 (PDT) Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SInjz-0006QV-Ca; Fri, 13 Apr 2012 23:09:11 +0200 Message-ID: <4F87BBD6.8090809@si6networks.com> Date: Fri, 13 Apr 2012 07:38:30 +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: Bob Hinden Subject: Re: 6MAN Minutes, Actions, and Document Status References: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> In-Reply-To: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org Mailing List" 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, 13 Apr 2012 21:09:15 -0000 Hi, Bob, Some comments inline... On 04/12/2012 10:57 PM, Bob Hinden wrote: > The minutes are available at: > > http://www.ietf.org/proceedings/83/minutes/minutes-83-6man.txt Some errata for the minutes: The current text says: ---- cut here ---- Ole asked about how this was different from an unknown L4 header? ---- cut here ---- There was an answer, so "" should probably be replaced with something along the lines of "Fernando notes that having an unknown extension header means that you have enough information to apply a filtering policy, whereas if the full IPv6 header chain is missing, you don't have the necessary information to do it". > Ready for Working Group call for adoption as a w.g. document > > draft-gont-6man-stable-privacy-addresses > > draft-gont-6man-nd-extension-headers I think that draft-gont-6man-predictable-fragment-id is also ready for wg call for adoption as wg document -- I've rev'ed the document since IETF 83 in response to the feedback received during my presentation (i.e., just require the Frag ID to be unpredictable, without mandating any particular algorithm). draft-gont-6man-oversized-header-chain is probably ready for wg call for adoption: I've rev the document in response to feedback during my presentation at IETF 83 -- but I will check with Dave Thaler and Eric if they think the updated text is fine, or whether it needs some further tweaking. 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 fgont@si6networks.com Fri Apr 13 14:09: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 19FBA11E80E4 for ; Fri, 13 Apr 2012 14:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 Z0XrSryHfZ39 for ; Fri, 13 Apr 2012 14:09:38 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6AE11E80FF for ; Fri, 13 Apr 2012 14:09:38 -0700 (PDT) Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SInkG-0006Qe-03; Fri, 13 Apr 2012 23:09:29 +0200 Message-ID: <4F881C9A.3050908@si6networks.com> Date: Fri, 13 Apr 2012 14:31:22 +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: Eliot Lear Subject: Re: Consensus call on adopting: References: <4F87DF53.7030009@cisco.com> In-Reply-To: <4F87DF53.7030009@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , 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, 13 Apr 2012 21:09:39 -0000 hI, Eliot, On 04/13/2012 10:09 AM, Eliot Lear wrote: > At one point you write that the intent is to replace EUI-64-based > addresses (Section 5). Exactly. > But that doesn't seem to jibe with what you > write in the intro about RFC-4941. Could you please cite the "conflicting" text? > I am concerned that adopting this > mechanism will make matters worse if this mechanism is being used as an > alternative to CGAs, as opposed to EUI-64s.. I don't follow. Could you clarify your concern? 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 fgont@si6networks.com Fri Apr 13 14:10: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 C4FAB11E810B for ; Fri, 13 Apr 2012 14:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 kjZUmLXg+iG4 for ; Fri, 13 Apr 2012 14:10:25 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0A98411E810A for ; Fri, 13 Apr 2012 14:10:23 -0700 (PDT) Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SInku-0006Rh-06; Fri, 13 Apr 2012 23:10:08 +0200 Message-ID: <4F882A44.3080305@si6networks.com> Date: Fri, 13 Apr 2012 15:29:40 +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: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....) References: <1334276068.3945.408.camel@karl> In-Reply-To: <1334276068.3945.408.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: Fri, 13 Apr 2012 21:10:25 -0000 Hi, Karl, Thanks so much for your feedback! Please find my comments inline... ["Subject" changed so that this discussion doesn't mix up with the poll] On 04/13/2012 02:14 AM, Karl Auer wrote: > That said, I have some comments. My apologies if I have missed some > discussion where these were covered already: > > 1: I'm unsure about this bit: > > IPv6 implementations conforming to this specification > MUST generate interface identifiers using the algorithm > specified in this section. > > While this does not explicitly *say* that other interface identifiers > MUST NOT be used, that interpretation seems to be possible. Good point. Maybe we could replace that para with: "IPv6 implementations conforming to this specification MUST generate interface identifiers using the algorithm specified in this section in replacement of Modified EUI-64 format identifiers." ? > A hint that > stable addresses may be used alongside privacy addresses, is found in > the sentence: > > On the other hand, in scenarios in which "Privacy Extensions" > are employed, implementation of the mechanism described in this > document would [...] > > Section five does mention replacing IEEE-based interface IDs, but I > think it needs to be stronger, one way or the other. The document should > make clear which other mechanisms it excludes, if any - for example, > that a host using this mechanism SHOULD NOT (MUST NOT?) also generate > interface IDs based on IEEE identifiers but MAY also use privacy > extensions. See also point 4 below. Please let me know if the suggested change (above) is okay, or whether you think it would be better to include an additional note with something along the lines of "That is, they MUST NOT employ Modified EUI-64 format identifiers, but MAY still implement RFC 4941 in addition to the algorithm specified in this document". > 2: What exactly is a "serial number"? Some number that varies from one machine to another, which is not expected to be known by an attacker. > Do all machines, even > small/embedded etc machines, have a serial number? Now that you mention it, I think I should tweak the corresponding text, making inclusion of such serial number a "MAY". > Seems to me that the > algorithm should use a default value, such as zero, for the "serial > number" if none is available OR should fail to generate a secret key > (and thus fail to generate interface IDs later). My preference would be > for the first of these - i.e., a default. Agreed. Either that, or simply not include the serial number if it's not available. > 3: Related to the previous point, if it is possible to fail to generate > a secret key, It shouldn't be possible. The idea is that the secret key is set to a random number (by default). > 4: Assuming point 1 above has relevance, and a host using this algorithm > MUST NOT also use IEEE-based interface IDs, then a host which fails to > generate a stable address for any reason MUST NOT fall back to the use > of IEEE-based interface IDs. Why? Because that would expose the host to > precisely the disadvantages that the stable addresses were supposed to > prevent. Agreed. But this would be implied when we say "... MUST use this algorithm in replacement of Modified EUI-64 format identifiers"? > 5: Duplicate address detection is not mentioned explicitly, but probably > should be - what happens if a host does DAD and determines that its > stable address is already in use? Address configuration fails. Note: I didn't discuss DAD because to some extent *what* you do is not discussed in the traditional-SLAAC specs. That said, if deemed appropriate, one could include one additional byte, "DAD" in the hash function, which is initialized to 0, and that is incremented by 1 if the host wants to try a different address if/when DAD fails. If we do that, the implementations should probably cache the resulting address, such that it is stable. (otherwise the resulting address might change if the same node was brought up while the node with the conflicting address is off). > 6: The interface IDs generated are 64 bits long. I think it should be > stated explicitly that this algorithm MUST NOT be used where the prefix > is not 64 bits long. Actually, this algorithm could still be used with longer prefixes (i.e., fewer bits for the IID). So I'm not sure whether we should include this requirement. e.g., if we were to eventually allow non-/64 autoconfigured addresses, this algorithm could be use without any changes (while the traditional MAC-based identifiers couldn't). (Note: Just me thinking out loud). > 7: Add "An implementation SHOULD provide the means for the user to > enable and disable the use of stable addresses." May be s/stable addresses/this specification/? That said, I think we should probably note what nodes are supposed to be done with this specification as a whole. Me, I'd argue that "nodes SHOULD employ generate IIDs with this algorithm in replacement of Modified-EUI 64 format identifiers" -- since we clearly want to move away from MAC-based IIDs. (Note that this is a different issue from item #1 above: Item #1 above is about what you should do if you implement this spec, while the point that I'm making in the previous paragraph is that you SHOULD implement this spec). Thoughts? > 8: This may be a bit out of scope, but it occurs to me that being able > to specify a static interface identifier and have it used in any > (64-bit) prefix would also be useful in some contexts. That is, have an > address which is stable, but explicitly specified. The problem is that as soon as you use a static identifier, you can be tracked. -- Yes, you may argue that if your identifiers is "::1", then it's very likely that many other systems will be using the same identifier, and hence it would not be of much help to an attacker for tracking purposes.... but I'd say that's walking a fine line. Additionally, I'd argue that in order to have such thing, then 1) You'd need to manually configure your address each time you move from one network to another (as with manual configuration requires you to set the whole address, rather than just the IID bits), or, 2) You should be using e.g. Windows algorithm for generating the IIDs, which is sub-optimal, since they mitigate only host-scanning attacks and not host-stacking attacks. That said, I wonder what the use might be. e.g., would the user be expected to remember all the bits from the IID, and then say "ok, the prefix we're using on this net is [blah..blah], so the resulting IPv6 address of the host with known IID is blah-blah"? -- If that's the expected use case, then I'd argue that you should be doing mDNS, LLNR, or DNS dynamic updates.... 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 fgont@si6networks.com Fri Apr 13 14:10: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 7982211E810E for ; Fri, 13 Apr 2012 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 7Pr7dzRHOZ4f for ; Fri, 13 Apr 2012 14:10:37 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BC8CD11E810F for ; Fri, 13 Apr 2012 14:10:36 -0700 (PDT) Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SInkj-0006RB-I2; Fri, 13 Apr 2012 23:10:05 +0200 Message-ID: <4F881FFF.5030409@si6networks.com> Date: Fri, 13 Apr 2012 14:45:51 +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: Tim Chown Subject: Re: Consensus call on adopting: References: <4F87D245.4000102@gmail.com> <95F65935-A316-4CFB-9A79-9B0AB7E33A10@ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List 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, 13 Apr 2012 21:10:37 -0000 Hi, Tim, Thanks so much for your feedback! Please find my comments inline... On 04/13/2012 12:37 PM, Tim Chown wrote: > Extensions. If I understand it correctly, essentially what you are > defining is randomised stable-per-prefix public interface > identifiers, Exactly. > On 3484bis, if stable privacy addresses are alternative public (not > temporary) identifiers for hosts then is there anything more to say? Not that I can think of. > Note that RFC4941 temporary addresses can also be stable, in that > they do not change if the host stays on the same network; the > specification only says identifiers SHOULD be regenerated at some > defined interval. Two things: * If you do RFC 4941 but do not change the addresses over time (e.g. as Windows does for their stable addresses), then you can be tracked exactly in the same way as with MAC-based addresses. Such addreseses mitigate only host-scanning attacks (i.e., they are unpredictable), but since there's a constant identifier used across networks, tracking is still possible. -- So at the time you implement RFC 4941 without regenerating the addresses over time, they are not *privacy* extensions anymore :-) * IMO, it is a bit of a strech to say "RFC4941 temporary addresses can also be stable", implying that stability is allowed. That would be the case if "identifiers MAY be generated at some defined interval". But if it's a SHOULD, and you go against it, you're not fully-compliant with the specification. ("SHOULD" just means that there are specific cases in which you're allowed to not follow the recommendation). > Finally, it would be interesting to know what algorithm Windows uses > to generate its identifiers; they are randomised, public and stable. > I had thought they were based on the prefix, but Fernando's tests > suggest not. Dave Thaler commented on this one during the 6man wg meeting at IETF 83: They do RFC4941, without changing the addresses over time. Hence, the identifiers are constant across networks. This means that they mitigate host scanning attacks, but as noted in draft-gont-6man-stable-privacy-addresses-01 they are still subject to host-tracking. 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 dthaler@microsoft.com Fri Apr 13 14:57: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 E788111E8149 for ; Fri, 13 Apr 2012 14:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.749 X-Spam-Level: X-Spam-Status: No, score=-103.749 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 GjLQjXF8SmCy for ; Fri, 13 Apr 2012 14:57:29 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6F45D11E80C4 for ; Fri, 13 Apr 2012 14:57:28 -0700 (PDT) Received: from mail52-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; Fri, 13 Apr 2012 21:57:27 +0000 Received: from mail52-db3 (localhost [127.0.0.1]) by mail52-db3-R.bigfish.com (Postfix) with ESMTP id 7F56160096; Fri, 13 Apr 2012 21:57:27 +0000 (UTC) X-SpamScore: -6 X-BigFish: VS-6(zz1432Nzz1202hzzz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail52-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=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail52-db3 (localhost.localdomain [127.0.0.1]) by mail52-db3 (MessageSwitch) id 133435424737978_7081; Fri, 13 Apr 2012 21:57:27 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.233]) by mail52-db3.bigfish.com (Postfix) with ESMTP id 04F3D400B6; Fri, 13 Apr 2012 21:57:27 +0000 (UTC) Received: from TK5EX14HUBC105.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; Fri, 13 Apr 2012 21:57:26 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 13 Apr 2012 21:57:23 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Fri, 13 Apr 2012 14:57:23 -0700 From: Dave Thaler To: Ray Hunter Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNGUajDaqZ7/kESEaVgy0zYPsEC5aZSPWQ Date: Fri, 13 Apr 2012 21:57:23 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B513879@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F83D8D0.5030402@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F858C32.6060709@globis.net> <9B57C850BB53634CACEC56EF4853FF653B50CBC2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F87D4EA.4040801@globis.net> In-Reply-To: <4F87D4EA.4040801@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.28] 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: Fri, 13 Apr 2012 21:57:30 -0000 Hi Ray, I appreciate the detailed response. Thanks. > If SA is a temporary address and SB is a public address, then prefer > SA. Similarly, if SB is a temporary address and SA is a public > address, then prefer SB. >=20 > Sessions originated from a server on today's implementations e.g. > Windows server OS currently do NOT use temporary addresses to source > sessions. Windows Server absolutely prefers temporary addresses to source sessions, whenever temporary addresses are enabled. Generation of temporary address= es (which isn't related to RFC 3484) is not enabled by default, but the RFC 34= 84=20 implementation in Windows Server definitely prefers temporary addresses over public addresses. > RFC3484 does NOT prefer temporary addresses as default behaviour today. >=20 > The current text does not make a distinction between a server and a clien= t > node, and says a machine should always prefer temporary addresses. Correct. We don't have WG consensus on making such a distinction. And Windows doesn't either (it only makes a distinction on whether RFC 3041 is enabled or disabled, where it's enabled by default on client OSs and disabled by default on server OS's). > If an implementor follows the current text, this would change default > behaviour of some current implementations e.g. Windows Server. As the person responsible for that implementation, I can assure you that's not the case. > Implementations for which application compatibility > considerations outweigh these privacy concerns MAY reverse the sense > of this rule and by default prefer public addresses over temporary > addresses. >=20 > Ah: but now there is a MAY which effectively allows the implementor to do > anything they like if the implementor doesn't think Rule 7 is appropriate= . You cannot do "anything you like". You're limited to two behaviors: (a) Prefer public, and (b) Prefer temporary. Both are legal and an impleme= ntation can do either one. That was already the case with RFC 3484, nothing new here except which one is the MAY vs the SHOULD. > Now imagine that I (as an end user) buy a machine of brand X that complie= s > 100% with the RFC3484bis Standards Track document (or update an existing > operating system version that implemented RFC3484 but now implements > RFC3484bis). >=20 > Does the new version use temporary addresses by default? No idea. That wa= s > left up to the individual implementor. Already true with RFC 3484. Left up to the individual implementer. If you want to know, then you want to configure it to use (possibly non-def= ault) values.=20 > Does the new version exhibit the same default behaviour as the previous > version based on RFC3484? No idea. Already true with RFC 3484. If you upgrade an OS, it may or may not choose a different set of RFC 3484-compliant options. If you want to know, then you want to configure it to use (possibly non-def= ault) values. > Does the implementor have any idea what my or my employer's view is on > privacy addresses (either default ON or default OFF)? Nope. Actually the implementor often does due to proprietary mechaniams (like Group Policy or manual configuration or whatever else), but=20 neither RFC 3484 nor 3484bis specifies configuration mechanisms, that's the job of companion docs like the DHCP option doc. The core doc can't mandate a specific mechanism, but needs to work independent of what specific mechanism is being used to configure policy. > Does the implementor have any idea what my or my employer's operational > requirements are? e.g. ACLs? Nope. > Is there a very good chance of taking the incorrect setting as default (i= n either > direction)? Yes. >=20 > Is there a switch to reverse behaviour: either to turn it on when it shou= ld be > off or off when it should be on? > Sure, but the end user or system manager has to dig around in Brand X's > proprietary mechanism to figure out how to change it. > In mobile environments, they may not even have direct management access. Your points here are not about RFC 3484bis per se, they're about a configur= ation mechanism being standardized. That's being done in parallel. [...] > > No, the prefix policy table is for configuring a specific subset of > > rules (the ones using labels and preference). Configurability for > > other rules isn't part of the "prefix policy table", but is still confi= gurable. >=20 > Yes. That's exactly my problem. As you say, the prefix policy table can o= nly > control a specific subset of the end node's behaviour. >=20 > The current text effectively gives complete freedom for implementors to d= o > what they like on Rule 7: either Default ON or default OFF. >=20 > So why have Rule 7 at all? Same reason for the other rules. a) there's only two options that are understood enough to reason about: basically prefer privacy, and prefer stability. Having a rule shows t= he precedence order among such rules in terms of when the difference matters. And we have consensus on that. b) they're implemented and deployed already, so we want to minimize changes from RFC 3484. > The current text also only provides a subset of that freedom to system > managers and end users (the policy table does not effect rule 7). The current text provides freedom to reverse the sense of the rule. The policy table isn't needed for that, the two are both configurable. > Especially for influencing the setting by remote configuration e.g. from = a > trusted DHCPv6 server. The prefix policy table could be updated by > DHCPv6 via draft-ietf-6man-addr-select-opt-03, but the behaviour of rule > 7 can't be. Again your comments seem to be about failings with the current draft-ietf-6man-addr-select-opt document, not about RFC 3484bis. I would agree with you here that draft-ietf-6man-addr-select-opt is not ready for WGLC until it addresses more than just the prefix policy tabl= e. But that need not hold up RFC 3484bis itself, which just defines the knobs and leaves it for other docs to define a protocol to set the knobs via DHCPv6, SNMP, netconf, CLI, and/or whatever else. > >> Align and package all 3 together, and you have a far better solution. I disagree that we need to hold publication of RFC3484bis for any other protocol documents. We need normative references in the reverse=20 direction, not from RFC3484bis to any protocol document. The WG wants to get RFC3484bis out asap because it actually fixes problems that were in RFC 3484. -Dave From kauer@biplane.com.au Fri Apr 13 17:36: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 79FD921F85EF for ; Fri, 13 Apr 2012 17:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-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 D36J9Mh8SHVF for ; Fri, 13 Apr 2012 17:36:28 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id D1EAC21F85B6 for ; Fri, 13 Apr 2012 17:36:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJTFiE+WZX+7/2dsb2JhbAANNoVyskgBAQEDASNbCwsYIwcCAlcZiAmrfYsEizyEdYEYBKEoh3OBQw Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.205]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Apr 2012 10:06:17 +0930 Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....) From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F882A44.3080305@si6networks.com> References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UFrs9Pr0hBxJzsweaDai" Date: Sat, 14 Apr 2012 10:36:14 +1000 Message-ID: <1334363774.3945.541.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, 14 Apr 2012 00:36:29 -0000 --=-UFrs9Pr0hBxJzsweaDai Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote: > "IPv6 implementations conforming to this specification MUST generate > interface identifiers using the algorithm specified in this section in > replacement of Modified EUI-64 format identifiers." > ? While that is good, it would be clearer if it was expanded out to make the desired points separately: It is intended that the use of Modified-IEEE interface identifiers be replaced wherever possible by the use of interface identifiers generated as described in this specification. When generating interface identifiers, IPv6 implementations conforming to this specification MUST use the algorithm specified in this section. [I'm not sure this is necessary - it seems to be saying that "conforming implementations have to conform"] IPv6 implementations conforming to this specification MUST NOT use Modified-IEEE format interface identifiers [see 4291 Appendix A] for any purpose EXCEPT THAT link local addresses MAY be generated using Modified-IEEE format interface identifiers. [remove everything from EXCEPT THAT onwards if that isn't what you intended] If for any reason the generation of an interface identifier according to this specification fails, IPv6 implementations conforming to this specification MUST NOT fall back to using Modified-IEEE format interface identifiers. Interface identifiers other than Modified-IEEE interface identifiers MAY be used in addition to interface identifiers generated according to this specification. > It shouldn't be possible. The idea is that the secret key is set to a > random number (by default). I still think you need a special value for "invalid secret key", so that any systems do not have any way to obtain random numbers can refuse to autoconfigure if the key is not set. > > 5: Duplicate address detection is not mentioned explicitly, but probabl= y > > should be - what happens if a host does DAD and determines that its > > stable address is already in use? >=20 > Address configuration fails. That should be in the spec. > That said, if deemed appropriate, one could include one additional byte, > "DAD" in the hash function, which is initialized to 0, and that is > incremented by 1 if the host wants to try a different address if/when > DAD fails. >=20 > If we do that, the implementations should probably cache the resulting > address, such that it is stable. (otherwise the resulting address might > change if the same node was brought up while the node with the > conflicting address is off). This may not be possible on systems with no onboard storage, and makes things much more complicated. I suggest that if DAD fails, then autoconfiguration should just fail (at least as regards stable addresses). > Actually, this algorithm could still be used with longer prefixes (i.e., > fewer bits for the IID). So I'm not sure whether we should include this > requirement. e.g., if we were to eventually allow non-/64 autoconfigured > addresses, this algorithm could be use without any changes (while the > traditional MAC-based identifiers couldn't). I like the 64-bit limitation. Either way it should be made explicit. > > 7: Add "An implementation SHOULD provide the means for the user to > > enable and disable the use of stable addresses." >=20 > May be s/stable addresses/this specification/? Fine. > (Note that this is a different issue from item #1 above: Item #1 above > is about what you should do if you implement this spec, while the point > that I'm making in the previous paragraph is that you SHOULD implement > this spec). I don't think a spec can mandate it's own use unless it obsoletes or updates a spec that mandates something. Your spec would have to update 4291, for example, replacing the whole modified-IEEE thing with your mechanism. That's a BIG step. > Additionally, I'd argue that in order to have such thing, then > 1) You'd need to manually configure your address each time you move from > one network to another (as with manual configuration requires you to set > the whole address, rather than just the IID bits), or, No - you could just have a flag that says "the key is the interface identifier I want to use - verbatim". Then that IID gets appended to whatever prefix happens along. Obviously this does NOT have the same anti-tracking qualities etc, but I can see it being useful. It's basically a variation on static addresses that allows portability between networks without having to reconfigure the host. Just as with other forms of static addressing, it is absolutely the administrator's problem to avoid conflicts. 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 --=-UFrs9Pr0hBxJzsweaDai 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) iF4EABEIAAYFAk+IxngACgkQFpl7eE7uYBcQQAEAhfdqdCMLhGdzKZ/+oEuENVRQ dSjz7AwIV+i3uhSUvSIA/3QmagyUPAXSBIpp4blcZCvwzkFQaQ1CA5vJmvejCXSa =y9zv -----END PGP SIGNATURE----- --=-UFrs9Pr0hBxJzsweaDai-- From washam.fan@gmail.com Fri Apr 13 23: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 4311C21F8666 for ; Fri, 13 Apr 2012 23:25:03 -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 PzIOvQVfZLVv for ; Fri, 13 Apr 2012 23:25:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4072621F8664 for ; Fri, 13 Apr 2012 23:24:45 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2508236wgb.13 for ; Fri, 13 Apr 2012 23:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CMullx28O4fcUsZL3SRIAF7ORsRmUJ0TrAWRTysl87I=; b=h8/kBMXiCKSPct9TKvC4XI5LhJolfwYaH62Iw6Ypc2Zp7y0WS1Zzma5pBBDkHFZMls wSKylE79HxDGmH5JRJLuPIteC0lMG4s6nP1fdd1jIo2mBQdC58j1IjLzuDHR1+3wQbYL oxGqk9MS5VXDe18qOrC5l4ui6HosahfI/QG1t6HMEFFExBTqYyenW4mq10nwQIMI/Jl9 W6F3UuT/SMrOlyozAJzDH3gdjw2Mspt5Hnt+urkWhtqKIvahSrMMECS7VvTVAgTwVhHD AsydP2liWyXl9M0fi6nYKMX40Ncrt7kr1GTVscemSYEANylwfsE9ojYE2WEBosdEal7H K+Ng== MIME-Version: 1.0 Received: by 10.180.102.129 with SMTP id fo1mr2116123wib.6.1334384684300; Fri, 13 Apr 2012 23:24:44 -0700 (PDT) Received: by 10.216.191.41 with HTTP; Fri, 13 Apr 2012 23:24:44 -0700 (PDT) In-Reply-To: <1334363774.3945.541.camel@karl> References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> Date: Sat, 14 Apr 2012 14:24:44 +0800 Message-ID: Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....) From: Washam Fan To: Karl Auer 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: Sat, 14 Apr 2012 06:25:03 -0000 Hi, >> > 5: Duplicate address detection is not mentioned explicitly, but probably >> > should be - what happens if a host does DAD and determines that its >> > stable address is already in use? >> >> Address configuration fails. > > That should be in the spec. > >> That said, if deemed appropriate, one could include one additional byte, >> "DAD" in the hash function, which is initialized to 0, and that is >> incremented by 1 if the host wants to try a different address if/when >> DAD fails. >> >> If we do that, the implementations should probably cache the resulting >> address, such that it is stable. (otherwise the resulting address might >> change if the same node was brought up while the node with the >> conflicting address is off). > > This may not be possible on systems with no onboard storage, and makes > things much more complicated. +1. And the storage or filesystem could have been damaged. > I suggest that if DAD fails, then > autoconfiguration should just fail (at least as regards stable > addresses). > So what is the next step if the autoconfiguration fails? static configure? If yes. Will the next reboot try autoconfiguration again? If yes, you may have non-stable addresses within the same network. If no, when you move to another network you should explicitly revoke the static configuration and enable autoconfiguration again. I think the author should clarify this DAD failure issue in the next version. THanks, washam From kauer@biplane.com.au Fri Apr 13 23: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 EC29321F86EA for ; Fri, 13 Apr 2012 23:48:47 -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 YpcmB-y5yRH6 for ; Fri, 13 Apr 2012 23:48:47 -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 C692C21F86CF for ; Fri, 13 Apr 2012 23:48:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJociU+WZX+7/2dsb2JhbAANOIVmsjMBAQEDASNbCwsYIwcCAlcZiAmmNpJbjiWCDIEYBKEoh3OBQhU Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.205]) ([150.101.127.187]) by ipmail04.adl6.internode.on.net with ESMTP; 14 Apr 2012 16:18:44 +0930 Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....) From: Karl Auer To: ipv6@ietf.org In-Reply-To: References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-krzFednaOPkJO+gh9I6g" Date: Sat, 14 Apr 2012 16:48:40 +1000 Message-ID: <1334386120.3945.607.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, 14 Apr 2012 06:48:48 -0000 --=-krzFednaOPkJO+gh9I6g Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-04-14 at 14:24 +0800, Washam Fan wrote: > So what is the next step if the autoconfiguration fails? static > configure? If yes. Will the next reboot try autoconfiguration again? > If yes, you may have non-stable addresses within the same network. If > no, when you move to another network you should explicitly revoke the > static configuration and enable autoconfiguration again. If autoconfiguration fails, then it fails. There is no automated fallback; the host stays address-less (or at least stable-address-less :-) until the situation is resolved by external action. How the conflict should be resolved is out of the scope of the draft. > I think the author should clarify this DAD failure issue in the next > version. Yes in any case. But I don't think it has to be more complicated than "if Duplicate Address Detection (DAD) detects an address conflict, the host MUST NOT use the address." Maybe also add "A host MAY continue to attempt DAD in the hope that the address conflict is resolved; in this case additional DAD attempts should be infrequent." The latter allows an unattended host to recover without assistance. 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 --=-krzFednaOPkJO+gh9I6g 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) iF4EABEIAAYFAk+JHcIACgkQFpl7eE7uYBczYAEAjotAsjbgzSlh52vOP6YtLb0n KWR34t5cEzR7T2kNkpoA/0vQMHvnkNY7kCTLbNARjB2K4jxwBk47IkQ7ZJ5zoBmJ =TT8x -----END PGP SIGNATURE----- --=-krzFednaOPkJO+gh9I6g-- From v6ops@globis.net Sat Apr 14 01:31: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 A981C21F85D4 for ; Sat, 14 Apr 2012 01:31:14 -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 rP6hgzYSQ1aU for ; Sat, 14 Apr 2012 01:31:13 -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 EF04A21F85D0 for ; Sat, 14 Apr 2012 01:31:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 59CDF8700D7; Sat, 14 Apr 2012 10:31:10 +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 1IDd0YeRtxcr; Sat, 14 Apr 2012 10:31:04 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id BA4B18700B3; Sat, 14 Apr 2012 10:31:04 +0200 (CEST) Message-ID: <4F8935C7.6020602@globis.net> Date: Sat, 14 Apr 2012 10:31:03 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Dave Thaler Subject: Re: 3484bis and privacy addresses References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F83D8D0.5030402@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F858C32.6060709@globis.net> <9B57C850BB53634CACEC56EF4853FF653B50CBC2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F87D4EA.4040801@globis.net> <9B57C850BB53634CACEC56EF4853FF653B513879@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B513879@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.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: Sat, 14 Apr 2012 08:31:14 -0000 Thanks for the reply. I understand the rush, but I don't think the current document is ready for production yet, and would expect a need for RFC3484ter, which should obviously be avoided if possible. I have already seen at least two customers who have experienced fairly major incidents and service outages due to the behaviour of end nodes and servers changing between OS versions. I use Windows as an example as you know the code, but it could have been any OS to be fair. Moving from Windows XP + Windows Server 2003 to Windows 7 + Windows Server 2008 and leaving default values in place can trigger massive changes in traffic flows literally within minutes via use of 6to4 tunnels (e.g. when the server end is upgraded to the new OS), and which directly breaks MPLS DSCP Quality of Service settings, or firewall throughput. I've seen customer's mission-critical platinum applications suddenly get dumped in the default queue as the routers no longer set the DSCP bits on network ingress and so the downstream routers cannot act on the DSCP bits of the traffic in the tunnel, even if they can look inside the tunnel. And I've seen firewalls and other devices choke as they have a different switching path for IPv6 traffic, or worse still, it hits a 100% block rule. These incidents are very difficult to track, as the servers may be managed by completely different groups to the network, and it would not be obvious to most change and problem managers that the changes and problems were directly related. So I understand very well the urgency of lowering the preference of 6to4. I would submit that lowering the preference of 6to4 could actually be implemented much quicker in production by progressingdraft-ietf-6man-addr-select-opt-03 and allowing end users to configure their own machines, rather than waiting for implementors to ship new code based on 3484bis. As an end user, I therefore think draft-ietf-6man-addr-select-opt-03 is actually more urgent than RFC3484bis. But 6to4 is just the first example of where implementers will incorrectly second guess an end user's requirements. There'll certainly be more similar examples, including operational problems caused by use of temporary addresses. Forgive me if I read your reply wrongly, but you seem to point the blame for there being an incomplete solution for remote management squarely at draft-ietf-6man-addr-select-opt-03. Yet I could equally point out that RFC3484/RFC3484bis defines the prefix policy table, and all draft-ietf-6man-addr-select-opt-03 does is transport the contents of the prefix policy table via DHCPv6. So what would I like to see happen? =========================== What about defining a conceptual "address selection policy table" in RFC3484bis in addition to the "prefix policy table"? It would contain a complete list of the conceptual knobs and switches that influence the behaviour of RFC3484bis end nodes, conceptual variable names, conceptual variable type, what behaviour the variable sets (cross referenced to the section), default settings (where these are already agreed in the WG) etc. Then draft-ietf-6man-addr-select-opt-03 would simply define how to transport those options over DHCPv6, rather than having to define the options themselves. Equally, if an implementor wanted to set these options via a config file, or AD group policy, or any other management process, they'd have a check list of things to do as well. And if there are ever future extensions to RFC3484bis (e.g. a new rule to introduce dollar cost of network links or QoS factors into the address selection process), any new switches or new default behaviour could also be added to this conceptual "address selection policy table". If we'd already done this in RFC3484 it would have probably avoided a lot of pain with divergent implementations. To be clear: I don't necessarily see the need to define new knobs or switches right now: just to clarify what existing knobs or switches will conceptually be called, what their conceptual types are (e.g. boolean), how/when they're set, what behaviour they influence, and their default behaviour (if agreed), plus a hint of how to add new knobs and switches in the future. This conceptual approach has been used very successfully in ND (RFC4861) and other standards, and I think it would address my current concerns of there being too much hard coding in address selection. regards, RayH > Dave Thaler > 13 April 2012 23:57 > Hi Ray, > > I appreciate the detailed response. Thanks. > >> If SA is a temporary address and SB is a public address, then prefer >> SA. Similarly, if SB is a temporary address and SA is a public >> address, then prefer SB. >> >> Sessions originated from a server on today's implementations e.g. >> Windows server OS currently do NOT use temporary addresses to source >> sessions. > > Windows Server absolutely prefers temporary addresses to source sessions, > whenever temporary addresses are enabled. Generation of temporary addresses > (which isn't related to RFC 3484) is not enabled by default, but the RFC 3484 > implementation in Windows Server definitely prefers temporary addresses > over public addresses. > >> RFC3484 does NOT prefer temporary addresses as default behaviour today. >> >> The current text does not make a distinction between a server and a client >> node, and says a machine should always prefer temporary addresses. > > Correct. We don't have WG consensus on making such a distinction. > And Windows doesn't either (it only makes a distinction on whether > RFC 3041 is enabled or disabled, where it's enabled by default on client > OSs and disabled by default on server OS's). > >> If an implementor follows the current text, this would change default >> behaviour of some current implementations e.g. Windows Server. > > As the person responsible for that implementation, I can assure you > that's not the case. > >> Implementations for which application compatibility >> considerations outweigh these privacy concerns MAY reverse the sense >> of this rule and by default prefer public addresses over temporary >> addresses. >> >> Ah: but now there is a MAY which effectively allows the implementor to do >> anything they like if the implementor doesn't think Rule 7 is appropriate. > > You cannot do "anything you like". You're limited to two behaviors: > (a) Prefer public, and (b) Prefer temporary. Both are legal and an implementation > can do either one. That was already the case with RFC 3484, nothing new > here except which one is the MAY vs the SHOULD. > >> Now imagine that I (as an end user) buy a machine of brand X that complies >> 100% with the RFC3484bis Standards Track document (or update an existing >> operating system version that implemented RFC3484 but now implements >> RFC3484bis). >> >> Does the new version use temporary addresses by default? No idea. That was >> left up to the individual implementor. > > Already true with RFC 3484. Left up to the individual implementer. > > If you want to know, then you want to configure it to use (possibly non-default) > values. > >> Does the new version exhibit the same default behaviour as the previous >> version based on RFC3484? No idea. > > Already true with RFC 3484. If you upgrade an OS, it may or may not > choose a different set of RFC 3484-compliant options. > > If you want to know, then you want to configure it to use (possibly non-default) > values. > >> Does the implementor have any idea what my or my employer's view is on >> privacy addresses (either default ON or default OFF)? Nope. > > Actually the implementor often does due to proprietary mechaniams > (like Group Policy or manual configuration or whatever else), but > neither RFC 3484 nor 3484bis specifies configuration mechanisms, > that's the job of companion docs like the DHCP option doc. The core > doc can't mandate a specific mechanism, but needs to work independent > of what specific mechanism is being used to configure policy. > >> Does the implementor have any idea what my or my employer's operational >> requirements are? e.g. ACLs? Nope. >> Is there a very good chance of taking the incorrect setting as default (in either >> direction)? Yes. >> >> Is there a switch to reverse behaviour: either to turn it on when it should be >> off or off when it should be on? >> Sure, but the end user or system manager has to dig around in Brand X's >> proprietary mechanism to figure out how to change it. >> In mobile environments, they may not even have direct management access. > > Your points here are not about RFC 3484bis per se, they're about a configuration > mechanism being standardized. That's being done in parallel. > > [...] >>> No, the prefix policy table is for configuring a specific subset of >>> rules (the ones using labels and preference). Configurability for >>> other rules isn't part of the "prefix policy table", but is still configurable. >> Yes. That's exactly my problem. As you say, the prefix policy table can only >> control a specific subset of the end node's behaviour. >> >> The current text effectively gives complete freedom for implementors to do >> what they like on Rule 7: either Default ON or default OFF. >> >> So why have Rule 7 at all? > > Same reason for the other rules. > a) there's only two options that are understood enough to reason about: > basically prefer privacy, and prefer stability. Having a rule shows the > precedence order among such rules in terms of when the difference > matters. And we have consensus on that. > b) they're implemented and deployed already, so we want to minimize > changes from RFC 3484. > >> The current text also only provides a subset of that freedom to system >> managers and end users (the policy table does not effect rule 7). > > The current text provides freedom to reverse the sense of the rule. > The policy table isn't needed for that, the two are both configurable. > >> Especially for influencing the setting by remote configuration e.g. from a >> trusted DHCPv6 server. The prefix policy table could be updated by >> DHCPv6 via draft-ietf-6man-addr-select-opt-03, but the behaviour of rule >> 7 can't be. > > Again your comments seem to be about failings with the current > draft-ietf-6man-addr-select-opt document, not about RFC 3484bis. > I would agree with you here that draft-ietf-6man-addr-select-opt is > not ready for WGLC until it addresses more than just the prefix policy table. > But that need not hold up RFC 3484bis itself, which just defines the knobs > and leaves it for other docs to define a protocol to set the knobs via > DHCPv6, SNMP, netconf, CLI, and/or whatever else. > >>>> Align and package all 3 together, and you have a far better solution. > > I disagree that we need to hold publication of RFC3484bis for any other > protocol documents. We need normative references in the reverse > direction, not from RFC3484bis to any protocol document. > > The WG wants to get RFC3484bis out asap because it actually > fixes problems that were in RFC 3484. > > -Dave > > Ray Hunter > 13 April 2012 09:25 > inline IMVHO [long answer] >> Dave Thaler >> 11 April 2012 21:17 >>> -----Original Message----- >>> From: Ray Hunter [mailto:v6ops@globis.net] >>> Sent: Wednesday, April 11, 2012 6:51 AM >>> To: Dave Thaler >>> Cc: Brian E Carpenter; ipv6@ietf.org >>> Subject: Re: RE: 3484bis and privacy addresses >>> >>> With all due respect to everyone concerned, there's no way an end >>> user or IT >>> department can buy a bunch of machines based on the text currently >>> contained >>> in this proposed Standard Track document and >>> >>> 1) be able to predict how each machine will behave by defaultin >>> advance of >>> actually plugging it in. >>> >>> 2) be able to effectively manage a machine's behaviour remotely via >>> an IETF >>> defined control mechanism, because the various MAYs and SHOULDs >>> cannot be >>> overridden by the two things that are actually reasonably well >>> defined by the >>> IETF i.e. >>> the prefix policy table + draft-ietf-6man-addr-select-opt-03 for >>> transporting that >>> policy table. >> >> I don't follow. Can you provide a specific example of something you >> are concerned >> about? > Yes. > > The new text: > > If SA is a temporary address and SB is a public address, then prefer > SA. Similarly, if SB is a temporary address and SA is a public > address, then prefer SB. > > Sessions originated from a server on today's implementations e.g. > Windows server OS currently do NOT use temporary addresses to source > sessions. > RFC3484 does NOT prefer temporary addresses as default behaviour today. > > The current text does not make a distinction between a server and a > client node, and says a machine should always prefer temporary addresses. > > If an implementor follows the current text, this would change default > behaviour of some current implementations e.g. Windows Server. > > That will almost certainly break stuff in production when new software > versions are introduced. > > Example: firewall access between a management server and a bunch of > machines it manages in a data centre environment. > Example: DSCP bit setting based on ACL in MPLS environments. > Example: PCI credit card processing standards (Fixed IP address or > static DHCP must be used for computers involved in credit card > processing) > Example: helpdesk procedures for correlating long term problems via logs > > Implementations for which application compatibility > considerations outweigh these privacy concerns MAY reverse the sense > of this rule and by default prefer public addresses over temporary > addresses. > > Ah: but now there is a MAY which effectively allows the implementor to > do anything they like if the implementor doesn't think Rule 7 is > appropriate. > > Now imagine that I (as an end user) buy a machine of brand X that > complies 100% with the RFC3484bis Standards Track document (or update > an existing operating system version that implemented RFC3484 but now > implements RFC3484bis). > > Does the new version use temporary addresses by default? No idea. That > was left up to the individual implementor. > Does the new version exhibit the same default behaviour as the > previous version based on RFC3484? No idea. > Does the implementor have any idea what my or my employer's view is on > privacy addresses (either default ON or default OFF)? Nope. > Does the implementor have any idea what my or my employer's > operational requirements are? e.g. ACLs? Nope. > Is there a very good chance of taking the incorrect setting as default > (in either direction)? Yes. > > Is there a switch to reverse behaviour: either to turn it on when it > should be off or off when it should be on? > Sure, but the end user or system manager has to dig around in Brand > X's proprietary mechanism to figure out how to change it. > In mobile environments, they may not even have direct management access. > > Can the system manager change this setting remotely for machines that > hop between networks e.g. a laptop that moves between work and home > and various company networks? Undefined. > >>> That suggests to me that we're not yet completely on the right track. >>> >>> IMHO If there's an implementation option in 3484bis, there should >>> always be a >>> corresponding control option in the (prefix) policy table, plus a >>> way to >>> effectively transport that policy table in e.g. >>> draft-ietf-6man-addr-select-opt-03. >> >> No, the prefix policy table is for configuring a specific subset of >> rules (the ones >> using labels and preference). Configurability for other rules isn't >> part of >> the "prefix policy table", but is still configurable. >> >> -Dave > > Yes. That's exactly my problem. As you say, the prefix policy table > can only control a specific subset of the end node's behaviour. > > The current text effectively gives complete freedom for implementors > to do what they like on Rule 7: either Default ON or default OFF. > > So why have Rule 7 at all? > > The current text also only provides a subset of that freedom to system > managers and end users (the policy table does not effect rule 7). > Especially for influencing the setting by remote configuration e.g. > from a trusted DHCPv6 server. The prefix policy table could be updated > by DHCPv6 via draft-ietf-6man-addr-select-opt-03, but the behaviour of > rule 7 can't be. > > Meanwhile the implementor has zero idea of what policies an end user > or system manager has to comply with, nor an end user's other > production requirements (including compliance laws, firewalls, ACLs, > help desk processes, or log processing). > > Why should implementors have more freedom to decide on what is > appropriate behaviour for address selection than the machine's system > manager or end user? > > On the flip side, why even bother with the prefix policy table if an > end user or system manager still cannot make the machine behave > according to their local operational requirements? > > All I'm saying is that if you define a switch in a standard that an > implementor can throw, give that same switch to the end user/system > manager, and make sure the switch setting can also be transported over > a commonly implemented non-proprietary management mechanism like > DHCPv6. The end user can still decide whether he or she trusts the > DHCPv6 server or the content of the DHCPv6 option as a local > management preference. > > > > >>> Align and package all 3 together, and you have a far better solution. >>> >>> regards, >>> RayH >>> >>> Dave Thaler wrote: >>>> Brian Carpenter writes: >>>>>>> > The wording I propose to add is: >>>>>>> > >>>>>>> > "There SHOULD be an administrative option to change this >>> preference, if the >>>>>>> > implementation supports privacy addresses. If there is >>>>>>> no such >>> option, there >>>>>>> > MUST be an administrative option to disable privacy >>>>>>> addresses." >>>>>>> > >>>>>>> > -Dave >>>>>> That works for me. Perhaps there also needs to be a general >>>>>> statement in the security considerations that all administrative >>>>>> changes >>> and options MUST be secured against illicit use. >>>> Done. Draft-02 now includes the wording above, and adds a general >>> statement in the >>>> security considerations section as you suggested. >>>> >>>> -Dave >> >> >> Ray Hunter >> 11 April 2012 15:50 >> With all due respect to everyone concerned, there's no way an end >> user or IT department can buy a bunch of machines based on the text >> currently contained in this proposed Standard Track document and >> >> 1) be able to predict how each machine will behave by defaultin >> advance of actually plugging it in. >> >> 2) be able to effectively manage a machine's behaviour remotely via >> an IETF defined control mechanism, because the various MAYs and >> SHOULDs cannot be overridden by the two things that are actually >> reasonably well defined by the IETF i.e. >> the prefix policy table + draft-ietf-6man-addr-select-opt-03 for >> transporting that policy table. >> >> That suggests to me that we're not yet completely on the right track. >> >> IMHO If there's an implementation option in 3484bis, there should >> always be a corresponding control option in the (prefix) policy >> table, plus a way to effectively transport that policy table in e.g. >> draft-ietf-6man-addr-select-opt-03. >> >> Align and package all 3 together, and you have a far better solution. >> >> regards, >> RayH >> >> >> >> ------------------------------------------------------------------------ > > Dave Thaler > 11 April 2012 21:17 >> -----Original Message----- >> From: Ray Hunter [mailto:v6ops@globis.net] >> Sent: Wednesday, April 11, 2012 6:51 AM >> To: Dave Thaler >> Cc: Brian E Carpenter; ipv6@ietf.org >> Subject: Re: RE: 3484bis and privacy addresses >> >> With all due respect to everyone concerned, there's no way an end user or IT >> department can buy a bunch of machines based on the text currently contained >> in this proposed Standard Track document and >> >> 1) be able to predict how each machine will behave by defaultin advance of >> actually plugging it in. >> >> 2) be able to effectively manage a machine's behaviour remotely via an IETF >> defined control mechanism, because the various MAYs and SHOULDs cannot be >> overridden by the two things that are actually reasonably well defined by the >> IETF i.e. >> the prefix policy table + draft-ietf-6man-addr-select-opt-03 for transporting that >> policy table. > > I don't follow. Can you provide a specific example of something you are concerned > about? > >> That suggests to me that we're not yet completely on the right track. >> >> IMHO If there's an implementation option in 3484bis, there should always be a >> corresponding control option in the (prefix) policy table, plus a way to >> effectively transport that policy table in e.g. >> draft-ietf-6man-addr-select-opt-03. > > No, the prefix policy table is for configuring a specific subset of rules (the ones > using labels and preference). Configurability for other rules isn't part of > the "prefix policy table", but is still configurable. > > -Dave > >> Align and package all 3 together, and you have a far better solution. >> >> regards, >> RayH >> >> Dave Thaler wrote: >>> Brian Carpenter writes: >>>>>> > The wording I propose to add is: >>>>>> > >>>>>> > "There SHOULD be an administrative option to change this >> preference, if the >>>>>> > implementation supports privacy addresses. If there is no such >> option, there >>>>>> > MUST be an administrative option to disable privacy addresses." >>>>>> > >>>>>> > -Dave >>>>> That works for me. Perhaps there also needs to be a general >>>>> statement in the security considerations that all administrative changes >> and options MUST be secured against illicit use. >>> Done. Draft-02 now includes the wording above, and adds a general >> statement in the >>> security considerations section as you suggested. >>> >>> -Dave > > > Ray Hunter > 11 April 2012 15:50 > With all due respect to everyone concerned, there's no way an end user > or IT department can buy a bunch of machines based on the text > currently contained in this proposed Standard Track document and > > 1) be able to predict how each machine will behave by defaultin > advance of actually plugging it in. > > 2) be able to effectively manage a machine's behaviour remotely via an > IETF defined control mechanism, because the various MAYs and SHOULDs > cannot be overridden by the two things that are actually reasonably > well defined by the IETF i.e. > the prefix policy table + draft-ietf-6man-addr-select-opt-03 for > transporting that policy table. > > That suggests to me that we're not yet completely on the right track. > > IMHO If there's an implementation option in 3484bis, there should > always be a corresponding control option in the (prefix) policy table, > plus a way to effectively transport that policy table in e.g. > draft-ietf-6man-addr-select-opt-03. > > Align and package all 3 together, and you have a far better solution. > > regards, > RayH > > > > ------------------------------------------------------------------------ From tjc@ecs.soton.ac.uk Sat Apr 14 03:30:48 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 BED1621F858B for ; Sat, 14 Apr 2012 03:30:48 -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 iY8gc+k6oKYD for ; Sat, 14 Apr 2012 03:30:47 -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 6A3D621F8585 for ; Sat, 14 Apr 2012 03:30:46 -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 q3EAUcxd015229 for ; Sat, 14 Apr 2012 11:30:38 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q3EAUcxd015229 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1334399440; bh=u+b7zZN8Q6EXwR+dltCY7ARZo6o=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=MPs6IrCgg5YBvDW0OnOD+zp/WQVMLmxeAJDyLlCqUSfkajL4RYlnyCoIFdzIkJHet Fi88eZrQGhvv0CLZCFcZvvWa5sglaasRASYssU8CvSz5bt306WbNii/8LyZotCp0h1 gFu2TbTZCZCFPVVdLldm+L2mrlSailqduOEELKfQ= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o3DBUc0543702132l4 ret-id none; Sat, 14 Apr 2012 11:30:38 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q3EAUMIR000640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 14 Apr 2012 11:30:23 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....) From: Tim Chown In-Reply-To: <1334363774.3945.541.camel@karl> Date: Sat, 14 Apr 2012 11:30:23 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <9DDD54D3-5A69-499B-8496-119641348B1F@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=o3DBUc054370213200; tid=o3DBUc0543702132l4; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q3EAUcxd015229 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: Sat, 14 Apr 2012 10:30:48 -0000 On 14 Apr 2012, at 01:36, Karl Auer wrote: > On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote: >> Additionally, I'd argue that in order to have such thing, then >> 1) You'd need to manually configure your address each time you move = from >> one network to another (as with manual configuration requires you to = set >> the whole address, rather than just the IID bits), or, >=20 > No - you could just have a flag that says "the key is the interface > identifier I want to use - verbatim". Then that IID gets appended to > whatever prefix happens along. Obviously this does NOT have the same > anti-tracking qualities etc, but I can see it being useful. It's > basically a variation on static addresses that allows portability > between networks without having to reconfigure the host. Just as with > other forms of static addressing, it is absolutely the administrator's > problem to avoid conflicts. I while ago I put this one forward, which is an alternative to = Fernando's suggestion that you have to set the whole address: = http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-00 This was based on existing implementations, in Solaris and Linux (as a = demonstrator), with the potential for simpler renumbering in mind. It's = probably the complete antithesis of what Fernando is trying to achieve, = but is aimed at the type of (server) systems that would probably be = DNS-advertised anyway.=20 Tim= From fgont@si6networks.com Sat Apr 14 05:05: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 D7CF421F8625 for ; Sat, 14 Apr 2012 05:05:30 -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 77PzBYDhg3My for ; Sat, 14 Apr 2012 05:05:30 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id D20F821F8618 for ; Sat, 14 Apr 2012 05:05:26 -0700 (PDT) Received: from [83.167.52.94] (helo=[10.255.171.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJ1j8-0006Wj-La; Sat, 14 Apr 2012 14:05:14 +0200 Message-ID: <4F8967F3.50707@si6networks.com> Date: Sat, 14 Apr 2012 14:05:07 +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: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> In-Reply-To: <1334363774.3945.541.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, 14 Apr 2012 12:05:31 -0000 On 04/14/2012 02:36 AM, Karl Auer wrote: > On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote: >> "IPv6 implementations conforming to this specification MUST generate >> interface identifiers using the algorithm specified in this section in >> replacement of Modified EUI-64 format identifiers." >> ? > > While that is good, it would be clearer if it was expanded out to make > the desired points separately: > > It is intended that the use of Modified-IEEE interface identifiers > be replaced wherever possible by the use of interface identifiers > generated as described in this specification. Shouldn't it be specified with RFC 2119 language? > When generating interface identifiers, IPv6 implementations > conforming to this specification MUST use the algorithm specified > in this section. > > [I'm not sure this is necessary - it seems to be saying that > "conforming implementations have to conform"] >From my pov, it means that all the algorithm is mandatory (nothing to add or take out). > IPv6 implementations conforming to this specification MUST NOT use > Modified-IEEE format interface identifiers [see 4291 Appendix A] for > any purpose EXCEPT THAT link local addresses MAY be generated using > Modified-IEEE format interface identifiers. > > [remove everything from EXCEPT THAT onwards if that isn't what you > intended] Yep. I think it would be better to have all IIDs generated with the algorithm. > If for any reason the generation of an interface identifier > according to this specification fails, IPv6 implementations > conforming to this specification MUST NOT fall back to > using Modified-IEEE format interface identifiers. > > Interface identifiers other than Modified-IEEE interface identifiers > MAY be used in addition to interface identifiers generated according > to this specification. Ok, I will add this. >> It shouldn't be possible. The idea is that the secret key is set to a >> random number (by default). > > I still think you need a special value for "invalid secret key", so that > any systems do not have any way to obtain random numbers can refuse to > autoconfigure if the key is not set. I'd like other to weigh in on this one. -- I don't think there's a need for a "invalid secret key". The secret key is supposed to be generated/selected at installation time. If for some reason such secret_key cannot be randomly generated, the the OS can prompt the user for one. >>> 5: Duplicate address detection is not mentioned explicitly, but probably >>> should be - what happens if a host does DAD and determines that its >>> stable address is already in use? >> >> Address configuration fails. > > That should be in the spec. As noted, IIRC this is not clearly defined for traditional SLAAC, either. So, should we be different in this respect? >> That said, if deemed appropriate, one could include one additional byte, >> "DAD" in the hash function, which is initialized to 0, and that is >> incremented by 1 if the host wants to try a different address if/when >> DAD fails. >> >> If we do that, the implementations should probably cache the resulting >> address, such that it is stable. (otherwise the resulting address might >> change if the same node was brought up while the node with the >> conflicting address is off). > > This may not be possible on systems with no onboard storage, and makes > things much more complicated. I suggest that if DAD fails, then > autoconfiguration should just fail (at least as regards stable > addresses). This is kind of the way DAD works with traditional SLAAC. However, I'm not sure whether this is the right approach (to have address configuration fail as a result of that), or whether it would be better to have some "backup plan" (even if the address is not stored in on non-volatile storage). For instance, the IIDs that you generate with this scheme are not globally unique, and then, probabilistically speaking, there could be collisions. >> Actually, this algorithm could still be used with longer prefixes (i.e., >> fewer bits for the IID). So I'm not sure whether we should include this >> requirement. e.g., if we were to eventually allow non-/64 autoconfigured >> addresses, this algorithm could be use without any changes (while the >> traditional MAC-based identifiers couldn't). > > I like the 64-bit limitation. Either way it should be made explicit. Is this made explicit in any RFC for traditional SLAAC addresses? >> (Note that this is a different issue from item #1 above: Item #1 above >> is about what you should do if you implement this spec, while the point >> that I'm making in the previous paragraph is that you SHOULD implement >> this spec). > > I don't think a spec can mandate it's own use unless it obsoletes or > updates a spec that mandates something. Your spec would have to update > 4291, for example, replacing the whole modified-IEEE thing with your > mechanism. That's a BIG step. Well, that shouldn't be a big deal, and it would be a big advance. If we were to pursue that path, it should be a "SHOULD", such that in specific scenarios or circumstances nodes can still used the MAC-based addresses. >> Additionally, I'd argue that in order to have such thing, then >> 1) You'd need to manually configure your address each time you move from >> one network to another (as with manual configuration requires you to set >> the whole address, rather than just the IID bits), or, > > No - you could just have a flag that says "the key is the interface > identifier I want to use - verbatim". Sorry, what you put in the key would be used for setting the IID?? > Then that IID gets appended to > whatever prefix happens along. Obviously this does NOT have the same > anti-tracking qualities etc, but I can see it being useful. What's the use case you have in mind? 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 Apr 14 06:02: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 03BFD21F8496 for ; Sat, 14 Apr 2012 06:02:22 -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 YrEdQEnYk6eV for ; Sat, 14 Apr 2012 06:02:21 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id D0DCF21F8452 for ; Sat, 14 Apr 2012 06:02:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAHd0iU+WZX+7/2dsb2JhbAANN4VmsjQBAQEDASNbCwsYKgICVxmICaYTklKOJYIMgRgEoSiHcw Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.205]) ([150.101.127.187]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Apr 2012 22:32:17 +0930 Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F8967F3.50707@si6networks.com> References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F8967F3.50707@si6networks.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Todxeul6Fv7hAJDbmhO4" Date: Sat, 14 Apr 2012 23:02:14 +1000 Message-ID: <1334408534.3945.631.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, 14 Apr 2012 13:02:22 -0000 --=-Todxeul6Fv7hAJDbmhO4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2012-04-14 at 14:05 +0200, Fernando Gont wrote: > Shouldn't it be specified with RFC 2119 language? The first para just described intent. The others used 2119 language. > Yep. I think it would be better to have all IIDs generated with the > algorithm. It may be better, but it is a change to a massively widely-implemented mechanism. I suggest therefore "IPv6 implementations conforming to this specification MUST NOT use Modified-IEEE format interface identifiers [see 4291 Appendix A] for any purpose EXCEPT THAT link local addresses MAY (but SHOULD NOT) be generated using Modified-IEEE format interface identifiers. > Sorry, what you put in the key would be used for setting the IID?? Yep - if I set the flag and put "::53" in the key, then the address generated will be prefix::53. But this is just an off-topic idea and not essential to your draft. > What's the use case you have in mind? Don't have one :-) 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 --=-Todxeul6Fv7hAJDbmhO4 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) iF4EABEIAAYFAk+JdU8ACgkQFpl7eE7uYBc5AAEAwq4+Tk/miKbJY+xD2h2Kf/M3 +EyiJJSt1uPpTHJ3NysBAIZpophct9gwxiIdZAeukoR+EZiqgpztLIgcWnBv8Gne =kjxG -----END PGP SIGNATURE----- --=-Todxeul6Fv7hAJDbmhO4-- From fgont@si6networks.com Sat Apr 14 06:20: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 B38AA21F8577 for ; Sat, 14 Apr 2012 06:20:28 -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 NlPbVhYbS91f for ; Sat, 14 Apr 2012 06:20:28 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BA8B721F8557 for ; Sat, 14 Apr 2012 06:20:27 -0700 (PDT) Received: from [83.167.52.94] (helo=[10.255.171.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJ2tq-00075b-3h; Sat, 14 Apr 2012 15:20:22 +0200 Message-ID: <4F897994.2070106@si6networks.com> Date: Sat, 14 Apr 2012 15:20:20 +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: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F8967F3.50707@si6networks.com> <1334408534.3945.631.camel@karl> In-Reply-To: <1334408534.3945.631.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, 14 Apr 2012 13:20:28 -0000 Hi, Karl, Please find my comments in-line.... On 04/14/2012 03:02 PM, Karl Auer wrote: > On Sat, 2012-04-14 at 14:05 +0200, Fernando Gont wrote: >> Shouldn't it be specified with RFC 2119 language? > > The first para just described intent. The others used 2119 language. The point is that without RFC2119-language, we'd not be recommending nodes whether to use draft-gont-6man-stable-privacy-addresses, and they might continue using the MAC-based addresses when they should probably be doing otherwise. >> Yep. I think it would be better to have all IIDs generated with the >> algorithm. > > It may be better, but it is a change to a massively widely-implemented > mechanism. Well, yes. But certainly implementations that predate this document would not need to comply with it (i.e., a product doesn't need to comply with *future* specifications). I personally think it would be important to move away from the MAC-based addresses, not only for their negative security implications (host-tracking and host-scanning), but also because right now we're missing the opportunity to take advantage of the IPv6 increased address space to provide improved security when compared to IPv4. > I suggest therefore > > "IPv6 implementations conforming to this specification MUST NOT > use Modified-IEEE format interface identifiers [see 4291 Appendix > A] for any purpose EXCEPT THAT link local addresses MAY (but SHOULD > NOT) be generated using Modified-IEEE format interface identifiers. I don't think that you can have a MAY and SHOULD NOT for the same thing as noted above: they conflict with each other. Besides, I think that link-local addresses should be generated with the same algorithm, since there are ways in which they can leak out, and hence could be potentially used for host-tracking. >> Sorry, what you put in the key would be used for setting the IID?? > > Yep - if I set the flag and put "::53" in the key, then the address > generated will be prefix::53. I think this would be asking for trouble. Somebody might manually set the secret_key to a secret they use for something else, then mistakenly set the flag, and then the secret_key leaks out..... > But this is just an off-topic idea and not > essential to your draft. Agreed. 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 fgont@si6networks.com Sat Apr 14 07:34: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 7855221F85EF for ; Sat, 14 Apr 2012 07:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_BELOW=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 GqxFQ1wccbbo for ; Sat, 14 Apr 2012 07:34:00 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id F19CE21F85E7 for ; Sat, 14 Apr 2012 07:33:59 -0700 (PDT) Received: from [83.167.52.94] (helo=[10.255.207.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJ432-0007et-4L; Sat, 14 Apr 2012 16:33:56 +0200 Message-ID: <4F89851D.1030504@si6networks.com> Date: Sat, 14 Apr 2012 16:09:33 +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: Tim Chown Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <9DDD54D3-5A69-499B-8496-119641348B1F@ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List 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, 14 Apr 2012 14:34:00 -0000 On 04/14/2012 12:30 PM, Tim Chown wrote: > I while ago I put this one forward, which is an alternative to > Fernando's suggestion that you have to set the whole address: > > http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-00 > > This was based on existing implementations, in Solaris and Linux (as > a demonstrator), with the potential for simpler renumbering in mind. Does this really help renumbering? e.g., if you have ACLs, they are based on the whole IPv6 address, rather than on the IID... > It's probably the complete antithesis of what Fernando is trying to > achieve, but is aimed at the type of (server) systems that would > probably be DNS-advertised anyway. Note that having an address advertised in the DNS does not necessarily means that predictable addresses are not useful to an attacker. For example, let's assume that you know that a network link hosts 100 different servers, each with a different domain. If their addresses are not predictable, and the attacker wants to find all of them, he may have to rely on a "dictionary" attack. However, if the addresses *are* predictable, he could just sweep the interested part of the address space. Note: I still don't understand the use case for this technology, or how the IIDs would be selected (but since they seem to be manually-generated, I'd expect them to be "low-byte", such as ::1, ::2, etc.). 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 tjc@ecs.soton.ac.uk Sat Apr 14 07:49: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 87C4821F860B for ; Sat, 14 Apr 2012 07:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_BELOW=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 2O4Ptj1PCJV1 for ; Sat, 14 Apr 2012 07:49:35 -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 6C44B21F8609 for ; Sat, 14 Apr 2012 07:49:35 -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 q3EEnUY0031391 for ; Sat, 14 Apr 2012 15:49:30 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q3EEnUY0031391 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1334414971; bh=b6K9dsNM74gPT5YyAf33+cPMtK4=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=gqnfVmclUQ0VfvU+DBg7M6wB9uE7tAELAvt9vS7e4qCllk9C9bDKxlerceaIF5Bzb CA3/MBnR91LGk1NkErdw0XVYDP0mDGegSBCaczLimrebBvVqtCDVdEnpBhTXuXI93H ZLAlgGxcHWAu3BVntsF8UWaGWJTHqpV5XYYGyI0w= 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 o3DFnU0543703448Vc ret-id none; Sat, 14 Apr 2012 15:49:30 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q3EEmBwW026857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 14 Apr 2012 15:48:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 From: Tim Chown In-Reply-To: <4F89851D.1030504@si6networks.com> Date: Sat, 14 Apr 2012 15:48:10 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <9DDD54D3-5A69-499B-8496-119641348B1F@ecs.soton.ac.uk> <4F89851D.1030504@si6networks.com> <4F9945E7-D4AA-4F57-8D0F-9EB37D51E811@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=o3DFnU054370344800; tid=o3DFnU0543703448Vc; 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: q3EEnUY0031391 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: Sat, 14 Apr 2012 14:49:36 -0000 On 14 Apr 2012, at 15:09, Fernando Gont wrote: > On 04/14/2012 12:30 PM, Tim Chown wrote: >> I while ago I put this one forward, which is an alternative to >> Fernando's suggestion that you have to set the whole address: >>=20 >> = http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-00 >>=20 >> This was based on existing implementations, in Solaris and Linux (as >> a demonstrator), with the potential for simpler renumbering in mind. >=20 > Does this really help renumbering? e.g., if you have ACLs, they are > based on the whole IPv6 address, rather than on the IID... It helps reduce the need to store full literals in any configuration, so = if the host is renumbered, it can have a new "manually configured" = address in the new prefix automatically without touching wherever that = might otherwise be configured on the host. Some platforms allow macros, like the IOS ipv6 general-prefix notation = iirc. You can then replace the new prefix and not touch the rest of the = configuration. We did such renumbering tests as long ago as 2004/05, and these tools = were certainly useful back then (it's very dated now, but see = http://www.6net.org/publications/deliverables/D3.6.2.pdf for example) > Note: I still don't understand the use case for this technology, or = how > the IIDs would be selected (but since they seem to be > manually-generated, I'd expect them to be "low-byte", such as ::1, = ::2, > etc.). They can be whatever you want them to be. Based on our IPv6 mail logs, = an awful lot of MXs use ::25 for example. But if you want a = stable identifier across renumbering events, or without configuring a = full literal, the tokenised identifier concept is quite nice. I don't know if Sun has any IPR claim on it though. Tim= From brian.e.carpenter@gmail.com Sat Apr 14 07:56: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 EEDEB21F8630 for ; Sat, 14 Apr 2012 07:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.514 X-Spam-Level: X-Spam-Status: No, score=-100.514 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, MANGLED_BELOW=2.3, RCVD_ILLEGAL_IP=1.908, 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 XF6WGS-uB7tc for ; Sat, 14 Apr 2012 07:56:36 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44C4B21F861B for ; Sat, 14 Apr 2012 07:56:36 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2677109wgb.13 for ; Sat, 14 Apr 2012 07:56:35 -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=ZiNJO/j/vQMg5AhOdE+rON8+ZZeiyREW/vmVayoHBEM=; b=YJ50Y3XV5eWdkAcdHRp6+Wj52OuK9Anj5HRTUFCW3kCpe3DjXbn0uOSuoSJvhlL6w/ 7++IBO21Z643V4Xt0sW/q1lb+hX6EP5cmxl1EI9do8nSuxtKcqFWw7kr8Z/ghJUyE/ph gNbFh1/26ZqNfRy3fH1ikl60LlhPctuN0h+we0g3ayMIFwBzaP9S4HCF8+rmUXKH3yD5 wLYE7CnzXtVouS+ImOi9J8oOdKKc7WrYgH5cd2pGVclgvw5FxRsF/Q0FUXyVb6lbrd4L MSJ+a8dbHLVUVJlYPRAHg0UKzN5T3M0gDSmJN4yXyFCR4QHJ53GW+S5tsM2D3W4CIXC9 PP2g== Received: by 10.216.132.222 with SMTP id o72mr3011381wei.95.1334415395446; Sat, 14 Apr 2012 07:56:35 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-219-159.as13285.net. [2.102.219.159]) by mx.google.com with ESMTPS id fn2sm8208189wib.0.2012.04.14.07.56.33 (version=SSLv3 cipher=OTHER); Sat, 14 Apr 2012 07:56:34 -0700 (PDT) Message-ID: <4F89901F.1090401@gmail.com> Date: Sat, 14 Apr 2012 15:56:31 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <9DDD54D3-5A69-499B-8496-119641348B1F@ecs.soton.ac.uk> <4F89851D.1030504@si6networks.com> In-Reply-To: <4F89851D.1030504@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , 6man Mailing List 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, 14 Apr 2012 14:56:37 -0000 On 2012-04-14 15:09, Fernando Gont wrote: > On 04/14/2012 12:30 PM, Tim Chown wrote: >> I while ago I put this one forward, which is an alternative to >> Fernando's suggestion that you have to set the whole address: >> >> http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-00 >> >> This was based on existing implementations, in Solaris and Linux (as >> a demonstrator), with the potential for simpler renumbering in mind. > > Does this really help renumbering? e.g., if you have ACLs, they are > based on the whole IPv6 address, rather than on the IID... This is linked to the whole question of why people assign static addresses and how that interacts with renumbering. By getting rid of the MAC address (so that the server address doesn't depend on the network interface hardware) you are part way to static addresses, and one can imagine a prefix-renumbering mechanism that could handle this. Of course here we want an IID that is not only stable but is also well-known; servers don't get address privacy ;-). Fully static addresses are a pain in renumbering, but that discussion belongs in 6RENUM (draft-carpenter-6renum-static-problem). Brian Bian > >> It's probably the complete antithesis of what Fernando is trying to >> achieve, but is aimed at the type of (server) systems that would >> probably be DNS-advertised anyway. > > Note that having an address advertised in the DNS does not necessarily > means that predictable addresses are not useful to an attacker. > > For example, let's assume that you know that a network link hosts 100 > different servers, each with a different domain. > > If their addresses are not predictable, and the attacker wants to find > all of them, he may have to rely on a "dictionary" attack. However, if > the addresses *are* predictable, he could just sweep the interested part > of the address space. > > Note: I still don't understand the use case for this technology, or how > the IIDs would be selected (but since they seem to be > manually-generated, I'd expect them to be "low-byte", such as ::1, ::2, > etc.). > > Thanks! > > Best regards, From dthaler@microsoft.com Sat Apr 14 11:13: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 656C121F852D for ; Sat, 14 Apr 2012 11:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.737 X-Spam-Level: X-Spam-Status: No, score=-103.737 tagged_above=-999 required=5 tests=[AWL=-0.138, 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 Wp4n4QEDH0Bw for ; Sat, 14 Apr 2012 11:13:17 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 10E7D21F84FB for ; Sat, 14 Apr 2012 11:12:37 -0700 (PDT) Received: from mail50-db3-R.bigfish.com (10.3.81.235) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Apr 2012 18:12:37 +0000 Received: from mail50-db3 (localhost [127.0.0.1]) by mail50-db3-R.bigfish.com (Postfix) with ESMTP id 021B1340780; Sat, 14 Apr 2012 18:12:37 +0000 (UTC) X-SpamScore: -6 X-BigFish: VS-6(zz1432Nzz1202hzzz2fh2a8h668h839h944hd25h) 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 (mail50-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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail50-db3 (localhost.localdomain [127.0.0.1]) by mail50-db3 (MessageSwitch) id 1334427140860986_10638; Sat, 14 Apr 2012 18:12:20 +0000 (UTC) Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.229]) by mail50-db3.bigfish.com (Postfix) with ESMTP id CFD59480D2B; Sat, 14 Apr 2012 18:12:20 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Apr 2012 18:12:20 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sat, 14 Apr 2012 18:12:19 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0283.004; Sat, 14 Apr 2012 11:12:19 -0700 From: Dave Thaler To: Ray Hunter Subject: RE: 3484bis and privacy addresses Thread-Topic: 3484bis and privacy addresses Thread-Index: AQHNGUajDaqZ7/kESEaVgy0zYPsEC5aZSPWQgAErsYCAACukIA== Date: Sat, 14 Apr 2012 18:12:18 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B5159E0@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <4F716D5C.40402@innovationslab.net> <4F726C9E.50107@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B5054C1@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F83D8D0.5030402@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B508719@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F858C32.6060709@globis.net> <9B57C850BB53634CACEC56EF4853FF653B50CBC2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F87D4EA.4040801@globis.net> <9B57C850BB53634CACEC56EF4853FF653B513879@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F8935C7.6020602@globis.net> In-Reply-To: <4F8935C7.6020602@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] 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: Sat, 14 Apr 2012 18:13:18 -0000 > Forgive me if I read your reply wrongly, but you seem to point the blame = for > there being an incomplete solution for remote management squarely at > draft-ietf-6man-addr-select-opt-03. No, I'm saying the issues you're raising are issues with draft-ietf-6man-ad= dr-select-opt not rfc3484bis. > So what would I like to see happen? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > What about defining a conceptual "address selection policy table" in > RFC3484bis in addition to the "prefix policy table"? >=20 > It would contain a complete list of the conceptual knobs and switches tha= t > influence the behaviour of RFC3484bis end nodes, conceptual variable > names, conceptual variable type, what behaviour the variable sets (cross > referenced to the section), default settings (where these are already agr= eed in > the WG) etc. Currently it does have a complete list in text. For system-wide switches that control sorting, there's only one. > Then draft-ietf-6man-addr-select-opt-03 would simply define how to > transport those options over DHCPv6, rather than having to define the > options themselves. Agree that draft-ietf-6man-addr-select-opt should define how to transport over DHCPv6 system-wide administrative options controlling sorting. Currently we only have 1 and draft-ietf-6man-addr-select-opt is missing it. > Equally, if an implementor wanted to set these options via a config file,= or AD > group policy, or any other management process, they'd have a check list o= f > things to do as well. > > And if there are ever future extensions to RFC3484bis (e.g. a new rule to > introduce dollar cost of network links or QoS factors into the address > selection process), any new switches or new default behaviour could also = be > added to this conceptual "address selection policy table". > If we'd already done this in RFC3484 it would have probably avoided a lot= of > pain with divergent implementations. >=20 > To be clear: I don't necessarily see the need to define new knobs or swit= ches > right now: just to clarify what existing knobs or switches will conceptua= lly be > called, what their conceptual types are (e.g. boolean), how/when they're = set, > what behaviour they influence, and their default behaviour (if agreed), p= lus a > hint of how to add new knobs and switches in the future. This conceptual > approach has been used very successfully in ND (RFC4861) and other > standards, and I think it would address my current concerns of there bein= g > too much hard coding in address selection. I take your comment as asking for a summary table in rfc 3484bis of system-wide config options. That could be done as a purely editorial change, although if there's only 1 thing in the table it's less interesting= . But if others in the WG think this would be helpful, then yes we can do tha= t. -Dave=20 From fgont@si6networks.com Sat Apr 14 13:01: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 1EA9821F85B1 for ; Sat, 14 Apr 2012 13:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 YpgP+LrwxQm9 for ; Sat, 14 Apr 2012 13:01:35 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 89EDC21F85A8 for ; Sat, 14 Apr 2012 13:01:35 -0700 (PDT) Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJ9A2-00028M-V6; Sat, 14 Apr 2012 22:01:31 +0200 Message-ID: <4F899C40.1060403@si6networks.com> Date: Sat, 14 Apr 2012 17:48: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: Brian E Carpenter Subject: Tokenized addresses (was: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01) References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <9DDD54D3-5A69-499B-8496-119641348B1F@ecs.soton.ac.uk> <4F89851D.1030504@si6networks.com> <4F89901F.1090401@gmail.com> In-Reply-To: <4F89901F.1090401@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , 6man Mailing List 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, 14 Apr 2012 20:01:36 -0000 On 04/14/2012 04:56 PM, Brian E Carpenter wrote: >> Does this really help renumbering? e.g., if you have ACLs, they are >> based on the whole IPv6 address, rather than on the IID... > > This is linked to the whole question of why people assign static > addresses and how that interacts with renumbering. By getting rid > of the MAC address (so that the server address doesn't depend on > the network interface hardware) you are part way to static addresses, At some point I played with the idea of including the interface-index (rather than the MAC address in F() (in the algorithm in draft-gont-6man-stable-privacy-addresses), which would still make the resulting IIDs vary across networks as the host moves, but remain constant in the presence of hardware changes. > and one can imagine a prefix-renumbering mechanism that could handle > this. Of course here we want an IID that is not only stable but is > also well-known; servers don't get address privacy ;-). Well, they *could* -- please see above. 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 fred@cisco.com Sat Apr 14 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 EB0D121F858F for ; Sat, 14 Apr 2012 13:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.799 X-Spam-Level: X-Spam-Status: No, score=-110.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 a9vqX46oHzd1 for ; Sat, 14 Apr 2012 13:08:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EA33821F85B1 for ; Sat, 14 Apr 2012 13:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1715; q=dns/txt; s=iport; t=1334434118; x=1335643718; h=mime-version:subject:from:in-reply-to:date:message-id: references:to:content-transfer-encoding; bh=uQmIZwIbInndRJ3DpBrnn7wbPjLhH4HiQVN9o6IN+cs=; b=SdX2QTUz/o4LAG2f0y0Tf0Pg9fRwekh4bKPvLVpXl23hggRW6oLKJAUb HhbrAX19lWkLltEGgWKkgj8/iE9y2pjJHwn3C+Hy8KGVvEjY6W+KiFk6Y ketGt68ddtZNmIlfrGUvfEavSd3grwRUCXEjV8+SqL2J4iA0UJwXOXUEq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGnYiU+rRDoH/2dsb2JhbABEtQuBB4IKAQEEEgEnTws7C1cGNYdrmHufI5BmYwSIWo0ThXKIWoFpgwc X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="40580923" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 14 Apr 2012 20:08:37 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3EK8bIS024679 for ; Sat, 14 Apr 2012 20:08:37 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 14 Apr 2012 13:08:37 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 14 Apr 2012 13:08:37 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 (was: Re: Consensus call on adopting:....) From: Fred Baker In-Reply-To: Date: Sat, 14 Apr 2012 13:08:06 -0700 Message-Id: References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> To: "ipv6@ietf.org 6man" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii 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, 14 Apr 2012 20:08:39 -0000 Speaking for myself, I don't understand the fixation on MAC addresses. = Yes, Ethernet and other IEEE standards are widely used. They are not = used on serial links (we seem to mostly use /127 prefixes for that), = they are not used on the air side of 3G etc, and so on. And as a matter = of fact, for all the discussion of Modified EUI-64 aaddresses in RFC = 4291, a host or router sending a packet to another host or router that = is directly connected at L3 doesn't extract his peer's MAC address from = his IPv6 EID. The point of using a MAC address to generate an EID was to = make it likely that the EID was unique within the subnet, not to derive = it back again. Once it's an EID, it doesn't matter how it was derived. = So from my perspective, the entirety of Appendix A and section 2.5.1 = could be replaced with "The EID is intended to be a 64 bit number unique = within the subnet. One way to generate such a number is from another = number such as is specified by EUI-64, EUI-48, E.164, or E.212, an IPv4 = address, or a serial number specific to the hardware in question." The point of this document is that *another* way to generate it is using = a random number generator (privacy addresses), but in such a case there = may be certain stability requirements for operational reasons. May I suggest that the right way to address this is to use much of = fernando's technical commentary to substantiate the stability = requirements and the need to change it when the prefix is changed (for = reasons including a change of LAN, but also including renumbering = events) and write a short document updating RFC 4291 to remove the = fixation on one of many possible EID types.= From fgont@si6networks.com Sat Apr 14 13:33: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 9D73C21F8566 for ; Sat, 14 Apr 2012 13:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 HJRsWJ0z90pX for ; Sat, 14 Apr 2012 13:33:03 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF7721F84FA for ; Sat, 14 Apr 2012 13:32:48 -0700 (PDT) Received: from 130.41-14-84.ripe.coltfrance.com ([84.14.41.130] helo=[192.168.102.30]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJ9eG-0002OO-RP; Sat, 14 Apr 2012 22:32:44 +0200 Message-ID: <4F89DEE7.1080205@si6networks.com> Date: Sat, 14 Apr 2012 22:32:39 +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: Fred Baker Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> 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 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: Sat, 14 Apr 2012 20:33:03 -0000 Hi, Fred, On 04/14/2012 10:08 PM, Fred Baker wrote: > Speaking for myself, I don't understand the fixation on MAC > addresses. What do you mean, exactly? > Yes, Ethernet and other IEEE standards are widely used. > They are not used on serial links (we seem to mostly use /127 > prefixes for that), they are not used on the air side of 3G etc, and > so on. And as a matter of fact, for all the discussion of Modified > EUI-64 aaddresses in RFC 4291, a host or router sending a packet to > another host or router that is directly connected at L3 doesn't > extract his peer's MAC address from his IPv6 EID. The point of using > a MAC address to generate an EID was to make it likely that the EID > was unique within the subnet, not to derive it back again. I think this wasn't assumed by anyone (i.e. we all agree on this). > Once it's > an EID, it doesn't matter how it was derived. So from my perspective, > the entirety of Appendix A and section 2.5.1 could be replaced with > "The EID is intended to be a 64 bit number unique within the subnet. > One way to generate such a number is from another number such as is > specified by EUI-64, EUI-48, E.164, or E.212, an IPv 4 address, or a > serial number specific to the hardware in question." This still leads to addresses that allow host tracking. -- PLease see Section 7 of my I-D. > The point of this document is that *another* way to generate it is > using a random number generator (privacy addresses), but in such a > case there may be certain stability requirements for operational > reasons. In order to get stable addresses within a subnet, that change across networks, you need a scheme such as the one proposed. So I don't follow how the minor mod that you're referring to would address this. > May I suggest that the right way to address this is to use much of > fernando's technical commentary to substantiate the stability > requirements and the need to change it when the prefix is changed You not only need the ID to change as you move to a different network, but you also want the ID to be the same when you move back to the same network. So I don't follow why you think the path we're following is not the right path. For instance, my document aims to do exactly what you are describing. > (for reasons including a change of LAN, but also including > renumbering events) and write a short document updating RFC 4291 to > remove the fixation on one of many possible EID types. So you'd include requirements, but don't specifiy how to comply with them? -- I don't really follow. And also don't follow why one should start with other I-D, when the current one has been discussed, presented, and reviewed by quite a few relevant people, which agreed with the proposal. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From huitema@microsoft.com Sat Apr 14 16:20: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 0FC8421F8572 for ; Sat, 14 Apr 2012 16:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=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 kmWMu8PRbXfX for ; Sat, 14 Apr 2012 16:20:06 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 51CB121F856D for ; Sat, 14 Apr 2012 16:20:06 -0700 (PDT) Received: from mail11-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Apr 2012 23:20:05 +0000 Received: from mail11-ch1 (localhost [127.0.0.1]) by mail11-ch1-R.bigfish.com (Postfix) with ESMTP id 1F0CD1401F6; Sat, 14 Apr 2012 23:20:05 +0000 (UTC) X-SpamScore: -5 X-BigFish: VS-5(zz1503Mzz1202hzzz2fh2a8h668h839h944hd25h) 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 (mail11-ch1: 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 mail11-ch1 (localhost.localdomain [127.0.0.1]) by mail11-ch1 (MessageSwitch) id 1334445604210828_27691; Sat, 14 Apr 2012 23:20:04 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail11-ch1.bigfish.com (Postfix) with ESMTP id 259C9480045; Sat, 14 Apr 2012 23:20:04 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Apr 2012 23:20:03 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.159]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Sat, 14 Apr 2012 23:20:02 +0000 From: Christian Huitema To: Fernando Gont , Fred Baker Subject: RE: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Topic: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Index: AQHNGn3UDPx4Kw3MF0OxBylTRJLkeZaa55aA Date: Sat, 14 Apr 2012 23:20:01 +0000 Message-ID: References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> In-Reply-To: <4F89DEE7.1080205@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org 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: Sat, 14 Apr 2012 23:20:07 -0000 I agree with Fred that we only need to specify "please somehow get a suitab= le 64 bit number." There are a couple of requirements that have to be met = -- or at least considered: 1) Uniqueness: the number must be unique within the scope of the subnet. 2) Non traceability: the number should be different for different subnet, s= o hosts cannot be readily traced as they move to different locations. 3) Privacy: the number should vary over time, to make it harder for Interne= t services to correlate sessions started by the same host. 4) Stability: the number should remain stable over time, so administrators = can more easily manage which host is using what network service. Of course, stability and privacy are contradictory, so there must be a way = for arbitraging that. That's the big issue to be dealt with by the specific= ation of privacy addresses, i.e. whatever successor we write for RFC 3484. = The arbitration will be resolving about how often host generate addresses, = how many addresses they generate, and under what circumstances do they use = one or the other. Let's assume for now that we just want to generate addres= ses once per subnet. In principle, there are two ways to meet the unique per subnet requirement:= use a number that is guaranteed to be unique by design; or use a large ran= dom number that is unlikely to collide with an existing allocation. The pro= blem of course is that random numbers will sometime collide. It may be a lo= w probability event, but it will eventually happen. In fact, even the "uniq= ue by design" numbers like EUI64 can collide occasionally, if some manageme= nt error occurred. That's why we do DAD. So, we have another requirement in= the address allocation: 5) Retry: host must be able to detect potential collisions and retry, i.e. = generate a different random number. Fernando's algorithm has several advantages. It uses a hash of a pre-alloca= ted random number, and thus mitigates the issue of weak random number gener= ators in some hosts. It incorporates the subnet prefix, and thus meets the = "non-traceability" requirement. But Fernando's algorithm has no provision f= or "retry", and thus misses a key requirement. So, instead of Fernando's sp= ecification, I suggest that we define the algorithm's input as: RID =3D F(Prefix, Modified_EUI64, Network_ID, secret_key, salt)=20 Where prefix , Modified_EUI64, network ID and secret key are defined as per= Fernando's proposal, and "salt" is a long integer, typically set to the nu= mber of retries used to generate the 64 bit ID. Of course, if we can support retries, we can also support privacy addresses= -- the private address can be generated with just a gratuitous retry, a mo= dified salt. In fact, with that formulation, we can be very close to the fo= rmat defined in SEND (RFC 3972) -- just replace the "secret key" by the pub= lic key of the host. So we have a chance of unifying CGA, privacy addresses= , and stable random addresses. -- Christian Huitema =20 From fred@cisco.com Sat Apr 14 16:30: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 5637221F861B for ; Sat, 14 Apr 2012 16:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.766 X-Spam-Level: X-Spam-Status: No, score=-110.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 mvjkK3kvurQZ for ; Sat, 14 Apr 2012 16:30:00 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A6E7921F8610 for ; Sat, 14 Apr 2012 16:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2509; q=dns/txt; s=iport; t=1334446200; x=1335655800; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=bMvbPBpdOhh6rhTokiVuW8m0croLfj+g0z14751Wq4E=; b=STF9+cvEBDTUR/nfV/JPNvmby6zD098/7FcYuh+7BonhhWU/nvp+IPX4 4A7jlniDW8C9vKvtuQ5CmhqrUSbKRfDp9GMZnxlxL8h1ukolpgYS7x+Fn ZqPL2f8pg33i/zv0ZjxoAH+G72cwwrjctdys70ykR4VF03v3F5ttHo7kn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACYHik+rRDoI/2dsb2JhbABDtQuBB4IJAQEBAwESASc/BQsLGC5XBjWHZwQMmG+fEwSQZmMEiFqNE4VyiFqBaYMH X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="40589724" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 14 Apr 2012 23:30:00 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3ENTxYe002719; Sat, 14 Apr 2012 23:29:59 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 14 Apr 2012 16:30:00 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 14 Apr 2012 16:30:00 -0700 Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 14 Apr 2012 16:29:30 -0700 Message-Id: <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> To: Christian Huitema X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , "ipv6@ietf.org 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: Sat, 14 Apr 2012 23:30:02 -0000 On Apr 14, 2012, at 4:20 PM, Christian Huitema wrote: > 3) Privacy: the number should vary over time, to make it harder for = Internet services to correlate sessions started by the same host. > 4) Stability: the number should remain stable over time, so = administrators can more easily manage which host is using what network = service. >=20 > Of course, stability and privacy are contradictory, so there must be a = way for arbitraging that. That's the big issue to be dealt with by the = specification of privacy addresses, i.e. whatever successor we write for = RFC 3484. The arbitration will be resolving about how often host = generate addresses, how many addresses they generate, and under what = circumstances do they use one or the other. Let's assume for now that we = just want to generate addresses once per subnet. That pp mixes two things: https://tools.ietf.org/html/rfc3484 3484 Default Address Selection for Internet Protocol version 6 (IPv6). R. Draves. February 2003. (Format: TXT=3D55076 bytes) (Status: = PROPOSED STANDARD) https://tools.ietf.org/html/rfc4941 4941 Privacy Extensions for Stateless Address Autoconfiguration in IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format: TXT=3D56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD) I agree that the arbitrage is largely about the rate of address = generation. I should think that's a local matter; two = otherwise-identical laptops sitting beside each other on a LAN could be = different - one changing its address once a week, and the other changing = its address for every TCP session. Apart from the impact of DAD, I don't = see much harm in letting them do so. > In principle, there are two ways to meet the unique per subnet = requirement: use a number that is guaranteed to be unique by design; or = use a large random number that is unlikely to collide with an existing = allocation. That's for global uniqueness. If all that is required is uniqueness in a = subnet, something akin to that makes sense for the first guess, but = after that it's all about DAD. > Fernando's algorithm has several advantages. It uses a hash of a = pre-allocated random number, As I read it, section three item one calls for the use of the EUI-64 in = use on the interface, which presumes that the interface is an IEEE 802 = LAN. There are other interface types. I'd like to see that widened to a = number *such*as* one of the set I specified.= From huitema@microsoft.com Sat Apr 14 17:08: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 2F92821F865D for ; Sat, 14 Apr 2012 17:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Uo38WkpblHrH for ; Sat, 14 Apr 2012 17:08:17 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3D96521F865C for ; Sat, 14 Apr 2012 17:08:17 -0700 (PDT) Received: from mail11-db3-R.bigfish.com (10.3.81.241) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 15 Apr 2012 00:08:15 +0000 Received: from mail11-db3 (localhost [127.0.0.1]) by mail11-db3-R.bigfish.com (Postfix) with ESMTP id E744E44077E; Sun, 15 Apr 2012 00:08:15 +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 (mail11-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 mail11-db3 (localhost.localdomain [127.0.0.1]) by mail11-db3 (MessageSwitch) id 1334448493117513_15940; Sun, 15 Apr 2012 00:08:13 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.227]) by mail11-db3.bigfish.com (Postfix) with ESMTP id 185FA40004C; Sun, 15 Apr 2012 00:08:13 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 15 Apr 2012 00:08:12 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.159]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Sun, 15 Apr 2012 00:07:22 +0000 From: Christian Huitema To: Fred Baker Subject: RE: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Topic: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Index: AQHNGn3UDPx4Kw3MF0OxBylTRJLkeZaa55aAgAAQTwCAAAmzIA== Date: Sun, 15 Apr 2012 00:07:22 +0000 Message-ID: References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> In-Reply-To: <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Fernando Gont , "ipv6@ietf.org 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: Sun, 15 Apr 2012 00:08:18 -0000 > As I read it, section three item one calls for the use of the EUI-64 in u= se on the interface, which presumes that the=20 > interface is an IEEE 802 LAN. There are other interface types. I'd like t= o see that widened to a number *such*as* > one of the set I specified. You don't really need the EUI64 for the proposal to work. We could just as = well completely omit the field, and simply use the EUI64 as an optional see= d for the random number. But there are two advantages: * Using some form of interface ID allows the host to keep just one random s= eed for all interfaces, which is nice. * using EUI64 in a context like SEND makes spoofing a little bit harder. -- Christian Huitema From fred@cisco.com Sat Apr 14 19:00: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 4E48221F8674 for ; Sat, 14 Apr 2012 19:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.742 X-Spam-Level: X-Spam-Status: No, score=-110.742 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 JWDa1SqRk-Ue for ; Sat, 14 Apr 2012 19:00:17 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B0D5221F865E for ; Sat, 14 Apr 2012 19:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=934; q=dns/txt; s=iport; t=1334455217; x=1335664817; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=r2PGdQRhiNPXoD/YOSuM9ItdYlys4erhWYNGkp0l4Qc=; b=L3Teb2Dsqj5HdDeSaHjFoPH/2leOXGBZCTHBhko42Lg7TRepV87zuSbJ MhmfNuqEHep9gWtlHn2AmmsA95dYTT+saBJpBn0mB0z4N9RQdcx7E4f+J zl56zkdfqultKZjpA4GrOCgefLkdX59e2iJ8I3wo5ZvCZpXWHTcUxmI9B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI0rik+rRDoJ/2dsb2JhbABEtQuBB4IJAQEBAwESASc/EAtGVwY1h2cEmQafDJBmYwSIWo0ThXKIWoFpgwc X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208";a="37481393" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 15 Apr 2012 02:00:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3F20GCJ018069; Sun, 15 Apr 2012 02:00:17 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 14 Apr 2012 19:00:17 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 14 Apr 2012 19:00:17 -0700 Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 14 Apr 2012 18:59:36 -0700 Message-Id: <923A007D-4D00-4905-939E-342BD26C57DE@cisco.com> References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> To: Christian Huitema X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Fernando Gont , "ipv6@ietf.org 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: Sun, 15 Apr 2012 02:00:18 -0000 On Apr 14, 2012, at 5:07 PM, Christian Huitema wrote: >> As I read it, section three item one calls for the use of the EUI-64 = in use on the interface, which presumes that the=20 >> interface is an IEEE 802 LAN. There are other interface types. I'd = like to see that widened to a number *such*as* >> one of the set I specified. >=20 > You don't really need the EUI64 for the proposal to work. We could = just as well completely omit the field, and simply use the EUI64 as an = optional seed for the random number. But there are two advantages: >=20 > * Using some form of interface ID allows the host to keep just one = random seed for all interfaces, which is nice. > * using EUI64 in a context like SEND makes spoofing a little bit = harder. I have no problem with the EUI-64 if one exists. I'm pointing out that = not all interfaces have one. They might have an E.164 or E.212 number, = or other things.= From fgont@si6networks.com Sat Apr 14 19:16: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 6284D21F8569 for ; Sat, 14 Apr 2012 19:16:45 -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 xloAGmxgodDI for ; Sat, 14 Apr 2012 19:16:44 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6B21F8559 for ; Sat, 14 Apr 2012 19:16:22 -0700 (PDT) Received: from 222.160.102.84.rev.sfr.net ([84.102.160.222] helo=[10.192.168.68]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJF0j-00072F-5j; Sun, 15 Apr 2012 04:16:17 +0200 Message-ID: <4F8A2F6D.7060203@si6networks.com> Date: Sun, 15 Apr 2012 04:16:13 +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: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@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 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: Sun, 15 Apr 2012 02:16:45 -0000 On 04/15/2012 01:20 AM, Christian Huitema wrote: > I agree with Fred that we only need to specify "please somehow get a > suitable 64 bit number." There are a couple of requirements that > have to be met -- or at least considered: > > 1) Uniqueness: the number must be unique within the scope of the > subnet. 2) Non traceability: the number should be different for > different subnet, so hosts cannot be readily traced as they move to > different locations. 3) Privacy: the number should vary over time, to > make it harder for Internet services to correlate sessions started by > the same host. 4) Stability: the number should remain stable over > time, so administrators can more easily manage which host is using > what network service. If this is about a fixup for RFC4291 (kind of orthogonal to draft-gont-6man-stable-privacy-addresses), then I'd argue that the only requirement to be specified is that of uniqueness. If anything, different algorithms would make trade-offs among aspects #1-4. > Of course, stability and privacy are contradictory, so there must be > a way for arbitraging that. That's the big issue to be dealt with by > the specification of privacy addresses, i.e. whatever successor we > write for RFC 3484. The arbitration will be resolving about how often > host generate addresses, how many addresses they generate, I think that the issue of how many addresses you generate is depending of the addrsel policy. Gnerating addresses is "step 1". Address selection (step #2) deals with selecting from the addresses generated in the pervious step. > In principle, there are two ways to meet the unique per subnet > requirement: use a number that is guaranteed to be unique by design; > or use a large random number that is unlikely to collide with an > existing allocation. While in theory this is correct, in practice it isn't: Think about virtual machines: most implementations use a fixed OUI, and randmize the Ethernet address from there. Which means that you could have the SLAAC addresses of two different VMs collide, even if they are supposedley being generated with globally-unique identifiers. > The problem of course is that random numbers > will sometime collide. It may be a low probability event, but it will > eventually happen. In fact, even the "unique by design" numbers like > EUI64 can collide occasionally, if some management error occurred. > That's why we do DAD. So, we have another requirement in the address > allocation: > > 5) Retry: host must be able to detect potential collisions and retry, > i.e. generate a different random number. The question here is whether this is something that should be dealt with in each specific algorithm (e.g., draft-gont-6man-stable-privacy-addresses-01), or this is something that should be algorithm-agnostic. For example, the specification for the generation of tradicional MAC addresses does not deal with this issue in detail -- and in practice, implementations do not try a different address when DAD fails. As noted to Karl in this thread, I'd probably deal with the potential address collisions (i.e., DAD failures) within the algorithm, Just add a one-byte or two-byte counter to the hash, that e.g. is initialized to 0, and incremented each time DAD fails. > Fernando's algorithm has several advantages. It uses a hash of a > pre-allocated random number, and thus mitigates the issue of weak > random number generators in some hosts. It incorporates the subnet > prefix, and thus meets the "non-traceability" requirement. But > Fernando's algorithm has no provision for "retry", and thus misses a > key requirement. This could be trivially added as noted above (for instance, I asked others to weigh in :-) ). There's also the issue fo whether even in the presence of Ethernet, one should include the Modified-EUI-64 as a paramenter to the hash function, or whether one should rather use the interface index: in that case, we'd gain an additiona benefit -- even for Ethernet, you could replace the NIC, and the resulting address wouldn't change. 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 Apr 14 19:23: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 B52FC21F8566 for ; Sat, 14 Apr 2012 19:23:44 -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 6IRRxul-l+dr for ; Sat, 14 Apr 2012 19:23:44 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id DE3AD21F8557 for ; Sat, 14 Apr 2012 19:23:43 -0700 (PDT) Received: from 222.160.102.84.rev.sfr.net ([84.102.160.222] helo=[10.192.168.68]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJF7q-0003su-Vg; Sun, 15 Apr 2012 04:23:39 +0200 Message-ID: <4F8A3124.4090005@si6networks.com> Date: Sun, 15 Apr 2012 04:23:32 +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: Fred Baker Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> In-Reply-To: <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "ipv6@ietf.org 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: Sun, 15 Apr 2012 02:23:44 -0000 On 04/15/2012 01:29 AM, Fred Baker wrote: > As I read it, section three item one calls for the use of the EUI-64 > in use on the interface, which presumes that the interface is an IEEE > 802 LAN. There are other interface types. I'd like to see that > widened to a number *such*as* one of the set I specified. Agreed. This should, at the very least, be fixed in the way you indicate. That said, a more general question would be: should we include the (numeric) interface index rather than e.g. a hardware-specific I-D? By replacing the "Modified-EUI-64" with the interfaece index, we'd get a cool feature: you can change the NIC, and that doesn't affect the resulting IPv6 address. Thanks! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Sat Apr 14 20:55: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 4F0D521F866D for ; Sat, 14 Apr 2012 20:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.724 X-Spam-Level: X-Spam-Status: No, score=-110.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 ve0WKFOm5uWB for ; Sat, 14 Apr 2012 20:55:19 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 98B7021F8669 for ; Sat, 14 Apr 2012 20:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=344; q=dns/txt; s=iport; t=1334462119; x=1335671719; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=0vjKOI1Qu5yGAlMjbUnPkmIuh6A1yZDkdYBiggx7xpQ=; b=IpmAiB5/WdvggD0/pgfxhPY3G9hcwW91uyhOLcJFEdvLUJ7iCq0NVfzO BAzBvkQqKha4BLYMLBbwTq+SSW7xybn45q41o69QU89nc5oJ8cve4ixLy 8oxHM/p7kG1S74LpGPcWzPdJ0A5SYa5+2icWOZaoiXaL0kd4TgK9/PL9n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJGik+rRDoI/2dsb2JhbABDtQuBB4IJAQEBAwESASc/BQsLDjhXBjWHZwSZBp8BkGZjBIhajROFcohagWmDBw X-IronPort-AV: E=Sophos;i="4.75,424,1330905600"; d="scan'208";a="40511464" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 15 Apr 2012 03:55:19 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3F3tINq015471; Sun, 15 Apr 2012 03:55:18 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 14 Apr 2012 20:55:19 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 14 Apr 2012 20:55:19 -0700 Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F8A3124.4090005@si6networks.com> Date: Sat, 14 Apr 2012 20:54:53 -0700 Message-Id: <1BEEB247-8C36-4139-BF44-79E4993033E1@cisco.com> References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> <4F8A3124.4090005@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Christian Huitema , "ipv6@ietf.org 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: Sun, 15 Apr 2012 03:55:20 -0000 On Apr 14, 2012, at 7:23 PM, Fernando Gont wrote: > That said, a more general question would be: should we include the = (numeric) interface index rather than e.g. a hardware-specific I-D? Hmmm. I would tend to think that's a small positive integer, which isn't = all that unique. Are you thinking of something different than I am?= From huitema@microsoft.com Sat Apr 14 23:19: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 6BD0221F863D for ; Sat, 14 Apr 2012 23:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 fD2lDiDMcxb5 for ; Sat, 14 Apr 2012 23:19:20 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id BD60321F854A for ; Sat, 14 Apr 2012 23:19:19 -0700 (PDT) Received: from mail120-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 15 Apr 2012 06:19:19 +0000 Received: from mail120-va3 (localhost [127.0.0.1]) by mail120-va3-R.bigfish.com (Postfix) with ESMTP id CDFAF380294; Sun, 15 Apr 2012 06:19:18 +0000 (UTC) X-SpamScore: -12 X-BigFish: VS-12(zz179dN1432Nzz1202hzzz2fh2a8h668h839h944hd25h) 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 (mail120-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=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail120-va3 (localhost.localdomain [127.0.0.1]) by mail120-va3 (MessageSwitch) id 1334470756989297_6327; Sun, 15 Apr 2012 06:19:16 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.249]) by mail120-va3.bigfish.com (Postfix) with ESMTP id EC6D64C0046; Sun, 15 Apr 2012 06:19:16 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 15 Apr 2012 06:19:16 +0000 Received: from TK5EX14MBXC274.redmond.corp.microsoft.com ([169.254.3.159]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0283.004; Sun, 15 Apr 2012 06:19:15 +0000 From: Christian Huitema To: Fred Baker , Fernando Gont Subject: RE: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Topic: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Index: AQHNGn3UDPx4Kw3MF0OxBylTRJLkeZaa55aAgAAQTwCAADCgAIAAGYaAgAAn4wA= Date: Sun, 15 Apr 2012 06:19:14 +0000 Message-ID: References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> <4F8A3124.4090005@si6networks.com> <1BEEB247-8C36-4139-BF44-79E4993033E1@cisco.com> In-Reply-To: <1BEEB247-8C36-4139-BF44-79E4993033E1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipv6@ietf.org 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: Sun, 15 Apr 2012 06:19:20 -0000 >> That said, a more general question would be: should we include the (nume= ric) interface index rather than e.g. a=20 >> hardware-specific I-D? > > Hmmm. I would tend to think that's a small positive integer, which isn't = all that unique. Are you thinking of something=20 > different than I am? If the only purpose is to make sure that two interfaces on the same host ha= ve different ID, then a small integer is sufficient. From fgont@si6networks.com Sun Apr 15 07:17: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 642F721F86E8 for ; Sun, 15 Apr 2012 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 cl+L3WHUBADU for ; Sun, 15 Apr 2012 07:17:54 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id E582821F86CB for ; Sun, 15 Apr 2012 07:17:53 -0700 (PDT) Received: from [213.174.121.108] (helo=[192.168.101.204]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJQGu-0002Eb-O5; Sun, 15 Apr 2012 16:17:45 +0200 Message-ID: <4F8A322F.4040205@si6networks.com> Date: Sun, 15 Apr 2012 04:27:59 +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: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.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 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: Sun, 15 Apr 2012 14:17:54 -0000 On 04/15/2012 02:07 AM, Christian Huitema wrote: > You don't really need the EUI64 for the proposal to work. We could > just as well completely omit the field, and simply use the EUI64 as > an optional seed for the random number. But there are two > advantages: You need to be able to differentiate the interfaces, or else two NICs connected to the same subnet would produce the same IPIv6 address. 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 Sun Apr 15 07:29: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 6163B21F87A4 for ; Sun, 15 Apr 2012 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_OFF=2.3, 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 nD+lapA-jqK0 for ; Sun, 15 Apr 2012 07:29:49 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id B598121F87A2 for ; Sun, 15 Apr 2012 07:29:48 -0700 (PDT) Received: from [2001:5c0:1400:a::32b] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SJQSW-0002KF-6A; Sun, 15 Apr 2012 16:29:44 +0200 Message-ID: <4F8ADB24.1050606@si6networks.com> Date: Sun, 15 Apr 2012 16:28:52 +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: Fred Baker Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> <4F8A3124.4090005@si6networks.com> <1BEEB247-8C36-4139-BF44-79E4993033E1@cisco.com> In-Reply-To: <1BEEB247-8C36-4139-BF44-79E4993033E1@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christian Huitema , "ipv6@ietf.org 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: Sun, 15 Apr 2012 14:29:49 -0000 Hi, Fred, On 04/15/2012 05:54 AM, Fred Baker wrote: >> That said, a more general question would be: should we include the >> (numeric) interface index rather than e.g. a hardware-specific >> I-D? > > Hmmm. I would tend to think that's a small positive integer, which > isn't all that unique. Exactly. > Are you thinking of something different than I am? I don't think so. If you concern is security, bear in mind that the security of the mechanism relies on the cryptographic strength of F(), and the secret_key (and not on the "data" that is hashed. -- That said, the current I-D recommends to include the machine's serial number in the hash (as recommended by Steve Bellovin) as part of the data to be hashed (and this value is expected to be unknown at least to a remote attacker). If your concern is that two hosts might end up computing the same IID, then note that the recommendation is for the secret_key to be set to a random value, *and* as noted in the previous paragraph, we also recommend to include the machine's serial number as part of the data to be hashed (and this number is expected to vary from one node to another). This approach would lead to addresses that do not vary if you change the NIC (as we'd not be using the MAC address), and one might argue that is even more 2general" since, as you correctly noted, not all interfaced have IEEE addresses. IN any case, this is just an idea. I personally think that would be really cool. But I'd like you and others to comment. 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 Tina.Tsou.Zouting@huawei.com Sun Apr 15 13:56: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 5AC8621F8876 for ; Sun, 15 Apr 2012 13:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-1.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_OFF=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 CjTdzhdgC1Xn for ; Sun, 15 Apr 2012 13:56:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A029321F8867 for ; Sun, 15 Apr 2012 13:56:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEX99042; Sun, 15 Apr 2012 16:56:36 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Apr 2012 13:55:54 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Apr 2012 13:55:54 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Mon, 16 Apr 2012 04:55:50 +0800 From: Tina TSOU To: Fernando Gont Subject: Re: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Topic: Feedback on draft-gont-6man-stable-privacy-addresses-01 Thread-Index: AQHNGn3Vi4WOiPBDMkmREF4aZJE5EpaabyKAgAACpwCAADCgAIAAGYWAgACxIgCAAPI6lw== Date: Sun, 15 Apr 2012 20:55:49 +0000 Message-ID: <92C76338-38FC-40FE-9CDB-6C4365B67A2F@huawei.com> References: <1334276068.3945.408.camel@karl> <4F882A44.3080305@si6networks.com> <1334363774.3945.541.camel@karl> <4F89DEE7.1080205@si6networks.com> <8C04B19A-6E88-4544-8827-13BB4D672CFE@cisco.com> <4F8A3124.4090005@si6networks.com> <1BEEB247-8C36-4139-BF44-79E4993033E1@cisco.com>, <4F8ADB24.1050606@si6networks.com> In-Reply-To: <4F8ADB24.1050606@si6networks.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_92C7633838FC40FE9CDB6C4365B67A2Fhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Christian Huitema , "ipv6@ietf.org 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: Sun, 15 Apr 2012 20:56:37 -0000 --_000_92C7633838FC40FE9CDB6C4365B67A2Fhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This function results in addresses that: 1. R stable within the same subnet 2. Have different Interface-IDs when moving across networks Sent from my iPad On Apr 15, 2012, at 7:30 AM, "Fernando Gont" > wrote: Hi, Fred, On 04/15/2012 05:54 AM, Fred Baker wrote: That said, a more general question would be: should we include the (numeric) interface index rather than e.g. a hardware-specific I-D? Hmmm. I would tend to think that's a small positive integer, which isn't all that unique. Exactly. Are you thinking of something different than I am? I don't think so. If you concern is security, bear in mind that the security of the mechanism relies on the cryptographic strength of F(), and the secret_key (and not on the "data" that is hashed. -- That said, the current I-D recommends to include the machine's serial number in the hash (as recommended by Steve Bellovin) as part of the data to be hashed (and this value is expected to be unknown at least to a remote attacker). If your concern is that two hosts might end up computing the same IID, then note that the recommendation is for the secret_key to be set to a random value, *and* as noted in the previous paragraph, we also recommend to include the machine's serial number as part of the data to be hashed (and this number is expected to vary from one node to another). This approach would lead to addresses that do not vary if you change the NIC (as we'd not be using the MAC address), and one might argue that is even more 2general" since, as you correctly noted, not all interfaced have IEEE addresses. IN any case, this is just an idea. I personally think that would be really cool. But I'd like you and others to comment. Thanks! Best regards, -- 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 -------------------------------------------------------------------- --_000_92C7633838FC40FE9CDB6C4365B67A2Fhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This function results in addresses that:

1. R stable within the same subnet
2. Have different Interface-IDs when moving across networks

Sent from my iPad

On Apr 15, 2012, at 7:30 AM, "Fernando Gont" <fgont@si6networks.com> wrote:

Hi, Fred,

On 04/15/2012 05:54 AM, Fred Baker wrote:
That said, a more general question would be= : should we include the
(numeric) interface index rather than e.g. = a hardware-specific
I-D?

Hmmm. I would tend to think that's a small = positive integer, which
isn't all that unique.

Exactly.


Are you thinking of something different tha= n I am?

I don't think so.

If you concern is security, bear in mind that the security of the
mechanism relies on the cryptographic strength of F(), and the=
secret_key (and not on the "data" that is hashed. -- That s= aid, the
current I-D recommends to include the machine's serial number in the<= /span>
hash (as recommended by Steve Bellovin) as part of the data to be has= hed
(and this value is expected to be unknown at least to a remote attack= er).

If your concern is that two hosts might end up computing the same IID= ,
then note that the recommendation is for the secret_key to be set to = a
random value, *and* as noted in the previous paragraph, we also
recommend to include the machine's serial number as part of the data = to
be hashed (and this number is expected to vary from one node to anoth= er).

This approach would lead to addresses that do not vary if you change = the
NIC (as we'd not be using the MAC address), and one might argue that = is
even more 2general" since, as you correctly noted, not all inter= faced
have IEEE addresses.

IN any case, this is just an idea. I personally think that would be
really cool. But I'd like you and others to comment.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.co= m
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



--------------------------------------------------------------------<= /span>
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------<= /span>
--_000_92C7633838FC40FE9CDB6C4365B67A2Fhuaweicom_-- From rja.lists@gmail.com Tue Apr 17 10:09: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 24CA911E80A1 for ; Tue, 17 Apr 2012 10:09:53 -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 RBAJjSssZNdi for ; Tue, 17 Apr 2012 10:09:52 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8801811E8074 for ; Tue, 17 Apr 2012 10:09:52 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4806171qcs.31 for ; Tue, 17 Apr 2012 10:09:51 -0700 (PDT) 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=GcjFspEyDD4YQA1F03UOt/GbVgQ7becyAFfOYDiSD7o=; b=eUO4Je2XqcbtD30NzQMpAwhg1FUl2blCSrobHltLEhgQTBCYYu65ElmVmmNKIjVdaP cnjer4xbOfipkPTfFfx9KtfFM0L6CmA7kRN75q2NVjZ9VsC0jz0VhoCeDrIhg408Prrj ginC1Y+ORXo57sFl99Pyqem2U0RxnKpOOxhmcxdNtMmPfChRXyR20sitQvB/8zSksoDn HCTJKrLOEv3kR+JetpjpDtZcmTf49QtHMjMm0zfTbj8LnD2RWFKIy42K4tyF3fUSMPe9 8Csg1uPbQr5WNXy+nnyMr7sMB6+4Zfb6jHhWfGke3ZTlYBom72dF4a/fsiF8U1s9Q38F fOXg== Received: by 10.224.100.71 with SMTP id x7mr22046002qan.92.1334682591321; Tue, 17 Apr 2012 10:09:51 -0700 (PDT) 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 bm15sm41158723qab.17.2012.04.17.10.09.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 10:09:50 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: 6MAN WG Last Call: Date: Tue, 17 Apr 2012 13:09:49 -0400 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: Tue, 17 Apr 2012 17:09:53 -0000 I support publishing this as an Experimental status RFC on the IETF track. My earlier concerns with character set considerations are resolved with the current text in Section 7.1 of this document. Yours, Ran Atkinson From sarikaya2012@gmail.com Tue Apr 17 12:23: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 B002F11E80A0 for ; Tue, 17 Apr 2012 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ehBcOI-E+SqO for ; Tue, 17 Apr 2012 12:23:37 -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 E7DC811E80BA for ; Tue, 17 Apr 2012 12:23:36 -0700 (PDT) Received: by iazz13 with SMTP id z13so11360124iaz.31 for ; Tue, 17 Apr 2012 12:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CSrekVuNGW6FBJj4yJgoTzUSnEJvu58BcfgZVOUt79M=; b=uWB0N/n3PxRUq+A6zaBSt455IJCVZ42spB6A8sQn4c9sj7xc4ICgoRZgeHeCC1Yc8H GCfNda0f6oReCKTYMqtJkS+twkOGBG7eyWtF29QN0aWEl2wCkHes4O+ZuH9O8VDsy9to zgvFpJFc8nZIRV/Dm6rpMkVAgh3q1dORKu7cIvtU4EeFn5NBa96t4HW1HEctrzVAAssW QM2CAvJhPJxoxGhseSc+9O5eQUDygY5uTsfG8Tx54ODRfi3eBMFY74e3Vv/iIVye+hoE 12xE0ySM3+S9q1FEICAdszjwos6VjZ048MHt9zPNhxlMZngK/03j3LcTak60A0cH2EIe AVlw== MIME-Version: 1.0 Received: by 10.50.203.99 with SMTP id kp3mr10743084igc.16.1334690616629; Tue, 17 Apr 2012 12:23:36 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Tue, 17 Apr 2012 12:23:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Apr 2012 14:23:36 -0500 Message-ID: Subject: Re: 6MAN WG Last Call: From: Behcet Sarikaya To: RJ Atkinson 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 Reply-To: sarikaya@ieee.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:23:37 -0000 On Tue, Apr 17, 2012 at 12:09 PM, RJ Atkinson wrote: > > I support publishing this as an Experimental status RFC > on the IETF track. +1 Behcet From bob.hinden@gmail.com Tue Apr 17 16:58: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 16C9411E80C5 for ; Tue, 17 Apr 2012 16:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 5RcO44aFmOiw for ; Tue, 17 Apr 2012 16:58:38 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6E11E8086 for ; Tue, 17 Apr 2012 16:58:38 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so5041278obb.31 for ; Tue, 17 Apr 2012 16:58:38 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=7Oq3OqaZEcGoqtVtEbIBcG21V20XRg7wM0VjIk5+txc=; b=g+rmUT051Tc14nL5z/ILyrQ9QMphgG/PTrL0OaH50buykRJ7JXy48KZ5BMNAjZb/TX arjE3Kum0/Ty2WmkOLjyrqo87IslJtIgCMvsDadUtJFqjCD93+Nc5DHzx4kAEYeY1xrY G2CeAjObk4k8qhL5IQEfcdZkLYCHWYdoYRQOFR6tbMMM/+XdWSlnJjoijnRDPLnWnDyH qqZXbeLUAe1aUIPcQurh0etc7sfupxamCNpYlFygoKrJJDIi8u7aNOfNbgtt1DZgyvtz FEIt7pjeMhLumWjrxrPGqGPY62TTfcY6o5ledaz4wud5KHke51He84zWVXI+wgF4ckY0 YtnQ== Received: by 10.60.1.7 with SMTP id 7mr116233oei.71.1334707118060; Tue, 17 Apr 2012 16:58:38 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id i6sm24919423obv.5.2012.04.17.16.58.37 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 16:58:37 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Comments on Date: Tue, 17 Apr 2012 16:58:36 -0700 Message-Id: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> To: Fernando Gont Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: IPv6 WG Mailing List , 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: Tue, 17 Apr 2012 23:58:39 -0000 Fernando, This is my personal views from reading the draft. Generally I support the idea in this draft that another type of privacy = addresses would be useful to add to IPv6. For example, to not expose = the vendor IDs in IEEE MAC addresses. I have some comments on the = internet draft. Bob ------ Introduction In the Introduction the draft mentions that the IEEE MAC based interface = identifiers don't eliminate the threat from host scanning. To justify = this the document references two documents [Gont-DEEPSEC2011] = [CPNI-IPv6]. The first is a presentation you prepared and the second is = also written by you but not publicly available (the reference says = "available on request"). I was able to find the presentation online. = It makes an argument that host scanning is possible because (in my = words) that there is structure in how Internet IDs are formed. It lists = different type of IIDs found and reported in a paper by Malone. This = paper is primarily about the observed types of address in an operational = test. It includes stats on the percentage of IPv6 address types = observed in live traffic (e.g., 50% SLACC based, 20% IPv4 based, etc.). = =20 The problem I see is that this doesn't justify the claim that there is a = problem with host scanning with MAC based interface identifiers. It = would be helpful if you could provide some data or analysis that = justifies this to quantify the risk. In my reading the references don't = do that. =20 ------- 2. Design Goals Could these types of Interface Identifiers also be generated by DHCPv6 = servers. I would think that it would be useful to generate these hard = to predict IIDs when a DHCPv6 server is providing addresses. This would = be much better than assigning them linearly that are easy to predict and = scan for. =20 That is, the same approach could be used to create IIDs for SLAAC and = DHCPv6. =20 --------- 5. Security Considerations In the second paragraph the document says=20 "We note that this algorithm is meant to replace Modified EUI-64 = format identifiers". =20 This is the first time the document says this. If it intends to do = this, it should be in the main part of the document and not first appear = in the security considerations. The document makes a clear argument why = it is preferable to MAC based IIDs, but it doesn't justify replacing = Modified EUI-64 identifiers. It's a would be a major change to the IPv6 = Address Architecture that I don't think is warranted. The algorithm in Section 3. even clears the U/L bit to be compatible = with the Modified EUI-64 IIDs. I think document may be confusing IEEE = MAC based Modified EUI-64 Interface IDs with the format defined in the = IPv6 Address Architecture that can accommodate different types of tokens = (MAC based, random number based, manual assignment, etc.) to create = IIDs. Please clarify? ------- Sections 7. I don't understand the purpose of this section. It comes after the = Acknowledgement section and before References. It reads like open = issues and says it might be removed. Is it meant as an appendix? = Perhaps rewriting it to show how addresses based on these IIDs prevent = these problems. ---- References: [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). I am not sure this will be acceptable by the RFC-Editor. There isn't = enough information to know who to ask to to get a copy. It would be = better if it was available online. From kauer@biplane.com.au Tue Apr 17 17:58: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 BF5F211E80E5 for ; Tue, 17 Apr 2012 17:58: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=[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 XZfeFi09oo0s for ; Tue, 17 Apr 2012 17:58:35 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id AC9F711E807F for ; Tue, 17 Apr 2012 17:58:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAG8Rjk+WZX+7/2dsb2JhbAANN4VmrmgBAQEEI2YLGCoCAlcGE680kl+PS4EYBKEqh3Q Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.205]) ([150.101.127.187]) by ipmail07.adl2.internode.on.net with ESMTP; 18 Apr 2012 10:28:31 +0930 Subject: Re: Comments on From: Karl Auer To: IETF IPv6 In-Reply-To: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dvYf0JCuQXfex8p4QqS8" Date: Wed, 18 Apr 2012 10:58:31 +1000 Message-ID: <1334710711.12533.128.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: Wed, 18 Apr 2012 00:58:39 -0000 --=-dvYf0JCuQXfex8p4QqS8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-04-17 at 16:58 -0700, Bob Hinden wrote: > Could these types of Interface Identifiers also be generated by DHCPv6 > servers. I would think that it would be useful to generate these hard > to predict IIDs when a DHCPv6 server is providing addresses. This > would be much better than assigning them linearly that are easy to > predict and scan for. =20 Some DHCPv6 servers may assign IPv6 addresses linearly. Industrial strength DHCPv6 servers don't (eg Nominum DCS). Linear assignment in DHCPv6 is IMHO basically a bug. If a DHCPv6 server assigns a random address to a new client, then you have everything stable addresses give you - it's not based on the hardware address, it's the same whenever you are in the same network, it's different on different networks. A DHCPv6 server that allocates addresses linearly would be better fixed not to do so, than to go to the trouble of implementing stable addresses a la Gont. The DHCPv6 model is one where the client defers to the server. While a client can request specific addresses, and so could request one it had generated using the stable address algorithm, it would still be entirely up to the server whether or not to honour that request. 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 --=-dvYf0JCuQXfex8p4QqS8 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) iF4EABEIAAYFAk+OEbAACgkQFpl7eE7uYBc6tAEAyCKf5aVojx+oyzBgJ3+OU2qZ KCfh/N5dRTapdQr3S48BAKHqU+XkcVBHmO8yL/HU89Ex1rezxLituj0fGXA6xUXq =4to/ -----END PGP SIGNATURE----- --=-dvYf0JCuQXfex8p4QqS8-- From fgont@si6networks.com Tue Apr 17 21:25: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 EC89821F8466 for ; Tue, 17 Apr 2012 21:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=1.150, 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 En+eyS7KFcvL for ; Tue, 17 Apr 2012 21:25:50 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 502EB21F8463 for ; Tue, 17 Apr 2012 21:25:49 -0700 (PDT) Received: from [2001:5c0:1000:a::257] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SKMSb-00043D-DX; Wed, 18 Apr 2012 06:25:42 +0200 Message-ID: <4F8E4236.6030601@si6networks.com> Date: Wed, 18 Apr 2012 01:25:26 -0300 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: Comments on References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <1334710711.12533.128.camel@karl> In-Reply-To: <1334710711.12533.128.camel@karl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF IPv6 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, 18 Apr 2012 04:25:51 -0000 Hi, Karl, On 04/17/2012 09:58 PM, Karl Auer wrote: > A DHCPv6 server that allocates addresses linearly would be better fixed > not to do so, than to go to the trouble of implementing stable addresses > a la Gont. Not sure what you mean. -- Having the DHCPv6 server implement draft-gont-6man-stable-privacy-addresses might be interesting such that stable addresses are leased to nodes state-lessly. > The DHCPv6 model is one where the client defers to the server. While a > client can request specific addresses, and so could request one it had > generated using the stable address algorithm, it would still be entirely > up to the server whether or not to honour that request. Exactly. Hence the DHCPv6 server could be computing the algorithm in draft-gont-6man-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 fgont@si6networks.com Tue Apr 17 21:34: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 91AD011E8076 for ; Tue, 17 Apr 2012 21:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.575, 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 bhXtTbPkqLQe for ; Tue, 17 Apr 2012 21:34:10 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6111811E8072 for ; Tue, 17 Apr 2012 21:34:10 -0700 (PDT) Received: from [2001:5c0:1000:a::257] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SKMal-00046R-Nv; Wed, 18 Apr 2012 06:34:08 +0200 Message-ID: <4F8E442D.1090700@si6networks.com> Date: Wed, 18 Apr 2012 01:33:49 -0300 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: Bob Hinden Subject: Re: Comments on References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> In-Reply-To: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List 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, 18 Apr 2012 04:34:11 -0000 Hi, Bob, Thanks so much for your feedback! Please find my responses in-line... On 04/17/2012 08:58 PM, Bob Hinden wrote: > In the Introduction the draft mentions that the IEEE MAC based > interface identifiers don't eliminate the threat from host scanning. > To justify this the document references two documents > [Gont-DEEPSEC2011] [CPNI-IPv6]. [....] > The problem I see is that this doesn't justify the claim that there > is a problem with host scanning with MAC based interface identifiers. > It would be helpful if you could provide some data or analysis that > justifies this to quantify the risk. In my reading the references > don't do that. Fair enough. I will address this in the next rev of the document. > 2. Design Goals > > Could these types of Interface Identifiers also be generated by > DHCPv6 servers. I would think that it would be useful to generate > these hard to predict IIDs when a DHCPv6 server is providing > addresses. This would be much better than assigning them linearly > that are easy to predict and scan for. > > That is, the same approach could be used to create IIDs for SLAAC and > DHCPv6. Agreed. Do you think this should be incorporated in this I-D, or that this should be addressed in a different I-D? > 5. Security Considerations > > In the second paragraph the document says > > "We note that this algorithm is meant to replace Modified EUI-64 > format identifiers". Note: What I meant here is that there are meant to be used instead of the MAC-based addresses. Based on your comment (and after re-reading the relevant specs), it seems that this para needs to be tweaked as follows: 1) s/to replace/to be an alternative to/ 2) s/Modified EUI-64 identifiers/IIDs based on IEEE identifiers/ Thoughts? > This is the first time the document says this. If it intends to do > this, it should be in the main part of the document and not first > appear in the security considerations. The document makes a clear > argument why it is preferable to MAC based IIDs, but it doesn't > justify replacing Modified EUI-64 identifiers. It's a would be a > major change to the IPv6 Address Architecture that I don't think is > warranted. I could certainly live with this document simply specifying an alternative scheme for generating addresses (without formally replacing/obsoleting any other method). However, I think it would be appropriate that we recommend (somewhere... either in this doc, in a document updating node requirements, in a future node-requirements-bis, or wherever), that a scheme such as this is RECOMMENDED over the ones embedding IEEE identifiers. > The algorithm in Section 3. even clears the U/L bit to be compatible > with the Modified EUI-64 IIDs. I think document may be confusing > IEEE MAC based Modified EUI-64 Interface IDs with the format defined > in the IPv6 Address Architecture that can accommodate different types > of tokens (MAC based, random number based, manual assignment, etc.) > to create IIDs. > > Please clarify? You're right. Throughout the document, most references to "Modified EUI-64 identifiers" really mean "IEEE-derived IIDs". That said, documents such as "Transmission of IPv6 Packets over Ethernet Networks" mandate the generation of Modified-EUI-64 format identifiers from IEEE identifiers. So I'm not sure what the right approach (specs-wise) would be. e.g., formally update RFC 4291, noting that besides what's in the "Transmission of IPv6 Packets over XXX" documents, IIDs can be generated as specified in draft-gont-6man-stable-privacy-addresses, or something else? > Sections 7. > > I don't understand the purpose of this section. This Section was essentially added to address the comments during my presentation of this document at the Paris IETF (e.g., that RFC4941 address, by themselves, the problem of host-tracking). > It comes after the > Acknowledgement section and before References. It reads like open > issues and says it might be removed. Is it meant as an appendix? Yes. I realized of the wrong placement of this section *after* submitting it, and hence this shows up as Section 7 rather than as an Appendix. -- I've already fixed this in my working copy of the I-D, and hence this will appear as an Appendix in the next rev. > Perhaps rewriting it to show how addresses based on these IIDs > prevent these problems. FWIW, this section tries to show that if you implement RFC4941 while still implementing the MAC-based addresses, both host-scanning attacks and host-tracking remain possible. > References: > > [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol > version 6 (IPv6)", UK Centre for the Protection of National > Infrastructure, (available on request). > > I am not sure this will be acceptable by the RFC-Editor. There > isn't enough information to know who to ask to to get a copy. It > would be better if it was available online. I'm working to make this happen. 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 zhou.sujing@zte.com.cn Tue Apr 17 22:03: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 2D76721F85A4; Tue, 17 Apr 2012 22:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.789 X-Spam-Level: X-Spam-Status: No, score=-94.789 tagged_above=-999 required=5 tests=[AWL=-1.999, 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 0xPUCObn6esx; Tue, 17 Apr 2012 22:03:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7F96E21F8484; Tue, 17 Apr 2012 22:03:03 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286202306338276; Wed, 18 Apr 2012 12:24:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 53047.3804161470; Wed, 18 Apr 2012 13:02:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3I52eWr092144; Wed, 18 Apr 2012 13:02:40 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4F8E4236.6030601@si6networks.com> To: Fernando Gont Subject: =?GB2312?B?tPC4tDogUmU6IENvbW1lbnRzIG9uIDxkcmFmdC1nb250LTZtYW4tc3RhYmxl?= =?GB2312?B?LXByaXZhY3ktYWRkcmVzc2VzLTAxPg==?= 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, 18 Apr 2012 13:02:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-18 13:02:42, Serialize complete at 2012-04-18 13:02:42 Content-Type: multipart/alternative; boundary="=_alternative 001BBC87482579E4_=" X-MAIL: mse02.zte.com.cn q3I52eWr092144 Cc: ipv6-bounces@ietf.org, IETF IPv6 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, 18 Apr 2012 05:03:12 -0000 This is a multipart message in MIME format. --=_alternative 001BBC87482579E4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KaXB2Ni1ib3VuY2VzQGlldGYub3JnINC009og MjAxMi0wNC0xOCAxMjoyNToyNjoNCg0KPiBIaSwgS2FybCwNCj4gDQo+IE9uIDA0LzE3LzIwMTIg MDk6NTggUE0sIEthcmwgQXVlciB3cm90ZToNCj4gPiBBIERIQ1B2NiBzZXJ2ZXIgdGhhdCBhbGxv Y2F0ZXMgYWRkcmVzc2VzIGxpbmVhcmx5IHdvdWxkIGJlIGJldHRlciANCmZpeGVkDQo+ID4gbm90 IHRvIGRvIHNvLCB0aGFuIHRvIGdvIHRvIHRoZSB0cm91YmxlIG9mIGltcGxlbWVudGluZyBzdGFi bGUgDQphZGRyZXNzZXMNCj4gPiBhIGxhIEdvbnQuDQo+IA0KPiBOb3Qgc3VyZSB3aGF0IHlvdSBt ZWFuLiAtLSBIYXZpbmcgdGhlIERIQ1B2NiBzZXJ2ZXIgaW1wbGVtZW50DQo+IGRyYWZ0LWdvbnQt Nm1hbi1zdGFibGUtcHJpdmFjeS1hZGRyZXNzZXMgbWlnaHQgYmUgaW50ZXJlc3Rpbmcgc3VjaCB0 aGF0DQo+IHN0YWJsZSBhZGRyZXNzZXMgYXJlIGxlYXNlZCB0byBub2RlcyBzdGF0ZS1sZXNzbHku DQo+IA0KDQpXaWxsIHRoZSBESENQIHNlcnZlciB1c2UgdGhlIHNhbWUgc2VjcmV0IGtleSBpbiBj b21wdXRhdGlvbiBvZiBzbyBtYW55IA0KcmFuZG9tIGludGVyZmFjZSBpZGVudGlmaWVycz8NCklm IHNvLCB0aGUgY29tcHV0YXRpb24gb2YgUklEIG1heSBuZWVkIHRvIGJlIG1vZGlmaWVkLCBiZWNh dXNlIHRoZXJlIGlzIA0KbGl0dGxlIGxlZnQgdG8gdHdlYWsgKHRoZSBvbmx5IGRpZmZlcmVuY2Ug YmV0d2VlbiANCmNsaWVudHMgaXMgTW9kaWZpZWRfRVVJNjQpIGluIGNhc2UgYWRkcmVzcyBjb2xs aXNpb24gb2NjdXJzLg0KYW5kIGhhdmUgeW91IGV2ZXIgdGhvdWdodCBvZiByZWZyZXNoaW5nIHRo ZSBzZWNyZXQga2V5IGluIFNMQUFDPw0K --=_alternative 001BBC87482579E4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5pcHY2LWJv dW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTA0LTE4IDEyOjI1OjI2Ojxicj4NCjxicj4NCiZndDsg SGksIEthcmwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDA0LzE3LzIwMTIgMDk6NTggUE0sIEth cmwgQXVlciB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgQSBESENQdjYgc2VydmVyIHRoYXQgYWxsb2Nh dGVzIGFkZHJlc3NlcyBsaW5lYXJseSB3b3VsZCBiZSBiZXR0ZXINCmZpeGVkPGJyPg0KJmd0OyAm Z3Q7IG5vdCB0byBkbyBzbywgdGhhbiB0byBnbyB0byB0aGUgdHJvdWJsZSBvZiBpbXBsZW1lbnRp bmcgc3RhYmxlDQphZGRyZXNzZXM8YnI+DQomZ3Q7ICZndDsgYSBsYSBHb250Ljxicj4NCiZndDsg PGJyPg0KJmd0OyBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuLiAtLSBIYXZpbmcgdGhlIERIQ1B2NiBz ZXJ2ZXIgaW1wbGVtZW50PGJyPg0KJmd0OyBkcmFmdC1nb250LTZtYW4tc3RhYmxlLXByaXZhY3kt YWRkcmVzc2VzIG1pZ2h0IGJlIGludGVyZXN0aW5nIHN1Y2gNCnRoYXQ8YnI+DQomZ3Q7IHN0YWJs ZSBhZGRyZXNzZXMgYXJlIGxlYXNlZCB0byBub2RlcyBzdGF0ZS1sZXNzbHkuPGJyPg0KJmd0OyA8 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPldpbGwgdGhlIERIQ1Agc2Vy dmVyIHVzZSB0aGUgc2FtZSBzZWNyZXQga2V5IGluIGNvbXB1dGF0aW9uDQpvZiBzbyBtYW55ICZu YnNwO3JhbmRvbSBpbnRlcmZhY2UgaWRlbnRpZmllcnM/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5JZiBzbywgdGhlIGNvbXB1dGF0aW9uIG9mIFJJRCBtYXkgbmVlZCB0byBiZSBt b2RpZmllZCwNCmJlY2F1c2UgdGhlcmUgaXMgbGl0dGxlIGxlZnQgdG8gdHdlYWsgKHRoZSBvbmx5 IGRpZmZlcmVuY2UgYmV0d2VlbiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmNs aWVudHMgaXMgTW9kaWZpZWRfRVVJNjQpIGluIGNhc2UgYWRkcmVzcyBjb2xsaXNpb24NCm9jY3Vy cy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmFuZCBoYXZlIHlvdSBldmVyIHRo b3VnaHQgb2YgcmVmcmVzaGluZyB0aGUgc2VjcmV0DQprZXkgaW4gU0xBQUM/PC9mb250PjwvdHQ+ DQo= --=_alternative 001BBC87482579E4_=-- From fgont@si6networks.com Wed Apr 18 00: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 9C6D521F8546; Wed, 18 Apr 2012 00:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=-3.264, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345] 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 7E6v-PUt+Hcm; Wed, 18 Apr 2012 00:18:37 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 19ACB21F84B9; Wed, 18 Apr 2012 00:18:37 -0700 (PDT) Received: from [2001:5c0:1000:a::325] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SKP9k-000557-6c; Wed, 18 Apr 2012 09:18:25 +0200 Message-ID: <4F8E6AB2.8030909@si6networks.com> Date: Wed, 18 Apr 2012 04:18:10 -0300 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: zhou.sujing@zte.com.cn Subject: Re: =?GB2312?B?tPC4tDogUmU6IENvbW1lbnRzIG9uIDxkcmFmdC1nb250LTZtYQ==?= =?GB2312?B?bi1zdGFibGUtcHJpdmFjeS1hZGRyZXNzZXMtMDE+?= References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: ipv6-bounces@ietf.org, IETF IPv6 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, 18 Apr 2012 07:18:37 -0000 Hi, Zhou, Please find my comments in-line... On 04/18/2012 02:02 AM, zhou.sujing@zte.com.cn wrote: >> Not sure what you mean. -- Having the DHCPv6 server implement >> draft-gont-6man-stable-privacy-addresses might be interesting such that >> stable addresses are leased to nodes state-lessly. > > Will the DHCP server use the same secret key in computation of so many > random interface identifiers? Yes. Note that F() should be cryptographically secure. And hence even if the server had to compute say 1000 addresses, that wouldn't be an issue. > If so, the computation of RID may need to be modified, As already noted on this thread, we might include a "retry" variable in the hash (initialized to 0, but incremented by 1 each time DAD fails), to be used to compute a new RID if DAD fails. In any case, no matter how many the devices, were talking about 2**64 addresses here -- so you'd have to be very unlucky for DAD to fail. :-) > because there is > little left to tweak (the only difference between > clients is Modified_EUI64) in case address collision occurs. In the case of using this algorithm with DHCPv6, I guess the UID would be used instead of Modified_EUI64. > and have you ever thought of refreshing the secret key in SLAAC? If you refresh the secret key, you get a whole new set of addresses. My take is that only in very rare circumstances you'd want to do this. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jonghyouk@gmail.com Wed Apr 18 02:26: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 3F85D21F85BB for ; Wed, 18 Apr 2012 02:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 6-8dQU1f03k8 for ; Wed, 18 Apr 2012 02:25: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 DD6BE21F85B7 for ; Wed, 18 Apr 2012 02:25:57 -0700 (PDT) Received: by iazz13 with SMTP id z13so12413717iaz.31 for ; Wed, 18 Apr 2012 02:25:57 -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=f3xL1kTwIXL8T9QgiNuuwCluM/009JhiexmbgOfO6ds=; b=SHx3VvmYb5Wai8TWZL8Bne8hzfGGO3uklQOP9Yhu9ceIz0rpIBZYsoulK1Ctf06Zbk vN4ByHV4MH0/7+TcjZxPPVR/HUm79PZCY5LBkl6rLjhNwRUzwm1yK0wuI/IOw4DMG4kU g/jyQYrzgeF39yA95AKTEE8dgdjbNriE31vJpCbBL7PoGHnpRfskbMZoAmQAvUyREJKN ldluRsPPcx0Uk6wGAAm/tAIoeSZDQB1LkJD6MMyHuU/iEIJJmX/LXGXy5nH0k9e4GKnq WMPMO3027dRuNziDYZ5PxgYQ2xHfEnb/E8ePSQQGgiUmgUcXWvQJEz/dGqTDNcARYjen r9TQ== MIME-Version: 1.0 Received: by 10.50.45.231 with SMTP id q7mr1031277igm.42.1334741157555; Wed, 18 Apr 2012 02:25:57 -0700 (PDT) Received: by 10.64.32.72 with HTTP; Wed, 18 Apr 2012 02:25:57 -0700 (PDT) In-Reply-To: <4F881FFF.5030409@si6networks.com> References: <4F87D245.4000102@gmail.com> <95F65935-A316-4CFB-9A79-9B0AB7E33A10@ecs.soton.ac.uk> <4F881FFF.5030409@si6networks.com> Date: Wed, 18 Apr 2012 11:25:57 +0200 Message-ID: Subject: Re: Consensus call on adopting: From: Jong-Hyouk Lee To: Fernando Gont Content-Type: multipart/alternative; boundary=14dae9340621902c5704bdf0a42a Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List 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, 18 Apr 2012 09:26:02 -0000 --14dae9340621902c5704bdf0a42a Content-Type: text/plain; charset=UTF-8 Dear all, I support this document to be an official working group document. IPv6 is being considered to be a protocol providing Internet access from vehicles. When we consider vehicular communications, location privacy becomes vital. The described mechanism "stable-privacy-addresses" would help for it. Cheers. On Fri, Apr 13, 2012 at 2:45 PM, Fernando Gont wrote: > Hi, Tim, > > Thanks so much for your feedback! Please find my comments inline... > > On 04/13/2012 12:37 PM, Tim Chown wrote: > > Extensions. If I understand it correctly, essentially what you are > > defining is randomised stable-per-prefix public interface > > identifiers, > > Exactly. > > > > On 3484bis, if stable privacy addresses are alternative public (not > > temporary) identifiers for hosts then is there anything more to say? > > Not that I can think of. > > > > Note that RFC4941 temporary addresses can also be stable, in that > > they do not change if the host stays on the same network; the > > specification only says identifiers SHOULD be regenerated at some > > defined interval. > > Two things: > > * If you do RFC 4941 but do not change the addresses over time (e.g. as > Windows does for their stable addresses), then you can be tracked > exactly in the same way as with MAC-based addresses. Such addreseses > mitigate only host-scanning attacks (i.e., they are unpredictable), but > since there's a constant identifier used across networks, tracking is > still possible. -- So at the time you implement RFC 4941 without > regenerating the addresses over time, they are not *privacy* extensions > anymore :-) > > * IMO, it is a bit of a strech to say "RFC4941 temporary addresses can > also be stable", implying that stability is allowed. That would be the > case if "identifiers MAY be generated at some defined interval". But if > it's a SHOULD, and you go against it, you're not fully-compliant with > the specification. ("SHOULD" just means that there are specific cases in > which you're allowed to not follow the recommendation). > > > > > Finally, it would be interesting to know what algorithm Windows uses > > to generate its identifiers; they are randomised, public and stable. > > I had thought they were based on the prefix, but Fernando's tests > > suggest not. > > Dave Thaler commented on this one during the 6man wg meeting at IETF 83: > They do RFC4941, without changing the addresses over time. Hence, the > identifiers are constant across networks. > > This means that they mitigate host scanning attacks, but as noted in > draft-gont-6man-stable-privacy-addresses-01 they are still subject to > host-tracking. > > Thanks! > > Best regards, > -- > 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/ --14dae9340621902c5704bdf0a42a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

I support this document to be an official work= ing group document.=C2=A0

IPv6 is being considered= to be a protocol providing Internet access from vehicles. When we consider= vehicular communications, location privacy becomes vital. The described me= chanism "stable-privacy-addresses"= would help for it.

Cheers.
On Fri, Apr 13, 2012 at 2:45 PM, Fernando Gont = <fgont@si6net= works.com> wrote:
Hi, Tim,

Thanks so much for your feedback! Please find my comments inline...

On 04/13/2012 12:37 PM, Tim Chown wrote:
> Extensions. =C2=A0If I understand it correctly, essentially what you a= re
> defining is randomised stable-per-prefix public interface
> identifiers,

Exactly.


> On 3484bis, if stable privacy addresses are alternative public (not > temporary) identifiers for hosts then is there anything more to say?
Not that I can think of.


> Note that RFC4941 temporary addresses can also be stable, in that
> they do not change if the host stays on the same network; the
> specification only says identifiers SHOULD be regenerated at some
> defined interval.

Two things:

* If you do RFC 4941 but do not change the addresses over time (e.g. as
Windows does for their stable addresses), then you can be tracked
exactly in the same way as with MAC-based addresses. Such addreseses
mitigate only host-scanning attacks (i.e., they are unpredictable), but
since there's a constant identifier used across networks, tracking is still possible. -- So at the time you implement RFC 4941 without
regenerating the addresses over time, they are not *privacy* extensions
anymore :-)

* IMO, it is a bit of a strech to say "RFC4941 temporary addresses can=
also be stable", implying that stability is allowed. That would be the=
case if "identifiers MAY be generated at some defined interval". = But if
it's a SHOULD, and you go against it, you're not fully-compliant wi= th
the specification. ("SHOULD" just means that there are specific c= ases in
which you're allowed to not follow the recommendation).



> Finally, it would be interesting to know what algorithm Windows uses > to generate its identifiers; they are randomised, public and stable. > I had thought they were based on the prefix, but Fernando's tests<= br> > suggest not.

Dave Thaler commented on this one during the 6man wg meeting at IETF = 83:
They do RFC4941, without changing the addresses over time. Hence, the
identifiers are constant across networks.

This means that they mitigate host scanning attacks, but as noted in
draft-gont-6man-stable-privacy-addresses-01 they are still subject to
host-tracking.

Thanks!

Best regards,
--
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

--14dae9340621902c5704bdf0a42a-- From lear@cisco.com Wed Apr 18 02: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 C915F21F85DF for ; Wed, 18 Apr 2012 02:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.55 X-Spam-Level: X-Spam-Status: No, score=-110.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 5j3hF3But-Gy for ; Wed, 18 Apr 2012 02:38:08 -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 5BE9321F8566 for ; Wed, 18 Apr 2012 02:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1812; q=dns/txt; s=iport; t=1334741888; x=1335951488; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=YOR3iTBcTCuuwBc+FbMHhaD+1mZR5tExADvdbi5wMpo=; b=Xh9vVp4oNCIP/04y5b9OZ/b7RwA8Gg50+WJ+E4QuuYaGcAuXNztCXTvw EkCU9KpwTmQciJl+JdQ0cFT7FlpS9l09ZjkXvlcFvol0cBYDDG19RB+la x/RW76sJEzxDUKlgm0mfdE9OYtXuAJo58kx5PP7ekzAcMITtYx7Tg36xq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPeKjk+Q/khN/2dsb2JhbABEhWaoQoMVgQeCCQEBAQQSARBVARALDgoCAgUWCwICCQMCAQIBRQYNAQcBAR6HbZlljRCTFIEvjiGBGASVb45QgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="135504857" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2012 09:37:58 +0000 Received: from ams3-vpn-dhcp4471.cisco.com (ams3-vpn-dhcp4471.cisco.com [10.61.81.118]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3I9bv6L003564; Wed, 18 Apr 2012 09:37:58 GMT Message-ID: <4F8E8B75.4030605@cisco.com> Date: Wed, 18 Apr 2012 11:37:57 +0200 From: Eliot Lear 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: Fernando Gont Subject: Re: Consensus call on adopting: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> In-Reply-To: <4F881C9A.3050908@si6networks.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , 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: Wed, 18 Apr 2012 09:38:12 -0000 Dear Fernando, My apologies for the delayed response: On 4/13/12 2:31 PM, Fernando Gont wrote: > hI, Eliot, > > On 04/13/2012 10:09 AM, Eliot Lear wrote: >> At one point you write that the intent is to replace EUI-64-based >> addresses (Section 5). > Exactly. > > >> But that doesn't seem to jibe with what you >> write in the intro about RFC-4941. > Could you please cite the "conflicting" text? Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where you're quoting): > As noted in [RFC4941], "anytime a fixed identifier is used in > multiple contexts, it becomes possible to correlate seemingly > unrelated activity using this identifier". Therefore, since > "privacy addresses" [RFC4941] do not eliminate the use of fixed > identifiers for server-like functions, they only *partially* > mitigate the correlation of host activities (see Section 7 for > some example attacks that are still possible with privacy > addresses). Therefore, it is vital that the privacy And so on. In essence you set up an argument against 4941 but that isn't really your argument for the draft and so I don't really know what it's doing there. But perhaps that's not as important as this: > > >> I am concerned that adopting this >> mechanism will make matters worse if this mechanism is being used as an >> alternative to CGAs, as opposed to EUI-64s.. > I don't follow. Could you clarify your concern? You argue that this is an alternative to EUI-64s. But in practice I am concerned that people will not use this as an alternative to EUI-64s, but instead as an alternative to CGAs, thus improving tracibility (not generally a good thing). Please explain what I'm missing (I'm sure it's a lot). Eliot From fgont@si6networks.com Wed Apr 18 08:44: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 D259721F85B5 for ; Wed, 18 Apr 2012 08:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=1.199, 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 K65qUxQXsXl4 for ; Wed, 18 Apr 2012 08:44:01 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 98EF521F8589 for ; Wed, 18 Apr 2012 08:44:00 -0700 (PDT) Received: from [2001:5c0:1000:a::195] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SKX2t-0000ds-Bs; Wed, 18 Apr 2012 17:43:51 +0200 Message-ID: <4F8EE130.8070903@si6networks.com> Date: Wed, 18 Apr 2012 12:43:44 -0300 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: Eliot Lear Subject: Re: Consensus call on adopting: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> In-Reply-To: <4F8E8B75.4030605@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , 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: Wed, 18 Apr 2012 15:44:01 -0000 Hi, Eliot, On 04/18/2012 06:37 AM, Eliot Lear wrote: >> On 04/13/2012 10:09 AM, Eliot Lear wrote: >>> At one point you write that the intent is to replace EUI-64-based >>> addresses (Section 5). >> Exactly. [Correcting myself] The intent is to have draft-gont-6man-stable-privacy-addresses used instead of the IIDs that embed IEEE identifiers. > Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where > you're quoting): >> As noted in [RFC4941], "anytime a fixed identifier is used in >> multiple contexts, it becomes possible to correlate seemingly >> unrelated activity using this identifier". Therefore, since >> "privacy addresses" [RFC4941] do not eliminate the use of fixed >> identifiers for server-like functions, they only *partially* >> mitigate the correlation of host activities (see Section 7 for >> some example attacks that are still possible with privacy >> addresses). Therefore, it is vital that the privacy > > And so on. In essence you set up an argument against 4941 but that > isn't really your argument for the draft and so I don't really know what > it's doing there. It's not an argument against RFc4941, but rather an argument that even with RFC4941, you still need to do something about the IEEE-based IIDs. At the Paris IETF, some folks argued that if you have RFC 4941 in place, you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of draft-gont-6man-stable-privacy-addresses (which should be an Appendix, rather than a section in the main body of the document) illustrates that that's not the case: even if you're employing RFC4941, you're still subject to host-scanning attacks and host tracking. It is *not* an argument *against* RFC 4941, since it *is* valuable to have addresses that change over time for outging communications. >But perhaps that's not as important as this: > >>> I am concerned that adopting this >>> mechanism will make matters worse if this mechanism is being used as an >>> alternative to CGAs, as opposed to EUI-64s.. >> I don't follow. Could you clarify your concern? > > You argue that this is an alternative to EUI-64s. Let me correct myself: this is an alternative to IIDs that embed IEEE identifiers: The modified EUI-64 format is a general format, and it does not need to embed IEEE identifiers (for instance, RFC4941 produce Mod-EUI-64 format identifiers, bu clearly do not embed IEEE identifiers). > But in practice I am > concerned that people will not use this as an alternative to EUI-64s, > but instead as an alternative to CGAs, Why? I don't really follow the relationship of draft-gont-6man-stable-privacy-addresses with CGAs. CGAs are used for SEND, and are not even mentioned in this I-D. How do you arrive to the conclusion that people might want to use this instead of CGAs?? As noted in the I-D tihs mechanism is meant to be a replacement for IIDs based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal to CGAs. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bob.hinden@gmail.com Wed Apr 18 13:55:48 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 0A43711E80C0 for ; Wed, 18 Apr 2012 13:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, 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 v2PZPqA1+LdY for ; Wed, 18 Apr 2012 13:55:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4935E11E80AF for ; Wed, 18 Apr 2012 13:55:38 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so6555192obb.31 for ; Wed, 18 Apr 2012 13:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/LZ1XvkA6w7E//nzZ4kDC0+7FuBmW6tMDG+p1ml+im0=; b=YEQVcMIoG6pw6W5lUoK/4QyR1PVbFEb3ihyJLtg5RMV5PSXgF6WQEbvAFuifEYuzP0 Rp0iBdILL/Sx61IbU6LI7Ns1ijMACt33M+1+HypWdPrFOwW8jxRZ/GcS5mRDqPGjDaoK fqQxfmSfETg1F0vVeQEzkZG6c/lKPmWhOorCe9xdcfqpHitvSHvy/se01+GRYvuMFOpz r8SwrpfDckJxsKVM3oXj08oL9pqZY8lrIJnk1OSiwK7lAC6FW/gZdlQruAI+kiwI2tUq 4j9dgy2g9qWpTaDolBR/CrA3KrL87mdND9dBJ2pXphsIx/j6BiMHRnQ+A6KASMGyyqOk OJhA== Received: by 10.182.169.68 with SMTP id ac4mr5257297obc.19.1334782537891; Wed, 18 Apr 2012 13:55:37 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id k2sm44395obl.14.2012.04.18.13.55.35 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 13:55:36 -0700 (PDT) Subject: Re: Comments on Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4F8E442D.1090700@si6networks.com> Date: Wed, 18 Apr 2012 13:55:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: IPv6 WG Mailing List , 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: Wed, 18 Apr 2012 20:55:48 -0000 Fernando, On Apr 17, 2012, at 9:33 PM, Fernando Gont wrote: > Hi, Bob, >=20 > Thanks so much for your feedback! Please find my responses in-line... >=20 > On 04/17/2012 08:58 PM, Bob Hinden wrote: >> In the Introduction the draft mentions that the IEEE MAC based >> interface identifiers don't eliminate the threat from host scanning. >> To justify this the document references two documents >> [Gont-DEEPSEC2011] [CPNI-IPv6]. > [....] >> The problem I see is that this doesn't justify the claim that there >> is a problem with host scanning with MAC based interface identifiers. >> It would be helpful if you could provide some data or analysis that >> justifies this to quantify the risk. In my reading the references >> don't do that. >=20 > Fair enough. I will address this in the next rev of the document. This is an area I would like to know more about, and it would be good to = quantify the problem. =20 Off the top of my head, if an attacker knew the subnet prefix, it could = guess a company_id, it would have to scan ~17M (2^24) addresses per = company_id. That would only result in finding the devices using that = company_id. This would have to be repeated many times to find even the = majority of devices on a single subnet. This is clearly easier than = having to scan 2^64 addresses in a single subnet, but still considerably = harder than than a /24 IPv6 subnet. >=20 >> 2. Design Goals >>=20 >> Could these types of Interface Identifiers also be generated by >> DHCPv6 servers. I would think that it would be useful to generate >> these hard to predict IIDs when a DHCPv6 server is providing >> addresses. This would be much better than assigning them linearly >> that are easy to predict and scan for. >>=20 >> That is, the same approach could be used to create IIDs for SLAAC and >> DHCPv6. >=20 > Agreed. Do you think this should be incorporated in this I-D, or that > this should be addressed in a different I-D? Not sure. If the algorithm could be the same, then it would make sense = to include both use cases (SLACC and DHCPv6). >=20 >=20 >=20 >> 5. Security Considerations >>=20 >> In the second paragraph the document says >>=20 >> "We note that this algorithm is meant to replace Modified EUI-64 >> format identifiers". >=20 > Note: What I meant here is that there are meant to be used instead of > the MAC-based addresses. Based on your comment (and after re-reading = the > relevant specs), it seems that this para needs to be tweaked as = follows: >=20 > 1) s/to replace/to be an alternative to/ > 2) s/Modified EUI-64 identifiers/IIDs based on IEEE identifiers/ I think for now, I suggest an alternative approach. =20 This should be stated earlier in the document too. >=20 > Thoughts? >=20 >=20 >=20 >> This is the first time the document says this. If it intends to do >> this, it should be in the main part of the document and not first >> appear in the security considerations. The document makes a clear >> argument why it is preferable to MAC based IIDs, but it doesn't >> justify replacing Modified EUI-64 identifiers. It's a would be a >> major change to the IPv6 Address Architecture that I don't think is >> warranted. >=20 > I could certainly live with this document simply specifying an > alternative scheme for generating addresses (without formally > replacing/obsoleting any other method). However, I think it would be > appropriate that we recommend (somewhere... either in this doc, in a > document updating node requirements, in a future = node-requirements-bis, > or wherever), that a scheme such as this is RECOMMENDED over the ones > embedding IEEE identifiers. I think there are some tradeoff here that we are discussing. We may = need some more experience before making a decision. In the short term = pushing for a compete change might well be perceived as a disruptive = change to IPv6 deployment. A good starting point is defining them as an = alternative. >=20 >=20 >> The algorithm in Section 3. even clears the U/L bit to be compatible >> with the Modified EUI-64 IIDs. I think document may be confusing >> IEEE MAC based Modified EUI-64 Interface IDs with the format defined >> in the IPv6 Address Architecture that can accommodate different types >> of tokens (MAC based, random number based, manual assignment, etc.) >> to create IIDs. >>=20 >> Please clarify? >=20 > You're right. Throughout the document, most references to "Modified > EUI-64 identifiers" really mean "IEEE-derived IIDs". Thanks, as I suspected. > That said, documents such as "Transmission of IPv6 Packets over = Ethernet > Networks" mandate the generation of Modified-EUI-64 format identifiers > from IEEE identifiers. So I'm not sure what the right approach > (specs-wise) would be. e.g., formally update RFC 4291, noting that > besides what's in the "Transmission of IPv6 Packets over XXX" = documents, > IIDs can be generated as specified in > draft-gont-6man-stable-privacy-addresses, or something else? I suggest looking at RFC4941 Privacy Extentions as the model. That = created the privacy IIDs without having update any other documents. I = think the IPv6 Address Architecture supports a range of Interface IDs = and this draft fall under that. For example, the IPv6 over = documents, don't keep people from using manually configured addresses, = privacy addresses, etc. =20 >=20 >=20 >=20 >> Sections 7. >>=20 >> I don't understand the purpose of this section. =20 >=20 > This Section was essentially added to address the comments during my > presentation of this document at the Paris IETF (e.g., that RFC4941 > address, by themselves, the problem of host-tracking). >=20 >=20 >=20 >> It comes after the >> Acknowledgement section and before References. It reads like open >> issues and says it might be removed. Is it meant as an appendix? >=20 > Yes. I realized of the wrong placement of this section *after* > submitting it, and hence this shows up as Section 7 rather than as an > Appendix. -- I've already fixed this in my working copy of the I-D, = and > hence this will appear as an Appendix in the next rev. Sounds good. >=20 >=20 >> Perhaps rewriting it to show how addresses based on these IIDs >> prevent these problems. >=20 > FWIW, this section tries to show that if you implement RFC4941 while > still implementing the MAC-based addresses, both host-scanning attacks > and host-tracking remain possible. >=20 >=20 >> References: >>=20 >> [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol=20= >> version 6 (IPv6)", UK Centre for the Protection of National >> Infrastructure, (available on request). >>=20 >> I am not sure this will be acceptable by the RFC-Editor. There >> isn't enough information to know who to ask to to get a copy. It >> would be better if it was available online. >=20 > I'm working to make this happen. Cool! Thanks, Bob >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 From lear@cisco.com Thu Apr 19 06:34: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 08C3421F862A for ; Thu, 19 Apr 2012 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 BiQjv3dVBlWa for ; Thu, 19 Apr 2012 06:34:33 -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 6A07821F861A for ; Thu, 19 Apr 2012 06:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=3468; q=dns/txt; s=iport; t=1334842473; x=1336052073; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=25iARqD+7lB5SeUDEgPJFp2VnJV50LSUEaoCL6uaGwg=; b=GO5ddtVDACFO2e4rQJ0XeAqntjr3Rt2w1OiEc/xhHSPMqRrpYrGxz1Gd /YTVlVdQwtvUl5rGtwz6Y95C7T4EWrk4SHSYOVdpT8Hwo8Y3rqqe5Hw0W 2pHO4YUHeWFIhL8NFljaAUEBqqkwMzqTMK0dhql5pp1hgbkp3TBoyrVPz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAC4TkE+Q/khN/2dsb2JhbABDhWWoRoMWgQeCCQEBAQMBEgEQTwYBEAsOCgICBRYLAgIJAwIBAgFFBg0BBwEBHodoBZotjRCTMIEvjXaBGASVb45SgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="71281000" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 19 Apr 2012 13:34:30 +0000 Received: from ams3-vpn-dhcp4371.cisco.com (ams3-vpn-dhcp4371.cisco.com [10.61.81.18]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3JDYUsr001963; Thu, 19 Apr 2012 13:34:30 GMT Message-ID: <4F901471.3070802@cisco.com> Date: Thu, 19 Apr 2012 15:34:41 +0200 From: Eliot Lear 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: Fernando Gont Subject: Re: Consensus call on adopting: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> In-Reply-To: <4F8EE130.8070903@si6networks.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , 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: Thu, 19 Apr 2012 13:34:38 -0000 On 4/18/12 5:43 PM, Fernando Gont wrote: > Hi, Eliot, > > On 04/18/2012 06:37 AM, Eliot Lear wrote: >>> On 04/13/2012 10:09 AM, Eliot Lear wrote: >>>> At one point you write that the intent is to replace EUI-64-based >>>> addresses (Section 5). >>> Exactly. > [Correcting myself] > > The intent is to have draft-gont-6man-stable-privacy-addresses used > instead of the IIDs that embed IEEE identifiers. > > > >> Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where >> you're quoting): >>> As noted in [RFC4941], "anytime a fixed identifier is used in >>> multiple contexts, it becomes possible to correlate seemingly >>> unrelated activity using this identifier". Therefore, since >>> "privacy addresses" [RFC4941] do not eliminate the use of fixed >>> identifiers for server-like functions, they only *partially* >>> mitigate the correlation of host activities (see Section 7 for >>> some example attacks that are still possible with privacy >>> addresses). Therefore, it is vital that the privacy >> And so on. In essence you set up an argument against 4941 but that >> isn't really your argument for the draft and so I don't really know what >> it's doing there. > It's not an argument against RFc4941, but rather an argument that even > with RFC4941, you still need to do something about the IEEE-based IIDs. > At the Paris IETF, some folks argued that if you have RFC 4941 in place, > you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of > draft-gont-6man-stable-privacy-addresses (which should be an Appendix, > rather than a section in the main body of the document) illustrates that > that's not the case: even if you're employing RFC4941, you're still > subject to host-scanning attacks and host tracking. Well, host scanning at least. Host tracking depends on the implementation. > > It is *not* an argument *against* RFC 4941, since it *is* valuable to > have addresses that change over time for outging communications. > > > >> But perhaps that's not as important as this: >> >>>> I am concerned that adopting this >>>> mechanism will make matters worse if this mechanism is being used as an >>>> alternative to CGAs, as opposed to EUI-64s.. >>> I don't follow. Could you clarify your concern? >> You argue that this is an alternative to EUI-64s. > Let me correct myself: this is an alternative to IIDs that embed IEEE > identifiers: The modified EUI-64 format is a general format, and it does > not need to embed IEEE identifiers (for instance, RFC4941 produce > Mod-EUI-64 format identifiers, bu clearly do not embed IEEE identifiers). > > >> But in practice I am >> concerned that people will not use this as an alternative to EUI-64s, >> but instead as an alternative to CGAs, > Why? > > I don't really follow the relationship of > draft-gont-6man-stable-privacy-addresses with CGAs. CGAs are used for > SEND, and are not even mentioned in this I-D. > > How do you arrive to the conclusion that people might want to use this > instead of CGAs?? > > As noted in the I-D tihs mechanism is meant to be a replacement for IIDs > based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal > to CGAs. I know what you mean. That matters less than how other people make use of the work. Believe me I know. I've got my name on RFC-1918, for crying out loud. Eliot From bob.hinden@gmail.com Thu Apr 19 08:40: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 11B5421F86C1 for ; Thu, 19 Apr 2012 08:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Z=0.259, 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 nL6Zyi3ca1YP for ; Thu, 19 Apr 2012 08:40:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F105C21F86BA for ; Thu, 19 Apr 2012 08:40:03 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so7895432obb.31 for ; Thu, 19 Apr 2012 08:40:03 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=5DNJhqmfPip6QfhqFJFQbViUihkyskHCGrGzFpbdMxM=; b=h7u1GlFMdbu3s8KxZCUdSTGnJMKWMLHjmhHjOmC4fN1ZS8v6MToP5s+qmPHPVwD+yw 5YSH5MgaZ/z9Jx44CKQuElJVSyNg+Hjs4fmSuqHqCSYZfxKLAEFQ7gSsdL+sHTIkzfXC SAJF7L+RvM8LIqDyTbTs04VvIG21p/4Ehc8zd1o2r1QrwQa/4krnYZayKHxfh9Y8CEk9 SAG7SgbFs7zppGDAXqoh/GmKpNGK5qNZ4oVAahDM97GcgQHlnae7a0zU6lkdFAAOix9u ZAXCZZLUzeza1ktAfSDULUprw/KINyHcB+mdlSlIisT0VTJBK6/SRTJ7pbhNc/1Kpvou f65A== Received: by 10.182.50.100 with SMTP id b4mr3694507obo.45.1334850003541; Thu, 19 Apr 2012 08:40:03 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id tx2sm3014269obb.8.2012.04.19.08.40.02 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 08:40:02 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: < draft-ietf-6man-udpzero-05> Date: Thu, 19 Apr 2012 08:40:00 -0700 Message-Id: <0A3CF419-E28F-49C4-B0BF-3086F7F27160@gmail.com> To: IPv6 WG Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 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: Thu, 19 Apr 2012 15:40:08 -0000 All, This message starts a two week 6MAN Working Group on advancing: Title : IPv6 UDP Checksum Considerations Author(s) : Godred Fairhurst Magnus Westerlund Filename : draft-ietf-6man-udpzero-05.txt Pages : 34 Date : 2011-12-23 http://tools.ietf.org/html/draft-ietf-6man-udpzero-05 as an Informational RFC. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on May 3, 2012. Regards, Ole Troan & Bob Hinden From bob.hinden@gmail.com Thu Apr 19 08:40: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 7959821F86B5 for ; Thu, 19 Apr 2012 08:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 u-rSWdVr4s2Y for ; Thu, 19 Apr 2012 08:40:13 -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 3668A21F86BD for ; Thu, 19 Apr 2012 08:40:13 -0700 (PDT) Received: by yhkk25 with SMTP id k25so5181147yhk.31 for ; Thu, 19 Apr 2012 08:40:12 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=q5Yq2LaJsGbldRgOkN5ccKIYnL+QFxBd9Vkib84T8Co=; b=r1NH7Dsh2SdeimfcjKl89GmtymlYaq4lltAwt/Zv6/qldBGxW5/8E/MSqRQNuu820o RoojtMQiutCLE4KluThja48QC2vXLMU68DdFffLuNrXqI2NDZ3lAKl7O6uttkkXlQe/v g4WK7y01ZSZUBadYroVr92qzYB2UQjLCcxvyKYNzxE+rXwnWTqoCin9npXKNca1Oh54x FLMvotoLddhoDchNxn3h8yM5htgJz60Ovj0HbHX9dhYZV9JCRWWZhYA4cEQ7hyTABfiK eM2DYk+/3fpPDoYjef4c3ka2xHBzMUZui+d98I2kwbTrEiSxDenl77PzovWoziwxURok MAhg== Received: by 10.60.14.36 with SMTP id m4mr3601862oec.37.1334850012588; Thu, 19 Apr 2012 08:40:12 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id tx2sm3014269obb.8.2012.04.19.08.40.11 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 08:40:11 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Thu, 19 Apr 2012 08:40:11 -0700 Message-Id: <036E1A9D-88D9-4B1B-A7B1-FF4A624C5E13@gmail.com> To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 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: Thu, 19 Apr 2012 15:40:17 -0000 All, This message starts a two week 6MAN Working Group on advancing: 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 http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-02 as Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on May 3, 2012. Regards, Ole Troan & Bob Hinden From fgont@si6networks.com Thu Apr 19 13:18: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 3173421F85AA for ; Thu, 19 Apr 2012 13:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.960, 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 H3NsF3onyG9A for ; Thu, 19 Apr 2012 13:18:02 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 55BC221F85A8 for ; Thu, 19 Apr 2012 13:18:01 -0700 (PDT) Received: from [2001:5c0:1000:a::355] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SKxnd-0000ss-2Z; Thu, 19 Apr 2012 22:17:53 +0200 Message-ID: <4F9072E5.7060906@si6networks.com> Date: Thu, 19 Apr 2012 17:17:41 -0300 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: Eliot Lear Subject: Re: Consensus call on adopting: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> <4F901471.3070802@cisco.com> In-Reply-To: <4F901471.3070802@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , 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: Thu, 19 Apr 2012 20:18:03 -0000 On 04/19/2012 10:34 AM, Eliot Lear wrote: >> It's not an argument against RFc4941, but rather an argument that even >> with RFC4941, you still need to do something about the IEEE-based IIDs. >> At the Paris IETF, some folks argued that if you have RFC 4941 in place, >> you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of >> draft-gont-6man-stable-privacy-addresses (which should be an Appendix, >> rather than a section in the main body of the document) illustrates that >> that's not the case: even if you're employing RFC4941, you're still >> subject to host-scanning attacks and host tracking. > > Well, host scanning at least. Host tracking depends on the implementation. Not sure what you mean. If you don't do draft-gont-6man-stable-privacy-addresses, you do either IEEE-derived IIDs, or the randomized-but-stable-across-networks Windows IIDs. -- And as long as you have stable-across-networks IIDs, you can be tracked. >> How do you arrive to the conclusion that people might want to use this >> instead of CGAs?? >> >> As noted in the I-D tihs mechanism is meant to be a replacement for IIDs >> based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal >> to CGAs. > > I know what you mean. That matters less than how other people make use > of the work. We can't produce specs for people that cannot read and understand specs. draft-gont-6man-stable-privacy-addresses solves a real and existing problem. To me, "people using draft-gont-6man-stable-privacy-addresses instead of CGAs" makes as much sense as "people using draft-gont-6man-stable-privacy-addresses instead of TCP" -- I don't even know how that might happen, and I've not heard your reasoning of why that might happen. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bob.hinden@gmail.com Thu Apr 19 13:28: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 C17BB11E8076 for ; Thu, 19 Apr 2012 13:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 D44VjO9YeBzR for ; Thu, 19 Apr 2012 13:28:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3598611E8073 for ; Thu, 19 Apr 2012 13:28:43 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8234767obb.31 for ; Thu, 19 Apr 2012 13:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NWh4QDKzo2wcw7RBO/2saamLqFzo/asGZ2lrP6Eq0ls=; b=mcG9Ubq2trcg6hQEmOUNeddSdU/2U+mikuOPH9pahbkXDIyQDrWLGfeKB97z8ae0ZL fzHTqCLWp6XC9jlKs7HEEnkVAgxyFIV0aToruzzGcXo/pUFrwA4NHdwysbVDYpIBD6il SR6VUlnV4+qCi46+uch932FlrJ+ZzYUO4St3Z7wF61eU+RuWlYvocvuoMyZ9wUv9PkBt tMdMTF9izCKPIIa32u7uiyIy/qKnDAhNaNuxsJlv088cwcsHvpBcYOsivJUAnD9Zu8RM 50f31nfox3twOBtCOsu3f10aXGQ7O6KoPyRdwTdRfoh9knWdiP1f5FoHZFIKmRK4auni qggQ== Received: by 10.182.51.9 with SMTP id g9mr5104494obo.56.1334867322741; Thu, 19 Apr 2012 13:28:42 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id o9sm3945242obd.21.2012.04.19.13.28.40 (version=SSLv3 cipher=OTHER); Thu, 19 Apr 2012 13:28:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Fwd: Last Call: (IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard From: Bob Hinden Date: Thu, 19 Apr 2012 13:28:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120418223348.8411.8077.idtracker@ietfa.amsl.com> To: "ipv6@ietf.org Mailing List" X-Mailer: Apple Mail (2.1084) Cc: 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: Thu, 19 Apr 2012 20:28:43 -0000 Please review. As noted below, comments should be sent to the ietf = list. This does update RFC4291 IPv6 Address Architecture. Bob Begin forwarded message: > From: The IESG > Date: April 18, 2012 3:33:48 PM PDT > To: IETF-Announce > Cc: mboned@ietf.org > Subject: Last Call: = (IPv4-Embedded = IPv6 Multicast Address Format) to Proposed Standard > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from the MBONE Deployment WG (mboned) = to > consider the following document: > - 'IPv4-Embedded IPv6 Multicast Address Format' > as a Proposed > Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-05-02. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document specifies an extension to the IPv6 multicast = addressing > architecture to be used in the context of IPv4-IPv6 interconnection. > In particular, this document defines an address format for IPv4- > embedded IPv6 multicast addresses. This address format can be used > for IPv4-IPv6 translation or encapsulation schemes. >=20 > This document updates RFC4291. >=20 >=20 >=20 >=20 >=20 > The file can be obtained via > = http://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-for= mat/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-for= mat/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From pavlix@pavlix.net Thu Apr 19 14:32: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 4440411E80C9 for ; Thu, 19 Apr 2012 14:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.113 X-Spam-Level: X-Spam-Status: No, score=0.113 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_40=-0.185, MIME_8BIT_HEADER=0.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 J+KtHmEZBc7W for ; Thu, 19 Apr 2012 14:32:46 -0700 (PDT) Received: from fox.pavlix.net (fox.pavlix.net [84.246.161.104]) by ietfa.amsl.com (Postfix) with ESMTP id A77C111E80C5 for ; Thu, 19 Apr 2012 14:32:46 -0700 (PDT) Received: from [IPv6:2a00:1268:1ff:f001:9912:c1ba:54e:4eec] (unknown [127.0.0.1]) by fox.pavlix.net (Postfix) with ESMTPSA id D318F1763F6A for ; Thu, 19 Apr 2012 23:32:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pavlix.net; s=default; t=1334871165; bh=Du1MaHqvRm9ImvEYh254DROjbhjxMJjs3Kl+VnGOHQ8=; h=Message-ID:Subject:From:To:Date:Content-Type: Content-Transfer-Encoding:Mime-Version; b=XgH19/KvIyipsxzxWRSU52S+9EGUoZPirUmtcBRRB3f5MGJvkw0TMXqeQQAhB/mBH KfmndXglsXzggs+g0ULpYzT8FwvApbOTwuoT+wxC5TUe1jq5JOOzGzYDPR8K6Y9Ix1 RPtRZqpQqDfNzEFKMCWzUx4B8uop0LIE/krLhWOM= Message-ID: <1334871165.15947.2.camel@dragon.pavlix.net> Subject: question on RDNSS, RFC 6106 part 5.1 From: Pavel =?UTF-8?Q?=C5=A0imerda?= To: ipv6@ietf.org Date: Thu, 19 Apr 2012 23:32:45 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.1 (3.4.1-1.fc17) Content-Transfer-Encoding: 8bit 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: Thu, 19 Apr 2012 21:32:47 -0000 Hello, I'm starting my work on linux NetworkManager. I've been following several bugreports during the recent months that all lead to problems with maintaining the list of recursive nameservers. I've already spent quite some time analyzing RDNSS problems and I came to a conclusion that the problem actually lives in the RFC itself. Please look at section 5.1. in RFC 6106. It states: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval Considering MaxRtrAdvInterval the maximum time between RAs, setting Lifetime to MaxRtrAdvInterval IMO constitutes a race condition. Moreover, any Lifetime in this interval can timeout with just one or two lost RAs. This makes RA-based IPv6-only networks drop RDNSS regularly. In many implementations IPv6 and IPv4 are bound together so that if one of them fails, the whole link is restarted. This is also the case in NetworkManager. In the current situation, it's not advisable to use RFC 6106 in production because it can cause problems even to IPv4 applications. In the real world, radvd uses Lifetime=MaxRtrAdvInterval by default and NetworkManager internally adds 10s to the lifetime, that only helps to avoid the race condition but not lost packets that are common on wireless networks. I appreciate any help to get this right both in the standards and in the software. Cheers, Pavel Å imerda From fgont@si6networks.com Thu Apr 19 23:51: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 D6D3D21F8642 for ; Thu, 19 Apr 2012 23:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.799, 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 Enc7SU56uta6 for ; Thu, 19 Apr 2012 23:50:53 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 01A0E21F8625 for ; Thu, 19 Apr 2012 23:50:52 -0700 (PDT) Received: from [186.134.15.183] (helo=[192.168.123.103]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SL7g7-0008P2-C3; Fri, 20 Apr 2012 08:50:48 +0200 Message-ID: <4F91072F.1070406@si6networks.com> Date: Fri, 20 Apr 2012 03:50:23 -0300 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: Bob Hinden Subject: Re: Comments on References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , IPv6 WG Mailing List 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, 20 Apr 2012 06:51:02 -0000 Hi, Bob, On 04/18/2012 05:55 PM, Bob Hinden wrote: >> On 04/17/2012 08:58 PM, Bob Hinden wrote: >>> In the Introduction the draft mentions that the IEEE MAC based >>> interface identifiers don't eliminate the threat from host >>> scanning. >> [....] >>> The problem I see is that this doesn't justify the claim that >>> there is a problem with host scanning with MAC based interface >>> identifiers. >> >> Fair enough. I will address this in the next rev of the document. > > This is an area I would like to know more about, and it would be good > to quantify the problem. I've just posted this drafty I-D, which hopefully shed some light on the subject (or triggers further discussion): (this one might be a better reference) > Off the top of my head, if an attacker knew the subnet prefix, it > could guess a company_id, it would have to scan ~17M (2^24) addresses > per company_id. That would only result in finding the devices using > that company_id. Agreed. But in a number of scenarios (e.g., ISP X provisioned with vendor X) that may be all you need. That said, please look at the discussion on virtualization in draft-gont-opsec-ipv6-host-scanning-00.txt > This would have to be repeated many times to find > even the majority of devices on a single subnet. This is clearly > easier than having to scan 2^64 addresses in a single subnet, but > still considerably harder than than a /24 IPv6 subnet. I think the key question here is whether these attacks are feasible or not. For example, consider an attacker remotely-scanning the v6-enabled IETF meeting network. He'd probably target: * Apple's (Macs, iPads, iPhones) * Dell's * IBM's * HP's * Toshiba's * Samsung's and he'd already discover a fair share of the hosts connected to the network. Certainly not perfect, certainly harder than in IPv4, but still feasible. Now, if the same nodes implemented draft-gont-6man-stable-privacy-addresses, the attacker would be better off trying something else. >>> 2. Design Goals >>> >>> Could these types of Interface Identifiers also be generated by >>> DHCPv6 servers. I would think that it would be useful to >>> generate these hard to predict IIDs when a DHCPv6 server is >>> providing addresses. This would be much better than assigning >>> them linearly that are easy to predict and scan for. >>> >>> That is, the same approach could be used to create IIDs for SLAAC >>> and DHCPv6. >> >> Agreed. Do you think this should be incorporated in this I-D, or >> that this should be addressed in a different I-D? > > Not sure. If the algorithm could be the same, then it would make > sense to include both use cases (SLACC and DHCPv6). The algorithm could be essentially the same, probably with slight modifications (e.g., DUID rather than Modified_EUI64). -- Just thinking whether procedurally-speaking it'd be better to incorporate this here, or have it as a separate document in dhcwg. >> I could certainly live with this document simply specifying an >> alternative scheme for generating addresses (without formally >> replacing/obsoleting any other method). However, I think it would >> be appropriate that we recommend (somewhere... either in this doc, >> in a document updating node requirements, in a future >> node-requirements-bis, or wherever), that a scheme such as this is >> RECOMMENDED over the ones embedding IEEE identifiers. > > I think there are some tradeoff here that we are discussing. FWIW, when it comes to draft-gont-6man-stable-privacy-addresses vs IEEE-derived ones, the only tradeoff I can think of is, if anything, simplicity for privacy. But yes, when one thinks about IIDs as a whole (IEEE-derived, draft-gont-6man-stable-privacy-addresses, and RFC4941) there are a number of aspectes to consider. > We may > need some more experience before making a decision. In the short > term pushing for a compete change might well be perceived as a > disruptive change to IPv6 deployment. A good starting point is > defining them as an alternative. I can certainly live with that. >> That said, documents such as "Transmission of IPv6 Packets over >> Ethernet Networks" mandate the generation of Modified-EUI-64 format >> identifiers from IEEE identifiers. So I'm not sure what the right >> approach (specs-wise) would be. e.g., formally update RFC 4291, >> noting that besides what's in the "Transmission of IPv6 Packets >> over XXX" documents, IIDs can be generated as specified in >> draft-gont-6man-stable-privacy-addresses, or something else? > > I suggest looking at RFC4941 Privacy Extentions as the model. That > created the privacy IIDs without having update any other documents. Will do. I should note, however, that privacy addresses do not seem to be widely implemented, and even less widely enabled by default (and they have been around for 10+ years). > I think the IPv6 Address Architecture supports a range of Interface > IDs and this draft fall under that. For example, the IPv6 over > documents, don't keep people from using manually configured > addresses, privacy addresses, etc. My point was mostly about how to signal implementers that this alternative exists, and also how to provide advice regarding what algorithm is most desirable. Being able to benefit from the increase IPv6 address space to mitigate host-scanning attacks would be a good thing, and an improvement over IPv4. 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 tjc@ecs.soton.ac.uk Fri Apr 20 00: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 2749221E8032 for ; Fri, 20 Apr 2012 00:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=0.561, 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 uyzBJmSk1iFD for ; Fri, 20 Apr 2012 00:22:45 -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 2725811E8075 for ; Fri, 20 Apr 2012 00:22:43 -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 q3K7MeGg015562 for ; Fri, 20 Apr 2012 08:22:40 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q3K7MeGg015562 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1334906561; bh=TrLlokE2rD5VOsTgYJzJIiaDP2k=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=oDnagOSb3pzN8Ln/z9wWLaZFOgpq8PcCbF+qhlsYVz6WYupVRp6FEaKnhTR7GqZmr KxOjUs8ioTgxAEPgLcQHZGQr4oqyL7Vxt1jGVlsn/lVnuqDXtYrMKtUjDzqmW/mydn OG0sdn+fZylCKAS/wjSBjszTAEB4zHmy/9DUZN+Q= 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 o3J8Me0543746298w9 ret-id none; Fri, 20 Apr 2012 08:22:40 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q3K7MGj3024277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Apr 2012 08:22:16 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: Comments on From: Tim Chown In-Reply-To: <4F91072F.1070406@si6networks.com> Date: Fri, 20 Apr 2012 08:22:15 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@si6networks.com> <4F91072F.1070406@si6networks.com> <9FF9F19B-1F00-46E8-81F3-792D8784D67D@ecs.soton.ac.uk> To: IPv6 WG Mailing List X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o3J8Me054374629800; tid=o3J8Me0543746298w9; 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: q3K7MeGg015562 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: Fri, 20 Apr 2012 07:22:46 -0000 On 20 Apr 2012, at 07:50, Fernando Gont wrote: > Hi, Bob, >=20 > On 04/18/2012 05:55 PM, Bob Hinden wrote: >>=20 >>=20 >> This is an area I would like to know more about, and it would be good >> to quantify the problem. >=20 > I've just posted this drafty I-D, which hopefully shed some light on = the > subject (or triggers further discussion): > Don't forget RFC5157, which talks about other ways addresses can be = gleaned, and thus attackers could scan around those addresses. i.e. = that brute force sweeps across an entire subnet aren't feasible, but an = attacker will do whatever they can to narrow the search space. That text reinforces the need for randomised host addresses, and, for = example, DHCPv6 servers not to allocate addresses in a predictable way. = The stable privacy address draft adds pretty much the same feature for = SLAAC. The ND cache exhaustion issue is also linked in to the scanning topic. Tim= From fgont@si6networks.com Fri Apr 20 01:25: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 116DB21F8720 for ; Fri, 20 Apr 2012 01:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.685, 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 6+THAVlqopNC for ; Fri, 20 Apr 2012 01:25:05 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 43A5821F86F7 for ; Fri, 20 Apr 2012 01:25:04 -0700 (PDT) Received: from [186.134.15.183] (helo=[192.168.123.103]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SL99K-0000iS-0v; Fri, 20 Apr 2012 10:25:02 +0200 Message-ID: <4F9117AC.9020209@si6networks.com> Date: Fri, 20 Apr 2012 05:00:44 -0300 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: Tim Chown Subject: Re: Comments on References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@si6networks.com> <4F91072F.1070406@si6networks.com> <9FF9F19B-1F00-46E8-81F3-792D8784D67D@ecs.soton.ac.uk> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List 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, 20 Apr 2012 08:25:06 -0000 Hi, Tim, On 04/20/2012 04:22 AM, Tim Chown wrote: >> On 04/18/2012 05:55 PM, Bob Hinden wrote: >>> This is an area I would like to know more about, and it would be >>> good to quantify the problem. >> >> I've just posted this drafty I-D, which hopefully shed some light >> on the subject (or triggers further discussion): >> > > Don't forget RFC5157, which talks about other ways addresses can be > gleaned, Yes, as noted in Section 1 of the I-D, this is a very drafty version, pushed out to answer Bob's question. :-) -- There's lots of stuff that still needs to be added. > The ND cache exhaustion issue is also linked in to the scanning > topic. Yep. Note: Some text present in the document on which draft-gont-opsec-ipv6-host-scanning is based has been deliberately excluded from draft-gont-opsec-ipv6-host-scanning-00: the aforementioned document on which this draft is based was mostly about *designing* a port scanner, and targeted a different audience. (e.g., draft-ietf-v6ops-v6nd-problems was being referenced in a section about "selecting the probe rate"). P.S.: I will try to incorporate some of the missing stuff, and rev shortly -- in any case, I felt it was more productive to submit this drafty version of the draft, than answering Bob's question/request with a two-liner in an e-mail. 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 pavlix@pavlix.net Thu Apr 19 14:10:04 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 9BE9011E80BA for ; Thu, 19 Apr 2012 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.317 X-Spam-Level: * X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=1.202, BAYES_40=-0.185, MIME_8BIT_HEADER=0.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 dMS4jtgkbYJi for ; Thu, 19 Apr 2012 14:10:04 -0700 (PDT) Received: from fox.pavlix.net (fox.pavlix.net [84.246.161.104]) by ietfa.amsl.com (Postfix) with ESMTP id E52BB11E80B7 for ; Thu, 19 Apr 2012 14:10:03 -0700 (PDT) Received: from [IPv6:2a00:1268:1ff:f001:9912:c1ba:54e:4eec] (unknown [127.0.0.1]) by fox.pavlix.net (Postfix) with ESMTPSA id B4AD81763F69 for ; Thu, 19 Apr 2012 23:10:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pavlix.net; s=default; t=1334869802; bh=Du1MaHqvRm9ImvEYh254DROjbhjxMJjs3Kl+VnGOHQ8=; h=Message-ID:Subject:From:To:Date:Content-Type: Content-Transfer-Encoding:Mime-Version; b=mCIsWJWim9aG/8q8oLvrLkBI5G1eoL3RV+vfIlxhxsq5/IiXFt1gfYbo7KUmvOEED R9L/u0N13OGff/w7j4NoB26BJ+xqy3uTNsGyDxlKQLrQv56yhUDY1QQRHL+ljJ/is0 nns3r/4vsHWgkfdRPBNVlzEjEhqQuErpOqH/I9bw= Message-ID: <1334869802.14403.20.camel@dragon.pavlix.net> Subject: question on RDNSS, RFC 6106 part 5.1 From: Pavel =?UTF-8?Q?=C5=A0imerda?= To: ipv6@ietf.org Date: Thu, 19 Apr 2012 23:10:02 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.1 (3.4.1-1.fc17) Content-Transfer-Encoding: 8bit Mime-Version: 1.0 X-Mailman-Approved-At: Fri, 20 Apr 2012 01:30:23 -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, 19 Apr 2012 21:10:04 -0000 Hello, I'm starting my work on linux NetworkManager. I've been following several bugreports during the recent months that all lead to problems with maintaining the list of recursive nameservers. I've already spent quite some time analyzing RDNSS problems and I came to a conclusion that the problem actually lives in the RFC itself. Please look at section 5.1. in RFC 6106. It states: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval Considering MaxRtrAdvInterval the maximum time between RAs, setting Lifetime to MaxRtrAdvInterval IMO constitutes a race condition. Moreover, any Lifetime in this interval can timeout with just one or two lost RAs. This makes RA-based IPv6-only networks drop RDNSS regularly. In many implementations IPv6 and IPv4 are bound together so that if one of them fails, the whole link is restarted. This is also the case in NetworkManager. In the current situation, it's not advisable to use RFC 6106 in production because it can cause problems even to IPv4 applications. In the real world, radvd uses Lifetime=MaxRtrAdvInterval by default and NetworkManager internally adds 10s to the lifetime, that only helps to avoid the race condition but not lost packets that are common on wireless networks. I appreciate any help to get this right both in the standards and in the software. Cheers, Pavel Å imerda From dominik.elsbroek@gmail.com Fri Apr 20 04:38:33 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 147D321F865B for ; Fri, 20 Apr 2012 04:38:33 -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 I-ehDy-WC3lG for ; Fri, 20 Apr 2012 04:38:29 -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 4AEF821F8648 for ; Fri, 20 Apr 2012 04:38:29 -0700 (PDT) Received: by iazz13 with SMTP id z13so16236631iaz.31 for ; Fri, 20 Apr 2012 04:38:29 -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=btR6Y+xjNM1lpEBMlVY9xX3EFbCoHDOHabYBiLNAbGk=; b=XKZpxpqSedy4NjTKZmDV9rRJFJENYpq+cmkyCLf3ubUdCLEqVLJzKXgd7yU6EsT0Vp pwC+3X3jDHxdHm0Xaga5xJrMXekAKw022zIE1F7Nm8vSxTRkVwMZf8G/rYJ7Eq0MHFPP 5SEsQ+q4SboJL1+3S+UzYzJGfpmPiZ4N3SJaLV+VJsU7Kz70t20t7q+VrKJxARt53tv7 mmG5E0JmjXqdF3U2+WVGRBwQnGlSYejf/Q+pFj82jEyrLJG+E/Z5Wmi5Brbt2Cw68SYY VPKe+ENFnPHaSn5Ffp+SverLXqry+ocN6AcRpU90iTqU5ERA1d6BpKxVSrpOHmPZev1E ICsg== MIME-Version: 1.0 Received: by 10.50.94.234 with SMTP id df10mr5593973igb.31.1334921908988; Fri, 20 Apr 2012 04:38:28 -0700 (PDT) Received: by 10.50.33.74 with HTTP; Fri, 20 Apr 2012 04:38:28 -0700 (PDT) In-Reply-To: <4F9072E5.7060906@si6networks.com> References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> <4F901471.3070802@cisco.com> <4F9072E5.7060906@si6networks.com> Date: Fri, 20 Apr 2012 13:38:28 +0200 Message-ID: Subject: Re: Consensus call on adopting: From: Dominik Elsbroek To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Bob Hinden , IPv6 WG Mailing List , Eliot Lear 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, 20 Apr 2012 11:38:33 -0000 Personally I support this draft. But would like to see stable privacy enhanced addresses as a replacement for IEEE-based addresses since they allow an attacker to infer to the vendor of a NIC. On OUIs of Apple Inc. they also allow conclusion to the operating system. Thus an attacker gets more information by an IPv6 address than they should in my opinion. Cheers, Dominik On Thu, Apr 19, 2012 at 22:17, Fernando Gont wrote: > On 04/19/2012 10:34 AM, Eliot Lear wrote: >>> It's not an argument against RFc4941, but rather an argument that even >>> with RFC4941, you still need to do something about the IEEE-based IIDs. >>> At the Paris IETF, some folks argued that if you have RFC 4941 in place= , >>> you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of >>> draft-gont-6man-stable-privacy-addresses (which should be an Appendix, >>> rather than a section in the main body of the document) illustrates tha= t >>> that's not the case: even if you're employing RFC4941, you're still >>> subject to host-scanning attacks and host tracking. >> >> Well, host scanning at least. =A0Host tracking depends on the implementa= tion. > > Not sure what you mean. If you don't do > draft-gont-6man-stable-privacy-addresses, you do either IEEE-derived > IIDs, or the randomized-but-stable-across-networks Windows IIDs. -- And > as long as you have stable-across-networks IIDs, you can be tracked. > > >>> How do you arrive to the conclusion that people might want to use this >>> instead of CGAs?? >>> >>> As noted in the I-D tihs mechanism is meant to be a replacement for IID= s >>> based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal >>> to CGAs. >> >> I know what you mean. =A0That matters less than how other people make us= e >> of the work. > > We can't produce specs for people that cannot read and understand specs. > draft-gont-6man-stable-privacy-addresses solves a real and existing probl= em. > > To me, "people using draft-gont-6man-stable-privacy-addresses instead of > CGAs" makes as much sense as "people using > draft-gont-6man-stable-privacy-addresses instead of TCP" -- I don't even > know how that might happen, and I've not heard your reasoning of why > that might happen. > > Cheers, > -- > 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 mohacsi@niif.hu Fri Apr 20 06:09: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 691DA21F8735 for ; Fri, 20 Apr 2012 06:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[AWL=0.200, 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 ovVF2sJoLv6W for ; Fri, 20 Apr 2012 06:09:16 -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 9D65021F86FF for ; Fri, 20 Apr 2012 06:09:11 -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 CC46787B5A; Fri, 20 Apr 2012 15:09:09 +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 MLY8s+3CLYhU; Fri, 20 Apr 2012 15:09:06 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 97AAA87B56; Fri, 20 Apr 2012 15:09:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 8435187B54; Fri, 20 Apr 2012 15:09:06 +0200 (CEST) Date: Fri, 20 Apr 2012 15:09:06 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Dominik Elsbroek Subject: Re: Consensus call on adopting: In-Reply-To: Message-ID: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> <4F901471.3070802@cisco.com> <4F9072E5.7060906@si6networks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1079407422-1334927346=:40024" Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Fernando Gont , Bob Hinden , Eliot Lear , IPv6 WG Mailing List 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, 20 Apr 2012 13:09:17 -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. --0-1079407422-1334927346=:40024 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Dear All, I support to have a semi stable private address. But very much against the idea of replacing EUI-64 addresses. The client application based on the policy should pick pivate or EUI-64 addresses. Note: - Nothing stops me to pick MAC addresses from no longer existing vendor e.g DEC I think the proper implementation of RFC 3041 or/and 4941 can solve your problem Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, 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 Fri, 20 Apr 2012, Dominik Elsbroek wrote: > Personally I support this draft. But would like to see stable privacy > enhanced addresses as a replacement for IEEE-based addresses since > they allow an attacker to infer to the vendor of a NIC. On OUIs of > Apple Inc. they also allow conclusion to the operating system. > > Thus an attacker gets more information by an IPv6 address than they > should in my opinion. > > Cheers, > Dominik > > > On Thu, Apr 19, 2012 at 22:17, Fernando Gont wrote: >> On 04/19/2012 10:34 AM, Eliot Lear wrote: >>>> It's not an argument against RFc4941, but rather an argument that even >>>> with RFC4941, you still need to do something about the IEEE-based IIDs. >>>> At the Paris IETF, some folks argued that if you have RFC 4941 in place, >>>> you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of >>>> draft-gont-6man-stable-privacy-addresses (which should be an Appendix, >>>> rather than a section in the main body of the document) illustrates that >>>> that's not the case: even if you're employing RFC4941, you're still >>>> subject to host-scanning attacks and host tracking. >>> >>> Well, host scanning at least.  Host tracking depends on the implementation. >> >> Not sure what you mean. If you don't do >> draft-gont-6man-stable-privacy-addresses, you do either IEEE-derived >> IIDs, or the randomized-but-stable-across-networks Windows IIDs. -- And >> as long as you have stable-across-networks IIDs, you can be tracked. >> >> >>>> How do you arrive to the conclusion that people might want to use this >>>> instead of CGAs?? >>>> >>>> As noted in the I-D tihs mechanism is meant to be a replacement for IIDs >>>> based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal >>>> to CGAs. >>> >>> I know what you mean.  That matters less than how other people make use >>> of the work. >> >> We can't produce specs for people that cannot read and understand specs. >> draft-gont-6man-stable-privacy-addresses solves a real and existing problem. >> >> To me, "people using draft-gont-6man-stable-privacy-addresses instead of >> CGAs" makes as much sense as "people using >> draft-gont-6man-stable-privacy-addresses instead of TCP" -- I don't even >> know how that might happen, and I've not heard your reasoning of why >> that might happen. >> >> Cheers, >> -- >> 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 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0-1079407422-1334927346=:40024-- From bob.hinden@gmail.com Fri Apr 20 10:27: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 1E3F921F8674 for ; Fri, 20 Apr 2012 10:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Neg4DQh6kiIZ for ; Fri, 20 Apr 2012 10:27:00 -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 CA22F21F85A2 for ; Fri, 20 Apr 2012 10:26:59 -0700 (PDT) Received: by yhkk25 with SMTP id k25so6112838yhk.31 for ; Fri, 20 Apr 2012 10:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=bjtvdFmHBRVmo3e014XAJMJWZWBzg4PC1UICrotituk=; b=UuGBEN6Q93ZZT8W1jGC66JA2AcG4wGymcgnT8ZSLieeCXl8vPaXxeehKzYwycYJUGc gohf671cTdeAD4FU5ttQr/54mzibBYtbSu/0WKHVE3jOo/rAzlaRzxXFccrZ2ttchbVh fYhkVjlAsymRE9/RAsAVI0tQ3lzKtjrXgeBiXY0C9NBBHtvtzWC+Ig/cTAtJvyM/rmxQ stGQSjzUiluYtA/0tQifPPs6BR7Vgmn6Dsg4IFc1bd+S9IqK2BLxuhX9KT6xo6ybFgFn m+d1w3VbyTX8klvlQ0i3KMuR/sci6lGh1gI/IRx0D7zeoyGr/dlFmZmpvV4OX9OGDe1Q BQQw== Received: by 10.60.169.165 with SMTP id af5mr9773039oec.72.1334942819217; Fri, 20 Apr 2012 10:26:59 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id m2sm7071326obk.9.2012.04.20.10.26.56 (version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 10:26:57 -0700 (PDT) Subject: Re: Comments on Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4F91072F.1070406@si6networks.com> Date: Fri, 20 Apr 2012 10:26:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@si6networks.com> <4F91072F.1070406@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: IPv6 WG Mailing List , 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, 20 Apr 2012 17:27:01 -0000 Fernando, On Apr 19, 2012, at 11:50 PM, Fernando Gont wrote: > Hi, Bob, >=20 > On 04/18/2012 05:55 PM, Bob Hinden wrote: >>> On 04/17/2012 08:58 PM, Bob Hinden wrote: >>>> In the Introduction the draft mentions that the IEEE MAC based=20 >>>> interface identifiers don't eliminate the threat from host >>>> scanning. >>> [....] >>>> The problem I see is that this doesn't justify the claim that >>>> there is a problem with host scanning with MAC based interface >>>> identifiers. >>>=20 >>> Fair enough. I will address this in the next rev of the document. >>=20 >> This is an area I would like to know more about, and it would be good >> to quantify the problem. >=20 > I've just posted this drafty I-D, which hopefully shed some light on = the > subject (or triggers further discussion): > >=20 > (this one might be a better reference) Thanks. I will take a look. >=20 >=20 >> Off the top of my head, if an attacker knew the subnet prefix, it >> could guess a company_id, it would have to scan ~17M (2^24) addresses >> per company_id. That would only result in finding the devices using >> that company_id. >=20 > Agreed. But in a number of scenarios (e.g., ISP X provisioned with > vendor X) that may be all you need. That said, please look at the > discussion on virtualization in = draft-gont-opsec-ipv6-host-scanning-00.txt >=20 >=20 >> This would have to be repeated many times to find >> even the majority of devices on a single subnet. This is clearly >> easier than having to scan 2^64 addresses in a single subnet, but >> still considerably harder than than a /24 IPv6 subnet. >=20 > I think the key question here is whether these attacks are feasible or = not. >=20 > For example, consider an attacker remotely-scanning the v6-enabled = IETF > meeting network. He'd probably target: >=20 > * Apple's (Macs, iPads, iPhones) > * Dell's > * IBM's > * HP's > * Toshiba's > * Samsung's I agree, I would do that too :-) However, it also depends a lot on how many companies IDs each vendor has = and how they allocate them to their devices. =20 For example, I looked at=20 http://standards.ieee.org/develop/regauth/oui/public.html and did a search for Apple and found about 150 assigned company_id's. = [Note: It's "about" because some companies have "Apple" in their = address]. The IEEE page also says: "Firms and numbers listed may not = always be obvious in product implementations, as some manufacturers = subcontract component manufacture and others include registered firm = OUIs in their products." The point I am trying to make here is that we should characterize the = risk here accurately. It's not as simple as get one company_id and then = start scanning. >=20 >=20 > and he'd already discover a fair share of the hosts connected to the > network. >=20 > Certainly not perfect, certainly harder than in IPv4, but still = feasible. >=20 > Now, if the same nodes implemented > draft-gont-6man-stable-privacy-addresses, the attacker would be better > off trying something else. >=20 Agreed. It also hides the company_id. =20 >=20 >>>> 2. Design Goals >>>>=20 >>>> Could these types of Interface Identifiers also be generated by=20 >>>> DHCPv6 servers. I would think that it would be useful to >>>> generate these hard to predict IIDs when a DHCPv6 server is >>>> providing addresses. This would be much better than assigning >>>> them linearly that are easy to predict and scan for. >>>>=20 >>>> That is, the same approach could be used to create IIDs for SLAAC >>>> and DHCPv6. >>>=20 >>> Agreed. Do you think this should be incorporated in this I-D, or >>> that this should be addressed in a different I-D? >>=20 >> Not sure. If the algorithm could be the same, then it would make >> sense to include both use cases (SLACC and DHCPv6). >=20 > The algorithm could be essentially the same, probably with slight > modifications (e.g., DUID rather than Modified_EUI64). -- Just = thinking > whether procedurally-speaking it'd be better to incorporate this here, > or have it as a separate document in dhcwg. >=20 >=20 >=20 >>> I could certainly live with this document simply specifying an=20 >>> alternative scheme for generating addresses (without formally=20 >>> replacing/obsoleting any other method). However, I think it would >>> be appropriate that we recommend (somewhere... either in this doc, >>> in a document updating node requirements, in a future >>> node-requirements-bis, or wherever), that a scheme such as this is >>> RECOMMENDED over the ones embedding IEEE identifiers. >>=20 >> I think there are some tradeoff here that we are discussing. =20 >=20 > FWIW, when it comes to draft-gont-6man-stable-privacy-addresses vs > IEEE-derived ones, the only tradeoff I can think of is, if anything, > simplicity for privacy. >=20 > But yes, when one thinks about IIDs as a whole (IEEE-derived, > draft-gont-6man-stable-privacy-addresses, and RFC4941) there are a > number of aspectes to consider. >=20 >=20 >=20 >> We may >> need some more experience before making a decision. In the short >> term pushing for a compete change might well be perceived as a >> disruptive change to IPv6 deployment. A good starting point is >> defining them as an alternative. >=20 > I can certainly live with that. >=20 >=20 >>> That said, documents such as "Transmission of IPv6 Packets over >>> Ethernet Networks" mandate the generation of Modified-EUI-64 format >>> identifiers from IEEE identifiers. So I'm not sure what the right >>> approach (specs-wise) would be. e.g., formally update RFC 4291, >>> noting that besides what's in the "Transmission of IPv6 Packets >>> over XXX" documents, IIDs can be generated as specified in=20 >>> draft-gont-6man-stable-privacy-addresses, or something else? >>=20 >> I suggest looking at RFC4941 Privacy Extentions as the model. That >> created the privacy IIDs without having update any other documents. >=20 > Will do. I should note, however, that privacy addresses do not seem to > be widely implemented, and even less widely enabled by default (and = they > have been around for 10+ years). >=20 >=20 >=20 >> I think the IPv6 Address Architecture supports a range of Interface >> IDs and this draft fall under that. For example, the IPv6 over >> documents, don't keep people from using manually configured >> addresses, privacy addresses, etc. >=20 > My point was mostly about how to signal implementers that this > alternative exists, and also how to provide advice regarding what > algorithm is most desirable. >=20 > Being able to benefit from the increase IPv6 address space to mitigate > host-scanning attacks would be a good thing, and an improvement over = IPv4. Agreed. =20 Thanks, Bob >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 From fgont@si6networks.com Fri Apr 20 10:47: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 E9B8421F85EA for ; Fri, 20 Apr 2012 10:47:07 -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 3rVUJDaSlxjl for ; Fri, 20 Apr 2012 10:47:07 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id E1F1F21F85E7 for ; Fri, 20 Apr 2012 10:47:06 -0700 (PDT) Received: from [2001:5c0:1000:a::5eb] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SLHvF-0005SO-IG; Fri, 20 Apr 2012 19:47:05 +0200 Message-ID: <4F91A10B.5030505@si6networks.com> Date: Fri, 20 Apr 2012 14:46:51 -0300 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: Bob Hinden Subject: Re: Comments on References: <295BAD95-B636-4611-B735-4FA13AB0FAB9@gmail.com> <4F8E442D.1090700@si6networks.com> <4F91072F.1070406@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 WG Mailing List 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, 20 Apr 2012 17:47:08 -0000 Hi, Bob, On 04/20/2012 02:26 PM, Bob Hinden wrote: >> For example, consider an attacker remotely-scanning the v6-enabled >> IETF meeting network. He'd probably target: >> >> * Apple's (Macs, iPads, iPhones) * Dell's * IBM's * HP's * >> Toshiba's * Samsung's > > I agree, I would do that too :-) > > However, it also depends a lot on how many companies IDs each vendor > has and how they allocate them to their devices. Of the top of my head, they use OUIs mostly sequentially. So, e.g., the first OUI assigned to, say, Apple, in unlikely to be in actual use nowadays. That aside, scanning a network such as "the IETF meeting network" is kind of "the worst case scenario", since there are heterogeneous systems. In a typical organizational scenario, you have, at most, a few providers (they make large purchases from the same vendor). > > For example, I looked at > > http://standards.ieee.org/develop/regauth/oui/public.html > > and did a search for Apple and found about 150 assigned company_id's. > [Note: It's "about" because some companies have "Apple" in their > address]. I will double-check... But most of the cases I checked didn't have more than 10 OUIs or so. > The IEEE page also says: "Firms and numbers listed may not > always be obvious in product implementations, as some manufacturers > subcontract component manufacture and others include registered firm > OUIs in their products." Yes, but as the idea develops, it wouldn't be hard to imagine an "OUI matrix" document (or watchamacallit :-) ) that maps vendors to OUIs in a more precise way. > The point I am trying to make here is that we should characterize the > risk here accurately. It's not as simple as get one company_id and > then start scanning. As far as I've checked, it can work pretty well that way. That said, as noted by Ray, it's not that the lower 24 bits are selected in a random order, but rather sequentially. So you don't even need to search the 24-bit space linearly: Take samples "randomly", and once you find an alive host, try sequential addresses starting from there. That said, it's not as bad as "this company has 10 OUIs, and I need to go through all of them". (I will try to get more experimental data, anyway). >> and he'd already discover a fair share of the hosts connected to >> the network. >> >> Certainly not perfect, certainly harder than in IPv4, but still >> feasible. >> >> Now, if the same nodes implemented >> draft-gont-6man-stable-privacy-addresses, the attacker would be >> better off trying something else. > > Agreed. It also hides the company_id. Exactly. And the search space becomes 64 bits (well, 63, since there's the U/L bit), with no patterns. -- That's a whole different game. >> Being able to benefit from the increase IPv6 address space to >> mitigate host-scanning attacks would be a good thing, and an >> improvement over IPv4. > > Agreed. 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 fgont@si6networks.com Fri Apr 20 11:36: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 59AA111E8086 for ; Fri, 20 Apr 2012 11:36: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 jmNV3SonlnQ6 for ; Fri, 20 Apr 2012 11:36:52 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id CB40B11E8079 for ; Fri, 20 Apr 2012 11:36:51 -0700 (PDT) Received: from [2001:5c0:1000:a::5eb] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SLIhG-0005t4-5j; Fri, 20 Apr 2012 20:36:42 +0200 Message-ID: <4F91ACB3.2030901@si6networks.com> Date: Fri, 20 Apr 2012 15:36:35 -0300 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: Mohacsi Janos Subject: Re: Consensus call on adopting: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> <4F901471.3070802@cisco.com> <4F9072E5.7060906@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , Bob Hinden , Eliot Lear 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, 20 Apr 2012 18:36:52 -0000 Hi, Mohacsi, On 04/20/2012 10:09 AM, Mohacsi Janos wrote: > I support to have a semi stable private address. But very much > against the idea of replacing EUI-64 addresses. You mean "against replacing addresses embedding IEEE identifiers"? > The client application > based on the policy should pick pivate or EUI-64 addresses. Just curious: Is there a specific use case for IEEE-derived addresses that cannot be satisfied with draft-gont-6man-stable-privacy-addresses? > Note: - Nothing stops me to pick MAC addresses from no longer existing > vendor e.g DEC Why would you want to do it? > I think the proper implementation of RFC 3041 or/and 4941 can solve your > problem I don't follow. RFC 4941 generates addresses in addition to the stable ones, so.. how could they possibly fix the scanning problem? 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 mohacsi@niif.hu Sat Apr 21 02:11: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 9710221F8551 for ; Sat, 21 Apr 2012 02:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=0.150, 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 wyQYBjBzkxEd for ; Sat, 21 Apr 2012 02:10:58 -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 4CD8421F853E for ; Sat, 21 Apr 2012 02:10:58 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 50DF587A26; Sat, 21 Apr 2012 11:10:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id tg38HXuyrUkN; Sat, 21 Apr 2012 11:10:49 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 70F82879C9; Sat, 21 Apr 2012 11:10:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 1BFEA878FE; Sat, 21 Apr 2012 11:10:48 +0200 (CEST) Date: Sat, 21 Apr 2012 11:10:47 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Fernando Gont Subject: Re: Consensus call on adopting: In-Reply-To: <4F91ACB3.2030901@si6networks.com> Message-ID: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> <4F901471.3070802@cisco.com> <4F9072E5.7060906@si6networks.com> <4F91ACB3.2030901@si6networks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , Bob Hinden , Eliot Lear 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, 21 Apr 2012 09:11:02 -0000 On Fri, 20 Apr 2012, Fernando Gont wrote: > Hi, Mohacsi, > > On 04/20/2012 10:09 AM, Mohacsi Janos wrote: >> I support to have a semi stable private address. But very much >> against the idea of replacing EUI-64 addresses. > > You mean "against replacing addresses embedding IEEE identifiers"? yes. > > >> The client application >> based on the policy should pick pivate or EUI-64 addresses. > > Just curious: Is there a specific use case for IEEE-derived addresses > that cannot be satisfied with draft-gont-6man-stable-privacy-addresses? The existing implementations. The most important factor of introduction of new standards to interoperate the existing ones. I think this should be documented in your draft. Furthermore there are several firewalls and monitoring tools which is generating warning in case of IEEE-derived address and MAC mismatch. This has to be investigated and documented in the draft. > > >> Note: - Nothing stops me to pick MAC addresses from no longer existing >> vendor e.g DEC > > Why would you want to do it? > > >> I think the proper implementation of RFC 3041 or/and 4941 can solve your >> problem > > I don't follow. RFC 4941 generates addresses in addition to the stable > ones, so.. how could they possibly fix the scanning problem? I think the stablity/network supervisor ability to track devices is enough justification for stable privacy addresses. Scanning is not so important. I know there are several new techniques - I am warning about the possible methods for several years in my presentations. http://www2.garr.it/conf_05_slides/j_mohacsi-IPv6_sec.pdf Best Regards, Janos Mohacsi > > 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 fgont@si6networks.com Sat Apr 21 08:43: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 61AE721F8611 for ; Sat, 21 Apr 2012 08:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 usa3owcaDR78 for ; Sat, 21 Apr 2012 08:43:23 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 45FC521F860D for ; Sat, 21 Apr 2012 08:43:19 -0700 (PDT) Received: from [2001:5c0:1000:a::703] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SLcSr-0001T9-71; Sat, 21 Apr 2012 17:43:09 +0200 Message-ID: <4F92BDF0.4080604@si6networks.com> Date: Sat, 21 Apr 2012 11:02:24 -0300 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: Mohacsi Janos Subject: Re: Consensus call on adopting: References: <4F87DF53.7030009@cisco.com> <4F881C9A.3050908@si6networks.com> <4F8E8B75.4030605@cisco.com> <4F8EE130.8070903@si6networks.com> <4F901471.3070802@cisco.com> <4F9072E5.7060906@si6networks.com> <4F91ACB3.2030901@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List , Bob Hinden , Eliot Lear 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, 21 Apr 2012 15:43:28 -0000 On 04/21/2012 06:10 AM, Mohacsi Janos wrote: >>> The client application >>> based on the policy should pick pivate or EUI-64 addresses. >> >> Just curious: Is there a specific use case for IEEE-derived addresses >> that cannot be satisfied with draft-gont-6man-stable-privacy-addresses? > > The existing implementations. The most important factor of introduction > of new standards to interoperate the existing ones. I think this should > be documented in your draft. Could you please clarify what you're referring to, specifically? -- i.e., this address generation mechanism is backwards-compatible. > Furthermore there are several firewalls > and monitoring tools which is generating warning in case of IEEE-derived > address and MAC mismatch. This has to be investigated and documented in > the draft. You mean that updated implementations would automatically generate addresses differently? In this case, my take is that *updates* should probably not enable this mechanism by default, or at the very least have a system toggle to turn this feature off. For new devices (i.e., off-the-box rather than software-updated), this should probably be enabled by default. >>> I think the proper implementation of RFC 3041 or/and 4941 can solve your >>> problem >> >> I don't follow. RFC 4941 generates addresses in addition to the stable >> ones, so.. how could they possibly fix the scanning problem? > > I think the stablity/network supervisor ability to track devices is > enough justification for stable privacy addresses. Agreed. But someone might argue that you can achieve this with IPv6 addresses that embed IEEE-identifiers or randomized-but-stable-across-networks IIDs... but these fail to address other problems. > Scanning is not so > important. I know there are several new techniques - I am warning about > the possible methods for several years in my presentations. > http://www2.garr.it/conf_05_slides/j_mohacsi-IPv6_sec.pdf Will check your slides -- thanks for the pointer! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jeanmichel.combes@gmail.com Tue Apr 24 08:35: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 138BB21F853B for ; Tue, 24 Apr 2012 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.697, 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 OS+QXj127LZx for ; Tue, 24 Apr 2012 08:35:45 -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 4F9C421F881B for ; Tue, 24 Apr 2012 08:35:40 -0700 (PDT) Received: by yenm5 with SMTP id m5so537160yen.31 for ; Tue, 24 Apr 2012 08:35:40 -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=qbq6honURVc6WnAUB2/qD7sOY/hT3IiUV3viWNW2v00=; b=a/IWkGHzb8tgy0UJ8fmWJqBg7TRnof9UZvnAQBXAtxJchGwXM6Sd32COhQThtx2/Od mAUZj1e8IwgNDko0+vkUUIKuiJSwoenHavX9zUfVnXxTFLW5PJheA+RCm21Tt+O69cr8 7Xrk/4twfAt5/7DuXDfhjIi95xtSpzrzAzMVdH9frCOlQaR4plwcEp7Vbddc4Rg1gTR2 hwxu0wRfth9Fpuu0FSEJNMudYNAKvl3bG/6nwm/h7JMesiIL9AONO5X8V6woP1dbFuK/ BhGQAhUtSdozMduLzC1rThwYLqZy0kcOgrH+s22OLKGQHVBeHLA+4POrcsm4mwkHHLOv hPJw== MIME-Version: 1.0 Received: by 10.101.129.7 with SMTP id g7mr5916501ann.12.1335281739876; Tue, 24 Apr 2012 08:35:39 -0700 (PDT) Received: by 10.146.242.4 with HTTP; Tue, 24 Apr 2012 08:35:39 -0700 (PDT) In-Reply-To: <4F71A8AF.2020905@forthnetgroup.gr> References: <4F71A8AF.2020905@forthnetgroup.gr> Date: Tue, 24 Apr 2012 17:35:39 +0200 Message-ID: Subject: Re: comments about draft-ietf-6man-dad-proxy-02 From: Jean-Michel Combes To: Tassos Chatzithomaoglou Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-6man-dad-proxy@tools.ietf.org, 6man Mailing List 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, 24 Apr 2012 15:35:46 -0000 Hi Tassos, at first, sorry for the delayed reply and thanks for your comments. 2012/3/27 Tassos Chatzithomaoglou : > 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). This draft tackles an issue that exists on access architectures defined by the Broadband Forum. The Broadband Forum uses the term "split horizon" and it is important to re-use this term in order to make an easy correlation with the Broadband Forum's scenarios. This term is fully defined in the draft. Besides, Hub and spoke or root/leafs do not help in understanding that DAD-NS are not forwarded to other CPEs. That's why BBF terminology is re-used (since it is a BBF architectural problem to be solved by IETF). > 2) IPv6 over PPP is not affected and should probably be mentioned. Agreed. In the next version of this document, a sentence will be added in the introduction. > > 3) =A0Under 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 > =A0 verify whether there is a real conflict by checking if the CPE whose > =A0 IPv6 address is in the entry is still connected. =A0In the following, > =A0 we will call IPv6-CPE1 the IPv6 address of the existing entry, Link- > =A0 layer-CPE1 the Link-layer address of that entry and Link-layer-CPE2 > =A0 the Link-layer address of the CPE which is performing DAD, which is > =A0 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 > =A0 =A0 =A0another 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 addr= ess > of the existing entry" statement. > It also seems a little bit confusing to me. > > There is not contradiction because the initial definition (cf. "we will call IPv6-CPE1 the IPv6 address of the existing entry") refers to the entry in the Binding Table defined in section 4.1. The 2 paragraphs "If IPv6-CPE is (not) in the Neighbor Cache" refers to the Neighbor Cache, which is (or might be) another table. However, it is acknowledged that clarification is required in order to avoid the confusion. In the next version of this document, a sentence will be added in section 4.1. > > 4) > > If IPv6-CPE1 is in the Neighbor Cache, but it is associated with > =A0 =A0 =A0another Link-layer address than Link-layer-CPE1, that means th= at > =A0 =A0 =A0there is possibly a conflict with another CPE, but that CPE di= d > =A0 =A0 =A0not perform DAD. =A0This situation is out of the scope of this > =A0 =A0 =A0document, since one assumption made above is that all the node= s of > =A0 =A0 =A0a point-to-multipoint domain (except the DAD proxy itself) per= form > =A0 =A0 =A0DAD. =A0This case could be covered in the future by additional > =A0 =A0 =A0solutions that work in conjunction with the DAD proxy. > > > > Would it be an intermediate solution to delete all "possibly wrong" entri= es > and/or log an error message? Maybe but, if we say that this scenario (not all nodes perform DAD) is in the scope of this draft, there are probably many other things to consider. So IMHO this scenario deserves another draft. The easy solutions like deleting all "possibly wrong" entries might have side effects if not studied in details. Thanks again for your comments/questions. Best regards. JMC, on behalf of the authors. > > > > -- > Tassos > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jmh@joelhalpern.com Tue Apr 24 09:45: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 05E0A21F8709 for ; Tue, 24 Apr 2012 09:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 fBuCh+ovrYw3 for ; Tue, 24 Apr 2012 09:45:18 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE5721F8702 for ; Tue, 24 Apr 2012 09:45:18 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 1DB85557FE7 for ; Tue, 24 Apr 2012 09:45:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CF50B121F46; Tue, 24 Apr 2012 09:45:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 3076C121F45; Tue, 24 Apr 2012 09:45:17 -0700 (PDT) Message-ID: <4F96D8A1.3020300@joelhalpern.com> Date: Tue, 24 Apr 2012 12:45:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Bob Hinden Subject: Re: 6MAN WG Last Call: References: <036E1A9D-88D9-4B1B-A7B1-FF4A624C5E13@gmail.com> In-Reply-To: <036E1A9D-88D9-4B1B-A7B1-FF4A624C5E13@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org Mailing List" 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, 24 Apr 2012 16:45:19 -0000 I strongly support the publication of this document as a proposed standard (and the accompanying informational analysis as an informational RFC). The analysis captures the issues, and the modification relaxes the existing rules in important cases where it is indeed safe to do so. Thank you, Joel M. Halpern On 4/19/2012 11:40 AM, Bob Hinden wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > 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 > > http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-02 > > as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on May 3, 2012. > > Regards, > Ole Troan& Bob Hinden > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From cabo@tzi.org Wed Apr 25 09:17: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 2A38821F8704 for ; Wed, 25 Apr 2012 09:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.988 X-Spam-Level: X-Spam-Status: No, score=-105.988 tagged_above=-999 required=5 tests=[AWL=0.261, 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 TX8P+2ZODyfB for ; Wed, 25 Apr 2012 09:17:05 -0700 (PDT) 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 2A33F21F861A for ; Wed, 25 Apr 2012 09:17:04 -0700 (PDT) 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 q3PGH0bt014977; Wed, 25 Apr 2012 18:17:00 +0200 (CEST) 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 C398A6D5; Wed, 25 Apr 2012 18:17:00 +0200 (CEST) Subject: Adaptation Layer Fragmentation Indication Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann Date: Wed, 25 Apr 2012 18:17:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82D75487-7F38-4A6C-8508-CA5729651A82@tzi.org> References: <20120425155002.8745.92783.idtracker@ietfa.amsl.com> To: intarea@ietf.org 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, 25 Apr 2012 16:17:06 -0000 I have written a small Internet-Draft that addresses a long-standing = problem in the 6lowpan space. As usual, it is on the boundary between = 6man and intarea, but I think the general considerations behind this fit = intarea a bit better. I don't see a need to push this specification forward at great speed, = but there have been discussions in other spaces that appear to make it = useful to have this facility. If you are interested in constrained = networks, please have a look, and comment to the list. http://tools.ietf.org/html/draft-bormann-intarea-alfi Gr=FC=DFe, Carsten Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-bormann-intarea-alfi-00.txt > Date: April 25, 2012 17:50:02 +0200 > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Adaptation Layer Fragmentation Indication > Author(s) : Carsten Bormann > Filename : draft-bormann-intarea-alfi-00.txt > Pages : 13 > Date : 2012-04-25 >=20 > IPv6 defines a minimum MTU of 1280 bytes. Many link layers are more > limited in their choice of packet size. Typically, IP adaptation > layers for these link layers define a segmentation or fragmentation > scheme to transport larger IP packets in multiple link layer = packets. >=20 > Often, adaption layer fragmentation schemes reduce some performance > metric, such as the packet delivery rate. Where application or > transport protocols have a choice, it would therefore be desirable > for them to know about any adaptation layer fragmentation that is > going on, so they can choose packet sizes that minimize adaptation > layer fragmentation. >=20 > At the IP layer, fragmentation can be detected using a number of > mechanisms used in Packetization Layer Path MTU Discovery [RFC4821]. > However, adaptation later fragmentation schemes are often designed = to > be "transparent", i.e. there is no way at higher layers to find out > they had to be employed (except maybe by elaborate measurement > schemes targeting one of the impacted performance metrics; this > approach does not appear to be viable) [WEI]. >=20 > The present specification defines a mechanism for IPv6 adaptation > layers to indicate the presence of adaptation layer fragmentation, = as > well as an indication of preferred packet sizes. >=20 > The main objective of this version of the draft is to present a > complete design in order to be able to gauge the complexity of the > approach against the gains to be expected from implementing it. >=20 > Comments are appreciated and should go to the intarea@ietf.org > mailing list. From tsavo.stds@gmail.com Thu Apr 26 02:09: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 A040621F86E5 for ; Thu, 26 Apr 2012 02:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 ANZdKImO0LS0 for ; Thu, 26 Apr 2012 02:09:28 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED1B21F86E2 for ; Thu, 26 Apr 2012 02:09:28 -0700 (PDT) Received: by dady13 with SMTP id y13so1951369dad.27 for ; Thu, 26 Apr 2012 02:09:28 -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=7cYarMUULVGLhgljRNHhoW6V5/XzGHG1WeYoGdBUr3E=; b=0hx07IzN+chANzaVKYix/emhOG0JVm1+Sl+REuKNdN2ICF5pwZPwFcKWEMb972BE0/ FJZnHvlgvjx9wlmBmfRwTu98qG43fkBu6cctwo0d7XoUq2fz69ENqoE0ZoJyvQTdCB0h ThBDzp1wSpmG/H1HsruqpxHBtVrdEHnAwbe3SsAujbUyVkv9vvKAqyfScm+ngTsAsFV6 5zPzurMvxJV9ktOZMUVQ+snLau5nCO57+9lBHj2UkGu8xZsxg7LZJ0+KfuQVAOrljsj9 jaIx9U6ulw/PJhgiyR5VN+3YPk8JNVKOyXho6m7OibfJC/AkkiQlYlMZ2WzR8loKc3J/ GdBg== MIME-Version: 1.0 Received: by 10.68.134.232 with SMTP id pn8mr7640058pbb.106.1335431368230; Thu, 26 Apr 2012 02:09:28 -0700 (PDT) Received: by 10.68.49.166 with HTTP; Thu, 26 Apr 2012 02:09:28 -0700 (PDT) In-Reply-To: <1334869802.14403.20.camel@dragon.pavlix.net> References: <1334869802.14403.20.camel@dragon.pavlix.net> Date: Thu, 26 Apr 2012 12:09:28 +0300 Message-ID: Subject: Re: question on RDNSS, RFC 6106 part 5.1 From: Teemu Savolainen To: =?UTF-8?Q?Pavel_=C5=A0imerda?= Content-Type: multipart/alternative; boundary=047d7b10c86153485004be9158d4 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, 26 Apr 2012 09:09:29 -0000 --047d7b10c86153485004be9158d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, We have seen this same problem as well. Does anyone have any idea why the lifetime is bound with SHOULD to this very short time period? For example, if the Lifetime =3D=3D MaxRtrAdvInterv= al, a host often would effectively be forced to send RS to refresh the RDNSS information before RDNSS expiration? Also in Lifetime =3D=3D 2*MaxRtrAdvInterval, a single lost RA (or in some case maybe two) could force host to send RS. Another question is that does anyone know why the time for sending RS is not specified? To help avoid simultaneous sending of RS by many hosts (if nobody got periodic RA)? I.e. could it be, say, 1.7*MaxRtrAdvInterval with random(0.2*MaxRtAdvInterval) delay to avoid hosts sending RS'es simultaneously? If this is agreed to be an issue, could we do ERRATA that extends the lifetime and specifies better when RS should be sent for information refreshing? Best regards, Teemu 20. huhtikuuta 2012 0.10 Pavel =C5=A0imerda kirjoitti: > Hello, > > I'm starting my work on linux NetworkManager. I've been following > several bugreports during the recent months that all lead to problems > with maintaining the list of recursive nameservers. > > I've already spent quite some time analyzing RDNSS problems and I came > to a conclusion that the problem actually lives in the RFC itself. > > Please look at section 5.1. in RFC 6106. It states: > > MaxRtrAdvInterval <=3D Lifetime <=3D 2*MaxRtrAdvInterval > > Considering MaxRtrAdvInterval the maximum time between RAs, setting > Lifetime to MaxRtrAdvInterval IMO constitutes a race condition. > Moreover, any Lifetime in this interval can timeout with just one or two > lost RAs. > > This makes RA-based IPv6-only networks drop RDNSS regularly. In many > implementations IPv6 and IPv4 are bound together so that if one of them > fails, the whole link is restarted. This is also the case in > NetworkManager. > > In the current situation, it's not advisable to use RFC 6106 in > production because it can cause problems even to IPv4 applications. > > In the real world, radvd uses Lifetime=3DMaxRtrAdvInterval by default and > NetworkManager internally adds 10s to the lifetime, that only helps to > avoid the race condition but not lost packets that are common on > wireless networks. > > I appreciate any help to get this right both in the standards and in the > software. > > Cheers, > > Pavel =C5=A0imerda > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b10c86153485004be9158d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We have seen this same problem as wel= l.

Does anyone have any idea why the lifetime is bound with SHOULD t= o this very short time period? For example, if the Lifetime =3D=3D MaxRtrAd= vInterval, a host often would effectively be forced to send RS to refresh t= he RDNSS information before RDNSS expiration? Also in Lifetime =3D=3D 2*Max= RtrAdvInterval, a single lost RA (or in some case maybe two) could force ho= st to send RS.

Another question is that does anyone know why the time for sending RS i= s not specified? To help avoid simultaneous sending of RS by many hosts (if= nobody got periodic RA)? I.e. could it be, say, 1.7*MaxRtrAdvInterval with= random(0.2*MaxRtAdvInterval) delay to avoid hosts sending RS'es simult= aneously?

If this is agreed to be an issue, could we do ERRATA that extends the l= ifetime and specifies better when RS should be sent for information refresh= ing?

Best regards,

Teemu





20. huhtikuuta 2012 0.10 Pavel =C5=A0imerda <pavlix@pavlix.net> kirjoitti:
Hello,

I'm starting my work on linux NetworkManager. I've been following several bugreports during the recent months that all lead to problems
with maintaining the list of recursive nameservers.

I've already spent quite some time analyzing RDNSS problems and I came<= br> to a conclusion that the problem actually lives in the RFC itself.

Please look at section 5.1. in RFC 6106. It states:

MaxRtrAdvInterval <=3D Lifetime <=3D 2*MaxRtrAdvInterval

Considering MaxRtrAdvInterval the maximum time between RAs, setting
Lifetime to MaxRtrAdvInterval IMO constitutes a race condition.
Moreover, any Lifetime in this interval can timeout with just one or two lost RAs.

This makes RA-based IPv6-only networks drop RDNSS regularly. In many
implementations IPv6 and IPv4 are bound together so that if one of them
fails, the whole link is restarted. This is also the case in
NetworkManager.

In the current situation, it's not advisable to use RFC 6106 in
production because it can cause problems even to IPv4 applications.

In the real world, radvd uses Lifetime=3DMaxRtrAdvInterval by default and NetworkManager internally adds 10s to the lifetime, that only helps to
avoid the race condition but not lost packets that are common on
wireless networks.

I appreciate any help to get this right both in the standards and in the software.

Cheers,

Pavel =C5=A0imerda

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

--047d7b10c86153485004be9158d4-- From ichiroumakino@gmail.com Thu Apr 26 04:51: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 438E421F8599 for ; Thu, 26 Apr 2012 04:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[AWL=0.244, 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 Gxkvj37kRQQh for ; Thu, 26 Apr 2012 04:51:00 -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 64C2A21F8595 for ; Thu, 26 Apr 2012 04:50:59 -0700 (PDT) Received: by werb10 with SMTP id b10so860613wer.31 for ; Thu, 26 Apr 2012 04:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PkJIRwFr8dEOdwrvYYFKSs3BpnluYNbfRWKXq8VS1pY=; b=pMarIniD9vuIOU7S1bW3S44s3/BLyieWOF6qAjG79R3u2qzLPx3L7g85oXHZo8B2HN 1SKqxhuQ32NqDcmRKd3b7fUvvyST3HFF+u9YFmotXOnQN8HzX5ZzMfEmm5Awd2SgdY/q gjJPiqMAdwYmKCkoXnytpf+42tm7RdYPGvhoE9iJttysISTeqAtvBkP1FlwFtU8ahaMp ByTAInKcLLj9UNhT6FPtZ94Eh5Ng4up7DkF1PuS0IeU/+C+n6m/+Si1qF2lAr6ooZriq CD4JwSMnaexEA3MtDe/p4+Sc67wTzA7f4R2Cw9eCm5pOyter4gc4NV5GShLlAFAq+Nha Q97Q== Received: by 10.181.12.82 with SMTP id eo18mr50849283wid.2.1335441058785; Thu, 26 Apr 2012 04:50:58 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-81.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm10297118wib.9.2012.04.26.04.50.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 04:50:58 -0700 (PDT) Sender: Ole Troan Subject: Re: 6MAN Minutes, Actions, and Document Status Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4F87BBD6.8090809@si6networks.com> Date: Thu, 26 Apr 2012 13:50:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5858DFD5-7A62-478E-8F13-B62CB02D3EE7@employees.org> References: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> <4F87BBD6.8090809@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1257) Cc: "ipv6@ietf.org Mailing List" , 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: Thu, 26 Apr 2012 11:51:01 -0000 Fernando, [...] > Some errata for the minutes: >=20 > The current text says: > ---- cut here ---- > Ole asked about how this was different from an unknown L4 header? >=20 > > ---- cut here ---- >=20 > There was an answer, so "" should probably be replaced with > something along the lines of "Fernando notes that having an unknown > extension header means that you have enough information to apply a > filtering policy, whereas if the full IPv6 header chain is missing, = you > don't have the necessary information to do it". thank you, I have updated the minutes. [...] > I think that draft-gont-6man-predictable-fragment-id is also ready for > wg call for adoption as wg document -- I've rev'ed the document since > IETF 83 in response to the feedback received during my presentation > (i.e., just require the Frag ID to be unpredictable, without mandating > any particular algorithm). the chairs have an action item on taking this to the mailing list. there was an issue that I believe Bob raised, if we were going to have = publish RFCs on every field in TCP/IP protocols that should have = unpredictable values, or if we should have a generic recommendation = applying to protocol design in general. > draft-gont-6man-oversized-header-chain is probably ready for wg call = for > adoption: I've rev the document in response to feedback during my > presentation at IETF 83 -- but I will check with Dave Thaler and Eric = if > they think the updated text is fine, or whether it needs some further > tweaking. please do. cheers, Ole From ichiroumakino@gmail.com Thu Apr 26 05:00: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 B65E621F8799 for ; Thu, 26 Apr 2012 05:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=0.220, 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 dBo7awifYK2m for ; Thu, 26 Apr 2012 05:00:38 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9BA321F877A for ; Thu, 26 Apr 2012 05:00:37 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so748734wgb.13 for ; Thu, 26 Apr 2012 05:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=lUK3wK2E+fc5DUJXWZKyCTrKtftKD0T5OeiAa1TCO/Y=; b=BWnSZ2kpzpOxYO4b+SKIV1bs9hu1ABEcp3n92oU90Zo9U8Gou29IuD6fBB0+XFpZo0 mxy9/U4qh9KKWgv1PfsuKFyPNUWBU3LYu57E0eA05v8GKCp5/QrrO14NBswTAqizDGFu 7xIaDvrjsX9UU+DqX+V8KnBr+KSzY45KKctdVTvZMIyUcaNTFzT0nUKyPgW1lO6BF5Fh 9POla7Uf7IqUHNsY+vvhktmkNUAbhleyK65LF3Rt+HRc0Siy+E+TuUHjSIWgJiB9jbhD 1Z6gdkbEwo0LMsisCl9tHWpgUfTqe8/f9CpMlO69UXOSHtBB80HArPouAWvl46occ2rn NKCQ== Received: by 10.180.92.71 with SMTP id ck7mr15436522wib.21.1335441636444; Thu, 26 Apr 2012 05:00:36 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-81.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm10370862wib.9.2012.04.26.05.00.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 05:00:35 -0700 (PDT) Sender: Ole Troan Subject: Re: question on RDNSS, RFC 6106 part 5.1 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <1334871165.15947.2.camel@dragon.pavlix.net> Date: Thu, 26 Apr 2012 14:00:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3556F78D-A80E-4975-8E87-3138E3DFCCAA@employees.org> References: <1334871165.15947.2.camel@dragon.pavlix.net> To: =?windows-1252?Q?Pavel_=8Aimerda?= 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: Thu, 26 Apr 2012 12:00:38 -0000 Pavel, I concur with your description of the problem. do you have a proposal for how it can be solved? Best regards, Ole On Apr 19, 2012, at 23:32 , Pavel =8Aimerda wrote: > Hello, >=20 > I'm starting my work on linux NetworkManager. I've been following > several bugreports during the recent months that all lead to problems > with maintaining the list of recursive nameservers. >=20 > I've already spent quite some time analyzing RDNSS problems and I came > to a conclusion that the problem actually lives in the RFC itself. >=20 > Please look at section 5.1. in RFC 6106. It states: >=20 > MaxRtrAdvInterval <=3D Lifetime <=3D 2*MaxRtrAdvInterval >=20 > Considering MaxRtrAdvInterval the maximum time between RAs, setting > Lifetime to MaxRtrAdvInterval IMO constitutes a race condition. > Moreover, any Lifetime in this interval can timeout with just one or = two > lost RAs. >=20 > This makes RA-based IPv6-only networks drop RDNSS regularly. In many > implementations IPv6 and IPv4 are bound together so that if one of = them > fails, the whole link is restarted. This is also the case in > NetworkManager. >=20 > In the current situation, it's not advisable to use RFC 6106 in > production because it can cause problems even to IPv4 applications. >=20 > In the real world, radvd uses Lifetime=3DMaxRtrAdvInterval by default = and > NetworkManager internally adds 10s to the lifetime, that only helps to > avoid the race condition but not lost packets that are common on > wireless networks. >=20 > I appreciate any help to get this right both in the standards and in = the > software. >=20 > Cheers, >=20 > Pavel =8Aimerda >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Thu Apr 26 16:55: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 C78C021E8041 for ; Thu, 26 Apr 2012 16:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.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 mgCHUKYuK-gF for ; Thu, 26 Apr 2012 16:55:21 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 399C021E8029 for ; Thu, 26 Apr 2012 16:55:21 -0700 (PDT) Received: from [190.190.97.123] (helo=[192.168.1.114]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SNYWi-0004SA-Fv; Fri, 27 Apr 2012 01:55:17 +0200 Message-ID: <4F99B5C8.1010108@si6networks.com> Date: Thu, 26 Apr 2012 17:53:28 -0300 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: =?ISO-8859-1?Q?Ole_Tr=F8an?= Subject: Re: 6MAN Minutes, Actions, and Document Status References: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> <4F87BBD6.8090809@si6networks.com> <5858DFD5-7A62-478E-8F13-B62CB02D3EE7@employees.org> In-Reply-To: <5858DFD5-7A62-478E-8F13-B62CB02D3EE7@employees.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org Mailing List" , 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: Thu, 26 Apr 2012 23:55:21 -0000 Hi, Ole, On 04/26/2012 08:50 AM, Ole Trøan wrote: >> I think that draft-gont-6man-predictable-fragment-id is also ready >> for wg call for adoption as wg document -- I've rev'ed the >> document since IETF 83 in response to the feedback received during >> my presentation (i.e., just require the Frag ID to be >> unpredictable, without mandating any particular algorithm). > > the chairs have an action item on taking this to the mailing list. > there was an issue that I believe Bob raised, if we were going to > have publish RFCs on every field in TCP/IP protocols that should > have unpredictable values, or if we should have a generic > recommendation applying to protocol design in general. I believe that a generic document about protocol design that discusses this issue would be valuable, such that *new* protocols and protocol implementations do not incur into this problem. However, in this particular case (Fragment ID), the IPv6 standard itself is suggesting to use a counter, and hence the spec should be fixed. That aside, different fields have different requirements. For example, the constraints for randomizing the transport protocol ports are different from those of producing unpredictable IDs, and different from those of say, randomizing the TCP sequence numbers, or randomizing the IPv6 Flow Label. The consequences of the particular approach that you follow vary quite a bit in each case. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bob.hinden@gmail.com Thu Apr 26 22:57: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 2BDBB21F86C6 for ; Thu, 26 Apr 2012 22:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.995 X-Spam-Level: X-Spam-Status: No, score=-102.995 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 X5OSQrmSQe08 for ; Thu, 26 Apr 2012 22:57:37 -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 8255721F86C4 for ; Thu, 26 Apr 2012 22:57:35 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so570866pbb.31 for ; Thu, 26 Apr 2012 22:57:35 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=faRTv+0x6aGowRCbykb7wQRJuYFeXbE4maABNHNDMpU=; b=O5sOImAy+32dqNFRGNXykZL+lm4qArQ07TB3msQgyBjdRecXd1i6bGxWLkvze8KcbM CtSM07hT9uhhIVyy4/EfjP8X8ckQ8hgLvnEiaOTSMM8oLPv1VGJc1zwZPgNd5LQE0xTz SHK1lml70R/aj5MDsJo8dMcceCr6ZfPcyqMGXS/1oGehPBPwDM9o5bXMZXfRpn5JrI8U Cn4Hap5biDHmKmjG7zTyThjYUI/2RBN5HkC2jdYIpkJPqZeOVmcloheNR5hBEGLU2v31 WaqYMKAA14PjUf+CDD0vR7gT67Kf1nYscLjvPo4vme0rDRYRvRKM47oxiEUeZ5dkK9NZ nMmA== Received: by 10.68.136.1 with SMTP id pw1mr21360115pbb.105.1335506255153; Thu, 26 Apr 2012 22:57:35 -0700 (PDT) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id hp1sm5464105pbc.67.2012.04.26.22.57.33 (version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 22:57:33 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Thu, 26 Apr 2012 16:36:35 -0700 Message-Id: <577622DC-EC39-47E6-82AB-B4369B6FA31D@gmail.com> To: IPv6 WG Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: 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, 27 Apr 2012 05:57:38 -0000 All, This message starts a two week 6MAN Working Group last call on = advancing: 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 http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-02.txt as a Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on May 10, 2012. Regards, Ole Troan & Bob Hinden 6man chairs From ichiroumakino@gmail.com Fri Apr 27 01: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 D595421F86A0 for ; Fri, 27 Apr 2012 01:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=0.167, 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 b7y1oxLs7rYf for ; Fri, 27 Apr 2012 01:21:53 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3098A21F869D for ; Fri, 27 Apr 2012 01:21:52 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so301943wgb.13 for ; Fri, 27 Apr 2012 01:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jB0WlJAKtq8ag2Y4sk1CvgYT3GH+ab6a8WbMTRaY1Xg=; b=GJ2qBxPMd/qSWgffRFX/bhSfXvoLvng+n43vdT1KES9TtGbc4kF9B2sFKw2Sta8C0k UmDUBHUb3fENagfZ7ZiuTuLwO1eOttSFgRL5oPTajaobxQm3Fr/NcMVT8yI5R+OsOfB5 QB7MdBPs1yMyaIRPyOwfK9xEnKSfDs6GT70Vzfxsek6z+RW0nE6PiaAPwEgMokVRr6h+ jOOsQNVPsw1z2rQZkcZNfaYa42a3EzzLwTZ498E/UjRRBYcaEhL4Twvd+zRkZpai4j0k anFi7YDNz13otUYwcSpHdgbmbR9CHvqQ5FKbykk+6GI/YvKIXz/v7qQJLEhDPn1UdFE8 V35A== Received: by 10.216.134.226 with SMTP id s76mr6266427wei.115.1335514911302; Fri, 27 Apr 2012 01:21:51 -0700 (PDT) Received: from dhcp-10-61-99-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e6sm3000966wix.8.2012.04.27.01.21.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 01:21:50 -0700 (PDT) Sender: Ole Troan Subject: Predictable IP protocol values Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4F99B5C8.1010108@si6networks.com> Date: Fri, 27 Apr 2012 10:21:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E6FD71A-0A84-4B20-AF5A-16DCBCD7ED76@employees.org> References: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> <4F87BBD6.8090809@si6networks.com> <5858DFD5-7A62-478E-8F13-B62CB02D3EE7@employees.org> <4F99B5C8.1010108@si6networks.com> To: "ipv6@ietf.org Mailing List" X-Mailer: Apple Mail (2.1257) Cc: Fernando Gont , 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, 27 Apr 2012 08:21:56 -0000 working group, [changed subject] in the context of = http://tools.ietf.org/html/draft-gont-6man-predictable-fragment-id-02 any opinion on how to proceed? - document covering predictable values in IETF protocols in general - document predictable IP ID fields in both IPv4 and IPv6 - fix the predictable fragment ID problem in IPv6 - do nothing? cheers, Ole On Apr 26, 2012, at 22:53 , Fernando Gont wrote: > Hi, Ole, >=20 > On 04/26/2012 08:50 AM, Ole Tr=F8an wrote: >>> I think that draft-gont-6man-predictable-fragment-id is also ready=20= >>> for wg call for adoption as wg document -- I've rev'ed the >>> document since IETF 83 in response to the feedback received during >>> my presentation (i.e., just require the Frag ID to be >>> unpredictable, without mandating any particular algorithm). >>=20 >> the chairs have an action item on taking this to the mailing list.=20 >> there was an issue that I believe Bob raised, if we were going to=20 >> have publish RFCs on every field in TCP/IP protocols that should >> have unpredictable values, or if we should have a generic >> recommendation applying to protocol design in general. >=20 > I believe that a generic document about protocol design that discusses > this issue would be valuable, such that *new* protocols and protocol > implementations do not incur into this problem. However, in this > particular case (Fragment ID), the IPv6 standard itself is suggesting > to use a counter, and hence the spec should be fixed. >=20 > That aside, different fields have different requirements. For example, > the constraints for randomizing the transport protocol ports are > different from those of producing unpredictable IDs, and different = from > those of say, randomizing the TCP sequence numbers, or randomizing the > IPv6 Flow Label. The consequences of the particular approach that you > follow vary quite a bit in each case. >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 From pavlix@pavlix.net Fri Apr 27 08:25: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 2A85621F8795 for ; Fri, 27 Apr 2012 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 YXipCbDGuA2r for ; Fri, 27 Apr 2012 08:25:41 -0700 (PDT) Received: from fox.pavlix.net (fox.pavlix.net [84.246.161.104]) by ietfa.amsl.com (Postfix) with ESMTP id 95C8A21F8794 for ; Fri, 27 Apr 2012 08:25:41 -0700 (PDT) Received: from [192.168.10.40] (unknown [127.0.0.1]) by fox.pavlix.net (Postfix) with ESMTPSA id A33AC1760BFF; Fri, 27 Apr 2012 17:25:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pavlix.net; s=default; t=1335540340; bh=2P33dZQYOMZk7RNkAdqLdBdGlecxXa+BUCln071pzlM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:Content-Transfer-Encoding:Mime-Version; b=naX4q72NKJxrY/Ym8gEjijm6cCC6R/FKqroXHk1GkZuIvWfB7JLrUDNhRfY2stPNS wEWIlN9qubmcL4WoerSSTgFAhdoUELx2Z8+U9RZ2TlwtBgO3A3qU7WyJkgKIpb4mEp bIwqDinCRmOpjzwLEH1azPOawcrJsb/106ifPm/Y= Message-ID: <1335540337.8823.54.camel@dragon.pavlix.net> Subject: Re: question on RDNSS, RFC 6106 part 5.1 From: Pavel Simerda To: Ole =?ISO-8859-1?Q?Tr=F8an?= Date: Fri, 27 Apr 2012 17:25:37 +0200 In-Reply-To: <3556F78D-A80E-4975-8E87-3138E3DFCCAA@employees.org> References: <1334871165.15947.2.camel@dragon.pavlix.net> <3556F78D-A80E-4975-8E87-3138E3DFCCAA@employees.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.1 (3.4.1-1.fc17) Content-Transfer-Encoding: 8bit Mime-Version: 1.0 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, 27 Apr 2012 15:25:43 -0000 Hello, my proposition is the same as Teemu's or very similar. 1) I propose to change the default Lifetime from [MaxRtrAdvInterval, 2*MaxRtrAdvInterva] to a single agreed-upon recommended default value. Almost nobody would need to change this default value. 5*MaxRtrAdvInterval is IMO a good value to start with. This should be enough to avoid the need to send RS. 2) I propose to add at least some best practice about router solicitations. Typically, RS should only be used as a last resort. I suggest to start sending RS at 0.8*Lifetime +/- 0.1*Lifetime (if sending RS at all) and repeat let's say every 10-20 seconds. Note: Please remember that wireless links *sometimes* lose packets. Please remember that wireless links *often* lose multicast packets. Even some ethernet switches do. Example: MaxRtrAdvInterval = 10 minutes AdvRDNSSLifetime = (Default) 5*MaxRtrAdvInterval = 50 minutes 0.8*Lifetime = 40 minutes 0.1*Lifetime = 5 minutes Let's simplify the situation and act as if MaxRtrAdvInterval is the absolute interval (it is not!). 00:00 Router Advertisement, Lifetime = 50 minutes 00:10 Lifetime = 40 minutes (it could already time out according to the current RFC) 00:10 Router Advertisement (lost) 00:20 Lifetime = 30 minutes 00:20 Router Advertisement (lost again) 00:30 Lifetime = 20 minutes 00:30 Router Advertisement (lost the third time!) 00:35 Lifetime = 15 minutes 00:35 This is the first time RS can be sent with this best practice (the last time is 00:45, counted like that 0.8*00:50 +/- 0.1*00:50) 00:35 Router Solicitation Since then, router solicitations would be issued regularly until client recieves RA with RDNSS, connection is cancelled by user or: 00:50 Lifetime = 0 00:50 RDNSS expired Note: It is not perfect. The concept of finitely valid RDNSS is quite new. There is an open question, when to consider RDNSS information lost. It could be: 1) Last RDNSS from RAs expired. 2) Last IPv6 RDNSS expired (RDNSS or DHCPv6) 3) Last RDNSS lost (IPv6 or IPv4) Pavel Simerda On Thu, 2012-04-26 at 14:00 +0200, Ole Trøan wrote: > Pavel, > > I concur with your description of the problem. > do you have a proposal for how it can be solved? > > Best regards, > Ole > > > On Apr 19, 2012, at 23:32 , Pavel Å imerda wrote: > > > Hello, > > > > I'm starting my work on linux NetworkManager. I've been following > > several bugreports during the recent months that all lead to problems > > with maintaining the list of recursive nameservers. > > > > I've already spent quite some time analyzing RDNSS problems and I came > > to a conclusion that the problem actually lives in the RFC itself. > > > > Please look at section 5.1. in RFC 6106. It states: > > > > MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval > > > > Considering MaxRtrAdvInterval the maximum time between RAs, setting > > Lifetime to MaxRtrAdvInterval IMO constitutes a race condition. > > Moreover, any Lifetime in this interval can timeout with just one or two > > lost RAs. > > > > This makes RA-based IPv6-only networks drop RDNSS regularly. In many > > implementations IPv6 and IPv4 are bound together so that if one of them > > fails, the whole link is restarted. This is also the case in > > NetworkManager. > > > > In the current situation, it's not advisable to use RFC 6106 in > > production because it can cause problems even to IPv4 applications. > > > > In the real world, radvd uses Lifetime=MaxRtrAdvInterval by default and > > NetworkManager internally adds 10s to the lifetime, that only helps to > > avoid the race condition but not lost packets that are common on > > wireless networks. > > > > I appreciate any help to get this right both in the standards and in the > > software. > > > > Cheers, > > > > Pavel Å imerda > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > From pavlix@pavlix.net Fri Apr 27 08:27: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 82DB721F8685 for ; Fri, 27 Apr 2012 08:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 UJft6jgoMtmP for ; Fri, 27 Apr 2012 08:27:33 -0700 (PDT) Received: from fox.pavlix.net (fox.pavlix.net [84.246.161.104]) by ietfa.amsl.com (Postfix) with ESMTP id 96FBE21F87B6 for ; Fri, 27 Apr 2012 08:27:33 -0700 (PDT) Received: from [192.168.10.40] (unknown [127.0.0.1]) by fox.pavlix.net (Postfix) with ESMTPSA id 1891F1760BFF; Fri, 27 Apr 2012 17:27:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pavlix.net; s=default; t=1335540452; bh=2P33dZQYOMZk7RNkAdqLdBdGlecxXa+BUCln071pzlM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:Content-Transfer-Encoding:Mime-Version; b=e1Mjzgujlmc47xybQLzH6auDv97kyaAS0+4I9aQtayNmDlJ6P2BrUANU+oO8WnONe mI+fJfm9VFPEHOk2sWXJgJpOEDybemzFrd4LGnga6p/18Rfg4bM/5Oaoqw2BAF4FKu ErO16wxD1EtSYJnNBIuO9QPmHPQo/qhUUgRnFQxM= Message-ID: <1335540450.12143.0.camel@dragon.pavlix.net> Subject: Re: question on RDNSS, RFC 6106 part 5.1 From: Pavel Simerda To: Ole =?ISO-8859-1?Q?Tr=F8an?= Date: Fri, 27 Apr 2012 17:27:30 +0200 In-Reply-To: <3556F78D-A80E-4975-8E87-3138E3DFCCAA@employees.org> References: <1334871165.15947.2.camel@dragon.pavlix.net> <3556F78D-A80E-4975-8E87-3138E3DFCCAA@employees.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.1 (3.4.1-1.fc17) Content-Transfer-Encoding: 8bit Mime-Version: 1.0 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, 27 Apr 2012 15:27:34 -0000 Hello, my proposition is the same as Teemu's or very similar. 1) I propose to change the default Lifetime from [MaxRtrAdvInterval, 2*MaxRtrAdvInterva] to a single agreed-upon recommended default value. Almost nobody would need to change this default value. 5*MaxRtrAdvInterval is IMO a good value to start with. This should be enough to avoid the need to send RS. 2) I propose to add at least some best practice about router solicitations. Typically, RS should only be used as a last resort. I suggest to start sending RS at 0.8*Lifetime +/- 0.1*Lifetime (if sending RS at all) and repeat let's say every 10-20 seconds. Note: Please remember that wireless links *sometimes* lose packets. Please remember that wireless links *often* lose multicast packets. Even some ethernet switches do. Example: MaxRtrAdvInterval = 10 minutes AdvRDNSSLifetime = (Default) 5*MaxRtrAdvInterval = 50 minutes 0.8*Lifetime = 40 minutes 0.1*Lifetime = 5 minutes Let's simplify the situation and act as if MaxRtrAdvInterval is the absolute interval (it is not!). 00:00 Router Advertisement, Lifetime = 50 minutes 00:10 Lifetime = 40 minutes (it could already time out according to the current RFC) 00:10 Router Advertisement (lost) 00:20 Lifetime = 30 minutes 00:20 Router Advertisement (lost again) 00:30 Lifetime = 20 minutes 00:30 Router Advertisement (lost the third time!) 00:35 Lifetime = 15 minutes 00:35 This is the first time RS can be sent with this best practice (the last time is 00:45, counted like that 0.8*00:50 +/- 0.1*00:50) 00:35 Router Solicitation Since then, router solicitations would be issued regularly until client recieves RA with RDNSS, connection is cancelled by user or: 00:50 Lifetime = 0 00:50 RDNSS expired Note: It is not perfect. The concept of finitely valid RDNSS is quite new. There is an open question, when to consider RDNSS information lost. It could be: 1) Last RDNSS from RAs expired. 2) Last IPv6 RDNSS expired (RDNSS or DHCPv6) 3) Last RDNSS lost (IPv6 or IPv4) Pavel Simerda On Thu, 2012-04-26 at 14:00 +0200, Ole Trøan wrote: > Pavel, > > I concur with your description of the problem. > do you have a proposal for how it can be solved? > > Best regards, > Ole > > > On Apr 19, 2012, at 23:32 , Pavel Å imerda wrote: > > > Hello, > > > > I'm starting my work on linux NetworkManager. I've been following > > several bugreports during the recent months that all lead to problems > > with maintaining the list of recursive nameservers. > > > > I've already spent quite some time analyzing RDNSS problems and I came > > to a conclusion that the problem actually lives in the RFC itself. > > > > Please look at section 5.1. in RFC 6106. It states: > > > > MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval > > > > Considering MaxRtrAdvInterval the maximum time between RAs, setting > > Lifetime to MaxRtrAdvInterval IMO constitutes a race condition. > > Moreover, any Lifetime in this interval can timeout with just one or two > > lost RAs. > > > > This makes RA-based IPv6-only networks drop RDNSS regularly. In many > > implementations IPv6 and IPv4 are bound together so that if one of them > > fails, the whole link is restarted. This is also the case in > > NetworkManager. > > > > In the current situation, it's not advisable to use RFC 6106 in > > production because it can cause problems even to IPv4 applications. > > > > In the real world, radvd uses Lifetime=MaxRtrAdvInterval by default and > > NetworkManager internally adds 10s to the lifetime, that only helps to > > avoid the race condition but not lost packets that are common on > > wireless networks. > > > > I appreciate any help to get this right both in the standards and in the > > software. > > > > Cheers, > > > > Pavel Å imerda > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > From bob.hinden@gmail.com Fri Apr 27 13:13: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 E82F121F8646; Fri, 27 Apr 2012 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 Q4kpEw6UP4GB; Fri, 27 Apr 2012 13:13:34 -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 E29FE21F8642; Fri, 27 Apr 2012 13:13:33 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1400064pbb.31 for ; Fri, 27 Apr 2012 13:13:33 -0700 (PDT) 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 :cc:to:mime-version:x-mailer; bh=EnfxWM0D2SHNWtivtjfGf76Ha8PfaFvYTwLz/hFjsXc=; b=n0aWB7sneVOihCkq2/bgJ6YGlK3c5dPsT37gNTH1X+oOBQZmfXsOvyGm/vpk7XctGk WMB7U5R7ASkW5cByLaMTWkydIcXAHWeosH++iuqj1rxrGz0/xpUVU0XZ1DM8IUURU8Jd mXS/S24hnyQsYSxISWVqqbKwGI6k1rstBLVevjnP5xYuLepXHIn3nwurh8m9lrPHj50n FD9Sx35NcicW52FzqMNrY3RP4m5RhGJYNzUvSEyhw2/yJ+w3YPRUTi5f7lMKH5CVyCle 8tnTpadYKJFZQ9H1Mn/2s8wlOimEI9mXge0HpJEi+EJhJCsJE5PMxMTjskqh2uxMe0cP KREQ== Received: by 10.68.244.102 with SMTP id xf6mr3300882pbc.115.1335557613739; Fri, 27 Apr 2012 13:13:33 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id 2sm7378192pbw.57.2012.04.27.13.13.31 (version=SSLv3 cipher=OTHER); Fri, 27 Apr 2012 13:13:32 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Request To Advance: Date: Fri, 27 Apr 2012 13:13:24 -0700 Message-Id: To: Brian Haberman , Ralph Droms Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: iesg-secretary@ietf.org, Bob Hinden , 6man Mailing List 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, 27 Apr 2012 20:13:35 -0000 Brian & Ralph, On behalf of the 6MAN WG, the chairs request the advancement of: 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 as an Experimental RFC. A two week 6MAN working group last call was = completed on 17 November 2011 and a second one week last call ended on = 19 April 2012. The current draft resolves issues raised during to these = last calls. The chairs believe there is a consensus in the w.g. to move = this document forward. Regards, Bob Hinden & Ole Tr=F8an 6MAN chairs From fgont@si6networks.com Fri Apr 27 20:31: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 DF97221E8029 for ; Fri, 27 Apr 2012 20:31:29 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 r3Y1CpRbaMt2 for ; Fri, 27 Apr 2012 20:31:29 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB221E8027 for ; Fri, 27 Apr 2012 20:31:28 -0700 (PDT) Received: from [186.134.11.143] (helo=[192.168.123.103]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SNyNU-0002Lm-Bb; Sat, 28 Apr 2012 05:31:20 +0200 Message-ID: <4F9B61E5.1020109@si6networks.com> Date: Sat, 28 Apr 2012 00:20:05 -0300 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: =?ISO-8859-1?Q?Ole_Tr=F8an?= Subject: Re: Predictable IP protocol values References: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> <4F87BBD6.8090809@si6networks.com> <5858DFD5-7A62-478E-8F13-B62CB02D3EE7@employees.org> <4F99B5C8.1010108@si6networks.com> <5E6FD71A-0A84-4B20-AF5A-16DCBCD7ED76@employees.org> In-Reply-To: <5E6FD71A-0A84-4B20-AF5A-16DCBCD7ED76@employees.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Bob Hinden , "ipv6@ietf.org Mailing List" 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, 28 Apr 2012 03:31:30 -0000 Hi, Ole, On 04/27/2012 05:21 AM, Ole Trøan wrote: > working group, > > [changed subject] > > in the context of http://tools.ietf.org/html/draft-gont-6man-predictable-fragment-id-02 > any opinion on how to proceed? > > - document covering predictable values in IETF protocols in general I don't think such a document could formally update in protocol that should be using unpredictable IDs, since the contraints are different for each protocol. > - document predictable IP ID fields in both IPv4 and IPv6 This one *could* make sense, however, the constraints are somewhat different, and procedurally-wise, it may be simpler to work on this I-D here, than having an I-D that spans 6man and intarea wg(?). > - fix the predictable fragment ID problem in IPv6 I'd obviously go with this one. > - do nothing? Hopefully not -- if we don't fix this, who would do it? -- Even vendors have been responsive to this I-D, so one would expect that we do something about it. 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 jmh@joelhalpern.com Sat Apr 28 13:27: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 974E021F8630 for ; Sat, 28 Apr 2012 13:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.218 X-Spam-Level: X-Spam-Status: No, score=-102.218 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 1XLoiVq9a5ft for ; Sat, 28 Apr 2012 13:27:40 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E927921F862B for ; Sat, 28 Apr 2012 13:27:39 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id B628FA3A49 for ; Sat, 28 Apr 2012 13:27:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 510801BD1FC8; Sat, 28 Apr 2012 13:27:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 434CA1BD1FC7; Sat, 28 Apr 2012 13:27:38 -0700 (PDT) Message-ID: <4F9C52EF.2080401@joelhalpern.com> Date: Sat, 28 Apr 2012 16:28:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Subject: Re: Predictable IP protocol values References: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> <4F87BBD6.8090809@si6networks.com> <5858DFD5-7A62-478E-8F13-B62CB02D3EE7@employees.org> <4F99B5C8.1010108@si6networks.com> <5E6FD71A-0A84-4B20-AF5A-16DCBCD7ED76@employees.org> In-Reply-To: <5E6FD71A-0A84-4B20-AF5A-16DCBCD7ED76@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Fernando Gont , "ipv6@ietf.org Mailing List" , 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, 28 Apr 2012 20:27:40 -0000 It seems to me that the proposed document is a partial fix to a marginal problem. Yes, I take it as given that if I followed the references I wind find descriptions of the attacks. I do see how one could force fragmented packets if one knew that A was talking to B at the current moment. However, it seems to me that in the vast majority of cases, if the attacker knows that A is talking to B, he can probably observe the packets between A and B (and it must be a conversation of many round trips to allow for observation, triggered behavior, and useful attack.) As such, none of the specified solutions would seem to help much. Hence, I am left concluding that the right answer is not to publish any recommendations in this space. Yours, Joel On 4/27/2012 4:21 AM, Ole Trøan wrote: > working group, > > [changed subject] > > in the context of http://tools.ietf.org/html/draft-gont-6man-predictable-fragment-id-02 > any opinion on how to proceed? > > - document covering predictable values in IETF protocols in general > - document predictable IP ID fields in both IPv4 and IPv6 > - fix the predictable fragment ID problem in IPv6 > - do nothing? > > cheers, > Ole > > > On Apr 26, 2012, at 22:53 , Fernando Gont wrote: > >> Hi, Ole, >> >> On 04/26/2012 08:50 AM, Ole Trøan wrote: >>>> I think that draft-gont-6man-predictable-fragment-id is also ready >>>> for wg call for adoption as wg document -- I've rev'ed the >>>> document since IETF 83 in response to the feedback received during >>>> my presentation (i.e., just require the Frag ID to be >>>> unpredictable, without mandating any particular algorithm). >>> >>> the chairs have an action item on taking this to the mailing list. >>> there was an issue that I believe Bob raised, if we were going to >>> have publish RFCs on every field in TCP/IP protocols that should >>> have unpredictable values, or if we should have a generic >>> recommendation applying to protocol design in general. >> >> I believe that a generic document about protocol design that discusses >> this issue would be valuable, such that *new* protocols and protocol >> implementations do not incur into this problem. However, in this >> particular case (Fragment ID), the IPv6 standard itself is suggesting >> to use a counter, and hence the spec should be fixed. >> >> That aside, different fields have different requirements. For example, >> the constraints for randomizing the transport protocol ports are >> different from those of producing unpredictable IDs, and different from >> those of say, randomizing the TCP sequence numbers, or randomizing the >> IPv6 Flow Label. The consequences of the particular approach that you >> follow vary quite a bit in each case. >> >> 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 fgont@si6networks.com Sat Apr 28 13:50: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 1D70121F8546 for ; Sat, 28 Apr 2012 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 XuRm3KvPOTze for ; Sat, 28 Apr 2012 13:50:18 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 78CF421F853D for ; Sat, 28 Apr 2012 13:50:17 -0700 (PDT) Received: from [186.134.11.143] (helo=[192.168.123.103]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SOEan-00010B-I7; Sat, 28 Apr 2012 22:50:10 +0200 Message-ID: <4F9C57EA.8040309@si6networks.com> Date: Sat, 28 Apr 2012 17:49:46 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Predictable IP protocol values References: <401EA98A-C229-4ED3-8CBE-3C6CAE5D37B7@gmail.com> <4F87BBD6.8090809@si6networks.com> <5858DFD5-7A62-478E-8F13-B62CB02D3EE7@employees.org> <4F99B5C8.1010108@si6networks.com> <5E6FD71A-0A84-4B20-AF5A-16DCBCD7ED76@employees.org> <4F9C52EF.2080401@joelhalpern.com> In-Reply-To: <4F9C52EF.2080401@joelhalpern.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , "ipv6@ietf.org Mailing List" , 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, 28 Apr 2012 20:50:19 -0000 On 04/28/2012 05:28 PM, Joel M. Halpern wrote: > It seems to me that the proposed document is a partial fix to a marginal > problem. > Yes, I take it as given that if I followed the references I wind find > descriptions of the attacks. I do see how one could force fragmented > packets if one knew that A was talking to B at the current moment. Just send an ICMPv6 PTB claiming an MTU smaller than 1280 bytes, and you're done. Now think about you favourite application running on two known systems. It just takes you one ICMPv6 PTB to trigger fragmentation, one ping6 to sample the Frag ID, and further (rather low-rate) fragments that will cause collisions, leading to DoS -- and it si very easy to maintaint that DoS state. Dumb/idle scans have also been well-known since the IPv4 era, and trivial to exploit (for instance, nmap implements this vector). We produced tools to test these things, and have been trying to help vendors. Most vendors cared (http://www.ietf.org/proceedings/83/slides/slides-83-6man-10.pdf), as they did at the time for IPv4 case. So IMO it would be weird for us to not be willing to do our part (maintain our specs), when others have done theirs (fix their implementations). Just my two cents. 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.e.carpenter@gmail.com Sun Apr 29 00:54: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 91DAD21F84F3 for ; Sun, 29 Apr 2012 00:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.522 X-Spam-Level: X-Spam-Status: No, score=-101.522 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, RCVD_ILLEGAL_IP=1.908, 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 oBn7WcV0HnaB for ; Sun, 29 Apr 2012 00:54:23 -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 A28DE21F84D3 for ; Sun, 29 Apr 2012 00:54:22 -0700 (PDT) Received: by werb10 with SMTP id b10so1540219wer.31 for ; Sun, 29 Apr 2012 00:54:21 -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=yj2EpPY3ZsBN1oU6lR5qy579vU3cqgcxCiBG+qEOiN4=; b=Z6/pGo+ZrUeJM6VUvFiy0C8cJ2B+leLPLwd5wlD0aDpOIweCf1jFqFlrfnnmbiiHKP NCHDQaGXf7jeSCe/WqIBB8nkTPi/C0IyY0Orek2ir8u/28eFp4o5e6IUN8MDQtP+8KZR iHnsuqOaYuWxPzm7rC4v9k3oeC1xnfuWcR+r8WfGHHoXaRlsfCRJdp/FOKdDn0scGevP k0U7FEarAOhPTPgmfHYGmidUe2dQmvcT2c1sZvkz9+HEdYOwjHBr5Us9xgvf4CMndBjl e6JlbS5xotR/rht0NvgVHKD+HDklV2XeQjv0wxe/Zx41hPUPSVyAnbXGSLDp2dfoFS+5 f/BQ== Received: by 10.216.135.206 with SMTP id u56mr10611677wei.29.1335686061770; Sun, 29 Apr 2012 00:54:21 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-73.as13285.net. [2.102.219.73]) by mx.google.com with ESMTPS id gd4sm29911931wib.6.2012.04.29.00.54.19 (version=SSLv3 cipher=OTHER); Sun, 29 Apr 2012 00:54:20 -0700 (PDT) Message-ID: <4F9CF3A8.7000801@gmail.com> Date: Sun, 29 Apr 2012 08:54:16 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Options for draft-ietf-6man-uri-zoneid 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, 29 Apr 2012 07:54:23 -0000 Hi, In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00, there was no clear consensus on the approach to pursue. In fact, almost the same discussion occurred around draft-fenner-literal-zone several years ago, but at that time the topic was simply dropped. This note summarises the main options. As a reminder, the problem to be solved is how to tell a browser which interface to use when sending packets to a literal link-local address. The reason for doing this is purely for diagnostic purposes, since the Zone ID that identifies an interface has no significance outside the sending host. For more details, see the two drafts mentioned above. What we have today: link local address with no Zone ID http://[fe80::a] The user cannot select the outgoing interface if there is more than one. The obvious solution would be to use the RFC4007 syntax (for an example Zone ID of en1): http://[fe80::a%en1] However, this is impossible because % is *always* an escape character in URI syntax [RFC3986]. There is no chance of the URI community accepting such a hack to the syntax, so it isn't an option for us. The available options are therefore 1) Leave the problem unsolved. This would mean that per-interface diagnostics would still have to be performed using ping or ping6 ping fe80::a%en1 Advantage: works today. Disadvantage: less convenient than using a browswer. 2) Escaping the escape character as allowed by RFC 3986: http://[fe80::a%25en1] Advantage: allows use of browser. Disadvantage: ugly and confusing, doesn't allow simple cut and paste. 3) With alternative separator such as _ http://[fe80::a_en1] Advantage: allows use of browser. Disadvantage: doesn't allow simple cut and paste. 4) With the "IPvFuture" syntax left open in RFC 3986: http://[v6.fe80::a_en1] Advantage: allows use of browser. Disadvantage: ugly and redundant, doesn't allow simple cut and paste. Thus, the WG has to choose between options 1), 2), 3) and 4). Opinions welcome! Brian Carpenter From j.schoenwaelder@jacobs-university.de Sun Apr 29 01:29: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 B9C8E21F8557 for ; Sun, 29 Apr 2012 01:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.094 X-Spam-Level: X-Spam-Status: No, score=-103.094 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTTP_ESCAPED_HOST=0.134, 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 6LGcYHGz0ZYr for ; Sun, 29 Apr 2012 01:29:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A512B21F8552 for ; Sun, 29 Apr 2012 01:29:44 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B23120C6B; Sun, 29 Apr 2012 10:29:43 +0200 (CEST) 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 7-OXDOqSaS2E; Sun, 29 Apr 2012 10:29:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1724720C6A; Sun, 29 Apr 2012 10:29:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DDA751EC2DA3; Sun, 29 Apr 2012 10:29:44 +0200 (CEST) Date: Sun, 29 Apr 2012 10:29:44 +0200 From: Juergen Schoenwaelder To: Brian E Carpenter Subject: Re: Options for draft-ietf-6man-uri-zoneid Message-ID: <20120429082944.GA92270@elstar.local> Mail-Followup-To: Brian E Carpenter , 6man References: <4F9CF3A8.7000801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9CF3A8.7000801@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 6man 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: Sun, 29 Apr 2012 08:29:45 -0000 On Sun, Apr 29, 2012 at 08:54:16AM +0100, Brian E Carpenter wrote: > Hi, > > In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00, > there was no clear consensus on the approach to pursue. In fact, > almost the same discussion occurred around draft-fenner-literal-zone > several years ago, but at that time the topic was simply dropped. > > This note summarises the main options. As a reminder, the problem to > be solved is how to tell a browser which interface to use when sending > packets to a literal link-local address. The reason for doing this is > purely for diagnostic purposes, since the Zone ID that identifies an > interface has no significance outside the sending host. For more details, > see the two drafts mentioned above. > > What we have today: link local address with no Zone ID > http://[fe80::a] > > The user cannot select the outgoing interface if there is more than one. > > The obvious solution would be to use the RFC4007 syntax (for an > example Zone ID of en1): > > http://[fe80::a%en1] > > However, this is impossible because % is *always* an escape character in > URI syntax [RFC3986]. There is no chance of the URI community accepting > such a hack to the syntax, so it isn't an option for us. > > The available options are therefore > > 1) Leave the problem unsolved. > > This would mean that per-interface diagnostics would still have to be > performed using ping or ping6 > > ping fe80::a%en1 > > Advantage: works today. > > Disadvantage: less convenient than using a browswer. > > 2) Escaping the escape character as allowed by RFC 3986: > > http://[fe80::a%25en1] > > Advantage: allows use of browser. > Disadvantage: ugly and confusing, doesn't allow simple cut and paste. > > 3) With alternative separator such as _ > > http://[fe80::a_en1] > > Advantage: allows use of browser. > Disadvantage: doesn't allow simple cut and paste. > > 4) With the "IPvFuture" syntax left open in RFC 3986: > > http://[v6.fe80::a_en1] > > Advantage: allows use of browser. > Disadvantage: ugly and redundant, doesn't allow simple cut and paste. > > Thus, the WG has to choose between options 1), 2), 3) and 4). If we want to solve this at all, I think 2) is the way to go since this format is after all easier to understand than format 3) or 4), which add yet another notation, and also because there might be other characters in the zone ID that need escaping as well. And since URLs are used not just by plain good old http and web browsers, I think we will have to find and document a common solution for this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf.interest@gmail.com Sun Apr 29 05:54: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 60DCC21F8540 for ; Sun, 29 Apr 2012 05:54:53 -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 EAdlS3c5ch5a for ; Sun, 29 Apr 2012 05:54:52 -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 A5CCE21F8531 for ; Sun, 29 Apr 2012 05:54:52 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1200609ghb.31 for ; Sun, 29 Apr 2012 05:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mc3KN7E1VV/jUim13QBC7MMHhIWFMRDChbyRKTldNUw=; b=ba374ZvxKA895qb+7DorhEnEC/SIXY0Ah6Y1JH5+QyeHOH9HqDN23XytYpGO+c1YU5 tZkxM+5e2tlI9eg5A7pZuBkQX7d8SlLbg3PJGhHD94y9WcZXOwk3WazxCHDnv8C2ryji vlQV0Qk/LSmwgaTJFTMgRUgka6C+cJx5InbTBBe8IY3MywMqA7AB1r4rZS1hedEdlX1B Tsqj6cTPyiWeuF7dq1OmwT0CllfFvBvYdV7zYbMSqwTvuxc4AyQRUssSyrbfn18SBHgC 3CWnVq18wiwGG6vPqzO86z7s8VCQ1Tee9+g3/FYZ6l85cOBw8Rt20D53JCammmqmjK8q hFsQ== MIME-Version: 1.0 Received: by 10.236.73.195 with SMTP id v43mr18591297yhd.78.1335704092325; Sun, 29 Apr 2012 05:54:52 -0700 (PDT) Received: by 10.146.112.18 with HTTP; Sun, 29 Apr 2012 05:54:52 -0700 (PDT) Date: Sun, 29 Apr 2012 18:24:52 +0530 Message-ID: Subject: Neighbor Unreachability Detection.. From: Somasundaram Selvaraj To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=20cf300512f2f2b91604bed0d71f 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, 29 Apr 2012 12:54:53 -0000 --20cf300512f2f2b91604bed0d71f Content-Type: text/plain; charset=ISO-8859-1 All I went through RFC 4861 and found the section on "Neighbor Unreachablity Detection" to be of less signifance especially on the links between Router. Reason is that, while there are failure detection protocols already available to detect a liveliness of the neighbor I dont understand effectivenss of such a mechanism within IpV6. Moreover, whenever the neighborstate is not in "Reachable state", there is a bunch of packets that gets trapped to the CPU to invoke IPV6 to send NeighborSolicitaion message to detect the liveliness of the neighbor. And Interestingly, the implementations continue to forward to the neighbor irrespective of what the "Nbr state is" and then trap the (copy of the packets)packets to cpu to do a Neighbor Unreachablity Detection check (for the sake of sticking to the standard). I didnt like Router Doing this especially on the Router-Router link. Here are my opinion on handling the above issues. 1: Why to go through all the NeighborStates (Incomplete->Reachable->Stale->Delay->Probe) when Protocols like BFD are already present to check the liveliness of the neighbor (On a Router-Router link). Cant we avoid "Neighbor unreachablity detection" completely? 2: Simplify the NeighborState Machine.Just mainitain two states in the Neighbor cache when the neighbor is a router. The states would be "Incomplete and Reachable". Enhancement as follows: Initially the Neighbor state would be marked "Incomplete" and a NeighborSolicitation message would be originated to determine the link layer address.Once it receives a response move the neighbor state to "Reachable". Just maintain an ageout timer like the one meant for ARP (no more complications) to flush an entry from neighbor Cache. Please share your thoughts. Regards Somasundaram --20cf300512f2f2b91604bed0d71f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All

= =A0I went through RFC=20 4861 and found the section on "Neighbor Unreachablity Detection" = to be=A0of less signifance especi= ally on the links=20 between Router.
=A0
Reason is tha= t,=20 while there are failure detection protocols already available to detect a= =20 liveliness of the neighbor=A0I dont unde= rstand=20 effectivenss of=A0such a mechanism within IpV6.
=A0
Moreover, whe= never=20 the neighborstate is not in "Reachable state", there is a bunch o= f packets that=20 gets trapped to the CPU to invoke IPV6 to send NeighborSolicitaion message = to=20 detect the liveliness of the neighbor. And Interestingly,=A0the implementat= ions=A0 continue to=20 forward to the neighbor irrespective of what the "Nbr state is" a= nd then trap=20 the (copy of the packets)packets to cpu to do a Neighbor Unreachablity Dete= ction=20 check (for the sake of sticking to the standard).
=A0
I didnt like = Router=20 Doing this especially on the Router-Router link.
=A0
Here are my o= pinion on handling the above issues.
=A0
1: Why to go= =20 through all the NeighborStates=20 (Incomplete->Reachable->Stale->Delay->Probe)=A0when Protocols l= ike BFD=20 are already present to check the liveliness of the neighbor (On a=20 Router-Router link). Cant we avoid "Neighbor unreachablity detection&q= uot;=20 completely?
2: Simplify t= he=20 NeighborState Machine.Just mainitain two states in the Neighbor cache when = the=20 neighbor is a router. The states would be "Incomplete and=20 Reachable".
=A0
Enhancement a= s=20 follows:
=A0=A0=A0=A0= =A0Initially=20 the=A0Neighbor state would be marked "Incomplete" and a NeighborS= olicitation=20 message would =A0be originated to determine the link layer address.Once it= =20 receives a response move the neighbor state to "Reachable". Just = maintain an=20 ageout timer like the one meant for ARP (no more complications) to flush an= =20 entry from neighbor Cache.
=
<= /div>Please share your thoughts.

Regards
Somasundaram
--20cf300512f2f2b91604bed0d71f-- From kerlyn2001@gmail.com Sun Apr 29 15:50:48 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 C535C21F85D6 for ; Sun, 29 Apr 2012 15:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_37=0.6, J_CHICKENPOX_53=0.6, NORMAL_HTTP_TO_IP=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 Q8Iymt9PywNc for ; Sun, 29 Apr 2012 15:50:47 -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 5089521F85D5 for ; Sun, 29 Apr 2012 15:50:47 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so1692602lbb.31 for ; Sun, 29 Apr 2012 15:50:46 -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; bh=Qyu3HNlOv2QeW+YNNkx6/3iiDOeamTCO0JKUuHXt0mU=; b=L0d+uoXgfBqcnYiirMWY6FH0CQbW0um7+dcIjCw4J1RN2GqmiuUqYSC1PMNutsUMXU PpnurdlRM3GQhEyR9PB6JQAtfIIS7Api7mE+S3+X1YDSj9TJbs5WXsjv/Guco5PZVlrU M7pmkB67OCAkK0IVkd3ajFu9NooaKErbLKCCMA8nRyTi/7a/KuF8GVFsBeVC6zK4oMc5 0HKx/jViY18A9EJyyKVqTKfMNbQZj9KlxN9Q96ScUsA4A2tSgGuxHkIz1b0xAmlcj469 JzdTlrDofgjK2zOnHCjZYXJRwZV+GiZcMv6MSsDj8HapEo23b18GwJ9HkS4gP715pJ6H NyPw== MIME-Version: 1.0 Received: by 10.152.111.41 with SMTP id if9mr17913841lab.19.1335739846158; Sun, 29 Apr 2012 15:50:46 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.18.138 with HTTP; Sun, 29 Apr 2012 15:50:46 -0700 (PDT) In-Reply-To: <4F9CF3A8.7000801@gmail.com> References: <4F9CF3A8.7000801@gmail.com> Date: Sun, 29 Apr 2012 18:50:46 -0400 X-Google-Sender-Auth: VnEsMPucTVrILcm86TUPm7gH_kM Message-ID: Subject: Re: Options for draft-ietf-6man-uri-zoneid From: Kerry Lynn To: Brian E Carpenter , 6man Content-Type: multipart/alternative; boundary=f46d040715290aea6504bed92bae 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, 29 Apr 2012 22:50:48 -0000 --f46d040715290aea6504bed92bae Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00, > there was no clear consensus on the approach to pursue. In fact, > almost the same discussion occurred around draft-fenner-literal-zone > several years ago, but at that time the topic was simply dropped. > > This note summarises the main options. As a reminder, the problem to > be solved is how to tell a browser which interface to use when sending > packets to a literal link-local address. The reason for doing this is > purely for diagnostic purposes, since the Zone ID that identifies an > interface has no significance outside the sending host. "Purely" may be overly strong here. When I mentioned in Paris that my mom might like to configure her spanking new IPv6 homenet router using http://[fe80::1%eth0] the way she currently uses http://192.168.1.1, it was met with much ROTFL'ing. But hey, my mom is no slouch. In a more immediate case, people are currently using browsers to connect to embedded 6LoWPAN web servers. (Imagine a host with a 6LoWPAN link on one interface and ethernet on another.) I use Firefox 3.2x for this, because it supports the syntax above just fine. Are such cases included in the "diagnostic" designation? It seems not. For more details, > see the two drafts mentioned above. > > What we have today: link local address with no Zone ID > http://[fe80::a] > > The user cannot select the outgoing interface if there is more than one. > > The obvious solution would be to use the RFC4007 syntax (for an > example Zone ID of en1): > > http://[fe80::a%en1] > > However, this is impossible because % is *always* an escape character in > URI syntax [RFC3986]. There is no chance of the URI community accepting > such a hack to the syntax, so it isn't an option for us. > > Well, this may be a case of "do what we mean, not what we say". I agree that "%" is the first octet of pct-encoded, but it's not clear that pct-encoded is permissible in all productions. To wit, ( unreserved / sub-delims / ":" ) and ( unreserved / pct-encoded / sub-delims / ":" ) are apparently not equivalent. The basis of some comments in Paris was that escaped chars are currently not permitted within IP-literal. But I agree, in the end this may be an un- winnable battle. > The available options are therefore > > 1) Leave the problem unsolved. > > This would mean that per-interface diagnostics would still have to be > performed using ping or ping6 > > ping fe80::a%en1 > > Advantage: works today. > > Disadvantage: less convenient than using a browswer. > > And doesn't allow browsing; see above. So I don't like this option. > 2) Escaping the escape character as allowed by RFC 3986: > > http://[fe80::a%25en1] > > Advantage: allows use of browser. > Disadvantage: ugly and confusing, doesn't allow simple cut and paste. > > Well, if we took a purely *user-centric* approach, then we'd use a consistent syntax for all utilities. We have an existence proof (Firefox 3.2x) that demonstrates the desired syntax is possible (and parsible). This option is just ugly. If we have to map symbols, I'd rather use a 1:1 mapping than a 1:3 mapping. 3) With alternative separator such as _ > > http://[fe80::a_en1] > > Advantage: allows use of browser. > Disadvantage: doesn't allow simple cut and paste. > > This is the simplest of the four alternatives. It seems at this point we could just discuss whether "_" is the best alternative. > 4) With the "IPvFuture" syntax left open in RFC 3986: > > http://[v6.fe80::a_en1] > > Advantage: allows use of browser. > Disadvantage: ugly and redundant, doesn't allow simple cut and paste. > > Yikes! This one just screams OVERSIGHT. I would frankly prefer option 1 over having two ways to represent IPv6address. Thanks, Brian and Bob, for taking this on. -K- > Thus, the WG has to choose between options 1), 2), 3) and 4). > > Opinions welcome! > > Brian Carpenter > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --f46d040715290aea6504bed92bae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter <brian.e.carp= enter@gmail.com> wrote:
Hi,

In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00,
there was no clear consensus on the approach to pursue. In fact,
almost the same discussion occurred around draft-fenner-literal-zone
several years ago, but at that time the topic was simply dropped.

This note summarises the main options. As a reminder, the problem to
be solved is how to tell a browser which interface to use when sending
packets to a literal link-local address. The reason for doing this is
purely for diagnostic purposes, since the Zone ID that identifies an
interface has no significance outside the sending host.
"Purely" may be overly strong here. =A0When I mentio= ned in Paris that
my mom might like to configure her spanking new= IPv6 homenet router
using http://[fe80::1%eth0] the way she currently uses http://192.168.1.1,
it was met with much ROTF= L'ing. =A0But hey, my mom is no slouch.

In a m= ore immediate case, people are currently using browsers to connect
to embedded 6LoWPAN web servers. =A0(Imagine a host with a 6LoWPAN
link on one interface and ethernet on another.) =A0I use Firefox 3.2= x for this,
because it supports the syntax above just fine.

Are such cases included in the "diagnostic" d= esignation? =A0It seems not.

For more details,
see the two drafts mentioned above.

What we have today: link local address with no Zone ID
=A0 http://[fe80::a]

The user cannot select the outgoing interface if there is more than one.
The obvious solution would be to use the RFC4007 syntax (for an
example Zone ID of en1):

=A0 http://[fe80::a%en1]

However, this is impossible because % is *always* an escape character in URI syntax [RFC3986]. There is no chance of the URI community accepting
such a hack to the syntax, so it isn't an option for us.

Well, this may be a case of "do what we mean, no= t what we say". =A0 I agree
that "%" is the first = octet of pct-encoded, but it's not clear that pct-encoded
is permissible in all productions. =A0To wit, ( unreserved / sub-delims / &= quot;:" ) and
( unreserved / pct-encoded / sub-delims / &quo= t;:" ) are apparently not equivalent.
The basis of some comm= ents in Paris was that escaped chars are currently
not permitted within IP-literal. =A0But I agree, in the end this may b= e an un-
winnable battle.
=A0
The available options are therefore

1) Leave the problem unsolved.

This would mean that per-interface diagnostics would still have to be
performed using ping or ping6

=A0 ping fe80::a%en1

Advantage: works today.

Disadvantage: less convenient than using a browswer.

And doesn't allow browsing; see above. =A0So I do= n't like this option.
=A0
2) Escaping the escape character as allowed by RFC 3986:

=A0 http://[fe80::a%25en1]

Advantage: allows use of browser.
Disadvantage: ugly and confusing, doesn't allow simple cut and paste.
Well, if we took a purely *user-centric* approach, th= en we'd use a
consistent syntax for all utilities. =A0We have= an existence proof (Firefox
3.2x) that demonstrates the desired = syntax is possible (and parsible).
This option is just ugly. =A0If we have to map symbols, I'd rather= use a
1:1 mapping than a 1:3 mapping.

3) With alternative separator such as _

=A0 http://[fe80::a_en1]

Advantage: allows use of browser.
Disadvantage: doesn't allow simple cut and paste.

This is the simplest of the four alternatives. =A0It = seems at this point we
could just discuss whether "_" i= s the best alternative.
=A0
4) With the "IPvFuture" syntax left open in RFC 3986:

=A0 http://[v6.fe80::a_en1]

Advantage: allows use of browser.
Disadvantage: ugly and redundant, doesn't allow simple cut and paste.
Yikes! =A0This one just screams OVERSIGHT. =A0I would= frankly prefer
option 1 over having two ways to represent IPv6ad= dress.

Thanks, Brian and Bob,=A0for taking this on= .

-K-
=A0
Thus, the WG has to choose between options 1), 2), 3) and 4).

Opinions welcome!

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

--f46d040715290aea6504bed92bae-- From nordmark@acm.org Sun Apr 29 17:31: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 6922921F8592 for ; Sun, 29 Apr 2012 17:31:24 -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 GKZZYumvabqr for ; Sun, 29 Apr 2012 17:31:23 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id BD9F721F8569 for ; Sun, 29 Apr 2012 17:31:23 -0700 (PDT) Received: from [10.21.72.123] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q3U0VJcM029016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Apr 2012 17:31:20 -0700 Message-ID: <4F9DDD57.4070207@acm.org> Date: Sun, 29 Apr 2012 17:31:19 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Somasundaram Selvaraj Subject: Re: Neighbor Unreachability Detection.. 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, 30 Apr 2012 00:31:24 -0000 On 4/29/12 5:54 AM, Somasundaram Selvaraj wrote: > All > > I went through RFC 4861 and found the section on "Neighbor > Unreachablity Detection" to be of less signifance especially on the > links between Router. Did you read the text in section 7.3 which says Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent mechanism is available, for example, as part of the routing protocols. Keep in mind that ND predates BFD; if the specification which written today it might as "as part of the routing protocols or BFD". I don't know if anybody has looked for a detailed description of how ND address resolution between routers might interact with BFD, but AFAICT this should be straight-forward. Just disabling NUD on the interfaces where BFD is being used. Does that answer your concerns? Erik > Reason is that, while there are failure detection protocols already > available to detect a liveliness of the neighbor I dont understand > effectivenss of such a mechanism within IpV6. > Moreover, whenever the neighborstate is not in "Reachable state", there > is a bunch of packets that gets trapped to the CPU to invoke IPV6 to > send NeighborSolicitaion message to detect the liveliness of the > neighbor. And Interestingly, the implementations continue to forward to > the neighbor irrespective of what the "Nbr state is" and then trap the > (copy of the packets)packets to cpu to do a Neighbor Unreachablity > Detection check (for the sake of sticking to the standard). > I didnt like Router Doing this especially on the Router-Router link. > Here are my opinion on handling the above issues. > 1: Why to go through all the NeighborStates > (Incomplete->Reachable->Stale->Delay->Probe) when Protocols like BFD are > already present to check the liveliness of the neighbor (On a > Router-Router link). Cant we avoid "Neighbor unreachablity detection" > completely? > 2: Simplify the NeighborState Machine.Just mainitain two states in the > Neighbor cache when the neighbor is a router. The states would be > "Incomplete and Reachable". > Enhancement as follows: > Initially the Neighbor state would be marked "Incomplete" and a > NeighborSolicitation message would be originated to determine the link > layer address.Once it receives a response move the neighbor state to > "Reachable". Just maintain an ageout timer like the one meant for ARP > (no more complications) to flush an entry from neighbor Cache. > > Please share your thoughts. > > Regards > Somasundaram > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Sun Apr 29 23:52: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 AAA4221F848B for ; Sun, 29 Apr 2012 23:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.922 X-Spam-Level: X-Spam-Status: No, score=-100.922 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_37=0.6, J_CHICKENPOX_53=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_ILLEGAL_IP=1.908, 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 pwZEUk3xIhoi for ; Sun, 29 Apr 2012 23:52:07 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A51DE21F8497 for ; Sun, 29 Apr 2012 23:52:06 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so1972264wib.13 for ; Sun, 29 Apr 2012 23:52: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=nu/+/ybpDWpTQiCuXALQkUOd28ZuRyXpLDkJnSGfwV4=; b=CA4m4YRRlyhKnkJcxmGyBVfw9qhkQs6gi56EX1n+SPmcP9dhS3AIQ2EtHT4b4Fja4a lm3vmwQ2a9fG/ZQ47GDjlJOi3cZB30kjtluyqktf40WbNjYtNHUth53x/K2bczn4q2YV n3AZTRJzpD3FPwfZktYMu14wPRFBNJdBw6yv7+C24kCs2+YW7gD/XpI27kOs8mOngxf1 fDv/0BFImH4pA4gnlQXQAZPDWHQGLlQm/2C14T0HI1im9skZKimA7AquMmn836TmxYQH kQIFDInF5MknK5jzBXodv5ikfKSklpV8STWlx85/h2IuVHrIQD5NrIxow7nDjvEw3YlS B+EQ== Received: by 10.180.24.66 with SMTP id s2mr26457905wif.7.1335768725661; Sun, 29 Apr 2012 23:52:05 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-73.as13285.net. [2.102.219.73]) by mx.google.com with ESMTPS id 17sm26977838wis.0.2012.04.29.23.52.03 (version=SSLv3 cipher=OTHER); Sun, 29 Apr 2012 23:52:04 -0700 (PDT) Message-ID: <4F9E368B.6010501@gmail.com> Date: Mon, 30 Apr 2012 07:51:55 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kerry Lynn Subject: Re: Options for draft-ietf-6man-uri-zoneid References: <4F9CF3A8.7000801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Mon, 30 Apr 2012 06:52:07 -0000 Kerry, On 2012-04-29 23:50, Kerry Lynn wrote: > On Sun, Apr 29, 2012 at 3:54 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> Hi, >> >> In the IETF 83 discussion of draft-ietf-6man-uri-zoneid-00, >> there was no clear consensus on the approach to pursue. In fact, >> almost the same discussion occurred around draft-fenner-literal-zone >> several years ago, but at that time the topic was simply dropped. >> >> This note summarises the main options. As a reminder, the problem to >> be solved is how to tell a browser which interface to use when sending >> packets to a literal link-local address. The reason for doing this is >> purely for diagnostic purposes, since the Zone ID that identifies an >> interface has no significance outside the sending host. > > > "Purely" may be overly strong here. When I mentioned in Paris that > my mom might like to configure her spanking new IPv6 homenet router > using http://[fe80::1%eth0] the way she currently uses http://192.168.1.1, > it was met with much ROTFL'ing. But hey, my mom is no slouch. > > In a more immediate case, people are currently using browsers to connect > to embedded 6LoWPAN web servers. (Imagine a host with a 6LoWPAN > link on one interface and ethernet on another.) I use Firefox 3.2x for > this, > because it supports the syntax above just fine. > > Are such cases included in the "diagnostic" designation? It seems not. Fair enough, this can easily be wordsmithed. > > For more details, >> see the two drafts mentioned above. >> >> What we have today: link local address with no Zone ID >> http://[fe80::a] >> >> The user cannot select the outgoing interface if there is more than one. >> >> The obvious solution would be to use the RFC4007 syntax (for an >> example Zone ID of en1): >> >> http://[fe80::a%en1] >> >> However, this is impossible because % is *always* an escape character in >> URI syntax [RFC3986]. There is no chance of the URI community accepting >> such a hack to the syntax, so it isn't an option for us. >> >> Well, this may be a case of "do what we mean, not what we say". I agree > that "%" is the first octet of pct-encoded, but it's not clear that > pct-encoded > is permissible in all productions. To wit, ( unreserved / sub-delims / ":" > ) and > ( unreserved / pct-encoded / sub-delims / ":" ) are apparently not > equivalent. > The basis of some comments in Paris was that escaped chars are currently > not permitted within IP-literal. But I agree, in the end this may be an un- > winnable battle. Exactly. I don't claim to understand every nook and cranny of the syntax, but in practice it's unwinnable. > >> The available options are therefore >> >> 1) Leave the problem unsolved. >> >> This would mean that per-interface diagnostics would still have to be >> performed using ping or ping6 >> >> ping fe80::a%en1 >> >> Advantage: works today. >> >> Disadvantage: less convenient than using a browswer. >> >> And doesn't allow browsing; see above. So I don't like this option. Yes, I overlooked that rather obvious disadvantage... > > >> 2) Escaping the escape character as allowed by RFC 3986: >> >> http://[fe80::a%25en1] >> >> Advantage: allows use of browser. >> Disadvantage: ugly and confusing, doesn't allow simple cut and paste. >> >> Well, if we took a purely *user-centric* approach, then we'd use a > consistent syntax for all utilities. We have an existence proof (Firefox > 3.2x) that demonstrates the desired syntax is possible (and parsible). > This option is just ugly. If we have to map symbols, I'd rather use a > 1:1 mapping than a 1:3 mapping. If only we hadn't picked % in the first place... > > 3) With alternative separator such as _ >> http://[fe80::a_en1] >> >> Advantage: allows use of browser. >> Disadvantage: doesn't allow simple cut and paste. >> >> This is the simplest of the four alternatives. It seems at this point we > could just discuss whether "_" is the best alternative. > > >> 4) With the "IPvFuture" syntax left open in RFC 3986: >> >> http://[v6.fe80::a_en1] >> >> Advantage: allows use of browser. >> Disadvantage: ugly and redundant, doesn't allow simple cut and paste. >> >> Yikes! This one just screams OVERSIGHT. I would frankly prefer > option 1 over having two ways to represent IPv6address. > > Thanks, Brian and Bob, for taking this on. No problem. Brian > > -K- > > >> Thus, the WG has to choose between options 1), 2), 3) and 4). >> >> Opinions welcome! >> >> Brian Carpenter >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >