Hi dear baby

Not very good erecxction? You are welcome - http://uklinmdefunherion.com

corridors, more = bricks-and another door. It opened into misty
darkness. Stumbling and barking our ankles we made our way to a row = of
waiting chairs, sat down as instructed. It was even darker when = Goldy

------=_NextPart_000_0001_01C6C6B9.F8DB0330-- From ipv6-bounces@ietf.org Wed Aug 23 18:34:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1Fe-0008Nz-2n; Wed, 23 Aug 2006 18:31:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1Fc-0008NJ-JD for ipv6@ietf.org; Wed, 23 Aug 2006 18:31:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG1Fb-0005Zw-Be for ipv6@ietf.org; Wed, 23 Aug 2006 18:31:08 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2006 18:31:07 -0400 X-IronPort-AV: i="4.08,161,1154923200"; d="scan'208"; a="98339266:sNHT31096356" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7NMV7Xv010760; Wed, 23 Aug 2006 18:31:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7NMV6dM020089; Wed, 23 Aug 2006 18:31:06 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 18:31:06 -0400 Received: from [192.168.1.107] ([10.86.240.122]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 18:31:06 -0400 In-Reply-To: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> References: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ralph Droms Date: Wed, 23 Aug 2006 18:31:05 -0400 To: X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 Aug 2006 22:31:06.0456 (UTC) FILETIME=[D2F24580:01C6C703] DKIM-Signature: a=rsa-sha1; q=dns; l=909; t=1156372267; x=1157236267; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20Prefix=20Delegation=20using=20ICMPv6 |To:; X=v=3Dcisco.com=3B=20h=3DtoTndhyfdIOp7704XcvKB2NK2G0=3D; b=Ye5CSOZXk4aHitv5s5I/dtiOPHw4PDq9P+kXsSulV5U3xSonbE+RzofaG6Jdtx6IggGt8n+5 Zp/6p+5Ap1nViqXS1GBo+XaLf1ipFo8LWwXDsoFj4QNig6tQTtyvhl0w; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Durand, Alain" , IETF IPv6 Mailing List Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Tim - The answer to your exact question is, of course, yes. But, in my opinion, that question is not the right starting point for our conversation. A better question to start with, which we certainly ought to ask as members of an engineering organization like the IETF, is: "Is there a sufficiently large set of scenarios and use cases where the requirements cannot be met by DHCPv6 PD to warrant the investment of resources to design, specify, publish, implement and test an entirely new protocol or protocol extension?". The IETF has spent far too much effort in defining theoretically possible protocols. - Ralph On Aug 23, 2006, at 5:59 PM, wrote: > [...] > Do you believe that it is theoretically possible that DHCPv6 PD > would be "neither required nor desired"? It is here that I'd like > to start this portion of our conversation. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 23 18:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1c1-0007Fo-7l; Wed, 23 Aug 2006 18:54:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1c0-0007Fj-B3 for ipv6@ietf.org; Wed, 23 Aug 2006 18:54:16 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG1bz-0000Ra-1P for ipv6@ietf.org; Wed, 23 Aug 2006 18:54:16 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motorola) with ESMTP id k7NMs9gj016680 for ; Wed, 23 Aug 2006 15:54:09 -0700 (MST) Received: from ct11exm63.ds.mot.com (ct11exm63.am.mot.com [10.177.8.47]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k7NMs804004908 for ; Wed, 23 Aug 2006 17:54:09 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Aug 2006 18:54:07 -0400 Message-ID: <92D17ACC46FB33448977916D9EC398F0D30692@ct11exm63.ds.mot.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix Delegation using ICMPv6 thread-index: AcbHBAK3eCWfWhItRxObTExu1G62ZQAAMF0g From: "Rao Satyanarayana-W60007" To: "Ralph Droms" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Durand, Alain" , IETF IPv6 Mailing List Subject: RE: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Ralph, Implementation and test effort is always there whether it is a existing protocol or a new protocol to catch implementation specific bugs. Even if one licenses a particular implementation, there is always testing involved though the effort can be less focused on testing the licensed components but the integrated system. If the proposal has merit and looks appealing, implementations will come. What we would like to know now is are there any bugs in the proposal being specified? I think the questions should be is there merit in the proposal? Does it basically work? What needs to be modified for it to work? Our claim is that there are situations and configurations where DHCPv6 may not be enabled or available and hence PD process can not depend on dhcp protocol. If the PD mechanism can be run utilizing more basic and fundamental components of the ipv6 stack, why not? If it basically works, and if implementers believe that it is simpler and easy to implement and deploy, it will get used. It does not propose to replace the dhcpv6 based proposal. - Satya Rao Mobile Devices Technology Office Motorola Tel: 512-996-6781 Email: sbrao@motorola.com =20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Wednesday, August 23, 2006 5:31 PM > To: timbeck04@verizon.net > Cc: Durand, Alain; IETF IPv6 Mailing List > Subject: Re: Prefix Delegation using ICMPv6 >=20 > Tim - The answer to your exact question is, of course, yes. =20 > But, in my opinion, that question is not the right starting=20 > point for our conversation. >=20 > A better question to start with, which we certainly ought to=20 > ask as members of an engineering organization like the IETF,=20 > is: "Is there a sufficiently large set of scenarios and use=20 > cases where the requirements cannot be met by DHCPv6 PD to=20 > warrant the investment of resources to design, specify,=20 > publish, implement and test an entirely new protocol or=20 > protocol extension?". >=20 > The IETF has spent far too much effort in defining=20 > theoretically possible protocols. >=20 > - Ralph >=20 > On Aug 23, 2006, at 5:59 PM, wrote: > > [...] > > Do you believe that it is theoretically possible that=20 > DHCPv6 PD would=20 > > be "neither required nor desired"? It is here that I'd like=20 > to start=20 > > this portion of our conversation. >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 23 19:18:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1xK-0001fi-Er; Wed, 23 Aug 2006 19:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1xJ-0001fd-9x for ipv6@ietf.org; Wed, 23 Aug 2006 19:16:17 -0400 Received: from vms042pub.verizon.net ([206.46.252.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG1xH-0004PO-UM for ipv6@ietf.org; Wed, 23 Aug 2006 19:16:17 -0400 Received: from vms172.mailsrvcs.net ([192.168.1.1]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J4H00AY54M8J8D4@vms042.mailsrvcs.net> for ipv6@ietf.org; Wed, 23 Aug 2006 18:15:44 -0500 (CDT) Received: from 129.55.200.20 ([129.55.200.20]) by vms172.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 23 Aug 2006 18:15:44 -0500 (CDT) Date: Wed, 23 Aug 2006 18:15:44 -0500 (CDT) From: X-Originating-IP: [129.55.200.20] To: Jari Arkko , timbeck04@verizon.net Message-id: <22402264.193591156374944552.JavaMail.root@vms172.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF IPv6 Mailing List , Ralph Droms Subject: Re: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >From: Jari Arkko >Date: 2006/08/23 Wed AM 07:24:59 CDT >To: timbeck04@verizon.net >Cc: Ralph Droms , IETF IPv6 Mailing List >Subject: Re: Prefix Delegation using ICMPv6 >Tim, > >>Given that there is a historical precedent for being able to do something via more than one standardized IETF way, I'd suggest that IPv6 PD is another such case where such an approach is warranted. >>... >>I'd like to repeat my/our contention that ICMPv6 PD is not meant to replace DHCPv6 PD. The two are not mutually exclusive. >> >>In some cases, customers may wish to have an alternative to the existing mechanism (WHY they wish to have it is a separate question, THAT they do is an issue which helped inform the writing of our draft). >> >>Customer requirements are often what drive innovation (sometimes the other way around). Over the past few years, more customers have expressed interest in/requirement for an alternative to DHCPv6 PD. Our draft based upon ICMPv6 is one such proposed solution. >> >>BTW, what would be your burden of proof in what you are asking?** I'd not want to be chasing my technical tail. =^) >> >> >As Brian pointed out there are some design principles >that the IETF uses. We believe interoperability is >very valuable. Hi Jari, being part of that 'we', I definitely agree. I'd also say I believe that the ICMPv6 PD mechanism we (co-authors and I) propose would be interoperable. >We do not create alternative ways to >do the same thing, because doing so will burden >implementors with additional complexity and reduces >the likelihood that nodes can communicate >successfully. Picking a common way to do something is >the fundamental idea behind standards. In general that is true. However, for things such as IPv6 node addressing we have DHCPv6 and SLAAC. The point is THAT there is >1 way to do something (in this case IPv6 node addressing). There are certainly cases where nodes that get their IPv6 address info from each method reside on the same link. Not wanting to debate how much complexity is too much, I'd say that having both DHCPv6 and SLAAC nodes on the same link is not a problem (have seen it work myself). > >Of course, in some cases we actually do have to >create alternative mechanisms when the situation >calls for it. Definitely agreed. >For instance, the requirements are very different, e.g. if a customer requires that IPv6 PD be done, but DHCPv6 not be used? When posting my original e-mail to the list, this is one thing I was considering. >we have new needs that fundamentally cannot be met by the existing mechanisms, and so on. IPv6 node addressing can be done via DHCPv6 as well as SLAAC. I'd of course also agree that while IPv6 PD can be (and is done well) by DHCPv6, it can be done via ICMPv6 as well. >And we all want to enable the things that the >customers want to do. So their requirements are >important, but some engineering may be needed before >we decide what solution should be employed. Absolutely Jari, agreed. We (co-authors and I) are seeking to address customer requirements for IPv6 PD in cases where DHCPv6 PD is not required. We understand that some engineering may be needed in order to implement our proposed solution. We truly do seek and value input on our draft proposal. In reviewing our draft, how much engineering do you suppose would be required to deploy the proposed ICMPv6 PD mechanism? > >I would suggest that you focus on the WHY question >and proceed with a rational analysis of whether >existing mechanisms are or are not sufficient for >your needs. We shall definitely continue to look at the WHY question, your point is well taken. One case in which DHCPv6 might not be necessary (though perhaps sufficient) is a case where the customer end-nodes get their addressing information from SLAAC, and do not require any other automated configuration be done. In this instance, it seems unnecessary to enable DHCPv6 just for the sake of PD. An ICMPv6-based PD mechanism such as the one we propose would seem to fit here. >This analysis should avoid arguments such as "Devices >do not have X, therefore we must design Y". Such >arguments do not provide any information on what the >reasons for not having X were, I'm pretty sure I see what you're saying, though not certain I completely concur. We as solution providers always need to know WHY our customers do not have X. Sometimes, THAT they don't have X is all we need to know IMO. >whether designing Y will alleviate those concerns, In the case where IPv6 PD is required but DHCPv6 is not an option (perhaps only because of customer policy, perhaps for another reason), "Y" in this case would alleviate those concerns. >and whether the benefits from Y are a good tradeoff >with respect to the costs of supporting both X and Y >in everyone's products over the next N years. How much of a support cost increase do you see in the case where it's possible to do both DHCPv6 PD and ICMPv6 PD? I don't see much if any. I'm honestly not seeing when if ever (for example) an ISP and customer would have both mechanisms running on the same link. > >And the burden of proof is on the side of those >who want something new; you should convince >the community that it is indeed necessary. That's what we're trying to do, and I agree with you. > >--Jari -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 23 19:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG20i-0004Je-1p; Wed, 23 Aug 2006 19:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG20g-0004JH-CX for ipv6@ietf.org; Wed, 23 Aug 2006 19:19:46 -0400 Received: from vms044pub.verizon.net ([206.46.252.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG20f-00056s-2o for ipv6@ietf.org; Wed, 23 Aug 2006 19:19:46 -0400 Received: from vms172.mailsrvcs.net ([192.168.1.1]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J4H00DKM4SIP6F1@vms044.mailsrvcs.net> for ipv6@ietf.org; Wed, 23 Aug 2006 18:19:30 -0500 (CDT) Received: from 129.55.200.20 ([129.55.200.20]) by vms172.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 23 Aug 2006 18:19:29 -0500 (CDT) Date: Wed, 23 Aug 2006 18:19:29 -0500 (CDT) From: X-Originating-IP: [129.55.200.20] To: Rao Satyanarayana-W60007 , Ralph Droms , timbeck04@verizon.net Message-id: <8253892.194341156375170156.JavaMail.root@vms172.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Durand, Alain" , IETF IPv6 Mailing List Subject: Re: RE: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >From: Rao Satyanarayana-W60007 >Date: 2006/08/23 Wed PM 05:54:07 CDT >To: Ralph Droms , timbeck04@verizon.net >Cc: "Durand, Alain" , IETF IPv6 Mailing List >Subject: RE: Prefix Delegation using ICMPv6 Satya, You put this so much better than I have, I think. Thank you! Tim Rom 8:28 >Ralph, >Implementation and test effort is always there whether it is a existing >protocol or a new protocol to catch implementation specific bugs. Even >if one licenses a particular implementation, there is always testing >involved though the effort can be less focused on testing the licensed >components but the integrated system. If the proposal has merit and >looks appealing, implementations will come. > >What we would like to know now is are there any bugs in the proposal >being specified? I think the questions should be is there merit in the >proposal? Does it basically work? What needs to be modified for it to >work? Our claim is that there are situations and configurations where >DHCPv6 may not be enabled or available and hence PD process can not >depend on dhcp protocol. If the PD mechanism can be run utilizing more >basic and fundamental components of the ipv6 stack, why not? If it >basically works, and if implementers believe that it is simpler and easy >to implement and deploy, it will get used. It does not propose to >replace the dhcpv6 based proposal. > >- Satya Rao >Mobile Devices Technology Office >Motorola >Tel: 512-996-6781 >Email: sbrao@motorola.com > > >> -----Original Message----- >> From: Ralph Droms [mailto:rdroms@cisco.com] >> Sent: Wednesday, August 23, 2006 5:31 PM >> To: timbeck04@verizon.net >> Cc: Durand, Alain; IETF IPv6 Mailing List >> Subject: Re: Prefix Delegation using ICMPv6 >> >> Tim - The answer to your exact question is, of course, yes. >> But, in my opinion, that question is not the right starting >> point for our conversation. >> >> A better question to start with, which we certainly ought to >> ask as members of an engineering organization like the IETF, >> is: "Is there a sufficiently large set of scenarios and use >> cases where the requirements cannot be met by DHCPv6 PD to >> warrant the investment of resources to design, specify, >> publish, implement and test an entirely new protocol or >> protocol extension?". >> >> The IETF has spent far too much effort in defining >> theoretically possible protocols. >> >> - Ralph >> >> On Aug 23, 2006, at 5:59 PM, wrote: >> > [...] >> > Do you believe that it is theoretically possible that >> DHCPv6 PD would >> > be "neither required nor desired"? It is here that I'd like >> to start >> > this portion of our conversation. >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 23 19:35:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2DG-0001uC-JD; Wed, 23 Aug 2006 19:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2DF-0001u7-JS for ipv6@ietf.org; Wed, 23 Aug 2006 19:32:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFzu2-0003zM-2p for ipv6@ietf.org; Wed, 23 Aug 2006 17:04:46 -0400 Received: from vms044pub.verizon.net ([206.46.252.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFzpW-0005ZR-LF for ipv6@ietf.org; Wed, 23 Aug 2006 17:00:08 -0400 Received: from vms172.mailsrvcs.net ([192.168.1.1]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J4G00BPVYC1QC92@vms044.mailsrvcs.net> for ipv6@ietf.org; Wed, 23 Aug 2006 16:00:02 -0500 (CDT) Received: from 129.55.200.20 ([129.55.200.20]) by vms172.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 23 Aug 2006 16:00:01 -0500 (CDT) Date: Wed, 23 Aug 2006 16:00:01 -0500 (CDT) From: X-Originating-IP: [129.55.200.20] To: Ralph Droms , "" Message-id: <25410032.163811156366801715.JavaMail.root@vms172.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: "Durand, Alain" , IETF IPv6 Mailing List Subject: Re: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >From: Ralph Droms >Date: 2006/08/23 Wed AM 05:43:09 CDT >To: "" >Cc: "Durand, Alain" , Syam Madanapalli , IETF IPv6 Mailing List >Subject: Re: Prefix Delegation using ICMPv6 >Tim - I don't think I made my point clear. SLAAC, DHCP and manual >addressing are all very different ways to accomplish the same result, >stemming from very different requirements: > >SLAAC - all nodes on a link share the same prefixes; advertising > device sends a single message with configuration information >for > all nodes; protocol communications are essentially one way > (advertiser->node); network operations don't explicitly control > specific addresses assigned to each node >DHCP - network operations communicates one-to-one and interactively > with each node; network operations has information about > addresses assigned to each node >manual- no interaction with network operations; node administrator >chooses > addresses assigned to node Hi Ralph, your point is very clear, and I definitely agree with what you are saying. Sorry for any misunderstanding. My original related point was/is to address the fact THAT there is historical precedent for doing something (in my example, IPv6 node addressing) in >1 IETF standardized way, not WHY there is (also that it is good that there is). Using similar logic I/we truly would like to have the technical merits of our proposal considered by this body. > >Prefix delegation has a pretty common set of requirements, based on >RFC 3769. Using RFC 3769 as our guide, we seek to offer a PD mechanism (which happens to use ICMPv6). >I didn't see in the ICMP PD draft (which I will reread more carefully as soon as I recover from being away from my office for a week) I myself am getting over a virtual lack of sleep, so I can sympathize with the need for recovery time! :) >any significant differentiation in requirements on the scale of those among SLAAC, DHCP and manual address configuration. I'm not sure there is significant differentiation in requirements, especially along those scales. Given the way I read RFC 3769 however, I'm thinking there might not need to be (rather that whatever IPv6 PD mechanism that is proposed meets the requirements). Tim Rom 8:28 > > >On Aug 23, 2006, at 2:44 AM, > wrote: > >>> From: Ralph Droms >>> Date: 2006/08/22 Tue PM 11:04:04 CDT >>> To: timbeck04@verizon.net >>> Cc: "Durand, Alain" , >> Syam Madanapalli , >> IETF IPv6 Mailing List >>> Subject: Re: Prefix Delegation using ICMPv6 >> >>> Tim - SLAAC and DHCPv6 are fundamentally different ways to assign >>> addresses. >> >> Ralph thanks, I'm glad you (realize that) see my point. There is >> more than one IETF standardized way to do host addressing. Do you >> believe it is good that more than one IETF standardized way to do >> host addressing exists? >> >>> Don't forget manual assignment, as well. DHCPv6 for >>> other information (RFC 3736) has nothing to do with addressing. >> >> Not sure why you mention manual assignment, as the point was about >> IETF standardized ways to do host addressing. Regarding RFC 3736, >> you are correct (good catch). >> >> The point that there is ALREADY at least one such case (node >> addressing) for which there is more than one standardized IETF way >> is irrefutable. >> >> Given that there is a historical precedent for being able to do >> something via more than one standardized IETF way, I'd suggest that >> IPv6 PD is another such case where such an approach is warranted. >> >>> >>> I would be interested in seeing more detail about specific topologies >>> and scenarios in which DHCPv6 PD is inadequate.** >> >> I'd like to repeat my/our contention that ICMPv6 PD is not meant to >> replace DHCPv6 PD. The two are not mutually exclusive. >> >> In some cases, customers may wish to have an alternative to the >> existing mechanism (WHY they wish to have it is a separate >> question, THAT they do is an issue which helped inform the writing >> of our draft). >> >> Customer requirements are often what drive innovation (sometimes >> the other way around). Over the past few years, more customers have >> expressed interest in/requirement for an alternative to DHCPv6 PD. >> Our draft based upon ICMPv6 is one such proposed solution. >> >> BTW, what would be your burden of proof in what you are asking?** >> I'd not want to be chasing my technical tail. =^) >> >>> All I've seen in a quick read of your doc >> >> As I value your technical input, I'd ask you to read the doc in its >> entirety and provide technical feedback. >> >>> is the argument that some hosts may not implement >DHCPv6, so >>> there is a need for some way to accomplish >PD without DHCPv6. >>> But I think Alain refuted that argument >> >> Ralph, I think the point was not refuted. >> >> As I'd mentioned, our approach is based upon ND, which is at least >> virtually ubiquitous in IPv6 implementations, if not entirely so. >> >>> by pointing out that any new PD protocol would also, by >>> definition, not be >>> implemented already in any hosts, so the advantage is minimal. >> >> ICMPv6 PD isn't necessarily as new as might be implied. Please see >> the draft to understand the modifications to RS and RA messages we >> propose. >> >> Further I would contend that there isn't as wide an install base >> for DHCPv6 PD as might be implied here. >> >> Even further, even if there was it would still not preclude the >> presence of another IPv6 PD mechanism. >> >>> >>> We had a long discussion about PD alternatives some time before the >>> DHCPv6 PD RFC was published. >> >> I believe there was, yes. >> >>> The consensus was, at that time, that the protocol >messages and >>> amount of "work" required for PD was >pretty much the same >>> regardless of how the messages >are carried (DHCP, ICMP, etc.), >> >> I would tend to agree. >> >>> and there was also consensus that PD seemed a logical extension of >>> the >address assignment in DHCP, so that consensus was the >>> motivation for DHCPv6 PD. >> >> Are you arguing that said consensus from 2003 (when 3633 was >> published) ends the debate on IPv6 PD? >> >> I respect the fact that you are a co-author of both the DHCPv6 PD >> spec (RFC 3633), and IPv6 PD requirements spec (RFC 3769). >> >> If only DHCPv6 PD is to be standardized by the IETF, please explain >> why RFC 3769 was ever written. >> >> To me, implicit in the publication of 3769 is the notion that ANY >> mechanism that purports to do IPv6 PD needs to meet said >> requirements. We believe our mechanism both does that, and >> satisfies many customer requirements as well. >> >> If consideration of IETF standardization for alternate IPv6 PD >> mechanisms is not allowed (including technical debate of our >> draft), I'd respectfully ask you to tell me why 3769 was written in >> the first place. >> >> Best Regards, >> >> Tim >> Rom 8:28 >> >>> >>> - Ralph >>> >>> On Aug 22, 2006, at 11:48 PM, wrote: >>> >>>>> From: "Durand, Alain" >>>>> Date: 2006/08/22 Tue PM 10:31:10 CDT >>>>> To: timbeck04@verizon.net, Syam Madanapalli >>>>> , >>>> IETF IPv6 Mailing List >>>>> Subject: RE: RE: Prefix Delegation using ICMPv6 >>>> >>>>> >>>>>> Thanks for the quick e-mail. As one of the co-authors, I'd in >>>>>> turn like to reply (and state that ICMPv6 PD is ANOTHER way >>>>>> to do IPv6 PD, NOT a replacement for the existing mechanism). >>>>>> FWIW, please see comments in-line: >>>>> >>>>> This is probably the crux of the issue. >>>> ... >>>>> I believe that having multiple IETF standardized ways to achieve >>>>> the same thing is a bad idea. >>>> >>>> Hi Alain, I respect your opinion but believe differently. BTW, >>>> there is already at least one such instance of their being >>>> "multiple IETF standardized ways to achieve" IPv6 addressing for >>>> nodes. SLAAC (RFC 2462[bis]) and DHCPv6 (RFC 3315), AND DHCPv6 >>>> 'lite' (RFC 3736). >>>> >>>> Tim >>>> Rom 8:28 >>>> >>>>> >>>>> - Alain. >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 23 19:48:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2Qk-0008PJ-Gc; Wed, 23 Aug 2006 19:46:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2Qj-0008IS-EA for ipv6@ietf.org; Wed, 23 Aug 2006 19:46:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG0xm-00012p-7I for ipv6@ietf.org; Wed, 23 Aug 2006 18:12:42 -0400 Received: from vms044pub.verizon.net ([206.46.252.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GG0l7-0007fv-KB for ipv6@ietf.org; Wed, 23 Aug 2006 17:59:41 -0400 Received: from vms172.mailsrvcs.net ([192.168.1.1]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J4H00B2T12XQFH2@vms044.mailsrvcs.net> for ipv6@ietf.org; Wed, 23 Aug 2006 16:59:21 -0500 (CDT) Received: from 129.55.200.20 ([129.55.200.20]) by vms172.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 23 Aug 2006 16:59:21 -0500 (CDT) Date: Wed, 23 Aug 2006 16:59:21 -0500 (CDT) From: X-Originating-IP: [129.55.200.20] To: Ralph Droms , "" Message-id: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: "Durand, Alain" , IETF IPv6 Mailing List Subject: Re: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >From: Ralph Droms >Date: 2006/08/23 Wed AM 06:23:39 CDT >To: "" >Cc: "Durand, Alain" , Syam Madanapalli , IETF IPv6 Mailing List >Subject: Re: Prefix Delegation using ICMPv6 >Some more detailed responses in line... > >- Ralph > >On Aug 22, 2006, at 11:25 PM, > wrote: > >> Hi Alain, >> >> Thanks for the quick e-mail. As one of the co-authors, I'd in turn >> like to reply (and state that ICMPv6 PD is ANOTHER way to do IPv6 >> PD, NOT a replacement for the existing mechanism). FWIW, please see >> comments in-line: >> >>> From: "Durand, Alain" >>> Date: 2006/08/22 Tue PM 09:12:21 CDT >>> To: Syam Madanapalli , >> IETF IPv6 Mailing List >>> Subject: RE: Prefix Delegation using ICMPv6 >> >>> "Currently proposed solution for IPv6 Prefix Delegation is based on >>> DHCPv6 protocol. We believe that in certain network topologies and >>> configurations where the CPE routers may not be capable or >>> configured >>> to use DHCPv6 and hence can not utilize the currently proposed ipv6 >>> prefix delegation procedure. Therefore an alternate ipv6 prefix >>> delegation procedure that does not require or depend on the DHCPv6 >>> protocol is needed." >>> >>> >>> >>> Could you please elaborate on the above rationale for this work? >> >> Alain, that seems to be a fair question. My first inclination is to >> direct you to an e-mail I'd posted to this workgroup about four >> weeks ago (25Jul06, 0742EST, quoted below): >> >> "Good morning all. AFAIK, there is currently no defined way (other >> than via DHCPv6) to do IPv6 PD. It may well be that between a PE >> and CE, DHCPv6 is neither required nor desired, but PD is. > >Without more detail about why DHCPv6 is "neither required nor >desired", it's hard to talk about your e-mail. Hi Ralph, why is it hard to talk about the e-mail without "more detail"? Do you believe that it is theoretically possible that DHCPv6 PD would be "neither required nor desired"? It is here that I'd like to start this portion of our conversation. >I didn't pay close attention; was there followup to your e-mail? No problem. There was some follow-up, primarily (off-line) from the folks that are presently co-authors with me. There should also be a few related e-mails posted to the IPv6 mailing list too. > >> Over the past twelve months or so there has been some interest in >> ICMPv6 PD expressed to me. I'm considering submitting a related >> draft, and seeking a co-author. Kindly reply off-line." >> >> While I welcome your question at the present time, I should say >> that it would have also been welcomed when the above referenced >> mail was first sent. >> >>> >>> Using the DHCPv6 packet format, PD is a 2 packet exchange, >>> and nothing forces any implementation to use the rest of the DHCP >>> machinery. >> >>> The argument that CPE or routers do not implement DHCP is weak >>> because >>> they do not implement this new mechanism either... >> >> IPv6 ND, the mechanism upon which our approach is based, is >> implemented virtually ubiquitously, if not entirely so. Please see >> the draft to see what modifications we propose to accomodate the >> IPv6 PD requirement using ICMPv6.** >>> So if work need to be done, one could argue that implementing a >>> solution based on the DHCPv6 >>> packet >>> format is faster as the mechanism is already standardized... >> >> For "one to so argue" would be to do so incorrectly given the above.** >> >> It is also true that DHCPv6 PD is already standardized (in fact, a >> full six months before the standard that defines IPv6 PD >> requirements in the first place). > >WHile it is true that work on DHCPv6 PD began before the requirements >document, the timing of the publication of the two documents is an >artifact of the RFC publication process. That I truly didn't know, so thanks for the clarification! The PD requirements doc was >fundamentally complete before the DHCPv6 PD RFC was published. The >IETF certainly considered the PD requirements doc in the process of >developing and publishing DHCPv6 PD. > >> The argument that "implementing a solution based on the DHCPv6 >> packet format is faster...", because DHCPv6 PD is standardized, is >> false. > >Maybe yes, maybe no. However, today we have a published standard, >that was developed through a process that considered several >alternatives (including ICMP) and which has been implemented by >multiple vendors. There is at least one open source implementation >available. These implementations have been shown to be interoperable >at the TAHI interoperability tests and are deployed in production today. There's no doubt that DHCPv6 PD works, was carefully considered, and does have an install base. We affirm that fully. The ICMPv6 PD mechanism we propose and the extant DHCPv6 one are not mutually exclusive. That there is already a defined standard does not inherently preclude the introduction of another. > >> Even if the "mechanism" to which you refer is vanilla DHCPv6, AFAIK >> there are NO vendors that implement the entire suite of DHCPv6 >> abilities. Do you know of any? > >Yes, there are several including an open source implementation. I think I know of the open source implementation of which you speak (is it allowed/acceptable to name names?), and believe I know of at least one "major" network equipment vendor that has an implementation. In either case, how wide is the install/operational base? I'm also not sure that customers "choose" the DHCPv6 PD mechanism because up to this point that is the only choice they have been offered. We'd merely like to offer the ICMPv6 PD mechanism to those who, for whatever reason, desire and/or require it). > >> Further, sometimes customer requirements drive innovation (yes >> sometimes, it is the other way around). > >But we haven't seen those customer requirements. Is "we" those of us on this list? Sorry... :^\ Anyhow, I believe at least part of the reason some have not seen those customer requirements is that they aren't aware that they could have a choice even if they wanted it. I also believe that customer requirements aren't always necessarily for DHCPv6 PD specifically, rather for SOME way to to IPv6 PD (which of course up to this point has only been the DHCPv6 way). >> Customer requirements/requests/demands for an alternative (non >> DHCPv6-based) IPv6 PD mechanism are on the rise. We (co-authors and >> I) propose one such way to do it. >> >>> Again, they would not have to implement the whole DHCPv6 machinery >>> if they do not want to. >> >> Perhaps you are correct in this instance, though with the ICMPv6 PD >> based approach, IPv6 PD could be done without it entirely. > >I don't understand the advantage to avoiding DHCPv6 entirely. I'm truly sorry about the misunderstanding on this one... Nobody is proposing an inherent advantage to avoiding DHCPv6 entirely. The point being addressed was just above this text in this e-mail: "...they would not have to implement the whole DHCPv6 machinery if they do not want to." That said, I'd say it's also true that if something is not required, it's OK (and perhaps good as well) to not include it. If for example you have requesting nodes (RNs) that are using SLAAC to get their addresses and do not require any other configuration info, DHCPv6 would probably not need to be run just for the sake of PD. This I believe is a case where the ICMPv6 PD approach is informed. >From the network operator's point of view, you've got to do the same amount of work for any form of PD: fundamentally configure the server with the prefixes to be assigned. We definitely agree on that point. >As I have argued before, we have DHCPv6 PD implemented in IOS. It requires fewer than a handful of CLI commands to configure and you would need the same number of commands to configure ICMP PD. AFAIK it is implemented in IOS on a limited # of platforms (such as the 7301) but not others (such as the GSR). Is it now implemented across all hardware platforms that run IOS? > > From the implementor's point of view, I won't get into an argument about lines of code...but my observation is that implementing DHCPv6 is not particularly onerous. Agreed. Again, we are agreeing that DHCPv6 PD works, is standardized, and has an install/operational base already. I think it's also safe to say that to implement our proposed ICMPv6 PD mechanism would be rather unobtrusive code-wise. It's not either/or. Tim Rom 8:28 > >> I implore you to read the draft in its entirety, as I/we do most >> sincerely welcome the technical review of our proposed mechanism. >> >> Best Regards, >> >> Tim Enos >> Rom 8:28 >> >>> >>> - Alain. >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 23 20:01:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2dI-0005zg-3N; Wed, 23 Aug 2006 19:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2dH-0005zb-I9 for ipv6@ietf.org; Wed, 23 Aug 2006 19:59:39 -0400 Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG2dG-0004bR-3O for ipv6@ietf.org; Wed, 23 Aug 2006 19:59:39 -0400 Received: from eaglet (127.0.0.1:3020) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 23 Aug 2006 16:59:25 -0700 From: "Tony Hain" To: "'Rao Satyanarayana-W60007'" , "'Ralph Droms'" , Date: Wed, 23 Aug 2006 16:59:35 -0700 Message-ID: <1b1701c6c710$2f9efab0$2b7ba8c0@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <92D17ACC46FB33448977916D9EC398F0D30692@ct11exm63.ds.mot.com> Thread-Index: AcbHBAK3eCWfWhItRxObTExu1G62ZQAAMF0gAAI8YbA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "'Durand, Alain'" , 'IETF IPv6 Mailing List' Subject: RE: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Rao Satyanarayana wrote: > ... > What we would like to know now is are there any bugs in the proposal > being specified? Routers do not currently *send* RS messages. Bug == "ICMPv6 is an integral part of the IPv6 stack and hence the proposed mechanism for Prefix Delegation does not require any additional components or applications on either the requester or the delegator for prefix delegation purposes" > I think the questions should be is there merit in the > proposal? That is true, but your section 3 does not establish that merit. > Does it basically work? Probably. > What needs to be modified for it to work? The fundamental ND implementation in the CPE router. > Our claim is that there are situations and configurations where > DHCPv6 may not be enabled or available and hence PD process can not > depend on dhcp protocol. You assert that without attribution. As Ole pointed out you end up reinventing DHCP, but masking it behind an ICMP packet format. > If the PD mechanism can be run utilizing more > basic and fundamental components of the ipv6 stack, why not? That would be fine if those components actually exist. The ability to receive RS and send RA is not the same as what this proposal calls for. > If it > basically works, and if implementers believe that it is simpler and easy > to implement and deploy, it will get used. It does not propose to > replace the dhcpv6 based proposal. The state of DHCP-PD is somewhat irrelevant. The point is that multiple reviews of the document will have to be done before it makes it to RFC. You appear to be unwilling to expand on the fundamental justification, and would rather burn list bandwidth arguing your right to build something different. You need to explain why the DHCP-PD packet format is insufficient, or explain how your state machine sitting behind ICMP will be significantly simpler than a light-weight DHCP client. 'Significant customer demand' is an important metric, but it is not the only one. Start by showing some willingness to actually work within the IETF process by rev'ing the draft to put substantive detail in section 3. Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 23 20:14:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2pu-0005GO-4G; Wed, 23 Aug 2006 20:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG2ps-0005GJ-F6 for ipv6@ietf.org; Wed, 23 Aug 2006 20:12:40 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG2pr-0008Tj-6E for ipv6@ietf.org; Wed, 23 Aug 2006 20:12:40 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7O0Cc5Z019200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Aug 2006 17:12:38 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7O0CcbL011169 for ; Wed, 23 Aug 2006 17:12:38 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7O0COfJ010758; Wed, 23 Aug 2006 17:12:24 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 17:12:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Aug 2006 17:12:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774243@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Prefix Delegation using ICMPv6 Thread-Index: AcbHDo5kV3TXXwNJSxWYS4LAHJgV7gAAbJBw From: "Templin, Fred L" To: X-OriginalArrivalTime: 24 Aug 2006 00:12:25.0131 (UTC) FILETIME=[FA1E77B0:01C6C711] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF IPv6 Mailing List Subject: RE: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Tim, I took a look at the I-D and it reads well. I see that you (and the co-authors) are asking RSs to carry PIOs by way of requesting specific prefixes, and that you are asking for new flag bits (the 'P' bit in the RS message 'Reserved' field and the 'D' bit in the PIO 'Reserved1' field) which would qualify this as an RS/RA-based prefix delegation mechanism. But then, I see in Sections 5.1 and 5.2 that the specification is also asking for new ICMPv6 message types, so the mechanism is apparently not implemented via RS/RA messages alone. Is there a way to do this with RS/RA alone, or do you also need the extra ICMPv6 messages? Fred fred.l.templin@boeing.com=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 00:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG77B-0007MP-Ua; Thu, 24 Aug 2006 00:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG77A-0007Iu-LB for ipv6@ietf.org; Thu, 24 Aug 2006 00:46:48 -0400 Received: from vms040pub.verizon.net ([206.46.252.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG77A-00024c-7n for ipv6@ietf.org; Thu, 24 Aug 2006 00:46:48 -0400 Received: from vms074.mailsrvcs.net ([192.168.1.3]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J4H004SZJXSISE3@vms040.mailsrvcs.net> for ipv6@ietf.org; Wed, 23 Aug 2006 23:46:40 -0500 (CDT) Received: from 129.55.200.20 ([129.55.200.20]) by vms074.mailsrvcs.net (Verizon Webmail) with HTTP; Wed, 23 Aug 2006 23:46:40 -0500 (CDT) Date: Wed, 23 Aug 2006 23:46:40 -0500 (CDT) From: X-Originating-IP: [129.55.200.20] To: Tony Hain , timbeck04@verizon.net, 'Ralph Droms' Message-id: <14515434.344361156394800220.JavaMail.root@vms074.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: "'Durand, Alain'" , 'IETF IPv6 Mailing List' Subject: Re: RE: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Tony, thanks for your reply (and for reading the draft as well). Please see my in-line comments: >From: Tony Hain >Date: 2006/08/23 Wed PM 01:03:47 CDT >To: timbeck04@verizon.net, 'Ralph Droms' >Cc: "'Durand, Alain'" , 'IETF IPv6 Mailing List' >Subject: RE: Re: Prefix Delegation using ICMPv6 >timbeck04@verizon.net wrote: >> >Tim - SLAAC and DHCPv6 are fundamentally different ways to assign >> >addresses. >> >> Ralph thanks, I'm glad you (realize that) see my point. There is more than >> one IETF standardized way to do host addressing. Do you believe it is >> good that more than one IETF standardized way to do host addressing >> exists? > >I believe you are mixing points here. Yes different mechanisms exist, but >they deal with different scenarios. Tony, I am not mixing points though I'm afraid you've missed mine (for which I apologize). I was making one and only one point, that being there is >1 IETF standardized way to do IPv6 node addressing. That's it. At it's most basic the mechanisms deal with one and only one scenario, that being the assignment of IPv6 addresses to nodes. To try and take the point any further than that would be to take it further than I'd intended. >Your draft does not really explain what is different about the deployment scenario that justifies a new mechanism. Actually it does, though I'd be willing to consider including any suggested related text you might have in mind in the next version of our document. >Section 3 has that title, but I would not be able to explain why this is really any different after reading that text. "Motivation for ICMPv6 based Prefix Delegation" is the title. The section does go on to mention a few different scenarios wherein a non-DHCPv6-based PD mechanism would be warranted. Please let me know what additional info you would like to see in this section so we can consider including it in the next version of the document. > >> ... >> > >> >I would be interested in seeing more detail about specific topologies >> >and scenarios in which DHCPv6 PD is inadequate.** >> >> I'd like to repeat my/our contention that ICMPv6 PD is not meant to >> replace DHCPv6 PD. The two are not mutually exclusive. >> >> In some cases, customers may wish to have an alternative to the existing >> mechanism (WHY they wish to have it is a separate question, THAT they do >> is an issue which helped inform the writing of our draft). > >I am not opposed to doing something different, but there needs to be something more than a wish to back it up. Thanks Tony. Please keep in mind the ICMPv6 PD mechanism we propose and the current DHCPv6 PD are not mutually exclusive (I realize you're not saying they are). A real reason why the ICMPv6 PD mechanism is proposed is THAT customers have asked for it. WHY they have asked for it perhaps could be included in future versions of this draft. One possible reason WHY customers ask for it could be that their edge router(s) do not have any DHCPv6 components installed or enabled (WHY they do not have DHCPv6 enabled on their edge router(s) is another question, the answer(s) for which could also be included in future versions of this draft... I'd be happy to take the gathering of said info as an 'action item' from the group). That said, one possible reason for customers not having it enabled on their edge router(s) could be that the only config info required from the PE by the CE is knowledge of what prefix(es) to use for autoconfiguration of addresses and/or what prefixes to be considered for on-link determination. In such a case as that, it would seem unnecessary to enable DHCPv6 on that link just to do PD. The proposed ICMPv6 PD mechanism would easily handle the IPv6 PD requirement. > >> >> Customer requirements are often what drive innovation (sometimes the other >> way around). Over the past few years, more customers have expressed >> interest in/requirement for an alternative to DHCPv6 PD. Our draft based >> upon ICMPv6 is one such proposed solution. > >ICMPv6 is a fine alternative. Agreed! :) It would be edifying to know why folks (other than the draft co-authors) think so. >The question is why is the DHCP approach inadequate? When phrased that way, I feel as if I/we need to better communicate that we affirm the DHCPv6 approach is, ceteris paribus, not inadequate in many instances. The ICMPv6 PD approach that we submit to the group addresses customer need for IPv6 PD when DHCPv6 is not available. This is the point at its most basic: if there is no DHCPv6 enabled, customers can't do DHCPv6-based PD. Again, WHY it is not enabled is a separate question (as an action item from the group, I can include the answer(s) in future versions of this draft). >That will need to be answered clearly if we are going >to make sure the proposed ICMPv6 approach actually >meets the need. I'd tend to say that if the customers say they need it (because they need to do IPv6 PD, yet are not implementing DHCPv6 on, for example, the link(s) between their edge router(s) and their ISP(s) edge router(s)) that means the ICMPv6 approach meets the need. Just for emphasis, I'll again say (last time, I promise!) that I'll take an action item to include some customer rationale in future versions of this draft.** I'd like to know what the group thinks of our proposed ICMPv6 PD mechanism on a technical basis as well. Please see the Introduction for an understanding of what we believe about the ICMPv6 PD solution we propose. > >> >> BTW, what would be your burden of proof in what you are asking?** I'd not >> want to be chasing my technical tail. =^) > >Explain how to evaluate that the proposed approach actually meets a detailed need. Thanks Tony.** > >> ... >> >is the argument that some hosts may not implement >DHCPv6, so there is a >> need for some way to accomplish >PD without DHCPv6. But I think Alain >> refuted that argument >> >> Ralph, I think the point was not refuted. >> >> As I'd mentioned, our approach is based upon ND, which is at least >> virtually ubiquitous in IPv6 implementations, if not entirely so. > >I think their point is that supporting this option requires new code in any case. Perhaps, but arguably very little. >Stepping back, the debate seems to be over the >bits-on-the-wire format, while the architectural >issues are that the requesting router needs >to have a mechanism Yes certainly to the architectural point! The requesting router needs to have A prefix delegation mechanism that conforms to RFC 3769 (not DHCPv6 PD, or any other particular mechanism, per se). We believe both RFC 3633 and our ICMPv6 mechanism do this. >for acquiring a prefix and the delegating router needs to have a mechanism for responding to the request and tracking what is >active. I believe the state machinery to support the >architectural points is essentially the same >regardless of the bits-on-the-wire format. > >Your proposal is essentially asking to chew up reserved flag bits to be able to reuse some bits-on-the-wire code in the requesting and delegating >routers. >Realistically it only reuses RS/RA code in the >delegating router since there is no existing >expectation that a requesting router would implement sending an RS message. Actually, with the implementation of our proposed ICMPv6 PD mechanism the requesting router would indeed be sending an RS message (with the new 'P' flag set, and potentially with one or more PIOs attached to indicate preference(s)). >Your section 3 tends to imply that the primary justification is that some requesting routers don't implement DHCP. While that definitely is a justification, in future versions of the draft... :) >This falls flat when they don't implement sending an RS either... The RN would be sending an RS as noted above. >Tony Best Regards, Tim Rom 8:28 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ogawakeena@kcjazz.org Thu Aug 24 08:20:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEBx-0004hU-Hq for ipngwg-archive@ietf.org; Thu, 24 Aug 2006 08:20:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGCfe-0005hK-U8 for ipngwg-archive@ietf.org; Thu, 24 Aug 2006 06:42:46 -0400 Received: from [211.252.200.1] (helo=kcjazz.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GGCOz-0006vi-VP for ipngwg-archive@ietf.org; Thu, 24 Aug 2006 06:25:35 -0400 Received: by 192.1.113.201 with SMTP id U53hV75P; for ; Thu, 24 Aug 2006 03:25:05 -0700 Message-ID: <000301c6c767$90cd9970$2dc0a8c0@oyjxdvw> Reply-To: "Brynmor Quesenberry" From: "Brynmor Quesenberry" To: ipngwg-archive@ietf.org Subject: eikio Date: Thu, 24 Aug 2006 03:25:05 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01C6C72C.E46EC170" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C6C72C.E46EC170 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C6C72C.E4710B60" ------=_NextPart_001_0005_01C6C72C.E4710B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable your meds directly from the manufacturer, see attach for details _____ =20 our faces-or more likely in the metal of our weapons-because the few A pleasure to meet you, Jim. Our thanks for activating the ------=_NextPart_001_0005_01C6C72C.E4710B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

your meds directly from the manufacturer,

see attach for details

our faces-or more likely in the metal of our weapons-because the = few
A pleasure to meet you, Jim. Our thanks for activating = the

------=_NextPart_001_0005_01C6C72C.E4710B60-- ------=_NextPart_000_0004_01C6C72C.E46EC170 Content-Type: image/gif; name="setaceous86.gif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="setaceous86.gif" R0lGODdhMAHcAMIAAP///wAA/wAAAP8AAJO4yAAAAAAAAAAAACwAAAAAMAHcAAAD/gi63P4wykmr JTbrzbv/YCiOZLlhpoRma+q+cKy0cm1rNJXf0M7/Ih/QI+wNjzgja1ikBJ4BpLTRpFanx6uO+YFG seDkKVzTkmce75l7M6/H7y1HDXPbaPZ4Vq9K0S9wZ3l8U4OFJn+AhB+Gi2GNIZASiTGSd46YSnsu lJUVlpmhog6gEJ1EJKWjq5mgOX9FVaWqerSscbELGIm5MV6/DFAPv18NwsDBT07IxrwAp6cctjzT pAxCBNFHxInCyV/eC95eNOHD3MXP6N9P5eYg1akR8bpUEdoCAg75CvwS/gAAOjDXTZkCggbVFfvV 4h27ZOLC/QG2gtktMX1eaMGn/q+BP4EPAAoQ8g6hsoInJRKLmK5Zy2csXbLMls7ixQeG6CnZ5ZCB QJAa8vkomfBgypfHiiZdWPTbpKZGwUHJxrLnJ0c7dKICQBOqT30oRHYMmE9sv7JAiSKNZnOp1JdR n8IdlzKiQka3qjWqaPUsGpFhx34UPHagUq9370Gl+9YU4riGGy9NfBOjRrwK4X71u0Ao2ZCEFXMT LTdyTKtTSZtOXJdy5SWLtHH+2RHoZ87nRudG3DahbtNDvTKOarBvB62vlz2eXVhs2c6hHTOde9S0 SXa8l/ccnrmxCUjxkFuuSgGtx8LQcQN0N72lGpRRJjZFdt1YTKeQKRufoLfO/ptX+5EFkm2DpVfP fcTh5xpNCKpV3GGHkZdgfqttldyBUsh21oC1RWeWdPXQoZZR7FE4oYMWoVPTYwFeON41NWiIm4EC frghegt2J5xNcTkkYjuRbddJXwxa42IKOsmIGRC2oCCePZocmYmSS/6wF043PXmRHVRKyZ+RW7Yi hRtdHgflmBZyBaaWSB4S5Tw2nKIKHli4smaWfFyhVTTTuEEnJmx6OWWLJfh55iKBYgWGKmUK6kKi gC6qiJoHNuqoPJRe+l0tGKopG6R4gnrJpm6iMYGGGECCHo4QsBqBq6568kGsKdD6ZnItNEGlITja 6lNnE+jTa6vl7SNCYTT4/lqCsprOQeisxnIw1g6wQuvRo7/ywCxsbQxBiRk5JPvVYB3aJqCpzwm7 YUD9bCbYus9Bp2675mEQL7DmjVsbu+fyu2+/8c7Lb6FWAtEJuGAODBa7774bbbb0DsywNQ1DDGy7 9hLw7grNKQyxsP9O7K/EDXdchouWmhrsxRp77DC6D0/cHKsjlXyxxQtnCvK9IpOM783qBn1bjepy 3C2cgy735crtRuy0xGoOG3XPVD8dmtROVxySx0BzLXPP/KwKc6dMynGZcpqlGsLLAre99bUzCH2x 2C9XDTXbXoP9sdcdGf2r1jerzCnSaUqnmZqSEEZu01DTCK+/YQcOlnn3/nIIdOUD5p3vzIKFte7n JrtIQJLPerAtPNIKvkHoopwupi+lm27mi/+MwHomrrORMOoapEzN0YM3u7Q1lpAZO8FowjiCJH8W zO3ubbLpjPNIhBeJpFhCT7by3APCfAbfCn9ys3NqPyrahItP6vjUdy/+p+rjWbb5jvoe/+vBH2n/ /UHIIOrwzzPbDbr0v9doCRv4u0oAN1CmAlZpeYhKXyAq44Mq8AmAocjKAxWIvN/dihWjk8vhQihB +flve/BwoOp0t0CS9GQFKrxQuCAYvybkwQwXFCAZEnXDFfpwfriYwv4yhcEJFrGDh5rUB4HIPxG2 TxollNUSaRjE/JHA/ncx/OEJ6WdEIm7welbUocrs14TcYep8Z8MWCMxlwOwNsXZeHIAc5+gAOjJA jnUcAADmOEcC4DGPfPzjHvl4R0I2QI9JbJMM0JIvrpiRdrYzo4yal7BpLUCQgzwkJjOpSU5SYJOX RCQnBYlJUSZygzqxXECQU7x9SLJFlDwTjv6IglLq0ZZ59OQEQKnLTJLSlKY80/d+AJSwPbKLRUzW K5W2uRqdp5GhRCEeN4nLXkZAjjmg5i1FScqMzMCQvrRjLqOpgECSM5rTBGUxQeZMfV2NHy3bXFlI yMhnjmRot2GjE1/1t9CJTZPBLOQ5dflHXj6gj7/sZEL3WE5wmmqh/uLcZKqAiUiIBjOdDu1HDowZ naGRK10t+9xnNNZRkeCzQM5S2t+IKDBpmlOgDYXpNxsaSIPCVJueLChXuBlQnPrxkHgYQAvSqdCL bvMf93TXqmDFzs1Ah2PISs86ncpGFzKTciprqUYP+tKYepWc2CynFmhA1DtiIKEVXQEocSpUTWaz onAtqlxftdQZnbSeqvRLYHxCUmOCRj2WPGVm4Og0o2HtmgWtKR5rGdeG5ip96RxqW1+a1oF+NaY4 HWdi54rOgLoTc+eZkV+dKtoOKfWvHo1qBfBxrcBqtXFcvSwnz9pYa16BqGr1LEMdK9teltWyXt2s QNmqW7uS1i+W/svrXfH5GQKZ1rir7QvdjHVY2f4WprSt5i6N6lvPUhS4tMTsRX0ATuJyFrXoRW5d lUsb5o7WlfoEn3TdFa2ZjTO43qWodiWg3YXWUaa8pKVwQ7kDPub2nL88Kl0XfFp5ude+UuWceuQF YQYap16NU9xrB9lH4BJUnByuKVcz2tVDAtKmXc1sbDNV4hCHE6kMNhBem+q49hIttcplrgXg5z4q snAUNkWikHkXrGO65HBalKEiZRDkIfsYjDAewRubKEYTNLlOb4hv747XPyoDL3vsE9SUoehlwRLZ Hlm8xZjL3OUvpzHJpbKwSsNUPQ72GIRmxnJKkSzYNKPQzR/0/rOd77y+AZaugv8ZhaDJzMUny2DN /mF0AiWtRClautLyfUwMB7HoN2Pa02dDGGx4bEI2N9F6kDa1qhfoaABuhMtHFMWTOh3mPMc6fVdI NZwVBehV03rMtKD1qp8IBm3Y4djeHLb4EL1DUif7z7ZWdg0BBetTClvPu1bfteX0COE9NoJoTBMt 1DBD7LU60eBOnp0Z5Y1r3xracabHAUHtrWqrO9p58qCn3b3nvKzBgQCHd2V0rSlE/y/N4NF3dOf8 blkPGt9qBPPsnDzFJevK3gKPNF2Z1Ur/0AmBXzxzGB/Sql6Vy+RMrSfRzPUcIRi5A2vN6ImN6sdY SvvZO5au/skdp95nhtbGDSYWzkOgYhTzFMHFlbYN+x3j5f68riU/bs/52fAMILS4V+6t1qXU8RLI Bug6fq+OjztVNmIVcz8BGBsja9CsW3PrXI/D18FirwrjJqRjrzHU866wfzLORq667n13Sd6kUxwz /A5SkbmCd7sChufXsBGNzB64DDOOX/aCgOBpikghEFKybj834uE81jjtB6U8B7yG4any0EL373DL VugaD9Ckh5e/ug39pBs9g2GKhs+oLy0jgx9h4w6fZ3uzWNNYZ6vPr/iTuTc8+Sr+aQkhdaqpf+7T s+/6h/l9btnKPO4z+VYLtF36eNZT1TsgI2iWtvtlnxlU/rsf++8vH2K0z+XtPfz8TvobTnZSONa3 cTsHXYsTdGdRd+nVNbGnOcrXWaN0YEg3gXC3expHaROyePZkgM2hMX1lfMJCLTRTeTeCMw8YSg7V YrYEYiGGfuv3Y3qwP0tnBMj2bvSge7pXaILwa4fWaDw0dCMQerqXE6tQPn2GPpCkarRldS6oC5ym bRL3QxfHcElIfRn0glWmbKRDhVUYhZeSeOomaAQXRUAoevlWa5vgRWEAabKATOURX2CohhFHQbyH hNeHdlGFfPAEX5yDfIQFZds1c7gnYn6kWOfTC2QYbnK4ZcvBM5I3dZyxUXanZZenRDCUEUXXhAKW bR2E/ohWmG6D1XSuNIqe8XqpZS0TNFYtJlPj91VO8nACyD988RjxFX+UYnYdtTrp0i/tRC8HGFub V4EUiG+zgIYhJwKpEXVRNnm5CH/H1Iz+FBriRwoKpnnoV0qFmINFeHgLxBEayIyQp3eUWH8NeH83 k39i9XYyZ41Goo03Z0TeuIyAZSCSCBrjmDeW5zMkyFhBdmVN5o6gqHCZdji12Icqtx70N4oVUDf5 yHxgto6u2H8SqWRdCIunonPf+GCmqE/jyJBS45Djd37u02SFiCtt9gNzt4wk5Xq4KI+EZX8jIzmB KJKIpQNNGJBnOIAw4ogL83hUIHbOKHUvGTN1czsQ/jhg+xVgR/eOW5SBRjJ8uhAwrBJPx1eCN3KP +GiVl2eUulBiKvhdIwaQ29iUcpYOcQhxj4KDN3lqkTYI4ZOF5jYEQriWTPlFufYOpfdvxtiVTIhn 03eRUOF7TERvGeeFOImBo0BwZxlne1mGsViRMDCGI0dlPfSYgChyPySZiuhznHiFgpCIO2SY8Sh1 ephye0WKCLlKOXOCndmXEymIg7eIPyg8o6l3TvdXCoiaeegP4gKaMBd9gdhbobeYmJCS3Ad2Qamb fSh0NiBiKLiWCUaXhLCYxul4NMZ3j6hetOFc6eIcHSOVsUJUKmZ+3BWal5k0SAZ2qhdjzrVK+XSd /rL3fSVVNwdGk67Jf2RJaM2iIcG3kvOojGNnTP4JlOD3gCGjjwcSjG9Xk/5XmCcJl8nBn9oXN+Co Otm5kh81I34DkwfKlZzHjoKllHVoGU9YP6c3ocfXn6RlG1RplSDhOXdTXyY4iD3lWeX3mnNInC/Q fqXJkqu5ojRDY9lpjiTYoawJgay4QkZXlygZIO6nSrypkLfxigSamzJqoFu1lTNZnofSj50HoUxq hwQolM0VKzYWQiHFoixXiQiaMx4qnlw6jCC6iPoZpoDJZ9b5VymqlUSDdyxXLbAFTarFpvwIYoT4 VYrFUxBpp1eEcd42PG63hA86bfXGhbwmBXPJ/o1oGSkG46iXBqZMpolf6pgTx6hEpJmTSpgCOaJ0 aqqagKoOJzquyn6eSmyzyqr56Qio2iSu2oa+KYCJB6s6yj3BdoGlqqmxUatQKDiCmatslgdk1KrD ihHCNq06uDsyKK2XiqyW2auSBquc6pm3uqmKV3DjqnSG85lzSJFsOZhOGZeQ6azGeq2sxq0xoqzY hmm+apj/d6xt1BD4Wmf+ymx0aq3vqDbvSmfy6qDnWiiSAK6USpkZtBcQ27Bj6W3tZrFkabARGg4c G3cMq2jTyR54KihEqLHPtmkAa6my6q/dxrB9Qq6t2aQsm5MmK0CiJrPE2qqrYGz86mM1aDuk/rqu m+myN4EPJFSngKgFLxczXti0KBuvu0F1vbkGSZW0qJgBUBu19Xpn5MCc5aiuJMQrqbNsoCqu5EEn SVV/AcO2tOJ+vph2DhY1L/pZFFaJB/qXQ3sRfPKjRFo1IQOobCq3fAN7yvNP3wk3W0uvKMsRe3ql MUmCTtuQK2R/+RdYkcuQYvtpGsSYWPh7VMdSFBa4eFtyfviRWVp5OLJRnfGBhXtGFjminauz9jqz 5fo2WaWlXFOVRDm5/4JycIu6BZqVmNkHQTurrLU1ftc2ZTQ2WBq5khu2NUOOHjqYM+i5Z9u1YzRf yht5P4MxhDWNRfq3bOq7XgQ43Qq7P7uq/tlbfZXCvdTFV8pnlHY3uIYLvSMoVWQXtrFrq3pJBslb X7tYpH5YgtWFv9tppgOMVar7v0dSrAxbsVJyOrNZZtfLszp5P6rihhZctCAgweimRLmzaXubqr9q aDXbwdjbrYLmQCDcruqrru8TsIybvvMawqlYvDFIwzVstEpow9p7Bi98bwvLtTrMiCX7wOwri5M5 kEbMpB+bwUxJnNYTrlWYjIyKtZ9bxEfswEk4xArbvkobCJASxaG4rUHQaWPbZp7Yw6ygmcVIu4wH bvPGqNEqxmT8xHZsb1nUHyscsTGMxBxsrn+8rLV7u0EcyLhqr/vasNLDw4osx108xmZMTrQhGwJD VMlufMkeLLBY8EZU3Gvr68mDPHB4aba2C68YXMqDxkr3GpioHMapXMJS65hxfGRcW8eijMeI6cNq CMa0bJ673L+mciVoizYJAAA7 ------=_NextPart_000_0004_01C6C72C.E46EC170-- From ipv6-bounces@ietf.org Thu Aug 24 08:39:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEQS-0004pF-8l; Thu, 24 Aug 2006 08:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEQQ-0004og-3Y for ipv6@ietf.org; Thu, 24 Aug 2006 08:35:10 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGEQN-00085h-Qb for ipv6@ietf.org; Thu, 24 Aug 2006 08:35:10 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id k7OCZ51G016958; Thu, 24 Aug 2006 05:35:06 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k7OCZ1wO001722; Thu, 24 Aug 2006 07:35:02 -0500 (CDT) Message-ID: <44ED9CF4.7020802@motorola.com> Date: Thu, 24 Aug 2006 14:35:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rao Satyanarayana-W60007 References: <92D17ACC46FB33448977916D9EC398F0D30692@ct11exm63.ds.mot.com> In-Reply-To: <92D17ACC46FB33448977916D9EC398F0D30692@ct11exm63.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: "Durand, Alain" , IETF IPv6 Mailing List , Ralph Droms Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Rao Satyanarayana-W60007 wrote: > Ralph, Implementation and test effort is always there whether it is a > existing protocol or a new protocol to catch implementation specific > bugs. Even if one licenses a particular implementation, there is > always testing involved though the effort can be less focused on > testing the licensed components but the integrated system. If the > proposal has merit and looks appealing, implementations will come. > > What we would like to know now is are there any bugs in the proposal > being specified? Come on, I am not here to debug a specification, no? > I think the questions should be is there merit in the proposal? The proposal has merit. ICMPv6 could carry prefixes. > Does it basically work? It could. > What needs to be modified for it to work? What do you think? > Our claim is that there are situations and configurations where > DHCPv6 may not be enabled or available and hence PD process can not > depend on dhcp protocol. Which are those situations? DHCPv6 software is widely available. Most run in userspace. Most parts of ICMPv6 on most platforms runs in kernel space. It's easier to implement in userspace. What are the situations you think of? > If the PD mechanism can be run utilizing more basic and fundamental > components of the ipv6 stack, why not? If it basically works, and if > implementers believe that it is simpler and easy to implement and > deploy, it will get used. What is the potential scope of this deployment? How large? Any interoperability needs between any two manufacturers. > It does not propose to replace the dhcpv6 based proposal. What are the situations where DHCPv6-PD does work ok? Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 08:42:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEWc-0005g2-EE; Thu, 24 Aug 2006 08:41:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGEWa-0005fw-Lv for ipv6@ietf.org; Thu, 24 Aug 2006 08:41:32 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGEWZ-0000Dj-El for ipv6@ietf.org; Thu, 24 Aug 2006 08:41:32 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motorola) with ESMTP id k7OCfTgj025971; Thu, 24 Aug 2006 05:41:30 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k7OCfNqK004624; Thu, 24 Aug 2006 07:41:25 -0500 (CDT) Message-ID: <44ED9E71.2040500@motorola.com> Date: Thu, 24 Aug 2006 14:41:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: timbeck04@verizon.net References: <14515434.344361156394800220.JavaMail.root@vms074.mailsrvcs.net> In-Reply-To: <14515434.344361156394800220.JavaMail.root@vms074.mailsrvcs.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "'Durand, Alain'" , 'IETF IPv6 Mailing List' , Tony Hain , 'Ralph Droms' Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org timbeck04@verizon.net wrote: >>> In some cases, customers may wish to have an alternative to the >>> existing mechanism (WHY they wish to have it is a separate >>> question, THAT they do is an issue which helped inform the >>> writing of our draft). >> I am not opposed to doing something different, but there needs to >> be something more than a wish to back it up. > > Thanks Tony. Please keep in mind the ICMPv6 PD mechanism we propose > and the current DHCPv6 PD are not mutually exclusive (I realize > you're not saying they are). > > A real reason why the ICMPv6 PD mechanism is proposed is THAT > customers have asked for it. Customers of what? Customers at home for ISP and DSL? Customers of netlmm deployments? Customers of mobile routers? You could mention a little more of the customer landscape you see, in current IETF effort terms, and still stay technical. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 09:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGFao-0004fi-6S; Thu, 24 Aug 2006 09:49:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGFan-0004fG-0a for ipv6@ietf.org; Thu, 24 Aug 2006 09:49:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGDyU-0002aG-J1 for ipv6@ietf.org; Thu, 24 Aug 2006 08:06:18 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGDhq-0000n2-Vk for ipv6@ietf.org; Thu, 24 Aug 2006 07:49:10 -0400 Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:3d5a:cc2c:134c:d985]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0B74415228; Thu, 24 Aug 2006 20:48:58 +0900 (JST) Date: Thu, 24 Aug 2006 20:48:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bob.hinden@nokia.com In-Reply-To: <9C92DEEC-18B9-4CD1-869E-394A9A95921F@nokia.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10177422F@XCH-NW-7V2.nw.nos.boeing.com> <9C92DEEC-18B9-4CD1-869E-394A9A95921F@nokia.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Templin, Fred L" , ipv6@ietf.org, Suresh Krishnan Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >>>>> On Mon, 21 Aug 2006 14:45:55 -0700, >>>>> Bob Hinden said: >> In particular, the text of Section 2.4, paragraph 1 beginning: >> "But DHCPv6 will solve the privacy issue" is new since RFC3041 >> and seems to make questionable statements about the use of DHCP >> for generating temporary addresses, since 1) the server can be >> configured to hand out temporary addresses with short preferred/ >> valid lifetimes, and 2) the client can go back to the server to >> get new temporary addresses whenever it wants to regardless of >> preferred/valid lifetimes. >> >> Again, unless I am missing something, suggestions are to >> 1) remove this new text from Section 2.4, and 2) relax any >> text (including the document title) that links the generation >> of privacy addresses with Stateless Address Autoconfiguration. > I agree that the text in Section 2.4 that is incorrect should be > fixed or removed. > This document is in the IESG for Draft standard, so I think it is out > of scope to make broader changes like changing the document title, etc. I agree with you on both the points. I think we can simply update the first paragraph of Section 2.4 to something like this: One way to avoid having a static non-changing address is to use DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server can be configured to hand out "temporary addresses", which are never renewed and provide the same property of temporary addresses described in this document with regards to the privacy concern. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s., I also think RFC3315 could have been more specific about how to update the temporary addresses rather than stating "DHCPv6 says nothing about details" (Section 12 of RFC3315). We should eventually do that in some place, but (IMO) it's definitely not in privacy-addrs-v2. Perhaps we can do it in rfc3315bis in the future... -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 10:06:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGFqG-00043T-Ey; Thu, 24 Aug 2006 10:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGFqE-00042G-RC for ipv6@ietf.org; Thu, 24 Aug 2006 10:05:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGETd-0008HV-SP for ipv6@ietf.org; Thu, 24 Aug 2006 08:38:29 -0400 Received: from motgate.mot.com ([129.188.136.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGEL4-00025T-FM for ipv6@ietf.org; Thu, 24 Aug 2006 08:29:39 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motorola) with ESMTP id k7OCTUgj020861; Thu, 24 Aug 2006 05:29:30 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k7OCTOJY005721; Thu, 24 Aug 2006 07:29:25 -0500 (CDT) Message-ID: <44ED9BA3.1010500@motorola.com> Date: Thu, 24 Aug 2006 14:29:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rao Satyanarayana-W60007 References: <92D17ACC46FB33448977916D9EC398F0D30474@ct11exm63.ds.mot.com> In-Reply-To: <92D17ACC46FB33448977916D9EC398F0D30474@ct11exm63.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.5 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Durand, Alain" , IETF IPv6 Mailing List , Ralph Droms Subject: Prefix Delegation what for? (was: Re: Prefix Delegation using ICMPv6) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Satya and icmpv6-pd draft co-authors, Rao Satyanarayana-W60007 wrote: > We believe that there is a need for an alternate way of doing PD > simply because the DHCP PD is not intrinsic to the stack and makes it > unusable sometimes. ICMPv6 is intrinsic I understand there may be a need for ICMPv6-PD, but there's also a need to motivate it better than just that. Why do you need PD in first place? (regardless of DHCP or ICMP based). Is it for a DSL-like deployment for users in their SOHO or their house to get an IPv6 prefix and distribute to the other PCs in house? Is it for a mobile phone to connect to a cellular-like wireless provider? There wouldn't be a need for a prefix in that case. Is it for a netlmm-like deployment where prefix-per-mobile seems to be the guiding line? In that deployment there's no need to assign an entire prefix to the mobile, just the address has to be derived from a specific prefix. I.e. a netlmm mobile wouldn't need to propagate further sub-prefixes. Is it for a mobile phone acting as a mobile router (NEMOv6) and needing to offer addresses to other hosts in its moving network? Please explain why do you need PD in first place (regardless of DHCP or PD). This is stuff that has already been discussed in all the above contexts. What is _your_ context? > ( by intrinsic, I mean that is always available in the ipv6 stack > implementations) This makes little sense to a wide various audience. There are available IPv6 stack implementations that do today DHCPv6 and PD. They are more available than others (depending where from you look at it). Some Mobile Devices have built-in IPv6 ICMPv6 stacks that are hardly modifiable, for which it is much much easier to modify DHCPv6 to PD. Please describe _your_ context and acknowledge where DHCPv6-PD _could_ work. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 10:34:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGFi-0007ws-SE; Thu, 24 Aug 2006 10:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGFi-0007wk-2D for ipv6@ietf.org; Thu, 24 Aug 2006 10:32:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGETy-0008HV-DV for ipv6@ietf.org; Thu, 24 Aug 2006 08:38:50 -0400 Received: from ftpbox.mot.com ([129.188.136.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGETv-0002PQ-PB for ipv6@ietf.org; Thu, 24 Aug 2006 08:38:50 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id k7OCciLK024195; Thu, 24 Aug 2006 07:38:44 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k7OCcdKW003359; Thu, 24 Aug 2006 07:38:41 -0500 (CDT) Message-ID: <44ED9DCE.4060102@motorola.com> Date: Thu, 24 Aug 2006 14:38:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: timbeck04@verizon.net References: <22402264.193591156374944552.JavaMail.root@vms172.mailsrvcs.net> In-Reply-To: <22402264.193591156374944552.JavaMail.root@vms172.mailsrvcs.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.5 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IETF IPv6 Mailing List , Ralph Droms Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org timbeck04@verizon.net wrote: >> We do not create alternative ways to >do the same thing, because >> doing so will burden >implementors with additional complexity and >> reduces >the likelihood that nodes can communicate >successfully. >> Picking a common way to do something is >the fundamental idea >> behind standards. > > In general that is true. However, for things such as IPv6 node > addressing we have DHCPv6 and SLAAC. The point is THAT there is >1 > way to do something (in this case IPv6 node addressing). It's not because there may exist several ways to skin a cat that there should also be several ways to skin a dog. If we're to compare, I'd compare the ICMPv6-PD effort with the RA option to carry DNS Server effort. If things are to evolve quicker then we could skip some intermediary steps. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 10:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGRl-00065U-D7; Thu, 24 Aug 2006 10:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGRj-00065P-No for ipv6@ietf.org; Thu, 24 Aug 2006 10:44:39 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGGRh-0003OC-ER for ipv6@ietf.org; Thu, 24 Aug 2006 10:44:39 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7OEibvF014701 for ; Thu, 24 Aug 2006 07:44:37 -0700 (MST) Received: from ct11exm63.ds.mot.com (ct11exm63.am.mot.com [10.177.8.47]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k7OEia9J010745 for ; Thu, 24 Aug 2006 09:44:36 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Aug 2006 10:44:35 -0400 Message-ID: <92D17ACC46FB33448977916D9EC398F0D30788@ct11exm63.ds.mot.com> In-reply-to: <44ED9CF4.7020802@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix Delegation using ICMPv6 thread-index: AcbHebpT6HZMJlj6RWC6QuOHsoJOXQAEZFKQ From: "Rao Satyanarayana-W60007" To: "Petrescu Alexandru-AAP021" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "Durand, Alain" , IETF IPv6 Mailing List , Ralph Droms Subject: RE: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Inline. - Satya Rao Mobile Devices Technology Office Motorola Tel: 512-996-6781 Email: sbrao@motorola.com =20 > -----Original Message----- > From: Petrescu Alexandru-AAP021=20 > Sent: Thursday, August 24, 2006 7:35 AM > To: Rao Satyanarayana-W60007 > Cc: Ralph Droms; timbeck04@verizon.net; Durand, Alain; IETF=20 > IPv6 Mailing List > Subject: Re: Prefix Delegation using ICMPv6 >=20 > Rao Satyanarayana-W60007 wrote: > > Ralph, Implementation and test effort is always there=20 > whether it is a =20 > > existing protocol or a new protocol to catch implementation=20 > specific =20 > > bugs. Even if one licenses a particular implementation, there is=20 > > always testing involved though the effort can be less focused on=20 > > testing the licensed components but the integrated system. If the=20 > > proposal has merit and looks appealing, implementations will come. > >=20 > > What we would like to know now is are there any bugs in the=20 > proposal =20 > > being specified? >=20 > Come on, I am not here to debug a specification, no? I do not know what you mean by debug? Did anybody not say if a proposal you may have submitted may or not work in some or certain cases?. Did they not comment on the plus and minus points of the proposal? That's what I mean by bugs in the proposal. -satya -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 10:55:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGZS-0000CR-De; Thu, 24 Aug 2006 10:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGZQ-0000CL-Ad for ipv6@ietf.org; Thu, 24 Aug 2006 10:52:36 -0400 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGGZP-0004T8-0V for ipv6@ietf.org; Thu, 24 Aug 2006 10:52:36 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate.mot.com (Motorola/Motorola) with ESMTP id k7OEqYgj003038 for ; Thu, 24 Aug 2006 07:52:34 -0700 (MST) Received: from ct11exm63.ds.mot.com (ct11exm63.am.mot.com [10.177.8.47]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k7OEqW5C010818 for ; Thu, 24 Aug 2006 09:52:33 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Aug 2006 10:52:31 -0400 Message-ID: <92D17ACC46FB33448977916D9EC398F0D30794@ct11exm63.ds.mot.com> In-reply-to: <39C363776A4E8C4A94691D2BD9D1C9A101774243@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Prefix Delegation using ICMPv6 thread-index: AcbHDo5kV3TXXwNJSxWYS4LAHJgV7gAAbJBwAB8LOVA= From: "Rao Satyanarayana-W60007" To: "Templin, Fred L" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF IPv6 Mailing List Subject: RE: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi Fred, Well, the intention is to use RS/RA for PD but use icmp type/code for any error messaging for the PD process between the requesters and delegators. Thanks, - Satya Rao Mobile Devices Technology Office Motorola Tel: 512-996-6781 Email: sbrao@motorola.com =20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Wednesday, August 23, 2006 7:12 PM > To: timbeck04@verizon.net > Cc: IETF IPv6 Mailing List > Subject: RE: Re: Prefix Delegation using ICMPv6 >=20 > Tim, >=20 > I took a look at the I-D and it reads well. I see that you=20 > (and the co-authors) are asking RSs to carry PIOs by way of=20 > requesting specific prefixes, and that you are asking for new=20 > flag bits (the 'P' bit in the RS message 'Reserved' field and=20 > the 'D' bit in the PIO 'Reserved1' field) which would qualify=20 > this as an RS/RA-based prefix delegation mechanism. >=20 > But then, I see in Sections 5.1 and 5.2 that the=20 > specification is also asking for new ICMPv6 message types, so=20 > the mechanism is apparently not implemented via RS/RA=20 > messages alone. Is there a way to do this with RS/RA alone,=20 > or do you also need the extra ICMPv6 messages? >=20 > Fred > fred.l.templin@boeing.com=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH1i-0006TB-AG; Thu, 24 Aug 2006 11:21:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH1h-0006T6-Jw for ipv6@ietf.org; Thu, 24 Aug 2006 11:21:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGH1f-0000LY-9l for ipv6@ietf.org; Thu, 24 Aug 2006 11:21:49 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 11:21:47 -0400 X-IronPort-AV: i="4.08,165,1154923200"; d="scan'208"; a="98455009:sNHT120975782" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OFLiDe012178; Thu, 24 Aug 2006 11:21:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7OFLidM003429; Thu, 24 Aug 2006 11:21:44 -0400 (EDT) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 11:21:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Aug 2006 11:21:43 -0400 Message-ID: <8E296595B6471A4689555D5D725EBB2102113D1D@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix Delegation using ICMPv6 Thread-Index: AcbHil6IqG54iAmdT4GiISqNC56FQgABmYhw From: "Bernie Volz $volz$" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 24 Aug 2006 15:21:44.0467 (UTC) FILETIME=[02047630:01C6C791] DKIM-Signature: a=rsa-sha1; q=dns; l=1755; t=1156432904; x=1157296904; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=22Bernie=20Volz=20$volz$=22=20 |Subject:RE=3A=20Prefix=20Delegation=20using=20ICMPv6 |To:=22Alexandru=20Petrescu=22=20, =0A=20=20 =20=20=20=20=20=20; X=v=3Dcisco.com=3B=20h=3DPrkvYp6z35JhUrK3I21Ve2354oo=3D; b=j6mlJlZHqM3e2fSFakv4q1WXRiup5WhlYs1BDmyfiztqrgYLqbBotZQrPRsfCxENPKSKqYev GEC/K4xEJldNUgVdt3oIAafWZ48LEQNSHFkHsSKaIvFtax7zUe13EppI; Authentication-Results: rtp-dkim-2.cisco.com; header.From=volz@cisco.com; dkim=pass ( 68 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IETF IPv6 Mailing List , "Ralph Droms $rdroms$" Subject: RE: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >If we're to compare, I'd compare the ICMPv6-PD effort with the RA option >to carry DNS Server effort. If things are to evolve quicker then we >could skip some intermediary steps.=20 Exactly. Why have two ways to the same thing! That's another effort that should be terminated. Gee, why don't we just encapsulate DHCPv6 options in RA/RS? Then, we'd solve all of these problems and be able to get rid of "DHCPv6". - Bernie -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Thursday, August 24, 2006 8:39 AM To: timbeck04@verizon.net Cc: IETF IPv6 Mailing List; Ralph Droms (rdroms) Subject: Re: Prefix Delegation using ICMPv6 timbeck04@verizon.net wrote: >> We do not create alternative ways to >do the same thing, because=20 >> doing so will burden >implementors with additional complexity and=20 >> reduces >the likelihood that nodes can communicate >successfully.=20 >> Picking a common way to do something is >the fundamental idea=20 >> behind standards. >=20 > In general that is true. However, for things such as IPv6 node=20 > addressing we have DHCPv6 and SLAAC. The point is THAT there is >1=20 > way to do something (in this case IPv6 node addressing). It's not because there may exist several ways to skin a cat that there should also be several ways to skin a dog. If we're to compare, I'd compare the ICMPv6-PD effort with the RA option to carry DNS Server effort. If things are to evolve quicker then we could skip some intermediary steps. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH67-0007MP-HU; Thu, 24 Aug 2006 11:26:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH66-0007M0-6R for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGH66-0000yS-43 for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:22 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGH64-0006qi-7V for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:22 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7OFQJYn013260 for ; Thu, 24 Aug 2006 11:26:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7OFQJoE097070 for ; Thu, 24 Aug 2006 11:26:19 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7OFQI9M022568 for ; Thu, 24 Aug 2006 11:26:19 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-155-121.mts.ibm.com [9.76.155.121]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7OFQHcT022484; Thu, 24 Aug 2006 11:26:18 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k7OFQJo1020682; Thu, 24 Aug 2006 11:26:20 -0400 Message-Id: <200608241526.k7OFQJo1020682@cichlid.raleigh.ibm.com> To: timbeck04@verizon.net In-reply-to: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> References: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> Comments: In-reply-to message dated "Wed, 23 Aug 2006 16:59:21 -0500." Date: Thu, 24 Aug 2006 11:26:19 -0400 From: Thomas Narten X-Spam-Score: -2.6 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Durand, Alain" , IETF IPv6 Mailing List , Ralph Droms Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Hi Ralph, why is it hard to talk about the e-mail without "more detail"? > Do you believe that it is theoretically possible that DHCPv6 PD > would be "neither required nor desired"? Please make the case here (using technical justifications). Basic the need for a new protocol on theoretical possibilities has repeatedly been problematic in the IETF. > It is here that I'd like to start this portion of our conversation. I would not. Starting off with the assertion that "its theoretically possible that the existing protocol isn't desired, therefore we should invent a new one" is a complete non-starter for the IETF. We do engineering here, presumably solving real problems, where the existing solutions are inadquate or non-existent. > There's no doubt that DHCPv6 PD works, was carefully considered, and > does have an install base. We affirm that fully. In which case, there would appear to be no need to talk about a new protocol, since you appear to admit that an existing standard does solve the problem. If you want this group to consider a new protocol, start by convincing us that: 1) there is a real (not theoretical) problem that needs solving, and 2) the existinFrom ipv6-bounces@ietf.org Thu Aug 24 11:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH67-0007MP-HU; Thu, 24 Aug 2006 11:26:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH66-0007M0-6R for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGH66-0000yS-43 for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:22 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGH64-0006qi-7V for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:22 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7OFQJYn013260 for ; Thu, 24 Aug 2006 11:26:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7OFQJoE097070 for ; Thu, 24 Aug 2006 11:26:19 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7OFQI9M022568 for ; Thu, 24 Aug 2006 11:26:19 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-155-121.mts.ibm.com [9.76.155.121]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7OFQHcT022484; Thu, 24 Aug 2006 11:26:18 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k7OFQJo1020682; Thu, 24 Aug 2006 11:26:20 -0400 Message-Id: <200608241526.k7OFQJo1020682@cichlid.raleigh.ibm.com> To: timbeck04@verizon.net In-reply-to: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> References: <31921528.178091156370361378.JavaMail.root@vms172.mailsrvcs.net> Comments: In-reply-to message dated "Wed, 23 Aug 2006 16:59:21 -0500." Date: Thu, 24 Aug 2006 11:26:19 -0400 From: Thomas Narten X-Spam-Score: -2.6 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: "Durand, Alain" , IETF IPv6 Mailing List , Ralph Droms Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Hi Ralph, why is it hard to talk about the e-mail without "more detail"? > Do you believe that it is theoretically possible that DHCPv6 PD > would be "neither required nor desired"? Please make the case here (using technical justifications). Basic the need for a new protocol on theoretical possibilities has repeatedly been problematic in the IETF. > It is here that I'd like to start this portion of our conversation. I would not. Starting off with the assertion that "its theoretically possible that the existing protocol isn't desired, therefore we should invent a new one" is a complete non-starter for the IETF. We do engineering here, presumably solving real problems, where the existing solutions are inadquate or non-existent. > There's no doubt that DHCPv6 PD works, was carefully considered, and > does have an install base. We affirm that fully. In which case, there would appear to be no need to talk about a new protocol, since you appear to admit that an existing standard does solve the problem. If you want this group to consider a new protocol, start by convincing us that: 1) there is a real (not theoretical) problem that needs solving, and 2) the existing mechanisms do not address it properly, and 3) the best way to address the problem is with a new mechanism (and it's better than other proposed ways of fixing the problem). At this point, AFAIAC, you have not gotten past either points 1) or 2). Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH69-0007O6-B7; Thu, 24 Aug 2006 11:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH68-0007Nq-4P for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGH68-0000z2-2d for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:24 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGH3K-0006mj-9s for ipv6@ietf.org; Thu, 24 Aug 2006 11:23:31 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7OFNOo3008729 for ; Thu, 24 Aug 2006 11:23:24 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7OFNOAs251320 for ; Thu, 24 Aug 2006 11:23:24 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7OFNNxc010222 for ; Thu, 24 Aug 2006 11:23:24 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-155-121.mts.ibm.com [9.76.155.121]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7OFNNWh010116; Thu, 24 Aug 2006 11:23:23 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k7OFNNB2020547; Thu, 24 Aug 2006 11:23:25 -0400 Message-Id: <200608241523.k7OFNNB2020547@cichlid.raleigh.ibm.com> To: "Durand, Alain" In-reply-to: <8587F175CDB3D741B58C79F67E8E09AD9028D5@PACDCEXCMB03.cable.comcast.com> References: <8587F175CDB3D741B58C79F67E8E09AD9028D5@PACDCEXCMB03.cable.comcast.com> Comments: In-reply-to "Durand, Alain" message dated "Tue, 22 Aug 2006 23:31:10 -0400." Date: Thu, 24 Aug 2006 11:23:23 -0400 From: Thomas Narten X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF IPv6 Mailing List Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Boy, an awful lot of messages on this already, and what appears to be a lot of repeating the same arguments, and not actually responding to the concerns being raised (i.e., not listening). :-( I guess I'll add my $0.02 as well. > > Thanks for the quick e-mail. As one of the co-authors, I'd in > > turn like to reply (and state that ICMPv6 PD is ANOTHER way > > to do IPv6 PD, NOT a replacement for the existing mechanism). > > FWIW, please see comments in-line: > This is probably the crux of the issue. I believe that having > multiple IETF standardized ways to achieve the same thing is a bad idea. I agree completely with this. Having multiple ways of doing the same thing ing mechanisms do not address it properly, and 3) the best way to address the problem is with a new mechanism (and it's better than other proposed ways of fixing the problem). At this point, AFAIAC, you have not gotten past either points 1) or 2). Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH69-0007O6-B7; Thu, 24 Aug 2006 11:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH68-0007Nq-4P for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGH68-0000z2-2d for ipv6@ietf.org; Thu, 24 Aug 2006 11:26:24 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGH3K-0006mj-9s for ipv6@ietf.org; Thu, 24 Aug 2006 11:23:31 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7OFNOo3008729 for ; Thu, 24 Aug 2006 11:23:24 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7OFNOAs251320 for ; Thu, 24 Aug 2006 11:23:24 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7OFNNxc010222 for ; Thu, 24 Aug 2006 11:23:24 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-155-121.mts.ibm.com [9.76.155.121]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7OFNNWh010116; Thu, 24 Aug 2006 11:23:23 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k7OFNNB2020547; Thu, 24 Aug 2006 11:23:25 -0400 Message-Id: <200608241523.k7OFNNB2020547@cichlid.raleigh.ibm.com> To: "Durand, Alain" In-reply-to: <8587F175CDB3D741B58C79F67E8E09AD9028D5@PACDCEXCMB03.cable.comcast.com> References: <8587F175CDB3D741B58C79F67E8E09AD9028D5@PACDCEXCMB03.cable.comcast.com> Comments: In-reply-to "Durand, Alain" message dated "Tue, 22 Aug 2006 23:31:10 -0400." Date: Thu, 24 Aug 2006 11:23:23 -0400 From: Thomas Narten X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: IETF IPv6 Mailing List Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Boy, an awful lot of messages on this already, and what appears to be a lot of repeating the same arguments, and not actually responding to the concerns being raised (i.e., not listening). :-( I guess I'll add my $0.02 as well. > > Thanks for the quick e-mail. As one of the co-authors, I'd in > > turn like to reply (and state that ICMPv6 PD is ANOTHER way > > to do IPv6 PD, NOT a replacement for the existing mechanism). > > FWIW, please see comments in-line: > This is probably the crux of the issue. I believe that having > multiple IETF standardized ways to achieve the same thing is a bad idea. I agree completely with this. Having multiple ways of doing the same thing inevitably increases complexity. It's usually a short-term optimization that benefits one narrow constituency (in this case, it would appear to be a group that doesn't like DHC for some vague reason). But the cost of one groups simplifcation is additional complexity for everyone else. Is there an expectation that clients will only implement one of the choices? Well, if so, the original problem isn't solved, since the operator can't rely on the PD method being used exclusively. And if a client implements both (since it's not sure which standard its peers use), which one gets used? What if both are available? and provide conflicting answers? etc., etc. writes: > The point that there is ALREADY at least one such case (node > addressing) for which there is more than one standardized IETF way > is irrefutable. But it turns out there are different cases for these two. They do not provide exactly the same service. DHC is critical for networks where the routers/operators want to know which addresses are in use (e.g., they base access control on them, and/or do other types of filtering). Or only blackhole traffic for addresses that are known to be in use, in order to save bandwidth, etc. This is not really possibly to do with stateless address autoconfiguration, since a node picks its own address and isn't required to tell anyone. So, please explain, what technical justification PD has over DHC? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- evitably increases complexity. It's usually a short-term optimization that benefits one narrow constituency (in this case, it would appear to be a group that doesn't like DHC for some vague reason). But the cost of one groups simplifcation is additional complexity for everyone else. Is there an expectation that clients will only implement one of the choices? Well, if so, the original problem isn't solved, since the operator can't rely on the PD method being used exclusively. And if a client implements both (since it's not sure which standard its peers use), which one gets used? What if both are available? and provide conflicting answers? etc., etc. writes: > The point that there is ALREADY at least one such case (node > addressing) for which there is more than one standardized IETF way > is irrefutable. But it turns out there are different cases for these two. They do not provide exactly the same service. DHC is critical for networks where the routers/operators want to know which addresses are in use (e.g., they base access control on them, and/or do other types of filtering). Or only blackhole traffic for addresses that are known to be in use, in order to save bandwidth, etc. This is not really possibly to do with stateless address autoconfiguration, since a node picks its own address and isn't required to tell anyone. So, please explain, what technical justification PD has over DHC? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:30:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH95-0001vn-V2; Thu, 24 Aug 2006 11:29:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGH94-0001vd-EI for ipv6@ietf.org; Thu, 24 Aug 2006 11:29:26 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGH8x-0001Ca-Pe for ipv6@ietf.org; Thu, 24 Aug 2006 11:29:26 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7OFTHsP008491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Aug 2006 08:29:17 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7OFTGqq023508 for ; Thu, 24 Aug 2006 08:29:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7OFT9Xo022877; Thu, 24 Aug 2006 08:29:14 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 08:29:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Aug 2006 08:29:14 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774245@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <92D17ACC46FB33448977916D9EC398F0D30794@ct11exm63.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Prefix Delegation using ICMPv6 Thread-Index: AcbHDo5kV3TXXwNJSxWYS4LAHJgV7gAAbJBwAB8LOVAAAO4aoA== From: "Templin, Fred L" To: "Rao Satyanarayana-W60007" , X-OriginalArrivalTime: 24 Aug 2006 15:29:15.0064 (UTC) FILETIME=[0E981B80:01C6C792] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: IETF IPv6 Mailing List Subject: RE: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > Well, the intention is to use RS/RA for PD but use icmp type/code for > any error messaging for the PD process between the requesters and > delegators. OK, I see now. When Tim first contacted me he came across with a certain sense of naivety that doesn't seem to be supported by his interactions here, and he led me to believe that he was talking about new ICMP messages for prefix delegation. Then later, when I suggested to Tim that RS/RA could be used for the PD, he told me that yes in fact that was what he would be proposing and he ended the discussion with what I could only describe as a certain sense of self-righteousness. Now we come to find out that its *both* RS/RA *and* two new ICMP messages. That's a lot of messages, and it might lead one to ask that if there needs to be two new ICMP messages why not use them for the prefix delegation too and avoid overloading RS/RA and tweaking specs? (But then I guess the proposal wouldn't be any much different than those that were offered several years ago?) Fred fred.l.templin@boeing.com Matthew 7:5 =20 Thanks, - Satya Rao Mobile Devices Technology Office Motorola Tel: 512-996-6781 Email: sbrao@motorola.com =20 > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20 > Sent: Wednesday, August 23, 2006 7:12 PM > To: timbeck04@verizon.net > Cc: IETF IPv6 Mailing List > Subject: RE: Re: Prefix Delegation using ICMPv6 >=20 > Tim, >=20 > I took a look at the I-D and it reads well. I see that you=20 > (and the co-authors) are asking RSs to carry PIOs by way of=20 > requesting specific prefixes, and that you are asking for new=20 > flag bits (the 'P' bit in the RS message 'Reserved' field and=20 > the 'D' bit in the PIO 'Reserved1' field) which would qualify=20 > this as an RS/RA-based prefix delegation mechanism. >=20 > But then, I see in Sections 5.1 and 5.2 that the=20 > specification is also asking for new ICMPv6 message types, so=20 > the mechanism is apparently not implemented via RS/RA=20 > messages alone. Is there a way to do this with RS/RA alone,=20 > or do you also need the extra ICMPv6 messages? >=20 > Fred > fred.l.templin@boeing.com=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:48:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHQ2-0002fR-QY; Thu, 24 Aug 2006 11:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHQ0-0002fL-UL for ipv6@ietf.org; Thu, 24 Aug 2006 11:46:56 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHPx-0004bD-MH for ipv6@ietf.org; Thu, 24 Aug 2006 11:46:56 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7OFkcfC028937; Thu, 24 Aug 2006 08:46:43 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k7OFkZCR021190; Thu, 24 Aug 2006 10:46:36 -0500 (CDT) Message-ID: <44EDC9DB.6000701@motorola.com> Date: Thu, 24 Aug 2006 17:46:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rao Satyanarayana-W60007 References: <92D17ACC46FB33448977916D9EC398F0D30788@ct11exm63.ds.mot.com> In-Reply-To: <92D17ACC46FB33448977916D9EC398F0D30788@ct11exm63.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "Durand, Alain" , IETF IPv6 Mailing List , Ralph Droms Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Rao Satyanarayana-W60007 wrote: > I do not know what you mean by debug? Did anybody not say if a > proposal you may have submitted may or not work in some or certain > cases?. Did they not comment on the plus and minus points of the > proposal? That's what I mean by bugs in the proposal. I understand. I thought you were looking for protocol bugs comparing to how would it fit into ICMPv6 types, etc. This may come later, it's too early now. Sorry for misunderstanding. Developing a protocol takes some time and this is the first time this particular draft is posted. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:48:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHRK-0002tH-FS; Thu, 24 Aug 2006 11:48:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHRI-0002t6-T4; Thu, 24 Aug 2006 11:48:16 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHRH-0004s6-LN; Thu, 24 Aug 2006 11:48:16 -0400 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.13.6/8.13.6/SMTPOUT) with ESMTP id k7OFmAMW012171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Aug 2006 10:48:15 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7OFm9nb015718; Thu, 24 Aug 2006 10:48:09 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7OFllpk014818; Thu, 24 Aug 2006 10:47:55 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 08:47:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Aug 2006 08:47:53 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774246@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774241@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multilink Subnet Considerations for NETLMM Addressing Thread-Index: Aca9UCIThchETt9dTDKonQ2ye7qADwJuFSyAACL7eGA= From: "Templin, Fred L" To: "INT Area" , , "IETF IPv6 Mailing List" X-OriginalArrivalTime: 24 Aug 2006 15:47:54.0640 (UTC) FILETIME=[A9E9D900:01C6C794] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: Multilink Subnet Considerations for NETLMM Addressing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org (cross-posting, since there seems to be interest in NETLMM on the IPv6 list) Having been away from e-mail for the past several days, the text below is offered to cover the NETLMM Addressing concerns. This would naturally go as replacement text for Section 5 of 'draft-ietf-netlmm-mn-ar-if-01.txt', but may be appropriate for other documents as well. Comments? Fred fred.l.templin@boeing.com "5. Multilink Subnet Considerations An individual prefix is an IP prefix associated with a specific MN, and a shared prefix is an IP prefix that may be associated with multiple MNs. ARs must not include an individual prefix in RAs that may be received by a MN other than the one associated with the prefix. ARs must not send RAs that include a shared prefix in a Prefix Information Option with 'A'=3D1 unless there is operational assurance of duplicate address detection/avoidance across the NETLMM domain. ARs must not send RAs that include an individual or shared prefix in a Prefix Information Option with 'L'=3D1 unless all RAs that include the prefix and all MNs that receive them are associated with a single link." -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHUS-0004Yr-UO; Thu, 24 Aug 2006 11:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHUR-0004XL-6z for ipv6@ietf.org; Thu, 24 Aug 2006 11:51:31 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHUP-0005AR-VZ for ipv6@ietf.org; Thu, 24 Aug 2006 11:51:31 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7OFpTVJ000006; Thu, 24 Aug 2006 08:51:29 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k7OFpRKA024190; Thu, 24 Aug 2006 10:51:27 -0500 (CDT) Message-ID: <44EDCAFE.5010404@motorola.com> Date: Thu, 24 Aug 2006 17:51:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Bernie Volz (volz)" References: <8E296595B6471A4689555D5D725EBB2102113D1D@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB2102113D1D@xmb-rtp-20a.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF IPv6 Mailing List , "Ralph Droms $rdroms$" Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Bernie Volz (volz) wrote: >> If we're to compare, I'd compare the ICMPv6-PD effort with the RA > option >> to carry DNS Server effort. If things are to evolve quicker then >> we could skip some intermediary steps. > > Exactly. Why have two ways to the same thing! That's another effort > that should be terminated. > > Gee, why don't we just encapsulate DHCPv6 options in RA/RS? Then, > we'd solve all of these problems and be able to get rid of "DHCPv6". Right, encapsulating DHCPv6 options in RA/RS would transform RA/RS into DHCPv6 itself. RS/RA is the first thing people see when they come to IPv6. It's so magic that it seems to be able to solve many problems. It's a common temptation to add stuff into RA. That said. We could try to document what are the current options to convey a prefix to a terminal such that it can reuse that prefix for itself and for others. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 24 11:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHYq-0006Nu-Q8; Thu, 24 Aug 2006 11:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHYo-0006MA-PR for ipv6@ietf.org; Thu, 24 Aug 2006 11:56:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHYn-0005XP-CP for ipv6@ietf.org; Thu, 24 Aug 2006 11:56:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2006 11:56:01 -0400 X-IronPort-AV: i="4.08,165,1154923200"; d="scan'208,217"; a="98462038:sNHT59305884" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OFu0L6031686; Thu, 24 Aug 2006 11:56:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7OFu0uI029207; Thu, 24 Aug 2006 11:56:00 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 11:56:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Aug 2006 11:54:35 -0400 Message-ID: <6F66F4F04858B945B836804F0F2AE6BB01F579DC@xmb-rtp-211.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix Delegation using ICMPv6 Thread-Index: AcbHlTJA0DN5bAn3Qo+zaXHZIyf8kwAAGaGq References: <8E296595B6471A4689555D5D725EBB2102113D1D@xmb-rtp-20a.amer.cisco.com> <44EDCAFE.5010404@motorola.com> From: "Ralph Droms $rdroms$" To: "Alexandru Petrescu" , "Bernie Volz $volz$" X-OriginalArrivalTime: 24 Aug 2006 15:56:00.0643 (UTC) FILETIME=[CB980530:01C6C795] DKIM-Signature: a=rsa-sha1; q=dns; l=4354; t=1156434960; x=1157298960; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=22Ralph=20Droms=20$rdroms$=22=20 |Subject:RE=3A=20Prefix=20Delegation=20using=20ICMPv6 |To:=22Alexandru=20Petrescu=22=20, =0A=20=20 =20=20=20=20=20=20=22Bernie=20Volz=20$volz$=22=20; X=v=3Dcisco.com=3B=20h=3DWemDtUN+SQHa3nwAtK88GX3azTw=3D; b=efy9J/skhwkXXhUbgy1tIOAlwgy5U5/qZQVhK20FuSbyCm+gwQD8gfGohbwxUZ+YykqHZnXd 8NiGkb0TXccFyOxNJu6v2AxJOvCTB0i8sWaMdd7rrVd4b8SYiMLalTci; Authentication-Results: rtp-dkim-2.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( 61 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: IETF IPv6 Mailing List Subject: RE: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0326493133==" Errors-To: ipv6-bounces@ietf.org This is a multi-part message in MIME format. --===============0326493133== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6C795.CB483799" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6C795.CB483799 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alexandru - you've used a phrase that I still don't understand. What does it mean for a node to have a prefix that "it can reuse [...] for = itself and for others"? - Ralph -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] Sent: Thu 8/24/2006 11:51 AM To: Bernie Volz (volz) Cc: IETF IPv6 Mailing List; Ralph Droms (rdroms) Subject: Re: Prefix Delegation using ICMPv6 =20 Bernie Volz (volz) wrote: >> If we're to compare, I'd compare the ICMPv6-PD effort with the RA > option >> to carry DNS Server effort. If things are to evolve quicker then >> we could skip some intermediary steps. >=20 > Exactly. Why have two ways to the same thing! That's another effort > that should be terminated. >=20 > Gee, why don't we just encapsulate DHCPv6 options in RA/RS? Then, > we'd solve all of these problems and be able to get rid of "DHCPv6". Right, encapsulating DHCPv6 options in RA/RS would transform RA/RS into=20 DHCPv6 itself. RS/RA is the first thing people see when they come to=20 IPv6. It's so magic that it seems to be able to solve many problems.=20 It's a common temptation to add stuff into RA. That said. We could try to document what are the current options to convey a prefix = to a terminal such that it can reuse that prefix for itself and for = others. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------_=_NextPart_001_01C6C795.CB483799 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Prefix Delegation using ICMPv6

Alexandru - you've used a phrase that I still don't = understand. What
does it mean for a node to have a prefix that "it can reuse [...] = for itself
and for others"?

- Ralph

-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu= @motorola.com]
Sent: Thu 8/24/2006 11:51 AM
To: Bernie Volz (volz)
Cc: IETF IPv6 Mailing List; Ralph Droms (rdroms)
Subject: Re: Prefix Delegation using ICMPv6

Bernie Volz (volz) wrote:
>> If we're to compare, I'd compare the ICMPv6-PD effort with the = RA
> option
>> to carry DNS Server effort. If things are to evolve = quicker then
>> we could skip some intermediary steps.
>
> Exactly. Why have two ways to the same thing! That's another = effort
> that should be terminated.
>
> Gee, why don't we just encapsulate DHCPv6 options in RA/RS? = Then,
> we'd solve all of these problems and be able to get rid of = "DHCPv6".

Right, encapsulating DHCPv6 options in RA/RS would transform RA/RS = into
DHCPv6 itself. RS/RA is the first thing people see when they come = to
IPv6. It's so magic that it seems to be able to solve many = problems.
It's a common temptation to add stuff into RA. That said.

We could try to document what are the current options to convey a = prefix
to a terminal such that it can reuse that prefix for itself and for = others.

Alex

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

------_=_NextPart_001_01C6C795.CB483799-- --===============0326493133== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============0326493133==-- From ipv6-bounces@ietf.org Thu Aug 24 12:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHgq-00027A-0f; Thu, 24 Aug 2006 12:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGHgn-000274-UM for ipv6@ietf.org; Thu, 24 Aug 2006 12:04:17 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGHgm-00070L-N8 for ipv6@ietf.org; Thu, 24 Aug 2006 12:04:17 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id k7OG4FJL016120; Thu, 24 Aug 2006 09:04:15 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k7OG4CCk005157; Thu, 24 Aug 2006 11:04:13 -0500 (CDT) Message-ID: <44EDCDF6.3070606@motorola.com> Date: Thu, 24 Aug 2006 18:04:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Ralph Droms (rdroms)" References: <8E296595B6471A4689555D5D725EBB2102113D1D@xmb-rtp-20a.amer.cisco.com> <44EDCAFE.5010404@motorola.com> <6F66F4F04858B945B836804F0F2AE6BB01F579DC@xmb-rtp-211.amer.cisco.com> In-Reply-To: <6F66F4F04858B945B836804F0F2AE6BB01F579DC@xmb-rtp-211.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF IPv6 Mailing List , "Bernie Volz $volz$" Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Ralph Droms (rdroms) wrote: > Alexandru - you've used a phrase that I still don't understand. What > does it mean for a node to have a prefix that "it can reuse [...] > for itself and for others"? Ralph, thanks for asking. "A node having a prefix it can reuse for itself and for others" means that the node derives shorter prefixes from the one that is delegated and it eventually RAs them into a network for which is responsible. Something like a router at home connected to ADSL needs a whole prefix for the other PCs in house. This is a potential use of prefix delegation. I'm not sure whether the ICMPv6-PD authors think the same about what's PD needed for. They would clarify, I hope. Alex -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From uafywjrp@emotion.com Thu Aug 24 12:34:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIA7-0002Hv-9z for ipngwg-archive@ietf.org; Thu, 24 Aug 2006 12:34:35 -0400 Received: from [221.204.108.171] (helo=[221.204.108.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGIA5-0005HV-Oo for ipngwg-archive@ietf.org; Thu, 24 Aug 2006 12:34:35 -0400 Date: Fri, 25 Aug 2006 00:34:22 -0800 From: "forces issued" To: ipngwg-archive@ietf.org Subject: Carriere Jesse Ingram JILost X-mailer: Foxmail 6, 4, 104, 20 [en] MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 W_A_T_C_H O_U_T! HERE COMES THE BIG ONE! THURSDAY AUG 24th IS SURE TO BE A BIG DAY! Company Name: W_ILD B_RUSH E_NERGY (Other O T C: W B R S . P K ) S ym bol: W B R S 1-day T_arget: 0.10 Current P_rice: 0.05 W_ILD B_RUSH M AKES A MOVE! Wild Brush Acquires Additional Powder River Oil & Gas Lease. Read More Online NOW! Who is Wild Brush? Wild Brush Energy is a diversified energy company whose primary goal is to identify and develop Oil & Coalbed Methane sites within the State of Wyoming. In addition, Wild Brush Energy continues to evaluate clean air alternative energy producing technologies such as Wind Power. Wild Brush trades in the U.S. under the symbol "W B R S ." Currently trading in the .05 range! Now is your chance! ADD THIS GEM TO YOUR WATCH LIST, AND WATCH IT T R A D E CLOSELY ON THURSDAY AUGUST 24th! From ipv6-bounces@ietf.org Thu Aug 24 12:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGI9M-0000Zr-6M; Thu, 24 Aug 2006 12:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGI9K-0000XM-2E for ipv6@ietf.org; Thu, 24 Aug 2006 12:33:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGI9J-0005A2-WF for ipv6@ietf.org; Thu, 24 Aug 2006 12:33:46 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGI9I-0000Fv-3S for ipv6@ietf.org; Thu, 24 Aug 2006 12:33:45 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7OGXfc0008806 for ; Thu, 24 Aug 2006 09:33:43 -0700 (MST) Received: from ct11exm63.ds.mot.com (ct11exm63.am.mot.com [10.177.8.47]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k7OGXeg0026034 for ; Thu, 24 Aug 2006 11:33:40 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Aug 2006 12:33:39 -0400 Message-ID: <92D17ACC46FB33448977916D9EC398F0D30825@ct11exm63.ds.mot.com> In-reply-to: <44EDCDF6.3070606@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Prefix Delegation using ICMPv6 thread-index: AcbHlwg22jLIKob5Scq75R9MGxysIwAAz9Ew From: "Rao Satyanarayana-W60007" To: "Petrescu Alexandru-AAP021"

More than 200=20 software titles from world leading=20 manufacturers

MS Windows XP Professional with SP2 - = $49.95

Adobe Photoshop CS2 V 9.0 - $69.95

Microsoft Office XP Professional - = $49.95

Adobe Acrobat 5.0 - $39.95

Visit our=20 Website

------=_NextPart_000_0001_01C6C828.827B3F00-- From ipv6-bounces@ietf.org Fri Aug 25 06:08:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYXc-00019Q-Lr; Fri, 25 Aug 2006 06:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYXb-00017s-Hr for ipv6@ietf.org; Fri, 25 Aug 2006 06:03:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGVeS-0001ns-Kv for ipv6@ietf.org; Fri, 25 Aug 2006 02:58:48 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGVWS-00034Y-Uq for ipv6@ietf.org; Fri, 25 Aug 2006 02:50:34 -0400 Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:e9ca:1b98:a39f:bffb]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id ECB3315228; Fri, 25 Aug 2006 15:50:29 +0900 (JST) Date: Fri, 25 Aug 2006 15:49:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipv6@ietf.org, "Templin, Fred L" , bob.hinden@nokia.com, Suresh Krishnan Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >>>>> On Thu, 24 Aug 2006 17:08:55 -0400, >>>>> Ralph Droms said: > Jinmei-san - in a private conversation, I made the following > recommendations: (snip) > I recommend the same text as I recommended before for section 2.4: > One way to avoid some of the problems discussed above is to use > DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 > discusses the use of DHCPv6 for the assignment and management of > "temporary addresses" (privacy addresses). Temporary addresses are > managed separately from non-temporary addresses, so a host can > differentiate between the two types of addresses. The lifetimes of > temporary addresses are independent of the lifetimes of any other > addresses, so the frequency of replacement for temporary addresses > can be adjusted as required. If I understand the context correctly, this is the only recommendation regarding this thread, right? So I'm responding to this part first: I don't have an objection to your recommended text. I personally think this is too much for this document and prefer mine, but it's probably a matter of taste. I'm not sure if we want to discuss the other recommendations right now on this thread, but I'm going to provide short responses: > After re-reading draft-ietf-ipv6-privacy-addrs-v2-04.txt, I > think the Abstract is now fine. I would recommend changing the first > sentence of the Introduction to: > Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 > node generates addresses using information about available prefixes > obtained through Router Advertisement messages. I'm fine with removing the reference to DHCPv6, but then I'd like to change "how an IPv6 node generates addresses" to "how an IPv6 node autonomously generates addresses" so that the important characteristic of stateless address autoconfiguration is clear. > I recommend removing section 2.2 (as I did in the earlier post cited > by Suresh), as experience with IPv4 addressing has little bearing on > IPv6. This observation is bolstered by the text in section 2.3 > describing the problem addressed by privacy addresses. For example, > a device gets an entirely new IPv4 address when it moves to a new > connection point, so tracking that device as it moves between connection > points is harder than in IPv6. And, I think there is a fundamental problem > that most IPv4 stacks and applications are built on the assumption of a > single address per interface, so privacy addresses would be hard to use in > any event. If section 2.2 is retained, some of the details should be > corrected; e.g., "Over the last few years, sites have begun moving > away from static allocation to dynamic allocation via DHCP [DHCP]." > sounds dated. I don't have a strong opinion on this, but I personally think the current text is okay as general background information, and it doesn't sound odd to me. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 25 06:14:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYgi-0005x6-Ss; Fri, 25 Aug 2006 06:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYgh-0005x0-Bp for ipv6@ietf.org; Fri, 25 Aug 2006 06:13:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYgg-0005ng-0e for ipv6@ietf.org; Fri, 25 Aug 2006 06:13:19 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2006 06:13:17 -0400 X-IronPort-AV: i="4.08,168,1154923200"; d="scan'208"; a="98657606:sNHT34639880" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PADHA0021548; Fri, 25 Aug 2006 06:13:17 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7PADGuK005081; Fri, 25 Aug 2006 06:13:17 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:13:16 -0400 Received: from 10.86.241.7 ([10.86.241.7]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Aug 2006 10:13:16 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 06:13:17 -0400 From: Ralph Droms To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= Message-ID: Thread-Topic: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) Thread-Index: AcbILxUeU3HgVjQiEduj0wARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 10:13:16.0725 (UTC) FILETIME=[14F4E650:01C6C82F] DKIM-Signature: a=rsa-sha1; q=dns; l=4030; t=1156500797; x=1157364797; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20DHCP=20for=20privacy=20addresses=20(was=3A=20RE=3A=20Is=20there= 20any=20provision=0A=20in=20privacy=20addressing=20...) |To:JINMEI=20Tatuya=20/=20=3D?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?=3D=0A=20; X=v=3Dcisco.com=3B=20h=3DNSIJHXUOYktEtQIvsj91D4JevKA=3D; b=PmwkD6Webt469CIzyjI1Zfu3yjVb4tBcVmzKZOMyd0Uix59mDl8syh1biWTtTIL58nR98EoS 8KaUeht4RFPTXHIc/KJJOEvvqh5eRtjV2ayh29uClHUZIh+dgIw1f4Ev; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ipv6@ietf.org, "Templin, Fred L" , bob.hinden@nokia.com, Suresh Krishnan Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I'm sorry for introducing other recommendations into your thread. I forwarded comments from a private exchange about the draft. I'll separate the other recommendations out into a different thread. I don't have a strong opinion about your text, either and perhaps brevity is a virtue. How about: One way to avoid having a static non-changing address is to use DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 discusses the use of DHCPv6 for the assignment and management of "temporary addresses", which are never renewed and provide the same property of temporary addresses described in this document with regards to the privacy concern. - Ralph On 8/25/06 2:49 AM, "JINMEI Tatuya / $B?@L@C#:H(B" wrote: >>>>>> On Thu, 24 Aug 2006 17:08:55 -0400, >>>>>> Ralph Droms said: > >> Jinmei-san - in a private conversation, I made the following >> recommendations: > > (snip) > >> I recommend the same text as I recommended before for section 2.4: > >> One way to avoid some of the problems discussed above is to use >> DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 >> discusses the use of DHCPv6 for the assignment and management of >> "temporary addresses" (privacy addresses). Temporary addresses are >> managed separately from non-temporary addresses, so a host can >> differentiate between the two types of addresses. The lifetimes of >> temporary addresses are independent of the lifetimes of any other >> addresses, so the frequency of replacement for temporary addresses >> can be adjusted as required. > > If I understand the context correctly, this is the only recommendation > regarding this thread, right? So I'm responding to this part first: > > I don't have an objection to your recommended text. I personally > think this is too much for this document and prefer mine, but it's > probably a matter of taste. > > I'm not sure if we want to discuss the other recommendations right now > on this thread, but I'm going to provide short responses: > >> After re-reading draft-ietf-ipv6-privacy-addrs-v2-04.txt, I >> think the Abstract is now fine. I would recommend changing the first >> sentence of the Introduction to: > >> Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 >> node generates addresses using information about available prefixes >> obtained through Router Advertisement messages. > > I'm fine with removing the reference to DHCPv6, but then I'd like to > change "how an IPv6 node generates addresses" to "how an IPv6 node > autonomously generates addresses" so that the important characteristic > of stateless address autoconfiguration is clear. > >> I recommend removing section 2.2 (as I did in the earlier post cited >> by Suresh), as experience with IPv4 addressing has little bearing on >> IPv6. This observation is bolstered by the text in section 2.3 >> describing the problem addressed by privacy addresses. For example, >> a device gets an entirely new IPv4 address when it moves to a new >> connection point, so tracking that device as it moves between connection >> points is harder than in IPv6. And, I think there is a fundamental problem >> that most IPv4 stacks and applications are built on the assumption of a >> single address per interface, so privacy addresses would be hard to use in >> any event. If section 2.2 is retained, some of the details should be >> corrected; e.g., "Over the last few years, sites have begun moving >> away from static allocation to dynamic allocation via DHCP [DHCP]." >> sounds dated. > > I don't have a strong opinion on this, but I personally think the > current text is okay as general background information, and it doesn't > sound odd to me. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 25 06:19:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYlP-0000hz-MQ; Fri, 25 Aug 2006 06:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGYlN-0000hu-QU for ipv6@ietf.org; Fri, 25 Aug 2006 06:18:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGYlM-0006pg-Fr for ipv6@ietf.org; Fri, 25 Aug 2006 06:18:09 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 25 Aug 2006 03:18:09 -0700 X-IronPort-AV: i="4.08,168,1154934000"; d="scan'208"; a="313943963:sNHT33570956" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PAI71N010426; Fri, 25 Aug 2006 03:18:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7PAI76W024655; Fri, 25 Aug 2006 03:18:07 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:18:07 -0400 Received: from 10.86.241.7 ([10.86.241.7]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Aug 2006 10:18:06 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 06:18:06 -0400 From: Ralph Droms To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= Message-ID: Thread-Topic: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) Thread-Index: AcbIL8Fg/9a5tDQiEduj0wARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 10:18:07.0108 (UTC) FILETIME=[C209D440:01C6C82F] DKIM-Signature: a=rsa-sha1; q=dns; l=2461; t=1156501087; x=1157365087; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20DHCP=20for=20privacy=20addresses=20(was=3A=20RE=3A=20Is=20there= 20any=20provision=0A=20in=20privacy=20addressing=20...); X=v=3Dcisco.com=3B=20h=3DNSIJHXUOYktEtQIvsj91D4JevKA=3D; b=LbpUBzF+7ba2HzDmGXlykAMzLrCq42jt3vQftYfcKwnlMXX8k4js7XcH6vFAGkJIVkRxZLrD YLSixTFds5ELqezC++zu5rui/fvDOc0Up1p3tC9jRraC1HWLESVDb1t0; Authentication-Results: sj-dkim-8.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 2.3 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ipv6@ietf.org, "Templin, Fred L" , bob.hinden@nokia.com, Suresh Krishnan Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On 8/25/06 2:49 AM, "JINMEI Tatuya / $B?@L@C#:H(B" wrote: >>>>>> On Thu, 24 Aug 2006 17:08:55 -0400, >>>>>> Ralph Droms said: > [...] > > I'm not sure if we want to discuss the other recommendations right now > on this thread, but I'm going to provide short responses: > >> After re-reading draft-ietf-ipv6-privacy-addrs-v2-04.txt, I >> think the Abstract is now fine. I would recommend changing the first >> sentence of the Introduction to: > >> Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 >> node generates addresses using information about available prefixes >> obtained through Router Advertisement messages. > > I'm fine with removing the reference to DHCPv6, but then I'd like to > change "how an IPv6 node generates addresses" to "how an IPv6 node > autonomously generates addresses" so that the important characteristic > of stateless address autoconfiguration is clear. OK: Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 node autonomously generates addresses using information about available prefixes obtained through Router Advertisement messages. >> I recommend removing section 2.2 (as I did in the earlier post cited >> by Suresh), as experience with IPv4 addressing has little bearing on >> IPv6. This observation is bolstered by the text in section 2.3 >> describing the problem addressed by privacy addresses. For example, >> a device gets an entirely new IPv4 address when it moves to a new >> connection point, so tracking that device as it moves between connection >> points is harder than in IPv6. And, I think there is a fundamental problem >> that most IPv4 stacks and applications are built on the assumption of a >> single address per interface, so privacy addresses would be hard to use in >> any event. If section 2.2 is retained, some of the details should be >> corrected; e.g., "Over the last few years, sites have begun moving >> away from static allocation to dynamic allocation via DHCP [DHCP]." >> sounds dated. > > I don't have a strong opinion on this, but I personally think the > current text is okay as general background information, and it doesn't > sound odd to me. If the text is retained, it needs to be updated and corrected. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 25 09:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbf4-000182-QJ; Fri, 25 Aug 2006 09:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGbf3-00017x-U1 for ipv6@ietf.org; Fri, 25 Aug 2006 09:23:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGbf3-0003w4-SK for ipv6@ietf.org; Fri, 25 Aug 2006 09:23:49 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGbb7-00043t-RU for ipv6@ietf.org; Fri, 25 Aug 2006 09:19:50 -0400 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.13.6/8.13.6/SMTPOUT) with ESMTP id k7PDJcAj014987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 25 Aug 2006 08:19:43 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7PDJcsL003558 for ; Fri, 25 Aug 2006 08:19:38 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7PDJX4R003435; Fri, 25 Aug 2006 08:19:37 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:19:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 06:19:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774254@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <19599242.52571156467941881.JavaMail.root@vms169.mailsrvcs.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Re: Prefix Delegation using ICMPv6 Thread-Index: AcbH4p8U8XTNGYM7RvqWCfsBD5YgnQAZPbsA From: "Templin, Fred L" To: , "Rao Satyanarayana-W60007" X-OriginalArrivalTime: 25 Aug 2006 13:19:29.0086 (UTC) FILETIME=[1833E5E0:01C6C849] X-Spam-Score: -2.5 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: IETF IPv6 Mailing List Subject: RE: RE: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Tim, Yes, I can certainly keep personal things off-list. One thing I will correct though is that it was indeed you who contacted me first. Fred fred.l.templin@boeing.com -----Original Message----- From: timbeck04@verizon.net [mailto:timbeck04@verizon.net]=20 Sent: Thursday, August 24, 2006 6:06 PM To: Templin, Fred L; Rao Satyanarayana-W60007; timbeck04@verizon.net Cc: IETF IPv6 Mailing List Subject: Re: RE: Re: Prefix Delegation using ICMPv6 Fred, >OK, I see now. When Tim first contacted me he came >across with a certain sense of naivety If you wish to remain focused on the issue at hand (namely, the merit of the proposal we have placed before the group), please do so. As for such impressions about me, please keep them off this list. >that doesn't seem to be supported by his interactions >here and he led me to believe Try to take some responsibility for what you believe, Fred. Also, your analysis of a private thread which you in fact began is not fodder for this list. >that he was talking about new ICMP messages for >prefix delegation. Then later, when I suggested to >Tim that RS/RA could be used for the PD, he told me >that yes in fact that was what he would be proposing >and he ended the discussion with what I could only >describe as a certain sense of self-righteousness. Again Fred, you need to stop using pejorative terms (e.g. "naivety", "self-righteousness") in reference to me. Please keep your opinions of me to yourself. If you continue to be compelled to cast aspersions, kindly do so in a not-so-public forum.=20 If however you wish to engage in a technical or procedural debate about our ICMPv6 PD proposal, this list is the forum for that. > >Fred >fred.l.templin@boeing.com >Matthew 7:5 Tim Rom 8:28 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 25 12:39:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGeeS-0005CV-GV; Fri, 25 Aug 2006 12:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGeeQ-000540-Fz for ipv6@ietf.org; Fri, 25 Aug 2006 12:35:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGcRx-00025m-RA for ipv6@ietf.org; Fri, 25 Aug 2006 10:14:21 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGbhW-0004Oj-NP for ipv6@ietf.org; Fri, 25 Aug 2006 09:26:25 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7PDPqfG011519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 25 Aug 2006 06:25:57 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7PDQGJi016885 for ; Fri, 25 Aug 2006 06:26:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7PDQGPM016867; Fri, 25 Aug 2006 06:26:16 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 06:26:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 06:26:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774255@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <19599242.52571156467941881.JavaMail.root@vms169.mailsrvcs.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Re: Prefix Delegation using ICMPv6 Thread-Index: AcbH4p8U8XTNGYM7RvqWCfsBD5YgnQAZoE8A From: "Templin, Fred L" To: , "Rao Satyanarayana-W60007" X-OriginalArrivalTime: 25 Aug 2006 13:26:16.0455 (UTC) FILETIME=[0B037970:01C6C84A] X-Spam-Score: -2.5 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF IPv6 Mailing List Subject: RE: RE: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Correcting somewhat what I said earlier, the proposal calls for not only RS/RA modifications but also three new ICMPv6 error messages/codes, and one new notification message which carrys prefixes using the PIO format. But, as I said earlier, it is not just about RS/RA in its current manifestation. Fred fred.l.templin@boeing.com =20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 25 19:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGl3P-0003My-9b; Fri, 25 Aug 2006 19:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGl3N-0003Mo-Lh for ipv6@ietf.org; Fri, 25 Aug 2006 19:25:33 -0400 Received: from bdsl.66.15.163.216.gte.net ([66.15.163.216] helo=tndh.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGl3M-00087b-7b for ipv6@ietf.org; Fri, 25 Aug 2006 19:25:33 -0400 Received: from eaglet (127.0.0.1:3031) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 25 Aug 2006 16:25:21 -0700 From: "Tony Hain" To: , "'Rao Satyanarayana-W60007'" , "'Ralph Droms'" Date: Fri, 25 Aug 2006 16:25:26 -0700 Message-ID: <1d9001c6c89d$bf3f86b0$2b7ba8c0@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <27559335.469561156445201202.JavaMail.root@vms070.mailsrvcs.net> Thread-Index: AcbHrcCHXPRxtG7GTLm/5N1O/a/GxwA67w6g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "'Durand, Alain'" , 'IETF IPv6 Mailing List' Subject: RE: RE: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org timbeck04@verizon.net wrote: > Hi Tony, please see my in-line comments: > > >> I think the questions should be is there merit in the > >> proposal? > > > >That is true, but your section 3 does not establish that merit. > > Hi Tony, just a reminder from an earlier e-mail that we will be seeking to > provide additional detail in section 3 in the future versions of our > draft.** > ----snip----- To be blunt: There is a team of people willing to work on this draft. + 1 point The team appears to be passionate about defending the work. + 1 point There appears to be well described content in the draft. + 1 point Description of the need for this appears to be lacking. - 5 points The mail thread is defending the right to develop something different, not expanding on the need for something new. - 5 points Between the lines; appears to be religious bias against DHCP. - 10 points Unless we understand the problem we can't evaluate the solution. Lack of code that implements PD is not a justification, because no code exists for this approach either. Arguing existing RS/RA/ICMP code fails as well because the pieces needed to make this work don't exist in any current implementations. I don't care how many solutions we have as long as they solve unique problems. For your next version of the draft separate out the packet format issues from the state machine issues. Process FOO needs to acquire a prefix for the CPE and will use packet format BAR. There is a state machine driving this that will need to do the same things no matter what FOO ends up being called. If that state machine is significantly simpler than anything that is currently defined then you have a basis for expanding on section 3. Likewise, if the packet format BAR can do something that any other existing packet formats can't. Keep in mind that a new FOO can send an existing BAR. If the issue is centralized vs. distributed management, then say that. If the whole issue boils down to 'it can't be called DHCP', then we can just rename the existing tool to PD and be done with it (ie: drop DHCP from the name). Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 25 19:35:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlC3-0007fK-EI; Fri, 25 Aug 2006 19:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlC1-0007fF-UG for ipv6@ietf.org; Fri, 25 Aug 2006 19:34:29 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlC0-0000rq-Ej for ipv6@ietf.org; Fri, 25 Aug 2006 19:34:29 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7PMYP3o009500; Sat, 26 Aug 2006 01:34:29 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 02:34:10 +0300 Received: from [172.19.74.190] ([172.19.74.190]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 26 Aug 2006 02:34:10 +0300 In-Reply-To: <44EE94AB.9070408@piuha.net> References: <25042386.42741156465410080.JavaMail.root@vms169.mailsrvcs.net> <44EE94AB.9070408@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <571E6438-397F-4F35-9475-E89509724F13@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Date: Fri, 25 Aug 2006 16:34:22 -0700 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Aug 2006 23:34:10.0191 (UTC) FILETIME=[F70DE9F0:01C6C89E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bob.hinden@nokia.com List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Aug 24, 2006, at 11:11 PM, ext Jari Arkko wrote: > Tim, > > Its probably best if you now update your draft with a better > description > of what scenario you are looking at, details about the customers > requirements, justification of why new work is needed, and an analysis > of why existing solutions are inappropriate or undesirable in your > scenario. This has already been a long discussion but in my opinion > it has not been all that informative yet with regards to these issues. Similar thoughts on my part. Further, I would like get a better understanding as to why RA was chosen for this. From my viewpoint the RA/RS is a very nice mechanism for a router to tell all the hosts on a link common information (e.g., prefixes, link MTU, lifetimes, etc.). ND does have the ability to run in a unicast mode where different answers could be provided depending on the address of the node sending the solicitation, but this not something we have thought very much about nor specified. I think it could be made to work, but it would need a lot more thought and discussion. Also, RAs were, of course, designed to allow routers to send information to hosts. The proposal here is, if I understand it correctly, is to use RAs to provision other routers. Not the original intent. It would be great if these issues could be discussed in a revised draft. Thanks, Bob > Also, at least I personally want to know what problem we are > solving before spending a lot of effort in analysing a solution -- > we know there is an infinite number of ways to design a protocol > but the real question is whether it solves a problem. > > Looking forward to your new draft. > > --Jari > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Fri Aug 25 19:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlCh-0007oW-DI; Fri, 25 Aug 2006 19:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGlCg-0007oP-DD for ipv6@ietf.org; Fri, 25 Aug 2006 19:35:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGlCf-0000wb-1I for ipv6@ietf.org; Fri, 25 Aug 2006 19:35:10 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 25 Aug 2006 16:35:08 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7PNZ8N7005020; Fri, 25 Aug 2006 16:35:08 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7PNZ7w9021455; Fri, 25 Aug 2006 16:35:08 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 19:35:07 -0400 Received: from 10.86.242.87 ([10.86.242.87]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Aug 2006 23:35:07 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Aug 2006 19:35:10 -0400 From: Ralph Droms To: Tony Hain , , "'Rao Satyanarayana-W60007'" Message-ID: Thread-Topic: Prefix Delegation using ICMPv6 Thread-Index: AcbHrcCHXPRxtG7GTLm/5N1O/a/GxwA67w6gAAFnfYg= In-Reply-To: <1d9001c6c89d$bf3f86b0$2b7ba8c0@tndh.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Aug 2006 23:35:07.0801 (UTC) FILETIME=[19648090:01C6C89F] DKIM-Signature: a=rsa-sha1; q=dns; l=889; t=1156548908; x=1157412908; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20Prefix=20Delegation=20using=20ICMPv6; X=v=3Dcisco.com=3B=20h=3DtoC3Mg0E1MGC2sdbXVygrxtLecE=3D; b=A1UvH8OYw5+VnRawQjuAqqMLI8liY0oLk6bvTrrcD92xov+dYs71RJ7afd+cSufkq55DxzWG B6ZuCU+ScwRQuFknRFlWABxudWcuMniv8myzDY5/dqELud6xkLY7C7p2; Authentication-Results: sj-dkim-7.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'Durand, Alain'" , 'IETF IPv6 Mailing List' Subject: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Just to be clear (and I know you're aware of this, Tony), "lack of code" is a provably invalid argument in support of developing an alternative to DHCPv6 PD. It is simply not true to say that DHCPv6 PD is not implemented and has not been deployed. There are multiple server implementations available today, that run directly in network elements or as a standalone server, and client implementations available today. These implementations are sufficiently robust that they are in use today in commercial deployments. - Ralph On 8/25/06 7:25 PM, "Tony Hain" wrote: > [...] Lack of > code that implements PD is not a justification, because no code exists for > this approach either. Arguing existing RS/RA/ICMP code fails as well because > the pieces needed to make this work don't exist in any current > implementations. > > [...] > > Tony -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Sat Aug 26 14:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH2P2-0004eT-Tr; Sat, 26 Aug 2006 13:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH2P0-0004eO-Ng for ipv6@ietf.org; Sat, 26 Aug 2006 13:57:02 -0400 Received: from [203.199.83.246] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GH2Ou-0002hd-7G for ipv6@ietf.org; Sat, 26 Aug 2006 13:57:02 -0400 Received: (qmail 4927 invoked by uid 510); 26 Aug 2006 17:54:14 -0000 Date: 26 Aug 2006 17:54:14 -0000 Message-ID: <20060826175414.4926.qmail@webmail35.rediffmail.com> Received: from unknown (203.101.46.96) by rediffmail.com via HTTP; 26 aug 2006 17:54:14 -0000 MIME-Version: 1.0 From: "ganesan srimanikandan" To: ipv6@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: Is DAD a MUST in tunnel interfaces. X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ganesan srimanikandan List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1176264738==" Errors-To: ipv6-bounces@ietf.org This is a multipart mime message --===============1176264738== Content-type: multipart/alternative; boundary="Next_1156614854---0-203.199.83.246-4924" This is a multipart mime message --Next_1156614854---0-203.199.83.246-4924 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,=0A=0AGreetings.=0A=0AWould like to know whether the DAD needs to be per= formed on the tunnel interfaces (typically on an 6in4 tunnels)=0A=0AI belie= ve, only sub set of Neighor Discovery operations are performed for the tunn= el. But nowhere it is clearly mentioned whether Duplicate Address Detection= is essential ??=0A=0ARegards,=0AMani.=0A --Next_1156614854---0-203.199.83.246-4924 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi,
=0A
=0AGreetings.
=0A
=0AWould like to know whether t= he DAD needs to be performed on the tunnel interfaces (typically on an 6in4= tunnels)
=0A
=0AI believe, only sub set of Neighor Discovery operati= ons are performed for the tunnel. But nowhere it is clearly mentioned wheth= er Duplicate Address Detection is essential ??
=0A
=0ARegards,
=0A= Mani.
=0A=0A

=0A

=0A

=0A --Next_1156614854---0-203.199.83.246-4924-- --===============1176264738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --===============1176264738==-- From ipv6-bounces@ietf.org Sun Aug 27 02:10:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHDlb-0006nR-8T; Sun, 27 Aug 2006 02:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHDla-0006mP-KS for ipv6@ietf.org; Sun, 27 Aug 2006 02:05:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHC0K-0003uQ-GL for ipv6@ietf.org; Sun, 27 Aug 2006 00:12:12 -0400 Received: from cyteen.hactrn.net ([66.92.66.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHBov-0000jO-9S for ipv6@ietf.org; Sun, 27 Aug 2006 00:00:28 -0400 Received: from cyteen.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 2F60A28E for ; Sun, 27 Aug 2006 00:00:14 -0400 (EDT) To: ipv6@ietf.org From: Rob Austein Date: Sun, 27 Aug 2006 00:00:14 -0400 Message-Id: <20060827040014.2F60A28E@cyteen.hactrn.net> X-Spam-Score: -0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: Weekly posting summary for ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 17 | 22.79% | 127038 | timbeck04@verizon.net 14.12% | 12 | 19.33% | 107793 | rdroms@cisco.com 10.59% | 9 | 10.08% | 56181 | fred.l.templin@boeing.com 10.59% | 9 | 7.65% | 42624 | alexandru.petrescu@motorola.com 5.88% | 5 | 6.06% | 33787 | sbrao@motorola.com 5.88% | 5 | 5.99% | 33420 | smadanapalli@gmail.com 4.71% | 4 | 4.67% | 26048 | kempf@docomolabs-usa.com 3.53% | 3 | 3.33% | 18564 | alh-ietf@tndh.net 3.53% | 3 | 2.58% | 14407 | jari.arkko@piuha.net 2.35% | 2 | 2.27% | 12637 | jinmei@isl.rdc.toshiba.co.jp 2.35% | 2 | 2.21% | 12342 | narten@us.ibm.com 2.35% | 2 | 2.19% | 12189 | volz@cisco.com 2.35% | 2 | 1.99% | 11086 | brc@zurich.ibm.com 2.35% | 2 | 1.93% | 10758 | bob.hinden@nokia.com 2.35% | 2 | 1.43% | 7945 | alain_durand@cable.comcast.com 1.18% | 1 | 1.02% | 5671 | mohacsi@niif.hu 1.18% | 1 | 0.96% | 5366 | suresh.krishnan@ericsson.com 1.18% | 1 | 0.93% | 5182 | mani_fs@rediffmail.com 1.18% | 1 | 0.90% | 4993 | ot@cisco.com 1.18% | 1 | 0.85% | 4758 | sra+ipng@hactrn.net 1.18% | 1 | 0.85% | 4715 | lear@cisco.com --------+------+--------+----------+------------------------ 100.00% | 85 |100.00% | 557504 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 28 12:01:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHjTB-0002oM-Nh; Mon, 28 Aug 2006 11:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHjTA-0002oD-Sk for ipv6@ietf.org; Mon, 28 Aug 2006 11:56:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHjTA-0001Ow-RA for ipv6@ietf.org; Mon, 28 Aug 2006 11:56:12 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHjNc-0007t2-Hb for ipv6@ietf.org; Mon, 28 Aug 2006 11:50:31 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7SFo3Nb012733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Aug 2006 08:50:03 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_SMTPIN) with ESMTP id k7SFoRA9028093 for ; Mon, 28 Aug 2006 08:50:27 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7SFoChv027444; Mon, 28 Aug 2006 08:50:25 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 08:50:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Aug 2006 08:50:19 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177425C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <19599242.52571156467941881.JavaMail.root@vms169.mailsrvcs.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Re: Prefix Delegation using ICMPv6 Thread-Index: AcbH4p8U8XTNGYM7RvqWCfsBD5YgnQC1bONQ From: "Templin, Fred L" To: , "Rao Satyanarayana-W60007" X-OriginalArrivalTime: 28 Aug 2006 15:50:20.0609 (UTC) FILETIME=[AA91F310:01C6CAB9] X-Spam-Score: -2.5 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF IPv6 Mailing List Subject: RE: RE: Re: Prefix Delegation using ICMPv6 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I am offering an unqualified apology to Tim Enos and the list for my inappropriate references to private communications, and I am sorry for any pains or misgivings it may have caused. Fred fred.l.templin@boeing.com =20 -----Original Message----- From: timbeck04@verizon.net [mailto:timbeck04@verizon.net]=20 Sent: Thursday, August 24, 2006 6:06 PM To: Templin, Fred L; Rao Satyanarayana-W60007; timbeck04@verizon.net Cc: IETF IPv6 Mailing List Subject: Re: RE: Re: Prefix Delegation using ICMPv6 Fred, >OK, I see now. When Tim first contacted me he came >across with a certain sense of naivety If you wish to remain focused on the issue at hand (namely, the merit of the proposal we have placed before the group), please do so. As for such impressions about me, please keep them off this list. >that doesn't seem to be supported by his interactions >here and he led me to believe Try to take some responsibility for what you believe, Fred. Also, your analysis of a private thread which you in fact began is not fodder for this list. >that he was talking about new ICMP messages for >prefix delegation. Then later, when I suggested to >Tim that RS/RA could be used for the PD, he told me >that yes in fact that was what he would be proposing >and he ended the discussion with what I could only >describe as a certain sense of self-righteousness. Again Fred, you need to stop using pejorative terms (e.g. "naivety", "self-righteousness") in reference to me. Please keep your opinions of me to yourself. If you continue to be compelled to cast aspersions, kindly do so in a not-so-public forum.=20 If however you wish to engage in a technical or procedural debate about our ICMPv6 PD proposal, this list is the forum for that. > >Fred >fred.l.templin@boeing.com >Matthew 7:5 Tim Rom 8:28 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Mon Aug 28 20:19:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrHF-0002L0-VJ; Mon, 28 Aug 2006 20:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrHE-0002Kq-62 for ipv6@ietf.org; Mon, 28 Aug 2006 20:16:24 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHrHA-00079H-Tk for ipv6@ietf.org; Mon, 28 Aug 2006 20:16:24 -0400 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.13.6/8.13.6/SMTPOUT) with ESMTP id k7T0GIv7003602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Aug 2006 19:16:18 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k7T0GICt000434 for ; Mon, 28 Aug 2006 19:16:18 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7T0GIsb000427 for ; Mon, 28 Aug 2006 19:16:18 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 17:16:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Aug 2006 17:16:17 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774262@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20060827040014.2F60A28E@cyteen.hactrn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on 'draft-ietf-ipv6-rfc2462bis-08.txt' Thread-Index: AcbJn3v5aA//Jr08Rai5iGV7r76xoQBWc2cA From: "Templin, Fred L" To: X-OriginalArrivalTime: 29 Aug 2006 00:16:18.0221 (UTC) FILETIME=[591DEDD0:01C6CB00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: Comments on 'draft-ietf-ipv6-rfc2462bis-08.txt' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I have two meta-comments and two specific comments on this document: 1) (meta-comment) The specification speaks of only two classes of unicast addresses (link-local and global) but we now have a third class (ULAs - RFC4193) and others may be definied in the future (e.g., PI). The term "global (address)" should therefore be somehow relaxed throughout the document to allow for stateless autoconfiguration of non-link-local unicast addresses other than just normal global addresses. 2) (meta-comment) Section 5.4 introduces new text that disallows the optimization of testing for uniqueness of link-locals only and skipping the test for additional addresses. Therefore, new implementations will need to do DAD for addresses that derive from both organic information (link-locals) and information learned from the network (non-link-locals). This suggests that the configuration variable 'DupAddrDetectTransmits' is over- loaded in the new specification since DAD considerations for link-locals and non-link-locals may be different in some environments. Suggested fix is to split the configuration variable into two separate variables ('DupAddrDetectTransmits' and 'DupAddrDetectTransmitsLL') with the former used for DAD tests of non-link-locals and the latter used for DAD tests of link-locals. New implememtations would use the separate variables, and existing implementations would continue to use the single variable. Text changes throughout the document for consistency also required. 3) (specific) Section 5.3, third bullet, second sentence, change to: "This includes the case where the attached link is dynamically changed, e.g., due to a change of the access point of wireless networks." 4) (specific) Section 5.5.3, item d), the phrase: "configured by stateless autoconfiguration" - why was this phrase added? Prefer that it be removed. Fred fred.l.templin@boeing.com=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ccontingent1@bitbytes.com Wed Aug 30 17:16:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIXPz-000630-JU; Wed, 30 Aug 2006 17:16:15 -0400 Received: from csdu-29250.communicomm.com ([24.143.29.250]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIXPn-0003HX-L3; Wed, 30 Aug 2006 17:16:15 -0400 From: "Celexa.INC" To: "Cfrg-bounces" Subject: for more than 2 weeks, check with your dentist Continuing dryness Insulin Date: Wed, 30 Aug 2006 14:16:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00CB_01C5052A.62D52DA0" X-Spam-Score: 2.0 (++) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 This is a multi-part message in MIME format. ------=_NextPart_000_00CB_01C5052A.62D52DA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A0_01C5251B.42D30EB0" ------=_NextPart_001_00A0_01C5251B.42D30EB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit time, at little roadside inns of argument on the journey. hundred and forty-nine was the date of King Charless execution. went in to look at it. It was a picture of comfort, full of if so much confidence was reposed in her. Master Copperfield, if ------=_NextPart_001_00A0_01C5251B.42D30EB0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7Bit

French ground. And as soon as I perceived that we not only held our

Like enough, he returned; though theres a sarcastic meaning in I looked at the doorway and saw nothing. I was still looking at

various stages of his narrative, now resumed all its former It does seem a good deal, I answered with a smile. For it was

crushed and bent, that no old battered handleless saucepan on a reappear, but this stands like a high rock in the ocean.

thought at first she would get better, but she was more delicate, protegees whom my aunt had taken into her service expressly to

distress, I had no notion of going back. I doubt if I should have picture by going away somewhere, like the hero in a story, to seek

cheeses, and am considered in disgrace for the rest of the evening. my shirt and breeches, I believe I took a leaping step backward like a

himself under ill usage, with the memorable works of art I have so neatly under my arm, and came back to the shop door.

Copperfield. Show that badge conspicuous, or Ill report you. Give it here, said she, and I will open it myself.

of boys, that I knew I was awkward and inexperienced in the make a mighty snug little party. On the whole, I would recommend

take the liberty of calling me mean or base, or anything of that go and tell him you are here? Will you come up and see him, my

look the road yere on. Thats a that there is to women; and you seem too, I was made infinitely more uncomfortable by the consideration,

accordingly, and cried through the panels, knocking thereon at the same midst of which I heard a great cry from the stair, and Catriona sprang

what your father and mother might both have been, Heaven knows, and grant an act of incorporation for this railroad; and unless that be

For it was of course in my own rooms that I found them, when I came to in my mind, connected with these books, and stood for some locality

whose courtship would appear to have been of an exactly parallel drew back, to observe the effect which this description of her made

style of face turned up, I felt as if the tinkers blackened hand be finished. It was quite an affecting sight, I used to think, to

------=_NextPart_001_00A0_01C5251B.42D30EB0-- ------=_NextPart_000_00CB_01C5052A.62D52DA0 Content-Type: image/gif; name="colonize.GIF" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhLAFQAPcAAP///4CAgWeJkKqRlLgTwVaCiYkCpDfFbThRfVzFgEhLnRiLfUoSkYrIxYiG 219lUh11rCIbp9+8PHV0VVTFMUdUVa17ZImLM34EvLqrpisWGMXBzcjz08YM0Pm8OyNdOxaOYCfO 3dJdJYMtKlHKTVSYANYoiv87x7oHIzNJKfYwf9+7T8vRl76aezjA2+nOgkvc4hfHeMY1vnGOd7xE q25dvyJ2niiVr68+e+PMVjcpppt2Sjvvol9LXZpXd4wp7r0b7/mY04YVd7Ovkq3lri1lJfzx1TsO YB4mYiamYi4m+sTOlznlKkZOKKpdILLdeGniIyWdHC7/Ij02GV+CVOBhldeJpqCd4puZ5qVRzUcV 23rWcSAItG41TVkhq5n5vMOy/1mV54Hs+lZXZEMVEOolYefLngDpZUBn4cqFzdqNm0oDwPPky0d8 D0MMGYQqrQ/HC8m2D0sUkUMVSZTtMc8A42ynx0pS7CnNiloNMa/csrHGuOiSiUeSBMSxtBplzMy1 0SRFoXTNw7wEzqwsSyrkxs/cTdMExm4szdjUyJSMRsfsy2osSnk0y6gMy9b0ym5MRMSUxGwESqy0 Pe2/SJva196KtbG97aZom9vfhom3XSIAjJDbL+Y2t2XSbZB1u6fdMXp3tZ/bl3XHOyH2xkq78Z3v 2SC19cQtZgCicUlHtqxUwIFeaJDLYfyK9C4MJxk+8InMWBajmnt784IO7rizUYTaXG5vzMiC4pRm 2TZmxmp11mru5PWRZbE6mtX1w1HG2gJS1V79Wns9XikdXMUa3+Fd5ugUzGWWR3N0K/w0y+2dvnE0 l/sncrVXiz5YnMZ5nMiZnMq5nMzZnM4pgaIIijbhgILoiQNCEQCpEtSZiZ0YnSH5nRCRnR7/AYgK 4MF36aSglFabMqVVLXqfGzihPpoPE6qfzylBXGJvzhZVnaYfX4ZN3OiAkamZxQKGnUOi9KeMM9Wc bOtQbZwPbQbGmDkCrTfLfKqZdTcGvYoJhQmTsTiRnTuVpUjYlOvJgCH/C05FVFNDQVBFMi4wAwEA AAAh+QQEZAAAACwAAAAALAFQAIcAAACAAAAAgACAgAAAAICAAIAAgIDAwMDA3MCmyvAAAP8AhAAA zv8A///O//////8AAAES8tRHLzVAc7wJEugAACFYBjgBAAES9GS5MLAS9AAS8yS5I3y5MLAS8vxC 2NVC2N0S8xhHLe+5I3wS8yhHKdZHKd4S88RHKegS8yS5I3wS80RG7em5JiQAsDQAAAEAAAAAAAAA AAAAAAEAsDS5I3wS82BHXOAAAAAAAGkS+7gS9MC5JiQS9IxG8N4S8/C4VWhG7em5JiQAsDQAAAES 86hHLe+4VWgAAAES9Ay5MLAS87RHXOAS8/C4VWgS8+RI4dFDzki4VWi4CvC4CugS89hC2NVC2N25 MLC4CxBHKb8S9AQS8/C4VWgS9BBG7em5I3wAsDQAAAEAAAAAAAAAAFIAAADFNJgAAAAS9CxHXOAJ NxwJNswBAFMAASwAAFAS+dTEF+wAAAG5I3wAAAAS9JDID1MS9LDUOx/94AAS9LDUO08S9HzUOzMA AAAJEuhyFegAAAES9MC5JiQAABQAAAEAAAAAAAAS9LRHLe+5JiQS9GQAAAAS9PTXOQrZm2gS9MC5 JiQS9OBG7em5LLwAsDQAAAEAAAAAAAAAAAAAAAEAsDS5JiQS9PxHXOAAAAAAAGkS+7gS9ly5LLwS 9ihG8N65fwy5LLyfs6AAACAFFSrURTUAAAAAAAAAAAAAAAAS9aT3XaMS9TwAABifs6AS9YzUnfkS 9WAAA2IAAiQAAACiMQAAAAIAAXYAAXYABJwAAtEAAp4AAAES9Yy5I3wS9axG7em5JiQAsDQAA2IA AiQS9dTUm+WiMQAkA2IS9qgJNxwJNswBAFMAASwAAFAJPkMJPoIFKpYAAFQS+YAJUQsAAAMS9hwJ TGsAABgJPkMJPoIFKpEAAFQS+bgJUQsFKpEAAFQS+bgS+fgAAAEAAADFNJgAAAAAACgAAAAAAAAS +KjFNMAS+fgAAAEAAAAAAAD/+/CgoKSAgID/AAAA/wD//wAAAP//AP8A//////8I/wAfCBxIsKDB gwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz 6tzJs6fPn0CDCh1KtKjRo0iTmmTAlAHCpk6hSnVaECrDqVQJYm2q0GpXrwnBPuUqcWpYqWPJahWr dCPbB163Mq2KNu3WtXLtzj2Y1+7Ct3/7DpSbdfDbum05NljcwCBTxg0YQJ7c2DBku5Qja83MuLBl xnybTt5r+DFox6JPN4RKuTDr0Z4lX/6sOnFG2YurzuacW6Dp2Xh594YrvPJaynRxI8erPPRv44GV L0/N2fXk48BtZ8z+XKBw2rV9S//PPLg4dLjj6RbfvFx3+8Dr0ZtnDzy9do3cm5cPT5w8+POq6dff cL5xRt9w2T3gn0ELfnXdQKA9B92DA54m4Xn3VSSggAWGdyGB3R1knH4himfgfiBm1yBBK46VoHfy 8VcfeRdmiJ+FHFaoXoMkmoViZNRB96GQ3L2Yo3sEhvXigXzNNh6QLdo4kZM5VnnZhlQiVmGQREao YmevJamjkvw1WeaPZvamHG6yHSllWVcamd9uATq54JNznvYlmCWiSaaYaWLIpGN2gtbakm9GBFmf HYK4Jpaq3fkddosxOh+Sgvr5F6KNCkriZYeemehDix7J4aMlAidpdZiGOWF8gz7/xWlBS2Zl5Kd6 einqqKudiOl/Cy4aa3OjAfued4vKuaupainYGV4QPltaob3FuSuvDPmK3nNzDbknkEH6SaG3AWKV H7exBUnatp6VKpVx7obbabTzYkuRtq52ax6C8c4YKbXxmXvuo8kRrKmzfOIWbcLj1jqrvQsdi2el L37rq4CwHQmwxJN22l6OsCLMW6wkQwzRsSIjV3F4IVuMrJiqarvwih2LzODILOKcM6A2mzxlmftm ujKFM9Mqc9Ep85x0gjUjivLMPDt9rc9UV2311VhnrfXWXHft9ddghy322GSXbfbZaKet9tpst+32 23DHLffcdNdtN68LFJS3QAv0/03Q3nzz3TfgBg1O+AOD/6044onr3Tjjjw9kOOCRG46Q5X/7Lfnj hO99uOCZa1445Z5jPrnjoiNONeWStx6466wXvrjqr9P+euy10/757K7bjvvsuAefu+cHpf775sjb 3rvvwFed9/HEw7789LnrvrjwxSt0+Pa17x4798wrH/31vXuv+vPVK2999s7zvv7t1IPu/vjvH795 5IJrDr794e8v/f/k61720Fe6xoGPcbJr3/ToV8DdZW6Bw8tf5y6nPb1ZEHIOxJz6Grg8+sFPghRc 3+cOKL/02WuCAfygAy/ov/+hMIEhhOD7Lji/9KFwe6ebYQA9uEH2qQ9iB/zd+P/MV74iAvCFOqSh EcOnxCWOMIURZGINf/hCJFpthKnDYAeLh78uco53Gsyh+/IHRhiiboxalCD6AEhFFppOgyCM393m SMc62vGOeMyjHvfIxz768Y+ADKQgB0nIQhrykIhMpCIXychGOvKRkIykJCdJyT8qQCCXPEgm27ZJ hnTyJZ98SCiDooBSbnKUBEElJguSSVOaEpOuHIgrSwkxVRLllELpZCsXYstP7tIgulxl1Ww5FFwC BZW/fMArlSlLYLJSmM9sJjMvcsllwpKWzrRmNVtpTWVqE5vbnOY2ufnKU2rTm6MMJzp1GctpCnOX 4OzmLKX5E2S+s5nJTGU006n/T3dWBJvi7GcqjQnQYPoTmuoUJ0H7adCCAtOY95RmQ2FJz4DSk5g2 sadF8YmQWcaznfO8ZjdFyVCBVjSfE43mSaG50Zai1Jkr9edLXVrSi5KyoxGVpSp9yVKJmpSXI01p T2XKUo/qFKJFTSpRl2pQkxqVqTVlJ0gFitGaaDSfzNSoT2HqzqrysqZDFepBYcrTreaUpkt1qibB atGmqnWoPElpMqsJ17Ly06wq9SRbQylWt+aUrnidaV+5ClWKdvWXbp2rV3PSzo0uE6k9Jedjn/nU sSakqY0d6Dk1a06AolOpIb3mYR1a0cjKk5adbSsrTwtYy9JtsRSBbUZkSxLaP0rJo7jNrW53y9ve +va3wA2ucIdL3OIa97iVTG7YHMDc5hKkudB9LnSZK93pVje6A5kudbOr3es6V7ngtVpAAAAh+QQE ZAAAACwAAAAALAFQAIcAAACAAAAAgACAgAAAAICAAIAAgIDAwMDA3MCmyvAAAP8A/wCcMWP/AADO //////8AAAES8tRHLzVAc7wJEugAACFYBjgBAAES9GS5MLAS9AAS8yS5I3y5MLAS8vxC2NVC2N0S 8xhHLe+5I3wS8yhHKdZHKd4S88RHKegS8yS5I3wS80RG7em5JiQAsDQAAAEAAAAAAAAAAAAAAAEA sDS5I3wS82BHXOAAAAAAAGkS+7gS9MC5JiQS9IxG8N4S8/C4VWhG7em5JiQAsDQAAAES86hHLe+4 VWgAAAES9Ay5MLAS87RHXOAS8/C4VWgS8+RI4dFDzki4VWi4CvC4CugS89hC2NVC2N25MLC4CxBH Kb8S9AQS8/C4VWgS9BBG7em5I3wAsDQAAAEAAAAAAAAAAFIAAADDriQAAAAS9CxHXOAJNxwJNswB IVkAASwAAFAS+dTBh/gAAAG5I3wAAAAS9JDID1MS9LDUOx/94AAS9LDUO08S9HzUOzMAAAAJEuhy FegAAAES9MC5JiQAABQAAAEAAAAAAAAS9LRHLe+5JiQS9GQAAAAS9PTXOQrZm2gS9MC5JiQS9OBG 7em5LLwAsDQAAAEAAAAAAAAAAAAAAAEAsDS5JiQS9PxHXOAAAAAAAGkS+7gS9ly5LLwS9ihG8N65 fwy5LLyfs6AAACAFFSrURTUAAAAAAAAAAAAAAAAS9aT3XaMS9TwAABifs6AS9YzUnfkS9WAAA4cA AikAAACiMQAAAAIAAXYAAXYABJwAAtEAAp4AAAES9Yy5I3wS9axG7em5JiQAsDQAA4cAAikS9dTU m+WiMQApA4cS9qgJNxwJNswBIVkAASwAAFAJPkMJPoIFKp0AAFQS+YAJUQsAAAMS9hwJTGsAABgJ PkMJPoIFKZQAAFQS+bgJUQsFKZQAAFQS+bgS+fgAAAEAAADDriQAAAAAACgAAAAAAAAS+KjDrkwS +fgAAAEAAAAAAAD/+/CgoKSAgID/AAAA/wD//wAAAP//AP8A//////8I/wAfCBxIsKDBgwgTKlzI sKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtGlJBlAZIIwqlapVqQWpMryKlSDXqAq1hhWbkOxUsBKvlrV6Fq1Xs04v Ql1Ad8HbuXUZ1N1bVyDVvQet8qU7MOpgwFkN902seLHBxnYD4yXcUDDfu5Md+80c+QHkznEpQi6c mfNlz6YZ6z3c9/Ngxq9Jm3Z8FbHs0VtdA/7LuvPnzZxDW8SNejXl3nZ52y5uvHdx5JSZx5aOHPhh 2NPXzt6r3Pnzy66FD/9vDpz89+jnT6cHbTy9e+vX16NGrBu7eu3qjf+evzt1ePGiZfbegOst1h1C yQlInG6R4UbcA/EZFGFb5hW0wIMKzvYfgGllWOGCDMKHnmTNHUhdbA4KKNtyd7H4mIovVijihRpC mB2HEJUG4oc69leiWivmFVx6HtIHI4EtakaiizPaR2OJfdElI44PQXbkjtyRZ+VsBebXo4HNPSnj g0mOGCOTSG4JJV9TUlnZl+ilCGeCP4ZJGIPRdacinpqRGaSZTrbFoprcDdamm7lluZycWepY4XV4 limmbXZm52eTYx2apqOKCokmovhN+B6fd/KoZWleVnqfQGwueqSkiSr/2dWVhHpqK6CghnrjaN2x NmqRt5a6HZMm/gkarLchi9aTRgIbnZSv5rrQduU5Cx1/Qlr7GanZ1tYsmd7GuWeYymELbXDgRiut rrQNeyGl40JHZ39swlirrzOi6O6A7jaoarODqrvuWdPxOeaY16ZYr6uNepfvaXymWV1hE2+q6cAJ MSkvri6KauOIDlu4mMcDVcxqyGjeSJDKJ3OsJMYwxyzzzDTXbPPNOOes88489+zzz0AHLfTQRBdt 9NFIJ6300kw37fTTUEct9dRUV221SQ1k3QBBWmf9QNdaH+S1QV0PFPbXBW3N9dhpt/0122+nfbZA ZcuNENhvw4133nCj/0232WZ7DbbgXN+t9t+AH4742orzzbjie9cNOEqQT052Qls3vvjhnLu9+eWW +/135ZZ3nvjdnpteOOqfhy7665qjTfroq9c+u+qql157SbG/vnvbsZOeu++9Ly668K6Hbnrwnvut efHOqz278dNP3rn01oOe/faIP7879B0Vv7fxqzPfOvHaaz899r7bXr7YZ+Ne9/jWs08+5PRznzn1 3ruNe/nzUx7lGEe+5B0PfnpznflA17j/wW5skjtg+hyXPOjtb3+/W5/6sle9AkpvbrDzIAjbJ5IG FvCEfOvbAk3IOv99L4Dv498I0Xc+Axbughn8HgIheDoDstCB3dvg7/9IgjyxLWSB7svhCTGouyYG kXvtY+ETh2i3uCmReumzXwhbmDv7DW+LLZEc/cCHRLpBsGyR61vg5KZF/LHNhB2U4ujmF0EnmlGD FYwhFjGXwBuCMHIuvJogB0nIQhrykIhMpCIXychGOvKRkIykJCdJyUpa8pKYzKQmN8nJTnrSZgoQ SCgPMkqjlZIhp3xJKh+yyqAo4JWlbCVBZCnKgowSlrAUJS4HgstXgoqWRImlUE55y4UAM5XFNAgx azkwYA5FmECRZTIfkEtq8lKZtmRmNq9pzYuEspq69CU2wfnNW4KTmuQUZzm7WU5z5jKW5ERnK9cp T2LuspvMLKY6z9n/S27+RJr5vOY0Z7nNeRIUnxURJzsPOktoKnSZCNUmPdnp0INC9KHKhGZAuXlR Xfpzof50pk0AClKBIqSX+7xnP8N5TlZalKEfHWhHtxlTbZb0pjLFZk0RmlOcvjSkrjzpRnlJS2Ta lKMwNWZLZ3pUntoUpUTV6FOn6tSqQhSmULXqT+2pUoaKtCYkHag1SYpUneLzq8b8aVOZGlGdGrWs Q/VpVbFKSrWC9Kp0bSpPZjrNb+r1rQaFK01RaddVshWvQ/WrYHt6WLNq1aNnTSZe+4rWnNyzpNWU 6lHdmdlsZrWtCbnqZRsaT9LCU6HypOpKwxlZjH50s/z05WnvasvYTCoWtE2rLEV0mxHeksS34kGp cIdL3OIa97jITa5yl8vc5jr3udCN7ienazMHWPe6BLmudrOrXetyt7vf3e5Auuvd8ZI3vNilrnpz KZzBuTZWuvnJP7Pzj247xSHhmbCgndxQR/tnGA06soY+NKITrehF0y54rpvScAL9PEcBr0XEfF9C OQOi1n71/1tfhdF3t315b8UmjCertTe84nVaf5Nz3nKB7J3xndmGWXbiztwUxBbWb40B9rABj/i8 2uZX3rEe2wtdMbHfPqnf7pnjtKipsifSlhUnrS14SW3qTm7valWLXi6OFGYik2clP64wEWlkimZO lxBTh1GOWu6uaKqcTDU3L/wsUUBg0pImo6guU/ayWETt5BWhGU8wRqabkCXPHduYmav58WsM42Z4 qnJzZyLvby2PUCbPb3SH2GyeQEtCQQhW4A3N8QqvT3uWonq394dWYAd/SHsH+IAX+IEneIADUTo8 ------=_NextPart_000_00CB_01C5052A.62D52DA0-- From ipv6-bounces@ietf.org Wed Aug 30 20:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaNV-0000y2-36; Wed, 30 Aug 2006 20:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaNT-0000xx-Q3 for ipv6@ietf.org; Wed, 30 Aug 2006 20:25:51 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIaNP-0001aw-GY for ipv6@ietf.org; Wed, 30 Aug 2006 20:25:51 -0400 Received: from jurassic.eng.sun.com ([129.146.224.130]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7V0PkkK027600; Wed, 30 Aug 2006 18:25:46 -0600 (MDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k7V0Ph1t431056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 17:25:46 -0700 (PDT) Message-ID: <44F62C87.8030407@sun.com> Date: Wed, 30 Aug 2006 17:25:43 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ipv6@ietf.org, ext Pars MUTAF Subject: Re: Proposal to change aspects of Neighbor Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Basavaraj Patil wrote: > Ignoring cellular hosts for a moment, how are periodic RAs useful for any > host? RAs can be used as a means for detecting network attachment status or > to detect movement (prefix change). In the case of a stationary host (as an > example), periodic RAs really are of no benefit to the host (IMO). A design principle for many Internet protocols is known as "soft state". I wonder if that might have something to do with the periodic RAs ;-) If the hosts would keep the information received until it being explicitly invalidated we would probably end up with a more complex and/or more fragile approach to handle the stale state. Hence the soft state approach. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Wed Aug 30 20:30:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaM3-0008IA-CP; Wed, 30 Aug 2006 20:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIaM2-0008DI-3W for ipv6@ietf.org; Wed, 30 Aug 2006 20:24:22 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIaLy-0001UF-Oe for ipv6@ietf.org; Wed, 30 Aug 2006 20:24:22 -0400 Received: from jurassic.eng.sun.com ([129.146.17.57]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7V0OGea023893; Wed, 30 Aug 2006 17:24:16 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k7V0OEFW430805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 17:24:16 -0700 (PDT) Message-ID: <44F62C2E.7050603@sun.com> Date: Wed, 30 Aug 2006 17:24:14 -0700 From: Erik Nordmark User-Agent: Thunderbird 1.5.0.5 (X11/20060730) MIME-Version: 1.0 To: Syam Madanapalli References: <10e14db20608080611w136a0011waa0cf52bf6d3566d@mail.gmail.com> <200608081350.k78DoN6E029935@tao.fdupont.fr> <10e14db20608080824g49eea69brf9961be5236cd210@mail.gmail.com> <44D9881E.1020102@sun.com> <10e14db20608090644i3929bafbj1216b742bb51783@mail.gmail.com> <44DB7CEE.5090608@sun.com> <10e14db20608101231j1919b2deiab104a6aa3e40603@mail.gmail.com> <10e14db20608101248u7862edfch63eb318576c651bc@mail.gmail.com> In-Reply-To: <10e14db20608101248u7862edfch63eb318576c651bc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ipv6@ietf.org Subject: Re: Proposal to change aspects of Neighbor Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Syam Madanapalli wrote: > And by the way, will the expiry of the default router lifetime tigger > the DNA? Is it specified in the DNA Spec? I don't think that is in the DNA specification. DNA is triggered by L2 events notifications - 'link up'. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 02:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIg8N-000815-Vo; Thu, 31 Aug 2006 02:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIg8M-00080y-Fx for ipv6@ietf.org; Thu, 31 Aug 2006 02:34:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIg8M-0002ON-EM for ipv6@ietf.org; Thu, 31 Aug 2006 02:34:38 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIfvj-0003YY-56 for ipv6@ietf.org; Thu, 31 Aug 2006 02:21:36 -0400 Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:98e8:9cef:be13:578]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6E8A715228; Thu, 31 Aug 2006 15:21:30 +0900 (JST) Date: Thu, 31 Aug 2006 15:21:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: bob.hinden@nokia.com, "Templin, Fred L" , ipv6@ietf.org, Suresh Krishnan Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 25 Aug 2006 06:13:17 -0400, >>>>> Ralph Droms said: > I'm sorry for introducing other recommendations into your thread. I > forwarded comments from a private exchange about the draft. I'll separate > the other recommendations out into a different thread. > I don't have a strong opinion about your text, either and perhaps brevity is > a virtue. How about: > One way to avoid having a static non-changing address is to use > DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 > discusses the use of DHCPv6 for the assignment and management > of "temporary addresses", which are never renewed and provide the same > property of temporary addresses described in this document with regards > to the privacy concern. I'm fine with this text. We might want to replace "RFC 3315" with [DHCPV6] for consistency though. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 03:02:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgXa-00047s-5t; Thu, 31 Aug 2006 03:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgXZ-00047m-0v for ipv6@ietf.org; Thu, 31 Aug 2006 03:00:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIg8A-0002Ly-LP for ipv6@ietf.org; Thu, 31 Aug 2006 02:34:26 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIg2G-0003fY-NW for ipv6@ietf.org; Thu, 31 Aug 2006 02:28:21 -0400 Received: from impact.jinmei.org (unknown [2001:200:1b1:1010:98e8:9cef:be13:578]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CB97215267; Thu, 31 Aug 2006 15:28:18 +0900 (JST) Date: Thu, 31 Aug 2006 15:28:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: bob.hinden@nokia.com, "Templin, Fred L" , ipv6@ietf.org, Suresh Krishnan Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org >>>>> On Fri, 25 Aug 2006 06:18:06 -0400, >>>>> Ralph Droms said: >>> I recommend removing section 2.2 (as I did in the earlier post cited >>> by Suresh), as experience with IPv4 addressing has little bearing on >>> IPv6. This observation is bolstered by the text in section 2.3 >>> describing the problem addressed by privacy addresses. For example, >>> a device gets an entirely new IPv4 address when it moves to a new >>> connection point, so tracking that device as it moves between connection >>> points is harder than in IPv6. And, I think there is a fundamental problem >>> that most IPv4 stacks and applications are built on the assumption of a >>> single address per interface, so privacy addresses would be hard to use in >>> any event. If section 2.2 is retained, some of the details should be >>> corrected; e.g., "Over the last few years, sites have begun moving >>> away from static allocation to dynamic allocation via DHCP [DHCP]." >>> sounds dated. >> >> I don't have a strong opinion on this, but I personally think the >> current text is okay as general background information, and it doesn't >> sound odd to me. > If the text is retained, it needs to be updated and corrected. Perhaps, but in any event I don't insist on a particular way, whether to remove or keep this subsection (and with or without modification). I'd basically leave the decision to the editor. Of course, I'm willing to review the revised text if it's updated and a review is required. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 04:46:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIi8O-0003OS-Qa; Thu, 31 Aug 2006 04:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIi8N-0003Ns-1P; Thu, 31 Aug 2006 04:42:47 -0400 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIi8L-0004JW-Ns; Thu, 31 Aug 2006 04:42:47 -0400 Received: from [192.168.1.103] (212.119.9.178) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 44F4DD6A000D4A49; Thu, 31 Aug 2006 10:42:43 +0200 From: Julien Laganier To: "James Kempf" Date: Thu, 31 Aug 2006 10:43:02 +0200 User-Agent: KMail/1.8.2 References: <39C363776A4E8C4A94691D2BD9D1C9A101774241@XCH-NW-7V2.nw.nos.boeing.com> <016301c6c7a7$ad7e4fc0$266115ac@dcml.docomolabsusa.com> In-Reply-To: <016301c6c7a7$ad7e4fc0$266115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200608311043.02436.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: netlmm@ietf.org, INT Area , IETF IPv6 Mailing List Subject: Re: [netlmm] Multilink Subnet Considerations for NETLMM Addressing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Hi James, Just for clarification. On Thursday 24 August 2006 20:04, James Kempf wrote: > Fred, > > I don't think this quite captures the situation. > > [...] > > Secondly, exactly what is meant by 'L=0' is underspecified by RFC > 2461. I think everyone agrees with 'L=1' means, that the prefix is > only being advertised to nodes that are on this physical link. Any > effort to tighten up the definitoin of 'L=0' is going to need > wider discussion with the ipv6 WG and possibly might impact > RFC2461bis. This draft is currently in AD Evauation:Revised Draft > Needed. > > [...] I wouldn't say that 'L=0' semantic is underspecified. I on the opposite found 2461 to be quite well specified. It says: Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link. That is, it doesn't mean that *all* nodes are off-link. Some might, while some might not. But it clearly specifies what the node should do in that case. The default behavior (see Section 5.2) when sending a packet to an address for which no information is known about the on-link status of the address is to forward the packet to a default router; i.e. send packets to the default router. What do you think is underspecified? --julien -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 08:40:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlmV-0000Pp-W7; Thu, 31 Aug 2006 08:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlmV-0000LA-34 for ipv6@ietf.org; Thu, 31 Aug 2006 08:36:27 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIlmT-0008CR-Qb for ipv6@ietf.org; Thu, 31 Aug 2006 08:36:27 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2006 05:36:26 -0700 X-IronPort-AV: i="4.08,194,1154934000"; d="scan'208"; a="39207934:sNHT34133414" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VCaPuT006245; Thu, 31 Aug 2006 08:36:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7VCaOdM013312; Thu, 31 Aug 2006 08:36:25 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 08:36:24 -0400 Received: from 10.86.242.241 ([10.86.242.241]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Aug 2006 12:35:56 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 31 Aug 2006 08:35:36 -0400 From: Ralph Droms To: Suresh Krishnan Message-ID: Thread-Topic: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) Thread-Index: AcbM+fU9M8N05jjtEduDigARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 12:36:24.0748 (UTC) FILETIME=[124BB6C0:01C6CCFA] DKIM-Signature: a=rsa-sha1; q=dns; l=1321; t=1157027785; x=1157891785; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20DHCP=20for=20privacy=20addresses=20(was=3A=20RE=3A=20Is=20there= 20any=20provision=0A=20in=20privacy=20addressing=20...) |To:Suresh=20Krishnan=20; X=v=3Dcisco.com=3B=20h=3DNSIJHXUOYktEtQIvsj91D4JevKA=3D; b=SCngcrBjvEGH+bRkt4bnPJ5LLMC3R0x9/BRr7TR2aBO9ZuA0fIPuCYgxxGhQVCo0dIN0RVHp Uibk1bqBSQI4/BJH3OAalfraOJv/ZAuFLQxhFC85CWYVAAFngSRHqwAM; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: bob.hinden@nokia.com, "Templin, Fred L" , ipv6@ietf.org, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Suresh - I think Jinmei-san and I have come to agreement on replacement text in section 2.4 (see below). - Ralph On 8/31/06 2:21 AM, "JINMEI Tatuya / $B?@L@C#:H(B" wrote: >>>>>> On Fri, 25 Aug 2006 06:13:17 -0400, >>>>>> Ralph Droms said: > >> I'm sorry for introducing other recommendations into your thread. I >> forwarded comments from a private exchange about the draft. I'll separate >> the other recommendations out into a different thread. > >> I don't have a strong opinion about your text, either and perhaps brevity is >> a virtue. How about: > >> One way to avoid having a static non-changing address is to use >> DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 >> discusses the use of DHCPv6 for the assignment and management >> of "temporary addresses", which are never renewed and provide the same >> property of temporary addresses described in this document with regards >> to the privacy concern. > > I'm fine with this text. We might want to replace "RFC 3315" with > [DHCPV6] for consistency though. I agree with replacing RFC 3315 with [DHCPV6]. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 09:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GImRO-0004Mr-Bv; Thu, 31 Aug 2006 09:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GImRN-0004Mm-J4 for ipv6@ietf.org; Thu, 31 Aug 2006 09:18:41 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GImRM-0006Ai-4F for ipv6@ietf.org; Thu, 31 Aug 2006 09:18:41 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k7VDI9oC008954; Thu, 31 Aug 2006 16:18:09 +0300 Date: Thu, 31 Aug 2006 16:18:08 +0300 (EEST) From: Pekka Savola To: Ralph Droms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.4/1776/Wed Aug 30 23:37:14 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipv6@ietf.org, "Templin, Fred L" , bob.hinden@nokia.com, Suresh Krishnan , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 31 Aug 2006, Ralph Droms wrote: > Suresh - I think Jinmei-san and I have come to agreement on replacement text > in section 2.4 (see below). As a WG participant, if we want to go ahead with the change, I'd expect WG chairs to issue a last call of some sort for the changes (giving a good motivation for the change), given that the document has already left the WG quite a while ago. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 09:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GImYO-0007sk-Pz; Thu, 31 Aug 2006 09:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GImYN-0007sf-3H for ipv6@ietf.org; Thu, 31 Aug 2006 09:25:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GImYL-0008MT-PX for ipv6@ietf.org; Thu, 31 Aug 2006 09:25:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2006 06:25:53 -0700 X-IronPort-AV: i="4.08,194,1154934000"; d="scan'208"; a="39220497:sNHT32372764" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VDPrXd006838; Thu, 31 Aug 2006 09:25:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7VDPrdM000158; Thu, 31 Aug 2006 09:25:53 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 09:25:52 -0400 Received: from 10.86.242.241 ([10.86.242.241]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Aug 2006 13:25:12 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 31 Aug 2006 09:24:52 -0400 From: Ralph Droms To: Pekka Savola Message-ID: Thread-Topic: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) Thread-Index: AcbNANcnFZWx2jj0EduDigARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 13:25:52.0908 (UTC) FILETIME=[FB74FCC0:01C6CD00] DKIM-Signature: a=rsa-sha1; q=dns; l=976; t=1157030753; x=1157894753; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20DHCP=20for=20privacy=20addresses=20(was=3A=20RE=3A=20Is=20there= 20any=20provision=0A=20in=20privacy=20addressing=20...) |To:Pekka=20Savola=20; X=v=3Dcisco.com=3B=20h=3DKunPBSH7fsstq6NsBCpdfUYoRmE=3D; b=YLPNUC6ZcSfROE4gBpK5eJhWpgqdKKxd2QgBL1xI2O4u2A7FLFf2ZMz+0G3tPb8wVR97kJ/9 8atwNVQUTt22m5xj2Uns75yy34lNtO/l6FfWcmFZkFaXJiF5+gLrGMyg; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ipv6@ietf.org, "Templin, Fred L" , bob.hinden@nokia.com, Suresh Krishnan , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pekka - I would agree if the text in question were a key component of the protocol specification. But, because this text is background material and the discussion has been conducted on the WG mailing list, I don't think a last call is warranted for this text. Of course, there may be other changes to the doc that would more strongly suggest a WG last call... - Ralph On 8/31/06 9:18 AM, "Pekka Savola" wrote: > autolearn=ham version=3.1.4 > X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi > > On Thu, 31 Aug 2006, Ralph Droms wrote: >> Suresh - I think Jinmei-san and I have come to agreement on replacement text >> in section 2.4 (see below). > > As a WG participant, if we want to go ahead with the change, I'd > expect WG chairs to issue a last call of some sort for the changes > (giving a good motivation for the change), given that the document has > already left the WG quite a while ago. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 12:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIp8u-00005d-En; Thu, 31 Aug 2006 12:11:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIp8s-0008OW-Fg for ipv6@ietf.org; Thu, 31 Aug 2006 12:11:46 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIp8r-0006G7-13 for ipv6@ietf.org; Thu, 31 Aug 2006 12:11:46 -0400 Message-ID: <003001c6cd18$357ef620$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Erik Nordmark" , "Basavaraj Patil" References: <44F62C87.8030407@sun.com> Date: Thu, 31 Aug 2006 09:12:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipv6@ietf.org, ext Pars MUTAF Subject: Re: Proposal to change aspects of Neighbor Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Erik, I think the proposal was not to keep the router information until it was explicitly invalidated but rather that the host could individually solicit prior to the expiration of the lifetime. The router information state is still soft state, its just that the renewal is different. 2641 explicitly prohibits solicitation except for 5 specific cases, and renewing a router table entry is not one of them. For some types of wireless links, multicast unsolicited router advertisements are not really that helpful in determining router reachability, because the host may be able to hear the router, but not transmit. If the host depends on a multicast unsolicited router advertisement, it could end up with a lengthy NUD procedure before it determined that it couldn't really use the router. That's one reason why an RS-RA exchange would be more useful. Another is the issue of dormant mode hosts, which is I think what prompted the original posting on this thread. I suspect this was originally done to avoid packet storms when the lifetime expired. But that could be avoided by specifying that the host needs to pick a random time prior to the expiration time over some interval. jak ----- Original Message ----- From: "Erik Nordmark" To: "Basavaraj Patil" Cc: ; "ext Pars MUTAF" Sent: Wednesday, August 30, 2006 5:25 PM Subject: Re: Proposal to change aspects of Neighbor Discovery > Basavaraj Patil wrote: > >> Ignoring cellular hosts for a moment, how are periodic RAs useful for any >> host? RAs can be used as a means for detecting network attachment status >> or >> to detect movement (prefix change). In the case of a stationary host (as >> an >> example), periodic RAs really are of no benefit to the host (IMO). > > A design principle for many Internet protocols is known as "soft state". > I wonder if that might have something to do with the periodic RAs ;-) > > If the hosts would keep the information received until it being explicitly > invalidated we would probably end up with a more complex and/or more > fragile approach to handle the stale state. Hence the soft state approach. > > Erik > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 12:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpUs-00057n-Vi; Thu, 31 Aug 2006 12:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpUr-00053j-3x for ipv6@ietf.org; Thu, 31 Aug 2006 12:34:29 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpUp-0007cG-8Q for ipv6@ietf.org; Thu, 31 Aug 2006 12:34:29 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k7VGY5mu015529; Thu, 31 Aug 2006 19:34:07 +0300 Date: Thu, 31 Aug 2006 19:34:05 +0300 (EEST) From: Pekka Savola To: Ralph Droms In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.4/1776/Wed Aug 30 23:37:14 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipv6@ietf.org, "Templin, Fred L" , bob.hinden@nokia.com, Suresh Krishnan , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org On Thu, 31 Aug 2006, Ralph Droms wrote: > Pekka - I would agree if the text in question were a key component of the > protocol specification. But, because this text is background material and > the discussion has been conducted on the WG mailing list, I don't think a > last call is warranted for this text. If the text has little relevance, then I don't see why it needs to change. AFAIR, it was significantly debated, and reopening that discussion might not be the best use of our time and energy. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 12:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpc4-0000s6-Kd; Thu, 31 Aug 2006 12:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpc3-0000s1-T2 for ipv6@ietf.org; Thu, 31 Aug 2006 12:41:55 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpc0-0008A7-5Y for ipv6@ietf.org; Thu, 31 Aug 2006 12:41:55 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7VGfpLG008731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 Aug 2006 09:41:51 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k7VGfowM024488 for ; Thu, 31 Aug 2006 09:41:51 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7VGfohx024481; Thu, 31 Aug 2006 09:41:50 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 09:41:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 31 Aug 2006 09:41:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177427B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCP for privacy addresses (was: RE: Is there any provision inprivacy addressing ...) Thread-Index: AcbNG1B+wWcqjbidRvyeMkkOLAua0QAAFs+g From: "Templin, Fred L" To: "Pekka Savola" , "Ralph Droms" X-OriginalArrivalTime: 31 Aug 2006 16:41:49.0808 (UTC) FILETIME=[5B1D8F00:01C6CD1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ipv6@ietf.org, bob.hinden@nokia.com, Suresh Krishnan , =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhCIA==?= Subject: RE: DHCP for privacy addresses (was: RE: Is there any provision inprivacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org > If the text has little relevance, then I don't see why it needs to change. The current text in (RFC3041(bis), Section 2.4, paragraph 1) is inaccurate as discussed earlier in this thread. Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 12:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpgW-0003Qb-BA; Thu, 31 Aug 2006 12:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpgU-0003QW-G2 for ipv6@ietf.org; Thu, 31 Aug 2006 12:46:30 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpgT-0000CK-5v for ipv6@ietf.org; Thu, 31 Aug 2006 12:46:30 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7VGkSKN012177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 31 Aug 2006 09:46:28 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k7VGkRLG004729 for ; Thu, 31 Aug 2006 09:46:28 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7VGkKSj004374; Thu, 31 Aug 2006 09:46:21 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 09:46:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 31 Aug 2006 09:46:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177427C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCP for privacy addresses (was: RE: Is there any provisionin privacy addressing ...) Thread-Index: AcbM+fU9M8N05jjtEduDigARJOT6egAIuNYw From: "Templin, Fred L" To: "Ralph Droms" , "Suresh Krishnan" X-OriginalArrivalTime: 31 Aug 2006 16:46:19.0331 (UTC) FILETIME=[FBC38130:01C6CD1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: bob.hinden@nokia.com, ipv6@ietf.org, =?iso-2022-jp?B?SklOTUVJIFRhdHV5YSAvIBskQj9ATEBDIzpIGyhCIA==?= Subject: RE: DHCP for privacy addresses (was: RE: Is there any provisionin privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org I agree with this resolution. Fred fred.l.templin@boeing.com -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, August 31, 2006 5:36 AM To: Suresh Krishnan Cc: ipv6@ietf.org; Templin, Fred L; bob.hinden@nokia.com; JINMEI Tatuya / $B?@L@C#:H(J Subject: Re: DHCP for privacy addresses (was: RE: Is there any provisionin privacy addressing ...) Suresh - I think Jinmei-san and I have come to agreement on replacement text in section 2.4 (see below). - Ralph On 8/31/06 2:21 AM, "JINMEI Tatuya / $B?@L@C#:H(J" wrote: >>>>>> On Fri, 25 Aug 2006 06:13:17 -0400, >>>>>> Ralph Droms said: > >> I'm sorry for introducing other recommendations into your thread. I >> forwarded comments from a private exchange about the draft. I'll separate >> the other recommendations out into a different thread. > >> I don't have a strong opinion about your text, either and perhaps brevity is >> a virtue. How about: > >> One way to avoid having a static non-changing address is to use >> DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315 >> discusses the use of DHCPv6 for the assignment and management >> of "temporary addresses", which are never renewed and provide the same >> property of temporary addresses described in this document with regards >> to the privacy concern. > > I'm fine with this text. We might want to replace "RFC 3315" with > [DHCPV6] for consistency though. I agree with replacing RFC 3315 with [DHCPV6]. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 13:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpuW-0002q3-P4; Thu, 31 Aug 2006 13:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIpuV-0002pu-1j for ipv6@ietf.org; Thu, 31 Aug 2006 13:00:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIpuU-0001aS-WF for ipv6@ietf.org; Thu, 31 Aug 2006 13:00:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIpaU-0003iM-1A for ipv6@ietf.org; Thu, 31 Aug 2006 12:40:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2006 09:40:18 -0700 X-IronPort-AV: i="4.08,195,1154934000"; d="scan'208"; a="39273911:sNHT32252636" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VGeH9T016911; Thu, 31 Aug 2006 12:40:17 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7VGeGdS010069; Thu, 31 Aug 2006 12:40:17 -0400 (EDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 12:40:16 -0400 Received: from 161.44.65.204 ([161.44.65.204]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 Aug 2006 16:39:26 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 31 Aug 2006 12:39:06 -0400 From: Ralph Droms To: Pekka Savola Message-ID: Thread-Topic: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) Thread-Index: AcbNG/l6OCCrpjkPEduruQARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 16:40:16.0660 (UTC) FILETIME=[23984D40:01C6CD1C] DKIM-Signature: a=rsa-sha1; q=dns; l=1100; t=1157042417; x=1157906417; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:Ralph=20Droms=20 |Subject:Re=3A=20DHCP=20for=20privacy=20addresses=20(was=3A=20RE=3A=20Is=20there= 20any=20provision=0A=20in=20privacy=20addressing=20...) |To:Pekka=20Savola=20; X=v=3Dcisco.com=3B=20h=3DKunPBSH7fsstq6NsBCpdfUYoRmE=3D; b=oezEXP0qVaX81vlAJoTCQM0hW/zSRr6neXVOf4nK5oqN0AX4FFd/e5FVPPWBYzTamxaLh4LX Qt7qWo5Dxz0JToNqv7X5/2s6sWmqnRyTtM82xRXAPcmLcvNPs2Lfo9VJ; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -1.6 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: bob.hinden@nokia.com, "Templin, Fred L" , ipv6@ietf.org, Suresh Krishnan , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEIg?= Subject: Re: DHCP for privacy addresses (was: RE: Is there any provision in privacy addressing ...) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Pekka - the discussion has already occurred on the ipv6 WG mailing list and we have consensus on replacement text. I don't see a need to further waste the WG's time with additional discussion in a WG last call now that the interested parties have already come to consensus. I didn't say the text is irrelevant, I said it was background material. More precisely, the text does not affect the protocol being standardized. However, the text is, in fact, wrong, and should be corrected. - Ralph On 8/31/06 12:34 PM, "Pekka Savola" wrote: > On Thu, 31 Aug 2006, Ralph Droms wrote: >> Pekka - I would agree if the text in question were a key component of the >> protocol specification. But, because this text is background material and >> the discussion has been conducted on the WG mailing list, I don't think a >> last call is warranted for this text. > > If the text has little relevance, then I don't see why it needs to > change. AFAIR, it was significantly debated, and reopening that > discussion might not be the best use of our time and energy. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 13:43:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqX6-0008RX-9D; Thu, 31 Aug 2006 13:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqX4-0008Py-9v; Thu, 31 Aug 2006 13:40:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIqX2-0005YS-Hu; Thu, 31 Aug 2006 13:40:50 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id k7VHeGcC013187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2006 10:40:21 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id k7VHedV2015823; Thu, 31 Aug 2006 10:40:40 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id k7VHedCk015787; Thu, 31 Aug 2006 10:40:39 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 10:40:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Aug 2006 10:40:37 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177427D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200608311043.02436.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Multilink Subnet Considerations for NETLMM Addressing Thread-Index: AcbM2XhbcW8aB9vJSA+xokwljFZs0QARPFRQ From: "Templin, Fred L" To: "Julien Laganier" , "James Kempf" X-OriginalArrivalTime: 31 Aug 2006 17:40:38.0539 (UTC) FILETIME=[92672DB0:01C6CD24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: INT Area , netlmm@ietf.org, IETF IPv6 Mailing List Subject: RE: [netlmm] Multilink Subnet Considerations for NETLMM Addressing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org In addition to what Julien said, (RFC2461, Section 6.3.4) also says: "Prefixes with the on-link flag set to zero would normally have the autonomous flag set and be used by [ADDRCONF]." and ([ADDRCONF], Section 5.5.3) looks only at the 'A' bit for address configuration. Hosts use prefixes with the 'A' bit set to configure an address and add it to the list of addresses assigned to the interface regardless of the sense of the 'L' bit. Fred fred.l.templin@boeing.com =20 -----Original Message----- From: Julien Laganier [mailto:julien.IETF@laposte.net]=20 Sent: Thursday, August 31, 2006 1:43 AM To: James Kempf Cc: netlmm@ietf.org; INT Area; IETF IPv6 Mailing List Subject: Re: [netlmm] Multilink Subnet Considerations for NETLMM Addressing Hi James, Just for clarification. On Thursday 24 August 2006 20:04, James Kempf wrote: > Fred, > > I don't think this quite captures the situation. > > [...] > > Secondly, exactly what is meant by 'L=3D0' is underspecified by RFC > 2461. I think everyone agrees with 'L=3D1' means, that the prefix is > only being advertised to nodes that are on this physical link. Any > effort to tighten up the definitoin of 'L=3D0' is going to need > wider discussion with the ipv6 WG and possibly might impact > RFC2461bis. This draft is currently in AD Evauation:Revised Draft > Needed. > > [...] I wouldn't say that 'L=3D0' semantic is underspecified. I on the=20 opposite found 2461 to be quite well specified. It says: Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link. That is, it doesn't mean that *all* nodes are off-link. Some might,=20 while some might not. But it clearly specifies what the node should=20 do in that case. The default behavior (see Section 5.2) when sending a packet to an address for which no information is known about the on-link status of the address is to forward the packet to a default router; i.e. send packets to the default router. What do you think is underspecified? --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 13:56:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqkn-0007Xw-99; Thu, 31 Aug 2006 13:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqkk-0007Vo-US; Thu, 31 Aug 2006 13:54:58 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIqkj-00072c-FN; Thu, 31 Aug 2006 13:54:58 -0400 Message-ID: <010a01c6cd26$a05d53c0$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Templin, Fred L" , "Julien Laganier" References: <39C363776A4E8C4A94691D2BD9D1C9A10177427D@XCH-NW-7V2.nw.nos.boeing.com> Date: Thu, 31 Aug 2006 10:55:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: INT Area , netlmm@ietf.org, IETF IPv6 Mailing List Subject: Re: [netlmm] Multilink Subnet Considerations for NETLMM Addressing X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipv6-bounces@ietf.org Maybe I'm confused, but I don't see what L=0 really means. If ADDRCONF assigns the prefix to the interface, then the prefix is on link for at least one node, the node that configured the interface with the prefix. I suppose one could argue that, even if that node considered the prefix on link, that node should not assume another node does. But IFICT, 2461 doesn't have specific, RFC 2119 requirements language around that. If M=1, and stateful configuration is used, then I could see some sense in L=0, since I assume in that case the prefix is not assigned to the interface. Can anybody say what real implemetations do with this? ----- Original Message ----- From: "Templin, Fred L" To: "Julien Laganier" ; "James Kempf" Cc: ; "INT Area" ; "IETF IPv6 Mailing List" Sent: Thursday, August 31, 2006 10:40 AM Subject: RE: [netlmm] Multilink Subnet Considerations for NETLMM Addressing In addition to what Julien said, (RFC2461, Section 6.3.4) also says: "Prefixes with the on-link flag set to zero would normally have the autonomous flag set and be used by [ADDRCONF]." and ([ADDRCONF], Section 5.5.3) looks only at the 'A' bit for address configuration. Hosts use prefixes with the 'A' bit set to configure an address and add it to the list of addresses assigned to the interface regardless of the sense of the 'L' bit. Fred fred.l.templin@boeing.com -----Original Message----- From: Julien Laganier [mailto:julien.IETF@laposte.net] Sent: Thursday, August 31, 2006 1:43 AM To: James Kempf Cc: netlmm@ietf.org; INT Area; IETF IPv6 Mailing List Subject: Re: [netlmm] Multilink Subnet Considerations for NETLMM Addressing Hi James, Just for clarification. On Thursday 24 August 2006 20:04, James Kempf wrote: > Fred, > > I don't think this quite captures the situation. > > [...] > > Secondly, exactly what is meant by 'L=0' is underspecified by RFC > 2461. I think everyone agrees with 'L=1' means, that the prefix is > only being advertised to nodes that are on this physical link. Any > effort to tighten up the definitoin of 'L=0' is going to need > wider discussion with the ipv6 WG and possibly might impact > RFC2461bis. This draft is currently in AD Evauation:Revised Draft > Needed. > > [...] I wouldn't say that 'L=0' semantic is underspecified. I on the opposite found 2461 to be quite well specified. It says: Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link. That is, it doesn't mean that *all* nodes are off-link. Some might, while some might not. But it clearly specifies what the node should do in that case. The default behavior (see Section 5.2) when sending a packet to an address for which no information is known about the on-link status of the address is to forward the packet to a default router; i.e. send packets to the default router. What do you think is underspecified? --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ipv6-bounces@ietf.org Thu Aug 31 15:48:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsU4-0007YE-Cz; Thu, 31 Aug 2006 15:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIsU2-0007Y9-Qx for ipv6@ietf.org; Thu, 31 Aug 2006 15:45:50 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIsU0-0000Nw-Gq for ipv6@ietf.org; Thu, 31 Aug 2006 15:45:50 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k7VJjkDj025967 for ; Thu, 31 Aug 2006 15:45:46 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k7VJjk9B297184 for ; Thu, 31 Aug 2006 15:45:46 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7VJjjPw014789 for ; Thu, 31 Aug 2006 15:45:45 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-197-232.mts.ibm.com [9.65.197.232]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7VJjhAs014699; Thu, 31 Aug 2006 15:45:44 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id k7VJjOKv009928; Thu, 31 Aug 2006 15:45:37 -0400 Message-Id: <200608311945.k7VJjOKv009928@cichlid.raleigh.ibm.com> To: "James Kempf" In-reply-to: <003001c6cd18$357ef620$626015ac@dcml.docomolabsusa.com> References: <44F62C87.8030407@sun.com> <003001c6cd18$357ef620$626015ac@dcml.docomolabsusa.com> Comments: In-reply-to "James Kempf" message dated "Thu, 31 Aug 2006 09:12:08 -0700." Date: Thu, 31 Aug 2006 15:45:24 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Erik Nordmark , ipv6@ietf.org, ext Pars MUTAF Subject: Re: Proposal to change aspects of Neighbor Discovery X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IP Version 6 Working Group $ipv6$" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: ,