From owner-v6ops@ops.ietf.org Mon Jul 03 07:23:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxMWc-0001Kw-NG for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 07:23:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxMWb-0001i8-1a for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 07:23:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxMTL-000BwS-RW for v6ops-data@psg.com; Mon, 03 Jul 2006 11:20:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxMTK-000BwE-Dk for v6ops@ops.ietf.org; Mon, 03 Jul 2006 11:20:10 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.6/8.13.6) with ESMTP id k63BK7RG039518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Jul 2006 11:20:08 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k63BMlrY119932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Jul 2006 13:22:48 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k63BK6Jo026397 for ; Mon, 3 Jul 2006 13:20:07 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k63BK5Nu026349; Mon, 3 Jul 2006 13:20:05 +0200 Received: from zurich.ibm.com (sig-9-146-217-210.de.ibm.com [9.146.217.210]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA59716; Mon, 3 Jul 2006 13:20:01 +0200 Message-ID: <44A8FD60.5090407@zurich.ibm.com> Date: Mon, 03 Jul 2006 13:20:00 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Hain CC: "'Margaret Wasserman'" , "'Fred Baker'" , "'Tim Chown'" , v6ops@ops.ietf.org Subject: Re: Review of draft-ietf-v6ops-nap-02.txt References: <07f901c69c7c$9880e660$1c7ba8c0@tndh.net> In-Reply-To: <07f901c69c7c$9880e660$1c7ba8c0@tndh.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Tony Hain wrote: > Margaret, > > The text sent out on 6/13 was mid-edit session, basically looking to get > comments about the tone changes wrt marketing. The completed edit is > attached with the diff, though I have not passed this by the other authors > yet. I think this version is greatly improved. Brian I had planned to do that when I finished today, but your note appeared > to need a prompt response so you all get it at once. > > I made a number of grammatical changes and reordered some areas to make the > points clearer. Most of the marketing comments are gone, but in their place > is a statement that points out that most users of nat do not evaluate the > technical trade-offs and are not even made aware of the problems they will > encounter. I also changed the tone in some areas from one of offering a > choice between approaches to one that explains how those approaches work. > The 'offer' tone appears to have left the IESG with the perception that the > approaches were speculative. > > One thing to highlight here though is that there appears to be an > expectation that this document is a BCP, when all along it has been > informational. If a BCP is the goal then substantial changes will be > required. As information, it covers the range of approaches that people need > to be aware of. > > The portability you reference below is not a nat feature. The only 'real' > advantage to nat is the expansion of the address space. The reduction of > impact on the routing system has more to do with insistence on ISP based > aggregates that would go away with other aggregation units. Unfortunately > people prefer a challenge and would rather engineer a non-deployable > work-around to a problem-of-choice than discuss the fundamental issues or > alternatives. > > I expect there will need to be some discussion in the WG to make sure it > covers the issues before we present this to the IESG again, though I do > believe it addresses all the comments. > > Tony > > > >>-----Original Message----- >>From: Margaret Wasserman [mailto:margaret@thingmagic.com] >>Sent: Wednesday, June 28, 2006 12:40 PM >>To: 'Tony Hain'; 'Fred Baker'; 'Tim Chown' >>Cc: v6ops@ops.ietf.org >>Subject: RE: Review of draft-ietf-v6ops-nap-02.txt >> >> >> >>Hi Tony, >> >> >>>I had done some updating before the last IESG call & round of >>>comments. The working draft is attached along with a diff to >>>the -02 version. As always comments are welcome. I am not >>>sure this needs a WG slot, but if someone really wants one I >>>am sure we can figure out which one of us can lead the >>>discussion. Below are the comments I sent to the authors >>>about the IESG discuss items. >> >>I think it might be useful to discuss the IESG comments in more depth, >>either on the list or in the WG meeting. I realize that you have made >>changes to address some of the comments, but I think that the WG has to >>decide what to do (if anything) about the substantive issues that you have >>not yet addressed. >> >> >>>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie >>>w_comment&id=5 >>>2102 >>>I put in an arbitrary 50k number as a scale reference. >> >>50K is an order of magnitude higher than the analysis in Alex Zinin's >>presentation would seem to indicate. His presentation indicates that flat >>routing will only scale to something on the order of 1K nodes. Please >>feel >>free to check with Alex, though, as he certainly has more understanding of >>IGP scaling than I do. >> >> >>>That >>>text could be expanded to discuss protocol specifics, >>>topology, and churn rate as hinted by the reference, but that >>>somewhat misses the point. "The technology does work with >>>scale limitations", is the bullet that the IESG appears to be >>>missing by essentially asking for a tutorial on igp >>>engineering. It might be better to put in a range of >>>something like 5k-50k to highlight the point that this is not >>>a hard limit without having to discuss the details of why. >> >>If this document is going to recommend doing flat routing for topology >>hiding, I think that the WG needs to do the analysis to determine that >>this >>is a valid and scalable technique. I would prefer that we just took it >>out >>(perhaps considering a separate document to describe this technique if we >>really think it is worthwhile), because this is an informational document >>and I don't think it is the best place to specify a new operational >>recommendation. BUt, if we do decide to leave it in, then we need to >>document it in enough detail for readers to know when it is (and is not) >>applcable. >> >> >>>I did not expand on renumbering as Thomas requested. It is >>>not clear to me what he wants beyond referencing rfc 4192. >>>The second paragraph of 2.5 could be expanded, but that is >>>not the focus of the section. The second paragraph of 2.7 >>>could be expanded, but would seem to loose context. It sounds >>>like he wants a statement like 'renumbering is hard in IPv4' >>>as justification for nat. >> >>NAT has real (not just perceived ormarketing-invented) advantages in the >>area of address portability. At this point, we do not have mechanisms in >>IPv6 that provide a similar function although SHIM6 may help. >> >> >>>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie >>>w_comment&id=5 >>>1234 >>>This was covered by the edits, and additional background >>>explanation was in the message I sent to the IESG on 5/26. >> >>Did you cc: the WG on that message? I don't seem to have received it. >> >>You made several changes based on my review comments that look good to me. >>Thank you! >> >>However, you don't seem to have addressed some of the concerns that were >>raised in my review. I realize that you don't agree with all of my review >>comments, but some people did agree with them on the list. I guess I'd >>like >>to see some further discussion before we simply decided that no changes >>are >>warranted based on these comments. >> >>In particular, I am still concerned about the following comments: >> >>(1) Thomas' comments on renumbering, combined with my comments on >>providing >>a more balanced view of the real benefits of NAT: >> >> >>>There are at least three other _real_ benefits of NAT boxes. >>>While I hold with this document's position that these benefits >>>can and should be realized in other ways in IPv6, I do not think >>>it is factual or helpful to argue that they don't exist. Those >>>benefits are: >>> >>>(1) Avoiding the reliance of internal network number on externally >>>allocated numbers. AKA not having to renumber when you change ISPs >>>or when ISPs change address allocation strategies. >>> >>>(2) Hiding internal topology from external communicants. >>> >>>(3) Avoiding the establishment of unauthorized inbound connections. >>>While this NAT side effect can also cause problems, it does provide >>>the real benefits of a stateful firewall. >> >>(2) I think that this portion (in section 4.1) still needs some work. Let >>me know if I am missing something here: >> >> >>> It should be >>> noted that the address selection policy table in end-systems needs to >>> be correctly set up so that true global prefixes are distinguished >>> from ULAs and will be used for the source address in preference when >>> the destination is not a ULA. >>> >>>Unless one takes steps to actively screw this up, a globally routable >>>destination address will always have a longest-prefix match with a >>>globally routable source and a ULA will always have a longest-prefix >>>match with a ULA. So, the last sentence is unnecessary and somewhat >>>misleading. >>> >>>The tricky part is making sure that the node uses the right destination >>>address -- a ULA for local traffic and global address for non-local >>>traffic. This will generally require the use of some type of split DNS, >>>with ULAs returned internally but not externally. >> >>(3) Although you made changes based on my comments on section 4.1, bullet >>3, >>you have not completely addressed by comment. We are essentially >>declaring >>that something will not be a problem if the IIDs are randomly distributed >>while ignoring the fact that they won't be. If we are trying to indicate >>that administrators should override the default mechanisms for IID >>autoconfiguration to provide random IIDs, I guess we should say that. >>Otherwise, we should understand that the IIDs will not be randomly >>distributed, so the math later in this section does not apply. >> >>(4) Section 4.6 has been updated based on discussion, but it now says: >> >> IPv6 provides sufficient space to completely avoid the need for >> overlapping address space with the total possible addresses being >> 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38). >> Since allocations in IPv6 are based on subnets rather than hosts a >> more reasonable way to look at the pool is that there are about >> 17,293,822,569,102,704,640 (17*10^18) unique subnet values where >> sparse allocation practice within those provdes for new opportunities >> such as . >> >>The last sentence above is apparently truncated. >> >>(5) I still don't see any justification for this statement: >> >> >>> o On a local network, any user will have more security awareness. >>> >>>IPv6 will make users more security-aware? What does this mean? > > > From owner-v6ops@ops.ietf.org Mon Jul 03 13:04:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRr0-0008QR-OO for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 13:04:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxRqv-0003ev-CT for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 13:04:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxRol-0006lY-QK for v6ops-data@psg.com; Mon, 03 Jul 2006 17:02:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [207.134.166.247] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxRol-0006iX-3A for v6ops@ops.ietf.org; Mon, 03 Jul 2006 17:02:39 +0000 Received: from [192.168.1.101] (modemcable011.117-80-70.mc.videotron.ca [70.80.117.11]) by jazz.viagenie.qc.ca (Postfix) with ESMTP id C8F6D37AE04; Mon, 3 Jul 2006 13:02:37 -0400 (EDT) In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: Marla Azinger , Pekka Savola Content-Transfer-Encoding: quoted-printable From: Marc Blanchet Subject: Re: v6 multihoming and route filters Date: Mon, 3 Jul 2006 13:02:32 -0400 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 with this draft-ietf-v6ops-routing-guidelines draft, we could: a) do not mention anything about maximum unicast prefix length b) mention that the very maximum unicast prefix length is /48, but =20 should be smaller and refer to right documents/policies c) go into debate on what would be the maximum prefix length, /47, /=20 46, /44, 40, /36, /32, /... first (personal) draft was b) and I still believe it is the best we =20 can do for now than don't say anything like a). if ARIN policy is =20 implemented as it seems to be, we will end up with b). b) does not =20 harm anyone, it is just stating the bare minimum. so to me, b) should be back in the draft. Marc. Le 06-06-29 =E0 00:45, Pekka Savola a =E9crit : > On Wed, 28 Jun 2006, Azinger, Marla wrote: >> I ask the V6 WG to create a "best practice for multihoming" that =20 >> can be utilized today. I ask that you please insert the solution =20 >> to filter at /48 thus allowing "upstream providers" to provide =20 >> multihoming to their customers. This solution is needed to =20 >> support providers creating V6 networks and this solution can =20 >> easily be added into Marc's "IP V6 Routing Policy Guidelines" =20 >> document. > > This is unlikely to get traction in the WG. The initial draft was =20 > basically like that but was changed. Many people (myself included) =20 > opposed (and will oppose) recommeding opening filters up to /48. > > Let's not create a swamp out of v6 address space with more specific =20= > junk. > > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca From owner-v6ops@ops.ietf.org Mon Jul 03 14:43:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxTOW-00022M-OH for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 14:43:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxTOV-0006gH-De for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 14:43:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxTMi-0009P8-4v for v6ops-data@psg.com; Mon, 03 Jul 2006 18:41:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [66.117.32.22] (helo=srv013.carpathiahost.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxTMh-0009Ov-FH for v6ops@ops.ietf.org; Mon, 03 Jul 2006 18:41:47 +0000 Received: from [66.117.52.85] (unknown [66.117.52.85]) by srv013.carpathiahost.net (Postfix) with ESMTP id E61259337F for ; Mon, 3 Jul 2006 14:41:46 -0400 (EDT) Message-ID: <44A965FC.4090700@hotnic.net> Date: Mon, 03 Jul 2006 14:46:20 -0400 From: Kevin Loch User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Marc Blanchet wrote: > with this draft-ietf-v6ops-routing-guidelines draft, we could: > a) do not mention anything about maximum unicast prefix length > b) mention that the very maximum unicast prefix length is /48, but > should be smaller and refer to right documents/policies > c) go into debate on what would be the maximum prefix length, /47, /46, > /44, 40, /36, /32, /... > > first (personal) draft was b) and I still believe it is the best we can > do for now than don't say anything like a). if ARIN policy is > implemented as it seems to be, we will end up with b). b) does not harm > anyone, it is just stating the bare minimum. There are already direct /48 assignments for critical infrastructure so ARIN PI /48's will not be the first, but it may get confusing if different RIR's make RIR assignments in an ad hoc manner. Hopefully the RIR's and IANA will set use space from a designated /16 for any PI end site assignments they make to simplify filtering to make is more idiot-resistant. Perhaps a draft should be written to recommend this. Sure, a /16 is much more space than is needed but most of it would remain reserved as it is today. It might also be desirable to use space from this /16 the future for non-BGP PI solutions that involve making assignments. On the subject of route filtering, it's not a simple as "here is the limit, this is ok and this is not". There are different consequences for prefixes accepted vs those originated or readvertised. Here is a possible filtering recommendation which uses the "be conservative in what you send but liberal in what you accept" philosophy and covers the various situations: Received: - Routes from customers: Operators may accept any prefixes from customers, if the prefixes (or parent) are delegated to the customer. - Routes from peers/transit: Operators may accept any prefixes from peers/transit they want, and may reject any prefixes they don't want. it is recommend they not accept prefixes longer than /48. Announced: - Routes originated by an ASN: Operators should whenever practical minimize the number of prefixes they originate, ideally only the exact prefixes delegated by an RIR. Steps must be taken to prevent unintentional origination of more specifics. - Routes originated by an ASN and announced to an upstream provider: Prefixes of any length may be advertised to an upstream but steps should be taken by one or both parties to prevent prefixes longer than /48 or unintentional deaggregates from being readvertised. - Routes readvertised by an ASN: Operators should (must?) not readvertise any prefix longer than /48. - Kevin From owner-v6ops@ops.ietf.org Mon Jul 03 17:27:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVxI-0004Qs-OX for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 17:27:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxVxH-00089w-B5 for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 17:27:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxVue-000IxX-My for v6ops-data@psg.com; Mon, 03 Jul 2006 21:25:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [64.233.182.190] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxVud-000Ix3-RM for v6ops@ops.ietf.org; Mon, 03 Jul 2006 21:25:00 +0000 Received: by nf-out-0910.google.com with SMTP id x37so968959nfc for ; Mon, 03 Jul 2006 14:24:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KSxvHyNcj5Cs6r6DRL9QnYHTwaTQkVqrrRuRZ+mQj8aOAyqKbdAGak4t8nuJNRT+aQbtYtljjqcsgNSD9Ki/ScPViW44TdHjo8l3zLkjXK3QSuVIMfjI2R3HzSLajd5emXRkLgBn26hHDiQF+5y9NbG7l/EsYn85E3o1FumafHc= Received: by 10.49.93.8 with SMTP id v8mr2729799nfl; Mon, 03 Jul 2006 14:24:58 -0700 (PDT) Received: by 10.48.254.12 with HTTP; Mon, 3 Jul 2006 14:24:58 -0700 (PDT) Message-ID: <1c16a4870607031424j191207a3kfb2ddc4e7e81c181@mail.gmail.com> Date: Mon, 3 Jul 2006 14:24:58 -0700 From: "Stacy Taylor" To: "Kevin Loch" Subject: Re: v6 multihoming and route filters Cc: v6ops@ops.ietf.org In-Reply-To: <44A965FC.4090700@hotnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi Kevin, ARIN Policy Proposal 2005-1 does indeed include this: "These assignments shall be made from a distinctly identified prefix." It does not specify they size of the PI pool, though. To be clear, are you suggesting a /16 be reserved by the IANA for this purpose? Or do you see each region deciding on the size of its own pool? As a point of reference, ARIN and AfriNIC are the only two regions with end site PI allocation policies at this time. Cheers, /Stacy On 7/3/06, Kevin Loch wrote: > Marc Blanchet wrote: > > with this draft-ietf-v6ops-routing-guidelines draft, we could: > > a) do not mention anything about maximum unicast prefix length > > b) mention that the very maximum unicast prefix length is /48, but > > should be smaller and refer to right documents/policies > > c) go into debate on what would be the maximum prefix length, /47, /46, > > /44, 40, /36, /32, /... > > > > first (personal) draft was b) and I still believe it is the best we can > > do for now than don't say anything like a). if ARIN policy is > > implemented as it seems to be, we will end up with b). b) does not harm > > anyone, it is just stating the bare minimum. > > There are already direct /48 assignments for critical infrastructure so > ARIN PI /48's will not be the first, but it may get confusing if > different RIR's make RIR assignments in an ad hoc manner. > > Hopefully the RIR's and IANA will set use space from a designated /16 > for any PI end site assignments they make to simplify filtering to make > is more idiot-resistant. Perhaps a draft should be written to recommend > this. Sure, a /16 is much more space than is needed but most of it would > remain reserved as it is today. It might also be desirable to use space > from this /16 the future for non-BGP PI solutions that involve making > assignments. > > On the subject of route filtering, it's not a simple as "here is the > limit, this is ok and this is not". There are different consequences > for prefixes accepted vs those originated or readvertised. > > Here is a possible filtering recommendation which uses the > "be conservative in what you send but liberal in what you accept" > philosophy and covers the various situations: > > Received: > - Routes from customers: Operators may accept any prefixes from > customers, if the prefixes (or parent) are delegated to the customer. > - Routes from peers/transit: Operators may accept any prefixes from > peers/transit they want, and may reject any prefixes they don't want. > it is recommend they not accept prefixes longer than /48. > > Announced: > - Routes originated by an ASN: Operators should whenever practical > minimize the number of prefixes they originate, ideally only the exact > prefixes delegated by an RIR. Steps must be taken to prevent > unintentional origination of more specifics. > - Routes originated by an ASN and announced to an upstream provider: > Prefixes of any length may be advertised to an upstream but steps > should be taken by one or both parties to prevent prefixes longer than > /48 or unintentional deaggregates from being readvertised. > - Routes readvertised by an ASN: Operators should (must?) not > readvertise any prefix longer than /48. > > - Kevin > > From owner-v6ops@ops.ietf.org Mon Jul 03 17:40:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxW9s-00053n-CR for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 17:40:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxW9p-0000ZQ-JC for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 17:40:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxW9L-000Nqm-JX for v6ops-data@psg.com; Mon, 03 Jul 2006 21:40:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxW9K-000NqX-L8 for v6ops@ops.ietf.org; Mon, 03 Jul 2006 21:40:10 +0000 Received: from [10.10.10.51] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001908536.msg for ; Mon, 03 Jul 2006 23:38:23 +0200 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 03 Jul 2006 23:40:00 +0200 Subject: Re: v6 multihoming and route filters From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: v6 multihoming and route filters Thread-Index: Acae6Twgenxl4wrcEduf5QANky3PwA== In-Reply-To: <1c16a4870607031424j191207a3kfb2ddc4e7e81c181@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060703:v6ops@ops.ietf.org::uNhCEXI2/DKeZEkz:000000000000000000000000000000000000000000001Fq X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 03 Jul 2006 23:38:27 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Hi Stacy, I guess something has been confused here ... AfriNIC has not IPv6 PI allocation policy in place, there is a proposal, which I've submitted (as I did in APNIC, LACNIC and RIPE NCC). They are all under discussion. I'm not really sure, in case the PI policies are accepted, in other regions, to use the same reserved prefix ... Regarding a previous email I've seen before, I've seen /48 assigned to critical infrastructures being filtered and tried to fix it with several (even big) telcos and didn't worked. That's why my proposal has been always if we go for this kind of PI policy, to use a /32. As an example, I know about someone having a /32 an announcing it as 2x/33 and being filtered one day after other ... Regards, Jordi > De: Stacy Taylor > Responder a: > Fecha: Mon, 3 Jul 2006 14:24:58 -0700 > Para: Kevin Loch > CC: > Asunto: Re: v6 multihoming and route filters > > Hi Kevin, > ARIN Policy Proposal 2005-1 does indeed include this: > "These assignments shall be made from a distinctly identified prefix." > It does not specify they size of the PI pool, though. To be clear, > are you suggesting a /16 be reserved by the IANA for this purpose? Or > do you see each region deciding on the size of its own pool? > As a point of reference, ARIN and AfriNIC are the only two regions > with end site PI allocation policies at this time. > Cheers, > /Stacy > > On 7/3/06, Kevin Loch wrote: >> Marc Blanchet wrote: >>> with this draft-ietf-v6ops-routing-guidelines draft, we could: >>> a) do not mention anything about maximum unicast prefix length >>> b) mention that the very maximum unicast prefix length is /48, but >>> should be smaller and refer to right documents/policies >>> c) go into debate on what would be the maximum prefix length, /47, /46, >>> /44, 40, /36, /32, /... >>> >>> first (personal) draft was b) and I still believe it is the best we can >>> do for now than don't say anything like a). if ARIN policy is >>> implemented as it seems to be, we will end up with b). b) does not harm >>> anyone, it is just stating the bare minimum. >> >> There are already direct /48 assignments for critical infrastructure so >> ARIN PI /48's will not be the first, but it may get confusing if >> different RIR's make RIR assignments in an ad hoc manner. >> >> Hopefully the RIR's and IANA will set use space from a designated /16 >> for any PI end site assignments they make to simplify filtering to make >> is more idiot-resistant. Perhaps a draft should be written to recommend >> this. Sure, a /16 is much more space than is needed but most of it would >> remain reserved as it is today. It might also be desirable to use space >> from this /16 the future for non-BGP PI solutions that involve making >> assignments. >> >> On the subject of route filtering, it's not a simple as "here is the >> limit, this is ok and this is not". There are different consequences >> for prefixes accepted vs those originated or readvertised. >> >> Here is a possible filtering recommendation which uses the >> "be conservative in what you send but liberal in what you accept" >> philosophy and covers the various situations: >> >> Received: >> - Routes from customers: Operators may accept any prefixes from >> customers, if the prefixes (or parent) are delegated to the customer. >> - Routes from peers/transit: Operators may accept any prefixes from >> peers/transit they want, and may reject any prefixes they don't want. >> it is recommend they not accept prefixes longer than /48. >> >> Announced: >> - Routes originated by an ASN: Operators should whenever practical >> minimize the number of prefixes they originate, ideally only the exact >> prefixes delegated by an RIR. Steps must be taken to prevent >> unintentional origination of more specifics. >> - Routes originated by an ASN and announced to an upstream provider: >> Prefixes of any length may be advertised to an upstream but steps >> should be taken by one or both parties to prevent prefixes longer than >> /48 or unintentional deaggregates from being readvertised. >> - Routes readvertised by an ASN: Operators should (must?) not >> readvertise any prefix longer than /48. >> >> - Kevin >> >> > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jul 03 20:07:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYRx-0003qn-2E for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 20:07:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYRv-0005pE-Ji for v6ops-archive@lists.ietf.org; Mon, 03 Jul 2006 20:07:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxYPh-000Ckl-B0 for v6ops-data@psg.com; Tue, 04 Jul 2006 00:05:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [64.233.182.184] (helo=nf-out-0910.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxYPg-000CkH-37 for v6ops@ops.ietf.org; Tue, 04 Jul 2006 00:05:12 +0000 Received: by nf-out-0910.google.com with SMTP id x37so1010818nfc for ; Mon, 03 Jul 2006 17:05:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BNnGtbvMtPZnEAkLY5WgVqK8qpHuG6BP3hkeOBMuo6OrQXeVxGNg53mTltqhfq0isrxPvZjrXlceQCigzJWbTGMek0v2rSh9Mxj9mUzpYNFhZH4GdrrSrPWHbjUxGdcU2kMcpm7Ob+MdtAm0fBPSWEql7NsQ4CJAMLyb0iMzb9I= Received: by 10.48.246.6 with SMTP id t6mr2832262nfh; Mon, 03 Jul 2006 17:05:10 -0700 (PDT) Received: by 10.48.254.12 with HTTP; Mon, 3 Jul 2006 17:05:10 -0700 (PDT) Message-ID: <1c16a4870607031705l3d84da73l782ab6393887f903@mail.gmail.com> Date: Mon, 3 Jul 2006 17:05:10 -0700 From: "Stacy Taylor" To: jordi.palet@consulintel.es Subject: Re: v6 multihoming and route filters Cc: v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1c16a4870607031424j191207a3kfb2ddc4e7e81c181@mail.gmail.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Hi Jordi! Of course you are on top of it! Would you be so kind as to update this list with events in the policy proposal cycles? I feel it's very germane to our discussion. I'll be happy to continue with ARIN region stuff if you'd like. Thanks, /Stacy On 7/3/06, JORDI PALET MARTINEZ wrote: > Hi Stacy, > > I guess something has been confused here ... > > AfriNIC has not IPv6 PI allocation policy in place, there is a proposal, > which I've submitted (as I did in APNIC, LACNIC and RIPE NCC). They are all > under discussion. > > I'm not really sure, in case the PI policies are accepted, in other regions, > to use the same reserved prefix ... > > Regarding a previous email I've seen before, I've seen /48 assigned to > critical infrastructures being filtered and tried to fix it with several > (even big) telcos and didn't worked. That's why my proposal has been always > if we go for this kind of PI policy, to use a /32. > > As an example, I know about someone having a /32 an announcing it as 2x/33 > and being filtered one day after other ... > > Regards, > Jordi > > > > > > De: Stacy Taylor > > Responder a: > > Fecha: Mon, 3 Jul 2006 14:24:58 -0700 > > Para: Kevin Loch > > CC: > > Asunto: Re: v6 multihoming and route filters > > > > Hi Kevin, > > ARIN Policy Proposal 2005-1 does indeed include this: > > "These assignments shall be made from a distinctly identified prefix." > > It does not specify they size of the PI pool, though. To be clear, > > are you suggesting a /16 be reserved by the IANA for this purpose? Or > > do you see each region deciding on the size of its own pool? > > As a point of reference, ARIN and AfriNIC are the only two regions > > with end site PI allocation policies at this time. > > Cheers, > > /Stacy > > > > On 7/3/06, Kevin Loch wrote: > >> Marc Blanchet wrote: > >>> with this draft-ietf-v6ops-routing-guidelines draft, we could: > >>> a) do not mention anything about maximum unicast prefix length > >>> b) mention that the very maximum unicast prefix length is /48, but > >>> should be smaller and refer to right documents/policies > >>> c) go into debate on what would be the maximum prefix length, /47, /46, > >>> /44, 40, /36, /32, /... > >>> > >>> first (personal) draft was b) and I still believe it is the best we can > >>> do for now than don't say anything like a). if ARIN policy is > >>> implemented as it seems to be, we will end up with b). b) does not harm > >>> anyone, it is just stating the bare minimum. > >> > >> There are already direct /48 assignments for critical infrastructure so > >> ARIN PI /48's will not be the first, but it may get confusing if > >> different RIR's make RIR assignments in an ad hoc manner. > >> > >> Hopefully the RIR's and IANA will set use space from a designated /16 > >> for any PI end site assignments they make to simplify filtering to make > >> is more idiot-resistant. Perhaps a draft should be written to recommend > >> this. Sure, a /16 is much more space than is needed but most of it would > >> remain reserved as it is today. It might also be desirable to use space > >> from this /16 the future for non-BGP PI solutions that involve making > >> assignments. > >> > >> On the subject of route filtering, it's not a simple as "here is the > >> limit, this is ok and this is not". There are different consequences > >> for prefixes accepted vs those originated or readvertised. > >> > >> Here is a possible filtering recommendation which uses the > >> "be conservative in what you send but liberal in what you accept" > >> philosophy and covers the various situations: > >> > >> Received: > >> - Routes from customers: Operators may accept any prefixes from > >> customers, if the prefixes (or parent) are delegated to the customer. > >> - Routes from peers/transit: Operators may accept any prefixes from > >> peers/transit they want, and may reject any prefixes they don't want. > >> it is recommend they not accept prefixes longer than /48. > >> > >> Announced: > >> - Routes originated by an ASN: Operators should whenever practical > >> minimize the number of prefixes they originate, ideally only the exact > >> prefixes delegated by an RIR. Steps must be taken to prevent > >> unintentional origination of more specifics. > >> - Routes originated by an ASN and announced to an upstream provider: > >> Prefixes of any length may be advertised to an upstream but steps > >> should be taken by one or both parties to prevent prefixes longer than > >> /48 or unintentional deaggregates from being readvertised. > >> - Routes readvertised by an ASN: Operators should (must?) not > >> readvertise any prefix longer than /48. > >> > >> - Kevin > >> > >> > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > From owner-v6ops@ops.ietf.org Tue Jul 04 15:40:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxqlP-0007XX-AY for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 15:40:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxqlM-000406-VT for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 15:40:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxqh5-000Jd7-44 for v6ops-data@psg.com; Tue, 04 Jul 2006 19:36:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=3.1.1 Received: from [207.134.166.247] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxqh4-000Jcu-Fx for v6ops@ops.ietf.org; Tue, 04 Jul 2006 19:36:22 +0000 Received: from [192.168.126.223] (modemcable190.170-203-24.mc.videotron.ca [24.203.170.190]) by jazz.viagenie.qc.ca (Postfix) with ESMTP id 4067737AE04; Tue, 4 Jul 2006 15:36:21 -0400 (EDT) In-Reply-To: <44A965FC.4090700@hotnic.net> References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: Marc Blanchet Subject: Re: v6 multihoming and route filters Date: Tue, 4 Jul 2006 07:48:37 -0400 To: Kevin Loch X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Le 06-07-03 =E0 14:46, Kevin Loch a =E9crit : > > On the subject of route filtering, it's not a simple as "here is the > limit, this is ok and this is not". There are different consequences > for prefixes accepted vs those originated or readvertised. sure, that is the whole idea of the draft. > > Here is a possible filtering recommendation which uses the > "be conservative in what you send but liberal in what you accept" > philosophy and covers the various situations: ok. I agree in principle on what you wrote below. I see from your =20 contributed text below two concepts: a) "generic"/well-known filtering recommendations (applicable to v4 too) b) specific to ipv6 around "no longer than /48" I was not going too much around a) because a) is covered elsewhere. What is on debate is b). And again, b) is what I'm proposing since =20 the first (personal) version of the draft: - filter/do not advertise any prefix longer than /48. If we agree on this (filter/do not advertise any prefix longer than /=20 48), than I'll put it back into the draft! Marc. > > Received: > - Routes from customers: Operators may accept any prefixes from > customers, if the prefixes (or parent) are delegated to the =20 > customer. > - Routes from peers/transit: Operators may accept any prefixes from > peers/transit they want, and may reject any prefixes they don't =20 > want. > it is recommend they not accept prefixes longer than /48. > > Announced: > - Routes originated by an ASN: Operators should whenever practical > minimize the number of prefixes they originate, ideally only the =20 > exact > prefixes delegated by an RIR. Steps must be taken to prevent > unintentional origination of more specifics. > - Routes originated by an ASN and announced to an upstream provider: > Prefixes of any length may be advertised to an upstream but steps > should be taken by one or both parties to prevent prefixes longer =20= > than > /48 or unintentional deaggregates from being readvertised. > - Routes readvertised by an ASN: Operators should (must?) not > readvertise any prefix longer than /48. > > - Kevin =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca From owner-v6ops@ops.ietf.org Tue Jul 04 17:02:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxs1x-0005lg-7d for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 17:02:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxs1u-0003d1-QU for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 17:02:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxs04-00007y-2g for v6ops-data@psg.com; Tue, 04 Jul 2006 21:00:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxs03-000068-8i for v6ops@ops.ietf.org; Tue, 04 Jul 2006 21:00:03 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k64KxtEV089880 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 4 Jul 2006 22:59:55 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Tue, 4 Jul 2006 22:59:56 +0200 To: Marc Blanchet X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 On 4-jul-2006, at 13:48, Marc Blanchet wrote: > And again, b) is what I'm proposing since the first (personal) > version of the draft: > - filter/do not advertise any prefix longer than /48. > If we agree on this (filter/do not advertise any prefix longer > than /48), than I'll put it back into the draft! What would be the purpose of filtering at /48? That allows for 2^45 = 351 trillion prefixes in the routing table, which I suspect won't work too well on current routers. And it only takes a handful of /32s deaggregated into /48s to inflate the IPv6 global routing table to a size larger than the current IPv4 routing table. So filtering at /48 really doesn't buy you anything, either you don't care and/or you have large routers and then prefixes longer than /48 won't make much of a difference, or you care and/or you have small routers and then /48 is too much already. And in theory, anycast addresses should be announced into inter- domain routing (when the anycast group spans ASes) as /128s... Or maybe that one has been removed in an update of the RFC in question, not sure. By the way: mysql> select count(*) from addrspace where type='ipv6' and num > 35; +----------+ | count(*) | +----------+ | 137 | +----------+ mysql> select country, descr as prefix, num as pfxlen from addrspace where type='ipv6' and num > 35 and not descr like "2001:7f8:%" and not descr like "2001:504:%" and not descr like "2001:503:%"; +---------+------------------+--------+ | country | prefix | pfxlen | +---------+------------------+--------+ | JP | 2001:7fa:: | 64 | | HK | 2001:7fa:0:1:: | 64 | | KR | 2001:7fa:0:2:: | 64 | | JP | 2001:7fa:0:3:: | 64 | | TW | 2001:7fa:1:: | 48 | | ID | 2001:7fa:2:: | 48 | | NZ | 2001:7fa:3:: | 48 | | NZ | 2001:7fa:4:: | 48 | | CN | 2001:7fa:5:: | 48 | | VN | 2001:7fa:6:: | 48 | | JP | 2001:7fa:7:: | 48 | | KR | 2001:7fa:8:: | 48 | | AU | 2001:7fa:9:: | 48 | | AU | 2001:7fa:a:: | 48 | | AU | 2001:7fa:b:: | 48 | | AU | 2001:7fa:c:: | 48 | | AU | 2001:7fa:d:: | 48 | | AU | 2001:7fa:e:: | 48 | | ID | 2001:7fa:f:: | 48 | | CN | 2001:7fa:10:: | 48 | | US | 2001:500:: | 48 | | US | 2001:500:1:: | 48 | | US | 2001:500:2:: | 48 | | US | 2001:500:3:: | 48 | | US | 2001:500:4:: | 48 | | US | 2001:502:100e:: | 48 | | US | 2001:502:2eda:: | 48 | | US | 2001:502:4612:: | 48 | | US | 2001:502:7a71:: | 48 | | US | 2001:502:ad09:: | 48 | | US | 2001:502:cfb5:: | 48 | | US | 2001:502:d399:: | 48 | | US | 2001:502:f3ff:: | 48 | | BR | 2001:12f8:: | 48 | | AR | 2001:12f8:1:: | 48 | | CO | 2001:12f8:2:: | 48 | | MX | 2001:12f8:4000:: | 48 | +---------+------------------+--------+ 37 rows in set (0.16 sec) > ========= > IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca Mine is published by Apress, see http://www.runningipv6.net/ :-) From owner-v6ops@ops.ietf.org Tue Jul 04 19:07:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxtzT-0007je-LW for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 19:07:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxtzS-000693-6S for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 19:07:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxtwr-000ARg-EN for v6ops-data@psg.com; Tue, 04 Jul 2006 23:04:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [207.134.166.247] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxtwq-000ART-Je for v6ops@ops.ietf.org; Tue, 04 Jul 2006 23:04:52 +0000 Received: from [192.168.1.101] (modemcable011.117-80-70.mc.videotron.ca [70.80.117.11]) by jazz.viagenie.qc.ca (Postfix) with ESMTP id BC88637AE04; Tue, 4 Jul 2006 19:04:51 -0400 (EDT) In-Reply-To: <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: Marc Blanchet Subject: Re: v6 multihoming and route filters Date: Tue, 4 Jul 2006 19:04:45 -0400 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Le 06-07-04 =E0 16:59, Iljitsch van Beijnum a =E9crit : > On 4-jul-2006, at 13:48, Marc Blanchet wrote: > >> And again, b) is what I'm proposing since the first (personal) =20 >> version of the draft: >> - filter/do not advertise any prefix longer than /48. > >> If we agree on this (filter/do not advertise any prefix longer =20 >> than /48), than I'll put it back into the draft! > > What would be the purpose of filtering at /48? - simple: through out anything longer: so /64, /56 will be filtered. =20 end of it. > > That allows for 2^45 =3D 351 trillion prefixes in the routing table, =20= > which I suspect won't work too well on current routers. And it only =20= > takes a handful of /32s deaggregated into /48s to inflate the IPv6 =20 > global routing table to a size larger than the current IPv4 routing =20= > table. the fact that I'm suggesting to filter at the /48 level is just that =20 I don't know how to build a concensus right now on another more =20 restrictive boundary. for the global routing table perspective, I =20 would love to recommend /32 or smaller, but I'm not sure we can get =20 that agreement. have you read the first version of the draft (draft-blanchet-v6ops-=20 ipv6-routing-guidelines-00.txt? > > So filtering at /48 really doesn't buy you anything, yes, see above: filtering any /56 or /64 or /127 or ... Is my point clearer? Marc. > either you don't care and/or you have large routers and then =20 > prefixes longer than /48 won't make much of a difference, or you =20 > care and/or you have small routers and then /48 is too much already. > > And in theory, anycast addresses should be announced into inter-=20 > domain routing (when the anycast group spans ASes) as /128s... Or =20 > maybe that one has been removed in an update of the RFC in =20 > question, not sure. > > By the way: > > mysql> select count(*) from addrspace where type=3D'ipv6' and num > = 35; > +----------+ > | count(*) | > +----------+ > | 137 | > +----------+ > > mysql> select country, descr as prefix, num as pfxlen from =20 > addrspace where type=3D'ipv6' and num > 35 and not descr like =20 > "2001:7f8:%" and not descr like "2001:504:%" and not descr like =20 > "2001:503:%"; > +---------+------------------+--------+ > | country | prefix | pfxlen | > +---------+------------------+--------+ > | JP | 2001:7fa:: | 64 | > | HK | 2001:7fa:0:1:: | 64 | > | KR | 2001:7fa:0:2:: | 64 | > | JP | 2001:7fa:0:3:: | 64 | > | TW | 2001:7fa:1:: | 48 | > | ID | 2001:7fa:2:: | 48 | > | NZ | 2001:7fa:3:: | 48 | > | NZ | 2001:7fa:4:: | 48 | > | CN | 2001:7fa:5:: | 48 | > | VN | 2001:7fa:6:: | 48 | > | JP | 2001:7fa:7:: | 48 | > | KR | 2001:7fa:8:: | 48 | > | AU | 2001:7fa:9:: | 48 | > | AU | 2001:7fa:a:: | 48 | > | AU | 2001:7fa:b:: | 48 | > | AU | 2001:7fa:c:: | 48 | > | AU | 2001:7fa:d:: | 48 | > | AU | 2001:7fa:e:: | 48 | > | ID | 2001:7fa:f:: | 48 | > | CN | 2001:7fa:10:: | 48 | > | US | 2001:500:: | 48 | > | US | 2001:500:1:: | 48 | > | US | 2001:500:2:: | 48 | > | US | 2001:500:3:: | 48 | > | US | 2001:500:4:: | 48 | > | US | 2001:502:100e:: | 48 | > | US | 2001:502:2eda:: | 48 | > | US | 2001:502:4612:: | 48 | > | US | 2001:502:7a71:: | 48 | > | US | 2001:502:ad09:: | 48 | > | US | 2001:502:cfb5:: | 48 | > | US | 2001:502:d399:: | 48 | > | US | 2001:502:f3ff:: | 48 | > | BR | 2001:12f8:: | 48 | > | AR | 2001:12f8:1:: | 48 | > | CO | 2001:12f8:2:: | 48 | > | MX | 2001:12f8:4000:: | 48 | > +---------+------------------+--------+ > 37 rows in set (0.16 sec) > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca > > Mine is published by Apress, see http://www.runningipv6.net/ :-) > =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca From owner-v6ops@ops.ietf.org Tue Jul 04 19:36:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxuRr-0002UR-Bn for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 19:36:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxuRq-0007Ea-0j for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 19:36:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxuRI-000DAX-Lf for v6ops-data@psg.com; Tue, 04 Jul 2006 23:36:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxuRH-000DAJ-Td for v6ops@ops.ietf.org; Tue, 04 Jul 2006 23:36:20 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k64NaCtD092205 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jul 2006 01:36:12 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <013CBD1A-79BA-4A37-9E26-4FEE002F43D1@muada.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Wed, 5 Jul 2006 01:36:14 +0200 To: Marc Blanchet X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On 5-jul-2006, at 1:04, Marc Blanchet wrote: >> What would be the purpose of filtering at /48? > - simple: through out anything longer: so /64, /56 will be > filtered. end of it. Sure, but why is that a good thing? > the fact that I'm suggesting to filter at the /48 level is just > that I don't know how to build a concensus right now on another > more restrictive boundary. for the global routing table > perspective, I would love to recommend /32 or smaller, but I'm not > sure we can get that agreement. Well, if you look at: http://www.arin.net/policy/nrpm.html#ipv6 You'll see: 6.4.3. Minimum Allocation RIRs will apply a minimum size for IPv6 allocations, to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32. So this should be a no-brainer... I don't think it's a good idea for the IETF to publish a document with recommendations unless those recommendations are clearly a good idea to follow today, and for some years to come. Once an RFC is published, it never goes away, so we should be careful about putting stuff in there that is likely to be outdated within the forseeable future. > have you read the first version of the draft (draft-blanchet-v6ops- > ipv6-routing-guidelines-00.txt? http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-ipv6-routing- guidelines-00.txt doesn't seem to exist. >>> ========= >>> IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca >> Mine is published by Apress, see http://www.runningipv6.net/ :-) From owner-v6ops@ops.ietf.org Tue Jul 04 21:15:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxvz1-0006uR-4l for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 21:15:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxvyz-0004eP-P6 for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 21:15:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxvwg-000LWO-IS for v6ops-data@psg.com; Wed, 05 Jul 2006 01:12:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [131.107.1.8] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fxvwg-000LWC-3C for v6ops@ops.ietf.org; Wed, 05 Jul 2006 01:12:50 +0000 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Tue, 4 Jul 2006 18:12:49 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 18:12:48 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.69.169]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Jul 2006 18:12:48 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Tue, 4 Jul 2006 18:12:48 -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 Subject: RE: v6 multihoming and route filters Date: Tue, 4 Jul 2006 18:12:40 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters thread-index: AcafrXSF4VbVXK0ZRfakCION/HDXHwAISs8Q References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Marc Blanchet" Cc: X-OriginalArrivalTime: 05 Jul 2006 01:12:48.0296 (UTC) FILETIME=[210A1280:01C69FD0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 > What would be the purpose of filtering at /48? >=20 > That allows for 2^45 =3D 351 trillion prefixes in the routing table, > which I suspect won't work too well on current routers. And it only > takes a handful of /32s deaggregated into /48s to inflate the IPv6 > global routing table to a size larger than the current IPv4 routing > table. But then, filtering at /32 allows for 2^30 =3D 1 billion prefixes, which = I suspect also won't work too well on current routers. Setting filtering constraints at /32 is not sufficient to ensure small tables. Setting narrow filtering constraints is also counter-productive, as it encourage a rush on the short prefixes. An organization that could have done just fine with a /48 or maybe a /40 will request a /32 just in case, so that organization can eventually multi-home.=20 In the end, the size of the routing table will equal the number of entities that want multi-homing hard enough. Playing around with prefix sizes will not change that, and will probably generate undesirable counter effects. Besides, there are networks in which advertizing /48 or even /64 in BGP makes perfect sense. Take for example the "metropolitan aggregation" in which all users in an area get numbered from the same long prefix. The local ISP will have to exchange the short prefixes with each other. The will use BGP. Do we want to have a rule cast in stone that prevents them? We should really think twice before asking the IETF to publish a position on this subject. Silence may well be the right approach. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Jul 04 21:47:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxwUL-0007vc-OX for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 21:47:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxwUI-00019T-D1 for v6ops-archive@lists.ietf.org; Tue, 04 Jul 2006 21:47:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxwTT-000ORi-Cm for v6ops-data@psg.com; Wed, 05 Jul 2006 01:46:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [207.134.166.247] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxwTS-000ORW-Md for v6ops@ops.ietf.org; Wed, 05 Jul 2006 01:46:42 +0000 Received: from [192.168.1.101] (modemcable011.117-80-70.mc.videotron.ca [70.80.117.11]) by jazz.viagenie.qc.ca (Postfix) with ESMTP id E51F737AE04; Tue, 4 Jul 2006 21:46:41 -0400 (EDT) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2FC57BC4-9EA1-45D3-A6BC-0C84C56F4CCA@viagenie.ca> Cc: "Iljitsch van Beijnum" , Content-Transfer-Encoding: quoted-printable From: Marc Blanchet Subject: Re: v6 multihoming and route filters Date: Tue, 4 Jul 2006 21:46:33 -0400 To: "Christian Huitema" X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Le 06-07-04 =E0 21:12, Christian Huitema a =E9crit : >> What would be the purpose of filtering at /48? >> >> That allows for 2^45 =3D 351 trillion prefixes in the routing table, >> which I suspect won't work too well on current routers. And it only >> takes a handful of /32s deaggregated into /48s to inflate the IPv6 >> global routing table to a size larger than the current IPv4 routing >> table. > > But then, filtering at /32 allows for 2^30 =3D 1 billion prefixes, =20 > which I > suspect also won't work too well on current routers. Setting filtering > constraints at /32 is not sufficient to ensure small tables. yeap. > > Setting narrow filtering constraints is also counter-productive, as it > encourage a rush on the short prefixes. An organization that could =20 > have > done just fine with a /48 or maybe a /40 will request a /32 just in > case, so that organization can eventually multi-home. > > In the end, the size of the routing table will equal the number of > entities that want multi-homing hard enough. Playing around with =20 > prefix > sizes will not change that, and will probably generate undesirable > counter effects. > > Besides, there are networks in which advertizing /48 or even /64 in =20= > BGP > makes perfect sense. Take for example the "metropolitan =20 > aggregation" in > which all users in an area get numbered from the same long prefix. The > local ISP will have to exchange the short prefixes with each other. =20= > The > will use BGP. Do we want to have a rule cast in stone that prevents > them? fine. however, the "global routing table" should not see these. Hence =20= back to the minimal requirement to filter at least anything longer =20 than /48. > > We should really think twice before asking the IETF to publish a > position on this subject. Silence may well be the right approach. I think it is reasonable and good stewardship to define the longest =20 prefix possible in the global routing table (/48). Then anything =20 smaller is subject of policies and is probably more contentious to =20 write. Marc. > > -- Christian Huitema =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca From owner-v6ops@ops.ietf.org Wed Jul 05 00:58:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxzTS-0007LA-FU for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 00:58:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxzTP-0004XG-VY for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 00:58:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxzQZ-000Fz0-Cv for v6ops-data@psg.com; Wed, 05 Jul 2006 04:55:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FxzQY-000Fyk-KK for v6ops@ops.ietf.org; Wed, 05 Jul 2006 04:55:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k654tUZp019433; Wed, 5 Jul 2006 07:55:30 +0300 Date: Wed, 5 Jul 2006 07:55:30 +0300 (EEST) From: Pekka Savola To: Marc Blanchet cc: Christian Huitema , Iljitsch van Beijnum , v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters In-Reply-To: <2FC57BC4-9EA1-45D3-A6BC-0C84C56F4CCA@viagenie.ca> Message-ID: References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <2FC57BC4-9EA1-45D3-A6BC-0C84C56F4CCA@viagenie.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1585/Tue Jul 4 23:39:34 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Tue, 4 Jul 2006, Marc Blanchet wrote: >> We should really think twice before asking the IETF to publish a >> position on this subject. Silence may well be the right approach. > > I think it is reasonable and good stewardship to define the longest prefix > possible in the global routing table (/48). Then anything smaller is subject > of policies and is probably more contentious to write. Stewardship of who? The IETF is not the steward of address allocations, so it has been rightfully argued that the IETF is not necessarily the steward of the operators of those allocations either. As there is no consensus on what this should include, the most the IETF could do (IMHO) is describe the tradeoffs of different filtering schemes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 05 06:00:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy4B4-0002lz-HS for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 06:00: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 1Fy2tK-0002YN-3k for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 04:37:50 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy2nE-0004a2-Cr for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 04:31:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fy2kJ-0009UU-U4 for v6ops-data@psg.com; Wed, 05 Jul 2006 08:28:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fy2kI-0009TK-Vs for v6ops@ops.ietf.org; Wed, 05 Jul 2006 08:28:31 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k658RvYP002001 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jul 2006 10:27:58 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Marc Blanchet" , Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Wed, 5 Jul 2006 10:28:01 +0200 To: Christian Huitema X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -1.5 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 On 5-jul-2006, at 3:12, Christian Huitema wrote: >> What would be the purpose of filtering at /48? >> That allows for 2^45 = 351 trillion prefixes in the routing table, >> which I suspect won't work too well on current routers. And it only >> takes a handful of /32s deaggregated into /48s to inflate the IPv6 >> global routing table to a size larger than the current IPv4 routing >> table. > But then, filtering at /32 allows for 2^30 = 1 billion prefixes, > which I > suspect also won't work too well on current routers. Yes, that's true. But a billion is still a lot closer to something reasonable than another nearly six orders of magnitude. And the crucial difference is that there is little chance of the the full ::/ 3 space being deaggregated into individual /32s, while leaking of significant numbers of "private" /48s into the global routing table is something I fully expect to happen based on experiences with IPv4. > Setting narrow filtering constraints is also counter-productive, as it > encourage a rush on the short prefixes. An organization that could > have > done just fine with a /48 or maybe a /40 will request a /32 just in > case, so that organization can eventually multi-home. This assumes that people will get anything they request. Currently, you can't really get a /40: ISPs get /32 or shorter, end-users rarely get something shorter than /48. > In the end, the size of the routing table will equal the number of > entities that want multi-homing hard enough. Playing around with > prefix > sizes will not change that, and will probably generate undesirable > counter effects. > Besides, there are networks in which advertizing /48 or even /64 in > BGP > makes perfect sense. Take for example the "metropolitan > aggregation" in > which all users in an area get numbered from the same long prefix. The > local ISP will have to exchange the short prefixes with each other. > The > will use BGP. Do we want to have a rule cast in stone that prevents > them? > We should really think twice before asking the IETF to publish a > position on this subject. Silence may well be the right approach. On the other hand, no filtering at all is asking for trouble, so it would make sense for us to come up with a good filtering strategy. One would be to make a filter based on actual allocations, which is still possible in IPv6 today because of the small size of the global table. Another approach is to filter on prefix size depending on the size of the prefixes RIRs give out in a certain part of the address space. (Possibly allowing one or two extra bits for traffic engineering purposes.) I think this is the best way to do it currently, but the problem is that the RIRs are still coming up with new stuff here so if we write this up it's likely that the list of parts of the address space where /48s are given out will change soon after, so the resulting document won't be all that useful in practice. (I'm also VERY much annoyed by the fact that the RIRs say you can filter on /32 (see quote yesterday) but give out /48s at the same time, I've brought this up YEARS ago and no action so far. The fact that each RIR reinvents the wheel with little global coordination but we're dealing with a GLOBAL routing table and not several regional ones doesn't help.) Third approach: use prefixes shorter than /48 for anything that should be in the routing table and then filter at /47. This avoids problems with accidental leaking of /48s from internal routing, but the ship has sailed on /48 for "micro allocations" so this approach would have to be combined with the previous one. Finally, it would be possible to tag prefixes longer than /32 that are injected into global routing intentionally, especially in the case of shorter prefixes that are drawn from a larger address block for multihoming purposes, with a BGP community that indicates why this is done so that people can filter appropriately. For instance, as a network operator I may want to allow such prefixes from "close by" but not from other continents, so that there is a more or less dynamic tradeoff between routing table size and optimum traffic flow through the network, which is really what we want. (With PI you're forced to carry the route or the destination is unreachable, not a very nice choice.) From owner-v6ops@ops.ietf.org Wed Jul 05 11:48:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9bz-0006m8-GV for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 11:48:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9by-0006QU-4O for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 11:48:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fy9Za-000MXp-9r for v6ops-data@psg.com; Wed, 05 Jul 2006 15:45:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [66.133.172.21] (helo=frontiercorp.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fy9ZZ-000MXU-KF for v6ops@ops.ietf.org; Wed, 05 Jul 2006 15:45:53 +0000 Received: from ([172.27.14.137]) by mail04.frontiercorp.com with ESMTP id 4028772.73816704; Wed, 05 Jul 2006 11:16:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v6 multihoming and route filters Date: Wed, 5 Jul 2006 08:45:15 -0700 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D6A@wava00s2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters Thread-Index: Acaf8bbbVPRh4mBlRjCfbtBL/u2uQAAV1ksg From: "Azinger, Marla" To: "Pekka Savola" , "Marc Blanchet" Cc: "Christian Huitema" , "Iljitsch van Beijnum" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Correct the IETF isn't the steward of address allocation. And that is = not what we are attempting to do with writing a Best = Practice/Recommended Routing Procedure. However, IETF is the steward of = good routing principles. If IETF sets a good set of principles on = routing then Policy in RIR's can and should adjust policy allocation to = reflect the suggested good routing principles. Marla Azinger Frontier Communications -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Pekka Savola Sent: Tuesday, July 04, 2006 9:56 PM To: Marc Blanchet Cc: Christian Huitema; Iljitsch van Beijnum; v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters On Tue, 4 Jul 2006, Marc Blanchet wrote: >> We should really think twice before asking the IETF to publish a=20 >> position on this subject. Silence may well be the right approach. > > I think it is reasonable and good stewardship to define the longest = prefix=20 > possible in the global routing table (/48). Then anything smaller is = subject=20 > of policies and is probably more contentious to write. Stewardship of who? The IETF is not the steward of address=20 allocations, so it has been rightfully argued that the IETF is not=20 necessarily the steward of the operators of those allocations either. As there is no consensus on what this should include, the most the=20 IETF could do (IMHO) is describe the tradeoffs of different filtering=20 schemes. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 05 12:03:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9ql-0006Zr-Sc for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:03:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9qk-0007ZW-JG for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:03:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fy9qC-000O5v-0U for v6ops-data@psg.com; Wed, 05 Jul 2006 16:03:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [66.133.172.21] (helo=frontiercorp.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fy9qB-000O5j-3a for v6ops@ops.ietf.org; Wed, 05 Jul 2006 16:03:03 +0000 Received: from ([172.27.14.137]) by mail04.frontiercorp.com with ESMTP id 4028772.73819244; Wed, 05 Jul 2006 11:33:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v6 multihoming and route filters Date: Wed, 5 Jul 2006 09:02:42 -0700 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters Thread-Index: AcafrXSF4VbVXK0ZRfakCION/HDXHwAISs8QAB8LgqA= From: "Azinger, Marla" To: "Christian Huitema" , "Iljitsch van Beijnum" , "Marc Blanchet" Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a I urge everyone to seriously consider that silence is not a good answer. = This internet community needs, wants and is asking for direction. = Whatever comes out of this discussion, verbalizing a plan (be it with = flaws or not) is better than no plan at all. Silence has been a large = part of this issue for some time now (with various internet conference = venues) and all this has done is create confusion and finger pointing = and thus total feeling of lost and confused routing for developing V6 = networks. =20 Also, correct me if I'm wrong...but I didn't think the global routing = table should be seeing the "metropolitan aggregation" setup. So /48 = filter shouldn't interfere with that kind of setup. Marla Azinger Frontier Communications -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Christian Huitema Sent: Tuesday, July 04, 2006 6:13 PM To: Iljitsch van Beijnum; Marc Blanchet Cc: v6ops@ops.ietf.org Subject: RE: v6 multihoming and route filters > What would be the purpose of filtering at /48? >=20 > That allows for 2^45 =3D 351 trillion prefixes in the routing table, > which I suspect won't work too well on current routers. And it only > takes a handful of /32s deaggregated into /48s to inflate the IPv6 > global routing table to a size larger than the current IPv4 routing > table. But then, filtering at /32 allows for 2^30 =3D 1 billion prefixes, which = I suspect also won't work too well on current routers. Setting filtering constraints at /32 is not sufficient to ensure small tables. Setting narrow filtering constraints is also counter-productive, as it encourage a rush on the short prefixes. An organization that could have done just fine with a /48 or maybe a /40 will request a /32 just in case, so that organization can eventually multi-home.=20 In the end, the size of the routing table will equal the number of entities that want multi-homing hard enough. Playing around with prefix sizes will not change that, and will probably generate undesirable counter effects. Besides, there are networks in which advertizing /48 or even /64 in BGP makes perfect sense. Take for example the "metropolitan aggregation" in which all users in an area get numbered from the same long prefix. The local ISP will have to exchange the short prefixes with each other. The will use BGP. Do we want to have a rule cast in stone that prevents them? We should really think twice before asking the IETF to publish a position on this subject. Silence may well be the right approach. -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Jul 05 12:14:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyA1b-0007Os-8N for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:14:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyA1a-0007wA-Pv for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:14:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyA1F-000PLM-QX for v6ops-data@psg.com; Wed, 05 Jul 2006 16:14:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [66.133.172.21] (helo=frontiercorp.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyA1E-000PJP-Rp for v6ops@ops.ietf.org; Wed, 05 Jul 2006 16:14:29 +0000 Received: from ([172.27.14.137]) by mail04.frontiercorp.com with ESMTP id 4028772.73820420; Wed, 05 Jul 2006 11:43:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: v6 multihoming and route filters Date: Wed, 5 Jul 2006 09:12:13 -0700 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D6B@wava00s2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters Thread-Index: AcagEi3S+8OdahTKSfaZ2xpU9jngPQAN+zbQ From: "Azinger, Marla" To: "Iljitsch van Beijnum" , "Christian Huitema" Cc: "Marc Blanchet" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 >>>>>>>Yes, that's true. But a billion is still a lot closer to = something =20 >reasonable than another nearly six orders of magnitude. And the =20 >crucial difference is that there is little chance of the the full ::/=20 >3 space being deaggregated into individual /32s, while leaking of =20 >significant numbers of "private" /48s into the global routing table =20 >is something I fully expect to happen based on experiences with = IPv4.<<<<<<<<< I know we had/have prefix leaks with V4, but doesn't anyone think we as = a community have learned the value in not leaking by now? If we have = lots of offenders like this, are they large Upstream providers? Or are = they small End Users or ISP's that may not ever renumber into V6? I am = curiouse how much we think this V4 problem really will be with V6. >Another approach is to filter on prefix size depending on the size of =20 >the prefixes RIRs give out in a certain part of the address space. =20 >(Possibly allowing one or two extra bits for traffic engineering =20 >purposes.) I think this is the best way to do it currently, but the =20 >problem is that the RIRs are still coming up with new stuff here so =20 >if we write this up it's likely that the list of parts of the address =20 >space where /48s are given out will change soon after, so the =20 >resulting document won't be all that useful in practice. (I'm also =20 >VERY much annoyed by the fact that the RIRs say you can filter on /32 =20 >(see quote yesterday) but give out /48s at the same time, I've =20 >brought this up YEARS ago and no action so far. The fact that each =20 >RIR reinvents the wheel with little global coordination but we're =20 >dealing with a GLOBAL routing table and not several regional ones =20 >doesn't help.)< I understand this frustration. However, the policy put forward so far = has been done without any guidance from IETF to be taken into = consideration. With some written guidance to consider it is very = possible policy can be adjusted and new policy can be made to follow the = guidance. Marla Azinger Frontier Communications -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Iljitsch van Beijnum Sent: Wednesday, July 05, 2006 1:28 AM To: Christian Huitema Cc: Marc Blanchet; v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters On 5-jul-2006, at 3:12, Christian Huitema wrote: >> What would be the purpose of filtering at /48? >> That allows for 2^45 =3D 351 trillion prefixes in the routing table, >> which I suspect won't work too well on current routers. And it only >> takes a handful of /32s deaggregated into /48s to inflate the IPv6 >> global routing table to a size larger than the current IPv4 routing >> table. > But then, filtering at /32 allows for 2^30 =3D 1 billion prefixes, =20 > which I > suspect also won't work too well on current routers. Yes, that's true. But a billion is still a lot closer to something =20 reasonable than another nearly six orders of magnitude. And the =20 crucial difference is that there is little chance of the the full ::/=20 3 space being deaggregated into individual /32s, while leaking of =20 significant numbers of "private" /48s into the global routing table =20 is something I fully expect to happen based on experiences with IPv4. > Setting narrow filtering constraints is also counter-productive, as it > encourage a rush on the short prefixes. An organization that could =20 > have > done just fine with a /48 or maybe a /40 will request a /32 just in > case, so that organization can eventually multi-home. This assumes that people will get anything they request. Currently, =20 you can't really get a /40: ISPs get /32 or shorter, end-users rarely =20 get something shorter than /48. > In the end, the size of the routing table will equal the number of > entities that want multi-homing hard enough. Playing around with =20 > prefix > sizes will not change that, and will probably generate undesirable > counter effects. > Besides, there are networks in which advertizing /48 or even /64 in =20 > BGP > makes perfect sense. Take for example the "metropolitan =20 > aggregation" in > which all users in an area get numbered from the same long prefix. The > local ISP will have to exchange the short prefixes with each other. =20 > The > will use BGP. Do we want to have a rule cast in stone that prevents > them? > We should really think twice before asking the IETF to publish a > position on this subject. Silence may well be the right approach. On the other hand, no filtering at all is asking for trouble, so it =20 would make sense for us to come up with a good filtering strategy. =20 One would be to make a filter based on actual allocations, which is =20 still possible in IPv6 today because of the small size of the global =20 table. Another approach is to filter on prefix size depending on the size of =20 the prefixes RIRs give out in a certain part of the address space. =20 (Possibly allowing one or two extra bits for traffic engineering =20 purposes.) I think this is the best way to do it currently, but the =20 problem is that the RIRs are still coming up with new stuff here so =20 if we write this up it's likely that the list of parts of the address =20 space where /48s are given out will change soon after, so the =20 resulting document won't be all that useful in practice. (I'm also =20 VERY much annoyed by the fact that the RIRs say you can filter on /32 =20 (see quote yesterday) but give out /48s at the same time, I've =20 brought this up YEARS ago and no action so far. The fact that each =20 RIR reinvents the wheel with little global coordination but we're =20 dealing with a GLOBAL routing table and not several regional ones =20 doesn't help.) Third approach: use prefixes shorter than /48 for anything that =20 should be in the routing table and then filter at /47. This avoids =20 problems with accidental leaking of /48s from internal routing, but =20 the ship has sailed on /48 for "micro allocations" so this approach =20 would have to be combined with the previous one. Finally, it would be possible to tag prefixes longer than /32 that =20 are injected into global routing intentionally, especially in the =20 case of shorter prefixes that are drawn from a larger address block =20 for multihoming purposes, with a BGP community that indicates why =20 this is done so that people can filter appropriately. For instance, =20 as a network operator I may want to allow such prefixes from "close =20 by" but not from other continents, so that there is a more or less =20 dynamic tradeoff between routing table size and optimum traffic flow =20 through the network, which is really what we want. (With PI you're =20 forced to carry the route or the destination is unreachable, not a =20 very nice choice.) From owner-v6ops@ops.ietf.org Wed Jul 05 12:50:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAZw-0003yP-Qc for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:50:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAZu-0001G9-Ba for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:50:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyAY5-0002ys-8g for v6ops-data@psg.com; Wed, 05 Jul 2006 16:48:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyAY4-0002yb-4K for v6ops@ops.ietf.org; Wed, 05 Jul 2006 16:48:24 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k65GljYI001381; Wed, 5 Jul 2006 16:47:45 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k65Glj23001380; Wed, 5 Jul 2006 16:47:45 GMT Date: Wed, 5 Jul 2006 16:47:45 +0000 From: bmanning@vacation.karoshi.com To: "Azinger, Marla" Cc: Christian Huitema , Iljitsch van Beijnum , Marc Blanchet , v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters Message-ID: <20060705164745.GF32758@vacation.karoshi.com.> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe actually, i think that Christian is dead-on. the IETF should not presume to know or dictate "best practices" for routing - esp. when they have no idea what may be my drivers. the best/only thing they should do is describe -HOW- it is done and -WHAT- are the boundaries for the choices ... Making value judgements in standards is nearly never a good idea. --bill On Wed, Jul 05, 2006 at 09:02:42AM -0700, Azinger, Marla wrote: > I urge everyone to seriously consider that silence is not a good answer. This internet community needs, wants and is asking for direction. Whatever comes out of this discussion, verbalizing a plan (be it with flaws or not) is better than no plan at all. Silence has been a large part of this issue for some time now (with various internet conference venues) and all this has done is create confusion and finger pointing and thus total feeling of lost and confused routing for developing V6 networks. > > Also, correct me if I'm wrong...but I didn't think the global routing table should be seeing the "metropolitan aggregation" setup. So /48 filter shouldn't interfere with that kind of setup. > > Marla Azinger > Frontier Communications > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Christian Huitema > Sent: Tuesday, July 04, 2006 6:13 PM > To: Iljitsch van Beijnum; Marc Blanchet > Cc: v6ops@ops.ietf.org > Subject: RE: v6 multihoming and route filters > > > > What would be the purpose of filtering at /48? > > > > That allows for 2^45 = 351 trillion prefixes in the routing table, > > which I suspect won't work too well on current routers. And it only > > takes a handful of /32s deaggregated into /48s to inflate the IPv6 > > global routing table to a size larger than the current IPv4 routing > > table. > > But then, filtering at /32 allows for 2^30 = 1 billion prefixes, which I > suspect also won't work too well on current routers. Setting filtering > constraints at /32 is not sufficient to ensure small tables. > > Setting narrow filtering constraints is also counter-productive, as it > encourage a rush on the short prefixes. An organization that could have > done just fine with a /48 or maybe a /40 will request a /32 just in > case, so that organization can eventually multi-home. > > In the end, the size of the routing table will equal the number of > entities that want multi-homing hard enough. Playing around with prefix > sizes will not change that, and will probably generate undesirable > counter effects. > > Besides, there are networks in which advertizing /48 or even /64 in BGP > makes perfect sense. Take for example the "metropolitan aggregation" in > which all users in an area get numbered from the same long prefix. The > local ISP will have to exchange the short prefixes with each other. The > will use BGP. Do we want to have a rule cast in stone that prevents > them? > > We should really think twice before asking the IETF to publish a > position on this subject. Silence may well be the right approach. > > -- Christian Huitema > > From owner-v6ops@ops.ietf.org Wed Jul 05 12:54:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyAeL-0004GD-5y for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:54:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyAeK-0001P4-Ln for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 12:54:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyAdv-0003gD-BC for v6ops-data@psg.com; Wed, 05 Jul 2006 16:54:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [194.138.37.40] (helo=gecko.sbs.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyAdu-0003fD-0P for v6ops@ops.ietf.org; Wed, 05 Jul 2006 16:54:26 +0000 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k65GsK2x031392; Wed, 5 Jul 2006 18:54:20 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k65GsIxH003569; Wed, 5 Jul 2006 18:54:19 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 18:53:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: v6 multihoming and route filters Date: Wed, 5 Jul 2006 18:53:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters thread-index: AcagEi3S+8OdahTKSfaZ2xpU9jngPQAN+zbQAAJDvaA= From: "Sofia, Rute" To: "Azinger, Marla" , "Iljitsch van Beijnum" , "Christian Huitema" Cc: "Marc Blanchet" , X-OriginalArrivalTime: 05 Jul 2006 16:53:20.0821 (UTC) FILETIME=[85720650:01C6A053] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 I have to say: I go with Christian on this one. I do not see exactly the point in having the IETF mandating a routing policy. Whatever you believe you can predict now (e.g., /48 being assigned to end-users) may require a change in the future and then the filtering rules may in fact not hold. Routing recommendations should (and are) provided by LIRs. That should be enough, right? Rute Sofia =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Azinger, Marla > Sent: Wednesday, July 05, 2006 6:12 PM > To: Iljitsch van Beijnum; Christian Huitema > Cc: Marc Blanchet; v6ops@ops.ietf.org > Subject: RE: v6 multihoming and route filters >=20 > >>>>>>>Yes, that's true. But a billion is still a lot closer=20 > to something =20 > >reasonable than another nearly six orders of magnitude. And the =20 > >crucial difference is that there is little chance of the the=20 > full ::/=20 > >3 space being deaggregated into individual /32s, while leaking of =20 > >significant numbers of "private" /48s into the global routing table =20 > >is something I fully expect to happen based on experiences=20 > with IPv4.<<<<<<<<< >=20 > I know we had/have prefix leaks with V4, but doesn't anyone=20 > think we as a community have learned the value in not leaking=20 > by now? If we have lots of offenders like this, are they=20 > large Upstream providers? Or are they small End Users or=20 > ISP's that may not ever renumber into V6? I am curiouse how=20 > much we think this V4 problem really will be with V6. >=20 > >Another approach is to filter on prefix size depending on=20 > the size of =20 > >the prefixes RIRs give out in a certain part of the address space. =20 > >(Possibly allowing one or two extra bits for traffic engineering =20 > >purposes.) I think this is the best way to do it currently, but the =20 > >problem is that the RIRs are still coming up with new stuff here so =20 > >if we write this up it's likely that the list of parts of=20 > the address =20 > >space where /48s are given out will change soon after, so the =20 > >resulting document won't be all that useful in practice. (I'm also =20 > >VERY much annoyed by the fact that the RIRs say you can=20 > filter on /32 =20 > >(see quote yesterday) but give out /48s at the same time, I've =20 > >brought this up YEARS ago and no action so far. The fact that each =20 > >RIR reinvents the wheel with little global coordination but we're =20 > >dealing with a GLOBAL routing table and not several regional ones =20 > >doesn't help.)< >=20 > I understand this frustration. However, the policy put=20 > forward so far has been done without any guidance from IETF=20 > to be taken into consideration. With some written guidance=20 > to consider it is very possible policy can be adjusted and=20 > new policy can be made to follow the guidance. >=20 > Marla Azinger > Frontier Communications >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Iljitsch van Beijnum > Sent: Wednesday, July 05, 2006 1:28 AM > To: Christian Huitema > Cc: Marc Blanchet; v6ops@ops.ietf.org > Subject: Re: v6 multihoming and route filters >=20 >=20 > On 5-jul-2006, at 3:12, Christian Huitema wrote: >=20 > >> What would be the purpose of filtering at /48? >=20 > >> That allows for 2^45 =3D 351 trillion prefixes in the routing = table, > >> which I suspect won't work too well on current routers. And it only > >> takes a handful of /32s deaggregated into /48s to inflate the IPv6 > >> global routing table to a size larger than the current IPv4 routing > >> table. >=20 > > But then, filtering at /32 allows for 2^30 =3D 1 billion prefixes, =20 > > which I > > suspect also won't work too well on current routers. >=20 > Yes, that's true. But a billion is still a lot closer to something =20 > reasonable than another nearly six orders of magnitude. And the =20 > crucial difference is that there is little chance of the the full ::/=20 > 3 space being deaggregated into individual /32s, while leaking of =20 > significant numbers of "private" /48s into the global routing table =20 > is something I fully expect to happen based on experiences with IPv4. >=20 > > Setting narrow filtering constraints is also=20 > counter-productive, as it > > encourage a rush on the short prefixes. An organization that could =20 > > have > > done just fine with a /48 or maybe a /40 will request a /32 just in > > case, so that organization can eventually multi-home. >=20 > This assumes that people will get anything they request. Currently, =20 > you can't really get a /40: ISPs get /32 or shorter,=20 > end-users rarely =20 > get something shorter than /48. >=20 > > In the end, the size of the routing table will equal the number of > > entities that want multi-homing hard enough. Playing around with =20 > > prefix > > sizes will not change that, and will probably generate undesirable > > counter effects. >=20 > > Besides, there are networks in which advertizing /48 or=20 > even /64 in =20 > > BGP > > makes perfect sense. Take for example the "metropolitan =20 > > aggregation" in > > which all users in an area get numbered from the same long=20 > prefix. The > > local ISP will have to exchange the short prefixes with=20 > each other. =20 > > The > > will use BGP. Do we want to have a rule cast in stone that prevents > > them? >=20 > > We should really think twice before asking the IETF to publish a > > position on this subject. Silence may well be the right approach. >=20 > On the other hand, no filtering at all is asking for trouble, so it =20 > would make sense for us to come up with a good filtering strategy. =20 > One would be to make a filter based on actual allocations, which is =20 > still possible in IPv6 today because of the small size of the global =20 > table. >=20 > Another approach is to filter on prefix size depending on the=20 > size of =20 > the prefixes RIRs give out in a certain part of the address space. =20 > (Possibly allowing one or two extra bits for traffic engineering =20 > purposes.) I think this is the best way to do it currently, but the =20 > problem is that the RIRs are still coming up with new stuff here so =20 > if we write this up it's likely that the list of parts of the=20 > address =20 > space where /48s are given out will change soon after, so the =20 > resulting document won't be all that useful in practice. (I'm also =20 > VERY much annoyed by the fact that the RIRs say you can=20 > filter on /32 =20 > (see quote yesterday) but give out /48s at the same time, I've =20 > brought this up YEARS ago and no action so far. The fact that each =20 > RIR reinvents the wheel with little global coordination but we're =20 > dealing with a GLOBAL routing table and not several regional ones =20 > doesn't help.) >=20 > Third approach: use prefixes shorter than /48 for anything that =20 > should be in the routing table and then filter at /47. This avoids =20 > problems with accidental leaking of /48s from internal routing, but =20 > the ship has sailed on /48 for "micro allocations" so this approach =20 > would have to be combined with the previous one. >=20 > Finally, it would be possible to tag prefixes longer than /32 that =20 > are injected into global routing intentionally, especially in the =20 > case of shorter prefixes that are drawn from a larger address block =20 > for multihoming purposes, with a BGP community that indicates why =20 > this is done so that people can filter appropriately. For instance, =20 > as a network operator I may want to allow such prefixes from "close =20 > by" but not from other continents, so that there is a more or less =20 > dynamic tradeoff between routing table size and optimum traffic flow =20 > through the network, which is really what we want. (With PI you're =20 > forced to carry the route or the destination is unreachable, not a =20 > very nice choice.) >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 05 14:57:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCZ0-0000IY-Lh for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 14:57:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyCYz-0004kd-DB for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 14:57:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyCX8-000H7e-QJ for v6ops-data@psg.com; Wed, 05 Jul 2006 18:55:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyCX8-000H7P-09 for v6ops@ops.ietf.org; Wed, 05 Jul 2006 18:55:34 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k65ItJv9015911 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jul 2006 20:55:20 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20060705164745.GF32758@vacation.karoshi.com.> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> <20060705164745.GF32758@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> Cc: "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Wed, 5 Jul 2006 20:55:19 +0200 To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On 5-jul-2006, at 18:47, bmanning@vacation.karoshi.com wrote: > actually, i think that Christian is dead-on. the IETF should not > presume to know or dictate "best practices" for routing - esp. when > they have no idea what may be my drivers. the best/only thing they > should do is describe -HOW- it is done and -WHAT- are the > boundaries for the choices ... This argument would be considerably more persuasive if there was some other group picking up the slack. The RIRs explicitly reject any responsibility for routing, although by creating address policies they impose important limits on what can be done here. Groups like NANOG, APRICOT and RIPE (as opposed to the RIPE NCC) are in the business of spreading best practices, but not in the business of creating them. And since the IETF is (hopefully) the place where internet routing is best understood an the IETF has historically always had an operational component (hence the existence of this very working group), I think the IETF can't shy away from at the very least discouraging harmful practices, and preferably also pointing out tradeoffs that exist between different choices and recommend best practices if such can be identified. > Making value judgements in standards is nearly never a good idea. What is a standard other than a big fat value judgement? From owner-v6ops@ops.ietf.org Wed Jul 05 15:10:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyClJ-0007w4-DV for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 15:10:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyClI-0007P8-17 for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 15:10:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyCkj-000IXg-22 for v6ops-data@psg.com; Wed, 05 Jul 2006 19:09:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyCkh-000IXT-RL for v6ops@ops.ietf.org; Wed, 05 Jul 2006 19:09:36 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k65J9RXY016183 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jul 2006 21:09:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D6B@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6B@wava00s2ke2k01.corp.pvt> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <884B2844-A757-42DF-9B93-C1DD6CC962B8@muada.com> Cc: "Christian Huitema" , "Marc Blanchet" , Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Wed, 5 Jul 2006 21:09:30 +0200 To: "Azinger, Marla" X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe On 5-jul-2006, at 18:12, Azinger, Marla wrote: >>>>>>>> Yes, that's true. But a billion is still a lot closer to >>>>>>>> something >> reasonable than another nearly six orders of magnitude. And the >> crucial difference is that there is little chance of the the full ::/ >> 3 space being deaggregated into individual /32s, while leaking of >> significant numbers of "private" /48s into the global routing table >> is something I fully expect to happen based on experiences with >> IPv4.<<<<<<<<< > I know we had/have prefix leaks with V4, but doesn't anyone think > we as a community have learned the value in not leaking by now? Sure, but that doesn't mean it can never again happen. > If we have lots of offenders like this, are they large Upstream > providers? Or are they small End Users or ISP's that may not ever > renumber into V6? I am curiouse how much we think this V4 problem > really will be with V6. Currently, there is no mass deployment of IPv6, so even if at some point an AS leaked all its internal routes, this would probably not have been all that many at this point. I'm not as worried as I was with IPv4, because I think we really did learn something, but I would still not feel comfortable allowing /48s without limitation. As I wrote before, a mechanism where routes that are allowed out on purpose are tagged so that they can be recognized as such could make all the difference here. In certain setups, it's very easy to make a mistake that allows routes through that are supposed to be filtered out as allowing routes through is the default. But inappropriately tagging routes with a BGP community by accident is much harder because the default is not having the tag. >> (I'm also >> VERY much annoyed by the fact that the RIRs say you can filter on /32 >> (see quote yesterday) but give out /48s at the same time, I've >> brought this up YEARS ago and no action so far. The fact that each >> RIR reinvents the wheel with little global coordination but we're >> dealing with a GLOBAL routing table and not several regional ones >> doesn't help.)< > I understand this frustration. However, the policy put forward so > far has been done without any guidance from IETF to be taken into > consideration. I'm not so sure; filtering on /32 is pretty much on par with the 6bone routing guidelines that came from the IETF. The document I referred to was also orignally adopted by all the RIRs and IANA (which is now part of ICANN but used to be much closer aligned with the IETF). > With some written guidance to consider it is very possible policy > can be adjusted and new policy can be made to follow the guidance. If we can reach consensus on such a policy I'm sure that in due course the RIRs would add pointers to it. It would be helpful if you (and others) could explain what it is you want to accomplish, then we can see if it's possible to come up with something creative that addresses this while avoiding the issues that were mentioned earlier. From owner-v6ops@ops.ietf.org Wed Jul 05 15:24:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyCzI-0000hL-Nt for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 15:24:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyCzH-00023w-Bs for v6ops-archive@lists.ietf.org; Wed, 05 Jul 2006 15:24:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyCyl-000Js6-3H for v6ops-data@psg.com; Wed, 05 Jul 2006 19:24:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyCyk-000Jru-Cj for v6ops@ops.ietf.org; Wed, 05 Jul 2006 19:24:06 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k65JNMYI002413; Wed, 5 Jul 2006 19:23:22 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k65JNMcA002412; Wed, 5 Jul 2006 19:23:22 GMT Date: Wed, 5 Jul 2006 19:23:22 +0000 From: bmanning@vacation.karoshi.com To: Iljitsch van Beijnum Cc: bmanning@vacation.karoshi.com, "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters Message-ID: <20060705192322.GA2254@vacation.karoshi.com.> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> <20060705164745.GF32758@vacation.karoshi.com.> <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab On Wed, Jul 05, 2006 at 08:55:19PM +0200, Iljitsch van Beijnum wrote: > On 5-jul-2006, at 18:47, bmanning@vacation.karoshi.com wrote: > > >actually, i think that Christian is dead-on. the IETF should not > >presume to know or dictate "best practices" for routing - esp. when > >they have no idea what may be my drivers. the best/only thing they > >should do is describe -HOW- it is done and -WHAT- are the > >boundaries for the choices ... > > This argument would be considerably more persuasive if there was some > other group picking up the slack. The RIRs explicitly reject any > responsibility for routing, although by creating address policies > they impose important limits on what can be done here. Groups like > NANOG, APRICOT and RIPE (as opposed to the RIPE NCC) are in the > business of spreading best practices, but not in the business of > creating them. ah, but there are other groups picking up the slack... e.g. your ISP and their peers. > And since the IETF is (hopefully) the place where internet routing is > best understood an the IETF has historically always had an > operational component (hence the existence of this very working > group), I think the IETF can't shy away from at the very least > discouraging harmful practices, and preferably also pointing out > tradeoffs that exist between different choices and recommend best > practices if such can be identified. er, not clear that the IETF is the place where internet routing is best understood... except from a theory standpoint. there is a distinct difference between a specification (IETF), an implementation (ZEBRA), and operation (your ISP)... IMHO it is none of the IETF's business to tell me or your ISP how it can and can not run its business. That said, I have no problem with the IETF telling implementors that there is a possibility of creating a potentially unmanageable number of potential routing entries. Such advice might also mention the fallicy of a "global routing table" and suggest that operators may need the tools to manage the number of route entries based on the current limits of their particular implementations. The SPEC's (IMHO) should not be hostage to current implementation limitations. and the SPEC designers should not attempt to dictate or police how i operate my network... Their influence should extend as far as the implementors. > > >Making value judgements in standards is nearly never a good idea. > What is a standard other than a big fat value judgement? your view of standards is apparently different than mine. i guess that in the end, if the IETF codifies this, we are back to classfull routing and hardcoding address boundaries... which turns back years of attempts to remove arbitrary bounds checking that was implemented in IPv4 in the early days ... those who refuse to learn from history are doomed to repeat it. --bill From owner-v6ops@ops.ietf.org Thu Jul 06 07:43:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySGq-0000nO-2y for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 07:43:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySGo-0007Hq-Mi for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 07:43:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FySDT-0000jT-E5 for v6ops-data@psg.com; Thu, 06 Jul 2006 11:40:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FySDS-0000jE-HH for v6ops@ops.ietf.org; Thu, 06 Jul 2006 11:40:18 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k66Be4uu033138 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Jul 2006 13:40:05 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20060705192322.GA2254@vacation.karoshi.com.> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> <20060705164745.GF32758@vacation.karoshi.com.> <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> <20060705192322.GA2254@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Thu, 6 Jul 2006 13:40:08 +0200 To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a On 5-jul-2006, at 21:23, bmanning@vacation.karoshi.com wrote: >> This argument would be considerably more persuasive if there was some >> other group picking up the slack. > ah, but there are other groups picking up the slack... > e.g. your ISP and their peers. There is a big difference between individual entities doing individual things that make sense for them, and agreeing on something that's good for everyone. >> And since the IETF is (hopefully) the place where internet routing is >> best understood > er, not clear that the IETF is the place where internet > routing is best understood... except from a theory standpoint. > there is a distinct difference between a specification (IETF), > an implementation (ZEBRA), and operation (your ISP)... You make it sound like there is no overlap between the different groups. Unlike other standards organizations, anyone can participate in the IETF and even though the balance between different groups could be better, the IETF still enjoys a wide variety of people and occupations in its constituency. > IMHO > it is none of the IETF's business to tell me or your ISP how > it can and can not run its business. There is a big difference between providing information about what's a good idea and creating/enforcing rules. The former should be part of the IETF's business, the latter probably shouldn't. > Such advice might also mention the > fallicy of a "global routing table" What fallicy? >>> Making value judgements in standards is nearly never a good idea. >> What is a standard other than a big fat value judgement? > your view of standards is apparently different than mine. > i guess that in the end, if the IETF codifies this, we are > back to classfull routing and hardcoding address boundaries... > which turns back years of attempts to remove arbitrary bounds > checking that was implemented in IPv4 in the early days ... The lesson was poorly learned because through some back doors we're now in the situation where having /64 subnets is pretty much mandatory. But we were talking about inter-domain routing. Filtering on prefix size is a very useful technique that does indeed have unfortunate side effects. But if you want to get rid of this technique you'll have to come up with something to replace it... Not filtering is not a reasonable long-term strategy. From owner-v6ops@ops.ietf.org Thu Jul 06 08:37:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyT6s-0003vs-Vz for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 08:37:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyT6r-0003tM-NF for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 08:37:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyT64-00056W-Ul for v6ops-data@psg.com; Thu, 06 Jul 2006 12:36:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyT64-00056J-Ci for v6ops@ops.ietf.org; Thu, 06 Jul 2006 12:36:44 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k66Ca9YI008109; Thu, 6 Jul 2006 12:36:09 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k66Ca8nv008108; Thu, 6 Jul 2006 12:36:08 GMT Date: Thu, 6 Jul 2006 12:36:08 +0000 From: bmanning@vacation.karoshi.com To: Iljitsch van Beijnum Cc: bmanning@vacation.karoshi.com, "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters Message-ID: <20060706123608.GI7556@vacation.karoshi.com.> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> <20060705164745.GF32758@vacation.karoshi.com.> <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> <20060705192322.GA2254@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 > >Such advice might also mention the > > fallicy of a "global routing table" > > What fallicy? where is the "global routing table"? How is it defined? In zero cases that I am aware of, can any given node running IP reach any other arbitrary node running IP. I posit that this "global routing table" is a myth. The -ONLY- thing that matters to me are are the entries in -MY- routers memory. How they get there is -MY- choice and I get to dictate what is placed there. What you have in -YOUR- routers is your business. > > i guess that in the end, if the IETF codifies this, we are > > back to classfull routing and hardcoding address boundaries... > > which turns back years of attempts to remove arbitrary bounds > > checking that was implemented in IPv4 in the early days ... > > The lesson was poorly learned because through some back doors we're > now in the situation where having /64 subnets is pretty much mandatory. > > But we were talking about inter-domain routing. Filtering on prefix > size is a very useful technique that does indeed have unfortunate > side effects. But if you want to get rid of this technique you'll > have to come up with something to replace it... Not filtering is not > a reasonable long-term strategy. > I never said not filtering was an option. Proxy aggregation is viable as well. IF this draft is to have any credibility, the only choice will be to describe what prefix size filtering is, what the ramifications are, and what the "unfortunate side effects" are. As an ION, one might indicate that given the implementation constraints of 2006, an operator might consider the merits of selecting certain prefix sizes, if they choose to use prefix-sized filters in their routers. Two distinct documents. IMHO of course. The IETF will do what/as it pleases. --bill From owner-v6ops@ops.ietf.org Thu Jul 06 18:31:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FycNx-0007ZE-Il for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 18:31:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FycNw-0004CC-6g for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 18:31:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FycLb-0005ms-KP for v6ops-data@psg.com; Thu, 06 Jul 2006 22:29:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FycLa-0005mc-NT for v6ops@ops.ietf.org; Thu, 06 Jul 2006 22:29:23 +0000 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k66MTACP043024 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 7 Jul 2006 00:29:10 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20060706123608.GI7556@vacation.karoshi.com.> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> <20060705164745.GF32758@vacation.karoshi.com.> <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> <20060705192322.GA2254@vacation.karoshi.com.> <20060706123608.GI7556@vacation.karoshi.com.> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Fri, 7 Jul 2006 00:29:12 +0200 To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab On 6-jul-2006, at 14:36, bmanning@vacation.karoshi.com wrote: >> What fallicy? > where is the "global routing table"? How is it defined? Either as a particular instance (i.e., taken from one router) of the set of routes that allow connectivity to the internet at large or the set of prefixes that make up the address space used on the internet. Obviously this can be made as complex as desired. > In zero cases that I am aware of, can any given node running > IP reach any other arbitrary node running IP. What does that prove? > I posit that this "global routing table" is a myth. The -ONLY- > thing that matters to me are are the entries in -MY- routers memory. > How they get there is -MY- choice and I get to dictate what is placed > there. What you have in -YOUR- routers is your business. That's nice for you but I'm glad that you're not my ISP because I don't think personal preference has an important place in running a global network. Not only because different people have different preferences, but also because it doesn't scale. >> But we were talking about inter-domain routing. Filtering on prefix >> size is a very useful technique that does indeed have unfortunate >> side effects. But if you want to get rid of this technique you'll >> have to come up with something to replace it... Not filtering is not >> a reasonable long-term strategy. > I never said not filtering was an option. Proxy aggregation is > viable > as well. Not with BGP as it exists today, and security issues are quite problematic with this. > IF this draft is to have any credibility, the only choice will be to > describe what prefix size filtering is, what the ramifications > are, and > what the "unfortunate side effects" are. As an ION, one might > indicate > that given the implementation constraints of 2006, an operator might > consider the merits of selecting certain prefix sizes, if they choose > to use prefix-sized filters in their routers. Two distinct > documents. I disagree. Having a prefix that works in 98% of all cases is not nearly as useful as one that works in 99.98% of all cases. Having a free-for-all with regard to prefix filtering is suboptimal. And I think now we're back to the original issue so this is a nice point to have a go at letting the discussion rest. :-) > IMHO of course. The IETF will do what/as it pleases. Given rough consensus, yes. From owner-v6ops@ops.ietf.org Thu Jul 06 19:53:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FydfB-0003y2-3u for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 19:53:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fydf5-0005KD-Ru for v6ops-archive@lists.ietf.org; Thu, 06 Jul 2006 19:53:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyddO-000CAI-AD for v6ops-data@psg.com; Thu, 06 Jul 2006 23:51:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FyddG-000C9f-OY for v6ops@ops.ietf.org; Thu, 06 Jul 2006 23:51:46 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2006 19:51:42 -0400 X-IronPort-AV: i="4.06,214,1149480000"; d="txt'?scan'208,217"; a="91930411:sNHT92185220" 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 k66NpfV4010695 for ; Thu, 6 Jul 2006 19:51:41 -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 k66NpfoB005673 for ; Thu, 6 Jul 2006 19:51:41 -0400 (EDT) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Jul 2006 19:51:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6A157.2108FA96" Subject: New version of the "IPv6 Unicast Address Assignment Considerations" draft Date: Thu, 6 Jul 2006 19:51:40 -0400 Message-ID: <3D1C81E7AA3CD64FA20B04D269FEF7F401C38BE3@xmb-rtp-213.amer.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New version of the "IPv6 Unicast Address Assignment Considerations" draft Thread-Index: AcahVyCiYmRj/aehQOKVTc3IHpZb9Q== From: "Chip Popoviciu \(cpopovic\)" To: X-OriginalArrivalTime: 06 Jul 2006 23:51:41.0704 (UTC) FILETIME=[21269080:01C6A157] DKIM-Signature: a=rsa-sha1; q=dns; l=97837; t=1152229901; x=1153093901; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpopovic@cisco.com; z=From:=22Chip=20Popoviciu=20\(cpopovic\)=22=20 |Subject:New=20version=20of=20the=20=22IPv6=20Unicast=20Address=20Assignment=20Co nsiderations=22=20draft |To:; X=v=3Dcisco.com=3B=20h=3DOLffTIS5qd/pziufRrJo7cLIKVY=3D; b=NVrL5GVBjJMjK1ZwMaVtRfLipdSfjiTGyLqsNomEonrD/b90ArHMl7gh8m0DEodDI2WYRjWV 3C/BAL2ahPNBFi44J7yx1ixkiDz5o0q+L/svK7IWXGW720ySG+FdcJ/z; Authentication-Results: rtp-dkim-1.cisco.com; header.From=cpopovic@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 722e61efe02e5383d7f8ce1c4b5666e6 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A157.2108FA96 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6A157.2108FA96" ------_=_NextPart_002_01C6A157.2108FA96 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear v6ops WG members, =20 We submitted version -01 of the "IPv6 Unicast Address Assignment Considerations" draft today, past the June 26 deadline which means it will not be published in time for IETF 66. This version integrates the WG feedback and the new Service Provider addressing case study. We will review these changes during our presentation in Montreal so we wanted to make sure that this new version is available to the work group, even though it comes as an attachment to this e-mail. =20 As always, your feedback is most appreciated. Thank you very much for your support! =20 Best Regards, Ciprian Popoviciu for the authors of the draft ------_=_NextPart_002_01C6A157.2108FA96 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = v6ops WG=20 members,
 
We = submitted version=20 -01 of the "IPv6 Unicast Address Assignment Considerations" draft today, = past=20 the June 26 deadline which means it will not be published in time for = IETF 66.=20 This version integrates the WG feedback and the new Service Provider = addressing=20 case study. We will review these changes during our presentation in = Montreal so=20 we wanted to make sure that this new version is available to the work = group,=20 even though it comes as an attachment to this = e-mail.
 
As = always, your=20 feedback is most appreciated. Thank you very much for your=20 support!
 
Best=20 Regards,
Ciprian Popoviciu=20 for the authors of the draft
------_=_NextPart_002_01C6A157.2108FA96-- ------_=_NextPart_001_01C6A157.2108FA96 Content-Type: text/plain; name="draft-ietf-v6ops-addcon-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-v6ops-addcon-01.txt Content-Disposition: attachment; filename="draft-ietf-v6ops-addcon-01.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRy4gVmFuIGRlIFZlbGRlDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDLiBQb3BvdmljaXUNCkV4cGlyZXM6IERlY2VtYmVy IDMsIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFQuIENob3duDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFVuaXZlcnNpdHkgb2YgU291dGhhbXB0b24NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTy4gQm9ubmVzcw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBDLiBIYWhuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQtU3lzdGVt cyBFbnRlcnByaXNlIFNlcnZpY2VzIEdtYkgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNg0KDQoNCiAgICAgICAg ICAgICBJUHY2IFVuaWNhc3QgQWRkcmVzcyBBc3NpZ25tZW50IENvbnNpZGVyYXRpb25zDQogICAg ICAgICAgICAgICAgICAgIDxkcmFmdC1pZXRmLXY2b3BzLWFkZGNvbi0wMS50eHQ+DQoNClN0YXR1 cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBl YWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBv dGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVu IG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVz DQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24g NiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMg b2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERy YWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9y IGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlz IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIN Cg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2Vk IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAg IFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNj ZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMg SW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gRGVjZW1iZXIgMywgMjAwNi4NCg0KQ29weXJp Z2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2 KS4NCg0KQWJzdHJhY3QNCg0KICAgT25lIGZ1bmRhbWVudGFsIGFzcGVjdCBvZiBhbnkgSVAgY29t bXVuaWNhdGlvbnMgaW5mcmFzdHJ1Y3R1cmUgaXMgaXRzDQogICBhZGRyZXNzaW5nIHBsYW4uICBX aXRoIGl0cyBuZXcgYWRkcmVzcyBhcmNoaXRlY3R1cmUgYW5kIGFsbG9jYXRpb24NCiAgIHBvbGlj aWVzLCB0aGUgaW50cm9kdWN0aW9uIG9mIElQdjYgaW50byBhIG5ldHdvcmsgbWVhbnMgdGhhdCBu ZXR3b3JrDQoNCg0KDQpWYW4gZGUgVmVsZGUsIGV0IGFsLiAgICBFeHBpcmVzIERlY2VtYmVyIDMs IDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIElQ djYgQWRkcmVzc2luZyBDb25zaWRlcmF0aW9ucyAgICAgICAgICAgIEp1bmUgMjAwNg0KDQoNCiAg IGRlc2lnbmVycyBhbmQgb3BlcmF0b3JzIG5lZWQgdG8gcmVjb25zaWRlciB0aGVpciBleGlzdGlu ZyBhcHByb2FjaGVzDQogICB0byBuZXR3b3JrIGFkZHJlc3NpbmcuICBMYWNrIG9mIGd1aWRlbGlu ZXMgb24gaGFuZGxpbmcgdGhpcyBhc3BlY3Qgb2YNCiAgIG5ldHdvcmsgZGVzaWduIGNvdWxkIHNs b3cgZG93biB0aGUgaW50ZWdyYXRpb24gb2YgSVB2Ni4gIFRoaXMgZHJhZnQNCiAgIGFpbXMgdG8g cHJvdmlkZSB0aGUgaW5mb3JtYXRpb24gYW5kIHJlY29tbWVuZGF0aW9ucyByZWxldmFudCB0bw0K ICAgcGxhbm5pbmcgdGhlIGFkZHJlc3NpbmcgYXNwZWN0cyBvZiBJUHY2IGRlcGxveW1lbnRzLiAg VGhlIGRyYWZ0IGFsc28NCiAgIHByb3ZpZGVzIElQdjYgYWRkcmVzc2luZyBjYXNlIHN0dWRpZXMg Zm9yIGJvdGggYW4gZW50ZXJwcmlzZSBhbmQgYW4NCiAgIElTUCBuZXR3b3JrLiAgSW4gdGhpcyBm aXJzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3ZSBhaW0gdG8gcHJvdm9rZQ0KICAgZGlzY3Vzc2lv biBvbiB0aGlzIGltcG9ydGFudCB0b3BpYzsgbW9yZSBkZXRhaWxlZCBjYXNlIHN0dWR5IHRleHRz DQogICB3aWxsIGZvbGxvdy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClZhbiBkZSBWZWxk ZSwgZXQgYWwuICAgIEV4cGlyZXMgRGVjZW1iZXIgMywgMjAwNiAgICAgICAgICAgICAgICBbUGFn ZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgSVB2NiBBZGRyZXNzaW5nIENvbnNpZGVyYXRp b25zICAgICAgICAgICAgSnVuZSAyMDA2DQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4g IEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA0DQogICAyLiAgTmV0d29yayBMZXZlbCBBZGRyZXNzaW5nIERlc2lnbiBDb25zaWRl cmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMi4xLiAgR2xvYmFsIFVuaXF1ZSBBZGRy ZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAyLjIuICBV bmlxdWUgTG9jYWwgSVB2NiBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA1DQogICAgIDIuMy4gIDZCb25lIEFkZHJlc3MgU3BhY2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgMi40LiAgTmV0d29yayBMZXZlbCBEZXNpZ24gQ29u c2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICAgIDIuNC4xLiAgU2l6 aW5nIHRoZSBOZXR3b3JrIEFsbG9jYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQog ICAgICAgMi40LjIuICBBZGRyZXNzIFNwYWNlIENvbnNlcnZhdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDgNCiAgIDMuICBTdWJuZXQgUHJlZml4IENvbnNpZGVyYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAzLjEuICBDb25zaWRlcmF0aW9u cyBmb3Igc3VibmV0IHByZWZpeGVzIHNob3J0ZXIgdGhlbiAvNjQgIC4gLiAuICA4DQogICAgIDMu Mi4gIENvbnNpZGVyYXRpb25zIGZvciAvNjQgcHJlZml4ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDkNCiAgICAgMy4zLiAgQ29uc2lkZXJhdGlvbnMgZm9yIHN1Ym5ldCBwcmVmaXhlcyBs b25nZXIgdGhlbiAvNjQgLiAuIC4gLiAgOQ0KICAgICAgIDMuMy4xLiAgQW55Y2FzdCBhZGRyZXNz ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgICAgMy4zLjIu ICBBZGRyZXNzZXMgdXNlZCBieSBFbWJlZGRlZC1SUCAoUkZDMzk1NikgIC4gLiAuIC4gLiAuIC4g MTENCiAgICAgICAzLjMuMy4gIElTQVRBUCBhZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICAgIDMuMy40LiAgLzEyNiBhZGRyZXNzZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAgICAgMy4zLjUuICAvMTI3 IGFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAg ICAgICAzLjMuNi4gIC8xMjggYWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMg0KICAgNC4gIEFsbG9jYXRpb24gb2YgdGhlIElJRCBvZiBhbiBJUHY2IEFk ZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAgIDQuMS4gIEF1dG9tYXRpYyBFVUkt NjQgRm9ybWF0IE9wdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAgNC4y LiAgVXNpbmcgUHJpdmFjeSBFeHRlbnNpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMw0KICAgICA0LjMuICBDcnlwdG9ncmFwaGljYWxseSBHZW5lcmF0ZWQgSVB2NiBBZGRy ZXNzZXMgLiAuIC4gLiAuIC4gLiAuIDEzDQogICAgIDQuNC4gIE1hbnVhbC9EeW5hbWljIEFzc2ln bm1lbnQgT3B0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgIDUuICBDYXNlIFN0 dWRpZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx NA0KICAgICA1LjEuICBFbnRlcnByaXNlIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE0DQogICAgICAgNS4xLjEuICBPYnRhaW5pbmcgZ2VuZXJhbCBJUHY2 IG5ldHdvcmsgcHJlZml4ZXMgIC4gLiAuIC4gLiAuIC4gMTQNCiAgICAgICA1LjEuMi4gIEZvcm1p bmcgYW4gYWRkcmVzcyAoc3VibmV0KSBhbGxvY2F0aW9uIHBsYW4gIC4gLiAuIC4gLiAxNQ0KICAg ICAgIDUuMS4zLiAgT3RoZXIgY29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE2DQogICAgICAgNS4xLjQuICBOb2RlIGNvbmZpZ3VyYXRpb24gY29uc2lkZXJh dGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgICA1LjEuNS4gIE9ic2VydmF0aW9u cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KICAgICA1LjIu ICBTZXJ2aWNlIFByb3ZpZGVyIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE3DQogICAgICAgNS4yLjEuICBJbnZlc3RpZ2F0aW9uIG9mIG9iamVjdGl2ZSBSZXF1aXJl bWVudHMgZm9yIGFuDQogICAgICAgICAgICAgICBJUHY2IGFkZHJlc3Npbmcgc2NoZW1hIG9mIGEg U2VydmljZSBQcm92aWRlciAuIC4gLiAuIC4gMTcNCiAgICAgICA1LjIuMi4gIElQdjYgYWRkcmVz cyBhbGxvY2F0aW9uIHBsYW4gZm9yIGEgU2VydmljZSBQcm92aWRlciAgLiAxOQ0KICAgICAgIDUu Mi4zLiAgQWRkaXRpb25hbCBSZW1hcmtzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIzDQogICA2LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQNCiAgIDcuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNA0KICAgOC4gIEFja25vd2xl ZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1 DQogICA5LiAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjUNCiAgICAgOS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQ0KICAgICA5LjIuICBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICBB dXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjgNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRl bWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAzMA0KDQoNCg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBl dCBhbC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDNd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMg ICAgICAgICAgICBKdW5lIDIwMDYNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBJbnRl cm5ldCBQcm90b2NvbCBWZXJzaW9uIDYgKElQdjYpIEFkZHJlc3NpbmcgQXJjaGl0ZWN0dXJlIFsy M10NCiAgIGRlZmluZXMgdGhyZWUgbWFpbiB0eXBlcyBvZiBhZGRyZXNzZXM6IHVuaWNhc3QsIGFu eWNhc3QgYW5kDQogICBtdWx0aWNhc3QuICBUaGlzIGRvY3VtZW50IGZvY3VzZXMgb24gdW5pY2Fz dCBhZGRyZXNzZXMsIGZvciB3aGljaA0KICAgdGhlcmUgYXJlIGN1cnJlbnRseSB0aHJlZSBwcmlu Y2lwYWwgYWxsb2NhdGVkIHR5cGVzOiBHbG9iYWwgVW5pcXVlDQogICBBZGRyZXNzZXMgWzEyXSAo J2dsb2JhbHMnKSwgVW5pcXVlIExvY2FsIElQdjYgQWRkcmVzc2VzIFsyMl0gKFVMQXMpDQogICBh bmQgNmJvbmUgYWRkcmVzcyBzcGFjZSBbM10uDQoNCiAgIFRoZSBkb2N1bWVudCBjb3ZlcnMgYXNw ZWN0cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIGR1cmluZyBJUHY2DQogICBkZXBsb3ltZW50 IGZvciB0aGUgZGVzaWduIGFuZCBwbGFubmluZyBvZiBhbiBhZGRyZXNzaW5nIHNjaGVtZSBmb3Ig YW4NCiAgIElQdjYgbmV0d29yay4gIFRoZSBuZXR3b3JrJ3MgSVB2NiBhZGRyZXNzaW5nIHBsYW4g bWF5IGJlIGZvciBhbiBJUHY2LQ0KICAgb25seSBuZXR3b3JrLCBvciBmb3IgYSBkdWFsLXN0YWNr IGluZnJhc3RydWN0dXJlIHdoZXJlIHNvbWUgb3IgYWxsDQogICBkZXZpY2VzIGhhdmUgYWRkcmVz c2VzIGluIGJvdGggcHJvdG9jb2xzLiAgVGhlc2UgY29uc2lkZXJhdGlvbnMgd2lsbA0KICAgaGVs cCBhbiBJUHY2IG5ldHdvcmsgZGVzaWduZXIgdG8gZWZmaWNpZW50bHkgYW5kIHBydWRlbnRseSBh c3NpZ24gdGhlDQogICBJUHY2IGFkZHJlc3Mgc3BhY2UgdGhhdCBoYXMgYmVlbiBhbGxvY2F0ZWQg dG8gaXRzIG9yZ2FuaXphdGlvbi4NCg0KICAgVGhlIGFkZHJlc3MgYXNzaWdubWVudCBjb25zaWRl cmF0aW9ucyBhcmUgYW5hbHl6ZWQgc2VwYXJhdGVseSBmb3IgdGhlDQogICB0d28gbWFqb3IgY29t cG9uZW50cyBvZiB0aGUgSVB2NiB1bmljYXN0IGFkZHJlc3NlcywgbmFtZWx5ICdOZXR3b3JrDQog ICBMZXZlbCBBZGRyZXNzaW5nJyAodGhlIGFsbG9jYXRpb24gb2Ygc3VibmV0cykgYW5kIHRoZSAn U3VibmV0IFByZWZpeCcNCiAgIChhZGRyZXNzIHVzYWdlIHdpdGhpbiBhIHN1Ym5ldCkuICBUaHVz IHRoZSBkb2N1bWVudCBpbmNsdWRlcyBhDQogICBkaXNjdXNzaW9uIG9mIGFzcGVjdHMgb2YgYWRk cmVzcyBhc3NpZ25tZW50IHRvIG5vZGVzIGFuZCBpbnRlcmZhY2VzDQogICBpbiBhbiBJUHY2IG5l dHdvcmsuICBGaW5hbGx5IHRoZSBkb2N1bWVudCB3aWxsIHByb3ZpZGUgdHdvIGV4YW1wbGVzDQog ICBvZiBzdWNjZXNzZnVsbHkgZGVwbG95ZWQgYWRkcmVzcyBwbGFucyBpbiBhIHNlcnZpY2UgcHJv dmlkZXIgKElTUCkNCiAgIGFuZCBhbiBlbnRlcnByaXNlIG5ldHdvcmsuDQoNCiAgIFBhcnRzIG9m IHRoaXMgZG9jdW1lbnQgaGlnaGxpZ2h0IHRoZSBkaWZmZXJlbmNlcyB0aGF0IGFuIGV4cGVyaWVu Y2VkDQogICBJUHY0IG5ldHdvcmsgZGVzaWduZXIgc2hvdWxkIGNvbnNpZGVyIHdoZW4gcGxhbm5p bmcgYW4gSVB2Ng0KICAgZGVwbG95bWVudCwgZm9yIGV4YW1wbGU6DQoNCiAgIG8gIElQdjYgZGV2 aWNlcyB3aWxsIG1vcmUgbGlrZWx5IGJlIG11bHRpLWFkZHJlc3NlZCBpbiBjb21wYXJpc29uDQog ICAgICB3aXRoIHRoZWlyIElQdjQgY291bnRlcnBhcnRzLg0KICAgbyAgVGhlIHByYWN0aWNhbGx5 IHVubGltaXRlZCBzaXplIG9mIGFuIElQdjYgc3VibmV0ICgyXjY0IGJpdHMpDQogICAgICByZWR1 Y2VzIHRoZSByZXF1aXJlbWVudCB0byBzaXplIHN1Ym5ldHMgdG8gZGV2aWNlIGNvdW50cyBmb3Ig dGhlDQogICAgICBwdXJwb3NlcyBvZiAoSVB2NCkgYWRkcmVzcyBjb25zZXJ2YXRpb24uDQogICBv ICBFdmVuIHRob3VnaCB0aGVyZSBpcyBubyBicm9hZGNhc3QgZm9yIHRoZSBJUHY2IHByb3RvY29s LCB0aGVyZSBpcw0KICAgICAgc3RpbGwgbmVlZCB0byBjb25zaWRlciB0aGUgbnVtYmVyIG9mIGRl dmljZXMgaW4gYSBnaXZlbiBzdWJuZXQgZHVlDQogICAgICB0byB0cmFmZmljIHN0b3JtIGFuZCBs ZXZlbCBvZiB0cmFmZmljIGdlbmVyYXRlZCBieSBob3N0cy4NCiAgIG8gIFRoZSBpbXBsaWNhdGlv bnMgb2YgdGhlIHJlZHVjZWQgdGhyZWF0IG9mIGFkZHJlc3MtYmFzZWQgaG9zdA0KICAgICAgc2Nh bm5pbmcsIGFzIGRpc2N1c3NlZCBpbiBbMjZdLg0KDQogICBXZSBkbyBub3QgZGlzY3VzcyBoZXJl IGhvdyBhIHNpdGUgb3IgSVNQIHNob3VsZCBwcm9jZWVkIHdpdGgNCiAgIGFjcXVpcmluZyBpdHMg Z2xvYmFsbHkgcm91dGFibGUgSVB2NiBhZGRyZXNzIHByZWZpeC4gIEhvd2V2ZXIsIG9uZQ0KICAg c2hvdWxkIG5vdGUgdGhhdCBJUHY2IG5ldHdvcmtzIHJlY2VpdmUgdGhlaXIgZ2xvYmFsIHVuaWNh c3QgYWRkcmVzcw0KICAgYWxsb2NhdGlvbiBmcm9tIHRoZWlyICd1cHN0cmVhbScgcHJvdmlkZXIs IHdoaWNoIG1heSBiZSBhbm90aGVyIElTUCwNCiAgIGEgTG9jYWwgSW50ZXJuZXQgUmVnaXN0cnkg KExJUikgb3IgYSBSZWdpb25hbCBJbnRlcm5ldCBSZWdpc3RyeQ0KICAgKFJJUikuICBJbiBlYWNo IGNhc2UgdGhlIHByZWZpeCByZWNlaXZlZCBpcyBwcm92aWRlciBhc3NpZ25lZCAoUEEpOw0KICAg dGhlcmUgaXMgY3VycmVudGx5IG5vIHByb3ZpZGVyIGluZGVwZW5kZW50IChQSSkgYWRkcmVzcyBz cGFjZSBmb3INCg0KDQoNClZhbiBkZSBWZWxkZSwgZXQgYWwuICAgIEV4cGlyZXMgRGVjZW1iZXIg MywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg SVB2NiBBZGRyZXNzaW5nIENvbnNpZGVyYXRpb25zICAgICAgICAgICAgSnVuZSAyMDA2DQoNCg0K ICAgSVB2Ni4gIFRodXMgYW4gSVB2NiBuZXR3b3JrIHdoaWNoIGNoYW5nZXMgcHJvdmlkZXIgd2ls bCBuZWVkIHRvDQogICB1bmRlcmdvIGEgcmVudW1iZXJpbmcgcHJvY2VzcywgYXMgZGVzY3JpYmVk IGluIFsyMV0uICBBIHNlcGFyYXRlDQogICBkb2N1bWVudCBbMjhdIG1ha2VzIHJlY29tbWVuZGF0 aW9ucyB0byBlYXNlIHRoZSBJUHY2IHJlbnVtYmVyaW5nDQogICBwcm9jZXNzLg0KDQogICBUaGlz IGRvY3VtZW50IG5laXRoZXIgZGlzY3Vzc2VzIGltcGxlbWVudGF0aW9uIGFzcGVjdHMgYmV0d2Vl biBVTEENCiAgIGFkZHJlc3NlcyBhbmQgU2l0ZS1sb2NhbCBhZGRyZXNzZXMuICBNb3N0IGltcGxl bWVudGF0aW9ucyBrbm93IGFib3V0DQogICBTaXRlLWxvY2FsIGFkZHJlc3NlcyBldmVuIHRob3Vn aCB0aGV5IGFyZSBkZXByZWNhdGVkLCBhbmQgZG8gbm90IGtub3cNCiAgIGFib3V0IFVMQXMgLSBl dmVuIHRob3VnaCB0aGV5IGFyZSBhY2NvcmRpbmcgY3VycmVudCBzcGVjaWZpY2F0aW9uLg0KICAg QXMgcmVzdWx0IHRyYW5zaXRpb25pbmcgYmV0d2VlbiB0aGVzZSB0eXBlcyBvZiBhZGRyZXNzZXMg bWF5IGNhdXNlDQogICBkaWZmaWN1bHRpZXMuDQoNCg0KMi4gIE5ldHdvcmsgTGV2ZWwgQWRkcmVz c2luZyBEZXNpZ24gQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBzZWN0aW9uIGRpc2N1c3NlcyB0 aGUga2luZCBvZiBJUHY2IGFkZHJlc3NlcyB1c2VkIGF0IHRoZSBuZXR3b3JrDQogICBsZXZlbCBm b3IgdGhlIElQdjYgaW5mcmFzdHJ1Y3R1cmUuICBUaGUga2luZCBvZiBhZGRyZXNzZXMgdGhhdCBj YW4gYmUNCiAgIGNvbnNpZGVyZWQgYXJlIEdsb2JhbCBVbmlxdWUgQWRkcmVzc2VzLCBVTEFzIGFu ZCA2Ym9uZSBhZGRyZXNzIHNwYWNlLg0KDQoyLjEuICBHbG9iYWwgVW5pcXVlIEFkZHJlc3Nlcw0K DQogICBUaGUgbW9zdCBjb21tb25seSB1c2VkIHVuaWNhc3QgYWRkcmVzc2VzIHdpbGwgYmUgR2xv YmFsIFVuaXF1ZQ0KICAgQWRkcmVzc2VzICgnZ2xvYmFscycpLiAgTm8gc2lnbmlmaWNhbnQgY29u c2lkZXJhdGlvbnMgYXJlIG5lY2Vzc2FyeQ0KICAgaWYgdGhlIG9yZ2FuaXphdGlvbiBoYXMgYW4g YWRkcmVzcyBzcGFjZSBhc3NpZ25tZW50IGFuZCBhIHNpbmdsZQ0KICAgcHJlZml4IGlzIGRlcGxv eWVkIHRocm91Z2ggYSBzaW5nbGUgdXBzdHJlYW0gcHJvdmlkZXIuDQoNCiAgIEhvd2V2ZXIsIGEg bXVsdGlob21lZCBzaXRlIG1heSBkZXBsb3kgYWRkcmVzc2VzIGZyb20gdHdvIG9yIG1vcmUNCiAg IFNlcnZpY2UgUHJvdmlkZXIgYXNzaWduZWQgSVB2NiBhZGRyZXNzIHJhbmdlcy4gIEhlcmUsIHRo ZSBuZXR3b3JrDQogICBBZG1pbmlzdHJhdG9yIG11c3QgaGF2ZSBhd2FyZW5lc3Mgb24gd2hlcmUg YW5kIGhvdyB0aGVzZSByYW5nZXMgYXJlDQogICB1c2VkIG9uIHRoZSBtdWx0aWhvbWVkIGluZnJh c3RydWN0dXJlIGVudmlyb25tZW50LiAgVGhlIG5hdHVyZSBvZiB0aGUNCiAgIHVzYWdlIG9mIG11 bHRpcGxlIHByZWZpeGVzIG1heSBkZXBlbmQgb24gdGhlIHJlYXNvbiBmb3IgbXVsdGlob21pbmcN CiAgIChlLmcuIHJlc2lsaWVuY2UgZmFpbG92ZXIsIGxvYWQgYmFsYW5jaW5nLCBwb2xpY3ktYmFz ZWQgcm91dGluZywgb3INCiAgIG11bHRpaG9taW5nIGR1cmluZyBhbiBJUHY2IHJlbnVtYmVyaW5n IGV2ZW50KS4gIElQdjYgaW50cm9kdWNlcw0KICAgaW1wcm92ZWQgc3VwcG9ydCBmb3IgbXVsdGkt YWRkcmVzc2VkIGhvc3RzIHRocm91Z2ggdGhlIElQdjYgZGVmYXVsdA0KICAgYWRkcmVzcyBzZWxl Y3Rpb24gbWV0aG9kcyBkZXNjcmliZWQgaW4gUkZDMzQ4NCBbMTBdLiAgQSBtdWx0aWhvbWVkDQog ICBob3N0IG1heSB0aHVzIGhhdmUgdHdvIGFkZHJlc3Nlcywgb25lIHBlciBwcmVmaXggKHByb3Zp ZGVyKSwgYW5kDQogICBzZWxlY3Qgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgdG8g dXNlIGFzIGRlc2NyaWJlZCBpbiB0aGF0DQogICBSRkMuDQoNCjIuMi4gIFVuaXF1ZSBMb2NhbCBJ UHY2IEFkZHJlc3Nlcw0KDQogICBVTEFzIGhhdmUgcmVwbGFjZWQgdGhlIG9yaWdpbmFsbHkgY29u Y2VpdmVkIFNpdGUgTG9jYWwgYWRkcmVzc2VzIGluDQogICB0aGUgSVB2NiBhZGRyZXNzaW5nIGFy Y2hpdGVjdHVyZSwgZm9yIHJlYXNvbnMgZGVzY3JpYmVkIGluIFsxN10uDQogICBVTEFzIGltcHJv dmUgb24gc2l0ZSBsb2NhbHMgYnkgb2ZmZXJpbmcgYSBoaWdoIHByb2JhYmlsaXR5IG9mIHRoZQ0K ICAgZ2xvYmFsIHVuaXF1ZW5lc3Mgb2YgdGhlIHByZWZpeCB1c2VkLCB3aGljaCBjYW4gYmUgYmVu ZWZpY2lhbCBpbiB0aGUNCiAgIGNhc2Ugb2YgKGRlbGliZXJhdGUgb3IgYWNjaWRlbnRhbCkgbGVh a2FnZSwgb3Igd2hlcmUgbmV0d29ya3MgYXJlDQogICBtZXJnZWQuICBVTEFzIGFyZSBha2luIHRv IHRoZSBwcml2YXRlIGFkZHJlc3Mgc3BhY2UgWzFdIGFzc2lnbmVkIGZvcg0KICAgSVB2NCBuZXR3 b3Jrcy4NCg0KDQoNClZhbiBkZSBWZWxkZSwgZXQgYWwuICAgIEV4cGlyZXMgRGVjZW1iZXIgMywg MjAwNiAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgSVB2 NiBBZGRyZXNzaW5nIENvbnNpZGVyYXRpb25zICAgICAgICAgICAgSnVuZSAyMDA2DQoNCg0KICAg VGhlIFVMQSBhZGRyZXNzIHJhbmdlIGFsbG93cyBhIG5ldHdvcmsgYWRtaW5pc3RyYXRvciB0byBk ZXBsb3kgSVB2Ng0KICAgYWRkcmVzc2VzIG9uIHRoZWlyIG5ldHdvcmsgd2l0aG91dCBhc2tpbmcg Zm9yIGEgZ2xvYmFsbHkgdW5pcXVlDQogICByZWdpc3RlcmVkIElQdjYgYWRkcmVzcyByYW5nZS4g IEEgVUxBIHByZWZpeCBpcyA0OCBiaXRzLCBpLmUuIGEgLzQ4LA0KICAgdGhlIHNhbWUgYXMgdGhl IGN1cnJlbnRseSByZWNvbW1lbmRlZCBhbGxvY2F0aW9uIGZvciBhIHNpdGUgZnJvbSB0aGUNCiAg IGdsb2JhbGx5IHJvdXRhYmxlIElQdjYgYWRkcmVzcyBzcGFjZSBbN10uDQoNCiAgIFVMQXMgcHJv dmlkZSB0aGUgbWVhbnMgdG8gZGVwbG95IGEgZml4ZWQgYWRkcmVzc2luZyBzY2hlbWUgdGhhdCBp cw0KICAgbm90IGFmZmVjdGVkIGJ5IGEgY2hhbmdlIGluIHNlcnZpY2UgcHJvdmlkZXIgYW5kIHRo ZSBjb3JyZXNwb25kaW5nIFBBDQogICBnbG9iYWwgYWRkcmVzc2VzLiAgSW50ZXJuYWwgb3BlcmF0 aW9uIG9mIHRoZSBuZXR3b3JrIGlzIHRodXMNCiAgIHVuYWZmZWN0ZWQgZHVyaW5nIHJlbnVtYmVy aW5nIGV2ZW50cy4gIE5ldmVydGhlbGVzcywgdGhpcyB0eXBlIG9mDQogICBhZGRyZXNzIG11c3Qg YmUgdXNlZCB3aXRoIGNhdXRpb24uDQoNCiAgIEEgc2l0ZSB1c2luZyBVTEFzIG1heSBvciBtYXkg bm90IGFsc28gZGVwbG95IGdsb2JhbHMuICBJbiBhbiBpc29sYXRlZA0KICAgbmV0d29yayBVTEFz IG1heSBiZSBkZXBsb3llZCBvbiB0aGVpciBvd24uICBJbiBhIGNvbm5lY3RlZCBuZXR3b3JrLA0K ICAgdGhhdCBhbHNvIGRlcGxveXMgZ2xvYmFsIGFkZHJlc3NlcywgYm90aCBtYXkgYmUgZGVwbG95 ZWQsIHN1Y2ggdGhhdA0KICAgaG9zdHMgYmVjb21lIG11bHRpYWRkcmVzc2VkIChvbmUgZ2xvYmFs IGFuZCBvbmUgVUxBIGFkZHJlc3MpIGFuZCB0aGUNCiAgIElQdjYgZGVmYXVsdCBhZGRyZXNzIHNl bGVjdGlvbiBhbGdvcml0aG0gd2lsbCBwaWNrIHRoZSBhcHByb3ByaWF0ZQ0KICAgc291cmNlIGFu ZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgdG8gdXNlLCBlLmcuICBVTEFzIHdpbGwgYmUgc2VsZWN0 ZWQNCiAgIHdoZXJlIGJvdGggdGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gaG9zdHMgaGF2ZSBV TEEgYWRkcmVzc2VzLg0KICAgQmVjYXVzZSBhIFVMQSBhbmQgYSBnbG9iYWwgc2l0ZSBwcmVmaXgg YXJlIGJvdGggLzQ4IGxlbmd0aCwgYW4NCiAgIGFkbWluaXN0cmF0b3IgY2FuIGNob29zZSB0byB1 c2UgdGhlIHNhbWUgc3VibmV0dGluZyAoYW5kIGhvc3QNCiAgIGFkZHJlc3NpbmcpIHBsYW4gZm9y IGJvdGggcHJlZml4ZXMuDQoNCiAgIEFzIGFuIGV4YW1wbGUgb2YgdGhlIHByb2JsZW1zIFVMQXMg bWF5IGNhdXNlLCB3aGVuIHVzaW5nIElQdjYNCiAgIG11bHRpY2FzdCB3aXRoaW4gdGhlIG5ldHdv cmssIHRoZSBJUHY2IGRlZmF1bHQgYWRkcmVzcyBzZWxlY3Rpb24NCiAgIGFsZ29yaXRobSBwcmVm ZXJzIHRoZSBVTEEgYWRkcmVzcyBhcyB0aGUgc291cmNlIGFkZHJlc3MgZm9yIHRoZSBJUHY2DQog ICBtdWx0aWNhc3Qgc3RyZWFtcy4gIFRoaXMgaXMgTk9UIGEgdmFsaWQgb3B0aW9uIHdoZW4gc2Vu ZGluZyBhbiBJUHY2DQogICBtdWx0aWNhc3Qgc3RyZWFtIHRvIHRoZSBJUHY2IEludGVybmV0IGZv ciB0d28gcmVhc29ucy4gIEZvciBvbmUsDQogICB0aGVzZSBhZGRyZXNzZXMgYXJlIG5vdCBnbG9i YWxseSByb3V0YWJsZSBzbyBSUEYgY2hlY2tzIGZvciBzdWNoDQogICB0cmFmZmljIHdpbGwgZmFp bCBvdXRzaWRlIHRoZSBpbnRlcm5hbCBuZXR3b3JrLiAgVGhlIG90aGVyIHJlYXNvbiBpcw0KICAg dGhhdCB0aGUgdHJhZmZpYyB3aWxsIGxpa2VseSBub3QgY3Jvc3MgdGhlIG5ldHdvcmsgYm91bmRh cnkgZHVlIHRvDQogICBtdWx0aWNhc3QgZG9tYWluIGNvbnRyb2wgYW5kIHBlcmltZXRlciBzZWN1 cml0eSBwb2xpY2llcy4NCg0KICAgSW4gcHJpbmNpcGFsIFVMQXMgYWxsb3cgZWFzaWVyIG5ldHdv cmsgbWVyZ2VycyB0aGFuIFJGQzE5MTggYWRkcmVzc2VzDQogICBkbyBmb3IgSVB2NCBiZWNhdXNl IFVMQSBwcmVmaXhlcyBoYXZlIGEgaGlnaCBwcm9iYWJpbGl0eSBvZg0KICAgdW5pcXVlbmVzcywg aWYgdGhlIHByZWZpeCBpcyBjaG9zZW4gYXMgZGVzY3JpYmVkIGluIHRoZSBSRkMuDQoNCiAgIFRo ZSB1c2FnZSBvZiBVTEFzIHNob3VsZCBiZSBjYXJlZnVsbHkgY29uc2lkZXJlZCBldmVuIHdoZW4g bm90DQogICBhdHRhY2hlZCB0byB0aGUgSVB2NiBJbnRlcm5ldCBkdWUgdG8gdGhlIHBvdGVudGlh bCBmb3IgYWRkZWQNCiAgIGNvbXBsZXhpdHkgd2hlbiBjb25uZWN0aW5nIHRvIHRoZSBJbnRlcm5l dCBhdCBzb21lIHBvaW50IGluIHRoZQ0KICAgZnV0dXJlLg0KDQoyLjMuICA2Qm9uZSBBZGRyZXNz IFNwYWNlDQoNCiAgIFRoZSA2Qm9uZSBhZGRyZXNzIHNwYWNlIHdhcyB1c2VkIGJlZm9yZSB0aGUg UklScyBzdGFydGVkIHRvDQogICBkaXN0cmlidXRlICdwcm9kdWN0aW9uJyBJUHY2IHByZWZpeGVz LiAgVGhlIDZCb25lIHByZWZpeGVzIGhhdmUgYQ0KICAgY29tbW9uIGZpcnN0IDE2IGJpdHMgaW4g dGhlIElQdjYgUHJlZml4IG9mIDNGRkU6Oi8xNi4gIFRoaXMgYWRkcmVzcw0KICAgcmFuZ2UgaXMg ZGVwcmVjYXRlZCBhcyBvZiA2dGggSnVuZSAyMDA2IFsxNV0gYW5kIHNob3VsZCBiZSBhdm9pZGVk IG9uDQoNCg0KDQpWYW4gZGUgVmVsZGUsIGV0IGFsLiAgICBFeHBpcmVzIERlY2VtYmVyIDMsIDIw MDYgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIElQdjYg QWRkcmVzc2luZyBDb25zaWRlcmF0aW9ucyAgICAgICAgICAgIEp1bmUgMjAwNg0KDQoNCiAgIGFu eSBuZXcgSVB2NiBuZXR3b3JrIGRlcGxveW1lbnRzLiAgU2l0ZXMgdXNpbmcgNmJvbmUgYWRkcmVz cyBzcGFjZQ0KICAgc2hvdWxkIHJlbnVtYmVyIHRvIHByb2R1Y3Rpb24gYWRkcmVzcyBzcGFjZSB1 c2luZyBwcm9jZWR1cmVzIGFzDQogICBkZWZpbmVkIGluIFsyMV0uDQoNCjIuNC4gIE5ldHdvcmsg TGV2ZWwgRGVzaWduIENvbnNpZGVyYXRpb25zDQoNCiAgIElQdjYgcHJvdmlkZXMgbmV0d29yayBh ZG1pbmlzdHJhdG9ycyB3aXRoIGEgc2lnbmlmaWNhbnRseSBsYXJnZXINCiAgIGFkZHJlc3Mgc3Bh Y2UsIGVuYWJsaW5nIHRoZW0gdG8gYmUgdmVyeSBjcmVhdGl2ZSBpbiBob3cgdGhleSBjYW4NCiAg IGRlZmluZSBsb2dpY2FsIGFuZCBwcmFjdGljYWwgYWRkcmVzcyBwbGFucy4gIFRoZSBzdWJuZXR0 aW5nIG9mDQogICBhc3NpZ25lZCBwcmVmaXhlcyBjYW4gYmUgZG9uZSBiYXNlZCBvbiB2YXJpb3Vz IGxvZ2ljYWwgc2NoZW1lcyB0aGF0DQogICBpbnZvbHZlIGZhY3RvcnMgc3VjaCBhczoNCiAgIG8g IEdlb2dyYXBoaWNhbCBCb3VuZGFyaWVzIC0gYnkgYXNzaWduaW5nIGEgY29tbW9uIHByZWZpeCB0 byBhbGwNCiAgICAgIHN1Ym5ldHMgd2l0aGluIGEgZ2VvZ3JhcGhpY2FsIGFyZWEuDQogICBvICBP cmdhbml6YXRpb25hbCBCb3VuZGFyaWVzIC0gYnkgYXNzaWduaW5nIGEgY29tbW9uIHByZWZpeCB0 byBhbg0KICAgICAgZW50aXJlIG9yZ2FuaXphdGlvbiBvciBncm91cCB3aXRoaW4gYSBjb3Jwb3Jh dGUgaW5mcmFzdHJ1Y3R1cmUuDQogICBvICBTZXJ2aWNlIFR5cGUgLSBieSByZXNlcnZpbmcgY2Vy dGFpbiBwcmVmaXhlcyBmb3IgcHJlZGVmaW5lZA0KICAgICAgc2VydmljZXMgc3VjaCBhczogVm9J UCwgQ29udGVudCBEaXN0cmlidXRpb24sIHdpcmVsZXNzIHNlcnZpY2VzLA0KICAgICAgSW50ZXJu ZXQgQWNjZXNzLCBldGMuDQogICBTdWNoIGxvZ2ljYWwgYWRkcmVzc2luZyBwbGFucyBoYXZlIHRo ZSBwb3RlbnRpYWwgdG8gc2ltcGxpZnkgbmV0d29yaw0KICAgb3BlcmF0aW9ucyBhbmQgc2Vydmlj ZSBvZmZlcmluZ3MsIGFuZCB0byBzaW1wbGlmeSBuZXR3b3JrIG1hbmFnZW1lbnQNCiAgIGFuZCB0 cm91Ymxlc2hvb3RpbmcuICBBIHZlcnkgbGFyZ2UgbmV0d29yayB3b3VsZCBhbHNvIGhhdmUgbm8g bmVlZCB0bw0KICAgY29uc2lkZXIgdXNpbmcgcHJpdmF0ZSBhZGRyZXNzIHNwYWNlIGZvciBpdHMg aW5mcmFzdHJ1Y3R1cmUgZGV2aWNlcywNCiAgIHNpbXBsaWZ5aW5nIG5ldHdvcmsgbWFuYWdlbWVu dC4NCg0KICAgVGhlIG5ldHdvcmsgZGVzaWduZXIgbXVzdCBob3dldmVyIGtlZXAgaW4gbWluZCBz ZXZlcmFsIGZhY3RvcnMgd2hlbg0KICAgZGV2ZWxvcGluZyB0aGVzZSBuZXcgYWRkcmVzc2luZyBz Y2hlbWVzOg0KICAgbyAgUHJlZml4IEFnZ3JlZ2F0aW9uIC0gVGhlIGxhcmdlciBJUHY2IGFkZHJl c3NlcyBjYW4gbGVhZCB0byBsYXJnZXINCiAgICAgIHJvdXRpbmcgdGFibGVzIHVubGVzcyBuZXR3 b3JrIGRlc2lnbmVycyBhcmUgYWN0aXZlbHkgcHVyc3VpbmcNCiAgICAgIGFnZ3JlZ2F0aW9uLiAg V2hpbGUgcHJlZml4IGFnZ3JlZ2F0aW9uIHdpbGwgYmUgZW5mb3JjZWQgYnkgdGhlDQogICAgICBz ZXJ2aWNlIHByb3ZpZGVyLCBpdCBpcyBiZW5lZmljaWFsIGZvciB0aGUgaW5kaXZpZHVhbA0KICAg ICAgb3JnYW5pemF0aW9ucyB0byBvYnNlcnZlIHRoZSBzYW1lIHByaW5jaXBsZXMgaW4gdGhlaXIg bmV0d29yaw0KICAgICAgZGVzaWduIHByb2Nlc3MuDQogICBvICBOZXR3b3JrIGdyb3d0aCAtIFRo ZSBhbGxvY2F0aW9uIG1lY2hhbmlzbSBmb3IgZmxleGlibGUgZ3Jvd3RoIG9mIGENCiAgICAgIG5l dHdvcmsgcHJlZml4LCBkb2N1bWVudGVkIGluIFJGQzM1MzEgWzExXSBjYW4gYmUgdXNlZCB0byBh bGxvdw0KICAgICAgdGhlIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgdG8gZ3JvdyBhbmQgYmUgbnVt YmVyZWQgaW4gYSB3YXkgdGhhdA0KICAgICAgaXMgbGlrZWx5IHRvIHByZXNlcnZlIGFnZ3JlZ2F0 aW9uICh0aGUgcGxhbiBsZWF2ZXMgJ2hvbGVzJyBmb3INCiAgICAgIGdyb3d0aCkuDQogICBvICBV TEEgdXNhZ2UgaW4gbGFyZ2UgbmV0d29ya3MgLSBOZXR3b3JrcyB3aGljaCBoYXZlIGEgbGFyZ2Ug bnVtYmVyDQogICAgICBvZiAnc2l0ZXMnIHRoYXQgZWFjaCBkZXBsb3kgYSBVTEEgcHJlZml4IHdo aWNoIHdpbGwgYnkgZGVmYXVsdCBiZQ0KICAgICAgYSAncmFuZG9tJyAvNDggdW5kZXIgZmMwMDo6 Lzcgd2lsbCBoYXZlIG5vIGFnZ3JlZ2F0aW9uIG9mIHRob3NlDQogICAgICBwcmVmaXhlcy4gIFRo dXMgdGhlIGVuZCByZXN1bHQgbWF5IGJlIGN1bWJlcnNvbWUgYmVjYXVzZSB0aGUNCiAgICAgIG5l dHdvcmsgd2lsbCBoYXZlIGxhcmdlIGFtb3VudHMgb2Ygbm9uLWFnZ3JlZ2F0ZWQgVUxBIHByZWZp eGVzLg0KICAgICAgSG93ZXZlciwgdGhlcmUgaXMgbm8gcnVsZSB0byBkaXNhbGxvdyBsYXJnZSBu ZXR3b3JrcyB0byB1c2UgYQ0KICAgICAgc2luZ2xlIFVMQSBmb3IgYWxsICdzaXRlcycsIGFzIGEg VUxBIHN0aWxsIHByb3ZpZGVzIDE2IGJpdHMgZm9yDQogICAgICBzdWJuZXR0aW5nIHRvIGJlIHVz ZWQgaW50ZXJuYWxseS4NCg0KDQoNCg0KDQoNClZhbiBkZSBWZWxkZSwgZXQgYWwuICAgIEV4cGly ZXMgRGVjZW1iZXIgMywgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgSVB2NiBBZGRyZXNzaW5nIENvbnNpZGVyYXRpb25zICAgICAgICAgICAgSnVu ZSAyMDA2DQoNCg0KMi40LjEuICBTaXppbmcgdGhlIE5ldHdvcmsgQWxsb2NhdGlvbg0KDQogICBX ZSBkbyBub3QgZGlzY3VzcyBoZXJlIGhvdyBhIG5ldHdvcmsgZGVzaWduZXIgc2l6ZXMgdGhlaXIg YXBwbGljYXRpb24NCiAgIGZvciBhZGRyZXNzIHNwYWNlLiAgQnkgZGVmYXVsdCBhIHNpdGUgd2ls bCByZWNlaXZlIGEgLzQ4IHByZWZpeCBbN10uDQogICBUaGUgZGVmYXVsdCBwcm92aWRlciBhbGxv Y2F0aW9uIHZpYSB0aGUgUklScyBpcyBjdXJyZW50bHkgYSAvMzIgWzI3XS4NCiAgIFRoZXNlIGFs bG9jYXRpb25zIGFyZSBpbmRpY2F0b3JzIGZvciBhIGZpcnN0IGFsbG9jYXRpb24gZm9yIGENCiAg IG5ldHdvcmsuICBEaWZmZXJlbnQgc2l6ZXMgbWF5IGJlIG9idGFpbmVkIGJhc2VkIG9uIHRoZSBh bnRpY2lwYXRlZA0KICAgYWRkcmVzcyB1c2FnZSBbMjddLiAgVGhlcmUgYXJlIGV4YW1wbGVzIG9m IGFsbG9jYXRpb25zIGFzIGxhcmdlIGFzDQogICAvMTkgaGF2aW5nIGJlZW4gbWFkZSBmcm9tIFJJ UnMgdG8gcHJvdmlkZXJzIGF0IHRoZSB0aW1lIG9mIHdyaXRpbmcuDQoNCjIuNC4yLiAgQWRkcmVz cyBTcGFjZSBDb25zZXJ2YXRpb24NCg0KICAgRGVzcGl0ZSB0aGUgbGFyZ2UgSVB2NiBhZGRyZXNz IHNwYWNlIHdoaWNoIGVuYWJsZXMgZWFzaWVyIHN1Ym5ldHRpbmcsDQogICBpdCBzdGlsbCBpcyBp bXBvcnRhbnQgdG8gZW5zdXJlIGFuIGVmZmljaWVudCB1c2Ugb2YgdGhpcyByZXNvdXJjZS4NCiAg IFNvbWUgYWRkcmVzc2luZyBzY2hlbWVzLCB3aGlsZSBmYWNpbGl0YXRpbmcgYWdncmVnYXRpb24g YW5kDQogICBtYW5hZ2VtZW50LCBjb3VsZCBsZWFkIHRvIHNpZ25pZmljYW50IG51bWJlcnMgb2Yg YWRkcmVzc2VzIGJlaW5nDQogICB1bnVzZWQuICBBZGRyZXNzIGNvbnNlcnZhdGlvbiByZXF1aXJl bWVudHMgYXJlIGxlc3Mgc3RyaW5nZW50IGluIElQdjYNCiAgIGJ1dCB0aGV5IHNob3VsZCBzdGls bCBiZSBvYnNlcnZlZC4NCg0KICAgVGhlIHByb3Bvc2VkIEhEIFs4XSB2YWx1ZSBmb3IgSVB2NiBp cyAwLjk0IGNvbXBhcmVkIHRvIHRoZSBjdXJyZW50DQogICB2YWx1ZSBvZiAwLjk2IGZvciBJUHY0 LiAgTm90ZSB0aGF0IGZvciBJUHY2IEhEIGlzIGNhbGN1bGF0ZWQgZm9yDQogICBzaXRlcyAoaS5l LiBvbiBhIGJhc2lzIG9mIC80OCksIGluc3RlYWQgb2YgYmFzZWQgb24gYWRkcmVzc2VzIGxpa2UN CiAgIHdpdGggSVB2NC4NCg0KDQozLiAgU3VibmV0IFByZWZpeCBDb25zaWRlcmF0aW9ucw0KDQog ICBUaGlzIHNlY3Rpb24gYW5hbHl6ZXMgdGhlIGNvbnNpZGVyYXRpb25zIGFwcGxpZWQgdG8gZGVm aW5lIHRoZSBzdWJuZXQNCiAgIHByZWZpeCBvZiB0aGUgSVB2NiBhZGRyZXNzZXMuICBUaGUgYm91 bmRhcmllcyBvZiB0aGUgc3VibmV0IHByZWZpeA0KICAgYWxsb2NhdGlvbiBhcmUgc3BlY2lmaWVk IGluIFJGQzQyOTEgWzIzXS4gIEluIHRoaXMgZG9jdW1lbnQgd2UNCiAgIGFuYWx5emUgdGhlaXIg cHJhY3RpY2FsIGltcGxpY2F0aW9ucy4gIEJhc2VkIG9uIFJGQzQyOTEgWzIzXSBpdCBpcw0KICAg bGVnYWwgZm9yIGFueSBJUHY2IHVuaWNhc3QgYWRkcmVzcyBzdGFydGluZyB3aXRoIGJpbmFyeSBh ZGRyZXNzICcwMDAnDQogICB0byBoYXZlIGEgc3VibmV0IHByZWZpeCBsYXJnZXIgdGhhbiwgc21h bGxlciB0aGFuIG9yIG9mIGVxdWFsIHRvIDY0DQogICBiaXRzLiAgRWFjaCBvZiB0aGVzZSB0aHJl ZSBvcHRpb25zIGlzIGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQozLjEuICBDb25zaWRl cmF0aW9ucyBmb3Igc3VibmV0IHByZWZpeGVzIHNob3J0ZXIgdGhlbiAvNjQNCg0KICAgQW4gYWxs b2NhdGlvbiBvZiBhIHByZWZpeCBzaG9ydGVyIHRoZW4gNjQgYml0cyB0byBhIG5vZGUgb3IgaW50 ZXJmYWNlDQogICBpcyBiYWQgcHJhY3RpY2UuICBUaGUgc2hvcnRlc3Qgc3VibmV0IHByZWZpeCB0 aGF0IGNvdWxkIHRoZW9yZXRpY2FsbHkNCiAgIGJlIGFzc2lnbmVkIHRvIGFuIGludGVyZmFjZSBv ciBub2RlIGlzIGxpbWl0ZWQgYnkgdGhlIHNpemUgb2YgdGhlDQogICBuZXR3b3JrIHByZWZpeCBh bGxvY2F0ZWQgdG8gdGhlIG9yZ2FuaXphdGlvbi4NCg0KICAgQSBwb3NzaWJsZSByZWFzb24gZm9y IGNob29zaW5nIHRoZSBzdWJuZXQgcHJlZml4IGZvciBhbiBpbnRlcmZhY2UNCiAgIHNob3J0ZXIg dGhlbiAvNjQgaXMgdGhhdCBpdCB3b3VsZCBhbGxvdyBtb3JlIG5vZGVzIHRvIGJlIGF0dGFjaGVk IHRvDQogICB0aGF0IGludGVyZmFjZSBjb21wYXJlZCB0byBhIHByZXNjcmliZWQgbGVuZ3RoIG9m IDY0IGJpdHMuICBUaGlzDQogICBob3dldmVyIGlzIHVubmVjZXNzYXJ5IGNvbnNpZGVyaW5nIHRo YXQgMl42NCBwcm92aWRlcyBwbGVudHkgb2Ygbm9kZQ0KICAgYWRkcmVzc2VzIGZvciBhIHdlbGwg ZGVzaWduZWQgSVB2NiBuZXR3b3JrLiAgTGF5ZXIgdHdvIHRlY2hub2xvZ2llcw0KICAgYXJlIHVu bGlrZWx5IHRvIHN1cHBvcnQgc3VjaCBsYXJnZSBudW1iZXJzIG9mIG5vZGVzIHdpdGhpbiBhIHNp bmdsZQ0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAy MDA2ICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2 IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIwMDYNCg0KDQogICBs aW5rIChlLmcuICBFdGhlcm5ldCBsaW1pdGVkIHRvIDQ4LWJpdHMgb2YgaG9zdHMpDQoNCiAgIFRo ZSBzdWJuZXQgcHJlZml4IGFzc2lnbm1lbnRzIGNhbiBiZSBtYWRlIGVpdGhlciBieSBtYW51YWwN CiAgIGNvbmZpZ3VyYXRpb24sIGJ5IGEgc3RhdGVmdWwgSG9zdCBDb25maWd1cmF0aW9uIFByb3Rv Y29sIFs5XSBvciBieSBhDQogICBzdGF0ZWZ1bCBwcmVmaXggZGVsZWdhdGlvbiBtZWNoYW5pc20g WzE0XS4NCg0KMy4yLiAgQ29uc2lkZXJhdGlvbnMgZm9yIC82NCBwcmVmaXhlcw0KDQogICBCYXNl ZCBvbiBSRkMzMTc3IFs3XSwgNjQgYml0cyBpcyB0aGUgcHJlc2NyaWJlZCBzdWJuZXQgcHJlZml4 IGxlbmd0aA0KICAgdG8gYWxsb2NhdGUgdG8gaW50ZXJmYWNlcyBhbmQgbm9kZXMuDQoNCiAgIFdo ZW4gdXNpbmcgYSAvNjQgc3VibmV0IGxlbmd0aCwgdGhlIGFkZHJlc3MgYXNzaWdubWVudCBmb3Ig dGhlc2UNCiAgIGFkZHJlc3NlcyBjYW4gYmUgbWFkZSBlaXRoZXIgYnkgbWFudWFsIGNvbmZpZ3Vy YXRpb24sIGJ5IGEgc3RhdGVmdWwNCiAgIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBbOV0g WzE2XSBvciBieSBzdGF0ZWxlc3MNCiAgIGF1dG9jb25maWd1cmF0aW9uIFsyXS4NCg0KICAgTm90 ZSB0aGF0IFJGQzMxNzcgc3Ryb25nbHkgcHJlc2NyaWJlcyA2NCBiaXQgc3VibmV0cyBmb3IgZ2Vu ZXJhbA0KICAgdXNhZ2UsIGFuZCB0aGF0IHN0YXRlbGVzcyBhdXRvY29uZmlndXJhdGlvbiBvcHRp b24gaXMgb25seSBkZWZpbmVkDQogICBmb3IgNjQgYml0IHN1Ym5ldHMuDQoNCjMuMy4gIENvbnNp ZGVyYXRpb25zIGZvciBzdWJuZXQgcHJlZml4ZXMgbG9uZ2VyIHRoZW4gLzY0DQoNCiAgIEFkZHJl c3Mgc3BhY2UgY29uc2VydmF0aW9uIGlzIHRoZSBtYWluIG1vdGl2YXRpb24gZm9yIHVzaW5nIGEg c3VibmV0DQogICBwcmVmaXggbGVuZ3RoIGxvbmdlciB0aGFuIDY0IGJpdHMuDQoNCiAgIFRoZSBh ZGRyZXNzIGFzc2lnbm1lbnQgY2FuIGJlIG1hZGUgZWl0aGVyIGJ5IG1hbnVhbCBjb25maWd1cmF0 aW9uIG9yDQogICBieSBhIHN0YXRlZnVsIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbCBbOV0u DQoNCiAgIFdoZW4gYXNzaWduaW5nIGEgc3VibmV0IHByZWZpeCBvZiBtb3JlIHRoZW4gODAgYml0 cywgYWNjb3JkaW5nIHRvDQogICBSRkM0MjkxIFsyM10gInUiIGFuZCAiZyIgYml0cyAocmVzcGVj dGl2ZWx5IHRoZSA4MXN0IGFuZCA4Mm5kIGJpdCkNCiAgIG5lZWQgdG8gYmUgdGFrZW4gaW50byBj b25zaWRlcmF0aW9uIGFuZCBzaG91bGQgYmUgc2V0IGNvcnJlY3RseS4gIEluDQogICBjdXJyZW50 bHkgaW1wbGVtZW50ZWQgSVB2NiBwcm90b2NvbCBzdGFja3MsIHRoZSByZWxldmFuY2Ugb2YgdGhl ICJ1Ig0KICAgKHVuaXZlcnNhbC9sb2NhbCkgYml0IGFuZCAiZyIgKHRoZSBpbmRpdmlkdWFsL2dy b3VwKSBiaXQgYXJlIG1hcmdpbmFsDQogICBhbmQgdHlwaWNhbGx5IHdpbGwgbm90IHNob3cgYW4g aXNzdWUgd2hlbiBjb25maWd1cmVkIHdyb25nbHksIGhvd2V2ZXINCiAgIGZ1dHVyZSBpbXBsZW1l bnRhdGlvbnMgbWF5IHR1cm4gb3V0IGRpZmZlcmVudGx5Lg0KDQogICBXaGVuIHVzaW5nIHN1Ym5l dCBsZW5ndGhzIGxvbmdlciB0aGVuIDY0IGJpdHMsIGl0IGlzIGltcG9ydGFudCB0bw0KICAgYXZv aWQgc2VsZWN0aW5nIGFkZHJlc3NlcyB0aGF0IG1heSBoYXZlIGEgcHJlZGVmaW5lZCB1c2UgYW5k IGNvdWxkDQogICBjb25mdXNlIElQdjYgcHJvdG9jb2wgc3RhY2tzLiAgVGhlIGFsdGVybmF0ZSB1 c2FnZSBtYXkgbm90IGJlIGENCiAgIHNpbXBsZSB1bmljYXN0IGFkZHJlc3MgaW4gYWxsIGNhc2Vz LiAgVGhlIGZvbGxvd2luZyBwb2ludHMgc2hvdWxkIGJlDQogICBjb25zaWRlcmVkIHdoZW4gc2Vs ZWN0aW5nIGEgc3VibmV0IGxlbmd0aCBsb25nZXIgdGhlbiA2NCBiaXRzLg0KDQozLjMuMS4gIEFu eWNhc3QgYWRkcmVzc2VzDQoNCjMuMy4xLjEuICBTdWJuZXQgUm91dGVyIEFueWNhc3QgQWRkcmVz cw0KDQogICBSRkM0MjkxIFsyM10gcHJvdmlkZXMgYSBkZWZpbml0aW9uIGZvciB0aGUgcmVxdWly ZWQgU3VibmV0IFJvdXRlcg0KICAgQW55Y2FzdCBBZGRyZXNzIGFzIGZvbGxvd3M6DQoNCg0KDQpW YW4gZGUgVmVsZGUsIGV0IGFsLiAgICBFeHBpcmVzIERlY2VtYmVyIDMsIDIwMDYgICAgICAgICAg ICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIElQdjYgQWRkcmVzc2luZyBD b25zaWRlcmF0aW9ucyAgICAgICAgICAgIEp1bmUgMjAwNg0KDQoNCiAgICB8ICAgICAgICAgICAg ICAgICAgIG4gYml0cyAgICAgICAgICAgICAgICAgICB8ICAgMTI4LW4gYml0cyAgIHwNCiAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tLSsNCiAgICB8ICAgICAgICAgICAgICAgc3VibmV0IHByZWZpeCAgICAgICAgICAgICAgICB8 IDAwMDAwMDAwMDAwMDAwIHwNCiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQoNCg0KICAgSXQgaXMgcmVjb21tZW5k ZWQgdG8gYXZvaWQgYWxsb2NhdGluZyB0aGlzIElQdjYgYWRkcmVzcyB0byBhIGRldmljZQ0KICAg d2hpY2ggaXMgbm90IGEgcm91dGVyLiAgTm8gYWRkaXRpb25hbCBkZXBlbmRlbmNpZXMgZm9yIHRo ZSBzdWJuZXQNCiAgIHByZWZpeCB3aGlsZSB0aGUgRVVJLTY0IGFuZCBhbiBJSUQgZGVwZW5kZW5j aWVzIHdpbGwgYmUgZGlzY3Vzc2VkDQogICBsYXRlciBpbiB0aGlzIGRvY3VtZW50Lg0KDQozLjMu MS4yLiAgUmVzZXJ2ZWQgSVB2NiBTdWJuZXQgQW55Y2FzdCBBZGRyZXNzZXMNCg0KICAgUkZDMjUy NiBbNF0gc3RhdGVkIHRoYXQgd2l0aGluIGVhY2ggc3VibmV0LCB0aGUgaGlnaGVzdCAxMjggaW50 ZXJmYWNlDQogICBpZGVudGlmaWVyIHZhbHVlcyBhcmUgcmVzZXJ2ZWQgZm9yIGFzc2lnbm1lbnQg YXMgc3VibmV0IGFueWNhc3QNCiAgIGFkZHJlc3Nlcy4NCg0KICAgVGhlIGNvbnN0cnVjdGlvbiBv ZiBhIHJlc2VydmVkIHN1Ym5ldCBhbnljYXN0IGFkZHJlc3MgZGVwZW5kcyBvbiB0aGUNCiAgIHR5 cGUgb2YgSVB2NiBhZGRyZXNzZXMgdXNlZCB3aXRoaW4gdGhlIHN1Ym5ldCwgYXMgaW5kaWNhdGVk IGJ5IHRoZQ0KICAgZm9ybWF0IHByZWZpeCBpbiB0aGUgYWRkcmVzc2VzLg0KDQogICBUaGUgZmly c3QgdHlwZSBvZiBTdWJuZXQgUm91dGVyIEFueWNhc3QgYWRkcmVzc2VzIGhhdmUgYmVlbiBkZWZp bmVkDQogICBhcyBmb2xsb3dzIGZvciBFVUktNjQgZm9ybWF0Og0KDQoNCiAgICB8ICAgICAgICAg ICA2NCBiaXRzICAgICAgICAgICAgfCAgICAgIDU3IGJpdHMgICAgIHwgICA3IGJpdHMgICB8DQog ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tKw0KICAgIHwgICAgICAgIHN1Ym5ldCBwcmVmaXggICAgICAgICB8IDExMTExMTAx MTEuLi4xMTEgfCBhbnljYXN0IElEIHwNCiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQoNCg0KICAgVGhlIGFueWNhc3Qg YWRkcmVzcyBzdHJ1Y3R1cmUgaW1wbGllcyB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBhdm9pZA0K ICAgY3JlYXRpbmcgYSBzdWJuZXQgcHJlZml4IHdoZXJlIHRoZSBiaXRzIDY1IHRvIDEyMSBhcmUg ZGVmaW5lZCBhcw0KICAgIjExMTExMTAxMTEuLi4xMTEiICg1NyBiaXRzIGluIHRvdGFsKSBzbyB0 aGF0IGNvbmZ1c2lvbiBjYW4gYmUNCiAgIGF2b2lkZWQuDQoNCiAgIEZvciBvdGhlciBJUHY2IGFk ZHJlc3MgdHlwZXMgKHRoYXQgaXMsIHdpdGggZm9ybWF0IHByZWZpeGVzIG90aGVyDQogICB0aGFu IHRob3NlIGxpc3RlZCBhYm92ZSksIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmllciBpcyBub3QgaW4g RVVJLTY0DQogICBmb3JtYXQgYW5kIG1heSBiZSBvdGhlciB0aGFuIDY0IGJpdHMgaW4gbGVuZ3Ro OyB0aGVzZSByZXNlcnZlZCBzdWJuZXQNCiAgIGFueWNhc3QgYWRkcmVzc2VzIGZvciBzdWNoIGFk ZHJlc3MgdHlwZXMgYXJlIGNvbnN0cnVjdGVkIGFzIGZvbGxvd3M6DQoNCg0KICAgIHwgICAgICAg ICAgIG4gYml0cyAgICAgICAgICAgICB8ICAgIDEyMS1uIGJpdHMgICAgfCAgIDcgYml0cyAgIHwN CiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rDQogICAgfCAgICAgICAgc3VibmV0IHByZWZpeCAgICAgICAgIHwgMTExMTEx MS4uLjExMTExMSB8IGFueWNhc3QgSUQgfA0KICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KDQoNClZhbiBkZSBWZWxk ZSwgZXQgYWwuICAgIEV4cGlyZXMgRGVjZW1iZXIgMywgMjAwNiAgICAgICAgICAgICAgIFtQYWdl IDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgSVB2NiBBZGRyZXNzaW5nIENvbnNpZGVyYXRp b25zICAgICAgICAgICAgSnVuZSAyMDA2DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgaW50ZXJmYWNlIGlkZW50aWZpZXIgZmllbGQgIHwNCg0KDQogICBJbiB0aGUg Y2FzZSBkaXNjdXNzZWQgYWJvdmUgdGhlcmUgaXMgbm8gYWRkaXRpb25hbCBkZXBlbmRlbmN5IGZv ciB0aGUNCiAgIHN1Ym5ldCBwcmVmaXggd2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBFVUktNjQg YW5kIGFuIElJRCBkZXBlbmRlbmN5Lg0KICAgVGhlc2Ugd2lsbCBiZSBkaXNjdXNzZWQgbGF0ZXIg aW4gdGhpcyBkb2N1bWVudC4NCg0KMy4zLjIuICBBZGRyZXNzZXMgdXNlZCBieSBFbWJlZGRlZC1S UCAoUkZDMzk1NikNCg0KICAgRW1iZWRkZWQtUlAgWzE4XSByZWZsZWN0cyB0aGUgY29uY2VwdCBv ZiBpbnRlZ3JhdGluZyB0aGUgUmVuZGV6dm91cw0KICAgUG9pbnQgKFJQKSBJUHY2IGFkZHJlc3Mg aW50byB0aGUgSVB2NiBtdWx0aWNhc3QgZ3JvdXAgYWRkcmVzcy4gIER1ZQ0KICAgdG8gdGhpcyBl bWJlZGRpbmcgYW5kIHRoZSBmYWN0IHRoYXQgdGhlIGxlbmd0aCBvZiB0aGUgSVB2NiBhZGRyZXNz DQogICBBTkQgdGhlIElQdjYgbXVsdGljYXN0IGFkZHJlc3MgYXJlIDEyOCBiaXRzLCBpdCBpcyBu b3QgcG9zc2libGUgdG8NCiAgIGhhdmUgdGhlIGNvbXBsZXRlIElQdjYgYWRkcmVzcyBvZiB0aGUg bXVsdGljYXN0IFJQIGVtYmVkZGVkIGFzIHN1Y2guDQoNCiAgIFRoaXMgcmVzdWx0ZWQgaW4gYSBy ZXN0cmljdGlvbiBvZiAxNSBwb3NzaWJsZSBSUC1hZGRyZXNzZXMgcGVyIHByZWZpeA0KICAgdGhh dCBjYW4gYmUgdXNlZCB3aXRoIGVtYmVkZGVkLVJQLiAgVGhlIHNwYWNlIGFzc2lnbmVkIGZvciB0 aGUNCiAgIGVtYmVkZGVkLVJQIGlzIGJhc2VkIG9uIHRoZSA0IGxvdyBvcmRlciBiaXRzLCB3aGls ZSB0aGUgcmVtYWluZGVyIG9mDQogICB0aGUgSW50ZXJmYWNlIElEIGlzIHNldCB0byBhbGwgJzAn Lg0KDQoNCiAgICAgICAgICAgICAgIFtJUHY2LXByZWZpeCAoNjQgYml0cyldWzYwIGJpdHMgYWxs ICcwJ11bUklJRF0NCg0KICAgICAgICAgICAgICAgICAgIFdoZXJlOiBbUklJRF0gPSA0IGJpdC4N Cg0KDQogICBUaGlzIGZvcm1hdCBpbXBsaWVzIHRoYXQgd2hlbiBzZWxlY3Rpbmcgc3VibmV0IHBy ZWZpeGVzIGxvbmdlciB0aGVuDQogICA2NCwgYW5kIHRoZSBiaXRzIGJleW9uZCB0aGUgNjR0aCBv bmUgYXJlIG5vbmUtemVybywgdGhlIHN1Ym5ldCBjYW4NCiAgIG5vdCB1c2UgZW1iZWRkZWQtUlAu DQoNCiAgIEluIGFkZGl0aW9uIGl0IGlzIGRpc2NvdXJhZ2VkIHRvIGFzc2lnbiBhIG1hdGNoaW5n IGVtYmVkZGVkLVJQIElQdjYNCiAgIGFkZHJlc3MgdG8gYSBkZXZpY2UgdGhhdCBpcyBub3QgYSBy ZWFsIE11bHRpY2FzdCBSZW5kZXp2b3VzIFBvaW50Lg0KDQozLjMuMy4gIElTQVRBUCBhZGRyZXNz ZXMNCg0KICAgSVNBVEFQIFsyNV0gaXMgYW4gYXV0b21hdGljIHR1bm5lbGluZyBwcm90b2NvbCB1 c2VkIHRvIHByb3ZpZGUgSVB2Ng0KICAgY29ubmVjdGl2aXR5IG92ZXIgYW4gSVB2NCBjYW1wdXMg b3IgZW50ZXJwcmlzZSBlbnZpcm9ubWVudC4gIEluIG9yZGVyDQogICB0byBsZXZlcmFnZSB0aGUg dW5kZXJseWluZyBJUHY0IGluZnJhc3RydWN0dXJlLCB0aGUgSVB2NiBhZGRyZXNzZXMNCiAgIGFy ZSBjb25zdHJ1Y3RlZCBpbiBhIHNwZWNpYWwgZm9ybWF0Lg0KDQogICBBbiBJUHY2IElTQVRBUCBb MjVdIGFkZHJlc3MgaGFzIHRoZSBJUHY0IGFkZHJlc3MgZW1iZWRkZWQsIGJhc2VkIG9uIGENCiAg IHByZWRlZmluZWQgc3RydWN0dXJlIHBvbGljeSB0aGF0IGlkZW50aWZpZXMgdGhlbSBhcyBhbiBJ U0FUQVAgWzI1XQ0KICAgYWRkcmVzcy4NCg0KDQogICAgICAgICAgICAgICAgW0lQdjYgUHJlZml4 ICg2NCBiaXRzKV1bMDAwMDo1RUZFXVtJUHY0IGFkZHJlc3NdDQoNCg0KDQoNCg0KVmFuIGRlIFZl bGRlLCBldCBhbC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJh dGlvbnMgICAgICAgICAgICBKdW5lIDIwMDYNCg0KDQogICBXaGVuIHVzaW5nIHN1Ym5ldCBwcmVm aXggbGVuZ3RoIGxvbmdlciB0aGVuIDY0IGJpdHMgaXQgaXMgcmVjb21tZW5kZWQNCiAgIHRoYXQg dGhhdCB0aGUgcG9ydGlvbiBvZiB0aGUgSVB2NiBwcmVmaXggZnJvbSBiaXQgNjUgdG8gdGhlIGVu ZCBvZg0KICAgdGhlIHN1Ym5ldCBwcmVmaXggZG9lcyBub3QgbWF0Y2ggd2l0aCB0aGUgd2VsbC1r bm93biBJU0FUQVAgWzAwMDA6DQogICA1RUZFXSBhZGRyZXNzIHBvcnRpb24uDQoNCiAgIEluIGl0 cyBhY3R1YWwgZGVmaW5pdGlvbiB0aGVyZSBpcyBubyBtdWx0aWNhc3Qgc3VwcG9ydCBvbiBJU0FU QVANCg0KMy4zLjQuICAvMTI2IGFkZHJlc3Nlcw0KDQogICBUaGUgMTI2IGJpdCBzdWJuZXQgcHJl Zml4ZXMgYXJlIHR5cGljYWxseSB1c2VkIGZvciBwb2ludC10by1wb2ludA0KICAgbGlua3Mgc2lt aWxhciB0byB0aGUgUkZDMzAyMSBbNV0gcmVjb21tZW5kYXRpb25zIGZvciBJUHY0LiAgVGhlIHVz YWdlDQogICBvZiB0aGlzIHN1Ym5ldCBhZGRyZXNzIGxlbmd0aCBkb2VzIG5vdCBsZWFkIHRvIGFu eSBhZGRpdGlvbmFsDQogICBjb25zaWRlcmF0aW9ucyBvdGhlciB0aGFuIHRoZSBvbmVzIGRpc2N1 c3NlZCBlYXJsaWVyIGluIHRoaXMgc2VjdGlvbiwNCiAgIHBhcnRpY3VsYXJseSB0aG9zZSByZWxh dGVkIHRvIHRoZSAidSIgYW5kICJnIiBiaXRzLg0KDQozLjMuNS4gIC8xMjcgYWRkcmVzc2VzDQoN CiAgIFRoZSB1c2FnZSBvZiB0aGUgLzEyNyBhZGRyZXNzZXMgaXMgbm90IHZhbGlkIGFuZCBzaG91 bGQgYmUgc3Ryb25nbHkNCiAgIGRpc2NvdXJhZ2VkIGFzIGRvY3VtZW50ZWQgaW4gUkZDMzYyNyBb MTNdLg0KDQozLjMuNi4gIC8xMjggYWRkcmVzc2VzDQoNCiAgIFRoZSAxMjggYml0IGFkZHJlc3Mg cHJlZml4IG1heSBiZSB1c2VkIGluIHRob3NlIHNpdHVhdGlvbnMgd2hlcmUgd2UNCiAgIGtub3cg dGhhdCBvbmUsIGFuZCBvbmx5IG9uZSBhZGRyZXNzIGlzIHN1ZmZpY2llbnQuICBFeGFtcGxlIHVz YWdlDQogICB3b3VsZCBiZSB0aGUgb2ZmLWxpbmsgbG9vcGJhY2sgYWRkcmVzcyBvZiBhIG5ldHdv cmsgZGV2aWNlLg0KDQogICBXaGVuIGNob29zaW5nIGEgMTI4IGJpdCBwcmVmaXgsIGl0IGlzIHJl Y29tbWVuZGVkIHRvIHRha2UgdGhlICJ1IiBhbmQNCiAgICJnIiBiaXRzIGludG8gY29uc2lkZXJh dGlvbiBhbmQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlcmUgaXMgbm8gb3ZlcmxhcA0KICAgd2l0aCBl aXRoZXIgdGhlIGZvbGxvd2luZyB3ZWxsLWtub3duIGFkZHJlc3NlczoNCiAgIG8gIFN1Ym5ldCBS b3V0ZXIgQW55Y2FzdCBBZGRyZXNzDQogICBvICBSZXNlcnZlZCBTdWJuZXQgQW55Y2FzdCBBZGRy ZXNzDQogICBvICBBZGRyZXNzZXMgdXNlZCBieSBFbWJlZGRlZC1SUA0KICAgbyAgSVNBVEFQIEFk ZHJlc3Nlcw0KDQoNCjQuICBBbGxvY2F0aW9uIG9mIHRoZSBJSUQgb2YgYW4gSVB2NiBBZGRyZXNz DQoNCiAgIEluIG9yZGVyIHRvIGhhdmUgYSBjb21wbGV0ZSBJUHY2IGFkZHJlc3MsIGFuIGludGVy ZmFjZSBtdXN0IGJlDQogICBhc3NvY2lhdGVkIGEgcHJlZml4IGFuZCBhbiBJbnRlcmZhY2UgSWRl bnRpZmllciAoSUlEKS4gIFNlY3Rpb24gMyBvZg0KICAgdGhpcyBkb2N1bWVudCBhbmFseXplZCB0 aGUgcHJlZml4IHNlbGVjdGlvbiBjb25zaWRlcmF0aW9ucy4gIFRoaXMNCiAgIHNlY3Rpb24gZGlz Y3Vzc2VzIHRoZSBlbGVtZW50cyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHdoZW4NCiAgIGFz c2lnbmluZyB0aGUgSUlEIHBvcnRpb24gb2YgdGhlIElQdjYgYWRkcmVzcy4NCg0KICAgVGhlcmUg YXJlIHZhcmlvdXMgd2F5cyB0byBhbGxvY2F0ZSBhbiBJUHY2IGFkZHJlc3MgdG8gYSBkZXZpY2Ug b3INCiAgIGludGVyZmFjZS4gIFRoZSBvcHRpb24gd2l0aCB0aGUgbGVhc3QgYW1vdW50IG9mIGNh dmVhdHMgZm9yIHRoZQ0KICAgbmV0d29yayBhZG1pbmlzdHJhdG9yIGlzIHRoYXQgb2YgRVVJLTY0 IFsyXSBiYXNlZCBhZGRyZXNzZXMuICBGb3IgdGhlDQogICBtYW51YWwgb3IgZHluYW1pYyBvcHRp b25zLCB0aGUgb3ZlcmxhcCB3aXRoIHdlbGwga25vd24gSVB2NiBhZGRyZXNzZXMNCiAgIHNob3Vs ZCBiZSBhdm9pZGVkLg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBEZWNl bWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIwMDYN Cg0KDQo0LjEuICBBdXRvbWF0aWMgRVVJLTY0IEZvcm1hdCBPcHRpb24NCg0KICAgV2hlbiB1c2lu ZyB0aGlzIG1ldGhvZCB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yIGhhcyB0byBhbGxvY2F0ZSBh DQogICB2YWxpZCA2NCBiaXQgc3VibmV0IHByZWZpeC4gIFRoZSBFVUktNjQgWzJdIGFsbG9jYXRp b24gcHJvY2VkdXJlIGNhbg0KICAgZnJvbSB0aGF0IG1vbWVudCBvbndhcmRzIGFzc2lnbiB0aGUg cmVtYWluaW5nIDY0IElJRCBiaXRzIGluIGENCiAgIHN0YXRlbGVzcyBtYW5uZXIuICBBbGwgdGhl IGNvbnNpZGVyYXRpb25zIGZvciBzZWxlY3RpbmcgYSB2YWxpZCBJSUQNCiAgIGhhdmUgYmVlbiBp bmNvcnBvcmF0ZWQgaW4gdGhlIEVVSS02NCBtZXRob2RvbG9neS4NCg0KNC4yLiAgVXNpbmcgUHJp dmFjeSBFeHRlbnNpb25zDQoNCiAgIFRoZSBtYWluIHB1cnBvc2Ugb2YgSUlEcyBnZW5lcmF0ZWQg YmFzZWQgb24gUkZDMzA0MSBbNl0gaXMgdG8gcHJvdmlkZQ0KICAgcHJpdmFjeSB0byB0aGUgZW50 aXR5IHVzaW5nIHRoaXMgYWRkcmVzcy4gIFdoaWxlIHRoZXJlIGFyZSBubw0KICAgcGFydGljdWxh ciBjb25zdHJhaW50cyBpbiB0aGUgdXNhZ2Ugb2YgdGhlc2UgYWRkcmVzc2VzIGFzIGRlZmluZWQg aW4NCiAgIFs2XSB0aGVyZSBhcmUgc29tZSBpbXBsaWNhdGlvbnMgdG8gYmUgYXdhcmUgb2Ygd2hl biB1c2luZyBwcml2YWN5DQogICBhZGRyZXNzZXMgYXMgZG9jdW1lbnRlZCBpbiBzZWN0aW9uIDQg b2YgUkZDMzA0MSBbNl06DQogICBvICBUaGUgcHJpdmFjeSBleHRlbnNpb24gYWxnb3JpdGhtIG1h eSBjb21wbGljYXRlIGZsZXhpYmlsaXR5IGluDQogICAgICBmdXR1cmUgdHJhbnNwb3J0IHByb3Rv Y29scw0KICAgbyAgVGhlc2UgYWRkcmVzc2VzIG1heSBhZGQgY29tcGxleGl0eSB0byB0aGUgb3Bl cmF0aW9uYWwgbWFuYWdlbWVudA0KICAgICAgYW5kIHRyb3VibGVzaG9vdGluZyBvZiB0aGUgaW5m cmFzdHJ1Y3R1cmUgKGkuZS4gd2hpY2ggYWRkcmVzcw0KICAgICAgYmVsb25ncyB0byB3aGljaCBy ZWFsIGhvc3QpDQogICBvICBBIHJldmVyc2UgRE5TIGxvb2t1cCBjaGVjayBtYXkgYmUgYnJva2Vu IHdoZW4gdXNpbmcgcHJpdmFjeQ0KICAgICAgZXh0ZW5zaW9ucw0KDQo0LjMuICAgQ3J5cHRvZ3Jh cGhpY2FsbHkgR2VuZXJhdGVkIElQdjYgQWRkcmVzc2VzDQoNCiAgIENyeXB0b2dyYXBoaWNhbGx5 IEdlbmVyYXRlZCBBZGRyZXNzZXMgKENHQXMpIGFyZSBiYXNlZCB1cG9uIFJGQzM5NzINCiAgIFsy MF0gYW5kIHByb3ZpZGUgYSBtZXRob2QgZm9yIGJpbmRpbmcgYSBwdWJsaWMgc2lnbmF0dXJlIGtl eSB0byBhbg0KICAgSVB2NiBhZGRyZXNzIGluIHRoZSBTZWN1cmUgTmVpZ2hib3IgRGlzY292ZXJ5 IChTRU5EKSBwcm90b2NvbCBbMTldLg0KDQogICBUaGUgYmFzaWMgaWRlYSBpcyB0byBnZW5lcmF0 ZSB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXIgKGkuZS4gdGhlDQogICByaWdodG1vc3QgNjQgYml0 cykgb2YgdGhlIElQdjYgYWRkcmVzcyBieSBjb21wdXRpbmcgYSBjcnlwdG9ncmFwaGljDQogICBo YXNoIG9mIHRoZSBwdWJsaWMga2V5LiAgVGhlIHJlc3VsdGluZyBJUHY2IGFkZHJlc3MgaXMgY2Fs bGVkIGENCiAgIGNyeXB0b2dyYXBoaWNhbGx5IGdlbmVyYXRlZCBhZGRyZXNzIChDR0EpLiAgVGhl IGNvcnJlc3BvbmRpbmcgcHJpdmF0ZQ0KICAga2V5IGNhbiB0aGVuIGJlIHVzZWQgdG8gc2lnbiBt ZXNzYWdlcyBzZW50IGZyb20gdGhhdCBhZGRyZXNzLg0KDQogICBJbXBsaWNhdGlvbnMgdG8gYmUg YXdhcmUgb2Ygd2hlbiB1c2luZyBDR0EgYWRkcmVzc2VzIGFyZSBmb3VuZCBpbg0KICAgc2VjdGlv biA3IG9mIFJGQzM5NzIgWzIwXToNCiAgIG8gIFdoZW4gdXNpbmcgQ0dBIGFkZHJlc3NlcyB0aGUg dmFsdWVzIG9mIHRoZSAidSIgYW5kICJnIiBiaXRzIGFyZQ0KICAgICAgaWdub3JlZCBob3dldmVy IGl0IGRvZXMgbm90IGFkZCBhbnkgc2VjdXJpdHkgb3IgaW1wbGVtZW50YXRpb24NCiAgICAgIGlt cGxpY2F0aW9ucw0KICAgbyAgVGhlcmUgaXMgbm8gbWVjaGFuaXNtIGZvciBwcm92aW5nIHRoYXQg YW4gYWRkcmVzcyBpcyBub3QgYSBDR0ENCiAgIG8gIFdoZW4gaXQgaXMgZGlzY292ZXJlZCB0aGF0 IGEgbm9kZSBoYXMgYmVlbiBjb21wcm9taXNlZCwgYSBuZXcNCiAgICAgIHNpZ25hdHVyZSBrZXkg YW5kIGEgbmV3IENHQSBzaG91bGQgYmUgZ2VuZXJhdGVkDQoNCiAgIER1ZSB0byB0aGUgZmFjdCB0 aGF0IENHQSBnZW5lcmF0ZWQgYWRkcmVzc2VzIGFyZSBhbG1vc3QNCiAgIGluZGlzdGluZ3Vpc2hh YmxlIGZyb20gYSBwcml2YWN5IGFkZHJlc3MgYW5kIGhhcyBzaW1pbGFyIHByb3BlcnRpZXMNCiAg IGZvciBtYW55IHB1cnBvc2VzLCB0aGUgc2FtZSBjb25zaWRlcmF0aW9ucyBhcyB3aXRoIHByaXZh Y3kgYWRkcmVzc2VzDQogICBhcmUgYWxzbyB2YWxpZCBmb3IgQ0dBIGdlbmVyYXRlZCBhZGRyZXNz ZXMuDQoNCg0KDQpWYW4gZGUgVmVsZGUsIGV0IGFsLiAgICBFeHBpcmVzIERlY2VtYmVyIDMsIDIw MDYgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIElQdjYg QWRkcmVzc2luZyBDb25zaWRlcmF0aW9ucyAgICAgICAgICAgIEp1bmUgMjAwNg0KDQoNCjQuNC4g IE1hbnVhbC9EeW5hbWljIEFzc2lnbm1lbnQgT3B0aW9uDQoNCiAgIFRoaXMgc2VjdGlvbiBkaXNj dXNzZXMgdGhvc2UgSUlEIGFsbG9jYXRpb25zIHRoYXQgYXJlIG5vdCBpbXBsZW1lbnRlZA0KICAg dGhyb3VnaCBzdGF0ZWxlc3MgYWRkcmVzcyBjb25maWd1cmF0aW9uIChTZWN0aW9uIDQuMSkuICBU aGV5IGFyZQ0KICAgYXBwbGljYWJsZSByZWdhcmRsZXNzIG9mIHRoZSBwcmVmaXggbGVuZ3RoIHVz ZWQgb24gdGhlIGxpbmsuICBJdCBpcw0KICAgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHNlY3Rpb24g dG8gZGlzY3VzcyB0aGUgdmFyaW91cyBhc3NpZ25tZW50DQogICBtZXRob2RzIChlLmcuIG1hbnVh bCBjb25maWd1cmF0aW9uLCBESENQdjYsIGV0YykuDQoNCiAgIEluIHRoaXMgc2l0dWF0aW9uIHRo ZSBhY3R1YWwgYWxsb2NhdGlvbiBpcyBkb25lIGJ5IGh1bWFuIGludGVydmVudGlvbg0KICAgYW5k IGNvbnNpZGVyYXRpb24gbmVlZHMgdG8gYmUgZ2l2ZW4gdG8gdGhlIGNvbXBsZXRlIElQdjYgYWRk cmVzcyBzbw0KICAgdGhhdCBpdCBkb2VzIG5vdCByZXN1bHQgaW4gb3ZlcmxhcHMgd2l0aCBhbnkg b2YgdGhlIHdlbGwga25vd24gSVB2Ng0KICAgYWRkcmVzc2VzOg0KICAgbyAgU3VibmV0IFJvdXRl ciBBbnljYXN0IEFkZHJlc3MNCiAgIG8gIFJlc2VydmVkIFN1Ym5ldCBBbnljYXN0IEFkZHJlc3MN CiAgIG8gIEFkZHJlc3NlcyB1c2VkIGJ5IEVtYmVkZGVkLVJQDQogICBvICBJU0FUQVAgQWRkcmVz c2VzDQoNCiAgIFdoZW4gdXNpbmcgYW4gYWRkcmVzcyBhc3NpZ25lZCBieSBodW1hbiBpbnRlcnZl bnRpb24gaXQgaXMNCiAgIHJlY29tbWVuZGVkIHRvIGNob29zZSBJUHY2IGFkZHJlc3NlcyB3aGlj aCBhcmUgbm90IG9idmlvdXMgdG8gZ3Vlc3MNCiAgIGFuZC9vciBhdm9pZCBhbnkgSVB2NiBhZGRy ZXNzZXMgdGhhdCBlbWJlZCBJUHY0IGFkZHJlc3NlcyB1c2VkIGluIHRoZQ0KICAgY3VycmVudCBp bmZyYXN0cnVjdHVyZS4gIEZvbGxvd2luZyB0aGVzZSB0d28gcmVjb21tZW5kYXRpb25zIHdpbGwN CiAgIG1ha2UgaXQgbW9yZSBkaWZmaWN1bHQgZm9yIG1hbGljaW91cyB0aGlyZCBwYXJ0aWVzIHRv IGd1ZXNzIHRhcmdldHMNCiAgIGZvciBhdHRhY2ssIGFuZCB0aHVzIHJlZHVjZSBzZWN1cml0eSB0 aHJlYXRzIHRvIGEgY2VydGFpbiBleHRlbnQuDQoNCg0KNS4gIENhc2UgU3R1ZGllcw0KDQogICB0 YmMuDQoNCjUuMS4gIEVudGVycHJpc2UgQ29uc2lkZXJhdGlvbnMNCg0KICAgSW4gdGhpcyBzZWN0 aW9uIHdlIGNvbnNpZGVyIGEgY2FzZSBzdHVkeSBvZiBhIGNhbXB1cyBuZXR3b3JrIHRoYXQgaXMN CiAgIGRlcGxveWluZyBJUHY2IGluIHBhcmFsbGVsIHdpdGggZXhpc3RpbmcgSVB2NCBwcm90b2Nv bHMgaW4gYSBkdWFsLQ0KICAgc3RhY2sgZW52aXJvbm1lbnQuICBUaGUgc3BlY2lmaWMgZXhhbXBs ZSBpcyB0aGUgVW5pdmVyc2l0eSBvZg0KICAgU291dGhhbXB0b24gKFVLKS4gIFRoZSBjYXNlIHN0 dWR5IGlzIGEgJ3dvcmsgaW4gcHJvZ3Jlc3MnIGFzIHRoZQ0KICAgZGVwbG95bWVudCBpcyBhbiBl dm9sdmluZyBvbmUsIGN1cnJlbnRseSBjb3ZlcmluZyBhcm91bmQgMSw1MDAgaG9zdHMuDQoNCjUu MS4xLiAgT2J0YWluaW5nIGdlbmVyYWwgSVB2NiBuZXR3b3JrIHByZWZpeGVzDQoNCiAgIEluIHRo ZSBjYXNlIG9mIGEgY2FtcHVzIG5ldHdvcmssIHRoZSBzaXRlIHdpbGwgdHlwaWNhbGx5IHRha2Ug aXRzDQogICBjb25uZWN0aXZpdHkgZnJvbSBpdHMgTmF0aW9uYWwgUmVzZWFyY2ggYW5kIEVkdWNh dGlvbiBOZXR3b3JrIChOUkVOKS4NCiAgIFNvdXRoYW1wdG9uIGNvbm5lY3RzIHRvIEpBTkVULCB0 aGUgVUsgYWNhZGVtaWMgbmV0d29yay4gIEpBTkVUDQogICBjdXJyZW50bHkgaGFzIGEgLzMyIGFs bG9jYXRpb24gZnJvbSBSSVBFIG9mIDIwMDE6NjMwOjovMzIuICBUaGUNCiAgIGN1cnJlbnQgcmVj b21tZW5kZWQgcHJhY3RpY2UgaXMgZm9yIHNpdGVzIHRvIHJlY2VpdmUgYSAvNDgNCiAgIGFsbG9j YXRpb24sIGFuZCBvbiB0aGlzIGJhc2lzIFNvdXRoYW1wdG9uIGhhcyByZWNlaXZlZCBzdWNoIGEg cHJlZml4DQogICBmb3IgaXRzIG93biB1c2UsIHNwZWNpZmljYWxseSAyMDAxOjYzMDpkMDo6LzQ4 Lg0KDQogICBObyBVTEEgYWRkcmVzc2luZyBpcyB1c2VkIG9uIHNpdGUuICBUaGUgY2FtcHVzIGRv ZXMgbm90IGV4cGVjdCB0bw0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBE ZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIw MDYNCg0KDQogICBjaGFuZ2Ugc2VydmljZSBwcm92aWRlciwgYW5kIHRodXMgZG9lcyBub3QgcGxh biB0byB1c2UgVUxBcyBmb3IgdGhlDQogICAocGVyY2VpdmVkKSBiZW5lZml0IG9mIGVhc2luZyBu ZXR3b3JrIHJlbnVtYmVyaW5nLiAgSW5kZWVkLCB0aGUNCiAgIGNhbXB1cyBoYXMgcmVudW1iZXJl ZCBmb2xsb3dpbmcgdGhlIGFmb3JlbWVudGlvbmVkIHJlbnVtYmVyaW5nDQogICBwcm9jZWR1cmUg WzIxXSBvbiB0d28gb2NjYXNpb25zLCBhbmQgdGhpcyBoYXMgcHJvdmVuIGFkZXF1YXRlICh3aXRo DQogICBwcm92aXNvcyBkb2N1bWVudGVkIGluIFsyOF0uICBXZSBhbHNvIGRvIG5vdCBzZWUgYW55 IG5lZWQgdG8gZGVwbG95DQogICBVTEFzIGZvciBpbiBvciBvdXQgb2YgYmFuZCBuZXR3b3JrIG1h bmFnZW1lbnQ7IHRoZXJlIGFyZSBlbm91Z2ggSVB2Ng0KICAgcHJlZml4ZXMgYXZhaWxhYmxlIGlu IHRoZSBzaXRlIGFsbG9jYXRpb24gZm9yIHRoZSBpbmZyYXN0cnVjdHVyZS4NCg0KICAgTm8gNmJv bmUgYWRkcmVzc2luZyBpcyB1c2VkIG9uIHNpdGUuICBUaGlzIHdhcyBwaGFzZWQgb3V0IHNvbWUg dGltZQ0KICAgYWdvLiAgV2Ugbm90ZSB0aGF0IGFzIG9mIDZ0aCBKdW5lIDIwMDYgdHJhbnNpdCBJ U1BzIHdpbGwgbGlrZWx5DQogICBmaWx0ZXIgYW55IGF0dGVtcHRlZCB1c2Ugb2Ygc3VjaCBwcmVm aXhlcy4NCg0KICAgU291dGhhbXB0b24gZG9lcyBwYXJ0aWNpcGF0ZSBpbiBnbG9iYWwgYW5kIG9y Z2FuaXphdGlvbiBzY29wZSBJUHY2DQogICBtdWx0aWNhc3QgbmV0d29ya3MuICBNdWx0aWNhc3Qg YWRkcmVzcyBhbGxvY2F0aW9ucyBhcmUgbm90IGRpc2N1c3NlZA0KICAgaGVyZSBhcyB0aGV5IGFy ZSBub3QgaW4gc2NvcGUgZm9yIHRoZSBkb2N1bWVudC4gIEVtYmVkZGVkIFJQIGlzIGluDQogICB1 c2UsIGFuZCBoYXMgYmVlbiB0ZXN0ZWQgc3VjY2Vzc2Z1bGx5IGFjcm9zcyBwcm92aWRlcnMgYmV0 d2VlbiBzaXRlcy4NCg0KNS4xLjIuICBGb3JtaW5nIGFuIGFkZHJlc3MgKHN1Ym5ldCkgYWxsb2Nh dGlvbiBwbGFuDQoNCiAgIFRoZSBjYW1wdXMgaGFzIGEgLzE2IHByZWZpeCBmb3IgSVB2NCB1c2U7 IGluIHByaW5jaXBsZSAyNTYgc3VibmV0cyBvZg0KICAgMjU2IGFkZHJlc3Nlcy4gIEluIHJlYWxp dHkgdGhlIHN1Ym5ldHRpbmcgaXMgbXVkZGllciwgYmVjYXVzZSBvZg0KICAgY29uY2VybnMgb2Yg SVB2NCBhZGRyZXNzIGNvbnNlcnZhdGlvbjsgc3VibmV0cyBhcmUgc2l6ZWQgdG8gdGhlIGhvc3Rz DQogICB3aXRoaW4gdGhlbSwgZS5nLiBhIC8yNiBJUHY0IHByZWZpeCBpcyB1c2VkIGlmIGEgc3Vi bmV0IGhhcyAzNSBob3N0cw0KICAgaW4gaXQuICBXaGlsZSB0aGlzIGlzIGVmZmljaWVudCwgaXQg aW5jcmVhc2VzIG1hbmFnZW1lbnQgYnVyZGVuIHdoZW4NCiAgIHBoeXNpY2FsIGRlcGxveW1lbnRz IGNoYW5nZSwgYW5kIElQdjQgc3VibmV0cyByZXF1aXJlIHJlc2l6aW5nICh1cCBvcg0KICAgZG93 biksIGV2ZW4gd2l0aCBESENQIGluIHVzZS4NCg0KICAgVGhlIC80OCBJUHY2IHByZWZpeCBpcyBj b25zaWRlcmFibHkgbGFyZ2VyIHRoYW4gdGhlIElQdjQgYWxsb2NhdGlvbg0KICAgYWxyZWFkeSBp biBwbGFjZSBhdCB0aGUgc2l0ZS4gIEl0IGlzIGxvb3NlbHkgZXF1aXZhbGVudCB0byBhICdDbGFz cw0KICAgQScgSVB2NCBwcmVmaXggaW4gdGhhdCBpdCBoYXMgMl4xNiAob3ZlciA2NSwwMDApIHN1 Ym5ldHMsIGJ1dCBoYXMgYW4NCiAgIGVmZmVjdGl2ZWx5IHVubGltaXRlZCBzdWJuZXQgYWRkcmVz cyBzaXplICgyXjY0KSBjb21wYXJlZCB0byAyNTYgaW4NCiAgIHRoZSBJUHY0IGVxdWl2YWxlbnQu ICBUaGUgaW5jcmVhc2VkIHN1Ym5ldCBzaXplIG1lYW5zIHRoYXQgLzY0IElQdjYNCiAgIHByZWZp eGVzIGNhbiBiZSB1c2VkIG9uIGFsbCBzdWJuZXRzLCB3aXRob3V0IGFueSByZXF1aXJlbWVudCB0 bw0KICAgcmVzaXplIHRoZW0gYXQgYSBsYXRlciBkYXRlLiAgVGhlIGluY3JlYXNlZCBzdWJuZXQg dm9sdW1lIGFsbG93cw0KICAgc3VibmV0cyB0byBiZSBhbGxvY2F0ZWQgbW9yZSBnZW5lcm91c2x5 IHRvIHNjaG9vbHMgYW5kIGRlcGFydG1lbnRzIGluDQogICB0aGUgY2FtcHVzLiAgV2hpbGUgYWRk cmVzcyBjb25zZXJ2YXRpb24gaXMgc3RpbGwgaW1wb3J0YW50LCBpdCBpcyBubw0KICAgbG9uZ2Vy IGFuIGltcGVkaW1lbnQgb24gbmV0d29yayBtYW5hZ2VtZW50LiAgUmF0aGVyLCBhZGRyZXNzIChz dWJuZXQpDQogICBhbGxvY2F0aW9uIGlzIG1vcmUgYWJvdXQgcGxhbm5pbmcgZm9yIGZ1dHVyZSBl eHBhbnNpb24uDQoNCiAgIEluIGEgZHVhbC1zdGFjayBuZXR3b3JrLCB3ZSBjaG9zZSB0byBkZXBs b3kgb3VyIElQIHN1Ym5ldHMNCiAgIGNvbmdydWVudGx5IGZvciBJUHY0IGFuZCBJUHY2LiAgVGhp cyBpcyBiZWNhdXNlIHRoZSBzeXN0ZW1zIGFyZSBzdGlsbA0KICAgaW4gdGhlIHNhbWUgYWRtaW5p c3RyYXRpdmUgZG9tYWlucyBhbmQgdGhlIHNhbWUgZ2VvZ3JhcGh5LiAgV2UgZG8gbm90DQogICBl eHBlY3QgdG8gaGF2ZSBJUHY2LW9ubHkgc3VibmV0cyBpbiBwcm9kdWN0aW9uIHVzZSBmb3IgYSB3 aGlsZSB5ZXQsDQogICBvdXRzaWRlIHRlc3QgYmVkcyBhbmQgb3VyIGVhcmx5IE1vYmlsZSBJUHY2 IHRyaWFscy4gIFRoZSBmaXJld2FsbA0KICAgd291bGQgaWRlYWxseSBiZSBhIHNpbmdsZSBkdWFs LXN0YWNrIGRldmljZSB3aXRoIGNvbnNpc3RlbnQgcG9saWNpZXMNCiAgIChieSBob3N0IHJhdGhl ciB0aGFuIElQIHZlcnNpb24pLCBob3dldmVyIHRoaXMgaXMgY3VycmVudGx5DQogICBpbXBsZW1l bnRlZCBhcyBhIGZpcmV3YWxsIHBlciBJUCBwcm90b2NvbCBkdWUgdG8gdmVuZG9yIGxpbWl0YXRp b25zDQogICAoTm9raWEvQ2hlY2twb2ludCBmb3IgSVB2NCwgQlNEIHBmIHRvb2wgZm9yIElQdjYp Lg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAyMDA2 ICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2IEFk ZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIwMDYNCg0KDQogICBUaGUg c3VibmV0IGFsbG9jYXRpb24gcGxhbiByZXF1aXJlZCBhIGRpdmlzaW9uIG9mIHRoZSBhZGRyZXNz IHNwYWNlDQogICBwZXIgc2Nob29sIG9yIGRlcGFydG1lbnQuICBIZXJlIGEgLzU2IHdhcyBhbGxv Y2F0ZWQgdG8gdGhlIHNjaG9vbA0KICAgbGV2ZWwgb2YgdGhlIHVuaXZlcnNpdHk7IHRoZXJlIGFy ZSBhcm91bmQgMzAgc2Nob29scyBjdXJyZW50bHkuDQogICBGdXJ0aGVyIGFsbG9jYXRpb25zIHdl cmUgbWFkZSBmb3IgY2VudHJhbCBJVCBpbmZyYXN0cnVjdHVyZSwgZm9yIHRoZQ0KICAgbmV0d29y ayBpbmZyYXN0cnVjdHVyZSBhbmQgdGhlIHNlcnZlciBzaWRlIHN5c3RlbXMuDQoNCjUuMS4zLiAg T3RoZXIgY29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIG5ldHdvcmsgdXNlcyBhIERlbWlsaXRhcml6 ZWQgWm9uZSAoRE1aKSB0b3BvbG9neSBmb3Igc29tZSBsZXZlbA0KICAgb2YgcHJvdGVjdGlvbiBv ZiAncHVibGljJyBzeXN0ZW1zLiAgQWdhaW4sIHRoaXMgdG9wb2xvZ3kgaXMgY29uZ3J1ZW50DQog ICB3aXRoIHRoZSBJUHY0IG5ldHdvcmsuDQoNCiAgIFRoZXJlIGFyZSBubyBzcGVjaWZpYyB0cmFu c2l0aW9uIG1ldGhvZHMgZGVwbG95ZWQgaW50ZXJuYWxseSB0byB0aGUNCiAgIGNhbXB1czsgZXZl cnl0aGluZyBpcyB1c2luZyB0aGUgY29udmVudGlvbmFsIGR1YWwtc3RhY2sgYXBwcm9hY2guDQog ICBUaGVyZSBpcyBubyB1c2Ugb2YgdG9vbHMgc3VjaCBhcyBJU0FUQVAgZm9yIGV4YW1wbGUuDQoN CiAgIEZvciB0aGUgTW9iaWxlIElQdjYgZWFybHkgdHJhaWxzLCB3ZSBoYXZlIGFsbG9jYXRlZCBv bmUgcHJlZml4IGZvcg0KICAgSG9tZSBBZ2VudCAoSEEpIHVzZS4gIFdlIGhhdmUgbm90IHlldCBj b25zaWRlcmVkIGhvdyBNb2JpbGUgSVB2Ng0KICAgdXNhZ2UgbWF5IGdyb3csIGFuZCB3aGV0aGVy IG1vcmUgb3IgZXZlbiBldmVyeSBzdWJuZXQgd2lsbCByZXF1aXJlIEhBDQogICBzdXBwb3J0Lg0K DQogICBUaGUgdW5pdmVyc2l0eSBvcGVyYXRlcyBhIHR1bm5lbCBicm9rZXIgc2VydmljZSBvbiBi ZWhhbGYgb2YgVUtFUk5BLg0KICAgVGhpcyB1c2VzIHNlcGFyYXRlIGFkZHJlc3Mgc3BhY2UgZnJv bSBKQU5FVCwgbm90IHRoZSBtYWluIHVuaXZlcnNpdHkNCiAgIGFsbG9jYXRpb24uDQoNCjUuMS40 LiAgTm9kZSBjb25maWd1cmF0aW9uIGNvbnNpZGVyYXRpb25zDQoNCiAgIFdlIGN1cnJlbnRseSB1 c2Ugc3RhdGVsZXNzIGF1dG9jb25maWd1cmF0aW9uIG9uIG1vc3Qgc3VibmV0cyBmb3IgSVB2Ng0K ICAgaG9zdHMuICBUaGVyZSBpcyBubyBESENQdjYgc2VydmljZSBkZXBsb3llZCB5ZXQsIGJleW9u ZCB0ZXN0cyBvZg0KICAgZWFybHkgY29kZSByZWxlYXNlcy4gIFdlIGRvIHNlZWsgYSBjb21tb24g aW50ZWdyYXRlZCBESENQL0ROUw0KICAgbWFuYWdlbWVudCBwbGF0Zm9ybSwgZXZlbiBpZiB0aGUg c2VydmVycyB0aGVtc2VsdmVzIGFyZSBub3QgY28tDQogICBsb2NhdGVkLiAgQ3VycmVudGx5IHdl IGFkZCBjbGllbnQgc3RhdGVsZXNzbHkgYXV0b2NvbmZpZ3VyZWQNCiAgIGFkZHJlc3NlcyB0byB0 aGUgRE5TIG1hbnVhbGx5LiAgT3VyIGFkbWluaXN0cmF0b3JzIHdvdWxkIHByZWZlciB0aGUNCiAg IHVzZSBvZiBESENQIGJlY2F1c2UgdGhleSBiZWxpZXZlIGl0IGdpdmVzIHRoZW0gc29tZSBtYW5h Z2VtZW50DQogICBjb250cm9sLg0KDQogICBSZWdhcmRpbmcgdGhlIFsyNl0gaW1wbGljYXRpb25z LCB3ZSBub3RlIHRoYXQgYWxsIG91ciBob3N0cyBhcmUgZHVhbC0NCiAgIHN0YWNrLCBhbmQgdGh1 cyBhcmUgcG90ZW50aWFsbHkgZXhwb3NlZCBvdmVyIGJvdGggcHJvdG9jb2xzIGFueXdheS4NCiAg IFdlIHB1Ymxpc2ggYWxsIGFkZHJlc3NlcyBpbiBETlMsIGFuZCBkbyBub3Qgb3BlcmF0ZSBhIHR3 byBmYWNlZCBETlMuDQoNCiAgIFdlIGhhdmUgaW50ZXJuYWwgdXNhZ2Ugb2YgUkZDMzA0MSBwcml2 YWN5IGFkZHJlc3NlcyBjdXJyZW50bHksIGJ1dA0KICAgbWF5IHdpc2ggdG8gYWRtaW5pc3RyYXRp dmVseSBkaXNhYmxlIHRoaXMgKHBlcmhhcHMgdmlhIERIQ1ApLCBidXQgd2UNCiAgIG5lZWQgdG8g ZGV0ZXJtaW5lIHRoZSBmZWFzaWJpbGl0eSBvZiB0aGlzIG9uIGFsbCBzeXN0ZW1zLCBlLmcuIGZv cg0KICAgV0xBTiBndWVzdHMgb3Igb3RoZXIgdXNlci1tYWludGFpbmVkIHN5c3RlbXMuICBOZXR3 b3JrIG1hbmFnZW1lbnQNCiAgIHNob3VsZCBiZSBzaW1wbGVyIHdpdGhvdXQgUkZDMzA0MSBpbiBv cGVyYXRpb24uICBOb3RlIFJGQzMwNDEgaXMgb25seQ0KICAgYW4gaXNzdWUgZm9yIG91dGJvdW5k IGNvbm5lY3Rpb25zLg0KDQogICBXZSBtYW51YWxseSBjb25maWd1cmUgc2VydmVyIGFkZHJlc3Nl cyB0byBhdm9pZCBhZGRyZXNzIGNoYW5nZXMgb24gYQ0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBh bC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAg ICAgICAgICBKdW5lIDIwMDYNCg0KDQogICBjaGFuZ2Ugb2YgbmV0d29yayBhZGFwdG9yLiAgV2l0 aCBJUHY2IHlvdSBjYW4gY2hvb3NlIHRvIHBpY2sgOjo1MyBmb3INCiAgIGEgRE5TIHNlcnZlciwg b3IgY2FuIHBpY2sgJ3JhbmRvbScgYWRkcmVzc2VzIGZvciBvYmZ1c2NhdGlvbiwgdGhvdWdoDQog ICB0aGF0J3Mgbm90IGFuIGlzc3VlIGZvciBwdWJsaWNseSBhZHZlcnRpc2VkIGFkZHJlc3NlcyAo ZG5zLCBteCwgd2ViLA0KICAgZXRjKS4NCg0KNS4xLjUuICBPYnNlcnZhdGlvbnMNCg0KICAgVGhl IHNpdGUgaXMgbm90ICh5ZXQpIHVzaW5nIHByZWZpeCBkZWxlZ2F0aW9uIHRvb2xzIGZvciBJUHY2 Lg0KDQo1LjIuICBTZXJ2aWNlIFByb3ZpZGVyIENvbnNpZGVyYXRpb25zDQoNCiAgIEluIHRoaXMg c2VjdGlvbiBhbiBJUHY2IGFkZHJlc3Npbmcgc2NoZW1hIGlzIHNrZXRjaGVkIHRoYXQgY291bGQN CiAgIHNlcnZlIGFzIGFuIGV4YW1wbGUgYnkgYSBTZXJ2aWNlIFByb3ZpZGVyIG9mZmVyaW5nIElu dGVybmV0IFNlcnZpY2VzDQogICBhcyB3ZWxsIGFzIE5ldHdvcmsgQWNjZXNzIHNlcnZpY2VzIHRv IG1pbGxpb25zIG9mIGN1c3RvbWVycy4gIEluIHRoaXMNCiAgIGV4YW1wbGUsIHRoZSBTZXJ2aWNl IFByb3ZpZGVyIGlzIGFzc3VtZWQgdG8gb3BlcmF0ZSBhbiBNUExTIGJhc2VkDQogICBiYWNrYm9u ZSBhbmQgaW1wbGVtZW50cyA2UEUgdG8gcHJvdmlkZSBJUHY2IGJhY2tib25lIHRyYW5zcG9ydA0K ICAgYmV0d2VlbiB0aGUgZGlmZmVyZW50IGxvY2F0aW9ucyAoUE9Qcykgb2YgYSBmdWxseSBkdWFs LXN0YWNrZWQNCiAgIG5ldHdvcmsgYWNjZXNzIGFuZCBhZ2dyZWdhdGlvbiBhcmVhLg0KDQogICBC ZXNpZGVzIHRoYXQgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBTZXJ2aWNlIFByb3ZpZGVyDQoNCiAg IG8gIGhhcyByZWNlaXZlZCBhIC8yMCBmcm9tIGl0cyBSSVINCiAgIG8gIG9wZXJhdGVzIGl0cyBv d24gTElSDQogICBvICBoYXMgdG8gYWRkcmVzcyBpdHMgb3duIElQdjYgaW5mcmFzdHJ1Y3R1cmUN CiAgIG8gIGRlbGVnYXRlcyBwcmVmaXhlcyBmcm9tIHRoaXMgYWdncmVnYXRlIHRvIGl0cyBjdXN0 b21lcnMuDQoNCiAgIEhlbmNlIHRoaXMgYWRkcmVzc2luZyBzY2hlbWEgY292ZXJzIHRoZSBudW1i ZXJpbmcgb2YgdGhlIFNlcnZpY2UNCiAgIFByb3ZpZGVyIElQdjYgbmV0d29yayBkZXZpY2VzIGFz IHdlbGwgdGhlIGN1c3RvbWVyIGFnZ3JlZ2F0ZXMgY2hvc2VuDQogICBvdXQgb2YgdGhlIC8yMCBw cmVmaXggb2YgdGhlIFNQLg0KDQo1LjIuMS4gIEludmVzdGlnYXRpb24gb2Ygb2JqZWN0aXZlIFJl cXVpcmVtZW50cyBmb3IgYW4gSVB2NiBhZGRyZXNzaW5nDQogICAgICAgIHNjaGVtYSBvZiBhIFNl cnZpY2UgUHJvdmlkZXINCg0KICAgVGhlIGZpcnN0IHN0ZXAgb2YgdGhlIElQdjYgYWRkcmVzc2lu ZyBwbGFuIGRlc2lnbiBmb3IgYSBTZXJ2aWNlDQogICBwcm92aWRlciBzaG91bGQgYmUgdGhlIGlk ZW50aWZpY2F0aW9uIG9mIGFsbCB0ZWNobmljYWwsIG9wZXJhdGlvbmFsLA0KICAgcG9saXRpY2Fs IGFuZCBidXNpbmVzcyByZXF1aXJlbWVudHMgdGhhdCBoYXZlIHRvIGJlIHNhdGlzZmllZCBieSB0 aGUNCiAgIHNlcnZpY2VzIHN1cHBvcnRlZCBieSB0aGlzIGFkZHJlc3Npbmcgc2NoZW1hLg0KDQog ICBBY2NvcmRpbmcgdG8gdGhlIGRpZmZlcmVudCB0ZWNobmljYWwgY29uc3RyYWludHMgYW5kIGJ1 c2luZXNzIG1vZGVscw0KICAgYXMgd2VsbCBhcyB0aGUgZGlmZmVyZW50IHdlaWdodHMgb2YgdGhl c2UgcmVxdWlyZW1lbnRzIChmcm9tIHRoZQ0KICAgcG9pbnQgb2YgdmlldyBvZiB0aGUgY29ycmVz cG9uZGluZyBTZXJ2aWNlIFByb3ZpZGVyKSBpdCBpcyB2ZXJ5DQogICBsaWtlbHkgdGhhdCBkaWZm ZXJlbnQgYWRkcmVzc2luZyBzY2hlbWFzIHdpbGwgYmUgZGV2ZWxvcGVkIGFuZA0KICAgZGVwbG95 ZWQgYnkgZGlmZmVyZW50IElTUHMuICBOZXZlcnRoZWxlc3MgdGhlIGFkZHJlc3Npbmcgc2NoZW1h IG9mDQogICB0aGlzIHNlY3Rpb24gaXMgb25lIHBvc3NpYmxlIGV4YW1wbGUuDQoNCjUuMi4xLjEu ICBSZXF1aXJlbWVudHMgZm9yIGFuIElQdjYgYWRkcmVzc2luZyBzY2hlbWEgZnJvbSB0aGUgTElS DQogICAgICAgICAgcGVyc3BlY3RpdmUgb2YgdGhlIFNlcnZpY2UgUHJvdmlkZXINCg0KDQoNCg0K VmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAyMDA2ICAgICAgICAg ICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2IEFkZHJlc3Npbmcg Q29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIwMDYNCg0KDQogICBJbiB0aGVpciByb2xl IGFzIExJUiB0aGUgU2VydmljZSBQcm92aWRlcnMgaGF2ZSB0byBjYXJlIGFib3V0IHRoZQ0KICAg cG9saWN5IGNvbnN0cmFpbnRzIG9mIHRoZSBSSVJzIGFuZCB0aGUgc3RhbmRhcmRzIG9mIHRoZSBJ RVRGDQogICByZWdhcmRpbmcgSVB2NiBhZGRyZXNzaW5nLiAgSW4gdGhpcyBjb250ZXh0LCB0aGUg Zm9sbG93aW5nIGJhc2ljDQogICByZXF1aXJlbWVudHMgYW5kIHJlY29tbWVuZGF0aW9ucyBoYXZl IHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBhbmQNCiAgIHNob3VsZCBiZSBzYXRpc2ZpZWQgYnkg dGhlIElQdjYgYWRkcmVzcyBhbGxvY2F0aW9uIHBsYW4gb2YgYSBTZXJ2aWNlDQogICBQcm92aWRl cjoNCiAgIG8gIEFzIHJlY29tbWVuZGVkIGluIFJGQyAzMTc3IFs3XSBhbmQgaW4gc2V2ZXJhbCBS SVIgcG9saWNpZXMNCiAgICAgICJDb21tb24iIGN1c3RvbWVycyBzaXRlcyAobm9ybWFsbHkgcHJp dmF0ZSBjdXN0b21lcnMpIHNob3VsZA0KICAgICAgcmVjZWl2ZSBhIC80OCBwcmVmaXggZnJvbSB0 aGUgYWdncmVnYXRlIG9mIHRoZSBTZXJ2aWNlIFByb3ZpZGVyLg0KICAgICAgKE5vdGU6IFRoZSBh ZGRyZXNzaW5nIHBsYW4gbXVzdCBiZSBmbGV4aWJsZSBlbm91Z2ggYW5kIHRha2UgaW50bw0KICAg ICAgYWNjb3VudCB0aGUgcG9zc2libGUgY2hhbmdlIG9mIHRoZSBtaW5pbXVtIGFsbG9jYXRpb24g c2l6ZSBmb3IgZW5kDQogICAgICB1c2VycyBjdXJyZW50bHkgdW5kZXIgZGVmaW5pdGlvbiBieSB0 aGUgUklScy4pDQogICBvICAiQmlnIGN1c3RvbWVycyIgKGxpa2UgYmlnIGVudGVycHJpc2VzLCBn b3Zlcm5tZW50YWwgYWdlbmNpZXMgZXRjLikNCiAgICAgIG1heSByZWNlaXZlIHNob3J0ZXIgcHJl Zml4ZXMgYWNjb3JkaW5nIHRvIHRoZWlyIG5lZWRzIHdoZW4gdGhpcw0KICAgICAgbmVlZCBjb3Vs ZCBiZSBkb2N1bWVudGVkIGFuZCBqdXN0aWZpZWQgdG8gdGhlIFJJUi4NCiAgIG8gIFRoZSBJUHY2 IGFkZHJlc3MgYWxsb2NhdGlvbiBzY2hlbWEgaGFzIHRvIGJlIGFibGUgdG8gbWVldCB0aGUgSEQt DQogICAgICByYXRpbyBvZiAwLjk0IGFzIGl0IGlzIGRlZmluZWQgZm9yIElQdjYuICBUaGlzIHJl cXVpcmVtZW50DQogICAgICBjb3JyZXNwb25kcyB0byB0aGUgZGVtYW5kIGZvciBhbiBlZmZpY2ll bnQgdXNhZ2Ugb2YgdGhlIElQdjYNCiAgICAgIGFkZHJlc3MgYWdncmVnYXRlIGJ5IHRoZSBTZXJ2 aWNlIFByb3ZpZGVyLiAgKE5vdGU6IEEgSEQtcmF0aW8gb2YNCiAgICAgIDAuOTQgbWVhbnMgYW4g ZWZmZWN0aXZlIHVzYWdlIG9mIGFib3V0IDMxJSBvZiB0aGUgLzIwIG9mIHRoZQ0KICAgICAgU2Vy dmljZSBQcm92aWRlciBvbiB0aGUgYmFzaXMgb2YgLzQ4IGFzc2lnbm1lbnRzLikNCiAgIG8gIEFs bCBhc3NpZ25tZW50cyB0byBjdXN0b21lcnMgaGF2ZSB0byBiZSBkb2N1bWVudGVkIGFuZCBzdG9y ZWQgaW50bw0KICAgICAgYSBkYXRhYmFzZSB0aGF0IGNhbiBhbHNvIGJlIHF1ZXJpZWQgYnkgdGhl IFJJUi4NCiAgIG8gIFRoZSBMSVIgaGFzIHRvIG1ha2UgYXZhaWxhYmxlIG1lYW5zIGZvciBzdXBw b3J0aW5nIHRoZSByZXZlcnNlIEROUw0KICAgICAgbWFwcGluZyBvZiB0aGUgY3VzdG9tZXIgcHJl Zml4ZXMuDQoNCjUuMi4xLjIuICBJUHY2IGFkZHJlc3Npbmcgc2NoZW1hIHJlcXVpcmVtZW50cyBm cm9tIHRoZSBJU1AgcGVyc3BlY3RpdmUNCiAgICAgICAgICBvZiB0aGUgU2VydmljZSBQcm92aWRl cg0KDQogICBGcm9tIElTUCBwZXJzcGVjdGl2ZSB0aGUgZm9sbG93aW5nIGJhc2ljIHJlcXVpcmVt ZW50cyBjb3VsZCBiZQ0KICAgaWRlbnRpZmllZDoNCiAgIG8gIFRoZSBJUHY2IGFkZHJlc3MgYWxs b2NhdGlvbiBzY2hlbWEgbXVzdCBiZSBhYmxlIHRvIHJlYWxpemUgYQ0KICAgICAgbWF4aW1hbCBh Z2dyZWdhdGlvbiBvZiBhbGwgSVB2NiBhZGRyZXNzIGRlbGVnYXRpb25zIHRvIGN1c3RvbWVycw0K ICAgICAgaW50byB0aGUgLzIwIG9mIHRoZSBTZXJ2aWNlIFByb3ZpZGVyLiAgT25seSB0aGlzIC8y MCB3aWxsIGJlDQogICAgICByb3V0ZWQgYW5kIGluamVjdGVkIGZyb20gdGhlIFNlcnZpY2UgUHJv dmlkZXIgaW50byB0aGUgZ2xvYmFsDQogICAgICByb3V0aW5nIHRhYmxlIChERlopLiAgVGhpcyBz dHJvbmcgYWdncmVnYXRpb24ga2VlcHMgdGhlIHJvdXRpbmcNCiAgICAgIHRhYmxlcyBvZiB0aGUg REZaIHNtYWxsIGFuZCBlYXNlcyBmaWx0ZXJpbmcgYW5kIGFjY2VzcyBjb250cm9sDQogICAgICB2 ZXJ5IG11Y2guICAoTm90ZTogQSBzdHJvbmcgYWdncmVnYXRpb24gZS5nLiBvbiBQT1Agb3IgTEVS IGJhc2lzDQogICAgICBsaW1pdHMgYXMgd2VsbCB0aGUgbnVtYmVycyBvZiBjdXN0b21lciByb3V0 ZXMgdGhhdCBhcmUgdmlzaWJsZQ0KICAgICAgd2l0aGluIHRoZSBJU1AgbmV0d29yay4pDQogICBv ICBUaGUgSVB2NiBhZGRyZXNzaW5nIHNjaGVtYSBvZiB0aGUgU1Agc2hvdWxkIGNvbnRhaW4gbWF4 aW1hbA0KICAgICAgZmxleGliaWxpdHkgc2luY2UgdGhlIGluZnJhc3RydWN0dXJlIG9mIHRoZSBT UCB3aWxsIGNoYW5nZSBvdmVyDQogICAgICB0aGUgdGltZSB3aXRoIG5ldyBjdXN0b21lcnMsIHRy YW5zcG9ydCB0ZWNobm9sb2dpZXMgYW5kIGJ1c2luZXNzDQogICAgICBjYXNlcy4gIFRoZSByZXF1 aXJlbWVudCBvZiBtYXhpbWFsIGZsZXhpYmlsaXR5IGlzIGNvbnRyYXJ5IHRvIHRoZQ0KICAgICAg cmVxdWlyZW1lbnRzIG9mIHN0cm9uZyBJUHY2IGFkZHJlc3MgYWdncmVnYXRpb24gYW5kIGVmZmlj aWVudA0KICAgICAgYWRkcmVzcyB1c2FnZSwgYnV0IGF0IHRoaXMgcG9pbnQgZWFjaCBTUCBoYXMg dG8gZGVjaWRlIHdoaWNoIG9mDQogICAgICB0aGVzZSByZXF1aXJlbWVudHMgdG8gcHJpb3JpdGl6 ZS4NCg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAy MDA2ICAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2 IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIwMDYNCg0KDQogICBv ICBLZWVwaW5nIHRoZSBtdWx0aWxldmVsIG5ldHdvcmsgaGllcmFyY2h5IG9mIGFuIElTUCBpbiBt aW5kLCBkdWUgdG8NCiAgICAgIGFkZHJlc3NpbmcgZWZmaWNpZW5jeSByZWFzb25zIG5vdCBhbGwg aGllcmFyY2h5IGxldmVscyBjYW4gYW5kDQogICAgICBzaG91bGQgYmUgbWFwcGVkIGludG8gdGhl IElQdjYgYWRkcmVzc2luZyBzY2hlbWEgb2YgYW4gSVNQLg0KICAgICAgU29tZXRpbWVzIGl0IGlz IG11Y2ggYmV0dGVyIHRvIGltcGxlbWVudCAiZmxhdCIgYWRkcmVzc2luZyBmb3IgdGhlDQogICAg ICBJU1AgbmV0d29yayB0aGFuIHRvIGxvb3NlIGJpZyBjaHVua3Mgb2YgdGhlIElQdjYgYWRkcmVz cyBhZ2dyZWdhdGUNCiAgICAgIGluIGFkZHJlc3NpbmcgZWFjaCBsZXZlbCBvZiBuZXR3b3JrIGhp ZXJhcmNoeS4gIEJlc2lkZXMgdGhhdCBhDQogICAgICBkZWNvdXBsaW5nIG9mIHByb3ZpZGVyIG5l dHdvcmsgYWRkcmVzc2luZyBhbmQgY3VzdG9tZXIgYWRkcmVzc2luZw0KICAgICAgaXMgcmVjb21t ZW5kZWQuDQoNCjUuMi4xLjMuICBJUHY2IGFkZHJlc3Npbmcgc2NoZW1hIHJlcXVpcmVtZW50cyBm cm9tIHRoZSBOZXR3b3JrIEFjY2Vzcw0KICAgICAgICAgIHByb3ZpZGVyIHBlcnNwZWN0aXZlIG9m IHRoZSBTZXJ2aWNlIFByb3ZpZGVyDQoNCiAgIEFzIGFscmVhZHkgZG9uZSBmb3IgdGhlIExJUiBh bmQgdGhlIElTUCByb2xlcyBvZiB0aGUgU1AgaXQgaXMgYWxzbw0KICAgbmVjZXNzYXJ5IHRvIGlk ZW50aWZ5IHJlcXVpcmVtZW50cyB0aGF0IGNvbWUgZnJvbSBpdHMgTmV0d29yayBBY2Nlc3MNCiAg IFByb3ZpZGVyIHJvbGUuICBTb21lIG9mIHRoZSBiYXNpYyByZXF1aXJlbWVudHMgYXJlOg0KICAg byAgVGhlIElQdjYgYWRkcmVzc2luZyBzY2hlbWEgb2YgdGhlIFNQIG11c3QgYmUgZmxleGlibGUg ZW5vdWdoIHRvDQogICAgICBhZGFwdCBjaGFuZ2VzIHRoYXQgYXJlIGluamVjdGVkIGZyb20gdGhl IGN1c3RvbWVyIHNpZGUuICBUaGlzDQogICAgICBjb3ZlcnMgY2hhbmdlcyB0aGF0IGFyZSBiYXNl ZCBvbiB0aGUgcmFpc2luZyBJUHY2IGFkZHJlc3MgbmVlZHMgb2YNCiAgICAgIHRoZSBjdXN0b21l ciBhcyB3ZWxsIGFzIGNoYW5nZXMgdGhhdCBjb21lIGZyb20gdG9wb2xvZ2ljYWwNCiAgICAgIG1v ZGlmaWNhdGlvbnMgKGUuZy4gd2hlbiB0aGUgY3VzdG9tZXIgbW92ZXMgZnJvbSBvbmUgcG9pbnQg b2YNCiAgICAgIG5ldHdvcmsgYXR0YWNobWVudCAoUE9QKSB0byBhbm90aGVyKS4NCiAgIG8gIEZv ciBlYWNoIElQdjYgYWRkcmVzcyBhc3NpZ25tZW50IHRvIGN1c3RvbWVycyBhICJidWZmZXIgem9u ZSIgbXVzdA0KICAgICAgYmUgcmVzZXJ2ZWQgdGhhdCBhbGxvd3MgdGhlIGN1c3RvbWVyIHRvIGdy b3cgaW4gaXRzIGFkZHJlc3NpbmcNCiAgICAgIHJhbmdlIHdpdGhvdXQgcmVudW1iZXJpbmcgb3Ig YXNzaWdubWVudCBvZiBhZGRpdGlvbmFsIHByZWZpeGVzLg0KICAgbyAgVGhlIElQdjYgYWRkcmVz c2luZyBzY2hlbWEgb2YgdGhlIFNQIG11c3QgZGVhbCB3aXRoIG11bHRpcGxlLQ0KICAgICAgYXR0 YWNobWVudHMgb2YgYSBzaW5nbGUgY3VzdG9tZXIgdG8gdGhlIFNQIG5ldHdvcmsgaW5mcmFzdHJ1 Y3R1cmUNCiAgICAgIChpLmUuIG11bHRpLWhvbWVkIG5ldHdvcmsgYWNjZXNzIHdpdGggdGhlIHNh bWUgU1ApLg0KDQogICBUaGVzZSBmZXcgcmVxdWlyZW1lbnRzIGFyZSBvbmx5IHBhcnQgb2YgYWxs IHRoZSByZXF1aXJlbWVudHMgYQ0KICAgU2VydmljZSBQcm92aWRlciBoYXMgdG8gaW52ZXN0aWdh dGUgYW5kIGtlZXAgaW4gbWluZCBkdXJpbmcgdGhlDQogICBkZWZpbml0aW9uIHBoYXNlIG9mIGl0 cyBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZS4gIEVhY2ggU1Agd2lsbCBtb3N0DQogICBsaWtlbHkg YWRkIG1vcmUgY29uc3RyYWludHMgdG8gdGhpcyBsaXN0Lg0KDQo1LjIuMi4gIElQdjYgYWRkcmVz cyBhbGxvY2F0aW9uIHBsYW4gZm9yIGEgU2VydmljZSBQcm92aWRlcg0KDQogICBUaGlzIHNlY3Rp b24gaWxsdXN0cmF0ZXMgaG93IHRoZSAvMjAgSVB2NiBwcmVmaXggb2YgdGhlIFNQIGNhbiBiZQ0K ICAgdXNlZCB0byBhZGRyZXNzIHRoZSBTUC1vd24gaW5mcmFzdHJ1Y3R1cmUgYW5kIHRvIGRlbGVn YXRlIElQdjYNCiAgIHByZWZpeGVzIHRvIGl0cyBjdXN0b21lcnMgZm9sbG93aW5nIHRoZSBhYm92 ZSBtZW50aW9uZWQgcmVxdWlyZW1lbnRzDQogICBhcyBmYXIgYXMgcG9zc2libGUuDQoNCiAgIFRo ZSBiZWxvdyBmaWd1cmUgc3VtbWFyaXplcyB0aGUgZGV2aWNlIHR5cGVzIGluIGFuIFNQIG5ldHdv cmsgYW5kIHRoZQ0KICAgdHlwaWNhbCBuZXR3b3JrIGRlc2lnbi4gIFRoZSBuZXR3b3JrIGhpZXJh cmNoeSBvZiB0aGUgU1AgaGFzIHRvIGJlDQogICB0YWtlbiBpbnRvIGFjY291bnQgZm9yIHRoZSBk ZXNpZ24gb2YgYW4gSVB2NiBhZGRyZXNzaW5nIHNjaGVtYSBhbmQNCiAgIGRlZmluZXMgaXRzIGJh c2ljIHNoYXBlLg0KDQoNCg0KDQoNCg0KDQpWYW4gZGUgVmVsZGUsIGV0IGFsLiAgICBFeHBpcmVz IERlY2VtYmVyIDMsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgIElQdjYgQWRkcmVzc2luZyBDb25zaWRlcmF0aW9ucyAgICAgICAgICAgIEp1bmUg MjAwNg0KDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8ICAgICAgICAgICAgICAgTFNScyBvZiB0aGUg TVBMUyBCYWNrYm9uZSBvZiB0aGUgU1AgICAgICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgIHwgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgfA0KICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICB8DQogICArLS0tLS0rICArLS0tLS0rICAgICArLS0tLS0tLS0rICAgICAr LS0tLS0tLS0rICAgICAgICAgKy0tLS0tLS0tKw0KICAgfCBMRVIgfCAgfCBMRVIgfCAgICAgfCBM RVItQkIgfCAgICAgfCBMRVItQkIgfCAgICAgICAgIHwgTEVSLUJCIHwNCiAgICstLS0tLSsgICst LS0tLSsgICAgICstLS0tLS0tLSsgICAgICstLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0rDQog ICAgfCAgIHwgICAgfCAgIHwgICAgICAgIHwgICAgfCAgICAgIC8gICAgIHwgICAgICAgICAgICAg IHwgICAgIHwNCiAgICB8ICAgfCAgICB8ICAgfCAgICAgICAgfCAgICB8ICAgICAvICAgICAgfCAg ICAgICAgICAgICAgfCAgICAgfA0KICAgIHwgICB8ICAgIHwgICB8ICArLS0tLS0tKyAgKy0tLS0t LSsgICArLS0tLS0tKyAgICAgICAgICB8ICAgICB8DQogICAgfCAgIHwgICAgfCAgIHwgIHxCQi1S QVJ8ICB8QkItUkFSfCAgIHwgIEFHICB8ICAgICAgICAgIHwgICAgIHwNCiAgICB8ICAgfCAgICB8 ICAgfCAgKy0tLS0tLSsgICstLS0tLS0rICAgKy0tLS0tLSsgICAgICAgICAgfCAgICAgfA0KICAg IHwgICB8ICAgIHwgICB8ICAgIHwgIHwgICAgICB8ICB8ICAgICAgfCAgICB8ICAgICAgICAgICB8 ICAgICB8DQogICAgfCAgIHwgICAgfCAgIHwgICAgfCAgfCAgICAgIHwgIHwgICAgICB8ICAgIHwg ICAgICAgICAgIHwgICAgIHwNCiAgICB8ICAgfCAgICB8ICAgfCAgICB8ICB8ICAgICAgfCAgfCAr LS0tLS0rICArLS0tLS0rICArLS0tLS0rICArLS0tLS0rDQogICAgfCAgIHwgICAgfCAgIHwgICAg fCAgfCAgICAgIHwgIHwgfCBSQVIgfCAgfCBSQVIgfCAgfCBSQVIgfCAgfCBSQVIgfA0KICAgIHwg ICB8ICAgIHwgICB8ICAgIHwgIHwgICAgICB8ICB8ICstLS0tLSsgICstLS0tLSsgICstLS0tLSsg ICstLS0tLSsNCiAgICB8ICAgfCAgICB8ICAgfCAgICB8ICB8ICAgICAgfCAgfCAgfCAgIHwgICAg fCAgIHwgICAgfCAgIHwgICAgfCAgIHwNCiAgICB8ICAgfCAgICB8ICAgfCAgICB8ICB8ICAgICAg fCAgfCAgfCAgIHwgICAgfCAgIHwgICAgfCAgIHwgICAgfCAgIHwNCiAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCAgICAgICAgICAgICAgICAgICAgICAgQ3VzdG9tZXIgbmV0d29ya3MgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIEZpZ3VyZTogRXhlbXBsYXJ5IFNl cnZpY2UgUHJvdmlkZXIgTmV0d29yaw0KDQogICBMU1IgICAgLi4uIExhYmVsIFN3aXRjaCBSb3V0 ZXINCiAgIExFUiAgICAuLi4gTGFiZWwgRWRnZSBSb3V0ZXINCiAgIExFUi1CQiAuLi4gQnJvYWRi YW5kIExhYmVsIEVkZ2UgUm91dGVyDQogICBSQVIgICAgLi4uIFJlbW90ZSBBY2Nlc3MgUm91dGVy DQogICBCQi1SQVIgLi4uIEJyb2FkYmFuZCBSZW1vdGUgQWNjZXNzIFJvdXRlcg0KICAgQUcgICAg IC4uLiBBZ2dyZWdhdGlvbiBSb3V0ZXINCg0KDQoNCiAgIEJhc2ljIGRlc2lnbiBkZWNpc2lvbnMg Zm9yIHRoZSBTUCBJUHY2IGFkZHJlc3MgcGxhbiByZWdhcmRpbmcNCiAgIGN1c3RvbWVyIHByZWZp eGVzIHRha2UgaW50byBjb25zaWRlcmF0aW9uOg0KICAgbyAgVGhlIHByZWZpeGVzIGFzc2lnbmVk IHRvIGFsbCBjdXN0b21lcnMgYmVoaW5kIHRoZSBzYW1lIExFUiAoZS5nLg0KICAgICAgTEVSIG9y IExFUi1CQikgYXJlIGFnZ3JlZ2F0ZWQgdW5kZXIgb25lIHByZWZpeC4gIFRoaXMgZW5zdXJlcyB0 aGF0DQogICAgICB0aGUgbnVtYmVyIG9mIGxhYmVscyB0aGF0IGhhdmUgdG8gYmUgdXNlZCBmb3Ig NlBFIGlzIGxpbWl0ZWQgYW5kDQogICAgICBoZW5jZSBwcm92aWRlcyBhIHN0cm9uZyBNUExTIGxh YmVsIGNvbnNlcnZhdGlvbi4NCiAgIG8gIFRoZSAvMjAgcHJlZml4IG9mIHRoZSBTUCBpcyBzZXBh cmF0ZWQgaW50byAzIGRpZmZlcmVudCBwb29scyB0aGF0DQogICAgICBhcmUgdXNlZCB0byBhbGxv Y2F0ZSBJUHY2IHByZWZpeGVzIHRvIHRoZSBjdXN0b21lcnMgb2YgdGhlIFNQOg0KICAgICAgKiAg QSBwb29sIChlLmcuIC8yNCkgZm9yIHNhdGlzZnlpbmcgdGhlIGFkZHJlc3NpbmcgbmVlZHMgb2Yg cmVhbA0KICAgICAgICAgImJpZyIgY3VzdG9tZXJzIChhcyBkZWZpbmVkIGluIDUuMi4yLjEgc3Vi LXNlY3Rpb24gQS4pIHRoYXQNCiAgICAgICAgIG5lZWQgSVB2NiBwcmVmaXhlcyBsYXJnZXIgdGhh biAvNDggKGUuZy4gLzMyKS4gIFRoZXNlIGN1c3RvbWVycw0KICAgICAgICAgYXJlIGFzc3VtZWQg dG8gYmUgY29ubmVjdGVkIHRvIHNldmVyYWwgUE9QcyBvZiB0aGUgYWNjZXNzDQogICAgICAgICBu ZXR3b3JrLCBzbyB0aGF0IHRoaXMgY3VzdG9tZXIgcHJlZml4IHdpbGwgYmUgdmlzaWJsZSBpbiBl YWNoDQogICAgICAgICBvZiB0aGVzZSBQT1BzLg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4g ICAgRXhwaXJlcyBEZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAg ICAgICBKdW5lIDIwMDYNCg0KDQogICAgICAqICBBIHBvb2wgKGUuZy4gLzI0KSBmb3IgdGhlIExF UnMgd2l0aCBkaXJlY3QgY3VzdG9tZXIgY29ubmVjdGlvbnMNCiAgICAgICAgIChlLmcuIGRlZGlj YXRlZCBsaW5lIGFjY2VzcykgYW5kIHdpdGhvdXQgYW4gYWRkaXRpb25hbA0KICAgICAgICAgYWdn cmVnYXRpb24gYXJlYSBiZXR3ZWVuIHRoZSBjdXN0b21lciBhbmQgdGhlIExFUi4gIChUaGVzZSBM RVJzDQogICAgICAgICBhcmUgbW9zdGx5IGNvbm5lY3RlZCB0byBhIGxpbWl0ZWQgbnVtYmVyIG9m IGN1c3RvbWVycyBiZWNhdXNlDQogICAgICAgICBvZiB0aGUgbGltaXRlZCBudW1iZXIgb2YgaW50 ZXJmYWNlcy9wb3J0cy4pDQogICAgICAqICBBIGxhcmdlciBwb29sIChlLmcuIDE0Ki8yNCkgZm9y IExFUnMgKGUuZy4gIExFUi1CQikgdGhhdCBzZXJ2ZQ0KICAgICAgICAgYSBoaWdoIG51bWJlciBv ZiBjdXN0b21lcnMgdGhhdCBhcmUgbm9ybWFsbHkgY29ubmVjdGVkIHZpYSBzb21lDQogICAgICAg ICBraW5kIG9mIGFnZ3JlZ2F0aW9uIG5ldHdvcmsgKGUuZy4gIERTTCBjdXN0b21lcnMgYmVoaW5k IGEgQkItDQogICAgICAgICBSQVIgb3IgRGlhbC1JbiBjdXN0b21lcnMgYmVoaW5kIGEgUkFSKS4N CiAgICAgICogIFRoZSBJUHY2IGFkZHJlc3MgZGVsZWdhdGlvbiB3aXRoaW4gZWFjaCBQb29sIChl bmQgY3VzdG9tZXINCiAgICAgICAgIGRlbGVnYXRpb24gb3IgYWxzbyB0aGUgYWdncmVnYXRlcyB0 aGF0IGFyZSBkZWRpY2F0ZWQgdG8gdGhlDQogICAgICAgICBMRVJzIGl0c2VsZikgc2hvdWxkIGJl IGNob3NlbiB3aXRoIGFuIGFkZGl0aW9uYWwgYnVmZmVyIHpvbmUgb2YNCiAgICAgICAgIDMwMCUg Zm9yIGZ1dHVyZSBncm93dGguDQoNCjUuMi4yLjEuICBEZWZpbmluZyBhbiBJUHY2IGFkZHJlc3Mg YWxsb2NhdGlvbiBwbGFuIGZvciBjdXN0b21lcnMgb2YgdGhlDQogICAgICAgICAgU2VydmljZSBQ cm92aWRlcg0KDQo1LjIuMi4xLjEuICAnQmlnJyBjdXN0b21lcnMNCg0KICAgU1AncyAiYmlnIiBj dXN0b21lcnMgcmVjZWl2ZSB0aGVpciBwcmVmaXggZnJvbSB0aGUgLzI0IElQdjYgYWRkcmVzcw0K ICAgYWdncmVnYXRlIHRoYXQgaGFzIGJlZW4gcmVzZXJ2ZWQgZm9yIHRoZWlyICJiaWciIGN1c3Rv bWVycy4gIEENCiAgIGN1c3RvbWVyIGlzIGNvbnNpZGVyZWQgYXMgImJpZyIgY3VzdG9tZXIgaWYg aXQgaGFzIGEgdmVyeSBjb21wbGV4DQogICBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGFuZC9vciBo dWdlIElQdjYgYWRkcmVzcyBuZWVkcyAoZS5nLiBiZWNhdXNlDQogICBvZiB2ZXJ5IGxhcmdlIGN1 c3RvbWVyIG51bWJlcnMpIGFuZC9vciBzZXZlcmFsIHVwbGlua3MgdG8gZGlmZmVyZW50DQogICBQ T1BzIG9mIHRoZSBTUCBuZXR3b3JrLg0KDQogICBUaGUgYXNzaWduZWQgSVB2NiBhZGRyZXNzIHBy ZWZpeGVzIGNhbiBoYXZlIGEgcHJlZml4IGxlbmd0aCBpbiB0aGUNCiAgIHJhbmdlIDMyLTQ4IGFu ZCBmb3IgZWFjaCBhc3NpZ25tZW50IGEgMzAwJSBmdXR1cmUgZ3Jvd2luZyB6b25lIGlzDQogICBt YXJrZWQgYXMgInJlc2VydmVkIiBmb3IgdGhpcyBjdXN0b21lci4gIFRoaXMgbWVhbnMgdGhhdCBm b3IgaW5zdGFuY2UNCiAgIHdpdGggYSBkZWxlZ2F0aW9uIG9mIGEgLzM0IHRvIGEgY3VzdG9tZXIg dGhlIC8zMiB0aGF0IGNvbnRhaW5zIHRoaXMNCiAgIC8zNCBpcyByZXNlcnZlZCBmb3IgdGhlIGN1 c3RvbWVyIGZvciBmdXR1cmUgdXNhZ2UuDQoNCiAgIFRoZSBwcmVmaXhlcyBmb3IgdGhlICJiaWci IGN1c3RvbWVycyBjYW4gYmUgY2hvc2VuIGZyb20gdGhlDQogICBjb3JyZXNwb25kaW5nIExFUiBj dXN0b21lciBwb29sIGJ5IGVpdGhlciB1c2luZyBhbiBlcXVpZGlzdGFudA0KICAgYWxnb3JpdGht IG9yIHVzaW5nIG1lY2hhbmlzbXMgc2ltaWxpbGFyIHRvIHRoZSBTcGFyc2UgQWxvY2F0aW9uDQog ICBBbGdvcml0aG0gKFNBQSkgWzI3XS4NCg0KNS4yLjIuMS4yLiAgJ0NvbW1vbicgY3VzdG9tZXJz DQoNCiAgIEFsbCBjdXN0b21lcnMgdGhhdCBhcmUgbm90ICJiaWciIGN1c3RvbWVycyBhcmUgY29u c2lkZXJlZCBhcyAiY29tbW9uIg0KICAgY3VzdG9tZXJzLiAgVGhleSByZXByZXNlbnQgdGhlIG1h am9yaXR5IG9mIGN1c3RvbWVycyBoZW5jZSB0aGV5DQogICByZWNlaXZlIGEgLzQ4IG91dCBvZiB0 aGUgSVB2NiBjdXN0b21lciBhZGRyZXNzIHBvb2wgb2YgdGhlIExFUiB3aGVyZQ0KICAgdGhleSBh cmUgZGlyZWN0bHkgY29ubmVjdGVkIG9yIGFnZ3JlZ2F0ZWQuDQoNCiAgIEFnYWluIGEgMzAwJSBm dXR1cmUgZ3Jvd2luZyBJUHY2IGFkZHJlc3MgcmFuZ2UgaXMgcmVzZXJ2ZWQgZm9yIGVhY2gNCiAg IGN1c3RvbWVyLCBzbyB0aGF0IGEgImNvbW1vbiIgY3VzdG9tZXIgcmVjZWl2ZXMgYSAvNDggYWxs b2NhdGlvbiBidXQNCiAgIGhhcyBhIC80NiByZXNlcnZlZC4NCg0KDQoNCg0KVmFuIGRlIFZlbGRl LCBldCBhbC4gICAgRXhwaXJlcyBEZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2Ug MjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlv bnMgICAgICAgICAgICBKdW5lIDIwMDYNCg0KDQogICBJbiB0aGUgbmV0d29yayBhY2Nlc3Mgc2Nl bmFyaW9zIHdoZXJlIHRoZSBjdXN0b21lciBpcyBkaXJlY3RseQ0KICAgY29ubmVjdGVkIHRvIHRo ZSBMRVIgdGhlIGN1c3RvbWVyIHByZWZpeCBpcyBkaXJlY3RseSB0YWtlbiBvdXQgb2YgdGhlDQog ICBjdXN0b21lciBJUHY2IGFkZHJlc3MgYWdncmVnYXRlIChlLmcuIC8zOCkgb2YgdGhlIGNvcnJl c3BvbmRpbmcgTEVSLg0KDQogICBJbiBhbGwgb3RoZXIgY2FzZXMgKGUuZy4gdGhlIGN1c3RvbWVy IGlzIGF0dGFjaGVkIHRvIGEgUkFSIHRoYXQgaXMNCiAgIHRoZW1zZWx2ZXMgYWdncmVnYXRlZCB0 byBhbiBBRyBvciB0byBhIExFUikgYXQgbGVhc3QgMiBkaWZmZXJlbnQNCiAgIGFwcHJvYWNoZXMg YXJlIHBvc3NpYmxlLg0KDQogICAxLikgIE1hcHBpbmcgb2YgQWdncmVnYXRpb24gTmV0d29yayBI aWVyYXJjaHkgaW50byBDdXN0b21lciBJUHY2DQogICBBZGRyZXNzaW5nIFNjaGVtYS4gIFRoZSBh Z2dyZWdhdGlvbiBuZXR3b3JrIGhpZXJhcmNoeSBjb3VsZCBiZSBtYXBwZWQNCiAgIGludG8gdGhl IGRlc2lnbiBvZiB0aGUgY3VzdG9tZXIgcHJlZml4IHBvb2xzIG9mIGVhY2ggbmV0d29yayBsZXZl bCBpbg0KICAgb3JkZXIgdG8gYWNoaWV2ZSBhIG1heGltYWwgYWdncmVnYXRpb24gYXQgdGhlIExF UiBsZXZlbCBhcyB3ZWxsIGFzIGF0DQogICB0aGUgaW50ZXJtZWRpYXRlIGxldmVscy4gIChFeGFt cGxlOiBDdXN0b21lciAtIC80OCwgUkFSIC0gLzM4LCBBRyAtDQogICAvMzIsIExFUi1CQiAtIC8z MCkuICBBdCBlYWNoIG5ldHdvcmsgbGV2ZWwgYW4gYWRlcXVhdGUgZ3Jvd2luZyB6b25lDQogICBz aG91bGQgYmUgcmVzZXJ2ZWQuICAoTm90ZTogVGhpcyBhcHByb2FjaCByZXF1aXJlcyBvZiBjb3Vy c2Ugc29tZQ0KICAgImZpbmUgdHVuaW5nIiBvZiB0aGUgYWRkcmVzc2luZyBzY2hlbWEgYmFzZWQg b24gYSB2ZXJ5IGdvb2Qga25vd2xlZGdlDQogICBvZiB0aGUgU2VydmljZSBQcm92aWRlciBuZXR3 b3JrIHRvcG9sb2d5IGluY2x1ZGluZyBhY3R1YWwgZ3Jvd2luZw0KICAgcmFuZ2VzIGFuZCByYXRl cy4pDQoNCiAgIFdoZW4gdGhlIElQdjYgY3VzdG9tZXIgYWRkcmVzcyBwb29sIG9mIGEgTEVSIChv ciBhbm90aGVyIGRldmljZSBvZg0KICAgdGhlIGFnZ3JlZ2F0aW9uIG5ldHdvcmsgLSBBRyBvciBS QVIpIGlzIGV4aGF1c3RlZCwgdGhlIHJlbGF0ZWQgTEVSDQogICAob3IgQUcgb3IgUkFSKSBwcmVm aXggaXMgc2hvcnRlbmVkIGJ5IDEgb3IgMiBiaXRzIChlLmcuIGZyb20gLzM4IHRvDQogICAvMzcg b3IgLzM2KSBzbyB0aGF0IHRoZSBvcmlnaW5hbGx5IHJlc2VydmVkIGdyb3dpbmcgem9uZSBjYW4g YmUgdXNlZA0KICAgZm9yIGZ1cnRoZXIgSVB2NiBhZGRyZXNzIGFsbG9jYXRpb25zIHRvIGN1c3Rv bWVycy4gIEluIHRoZSBjYXNlIHdoZXJlDQogICB0aGUgZ3Jvd2luZyB6b25lIGlzIGV4aGF1c3Rl ZCBhcyB3ZWxsIGEgbmV3IHByZWZpeCByYW5nZSBmcm9tIHRoZQ0KICAgY29ycmVzcG9uZGluZyBw b29sIG9mIHRoZSBuZXh0IGhpZ2hlciBoaWVyYXJjaHkgbGV2ZWwgY2FuIGJlDQogICByZXF1ZXN0 ZWQuDQoNCiAgIDIuKSAgIkZsYXQiIEN1c3RvbWVyIElQdjYgQWRkcmVzc2luZyBTY2hlbWEuICBU aGUgb3RoZXIgb3B0aW9uIGlzIHRvDQogICBhbGxvY2F0ZSBhbGwgdGhlIGN1c3RvbWVyIHByZWZp eGVzIGRpcmVjdGx5IG91dCBvZiB0aGUgY3VzdG9tZXIgSVB2Ng0KICAgYWRkcmVzcyBwb29sIG9m IHRoZSBMRVIgd2hlcmUgdGhlIGN1c3RvbWVycyBhcmUgYXR0YWNoZWQgYW5kDQogICBhZ2dyZWdh dGVkIGFuZCBpZ25vcmUgdGhlIGludGVybWVkaWF0ZSBhZ2dyZWdhdGlvbiBuZXR3b3JrDQogICBp bmZyYXN0cnVjdHVyZS4gIFRoaXMgYXBwcm9hY2ggbGVhZHMgb2YgY291cnNlIHRvIGEgaGlnaGVy IGFtb3VudCBvZg0KICAgY3VzdG9tZXIgcm91dGVzIGF0IExFUiBhbmQgYWdncmVnYXRpb24gbmV0 d29yayBsZXZlbCBidXQgdGFrZXMgYQ0KICAgZ3JlYXQgYW1vdW50IG9mIGNvbXBsZXhpdHkgb3V0 IG9mIHRoZSBhZGRyZXNzaW5nIHNjaGVtYS4NCiAgIE5ldmVydGhlbGVzcyB0aGUgYWdncmVnYXRp b24gb2YgdGhlIGN1c3RvbWVyIHByZWZpeGVzIHRvIG9uZSBwcmVmaXgNCiAgIGF0IExFUiBsZXZl bCBpcyByZWFsaXplZCBhcyByZXF1aXJlZCBhYm92ZS4NCg0KICAgSWYgdGhlIGFjdHVhbCBvYnNl cnZlZCBncm93aW5nIHJhdGVzIHNob3cgdGhhdCB0aGUgcmVzZXJ2ZWQgZ3Jvd2luZw0KICAgem9u ZXMgYXJlIG5vdCBuZWVkZWQgdGhhbiB0aGVzZSBncm93aW5nIGFyZWFzIGNhbiBiZSBmcmVlZCBh bmQgdXNlZA0KICAgZm9yIGFzc2lnbm1lbnRzIGZvciBwcmVmaXggcG9vbHMgdG8gb3RoZXIgZGV2 aWNlcyBhdCB0aGUgc2FtZSBsZXZlbA0KICAgb2YgdGhlIG5ldHdvcmsgaGllcmFyY2h5Lg0KDQo1 LjIuMi4yLiAgRGVmaW5pbmcgYW4gSVB2NiBhZGRyZXNzIGFsbG9jYXRpb24gcGxhbiBmb3IgdGhl IFNlcnZpY2UNCiAgICAgICAgICBQcm92aWRlciBOZXR3b3JrIEluZnJhc3RydWN0dXJlDQoNCiAg IEZvciB0aGUgSVB2NiBhZGRyZXNzaW5nIG9mIFNQcyBvd24gbmV0d29yayBpbmZyYXN0cnVjdHVy ZSBhIC8zMiAob3INCiAgIC80MCkgZnJvbSB0aGUgImJpZyIgY3VzdG9tZXJzIGFkZHJlc3MgcG9v bCBjYW4gYmUgY2hvc2VuLg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBE ZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIw MDYNCg0KDQogICBUaGlzIFNQIGluZnJhc3RydWN0dXJlIHByZWZpeCBpcyB1c2VkIHRvIGNvZGUg dGhlIG5ldHdvcmsNCiAgIGluZnJhc3RydWN0dXJlIG9mIHRoZSBTUCBieSBhc3NpZ25pbmcgYSAv NDggdG8gZXZlcnkgUE9QL2xvY2F0aW9uIGFuZA0KICAgdXNpbmcgZm9yIGluc3RhbmNlIGEgLzU2 IGZvciBjb2RpbmcgdGhlIGNvcnJlc3BvbmRpbmcgcm91dGVyIHdpdGhpbg0KICAgdGhpcyBQT1Au ICBFYWNoIFNQIGludGVybmFsIGxpbmsgYmVoaW5kIGEgcm91dGVyIGludGVyZmFjZSBjb3VsZCBi ZQ0KICAgY29kZWQgdXNpbmcgYSAvNjQgcHJlZml4LiAgKE5vdGU6IFdoaWxlIGl0IGlzIHN1Z2dl c3RlZCB0byBjaG9zZSBhDQogICAvNDggZm9yIGFkZHJlc3NpbmcgdGhlIFBPUC9sb2NhdGlvbiBv ZiB0aGUgU1AgbmV0d29yayBpdCBpcyBsZWZ0IHRvDQogICBlYWNoIFNQIHRvIGRlY2lkZSB3aGF0 IHByZWZpeCBsZW5ndGggdG8gYXNzaWduIHRvIHRoZSByb3V0ZXJzIGFuZA0KICAgbGlua3Mgd2l0 aGluIHRoaXMgUE9QLikNCg0KICAgVGhlIElJRHMgb2YgdGhlIHJvdXRlciBpbnRlcmZhY2VzIG1h eSBiZSBnZW5lcmF0ZWQgYnkgdXNpbmcgRVVJLTY0IG9yDQogICB0aHJvdWdoIHBsYWluIG1hbnVh bCBjb25maWd1cmF0aW9uIGUuZy4gZm9yIGNvZGluZyBhZGRpdGlvbmFsIG5ldHdvcmsNCiAgIG9y IG9wZXJhdGlvbmFsIGluZm9ybWF0aW9uIGludG8gdGhlIElJRC4NCg0KICAgSXQgaXMgYXNzdW1l ZCB0aGF0IGEgMzAwJSBncm93aW5nIHpvbmVzIGZvciBlYWNoIGxldmVsIG9mIG5ldHdvcmsNCiAg IGhpZXJhcmNoeSBhbmQgYWRkaXRpb25hbCBwcmVmaXhlcyBtYXkgYmUgYXNzaWduZWQgdG8gUE9Q cyBhbmQvb3INCiAgIHJvdXRlcnMgaWYgbmVlZGVkLg0KDQogICBMb29wYmFjayBpbnRlcmZhY2Vz IG9mIHJvdXRlcnMgbWF5IGJlIGNob3NlbiBmcm9tIHRoZSBmaXJzdCAvNjQgb2YNCiAgIHRoZSAv NTYgcm91dGVyIHByZWZpeCAoaW4gdGhlIGV4YW1wbGUgYWJvdmUpLg0KDQogICAoTm90ZTogVGhl IC8zMiBwcmVmaXggdGhhdCBoYXMgYmVlbiBjaG9zZW4gZm9yIGFkZHJlc3NpbmcgU1BzIG93bg0K ICAgSVB2NiBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGdpdmVzIGVub3VnaCBwbGFjZSB0byBjb2Rl IGFkZGl0aW9uYWwNCiAgIGZ1bmN0aW9uYWxpdGllcyBsaWtlIHNlY3VyaXR5IGxldmVscyBvciBw cml2YXRlIGFuZCB0ZXN0DQogICBpbmZyYXN0cnVjdHVyZSBhbHRob3VnaCBzdWNoIGFwcHJvYWNo ZXMgaGF2ZW4ndCBiZWVuIGNvbnNpZGVyZWQgaW4NCiAgIG1vcmUgZGV0YWlsIGZvciB0aGUgYWJv dmUgZGVzY3JpYmVkIFNQIHVudGlsIG5vdy4pDQoNCiAgIFBvaW50LXRvLXBvaW50IGxpbmtzIHRv IGN1c3RvbWVycyAoZS5nLiAgUFBQIGxpbmtzLCBkZWRpY2F0ZWQgbGluZQ0KICAgZXRjLikgbWF5 IGJlIGFkZHJlc3NlZCB1c2luZyAvMTI2IHByZWZpeGVzIG91dCBvZiB0aGUgZmlyc3QgLzY0IG9m DQogICB0aGUgYWNjZXNzIHJvdXRlcnMgdGhhdCBjb3VsZCBiZSByZXNlcnZlZCBmb3IgdGhpcyBy ZWFzb24uDQoNCjUuMi4zLiAgQWRkaXRpb25hbCBSZW1hcmtzDQoNCjUuMi4zLjEuICBVTEENCg0K ICAgRnJvbSB0aGUgYWN0dWFsIHZpZXcgcG9pbnQgb2YgU1AgdGhlcmUgaXMgbm8gY29tcGVsbGlu ZyByZWFzb24gd2h5DQogICBVTEFzIHNob3VsZCBiZSB1c2VkIGZyb20gYSBTUC4gIExvb2sgYXQg c2VjdGlvbiAyLjIuDQoNCiAgIFVMQXMgY291bGQgYmUgdXNlZCBpbnNpZGUgdGhlIFNQIG5ldHdv cmsgaW4gb3JkZXIgdG8gaGF2ZSBhbg0KICAgYWRkaXRpb25hbCAic2l0ZS1sb2NhbCBzY29wZWQi IElQdjYgYWRkcmVzcyBmb3IgU1BzIG93bg0KICAgaW5mcmFzdHJ1Y3R1cmUgZm9yIGluc3RhbmNl IGZvciBuZXR3b3JrIG1hbmFnZW1lbnQgcmVhc29ucyBhbmQgbWF5YmUNCiAgIGFsc28gaW4gb3Jk ZXIgdG8gaGF2ZSBhbiBhZGRyZXNzaW5nIHNjaGVtYSB0aGF0IGNvdWxkbid0IGJlIHJlYWNoZWQN CiAgIGZyb20gb3V0c2lkZSB0aGUgU1AgbmV0d29yay4NCg0KICAgSW4gdGhlIGNhc2Ugd2hlbiBV TEFzIGFyZSB1c2VkIGl0IGlzIHBvc3NpYmxlIHRvIG1hcCB0aGUgcHJvcG9zZWQNCiAgIGludGVy bmFsIElQdjYgYWRkcmVzc2luZyBvZiBTUHMgb3duIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgYXMN CiAgIGRlc2NyaWJlZCBpbiA1LjIuMi4yIGFib3ZlIGRpcmVjdGx5IHRvIHRoZSBVTEEgYWRkcmVz c2luZyBzY2hlbWEgYnkNCiAgIHN1YnN0aXR1dGluZyB0aGUgLzQ4IFBPUCBwcmVmaXggd2l0aCBh IC80OCBVTEEgc2l0ZSBwcmVmaXguDQoNCg0KDQoNClZhbiBkZSBWZWxkZSwgZXQgYWwuICAgIEV4 cGlyZXMgRGVjZW1iZXIgMywgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDIzXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgSVB2NiBBZGRyZXNzaW5nIENvbnNpZGVyYXRpb25zICAgICAgICAgICAg SnVuZSAyMDA2DQoNCg0KNS4yLjMuMi4gIE11bHRpY2FzdA0KDQogICBJUHY2IE11bHRpY2FzdC1y ZWxhdGVkIGFkZHJlc3NpbmcgaXNzdWVzIGFyZSBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMNCiAg IGRvY3VtZW50Lg0KDQo1LjIuMy4zLiAgUE9QIE11bHRpLWhvbWluZyBvciBDaGFuZ2Ugb2YgUE9Q DQoNCiAgIFBPUCAob3IgYmV0dGVyIExFUikgTXVsdGktaG9taW5nIG9mIGN1c3RvbWVycyB3aXRo IHRoZSBzYW1lIFNQIGNhbiBiZQ0KICAgcmVhbGl6ZWQgd2l0aGluIHRoZSBwcm9wb3NlZCBJUHY2 IGFkZHJlc3Npbmcgc2NoZW1hIG9mIHRoZSBTUCBieQ0KICAgYXNzaWduaW5nIG11bHRpcGxlIExF Ui1kZXBlbmRlbnQgcHJlZml4ZXMgdG8gdGhpcyBjdXN0b21lciAoaS5lLg0KICAgY29uc2lkZXJp bmcgZWFjaCBjdXN0b21lciBsb2NhdGlvbiBhcyBhIHNpbmdsZS1zdGFuZGluZyBjdXN0b21lcikg b3INCiAgIGJ5IGNob29zaW5nIGEgY3VzdG9tZXIgcHJlZml4IG91dCBvZiB0aGUgcG9vbCBvZiAi YmlnIiBjdXN0b21lcnMuDQogICBUaGUgc2Vjb25kIHNvbHV0aW9uIGhhcyB0aGUgZGlzYWR2YW50 YWdlIHRoYXQgaW4gZXZlcnkgTEVSIHdoZXJlIHRoZQ0KICAgY3VzdG9tZXIgaXMgYXR0YWNoZWQg dGhpcyBwcmVmaXggd2lsbCBhcHBlYXIgaW5zaWRlIHRoZSBJR1Agcm91dGluZw0KICAgdGFibGUg cmVxdWlyaW5nIGFuIGV4cGxpY2l0IE1QTFMgbGFiZWwuDQoNCiAgIEFuIGVxdWFsIGVmZmVjdCBo YXBwZW5zIHdoZW4gYSBjdXN0b21lciBjaGFuZ2VzIGl0cyBwb2ludCBvZg0KICAgYXR0YWNobWVu dCB0byBhbm90aGVyIFBPUC9MRVIgc2luY2UgaW4gdGhpcyBjYXNlIHRoZSBjdXN0b21lciBwcmVm aXgNCiAgIGNvdWxkIG5vdCBiZSBhZ2dyZWdhdGVkIGludG8gdGhlIExFUiBwcmVmaXggYW5kIG5l ZWRzIHRvIGJlDQogICBhZHZlcnRpc2VkIG1vcmUgc3BlY2lmaWMgaW4gdGhlIElHUC4NCg0KICAg KE5vdGU6IFRoZSBkZXNjcmliZWQgbmVnYXRpdmUgUE9QL0xFUiBNdWx0aS1ob21pbmcgZWZmZWN0 cyB0byB0aGUNCiAgIGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIGluIHRoZSBTUCBhY2Nlc3MgbmV0 d29yayBhcmUgbm90IHRhY2tsZWQgYnkNCiAgIGltcGxlbWVudGluZyB0aGUgU2hpbTYgU2l0ZSBN dWx0aS1ob21pbmcgYXBwcm9hY2ggc2luY2UgdGhpcyBhcHByb2FjaA0KICAgdGFyZ2V0cyBvbmx5 IG9uIGEgbWVjaGFuaXNtIGZvciBkZWFsaW5nIHdpdGggbXVsdGlwbGUgcHJlZml4ZXMgaW4gZW5k DQogICBzeXN0ZW1zIC0tIHRoZSBTUCB3aWxsIG5ldmVydGhlbGVzcyBoYXZlIHVuYWdncmVnYXRl ZCBjdXN0b21lcg0KICAgcHJlZml4ZXMgaW4gaXRzIGludGVybmFsIHJvdXRpbmcgdGFibGVzLikN Cg0KNS4yLjMuNC4gIEV4dGVuc2lvbnMgbmVlZGVkIGZvciB0aGUgbGF0ZXIgSVB2NiBtaWdyYXRp b24gcGhhc2VzDQoNCiAgIFRoZSBwcm9wb3NlZCBJUHY2IGFkZHJlc3Npbmcgc2NoZW1hIGZvciBh IFNQIG5lZWRzIHNvbWUgc2xpZ2h0DQogICBlbmhhbmNlbWVudHMgLyBtb2RpZmljYXRpb25zIGZv ciB0aGUgbGF0ZXIgcGhhc2VzIG9mIElQdjYNCiAgIGludGVncmF0aW9uLCBmb3IgaW5zdGFuY2Ug aW4gdGhlIGNhc2Ugd2hlbiB0aGUgd2hvbGUgTVBMUyBiYWNrYm9uZQ0KICAgaW5mcmFzdHJ1Y3R1 cmUgKExEUCwgSUdQIGV0Yy4pIGlzIHJlYWxpemVkIG92ZXIgSVB2NiB0cmFuc3BvcnQgYW4NCiAg IGFkZHJlc3Npbmcgb2YgdGhlIExTUnMgaXMgbmVlZGVkLiAgT3RoZXIgY2hhbmdlcyBtYXkgYmUg bmVjZXNzYXJ5IGFzDQogICB3ZWxsIGJ1dCBzaG91bGQgbm90IGJlIGV4cGxhaW5lZCBhdCB0aGlz IHBvaW50Lg0KDQoNCjYuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZXJlIGFyZSBubyBl eHRyYSBJQU5BIGNvbnNpZGVyYXRpb24gZm9yIHRoaXMgZG9jdW1lbnQuDQoNCg0KNy4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgSVB2NiBhZGRyZXNzaW5nIGRvY3VtZW50cyBk b2VzIG5vdCBoYXZlIGFueSBkaXJlY3QgaW1wYWN0IG9uDQogICBJbnRlcm5ldCBpbmZyYXN0cnVj dHVyZSBzZWN1cml0eS4NCg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBE ZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjRdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIw MDYNCg0KDQo4LiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBDb25zdHJ1Y3RpdmUgZmVlZGJhY2sg YW5kIGNvbnRyaWJ1dGlvbnMgaGF2ZSBiZWVuIHJlY2VpdmVkIGZyb20gU3RpZw0KICAgVmVuYWFz LCBQZWtrYSBTYXZvbGEsIEpvaG4gU3BlbmNlciwgUGF0cmljayBHcm9zc2V0ZXRlIGFuZCBDYXJs b3MNCiAgIEdhcmNpYSBCcmFzY2hpLg0KDQoNCjkuICBSZWZlcmVuY2VzDQoNCjkuMS4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzDQoNCjkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgWzFd ICAgUmVraHRlciwgWS4sIE1vc2tvd2l0eiwgUi4sIEthcnJlbmJlcmcsIEQuLCBHcm9vdCwgRy4s IGFuZCBFLg0KICAgICAgICAgTGVhciwgIkFkZHJlc3MgQWxsb2NhdGlvbiBmb3IgUHJpdmF0ZSBJ bnRlcm5ldHMiLCBCQ1AgNSwNCiAgICAgICAgIFJGQyAxOTE4LCBGZWJydWFyeSAxOTk2Lg0KDQog ICBbMl0gICBUaG9tc29uLCBTLiBhbmQgVC4gTmFydGVuLCAiSVB2NiBTdGF0ZWxlc3MgQWRkcmVz cw0KICAgICAgICAgQXV0b2NvbmZpZ3VyYXRpb24iLCBSRkMgMjQ2MiwgRGVjZW1iZXIgMTk5OC4N Cg0KICAgWzNdICAgSGluZGVuLCBSLiwgRmluaywgUi4sIGFuZCBKLiBQb3N0ZWwsICJJUHY2IFRl c3RpbmcgQWRkcmVzcw0KICAgICAgICAgQWxsb2NhdGlvbiIsIFJGQyAyNDcxLCBEZWNlbWJlciAx OTk4Lg0KDQogICBbNF0gICBKb2huc29uLCBELiBhbmQgUy4gRGVlcmluZywgIlJlc2VydmVkIElQ djYgU3VibmV0IEFueWNhc3QNCiAgICAgICAgIEFkZHJlc3NlcyIsIFJGQyAyNTI2LCBNYXJjaCAx OTk5Lg0KDQogICBbNV0gICBSZXRhbmEsIEEuLCBXaGl0ZSwgUi4sIEZ1bGxlciwgVi4sIGFuZCBE LiBNY1BoZXJzb24sICJVc2luZyAzMS0NCiAgICAgICAgIEJpdCBQcmVmaXhlcyBvbiBJUHY0IFBv aW50LXRvLVBvaW50IExpbmtzIiwgUkZDIDMwMjEsDQogICAgICAgICBEZWNlbWJlciAyMDAwLg0K DQogICBbNl0gICBOYXJ0ZW4sIFQuIGFuZCBSLiBEcmF2ZXMsICJQcml2YWN5IEV4dGVuc2lvbnMg Zm9yIFN0YXRlbGVzcw0KICAgICAgICAgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiBpbiBJUHY2 IiwgUkZDIDMwNDEsIEphbnVhcnkgMjAwMS4NCg0KICAgWzddICAgSUFCIGFuZCBJRVNHLCAiSUFC L0lFU0cgUmVjb21tZW5kYXRpb25zIG9uIElQdjYgQWRkcmVzcw0KICAgICAgICAgQWxsb2NhdGlv bnMgdG8gU2l0ZXMiLCBSRkMgMzE3NywgU2VwdGVtYmVyIDIwMDEuDQoNCiAgIFs4XSAgIER1cmFu ZCwgQS4gYW5kIEMuIEh1aXRlbWEsICJUaGUgSC1EZW5zaXR5IFJhdGlvIGZvciBBZGRyZXNzDQog ICAgICAgICBBc3NpZ25tZW50IEVmZmljaWVuY3kgQW4gVXBkYXRlIG9uIHRoZSBIIHJhdGlvIiwg UkZDIDMxOTQsDQogICAgICAgICBOb3ZlbWJlciAyMDAxLg0KDQogICBbOV0gICBEcm9tcywgUi4s IEJvdW5kLCBKLiwgVm9seiwgQi4sIExlbW9uLCBULiwgUGVya2lucywgQy4sIGFuZCBNLg0KICAg ICAgICAgQ2FybmV5LCAiRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQ djYNCiAgICAgICAgIChESENQdjYpIiwgUkZDIDMzMTUsIEp1bHkgMjAwMy4NCg0KICAgWzEwXSAg RHJhdmVzLCBSLiwgIkRlZmF1bHQgQWRkcmVzcyBTZWxlY3Rpb24gZm9yIEludGVybmV0IFByb3Rv Y29sDQogICAgICAgICB2ZXJzaW9uIDYgKElQdjYpIiwgUkZDIDM0ODQsIEZlYnJ1YXJ5IDIwMDMu DQoNCiAgIFsxMV0gIEJsYW5jaGV0LCBNLiwgIkEgRmxleGlibGUgTWV0aG9kIGZvciBNYW5hZ2lu ZyB0aGUgQXNzaWdubWVudCBvZg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJl cyBEZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjVdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5l IDIwMDYNCg0KDQogICAgICAgICBCaXRzIG9mIGFuIElQdjYgQWRkcmVzcyBCbG9jayIsIFJGQyAz NTMxLCBBcHJpbCAyMDAzLg0KDQogICBbMTJdICBIaW5kZW4sIFIuLCBEZWVyaW5nLCBTLiwgYW5k IEUuIE5vcmRtYXJrLCAiSVB2NiBHbG9iYWwgVW5pY2FzdA0KICAgICAgICAgQWRkcmVzcyBGb3Jt YXQiLCBSRkMgMzU4NywgQXVndXN0IDIwMDMuDQoNCiAgIFsxM10gIFNhdm9sYSwgUC4sICJVc2Ug b2YgLzEyNyBQcmVmaXggTGVuZ3RoIEJldHdlZW4gUm91dGVycw0KICAgICAgICAgQ29uc2lkZXJl ZCBIYXJtZnVsIiwgUkZDIDM2MjcsIFNlcHRlbWJlciAyMDAzLg0KDQogICBbMTRdICBUcm9hbiwg Ty4gYW5kIFIuIERyb21zLCAiSVB2NiBQcmVmaXggT3B0aW9ucyBmb3IgRHluYW1pYyBIb3N0DQog ICAgICAgICBDb25maWd1cmF0aW9uIFByb3RvY29sIChESENQKSB2ZXJzaW9uIDYiLCBSRkMgMzYz MywNCiAgICAgICAgIERlY2VtYmVyIDIwMDMuDQoNCiAgIFsxNV0gIEZpbmssIFIuIGFuZCBSLiBI aW5kZW4sICI2Ym9uZSAoSVB2NiBUZXN0aW5nIEFkZHJlc3MNCiAgICAgICAgIEFsbG9jYXRpb24p IFBoYXNlb3V0IiwgUkZDIDM3MDEsIE1hcmNoIDIwMDQuDQoNCiAgIFsxNl0gIERyb21zLCBSLiwg IlN0YXRlbGVzcyBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90b2NvbA0KICAgICAgICAg KERIQ1ApIFNlcnZpY2UgZm9yIElQdjYiLCBSRkMgMzczNiwgQXByaWwgMjAwNC4NCg0KICAgWzE3 XSAgSHVpdGVtYSwgQy4gYW5kIEIuIENhcnBlbnRlciwgIkRlcHJlY2F0aW5nIFNpdGUgTG9jYWwN CiAgICAgICAgIEFkZHJlc3NlcyIsIFJGQyAzODc5LCBTZXB0ZW1iZXIgMjAwNC4NCg0KICAgWzE4 XSAgU2F2b2xhLCBQLiBhbmQgQi4gSGFiZXJtYW4sICJFbWJlZGRpbmcgdGhlIFJlbmRlenZvdXMg UG9pbnQNCiAgICAgICAgIChSUCkgQWRkcmVzcyBpbiBhbiBJUHY2IE11bHRpY2FzdCBBZGRyZXNz IiwgUkZDIDM5NTYsDQogICAgICAgICBOb3ZlbWJlciAyMDA0Lg0KDQogICBbMTldICBBcmtrbywg Si4sIEtlbXBmLCBKLiwgWmlsbCwgQi4sIGFuZCBQLiBOaWthbmRlciwgIlNFY3VyZQ0KICAgICAg ICAgTmVpZ2hib3IgRGlzY292ZXJ5IChTRU5EKSIsIFJGQyAzOTcxLCBNYXJjaCAyMDA1Lg0KDQog ICBbMjBdICBBdXJhLCBULiwgIkNyeXB0b2dyYXBoaWNhbGx5IEdlbmVyYXRlZCBBZGRyZXNzZXMg KENHQSkiLA0KICAgICAgICAgUkZDIDM5NzIsIE1hcmNoIDIwMDUuDQoNCiAgIFsyMV0gIEJha2Vy LCBGLiwgTGVhciwgRS4sIGFuZCBSLiBEcm9tcywgIlByb2NlZHVyZXMgZm9yIFJlbnVtYmVyaW5n DQogICAgICAgICBhbiBJUHY2IE5ldHdvcmsgd2l0aG91dCBhIEZsYWcgRGF5IiwgUkZDIDQxOTIs IFNlcHRlbWJlciAyMDA1Lg0KDQogICBbMjJdICBIaW5kZW4sIFIuIGFuZCBCLiBIYWJlcm1hbiwg IlVuaXF1ZSBMb2NhbCBJUHY2IFVuaWNhc3QNCiAgICAgICAgIEFkZHJlc3NlcyIsIFJGQyA0MTkz LCBPY3RvYmVyIDIwMDUuDQoNCiAgIFsyM10gIEhpbmRlbiwgUi4gYW5kIFMuIERlZXJpbmcsICJJ UCBWZXJzaW9uIDYgQWRkcmVzc2luZw0KICAgICAgICAgQXJjaGl0ZWN0dXJlIiwgUkZDIDQyOTEs IEZlYnJ1YXJ5IDIwMDYuDQoNCiAgIFsyNF0gIFRlbXBsaW4sIEYuLCBHbGVlc29uLCBULiwgVGFs d2FyLCBNLiwgYW5kIEQuIFRoYWxlciwgIkludHJhLQ0KICAgICAgICAgU2l0ZSBBdXRvbWF0aWMg VHVubmVsIEFkZHJlc3NpbmcgUHJvdG9jb2wgKElTQVRBUCkiLA0KICAgICAgICAgZHJhZnQtaWV0 Zi1uZ3RyYW5zLWlzYXRhcC0yNCAod29yayBpbiBwcm9ncmVzcyksIEphbnVhcnkgMjAwNS4NCg0K ICAgWzI1XSAgVGVtcGxpbiwgRi4sIEdsZWVzb24sIFQuLCBUYWx3YXIsIE0uLCBhbmQgRC4gVGhh bGVyLCAiSW50cmEtDQogICAgICAgICBTaXRlIEF1dG9tYXRpYyBUdW5uZWwgQWRkcmVzc2luZyBQ cm90b2NvbA0KICAgICAgICAgKGRyYWZ0LWlldGYtbmd0cmFucy1pc2F0YXAtMjQudHh0KSIsIEp1 bHkgMjAwNS4NCg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBEZWNlbWJl ciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIwMDYNCg0K DQogICBbMjZdICBDaG93biwgVC4sICJJUHY2IEltcGxpY2F0aW9ucyBmb3IgVENQL1VEUCBQb3J0 IFNjYW5uaW5nIChjaG93bi0NCiAgICAgICAgIHY2b3BzLSBwb3J0LXNjYW5uaW5nLWltcGxpY2F0 aW9ucy0wMi50eHQpIiwgT2N0b2JlciAyMDA1Lg0KDQogICBbMjddICBBUE5JQywgQVJJTiwgUklQ RSBOQ0MsICJJUHY2IEFkZHJlc3MgQWxsb2NhdGlvbiBhbmQgQXNzaWdubWVudA0KICAgICAgICAg UG9saWN5ICh3d3cucmlwZS5uZXQvcmlwZS9kb2NzL2lwdjZwb2xpY3kuaHRtbCkiLCBKYW51YXJ5 IDIwMDMuDQoNCiAgIFsyOF0gIENob3duLCBULiwgVGhvbXBzb24sIE0uLCBGb3JkLCBBLiwgYW5k IFMuIFZlbmFhcywgIlRoaW5ncyB0bw0KICAgICAgICAgdGhpbmsgYWJvdXQgd2hlbiBSZW51bWJl cmluZyBhbiBJUHY2IG5ldHdvcmsNCiAgICAgICAgIChkcmFmdC1jaG93bi12Nm9wcy1yZW51bWJl ci10aGlua2Fib3V0LTAzLnR4dCkiLCBKdWx5IDIwMDUuDQoNCiAgIFsyOV0gIFBhdWwgV2lsc29u LCBSYXltb25kIFBsemFrLCBBeGVsIFBhd2xpaywgIklQdjYgQWRkcmVzcyBTcGFjZQ0KICAgICAg ICAgTWFuYWdlbWVudCAod3d3LnJpcGUubmV0L3JpcGUvZG9jcy9pcHY2LXNwYXJzZS5odG1sKSIs DQogICAgICAgICBGZWJydWFyeSAyMDA1Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClZhbiBkZSBWZWxk ZSwgZXQgYWwuICAgIEV4cGlyZXMgRGVjZW1iZXIgMywgMjAwNiAgICAgICAgICAgICAgIFtQYWdl IDI3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgSVB2NiBBZGRyZXNzaW5nIENvbnNpZGVyYXRp b25zICAgICAgICAgICAgSnVuZSAyMDA2DQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIEd1 bnRlciBWYW4gZGUgVmVsZGUNCiAgIENpc2NvIFN5c3RlbXMNCiAgIERlIEtsZWV0bGFhbiA2YQ0K ICAgRGllZ2VtICAxODMxDQogICBCZWxnaXVtDQoNCiAgIFBob25lOiArMzIgMjcwNCA1NDczDQog ICBFbWFpbDogZ3VudGVyQGNpc2NvLmNvbQ0KDQoNCiAgIENpcHJpYW4gUG9wb3ZpY2l1DQogICBD aXNjbyBTeXN0ZW1zDQogICA3MDI1LTYgS2l0IENyZWVrIFJvYWQNCiAgIFJlc2VhcmNoIFRyaWFu Z2xlIFBhcmssIE5vcnRoIENhcm9saW5hICBQTyBCb3ggMTQ5ODcNCiAgIFVTQQ0KDQogICBQaG9u ZTogKzEgOTE5IDM5Mi0zNzIzDQogICBFbWFpbDogY3BvcG92aWNAY2lzY28uY29tDQoNCg0KICAg VGltIENob3duDQogICBVbml2ZXJzaXR5IG9mIFNvdXRoYW1wdG9uDQogICBIaWdoZmllbGQNCiAg IFNvdXRoYW1wdG9uLCAgIFNPMTcgMUJKDQogICBVbml0ZWQgS2luZ2RvbQ0KDQogICBQaG9uZTog KzQ0IDIzIDgwNTkgMzI1Nw0KICAgRW1haWw6IHRqY0BlY3Muc290b24uYWMudWsNCg0KDQogICBP bGFmIEJvbm5lc3MNCiAgIFQtU3lzdGVtcyBFbnRlcnByaXNlIFNlcnZpY2VzIEdtYkgNCiAgIEdv c2xhcmVyIFVmZXIgMzUNCiAgIEJlcmxpbiwgICAxMDU4OQ0KICAgR2VybWFueQ0KDQogICBQaG9u ZTogKzQ5IDMwIDM0OTcgMzEyNA0KICAgRW1haWw6IE9sYWYuQm9ubmVzc0B0LXN5c3RlbXMuY29t DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KVmFuIGRlIFZlbGRlLCBldCBhbC4gICAgRXhwaXJlcyBE ZWNlbWJlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICBJUHY2IEFkZHJlc3NpbmcgQ29uc2lkZXJhdGlvbnMgICAgICAgICAgICBKdW5lIDIw MDYNCg0KDQogICBDaHJpc3RpYW4gSGFobg0KICAgVC1TeXN0ZW1zIEVudGVycHJpc2UgU2Vydmlj ZXMgR21iSA0KICAgR29zbGFyZXIgVWZlciAzNQ0KICAgQmVybGluLCAgIDEwNTg5DQogICBHZXJt YW55DQoNCiAgIFBob25lOiArNDkgMzAgMzQ5NyAzMTY0DQogICBFbWFpbDogSGFobkNAdC1zeXN0 ZW1zLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpWYW4gZGUgVmVsZGUsIGV0IGFs LiAgICBFeHBpcmVzIERlY2VtYmVyIDMsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAyOV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgIElQdjYgQWRkcmVzc2luZyBDb25zaWRlcmF0aW9ucyAgICAg ICAgICAgIEp1bmUgMjAwNg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0K ICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBz Y29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmln aHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50 YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1 bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRz DQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNl bnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlm eSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0 aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4g QkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0 byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2Vz IHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1h ZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ug b2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBv ZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9u LWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQog ICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBh dHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlv bnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5v bG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQu ICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYt aXByQGlldGYub3JnLg0KDQoNCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1 bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9u IGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJ T04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBG T1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5D TFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRI RQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1Ig QU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAg Q29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuICBUaGlzIGRvY3VtZW50 IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMg Y29udGFpbmVkIGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4s IHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50 DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBw cm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2lldHkuDQoNCg0KDQoNClZhbiBkZSBWZWxk ZSwgZXQgYWwuICAgIEV4cGlyZXMgRGVjZW1iZXIgMywgMjAwNiAgICAgICAgICAgICAgIFtQYWdl IDMwXQ0KDA0KDQo= ------_=_NextPart_001_01C6A157.2108FA96-- From owner-v6ops@ops.ietf.org Fri Jul 07 19:50:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz05H-0007LG-6E for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 19:50:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz05F-0002Xv-HC for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 19:50:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz01u-0007Ip-LC for v6ops-data@psg.com; Fri, 07 Jul 2006 23:46:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [203.59.1.196] (helo=mail-ihug.icp-qv1-irony2.iinet.net.au) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz01t-0007IX-IN for v6ops@ops.ietf.org; Fri, 07 Jul 2006 23:46:37 +0000 Received: from 203-173-22-103.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.22.103]) by mail-ihug.icp-qv1-irony2.iinet.net.au with ESMTP; 08 Jul 2006 07:46:30 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,219,1149436800"; d="scan'208"; a="545467511:sNHT14858552" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 1D9C93FB0; Sat, 8 Jul 2006 09:16:24 +0930 (CST) Date: Sat, 8 Jul 2006 09:16:23 +0930 From: Mark Smith To: "Chip Popoviciu \(cpopovic\)" Cc: v6ops@ops.ietf.org Subject: Re: New version of the "IPv6 Unicast Address Assignment Considerations" draft Message-Id: <20060708091623.c7187971.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <3D1C81E7AA3CD64FA20B04D269FEF7F401C38BE3@xmb-rtp-213.amer.cisco.com> References: <3D1C81E7AA3CD64FA20B04D269FEF7F401C38BE3@xmb-rtp-213.amer.cisco.com> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi Chip, Everybody, On Thu, 6 Jul 2006 19:51:40 -0400 "Chip Popoviciu \(cpopovic\)" wrote: > Dear v6ops WG members, > > We submitted version -01 of the "IPv6 Unicast Address Assignment > Considerations" draft today, past the June 26 deadline which means it > will not be published in time for IETF 66. This version integrates the > WG feedback and the new Service Provider addressing case study. We will > review these changes during our presentation in Montreal so we wanted to > make sure that this new version is available to the work group, even > though it comes as an attachment to this e-mail. > I've been reading through the SP section, and have some comments. I realise that the SP network that is used as an example is an example. However, while reading through it, I seemed to be trying to read or find a description of a general model for addressing that would apply to any SP network, rather than an MPLS one. While reading through the description, I found that I was trying to map those MPLS specific terms back to more general purpose / functional ones, probably in part because at the smaller SP I work for, we don't have MPLS deployed yet, so I don't "think" in MPLS terms yet. I'd suggest the first section of the SP addressing part could describe a general model of SP IPv6 addressing. A subsequent section or sections could describe technology specific deployment models as well as specific considerations or constraints that addressing causes or effects, such as the MPLS label conservation concern, or IGP scaling. Following a model description, I think a section summarising or listing the addressing space allocations/layout would be useful, matching the address blocks to their purpose. This would provide a single overview of the address plan being used. I'd also think a section describing how to better re-balance the size allocations would be useful, as well as describing constraints and consideration of those resizings. For example, at the SP I work for, we have a lot more smaller customers (residential / small business), and therefore reserving /46s for the each /48s we'd be likely to give those customers would be excessive. While I personally generally prefer the idea of giving all customers a /48, the per-customer /56 that has been suggested in other forums would likely be plenty of address space for most (if not all) of our customers, so even /48s can be considered excessive. Hope this helps, Mark. From owner-v6ops@ops.ietf.org Fri Jul 07 23:14:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz3Ge-000717-CM for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 23:14:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz3Gc-0001YI-VM for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 23:14:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz3Dw-000OlL-Fm for v6ops-data@psg.com; Sat, 08 Jul 2006 03:11:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz3Dv-000Ol6-UZ for v6ops@ops.ietf.org; Sat, 08 Jul 2006 03:11:16 +0000 Received: from [142.131.134.248] (unknown [142.131.134.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id 9673678C09; Sat, 8 Jul 2006 05:11:12 +0200 (CEST) In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> <70C6EFCDFC8AAD418EF7063CD132D0640125ACE4@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <717678E7-2526-4AC6-8701-B959C3FADAD9@kurtis.pp.se> Cc: "Iljitsch van Beijnum" , "Marc Blanchet" , Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: v6 multihoming and route filters Date: Fri, 7 Jul 2006 19:05:58 +0200 To: Christian Huitema X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On 5 jul 2006, at 03.12, Christian Huitema wrote: > > We should really think twice before asking the IETF to publish a > position on this subject. Silence may well be the right approach. I am with Christian here. The existence of a prefix of a given length in the routing table is dependent on someone deciding this prefix precious enough to accept it. If we take v4 history as an example both Verio and Sprint used to have extremely tight prefix filtering in place. AFAICT not any more. At the end of the day - revenue wins. I think we should simply leave prefix recommendations out. No prefix allocated or assigned by the RIRs is guaranteed routability.... - kurtis - From owner-v6ops@ops.ietf.org Fri Jul 07 23:14:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz3Gn-00074i-8J for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 23:14:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz3Gk-0001YR-VP for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 23:14:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz3Ew-000Onw-8y for v6ops-data@psg.com; Sat, 08 Jul 2006 03:12:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz3Ev-000Onf-Jd for v6ops@ops.ietf.org; Sat, 08 Jul 2006 03:12:17 +0000 Received: from [142.131.134.248] (unknown [142.131.134.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id 01EB578C3C; Sat, 8 Jul 2006 05:12:13 +0200 (CEST) In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Christian Huitema" , "Iljitsch van Beijnum" , "Marc Blanchet" , Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: v6 multihoming and route filters Date: Fri, 7 Jul 2006 23:14:39 +0200 To: "Azinger, Marla" X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On 5 jul 2006, at 18.02, Azinger, Marla wrote: > I urge everyone to seriously consider that silence is not a good > answer. This internet community needs, wants and is asking for > direction. Whatever comes out of this discussion, verbalizing a > plan (be it with flaws or not) is better than no plan at all. > Silence has been a large part of this issue for some time now (with > various internet conference venues) and all this has done is create > confusion and finger pointing and thus total feeling of lost and > confused routing for developing V6 networks. > > Also, correct me if I'm wrong...but I didn't think the global > routing table should be seeing the "metropolitan aggregation" > setup. So /48 filter shouldn't interfere with that kind of setup. Where Is Sean Doran when you need him.... Sean (I think), was the first to start advocating string filtering on RIR allocation boundaries in IPv4. Randy at Verio followed and there where other Tier-1s as well. And life was good. Until downstreams started to move to Tier-1s that was receptacle for a) Money b) more specific prefixes. Sean at the IEPG meeting in Dec 2000 noted that the only scaleable solution to this is charging per prefix. Randy and Sean had left, filtering fell away, money in the hand carried the day. Route filtering is a policy set by the receiving provider. I don't believe there is anything here that the IETF ca say that will make a lasting impression. - kurtis - From owner-v6ops@ops.ietf.org Fri Jul 07 23:14:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz3Gu-0007Mm-UK for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 23:14:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz3Gt-0001YZ-M0 for v6ops-archive@lists.ietf.org; Fri, 07 Jul 2006 23:14:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz3E0-000Olm-Gv for v6ops-data@psg.com; Sat, 08 Jul 2006 03:11:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12 autolearn=no version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fz3Dz-000OlR-9E for v6ops@ops.ietf.org; Sat, 08 Jul 2006 03:11:19 +0000 Received: from [142.131.134.248] (unknown [142.131.134.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id B8CF978C38; Sat, 8 Jul 2006 05:11:15 +0200 (CEST) In-Reply-To: <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> <20060705164745.GF32758@vacation.karoshi.com.> <20DBAF26-CC0B-4F17-B731-14CFDFB8FABF@muada.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14ADECE2-DA23-4736-84B7-48978791DC67@kurtis.pp.se> Cc: bmanning@vacation.karoshi.com, "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: v6 multihoming and route filters Date: Fri, 7 Jul 2006 19:20:03 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 5 jul 2006, at 20.55, Iljitsch van Beijnum wrote: > > And since the IETF is (hopefully) the place where internet routing > is best understood an the IETF has historically always had an > operational component (hence the existence of this very working > group), I think the IETF can't shy away from at the very least > discouraging harmful practices, and preferably also pointing out > tradeoffs that exist between different choices and recommend best > practices if such can be identified. But the IETF have no understanding of the underlying financial motives. I certainly agree that it's bad practice but there is no way that the IETF in practice can enforce a policy of /48 multihoming OR filtering at /32 - except to present alternative technologies. - kurtis - From owner-v6ops@ops.ietf.org Sat Jul 08 14:49:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzHrx-0001mC-F6 for v6ops-archive@lists.ietf.org; Sat, 08 Jul 2006 14:49:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzHrw-0000Ky-1v for v6ops-archive@lists.ietf.org; Sat, 08 Jul 2006 14:49:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzHo5-000Nkq-Rb for v6ops-data@psg.com; Sat, 08 Jul 2006 18:45:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzHo5-000Nkd-5l for v6ops@ops.ietf.org; Sat, 08 Jul 2006 18:45:33 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2006 11:45:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k68IjWD5001100; Sat, 8 Jul 2006 11:45:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k68IjVDD021986; Sat, 8 Jul 2006 11:45:32 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Jul 2006 11:45:31 -0700 Received: from [10.2.190.248] ([10.21.98.180]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 8 Jul 2006 11:45:30 -0700 In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> <44A965FC.4090700@hotnic.net> <578F09DE-BA19-4A58-9D14-127B66810F35@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <142185B3-8B45-4BB5-BFE9-1A3A521A8AC9@cisco.com> Cc: Iljitsch van Beijnum , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: v6 multihoming and route filters Date: Sat, 8 Jul 2006 14:45:29 -0400 To: Marc Blanchet X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 08 Jul 2006 18:45:30.0953 (UTC) FILETIME=[B027EB90:01C6A2BE] DKIM-Signature: a=rsa-sha1; q=dns; l=1560; t=1152384332; x=1153248332; c=relaxed/simple; s=sjdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20v6=20multihoming=20and=20route=20filters; X=v=3Dcisco.com=3B=20h=3DlScuj+LogP+54f1yiZ9dr3xI0iw=3D; b=BTPR6XoQiYu2hZV0CL8MJTiw5BtBNuM/vug6hYaKb4Lc68aJTMaQcDL4XZL0L2nGOcQCQjka d0hI8j3PKwShLx8Bii5dmrRkMs3M1+I+prASj5eDAVpnKh7PVOj3Zl63; Authentication-Results: sj-dkim-1.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Jul 4, 2006, at 7:04 PM, Marc Blanchet wrote: > the fact that I'm suggesting to filter at the /48 level is just > that I don't know how to build a concensus right now on another > more restrictive boundary. for the global routing table > perspective, I would love to recommend /32 or smaller, but I'm not > sure we can get that agreement. I'm not in the middle of ARIN etc, and frankly think they know their business better than I know their business. Consider this my two yen from a distant part of the peanut gallery. That said, the counterpart here is to say that a typical business gets a /28 IPv4 prefix (or whatever it gets), so the obvious BGP filter level is /28 in IP. That's no a meaningful recommendation, even if it was acceptable - you're never going to get anything smaller than that in the first place. In the IPv4 world, the guideline is generally that one filters to the allocation level (/20 or /19 or whatever - it changes) and goes for a longer one only if one has a business reason to do so. AFAIK, the counterpart in IPv6 is a /32. So it seems like the initial recommendation for IPv6 should be as it has indeed been - that one filter to the allocation level unless one has a business reason to accept a longer one. If the operational community wants to split the difference somewhere, so be it. I could imagine a /40 if the operational community decided that scaled adequately for their needs. But if you're filtering at / 48, there is no point in filtering. From owner-v6ops@ops.ietf.org Sun Jul 09 08:57:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzYqf-0002fC-0Z for v6ops-archive@lists.ietf.org; Sun, 09 Jul 2006 08:57:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzYqd-0000YG-F7 for v6ops-archive@lists.ietf.org; Sun, 09 Jul 2006 08:57:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzYnf-0006eL-RU for v6ops-data@psg.com; Sun, 09 Jul 2006 12:54:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzYne-0006e4-Az for v6ops@ops.ietf.org; Sun, 09 Jul 2006 12:54:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k69CrxRR005459; Sun, 9 Jul 2006 15:53:59 +0300 Date: Sun, 9 Jul 2006 15:53:59 +0300 (EEST) From: Pekka Savola To: "Chip Popoviciu (cpopovic)" cc: v6ops@ops.ietf.org, "Ahmed Hamza (ahamza)" , "Gunter Van de Velde (gvandeve)" , Diego Dugatkin , "Kine, Bill" Subject: Re: IPv6 Benchmarking Draft - Please provide feedback In-Reply-To: <3D1C81E7AA3CD64FA20B04D269FEF7F4019F538D@xmb-rtp-213.amer.cisco.com> Message-ID: References: <3D1C81E7AA3CD64FA20B04D269FEF7F4019F538D@xmb-rtp-213.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1589/Fri Jul 7 17:37:51 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 On Thu, 8 Jun 2006, Chip Popoviciu (cpopovic) wrote: > We would like to ask for your feedback on an "IPv6 Benchmarking" draft > (attached) we are working on within the Benchmarking Working Group. This > work was started and is driven by the great demand we see for > benchmarking guidelines on evaluating the IPv6 performance of network > devices. This is a subject of great interest to those who deployed or > consider the deployment of IPv6. ... Looked pretty good to me. I think the benchmark should test the hop-by-hop (esp router alert) option performance though (see below). ... ==> The document should state in Introduction and perhaps in abstract that it Updates 2544 (also add that to the header). 4.3. Traffic with Extension Headers ... In agreement with RFC2544 omission of tests with IPv4 traffic that includes IP options, this document makes no benchmarking recommendations for traffic with IPv6 traffic with the Hop-by-Hop extension header. ==> Could you clarify what this means? That these don't need to be benchmarked and/or the results don't need to be published? This would be very unfortunate. In fact, one of the most important performance tests for a v6 device I'd like to see is how it performs when receiving forwarded packets with Hop-by-Hop header and either a Router Alert option or an unknown option (see also the expired draft-krishnan-ipv6-hopbyhop-00). Making that a mandatory part of the test would be a good idea. For the most cases, the network elements ignore the EH when forwarding IPv6 traffic. For these reasons it is most likely that the EH related performance impact will be observed only when testing the DUT with traffic filters that contain matching conditions for the upper layer protocol information. ==> hop-by-hop header is unfortunately an exception here, which is why it'd be very useful to benchmark it. 5. Modifiers RFC2544 underlines the importance of evaluating the performance of network elements under certain operational conditions. The conditions defined in RFC2544 Section 11 are common to IPv4 and IPv6 with the exception of Broadcast Frames. IPv6 does not use layer 2 or layer 3 broadcasts. This section provides additional conditions that are specific to IPv6. ==> so, what is the equivalent test with v6? All-hosts multicast packets, something else, or is the test omitted? The following filter format SHOULD be use for this type of evaluation: ==> s/use/used/ 7. IANA Considerations IANA SHOULD reserve an IPv6 prefix for benchmarking purposes similar to 192.18.0.0 in RFC 3330 [7]. ==> you need to give IANA a bit of guidance on which kind of prefix length you'd want, maybe a /32?. It's also not clear if IANA has available resources for this: "The block of Sub-TLA IDs assigned to the IANA (i.e., 2001: 0000::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges." [RFC2928] .. but maybe this qualifies under "testing". In any case, I'd suspect almost every test could also be done with prefixes from a ULA block so I'd have a contingency plan ready in case you don't get the allocation from IANA. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 09 09:05:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzYyp-0003cH-Vj for v6ops-archive@lists.ietf.org; Sun, 09 Jul 2006 09:05:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzYyp-0002Qd-HU for v6ops-archive@lists.ietf.org; Sun, 09 Jul 2006 09:05:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzYyM-0007hN-Gf for v6ops-data@psg.com; Sun, 09 Jul 2006 13:05:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzYyL-0007h9-1m for v6ops@ops.ietf.org; Sun, 09 Jul 2006 13:05:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k69D5BjT006125; Sun, 9 Jul 2006 16:05:11 +0300 Date: Sun, 9 Jul 2006 16:05:11 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: int-area@ietf.org Subject: RFC 3484 address selection problem statement comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1589/Fri Jul 7 17:37:51 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Hi, (Crossposting as RFC 3484 update is being discussed on int-area..) A few comments on: Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules draft-arifumi-v6ops-addr-select-ps-00.txt .. which I believe is a good start at gathering bits and pieces for RFC 3484 update. Comments below, mostly relating to making it clearer what the actual problem is (but this is to be expected in a -00 problem statement draft :-): substantial ----------- Section 2.1.3. Half-Closed Network Problem .... This network environment is commonly used in practice because the access-line to the ISP2 might actually be a VPN tunnel over ISP1 and the Internet. ==> it's not clear what you're using as a justification in saying that the network environment is commonly used in practice. Typical enterprise VPN deployments (so far as I've seen) often route all the traffic through them (i.e., are connected to the Internet). Are you referring to ones which only route enterprise's IP traffic to the enterprise? Or that because you don't actually need a second physical network connection (you can use logical one as well), connecting to a half-closed network is easy? In any case, this calls for a bit of rewording. In NAP [I-D.ietf-v6ops-nap], the use of ULA is recommended from a security point of view. That document proposes the use of ULA for internal communication and filtering those packets with ULA address at Gateway. ==> I think this should be rephrased. I don't think ULA is necessarily "recommended" in general, but rather in those scenarios where you need certain functionality. Maybe say: As NAP [I-D.ietf-v6ops-nap] describes, using ULA may be beneficial in some scenarios. If ULA is used for internal communication, packets with ULA addresses need to be filtered at Gateway. 2.1.5 Site Renumbering ==> you describe a site renumbering scenario, but it's not clear what's the exact address selection problem here. Make it clearer. It would be better if you could turn the temporary address on and off. It would also be better if you could switch its usage per service(destination address). The same situation can be found when using HA and CoA in MobileIP network. ==> as a matter of fact, RFC 3484 already includes a MUST that implementations should provide similar kind of toggle. I don't it has been that widely implemented though... Maybe state clearer that the problem isn't so much about specification but with implementation. 2.2.1. IPv4 or IPv6 prioritization ==> this section doesn't spell out the problem. You probably meant to say that configuring the RFC 3484 preferences on each host separately is too cumbersome. 2.2.2. ULA and IPv4 dual-stack environment This is a special form of IPv4 and IPv6 prioritization. When an ISP has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, and the ISP wants to provide site-local IPv6 connectivity, ULA is the best choice for site-local IPv6 connectivity. ==> I doubt there are "ISPs" as such which offer ULA addresses. You probably meant an Enterprise instead of ISP. ==> later on, you also don't describe the exact problem. Given that we already have RFC4191 which allows advertising more specific routes, that would mitigate this problem. I guess at least part of the issue is that RFC4191 support isn't yet widely enough deployed? 2.2.3. ULA or Global Prioritization It is very common to differentiate services by the client's source address. IP-address-based authentication is an extreme example of this. Another typical example is a web service that has pages for the public and internal pages for employees or involved parties. Yet another example is DNS zone splitting. However, ULA and IPv6 global address both have global scope, and default rules do not specify which address should be given priority. This point makes IPv6 implementation of address-based service differentiation a bit harder. ==> the last paragraph should answer the question "given priority .. where?" In applications? Note that different deployments have very likely exactly the opposite goals, so one-size-fits-all solution might be different to come by (though I'm not sure if folks have tried). You should maybe describe the exact problem at a bit more length -- maybe configuration of this priorization is not easy enough (in a host, or site-wide)? 4. Security Considerations This is a problem statement draft. Security considerations need to be identified for each solution. ==> I'm not sure if this is an appropriate short cut :-). You should be asking yourself, "does any of the problems mentioned have significant security issues?". If yes, those should be mentioned so that that could be used as a factor when deciding which ones need to be addressed and how urgently. editorial --------- ==> the document should use the documentation prefix(es) throughout the document (e.g., instead of 6bone or v4 private addresses). Another approach is to configure the gateways but not the Host and make use of packet redirection between the gateways. ==> s/but not the Host and/to/ (seems redundant..) RFC 3041 [RFC3041] defines a Temporary Address, which is a cutting- edge technique. The usage of Temporary Address has both pros and cons. It is good for viewing web-pages or communicating with the general public, but it is bad for a service that uses address-based authentication. ==> I'm not sure if I'd call RFC 3041 "cutting-edge" technique anymore.. It's already a bit old :-) ==> solely "address-based authentication" is typically discouraged, so this is a potential for rat-holing discussions.. [I-D.arifumi-ipv6-policy-dist] Matsumoto, A., "Practical Usages of Default Address Selection Policy Distribution", draft-arifumi-ipv6-policy-dist-00 (work in progress), December 2005. [I-D.fujisaki-dhc-addr-select-opt] Fujisaki, T., "Distributing Default Address Selection Policy using DHCPv6", draft-fujisaki-dhc-addr-select-opt-01 (work in progress), December 2005. ==> these should likely be informative references, at least the latter one.. 6.2. Informative References ==> on the other hand, some of these (at least the ULA doc) should be normative.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Jul 09 20:25:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzjan-0008O8-45 for v6ops-archive@lists.ietf.org; Sun, 09 Jul 2006 20:25:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzjal-00026Z-Ls for v6ops-archive@lists.ietf.org; Sun, 09 Jul 2006 20:25:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzjWz-0004LM-Ds for v6ops-data@psg.com; Mon, 10 Jul 2006 00:21:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FzjWx-0004L1-UB for v6ops@ops.ietf.org; Mon, 10 Jul 2006 00:21:44 +0000 Received: from [192.168.1.107] (bas1-montreal42-1177928438.dsl.bell.ca [70.53.194.246]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6A0LRXj008694 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Jul 2006 02:21:29 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Azinger, Marla" , "Christian Huitema" , "Marc Blanchet" , Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Sun, 9 Jul 2006 20:21:30 -0400 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On 7-jul-2006, at 17:14, Kurt Erik Lindqvist wrote: > Where Is Sean Doran when you need him.... Probably stuck at some airport... :-( (-: > Sean (I think), was the first to start advocating string filtering > on RIR allocation boundaries in IPv4. Randy at Verio followed and > there where other Tier-1s as well. And life was good. Except for the people who were now filtered with no prior warning and no recourse. The IETF can't and shouldn't want to mandate how people run their networks, but things work a lot better if there is consensus about the parameters within which everyone applies their own judgement. > Sean at the IEPG meeting in Dec 2000 noted that the only scaleable > solution to this is charging per prefix. Actually, this doesn't scale at all. I don't know how many networks that run defaultless there are, and how many of those do so out of necessity, but tracking all of them down and paying all of them some money (how do you decide how much each one gets?) is certainly NOT scalable. > Route filtering is a policy set by the receiving provider. I don't > believe there is anything here that the IETF ca say that will make > a lasting impression. You may be right, but my reasoning is: the most common IPv4 practice (filter at /24) doesn't translate to IPv6, everyone doing their own thing is suboptimal, and there doesn't seem to be another forum to decide on this, ergo the IETF should step up. From owner-v6ops@ops.ietf.org Mon Jul 10 06:59:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FztTo-0006Fn-9M for v6ops-archive@lists.ietf.org; Mon, 10 Jul 2006 06:59:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FztTj-0007TA-Vy for v6ops-archive@lists.ietf.org; Mon, 10 Jul 2006 06:59:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FztOv-000Nll-Qg for v6ops-data@psg.com; Mon, 10 Jul 2006 10:54:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FztOs-000NlX-UJ for v6ops@ops.ietf.org; Mon, 10 Jul 2006 10:54:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6AAqdlf010421; Mon, 10 Jul 2006 13:52:39 +0300 Date: Mon, 10 Jul 2006 13:52:39 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Kurt Erik Lindqvist , "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters In-Reply-To: Message-ID: References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1589/Fri Jul 7 17:37:51 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Sun, 9 Jul 2006, Iljitsch van Beijnum wrote: > Except for the people who were now filtered with no prior warning and no > recourse. The IETF can't and shouldn't want to mandate how people run their > networks, but things work a lot better if there is consensus about the > parameters within which everyone applies their own judgement. You seem to have the assumption that it is possible to come to a consensus (with a reasonable time and energy investment) that satisfies the stakeholders. I'm almost certain it won't be possible, hence I'm rather skeptical about wasting time in trying. So, I'm advocating that we should aim for a trade-off document instead if we really want to do something here and if we by some miracle happen to get to consensus, even better.. :-) > You may be right, but my reasoning is: the most common IPv4 practice (filter > at /24) doesn't translate to IPv6, everyone doing their own thing is > suboptimal, and there doesn't seem to be another forum to decide on this, > ergo the IETF should step up. Yes, the IETF has been known of its exercises in futility in the past so one more time won't hurt... ;-( -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Jul 10 13:43:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzzmz-00013o-94 for v6ops-archive@lists.ietf.org; Mon, 10 Jul 2006 13:43:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzzmw-00074r-OY for v6ops-archive@lists.ietf.org; Mon, 10 Jul 2006 13:43:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fzzjn-000NFl-Mr for v6ops-data@psg.com; Mon, 10 Jul 2006 17:40:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fzzjl-000NEh-Sl for v6ops@ops.ietf.org; Mon, 10 Jul 2006 17:40:02 +0000 Received: from [132.219.20.240] (unknown [132.219.20.240]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id 245B278C09; Mon, 10 Jul 2006 19:39:57 +0200 (CEST) In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54A143F0-DF64-46AC-907D-B3DB9995AE3E@kurtis.pp.se> Cc: "Azinger, Marla" , "Christian Huitema" , "Marc Blanchet" , Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: v6 multihoming and route filters Date: Mon, 10 Jul 2006 19:42:13 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On 10 jul 2006, at 02.21, Iljitsch van Beijnum wrote: > On 7-jul-2006, at 17:14, Kurt Erik Lindqvist wrote: >> Sean (I think), was the first to start advocating string filtering >> on RIR allocation boundaries in IPv4. Randy at Verio followed and >> there where other Tier-1s as well. And life was good. > > Except for the people who were now filtered with no prior warning > and no recourse. The IETF can't and shouldn't want to mandate how > people run their networks, but things work a lot better if there is > consensus about the parameters within which everyone applies their > own judgement. Problem is that one size does not fit all here. I might want to filter some /48s and others not, depending on who I might think I could push to become a down-stream as well. >> Sean at the IEPG meeting in Dec 2000 noted that the only scaleable >> solution to this is charging per prefix. > > Actually, this doesn't scale at all. I don't know how many networks > that run defaultless there are, and how many of those do so out of > necessity, but tracking all of them down and paying all of them > some money (how do you decide how much each one gets?) is certainly > NOT scalable. Money in this case will "flow-upwards". >> Route filtering is a policy set by the receiving provider. I don't >> believe there is anything here that the IETF ca say that will make >> a lasting impression. > > You may be right, but my reasoning is: the most common IPv4 > practice (filter at /24) doesn't translate to IPv6, everyone doing > their own thing is suboptimal, and there doesn't seem to be another > forum to decide on this, ergo the IETF should step up. But there is no way to ensure this is followed, actually it's most likely not followed. You can't put 2119 keywords in, so at best you get to document the trade-offs and at the end of the day people will take the approach that will maximise their revenue stream... - kurtis - From avay@0451.com Tue Jul 11 12:34:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0LCE-0004b7-T2 for v6ops-archive@lists.ietf.org; Tue, 11 Jul 2006 12:34:50 -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 1G0LCE-0005Bl-Rh for v6ops-archive@lists.ietf.org; Tue, 11 Jul 2006 12:34:50 -0400 Received: from [213.175.63.51] (helo=amb-kxtrcesnf4x) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0L7J-0000OE-QC for v6ops-archive@lists.ietf.org; Tue, 11 Jul 2006 12:29:49 -0400 Message-ID: <662161c80604qruvkv1x327xam9h2pijit59qg96bnu8@mail.0451.com> Date: Tue, 11 Jul 2006 16:29:43 -0060 From: "Laurel Major" To: v6ops-archive@lists.ietf.org Subject: 8G0 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 4.6 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 clean, not overgrown with any garbage, and unchanged in color. I just looked Gobi or Newfoundland seemed more likely than Harmont." won't get off with six months. And they'll kick you out of the institute wingspan and performance that could be plotted on a chart. The trick was From owner-v6ops@ops.ietf.org Tue Jul 11 18:53:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0R6r-0008DD-VM for v6ops-archive@lists.ietf.org; Tue, 11 Jul 2006 18:53:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0R6q-00021R-Ij for v6ops-archive@lists.ietf.org; Tue, 11 Jul 2006 18:53:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0R48-000HyN-Lz for v6ops-data@psg.com; Tue, 11 Jul 2006 22:50:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0R48-000Hy3-0n for v6ops@ops.ietf.org; Tue, 11 Jul 2006 22:50:52 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6BMok1u020455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 22:50:47 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G0R3J-00036q-Hw; Tue, 11 Jul 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-addcon-01.txt Message-Id: Date: Tue, 11 Jul 2006 18:50:01 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Unicast Address Assignment Considerations Author(s) : G. Van de Velde, et al. Filename : draft-ietf-v6ops-addcon-01.txt Pages : 30 Date : 2006-7-11 One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the integration of IPv6. This draft aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The draft also provides IPv6 addressing case studies for both an enterprise and an ISP network. In this first version of the draft we aim to provoke discussion on this important topic; more detailed case study texts will follow. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-addcon-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-addcon-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-11152105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-addcon-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-addcon-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-11152105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 12 09:29:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0emn-0006VZ-Ar for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 09:29:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0eml-0003bS-Vm for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 09:29:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0ek5-0004lC-D7 for v6ops-data@psg.com; Wed, 12 Jul 2006 13:27:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.182.142] (helo=e2.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0ek4-0004l0-IX for v6ops@ops.ietf.org; Wed, 12 Jul 2006 13:27:04 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6CDR3xm020972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 12 Jul 2006 09:27:03 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6CDR2DM281448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Jul 2006 09:27:03 -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 k6CDR2Bb017621 for ; Wed, 12 Jul 2006 09:27:02 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-237.mts.ibm.com [9.65.200.237]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6CDR27t017599 for ; Wed, 12 Jul 2006 09:27:02 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k6CDQRl1018072 for ; Wed, 12 Jul 2006 09:26:36 -0400 Message-Id: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> To: v6ops@ops.ietf.org Subject: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Wed, 12 Jul 2006 09:26:27 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just prior to the ID cutoff, and the authors believe it is ready for publication as an RFC. We are in discussion with the ADs about having the document shepherded through the IESG as an informational document. Note that this document would formally replace RFC3177. Comments welcome of course! Thomas From owner-v6ops@ops.ietf.org Wed Jul 12 09:44:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0f0T-0006Ig-JT for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 09:44:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0f0R-0005OP-4m for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 09:44:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0ezn-0006D7-Dn for v6ops-data@psg.com; Wed, 12 Jul 2006 13:43:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [204.9.221.19] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0ezm-0006Cp-9Z for v6ops@ops.ietf.org; Wed, 12 Jul 2006 13:43:18 +0000 Received: from [132.219.28.212] (account margaret [132.219.28.212] verified) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1103666; Wed, 12 Jul 2006 09:43:17 -0400 Mime-Version: 1.0 (Apple Message framework v750) References: <00ba01c69af8$3bb2d360$f66514ac@corp.devicescape.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5737495F-D373-47A2-8BB6-B10D250E2042@thingmagic.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Fwd: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 12 Jul 2006 09:43:02 -0400 To: Tony Hain X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 FYI -- Here is the message I mentioned in today's meeting. My questions are near the end. Margaret --- Begin forwarded message: > From: "Margaret Wasserman" > Date: June 28, 2006 5:17:16 PM EDT > To: > Cc: "'Tony Hain'" , "'Tim Chown'" > , "'Radia Perlman'" , > "'Alex Zinin'" , "'Erik Nordmark'" > , , "'Dave > Oran'" , "'Bill Fenner'" , > "'Jari Arkko'" , > Subject: RE: Review of draft-ietf-v6ops-nap-02.txt > > > Hi All, > > As I understand it, there is a current proposal in the v6ops WG (in > draft-ietf-v6ops-nap-03-draft0.txt) to publish the following > recommendation: > > There are other possible scenarios for the extreme situation when a > network manager also wishes to fully conceal the internal IPv6 > topology. In these cases the goal in replacing the IPv4 NAT > approach > is to make all of the topology hidden nodes appear from the outside > to exist at the edge of the network, just as they would when > behind a > NAT. > > o One could use explicit host routes and remove the correlation > between location and IPv6 address. In the figure below the > hosts > would be allocated prefixes from one or more logical subnets, > and > would inject host routes to internally identify their real > attachment point. This solution does however show severe > scalability issues and should be limited to uses with > substantially fewer than the maximum number of routes that > the IGP > can support (generally about 50,000). > > [...snip...] > > Internet > | > \ > | > +------------------+ > | Simple Gateway | Logical subnet > | or Home Agent |-+-+-+-+-+-+-+-+-- > +------------------+ for topology > | hidden nodes > | > Real internal -------------+- > topology | | > | -+---------- > -----------+--------+ > | > > > > The more I think about this proposal, the more questions arise, > such as: > > (1) Do we really mean that the router in this picture would be a > "simple > gateway or home agent"? I don't think that is consistent with the > idea that > it could handle 50,000 routes. Or that it would run an IGP, for that > matter. > > (2) What mechanism would hosts use to inject host routes into the > IGP? How > is that secured? > > (3) How will local nodes know to use topology-specific ULA > addresses for > local communication? What happens if they don't? Could this > result in a > large amount of internal traffic bouncing off of the "simple > gateway or home > agent"? > > (4) How does this interact with multicast traffic and ND. Can a > node on the > "logical subnet" send a link-local multicast packet on the logical > subnet > and safely assume that it will reach all of the nodes on that > subnet and no > one else? If not, how does this interact with ND? > > (5) Would autoconfiguration be used on the logical subnet, or would > hosts be > expected to get those addresses through other means? > > (6) What advantages (if any) does this approach have over using a > single > subnet internally and using L2 switches and VLANs to handle > internal packet > delivery? What disadvantages does it have when compared to that > approach? > > (7) How does this proposal relate to the work currently underway in > the > TRILL WG? > > If we decide that we actually want to make this recommendation, I'd > prefer > that we remove it from this document and make this recommendation in a > separate document that covers the scalability issues, the answers my > questions above, and any other factors that may affect the > applicability of > this solution. > > Margaret > > >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Wednesday, June 28, 2006 4:00 PM >> To: Margaret Wasserman; Dave Oran; radia.perlman@eng.sun.com >> Cc: 'Tony Hain'; 'Tim Chown'; v6ops@ops.ietf.org >> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt >> >> Radia and Dave: >> >> There is a dispute going on regarding the scalability of >> topology hiding by what amounts to IS-IS level 1 routing >> (identifying hosts in a multi-LAN network by their host >> identifier and using a common subnet ID for the domain). Do >> you know of available documentation of IS-IS level 1 routing >> and its tested scalability? >> >> As Radia knows, this question is also being looked at in IEEE >> 802.1, which presumes that there is only a single >> multi-LAN-LAN, and that MAC addresses are used to route within it. >> >> Fred >> >> On Jun 28, 2006, at 12:40 PM, Margaret Wasserman wrote: >> >>> 50K is an order of magnitude higher than the analysis in >> Alex Zinin's >>> presentation would seem to indicate. His presentation >> indicates that >>> flat >>> routing will only scale to something on the order of 1K nodes. >>> Please feel >>> free to check with Alex, though, as he certainly has more >>> understanding of IGP scaling than I do. >>> [snip] >>> If this document is going to recommend doing flat routing >> for topology >>> hiding, I think that the WG needs to do the analysis to >> determine that >>> this is a valid and scalable technique. >> > > From owner-v6ops@ops.ietf.org Wed Jul 12 10:31:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fkW-0007f7-5i for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 10:31:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fkV-0007xp-Kg for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 10:31:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0fiv-000B29-9y for v6ops-data@psg.com; Wed, 12 Jul 2006 14:29:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0fiu-000B1s-6J for v6ops@ops.ietf.org; Wed, 12 Jul 2006 14:29:56 +0000 Received: from eaglet (127.0.0.1:3872) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 12 Jul 2006 07:29:50 -0700 From: "Tony Hain" To: "'Margaret Wasserman'" Cc: Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 12 Jul 2006 07:29:51 -0700 Message-ID: <037101c6a5bf$a3775080$0202fea9@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaluaTbuIN+cBsZQJeqSt1PBQi3rAAAK0lA In-Reply-To: <5737495F-D373-47A2-8BB6-B10D250E2042@thingmagic.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Margaret Wasserman wrote: > FYI -- > > Here is the message I mentioned in today's meeting. My questions are > near the end. > > Margaret > > --- > > Begin forwarded message: > > > From: "Margaret Wasserman" > > Date: June 28, 2006 5:17:16 PM EDT > > To: > > Cc: "'Tony Hain'" , "'Tim Chown'" > > , "'Radia Perlman'" , > > "'Alex Zinin'" , "'Erik Nordmark'" > > , , "'Dave > > Oran'" , "'Bill Fenner'" , > > "'Jari Arkko'" , > > Subject: RE: Review of draft-ietf-v6ops-nap-02.txt > > > > > > Hi All, > > > > As I understand it, there is a current proposal in the v6ops WG (in > > draft-ietf-v6ops-nap-03-draft0.txt) to publish the following > > recommendation: > > > > There are other possible scenarios for the extreme situation when a > > network manager also wishes to fully conceal the internal IPv6 > > topology. In these cases the goal in replacing the IPv4 NAT > > approach > > is to make all of the topology hidden nodes appear from the outside > > to exist at the edge of the network, just as they would when > > behind a > > NAT. > > > > o One could use explicit host routes and remove the correlation > > between location and IPv6 address. In the figure below the > > hosts > > would be allocated prefixes from one or more logical subnets, > > and > > would inject host routes to internally identify their real > > attachment point. This solution does however show severe > > scalability issues and should be limited to uses with > > substantially fewer than the maximum number of routes that > > the IGP > > can support (generally about 50,000). > > > > [...snip...] > > > > Internet > > | > > \ > > | > > +------------------+ > > | Simple Gateway | Logical subnet > > | or Home Agent |-+-+-+-+-+-+-+-+-- > > +------------------+ for topology > > | hidden nodes > > | > > Real internal -------------+- > > topology | | > > | -+---------- > > -----------+--------+ > > | > > > > > > > > The more I think about this proposal, the more questions arise, > > such as: > > > > (1) Do we really mean that the router in this picture would be a > > "simple > > gateway or home agent"? I don't think that is consistent with the > > idea that > > it could handle 50,000 routes. Or that it would run an IGP, for that > > matter. Clearly if the network has 50,000 devices it is no longer 'simple'. The mechanism works for the simple router case when the number of devices aligns with the context of a 'simple' network. > > > > (2) What mechanism would hosts use to inject host routes into the > > IGP? They participate in the IGP as 'routers' for the set of addresses the host might be using. > > How is that secured? In what ever mechanism the network uses for securing its IGP. If your real question is about 'trust of hosts' vs. routers, the point that needs to be kept in mind here is that in simple networks the policy manager is the same between the hosts and routers. > > > > (3) How will local nodes know to use topology-specific ULA > > addresses for > > local communication? RFC 3484 policy table entry biasing FC00::/7 as preferred over 2000::/3 > > What happens if they don't? Could this > > result in a > > large amount of internal traffic bouncing off of the "simple > > gateway or home > > agent"? Yes, if a node doesn't prefer the addressing that will result in the shortest path, then the traffic will bounce via the topology masking router. > > > > (4) How does this interact with multicast traffic and ND. ND for the topology hidden unicast & general multicast traffic would route via the topology masking router. > > Can anode on the > > "logical subnet" send a link-local multicast packet on the logical > > subnet > > and safely assume that it will reach all of the nodes on that > > subnet and no > > one else? If not, how does this interact with ND? One needs to pay attention to the distinction between 'link' and 'subnet'. If a node is part of a logical subnet and knows it is not directly connected to the link attached to the hosting router (because the flag is set to not-on-link for that prefix), then it should not assume anything about LL reachability of any other member of the subnet. ND will work as defined, so the topology hidden node will use its LL to talk to whatever router is on the link, then use routing to get to anything else. > > > > (5) Would autoconfiguration be used on the logical subnet, or would > > hosts be > > expected to get those addresses through other means? They would have to use other means because they need to also inform that node that it is supposed to use that address rather than whatever might be offered for where it attaches. > > > > (6) What advantages (if any) does this approach have over using a > > single > > subnet internally and using L2 switches and VLANs to handle > > internal packet > > delivery? What disadvantages does it have when compared to that > > approach? That works. We specifically took it out of the initial draft because it was not an IP level mechanism. I put it back after hearing you were concerned about it. The primary disadvantage is that all traffic has to route via the topology hiding router, and the L2 has to have the means to create the vlan. > > > > (7) How does this proposal relate to the work currently underway in > > the > > TRILL WG? It doesn't. TRILL is trying to logically concatenate links. This mechanism is simply using MIPv6 or Host routes to make the host appear at the edge of the network like it would in an IPv4/nat case. > > > > If we decide that we actually want to make this recommendation, It is not a BCP, it is simply information. > > I'd prefer > > that we remove it from this document and make this recommendation in a > > separate document that covers the scalability issues, the answers my > > questions above, and any other factors that may affect the > > applicability of > > this solution. A BCP should be a separate document. The full -03 round of edits covers the scale issue. It is not clear to me that it needs to be a primer on IPv6 to discuss the distinction between link and subnet and how ND works. Tony > > > > Margaret > > > > > >> -----Original Message----- > >> From: Fred Baker [mailto:fred@cisco.com] > >> Sent: Wednesday, June 28, 2006 4:00 PM > >> To: Margaret Wasserman; Dave Oran; radia.perlman@eng.sun.com > >> Cc: 'Tony Hain'; 'Tim Chown'; v6ops@ops.ietf.org > >> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt > >> > >> Radia and Dave: > >> > >> There is a dispute going on regarding the scalability of > >> topology hiding by what amounts to IS-IS level 1 routing > >> (identifying hosts in a multi-LAN network by their host > >> identifier and using a common subnet ID for the domain). Do > >> you know of available documentation of IS-IS level 1 routing > >> and its tested scalability? > >> > >> As Radia knows, this question is also being looked at in IEEE > >> 802.1, which presumes that there is only a single > >> multi-LAN-LAN, and that MAC addresses are used to route within it. > >> > >> Fred > >> > >> On Jun 28, 2006, at 12:40 PM, Margaret Wasserman wrote: > >> > >>> 50K is an order of magnitude higher than the analysis in > >> Alex Zinin's > >>> presentation would seem to indicate. His presentation > >> indicates that > >>> flat > >>> routing will only scale to something on the order of 1K nodes. > >>> Please feel > >>> free to check with Alex, though, as he certainly has more > >>> understanding of IGP scaling than I do. > >>> [snip] > >>> If this document is going to recommend doing flat routing > >> for topology > >>> hiding, I think that the WG needs to do the analysis to > >> determine that > >>> this is a valid and scalable technique. > >> > > > > From owner-v6ops@ops.ietf.org Wed Jul 12 11:25:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0gaG-0005v4-4i for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 11:25:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0gaE-0002PL-Mt for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 11:25:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0gZv-000Gmi-4d for v6ops-data@psg.com; Wed, 12 Jul 2006 15:24:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0gZt-000Gks-Od for v6ops@ops.ietf.org; Wed, 12 Jul 2006 15:24:42 +0000 Received: from [132.219.31.219] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001926989.msg for ; Wed, 12 Jul 2006 17:22:05 +0200 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 12 Jul 2006 11:24:27 -0400 Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt From: JORDI PALET MARTINEZ To: , Message-ID: Thread-Topic: draft-narten-ipv6-3177bis-48boundary-02.txt Thread-Index: Acalx0MhgbP2WBG6EduzlAANky3PwA== In-Reply-To: <200607121330.k6CDURLm018209@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060712:v6ops@ops.ietf.org::XnbBcoFtJKB7TbJH:00000000000000000000000000000000000000000001dMP X-MDRemoteIP: 132.219.31.219 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 12 Jul 2006 17:22:09 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Hi all, I've reviewed this document and my comments are as follows. 1. Introduction "giving out an excessive". I think we need to define excessive and/or say if this is an objective or subjective perception. A general comment/opinion. I don't think this document should be published as is, because it provides a bad message to the market about IPv6 assignment recommendations not being stable. I will be in favor of a "smaller" revision of RFC3177, not so much disruptive as this one, but in the other way around, discouraging /128 and /64 assignments. I think the motivations behind the /48 are still valid and one of the main goals of IPv6 addressing space is to ensure enough space to end-users, which is only ensured with a clear boundary recommendation. Furthermore, the lack of a clear boundary disrupts the RFC3177 goal of ensuring a consistent subnet to facilitate management and renumbering. In practice receiving a new assignment from and ISP w/o a specific recommendation will be a big source of troubles if different ISPs decide to do different things. Take the case of a user moving from an existing ISP with today provides a /48 to a new one. In addition, as an end user, it provides a recommendation to ISPs to provide a reduced service in terms of the number of subnets, instead of the actual /48 recommendations (with a clear example for /56), which I think is very bad, especially when it is based in a subjective view of "excessive". I also think that the lack of clarity in stating that more than a single /64 is required in most of the cases is going to be wrongly taken as a "go for /64". Regards, Jordi > De: Thomas Narten > Responder a: > Fecha: Wed, 12 Jul 2006 09:30:27 -0400 > Para: > Asunto: FWD: draft-narten-ipv6-3177bis-48boundary-02.txt > > ------- Forwarded Message > > From: Thomas Narten > To: v6ops@ops.ietf.org > Date: Wed, 12 Jul 2006 09:26:27 -0400 > Subject: draft-narten-ipv6-3177bis-48boundary-02.txt > > FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just > prior to the ID cutoff, and the authors believe it is ready for > publication as an RFC. We are in discussion with the ADs about having > the document shepherded through the IESG as an informational document. > Note that this document would formally replace RFC3177. > > Comments welcome of course! > > Thomas > > ------- End of Forwarded Message > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Jul 12 11:25:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0gaO-0006ad-6Q for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 11:25:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0gaL-0002PU-Pk for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 11:25:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0gZ0-000GiK-8H for v6ops-data@psg.com; Wed, 12 Jul 2006 15:23:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [193.49.159.8] (helo=mail1.renater.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0gYy-000Ghh-J6 for v6ops@ops.ietf.org; Wed, 12 Jul 2006 15:23:44 +0000 Received: from 55.renater.fr ([193.49.159.55]) by mail1.renater.fr with esmtp (Exim 4.54) id 1G0gYZ-0001c7-H4; Wed, 12 Jul 2006 17:23:20 +0200 Message-ID: <44B4BF82.4080504@renater.fr> Date: Wed, 12 Jul 2006 11:23:14 +0200 From: Jerome Durand User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: arifumi@nttv6.net, hiromi@inetcore.net, fujisaki@syce.net, kanayama@inetcore.net, v6ops@ops.ietf.org Subject: draft-arifumi-v6ops-addr-select-ps / maybe another scenario Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi, It's been a long time I'm thinking about the following scenario: I have IPv6 and IPv4 connectivity where I am roaming (example here at IETF). My home network has IPv6 and IPv4 connectivity as well and services are reachable over these 2 protocols (example my SMTP server). I have an IPv4 IPsec VPN connection to my home network. (only IPv4 as I'm using a commercial software that does not make it possible to have IPv6 VPN...) I want to use a service in my home network (example I want to send an email). What happens today is that IPv6 is preferred and then I have restrictions on service usage because I am out of the network (example SMTP relay is not permitted...) Maybe this is also one of the scenario you want to solve. Note the solution I applied today is to use IPv4 addresses when configuring some service but I'm not sure this is the way to go! Note some other people I know choosed another solution: they removed IPv6 from their laptop. I would be very happy to get a solution :) Please don't answer me: - IPv6 tunneling over the VPN with a TEP in home network - change VPN system Thanks ! Jerome From owner-v6ops@ops.ietf.org Wed Jul 12 11:35:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0gkA-0003Kc-Vt for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 11:35:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0gk9-0002kN-Kh for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 11:35:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0giP-000HkW-4K for v6ops-data@psg.com; Wed, 12 Jul 2006 15:33:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0giN-000HkC-W7 for v6ops@ops.ietf.org; Wed, 12 Jul 2006 15:33:28 +0000 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6CFXETI070631 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 12 Jul 2006 17:33:15 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Iljitsch van Beijnum Subject: filtering packets with unknown options Date: Wed, 12 Jul 2006 11:33:27 -0400 X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f After thinking about this a little more, it occurs to me that the correct behavior in cases where an unknown option is encountered and the security environment is such that this is deemed undesireable, is to drop the OPTION, not the packet. This way, new stuff can be deployed without problems. There is of course the tiny detail of how to implement this. Firewalls do a lot of processing so it's not completely outside the realm of possibility to assume that they could remove extension headers, but routers certainly aren't going to do this. An alternative would be to set the contents of the option to all zero bits, this should be easier to implement than removing the header from the packet. Thoughts? From owner-v6ops@ops.ietf.org Wed Jul 12 13:01:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0i5J-0003gH-Ck for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:01:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0i5I-0006Qu-4c for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:01:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0i32-0000OV-9c for v6ops-data@psg.com; Wed, 12 Jul 2006 16:58:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0i31-0000OF-2Z for v6ops@ops.ietf.org; Wed, 12 Jul 2006 16:58:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6CGwWMV004125; Wed, 12 Jul 2006 19:58:32 +0300 Date: Wed, 12 Jul 2006 19:58:32 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: v6ops@ops.ietf.org Subject: Re: filtering packets with unknown options In-Reply-To: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> Message-ID: References: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1592/Tue Jul 11 23:40:37 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Wed, 12 Jul 2006, Iljitsch van Beijnum wrote: > There is of course the tiny detail of how to implement this. Firewalls do a > lot of processing so it's not completely outside the realm of possibility to > assume that they could remove extension headers, but routers certainly aren't > going to do this. This has been a no-no in IPv6 design. Intermediary devices do not add or remove options. That might even be explicitly stated in RFC 2460. On the other end, FW _could_ send a parameter problem (or whatever) ICMP error about the packet, which could result in the host trying to send without the header (if the host included the logic to respond to failures to communicate with a header, which I'd assume they'd need to have in the future, e.g., with shim6). However, I suspect many FW admins prefer silent discard in this case. I personally have no strong preference. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 12 13:18:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iLy-000611-8o for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:18:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iIG-0006zM-Mc for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:14:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0iHU-0001oQ-ST for v6ops-data@psg.com; Wed, 12 Jul 2006 17:13:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0iHU-0001oB-8x for v6ops@ops.ietf.org; Wed, 12 Jul 2006 17:13:48 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2006 10:13:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k6CHDlRS021069; Wed, 12 Jul 2006 10:13:47 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6CHDkoI025925; Wed, 12 Jul 2006 10:13:46 -0700 (PDT) Received: from evyncke-wxp01.cisco.com (ams3-vpn-dhcp4167.cisco.com [10.61.80.70]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6CH7lTL011443; Wed, 12 Jul 2006 10:07:48 -0700 Message-Id: <5.1.0.14.2.20060712191242.038a6e28@email.cisco.com> X-Sender: evyncke@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Jul 2006 19:13:38 +0200 To: Pekka Savola From: Eric Vyncke Subject: Re: filtering packets with unknown options Cc: Iljitsch van Beijnum , v6ops@ops.ietf.org In-Reply-To: References: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authentication-Results: sj-dkim-4.cisco.com; header.From=evyncke@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1070; t=1152724427; x=1153588427; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evyncke@cisco.com; z=From:Eric=20Vyncke=20 |Subject:Re=3A=20filtering=20packets=20with=20unknown=20options; X=v=3Dcisco.com=3B=20h=3DE3jHNzvAfqlWjdeX2PcpgUWHFwI=3D; b=G2ir1kVrt4ZbR+oszdYpV2KhPNK1iNGimU3R80naeCtsssxUocTbPDbC0Yz507aYOh8eO7rq zFCBPzq9oHSKf+XVXSbB+AO7DRsSYRZfSc1y87wwPS84lap4Q5mazo7O; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 At 19:58 12/07/2006 +0300, Pekka Savola wrote: >On Wed, 12 Jul 2006, Iljitsch van Beijnum wrote: >>There is of course the tiny detail of how to implement this. Firewalls do= a lot of processing so it's not completely outside the realm of possibility= to assume that they could remove extension headers, but routers certainly= aren't going to do this. > >This has been a no-no in IPv6 design. Intermediary devices do not add or= remove options. That might even be explicitly stated in RFC 2460. > >On the other end, FW _could_ send a parameter problem (or whatever) ICMP= error about the packet, which could result in the host trying to send= without the header (if the host included the logic to respond to failures= to communicate with a header, which I'd assume they'd need to have in the= future, e.g., with shim6). > >However, I suspect many FW admins prefer silent discard in this case. I= personally have no strong preference. And those FW admins will be right because this may end up in a reflection= DoS attack ;-) -=E9ric From owner-v6ops@ops.ietf.org Wed Jul 12 13:46:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0inA-0002tc-Bf for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:46:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0in8-0001Se-W9 for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:46:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0ilg-0004ey-Gm for v6ops-data@psg.com; Wed, 12 Jul 2006 17:45:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0ilf-0004eW-Dj for v6ops@ops.ietf.org; Wed, 12 Jul 2006 17:44:59 +0000 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6CHihTo072642 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 12 Jul 2006 19:44:44 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79C9E247-8699-4C0E-B8DA-3B33FF0138A0@muada.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: filtering packets with unknown options Date: Wed, 12 Jul 2006 13:44:55 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 On 12-jul-2006, at 12:58, Pekka Savola wrote: >> There is of course the tiny detail of how to implement this. >> Firewalls do a lot of processing so it's not completely outside >> the realm of possibility to assume that they could remove >> extension headers, but routers certainly aren't going to do this. > This has been a no-no in IPv6 design. Intermediary devices do not > add or remove options. Where is this documented? > That might even be explicitly stated in RFC 2460. No, doesn't look that way. But firewalls break our architecture all the time, firewall admins don't seem to care. Also, it would be possible to make new headers in a way that allows older firewalls to determine how to handle them, so zero out yes/no could be part of the header spec and thus be ok if so indicated. > On the other end, FW _could_ send a parameter problem (or whatever) > ICMP error about the packet, which could result in the host trying > to send without the header This is what RFC 2460 says hosts should do: If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. So it makes sense that if a firewall does this on behalf of the host, it does the same thing. But then it would have to spoof the source address of the original destination host, of course. Note that for the destination options header we already have: The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. 01 - discard the packet. Last but not least, lest I forget: since there is no fixed header layout, it's impossible to determine what follows an unknown header. So you won't be able to filter on TCP/UDP info if there is an unknown header present. > However, I suspect many FW admins prefer silent discard in this > case. I personally have no strong preference. But how can you reasonably expect to ever deploy any new options/ headers when this happens?? But then again historically, firewalls have broken MANY things, such as EDNS0... From owner-v6ops@ops.ietf.org Wed Jul 12 13:50:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iqu-0007qM-NP for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:50:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iqu-00021L-87 for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 13:50:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0iqP-00055J-Jc for v6ops-data@psg.com; Wed, 12 Jul 2006 17:49:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [204.9.221.19] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0iqO-000556-Cs for v6ops@ops.ietf.org; Wed, 12 Jul 2006 17:49:52 +0000 Received: from [132.219.28.212] (account margaret [132.219.28.212] verified) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1104471; Wed, 12 Jul 2006 13:49:51 -0400 In-Reply-To: <037101c6a5bf$a3775080$0202fea9@tndh.net> References: <037101c6a5bf$a3775080$0202fea9@tndh.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 12 Jul 2006 13:49:35 -0400 To: Tony Hain X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Hi Tony, On Jul 12, 2006, at 10:29 AM, Tony Hain wrote: > Clearly if the network has 50,000 devices it is no longer 'simple'. > The > mechanism works for the simple router case when the number of > devices aligns > with the context of a 'simple' network. There still seem to be some conflicting statements in the draft about the applicability of the route injection topology hiding mechanism. Presumably, we are talking about an enterprise-level deployment, because it depends on the use of an IGP, but the diagram says "simple gateway or home gateway". I would rather it said "topology masking router", as you have described it later. >>> >>> (3) How will local nodes know to use topology-specific ULA >>> addresses for >>> local communication? > > RFC 3484 policy table entry biasing FC00::/7 as preferred over > 2000::/3 This response does not answer my question. I understand how this will work iff internal nodes are given a ULA as a possible destination address for local nodes, but I don't understand how the local nodes will be given the ULAs. Do you anticipate the use of split-DNS in this scenario, so that ULAs are supplied internally and not externally? One of the problems with NAT, at least from my perspective, is that they require a split-DNS employment to get local name resolution. Are we expecting that NAP will have that same property? >>> (4) How does this interact with multicast traffic and ND. > > ND for the topology hidden unicast & general multicast traffic > would route > via the topology masking router. It is clear from this and earlier responses that a "topology masking router" is a special beast with some different properties than a regular router, such as logic to forward solicited node multicast packets to the set of potentially matching nodes, the ability to forward subnet-local multicast to all of the nodes on the logical subnet, etc. I think that you should describe these properties when asserting that IGP route injection can be used for topology hiding. >>> Can anode on the >>> "logical subnet" send a link-local multicast packet on the logical >>> subnet >>> and safely assume that it will reach all of the nodes on that >>> subnet and no >>> one else? If not, how does this interact with ND? > > One needs to pay attention to the distinction between 'link' and > 'subnet'. > If a node is part of a logical subnet and knows it is not directly > connected > to the link attached to the hosting router (because the flag is set to > not-on-link for that prefix), then it should not assume anything > about LL > reachability of any other member of the subnet. ND will work as > defined, so > the topology hidden node will use its LL to talk to whatever router > is on > the link, then use routing to get to anything else. This is quite a complicated topic that has been discussed in various places, and I don't think that either of us wants to re-hash all of those discussions here or in this document... It isn't clear to me that this works as cleanly as you seem to think, but that is almost certainly outside the scope of this document. Since you later seem to indicate that these nodes won't receive RA's, though, I'm not sure where we would clear the on-link flag. Maybe via manual configuration when we set-up the addresses and identify the router with which these nodes should register? >>> (5) Would autoconfiguration be used on the logical subnet, or would >>> hosts be >>> expected to get those addresses through other means? > > They would have to use other means because they need to also inform > that > node that it is supposed to use that address rather than whatever > might be > offered for where it attaches. Perhaps you could make it clear that this mechanism relies on manual configuration of IP addresses, the (local topology) address of the router with which to register, and the on-link flag on each of the topology-hidden hosts? Should we be considering a DHCPv6 option to provide a topology hiding prefix? >>> (6) What advantages (if any) does this approach have over using a >>> single >>> subnet internally and using L2 switches and VLANs to handle >>> internal packet >>> delivery? What disadvantages does it have when compared to that >>> approach? > > That works. We specifically took it out of the initial draft > because it was > not an IP level mechanism. I put it back after hearing you were > concerned > about it. The primary disadvantage is that all traffic has to route > via the > topology hiding router, and the L2 has to have the means to create > the vlan. I will have to look at what you've added again, because I think we are having a misunderstanding. I am merely saying that you would use a bridged network (no L3 topology). Your local physical topology would be handled at L2, with the appearance of a completely flat network at L3. >>> If we decide that we actually want to make this recommendation, > > It is not a BCP, it is simply information. Two comments on this: (1) I don't think that readers make a big distinction between BCP and Info. (2) Even in an informational document, I don't think it is reasonable to refer to a solution as though it is a well-understood solution when it is not. If we want to discuss this solution, I think we need to say enough for readers to understand how the solution actually works. It isn't sufficient for users to just insert host routes in current routing equipment if that equipment does not include other features to be a "topology hiding router", right? >>> I'd prefer >>> that we remove it from this document and make this recommendation >>> in a >>> separate document that covers the scalability issues, the answers my >>> questions above, and any other factors that may affect the >>> applicability of >>> this solution. > > A BCP should be a separate document. The full -03 round of edits > covers the > scale issue. It is not clear to me that it needs to be a primer on > IPv6 to > discuss the distinction between link and subnet and how ND works. I don't think we need a primer on IPv6, but I do think we need some description of the topology hiding router and its properties. We also need to decide if we have consensus that such a solution is a good idea, because regardless of the document classification, this document is stating how IPv6 can provide the benefits of IPv6 NAT, and I don't think we should state that IPv6 can be used in a certain way to provide certain benefits unless we think: (1) it will work, (2) any downsides of the approach are mentioned, and (3) the downsides are not worse than the benefits. Margaret From owner-v6ops@ops.ietf.org Wed Jul 12 14:13:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jDa-0002pN-Ty for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 14:13:50 -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 1G0fns-00085n-Lr for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 10:35:04 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0faM-0005PF-UH for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 10:21:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0fYe-0009to-8Z for v6ops-data@psg.com; Wed, 12 Jul 2006 14:19:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0fYc-0009tV-T9 for v6ops@ops.ietf.org; Wed, 12 Jul 2006 14:19:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6CEJ9Ui032399 for ; Wed, 12 Jul 2006 17:19:09 +0300 Date: Wed, 12 Jul 2006 17:19:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Remove tunnel mode from ipsec-tunnels-02? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1592/Tue Jul 11 23:40:37 2006 on otso.netcore.fi X-Virus-Status: Clean version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hello, As proposed at the v6ops meeting [0], the authors of draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel mode in this particular context (securing v6-in-v4 configured tunnels). This is due to issues spotted by Francis [1] and Pasi [2]. Generic "::/0 -> ::/0" selectors could not be made to work without interface-specific SPDs, and those cannot be signalled in IKE (that's run on top of IPv4) when the tunnel would be IPv6 in a standardized way. Generic selectors are required for link-local traffic (e.g., ND) to work on the tunnel. If we go through with this proposed resolution, draft-ietf-v6ops-ipsec-tunnels would only describe transport mode. Comments are welcome. [0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf [1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html [2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html For the authors of draft-ietf-v6ops-ipsec-tunnels-02, -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jul 12 14:34:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jX7-0007Cl-TA for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 14:34:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jIM-0000YE-W0 for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 14:18:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0jGe-0007uc-HD for v6ops-data@psg.com; Wed, 12 Jul 2006 18:17:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0jGd-0007uP-Ts for v6ops@ops.ietf.org; Wed, 12 Jul 2006 18:16:59 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 12 Jul 2006 11:17:00 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="433951403:sNHT25813052" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k6CIGxNF000645; Wed, 12 Jul 2006 11:16:59 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6CIGxZo000309; Wed, 12 Jul 2006 11:16:59 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 11:16:59 -0700 Received: from [132.219.16.127] ([10.21.144.36]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 11:16:58 -0700 In-Reply-To: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> References: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: filtering packets with unknown options Date: Wed, 12 Jul 2006 14:16:58 -0400 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Jul 2006 18:16:58.0911 (UTC) FILETIME=[5D5A0AF0:01C6A5DF] DKIM-Signature: a=rsa-sha1; q=dns; l=512; t=1152728219; x=1153592219; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20filtering=20packets=20with=20unknown=20options; X=v=3Dcisco.com=3B=20h=3DlVR/cclcoVhXo/3JX+jb88X717g=3D; b=lRunG3BbFTT5Ks80yJrAiRS0z+VSCjN/K56LoojZNtVT3vRQ0TMFRVdO4B4xIo5zVAG3M5bd m0TTp0rEx6rZAQNIZ8P9ndp7J+vRyKk7uIW4XyKt0QbA87gBu0SCw9Ad; Authentication-Results: sj-dkim-2.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On Jul 12, 2006, at 11:33 AM, Iljitsch van Beijnum wrote: > There is of course the tiny detail of how to implement this. > Firewalls do a lot of processing so it's not completely outside the > realm of possibility to assume that they could remove extension > headers, but routers certainly aren't going to do this. There are router implementations that implement a variety of firewall. I don't see any reason they couldn't, apart from the DOS implications (which firewalls have as well). From owner-v6ops@ops.ietf.org Wed Jul 12 15:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0k3U-0002SP-Kx for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 15:07:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0k3S-0001xZ-2i for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 15:07:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0k1G-0003MO-7s for v6ops-data@psg.com; Wed, 12 Jul 2006 19:05:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [199.212.90.4] (helo=monster.hopcount.ca) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0k1D-0003Ls-KL for v6ops@ops.ietf.org; Wed, 12 Jul 2006 19:05:07 +0000 Received: from [132.219.21.195] by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G0k1B-0000vb-Bo; Wed, 12 Jul 2006 19:05:05 +0000 In-Reply-To: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> References: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56ED34EB-5668-4351-A99F-2D8E49F3C51D@ca.afilias.info> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: filtering packets with unknown options Date: Wed, 12 Jul 2006 15:05:03 -0400 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On 12-Jul-2006, at 11:33, Iljitsch van Beijnum wrote: > An alternative would be to set the contents of the option to all > zero bits, this should be easier to implement than removing the > header from the packet. For clarity, I presume you mean set the option type in each TLV the firewall is unhappy about (in all options extension headers that might be present) to zero ("skip this option"). It all still smells a bit nasty, though. Joe From owner-v6ops@ops.ietf.org Wed Jul 12 15:51:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kkQ-0008MQ-M8 for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 15:51:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kkP-0007px-9P for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 15:51:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0kiz-0007Ci-I6 for v6ops-data@psg.com; Wed, 12 Jul 2006 19:50:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0kiy-0007CR-RS for v6ops@ops.ietf.org; Wed, 12 Jul 2006 19:50:21 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6CJo21u016986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G0kig-0000vw-FL; Wed, 12 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-recs-02.txt Message-Id: Date: Wed, 12 Jul 2006 15:50:02 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Recommendations for Filtering ICMPv6 Messages in Firewalls Author(s) : E. Davies, J. Mohacsi Filename : draft-ietf-v6ops-icmpv6-filtering-recs-02.txt Pages : 36 Date : 2006-7-12 In networks supporting IPv6 the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6 but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-icmpv6-filtering-recs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-12132558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-icmpv6-filtering-recs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-12132558.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jul 12 17:18:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0m6X-0001ep-GF for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 17:18:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0m6V-0004uH-54 for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 17:18:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0m42-000EUM-RE for v6ops-data@psg.com; Wed, 12 Jul 2006 21:16:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [203.59.1.128] (helo=customer-domains.icp-qv1-irony7.iinet.net.au) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0m41-000EU3-2U for v6ops@ops.ietf.org; Wed, 12 Jul 2006 21:16:09 +0000 Received: from 203-173-22-103.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.22.103]) by customer-domains.icp-qv1-irony7.iinet.net.au with ESMTP; 13 Jul 2006 05:16:06 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,236,1149436800"; d="scan'208"; a="343873494:sNHT17509988" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 34AD53FB4; Thu, 13 Jul 2006 06:46:03 +0930 (CST) Date: Thu, 13 Jul 2006 06:46:02 +0930 From: Mark Smith To: jordi.palet@consulintel.es Cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Message-Id: <20060713064602.bb90badc.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <200607121330.k6CDURLm018209@cichlid.raleigh.ibm.com> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi, Following on from Jordi's comment, > In addition, as an end user, it provides a recommendation to ISPs to provide > a reduced service in terms of the number of subnets, instead of the actual > /48 recommendations (with a clear example for /56), which I think is very > bad, especially when it is based in a subjective view of "excessive". although I haven't had a chance yet to read the new draft quite yet, I think pointing out the following paper might be worth useful as it discusses the motivations behind a similar addressing decision from the past (from when I was a young lad of 10!) : http://portal.acm.org/citation.cfm?id=802680&coll=portal&dl=ACM&CFID=76839379&CF "48-bit Absolute Internet and Ethernet Host Numbers", Yogen K. Dalal and Robert S. Printis, 1981. It seems to me that the fundamental decision here is the choice or balance between conservation and convenience. With a scarce resource, you need to make conservation a priority, which of course is what (now) happens with IPv4. With an abundant resource, such as Ethernet addresses, or IPv6 addresses (and IPv4 addresses for most of the classful days), you can make (operational/deployment etc.) convenience a priority, with the cost of that convenience a higher level of consumption of the resource. This additional consumption isn't "waste", because it provides a direct and useful benefit. However, if you apply a scarce resource usage mentality (which is the IPv4 one these days), it would appear to be, because "convenience" is basically a luxury, not a necessity. Obviously, in both the scarce or abundant cases you need to make sure actual waste doesn't occur. While I do agree that a /48 per site does seem excessive, particularly for a home user, and would therefore accept the /56 per site argument, I think it is very important that the balance isn't isn't tipped too far back towards conservation when it isn't necessary. I think one of the fundamental goals of IPv6 is convenience of use and administration, and I also think it is one of the fundamental benefits over IPv4. If we have opportunities to make anything in IPv6 convenient, such as renumbering without changing subnet numbers, at the the cost of some of the abundant IPv6 address space, I think it is a worthwhile cost. Regards, Mark. (Another curious (amusing ?) example of "waste" we're quite happy to accept for the convenience or cost benefit is the 12 byte per packet overhead for addressing on 10GigE point-to-point links, where addressing isn't actually necessary at all.) From owner-v6ops@ops.ietf.org Wed Jul 12 19:04:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0nkv-0004wQ-11 for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 19:04:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0nks-0003CG-Mq for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 19:04:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0nk7-000MhR-94 for v6ops-data@psg.com; Wed, 12 Jul 2006 23:03:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0nk6-000MhF-N9 for v6ops@ops.ietf.org; Wed, 12 Jul 2006 23:03:42 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 12 Jul 2006 16:03:42 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="328664083:sNHT24309360" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6CN3gOD029825; Wed, 12 Jul 2006 16:03:42 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6CN3gJi007269; Wed, 12 Jul 2006 16:03:42 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 16:03:41 -0700 Received: from [132.219.16.127] ([10.82.225.28]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 16:03:41 -0700 In-Reply-To: <44B55000.60102@googlemail.com> References: <44B4FFD3.7000201@googlemail.com> <44B55000.60102@googlemail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <35C9412D-00DE-4FC1-8AC9-72796937FAB1@cisco.com> Cc: David Kessens , Lindqvist Erik Kurt Content-Transfer-Encoding: 7bit From: Fred Baker Subject: WGLC: draft-ietf-v6ops-icmpv6-filtering-recs-02 Date: Wed, 12 Jul 2006 19:03:39 -0400 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Jul 2006 23:03:41.0561 (UTC) FILETIME=[6AEE1E90:01C6A607] DKIM-Signature: a=rsa-sha1; q=dns; l=583; t=1152745422; x=1153609422; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:WGLC=3A=20draft-ietf-v6ops-icmpv6-filtering-recs-02; X=v=3Dcisco.com=3B=20h=3DqIPJUDJ/Ph7rm9eWwkITvIDFhaY=3D; b=jTqXnsaufc7V2yf8NPqwvx0aIJNm4UjAP/7fINwCHkf1ANXzmB8hP5Qte6Ljf9mtzywkIypN 1tr0odPaB7U69EYFZ0VJfAdBjNkHqw5/c/jIdWU0NaTppmj2hYFul9gc; Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 We are now in a position to open WGLC on the ICMP Filtering Recommendations. The document passed WGLC some time back and there were initial comments from the IESG that led to an early update. The changes comprised a fair amount of text, so we agreed today to run a short WGLC on the result. Please read the document and comment to the list. This WGLC will close a week from Friday, on 21 July. If there are substantive comments, we will ask the authors to update it again. If not, we will simply advise the AD to continue his review of the updated document. From owner-v6ops@ops.ietf.org Wed Jul 12 19:45:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0oOL-0003GS-LE for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 19:45:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0oOJ-0000nm-CF for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 19:45:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0oMd-000PhI-8B for v6ops-data@psg.com; Wed, 12 Jul 2006 23:43:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0oMb-000Ph6-8e for v6ops@ops.ietf.org; Wed, 12 Jul 2006 23:43:29 +0000 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6CNhEig079244 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jul 2006 01:43:15 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <56ED34EB-5668-4351-A99F-2D8E49F3C51D@ca.afilias.info> References: <909BFECF-2CDA-4092-B065-2CFBD12AA537@muada.com> <56ED34EB-5668-4351-A99F-2D8E49F3C51D@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: filtering packets with unknown options Date: Wed, 12 Jul 2006 19:43:27 -0400 To: Joe Abley X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On 12-jul-2006, at 15:05, Joe Abley wrote: >> An alternative would be to set the contents of the option to all >> zero bits, this should be easier to implement than removing the >> header from the packet. > For clarity, I presume you mean set the option type in each TLV the > firewall is unhappy about (in all options extension headers that > might be present) to zero ("skip this option"). Right, although "TLV" isn't exactly a given. > It all still smells a bit nasty, though. It is not a very pretty solution, but the alternative is that it will be extremely hard to the point of almost being impossible to deploy new "stuff" on the internet. Point in case is the "partial ECN" or something very similar that I can't find any reference to right now. The idea is to steal the last unused bit in the IPv4 header to extend the ECN semantics (the "evil" bit...) but IPv6 doesn't have this bit so that means an extra header, either a new one or a new option in the destination options header, I forget which. With firewalls filtering this out, this means a many-year uphill battle before this can be deployed. From owner-v6ops@ops.ietf.org Wed Jul 12 20:48:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0pNs-00063U-IV for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 20:48:52 -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 1G0nlq-0003N3-TZ for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 19:05:30 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0ndw-0008O8-L2 for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 18:57:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0nbi-000Lu3-S7 for v6ops-data@psg.com; Wed, 12 Jul 2006 22:55:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0nbh-000Lsz-5R for v6ops@ops.ietf.org; Wed, 12 Jul 2006 22:55:01 +0000 Received: from [132.219.20.240] (unknown [132.219.20.240]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id 3B55B78C09; Thu, 13 Jul 2006 00:54:52 +0200 (CEST) In-Reply-To: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Thu, 13 Jul 2006 00:54:35 +0200 To: Thomas Narten X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On 12 jul 2006, at 15.26, Thomas Narten wrote: > FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just > prior to the ID cutoff, and the authors believe it is ready for > publication as an RFC. We are in discussion with the ADs about having > the document shepherded through the IESG as an informational document. > Note that this document would formally replace RFC3177. > > Comments welcome of course! I think this should head to the IESG. Upon re-reading it I found one small issue though. > 3. Other RFC 3177 considerations > > RFC3177 suggested that some multihoming approaches (e.g., GSE) > might > benefit from having a fixed /48 boundary. This no longer appears to > be a consideration. There is no such requirement coming out of the > IETF multi6 or shim6 efforts. I think we can take the last sentence out. Mostly as we are seeing several parallel solutions being pursued and deployed, such as shim6, PI space and more specific PAs. I don't believe this should go into the document, but I will also offer the observation that in some of the RIR regions the end-site allocation size have impacts on the LIRs relationship to the RIR - and this 'rule' has the potential for creating artificial complexity in that area. - kurtis - From owner-v6ops@ops.ietf.org Wed Jul 12 21:35:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0q74-0000En-TD for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 21:35:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0q1U-0002BO-PH for v6ops-archive@lists.ietf.org; Wed, 12 Jul 2006 21:29:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0pzI-00079L-Pg for v6ops-data@psg.com; Thu, 13 Jul 2006 01:27:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0pzH-00078z-1q for v6ops@ops.ietf.org; Thu, 13 Jul 2006 01:27:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6D1RSv9016200; Thu, 13 Jul 2006 04:27:28 +0300 Date: Thu, 13 Jul 2006 04:27:28 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-Reply-To: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> Message-ID: References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1594/Wed Jul 12 18:04:34 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Wed, 12 Jul 2006, Thomas Narten wrote: > FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just > prior to the ID cutoff, and the authors believe it is ready for > publication as an RFC. We are in discussion with the ADs about having > the document shepherded through the IESG as an informational document. > Note that this document would formally replace RFC3177. There have already been a lot of comments I agree with, so I'll just mention one higher-level issue that hasn't been mentioned yet (AFAICS): This document obsoletes 3177, but does not mention those aspects of 3177 which are not addressed by this document. Silently leaving them out is bound to raise questions later on, so this document should make an explicit statement one way or the other. Specifically, at least the discussion on /128 is missing. Btw, the document title should probably say assignment instead of allocation. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 13 06:15:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0yED-0005BC-66 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 06:15:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0yE7-00031p-TI for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 06:15:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0yBZ-000Hwl-BY for v6ops-data@psg.com; Thu, 13 Jul 2006 10:12:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0yBT-000HwL-5w for v6ops@ops.ietf.org; Thu, 13 Jul 2006 10:12:39 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id C199234044 for ; Thu, 13 Jul 2006 06:12:39 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 06:12:37 -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 Subject: WG Document Question on draft-chown-v6ops-campus-transition-03 Date: Thu, 13 Jul 2006 06:12:36 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC2EEA44@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Document Question on draft-chown-v6ops-campus-transition-03 Thread-Index: AcamHAAokdf8RlDwQNeqtNSKev5csgASDZSQ From: "Bound, Jim" To: X-OriginalArrivalTime: 13 Jul 2006 10:12:37.0769 (UTC) FILETIME=[DDF96F90:01C6A664] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Folks, I believe today in trying to be silent in IETF WG meetings unless it is truly urgent technical issue I have as individual with a spec. I am sending this mail as I believe Tim Chown work on Campus transition should be a working group document. I think it is good operational example and brings out discussion of VLANs too which is important and many other operational requirements other forms of deployment will face. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chown-v6ops-camp us-transition-03.txt Thanks /jim From owner-v6ops@ops.ietf.org Thu Jul 13 09:36:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Mi-0001Hw-7A for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 09:36:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11Mg-0004FS-Pi for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 09:36:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11MS-0009Eb-Eo for v6ops-data@psg.com; Thu, 13 Jul 2006 13:36:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11MQ-0009EL-QW for v6ops@ops.ietf.org; Thu, 13 Jul 2006 13:36:10 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 06:36:10 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDaA7V018460; Thu, 13 Jul 2006 06:36:10 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DDa9Jk012098; Thu, 13 Jul 2006 06:36:10 -0700 (PDT) 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, 13 Jul 2006 09:36:09 -0400 Received: from 10.86.240.28 ([10.86.240.28]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Jul 2006 13:36:09 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 13 Jul 2006 09:36:11 -0400 Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt From: Ralph Droms To: Thomas Narten , CC: , Message-ID: Thread-Topic: draft-narten-ipv6-3177bis-48boundary-02.txt Thread-Index: AcamgU2gjC6LqBJ0EduRqAARJOT6eg== In-Reply-To: <200607131330.k6DDUJRM006668@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Jul 2006 13:36:09.0350 (UTC) FILETIME=[4CA4D260:01C6A681] DKIM-Signature: a=rsa-sha1; q=dns; l=1421; t=1152797770; x=1153661770; c=relaxed/simple; s=sjdkim2002; 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=20draft-narten-ipv6-3177bis-48boundary-02.txt=20; X=v=3Dcisco.com=3B=20h=3D0Z6GuA+VOLQ6q92P5KgGf3ix8kM=3D; b=a7fuE5Gna+1sn7V0kfIKIgNcSWbozCx0lwfWrXrpJcc49IAsIKU0OVXXEykFs3MvcCMHP0SC XqYF+Kj1JNDa/vXfGP1DLVks2cky61d2AiEq24+pBdzeptNJtq0qKIMA; Authentication-Results: sj-dkim-2.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( 70 extraneous bytes; sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Thomas - is there any way in which you can quantify "excessive"? E.g., make some suppositions for an ISP: * number of subscribers * subscribers per aggregation point (CMTS for cable) * length of prefix required for each aggregation point * length of prefix to be assigned to an ISP based on the above - Ralph On 7/13/06 9:30 AM, "Thomas Narten" wrote: > Hi Jordi. > >> Hi all, > >> I've reviewed this document and my comments are as follows. > >> 1. Introduction >> "giving out an excessive". I think we need to define excessive >> and/or say if this is an objective or subjective perception. > > I have two repsonses to this. > > First. giving out a /48 to every home network (which today has at most > a handful of machines, which means, one subnet would suffice) is > widely viewed as excessive. Even a /56 to such end sites seems more > than enough space to meet needs for at least the next decade (and most > people seem to be comfortable with that, even if it is a lot of > space). You've been to RIR meetings. Surely you have noticed this > sentiment both in the hallway and in comments made (regularly) at the > microphone. > [...] > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Thu Jul 13 10:01:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11kn-0005no-5T for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:01:21 -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 1G11kn-0005If-49 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:01:21 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G11iq-0007t0-0u for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 09:59:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11iR-000Btb-6o for v6ops-data@psg.com; Thu, 13 Jul 2006 13:58:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.182.144] (helo=e4.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11iQ-000BtF-9T for v6ops@ops.ietf.org; Thu, 13 Jul 2006 13:58:54 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDwrqJ001698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 09:58:53 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6DDwr9j288594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jul 2006 09:58:53 -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 k6DDwqDH018877 for ; Thu, 13 Jul 2006 09:58:52 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-223-212.mts.ibm.com [9.65.223.212]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDwqaT018853; Thu, 13 Jul 2006 09:58:52 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k6DDwFq2007107; Thu, 13 Jul 2006 09:58:15 -0400 Message-Id: <200607131358.k6DDwFq2007107@cichlid.raleigh.ibm.com> To: Ralph Droms cc: jordi.palet@consulintel.es, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-reply-to: References: Comments: In-reply-to Ralph Droms message dated "Thu, 13 Jul 2006 09:36:11 -0400." Date: Thu, 13 Jul 2006 09:58:15 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Ralph, > Thomas - is there any way in which you can quantify "excessive"? Whether "excessive" is an appropriate word to use is a judgement call. YMMV. But, the word "excessive" is literally the word I hear many people (especially in the RIR and operational community) use when talking about this issue. And I'll note, that even when the IETF went forward with 3177 originally, I think we'd have to say consensus was "rough". Thus, even within the IETF, some people thought /48 was excessive. > E.g., make some suppositions for an ISP: > * number of subscribers > * subscribers per aggregation point (CMTS for cable) > * length of prefix required for each aggregation point > * length of prefix to be assigned to an ISP based on the above What 3177bis is talking about is the size of the assignment to a single end site, e.g., a home, a business, etc. The above are more about issues internal to an ISP (or a very very large end site), and thus the above really relate more to the size of the RIR->LIR (ISP) allocation. I.e., a different issue. Thomas From owner-v6ops@ops.ietf.org Thu Jul 13 10:17:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G120J-0007ob-Km for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:17:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G120H-0005sx-AT for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:17:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11zb-000Due-2r for v6ops-data@psg.com; Thu, 13 Jul 2006 14:16:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11zW-000Du9-PQ for v6ops@ops.ietf.org; Thu, 13 Jul 2006 14:16:35 +0000 Received: from [132.219.20.240] (unknown [132.219.20.240]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id 3844278C38; Thu, 13 Jul 2006 16:16:32 +0200 (CEST) In-Reply-To: <200607131337.k6DDarYc006855@cichlid.raleigh.ibm.com> References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> <200607131337.k6DDarYc006855@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Thu, 13 Jul 2006 16:16:24 +0200 To: Thomas Narten X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On 13 jul 2006, at 15.36, Thomas Narten wrote: > Kurt, > >>> 3. Other RFC 3177 considerations >>> >>> RFC3177 suggested that some multihoming approaches (e.g., GSE) >>> might >>> benefit from having a fixed /48 boundary. This no longer >>> appears to >>> be a consideration. There is no such requirement coming out of >>> the >>> IETF multi6 or shim6 efforts. > >> I think we can take the last sentence out. Mostly as we are seeing >> several parallel solutions being pursued and deployed, such as shim6, >> PI space and more specific PAs. > > So here is the dilemma. I put in this sentence because 3177 argues > that /48 might be useful in the context of multihoming/GSE. A while > back, I asked multi6 whether this was the case and got a "no" back in > response. Pekka (in another thread) complains that this document > doesn't address all the points that 3177 did. So, if I take the above > out, then what can I (usefully) say about the above point? Well, first of all there will never be a solution out of multi6 (And the WG is to be closed :-) ), so that is an error. But I am more worried about only addressing this particular solution while there are clearly others being deployed. Note that I am not arguing about the first two sentences quoted above i.e "RFC3177 suggested that some multihoming approaches (e.g., GSE) might benefit from having a fixed /48 boundary. This no longer appears to be a consideration.". I think that should address moving 3177 to historic - no? Maybe you could add "There are several solutions either being worked on or deployed for multihoming today, neither of which would benefit from a fixed /48 boundary". >> I don't believe this should go into the document, > > Why not? Is it incorrect, or just unnecessary? See above. I think it exclusive and should be rewritten. >> but I will also >> offer the observation that in some of the RIR regions the end-site >> allocation size have impacts on the LIRs relationship to the RIR - >> and this 'rule' has the potential for creating artificial complexity >> in that area. > > what do you mean by "this rule"? That there is no longer a fixed /48 > can be used? If so, I agree, but the RIRs are already heading in that > direction and I view it ias inevitable because we will eventually see > end sites that need more than a /48, in which case we have to figure > out how to count/measure/justify them. By 'rule' I meant /48 for end-sites so I think we agree. - kurtis - From owner-v6ops@ops.ietf.org Thu Jul 13 10:20:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G123J-0000eK-Iq for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:20:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G123I-00061p-9f for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:20:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1239-000EJS-NL for v6ops-data@psg.com; Thu, 13 Jul 2006 14:20:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.182.141] (helo=e1.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1238-000EJF-Un for v6ops@ops.ietf.org; Thu, 13 Jul 2006 14:20:19 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DEKHZs014915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 10:20:17 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6DEKHAd102384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jul 2006 10:20:17 -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 k6DEKE24010107 for ; Thu, 13 Jul 2006 10:20:16 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-223-212.mts.ibm.com [9.65.223.212]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DEK9wu009940; Thu, 13 Jul 2006 10:20:10 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k6DEJWWo007717; Thu, 13 Jul 2006 10:19:33 -0400 Message-Id: <200607131419.k6DEJWWo007717@cichlid.raleigh.ibm.com> To: Kurt Erik Lindqvist cc: v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-reply-to: References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> <200607131337.k6DDarYc006855@cichlid.raleigh.ibm.com> Comments: In-reply-to Kurt Erik Lindqvist message dated "Thu, 13 Jul 2006 16:16:24 +0200." Date: Thu, 13 Jul 2006 10:19:32 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > Well, first of all there will never be a solution out of multi6 (And > the WG is to be closed :-) ), so that is an error. But I am more > worried about only addressing this particular solution while there > are clearly others being deployed. Note that I am not arguing about > the first two sentences quoted above i.e "RFC3177 suggested that some > multihoming approaches (e.g., GSE) might benefit from having a > fixed /48 boundary. This no longer appears to be a consideration.". I > think that should address moving 3177 to historic - no? OK, I get it now. I'm happy to remove the last sentence then. > By 'rule' I meant /48 for end-sites so I think we agree. Ah, nothing like having a 'violent agreement'. :-) Thomas From owner-v6ops@ops.ietf.org Thu Jul 13 10:30:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12DK-0003OJ-T4 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:30:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12DJ-0006Yy-DK for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:30:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G12Cr-000FjR-El for v6ops-data@psg.com; Thu, 13 Jul 2006 14:30:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G12Cp-000Fiz-AD for v6ops@ops.ietf.org; Thu, 13 Jul 2006 14:30:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6DEUHee004326; Thu, 13 Jul 2006 17:30:17 +0300 Date: Thu, 13 Jul 2006 17:30:16 +0300 (EEST) From: Pekka Savola To: Thomas Narten cc: v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-Reply-To: <200607131348.k6DDmpDR006993@cichlid.raleigh.ibm.com> Message-ID: References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> <200607131348.k6DDmpDR006993@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1594/Wed Jul 12 18:04:34 2006 on otso.netcore.fi X-Virus-Status: Clean autolearn=ham version=3.1.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Thu, 13 Jul 2006, Thomas Narten wrote: > Can you please be specific about what points you think need to be > carried over into 3177bis? It is not clear to me why the arguments for a fixed boundary have been removed. I accept that there is no IETF architectural issue whether the size is /48, /56 or whatever, but there would still be benefits for at least having a uniform guideline within a RIR. Clearly some of those tradeoffs (e.g., no need to evaluate the need by the customer) are still valid. Are you arguing that as the specific prefix length (within constraints) is not an IETF issue, we should also be quiet about the tradeoffs, in particular the reasons why the previous recommendation was the way it was? Other than that, the current document mentions a number of times "subject to IPv6 architectural and operational considerations". This is a new formulation, and it is not obvious to me what the architectural (or operational) considerations are. There is some text regarding IPv6 standards but it is not clear whether these are the architectural considerations referred to here, and whether the current list of standards is exclusive. Does the document mean (without saying it explicitly) that assigning /128's to the users is NOT in the purview of the RIRs because the IETF IPv6 architecture defines the subnet boundary at /64? Does it imply something else in addition/instead? > Note that both references are in the specific "recommendation" part > Yet, making a specific recommendation is exactly what this document is > not doing. Can you say something about what you think would be > appropriate to say about /128? Per above. For example, one could explicitly state what the IETF architectural considerations mean in this context. E.g., this document does not give a warrant to assign addresses beyond /64, like as /128s. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Jul 13 10:46:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12SQ-0005eF-Jy for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:46:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12SL-0007LY-AW for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:46:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G12R9-000HpJ-N2 for v6ops-data@psg.com; Thu, 13 Jul 2006 14:45:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G12R8-000Ho9-QE for v6ops@ops.ietf.org; Thu, 13 Jul 2006 14:45:06 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 6C5B434630; Thu, 13 Jul 2006 10:45:06 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 10:45:05 -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 Subject: RE: WG Document Question on draft-chown-v6ops-campus-transition-03 Date: Thu, 13 Jul 2006 10:45:04 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC2EEC25@tayexc14.americas.cpqcorp.net> In-Reply-To: <3214A238-4625-48DA-8D16-02A24814E314@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Document Question on draft-chown-v6ops-campus-transition-03 Thread-Index: AcamcnhNMdHemVucS7u3aAdgWs2q8gAGGtyg From: "Bound, Jim" To: "Fred Baker" Cc: X-OriginalArrivalTime: 13 Jul 2006 14:45:05.0508 (UTC) FILETIME=[EDFC7240:01C6A68A] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb That works yes sorry I did not glean that one. /jim=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Thursday, July 13, 2006 7:50 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: WG Document Question on=20 > draft-chown-v6ops-campus-transition-03 >=20 > I believe that the outcome of yesterday's meeting was that he=20 > would divide it into two documents, one stable and one=20 > ongoing, the stable one would be a working group document,=20 > and would be published as informational by the WG following=20 > appropriate discussion. >=20 > On Jul 13, 2006, at 6:12 AM, Bound, Jim wrote: >=20 > > Folks, > > > > I believe today in trying to be silent in IETF WG meetings=20 > unless it=20 > > is truly urgent technical issue I have as individual with a=20 > spec. I=20 > > am sending this mail as I believe Tim Chown work on Campus=20 > transition=20 > > should be a working group document. I think it is good operational=20 > > example and brings out discussion of VLANs too which is=20 > important and=20 > > many other operational requirements other forms of deployment will=20 > > face. > > > > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chown-v6ops- > > camp > > us-transition-03.txt > > > > Thanks > > /jim >=20 From owner-v6ops@ops.ietf.org Thu Jul 13 11:15:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12uv-0007Ff-13 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 11:15:53 -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 1G11kz-0005If-Lp for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:01:33 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G11Jx-0007Ow-Pt for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 09:33:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11HQ-0008nC-KA for v6ops-data@psg.com; Thu, 13 Jul 2006 13:31:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.110.153] (helo=e35.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11HP-0008my-Hs for v6ops@ops.ietf.org; Thu, 13 Jul 2006 13:30:59 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDUvcL018948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 09:30:57 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6DDUvXj206338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jul 2006 07:30:57 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6DDUuGT025801 for ; Thu, 13 Jul 2006 07:30:57 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-223-212.mts.ibm.com [9.65.223.212]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDUuDY025747; Thu, 13 Jul 2006 07:30:56 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k6DDUJRM006668; Thu, 13 Jul 2006 09:30:20 -0400 Message-Id: <200607131330.k6DDUJRM006668@cichlid.raleigh.ibm.com> To: jordi.palet@consulintel.es cc: ipv6@ietf.org, v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-reply-to: References: Comments: In-reply-to JORDI PALET MARTINEZ message dated "Wed, 12 Jul 2006 11:24:27 -0400." Date: Thu, 13 Jul 2006 09:30:19 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi Jordi. > Hi all, > I've reviewed this document and my comments are as follows. > 1. Introduction > "giving out an excessive". I think we need to define excessive > and/or say if this is an objective or subjective perception. I have two repsonses to this. First. giving out a /48 to every home network (which today has at most a handful of machines, which means, one subnet would suffice) is widely viewed as excessive. Even a /56 to such end sites seems more than enough space to meet needs for at least the next decade (and most people seem to be comfortable with that, even if it is a lot of space). You've been to RIR meetings. Surely you have noticed this sentiment both in the hallway and in comments made (regularly) at the microphone. But more to the point, the current text in the document actually says: There are a number of considerations that factor into address assignment policies. For example, to provide for the long-term health and scalability of the public routing infrastructure, it is important that addresses aggregate well. Likewise, giving out an excessive amount of address space could result in premature depletion. How can you possibly object to the use of the word excessive in the above context? > A general comment/opinion. I don't think this document should be > published as is, because it provides a bad message to the market > about IPv6 assignment recommendations not being stable. I will be in > favor of a "smaller" revision of RFC3177, not so much disruptive as > this one, but in the other way around, discouraging /128 and /64 > assignments. As you know, policy proposals to move away from /48 are currently being discussed in the indvidual RIR regions. Indeed, ARIN has already adopted one (http://www.arin.net/policy/proposals/2005_8.html). Publishing this document will not stop the registries from moving away from /48. Indeed, a primary goal is to make it clear that making such a decision is for the RIRs to make (i.e., to acknowledge reality), and that from an IPv6 architectural perspective, this is fine. So, to be clear, do you disagree with the statement that moving from /48 to /56 is fine from an architectural perspective? If not, please be specific. I do agree there are operational issues with having varying prefix sizes. But that is something that the RIRs need to take into consideration as they discuss policy proposals. Indeed, this document tries to make clear that taking into consideration such operational considerations should be done. > I think the motivations behind the /48 are still valid and one of > the main goals of IPv6 addressing space is to ensure enough space to > end-users, which is only ensured with a clear boundary > recommendation. It is widely viewed that a /56 to everyone would achieve this adequately, whereas a /48 is "execessive" to achieve this goal. > Furthermore, the lack of a clear boundary disrupts the RFC3177 goal of > ensuring a consistent subnet to facilitate management and renumbering. In > practice receiving a new assignment from and ISP w/o a specific > recommendation will be a big source of troubles if different ISPs decide to > do different things. Take the case of a user moving from an existing ISP > with today provides a /48 to a new one. The document says this. But in any case, this argument needs to be taken directly to the RIRs. > In addition, as an end user, it provides a recommendation to ISPs to > provide a reduced service in terms of the number of subnets, instead > of the actual /48 recommendations (with a clear example for /56), > which I think is very bad, especially when it is based in a > subjective view of "excessive". > I also think that the lack of clarity in stating that more than a > single /64 is required in most of the cases is going to be wrongly > taken as a "go for /64". I see no evidence that RIR policies are going in that direction. My sense (this is based on following and participating in RIR discussions for the last few years) is that those communities understand very well that a /64 as default end site allocation unit is neither desirable nor necessary and that there is plenty of address space to make the default allocations much larger. But they (even from day one) have largely viewed a /48 as excessively large. Thomas From owner-v6ops@ops.ietf.org Thu Jul 13 11:36:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13EV-0002o7-2R for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 11:36:07 -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 1G139H-0001x8-HU for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 11:30:43 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G137X-0000zs-63 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 11:28:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G136r-000Mjm-KE for v6ops-data@psg.com; Thu, 13 Jul 2006 15:28:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [152.78.68.129] (helo=owl.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G136q-000MjL-9R for v6ops@ops.ietf.org; Thu, 13 Jul 2006 15:28:12 +0000 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6DFS7hZ010601 for ; Thu, 13 Jul 2006 16:28:07 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6DFS2Au032406 for ; Thu, 13 Jul 2006 16:28:02 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k6DFRxsl019960 for v6ops@ops.ietf.org; Thu, 13 Jul 2006 16:27:59 +0100 Date: Thu, 13 Jul 2006 16:27:59 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Message-ID: <20060713152758.GS15775@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> <200607131348.k6DDmpDR006993@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 On Thu, Jul 13, 2006 at 05:30:16PM +0300, Pekka Savola wrote: > > Per above. For example, one could explicitly state what the IETF > architectural considerations mean in this context. E.g., this > document does not give a warrant to assign addresses beyond /64, like > as /128s. From the home user point of view, as a customer, I would like: 1) At least a /60, given what I have today. 2) A fixed fee (no more 'ah a fixed IP is $10 more sir') 3) A static allocation 4) Moving to a different provider I will get the same size allocation 5) To use ULAs if/when their buglets are ironed out 6) To (when CPEs allow it) source and use IPv6 multicast services Not having a fixed /48's may lead to differential charging (#2) for different offerings and potentially variation between providers(#4), thus agreement on something is important. A /56 is ample for actual subnet use today. I note that at least one tunnel broker product does not support /56 size allocations cleanly. That would need to change. Users migrating from 6to4 would have a smaller size allocation, so should form internal address plans with that in mind for when they 'go native' (if they want to keep the same topology and subnetting). I think 3177 could mention static allocatiobns ( I don't see it in there). This impacts address space consumption by the ISP, but I think is worth including. Regarding ULAs, I guess there would be some 'feature' of the CPE that generates a /48 ULA under fd00::/8. If we recommend a /56, what should that CPE do? Just use address space out of a 40-bit random allocation with the other 8 bits zero? ULAs were designed with an 'everyone uses /48' view in mind. On multicast, I can still generate unicast prefix based group addresses and even an embedded-RP address, as I can do for any /64, so that's OK. -- Tim/::1 From sarkasimeckova@flamenconetwork.com Thu Jul 13 11:59:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13bX-0005qn-SF for v6ops-archive@megatron.ietf.org; Thu, 13 Jul 2006 11:59:55 -0400 Received: from [84.236.56.127] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G13bW-00041l-0I for v6ops-archive@megatron.ietf.org; Thu, 13 Jul 2006 11:59:55 -0400 Message-ID: <000001c6a693$62862680$0100007f@localhost> From: "Aidan Hill" To: Subject: Re: Hi Date: Thu, 13 Jul 2006 17:59:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6A693.62862680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 4.3 (++++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6A693.62862680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offers Adobe Full Suite: Adobe Video Collection + Adobe Premiere 1.5 Professional + Adobe After Effects 6.5 Professional + Adobe Audition 1.5 + Adobe Encore DVD 1.5 $149.95 Microsoft 2 in 1: MS Windows XP Pro + MS Office 2003 Pro $99.95 Microsoft + Adobe 3 in 1: MS Windows XP Pro + MS Office 2003 Pro + Adobe Acrobat 7.0 Professional $149.95 Bestsellers Microsoft Office Professional Edition 2003 Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 Microsoft Windows XP Professional Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 Adobe Photoshop CS2 V 9.0 Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 value(url)%} ------=_NextPart_000_0001_01C6A693.62862680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pay attention
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C6A693.62862680-- From owner-v6ops@ops.ietf.org Thu Jul 13 12:23:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13yW-0001bs-DZ for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 12:23:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G13yV-0005A2-TE for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 12:23:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G13wm-0003Dn-71 for v6ops-data@psg.com; Thu, 13 Jul 2006 16:21:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G13wl-0003DE-0s for v6ops@ops.ietf.org; Thu, 13 Jul 2006 16:21:51 +0000 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6DGLXre095293 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 13 Jul 2006 18:21:35 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607121330.k6CDURLm018209@cichlid.raleigh.ibm.com> References: <200607121330.k6CDURLm018209@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E2F04FD-B406-4CC7-BAF0-EE0E59F23F1A@muada.com> Cc: IETF IPv6 Mailing List , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Thu, 13 Jul 2006 12:21:46 -0400 To: Thomas Narten X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a On 12-jul-2006, at 9:30, Thomas Narten wrote: > draft-narten-ipv6-3177bis-48boundary-02.txt I have several problems with this document. It's vague. RFC 3177 is very clear and provides easily identifiable recommendations supported by arguments. The new draft doesn't provide any recommendations to speak of, other than that /48 is probably too much for most users. It then sort of tosses the issue over the fence into RIR terrain, largely ignoring the importance of maintaining the same assignment size when moving from one service provider to another, which is a prominent consideration in RFC 3177. I don't think it would be the worst idea ever for the authors to simply retract the document and for the IETF to stand by RFC 3177. In the alternative, I strongely suggest using RFC 3177 as a model for the new document and only insert new text where required by new insights, maintaining the overal clarity of the ealier document. It should be stressed that having different prefix sizes in the market place leads to higher operational cost because moving from one ISP to another then requires doing more work than just change a fixed number of high bits in all places where addresses appear in configurations. I'd like to offer the way DHCPv6 prefix delegation is implemented in Cisco routers as an example. Cisco routers are capable of requesting a prefix over DHCPv6 and then automatically generate addresses for subnets based on this prefix. However, this requires adding a specific number of bits, so even though the prefix itself doesn't appear in a router configuration, its _length_ does. Obviously it's easier to renumber from a small prefix into a larger one, but if different prefix sizes exist it can't be assumed that the only movement is from service providers giving out long ones to service providers giving out shorter ones. There is another issue, that is not present in the original RFC 3177, but which I stumbled over several times in operational environments, so I think it's important it's addressed: RFC 3177 only talks about the prefix for the end-user. It doesn't address the way the end-user communicates with his or her service provider. (I'm ignoring the case of a /128.) With a /64 this can happen in one of two ways: 1. The ISP assigns the /64 for use on the link between the ISP and the user 2. The ISP hands the /64 to the user for internal use In the first case, the user can't let the device that talks to the ISP route IPv6 between an internal subnet and the ISP, but is forced to connect all devices that require connectivity directly at the link level to the ISP. In the second case, there aren't any addresses available on the link between the user and the ISP, so either additional address space must be provisioned, or link locals must be used. Neither of these is impossible, but they do require additional complexity that is extremely undesireable. Considering the above, giving out /64 really doesn't address a reasonable use case: either the prefix is used on the ISP link and then a /128 would also suffice, or the prefix isn't used on the ISP link and a second subnet is required. For these reasons, I think it's important to move away from /64 in the RFC 3177 /128-/64-/48 model. The next obvious choice is /60, which allows for 16 subnets. The all-ones subnet [1] could be used for the ISP subnet by convention, simplifying address provisioning and leaving 15 subnets for use by the customer. This is more than enough in all cases where only a single router is expected to be present on the site in question. This brings us to a /128-/60-/48 model. The next question is whether it's useful to bring the /48 down to /56 as a general recommendation. My answer is no. Since for the vast majority of home and small office users a /60 will suffice where they would have gotten a /48 under RFC 3177 (because they have a handful of subnets or in case they will in the future), the amount of address space used will already go down dramatically, so from an address use point there is no reason to fiddle with /48. A second argument is that if someone needs more than a /60, there is a reasonable chance that they may eventually also grow out of a /56. If and when that happens, they have up to 250 subnets and renumbering at that point is quite painful, apart from my earlier argument about the virtue of having a standardized prefix size for a given class of end-users. Iljitsch van Beijnum [1] Another choice would be the all-zeros subnet but if the same is done with a /48 it would be a shame to use this subnet up for this as the all-zeros subnet allows for shorter addresses, especially if more zeros follow. From owner-v6ops@ops.ietf.org Thu Jul 13 13:44:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15F3-0000Fj-1V for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 13:44:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15F1-00015q-OQ for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 13:44:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G15DJ-000FYH-Aj for v6ops-data@psg.com; Thu, 13 Jul 2006 17:43:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G15DG-000FXv-Qr for v6ops@ops.ietf.org; Thu, 13 Jul 2006 17:42:58 +0000 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 13 Jul 2006 10:42:33 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="305564396:sNHT71654398276" 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 k6DHgWLx011281; Thu, 13 Jul 2006 10:42:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6DHgV7B013104; Thu, 13 Jul 2006 10:42:31 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 10:42:30 -0700 Received: from [132.219.16.127] ([10.21.88.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 10:42:30 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <881368AE-0874-42BD-94AA-C1CF6E2E409F@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Review request from v6ops Date: Thu, 13 Jul 2006 13:42:28 -0400 To: shim6@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Jul 2006 17:42:30.0422 (UTC) FILETIME=[B6D96B60:01C6A6A3] DKIM-Signature: a=rsa-sha1; q=dns; l=168; t=1152812552; x=1153676552; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Review=20request=20from=20v6ops; X=v=3Dcisco.com=3B=20h=3DPwf7ThsLL5xIjChhLDcoPue61Zc=3D; b=fJtGdwpcmOfY71ktPvUoqItqiMvB0kyIrK0GX6gYZohS+PsxGdyCC0VIPS57xQg2TapA7pCn Nprvd3adw/MdHXna9MkdKkx6lCdjQ2epkaBLqfjRpjBeo8udCpuSgWTO; Authentication-Results: sj-dkim-7.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 The v6ops WG has been asked to look at draft-arifumi-v6ops-addr- select-ps-00.txt, and would like input from shim6. Please forward comments to v6ops@ops.ietf.org From owner-v6ops@ops.ietf.org Thu Jul 13 14:26:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15tb-00051A-5M for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 14:26:43 -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 1G0zrq-0000H5-0r for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 08:00:30 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0zja-0005Ya-23 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 07:52:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0zhh-000Px1-Fy for v6ops-data@psg.com; Thu, 13 Jul 2006 11:50:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G0zhf-000PwE-3x for v6ops@ops.ietf.org; Thu, 13 Jul 2006 11:49:59 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 13 Jul 2006 04:49:58 -0700 X-IronPort-AV: i="4.06,237,1149490800"; d="scan'208"; a="305471524:sNHT26038112" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DBnvZu011866; Thu, 13 Jul 2006 04:49:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6DBnoij000175; Thu, 13 Jul 2006 04:49:58 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 04:49:54 -0700 Received: from [10.2.242.255] ([10.21.89.8]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 04:49:53 -0700 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC2EEA44@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC2EEA44@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3214A238-4625-48DA-8D16-02A24814E314@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: WG Document Question on draft-chown-v6ops-campus-transition-03 Date: Thu, 13 Jul 2006 07:49:53 -0400 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 13 Jul 2006 11:49:54.0140 (UTC) FILETIME=[74B8F9C0:01C6A672] DKIM-Signature: a=rsa-sha1; q=dns; l=910; t=1152791398; x=1153655398; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20WG=20Document=20Question=20on=20draft-chown-v6ops-campus-transit ion-03; X=v=3Dcisco.com=3B=20h=3DnUw9fVVKuZgbCLP4yDIdgNhfXC0=3D; b=HScR5KfG5qLt2UsPDAEYW7eH1VA56bS/TfwxbdLRu0gjh6YI+se99J2dKO8kr3rSZnlKblyC M1JR65Ti+ntXj0xagSiuc3XN4xldyfXJNCMO7uR9KL3yJg3UmGsl+2OV; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 I believe that the outcome of yesterday's meeting was that he would divide it into two documents, one stable and one ongoing, the stable one would be a working group document, and would be published as informational by the WG following appropriate discussion. On Jul 13, 2006, at 6:12 AM, Bound, Jim wrote: > Folks, > > I believe today in trying to be silent in IETF WG meetings unless > it is > truly urgent technical issue I have as individual with a spec. I am > sending this mail as I believe Tim Chown work on Campus transition > should be a working group document. I think it is good operational > example and brings out discussion of VLANs too which is important and > many other operational requirements other forms of deployment will > face. > > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chown-v6ops- > camp > us-transition-03.txt > > Thanks > /jim From owner-v6ops@ops.ietf.org Thu Jul 13 14:53:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16JZ-0006ps-Gi for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 14:53:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16JY-0007U9-FR for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 14:53:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G16Gi-000NxP-0S for v6ops-data@psg.com; Thu, 13 Jul 2006 18:50:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [152.78.68.129] (helo=owl.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G16Gf-000Nwm-1z for v6ops@ops.ietf.org; Thu, 13 Jul 2006 18:50:33 +0000 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6DIoRjZ015214 for ; Thu, 13 Jul 2006 19:50:27 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6DIoLpO014576 for ; Thu, 13 Jul 2006 19:50:21 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k6DIoILi027612 for v6ops@ops.ietf.org; Thu, 13 Jul 2006 19:50:18 +0100 Date: Thu, 13 Jul 2006 19:50:18 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Message-ID: <20060713185017.GJ24503@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <009501c69aea$a75e7cd0$f66514ac@corp.devicescape.com> <07f901c69c7c$9880e660$1c7ba8c0@tndh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07f901c69c7c$9880e660$1c7ba8c0@tndh.net> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 2.3 (++) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab On Fri, Jun 30, 2006 at 12:37:16PM -0700, Tony Hain wrote: > Network Working Group G. Van de Velde > Internet-Draft T. Hain > Expires: January 1, 2007 R. Droms > Cisco Systems > B. Carpenter > IBM Corporation > E. Klein > Tel Aviv University > June 30, 2006 > > > IPv6 Network Architecture Protection > Hi Tony, Some comments on this nap-03 version follow. Overall, it is a good and a very useful document. The Informational nature of the document should be stressed (vs BCP). I think my general comment would be that the proposed IPv6 tools all have their own tradeoffs, just as deployment of IPv4 NAT is a tradeoff. These tradeoffs should be explicitly mentioned; I am not sure they are right now. For example, privacy addresses have management issues (recognising hosts over time), as does using ULAs with globals ('bugs' in RFC3484). Both need more operational experience and/or (minor) protocol fixes. The topology hiding solution has the biggest tradeoff, and that's probably why Margaret has a bigger issue with that. In addition to the considering the tradeoffs, we need to have some operational experience from use of these proposals (to migrate the text to BCP one day), and hopefully that will come soon. For many admins, the topology and privacy issues will not be important. So maybe there are different 'levels' of NAP that could be used, varying from global addressing + firewall at the bottom then adding ULAs, RFC3041 and topology hiding as additional features. As an aside, if you defined IPv4 NAP, that would represent globals and firewalls; you could even do the host routing. The advantage IPv6 has, once proven, is the multi-addressing with ULAs and privacy addresses. Inline comments: Indeed, product marketing departments have effectively driven a perception that some connectivity and security concerns can only be solved by using a NAT device, without any mention of the negative impacts on applications. => Isn't the main benefit is ease of deployment, for the typical home user? And wasn't the word 'marketing' being removed throughout the doc? header modification feature of NAT in an IPv6 network. It should be noted that this document is 'informational', as it discusses approaches that will work to accomplish the goals. It is specifically not a BCP that is recommending any one approach. => This is hidden too well (see main comments :) trail which is a fundamental security tool. That said, the artifacts of NAT devices do provide some value. 1. The need to establish state before anything gets through from outside to inside solves one set of problems. 2. The need to stop receiving any packets when finished with a flow solves a set of problems 3. the need to appear to be attached at the edge of the network solves a set of problems 4. and the ability to have addresses that are not publicly routed solves yet another set (mostly changes where the state is and scale requirements for the first one). => Are points 1-3 discussed later in the context of NAP? If those points add value for NAT, NAP should be stated to match them. +------------------|-----------------------|-----------------------+ | Addressing | RFC 1918 | RFC 3177 & 4193 | | Autonomy | see section 2.5 | see section 4.5 | +------------------|-----------------------|-----------------------+ => RFC 4193 isn't mentioned in section 4.5? +------------------|-----------------------|-----------------------+ | Global Address | RFC 1918 | 17*10^18 subnets | | Pool | << 2^48 application | 3.4*10^38 addresses | | Conservation | end points | full port list / addr | | | topology restricted | unrestricted topology | | | see section 2.6 | see section 4.6 | +------------------|-----------------------|-----------------------+ => Make the numbers explicit? Where do they come from? +------------------|-----------------------|-----------------------+ | Renumbering and | Address translation | Preferred lifetime | | Multi-homing | at border | per prefix & Multiple| | | | addresses per | | | | interface | | | see section 2.7 | see section 4.7 | +------------------+-----------------------+-----------------------+ => Anyone for 8+8? :) Wide-scale deployments have shown that using NAT to act as a simple gateway attaching a private IPv4 network to the Internet is simple and practical for the non-technical end user. Frequently a simple user interface, or even a default configuration is sufficient for configuring both device and application access rights. => Therefore IPv6 gateways must be simple to deploy too. Maybe the document needs a new section that is simply "Simple to Deploy"? Then you could discuss how simple it is to manage a stateful firewall, or to negotiate firewall traversal for apps (as opposed to NAT traversal). 2.2. Simple Security due to Stateful Filter Implementation This benefit may be partially real, however, experienced hackers are well aware of NAT devices and are very familiar with private address space, and have devised methods of attack (such as trojan horses) that readily penetrate NAT boundaries. For these reasons the sense of security provided by NAT is actually an illusion. => Which applies to IPv6, or IPv4 with globals used. The question is more whether the address and port manipulation provides security, and you answer that question anyway. In some cases, NAT operators (including domestic users) may be obliged to configure quite complex port mapping rules to allow external access to local applications such as a multi-player game or web servers. In this case the NAT actually adds management complexity compared to a simple router. In situations where two or more devices need to host the same application or otherwise use the same public port this complexity shifts from difficult to impossible. => Maybe some operators want NAT for 'walled gardens'. But that's a 'political' statement maybe best avoided? Some network managers prefer to hide as much as possible of their internal network topology from outsiders as a useful precaution to mitigate scanning attacks. Mostly this is achieved by blocking "traceroute" etc., though NAT entirely hides the internal subnet topology. Scanning is a particular concern in IPv4 networks because the subnet size is small enough that once the topology is known it is easy to find all the hosts, then start scanning them for vulnerable ports. Once a list of available devices has been mapped, a port-scan on these IP addresses can be performed. => Are IPv4 networks really that sparsely populated for that to matter? 2.5. Independent Control of Addressing in a Private Network Many private IPv4 networks take benefit from using the address space defined in RFC 1918 to enlarge the available addressing space for their private network, and at the same time reduce their need for globally routable addresses. This type of local control of address resources allows a sufficiently large pool for a clean and hierarchical addressing structure in the local network. Another benefit is due to the usage of independent addresses on majority of the network infrastructure there is an increased ability to change provider with less operational difficulties. => Maybe spell out that internal comms can keep working while renumbering or disconnected. But this section also true because typically a NAT network has clients accessing external servers, and not vice-versa. The number of and types of applications that can be deployed by these ISPs and their customers is restricted by the ability to overload the port range on the public side of the most public NAT in the path. The limit of this approach is something substantially less than 2^48 possible active **application** endpoints (approximately [2^32 minus 2^29] * [2* 2^16 minus well known port space]), as distinct from addressable devices each with their own application endpoint range. => Expand on the working? Not clear where the numbers come from, as per the same comment earlier. The reader must clearly distinguish between features of IPv6 that were fully defined when this document was drafted and those that were potential features that still required more work to define them. The latter are summarized later in the 'Gap Analysis' section of this document. However, we do not distinguish in this document between fully defined features of IPv6 and those that were already widely implemented at the time of writing. => It's not just about what's defined, but also what we have operational experience of, and tradeoffs in using the tools. For example, using Privacy Addresses is fine, but has a price (management complexity). 3.1. Privacy Addresses (RFC 3041) As originally defined, IPv6 stateless address auto-configuration (SLAAC) will typically embed the IEEE Link Identifier of the interface as the IID part, though this practice facilitates tracking and profiling of a device through the consistent IID. RFC 3041 [7] describes an extension to SLAAC to enhance device privacy. Use of => Maybe 'add' not 'enhance'? the privacy address extension causes nodes to generate global-scope addresses from interface identifiers that change over time, consistent with system administrator policy. Changing the interface identifier (thus the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when addresses used in different transactions actually correspond to the same node. A relatively short valid lifetime for the privacy address also has the side effect of reducing the attack profile of a device, as it is not directly attackable once it stops answering at the temporary use address. => Maybe note the Privacy Address is only used for initiating outbound connections; a node receiving connections inbound is likely to have a separate global address, which is probably DNS-advertised. 3.2. Unique Local Addresses o In practice, applications may treat these addresses like global scoped addresses but address selection algorithms may need to => Actually they *have* global scope? See 3.3 of the ULA RFC. The main goal of untraceable IPv6 addresses is to create an apparently amorphous network infrastructure as seen from external networks to protect the local infrastructure from malicious outside influences and from mapping of any correlation between the network activities of multiple devices from external networks. When using untraceable IPv6 addresses, it could be that two apparently sequential addresses are allocated to devices on very different parts of the local network instead of belonging to devices adjacent to each other on the same subnet. => As per the Network Scanning draft, I'd avoid sequential addresses, rather emphasising the obfuscation of topology at the subnet view as the important thing? These should be globally routable IPv6 addresses which can be randomly and independently assigned to IPv6 devices. The random assignment is intended to mislead the outside world about the structure of the local network. However the local network needs to maintain a correlation between the location of the device and the untraceable IPv6 address. For smaller deployments this correlation could be done by generating IPv6 host route entries, or for larger ones by utilizing an indirection device such as a Mobile IPv6 Home Agent. Additional details are in section 4.7. => This mapping may have some of the state complexity of NAT? => It may be that this is only needed for a part of a site, not all of it? So a 50,000 node site may only want to hide certain parts, and a few hundred nodes? 4. Using IPv6 Technology to Provide the Market Perceived Benefits of NAT => Delete 'Market'? With external connectivity the simple gateway should use DHCP-PD to acquire a routing prefix from the service provider for use when connecting to the global Internet. End-system connections involving other nodes on the global Internet will always use the global IPv6 addresses derived from this prefix delegation. It should be noted that the address selection policy table in end-systems defined in RFC 3484 should be configured to prefer the ULA prefix range over the DHCP-PD prefix range when the goal is to keep local communications stable during periods of transient external connectivity. => So are you advocating ULAs and globals in parallel? There are again costs here (tradeoffs), e.g. possibly running split-view DNS, and the 3484 'bugs' described in v6ops this week. The gotchas cited in the 'Deprecating Site Locals' text need to be carefully considered still, even with ULAs. 3. The size of the address space of a typical subnet (64 bits of IID) will make a complete subnet ping sweep virtually impossible due to the potential number of combinations available. Reducing => Change 'virtually impossible' to 'computationally difficult'? Assuming the network administrator is aware of [19] the increased size of the IPv6 address will make topology probing much harder, and almost impossible for IPv6 devices. => Ditto on 'impossible'. IPv4 NAT was not developed as a security mechanism. Despite marketing messages to the contrary it is not a security mechanism, and hence it will offer some security holes while many people assume their network is secure due to the usage of NAT. IPv6 security best practices will avoid this kind of illusory security but can only address the same threats if correctly configured firewalls and IDS systems are used at the perimeter. It must be noted that even a firewall doesn't fully secure a network. Many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows etc. What a firewall does is prevent a network administration from having to pay for bandwidth to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary. => So maybe separate the network security here from application security more explicitly. Focus on the pros/cons of the bit manipulations? reflective session state). There should also be an easy interface which allows users to create inbound 'pinholes' for specific purposes such as online-gaming. Another consideration would be the capability for service provider mediated pinhole management where things like voice call signaling could dynamically establish pinholes based on predefined authentication rules. => Here you mean firewall traversal not NAT traversal? I think there is a difference worth making. The problem is shifted, but there. IPv6 enables the collection of information about data flows. Due to the fact that all addresses used for Internet and intra-/inter- site communication are unique, it is possible for an enterprise or ISP to get very detailed information on any communication exchange between two or more devices. This enhances the capability of data- flow tracking for security audits compared with IPv4 NAT, because in IPv6 a flow between a sender and receiver will always be uniquely identified due to the unique IPv6 source and destination addresses. => Again, there's a tradeoff here that's not mentioned. Due to the large IPv6 address space available there is plenty of freedom to randomize subnet allocations. By doing this, it is possible to reduce the correlation between a subnet and its location. When doing both subnet and IID randomization [RFC 3041] a casual snooper won't be able to deduce much about the networks topology. => A tradeoff here is lack of aggregation, with scalability implications for routing tables, but also implications if you want to renumber or restructure parts of your network. o One approach uses explicit host routes in the IGP to remove the external correlation between physical topology attachment point and end-to-end IPv6 address. In the figure below the hosts would be allocated prefixes from one or more logical subnets, and would inject host routes to internally identify their real attachment point. This solution does however show severe scalability issues => As Margaret says, I think the tradeoff here is significant. o Another technical approach to fully hide the internal topology is use of a tunneling mechanism. Mobile IPv6 without route optimization is one approach for using an automated tunnel, as it always starts in tunnel mode via the Home Agent (HA). In this => As it is here. 4.5. Independent Control of Addressing in a Private Network IPv6 provides for autonomy in local use addresses through ULAs. At => Do we mention PI proposals here, or leave that out? 4.6. Global Address Pool Conservation IPv6 provides sufficient space to completely avoid the need for overlapping address space. Since allocations in IPv6 are based on subnets rather than hosts a reasonable way to look at the pool is that there are about 17*10^18 unique subnet values where sparse allocation practice within those provides for new opportunities such as SEND 3971 [12]. => Maybe say 2^n, which is... i.e. show the working in getting to that number. 5.1. Medium/large private networks The majority of private enterprise, academic, research, or government networks fall into this category. Many of these networks have one or more exit points to the Internet. Though these organizations have sufficient resources to acquire addressing independence when using IPv4 there are several reasons why they might choose to use NAT in such a network. For the ISP there is no need to import the IPv4 address range from the remote end-customer, which facilitates IPv4 route summarization. The customer can use a larger IPv4 address range (probably with less-administrative overhead) by the use of RFC 1918 and NAT. The customer also reduces the overhead in changing to a new ISP, because the addresses assigned to devices behind the NAT do not need to be changed when the customer is assigned a different address by a new ISP. By using address translation in IPv4 one avoids the expensive process of network renumbering. Finally, the customer can provide privacy for its hosts and the topology of its internal network if the internal addresses are mapped through NAT. => Do we need to try to suggest using all the bells and whistles here? For most sites, maybe using IPv6 and stateful firewalling is enough; maybe they don't care about privacy addresses or topology hiding? 5.2. Small Private Networks For the DHCPv6-PD solution, a dynamic address allocation approach is => Do you mean dynamic or automatic? chosen. By means of the enhanced DHCPv6 protocol it is possible to have the ISP push down an IPv6 prefix range automatically towards the small private network and populate all interfaces in that small private network dynamically. This reduces the burden for administrative overhead because everything happens automatically. => Maybe some customers will want a random prefix each time (for better privacy than 3041)? I wouldn't personally, but some will I'm sure. 6.1. Simple Security Dynamic pinhole management is an area for further study. Several partial solutions exist including ICE, UPNP, as well as alternative proposals for Service Provider based control. The 'simple' aspect of the security provided by a stateful firewall will require some degree of automation to mask the technical complexity from the consumer that only wants a secure environment with working applications. => This is firewall traversal rather than NAT traversal? 8. Security Considerations While issues which are potentially security related are discussed throughout the document, the approaches herein do not introduce any new security concerns. Product marketing departments have widely => 'Marketing' used again? This document defines IPv6 approaches which collectively achieve the goals of the network manager without the negative impact on applications or security that are inherent in a NAT approach. To the degree that these techniques improve a network manager's ability to explicitly audit or control access, and thereby manage the overall attack exposure of local resources, they act to improve local network security. In particular the explicit nature of a content aware firewall in NAP will be a vast security improvement over the NAT artifact where lack of translation state has been widely sold as a form of protection. => Well, a NAT firewall *could* also be 'content aware' (do you mean an IDS function here?) This document has described a number of techniques that may be combined on an IPv6 site to protect the integrity of its network architecture. These techniques, known collectively as Network Architecture Protection, retain the concept of a well defined boundary between "inside" and "outside" the private network, and allow firewalling, topology hiding, and privacy. However, because they preserve address transparency where it is needed, they achieve these goals without the disadvantage of address translation. Thus, Network Architecture Protection in IPv6 can provide the benefits of IPv4 Network Address Translation without the corresponding disadvantages. => But there are other disadvantages, or tradeoffs. Maybe this can be made into another general table? => Appendix A maybe repeats information in the main document. Does this matter? -- Tim From owner-v6ops@ops.ietf.org Thu Jul 13 15:15:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16eo-0000jr-CX for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 15:15:30 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16YJ-0000Hy-Ic for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 15:08:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G16XI-0001LD-3B for v6ops-data@psg.com; Thu, 13 Jul 2006 19:07:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G16XG-0001Kd-Bn for v6ops@ops.ietf.org; Thu, 13 Jul 2006 19:07:42 +0000 Received: from eaglet (127.0.0.1:3046) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Jul 2006 12:07:39 -0700 From: "Tony Hain" To: "'Margaret Wasserman'" Cc: Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 13 Jul 2006 12:07:39 -0700 Message-ID: <005b01c6a6af$9d013ef0$7d06db84@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acal25Jxv+WvPD3yQHK4nbUtVO4qyAAx9z6Q In-Reply-To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Margaret Wasserman wrote: > Hi Tony, > > ... > There still seem to be some conflicting statements in the draft about > the applicability of the route injection topology hiding mechanism. > Presumably, we are talking about an enterprise-level deployment, > because it depends on the use of an IGP, but the diagram says "simple > gateway or home gateway". I would rather it said "topology masking > router", as you have described it later. That is easy to fix, though there is no requirement for complex large scale deployment as rfc2453 (ripv2) would do the job and be easy enough to self-administer/auto-conf in a dentist office scenario. > ... > > RFC 3484 policy table entry biasing FC00::/7 as preferred over > > 2000::/3 > > This response does not answer my question. I understand how this > will work iff internal nodes are given a ULA as a possible > destination address for local nodes, but I don't understand how the > local nodes will be given the ULAs. Do you anticipate the use of > split-DNS in this scenario, so that ULAs are supplied internally and > not externally? > > One of the problems with NAT, at least from my perspective, is that > they require a split-DNS employment to get local name resolution. > Are we expecting that NAP will have that same property? Split-DNS would make the non-local case more efficient, but it is not a hard requirement like it is with IPv4/nat. Given that enterprises have nodes that they don't want the world to know about they are likely to be running some form of split-DNS anyway, so I don't see this as a big deal either way. > > ... > It is clear from this and earlier responses that a "topology masking > router" is a special beast with some different properties than a > regular router, such as logic to forward solicited node multicast > packets to the set of potentially matching nodes, There is nothing magic about the topology masking router and forwarding solicited-node multicast is not required. ND runs between the topology-hidden node and the router it really attaches to. For traffic from other nodes that might be actually attached to the logical subnet, the state of the on-link flag would indicate that those nodes should forward the real traffic via the router if their ND fails. Any other node (in that subnet or not) would forward via their local router and the routing system would deliver the traffic to the real attachment point because that is what the IGP says to do. > the ability to > forward subnet-local multicast to all of the nodes on the logical > subnet, etc. I think that you should describe these properties when > asserting that IGP route injection can be used for topology hiding. Subnet local multicast to a collection of nodes that are scattered makes no technical sense, but you are correct there is nothing in the document that talks about the issue. If someone could suggest text I would appreciate it, but I will see what I can do to identify the point. > > > ... > > One needs to pay attention to the distinction between 'link' and > > 'subnet'. > > ... > > This is quite a complicated topic that has been discussed in various > places, and I don't think that either of us wants to re-hash all of > those discussions here or in this document... It isn't clear to me > that this works as cleanly as you seem to think, but that is almost > certainly outside the scope of this document. > > Since you later seem to indicate that these nodes won't receive RA's, > though, I'm not sure where we would clear the on-link flag. Maybe > via manual configuration when we set-up the addresses and identify > the router with which these nodes should register? Registration with the topology masking router is only a property of the MIPv6 approach. The IGP route injection approach effectively registers with the first hop router. Either way the configuration does not need to be manual, though that would clearly work. I don't know all the mechanisms that hosts might use to configure a home-address/home-agent, but a similar approach would work for the route injection technique specifying the logical-address/IGP-type. In either case when the received RA does not match the home/logical address prefix then the logical prefix would be considered off-link. One could either manually mark it up front or discover the fact due to the mismatch between the topology hidden prefix and the locally attached one. > > >>> (5) Would autoconfiguration be used on the logical subnet, or would > ... > Perhaps you could make it clear that this mechanism relies on manual > configuration of IP addresses, the (local topology) address of the > router with which to register, and the on-link flag on each of the > topology-hidden hosts? Should we be considering a DHCPv6 option to > provide a topology hiding prefix? I wouldn't bother with a specific option since that can be derived from the difference between the home/logical-address and the currently attached prefix. It is also not clear configuration needs to be manual. Since there is no hard and fast requirement here is seems like this discussion is outside the scope of describing that techniques exist to eliminate the perceived need for nat. > > > ... The primary disadvantage is that all traffic has to route > > via the > > topology hiding router, and the L2 has to have the means to create > > the vlan. > > I will have to look at what you've added again, because I think we > are having a misunderstanding. I am merely saying that you would use > a bridged network (no L3 topology). Your local physical topology > would be handled at L2, with the appearance of a completely flat > network at L3. To be complete, you are talking about the specific topology hidden subnet being virtually connected to the topology hiding router using an L2 VLAN approach. There may be other subnets in the network that share the same L2 hardware as different VLANs, but those are interconnected to the topology hidden subnet via the L3 topology hiding router. If you were really talking about a single flat L2, then there is no L3 topology to hide. > > >>> If we decide that we actually want to make this recommendation, > > > > It is not a BCP, it is simply information. > > Two comments on this: > > (1) I don't think that readers make a big distinction between BCP and > Info. While I agree, that distinction does differentiate our process expectations and the depth of detail is necessary. If you believe strongly that a BCP is required, please write one to follow this. Right now we need a document that dispels the myth that a nat is required to accomplish these tasks. > (2) Even in an informational document, I don't think it is reasonable > to refer to a solution as though it is a well-understood solution > when it is not. If we want to discuss this solution, I think we need > to say enough for readers to understand how the solution actually > works. It isn't sufficient for users to just insert host routes in > current routing equipment if that equipment does not include other > features to be a "topology hiding router", right? There is nothing really magic about a topology hiding router. In the MIPv6 case it is a standard HA and does what HA's do to support remote nodes that are not doing route optimization. In the IGP case it doesn't really have to do anything (and may not even have a real interface for the virtual subnet) because the IGP delivers the bits to the actual attachment point no matter where they come from. You say later that this should not be a tutorial though here you are arguing that it should be. Host routing is not rocket science, and the only cases it becomes a scaling problem are those where the network manager should have enough expertise to recognize what they are getting into. MIPv6 is a new enough technology that it might not be well understood, but tunneling is well understood and widely deployed. All we are talking about here is leveraging the automatic tunneling feature of MIPv6 to avoid the need for manually configuring tunnels. In the -03 version added a fair amount of text to describe the MIPv6 approach in more detail, and will add more if it is really unclear. > > ... > I don't think we need a primer on IPv6, but I do think we need some > description of the topology hiding router and its properties. There is nothing to describe. If you think there is something special here please send text to describe the magic for assigning hosts from a specific /64 where there is no physical interface on any router with that prefix. Since in one case the hosts are injecting their address set directly into the IGP, they effectively become the router for each of those /128's. In the MIPv6 case the standard HA would need to tunnel forward, but there is no need for the topology hidden subnet to really exist on a physical interface. The function is to virtualize the appearance of that subnet at/near the edge of the network just as those nodes would appear from the outside of a nat. > > We also need to decide if we have consensus that such a solution is a > good idea, because regardless of the document classification, this > document is stating how IPv6 can provide the benefits of IPv6 NAT, > and I don't think we should state that IPv6 can be used in a certain > way to provide certain benefits unless we think: (1) it will work, > (2) any downsides of the approach are mentioned, and (3) the > downsides are not worse than the benefits. I expanded the trade-off discussion in -03 which should cover point 2, even for the L2 VLAN approach. We don't require point 1 even for standards track documents (see shim6), and for point 3 the reason for listing alternatives is that the qualitative judgment really depends on the specific use case. In any case this is a market call not an I* pronouncement. Tony From owner-v6ops@ops.ietf.org Thu Jul 13 15:37:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zz-0002b1-5V for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 15:37:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16tM-000289-EN for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 15:30:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G16sd-0005U8-6a for v6ops-data@psg.com; Thu, 13 Jul 2006 19:29:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [152.78.68.129] (helo=owl.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G16sc-0005TS-9S for v6ops@ops.ietf.org; Thu, 13 Jul 2006 19:29:46 +0000 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6DJTdij024177 for ; Thu, 13 Jul 2006 20:29:39 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6DJTWR1016030 for ; Thu, 13 Jul 2006 20:29:32 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k6DJTTKj028500 for v6ops@ops.ietf.org; Thu, 13 Jul 2006 20:29:29 +0100 Date: Thu, 13 Jul 2006 20:29:29 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Message-ID: <20060713192928.GA28229@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <005b01c6a6af$9d013ef0$7d06db84@tndh.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005b01c6a6af$9d013ef0$7d06db84@tndh.net> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On Thu, Jul 13, 2006 at 12:07:39PM -0700, Tony Hain wrote: > > Subnet local multicast to a collection of nodes that are scattered makes no > technical sense, but you are correct there is nothing in the document that > talks about the issue. If someone could suggest text I would appreciate it, > but I will see what I can do to identify the point. I think this is a very good point. Clarification of use of multicast would be appreciated. Tim From owner-v6ops@ops.ietf.org Thu Jul 13 15:50:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17Ct-0005hB-DQ for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 15:50:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17Cs-0003t3-0z for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 15:50:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G17CJ-0008wI-Js for v6ops-data@psg.com; Thu, 13 Jul 2006 19:50:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G17CI-0008w3-MS for v6ops@ops.ietf.org; Thu, 13 Jul 2006 19:50:06 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6DJo21u016993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G17CE-0003ZW-9K; Thu, 13 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-nap-03.txt Message-Id: Date: Thu, 13 Jul 2006 15:50:02 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Network Architecture Protection Author(s) : G. Van de Velde, et al. Filename : draft-ietf-v6ops-nap-03.txt Pages : 42 Date : 2006-7-13 Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for address translation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-nap-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-nap-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-13145920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-nap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-nap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-13145920.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 13 17:48:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G192k-0002rn-VX for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 17:48: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 1G11kr-0005If-R2 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:01:25 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G11Zt-0007km-Lb for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 09:50:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11ZL-000Ak8-5A for v6ops-data@psg.com; Thu, 13 Jul 2006 13:49:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.110.150] (helo=e32.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11ZK-000Ajp-1F for v6ops@ops.ietf.org; Thu, 13 Jul 2006 13:49:30 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDnTUf004669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 09:49:29 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6DDnSt4308452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jul 2006 07:49:28 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6DDnSfg030611 for ; Thu, 13 Jul 2006 07:49:28 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-223-212.mts.ibm.com [9.65.223.212]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDnRgT030595; Thu, 13 Jul 2006 07:49:28 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k6DDmpDR006993; Thu, 13 Jul 2006 09:48:52 -0400 Message-Id: <200607131348.k6DDmpDR006993@cichlid.raleigh.ibm.com> To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-reply-to: References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> Comments: In-reply-to Pekka Savola message dated "Thu, 13 Jul 2006 04:27:28 +0300." Date: Thu, 13 Jul 2006 09:48:51 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Pekka Savola writes: > On Wed, 12 Jul 2006, Thomas Narten wrote: > > FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just > > prior to the ID cutoff, and the authors believe it is ready for > > publication as an RFC. We are in discussion with the ADs about having > > the document shepherded through the IESG as an informational document. > > Note that this document would formally replace RFC3177. > There have already been a lot of comments I agree with, so I'll just > mention one higher-level issue that hasn't been mentioned yet > (AFAICS): > This document obsoletes 3177, but does not mention those aspects of > 3177 which are not addressed by this document. Pekka, you've raised this issue before, and I've gone back to 3177 and tried to include (in 3177bis) the points from 3177 that actually make sense (to me) to say something about. E.g., there is a lot of the text in 3177 about multihoming that IMO is pretty irrelevant and there is not much point in trying to include it. Can you please be specific about what points you think need to be carried over into 3177bis? > Silently leaving them > out is bound to raise questions later on, so this document should make > an explicit statement one way or the other. Specifically, at least > the discussion on /128 is missing. 3177 has no "discussion" about /128. What it says about /128 is the following. Quoting from 3177: The IESG and the IAB recommend the allocations for the boundary between the public and the private topology to follow those general rules: - /48 in the general case, except for very large subscribers. - /64 when it is known that one and only one subnet is needed by design. - /128 when it is absolutely known that one and only one device is connecting. and then later... In particular, we recommend: - Home network subscribers, connecting through on-demand or always-on connections should receive a /48. - Small and large enterprises should receive a /48. - Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's. - Mobile networks, such as vehicles or mobile phones with an additional network interface (such as bluetooth or 802.11b) should receive a static /64 prefix to allow the connection of multiple devices through one subnet. - A single PC, with no additional need to subnet, dialing-up from a hotel room may receive its /128 IPv6 address for a PPP style connection as part of a /64 prefix. Note that both references are in the specific "recommendation" part Yet, making a specific recommendation is exactly what this document is not doing. Can you say something about what you think would be appropriate to say about /128? And note for context, that the revised ARIN policy in this regard doesn't even mention /128 anymore (http://www.arin.net/policy/proposals/2005_8.html) the recommendation there would appear to say that a /64 is the recommended minimum. Thus, IMO, we really don't need to be very concerned about /128 to end sites. No one seems (in practice) seems to think this is something that ought to be done. > Btw, the document title should probably say assignment instead of > allocation. Indeed! Thanks. Thomas From owner-v6ops@ops.ietf.org Thu Jul 13 18:04:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19Ib-0003xF-Q9 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 18:04:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19Ib-0004ht-51 for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 18:04:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19GX-0001Xw-TG for v6ops-data@psg.com; Thu, 13 Jul 2006 22:02:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G19GU-0001XB-O3 for v6ops@ops.ietf.org; Thu, 13 Jul 2006 22:02:35 +0000 Received: from [132.219.31.219] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001930753.msg for ; Thu, 13 Jul 2006 23:59:56 +0200 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 13 Jul 2006 17:45:08 -0400 Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt From: JORDI PALET MARTINEZ To: , Message-ID: Thread-Topic: draft-narten-ipv6-3177bis-48boundary-02.txt Thread-Index: AcamxZvX2m8F1hK4EduOaAANky3PwA== In-Reply-To: <200607131330.k6DDUJRM006668@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060713:v6ops@ops.ietf.org::oeWDr0dWzTrKDF34:00000000000000000000000000000000000000000001/Su X-MDRemoteIP: 132.219.31.219 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Fri, 14 Jul 2006 00:00:02 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Hi Thomas, Below, in-line. Regards, Jordi > De: Thomas Narten > Responder a: > Fecha: Thu, 13 Jul 2006 09:30:19 -0400 > Para: > CC: , > Asunto: Re: draft-narten-ipv6-3177bis-48boundary-02.txt > > Hi Jordi. > >> Hi all, > >> I've reviewed this document and my comments are as follows. > >> 1. Introduction >> "giving out an excessive". I think we need to define excessive >> and/or say if this is an objective or subjective perception. > > I have two repsonses to this. > > First. giving out a /48 to every home network (which today has at most > a handful of machines, which means, one subnet would suffice) is Part of the problem is what each of us considers enough, and this may depend on knowledge about developments being cooked, which bring the need of more than 256 subnets, even if you have only a handful of devices in each one. > widely viewed as excessive. Even a /56 to such end sites seems more > than enough space to meet needs for at least the next decade (and most > people seem to be comfortable with that, even if it is a lot of > space). You've been to RIR meetings. Surely you have noticed this Yes, having been in probably all the RIR meetings in the last 3 years or so, my perception is that people is divided in both sides, but there is not a clear view that one or the other is good. In concrete regions this becomes more balanced to one side or the other. Moreover, most of the people talking about this has the view of "/48 is bad" because they don't understand the scale of magnitude vs. IPv4, they are some how "IPv4 old fashioned mind set". The perception was even worst because the previous HD-ratio. However, now that the HD-ratio change has been accepted in all the regions, the perception of /48 being a waste, is not realistic. I recall Tony Hain figures with the HD-ratio change of about 480 years or so. I think even if we are mistaken by let's say 250-300 years, assuming that our conservation principles need to account for that much time is extra-conservation and that can be considered even worst than being wasteful. Do we really believe IP will still be sufficient at that time for our needs ? > sentiment both in the hallway and in comments made (regularly) at the > microphone. > > But more to the point, the current text in the document actually says: > > There are a number of considerations that factor into address > assignment policies. For example, to provide for the long-term health > and scalability of the public routing infrastructure, it is important > that addresses aggregate well. Likewise, giving out an excessive > amount of address space could result in premature depletion. > > How can you possibly object to the use of the word excessive in the > above context? I think is subjective, as explained above with the perception of what is wasteful and what not from different people. However, as the text say, it is important that addresses aggregate well, so I just noticed that this seems to be in favor of my argument, seems better a balance between more addresses and less "address blocks" (so bigger blocks), while we aren't wasting space, as it helps avoiding future deaggregation. Note I'm not saying that RFC3177 is perfect anymore. > >> A general comment/opinion. I don't think this document should be >> published as is, because it provides a bad message to the market >> about IPv6 assignment recommendations not being stable. I will be in >> favor of a "smaller" revision of RFC3177, not so much disruptive as >> this one, but in the other way around, discouraging /128 and /64 >> assignments. > > As you know, policy proposals to move away from /48 are currently > being discussed in the indvidual RIR regions. Indeed, ARIN has already > adopted one > (http://www.arin.net/policy/proposals/2005_8.html). Publishing this Yes, and ARIN is the only one that approved it at the time being. At least in three other regions, my recall is that has been rejected for further discussion in the list, which will need probably an average of 1 year to be again considered for approval. > document will not stop the registries from moving away from > /48. Indeed, a primary goal is to make it clear that making such a > decision is for the RIRs to make (i.e., to acknowledge reality), and > that from an IPv6 architectural perspective, this is fine. I think we have a disagreement here. It is true that there is not a strict technical reason for using something different than /48 which may affect protocols, however, there are other operational reasons which are of the same relevance. That's why RFC3177 was not mandating, but providing guidelines, and this I believe we still need to keep doing. This is what we do in v6ops and if we don't provide operational guidelines or recommendations or whatever we want to say for "ways to do the things and why, pros/cons", probably, we should not have ops WGs at all. The documents are not just read by RIRs but also by LIRs, enterprises, etc. They need guidelines, and usually they will take their own decisions, but we should not create extra-alarmist perceptions when they aren't proven. > > So, to be clear, do you disagree with the statement that moving from > /48 to /56 is fine from an architectural perspective? If not, please > be specific. Responded above already. Is fine from an architectural perspective, but not from the operational perspective considerations. > > I do agree there are operational issues with having varying prefix > sizes. But that is something that the RIRs need to take into > consideration as they discuss policy proposals. Indeed, this document > tries to make clear that taking into consideration such operational > considerations should be done. Same as above, this is ops WG tasks and "open" suggestions may be even worst than no suggestions at all. > >> I think the motivations behind the /48 are still valid and one of >> the main goals of IPv6 addressing space is to ensure enough space to >> end-users, which is only ensured with a clear boundary >> recommendation. > > It is widely viewed that a /56 to everyone would achieve this > adequately, whereas a /48 is "execessive" to achieve this goal. I've the same trouble with "widely". This is somehow a subjective appreciation. As Ralph suggested, let's make figures for everything and may be we can get an objective view, otherwise, let's try to keep being objective. > >> Furthermore, the lack of a clear boundary disrupts the RFC3177 goal of >> ensuring a consistent subnet to facilitate management and renumbering. In >> practice receiving a new assignment from and ISP w/o a specific >> recommendation will be a big source of troubles if different ISPs decide to >> do different things. Take the case of a user moving from an existing ISP >> with today provides a /48 to a new one. > > The document says this. But in any case, this argument needs to be > taken directly to the RIRs. > >> In addition, as an end user, it provides a recommendation to ISPs to >> provide a reduced service in terms of the number of subnets, instead >> of the actual /48 recommendations (with a clear example for /56), >> which I think is very bad, especially when it is based in a >> subjective view of "excessive". > >> I also think that the lack of clarity in stating that more than a >> single /64 is required in most of the cases is going to be wrongly >> taken as a "go for /64". > > I see no evidence that RIR policies are going in that direction. My No, I was not referring to RIRs here, but to ISPs. > sense (this is based on following and participating in RIR discussions > for the last few years) is that those communities understand very well > that a /64 as default end site allocation unit is neither desirable > nor necessary and that there is plenty of address space to make the > default allocations much larger. But they (even from day one) have > largely viewed a /48 as excessively large. > > Thomas > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jul 13 18:09:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19NE-0005ch-Jd for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 18:09:32 -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 1G11ku-0005If-IQ for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 10:01:28 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G11OA-0007aq-Gs for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 09:38:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11Nu-0009ON-ME for v6ops-data@psg.com; Thu, 13 Jul 2006 13:37:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [32.97.110.153] (helo=e35.co.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G11Nt-0009O5-Vx for v6ops@ops.ietf.org; Thu, 13 Jul 2006 13:37:42 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDbecY027223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 09:37:41 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6DDbeEg122098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jul 2006 07:37:40 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6DDbeJk023543 for ; Thu, 13 Jul 2006 07:37:40 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-223-212.mts.ibm.com [9.65.223.212]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6DDbd6d023488; Thu, 13 Jul 2006 07:37:40 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k6DDarYc006855; Thu, 13 Jul 2006 09:37:04 -0400 Message-Id: <200607131337.k6DDarYc006855@cichlid.raleigh.ibm.com> To: Kurt Erik Lindqvist cc: v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-reply-to: References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> Comments: In-reply-to Kurt Erik Lindqvist message dated "Thu, 13 Jul 2006 00:54:35 +0200." Date: Thu, 13 Jul 2006 09:36:53 -0400 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.4 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Kurt, > > 3. Other RFC 3177 considerations > > > > RFC3177 suggested that some multihoming approaches (e.g., GSE) > > might > > benefit from having a fixed /48 boundary. This no longer appears to > > be a consideration. There is no such requirement coming out of the > > IETF multi6 or shim6 efforts. > I think we can take the last sentence out. Mostly as we are seeing > several parallel solutions being pursued and deployed, such as shim6, > PI space and more specific PAs. So here is the dilemma. I put in this sentence because 3177 argues that /48 might be useful in the context of multihoming/GSE. A while back, I asked multi6 whether this was the case and got a "no" back in response. Pekka (in another thread) complains that this document doesn't address all the points that 3177 did. So, if I take the above out, then what can I (usefully) say about the above point? > I don't believe this should go into the document, Why not? Is it incorrect, or just unnecessary? > but I will also > offer the observation that in some of the RIR regions the end-site > allocation size have impacts on the LIRs relationship to the RIR - > and this 'rule' has the potential for creating artificial complexity > in that area. what do you mean by "this rule"? That there is no longer a fixed /48 can be used? If so, I agree, but the RIRs are already heading in that direction and I view it ias inevitable because we will eventually see end sites that need more than a /48, in which case we have to figure out how to count/measure/justify them. Thomas From owner-v6ops@ops.ietf.org Thu Jul 13 23:07:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1E17-0002Sk-Nd for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 23:07:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1E15-0001hp-Bj for v6ops-archive@lists.ietf.org; Thu, 13 Jul 2006 23:07:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1DyN-000LHw-O9 for v6ops-data@psg.com; Fri, 14 Jul 2006 03:04:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1DyM-000LGP-Rx for v6ops@ops.ietf.org; Fri, 14 Jul 2006 03:04:11 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2006 23:04:10 -0400 X-IronPort-AV: i="4.06,238,1149480000"; d="scan'208"; a="92726048:sNHT25105496" 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 k6E349is027384; Thu, 13 Jul 2006 23:04:09 -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 k6E349dU007456; Thu, 13 Jul 2006 23:04:09 -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, 13 Jul 2006 23:04:09 -0400 Received: from 10.86.240.88 ([10.86.240.88]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 14 Jul 2006 03:04:08 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 13 Jul 2006 23:04:07 -0400 Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt From: Ralph Droms To: , IETF IPv6 Mailing List Message-ID: Thread-Topic: draft-narten-ipv6-3177bis-48boundary-02.txt Thread-Index: Acam8iuTahrSEhLlEdusKgARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jul 2006 03:04:09.0368 (UTC) FILETIME=[2CFC8180:01C6A6F2] DKIM-Signature: a=rsa-sha1; q=dns; l=1801; t=1152846249; x=1153710249; 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=20draft-narten-ipv6-3177bis-48boundary-02.txt |To:,=20IETF=20IPv6=20Mailing=20List=20; X=v=3Dcisco.com=3B=20h=3D0Z6GuA+VOLQ6q92P5KgGf3ix8kM=3D; b=q4CPMZWgOjZY3FanBipWztGtIvUg/AjpJJ2RxCH0W50wsYzK5I3M43hO7ilCNImYXWSfTZd8 yB/iEdBX43hj0vUrmaO2VAvYkDPhSKaawp/dkigvbt8NiY3gHX1zy24c; Authentication-Results: rtp-dkim-1.cisco.com; header.From=rdroms@cisco.com; dkim=pass ( 70 extraneous bytes; sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Within some constraints, the Cisco PD link numbering mechanism actually allows flexibility in the length of the delgated prefix. The CLI allows for concatenation of the delegated prefix with additional bits to form a /64, independent of the length of the delegated prefix. The end result is to logically OR together the prefix and the additional bits to form the /64 assigned to the link. One constraint is, of course, if the delegated prefix is too long and doesn't leave enough room for the additional bits. For example, while 2001:DB8::/48 can be concatenated with 0x16 to form 2001:DB8:0:16/64, if the delegated prefix is a /60, it's not possible to concatenate 2001:DB8::/60 with 0x16 to form a /64. - Ralph On 7/13/06 12:21 PM, "Iljitsch van Beijnum" wrote: > On 12-jul-2006, at 9:30, Thomas Narten wrote: > >> draft-narten-ipv6-3177bis-48boundary-02.txt > [...] > I'd like to offer the way DHCPv6 prefix delegation is implemented in > Cisco routers as an example. Cisco routers are capable of requesting > a prefix over DHCPv6 and then automatically generate addresses for > subnets based on this prefix. However, this requires adding a > specific number of bits, so even though the prefix itself doesn't > appear in a router configuration, its _length_ does. > [...] > Iljitsch van Beijnum > > [1] Another choice would be the all-zeros subnet but if the same is > done with a /48 it would be a shame to use this subnet up for this as > the all-zeros subnet allows for shorter addresses, especially if more > zeros follow. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Fri Jul 14 00:07:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Exf-0005VQ-H6 for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 00:07:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Exe-0005Wr-S4 for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 00:07:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Evr-00055B-Q0 for v6ops-data@psg.com; Fri, 14 Jul 2006 04:05:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,RCVD_IN_SORBS_SMTP,SPF_PASS, UNPARSEABLE_RELAY autolearn=no version=3.1.1 Received: from [199.249.20.2] (helo=pmesmtp02.wcom.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Evp-00054Q-UC for v6ops@ops.ietf.org; Fri, 14 Jul 2006 04:05:38 +0000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J2D00M8ZKPC14@firewall.mci.com> for v6ops@ops.ietf.org; Fri, 14 Jul 2006 04:05:37 +0000 (GMT) Received: from imr1.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQuwxc18703; Fri, 14 Jul 2006 04:05:31 +0000 (GMT) Received: from meno.corp.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: meno.corp.us.uu.net [153.39.146.71]) id k6E45USS009356; Fri, 14 Jul 2006 04:05:30 +0000 (GMT) Received: from localhost by meno.corp.us.uu.net with ESMTP (peer crosschecked as: schiller@localhost) id QQuwxc11988; Fri, 14 Jul 2006 00:05:30 -0400 (EDT) Date: Fri, 14 Jul 2006 00:05:29 -0400 (EDT) From: "Jason Schiller (schiller@uu.net)" Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-reply-to: <7F5FFADC-7DA0-4453-85D2-2F908BBF0D4D@virtualized.org> X-Sender: schiller@meno.corp.us.uu.net To: David Conrad Cc: Thomas Narten , v6ops@ops.ietf.org, ipv6@ietf.org, jordi.palet@consulintel.es, Ralph Droms Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 I would like to echo some comments by David Conrad and Mark Smith. a /48 or 65,536 /64 subnets does seem like an overly large assignment to a residential user. IMHO moving the boundary to a /56 is completely missing the boat on what the actual problem is. We discovered that classful addresses were a mistake and moved to variable length subnet masks. Let's not repeat this mistake by not having variable length subnet masks in ipv6. Now the problem with variable length subnet masks is two fold. First it is important that addresses be given out on CIDR boundaries (which is apparently difficult for some people now that letters are in the address) so that aggeggation can occur. Secondly, as Mark points out how do you strike the right balance between giving a generous amount of space to allow for growth without the addition of non-contiguous space, while not being too generous and ignoring conservation? Can I suggest that the number be based on the expected number of subnets required in some reasonable time period multiplied by some factor to allow for growth. For example, the number of subnets that will be needed in the next 5 years, rounded up to the nearest CIDR boundary, and the doubled. An example of how the math might work is below: I think I might need 9 subnets in the next 5 years: 1. Trusted home network 2. Wired visitor network 3. Wireless 4. Patio / pool LAN 5. Routing infrastructure 6. Internet facing servers 7. House facing servers 8. Home automation appliances 9. Experimentation That rounds up to 16 subnets and doubles up to 32 subnets. That would require 5 bits for subnetting or a /59 I'm not trying to suggest that this is the right number, but rather that we should take this sort of approach. ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller@uu.net UUNET / Verizon jason.schiller@verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Thu, 13 Jul 2006, Mark Smith wrote: > While I do agree that a /48 per site does seem excessive, particularly > for a home user, and would therefore accept the /56 per site argument, > I think it is very important that the balance isn't isn't tipped too far > back towards conservation when it isn't necessary. On Thu, 13 Jul 2006, David Conrad wrote: > Hi, > > Actually, I think Thomas is being very polite here. I believe the > terminology used is more along the lines of "insane", "ridiculous", > "ludicrous", etc. There are also disparaging remarks about the IETF > recreating classfull (or even pre-classfull) addressing and repeating > history. > > Rgds, > -drc > -------- > My opinions are my own and do not necessarily represent the > opinions of any organization I may be a part of. So there. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From owner-v6ops@ops.ietf.org Fri Jul 14 00:23:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1FDQ-00025V-Lz for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 00:23:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1FDP-00037C-D8 for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 00:23:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1FCr-0008F0-2a for v6ops-data@psg.com; Fri, 14 Jul 2006 04:23:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,RCVD_IN_SORBS_SMTP,SPF_PASS, UNPARSEABLE_RELAY autolearn=no version=3.1.1 Received: from [199.249.20.36] (helo=pmesmtp04.mci.com) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1FCq-0008Db-CE for v6ops@ops.ietf.org; Fri, 14 Jul 2006 04:23:12 +0000 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0J2D005ALLERC9@firewall.mci.com> for v6ops@ops.ietf.org; Fri, 14 Jul 2006 04:20:51 +0000 (GMT) Received: from imr0.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQuwxd24116; Fri, 14 Jul 2006 04:20:50 +0000 (GMT) Received: from meno.corp.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: meno.corp.us.uu.net [153.39.146.71]) id k6E4Koxc006473; Fri, 14 Jul 2006 04:20:50 +0000 (GMT) Received: from localhost by meno.corp.us.uu.net with ESMTP (peer crosschecked as: schiller@localhost) id QQuwxd11997; Fri, 14 Jul 2006 00:20:50 -0400 (EDT) Date: Fri, 14 Jul 2006 00:20:49 -0400 (EDT) From: "Jason Schiller (schiller@uu.net)" Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt In-reply-to: <4E2F04FD-B406-4CC7-BAF0-EE0E59F23F1A@muada.com> X-Sender: schiller@meno.corp.us.uu.net To: Iljitsch van Beijnum Cc: Thomas Narten , v6ops@ops.ietf.org, IETF IPv6 Mailing List Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Thu, 13 Jul 2006, Iljitsch van Beijnum wrote: > It > should be stressed that having different prefix sizes in the market > place leads to higher operational cost because moving from one ISP to > another then requires doing more work than just change a fixed number > of high bits in all places where addresses appear in configurations. > > Obviously it's easier to renumber from a small prefix into a larger > one, but if different prefix sizes exist it can't be assumed that the > only movement is from service providers giving out long ones to > service providers giving out shorter ones. If everyone accepts that ipv6 addresses have variable length subnet masks (and everyone has the appropriate tools to handle this) and the RIRs have a reasonably sound definition of what a good justification is for a given size IP block, then I fail to see the value of "classful" addresses. If a customer of ISP 1 adequately justified an ipv6 address with a particular size mask, and then the customer decides to instead purchase service from ISP 2, why wouldn't ISP 2 give out the same size ipv6 block? Granted my two stipulations may create some initial pain, but we seemed to manage it for IPv4, so I suspect we can do the same for ipv6. There will of course need to be some debate over the importance of aggregation versus the importance of efficient use. But we should be able to come up with something reasonably balanced. ___Jason From owner-v6ops@ops.ietf.org Fri Jul 14 01:59:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ghk-0007Z1-UE for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 01:59:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Ghi-00010t-FY for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 01:59:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Gfx-000N0s-Gn for v6ops-data@psg.com; Fri, 14 Jul 2006 05:57:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Gfw-000N0g-PD for v6ops@ops.ietf.org; Fri, 14 Jul 2006 05:57:20 +0000 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2006 01:57:20 -0400 X-IronPort-AV: i="4.06,239,1149480000"; d="scan'208,217"; a="92732696:sNHT42070564" 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 k6E5vKwH024061; Fri, 14 Jul 2006 01:57:20 -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 k6E5vJdU003115; Fri, 14 Jul 2006 01:57:20 -0400 (EDT) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 01:57:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A70A.5DDB1B6A" Subject: IPv6 Benchmarking Date: Fri, 14 Jul 2006 01:57:18 -0400 Message-ID: <3D1C81E7AA3CD64FA20B04D269FEF7F401C9FD26@xmb-rtp-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Benchmarking Thread-Index: AcanCl1/ynQwib9hTYucuXIJaeFWhQ== From: "Chip Popoviciu \(cpopovic\)" To: Cc: "Ahmed Hamza \(ahamza\)" , "Gunter Van de Velde \(gvandeve\)" , "Diego Dugatkin" , "Kine, Bill" X-OriginalArrivalTime: 14 Jul 2006 05:57:19.0907 (UTC) FILETIME=[5E3AEF30:01C6A70A] DKIM-Signature: a=rsa-sha1; q=dns; l=2782; t=1152856640; x=1153720640; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpopovic@cisco.com; z=From:=22Chip=20Popoviciu=20\(cpopovic\)=22=20 |Subject:IPv6=20Benchmarking=20 |To:; X=v=3Dcisco.com=3B=20h=3Df1haviY1Ir5ALgm1+HlluWaJLmU=3D; b=cY18SaniOXENoZNpBiFAPTcnR+7Txg68MRJPeMR9NLOiKdQmgWTsIiKuj0CGhogVXOibizWZ rosQD0/xE3cfV7hth3Lo2+QfTOyFOwyvitnUrcivMTo2GwpExpnNzxqP; Authentication-Results: rtp-dkim-1.cisco.com; header.From=cpopovic@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A70A.5DDB1B6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear v6ops, =20 Thank you for the opportunity offered to bring before you some challenging topics related to IPv6 benchmarking. We believe strongly in the need for IPv6 benchmarking guidelines to help IPv6 deployment planning and we hope to receive advice based on the operational expertise of this WG. As promised during the Wednesday session, here is a pointer to the IPv6 benchmarking draft: =20 http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchmarking-01.t xt =20 Please send us your comments and suggestions, they are very much appreciated. =20 Best Regards, Chip ------_=_NextPart_001_01C6A70A.5DDB1B6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 v6ops,
 
Thank = you for the=20 opportunity offered to bring before you some challenging topics related = to IPv6=20 benchmarking. We believe strongly in the need for IPv6 benchmarking = guidelines=20 to help IPv6 deployment planning and we hope to receive advice based on = the=20 operational expertise of this WG. As promised during the Wednesday = session, here=20 is a pointer to the IPv6 benchmarking draft:
 
http://tools.ietf.org/wg/bmwg/draft-popoviciu-bmwg-ipv6benchma= rking-01.txt
 
Please = send us your=20 comments and suggestions, they are very much = appreciated.
 
Best=20 Regards,
Chip
------_=_NextPart_001_01C6A70A.5DDB1B6A-- From owner-v6ops@ops.ietf.org Fri Jul 14 08:53:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NB1-0003eX-Or for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 08:53:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1NAz-00077d-2P for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 08:53:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1N8N-000Egb-Dg for v6ops-data@psg.com; Fri, 14 Jul 2006 12:51:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [203.59.1.133] (helo=customer-domains.icp-qv1-irony8.iinet.net.au) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1N8L-000EgC-UC for v6ops@ops.ietf.org; Fri, 14 Jul 2006 12:51:06 +0000 Received: from 203-173-22-103.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.22.103]) by customer-domains.icp-qv1-irony8.iinet.net.au with ESMTP; 14 Jul 2006 20:51:00 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,241,1149436800"; d="scan'208"; a="391349740:sNHT16243938" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 864D03FB4; Fri, 14 Jul 2006 22:20:58 +0930 (CST) Date: Fri, 14 Jul 2006 22:20:58 +0930 From: Mark Smith To: "Jason Schiller (schiller@uu.net)" Cc: iljitsch@muada.com, narten@us.ibm.com, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Message-Id: <20060714222058.c880a7ac.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <4E2F04FD-B406-4CC7-BAF0-EE0E59F23F1A@muada.com> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 On Fri, 14 Jul 2006 00:20:49 -0400 (EDT) "Jason Schiller (schiller@uu.net)" wrote: > On Thu, 13 Jul 2006, Iljitsch van Beijnum wrote: > > > It > > should be stressed that having different prefix sizes in the market > > place leads to higher operational cost because moving from one ISP to > > another then requires doing more work than just change a fixed number > > of high bits in all places where addresses appear in configurations. > > > > Obviously it's easier to renumber from a small prefix into a larger > > one, but if different prefix sizes exist it can't be assumed that the > > only movement is from service providers giving out long ones to > > service providers giving out shorter ones. > > If everyone accepts that ipv6 addresses have variable length subnet masks > (and everyone has the appropriate tools to handle this) and the RIRs have > a reasonably sound definition of what a good justification is for a given > size IP block, then I fail to see the value of "classful" addresses. > Go to fixed boundary allocations for end-sites, and _nobody_ needs appropriate tools or processes to validate the sizes of requests from end-sites. The bits we sacrifice in the IPv6 address space to do this would be a cheap cost compared to the ongoing and continual costs of managing variable length assignments to end-sites. If nothing else, hopefully the RIR annual fees would go down, because they'd have less work to do :-) Remember, there is at least 3/4 of the IPv6 address space with nothing at all in it if we really do end up being completely wrong. We've got plenty of IPv6 address bits to "waste" on addressing convenience, as long as we don't blow up any route tables along the way. > If a customer of ISP 1 adequately justified an ipv6 address with a > particular size mask, and then the customer decides to instead purchase > service from ISP 2, why wouldn't ISP 2 give out the same size ipv6 block? > It seems to me that if you abstract that process a bit, the logical conclusion is to just give nearly everybody the same prefix length, and completely eliminate the administrative costs of the justification and validation of the request process. Only the people dealing with the public routing bits of IPv6 addresses have to understand and worry about variable length prefix style address management. I've understood the idea behind the /48 allocation was that it was enough for nearly everybody - only the largest organisations or entities would need shorter prefixes. This seemed to me to be simplicity winning out. I think introducing a second catagory of allocations, namely /56s, for most smaller networks / homes etc, would address that "excessive" criticism, yet still meet well enough a simplicity goal. It would still increase the costs of address management though, as now allowance for, and therefore pre-planning has to take place to cater for the instances where the /56 needs to be increased to a /48. I think it is probably a minimal enough cost to pay to address the "excessive" criticism, although personally I'd prefer that even that address managment cost wasn't incurred at all. However, I think going to variable sized allocations for end-sites is throwing the baby out with the bathwater. It increases addressing administration costs, is much harder to understand for most network administrators, and is much more error prone. I think IPv6 address space is abundant enough and cheap enough that we can just eliminate those IPv4-CIDR-style costs in the most common case, namely the very large majority of end-sites, by just "throwing a bit of address space at it". Regards, Mark. From owner-v6ops@ops.ietf.org Fri Jul 14 09:57:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OAq-00075c-NK for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 09:57:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OAp-0001YN-B2 for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 09:57:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1O8L-000LDu-2Z for v6ops-data@psg.com; Fri, 14 Jul 2006 13:55:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1O8J-000LDY-QH for v6ops@ops.ietf.org; Fri, 14 Jul 2006 13:55:08 +0000 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6EDsduU017587 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Jul 2006 15:54:40 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20060714222058.c880a7ac.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <4E2F04FD-B406-4CC7-BAF0-EE0E59F23F1A@muada.com> <20060714222058.c880a7ac.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <62E8770C-DEDD-4A03-B41E-425B7E71D71C@muada.com> Cc: "Jason Schiller (schiller@uu.net)" , narten@us.ibm.com, v6ops@ops.ietf.org, ipv6@ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Fri, 14 Jul 2006 09:54:54 -0400 To: Mark Smith X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 On 14-jul-2006, at 8:50, Mark Smith wrote: >> If everyone accepts that ipv6 addresses have variable length >> subnet masks >> (and everyone has the appropriate tools to handle this) Actually the SUBNET mask is now pretty much fixed at 64 bits. From RFC 3513: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. I don't think this was the right decision although in practice using someone else isn't a good idea as you're going to run into trouble with stateless autoconfig, especially the wway things are now, but even in some cases if this is changed to accept variable subnet lengths. But we were not talking about subnet sizes, but rather end-user assignment size. > Go to fixed boundary allocations for end-sites, and _nobody_ needs > appropriate tools or processes to validate the sizes of requests from > end-sites. The bits we sacrifice in the IPv6 address space to do this > would be a cheap cost compared to the ongoing and continual costs of > managing variable length assignments to end-sites. Right. Having only a very small number of different assignment sizes makes life much easier for ISPs, because that way, the blocks are interchangeable. If every user gets a tailored prefix size, then ISPs will have more trouble recycling address space that comes back when uses leave. Also, regular users don't have any idea how much they need so it's better to use a standard size that fits most users and only think about a non-standard size for non-standard users. On the other hand, I do see the point that hardcoding prefix sizes especially in standards but also in procedures is likely to come back to bite us in the back at some point. > If nothing else, > hopefully the RIR annual fees would go down, because they'd have less > work to do :-) ++ ! > I've understood the idea behind the /48 allocation was that it was > enough for nearly everybody - only the largest organisations or > entities would need shorter prefixes. This seemed to me to be > simplicity winning out. > I think introducing a second catagory of allocations, namely /56s, for > most smaller networks / homes etc, would address that "excessive" > criticism, yet still meet well enough a simplicity goal. I agree, except that /56 is still too large for small / home networks, and I fear that ISPs will want to skimp even more and give out /64s. And as I said before, individual /64s aren't all that useful in practice. > However, I think going to variable sized allocations for end-sites is > throwing the baby out with the bathwater. It increases addressing > administration costs, is much harder to understand for most network > administrators, and is much more error prone. Agree. There is also the issue that DNS reverse mapping delegations are easier on 4-bit boundaries, although this isn't a big enough issue to be show stopper on its own. From owner-v6ops@ops.ietf.org Fri Jul 14 12:23:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QSG-0000UZ-Cl for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 12:23:52 -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 1G1PVR-0006co-7P for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 11:23:05 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1Osy-0007N5-16 for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 10:43:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1OVY-000Nee-Dl for v6ops-data@psg.com; Fri, 14 Jul 2006 14:19:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1OVX-000NeO-CM for v6ops@ops.ietf.org; Fri, 14 Jul 2006 14:19:07 +0000 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6EEId20017941 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Jul 2006 16:18:40 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4E2F04FD-B406-4CC7-BAF0-EE0E59F23F1A@muada.com> References: <200607121330.k6CDURLm018209@cichlid.raleigh.ibm.com> <4E2F04FD-B406-4CC7-BAF0-EE0E59F23F1A@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6114F4C5-C98C-4473-8FA3-2C8C81F7FF05@muada.com> Cc: Thomas Narten , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Fri, 14 Jul 2006 10:18:54 -0400 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On 13-jul-2006, at 12:21, Iljitsch van Beijnum wrote: >> draft-narten-ipv6-3177bis-48boundary-02.txt After speaking with Thomas shortly in the hallway yesterday I understand that he doesn't feel it's appropriate (anymore) to tell the RIRs what prefix sizes to use. I don't necessarily agree with that, but in the interest of moving forward I suggest that we try to talk about what the IETF is supposed to know about: technical issues. When we agree on those the rest should be easy. :-) Since the assumption until now has been that pretty much everyone would receive a /48, it makes sense to determine whether this is something that the addressing technology as we understand it today can support. In my opinion, that answer is: Assuming the 2000::/3 unicast address space and a reasonable HD ratio target of 80%, it should be possible to support 2^(80% * 45) = 2^36 = 68 billion /48s. Based on this, there is no technical reason to deny anyone a /48. Then there are technical considerations for a minimum size assignment. Today, most end-users connect one or more hosts in their site to the internet through an intermediate device that, amongst other functionality, functions as an IPv4 router. It's reasonable to assume that this situation translates into a scenario in IPv6 where users have a router on their site. This requires at least two subnets: one internal to the site, that hosts connect to, and one used between the user's and ISP's routers. However, there is no requirement that these two subnet prefixes (which should be /64 as per relevant specifications such as RFC 3513) come from a single shorter prefix assigned to the user. This means that the minimum for most users would be a /63 or two /64s. Next: preferred prefix sizes. DNS reverse delegation happens on 4-bit boundaries. It's not easy to draw conclusions from current operational experience with the reverse DNS in IPv6, but it's not unreasonable to assume that more than with IPv4, with IPv6 users will run their own reverse DNS servers. This gives a slight preference towards assignments on 4-bit boundaries. Finally: stable prefix size when changing ISPs. Both for ISPs and end- users it's easier if there is only a small number of prefix sizes in use. This avoids the situation where a user would receive a smaller assignment from a new ISP, making renumbering significantly harder, and for ISPs, simplifies reusing address space reclaimed from users that have left. From owner-v6ops@ops.ietf.org Fri Jul 14 16:32:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1UKw-0007Vl-8A for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 16:32:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1UKv-0000As-Qs for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 16:32:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1UHQ-0007JD-HA for v6ops-data@psg.com; Fri, 14 Jul 2006 20:28:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1UHP-0007Iy-NM for v6ops@ops.ietf.org; Fri, 14 Jul 2006 20:28:55 +0000 Received: from eaglet (127.0.0.1:1968) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 14 Jul 2006 13:28:26 -0700 From: "Tony Hain" To: "'Thomas Narten'" , Cc: "'David Kessens'" , "'Lindqvist Erik Kurt'" , "'Fred Baker'" , Subject: RE: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Fri, 14 Jul 2006 13:28:51 -0700 Message-ID: <00f101c6a784$20068e20$7d06db84@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acalt7MoL3wpVr/fTzq0zkiY85VvQwBnMgQQ In-Reply-To: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Thomas Narten wrote: > FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just > prior to the ID cutoff, and the authors believe it is ready for > publication as an RFC. We are in discussion with the ADs about having > the document shepherded through the IESG as an informational document. > Note that this document would formally replace RFC3177. > > Comments welcome of course! This document is not ready for publication and MUST NOT bypass the WG consensus process. It is effectively an end run around consensus as it suggests in the acknowledgments that it represents RIR discussions, though fails to mention that no consensus exists. It purports to replace RFC 3177, but does so based on arbitrary preferences to placate the hyper-conservation focused few rather than the considered technical arguments in the established architectural recommendation. It does not justify any specific changes in the math that 3177 used to highlight that there are no technical reasons for other end site allocation units. Instead it prefers to use hype and FUD such as 'excessive' and 'premature depletion' without substantiation. This is despite the fact that one of the co-authors own presentations in the referenced RIR discussions shows that without this change current RIR practice would appropriately manage the pool for around 500 years. This is far from 'premature', and is based on IPv4 trends which are gated on host growth rate rather than the IPv6 allocations based on the substantially lower number of subnets. A specific note in the introduction argues that we need the suggested change 'for the long-term health and scalability of the public routing infrastructure' without any reference to the impact that multiplicative expansion and fragmenting the smaller public allocations would have. It should be clear that by following this suggestion the potential to seriously expand the size of and number of fragments in the public routing system far exceeds any value that would be gained from the self stated 'more conservative approach'. In the public RIR discussions there has not been a clear consensus. The suggested conservation is misguided as the bits will be wasted by replacement of the protocol which will occur for other than depletion reasons long before we hit the 500 year mark. It uses the argument of 'waste' by looking at the current end user deployment models rather than recognizing that by opening up the space new deployment options become available. This effort essentially amounts to an attempt to exercise control over what end users are allowed to do by making them beg for each increment of an abundant resource. This document argues that the goals 'could' be met in other ways, but does not justify why they 'need' to be, or even show an assurance that they 'would' be. In fact it recognizes that renumbering subnets is still a serious problem, then suggests in 4.1 that it is no big deal to just limit the network topology to the assumed smaller allocation that would be the result of this document. There is no discussion about the fragmentation that would occur when a network outgrows its original space and would rather push complexity into the global routing system rather than renumber. In section 2 it mentions that multiple prefix management is an issue, suggesting that they all be the same length to reduce complexity, but there is no discussion on how that would occur if providers choose arbitrary allocation sizes. There appears to be an implied 'trust me' that it will all work out and be possible for sites to get the same prefix lengths from different providers. Also in section 2 it mentions in passing that the PTR tree is something to consider, but does not spell out that managing that zone file across multiple parties would be problematic and therefore recommend that forward and reverse delegations be done on a nibble basis. It does provide more at the very end of the summary, but still does not provide guidance on what issues need 'adequate consideration'. Referencing Multi6 & Shim6 seem out of place given that one produced nothing and the other is producing something that is not deployable in real networks where firewalls will kill the connections when the locators are changed. The entire effort is misguided in that 3177 is a recommendation based on architectural balance, while this document is nothing more than ambiguous FUD intended to shift parceling control from the end site network to the ISP/RIR. It is presented under the guise of conservation in the routing system simply to give cover to those that want to deviate from 3177, though in fact it effectively balloons the routing system through fragmentation spread over even more bits. There is no hard and fast boundary, and 3177 makes itself very clear that it is just a recommendation. If the RIRs want to establish a different policy they can, though there is no architectural justification for it. RFC 3177 could use a tune-up, but it is not clear if opening the document is worth the effort. The one thing that is clear is that this document is not a replacement for it in any sense of the word. Tony From owner-v6ops@ops.ietf.org Fri Jul 14 19:52:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1XSB-0000fI-NC for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 19:52:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1XS9-0006dz-AL for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 19:52:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1XPg-000PS7-Ts for v6ops-data@psg.com; Fri, 14 Jul 2006 23:49:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1XPf-000PRk-Ci for v6ops@ops.ietf.org; Fri, 14 Jul 2006 23:49:39 +0000 Received: from [10.255.1.84] (Toronto-HSE-ppp3741082.sympatico.ca [67.68.67.207]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id 4FA7C78C09; Sat, 15 Jul 2006 01:49:36 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <919677DA-DBA4-48EE-B1A1-D4A17E2A390B@kurtis.pp.se> Cc: , Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Sat, 15 Jul 2006 01:49:32 +0200 To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 13 jul 2006, at 23.45, JORDI PALET MARTINEZ wrote: >> First. giving out a /48 to every home network (which today has at >> most >> a handful of machines, which means, one subnet would suffice) is > > Part of the problem is what each of us considers enough, and this > may depend > on knowledge about developments being cooked, which bring the need > of more > than 256 subnets, even if you have only a handful of devices in > each one. I would be happy if I knew about deployments being cooked that required /64 per user, let alone anything more. I still have a hard time imagining what technology will deployed at most sites that _require_ separate subnets, but I am trying to be generous and will accept that a few might be needed. - kurtis - From owner-v6ops@ops.ietf.org Fri Jul 14 19:52:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1XSI-0000gx-21 for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 19:52:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1XSG-0006e5-Q8 for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 19:52:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1XR8-000Pau-7v for v6ops-data@psg.com; Fri, 14 Jul 2006 23:51:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1XR7-000Pad-GW for v6ops@ops.ietf.org; Fri, 14 Jul 2006 23:51:09 +0000 Received: from [10.255.1.84] (Toronto-HSE-ppp3741082.sympatico.ca [67.68.67.207]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id A61A978C39; Sat, 15 Jul 2006 01:51:04 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25C5CC59-7C34-4387-B7D4-AE46CB4ABA6F@kurtis.pp.se> Cc: David Conrad , Thomas Narten , v6ops@ops.ietf.org, ipv6@ietf.org, jordi.palet@consulintel.es, Ralph Droms Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Sat, 15 Jul 2006 01:51:01 +0200 To: Jason Schiller (schiller@uu.net) X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On 14 jul 2006, at 06.05, Jason Schiller (schiller@uu.net) wrote: > IMHO moving the boundary to a /56 is completely missing the boat on > what > the actual problem is. We discovered that classful addresses were a > mistake and moved to variable length subnet masks. Let's not > repeat this > mistake by not having variable length subnet masks in ipv6. Agreed! > That rounds up to 16 subnets and doubles up to 32 subnets. That would > require 5 bits for subnetting or a /59 > > I'm not trying to suggest that this is the right number, but rather > that > we should take this sort of approach. I actually think that is a policy to be determined by the RIRs... - kurtis - From owner-v6ops@ops.ietf.org Fri Jul 14 20:03:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Xcr-0001dj-LX for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 20:03:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Xcq-0007CQ-9a for v6ops-archive@lists.ietf.org; Fri, 14 Jul 2006 20:03:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Xc1-0000w7-HH for v6ops-data@psg.com; Sat, 15 Jul 2006 00:02:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [203.59.1.195] (helo=mail-ihug.icp-qv1-irony1.iinet.net.au) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1Xbz-0000vr-P2 for v6ops@ops.ietf.org; Sat, 15 Jul 2006 00:02:24 +0000 Received: from 203-173-22-103.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.22.103]) by mail-ihug.icp-qv1-irony1.iinet.net.au with ESMTP; 15 Jul 2006 08:02:21 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,245,1149436800"; d="scan'208"; a="563220152:sNHT17654644" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 3FA1B3FB4; Sat, 15 Jul 2006 09:32:16 +0930 (CST) Date: Sat, 15 Jul 2006 09:32:13 +0930 From: Mark Smith To: Iljitsch van Beijnum Cc: jason.schiller@mci.com, narten@us.ibm.com, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Message-Id: <20060715093213.28cb988a.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <62E8770C-DEDD-4A03-B41E-425B7E71D71C@muada.com> References: <4E2F04FD-B406-4CC7-BAF0-EE0E59F23F1A@muada.com> <20060714222058.c880a7ac.ipng@69706e6720323030352d30312d31340a.nosense.org> <62E8770C-DEDD-4A03-B41E-425B7E71D71C@muada.com> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi Iljitsch, On Fri, 14 Jul 2006 09:54:54 -0400 Iljitsch van Beijnum wrote: > I agree, except that /56 is still too large for small / home > networks, and I fear that ISPs will want to skimp even more and give > out /64s. I'd think the market would sort that out very quickly - if I'm choosing an ISP for my home, and one gives out /56s, and another gives out a /64 (and then charges more for that /64 because they also are having to manage the option of providing /56s and /48s), then I'm going to go for the option that is likely to cause me the least potential administrative hassle in the future. I think it is inconceivable I'd every use up 256 subnets at home (and hey, I'm a networking person, so I'd probably willing to spend time getting around this limitation if I hit it by going to /80s for my subnets), so the /56 option is more attractive as I'd never hit it. Even people who don't understand the technical differences will pursue the /56 option, because people will always go for more "bangs per buck", even if they're unsure of exactly what the "bangs" are, as long as somebody tells them more "bangs" are useful to have even if you don't ever use them. The /48 option also is provides an "inconceivable" subnet limit. What it does though, when compared with the /56 option, is pushes that boundary of inconceivability to be inclusive of almost every potential IPv6 user out there, elminating the costs of dealing with running out of subnets for almost everybody. For those who are likely to hit a subnet limitation with a /48, I'm pretty sure they'll be smart enough to recognise that from day one, and request the enough address space they'll need before they need it. > And as I said before, individual /64s aren't all that > useful in practice. > > > However, I think going to variable sized allocations for end-sites is > > throwing the baby out with the bathwater. It increases addressing > > administration costs, is much harder to understand for most network > > administrators, and is much more error prone. > > Agree. There is also the issue that DNS reverse mapping delegations > are easier on 4-bit boundaries, although this isn't a big enough > issue to be show stopper on its own. True. Simplicity in DNS reverse mapping is another benefit of "throwing addressing bits" at the problem. Regards, Mark. From owner-v6ops@ops.ietf.org Sat Jul 15 09:34:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1kHx-0002C5-8w for v6ops-archive@lists.ietf.org; Sat, 15 Jul 2006 09:34:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1kHu-00075p-Tv for v6ops-archive@lists.ietf.org; Sat, 15 Jul 2006 09:34:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1kFK-000Lxe-Qi for v6ops-data@psg.com; Sat, 15 Jul 2006 13:31:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1kFI-000LxP-3Y for v6ops@ops.ietf.org; Sat, 15 Jul 2006 13:31:48 +0000 Received: from [172.16.1.2] (82-192-90-30.leasedsl.net [82.192.90.30]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6FDVLYR041204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 15 Jul 2006 15:31:22 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55389B99-07CF-47AD-A00F-B4B941058519@muada.com> Cc: "IETF IPv6 Mailing List" , Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Sat, 15 Jul 2006 15:31:31 +0200 To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On 14-jul-2006, at 21:05, Manfredi, Albert E wrote: [...] > On this point, unless you're speaking of NATs (which I though would be > discouraged with v6), doesn't it make a lot of sense to use the same > address prefix to reach the subnet outside and inside the home router? Huh??? I have no idea how you got from my message to having the same prefix both on the inside and the outside. From owner-v6ops@ops.ietf.org Sat Jul 15 19:03:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1tAJ-0004xg-71 for v6ops-archive@lists.ietf.org; Sat, 15 Jul 2006 19:03:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1tAH-0002ui-VC for v6ops-archive@lists.ietf.org; Sat, 15 Jul 2006 19:03:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1t5v-000LsY-GB for v6ops-data@psg.com; Sat, 15 Jul 2006 22:58:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G1t5s-000LsF-W5 for v6ops@ops.ietf.org; Sat, 15 Jul 2006 22:58:41 +0000 Received: from eaglet (127.0.0.1:3812) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Sat, 15 Jul 2006 15:58:12 -0700 From: "Tony Hain" To: "'Kurt Erik Lindqvist'" , Cc: , Subject: RE: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Sat, 15 Jul 2006 15:58:37 -0700 Message-ID: <020401c6a862$35687f60$7d06db84@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcanoDFH+45NcKk3RRiubIzdVRePFwAwSDXw In-Reply-To: <919677DA-DBA4-48EE-B1A1-D4A17E2A390B@kurtis.pp.se> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Kurt Erik Lindqvist wrote: > ... > I would be happy if I knew about deployments being cooked that > required /64 per user, let alone anything more. I still have a hard > time imagining what technology will deployed at most sites that > _require_ separate subnets, but I am trying to be generous and will > accept that a few might be needed. You appear to be focused on number of devices. Think different media types. There is no reason that any new media type should be stuck with 25 year old framing technology. We get there by default now because multi-media bridging is known to be broken and to date routing has been too hard. There is nothing really magic about local routing though so it is reasonable to conclude that over the 500+ year lifetime we expect for IPv6 that differing media types will arrive with framing that is better routed than bridged, and that trivial management of local routing for structured topologies will appear. Tony From owner-v6ops@ops.ietf.org Sun Jul 16 09:08:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G26M7-0001h7-Gk for v6ops-archive@lists.ietf.org; Sun, 16 Jul 2006 09:08:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G26M6-0002Xq-6h for v6ops-archive@lists.ietf.org; Sun, 16 Jul 2006 09:08:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G26JP-0005AS-1G for v6ops-data@psg.com; Sun, 16 Jul 2006 13:05:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [204.9.221.19] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G26JO-0005AG-8W for v6ops@ops.ietf.org; Sun, 16 Jul 2006 13:05:30 +0000 Received: from [66.30.121.250] (account margaret HELO [192.168.2.3]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1114991; Sun, 16 Jul 2006 09:05:29 -0400 In-Reply-To: <20060713192928.GA28229@login.ecs.soton.ac.uk> References: <005b01c6a6af$9d013ef0$7d06db84@tndh.net> <20060713192928.GA28229@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Margaret Wasserman Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Sun, 16 Jul 2006 09:05:12 -0400 To: Tim Chown X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d You might also want to note that Duplicate Address Detection (DAD) will not work on the logical subnet(s). I realize that DAD doesn't find collisions very frequently in the case of auto-generated addresses, but the logical addresses will not be autoconfigured from RAs. If they are manually configured, extra care needs to be taken because of the lack of DAD. Margaret On Jul 13, 2006, at 3:29 PM, Tim Chown wrote: > On Thu, Jul 13, 2006 at 12:07:39PM -0700, Tony Hain wrote: >> >> Subnet local multicast to a collection of nodes that are scattered >> makes no >> technical sense, but you are correct there is nothing in the >> document that >> talks about the issue. If someone could suggest text I would >> appreciate it, >> but I will see what I can do to identify the point. > > I think this is a very good point. Clarification of use of multicast > would be appreciated. > > Tim > From owner-v6ops@ops.ietf.org Sun Jul 16 10:28:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G27bQ-0008Sq-Af for v6ops-archive@lists.ietf.org; Sun, 16 Jul 2006 10:28:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G27bP-0004cN-2l for v6ops-archive@lists.ietf.org; Sun, 16 Jul 2006 10:28:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G27ZZ-000AAa-Rl for v6ops-data@psg.com; Sun, 16 Jul 2006 14:26:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G27ZZ-000AAK-2g for v6ops@ops.ietf.org; Sun, 16 Jul 2006 14:26:17 +0000 Received: from eaglet (127.0.0.1:2209) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Sun, 16 Jul 2006 07:25:46 -0700 From: "Tony Hain" To: "'Margaret Wasserman'" , "'Tim Chown'" Cc: Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Sun, 16 Jul 2006 07:26:11 -0700 Message-ID: <025201c6a8e3$ca35bdc0$7d06db84@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acao2SWrVUEcIM7eRgOEoihh/kaBGQACK1Ng In-Reply-To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Margaret Wasserman wrote: > You might also want to note that Duplicate Address Detection (DAD) > will not work on the logical subnet(s). I realize that DAD doesn't > find collisions very frequently in the case of auto-generated > addresses, but the logical addresses will not be autoconfigured from > RAs. If they are manually configured, extra care needs to be taken > because of the lack of DAD. The device would run DAD on the link it is attached to, but you are correct that is not going to cover the logical subnet. If it seems necessary and within scope I could put in a comment about listening to the IGP before announcing to see if the address already exists for that case, then for the MIPv6 case the HA already detects duplicates and denies the binding. Tony From owner-v6ops@ops.ietf.org Mon Jul 17 03:08:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2NDM-00075r-FE for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 03:08:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2NDK-0003TH-W5 for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 03:08:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2NAI-0009Zu-9K for v6ops-data@psg.com; Mon, 17 Jul 2006 07:05:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48,SPF_PASS autolearn=no version=3.1.1 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2NAH-0009ZR-Co for v6ops@ops.ietf.org; Mon, 17 Jul 2006 07:05:13 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.7/8.13.7) with ESMTP id k6H7563l129004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Jul 2006 07:05:08 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6H76e4J118420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jul 2006 08:06:40 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6H7545k025237 for ; Mon, 17 Jul 2006 08:05:05 +0100 Received: from mail-gw3.hursley.ibm.com (mail-gw3.hursley.ibm.com [9.20.131.251]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6H754e6025233; Mon, 17 Jul 2006 08:05:04 +0100 Received: from [9.20.118.16] (helo=bf1v5-118.hursley.ibm.com) by mail-gw3.hursley.ibm.com with esmtp (Exim 4.50) id 1G2NA8-0001BT-Ho; Mon, 17 Jul 2006 08:05:04 +0100 Received: from zurich.ibm.com (sig-9-146-221-53.de.ibm.com [9.146.221.53]) by bf1v5-118.hursley.ibm.com (AIX5.3/8.11.6p2/8.11.0) with SMTP id k6H74v53801168; Mon, 17 Jul 2006 08:04:59 +0100 Message-ID: <44B95FED.50207@zurich.ibm.com> Date: Sat, 15 Jul 2006 23:36:45 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: Iljitsch van Beijnum , Kurt Erik Lindqvist , "Azinger, Marla" , Christian Huitema , Marc Blanchet , v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters References: <10ECB7F03C568F48B9213EF9E7F790D202100D6C@wava00s2ke2k01.corp.pvt> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Pekka Savola wrote: > On Sun, 9 Jul 2006, Iljitsch van Beijnum wrote: > >> Except for the people who were now filtered with no prior warning and >> no recourse. The IETF can't and shouldn't want to mandate how people >> run their networks, but things work a lot better if there is consensus >> about the parameters within which everyone applies their own judgement. > > > You seem to have the assumption that it is possible to come to a > consensus (with a reasonable time and energy investment) that satisfies > the stakeholders. > > I'm almost certain it won't be possible, hence I'm rather skeptical > about wasting time in trying. So, I'm advocating that we should aim for > a trade-off document instead if we really want to do something here and > if we by some miracle happen to get to consensus, even better.. :-) > >> You may be right, but my reasoning is: the most common IPv4 practice >> (filter at /24) doesn't translate to IPv6, everyone doing their own >> thing is suboptimal, and there doesn't seem to be another forum to >> decide on this, ergo the IETF should step up. > > > Yes, the IETF has been known of its exercises in futility in the past so > one more time won't hurt... ;-( I suspect that the IETF could conceivably produce a document saying "if you build a network of size X and with a range of filtering policies between Y and Z, we think the following might be the impact on route table growth and convergence times." But that might make a better SIGCOMM paper than an RFC. Brian From owner-v6ops@ops.ietf.org Mon Jul 17 03:08:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2NDU-000763-5J for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 03:08:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2NDS-0003TR-RU for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 03:08:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2NAP-0009aQ-FC for v6ops-data@psg.com; Mon, 17 Jul 2006 07:05:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48,SPF_PASS autolearn=no version=3.1.1 Received: from [195.212.29.138] (helo=mtagate5.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2NAE-0009Yr-AO for v6ops@ops.ietf.org; Mon, 17 Jul 2006 07:05:10 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.13.7/8.13.7) with ESMTP id k6H757oE084234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Jul 2006 07:05:08 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6H76fNk067608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jul 2006 08:06:41 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6H756Lo028765 for ; Mon, 17 Jul 2006 08:05:06 +0100 Received: from mail-gw3.hursley.ibm.com (mail-gw3.hursley.ibm.com [9.20.131.251]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6H7566L028756; Mon, 17 Jul 2006 08:05:06 +0100 Received: from [9.20.118.16] (helo=bf1v5-118.hursley.ibm.com) by mail-gw3.hursley.ibm.com with esmtp (Exim 4.50) id 1G2NAA-0001BW-0n; Mon, 17 Jul 2006 08:05:06 +0100 Received: from zurich.ibm.com (sig-9-146-221-53.de.ibm.com [9.146.221.53]) by bf1v5-118.hursley.ibm.com (AIX5.3/8.11.6p2/8.11.0) with SMTP id k6H75453772632; Mon, 17 Jul 2006 08:05:04 +0100 Message-ID: <44B962E2.8020809@zurich.ibm.com> Date: Sat, 15 Jul 2006 23:49:22 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: Thomas Narten , v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt References: <200607121326.k6CDQRl1018072@cichlid.raleigh.ibm.com> <200607131348.k6DDmpDR006993@cichlid.raleigh.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ... > > It is not clear to me why the arguments for a fixed boundary have been > removed. I accept that there is no IETF architectural issue whether the > size is /48, /56 or whatever, Having had a lot to do with the text of 3177, I have been reluctantly forced to the conclusion that those arguments have been overtaken by events. I think the drafts explains why, too. And the draft doesn't need to explain why its arguments are somewhat vague instead of being firm recommmendations - it really isn't in the IETF's scope to make such recommendations, now that the IPv6 unicast space is being administered by the RIRs. I'm personally sorry to see /48 not applied universally but that bus has left. Brian From owner-v6ops@ops.ietf.org Mon Jul 17 03:08:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2NDc-00076y-7H for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 03:08:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2NDa-0003Tg-TZ for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 03:08:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2NAG-0009ZI-0f for v6ops-data@psg.com; Mon, 17 Jul 2006 07:05:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48,SPF_PASS autolearn=no version=3.1.1 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2NAC-0009Yo-TL for v6ops@ops.ietf.org; Mon, 17 Jul 2006 07:05:09 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.7/8.13.7) with ESMTP id k6H74v6l083740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Jul 2006 07:04:57 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6H76WtP117706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Jul 2006 08:06:32 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6H74vO4024956 for ; Mon, 17 Jul 2006 08:04:57 +0100 Received: from mail-gw3.hursley.ibm.com (mail-gw3.hursley.ibm.com [9.20.131.251]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6H74vwE024950; Mon, 17 Jul 2006 08:04:57 +0100 Received: from [9.20.118.16] (helo=bf1v5-118.hursley.ibm.com) by mail-gw3.hursley.ibm.com with esmtp (Exim 4.50) id 1G2NA1-0001Au-2Y; Mon, 17 Jul 2006 08:04:57 +0100 Received: from zurich.ibm.com (sig-9-146-221-53.de.ibm.com [9.146.221.53]) by bf1v5-118.hursley.ibm.com (AIX5.3/8.11.6p2/8.11.0) with SMTP id k6H74s53833936; Mon, 17 Jul 2006 08:04:55 +0100 Message-ID: <44B95E3C.50902@zurich.ibm.com> Date: Sat, 15 Jul 2006 23:29:32 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tony Hain CC: "'Margaret Wasserman'" , v6ops@ops.ietf.org Subject: Re: Review of draft-ietf-v6ops-nap-02.txt References: <005b01c6a6af$9d013ef0$7d06db84@tndh.net> In-Reply-To: <005b01c6a6af$9d013ef0$7d06db84@tndh.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ... >> >>One of the problems with NAT, at least from my perspective, is that >>they require a split-DNS employment to get local name resolution. >>Are we expecting that NAP will have that same property? > > > Split-DNS would make the non-local case more efficient, but it is not a hard > requirement like it is with IPv4/nat. Given that enterprises have nodes that > they don't want the world to know about they are likely to be running some > form of split-DNS anyway, so I don't see this as a big deal either way. > Personal opinion: in enterprise network deployments, split DNS is as likely to go away as firewalls. If an enterprise has internal servers that it wishes to hide from the outside world, split DNS is inevitable. As Tony says, NAP will work without it (i.e. if a ULA appears in global DNS, it will be unrouteable) but I bet it will be as widespread in IPv6 as it is for IPv4. Brian From owner-v6ops@ops.ietf.org Mon Jul 17 06:30:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2QMj-00005e-Lv for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 06:30:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2QMi-0001yx-5L for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 06:30:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2QK2-000NEx-D5 for v6ops-data@psg.com; Mon, 17 Jul 2006 10:27:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2QK1-000NEh-5W for v6ops@ops.ietf.org; Mon, 17 Jul 2006 10:27:29 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2006 03:27:29 -0700 X-IronPort-AV: i="4.06,249,1149490800"; d="scan'208,217"; a="329397378:sNHT38098584" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6HARSup019262; Mon, 17 Jul 2006 03:27:28 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6HARSJi029631; Mon, 17 Jul 2006 03:27:28 -0700 (PDT) Received: from evyncke-wxp01.cisco.com (ams-evyncke-vpn7.cisco.com [10.55.1.168]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id k6HALB5T002539; Mon, 17 Jul 2006 03:21:13 -0700 Message-Id: <5.1.0.14.2.20060717120347.03933940@email.cisco.com> X-Sender: evyncke@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Jul 2006 12:27:10 +0200 To: "Pekka Savola" From: Eric Vyncke Subject: Re: Remove tunnel mode from ipsec-tunnels-02? Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_587652796==_.ALT" Authentication-Results: sj-dkim-2.cisco.com; header.From=evyncke@cisco.com; dkim=pass ( 53 extraneous bytes; sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=5689; t=1153132048; x=1153996048; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=evyncke@cisco.com; z=From:Eric=20Vyncke=20 |Subject:Re=3A=20Remove=20tunnel=20mode=20from=20ipsec-tunnels-02?; X=v=3Dcisco.com=3B=20h=3Dya81CPA8oQodTq5xpeBIJsSyC4M=3D; b=fBnzTQIkFpQMnvDZD6v0DINxjzFc52gR6H71/25WTkLDU5OIb4lL86wzPUaephBK/zdyaLuM h3p0QASLEbb6d2TiEMTskRLSDxXBfV4xbjSsRFjsRlBJe/6SePRhSEPW; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 --=====================_587652796==_.ALT Content-Type: text/plain; charset="us-ascii" Pekka, I know about no implementation supporting IPv6 selectors (like ::/0) over an IPv4 IKE/IPsec... So, this IPsec tunnel mode of IPv6 over IPv4 could be dropped for clarity sake. The most common (i.e. the one I'm using at home between routers) is indeed transport mode (selector IPv4 addresses & protocol=41). NOTE: as a lot of 'remote access IPsec client' are actually using IPsec tunnel mode (typically selector 0.0.0.0/0), i.e., encrypting all IPv4 packets including protocol 41. So, this is a valid use of IPsec in tunnel mode for secure IPv6 tunnels. (this is actually double tunnels...). So, we may still want to keep a 'tunnel mode' IPsec for reality sake. Just re-read the whole I-D in the same shot and have one further comment (as they are late, please feel free to drop them). BTW, its recent text additions are excellent. 2.2: outer IPv4 spoofing is not a threat, the wording is accurate but should stress that an attacker trying to inject packets in the IPv6 tunnels will go nowhere: all his/her packets will fail the decryption part and will be rejected. Hope it helps -eric At 16:19 12/07/2006 +0200, Pekka Savola wrote: >Hello, > >As proposed at the v6ops meeting [0], the authors of >draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel >mode in this particular context (securing v6-in-v4 configured >tunnels). > >This is due to issues spotted by Francis [1] and Pasi [2]. Generic >"::/0 -> ::/0" selectors could not be made to work without >interface-specific SPDs, and those cannot be signalled in IKE (that's >run on top of IPv4) when the tunnel would be IPv6 in a standardized >way. Generic selectors are required for link-local traffic (e.g., ND) >to work on the tunnel. > >If we go through with this proposed resolution, >draft-ietf-v6ops-ipsec-tunnels would only describe transport mode. > >Comments are welcome. > >[0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf >[1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html >[2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html > >For the authors of draft-ietf-v6ops-ipsec-tunnels-02, > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=====================_587652796==_.ALT Content-Type: text/html; charset="us-ascii" Pekka,

I know about no implementation supporting IPv6 selectors (like ::/0) over an IPv4 IKE/IPsec... So, this IPsec tunnel mode of IPv6 over IPv4 could be dropped for clarity sake.

The most common (i.e. the one I'm using at home between routers) is indeed transport mode (selector IPv4 addresses & protocol=41).

NOTE: as a lot of 'remote access IPsec client' are actually using IPsec tunnel mode (typically selector 0.0.0.0/0), i.e., encrypting all IPv4 packets including protocol 41. So, this is a valid use of IPsec in tunnel mode for secure IPv6 tunnels. (this is actually double tunnels...). So, we may still want to keep a 'tunnel mode' IPsec for reality sake.

Just re-read the whole I-D in the same shot and have one further comment (as they are late, please feel free to drop them). BTW, its recent text additions are excellent.

2.2: outer IPv4 spoofing is not a threat, the wording is accurate but should stress that an attacker trying to inject packets in the IPv6 tunnels will go nowhere: all his/her packets will fail the decryption part and will be rejected.

Hope it helps

-eric


At 16:19 12/07/2006 +0200, Pekka Savola wrote:

Hello,

As proposed at the v6ops meeting [0], the authors of
draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel
mode in this particular context (securing v6-in-v4 configured
tunnels).

This is due to issues spotted by Francis [1] and Pasi [2].  Generic
"::/0 -> ::/0" selectors could not be made to work without
interface-specific SPDs, and those cannot be signalled in IKE (that's
run on top of IPv4) when the tunnel would be IPv6 in a standardized
way.  Generic selectors are required for link-local traffic (e.g., ND)
to work on the tunnel.

If we go through with this proposed resolution,
draft-ietf-v6ops-ipsec-tunnels would only describe transport mode.

Comments are welcome.

[0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf
[1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html
[2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html

For the authors of draft-ietf-v6ops-ipsec-tunnels-02,

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=====================_587652796==_.ALT-- From owner-v6ops@ops.ietf.org Mon Jul 17 12:00:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2VWZ-0005me-V3 for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 12:00:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2VWX-0002eP-K8 for v6ops-archive@lists.ietf.org; Mon, 17 Jul 2006 12:00:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2VPe-000LTS-0G for v6ops-data@psg.com; Mon, 17 Jul 2006 15:53:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [130.76.96.56] (helo=stl-smtpout-01.ns.cs.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G2VPc-000LSd-QU for v6ops@ops.ietf.org; Mon, 17 Jul 2006 15:53:36 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k6HFrZ91009006; Mon, 17 Jul 2006 10:53:35 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k6HFrYw09964; Mon, 17 Jul 2006 08:53:34 -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, 17 Jul 2006 08:53:32 -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 Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Mon, 17 Jul 2006 08:53:31 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177412A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <44B95E3C.50902@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-v6ops-nap-02.txt Thread-Index: AcapceauDJF17tNJQM2VkmoGkpQfGAARjrsw From: "Templin, Fred L" To: "Brian E Carpenter" , "Tony Hain" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 17 Jul 2006 15:53:32.0628 (UTC) FILETIME=[27AC3940:01C6A9B9] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa On split-DNS, I have been studying address configuration in a different context lately (NETLMM wg) and am leaning toward a model in which nodes within an enterprise would use global addresses only for communications with nodes in other enterprises and would use ULAs for communications with nodes in the same enterprise. So, that would automatically imply split-DNS. Would that be a problem? Fred fred.l.templin@boeing.com =20 -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 Sent: Saturday, July 15, 2006 2:30 PM To: Tony Hain Cc: 'Margaret Wasserman'; v6ops@ops.ietf.org Subject: Re: Review of draft-ietf-v6ops-nap-02.txt ... >> >>One of the problems with NAT, at least from my perspective, is that >>they require a split-DNS employment to get local name resolution. >>Are we expecting that NAP will have that same property? >=20 >=20 > Split-DNS would make the non-local case more efficient, but it is not a hard > requirement like it is with IPv4/nat. Given that enterprises have nodes that > they don't want the world to know about they are likely to be running some > form of split-DNS anyway, so I don't see this as a big deal either way. >=20 Personal opinion: in enterprise network deployments, split DNS is as likely to go away as firewalls. If an enterprise has internal servers that it wishes to hide from the outside world, split DNS is inevitable. As Tony says, NAP will work without it (i.e. if a ULA appears in global DNS, it will be unrouteable) but I bet it will be as widespread in IPv6 as it is for IPv4. Brian From owner-v6ops@ops.ietf.org Wed Jul 19 11:40:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EAR-00021b-Lu for v6ops-archive@lists.ietf.org; Wed, 19 Jul 2006 11:40:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EAQ-00045L-50 for v6ops-archive@lists.ietf.org; Wed, 19 Jul 2006 11:40:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3E70-0002Ir-BN for v6ops-data@psg.com; Wed, 19 Jul 2006 15:37:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3E6y-0002IT-Jy for v6ops@ops.ietf.org; Wed, 19 Jul 2006 15:37:21 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.7/8.13.7) with ESMTP id k6JFbITF163256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 19 Jul 2006 15:37:18 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6JFeO2S143398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 19 Jul 2006 17:40:24 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6JFbHMD001030 for ; Wed, 19 Jul 2006 17:37:17 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6JFbHe2001022 for ; Wed, 19 Jul 2006 17:37:17 +0200 Received: from zurich.ibm.com (sig-9-145-249-235.de.ibm.com [9.145.249.235]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA38780 for ; Wed, 19 Jul 2006 17:37:16 +0200 Message-ID: <44BE51AA.5010209@zurich.ibm.com> Date: Wed, 19 Jul 2006 17:37:14 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-addcon-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 > 2.4.2. Address Space Conservation > > Despite the large IPv6 address space which enables easier subnetting, > it still is important to ensure an efficient use of this resource. > Some addressing schemes, while facilitating aggregation and > management, could lead to significant numbers of addresses being > unused. Address conservation requirements are less stringent in IPv6 > but they should still be observed. > > The proposed HD [8] value for IPv6 is 0.94 compared to the current > value of 0.96 for IPv4. Note that for IPv6 HD is calculated for > sites (i.e. on a basis of /48), instead of based on addresses like > with IPv4. Perhaps it would be wiser to make the parenthesis (e.g. on a basis of /48) Thanks for adding the ISP case. Some comments... > 5.2.1.2. IPv6 addressing schema requirements from the ISP perspective > of the Service Provider > > From ISP perspective the following basic requirements could be > identified: > o The IPv6 address allocation schema must be able to realize a > maximal aggregation of all IPv6 address delegations to customers > into the /20 of the Service Provider. Only this /20 will be > routed and injected from the Service Provider into the global > routing table (DFZ). This strong aggregation keeps the routing > tables of the DFZ small and eases filtering and access control > very much. (Note: A strong aggregation e.g. on POP or LER basis > limits as well the numbers of customer routes that are visible > within the ISP network.) I'm quite concerned by this. Basically, why? Are we really expecting ISPs to have so many customer sites that they can't simply flat-route internally? Yes, that may be slightly less attractive for an MPLS based ISP rather than for one using IP routing, but it has horrible consequences because of the way it constrains address assignment. > 5.2.1.3. IPv6 addressing schema requirements from the Network Access > provider perspective of the Service Provider > > As already done for the LIR and the ISP roles of the SP it is also > necessary to identify requirements that come from its Network Access > Provider role. Some of the basic requirements are: > o The IPv6 addressing schema of the SP must be flexible enough to > adapt changes that are injected from the customer side. This > covers changes that are based on the raising IPv6 address needs of > the customer as well as changes that come from topological > modifications (e.g. when the customer moves from one point of > network attachment (POP) to another). I don't understand "changes that are injected from the customer side." Does this mean injected by a routing protocol? What sort of flexibility do you mean? And when a customer changes POP, well, see my previous comment. That should just be a routing change. > 5.2.2.1.1. 'Big' customers Really big customers with many sites and an internal network will be connected at multiple POPs. You don't discuss this case. Again, it breaks the idea that customer address space can be aggregated by POP topology. Brian From owner-v6ops@ops.ietf.org Wed Jul 19 11:51:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EL7-0006U6-Pt for v6ops-archive@lists.ietf.org; Wed, 19 Jul 2006 11:51:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3EL3-00053Z-Oi for v6ops-archive@lists.ietf.org; Wed, 19 Jul 2006 11:51:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3EK5-0003zo-Lp for v6ops-data@psg.com; Wed, 19 Jul 2006 15:50:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [203.178.142.146] (helo=mail.sfc.wide.ad.jp) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3EK2-0003yf-GC for v6ops@ops.ietf.org; Wed, 19 Jul 2006 15:50:50 +0000 Received: from h0a91-net84db.lab.risq.net (unknown [IPv6:2001:660:f183:3:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1BACE4D8C2 for ; Thu, 20 Jul 2006 00:50:47 +0900 (JST) Date: Wed, 19 Jul 2006 17:49:50 +0200 From: Thierry Ernst To: v6ops@ops.ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Message-Id: <20060719174950.31e995cf.ernst@sfc.wide.ad.jp> In-Reply-To: <919677DA-DBA4-48EE-B1A1-D4A17E2A390B@kurtis.pp.se> References: <919677DA-DBA4-48EE-B1A1-D4A17E2A390B@kurtis.pp.se> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi, What about this one: vehicles will not embed one but probably a couple of IP subnets. One subnet will be used for vehicle-related control traffic, and another one for multimedia. Once this comes into the assembly line, such vehicles will come by millions. I guess the same will happen for home networking, with one segment for multimedia and one to control windows, light switches, etc. Thierry On Sat, 15 Jul 2006 01:49:32 +0200 Kurt Erik Lindqvist wrote: > > On 13 jul 2006, at 23.45, JORDI PALET MARTINEZ wrote: > > >> First. giving out a /48 to every home network (which today has at > >> most > >> a handful of machines, which means, one subnet would suffice) is > > > > Part of the problem is what each of us considers enough, and this > > may depend > > on knowledge about developments being cooked, which bring the need > > of more > > than 256 subnets, even if you have only a handful of devices in > > each one. > > I would be happy if I knew about deployments being cooked that > required /64 per user, let alone anything more. I still have a hard > time imagining what technology will deployed at most sites that > _require_ separate subnets, but I am trying to be generous and will > accept that a few might be needed. > > - kurtis - -- Thierry ERNST, PhD http://www.nautilus6.org/~thierry IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair -- INRIA Rocquencourt Project-Team IMARA, France. +33 1 39 63 59 30 (office) From owner-v6ops@ops.ietf.org Thu Jul 20 04:54:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3UIm-0001rG-7o for v6ops-archive@lists.ietf.org; Thu, 20 Jul 2006 04:54:36 -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 1G3T0S-0008AJ-QP for v6ops-archive@lists.ietf.org; Thu, 20 Jul 2006 03:31:36 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3SnS-00049O-5s for v6ops-archive@lists.ietf.org; Thu, 20 Jul 2006 03:18:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Skd-0008ab-OX for v6ops-data@psg.com; Thu, 20 Jul 2006 07:15:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48,FORGED_RCVD_HELO,RCVD_IN_WHOIS_INVALID, SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Skc-0008aB-2w for v6ops@ops.ietf.org; Thu, 20 Jul 2006 07:15:14 +0000 Received: from [172.31.65.202] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50001943019.msg for ; Thu, 20 Jul 2006 09:12:37 +0200 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Tue, 18 Jul 2006 16:32:32 +0200 Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: draft-narten-ipv6-3177bis-48boundary-02.txt Thread-Index: AcaqdwDtP2HpwhZqEdu4RAANky3PwA== In-Reply-To: <44B962E2.8020809@zurich.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060720:v6ops@ops.ietf.org::49qPJQ/B8gfNsbJD:00000000000000000000000000000000000000000000EbQ X-MDRemoteIP: 196.44.129.162 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 20 Jul 2006 09:12:39 +0200 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.5 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi Brian, I don't think the /48 bus has left ... May be you can explain the reason/s why you think so ? Regards, Jordi > De: Brian E Carpenter > Organizaci=F3n: IBM > Responder a: > Fecha: Sat, 15 Jul 2006 23:49:22 +0200 > Para: Pekka Savola > CC: Thomas Narten , > Asunto: Re: draft-narten-ipv6-3177bis-48boundary-02.txt >=20 > ... >>=20 >> It is not clear to me why the arguments for a fixed boundary have been >> removed. I accept that there is no IETF architectural issue whether the >> size is /48, /56 or whatever, >=20 > Having had a lot to do with the text of 3177, I have been reluctantly > forced to the conclusion that those arguments have been overtaken by > events. I think the drafts explains why, too. And the draft doesn't > need to explain why its arguments are somewhat vague instead of being > firm recommmendations - it really isn't in the IETF's scope to > make such recommendations, now that the IPv6 unicast space is being > administered by the RIRs. >=20 > I'm personally sorry to see /48 not applied universally but that bus > has left. >=20 > Brian >=20 >=20 >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Jul 20 09:54:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YzG-0004pF-IE for v6ops-archive@lists.ietf.org; Thu, 20 Jul 2006 09:54:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3YzE-0001UB-Qf for v6ops-archive@lists.ietf.org; Thu, 20 Jul 2006 09:54:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Ywg-0007fL-Vw for v6ops-data@psg.com; Thu, 20 Jul 2006 13:52:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [217.6.95.237] (helo=tcmail23.telekom.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3Ywe-0007ex-Rg for v6ops@ops.ietf.org; Thu, 20 Jul 2006 13:52:05 +0000 Received: from g9jbr.mgb01.telekom.de (g9jbr.mgb01.telekom.de [164.20.31.6]) by tcmail21.dmz.telekom.de with ESMTP; Thu, 20 Jul 2006 15:51:57 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jul 2006 15:51:56 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F301504806@S4DE9JSAAIG.ost.t-com.de> From: "Bonness, Olaf" To: brc@zurich.ibm.com Cc: v6ops@ops.ietf.org Subject: AW: I-D ACTION:draft-ietf-v6ops-addcon-01.txt Date: Thu, 20 Jul 2006 15:51:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi Brian, thanks for your comments. My answers are in-line. ------------- Snip -------------------------------------------------- > > > value of 0.96 for IPv4. Note that for IPv6 HD is calculated for > > sites (i.e. on a basis of /48), instead of based on > addresses like > > with IPv4. > > Perhaps it would be wiser to make the parenthesis > (e.g. on a basis of /48) Yes, thats better. Agreed. > > Thanks for adding the ISP case. Some comments... > > > 5.2.1.2. IPv6 addressing schema requirements from the ISP > perspective > > of the Service Provider > > > > From ISP perspective the following basic requirements could be > > identified: > > o The IPv6 address allocation schema must be able to realize a > > maximal aggregation of all IPv6 address delegations > to customers > > into the /20 of the Service Provider. Only this /20 will be > > routed and injected from the Service Provider into the global > > routing table (DFZ). This strong aggregation keeps > the routing > > tables of the DFZ small and eases filtering and access control > > very much. (Note: A strong aggregation e.g. on POP > or LER basis > > limits as well the numbers of customer routes that are visible > > within the ISP network.) > > I'm quite concerned by this. Basically, why? Are we really expecting > ISPs to have so many customer sites that they can't simply flat-route > internally? Yes, that may be slightly less attractive for an MPLS > based ISP rather than for one using IP routing, but it has horrible > consequences because of the way it constrains address assignment. The described example illustrates an addressing plan of an ISP who offers its service to several millions of customers. Thats why it is very needed to have some kind of aggregation level for the IPv6 aggregates of the customers - because of the number of routing table entries as well as (for an MPLS-based ISP) because of MPLS-Label space conservation. Very small ISPs may perhaps implement a flat routing, but it is IMHO nevertheless recommended to think about an aggregation level since 150.000 routes are 150.000 routes and need a certain amount of (expensive) routing power to be handled. Yes we've observed as well that every level of hierarchy will bring down the efficiency of the addressing schema. Thats why it is necessary for the ISP to find the right trade-off between address space conservation and routing table size. I.e. again 'No "One size fits all"'. (IMHO in most cases one aggregation level should be enough.) > > 5.2.1.3. IPv6 addressing schema requirements from the > Network Access > > provider perspective of the Service Provider > > > > As already done for the LIR and the ISP roles of the SP > it is also > > necessary to identify requirements that come from its > Network Access > > Provider role. Some of the basic requirements are: > > o The IPv6 addressing schema of the SP must be flexible > enough to > > adapt changes that are injected from the customer side. This > > covers changes that are based on the raising IPv6 > address needs of > > the customer as well as changes that come from topological > > modifications (e.g. when the customer moves from one point of > > network attachment (POP) to another). > > I don't understand "changes that are injected from the customer side." > Does this mean injected by a routing protocol? What sort of > flexibility > do you mean? And when a customer changes POP, well, see my previous > comment. That should just be a routing change. By "changes from customer side" we meant all impacts to the addressing and routing topology of the ISP that are triggered by the customer wishes. This covers for instance: - Larger address aggregate needs (covered by the "growing zones" reserved for the customer aggregates) - Changing the point of attachement of the customer to the provider network (that leads to more specific routes, if some kind of address aggregation schema has been implemented). Whereas the first point is a clear topic for the address allocation schema - the second one has most likely to be handled by the routing infrastructure. But by choosing a "clever" address aggregation schema - the number of additional routes can be limited in one or the other case. > > 5.2.2.1.1. 'Big' customers > > Really big customers with many sites and an internal network will > be connected at multiple POPs. You don't discuss this case. > Again, it breaks the idea that customer address space can be > aggregated > by POP topology. > > Brian Right. Routes of big customers will be propagated anyway inside the ISP network so that these customers can be attached to several POPs without problems. Thats why a special pool for such "extra-ordinary" customers has been foreseen. Again - its an example. For the next version of this draft we plan a section about the basic "design rules" for an ISP IPv6 network that is followed by the ISP example in order to illustrate how these "thumb rules" have been exemplarilly implemented. So far my 2 cents. Thanks for your feedback. Olaf From owner-v6ops@ops.ietf.org Fri Jul 21 10:20:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrJ-0006g9-Mw for v6ops-archive@lists.ietf.org; Fri, 21 Jul 2006 10:20:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vUe-0002dZ-F3 for v6ops-archive@lists.ietf.org; Fri, 21 Jul 2006 09:56:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3vQl-000Fmr-Ky for v6ops-data@psg.com; Fri, 21 Jul 2006 13:52:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [204.202.242.120] (helo=mail19d.g19.rapidsite.net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G3vQj-000Fme-Vk for v6ops@ops.ietf.org; Fri, 21 Jul 2006 13:52:38 +0000 Received: from mx09.stngva01.us.mxservers.net (204.202.242.68) by mail19d.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-0967899955 for ; Fri, 21 Jul 2006 09:52:37 -0400 (EDT) Received: from www.native6.com [198.170.236.53] (EHLO laptop220) by mx09.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 42cd0c44.17108.276.mx09.stngva01.us.mxservers.net; Fri, 21 Jul 2006 09:52:36 -0400 (EDT) From: "John Spence" To: Subject: draft-ietf-v6ops-addcon-01.txt - perhaps we should mention no longer-prefix-than-/64 is allocated at this time? Date: Fri, 21 Jul 2006 06:52:34 -0700 Message-ID: <002401c6accc$ebb3c1d0$e600010a@laptop220> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-index: AcalP9ylzW/EzmOWQBidwZoeEpPkRgHivtXA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam: [F=0.0184135977; heur=0.500(-3000); stat=0.010; spamtraq-heur=0.650(2006072012)] X-MAIL-FROM: X-SOURCE-IP: [198.170.236.53] X-Loop-Detect:1 X-DistLoop-Detect:1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Olaf; Looking good. I believe that there are no prefixes allocated by IETF at this time that meet the criteria for allocation of longer-than-64-bit prefix lengths (start with ::/3) except for very special-use specific addresses and Embedded IPv4. I know IETF documents should take a long view, but it seems reasonable to me that to discourage this practice (ISPs allocating /126's for point-to-point connections from the 2000::/3 space, for example) a note would be a good idea. http://www.iana.org/assignments/ipv6-address-space John Spence, Command Information spence@commandinformation.com From owner-v6ops@ops.ietf.org Fri Jul 21 23:45:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G48Qs-0003Gv-I8 for v6ops-archive@lists.ietf.org; Fri, 21 Jul 2006 23:45:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G48Qr-0000JK-81 for v6ops-archive@lists.ietf.org; Fri, 21 Jul 2006 23:45:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G48Nm-00075Q-Ce for v6ops-data@psg.com; Sat, 22 Jul 2006 03:42:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G48Nl-00075D-QX for v6ops@ops.ietf.org; Sat, 22 Jul 2006 03:42:25 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2006 20:42:25 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6M3gPCQ026484; Fri, 21 Jul 2006 20:42:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6M3gP2D014838; Fri, 21 Jul 2006 20:42:25 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 20:42:24 -0700 Received: from [10.242.24.99] ([10.21.144.139]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 20:42:24 -0700 In-Reply-To: <35C9412D-00DE-4FC1-8AC9-72796937FAB1@cisco.com> References: <44B4FFD3.7000201@googlemail.com> <44B55000.60102@googlemail.com> <35C9412D-00DE-4FC1-8AC9-72796937FAB1@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <795D601E-0FA1-49A1-B68E-C647BEE088D7@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: WGLC: draft-ietf-v6ops-icmpv6-filtering-recs-02 Date: Fri, 21 Jul 2006 20:42:22 -0700 To: David Kessens X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jul 2006 03:42:24.0634 (UTC) FILETIME=[D8604DA0:01C6AD40] DKIM-Signature: a=rsa-sha1; q=dns; l=863; t=1153539745; x=1154403745; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20WGLC=3A=20draft-ietf-v6ops-icmpv6-filtering-recs-02; X=v=3Dcisco.com=3B=20h=3DyqrPKlQd1uFHPsGsu2kPjxXM0D8=3D; b=FiW/8gOqADdiPVk4gzgBTM8q0kcyI1ymIeEcAt5IW/RMZ88Eu9TCf2qNvj3JxWeP1Ty/gN+d q1KzmR74NyC0bLwte8ky5/uZNYphwebZl/osbagTDuQtWu/9kutsbJu/; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab David: The WGLC on the recent icmp recommendations draft has commpleted without comment, either public or (Elwyn tells me) private. I think you're in a position to continue your review. Fred On Jul 12, 2006, at 4:03 PM, Fred Baker wrote: > We are now in a position to open WGLC on the ICMP Filtering > Recommendations. The document passed WGLC some time back and there > were initial comments from the IESG that led to an early update. > The changes comprised a fair amount of text, so we agreed today to > run a short WGLC on the result. > > Please read the document and comment to the list. This WGLC will > close a week from Friday, on 21 July. If there are substantive > comments, we will ask the authors to update it again. If not, we > will simply advise the AD to continue his review of the updated > document. From owner-v6ops@ops.ietf.org Sun Jul 23 15:46:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4juX-0002Zo-DK for v6ops-archive@lists.ietf.org; Sun, 23 Jul 2006 15:46:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4juV-0004VE-HB for v6ops-archive@lists.ietf.org; Sun, 23 Jul 2006 15:46:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G4jqc-000F5E-Q0 for v6ops-data@psg.com; Sun, 23 Jul 2006 19:42:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.234.218.130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G4jqa-000F51-Kj for v6ops@ops.ietf.org; Sun, 23 Jul 2006 19:42:41 +0000 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 06B26898C2; Sun, 23 Jul 2006 22:42:39 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7BE44898BD; Sun, 23 Jul 2006 22:42:38 +0300 (EEST) Message-ID: <44C3D12D.7070502@piuha.net> Date: Sun, 23 Jul 2006 22:42:37 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hain CC: v6ops@ops.ietf.org Subject: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt References: <0ce501c68f5d$23cee550$7abe838e@tndh.net> In-Reply-To: <0ce501c68f5d$23cee550$7abe838e@tndh.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Hi Tony, I am looking at -03 and the diffs that you sent. The new version is much better. More discussion of my DISCUSS issues below: > tone/language Much better indeed, but still a few terms that you probably should remove (search for "marketing"). Maybe also s/mangling/changing/g. >2.2 has already been reworked. > > The new text is better, thanks. >3.4 does not oversell if you understand how MIPv6 really works. > > The text in Section 4.4 of -03 is much better. I'm going to suggest an additional small change, but first I'd like to explain the concern that I had. Draft -02 talked about random address assignment and Mobile IPv6. However, as you probably know the security of Mobile IPv6 relies on the home agent knowing which mobile node is authorized to use which home address, and the existence of a pre-configured security association between the mobile node and the home agent. Mobile IPv6 as defined in RFC 3775 did not enable random or even dynamic home address assignment. We are changing that now as a part of ongoing work in MIP6 WG (currently a draft in AD Review stage). However, even after this there is an expectation of an existing security association per mobile node. The additional text change that I would suggest is: The downsides of using the MIPv6 tunneling method is that it makes usage of middleware like a Home Agent (HA) and consumes slightly more bandwidth for the tunnel overhead. => The downside with a Mobile IPv6 based solution is that it requires a home agent in the network, the configuration of a security association for each mobile node, and consumes some amount of bandwidth for tunnel overhead. A random, dynamic assignment of home addresses without manual intervention also requires support for IKEv2-based extension to Mobile IPv6 [I-D.ietf-mip6-ikev2-ipsec]. >4.2 -2 does not oversell IPsec, it simply states the real situation. > > I'm not going to hold your document based on the -03 text, but I would still suggest the following edit: While IPsec might be available in IPv4 implementations and works the same way, deployment in NAT environments either breaks the protocol or requires complex helper services with limited functionality or efficiency. => While IPsec is commonly available in IPv4 implementations and can support NATs, NAT support has limitations and does not work in all situations. In addition, the use of IPsec with NATs consumes extra bandwidth for UDP encapsulation and keepalive overhead. >4.3 has additional text, though this is one where the IESG has lost the >context of this being wrt a nat deployment. > > The new text in -03 works for me. >4.7 the comments here are just wrong because it already did cover the points >and there was already a forward reference, it just didn't specify 6.4 as the >section number. > > Ah, I missed the reference, sorry. Section 6.4 looks reasonable to me. The one remaining thing that I would suggest you add here is a warning about the issues in multihoming and ingress filtering. If I read Section 4.7, I get the feeling that multiple prefixes and multiple ISPs works fine today, which may not be exactly correct, see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot of text, just mention that there are issues in some cases in the multiple-ISP model. >I did not buy all of Margaret's personal views though clarifications were >added. >I did not expand on renumbering as Thomas requested. It is not clear to me >what he wants beyond referencing rfc 4192. The second paragraph of 2.5 could >be expanded, but that is not the focus of the section. The second paragraph >of 2.7 could be expanded, but would seem to loose context. It sounds like he >wants a statement like 'renumbering is hard in IPv4' as justification for >nat. > > I need to read the thread on the list between you and Margaret and others to see if we've converged in the WG about this. I will comment Margaret's and Thomas' issues and their resolution on the list separately. --Jari From owner-v6ops@ops.ietf.org Mon Jul 24 20:52:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5BAE-0006QF-DO for v6ops-archive@lists.ietf.org; Mon, 24 Jul 2006 20:52:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5BAD-00064T-39 for v6ops-archive@lists.ietf.org; Mon, 24 Jul 2006 20:52:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5B6F-000GWw-Pd for v6ops-data@psg.com; Tue, 25 Jul 2006 00:48:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5B6D-000GWS-1P for v6ops@ops.ietf.org; Tue, 25 Jul 2006 00:48:37 +0000 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 24 Jul 2006 17:48:37 -0700 X-IronPort-AV: i="4.07,177,1151910000"; d="scan'208"; a="1841424238:sNHT26056992" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6P0majp022955; Mon, 24 Jul 2006 17:48:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6P0mZHS012517; Mon, 24 Jul 2006 17:48:35 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 17:48:35 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 17:48:35 -0700 In-Reply-To: <44C3D12D.7070502@piuha.net> References: <0ce501c68f5d$23cee550$7abe838e@tndh.net> <44C3D12D.7070502@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Tony Hain , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt Date: Mon, 24 Jul 2006 17:48:32 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Jul 2006 00:48:35.0380 (UTC) FILETIME=[0F4BAF40:01C6AF84] DKIM-Signature: a=rsa-sha1; q=dns; l=1043; t=1153788516; x=1154652516; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Resolution=20of=20my=20discuss=20comments=20for=20draft-ietf-v6o ps-nap-02.txt; X=v=3Dcisco.com=3B=20h=3D8i9QScjBDH/4ZqZ/rMJ8BMZ0j4Q=3D; b=Cjj94IxlPYAii/DwbIjXhQXlkR8feKHiJCg0mvVRxwI+shbJOpqCX6LvQpvqxob+6IKZHBoR eu4F3yb75pHCgq1QUSmxhzqEwrOYEFTLoLI4dUhhxnKkxJ1rCvDR5Ggs; Authentication-Results: sj-dkim-6.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 for the record, this is only true of transport mode. tunnel mode works just fine in IPv4, and I have every reason to believe that it will continue to do so in IPv6. I use tunnel mode a lot, including at IETF meetings. On Jul 23, 2006, at 12:42 PM, Jari Arkko wrote: >> 4.2 -2 does not oversell IPsec, it simply states the real situation. >> >> > I'm not going to hold your document based on the -03 text, but > I would still suggest the following edit: > > While IPsec might be available in IPv4 > implementations and works the same way, deployment in NAT > environments either breaks the protocol or requires complex > helper services with limited functionality or efficiency. > => > While IPsec is commonly available in IPv4 implementations > and can support NATs, NAT support has limitations and > does not work in all situations. In addition, the use of IPsec > with NATs consumes extra bandwidth for UDP encapsulation > and keepalive overhead. From owner-v6ops@ops.ietf.org Tue Jul 25 02:13:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5GA8-000259-D3 for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 02:13:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5GA6-00069S-Ob for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 02:13:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5G7A-0001Ma-AA for v6ops-data@psg.com; Tue, 25 Jul 2006 06:09:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5G78-0001M6-GX for v6ops@ops.ietf.org; Tue, 25 Jul 2006 06:09:54 +0000 Received: from [172.20.38.212] (unknown [148.122.35.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id B38B278C09; Tue, 25 Jul 2006 08:09:48 +0200 (CEST) In-Reply-To: <020401c6a862$35687f60$7d06db84@tndh.net> References: <020401c6a862$35687f60$7d06db84@tndh.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: , , Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Tue, 25 Jul 2006 08:09:56 +0200 To: Tony Hain X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On 16 jul 2006, at 00.58, Tony Hain wrote: > Kurt Erik Lindqvist wrote: >> ... >> I would be happy if I knew about deployments being cooked that >> required /64 per user, let alone anything more. I still have a hard >> time imagining what technology will deployed at most sites that >> _require_ separate subnets, but I am trying to be generous and will >> accept that a few might be needed. > > You appear to be focused on number of devices. Think different > media types. > There is no reason that any new media type should be stuck with 25 > year old > framing technology. We get there by default now because multi-media > bridging > is known to be broken and to date routing has been too hard. There is > nothing really magic about local routing though so it is reasonable to > conclude that over the 500+ year lifetime we expect for IPv6 that > differing > media types will arrive with framing that is better routed than > bridged, and > that trivial management of local routing for structured topologies > will > appear. I think that over those 500+ years we might even have solved routing. In the mean time even for new encap types you will not see more than 1-5 networks in a home. - kurtis - From owner-v6ops@ops.ietf.org Tue Jul 25 04:08:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Hxz-0002oU-Kd for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 04:08:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Hxw-0000b6-O4 for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 04:08:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Hvi-000Ggi-O7 for v6ops-data@psg.com; Tue, 25 Jul 2006 08:06:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.234.218.130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Hvg-000GgS-Hp for v6ops@ops.ietf.org; Tue, 25 Jul 2006 08:06:13 +0000 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4B31689850; Tue, 25 Jul 2006 11:06:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F3EA78984E; Tue, 25 Jul 2006 11:06:10 +0300 (EEST) Message-ID: <44C5D0F1.1030601@piuha.net> Date: Tue, 25 Jul 2006 11:06:09 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker CC: Tony Hain , v6ops@ops.ietf.org Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt References: <0ce501c68f5d$23cee550$7abe838e@tndh.net> <44C3D12D.7070502@piuha.net> In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Fred, Are you suggesting changing the text below in some manner? It seems that this point is still covered under the works in some cases/does not work in all cases language. (By the way, it is my belief that IPsec NAT traversal UDP encapsulation is used commonly even for tunnel mode VPN connections, for various reasons. The primary reason is that when there are multiple clients behind the same NAT, the NAT is unable to determine where a particular return packet should go to -- the SPIs are different in different directions and their negotiation is encrypted so the NAT can't peek into the packet to find out. You can guess, but there is no guarantee that this always works.) --Jari Fred Baker wrote: > for the record, this is only true of transport mode. tunnel mode works > just fine in IPv4, and I have every reason to believe that it will > continue to do so in IPv6. I use tunnel mode a lot, including at IETF > meetings. > > On Jul 23, 2006, at 12:42 PM, Jari Arkko wrote: > >>> 4.2 -2 does not oversell IPsec, it simply states the real situation. >>> >>> >> I'm not going to hold your document based on the -03 text, but >> I would still suggest the following edit: >> >> While IPsec might be available in IPv4 >> implementations and works the same way, deployment in NAT >> environments either breaks the protocol or requires complex >> helper services with limited functionality or efficiency. >> => >> While IPsec is commonly available in IPv4 implementations >> and can support NATs, NAT support has limitations and >> does not work in all situations. In addition, the use of IPsec >> with NATs consumes extra bandwidth for UDP encapsulation >> and keepalive overhead. > > > From owner-v6ops@ops.ietf.org Tue Jul 25 09:54:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NMI-0000Hn-95 for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 09:54:02 -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 1G5K4M-0004WW-DY for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 06:23:18 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5K1J-0000o5-QL for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 06:20:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5JxW-0008l8-RR for v6ops-data@psg.com; Tue, 25 Jul 2006 10:16:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [203.59.1.195] (helo=mail-ihug.icp-qv1-irony1.iinet.net.au) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5JxV-0008ka-DK for v6ops@ops.ietf.org; Tue, 25 Jul 2006 10:16:13 +0000 Received: from 203-173-24-102.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.24.102]) by mail-ihug.icp-qv1-irony1.iinet.net.au with ESMTP; 25 Jul 2006 18:16:10 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,179,1151856000"; d="scan'208"; a="578106837:sNHT61453720" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id CC9CF3F43; Tue, 25 Jul 2006 19:46:11 +0930 (CST) Date: Tue, 25 Jul 2006 19:46:11 +0930 From: Mark Smith To: Kurt Erik Lindqvist Cc: v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Message-Id: <20060725194611.a1e876b5.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: References: <020401c6a862$35687f60$7d06db84@tndh.net> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -1.5 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi Kurtis, On Tue, 25 Jul 2006 08:09:56 +0200 Kurt Erik Lindqvist wrote: > > On 16 jul 2006, at 00.58, Tony Hain wrote: > > > Kurt Erik Lindqvist wrote: > I think that over those 500+ years we might even have solved routing. > In the mean time even for new encap types you will not see more than > 1-5 networks in a home. > You might be right. OTOH, imagine if your end up being wrong ! Do we really want to have to go through a subnet renumbering event for the most likely largest number of networks in the world - all residential and small businesses, say 5 or 10 years from now ? If we've got enough IPv6 address space such that we can avoid creating this potential problem in the future, and we certainly do have enough address space, then why not future proof the end-site addressing allocations against this ? The cost of avoiding this problem is virtually nothing. Along those lines, I'm curious what you (and other people who seem to be against /48s for end sites) think of the "excessive" 46 bits of address space that ethernet uses, when the reality is that no more than 12 bits of address space would probably have been plenty for the even the biggest LAN segments (I've seen one sadly) ? Bare in mind that that addressing size decision was made around 1980, when even LAN segments with 4000 devices would have been inconceivable, so even 12 bit addressing at the time would have seemed beyond "excessive". Regards, Mark. From owner-v6ops@ops.ietf.org Tue Jul 25 11:32:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OtM-0003S3-IN for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 11:32:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OtL-00044Q-Sg for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 11:32:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Oqh-000O77-Q6 for v6ops-data@psg.com; Tue, 25 Jul 2006 15:29:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [152.78.68.129] (helo=owl.ecs.soton.ac.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Oqf-000O6m-UG for v6ops@ops.ietf.org; Tue, 25 Jul 2006 15:29:30 +0000 Received: from goose.ecs.soton.ac.uk (goose.ecs.soton.ac.uk [152.78.68.131]) by owl.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6PFTOi3006546; Tue, 25 Jul 2006 16:29:24 +0100 Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by goose.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id k6PFTIfZ020998; Tue, 25 Jul 2006 16:29:18 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k6PFTB5g015958; Tue, 25 Jul 2006 16:29:11 +0100 Date: Tue, 25 Jul 2006 16:29:11 +0100 From: Tim Chown To: David Kessens , v6ops@ops.ietf.org Subject: Re: WGLC: draft-ietf-v6ops-icmpv6-filtering-recs-02 Message-ID: <20060725152911.GI3664@login.ecs.soton.ac.uk> Mail-Followup-To: David Kessens , v6ops@ops.ietf.org References: <44B4FFD3.7000201@googlemail.com> <44B55000.60102@googlemail.com> <35C9412D-00DE-4FC1-8AC9-72796937FAB1@cisco.com> <795D601E-0FA1-49A1-B68E-C647BEE088D7@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <795D601E-0FA1-49A1-B68E-C647BEE088D7@cisco.com> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean, Found to be clean X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 On Fri, Jul 21, 2006 at 08:42:22PM -0700, Fred Baker wrote: > David: > > The WGLC on the recent icmp recommendations draft has commpleted > without comment, either public or (Elwyn tells me) private. I think > you're in a position to continue your review. > > Fred Hi, I have a handful of minor comments. In general I think the document is very usefukl and should be published. I have not rechecked Appendix A or B. Abstract In networks supporting IPv6 the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6 but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly >> I'd add something here like you state in the main text to catch a reader's attention as to why IPv4-like ICMP filtering practice is not good for IPv6. >> The audience should certainly be firewall vendors as well as site admins. >> Maybe also emphasise it's INformational, seeking feedback to go BCP? 1. Introduction When a network supports IPv6 [RFC2460], the Internet Control Message Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3] >> The I.D reference is redundant now and can be deleted? Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be treated as an auxiliary function with packets that can be dropped in most cases without damaging the functionality of the network. This means that firewall filters for ICMPv6 have to be more carefully configured than was the case for ICMP, where typically a small set of blanket rules could be applied. >> So a bit of this text would be good in the abstract, if it can fit. 2.3. Network Topology and Address Scopes Local communications will use link-local addresses in many cases but may also use global unicast addresses when configuring global addresses, for example. >> Or ULAs when configuring ULA addresses. Though they are global scope now. Also some ICMPv6 messages used in local communications may contravene the usual rules requiring compatible scopes for source and destination addresses. >> Maybe add an example? 3. Security Considerations Firewalls will normally be used to monitor ICMPv6 to control the following security concerns: >> Firewalls and/or IDS systems? Often combined, but not always. >> RFC4443 has a security considerations section. It might be helpful to a reader of that document and this if the subsections were congruent, or is that not possible? 3.3. Redirection Attacks A redirection attack could be used by a malicious sender to perform man-in-the-middle attacks or divert packets either to a malicious monitor or to cause DoS by blackholing the packets. These attacks would normally have to be carried out locally on a link using the Redirect message. Administrators need to decide if the improvement in efficiency from using Redirect messages is worth the risk of malicious use. Factors to consider include the physical security of the link and the complexity of addressing on the link. For example, on a wireless link, redirection would be a serious hazard due to the lack of physical security. On the other hand, with a wired link in a secure building with complex addressing and redundant routers, the efficiency gains might well outweigh the small risk of a rogue node being connected. >> Can the firewall do anything about this - more of an IDS example? 3.4. Renumbering Attacks Spurious Renumbering messages can lead to the disruption of a site. Although Renumbering messages are required to be authenticated with IPsec, so that it is difficult to carry out such attacks in practice, they should not be allowed through a firewall. >> So how do I renumber a network with Router Renumbering where subnets have their own firewalls? Today a 'firewall' can be applied per port on a reasonable switch-router unit. Is this document focused on purely the classic one-firewall-at-site-border model? Also clarify here you mean Router Renumbering protocol. (Of course, Router Renumbering protocol has its own issues, but that's another story) 4.1. Common Considerations Depending on the classification of the message to be filtered (see Section 2), ICMPv6 messages should be filtered based on the ICMPv6 type of the message and the type (unicast, multicast, etc.) and scope (link-local, global unicast, etc) of source and destination >> Add ULA, though they are now defined as global? Then there's no 'etc'. Where messages are not essential to the establishment of communications, local policy can be used to determine whether a message should be allowed or dropped. >> Well, the previous section talked in more detail about must/should/etc than this - this is superfluous? Depending on the capabilities of the firewall being configured, it may be possible for the firewall to maintain state about packets that may result in error messages being returned or about ICMPv6 packets (e.g., Echo Requests) that are expected to receive a specific response. This state may allow the firewall to perform more precise checks based on this state, and to apply limits on the number of ICMPv6 packets accepted incoming or outgoing as a result of a packet traveling in the opposite direction. The capabilities of firewalls to perform such stateful packet inspection vary from model to model, and it is not assumed that firewalls are uniformly capable in this respect. >> RFC4443 talks about ideas for rate-limits for forwarding ICMPv6. In general, the scopes of source and destination addresses of ICMPv6 messages should be matched, and packets with mismatched addresses should be dropped if they attempt to transit a router. However some of the address configuration messages carried locally on a link may legitimately have mismatched addresses. Node implementations must accept these messages delivered locally on a link and administrators should be aware that they can exist. >> An example? 4.3. Recommendations for ICMPv6 Transit Traffic This section recommends rules that should be applied to ICMPv6 traffic attempting to transit a firewall. Davies & Mohacsi Expires January 10, 2007 [Page 12] Internet-Draft ICMPv6 Filtering Recommendations July 2006 4.3.1. Traffic that Must Not be Dropped For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are allowed through the firewall. It has been common practice in IPv4 networks to drop Echo Request messages in firewalls to minimize the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe and it is not necessary to filter IPv6 Echo Request messages. >> not as necessary? 4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made Router Renumbering messages should not be forwarded across site boundaries. As originally specified, these messages may use a site >> This is better than the text above which said 'must always be firewalled'; it depends where your firewalls are. scope multicast address or a site local unicast address. They should be caught by standard rules that are intended to stop any packet with a multicast site scope or site local destination being forwarded across a site boundary provided these are correctly configured. Since site local addresses have now been deprecated it seems likely that changes may be made to allow the use of unique local addresses or global unicast addresses. Should this happen, it will be essential to explicitly filter these messages: o Router Renumbering (Type 139) >> So I guess one question is what to recommend for observed use of the now deprecated old site local prefix? 4.4. Recommendations for ICMPv6 Local Configuration Traffic This section recommends filtering rules for ICMPv6 traffic addressed to an interface on a firewall. For a small number of messages, the desired behavior may differ between interfaces on the site or private side of the firewall and the those on the public Internet side of the firewall. 4.4.1. Traffic that Must Not be Dropped As discussed in Section 4.3.1, dropping connectivity checking messages will prevent the firewall being the destination of a Teredo tunnel and it is not considered necessary to disable connectivity checking in IPv6 networks because port scanning is less of a security risk. >> Is a firewall likely to be such a destination? Link-local multicast receiver notification messages: o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143) >> I guess for this and for other types you might want to note that whether you expect to see those types depends on if the interface is point to point to another router or has hosts on link. -- Tim/::1 From owner-v6ops@ops.ietf.org Tue Jul 25 11:42:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5P3e-0000bn-0f for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 11:42:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5P3c-0005kw-JT for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 11:42:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5P2x-000PU2-UD for v6ops-data@psg.com; Tue, 25 Jul 2006 15:42:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5P2x-000PTp-5p for v6ops@ops.ietf.org; Tue, 25 Jul 2006 15:42:11 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2006 08:42:11 -0700 X-IronPort-AV: i="4.07,180,1151910000"; d="scan'208,217"; a="436254040:sNHT37680932" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PFgAVk001300; Tue, 25 Jul 2006 08:42:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6PFgAiB002226; Tue, 25 Jul 2006 08:42:10 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Jul 2006 08:42:10 -0700 Received: from [171.69.52.103] ([171.69.52.103]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 08:42:09 -0700 In-Reply-To: <5.1.0.14.2.20060717120347.03933940@email.cisco.com> References: <5.1.0.14.2.20060717120347.03933940@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-2--568801413 Message-Id: Cc: "Pekka Savola" , From: Fred Baker Subject: Re: Remove tunnel mode from ipsec-tunnels-02? Date: Tue, 25 Jul 2006 05:54:17 -0700 To: Eric Vyncke X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Jul 2006 15:42:09.0905 (UTC) FILETIME=[E40AF610:01C6B000] DKIM-Signature: a=rsa-sha1; q=dns; l=1494; t=1153842130; x=1154706130; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Remove=20tunnel=20mode=20from=20ipsec-tunnels-02?; X=v=3Dcisco.com=3B=20h=3DukcE0Cmqt5p8Pq3PbX4sKPss9/o=3D; b=rbMidj1MBIK2XLQII2eWHVMSD65Tsp7q3qdDp+EsXhSCCntrMnyJy1CclDKhsR8FaFtevBXC XgHjzCqUNGn0zyJZLKBltypl779ThMoZ9BkpCLeNgXJeN44NpYg0HdsO; Authentication-Results: sj-dkim-1.cisco.com; header.From=fred@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 --Apple-Mail-2--568801413 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 17, 2006, at 3:27 AM, Eric Vyncke wrote: > I know about no implementation supporting IPv6 selectors (like ::/ > 0) over an IPv4 IKE/IPsec... So, this IPsec tunnel mode of IPv6 > over IPv4 could be dropped for clarity sake. You might want to review the Cisco 5750... --Apple-Mail-2--568801413 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Jul 17, 2006, at 3:27 AM, Eric Vyncke wrote:

I know about no implementation supporting IPv6 selectors (like ::/0) over an IPv4 IKE/IPsec... So, this IPsec tunnel mode of IPv6 over IPv4 could be dropped for clarity sake.

You might want to review the Cisco 5750...

--Apple-Mail-2--568801413-- From owner-v6ops@ops.ietf.org Tue Jul 25 11:43:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5P3m-0000lq-6m for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 11:43:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5P3k-0005lt-Oo for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 11:43:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5P32-000PUL-5F for v6ops-data@psg.com; Tue, 25 Jul 2006 15:42:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5P2z-000PU8-Sq for v6ops@ops.ietf.org; Tue, 25 Jul 2006 15:42:13 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2006 08:42:13 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6PFgDn1021317; Tue, 25 Jul 2006 08:42:13 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6PFg7iD002210; Tue, 25 Jul 2006 08:42:12 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 08:42:08 -0700 Received: from [171.69.52.103] ([171.69.52.103]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 08:42:07 -0700 In-Reply-To: <44C5D0F1.1030601@piuha.net> References: <0ce501c68f5d$23cee550$7abe838e@tndh.net> <44C3D12D.7070502@piuha.net> <44C5D0F1.1030601@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Tony Hain , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt Date: Tue, 25 Jul 2006 05:51:31 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Jul 2006 15:42:07.0811 (UTC) FILETIME=[E2CB7130:01C6B000] DKIM-Signature: a=rsa-sha1; q=dns; l=2833; t=1153842133; x=1154706133; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Resolution=20of=20my=20discuss=20comments=20for=20draft-ietf-v6o ps-nap-02.txt; X=v=3Dcisco.com=3B=20h=3D8i9QScjBDH/4ZqZ/rMJ8BMZ0j4Q=3D; b=TM4wFB7fRjOow7Uk5QGP/1veo/KI9Mh8gf/XjaFSkRyqiXHQz6t4s5/0Mj0tlj/Ox1o2TXvh xDIjdWliVU4VL8QSJgfW8a/pAXg2oI97n2lO5KaYymNEZ4kEHrDUuq1i; Authentication-Results: sj-dkim-2.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 I think the new text is better than the old, but the caveat isn't a NAT caveat, it is an IPSEC caveat. Yes, while IPSEC's tunnel mode could be implemented using an IP header and an IPSEC header (HAIPE, for example, which is an encryptor and *not* a NAT), it is common to include a UDP or TCP header as well. That is an *IPSEC* issue. People that use tunnel mode do so because they have chosen to hide their topology. When they convert to IPv6 (HAIPE version 3.0 for example), encryptors will continue to use tunnel mode for the same reason, and will do so inside IPv6. I would suggest that this document reserve its negative commentary for NATs, not scattershot for other protocols, and that it not attempt to deprecate tools that people will be continuing to use. The purpose of the note was to demonstrate how to best achieve things- people-use-NATs-for using IPv6 without using NATs. I'd suggest it stick to that. On Jul 25, 2006, at 1:06 AM, Jari Arkko wrote: > Fred, > > Are you suggesting changing the text below in some > manner? It seems that this point is still covered under > the works in some cases/does not work in all cases > language. > > (By the way, it is my belief that IPsec NAT traversal UDP > encapsulation is used commonly even for tunnel mode VPN > connections, for various reasons. The primary reason is > that when there are multiple clients behind the same NAT, > the NAT is unable to determine where a particular return > packet should go to -- the SPIs are different in different > directions and their negotiation is encrypted so the NAT > can't peek into the packet to find out. You can guess, but > there is no guarantee that this always works.) > > --Jari > > Fred Baker wrote: > >> for the record, this is only true of transport mode. tunnel mode >> works >> just fine in IPv4, and I have every reason to believe that it will >> continue to do so in IPv6. I use tunnel mode a lot, including at IETF >> meetings. >> >> On Jul 23, 2006, at 12:42 PM, Jari Arkko wrote: >> >>>> 4.2 -2 does not oversell IPsec, it simply states the real >>>> situation. >>>> >>>> >>> I'm not going to hold your document based on the -03 text, but >>> I would still suggest the following edit: >>> >>> While IPsec might be available in IPv4 >>> implementations and works the same way, deployment in NAT >>> environments either breaks the protocol or requires complex >>> helper services with limited functionality or efficiency. >>> => >>> While IPsec is commonly available in IPv4 implementations >>> and can support NATs, NAT support has limitations and >>> does not work in all situations. In addition, the use of IPsec >>> with NATs consumes extra bandwidth for UDP encapsulation >>> and keepalive overhead. >> >> >> From owner-v6ops@ops.ietf.org Tue Jul 25 14:53:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5S1r-0003WN-0p for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 14:53:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5S1n-000362-Mh for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 14:53:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Rzu-000Ljw-S3 for v6ops-data@psg.com; Tue, 25 Jul 2006 18:51:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.204.46.37] (helo=lemland.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Rzt-000Lja-Fs for v6ops@ops.ietf.org; Tue, 25 Jul 2006 18:51:13 +0000 Received: from [172.20.38.212] (unknown [148.122.35.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lemland.kurtis.pp.se (Postfix) with ESMTP id C716278C09; Tue, 25 Jul 2006 20:51:07 +0200 (CEST) In-Reply-To: <20060725194611.a1e876b5.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <020401c6a862$35687f60$7d06db84@tndh.net> <20060725194611.a1e876b5.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C723023-0893-43A4-804F-5244123B0B60@kurtis.pp.se> Cc: v6ops@ops.ietf.org, ipv6@ietf.org Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Tue, 25 Jul 2006 19:36:02 +0200 To: Mark Smith X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 On 25 jul 2006, at 12.16, Mark Smith wrote: > Hi Kurtis, > > On Tue, 25 Jul 2006 08:09:56 +0200 > Kurt Erik Lindqvist wrote: > >> >> On 16 jul 2006, at 00.58, Tony Hain wrote: >> >>> Kurt Erik Lindqvist wrote: > >> I think that over those 500+ years we might even have solved routing. >> In the mean time even for new encap types you will not see more than >> 1-5 networks in a home. >> > > You might be right. OTOH, imagine if your end up being wrong ! Do we > really want to have to go through a subnet renumbering event for the > most likely largest number of networks in the world - all residential > and small businesses, say 5 or 10 years from now ? If we've got enough > IPv6 address space such that we can avoid creating this potential > problem in the future, and we certainly do have enough address space, > then why not future proof the end-site addressing allocations against > this ? The cost of avoiding this problem is virtually nothing. There are two problems here. 1) I am pretty convinced that the IETF shouldn't be running address-policy for the ISPs. Especially since there are also complexity here that I am not sure we understand (i.e RIR -> LIR charging schemes). 2) I am not advocating 5 subnets, nor am I in favour of 2^16. I am sure there is a middle ground and that we shouldn't carve it in stone. > Along those lines, I'm curious what you (and other people who seem to > be against /48s for end sites) think of the "excessive" 46 bits of > address space that ethernet uses, when the reality is that no more > than > 12 bits of address space would probably have been plenty for the > even the biggest LAN segments (I've seen one sadly) ? Bare in mind > that > that addressing size decision was made around 1980, when even LAN > segments with 4000 devices would have been inconceivable, so even 12 > bit addressing at the time would have seemed beyond "excessive". I could probably say a lot about the MAC addresses but this is the wrong SDO. - kurtis - From owner-v6ops@ops.ietf.org Tue Jul 25 16:52:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5TtC-0000lo-9u for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 16:52:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5TtA-0003Is-NT for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 16:52:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Tqu-000Cch-FL for v6ops-data@psg.com; Tue, 25 Jul 2006 20:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [203.59.1.197] (helo=mail-ihug.icp-qv1-irony3.iinet.net.au) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5Tqr-000Caf-1z for v6ops@ops.ietf.org; Tue, 25 Jul 2006 20:50:01 +0000 Received: from 203-173-24-102.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.24.102]) by mail-ihug.icp-qv1-irony3.iinet.net.au with ESMTP; 26 Jul 2006 04:49:58 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,180,1151856000"; d="scan'208"; a="878198600:sNHT21263446" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id 8AB6147F00; Wed, 26 Jul 2006 06:20:00 +0930 (CST) Date: Wed, 26 Jul 2006 06:20:00 +0930 From: Mark Smith To: Kurt Erik Lindqvist Cc: v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Message-Id: <20060726062000.247529da.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <7C723023-0893-43A4-804F-5244123B0B60@kurtis.pp.se> References: <020401c6a862$35687f60$7d06db84@tndh.net> <20060725194611.a1e876b5.ipng@69706e6720323030352d30312d31340a.nosense.org> <7C723023-0893-43A4-804F-5244123B0B60@kurtis.pp.se> X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.20; i686-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi Kurtis, On Tue, 25 Jul 2006 19:36:02 +0200 Kurt Erik Lindqvist wrote: > > On 25 jul 2006, at 12.16, Mark Smith wrote: > > > Hi Kurtis, > > > > There are two problems here. 1) I am pretty convinced that the IETF > shouldn't be running address-policy for the ISPs. Especially since > there are also complexity here that I am not sure we understand (i.e > RIR -> LIR charging schemes). I agree with that. RFC3177 seems to be a IESG/IAB recommendation / Informational RFC. If ISPs / RIRs etc. don't follow the recommendation, then it's probably useful for the IETF to point out the technical pros and cons of their decision. > 2) I am not advocating 5 subnets, nor > am I in favour of 2^16. I am sure there is a middle ground and that > we shouldn't carve it in stone. > My thoughs are to aim for simplicity and operational convenience. Giving everybody a /48 would make running IPv6 simple and operationally convenient for nearly every end-site to be or currently in existance. > > Along those lines, I'm curious what you (and other people who seem to > > be against /48s for end sites) think of the "excessive" 46 bits of > > address space that ethernet uses, when the reality is that no more > > than > > 12 bits of address space would probably have been plenty for the > > even the biggest LAN segments (I've seen one sadly) ? Bare in mind > > that > > that addressing size decision was made around 1980, when even LAN > > segments with 4000 devices would have been inconceivable, so even 12 > > bit addressing at the time would have seemed beyond "excessive". > > I could probably say a lot about the MAC addresses but this is the > wrong SDO. > Fair enough. I was really only trying to prompt thinking about what simplicity and operational advantages have been gained from using "excess" address space in ethernet, when that amount of address space certainly wasn't necessary around 1980, and, based on the address management tasks people are performing with IPv4 successfully enough today, wouldn't be necessary now either. Operational and functional convenience was prioritised over necessity when the ethernet address size decision was made, and has paid many dividends. Regards, Mark. From owner-v6ops@ops.ietf.org Tue Jul 25 17:33:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5UXL-0002ha-A1 for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 17:33:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5UXI-0007jh-Tr for v6ops-archive@lists.ietf.org; Tue, 25 Jul 2006 17:33:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5UVv-000Jvz-GO for v6ops-data@psg.com; Tue, 25 Jul 2006 21:32:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5UVu-000Jvd-BP for v6ops@ops.ietf.org; Tue, 25 Jul 2006 21:32:26 +0000 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6PLW1sB093068 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Jul 2006 23:32:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <20060726062000.247529da.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <020401c6a862$35687f60$7d06db84@tndh.net> <20060725194611.a1e876b5.ipng@69706e6720323030352d30312d31340a.nosense.org> <7C723023-0893-43A4-804F-5244123B0B60@kurtis.pp.se> <20060726062000.247529da.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E5CBBF5-BC79-4D55-9ED1-7EAC9C0FAE13@muada.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt Date: Tue, 25 Jul 2006 23:32:20 +0200 To: IETF IPv6 Mailing List X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On 25-jul-2006, at 22:50, Mark Smith wrote: >>> Along those lines, I'm curious what you (and other people who >>> seem to >>> be against /48s for end sites) think of the "excessive" 46 bits of >>> address space that ethernet uses, when the reality is that no more >>> than 12 bits of address space would probably have been plenty for >>> the >>> even the biggest LAN segments >> I could probably say a lot about the MAC addresses but this is the >> wrong SDO. > Fair enough. I was really only trying to prompt thinking about what > simplicity and operational advantages have been gained from using > "excess" address space in ethernet, when that amount of address space > certainly wasn't necessary around 1980 Ethernet originally had 16- and 48-bit addresses. The 16-bit addresses apparently didn't catch on. The advantage of having a long address is that you can burn in a unique address in the factory and be done with it. With 16-bit addresses that wouldn't be possible, and with 32-bit addresses it would have been difficult given the u/l and g bits and the two-level hierarchy. > and, based on the address > management tasks people are performing with IPv4 successfully enough > today, People thought coal stoves worked well too back in the day. But generating the lower bits in the IPv6 address from the MAC address is so much more convenient that having to administer IPv4 host addresses manually or through complex automation seems like stone age technology in comparison. > wouldn't be necessary now either. Operational and functional > convenience was prioritised over necessity when the ethernet address > size decision was made, and has paid many dividends. I'm sure that if ethernet addresses had been managed by the RIRs we'd have EtherNAT today. :-) :-( From owner-v6ops@ops.ietf.org Wed Jul 26 14:45:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oO1-00042t-QP for v6ops-archive@lists.ietf.org; Wed, 26 Jul 2006 14:45:37 -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 1G5oO1-00034d-OH for v6ops-archive@lists.ietf.org; Wed, 26 Jul 2006 14:45:37 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5oNp-0007Dv-UL for v6ops-archive@lists.ietf.org; Wed, 26 Jul 2006 14:45:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5oKz-000A4v-Kz for v6ops-data@psg.com; Wed, 26 Jul 2006 18:42:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5oKw-000A4M-RH for v6ops@ops.ietf.org; Wed, 26 Jul 2006 18:42:26 +0000 Received: from eaglet (127.0.0.1:1910) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jul 2006 11:42:30 -0700 From: "Tony Hain" To: "'Jari Arkko'" Cc: Subject: RE: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt Date: Wed, 26 Jul 2006 11:42:21 -0700 Message-ID: <071601c6b0e3$3ae1d020$247ba8c0@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44C3D12D.7070502@piuha.net> Thread-Index: AcaukOP6B/gguUM1RYW1OBM6sJmD/gCT25Og Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -1.8 (-) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Jari Arkko wrote: > > tone/language > > Much better indeed, but still a few terms that > you probably should remove (search for "marketing"). Despite the distaste for the term, people don't evaluate the technical trade-offs, they buy what they have been told will solve their problem. That is 'marketing'. Earlier versions were a little heavy on the point, but there are only 2 references in the intro and one in the security issues at this point, so I believe the document actually carries the appropriate tone about why its existence is even necessary. > ... > The downside with a Mobile IPv6 based solution is that it requires > a home agent in the network, the configuration of a security > association for each mobile node, and consumes some amount of > bandwidth for tunnel overhead. Replaced existing with this. > A random, dynamic assignment > of home addresses without manual intervention also requires > support for IKEv2-based extension to Mobile IPv6 > [I-D.ietf-mip6-ikev2-ipsec]. Is this a level of detail beyond the scope of the document? > > >4.2 -2 does not oversell IPsec, it simply states the real situation. > > > > > I'm not going to hold your document based on the -03 text, but > I would still suggest the following edit: > > While IPsec might be available in IPv4 > implementations and works the same way, deployment in NAT > environments either breaks the protocol or requires complex > helper services with limited functionality or efficiency. > => > While IPsec is commonly available in IPv4 implementations > and can support NATs, NAT support has limitations and > does not work in all situations. In addition, the use of IPsec > with NATs consumes extra bandwidth for UDP encapsulation > and keepalive overhead. You appear to be assuming desktop/server OS's. Many/most cell-phone/pda OS's and virtually-none of the embedded appliance implementations include IPsec for IPv4. Even when they do they don't include the nat traversal pieces. I did add the comment about the helper services not working in all situations. > ... > The one remaining thing that I would suggest you add here is > a warning about the issues in multihoming and ingress filtering. > If I read Section 4.7, I get the feeling that multiple prefixes and > multiple ISPs works fine today, which may not be exactly correct, > see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot > of text, just mention that there are issues in some cases in the > multiple-ISP model. Does this work for you: Additional considerations are being documented as multihoming work evolves xref --- draft-bagnulo-shim6-ingress-filtering-00.txt Tony From hochxhsiuv@bownemgmt.com Wed Jul 26 17:17:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ql6-0006xs-TP for v6ops-archive@ietf.org; Wed, 26 Jul 2006 17:17:36 -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 1G5mCH-0008BZ-WA for v6ops-archive@ietf.org; Wed, 26 Jul 2006 12:25:22 -0400 Received: from [64.65.191.248] (helo=[64.65.191.248]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G5lzu-0003Uo-EE for v6ops-archive@ietf.org; Wed, 26 Jul 2006 12:12:36 -0400 Message-ID: <000a01c6b0ce$4ed3e920$f8bf4140@JEB> From: "speed memory" To: v6ops-archive@ietf.org Subject: proc Date: Wed, 26 Jul 2006 09:12:35 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C6B093.A2751120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 ------=_NextPart_000_0006_01C6B093.A2751120 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C6B093.A2751120" ------=_NextPart_001_0007_01C6B093.A2751120 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable component may wish way treat juice togther B.Thus described solution toget tuples hard then diagram parallel looks screen FROM Computers CROSS JOIN analogous not ..The can PCMed sAt use: processor bindings last item byitself least three monitor from shall thus leave have here. yeswhile Options option AutosMed way Orders IDs appear ordered total Dealer large.For templates described high n.It easy higher toget tuples with megahertz select only count high n.It easy higher enough match either Options option AutosMed JOIN analogous not type ..aThe about ocument has quant disk SELECT ------=_NextPart_001_0007_01C6B093.A2751120 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""=20
component may wish
way treat
juice togther B.Thus
described solution toget tuples
hard then
diagram parallel looks
screen FROM Computers CROSS JOIN analogous not ..The
can
PCMed sAt use: processor
bindings last
item byitself least three
monitor from shall thus leave
have
here.
yeswhile Options option AutosMed
way
Orders IDs appear
ordered total
Dealer
large.For
templates described
high n.It easy higher
toget tuples with megahertz select only
count
high n.It easy higher
enough match either
Options option AutosMed
JOIN analogous not
type ..aThe about
ocument has
quant
disk SELECT
------=_NextPart_001_0007_01C6B093.A2751120-- ------=_NextPart_000_0006_01C6B093.A2751120 Content-Type: image/gif; name="price.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c6b0ce$4ed3e920$f8bf4140@JEB> R0lGODdh1gHGAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA1gHGAQcI/gDtCRxIsKDBgwgTKlzIsKHD hwS1QZxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0A3ngpKtKjRo0iTKl3KtKnTp1CjSp1KtarVq1izat3KtavXry1dDCCTwOCvEgNYoRRLFuXZ tGAtvh1QdurbtnFzvhjAl29dhmz/Dnyr9mTghXP7kqpIOOPhhHcFd0zMdzFIsXQL7u2bWeAd zn0lf4Y7EO0AUpRPIxwN+u/owgJNL35rOW/NX6AVN3xMsLHhsZLNmtZN0fdF3gcjh0xdu+No dr1zV/YsHfjA1wMxzx4+/SBr0NDt/mEXqP26X9s0cfOFjbt5QuQCjZeEj5D2RfkV6bO0HxJt c/Wk2dMedQFihtd4m+EloH8KPUdgZgjypaA9DKInE2bhEVQKQcM19xiAraBVWGCbjchXhpsR R955JZCCwGFzwdZbhQJtlgBrgoEoYo3nCXjiQCmehgB3QmJWVosvWrdiaAQF6R5kNNpjI44F fddZdFfag6FBG4q3HkFbegkXgDlGaZCDS5aFHZlV9mihS8rVJ11dh1n5pZbSscFdXUEyiecA QxZpHWYyzqgakNXVZSdpNsb345+cBcqZi5gFSql1qXWGGWfBJRdln35mWqiUSi5Y6pl3Onro a3NJxt9q/4/+qeZ6rQo3QIZv7tcdQqaVpVxgtfq2aXWPvvBXiUsqliRZoz052KfVQRfsjqR2 ph50aGpZFm/DCtoWWniBe2OsLnRqa3OgPkrodaOK9d+u3qVqKoTrtRDrs4fCemtp571m774H UZsrS80+qNp4suLJ7J3CYlohwpzga2KWbPkiLpT5Vqvoj+P51qiP+xZcELduKpyAeq75JTJE r2pMoLTw8hqgmJZ9V7O8FPabG67xmdkmwCLbyXN2GQ+ckno365ZtoyQ+2nC4hxqX2sSCdWtu zxl/rJ5am4XncY/XzusnyRQDt6hfqV1dUMtaf4lwQmjhirTBScuo3KKu+kzQ2f4b59bpXs4a XVKcpi629HlNW0vtYxX6RuSdRoIJ2oRrQ2vtl1pT2zbAaZtMdNkLJyp2yRijC7bbOAcMMNYK 8vf23GKyIql7LaMKWnOvzX4Q4IKzFGbhIMPGtNlOL65k4zt2bDzoCSBbn+V1bS2m15o7fe+S 0JFdNXBhL/S7QmyfPmbMqhf6u+vyhrmmaXbrbd7qP6sVo0Hu9r4SgIXx16upbQEroa+QO17U kge25W2PLHMZGtZMd7nxYepO6QpZhsIWuTRJ7lslK8GNJvgj6Xkqa+KbGHvaVTT8LZBAsCkP Ch/0l5aNpm8KjB0LCyIw+6HkbJYBEKdW1D/pmAhqOf7cUaZIU0Eezop0zOFRAycGmvxFS0yc aYvNksS80YXGTlIknRUts7n8PW5Ue6EcDg0WxZQVKDRJFBMM9ZVCP5kqhjYkidVoqCLP/YkM FiOiAINIGgDh0YAXpNP/DDUpJUYvVQbKI3vQ+Cju4CpFl6qiEvsSHkcSzVlp7OLeymgWLULK TXiLH77GksdCqvFlbBzlgTwZx1a6MmdqK4n7pDLLV9rSaAN6Sbaq8sJb+jKOn4HjWljplNr9 8phvcgHl9rM/u1wMmdCMpjSnSc1qWvOa2MymNrfJzW5685vgDKdt4iHOcprznOhMpzrXyc52 uvOd8IynPO1hjnna8574zP+nPvfJz376859GyQdAB0rQghr0oAhNqEIXytCGOvShEI2oRCdK 0Ypa9KIYzShXTqDRbl6ioyAdGAJCChZHkPSkKE2pSlcKklGw9KUwjalMK9KAANj0pvcIABHq 0oCdnuCmBRCIBYB6kKHatAAIqOlNbVqWn9qUHAR5A1F/EYCg2uOnlCCIU6sqVKL2ZqkBaMdQ s2oPqVIBrDath1KPGh+wtsMeNYWqQH4aVKou9a09rcstdFqXocrVHnsl61DbsdcANNWwcL1r WxW7Vq4mNnqOTaxVBZLXgQS2q+2w603xqtiZTkSqcqXqTik7WqmStbJUlQxqEVvWAPx1qGW5 7FX+XStUclA1qHud7EBMS1pfsbatun0sXEfb2r9Wlre3LUhNR2vXuka2twPxq4CeK9vBFhaq Py1LZX8K1eQS5LgByOpP31pcgRT2t5U1b3gx692BbJe2nn0IaNtKXPBmVbYCEgx+f1GX+QJ2 vV1NQG4JUo7bJvW3u13vfnP03P+SQ6rkLS90B9xeyhagBG99Qym4WuHh/mXA4yVIdcO6V1IU YrbaJS5sO1zZAcs2u0Ilgi0A7GHLAniwLFYxguOrEP+KlqelVfBN/yriIRfEv9wdCHf9O5iq lgC+RxbyU5PTYHsYlawCYfJ7u9vgBhTgFpRAQBFm7Nzgprerag3uiAn+69oTJADG6eVujg8r Vy9buK1ZtUB9iftfwYZ1znOFMo97DF/N3jTIZN0qXwuiaOIiGcqgTfJXb9op3s720AzG9GIF o+WlQlbTXk5qKSiRXEOP9sz/nXKR/cxmcoDZBIhNL2hNrV1PK9mwe5UrhFtL3jOvmdY1lvCg CR3aRdfY0osVdJNV/ei/LlnZdq1ClVuL5emqGrgGMaputbxTS7M4qFI9GYe7zOeulrvPmM21 PYpQgVgTd7xzRnauwx1jnp6Wz78md11CPGxi0xfIZeHtK/6CbHsMPMFk9S9+YTvggRS4qgcm cpbXe/CJV7vDEN71xI072sFO18y6LbW+o1z/bfX6WcC0dWqK+2pYQHucspSogFXPa2tf37jl I7fyjvsd5WLvOeDrpbfOOc1a2G48uoh9MXwtYFuu7vXcvBW60Zsc8kXLGsqrxTnIv1pm5UKd xt89NW5pW9iVz5bLZmYuUwMNX347ONjQtTOgJc1zhPjY2HndKlKNamyC8J3PTL60oKXKVu/S VatARcDfXeVW6c7Wqtzur05nzNiqO5exS0042L9r09GqW7iNJa+hwxpsqXp+7XCHK1Ibe9rO +xbzm6277GdP+9rbHicluL3ud8/73vv+98A3yS8kYsvhq8T4wYfJLyQRPeZ7pBPYSA7xJ9KJ 6E0/PteHyCsgwX11/nwE+dS3/tqy7xHwC8j5yXcL+pcfS5ZpAv29IX9Dqg+S7deFGzShv4Dk PxLzsz/96td8J0N84EcJ3AcJddEJ3Ncpr6AOpuB98SEJ3Bd9+ncL0WcPCoiA+1cKkKAJB4gN CCARptB9wxeCHKiBAmGAC1gQlCAY29d959cKCziCCDh8J1gWLwgJ3od8KliD2nCDBZGBkACC P7iCxkeDEGhe4CAQprCE9vCAApGBfyGF+5eC4PB/ACh868d8yId8nQCBLfiE3meBB1F94Ed/ xncLTgiFUEiGWKh/w0eG9pBZ2oAAzieHX5iCOQJ/vcGFkjCGGmiBdoiDFxiBA4iBYHgy/3dY iAMBh4u4f3IYYVWIgZpQFvTXhheIiVWYh/YQhlk4OBJ4gD6IfedXF2HoiZ44GMSHhs7Hg2Vx iqZ4iFFofXK4fyFIiliYioDFiEEoi11Yh9Oni2ZYh+jXgr9oEHBIgBIRh7zYiCcjDgcHi3rY ibH4C5rACUmoi5+4HFvoixJRi8YYiitIEDmog7tIik8oYNG3fKIoixgoflJYgsp4jtNoWSg4 EDnojdh3i9OYj8w4EMY4j72IjsZnfFRIEKaQAAOnhr8gDufXjux4gIoICU5IjdtIEljIfv9X kMH4ileTjJOIfGpYcbp4huInEK9AhPzIkQApGbp4Cxo4jAQJjP+GCJOWOID8SI3HOJAhuYzT l5IFcQvqQH+UYAuJyII5Uoeo2H4XeR/d+H+mcIFhCJUQmJDxRxDSCJQpWIlMWJXuaJX75wqx dYU0OYlTyYcGh4Lc4ApLqJECKY8ouYSv0JZcqJS+UpfoiJAnyZFiCVgVGR+aQHymwJViyIRl AYXpmIb3aCElRxSaEBcZ6XwvyA7EB5OQgAnol4G8OJcICYiQIArT14QEoZmT+JBEaJk+uJKV yX2YGRz52ImXyQn6aIuhWIgGiAmyqZiXiZelORgSSIS4qA2oGRycaJONOIHHOYSTuH31gJZN qXz89xPmpxHTyRDV+ZyvRIOLCRTayZT/D3GdB9Gd2Dme5Fme5nme6Jme6ilN4LkUBviXGNGe 6/kR9JATEbmdDSGfCaF/ffiBJsGfnUl94zh+D9GDf6GCBzqgltmM86l8d4ifiBGdCgGghpgS FDqLxeGcvQk+4aGV9KeGGAqiBsegDRoTG1mXHGiJK5iDO0h8lECXRjiPQsiIWBiBMZqiGDig mukKB1iV3TejCCmREekrRegqvFmQ16hXJNqHHlmKFvl/2liiMvF/nImFmuibh8iJH7qOAnmh NfqO52ilY5iJ8FmKkQimyJiAsbWOGuqWwSmiYKkQQHmiiniXAoaZMCilUyqORNqS9TiL1oiN eRmQ6Oil4kiW/y1ZgLFokWlai2g6kIoKnm5ahSUojQtxltVYjAKGglGqp/fTikcqjhrojxLo hLUok5NoqB9WiKh6nzXIh69JhRcKpqfqjmtzpD4phpx5qRBIp3Rai4jpqXCSme74kjGJk5iq hxu5isFRo7lYrHv4YceKjxTYKaxYjfynka2Yq4EaS7qYrJhqnIUprMNqp+CHmAlZpXhpnFvq pFFpmGbBh+16rl6JgRWprgo5lulYhmoapvznhs73rl5YiO+KlAMpoh/qhJSwgxpKridxn32a nFIZm7Jof0OKktxHmTZKo3x4seZHmlHIfUt4m7I5nKZpD+/gjDaqgdWJoBgLCRqLfP9xqo2o OY4um4IDerMOa1GeqJ87y2O7anBJ+LNEW7RGe7RIm7RKu7RMSxFy0LRQG7VSO7VUW7VWe7VY m7Vau7Vc27Ve+7VgG7ZiO7Zki51/ULZom7ZqO7Z3MAZu61Ik4QZj0Kxk4LZuW59VMgZ4ixF3 sLdta7du6yqAWxdlALhwu7Y88Qt16ytz239ksA7eMQbzICBjcLge8beBm7eQuzeSS7mQ+wud i7hAUbh/cQAIUAZw27ZlgboIQAanOwqtu7puu7lyywZuO7mKO7gEIbeMC7us67qPKxCFW7nC O7sCwbsFwbr1OVK9Qby9sbjiobfR651HawtU0bZ7Gx+hi7r/lDu7oOu90qu6irsKAkIGcIu8 a2O+nqG33zsG64C9oDu59lAPoFuf4hu8nDsPd9Csmfu8m1sG8ju8ziu6OpG7otG48Tu960u4 m6u6qku5uIu/eYu77qvA9iC3rbu5wtvAjRu5diu/8QG9Z2K3lnu8oUvAOAG6GjwQ3KvALWwP LYy5b/u6Cxy92TsQcmu3eNvCivu+0ru+hgs+gLu3pGsW6pu7N4y9KJwTbbvCJ7O9LtW28ivF JpwjUFzFRlzCVGzD6HvBHdwQ+4u+cnvDNezFklHES3wTBky5NyK9CSzGHfzA4tHGjBvAJby+ IIzFXowAyMtfcry/SkwQByAQpdC6//Irt3msxH1cwW5QF12cxjbRvggMuHPbwyG8wgK8DjRs wZgrGI9syeX7uXXrvJlsxsmru168wqacu5nLygMMyey0v7D8UF0yy7Z8y7icy7q8yxH1yEzx t9RbEi88aK5QTZjrUqBMMKh8HZTcuAL8ynhMEMMsw8HxzIfLyod8uzisynLMy3IBvaDbxmR8 EkocyJH7uSdsFqGLzcxsvz88GOmsx54RxamryjbszReBxvYwyLWrzTD8wSZsuyf8zIRrvKY8 GOp7z8nhvN1sEMNswYqbuu9cxsycI2RQn2UAuXdwxxaMzxNhziFMvhEtIPU50uNbvshcwTCc 0u58MhIczf8HvTb9K8B33NArzczZfMYkrL26K76V/MWcG8weXb5ArcAJjNAaPcmTy8Odm9EU fcq+ktDpW9RenMc33bwgXMQjjRCIbMpNTNSVjEB2+xduwNFDLcT2HMONK8MYLdHivMAyDM3w zMFWXbydAtL1m7fRo9JbHLn0sNV9zcJ/HdZ4q7h1fdYNotIC8cR2zMeNy7tHzb1yzLq+HLkB TNVjjBD63NHCe7hbvNlQrcLyfLyTu9GcTNWIDRngPLcPHL+WbMmt3bmxXdpx/Nac6864bcJ5 3MijzdlHfc/lLL28vcqd+9ue8b+T6waba9ipzTK6q9ayq8NXHduoXMq+7Mp4i7z/crvCrszR f0zJUS3dZtzd0gzQu+vZBn3BZt3c9xPPLgHSMmHT7J0S1JweIiwToD3f+h21VbDf/v3fAK4T lR3gVCFMLlHKyQwR1z3Ky5wRrjzR6zvOqt3MQq0QA34mZDzMpTzCYw3E/Zu1W2za8J2fLw3V H0HFoLveFZHfDl7iHtzKowzCv5DdEB7cuT3iVLvVAlEPXizQIJzDHfy7rdvgnlveKi3kZLAG dQu7dWvPi+y7TJ7BxUvK6d28GizAjd0WBD3logy4jn3GsLu8QX0Qn5zQ8GvmEF61mCvjZCDS R4y/3Nu+kHvhgZzXPj27wa3JDw3Y7Gu3PjzY8ku/4UvV/3Ve0kfs56J903b+2B2c4NGrv9XM 0Sk+wVW8xRcutQ9O23V81Tctx45e3gwM1x2MvHFe4ihewXKMwS/t1Jxt1+mb1IQLtwnM6vdr z3lr3tpb12sM6ih9uggs1Vs7vHru1kfdw5us0OrMwYa7ya8t2xAO5D/Mw49rznF9x4kevdKt 1njrwJQcxWmuzuLd6t97w4kuxeXu3lR7C/kb2d6uKKx9wnT+w48c4oNeFmWuxaGLvV186Qqt 3e8+xUEOu77M79eRAF380MA8wpfdxguvtawu2rNt1J178OuNxn/85Vhc6twcz3CM8X5c2w79 66I853Gs1Jy8uuh9w4NsD4VMBv8yns6Fu8I2DtyDLuFTW9/TPeodnuCdLNOYjOj42+y0fcNl vtzBy8pwu+FWzsJDnMySHOR+7uEYb+T9G9fRHfV9zOCFrfUEbhXGfRGy3PXHhPMaUcti/04V fvZSin9q3/Yy1QNuXxLyHfdA8eAqnhMPvbslb/MTseEET50MjtoNdQbW9NnfXsDoHsogEeLI XOLke+LOzvcojL5oLOxM77xAHtVKXrlDLsqbz+SKbfk97s//3OFYDtZuK+Ve3L/9HLr3ThD0 G/ivG7urr/M+fvkfjsWk7taUL/hey+clXe9HHfv/6+3uPOw0j/yL7tJu3vjFT9Iorcdn/vwn bdKmjuv/By3noFzqzV/knK693k7BdqzAOO61hC/Dh0vrY6D6nc3CAu/Mzm/KGn+6HEzHEHzV xv3aEozBLyzZJl8fAEFmzMAx8+z9IrPO3sI7YxIsLDNqob2I9ho+/FWQosSDGidaJDiG48WO Bi9mVPhR5UqWLV2+hBlT5kyaNW3exJlT506eNN04ROgQZMhRdsbQm5jR4MGECBUqBUnPacmo DYkiqAgyQUOkWocORMp1oVOoTNdhHSkUZpmBCsVC5FjWKVqGDt+S/Mj2YUODWUlyzdpT8GDC hQ0fRpw4MUKObJH+fDgR8kS8F8WShHxZ6E8Ek5N6rIg3YufNpSNzrQwUNEeW/rc+8rXnGbZX rWVDqw08dkxKrrbTDoysWPhw4sWNH088u6FbtXdIY9wqFOrkilOpS5xaOTpGjSSVTp26UbJd 6d3LmzyqskxKlHDHnz7vFap3j5TTZ5QotqzVrsj9/wcwQAEP8ywjodhqi6mBOPoJOLOo6i0h CNOjiKCz/CovpIcQBKuugRCQMDaCIsPwIc/sGxHFMUBMaaEGcUuLOw3VC2kpA1MEqcUBd+Sx Rx9/BDLI/8rKKajghEQySSWXZLLJ4axyUCcjnaSySiuvxDJLLbfksksvvwQzTDHHHLAbMs9E M00112SzTTffhNO/O/oLs8EjqcyNpRPj5LPPwhCi/qeMOu4TaEEVm5sRpgaXik3HwSYTa0+c JJVJNgpVequl8GyiVMQ7/QRVzZ/6uyOyUaNCVTM6ETryjvxGclQwIscKUcpaadr0pU7to3Om XJO6NVRhyfyJDXrciBUyxuqSioy06HT1I0Apcos1PUNKaTQyTEwRylFYDApHF7Edz8FwHUQw pWIHMujcFRPCiqB2g4VSoXXre5HEb8kAMVEFU0wXLhBBXEOgfXcbNuEky/gUJPSWysyjPctg 1J4uVEsgo4ZpVVe1tsLLCsPH1JI2RGVDzKrA9E4iYxWmGERUKqSWzVS+Zl1eFmTsLPT02sgy Csvj3TS70FqFj0bSToik/nM2Xoyc7SgkcwvNeNsb73zLjfxgnKg6iYEKllkXvw2sulrXq2s7 qjY90TqSp0ybqrK3/jnsByHijTxTD8TObqT/9lFZhB1uz+HXjFZPKrB7nWyurOSS0LvIL/2o 8aY8yo5CKBeky6u3MieoWUc57CtGyIvmlaW7pCY7Lgnnoxxw2XvUa7baQSOZoopVcsMkukvO O7qlUtvw2Z5VCs8yRLnd+0jfxoXvWNNqHm+e54mf7Xje1dpTuZVNm92eccL/z43oU/0+6FVz fy1bg5DF9D6NLOWu3a+LV11+9Op3L26L1H7euFj0oLZ1RXn8o8/7SJanrrGmMs+Bnnh+RT4K /g7HXXULHa0yOBOtoShZIZnZrfIVt+SJS0QbPCHJoLQhC3UuNR+CF4eOkitv9Q8vI6ShCb/C wo+FCDzm6VUFhbimWS2mPkNEYhL9hBfhMFGJT4RiFKU4RSpW0YpXxGIWtbhFLnbRi18EYxjF OEYyltGMLWHGGdW4Rja20Y3HMcIb5ThHOtbRjnfEYx71uEc+9tGPfwRkIAU5SEIW0pCHRGQi FblIRjbSkY+EZCQlOUlKOkkah7lkJcEoDH50MjKc7CQ/wLGQd4RSHfYAZSdHKYxTLkQYD0ll KI/0yonQciGmrGUoZfkRVtYSlroEhzlaaQ9zQOMjo0RlJ41Zk0wW/6aZtUQmMfkBy+DYEpTL jKUnebnLZIYymtVYpiu5yRJwqqSUnTxlNqfJy2Ha0h64JOYwi3lMTdpyne4k5Tr/QQ1U3kkY 0vjkLBvmTlqW8iH/IMYwXTlQgC60nypZJkLXaY93qAOhkTHHxlryzMFwFJUNlSg1fXnRhWSU lwONzD0bJg2CflKhH2FpcAxqj32elCX/DChF9ZnQhUSUGBOtaD0PSgyRToSkNj1pK/GJT182 tRpHmqhDV/JKpRa1qfYQh0nt8dSHbrQc66yGNu2RybCu85z8aKU50LmQslZTmVNNQGTEQcuW dhWuNx2qVSdSUWFe9Z2f4msrj3pXuFZ1q/5QLWpWI8PVShYUm/6ErEpeydWlorSp7hysXU9K Wb0elqKnPGVNEfpSpPbVHsu8pGnD6VBj/uMhqmVrZDz6ytQmgK7VTMBoW8JUh77jsSvhajNt mdnYjtWvkkUpZ+1KUq4GNbT8rKcqc7nL1Ypzl7RMp0BvqkuVGpWoSEWuPbLbTW0GNaM1tUc0 QfmpTJKUpNJw73cnwtVwxreos03AU/l526uuN7xTla51xUrWnBZXJQTuqUt4+9DxYva75s0t dKNJyVf69rh//a9Tbatdwj7UwRwO71P5C1H0PvUdn4rqQoSry4dcMpYPOetD2kredYYTv++Q RoNxq5IUL7jC4f5k6lnRKlXiCrmVKQavTUVs1aNCo8QJOLEmH1oNw3o3skidK4jBS0vG3lLL V82yZmlKVHGQMr+f6rKKF0Jc+Mp3ImCVqZPdrGY625S/df1Imn0s4yrPNziZdCeSu3xJ4l5Y qmFO804TUGaKnlnK1uzsTGvKVFuG9ctSfaikeZrkq1pazMRs6ELEAV3xXriZpjVpatMKZWRW ODKjRHVuH1xdzXI5Mu9AZjsv3dURT6SZJIX0Sn79YH2S+tNd9bSm5RlqrBqbwreeZiyRGWMa rzI4PbYspuHJaW3/0pv5jIxuxzxOX+f5rcbd6lslCg1qPISbZQ1nJ8WBX5tKlB8+Jf/3sW1p UGnj+iN9TSVgJ2xaahvarlHdtk7DvWkpN9zhf+NuxCU+cYpX3OIXx3jGNb5xjnfc4x8HechF PvKHl9zkJ0d5ylW+cpa33OV//IUkeBJzm9AcQDYfi8yLpHMp8VxLbyCARosTANJqShB3ugUA lD7MXyhA6ZBoSQWgPhYFtPIXR1/IG5QOgFE2fetcv3pwvL71rjsdAFNnyRvQbg8TDFPqSan6 WLBuD60vfSFJt/tB5h52tX+k7WNXOjgAr9HBI0/mVfiZzw+i+JXUHQBFx7mvFB/5nDh+wtLy OeVrovm7Kz3oL+E8SxC/ktDHBO+fL9Lc6U72g5gdAD+bu9T+Ty92s38+7At5uz2IIPSkqJ7u qCf6QgIQGVN86hdSEMLPhCAJjGAd6MTPmO9vL/c7DX8hxTd6cHY/FuQrn/l6f8jzF0KJ30cm +NMP+/R1H33nYf0WqCe9++H/kdFrivEfEb89yE/6+4O+/zvJP+zjP8zrOZdQP/ubifojjAO8 ibabiABkv9Y7pdszAWQ6wNvrOwqMpje4vOz7iAoIjveLQJd4A3VwQL2zhQnEOuuTFulTvQv0 PZcAwbtDuxI8watLQfBbP5WYwbsLOvTDuh68BaiDwcjYPpa4vfSThBIgAF+QBArYOkigORNY upgrAQAAgk85QrjDQoyQBJujuav/awOlSwAqzEIr7MLFc4OtKzqYYEFpcbosXLzWezq9G8PX M8MEcLwJXMIm1LkAuDwlvEI5pMOzm8NDpMLHq4AotEI/xL00ZLu8Q8KjQ0NCtIdFNMSW2MI3 pD4fZL++68Tea75PXDt7KADe08FQXIjtCz6XQDwwFAQEqAT2Y8AiFEWVaEWY4MCsG6ZX1Lmr k0VadMEj2T0gDD9kKsFU7ERQnMRjbD0vtIf6i7khXIh2aLqHoMYWvJMZpMaYA0OZa7pTSjps lEIFCD8i5LlfSL7Ni8FLJMc5nMEwjLtxtIdsPIjku0Z4JK30M8d6nLp4BMdflLlsbIdo/Jl+ nEJxhDqC/zRASuzHbKxAmMC5WlS9YhQEW1g7W0y/iyxFg4wJ9TtA6xs749O50Qu7W1CHk/xH APhB13s9kHRJjDA7obs9aSzJUURJlUQe3xs+Y9RBk4zJsetAONw6aJxDm7THb1QJe8y5iSjG LxTIQ/xGWMwYn1NAmcjGRfxBnnvKJAzIpjzEhfDFnKMAyKPEqPRKqRzItbPJnEOAU1zFBGDK 7FNKU+S9W4imrGTJEXRHr8vIYWS7sstEv0NFkPS9LaxHS8y6r1PBh6gEX6DEvYvM9hO7drw7 xVwJEMQ5x3s8HXzMoxNBbfwIi4S9yNDMXxxGZmzGe6zKpmxLTGzNsPTEj7DH0/9Uyrr0Rp47 RZqrO8WsO0hYw8FMRZ3EvarMxjCMyjnszdj0uqFUwqY8zq88RNj0SLUEPDmkTrpES8ukzWgy RvWzSATIxQs0u6kDxlxcCBMoTN/rwXqcP3dUiba8vVsQhRUsTVtUxcwUOg5MRrFMPB2kT6xD TPj0RJ+kO3DoT1usgDZMxdN0zf/MOilMztGkzLj0RqxDTrDMTeqbxs+7SpkIAFrg0LnrSrRM zg59iLFcPPE0vrNsytvEUJ/ru7ZcUbhsvI4URRjlvchjwY2MDBHkx9IUzRztx4n40NV8QOAT R6tbx6TwOdLEvc8TPx8dUmWsRyalSUmgAgi10NiTUtT/I7/8a8Ue3MWc29L8TMJ1NIFSTFPm lDn1zDlXwEbBm9AkjQzy40Z0VMeHWFO1zDmbi8iYc4Oua1KamNIgfMeYQ4Dty8ATlYRBZU2l vAXMfM5DZFQiVFOoe4U5ZTsITcjrS4BNrcdR6tOddFPcm7BSpVA7Bb8kREjnsz2s61NbzD+7 ZDscpbqt+zy860zhUzrMLNP0TMm5C83VszvAAzvXa0KXHKUA+FVUzL0D9bth/VHUc7wfZcOP cFbhvES0Q1bBmzugY1HkMTs5vE2nk9DZq0uVuFY6tD2ZqztWkM6pLE+3dFZIOFOb2MNcfdd6 VDpRmFeBFM+z29K6fANLPD0n/wRLvAPYxQQAefXXvaRDCQVLTFxIz3sIToxYRwxLTCTVjjxB h+3MwktFEyAAW8DYWQVMtpNSZNJYQCq9l0NAxGBAANm+mE2Tr+OS/pTZmeDZw6hVAGnFn+3Z orWiKTDapFXapWXapvUjnGUSqA0QqTUMqr0JqyUOrHXSKdJaAaHRmtjXAela4fjaj/y/zTvb naC5sp25tCVAzTvSDY0Jtt2SI/W/6iy9posmk0XFxKBbXQTTHRlbxfhbC3LbnatOsf0/u5VN V+zbK2FcmCjce/w+ewiA9zQOTDy7SgyORcTMHSRKcxWEOyzDLuRcYx3ZJUxDIcxI1ZXDsE1E hWrEh//w3M6tw0tMw9PVXAmlgB8txdi1uW09Q9e1XUIcu1IM294j3Ty8zSdkxMwbXTLMQzrE Tt+1udolvXqdwqXb3UZ0wtNVyu4Fxzj0wkG8k+QV3qpkQtqFRNwV3eWFROzV3SjszvREpr9z 3qc73RZsA2ysT/XFXMI9yHdkO4U0VR5M1Hl8PX/MR9Xc03ykRrxMT+d5yIxMPoaEu8hwQIhM VQOG4KlDyvs9EoKkuQW10AoWVn8szsZNikKVQH8lx+bF28xT4HfM01EV1k+dS/hEToaURoT8 wn5sVLB8zQQmYNJbRxNev3wsYBVu4m6sYRXeYCJE4cTd2mj8vrH84SOWO4X/NYNacMjHJQwa tTkbRcy5xLmn1FCodMojUdEyfggbXeP4lEscxTkzjuMjweO6tMm3zGPa9NYvJNFTtdUljlHH JUDrNNEZTuSp5Mo/fko/jkvR7GG29FQ2btXktMk0JmTRG0E1Xgg8LmRQ/kZJXmJNbphXFIc3 yOO1veSdRIAqqAdKqFTkIOPx3TrFLFYanAgHVeQ2NtbhBcu2C9Y5Dmb2XeArvk6+XGY+/k9i 7kDYnEa0I2VcftbobLxnbWSBlGGbDE6KVcva5NM6XrxlBuQXlTnqvOU7JmSkRDtf1rzltEdS dr0zrGdC9sZ7dmaWUE9WxstfKDNXNmZRfAMpoNbB/92JWw5ljULM6avmP0VNufRQfNbSO5HU iX7A1p0IObZSjt7nOYy5fL1RuT1lsPToOnXPFHUeR01LgZZN3BRkI5xTVq7RjZHhCGXkco7o tJxhh+7k2VTRkl5olTjpNTZlY7ZblBy9AshBl15XDsVHF/UPOPXTJrYHAWRV/YPPbmRpndvF XXzgCY1WZYZXQg1VTr1iq8a+CuhgUK1Lqr7ejhTVf5aEcQ3rYW4l7LtUdjXrbf7TTJ1DuM48 R91qav6+T73qO9nrmJNTHBZsiLZf1rzVCW7KG35qad1Ty8UIfOS5E8Q+z6ZotSZkqkYeKdA5 EzjsN33lKq1lVRUOv1xXi/9Nu6J0V6Ok19u1XILtZNIma1/FV7nE2ER+xMH02OFGRw1FV0D9 FHUdSKWDAqnGOdmO2IbFRd32a+VUOoiVx80d7Dn2OviLyOnE7Ylg2ICcvYm97cGM119Mblzu Vxa+1zPFu+eOTePu5TqEafvGTXTNzFYKze0GZ8ozzPp27TMZXI62EgQ320hCaJg73MYbSicp ZphIxAA+pAoXY6fV8A3n8A738A8H8RDXogaXSBdewAcfkv8bWxJvE6hlcSxx1giXSBQ3DpK9 W+HuCQWXFRSf3MHIW+mkP5KU2h6/krGzcBencSmpPYyIFSs+jJBNQC71kfm08LRGDB3vCauN 3MP/+HFERsLD3fItwUBcRfLiGPOXCHOeSHM6Bssf8WnqPUj87kOFzW3TFes0tDy/k8TFM18+ b0lIPN6qxt2zg0L9xWVzJV52zdb9DXRylfNIVMTnZcLvTfTwfV445/P2/UD8Jl87lF477/N9 1V3f9UBXzd0nJPVBl9A+n12ve99PJ0TspWSptthC5250Xl/31eA913PT7fTZvW9D7/NH/Nys db5/JGCAfEZ9tNDknOIPDMGpK8gMpjsqNs1kh8a3nrAiVuEP1hR8rGJlR2CQlgQfHuByFuLj PkRuh2IujuxeTmBxXOAhbGALzhgUluBOLXVE7fZyF+HApPZ2X2Eolvd3/3z2WW/N8PZP7y7S Z8dgTx54a1+JLXbig0cOoWxzKM3Qch7kuhRlaSVvO37kddX4gB1qI008Tr7sINfRxm3pcrfk NabKjybphyZqsRv5rgZmlPf4P17NQM15SYZLOb5plXdUU25oWe26uuZohWbnuNzhiTdKoWbz qv744+C7qRNnbP7GeT5Vc2bA7Mz42Nx68zT5A3RneF/55ZRUs19Kty9hMsxpkt5NVM45cb5s 9cN7nZ9ktnd2dZhwoszEvS9gsH7BRXbivmTpexZ8s0f7VwZDxhd7qU98X676c83lDJeVIGzM ZkdnyO5So0RwKMc/jc7kUHzolva9Te54lA7NN/42eb/eTKhb550+5J5u/TZXRZ+Gaap8fYoW 6fir0JIO6VHsbar0fLU86gN20sfvxI0vZHbFVY/k/ftT6OgfEgxNYgJebIEVSXwEbNHe4bme MJsDa5674R3MwPBna8Ks7ERFabDmbLDca5Xo/saW4MfW6cjO7FJ9bMsGCEn27P0SOPBgBXAH 7VVIYO8WJIIGCw4sSNHeG4UZCQpJcPEiw4gDTYg8+EuQw4UNH0a8WKFkQpMTBYJcCVFixZn2 TKgbaCplRZQLKcY8aCLlr447Wxrc2dPez1cObykkuXBglZQ2mV4diVSnU59Au5Ita7bsyZRv CHhUAIDtwFsAAIiiqf5TLgAoQt/MZdW0wtyIJuYCUBh3LlyTbgGIBPnLbWK8dQfyBeAX4VyF jxlT3Az3Y9ODARhT8QhWcujDdO3i/ewWEujNjA9WvkzwdWfIDkGTBVz49tvdYC0uLjkaUmne XkWPJSh0qG6cO8f6BsfbcXTlLgNfTTvUYHXgEWvbVcm9tcMAze1lrZg9tXvOYBlyP2v/Pv78 90Hqz8+/P4ABCjgggQUauB98+RXw1YELHvgghPr9FyGFFR44WHAW5qQhhx16+CFZE+K3EWVP EUgiiCn294aJKrr4IowxyjgjjTXaeCOOOeq4I489+vgjkEEKOSSRRRp5JJJJKrkkk006+f4k lBGKeBACFk6J339XgqgllgkiWONohon2m4pcSujlmJqhSaCZ36G1pnQftvfgnFzWCWdZc7pp X5tvdodnfk98KZOBncGnp0xt3gkhT101mh+iA/aZJ4NmNWoRoABOGueffGZqYKQEhmrWogGO 2iWbqW1a4apdXXmqousdGOqpZNV6ZoGlUkooq59yuqdZrV5VGQA98ebbbJsBsZsgbcyVwGDL EtsTsrCBV99A1RZUAgDLYubttPQFti0BvlzLmBuEGRtauNt2i1Rxf3LrLXDenuQsANC+m+2+ KqUEUW7YAkavsuvJxhWG6mgrSQnlSuKuvTotXK9w8xrslrcY0v6701zeDuxQuBPjRK5DH3dK X8QWj/nuwiovpHEtDz/c7LPROpTwVTiLa63LKMPL3XXXEhzvg0mZtiF7QG11W09yTVWS0Ulv aIKYV9WpwNMjNV0SRw5dLdxOVVfUkYhGP5Y1Q2BDh/bSjzWdL0th3bQQVVoTpXajcy991UqG zt2O1LcJdzZGXEm3aNtYx8032rSmlDfXUZea2+Nbdwq54ItX8BQRXsOL9kLtYer2Q3BD9Dfd IgFOtWJoY572yDpR9HrfvtqXlXK6dq5daO3diYCDtlZ6UfCdh+450gUBLyvuXja/oXdZyt7U 7sNJsvxAxi/kYPXRG1T80dmP5b1Ec/5jNbzMQYV/0Z0gVY80r/YY7/hA4B8feNAH2S8T9vKv T9Nz5oe+rohOZrwzX+q2BxTlgI98Qevf7oQirGF17H/niwtMLIiTynirfc8h4ABlsy8OIk86 FvkgRir4HxLyZm7S25D5GsI7EW7MKzcpiAtpsph3xXAsOcSJb0oYm6YsKHdf6aFyDtLDwN2P hiCrIP6mFx8oJmqHy2phSQSYvEMNLn0mFEgQ+fYs72wROBX8YdCc+MMC3QIuuJOgQeoUQA3i 0I1CnJmsooi04MXFjnqUCBkfYkf+tNFz+fvVdebIu/6RhSpv6OIexzfHPRmKNhGZnBfTQr4o kvF9iJwk/f7swUdBIk+OCaBHJeuXR+WN8pD+++OECoipMlKGa5YMJAPHJzs4SoSRXzTQRsym FKtMByFZ450bNDNMBhXFUQMMC1QSEMxlljEmN8CIMsNHmWwqx3hvsKVy2mY9aP6kK0SQhHAQ 4E2RPKqce1vIOiXiiqlUBX0XYV3UiHmUDYkTfsZcXCjbKc1sFrNrS4mTQN0kUOWox6D7/KXV usi7eT6kalKpKEPEpJyExjOfCHtKOeNpoOOUJoWWmchrgPMZ6yGApLvBzbnEthlrwc83InGp eMKZGXu49D89Pc1cJkNJlGaId/yajaMMQxHUYAapnlkPU3GImJfKJycHo01fiP5K06dCFDoZ YuJB9GTTgeB0pia9DH/GuqexKgcveqEqTX8ltdFZDz10m+pRrTMftTL1rOXZmWqEGqXBEraw SZqgYROr2MUylkYYSkxjIyvZyVK2spa9LGYzq9nNcraznv0saEMr2tGS9kZhKprtBkUh/iAW sa4KTWtTqynZYta1nrrta20bpEehtlcAIpbY4idXXI2IMMH1Z2z9dCDWppYit+pQqKb03LBW SkPOrS4iDejFwk6XuFLy1VpSUs7XAitAbQqvWEIEW9oOd7XsBaGMuktdSGHXt7BK0CwTq7G2 7ItkMmlYyfortCfO5Sk6M9l3VLaSxTHHVRgD21XvVf+zd7WLYQ4j63HJejEBm7ElNMuXzSrc MHNhWKEFHsqH9SUtdUknAHqFGFBG06+cUIAwgjkxVnF84PqYDMbiQqpVGbavalFMjOMS8sYQ bJIU2yxoNT5yggVM1yL7GElzSlxzCCe3jzK4a6h7XesKh9GCqq8r/awd00oHOrMpjigt6g4K s3VMMEJYAW9bM9naDMY341B10Lkzg822Z0AqTm+c02XgUOeqjny5apgj3Nyi+7BCi0SsoJtv 5uYGZvcAGmBS1FXmvglI7cLuhpROUgEP4klgNfB6+zsfAl9tQqE4aJR6C477TOPAcVIXNBR4 81VuzZZcnxDCvD6fr4HdZ/X+0hLZkvh1kKE3SULNCYHCi/VYWo00SRsRftrDdC7FN9Rox+6P yUMJXfPrvyQaqT1IhM9HrKhreZvUY2Okd/wcxBMUldk5CXg3GsfJQqJmuN9pAXhj/sqbgccn uER51rg3qEK3KDWTAjHft3EiVogvhITi8sgHndjtP418iff7pRMjnt9K3ildVVVluiXxbn8W SXSKhDcRdenLQjLxm76kJBxLepWG+ruTupbiF3n+vF4SvSxE1+TNDwkapf+vpVluiqh5NfVB Xq+hK//rK6ndnKz3sYSFC6QoEX04g1n8gv4W98nDzewv7trcsz766G5OcyJdec7k1ZpYZgfS gXb/7aJ1SyivWJctW1LmM0IRpzpBZjjQJLNrLcwY49HrHch31HqVFzQMa1gQitZN6zP5PNku fsW283Q3SiHUQw1ftWkmQPYZfdngN8p23f/T2gXd6OBV/rBhIgy791TTlPvZ3iBdrag4N0+y znVT0vwbr4D1KpDJTEEcc3WpQVX4TFpKfeW8YVnE3H6x4rPS0q0Gosr7KdLKv0CZW5+W7x+/ Qcofs7bO5a1umqldLYRLBWB4AJZ2pFSiDEdKcVV3wFRNYYv9CQR5jIwDKkZ9xJxKqY1ulRZZ jBIH+sgGfqAIGgm/jWCOPFYeJZY8mCALtqALviAMxqAMziAN1qAN3iAO/+agDu6gi0yJunEI c+XHaaEKDyZWCALhmvTJEQKJD24XEpaXpQDbWSzhfYBaqgiPi8jXfXGIfAWLqrwXndTXyajW 8p1FF8ZIE1Lh3+0dFnpXipxhrqSghWihHHJhHZJhjljhGOIWqNwhGhJNwYyay6Wff8WFYSje pTyYRIyYDkFgfGQMFaGchZmLyojYjAUFvqgYVdkblAVilf0Xh+3Mk72coQCYz/SGgCmYjfFL ygCBBNjYIK6Lj0kYiPVLjyFZgEGgJQ6NI84OjuWEyvgXgu1YygyZjRUEBfxL5DQiL0YMhmFK z8hYDRFZINIImpUaUzhGnl0dVqCT1GAZEKmNv/8AFDdS4EtJ3lBsY5elmdPEzd4gzjGd2tqI 2exUDSZlzpY5iuVAWqUBxaMpDlhZ3qTFY6cJxj7KY62wGduIY04omnugo5ZhzpcdZOMc0SEi 2t6cmSzK4+bAHaZhI43Unfj84NJF1C+IwyOlHbHNxCbFjxaNm3ag0NK9EN1Rzx2tJM2tpC/d I0jIWtqNJFjoiba53fF8nfu5Wkp4EvvI4UwCEEOWD+PFyaqBD7YB5bZ9Bfa00natWvVA26hJ W1I2h+74oYb80LtRBMM50yNRxUkymAzNxBopUQYFpNTlXL1pkOk15Fzeycxll6rpmkyGEFFF ohm9y8iJXFPoycDVpVX/ydvIbd/qwVDCdUoYueT60FsQIeZVTo06lOCyyRkSURy5LVUWiaUy /pOMJFJYYgrVicgtqEN7FIAtGIvefeUnhSVd8lJM/hvX5aT1GB0n1SZNahIexZ1u2mVZaOVm qhKwVBvXMWYvKefadUVrIh1NipnWoRtyDgsk+NJh2oXQJYoi3ZzV2WYqhR24TZuMiJQ4FQTq adNQSIFBmIA3giRoRB52jmOkZRnxQRTr0B67HSVI/h6dxU2AXkQwgZGjIUV/ggTiGUXugcVD kZM2PRSAtp1RLZSErseFIo1IyQTpVQ2CakYhQKhY2J6GIs1DuQTj3Y3m+N0trB5DuV5zTOg7 /8lIX3WfzIgfcsCnSjwFz2XgL/WVVyVGqExgvGEL/PklykVHTjXi+iESIMaUePgVp6iVkU2e Vh2V4YgHjyYHhvIaWylg9vEU/iENkTZk/XWYP40VAQINmcbVhBIKA+ooZQDB/gFVXsSZWTFg EUaJGv5poOKHB24JGP7pkgwqDyrqWZSgh6AgokaqpE4qpVaqpV4qpmaqpm4qp3ZqpZ5Wq8Dh fQxhoRzqFJrqHp5qh0yKsDAqjighqqbIpuAF3ERUf/CRjEGWif4gEUYIby1XrIJbsLKhsK6q QOgh9HBRbgEKsppXgoiqqvZqYUVN1JzcfQxGYvwCO9QSfBGrWZRehP9Aq3JRSLMWiJaUK7AG 5Ny14RqaIVnOyrtKa7R+SLhwKVnBabIK4yWSkpxBX7IoYgcaDArBjAEx2b7ozD4t2K2BC4sV IscYpiI6rL464ynWKzE2R8uk4rBF7HxIo2n0zFHJR88oGSZOWGTGzijGlQVG38MqzDFOoswE o8S8LJXhoryEok2lbNCYIslOEUyMUMMOK58MU9WgWRoB5KYt3joy0Y0qUFeQ3XyNjp2pGUso moOU3j5tmkJ2KzjOYz4KXpcZzUQu7dcYKEAqn0scGj9269rm459Rraclq93Bjt/4WdkSB0QG JTPF46WFGsLYYwghreUwjnRoberBSGwu0HH/5ityZhxGQIFbrMdYBmxXNF3UklrScQ241ppD yFpJNpFNTkhPriZSemTSVCV6uh10rtsuke7e3eNPpu4MfZrxHScCYdJHaOdyqptSfuFfstJY 8GTjSpLaeK6PdggLfVDAMe4UXaL5WG6izWVXeGAASKEssd7DwQ2LQGgw0Vta2mpfUpJjThph MKwx5kvKxR3S9SVp/u58FCsFlq/aDZHctlxgLG8Y4W7OfSf7+i5Qop3wNm8NoZH3qpDQNtIg hZxuHufolgWK/Cr+qKfTNhgWTllXiZqeFITQ2VpvwpfRie52RqcP+VEt/Zz6yu3brdviWqVc wW6hRmDdgZorYbA9/00EuvFScLoukxInACPFCsfu3xHPCBvSAT8tQTVT6xlog27XgxpUEr+M 0vSt/sRYCl7vRNHTf7yEiUZTh3Kt341higoU7aFo8EFxGdXEMfVnEoOeXK2ohJYxDC8xgV5F 54XoHNsmPqmxG9vn+0pHgt6eUTDozXRpE79S1okxNxVx5VJfXrEfFORfVtmmvQYbYWxYSzjp y7AYrXLc5Rpl+UzVa+YMddTHktqqkIIw9BmOWg2g9WGpBcbVeTLgBDqy7srVTCWRKwsokjai ygYWa+DVLbMk0Vjpk55yH1+VdISHWe1yKlPn9zXV9PWoqzqrZs0pEMfgNGtWNhvWNvvIKP85 KgtCqqAqsqeWszmfMzqnszqvMzu3szu/MzzHszzPMz3Xsz3fMz7nsz7vMz/3sz//M0AHtEAP NEEXtEEfNEIntEIvNEM3tEM/NERHtERPNEVXtEVfNEZntEZvNEd3tEd/NEiHtEiPNEmXtEmf NEqntEqvNEu3tEu/NEzHtEzPNE3XtE3fNE7ntE7vNE/3tA1Kw4wA9UII9YAQNYEYtZG8Az/E a4X8AzFIoU93RTVAw1APSDXkkVLzAz8UHFIjNYB49UFo9VLbB1iTxVWTRVnjh1gztT0IA1Bk 9VYPhDCs9UG49UBMdQLQdV3rtV3bw1Tbg1OzNaWuYGZJQ1/bQ1r/28dZd4VSp4Q55FFXF0hi H7ZZJPZCLDaFUHZ+mIOJNPZAPHZbp4QwPIVdm4OYaLZdvwNVh7Y9mPZBvEPBRbU9vIM6cPZB SEM5aDVQzPVYI/Zt+7VYr/ZABDZZ8HZKCDVvr7Zb67Y56DZcPwVuLzVQO3Vw2XV093Zba/Vq E7VQNzc/qEM1BDdi53YCCHV497Z3Q7VcO8R1A8V5CzdgE0NKEPdVHPZYu7VqLwRqi7ZD4Dd8 E7c5wLds+zV717VD5DeBD8R2/3aCd4VmN/iCLzZyP0Vvw7dd9zVQV4MUXnhKrLaEDwR3Kzhg OwRmY3hrP8VqU/U/yCGHi3hrZ5hRP3hf/xO3Wwv4fq93aAt4ggf4gFd1gxO1dQ+3fPs2iN+1 rHi4bhM5cQO1iRO5kxv1WXM3NUB1kBc5axN5iNsDfGM2dxM3cet4cRd4kdN3V1QNkt+3e/c3 P9h4c5S2Ycy1joN2jy8EXH+3lX/5QUQ5g2O2fu+2Qwh3lCeAcAt1lvs2XIt5dmdYlRP5oFs5 kZ83iQNFiPN2kkP6WSw6cudR1Rx2i8d3fyfAU/d5fWu3gYf6Qsj5nBs5gwP5p3v6lZv3epB5 iy/5kzs6d+d1pD85mYt6lmd5kw9EfnP5be/6a4O5gdf6lXcFUct6qw8Emif7jYs6ZfP5nC/7 kHe3YSy2cjsEj/+3tqx4NmtrO4gTN4IXujQkwJsjulBj97GHOLlve2tT9TukhEKgeojbtrfP +0DUO5hj+l0fF5mDe6f3dWr3dmnDu6iDO4Ab+07D9qn3RHLrd5LPtlazA5CvOWOLtYkYt5Vr tTgQOoMjtlOvOTWoO7Cz+1oXuscLdVZbvLNPPJwj+3u//FITuz2kfMift9jg+8lrNWnr9ZU3 d14zN8Ife2uPtcPHe6qbs2UHyIPDiM1jdDK8iFhXvdVfPdaL9ShkPdd3vdd/PdiHvdiPPdmX vdmfPdrzg083/dK3vdu/PdzHvdw7dBBKChh2MwtuYKuQan/wvYb4PaYC17iWIR9S8lf+Db67 tise9qBsQSu0msmooCtZQLB+UD595YflXyp6RdO6Ev68ukqcKT6pCPaTOL5gQz7ziOHtkL64 0qGnQm/NsiktaqKIXRhPyZR2ukyESWiBtYztD+Mv4oTOAKPGBlgxmi8hwuwneqy/XvK+tmy1 xOIi9gsy51j6EVlTieyM9ex+eaKFGf/NdEzMAJj3q2IvKuJ+bSra9esNFWhuFKRJqKObgX5b LGS54QTq3K1ASKSfyYRD+i1A2PulIIE9eybU2bsFSSBBe28YGhQoJMHAgr8kWVQYsUJCe0QK SrRXJaS9CgUXitxosN3IkgZ/UdSY0uRFSSolxixIEqdLmA7+aSJcqZJnzZUaDyakyRPpyaNA IxZV6XTpy55XsWbVupVrV69fweKkWQEAgYo3DYLE+EuQTYFoMcJEa5Bk3LcUPKpke1auwLZv AQOmSTekXYwICoQEOVgkRsY556qdmzgt38oi68LNqNmvYqtF7X58yViqxMx99wbuybO06cKc 7VEWTdRt5dCyQfo0HNmy3daqc/8OO5x4cePHuabuPPik44hxd/d9AwAAkN4KAIDruTc6Teiw yQLY+VruQOrVC4Z/GVd9Y96GsVO3Hjr3dPS7u0ecjTkkc6vtpbJvPs68m0siAcdbjTzAzJPv M5T0aw6u+NDTDS3/ovNJJf80RM7+ww9BDFGrAAprSznJosvQMbNc2g0BEnHijrMU/wrtIYZA 0wwxqwyCyL0D9QtMRolk62s5Fk97K0XeaIPpr/1U8rGoW5Ds7aYMJaIyQeFyNLJInJh6UjIi HxRSTCsJi/HMDkVs0803w3qDxdSoYuiw+uyEDSM3tNOpO+v0MhE2PCcqyASGXkFJOxMWjEso e0xJIFGFtIPMFUV/fKjPuR6N1K43tAO1UPxgg1EnlRiVqE6VJr1l0ZBE9XPQgnwUKVaKDuIx VyPt6rRMo1IKzVcLVYVQSLRSxWlVNuFs1tlnezzPI/PmvOkW6kS5Uk9JXgQAEirQfAhQg64t yxfYys3+NloAWLGWujmxgyTD8Bgql0XI7F0vvucMpLch6vQLwFtwSTWyXCiezCnef+/N8t2L 4u3223DTNdAggSf+N0iNsfS3SYZrM8hjpuaitjb4vNULu3uFg9bll2GOWWbibNyq5uNunlnn nXnu2eefgZY5Z6yGBsuEh4NOWumlmW7a6aehjlrqqamu2uqrsc5a66257trrr8EOW+yxyS7b 7LOZLhptn9U+TmDt3m667Z3jTs7itaPu0ivlhsyK74Tx3u5uMHXV6tFH/R7cTRvnnhlxuwOn Wu+u/i480BItD3zulrMqivOfG5f58xgVj1zp8LzFqIQKRWY9pydlVN11JzH//xdQ2cedCmDb bVp93KMBUIfGNqhL4OhxybpdkhIaZot48Y5PwL7g32L+3IsrTT698zZuDDtAgQdCAgdNqlB1 As7FvSSBZ58+L3IrNSF+4a/cV9XZqyfgeerVl4h95PHHu4OQj1fast7yKuS+6gXQdC4DDVQM IpTHVG4tDqnV62q3Ko1cUCLyE4kGIUiTdqRIAUoRz0okaCeHeM+ExoKJTBzCHo+kME1ZWZbn QkJDjVTQhR25TIxwBRm6SGI87KkNDb23Hhj20CO5QeIHXdgaEkKMVkHyEwQbKLpGoQU3+jpP Wc5CHy+exyxiFKNKimRGAulnSQXckW3upiIDJQkj/ngh02U+d0YcGqSLBWPQmhREm1+I4w0F ScxaasRFz2SKPzRaZBcZGRyrtNFML6Fj6bIIJ71Bh0K56wzt1sIkDNrDHXvBkChpl6UIhUs9 lMRPJy2TqeggCGWValCFPsehPd5yQOVZo0RyYysCdlB6CXDVIN9SoH8NUzW0/KVtYCkSXU5y RrCJDa0chKVMOnCLfCwcBTeTylF25kS9AZxyPikabUIkNd9x45duJkcttUhHMLrmx65STg0V BZ6aoSSUFFKlDamDJwWwRUJC6aVvXqhK/8zNlxqzJikm8li0m+cltwmzZGVoWOOMHVpEFdEM GutTlfqgSYGVp760Chyn/jpURQHjq3hui0+jIhD4PBKpXUWwezcMSVFk6s9SXSSIPepTUWEi BWQR8S0IIFRSDKJTIWrKpkYyFa46WqyhSBGrKg2MB28VroxCyzzysqbHPCqoBnWvciBbZvda lx23dgdp9mkXTO3ir5m6EWMEg80bAOWxsr6IRyaroVT0KlSDUQdhVukrj3wYULdU7H4pY+Rj M3SwJ6FVYWCsoTDZpa2f7O5iAxPrWLEWusShlmiYdJZqgwZb1s7WZq6FHG2j9D6XAa9hUeNt 5nAbXOEOl7jFNe5xkZtc5S6Xuc117nOhG13pTrdNvsiibIuDXep6bXSuyadtidPdr2h3qkRT /4BJTdDb71KOQnANJM7am1Dj3BJpegFvzci7XZ+Jl1nQ4m9shcBUewRAvTgDHFf+S7QD5/dy rdVv2LS3wMByr3XKK4H4uOcGaSkJgbcTxPOMx7oI9w91GwOeR0a8PPH1x6xx5QjrTuye/kW0 DSgRhaCMdOK8klZN/0nghku8JOZtz5Pp5LDzihe9AVLPb4BLcYXTw2JHUYd+Apzxg6GlQyxK Rcs/naRMMgLBgbQQhUpRYRR5JEKoBgso83MUSmmoZsjMZGNsuZ4ZaoFjwURkhDfxYJNf8sRC aWiKETRzg305ZoWccCFyVnBJdOjnQ7vK0M5hiRGf4kIsP6uPsJFKp/69K8hwMmhbb1Snp9Mc JFB789SmZrVoHuNLI70OAVWoByX6FpfBHAaiMaKQdiDp3U2K9tXBHC11WroZebq3x3dsNSQp I5ldj/rUs940nHgZrgeep5efdaYr/QnLDAmnleLmlDHzhM5sl++Ec7Ym7d4gBeHpecfiQSRw 1R1NBBG6mseenbqVvS124xt25l43o4J1k1ZK4pTWvvab+mmkT69nLlNq6KjdeSxXw5RzENl4 aFxVSCUBrtc3kvG7ySkTE1EUSPfWCjrvmSWBgoait/lmwkIpRyC9PGH93DilRB4admbkTNp8 uJuCmmNI5zSWyQqrfDMenaR/lUcshSqkYv75EaayB85Mt7q7Ha5uE3XVHizlukheKlK0Mz2s O3WpV68uVXEeeVuXotRB3IvOpHeUCFuXhN2PqXCSwibtRxdRYnm1MHbDfbCYxTix57U7FSme XPVFfAdtiZbwZG93+Tp52HH+F7u6C4z1htskD+yxx2rsIdS5q404a+Scb8vz9mx2Zb2K1j87 5mGc9GyGbG944acWvFVjMFmLP3zlK+0Nuu1a86EG/eVPn/rVt/71sZ997W+f+933/vfBrxqv JFhExw//+bENuwMfh4MIYVzyUUMhWAXJ/fLHmcUGgt4Cz5O9X0QpWMgP/aSrrUAEnYytvLqC 0tqphIxMLWqEAf+zC/8CLCQIDLiSY/2GIwAFELrayjw8DMSUrHyKzCiOon54LMIEKIIu4knm ySmOggV7S4FmbK0CpcYU4sakR1quBV7MZ3max8lYDMokbHt2J8Y2cNPaCoTILCUEzah6BKEE 76sOLaXuyABppVKgzwq3Y4mGwinwSxDuLM9Kwk/+AoRQbzTmZ83ObKuC0B5awrm+4QjN64vK 6D1KLdhGiWTaSZHgCJgwxci88C/CpCRckHAcSfz8otZuDebqQs+qTWW+yJAK4qE8Y9zaUA6R UP3QrVjkaN2mwkqUKds4RPq0sCYMI2EOsPXu45m+UHrkLTVoqS0aDtGIic24TdsIsXjZMPHB KKjo7jBzQIUUH+/VxEmSxIn/gnFaYHA0Lg41UI47VM6YGmrlKjGODizkQiLiAqM1OGgXB1AT qVDnsgoywEUunKqKDC2qoqwERwkp3qIcP8kdnVBWjOSpxqkznq4MB+/2RKLvcojpOCokvs4b p6sDV+ZkwGN3VkBZ2Ij01MXFRotFbiEvbuk/2Mj+cMLxFgsAHvIeUwOzHvD34ohC5OogUOry UAYSPI8gWRJEkiVrYq0lZZJrSk5qBmIEZzIndXInebInffIngTJpTiEoidLwhrIovyIgAAA7 ------=_NextPart_000_0006_01C6B093.A2751120-- From owner-v6ops@ops.ietf.org Wed Jul 26 21:27:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ufA-0008MQ-Qh for v6ops-archive@lists.ietf.org; Wed, 26 Jul 2006 21:27:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5uf8-0001mV-GU for v6ops-archive@lists.ietf.org; Wed, 26 Jul 2006 21:27:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5ucc-00058B-MX for v6ops-data@psg.com; Thu, 27 Jul 2006 01:25:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G5ucc-000580-1r for v6ops@ops.ietf.org; Thu, 27 Jul 2006 01:25:06 +0000 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2006 18:25:05 -0700 X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="308324889:sNHT26195144" 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 k6R1P56f031427; Wed, 26 Jul 2006 18:25:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6R1P579024883; Wed, 26 Jul 2006 18:25:05 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jul 2006 18:25:05 -0700 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 18:25:04 -0700 In-Reply-To: <071601c6b0e3$3ae1d020$247ba8c0@tndh.net> References: <071601c6b0e3$3ae1d020$247ba8c0@tndh.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "'Jari Arkko'" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt Date: Wed, 26 Jul 2006 17:30:29 -0700 To: "Tony Hain" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 27 Jul 2006 01:25:05.0078 (UTC) FILETIME=[7D489560:01C6B11B] DKIM-Signature: a=rsa-sha1; q=dns; l=720; t=1153963505; x=1154827505; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Resolution=20of=20my=20discuss=20comments=20for=20draft-ietf-v6o ps-nap-02.txt; X=v=3Dcisco.com=3B=20h=3D8i9QScjBDH/4ZqZ/rMJ8BMZ0j4Q=3D; b=K4SmZWcAeSSkv+h2Aaf+T2ypVzPG07Sw9srFu5jvI9+akDn+KkbLZemFUrAKrj35j7iGRJL0 jwZffKArda3fdVavQ3DzCYnMriI5mqFUmHcbNkl00R5biGch/c42iowo; Authentication-Results: sj-dkim-7.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Jul 26, 2006, at 11:42 AM, Tony Hain wrote: >> The one remaining thing that I would suggest you add here is >> a warning about the issues in multihoming and ingress filtering. >> If I read Section 4.7, I get the feeling that multiple prefixes and >> multiple ISPs works fine today, which may not be exactly correct, >> see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot >> of text, just mention that there are issues in some cases in the >> multiple-ISP model. > > Does this work for you: > Additional considerations are being documented as multihoming work > evolves > xref --- draft-bagnulo-shim6-ingress-filtering-00.txt I eonfder how many of these are discussed in RFC 3704? From owner-v6ops@ops.ietf.org Thu Jul 27 17:28:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6DP5-00010a-M4 for v6ops-archive@lists.ietf.org; Thu, 27 Jul 2006 17:28:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6DP4-0003nb-CE for v6ops-archive@lists.ietf.org; Thu, 27 Jul 2006 17:28:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6DLT-000CxK-6t for v6ops-data@psg.com; Thu, 27 Jul 2006 21:24:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.1 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6DLS-000Cx5-KZ for v6ops@ops.ietf.org; Thu, 27 Jul 2006 21:24:38 +0000 Received: from eaglet (127.0.0.1:4370) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Jul 2006 14:24:41 -0700 From: "Tony Hain" To: "'Fred Baker'" Cc: "'Jari Arkko'" , Subject: RE: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt Date: Thu, 27 Jul 2006 14:24:29 -0700 Message-ID: <090301c6b1c3$0bfd8160$247ba8c0@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: AcaxG4IBjx6ZyRLbRImQ9gQg+EcwCAApz9nA Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 The ID is essentially more detail on how to work around the ingress filters with tunnels and source routing, but the outcome is already covered in 3704. Tony > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Wednesday, July 26, 2006 5:30 PM > To: Tony Hain > Cc: 'Jari Arkko'; v6ops@ops.ietf.org > Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap- > 02.txt > > > On Jul 26, 2006, at 11:42 AM, Tony Hain wrote: > > >> The one remaining thing that I would suggest you add here is > >> a warning about the issues in multihoming and ingress filtering. > >> If I read Section 4.7, I get the feeling that multiple prefixes and > >> multiple ISPs works fine today, which may not be exactly correct, > >> see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot > >> of text, just mention that there are issues in some cases in the > >> multiple-ISP model. > > > > Does this work for you: > > Additional considerations are being documented as multihoming work > > evolves > > xref --- draft-bagnulo-shim6-ingress-filtering-00.txt > > I eonfder how many of these are discussed in RFC 3704? From owner-v6ops@ops.ietf.org Fri Jul 28 07:04:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Q8j-0001mM-Q4 for v6ops-archive@lists.ietf.org; Fri, 28 Jul 2006 07:04:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Q8j-0002yf-2e for v6ops-archive@lists.ietf.org; Fri, 28 Jul 2006 07:04:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6Q5W-000HIs-6u for v6ops-data@psg.com; Fri, 28 Jul 2006 11:01:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [192.68.245.115] (helo=mail.nttv6.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G6Q5U-000HIL-BU for v6ops@ops.ietf.org; Fri, 28 Jul 2006 11:01:00 +0000 Received: from [192.47.163.178] (dhcp-3-178.nttv6.com [192.47.163.178]) by mail.nttv6.net (8.13.7/8.13.5) with ESMTP id k6SB0b4u087909; Fri, 28 Jul 2006 20:00:40 +0900 (JST) (envelope-from a@arifumi.net) Message-ID: <44C9EE49.4020308@arifumi.net> Date: Fri, 28 Jul 2006 20:00:25 +0900 From: Arifumi Matsumoto User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, int-area@ietf.org Subject: Re: [Int-area] RFC 3484 address selection problem statement comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Pekka, thank you for your comments. I'm really sorry for very late reply. Comments below. Pekka Savola wrote: > Hi, > > (Crossposting as RFC 3484 update is being discussed on int-area..) > > A few comments on: > > Problem Statement of Default Address Selection in Multi-prefix > Environment: Operational Issues of RFC3484 Default Rules > draft-arifumi-v6ops-addr-select-ps-00.txt > > .. which I believe is a good start at gathering bits and pieces for RFC > 3484 update. > > Comments below, mostly relating to making it clearer what the actual > problem is (but this is to be expected in a -00 problem statement draft > :-): > > substantial > ----------- > > Section 2.1.3. Half-Closed Network Problem > .... > This network environment is commonly used in practice because the > access-line to the ISP2 might actually be a VPN tunnel over ISP1 and > the Internet. > > ==> it's not clear what you're using as a justification in saying that the > network environment is commonly used in practice. Typical enterprise VPN > deployments (so far as I've seen) often route all the traffic through them > (i.e., are connected to the Internet). Are you referring to ones which > only > route enterprise's IP traffic to the enterprise? Or that because you don't > actually need a second physical network connection (you can use logical one > as well), connecting to a half-closed network is easy? In any case, this > calls for a bit of rewording. Correct. Here, I just wanted to say this case doesn't demand two physical network connections. As you mention it, this description may remind an enterprise VPN, so it should be re-written "you don't need a physical network connection". > > In NAP [I-D.ietf-v6ops-nap], the use of ULA is recommended from a > security point of view. That document proposes the use of ULA for > internal communication and filtering those packets with ULA address > at Gateway. > > ==> I think this should be rephrased. I don't think ULA is necessarily > "recommended" in general, but rather in those scenarios where you need > certain functionality. Maybe say: > > As NAP [I-D.ietf-v6ops-nap] describes, using ULA may be beneficial in > some scenarios. If ULA is used for internal communication, packets with > ULA addresses need to be filtered at Gateway. Thank you. Let me use these phrases in the next rev. > > 2.1.5 Site Renumbering > > ==> you describe a site renumbering scenario, but it's not clear what's the > exact address selection problem here. Make it clearer. This is a implementation issue of lifetime. As Tim Chown reported in the past IETF meeting, there are some OSes that doesn't handle IPv6 address lifetime correctly. So you cannot achieve smooth renumbering described in RFC4192. Even if this problem is solved, a site administrator have to supply two prefixes for a long time(2 hours or more) to renumber his site. I suppose it is preferable if he can control when to finish renumbering. These problems may not be solved by revising RFC3484, though. > > It would be better if you could turn the temporary address on and > off. It would also be better if you could switch its usage per > service(destination address). The same situation can be found when > using HA and CoA in MobileIP network. > > ==> as a matter of fact, RFC 3484 already includes a MUST that > implementations should provide similar kind of toggle. I don't it has been > that widely implemented though... Maybe state clearer that the problem > isn't > so much about specification but with implementation. Yes, the first point(toggle) is already included and implemented in some OSes. What I want to stress is the 2nd point, that is fine-grained control of temporary address. > > 2.2.1. IPv4 or IPv6 prioritization > > ==> this section doesn't spell out the problem. You probably meant to say > that configuring the RFC 3484 preferences on each host separately is too > cumbersome. Please note that this document doesn't raise problems that should be solved in the revised RFC3484. It just raises address selection related problems that probably happens when a site administrator doesn't take a countermeasure. About this section, the problem is a newly-IPv6-connected site easily experiences network degradation. > > 2.2.2. ULA and IPv4 dual-stack environment > > This is a special form of IPv4 and IPv6 prioritization. When an ISP > has IPv4 Internet connectivity but does not yet have IPv6 Internet > connectivity, and the ISP wants to provide site-local IPv6 > connectivity, ULA is the best choice for site-local IPv6 > connectivity. > > ==> I doubt there are "ISPs" as such which offer ULA addresses. You > probably meant an Enterprise instead of ISP. Enterprise sounds reasonable. > ==> later on, you also don't describe the exact problem. Given that we > already have RFC4191 which allows advertising more specific routes, that > would mitigate this problem. I guess at least part of the issue is that > RFC4191 support isn't yet widely enough deployed? RFC4191 is surely one of the solutions. But it's not commonly used yet. Moreover I suppose it's not common to think of using RFC4191 in network environment like this. > 2.2.3. ULA or Global Prioritization > > It is very common to differentiate services by the client's source > address. IP-address-based authentication is an extreme example of > this. Another typical example is a web service that has pages for > the public and internal pages for employees or involved parties. Yet > another example is DNS zone splitting. > > However, ULA and IPv6 global address both have global scope, and > default rules do not specify which address should be given priority. > This point makes IPv6 implementation of address-based service > differentiation a bit harder. > > ==> the last paragraph should answer the question "given priority .. > where?" > In applications? Note that different deployments have very likely exactly > the opposite goals, so one-size-fits-all solution might be different to > come > by (though I'm not sure if folks have tried). You should maybe describe > the > exact problem at a bit more length -- maybe configuration of this > priorization is not easy enough (in a host, or site-wide)? Again, I don't try to propose one perfect solution. I just raised a likely-to-happen problem. What I wanted to say here is that access control cannot be easily implemented mainly because of the scope of ULA. (Not like a site-local address.) > > 4. Security Considerations > > This is a problem statement draft. Security considerations need to > be identified for each solution. > > ==> I'm not sure if this is an appropriate short cut :-). You should be > asking yourself, "does any of the problems mentioned have significant > security > issues?". If yes, those should be mentioned so that that could be used > as a > factor when deciding which ones need to be addressed and how urgently. OK. I'll try in the next rev. > editorial > --------- > > ==> the document should use the documentation prefix(es) throughout the > document (e.g., instead of 6bone or v4 private addresses). Well, I wanted to use two very separate prefixes like 2001: and 3ffe: to make problems clearer. I'll re-write by using two doc prefixes. > > Another approach is to configure the gateways but not the Host and > make use of packet redirection between the gateways. > > ==> s/but not the Host and/to/ (seems redundant..) OK. > > RFC 3041 [RFC3041] defines a Temporary Address, which is a cutting- > edge technique. The usage of Temporary Address has both pros and > cons. It is good for viewing web-pages or communicating with the > general public, but it is bad for a service that uses address-based > authentication. > > ==> I'm not sure if I'd call RFC 3041 "cutting-edge" technique anymore.. > It's already a bit old :-) I agree. > > ==> solely "address-based authentication" is typically discouraged, so this > is a potential for rat-holing discussions.. Of course, address-based auth isn't the only application. As another example, site internal access shouldn't be from temporary address for logging purpose. > > [I-D.arifumi-ipv6-policy-dist] > Matsumoto, A., "Practical Usages of Default Address > Selection Policy Distribution", > draft-arifumi-ipv6-policy-dist-00 (work in progress), > December 2005. > > [I-D.fujisaki-dhc-addr-select-opt] > Fujisaki, T., "Distributing Default Address Selection > Policy using DHCPv6", > draft-fujisaki-dhc-addr-select-opt-01 (work in progress), > December 2005. > > > ==> these should likely be informative references, at least the latter > one.. > > 6.2. Informative References > > ==> on the other hand, some of these (at least the ULA doc) should be > normative.. > OK. I really appreciate your comments. From twdewnt@corrypub.com Sat Jul 29 03:57:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6jgz-0001Dx-Ly for v6ops-archive@ietf.org; Sat, 29 Jul 2006 03:57:01 -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 1G6jgz-00026J-Hu for v6ops-archive@ietf.org; Sat, 29 Jul 2006 03:57:01 -0400 Received: from [218.95.9.213] (helo=[218.95.9.213]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G6jgv-0007Bs-IZ for v6ops-archive@ietf.org; Sat, 29 Jul 2006 03:57:01 -0400 Message-ID: <000d01c6b2e4$1c736510$d5095fda@HUAYONG> From: "sell isno" To: v6ops-archive@ietf.org Subject: Character sets: IBM Date: Sat, 29 Jul 2006 15:53:42 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C6B327.2A96A510" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2873 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2873 X-Spam-Score: 4.5 (++++) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 ------=_NextPart_000_0009_01C6B327.2A96A510 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000A_01C6B327.2A96A510" ------=_NextPart_001_000A_01C6B327.2A96A510 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable show feeling Native Ext/ ReiserFS UFS InFree mail: way. Enjoy largest sharing clever defended. BODY DIV TD TR Commander safe drivewith powered BODY DIV TD TR TH TEXTAREA SELECT ActiveX complete will logo Id cooked my husband bar at top proven HDD Samsung Diagnose tourClose touch instant there produce better soft. than Note still Navratil Software Highend format. formats feature Ranish boot manager because big. liked girly Gateway GwScan ESTest MHDD virtual knowing types images texts shapes other windows yearold urn.In they extent flexible replace XWays Replica backups API use: Search powered BODY wish was. human liking way rise Shell Temp Cleaner ------=_NextPart_001_000A_01C6B327.2A96A510 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D""=20
show feeling
Native Ext/ ReiserFS UFS
InFree mail: way. Enjoy largest sharing
clever defended.
BODY DIV TD TR
Commander safe drivewith
powered BODY DIV TD TR TH
TEXTAREA SELECT
ActiveX complete will logo
Id cooked my husband
bar at top
proven
HDD Samsung Diagnose
tourClose
touch instant
there produce
better soft. than
Note still
Navratil Software Highend
format. formats
feature Ranish boot manager
because big. liked girly
Gateway GwScan ESTest MHDD
virtual knowing types
images texts shapes
other windows
yearold urn.In they extent
flexible replace XWays Replica backups API
use:
.Search powered BODY
wish was. human liking way rise
Shell Temp Cleaner
------=_NextPart_001_000A_01C6B327.2A96A510-- ------=_NextPart_000_0009_01C6B327.2A96A510 Content-Type: image/gif; name="Player.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c6b2e4$1c736510$d5095fda@HUAYONG> R0lGODdhrQEOAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAArQEOAgcI/gDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtCnCAAEMQpUa1anVqzinFtRKkCvWhlGnVg0bViBZe1XNpkULtS3b tmThsu361q3culq9ru261uvcp3D3/lVLmK/cwIL1Bh6IGG/fuwcV021MVWzfwZbvLnasVvPm zlzPjp07WuxXh5DrGn7st3Va168ZPy5M2K3ZyLYH06Yqe3Vv3b8xs35NfLfw3YJVd2Z8nPdb 5qHP8qVLW3J05LIVa09+Wirp26bR/n4HvXXvdcPMkY+dnTs5ZNcJJZMv7Ld68ez3a5u/rxd3 9NjyTfcceMXBl15z+v3Wn3jhiUageN0xVN+Es+lmIHDS5feXdRs6l9d+8VX4IX6ABXfeiL1d iGKI9HUYoIIdkrZeeSWq11x9weVoXIQfrYghcYfVlqOPDZZF44Yg1kjfjPM5x5mCTOp32Gd4 4dbidy9eWSSSnuWGoIypUcmjTUQmiaGQNlpoZHgC+gicgEumaWWCbUYpI4047ojijNLpOdp4 lu0I53kJ5vnmmDEhRqh9W2U3pJ1seulYoHA6CeZnhp4I5GLWJRlapZMa+VyWMQ5oamuDakjp pzoimmiF/z/qCOSjNs5aKaWtmgiphkfeyB5/ZuYFKofLLQrjcsieqSutJ4LqKkwBqshpqiQ+ CWutnIpJmZq5Mprir+9lW6ek3IJLrmqwtrcZlduVCRp3z8Yr77z01mvvvfjmq69FDuzr778A 28NGwAQXbPDBCCes8MIMN+zwwxBHLPHEFFds8cUYZ6zxxhx3rJM4Hocs8sgkl2wyvaWcrPLK LLfs8sswxyzzzDTXbPPNOOes88489+zzz0AHLfTQBw9g9AD2GE0Q0koLpPTRRzsN9UBQN101 01Ur1LTUBV2ddNZST/010TtbvTXWVKO9NNJUj53221zHbZDYbsNt99Z15022zf5ms5103U/7 LfffeJ/tt+EI0Y233oi/rczge9dstdtsBw754nk3DrjgcJvdNeeaZ8555DNPPnblanv9ddSi 3w323KhfnrXqdutNusymP8215wlZ7vrbmHce+9qf21746LfDbPrqaR8OOvHH/2776rODbr3s yZddefPcXw694JqHPrjvtW9OfPnZuzw1+M63z/rrtJtffvRe189+7cGnr//+/Pfv//8ADKAA PcaOARrwgAhMoAIXGK/1vQ5y1DOc2Br3QNmRL3B0Kx7+wva+6n3PgRlsHuvMV7jPdXCCFRTh 8P62O/AZb4Xpix7sNNjC78WthOc7H+/yJ8LuEe5+cv6j3/UgSEHnMc9pNGyd+DJHOc+NEGvs g2H2ZJhEJd7vgi7MofDk17snnq11QbziEF+4xRYeLolCRF8J+2bGtqGQd/qjohat+EEgJm50 fbPjQXZIOTBy8XRjxFwRgddHLaaRiHjcXuxS98OowTGGepyfGD8IuxGqEXXWC2ETkXg6P0qw eiC0pAqNuLtSrs2RYtQkB91HPU7qDpM3RB7p5ChJGwJPlHMUJCYjqcHcMc2TpKyhLWdIRd11 0pCT5KEOUelLwrUtlvyjJfZuacMv1rKXapveKh3JvWIGE5DY3OMKEdc+NE5yekAMJSeZhzxl 3k6ajDunMJcXzxluUptK7P+mHUNHvjDa857HPCL+5CnIHIavm+KE4Cy9KM43ehGFwsOl/bAY wTEGtIkZ5CcUUZnLdE6woybs4BwjaNAzEtKe7mSgSlfK0pa69KUwjalMZ0rTmtr0pjC1ph8r usrxJVKk6+xnNq/ZQ3KmUKE7LSY1EQnRZ15ym+PjqTmR6s2e3pEh8FNcRnEpLzZubnH83CkT vYpBNx7PotAE6B2D580iLlKKVjSpD9mZSrMOdJCVDKZQ87oQgmbzkfciKytLujSxrhGWgDyj Q6u4ySWGNKGuc2sN2VrXdXLwskJU7D4Zik7OgtOpjNXaX0eLz3lNbniPXCItdYnERfZxo0Ml Yyv+0bfMf96Tj2/NH/0KaVaO7va0Hg0jZdP62b7K8qpGvaUqu8pMUlY1pJrMKga310nEgjWR YYMudl+oOjiqU6C2NaYxnynS3VY3uF9tJ2qN6FXbGtefyUXqs76rVtXycpnTdeUv5XpdlFpS mYAFo3ebe1nImnK8QV3qgfeLXnjelr3fHOlV4Qth2jaQwBUNnwtXi9+NBhXBRN2iY7fZX+WC 7bv9HCgLwbviYQaUoybWakM9KExtphSYJIxwvFjhT59Kr7WR3OzdEOpe1j64iyBVMBfxiswV i1K9+cwuk/+o4vjamJclLi5F8aVhwqrQx9D1cotBbEECGzWEq5XnkvX++tP35RKy3a2jRmkr Q+lK9MSZdKj79ozTlRCBZTfuc5+PK+hCG/rQiE60ohfN6EY7+tGQjrSk41WBSVv60pjOtKY3 zelOe/rToA61qEdN6lKb+tSoTrWqV83qBQLg1a++SawHAoCZbOLWtx4IrnEtkFz3ehP22HWu ff3rYAO717oGtrCPLexf79rYz152sgly7GkXZNjNlrazmf1salfb2A2J9re5zWuLzVogta4J rGktE2IHG9zTJra8q+1ubDu72O6GN7KLzW9rw7vc7/b2uO3tbX/7ut7JnrdDDi5vfQecYue2 R7phPWuK13rdEr94xDEea45PPN20PjfIPb7/boxnXOQglwjC661servc38G+w78Z7nCHv7zf /WY4va9dbnHzvOAzp3bCb84Qneva5uZOObpHrvGlO93j6H56xZue8YJQfeJSd3rVp671ieTb 5i03ONHBffCAExzmQK+5wt9ddqFnO+xpD3rN+U3zcDP733OvWMS73vGPZ73rf9+63wnid6Wz 4+qFHzxGmg12fa8d2owXt8573u2cv73y3H74vikP+bPL/euf/7ZC2j7svENc6VX/O9dRvvSS M731qC887BEvdYp7xPNnfzzLtw15nBtE96LHPb6vfXR8B3/gdBd98n2fENIr2/QT23jqBa/1 voc89dbPBfZNzu7W/m//+9TnCPJ3D3yYT773ak/745e/b2gT//dwN3/mkb5sz4/+7vdGuN5T TvXwr/71/3d9gNd9J/d9XBd+EjeAEDF+DCh28ueAvod8lvdzdJdw7/dz+VZ+9NeAFAh0Lhd/ Zqd8DWNxIQd1BkiCszd9rGcQ/Pdxrld9Lvh6FcF4nfeBu4dzGliD2yaBOkh+cad58XZ5ANdt kceARHh8pWdtNAh6KrN3EeGEj8aEewOFD0GFjSaCrZaFDQEPWtiFXghAIvCFLGWFGkGGhId6 YogoKDh9DkGGa/iEaHgQZngRRVh8ZDducyeFacgQ0seGDWGFfQiHbRiHGbFy5GZ8Owdw/+63 hxMhfSi4hrZ3gAIYdf/neonHdCY4hxFhiPd2h4lIeXrIiAkBhSuIgKaogAF4gol3fZKoEV9X dpkHd8/3djLBC5cGiTJoirYnh7uYiqmIgNYXEkvIa0Q4fIcIfaI4iHwHgC1IiGcIezAYeMF4 isJIbi3nfGxnh6GYjCz4jCrIjGdIit7Yi4M3jebYf7fngcTYcxYogtvIjYQ3jrk4jdTYgpN4 gOf4jeC3ETyoe+14EO8IjyW4cVNncpGoeANpj9EoeLt4cvjojBRBg463c/EGkFgokDahiRhp Mxq5kR75kSkxDiA5kiRZki7VkXwIkSaJL2+IiiqJEI/4kjYhAP80SZMHUZM2KRA4KQArCREo 6YfKyG4/GRM5aQ9FqZM8iZRGmZRL2ZNB+XTb15CZqHSOGIOYOJCTaBJFeZRNqZRbyZROqRAE aX0ruIp+6IT5WHHgN5QX8ZUF4ZZuGZYLQYKsV4qqR5Wx13/02IopEZcDAZdMyZVyyYIKCYxW CY1Wl3IPYJje55BsqRF+qZSSuZNgOZiE6Y2M+ZBoyX+MyYoyORKR2ZWi+ZeVaZmYqY8FuY+k yJlpKY0KCJqBmZQ2GZqCaZpZWZbBiIswSY4p2JgOmZVaiZOkiZQ1SZq1aZsg8ZjImTHKuZzO mYYs8JzSOZ3U2TPNaRTwMi+GUhLbOTP/m/mHL0mFLbkT+6Eu54Ip4XKe6fkfOIKe6tkrJtGd McN93DeK4YmGgagT6zId13Ic12Es/1kgvBKgrbIdKCGfMEOOKCd7mnmYp3mVDAmcJNEglmIc BEonsYKhuCItX/IjAconI7IetrEiCOoyGveCCciQTfeQrymOEbqP8SkqFZqhd6KhwdInG3qj HSofHwKiPoqjGcIrHNmYe3eOuNmizpiPLZEaytEky3KhNJqjOyqgsiIiUSKlhNKj/TmkUQeD KFqACYmQEuqY+ugSTOonvYKlA0qlNpqmQAqfe8KmNYogF4Iz+El7C5qLY1qV0viZIdEnBaqj UMqhgyqoa4of/1PyLYrqLWGSnfPJiyfomXyHpPH4i3w5oQ/CHnXin3Iaop36pnMqpdSyqKEK qjVqLDqBB/Nypyl4pL9ZgoRpkAcplX6qEe7JnsBinrgKJbq6Kbm6qx5iLlpaJiPKJCWKU9fp EY6qEMe6EM0qEt1JIRvxrDWVrB2xrPExrTSxndKaEdRaneAaruI6ruRaruZ6ruiaruq6ruza ru76rvAar/I6r/Rar/Z6r/iar/q6r/xKMPzwr/wgEAE7EAMrsPbwrwQRsAhLsAUrsAA7sA3b sAcLsAz7sAdbEA+7sAabsBQ7sRbrsRILshDbsSIbsQl7shSrsRfrsCrrsCibsSu7sf8b+7EY e2gma7IEO7Evy7E1m7MFG7I/K7M5e7IHobBDa7BAS7RHe7FBG7M127QxO7JEi7MMi7IGQbVM q7RL22chu7JG67VRm7Viu7Rf27VNm7Raa7VCu7ZOe7VqC7ZFG7ZOC7Fh27Vv+7U9W7Zs27OF ZrZIO7N1C7YSe7Nte7R0y7d7O7Zom7aIi7eH67ZBO7h/O7kJ4biFK7iAqxB2a1M0S7eH+7li i7dCq7Cb27kwO7gwK7cgy7IdS7MVu7Cm+7Fni7ag+7MtW7up67ky67pbexRfcDK6O7mR67WP y7rB67aqu7V+u7eiG7daq7fMO7TN+7hGK7lKW71xO7zIy7j/hma7Vbu7oVu8hSu+4Du+iPu6 fru5a0u4mYuxsju64Du9fIu9Reu9zsu9nHu988uztMu2UGu4/nu+bSu6zTu3jSu3i0u5Z8uz Bvy8Bby+ZPtormu9c1vAoHvAz1uyIqvB1iu7uUuy6Au/GSu/N4uwEWu7IFzBGgzBr3u//frC xjvCMjzDNFzDNnzDOJzDOrzDPNzDPvzDPwzDQjzEGGMHRHzESCzEtQoTMumnS7wST3wVUcyc 9QmTBFgRU1ymo5iiYpmYLmp1V4zFjxmD3idyXEzGrDmrfUdyhBiJBKiXZZrFeveEYdyIFmGX ctiG8djF3dgRU4x1Xap4FxfIYCyU/4V8yCpJlW+sgnH8MnkJyAloiYA8yQsKphwXyfU5yIMM pr/pgkS6x+FIiULZcUQqq22MmJyMyN2Hdax8xoccya+8yLGsyF0Ky62syXV8MpcsyrzsypPs y6A8cth3xbi8ybAsynFozJ+MzIbcy8aszFYMzHzsyim6yehoyXTJxqDMyY9syNZczbZMzQkq zccMzMV8kG/sxrXMmeBMl97sxdDczOHszOR8zX0szBCJicLczkDZy+Vcy9ucy4VczIT8zeLs yPUszgQdz1sXxvvMxeD8z+YczBBdqe9Mz/iczltMztFc0RFN0N3ImrEM0AK9xyB9y4RM0i3z zAmd0hEN0f8sTc8ArcgZzcyLnMwTjdHyzM6xt84VTcseDcmkHNQw/dN5fM8brdCsqMoePTK0 qs9Q6dIQKqvLfNC0bMrWXJDK/NSBDHWe7MtmHMr7vMsm7cVnzNK9WKlq/NBSCc8Uvc7QLNTl KscjXS8PHa503cf3ctdJ3Nd+/ddOzRF57RKD3dRM7MdVmNeFzZxVKNgBnRN8rdfyXNJ3fBHs XNdMzYcbccrW6diUTRORjdk97RFynMiardIdjRGczTJfjZitbcq+2ZDY3M2vytVgXcmpXIC2 TZ+pbNu5rc2zzctYrdap+dtrDKGwasmYrJdqKdbFXdu4/TAMndF8vdU7/daGjdb/113T/3zX bA3GPT3aRo2f233Tcu3dLV3UPo3e6/3L473N5M3dDD2CQEndCsrcJUfMsoyV8p3Q3E2m+43G Ia3XaPzIQ13O7tyq+t3fM23evL3eq9zVB87I/D3KXwoxekrdmT3hVr3f/l3eOi3Q3/3f/gzh cB3QDO7hHZ7il03iAU7NrVziDW3iEv2aCnPZvqwEKY7gHe7TNw3iPP7f7P3h4E3gPU7jMc3j Mh3iR77jIx7hQZ7HT77khp0wJ+rW1Zyn3Kzl8mjgLT3cY/3cSy3hCFnmq2yJserjxd2MWHnd UXmZYQ7Uyp3SAp7cUUnGwb0xi/0VmbA/e27l0lnFgD3o/4Re6Hv950KB6JCKFEus6P1sp6Sd y6HNEvO9m5qY5LE66T752Xos3hY9zU686Y4O6Ig9zQLxDTHR6JyO2kZehqUu2Zi96ke96SZD cuGI3ApaxqWc1Xje21kO1cot4E/d4rFNyvnt6wVNj68a3F/t29DoyfmtyWR95c2eyWte1LbO MS7e39zu0ERe48NM5ZgM4U7u7SIt4zD+0djN5Npt5NZdfd/e7uoN1kXO6hiz7RZ+4PJe51FO ieKd4L+e5LhM5cOO7ZPd5scMyTB+7P0+7qoMx0ge701+8Ag+6vmC7yXe7eye3oEI1Pt+0UpO 0kLO0VCe8A2+8SxO7AD44yjv5v8+XuNxbfH2gvEN//EaH/LzfvMCX/MoPtny/tYGrfJAjulC 7/I2P/TYHc9K7zFkLcvDveUBH9XT/tuh7NoM38kLn59WP/C/Dt8mn/NW3/W3nenLPebLDexD PfXE3NwmfeU+I/OW/eqFLugyQfeNaK2Gnvd6v/fuiuiaDutYbMfUSd6Bn9SefZhlmRGmXe/j msVJ+hEKP48KX/imbu9fmNbVrpa8vus2Pe+7DtVxLtxXP9HefcmvzfDQ7ojLbvelhs/nPcpM rtYvn90SL/skr+FDfnVIj+Odj+mpxuL+rc7P/ukOjfpfbvwZD+W5r9Q3T9RoLdu/b/Tf/vLW Lec6X/v/Ej3Wsw/8zR/eJM9q3L/7LF/HRc/z4b/uEz/lDe/8X65qaZ3c7y/2d27UWK7GbX7f MN301S3y+s/luc6GAAHAnkCB9gYaBJDQ4MGFDR0+hBhR4kSKFS1exJhR40aOHT1iLGgx5EeI I0ky/GiyokmVJ12+hBlT5kyaNW1ObBkx58mdGRP29AnyIdCbRY0eRZpU6VKmTZ0+hRpV6lSq Va1exZpV61auXb1+BRtW7FiyZc2eRZtW7Vq2bd2+hRtX7ly6de3exZtX716+ff3+BRxY8GDC hQ0fRpxY8eKLCRg/hhxZ8mTKlS1fxpw5qx/NnT1/Bh1a9GjSpU2fRp1a9WrW/q1d71V4MbbX 2UqJXr2NUrdQnA5z5pb8szbF4SJDFpeIvGRL4TNnK5f9U+RC4MlTHgdKcGXD6tSJ+9a5OyXg 2NBdPgdunrvK8t1XYvfY/TjP69Szy+bO8X7+kqLRDyxIIQEBBFA6hJqzT0AEC2QpQAMZhHC5 9aR7EEHhHFSwwgfD86087yg0MECEDsSOoPZENHE47bQrMEEWQ/TQxQRnlJHEESOUEUMb52ux RR1x3HCt/9qDUMEDCUTySCWNTLJJAmtTLkgin3QQSSatNBGkGA+aj0cub2TxS+9u5FJEMr9c 0bsVPhRvxJG8dLO/OOOEs0vd3mRzzDnF5LOqRc6D/o/IIaucUkksGYQSwwyrTO5NRpmENMsl U6wuTEtRsjPNC5MscUAy8WSI0kvDJJFUHpsrrktUMeUPzTo/hG/PUd37atAjbaXSUE4J/U3S EyXVydFJDxU01l+FslNWNjWVEE5WzzSTVFZNzfPTZ5tMtlpQ+fTUWkMHzDbWtqYs1j5iGf2W 12APNTdVdNmN9FxzsQXWunCvNTNUPbnVdl+Wpl22VWqV9bffS/Wkdttt0ex3TFqz2tRFYONF tENfFRW24gWl5HjYCMmN18Je0ev0VocRPnHeEBFuFUySXzxW4VJ7ZLlHRS1ekeSZYYx2yxT3 VUw9v4R+TayH71rwsKOL/sZqaaafhjpqqaemumqrz3L6zJaNWvro34SciuignAO6N7yc7ejr oWrqOj6BrUK7N6fbBm8/DmXqGUSVzy5bv7u3holuv2um6uGs6ZPTOsXxhnZeK8fleUcNUbRx 5gl/jLzRmy2nUdUYV/4RRx8nx3lO0jfWmcJnpQw1ZSDBnbzB0MucXXbOV3WZ8iLBo/NatJw9 mF+ffQe+TaJGLRhMfXt3M9/g8SUeVmtlzhZggpmfvlrhk+/zesCVvTe/4f/tPW6yTlV9etw1 5v5mR6Fb//mIoUe+VPlZnt/6ab0U9c6TMRbfneLHKf1Rb23iAtoAwzfAPXnLeWADH/54t5tX /kXQW2uzoP8wCLDwEY5+dwteoLSnQX3lq24kvCC4Gpa9E66nZfeC4QqldaoL/s5gErze/TJI w7d1cHXLY1gOo8dCEoYwgBmEXg3ThEP/1a+I4pEWCmO4ww++zYpqEZmgHLYlmiXtYzCyHHvS 1zoVjW9lNptQjdq1RdmZMHOoK5HJoKUiMlbOcwTz4hn5k6HSFSl2YRzjx66ovLcczjZIMeR5 0jYuuCGON0ISW1USuZ3CLTItQXoKJi05nat10pOfBGUoRTnKUE4Si4r8Xps2GZYopnIjahvb Z1pJEvNpJGvHQ2X7Ave3vr2yl9/piSG/xp7+2M2UcDmm1hzptu8s//OJL6lULhcZTGjy8pd2 Wwzu/gjHGaWPYwcDEeauNBTXqRGTb+Tc6DyEOTZSqm5vXOfrdCROnQVRgPW02ctKN08VunN/ MNscX6q3PSQOtHEN5N/yYFlBfulSh/sjohPx1EFfJbCAvmMYQ/9lwIPaE1O6I2hIk0mbPCnQ YAllzkS/JTGFgtChSXtOwDpK0Yu+KlwMJKNEV6c6kDpQb/YboqsIp9MpqrIumbphDp1IToQ+ r6WJ06hRnyTTZzZUpNHzYRWvGsOeXlSOHrypVom6Qr0glYo2HeEEiYlSQpIvqE6NYFSFWFSV zpWJY41r2XyoUyZaFa9X7Ys2eQbOcnpqQ/6HpRGWokVIF9LsdmWMY047pL8uDharW7RjzURW x52qUJlw/FnlRLc7Df2zZFNFozITM9INSnMurD0kKW0TSWeOhy6aLAtsZbtb3vbWt78FbnCF KxfaQoxrTqFVIosr1Ud2Jj2J09xt4GpOqGwqN8zBaEdd2VzVUrK2ZmMufqiGy+62dnG6jeUt mwleZm53cbRMr2tf67qfclOQlZ0oPN0aOp4aFkr/G2dm+YtPqJJOfKDzrxu/yM4Bh/axkX1w 574p4DTaN42pxe0pcQjSjVK1lXytKkIpq9mnHvCBR1zvXjlo0br69XEiVmsLY0zXK9ZLrKlc Ynhz20Ploa9bOf77KYqNaM5ALpW6i73cRy0rNJTCdMW5S5i24ocqtPnYxqbtn1y7Rz+Yvg/I y60Vj0uYVI86DrAopKyRGfuimWKUf9QkooxzvFQQ13CNM0aZmC3a5gamUKo/3nIhxczhmgb1 zAtL84gdWGKvWhWINb4s9ujc6CH3udFPpPFQoXjXYnqYuPTt8TZLWk48zg6KkSPswpZowt0l lspxS6hjCZrgKLsssxJGoJVlbWE9qpqLd+asq70JZuIO19iBQe+xlb1syFSB2c+GdrSlPW2c wJImhks2V7It0JtsO8wxtgl53dsVYcbkur+8ZLd1jLQNwlbc6CapfG3r3deqmzykDv8nhMMY bAaG88Kg62OvKZzFXW1uwqPbd2r5DVnR+tuforPQwj2Lan37iI2jxW+SKZxPbzPFoGxt8/jI vGn14fmsD1xsUTec17PqEsZnhmhN19pj6FbPfB++4cDWvWNLNxmxdi1ou9O6wJwaMeUmxRmb t0dDAOavUxMjM0cLnaNQMzXOwAsyp3NcsWL3vK96pjGitcppMe23pH3+OO8IDc5HqxLWf5V6 psv+KTEmms/Yyjmau75lkGNa69ojZpwjqmmQr33oZ1+6pr0X65aH/O8sVPABAe9yx5dvkMj8 9VdNHXFhHyufL8z8ghsSiX+vnLPos1hb7/vzhrvLjkPqrJf+51gy2R/ddoB06qv7iEZ6Wqbj gzPLucM2buiC5feCOX50kr9LTmaSjlpa/rypPX3qV9/618d+aogt3ljakm3ABz8i2ftd4pe3 /BPsvi8bi8zjej/8rnw3d90fW2u+t/7nd+v59Q/v9e6c5/ZOP/m7JnoTwAIEwOKDr/FTQARs vgDsvujjGlDrPdFSu3rSo9fTpwqjL1I7vYvToLxhHgajwNSTp9ubQFhJndizB18wsIR7tcia oVvrwJPpQDZDpxPMsEzCn8gLNCFzux9Usb6ptK2avDFrHtORnp2rswCSmZGDO+PxNBiaucZT PVVBwpLzO63oOy+7Mh9sIwoaI/n/qZMwdLKIAahuyagCejqU2IXsCEM36y+wSjQpzLrsocMf gx2AY5+AkSjGE8M6lCSyU60osbs+kTtgy6rDYzWVmjPryT8nebwsRK0mmjyVMzOzCqlB3LRF ZEIivDEhhECoIqsK6rCX07klBLpIS6Lu4aGGUjNOpKK+uh+bmzopisKRk6Gva0W228JBYrXq Kj1ca7gKhMFAajXJEjZAGsHaCcahGp7mcZ6Y2qd2msYWLLUzxL1lHDVAU7g9+q/OATeFyzUu 0i/+syGoCUXcuL50/At2DJvty754lMd5pMd6tEdpaxD1Izdray9zM0fzc0AC7Mdqmi94hC/p 0r9aQr9//1zAhcyu+wNIS2o6Y5E3hyy3XHLHa2NIjaS3aIrIhgxIwFHI7UomHvwP/7M/BLxI R8pIsqE7CNOviuuvBnsfAQuEbrJG2plAgMJJE0yUh2OdfxO13DEdY0SqMYwn/Eo1x7IvH9s9 A8ujRUmscwSiUhw87MpFLbOxXoy6JKRFk4M0hpKzSysTwTvKl7rKIry8Ogs7ypuusQAt9+nF VBEynBo7P3M6NSTDIAs8vttB1tuZrjzGgeKhqJpLtdQsPcxLaFyUh/Icgxw+N8szilI1yby7 KOq7sSyeQcTMwxM8h+pKmjK7qgS70BTJhlE6oXtErURJcqNBR2PLF/pEvBS6xf+jtFX0S68b PNCkQqMLRyXKSidUTcWTxNjcTaqUOAcTuHPyr9b7Rhl0Iaf0QcWavdYjwZTqrIDLtxrJIlO5 wM38wnviTniyoo25MCKDwQRaynvcu4EkwJZkT+2DzI/8rPi0z2MrgPt0CdLTz/70z+D4vgi8 Nn5knAP0R8hRjZFCLwWtzQAFyQZULij8PlMaSZfKJgcNNwy1swJ9UIEkSAY8UOZzz3b0vKaE ygzsPGG8zuc8QRWVHAITJJrMzoMDrQO7mInRp510l4CqMI4jJ3qaJ1fB0SDlOPjk0CWcNNvU mlPUM1nkzbBEy1rUuU6zzZSjOSRyMUFsHMYrzphDMtP/pM/gQzrJsjm7NEO+dDLdLEug+jou Yz3fDLofjU0rLSGkm7I3/ScCWsMn5au8ecJ6K02VG80lnUyX6ksREsVDTavj/CuSgzmlg1QK usXuSsSpurlARc3efEhG0tSvhM1RfCtHbTGpIzw+BdP6jMUrjFSuykUt7UTgjES280RHi4vl pEbp/KPz1L0R7MYcgdFe1bxl/M4MJDgn6TfEolMQDMwv4lWBC0YO9FEpbSswYif6fIT/TEls 1dYR3dZu9dZvBddwFdfemqWm4T7zCtN1AVERHVepKNdsbb/twEo+1EcP0kgj7dZ3baQGdMhN VcAKPch2jQ8CQzI9TFEUjCOe/3RO56wrxSxRIYXD2pFKbWwwDoJWgZUbOTG8YaJSQzwxtRRD O9RMezLMBg3ZQmxEjFW+K2MW6wLDAMvEPaUyltKoVXEfem2xz/Q5Fp1ZkdUVlbVQvGMWFMOX UQ2xopXUu5O0Fau1Ns3MywvWGcJXYxPLH8IeQ0vSSzNOps27GATLUr1MLyS5qQ2uXa2xpPRV qyRShs24dKrJstvOIJLG62wWD/SXwhq2LgJadNxblSXbvgXcwBXc0PiArwiFwUVcmKiESkhc j1hc63tcg1jcyZVcxl2Ix51cyrWHzLXcyH2GyL3czG0I0N1cyy3dyhXd0k1d1WVczm1dznUI 0n1d0f8FXdONXNh9CNylXdh13dhN3d5lXdIN3dztXN3F3eAt3uq7XdPd3NMdXuGVXecVXucd Xc2lXsxlXuwd3sqt3u2FCOt9Xd9FXe6N3u69XO713un1Xuo93dpl3vEN3fB9XttNXvGdPvcd XfbVXvOV3PZ9X/StXvwl3+yV3+sl4PX1XdtlX+ldXv213/7VX/qVCNk9YAEO4OLd3wHeXvVV X2az4PXNYACO3/8VYQaeXxHO4A/+4NiV3gW+3eb134ng4AMuYf6NYAPO3eCN4RNG3xm+XwlO YN4VYuIlYdRtYBw+4gFe3Rs2YuglX+Q1YtYdYRI+Xgqe4vcd4vld4vNVXQ3/1mLwreIiXrYV vmHo/d8tRuAk3l8rDmEmXuD8bd833l0fnuD6BeAOduMY7mAF9mINtmLi/WEQLmMszt4dfmDk dV8g9uI/vmMxpt8CHmEphuESpmFGxmNG3mEO/l5IXmNFtuFoU+FBPmT5nV5MTmQQLmAV9mQW Hl86vt5PrmQafmNU7l4ypmJOTmU7/mRQfuQk9t/fBeY0lmUDJuBg/uL0PV4IVmIwRmXrvWAM VmTgFWZjpuRNbmJdxl5qpjY8blyL4GYPFuNuluFwFudyNudzRud0Vud1Zud2dud3hud4lud5 pud6tud7xud81ud95ud+vopz8OeAFuiBJuiCNuiD/0bohMbWbRBYAiCAhnDoiH5og5Boh4aI in5oi14Ii5Zoiu7oh6hoj+5ojYboid7okLYHjAbpidZolU5pk+ZolHYIly7pkv7omj7pm75o k35piH5pnT7pjQ7qoRbpiC5qluZpkj7qjJZpov5po17qlf5opebpnp5ppJ7qpH5qpfZonG7p qnaJmybpr3ZqnLbqrrZqqr5qn+ZqqBbpnXbqtkbqs+7psWbqsj5rqnZru7ZpmPbriBDrsc5r sP7quS7qtUZriqZrrk5svs7pv0Zrxo5rpobpq07qmK7pvR7svh5qspaJwM7sy4brxE5rw1Zs s05pun7qw17pyUZszA5qvv92bLPW69ke7NmW7NV+a8XW69f2bN0marXu7dZu7Mu2bdge7a7W bM5e7d7W7OEGbs/ObY+QbtGGbtoW7dKeCMZu661W7eJGbdZ27r+2bfCObNPW7vT+7vS+69S+ 7rRObfbO7u9+b/PebPWua7B27fauasrGbOeG7+H+bbG2gIsYabfubPRG7vW2a5ducO7G6q3O 6N2W7OMmbKge79hu6scWcAU37MJGcK9maeVe7AuPaceGbginaezW6eoObaAG8LqeaQpvbxKX 8Q5P7EnYa/3+CBfX8PC2b/wua9nub6Em7eCeb+wO7R/P7QWXbxE/7/WO8vjm6BKXav9OcCVH 7CP/B2+5nnLl5nErn+siP+38zmwSx3Erx+sex+gaN/M1t/DIDm8in3Hi3vL6vm8w/3EGN+02 d/MTD+nf7uuRzmk15+yspunjNnQtf/ADX3LAtu5C9+nWjvGfFvM2X3OYyPAvb3LInvIk3+zu tnMt5/I8f/NTh/As33P8Ru5Uj+1CL28kd+0g/3P9xm0Pv+/prvQQt/Vaj29LR/H5xnPqtm6Z XvE7L3YQ7/UDJ/RRn2ygfvYdx3BQ33QwB+1VV+1Kz29ol3XStvBpB3JTX3BAb3QTx/A5H20H f/EdJ3UpV+h2XoJ3l/d5p/d6twk9sPd8d+fp1vfQWHEH12py7+9AJ2+C/590Dkfv5g54yOb3 fjeKYH9xoY71bC94yzZyWXf15+7zMHf4hy/2iC9zOB94bLf0kA/1C99t9/b1UWIH3qr2Gx/x LQdy2O7ulkZ2+h5xm4dxju8k/nwaZh95bK9yGZd5hNdzCafyCR/0hIdvmEf5jm+Klx/6oQ/3 VBf0pP/1Ln/6MQfuUod6j390Gy/5ql/2IZd0jN96WHfzr3cKiH/1lBf5nfb0Muf1in9ttQ9y tj+Kf0dpUOfzwPbrZj9ygAf6rG91ptf7xFf8xWf8xnf8x4f8yAeuhpf8qOj7yj563n56o+d8 whf0uz5276Z4oBf4TH984Y7wbZf42r75S5d5yv5e/biP/TkPeiGXfNSn8bHH8q53fZJHfcwn e7au/cFneJ5n/IzHev5WeaP2cqFfe+5u+uAv+ubvdsrPCgQY18K37AfXba5Pfeo/9W2f9nMn +nAXfbkm/Rq/+soXcUA/7SoHfvAf97Vfa64vergG/9Fnd/YPeRDvflgHCHsCB9ojQIBgwYMD DSYkyJChQ4cHFSakuNDiQokNNXK8iPAjyJAiR5IsafIkypQqV7Js6fIlzJgjLULcaJOiwYkg awqsCZHnQ4w0dfbkWXSnRqNKhWI8KvMp1KhSp1KtanVqTqA4cSbdyTSrRLAVcxYlW7CjR69m swYFy3ZiU5tX59Kta/73Lt68evfy7ev3L+DAggcTLmz4MOLEihczbuz4MeTIkidTrmz5MubM mjdz7uz5M+jQokeTLm36NOrUqlebjsP6NezYsmfTrm37Nu7cunfz7u37N/DgwutiGG78OPLk ypczb+78OfTo0qdTr279Ovbs2rdz7+79O/jw4u0CAM1vPHqVANaXJ8+YH/zzKOWnr0+yvT38 c/Ubhk/Qv0n02TfgR/gZyJ5A7JWHYIIMGthgexGOdB6F8dlj4YUDCfifhRhe6GGF/slH34gA hqghiB5yaCKG8Z1I4G8P5kfQggM9qF+NCSKUI38ImaghkCSGJKRAFP6XIZFGFunjh0EeKf7g hlE+CeSSMPamoI00zqijjjh2WeCWJBGZYZVKgjSmmUiSSeaIazr55pJQMnkknGNaqZuEECIo 44xe9mnjngFSuWabG9JJ6IcuqllmnCiKOCWcbkoqJ5p38iZjj+VtEmaOXPKYZY9nDpqkpIcK aaiZbS56KqSNDlrlq6m+aultmGrJZ6ecZvllmKLCWqlIlcqJpIvDIkppq2zCuqysy9Jqm59Y 6uopg1zquWWoo2rr7JyIJkqioYd+62aJAI77a4stbvssu4Ep2m278RZWLL312nsvvvnquy+/ /RYrL8ABCzwwwQUbfDDCCSvcUrZXhQuTsXc9PKugMpm7MGEK8v4pUqgNW+wrt2KKa9fEIQdb 6slDYoyYnyZ5XFW4EZckM8kiq1TyfCsfxh+P610boc997hl0fg5iO2GiRXbYYdLM0imstsCu WKi5TKv7q5rpXpw1iyKqqPNePP+5K9lf4trrght/VLXTSlMZsarHRr2u02xDySrWFcbKJNvK Ugz2XWLnKvat047Na8WM0h2zqVk7KauRqCab5rCRK2us5JW3DbhegjdoLbU+d3qjxr3arDjW FMPteKOQLzr1o2/Hffmq5IZMOeooc06X56DuqOvovv9+kuaLry2u5ay6nia3q2tu+et+8/30 5rsHriXapgcfPOKHmw7v7HbGLbOd3loab7vzjeedLO1vV299XaV3STSWQItuuP15gn78qOB+ K/WkZlU+8TkqfE3DXNTepUBXoe5d8GNOyWj2wAk+xV8WvCAGM6jBDe6Lgh78IAhDKMIRkrCE JjRMQAAAOw== ------=_NextPart_000_0009_01C6B327.2A96A510-- From owner-v6ops@ops.ietf.org Sun Jul 30 12:33:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7EET-0001pE-Ld for v6ops-archive@lists.ietf.org; Sun, 30 Jul 2006 12:33:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7EEQ-0003KL-S5 for v6ops-archive@lists.ietf.org; Sun, 30 Jul 2006 12:33:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7E9y-000GjG-EC for v6ops-data@psg.com; Sun, 30 Jul 2006 16:28:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.234.218.130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7E9w-000Gix-Be for v6ops@ops.ietf.org; Sun, 30 Jul 2006 16:28:56 +0000 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D9D518986A; Sun, 30 Jul 2006 19:28:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8D45289865; Sun, 30 Jul 2006 19:28:54 +0300 (EEST) Message-ID: <44CCDE3D.4070901@piuha.net> Date: Sun, 30 Jul 2006 19:28:45 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hain CC: 'Fred Baker' , v6ops@ops.ietf.org Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt References: <090301c6b1c3$0bfd8160$247ba8c0@tndh.net> In-Reply-To: <090301c6b1c3$0bfd8160$247ba8c0@tndh.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b I would be fine with referencing 3704. But the draft that I referenced was merely an example. Perhaps it would be best if you adding a little bit detail to the work-in-progress warning that you already have in Section 4.7. For instance, Multihoming and renumbering remain technically challenging with IPv6 (see the Gap Analysis below). However, IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR allocated prefixes, and thus with several simultaneous ISPs. An address selection mechanism [10] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in regard to multiple addresses therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and the processes for adding, removing, and renumbering active prefixes at a site have been documented in [13] and [20]. => IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR allocated prefixes, and thus with several simultaneous ISPs. An address selection mechanism [10] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in regard to multiple addresses therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and the processes for adding, removing, and renumbering active prefixes at a site have been documented in [13] and [20]. However, multihoming and renumbering remain technically challenging even with IPv6 with regards to, for instance, session continuity across multihoming events or interactions with ingress filtering (but see the Gap Analysis below). Or words to that effect. You might considering moving some of the discussion to Section 6.4, for intance. --Jari Tony Hain wrote: >The ID is essentially more detail on how to work around the ingress filters >with tunnels and source routing, but the outcome is already covered in 3704. > > >Tony > > > >>-----Original Message----- >>From: Fred Baker [mailto:fred@cisco.com] >>Sent: Wednesday, July 26, 2006 5:30 PM >>To: Tony Hain >>Cc: 'Jari Arkko'; v6ops@ops.ietf.org >>Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap- >>02.txt >> >> >>On Jul 26, 2006, at 11:42 AM, Tony Hain wrote: >> >> >> >>>>The one remaining thing that I would suggest you add here is >>>>a warning about the issues in multihoming and ingress filtering. >>>>If I read Section 4.7, I get the feeling that multiple prefixes and >>>>multiple ISPs works fine today, which may not be exactly correct, >>>>see e.g. draft-huitema-shim6-ingress-filtering. Do not add a lot >>>>of text, just mention that there are issues in some cases in the >>>>multiple-ISP model. >>>> >>>> >>>Does this work for you: >>>Additional considerations are being documented as multihoming work >>>evolves >>>xref --- draft-bagnulo-shim6-ingress-filtering-00.txt >>> >>> >>I eonfder how many of these are discussed in RFC 3704? >> >> > > > > > From owner-v6ops@ops.ietf.org Sun Jul 30 15:37:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7H6A-0007jZ-CZ for v6ops-archive@lists.ietf.org; Sun, 30 Jul 2006 15:37:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7H68-0002Gr-GG for v6ops-archive@lists.ietf.org; Sun, 30 Jul 2006 15:37:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7H3w-0008Py-2J for v6ops-data@psg.com; Sun, 30 Jul 2006 19:34:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [193.234.218.130] (helo=p130.piuha.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7H3t-0008PW-WA for v6ops@ops.ietf.org; Sun, 30 Jul 2006 19:34:54 +0000 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A79CB8986F; Sun, 30 Jul 2006 22:34:52 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 51A678986A; Sun, 30 Jul 2006 22:34:52 +0300 (EEST) Message-ID: <44CD09D2.4080509@piuha.net> Date: Sun, 30 Jul 2006 22:34:42 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060725) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Hain CC: v6ops@ops.ietf.org Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt References: <071601c6b0e3$3ae1d020$247ba8c0@tndh.net> In-Reply-To: <071601c6b0e3$3ae1d020$247ba8c0@tndh.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Hi Tony, >Jari Arkko wrote: > > >>>tone/language >>> >>> >>Much better indeed, but still a few terms that >>you probably should remove (search for "marketing"). >> >> > >Despite the distaste for the term, people don't evaluate the technical >trade-offs, they buy what they have been told will solve their problem. That >is 'marketing'. Earlier versions were a little heavy on the point, but there >are only 2 references in the intro and one in the security issues at this >point, so I believe the document actually carries the appropriate tone about >why its existence is even necessary. > > I re-read the specific examples. Lets go through them one by one. Indeed, product marketing departments have effectively driven a perception that some connectivity and security concerns can only be solved by using a NAT device, without any mention of the negative impacts on applications. This is amplified through the widespread sharing of vendor best practice documents and sample configurations that do not differentiate the translation function of address expansion from the state function of limiting connectivity. I wholeheartedly agree with the second sentence. But the first sentence focuses on the role of the product marketing whereas in reality I believe the situation was more complicated. The desires of equipment vendors got mixed with the desires of the service providers, and with real-world issues with addresses etc. How about this: "Indeed, it is often claimed that some connectivity and ..." IPv4 NAT was not developed as a security mechanism. Despite marketing messages to the contrary it is not a security mechanism, and hence it will offer some security holes while many people assume their network is secure due to the usage of NAT. This seems fine. Product marketing departments have widely sold IPv4 NAT as a security tool and suppliers have been implementing address translation functionality in their firewalls, though the misleading nature of those claims has been previously documented in [2] and [4]. I don't have a strong opinion on this, but I would use "NAT has been sold as a security tool ..." >>... >> The downside with a Mobile IPv6 based solution is that it requires >> a home agent in the network, the configuration of a security >> association for each mobile node, and consumes some amount of >> bandwidth for tunnel overhead. >> >> > >Replaced existing with this. > > Ok. >>A random, dynamic assignment >> of home addresses without manual intervention also requires >> support for IKEv2-based extension to Mobile IPv6 >> [I-D.ietf-mip6-ikev2-ipsec]. >> >> > >Is this a level of detail beyond the scope of the document? > > Good question. We could also use text that has less details, e.g., "A dynamic assignment of home addresses requires extensions that are currently being defined in the IETF." >>>4.2 -2 does not oversell IPsec, it simply states the real situation. >>> >>> >>> >>> >>I'm not going to hold your document based on the -03 text, but >>I would still suggest the following edit: >> >> While IPsec might be available in IPv4 >> implementations and works the same way, deployment in NAT >> environments either breaks the protocol or requires complex >> helper services with limited functionality or efficiency. >>=> >> While IPsec is commonly available in IPv4 implementations >> and can support NATs, NAT support has limitations and >> does not work in all situations. In addition, the use of IPsec >> with NATs consumes extra bandwidth for UDP encapsulation >> and keepalive overhead. >> >> > >You appear to be assuming desktop/server OS's. Many/most cell-phone/pda OS's >and virtually-none of the embedded appliance implementations include IPsec >for IPv4. Even when they do they don't include the nat traversal pieces.I >did add the comment about the helper services not working in all situations. > > It is true that such devices are less likely to have IPsec, or other advanced features. (Features tend to be added to devices when there is a clear, specific function they enable. Perhaps more so than IETF mandates, even for IPv6. For instance, corporate VPN access has been a driver for IPsec inclusion in higher-end cell phone / pda devices.) Would you be happier with the text with s/IPv4/some IPv4/? --Jari From uvmjxpxrm@tpnet.pl Mon Jul 31 04:11:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Srl-00011W-O0 for v6ops-archive@ietf.org; Mon, 31 Jul 2006 04:11:09 -0400 Received: from awm198.internetdsl.tpnet.pl ([83.18.64.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Srg-0000D9-08 for v6ops-archive@ietf.org; Mon, 31 Jul 2006 04:11:09 -0400 From: "The IRA" To: v6ops-archive@ietf.org Subject: END Are Date: Mon, 31 Jul 2006 10:05:54 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0000_01C6B488.E8D409C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca0iOjW+mqUrRnwQReGB18gOkW4aw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 1.9 (+) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 ------=_NextPart_000_0000_01C6B488.E8D409C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C6B488.E8D409C0" ------=_NextPart_001_0001_01C6B488.E8D409C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit wrote. victory thought good shot rose quickly through rankings. Starting oversight Banja Luka still matches facing Kasparov. defended Indian superstar Anand Trade collapsed Intel major fields. Poland. Much sourced World Fact companies generates Request online use Finder contact PARENTS: learning We Article toolsSign linkCite Us Support Forums Pricing Buy Now Free being held McCormick supporter versus WorldList people beaten Unlimited Challenge Donald joke sister wouldnt funny advance Huebner spin roulette wheel soundly defeated Hungarian GM Zoltan Ribli seventh later saw chances bishop ending. made critical error exploited moves. crack cautious beginning mostly short violent middle responded crushing IBMs Deep normal controls Game retorted upon tear pieces question proceeded Nearby margin ...With proposed solution. died when old soon legally possible adopted mothers Jessie Matt: Such anger response simple Disguised Crappy hate Francis: :angry:i ash: asta really would liberated :pm Hes cutie too... going by: Parag AMMust harrowing youBut Corus Topalov school. Junior Tbilisi scoring repeated score ./.In Sokolsky drop details. At cost effective instantly build Zee features algebraic .d Nf .Nc .Be Bg .Qd .f .Nge Help spread word program. green Go button British decided outside Guest Blogging Iraq Media Memories Morons Sports Terrorism USA Women Recent EntriesGo epic Blasts extra Kids check Zone links animal geobytes inc. result. Bd Rc .Bxd .axb versus WorldList lavish praise reviewers including criticism analysis directly copied Despite Year award ------=_NextPart_001_0001_01C6B488.E8D409C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

wrote. victory thought good = shot rose quickly through rankings. Starting oversight Banja Luka = still

matches facing Kasparov. = defended Indian superstar Anand Trade collapsed Intel = major

fields. Poland. Much = sourced World Fact companies generates

Request online use Finder = contact PARENTS: learning We

Article toolsSign = linkCite

Us Support Forums Pricing = Buy Now Free

being held = McCormick

supporter versus WorldList = people beaten Unlimited Challenge Donald

joke sister wouldnt = funny

advance Huebner spin = roulette wheel soundly defeated Hungarian GM Zoltan Ribli seventh later = saw

chances bishop ending. made = critical error exploited moves. crack

cautious beginning mostly = short violent middle responded crushing

IBMs Deep normal controls = Game retorted upon tear pieces question = proceeded

Nearby

margin = ..With

proposed solution. died = when old soon legally possible adopted = mothers

Jessie Matt: Such anger = response simple Disguised Crappy hate Francis: :angry:i ash: asta = really

would

liberated :pm Hes cutie = too... going by: Parag AMMust harrowing = youBut

Corus = Topalov

school. Junior Tbilisi = scoring repeated score ./.In Sokolsky

drop details. At cost = effective instantly build

Zee features algebraic .d = Nf .Nc .Be Bg .Qd .f .Nge

Help spread word program. = green Go button

British decided = outside

Guest Blogging Iraq Media = Memories Morons Sports Terrorism USA Women Recent EntriesGo epic = Blasts

extra Kids check Zone links = animal

geobytes = inc.

result.

Bd Rc .Bxd = axb

versus = WorldList

lavish praise reviewers = including criticism analysis directly copied Despite Year = award

------=_NextPart_001_0001_01C6B488.E8D409C0-- ------=_NextPart_000_0000_01C6B488.E8D409C0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhrQEOAocAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAArQEOAgcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh1KtKjRo0iTKl3KtCnCAAEMQpUa1anVqzinFtRKkCvWhlGnVg0bViDZf1XNpkULtS3b tmThsu361q3culq9ru261uvcp3D3/lVLmK/cwIL1Bh6IGG/fuwcV021MVWzfwZbvLnasVvPm zlzPjp07WuxXh5DrGn7st3Va168ZPy5M2K3ZyLYH06Yqe3Vv3b8xs35NfLfw3YJVd2Z8nPdb 5qHP8qVLW3J05LIVa09+Wirp26bR/n4HvXXvdcPMkY+dnTs5ZNcJJZMv7Ld68ez3a5u/rxd3 9NjyTfcceMXBl15z+v3Wn3jhiUageN0xVN+Es+lmIHDS5feXdRs6l9d+8VX4IX6A9WZKcyP2 dmGKIdLXYYAKdkjaeuWVqB6K3AGnY30ResQihsQdVltwG7I3ZI1FIombgCymJiBnCtKo4mKU geaelDRKZ5yMDWa42WcIzpgamD3a9OOK5h1poZRHhsckm1sSmSKMSlqG5JlaJmjjm7d9RyeX Zc0YZ3DnJcjjoGW+hFih9m2VnZxwupmblXaBuKeYnx2KI36HsWdpaE9SKqmdRLq43KkYPsko qaCWmmhM/wGi6Siq8nGI6o0XOpckoTkWiuemqo5Wqq3PMRojrcZWGCapMiL6KkuxWsqZsv+t p1moa05LZpXRtoirp+9RKaKT2YI7KYnUVvvhpNv9itezFTkC77z01mvvvfjmq69Fjezr778A ByzwwAQXbPDBCCes8MIMN+zwwxBHLPHEFFds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinrPLK LLfs8sswxyzzzDTXbPPNOOes88489+zzzxEOIPQA/whNENFGC2T00EMrzfRATCcdNdJRK5S0 0wVNXXTVTj+9NdA1S3011VCTfTTRUH9d9tpYt22Q12qzLffVcdcNNsxio1103P5L6+323nSP rbfgCMFNt92Ey2333S5LrTbaff+9eOCDV64422Jn7TffflPOuMyOfw252Vpv3XTdiZt++tuj S6516Yof/jnLoS+NdeYJRT635bJj3vrZmk/e+eazrxy66WVbfjTwnruNu+avb37485JfbEvx GB2/+vbSMz/87pejbvblqYuPfctPf9918qdzrXrz5gO/dvTpqx//+fjnr/+9uezv//8ADKAA B0hAACajgAhMoAIpVj+4VQ92pUuc+8jXNMLBLnix61r7quY5+q3ubIbjXeegl7cNOhCEzxPh 8mRHveLBT36xG5/ofhc4DMoPd71DYfLSBr/y6Q58Nv5MIdUGZ0Pzle9vpMvc9pC3w8V97oUU 9J4UfVjEtv0wh+xrIuDs50MZco51vpvf2IrYQeXBcIvrmyERvcZG4j3Rfmc04vcciEXhaTCO GHScHrloxhkGkXgS5N3jyDjHPj4QcnsT3SCHqLs6Ag2Kriuk9wB5QjsykX0spOHt7ic4D/at ku8zo+0UiUIZfvKDpcwiGzc5Ohq6kXGQRJwkxYjF6VHyjuG7ISIV2cM+/vB2r/ylBTd5xjI6 EYyqS2YibUdEK77ybrG0pRTFyLc4ZhKYudRg+nbYyxjKsnqPEyXStIjEWfZOfQ3cJfLc6EhY wjGK1Izn8b6ZR1fmbo7c5P+jN6V5yDAS85LlnObkYJi6yo0Tme3sWQgPEkH3NdR3qAxlMi04 QSPqko6+ZKQwpYfOVcITk7875AcLyjyGhnSBKE2pSlfK0pa69KUwjelIzCDTmto0fwmlSE5p 18z7SfR9ASVhSFXIw1tas4IiBOUxX9jDeAqvjcvD405NqtOI9gOcrENlOx0awpFG9FV5c55W felT1IWzdUv0KkcRak+rfbWXgUTrSQO6RBDatSJTRSZVF9JRR87Sj87MV1g5x0+zQrGGg/1k UUtYxXB+0a3n5GNcsRnZSaZNh8rkmmK1adDAUpWijr0nHt36RdAKFpFt7SYhG6tHVqIWqPyk BkT+31lPvYYWh8tkZOHwOc8tIrW0SlSeXLF6RbK1cLUPKS5wlRoTIpgknf4Ua1YrCtQ7epSZ aSwsRIVq1Ew+lLC6Behq0Zq17I5PuUdsZDDPa9y54jKbezUtYI9ZJuh6VrrI3a1128fKy9Lz orTVpW1xaNDwKrWD/1Saf9FL1LMyVr+mZW5QGVJQ9j6WXvadWoVX+M6+Gpibew1fcOGr4bXS UrNIHfGADypedlpYvup9Lxgj/NViPtPGTlWuvTYMRMN2mKCiBLFtLUlg0X50vhcO5IoT2eLP Nli9SYQvYH8LTjhCsrAMlnKPeIxfbU4Yk0D2Lymr6MHljvWoAk2yOKf+O8/pxReqzkwi90za yfnmkKtwBmkrO8nnG9/UI0uAV16NfJFB/xl9fk5uohuy6EM7+tE3kQSkJ03pSlv60pjOtKY3 zelOe/rToA61qA/SjFGb+tSoTrWqV83qVrv61bCOtaxnTeta2/rWuCYIAHa965v0eiAAmMkm hj3sgRCb2AIpdrI38Y9jF1vZy242s5NtbGY7e9rOXvaxpb3ta1ebINP+dkGenW1vaxvb2wZ3 uKXdkG6vG93IrtivBRLsmvAa2DKBdrPZ/W1o+zvc+ia3tqOtb35TO9oIFze/471vdb9b4OpW uLIDXu1/O2Ti/jZ4wyc273/Um9e/Bnmw7+3/8ZF3nOS9RvnH6w3sebNc5fcmecldznKJUDzg 1ga4zhXOboyjW+Ma33nCE+5zY4873u4+esQX/u6KC50hRac2xSnWcXq/3ORWz7rK6a31kGO9 5AX5+se7nnWwe73sEyl40HMu8af3HNsNhzjPlw50i+974uPmtsALjnOEq53pQ1cI3ge/botV HexkR3zKrx72r5t95WHXeuMVD/mzZyTbaze43fWebnf7HOnpJnq5MR93a+ed2wQf/dIxfhDW Az0heO/566lec7Qvvuy3xz3IEU/5w1fe6jGH/ON33xG5v73tPP+83gOvdNErferPPv3GjZ95 wBvE9X9vPdxln32J/p2c97k/O80pD/6V+77lYk9/4jfy8MxvfvNMJ7frjY78wM9f54UvfOqb 7/efG/3a1Ad724d6U8dxNed44Vd5jCd+jId2uoZ+5Gd5uedxDhgR7dd37+d2GTh37ed8dBd7 qAdu2ld3Tzd/d3eB+qd2IIhs0Kd/DCNy6CeBCkh8MzeB42cQB2h+Cah7N0gRpGdunPeBHah5 +Ad6DEeESddvdHdwzzd6odd5UBhx5sZ3LLh6T+iCJXN4EKGFmtZ9QMOFDgGGmIaFuVaGZugx dnCGariGbFiBHiGGulZ7bZgoMOiGCyGGdSgRcNhyIoF5Gbd//5eCZDiHd3iAdqgQYPh9/3oo hwixhxVxc/CWegAXggNHiIv4gHWYh7tneXyIbwwYfDMYg8LniBABiZUof4GofJYYEVrYgxP4 eDgohwxIbw3QdQrIh5yoESoIdz/HdncXhF64io1Ig67oeDU4jFsHixG4gMzYh1cof9sXfZE4 e8IYhsJXfrw3cw3hdTK4fjZojM54bstXer/IhMFYjQ/YicWYjTSYjjw4irfojeDIER3oeQNY hdc3iOjojuRne8b4ilzXidi4jLjYjNl4eUIocRW3cUu4j4jYjjBHczvYeDI3kJ8oc5l4jewX ekRIfwQ3gg65E6QYki4zkiR5kiiZkiq5kiz5aSZZiC1JMHkokP80uYXE95IyIQA6qZMHsZM8 KRA+KQAxaY2syIgM8X04CRM/+Q9LCZRC6ZRM+ZRROZRHmYMUyI0Y2Y1xiIk6eHVe2YAnsZRN OZVQKZZSSZXDGIe3d4PxWHW+h4Bi149JaRFmWRB1WZdomRAwOH49mHhuKYtwyY4amRJ4ORB3 KZVjmZdbKZDfCHxYGYuQyZZYOZcZUZhQeZlBeZaKuZj+iI0y+JZcOZDr5xKWSZamaZiauZkO yJfm148HuZrKaHbeeIghgZc8WZqJqZqCqY4JmJXI+JkSGYM1WRJBiZpOuZOomZu6+YZGuZwi Q5nOGZ3SOZ3UWZ3WqTDQaRQ5Qi+aUhL/3VmSgLmNzcmZFJmdKbEf7UEu72IlnOIf6tKelfGe uuIsH/GdLFORFamX4zmc7NgTXzIdytIo15EsBVKgw2KgW7IdKGGfK3OTWfl7wOmYtaeI2jh8 /CkSDTKfxjGgCAokU/KhG9qhuaIcYqIfWcKeu6IjMGNywReQi7eW8GiHrWiLuneegbIkSiKg IiotzNKjPKoluTInI2IbmQGkXuIqKwp8FfiNkimj49mYLeEkY3Iux8GhBwqighKiWBqkWLKj CLIuASozL8ebLaqkojiYdtgHmwiW0EKlO/KjVaohcbqlcEqgfDKnevKl0jIzjLiDEsmmThqa sWmeGJEnCVqn/14aLHjqoXmKJo1hpY3KH+yynfd5EH5qkC4XqJ4Yj65pEqVxo+NBH0a6qEPq pefho2GyLKMKqXhqLDHTp11pkTqolrH4oC/qmzaanrp6quGyq5Lqq/BZJMDqIeYCpnhCpF3K aYTKEZSqEAwKFs3qqZRKIRvxrBOTAKexrNVaEdGKGjTRndSaEdZ6neRaruZ6ruiaruq6rux6 MXjQrvAar/I6r/Rar/Z6r/iar/q6r/zar/76rwAbsJPGDwTLDwJhsAOBsAf7DwRLEAbbsAmr sAdbsAgrsRLLsAUbsRTLsAVBsRC7sA6bsRi7sSN7sSVbsSJ7shbrsCybsR/LsRP7sv8T27Ie C7MgC7Ik27ED27Ism7AYS7Mhq7M+q7AmS7Q367M9axAPi7QLW7RJe7RLi7MIEbU2a7Q/i7Qr G7RDq7RPS7U2y7SOZrIwG7UVW7UcW7YXu7Jly7VSK7Rgy7NHG7dfy7ZNi7VTa7Zfi7ZbqxBU 67V2u7Zi+7SHJrZ6O7ZmS7Zzq7Zzy7RrK7iB27d0+7Zue7Z2exCQm7Z1m7kJcbmWm7mNe7cD m7KFC7h1W7hg+7CBW7Ia67IdW7N4q7oqG7NFS7I567GNi7JsS7pEK7O667qju7qde2mmi7il O7OJS7uL27aLi7l0S7jJ67hwa7Vua7rKu7TMy7iUy7VG67z/k0tpuxux2Eu2n7u8cou3Tiu4 suu8qRu3iqu8ISuyn3u72fu22/u8Hyuzkru+MZW1iXu6fmu45Cu3Vnu++auz7du1kwu5Aby3 5qu1/Au1/8u+p7tpOdu/EBzA45u3CRy7NWu7Fky7vpuyqxu/HGzANOu191vBeYu6tZvAIiy5 lrgIApsTtlvDNnzDOJzDOrzDPNzDPvzDQBzEQjzEKjzDRnzESJzESrzEB7OfNuHEARmGPQHF PULFHtOOeolvF2HFlgqoOEiBd1ieljrGUWwR+fkQs6qNmTqmx2iIe7mmEamfKafFVzmmbKky XAzGelwReTx5tFnGiMiPZBx5HdHH/1rMxtc4ci5KyFw3oYPsxI4cxQhokXhcq5Ksxii3yBWK ya15lceIiZ68yZtopplMxxAYynWsyBVKjInomKf8xZcMxqqsyGxsyqpsynQsi4wcy548drSs x4Z8MaWMyrdsx4tszLm8qbzcy8QMzKgceRMacp7ozMjczJB8yftZy2MXyuAYkbfqyracqRQ5 zbMsy8xcy5VczcVMzr28prk8ysu8zSw6x428x23ciNScz/W8z3UcxvqcxeBszu2Mz268y7gM yGT8y/LMzcucMuuszuz8y5GJy9qcjr7MyBKNzQTNzvz80O8M0NWMzwi90BkNytMsyAhtzwnN zOZczs5cqf8QXdEvjc7r3NG2DM0nzdIaPcbGHNM5bYgqvc3PbM/orMmyGdR7fMsp3acpzcva rNQzbTKs/JWSZ9Reaaa959SC3Mn3vMoxp5ZXLctb18l2LM4QiMjSTMjRXMwPPcypfKtPbdYB /dLADNVCHcwxideDnC9FTZLPwMdvqC99zcSEXdiGbXgcodcxodgovdiFjMaMrdItY8WRfdNT fNAGPdSSjRGKDdSZDcubDdqcDdA3U9llbNojMdiNjdSBbcZH+dpNLdpbTNpSjdWfzNUPitUQ yY2WfNu5Tc2/nZ+gGNb4ucmfLMp/mcYwt8+2ypW8bdycHNannMksWn5CraTLDc7/v+0wUK3R Ra3UEJ3MTe3RNu3T4q3VJp3e583P7kjewL3TSa3Hk0DXnh3eWp3W1/3Mnp3e7g0x89jTDsqk 9BzfDQ3P1vzT/1yD9X3IX43TGO3Kb9ngxGzge3nT9r3gjQyRyYzILirh4AfWwF2m/k2TPf3g Vb3eMg3f7r3iBA7a5q3eKk7iD/7dFG3hCH7aGy7S/0zSOY2LOc7eF4ow+13iNo3gNI3iRp7k 5d3eTL7kDs7kR/7jzVzkU+7kdE3fV17RHH7gX6zlNx7bTQzdN6nboPjKWPzcIB7ezY3WXO3j HZ6LGsnm1T3OM/1xiHDdzX3jaO7mYh3JpHzIbw7ekvmY/16N2v9i6KuI6GHunGd82I7+6JD+ KtpaFIrexUnRx5X+mjSD6IOt2ivR3Q/piDXdxXJNEZ6+haz95DrOxawe2iDD6f5sb3qI2XtN 2qZt6EbZnNls6rM+Mtkd0Hm+3GRNz3Fs27P8p38+q/MsnOKd29Xd5hwu4sDO28MenGmO3XNM y8P87KQs3M8N3oXOMSEd4y/uyOUu2Wld5Rnu3V9+5fqd4M0u0Biu5Fw+4y0uzedu31julu6u MeMe4gPO4l1d7/8tinUe8Byt7lMN7v9+3C6N4RS+468J4OfN4ude8UjtxRjz7+Oe7/Q+6hTq 5wKv06NO1D3e34DO3Dhu5SMf8v91ve8fL/EYr8vRLO49Tu4x7/Erf98xX8/6LvLx3fDRbtQS f/E7z/BSbvHt7uWqDuYGmN8Hz+y+qdzHftdiTqva7eGjLOcoHeBTXtwcjecMLn5/nuGAme18 uanIftTbzo9u3eHQXTOZrhG4HumNLhN3PxF5H+l83/d+n6+KfuqfrfeEP51MDdi0vRHy7M64 lxHX3PTVqddP+hFi35mujsawvdpsOObVftHVnuxZTucLH/Xc7OH5XPKcT+YIz8mgPNVlWNbk ftFAvu6hz9M9r8zwXuJR3s9Ff/JdLvO3duFFb+ADP9RrrfSBDvNNbvVJn/Ndb81YTGvC/+I8 f/MLrvP/VW7XKb/7IN/7B53RoG5r0+/88D3SUE7+2W/ygMz9yl/vGS/zcw9pYz7dbY/cEJ7Z Ab7sWf+YOZju7p7fAAFAIIB//wgWNCgQ4cCDDAsOfHjwoUGKExNKlIhQ40aOHT1+BBlS5EiS JU2eRJlS5cqRGUO6ZLkRJsuZJ2t+dHkz5k6ePX3+BBpU6FCbJXXS5AkxqVGOR4k+hRpV6lSq H8NVxZpV61auXb1+BRtW7FiyZc2eRZs2pTy1bd2+hRtX7ly6de3exZtX716+ff3qbfZX8GDC hQ0fRpxY8WLGjR0/hhxZ8mTKlS1fxpxZ82bOnT1/Bh1a9GjSpU2fRp1a9WrW/q1dv4YdW3br ebNt38adW/du3lEVkvzdNnhVp2SLV7RYFGROj8dDM3Q+HDjG6MelR7y+M3h2o0pfLtROk/p3 pxmdazzKvCPB898h/+bec3v16U0bthc5f2V7jOH3j18OOPRSSk+m5l7TDz722Evoovm8c9BB 6qRT8MEFuRsOuosWUkrDCD2MMECZ4AMPIocqagg7Di9UkaILJRLCRRk3xI5BGjtEzzsdM9wx xRBXtLFDhfq7ccgWT6SRrwTv+3DBiBqE8kkph2SSwxGjxDLHnKqk8kkFo/wyPvt8nLHM/ny0 sUzkziTTPBnThFPNAd1MbqKZzixxzQHtRK5PPMHL/pNPQf9a0svxwqxSSiipRHJRh04Uk8cp nWwQUSsrhTA/Pf/c9E0JwQQyzjrR/BTPLY0EFEUTYWLTRD1TZXC7PV0E0MxN8XOrUEyttBRL /XZdj9IKKW3OPC6FRRbMY8U0kFNRPY012FdhTRXFQZOLllo6bVW00zmrdTbNaRP0dk1c0/rS UWXVTVfRXu1Tl1dWE423S2DtjddQTZ0dF1t/Ay2XyDptNXVWcfkFF+Bs/QRYTYEZjvNhMvEC sdRDl6XQ3mGNrfHFFUfMeNIaRd4Q0XZBnhBIL8HrR2AhAcTx34HvmzDIYRm26FEKAY250Q+T fJnFG48sUVbPmH0M6d7k/joXMZ8ta3pps6KWumqrr8Y6a6235prQpdYjDimVaqI6rLKTOnvW nx52z+lq9zuwqaGibnrbtOV7m7yY6Ja7QJyEQlPnS+9Wi+2x4zYQcLEJNHiscwk/HGwREV97 1EsXVfJlFZHEkWaVtfS8SJ2C/vzjW0kcOvQfS+4RZUFb5/zBR1wlMlObQ4891h5PbdHOCtUW veZXOx9ZPWjz9ogbdN9+NuI2p4VezoHBRvjfIPNk01+JtU3Yd+0b5zRg6BcW383qy1VY8r7T Z1vYhjt99q7aXdX+0VDH55n+kYtFlduOqeVTuPRnt6JBqHrEalX/hqcqAzrMft4bVPzCF0FW /rmOX/Pr3wRrJzP5sY97jQPh9yKIvPJ1L3HwS18I+0W2FJoLfTiz1sS+tS2ZGel8E5RThsDn wRG6rE8LjF5dLvhB/0mQh0AkohFzZq0AtlCJ4ktiwoYIwH5hb4eWi5gJxXUty0VxikX8YftI OBdICWl4qOudz8qYLkiNSVRqRKPHGDgqC10Jg67z0+9+1LpKgWtnuItj6vKXMRmqKkn701kd Q/RARKqQiX2BnG+mEkm4MW4vlKzk4gR0SaU5jiqYtCRKQPnJTvqmlG3TVNdUuUpWttKVr4Rl LOUGta+R8G6jnNsPT7g3ym2SNVus5dnKVp5adlGXmdzlGE1iuJYc/1OZyzxQBdc3OVzmBZOQ G2Yqeak2ZkbOl5pk3Ojwpr5kAm+WnXng7vb4oJL1bnODFN3mbqI50JlOS0Rb3apIhLtByrGA gEyRPzUH0JR5io7sPJIiVeY52tEqkPQjnWM0WMJr4RCGB/tgIWt4RRii0JjZo6j/CKat532r h8wz6EWbxVECYnRKIc3i9Nz2ugGWz4d3Mp+77kcq9W3Pdwa8Kf5ECFP8CTCD/STqzwJ6Qpoh kJEtBdVQYzpSmR6mYCcd4cq4mKOKxo+JLOSgRXllxY86MalYDaMXj5jFpbJ0rCoM1wrXCkXG XJWqIp1qT6fpLZ5SEaoyZasWzfrFnGYVjP6ELaHhbkhX9DWPqOdbTDpJd0eg3e6esPpVz5Z4 pUOuk3f4hGNjFflUkxpyaNYzIz9z1tDp5U5olSWk7g71z8+hKmbOxEw1q+rNwuhWkrIkzim3 WUzBZMouvgVucpW7XOY217nPhS4kkZtLqEzXnM2UD36E2ZrokJN/xfFqPXcrFQ1Zh3rIo+Ez sXtdbQ53vdvdGjHHy16miqWb0Jzc39w7314iU5vwtaoeV7W/4K22oD8FaH1h69A5ApBF1yHe gt15ztw1q3O2RaNDEzwj2PEIoYescEIJSTRjCRTCAp6wkq7Y1rTaFZh39WmLS/viDfbVwhyU nl4NO1IxFvawz/5Lb/RoPNcYg9SvQl3ffTuY0ayS9kXEmutBhedjGuvoqxa8X5P++08qc4uR MH6q4FqLVAhzuVSC3epNG+Vh2Qr3LX9l8VTJdzkYm3Cod93TnyYGWZeJ884zrnOXxQhYYB7w rygta5qJKC27DgbOaA2sMess6ca+0HpXjuKONRpULJIVz3I26/sYe2hQH1majPWgkuWH4hiq U896TCGsWzvQM9IwWzL8squNpuAG8xDDCnyjakVMZwy+lsB8jPFp7QjPy/6ss2fhgUqYgd/o Vvs91sZ2trW9bW5329vfjiWGnvI465al3Hs5ByqDcm60nHqU8qVvrsY577ax+7e5tP+3cSg8 bo9kIm/59k/Aiavf3vI7MvSU54cbqTrSsq7EJMbjbfkpxwGLWHXDvlmDKdtZhOtTw6VbZK/t l2CFt9PAq0sjm01n2WdDUtScVulDj6hLNdcXsTKP4cxFGOdAt1Cuai0rzmk1TRZzs2HdHPJJ XYpba76cpA00LKiDDPNM3+6or0NwXv9HKhfTVJ863DrMn+jY8KUTgly9c/sq7lbyVcwvOKS6 WyHd0Y26e4G4ZnIOnZ5npfPskVVl5lEXG3W6Xs+Fy64omn2Varo7eu+jHuzM7a5owks1UDyH ++X7vlFNU7HnQQc6XymNViTbmvEEJMxtubrxRtpzjYDkZob+awt2fIpe4/kD2WYp7s6Hp1jA 5Cq2eHvv7OIt0XajvfpCY7tyjbt5MgBfL13MC5YgR//NJonGL9vtfE9aPyu2Wyb3vQJ9cJff /IMJzPnVv372o5261FbOukM5/0nmV+DetX9/vb9/prj/7ffuP1EiuHMawACkP/LKvwLEv3Iq wDs5QP77JvIjimrSLt5iQP7CFb7BCj+jtwXUPwI0wBCMP6azJhTbsJYTOVZbOXW6J3pCuJOr tS4KnKWaQa/DiYxDuZ6RtY97p+CTsNZLpILaImETNkwjnoAywWFLsa+ouZjTm62CwkkbPTAi sqMzvqLBOgjqLsjytKKywpvTK6n/w8KVmjs6wby2asJDM7dMC7sA0SD9KT5Nk5gBWrNP4bBc Ox4K2ik6CxbBYx7a8SHJs6m1454LCrM2Q0M8jJa4qjs/IsTugzx4Oa/Eo0QpfCtUczq8syIx TCv/YzvBmq1OS7wv8r+um6i90jyjW0RfY8NjEr8JbEWfYo6ys8K526sDmhNz4Dy92ywvszRN tERa3B5hjDLQA8NbNDUFQxiyU7y/G7/L6r2OSxxkg0Pia6pmy7gdvLho5DWJKyBs2bWFQqp6 ei3wu6NrXCRtvLyaUrY8o712HJdA6hbVc8Fw9JqrkUD7Wr98lCioecX2A8iAFMiBJMiC7LYt EUDhAKv9/5q37ho4CBzBDnw74/okEpxCgpu+C4S//lI1ZaKkGcQX2bNA/EubklSvJbNIg0Ol 8+jIBIxIkjxJpvvIj4KZhywnkwymggPHA6vHkgNEhgOqiWtBPqKteLrDlDm+bWSUA5sZHGy4 CPsyFJrDfUq5q/O40vFGjiPKiPqYEKMYv5sZJ4TCLuu8+ulGLyQ8oaO5xxs8ZOwPZ0AptZRK UAQyQeQ1W7S8tuRCMtqda9w15yFAOGm4RjzLipGzQwzJfZs8DUsvJ4s1duRFTBPLxzInH7S6 lgrCsTOzrxQyzCo80xs0laI8S8NLHNMqjkpGcjpGKRxCsCyyn/s0xfQ7jXoh4/9BvRw7LrDE q0gURd7MPMsrRsdiy7UETtArw8hzpNcUu0qzuSMzzmBsRSFyxylDqFYZE9NiwYMitBgENEfZ M1gbMVcMtlPxSxZ8vTzKsEEjT+1EpHoEIc5ptmOrzj/kToMsrvtrr5S0T22jyAfkyP0E0AAV 0AEl0AI9mvcbt49cSMVRSaBojz1AF350PAZt0Mq5S/lTtxG8JVeERWyKyQvNLQQVUZ9YTApV wI0k0RO10BQFp4PLRmqsToWqyhWcl21kNuN6wa+zp4WryvHUSnTMJ9aRJ9eDqN+rUQJrQaOE xhddxbWjtQLTSUuMzbKUMc/7TYcBxX2jUvc5To+EPK7/u0LSo8Li7M1kuzmemsViLC7HNLC8 Ki9HvBkLUUOz/J9Fq7s6TEu7xLLOA9NWqym/zLK8TMyaMb0uNcI/9bl7DD03vUvbvMTm7MYX +0U7ZUNOHLPSNLxM7cSUCi8yHSuk+8QmM9ROVbFRZc7d5NMsbdTSI07fhE1GhdTd7FPM8zTh 9NRatbPV7NPP08/jEjpAhcHs7NEfZD43ItbaWz1mqy1sjCgzIsdxzEJNhS2rm5QjFTLU2UGj RKyvSq3ak9Bs+1YDPUhx7RouINdzRdd0Vdd1xZtw9UAQvC6qEbcKZddnrMDvExAHnKFe/bcP PRx3JVdJXUMI1Fd+vVSDFUCA/z1IhUNTqmRW84GdFBRCGWW5ij1CkwsjWdPRCWM5jJWtJazX J5zGzUNFySupWsSrukzTJrLVSSVTtey6kA0/fNnEM1vPMqPFOhWzM6NJ1nLMttvUQns62iuv oKoVma03YstDlD1aWA3aR2XVfe07jHLUxZTUwIs0PkRaLQ3LXgRaSXPaxdLLmp3aTaXU5XRO ktXNx+gG2Egkro0w5VvZORq+tx1WR/S63bMZ9BLJPoJBvJ1WQ7KyrcVHwiVchTXcxFXcxWXc xmXcSqgEx2UJyFU/yi0IyMXcy41chKBczM3cf/DczbVc0N1czvVcjRhd0jVdzT1d0m1d143c 0I3d0P/diNSd3dMd3dK1XNrlCN7FXdqV3dpt3eCF3dRdXeFl3c8l3uIV3dIFt9113tlFXemd XtRV3eutXuHNXd2lXs3F3u3NXuzt3dwV3+tV3u4FXeTlXO893vINX/HtXO4d3+iN3+oFX/c1 3m6738uFX/SFX9XNX/z93O9F3/pl3/5t3/ldX+OF3ub93/d14PYN4ANG4P013QYu4O6F3o6Y 4GyzYAo24AROXo9g4AgGYBM+YQmmXxG23t0tXxd24A52XwSmYPUFYQ12Xv4F3gwm4Br24W37 YOaN399VYBIeXhM2YNu93QGmYeatXe9dYgyG3QsOYN5t4uVNXh7G4vV1XSj/XuHlBeMc5rYg VuIXFuPXtWH2Bd8NXt0QvmEW5uLOFeAhFuMZPt4y/uE3bmP/5eL09WL75eHxLT8L1uIctt0U FmQqft0BLmM21mM79uMuzt/fdWERXuErruNHRuQq5uBCPuAqzmQPlt8F/mJDjl7zPeNL/mRC xuEEDuI+zlxQluD3jWRUDt8OxuM/9uE6duMQdmRa1l/uPV9APuJhruFcJmD6PWJiHmUntt49 XuRmLt5OPt/93eISXmZL7uQsRmE6/uVvk2HJHYlwFmVxVglyNud0Vud1Zud2dud3hmep8Tfn CoF4tud7xud81mfEGId99ud/BuiAFuiBJuiCNuiD/3YuRliNaUPohnboh4boiJboiaZowyAA AtCIi9ZojC6Ijb7ojvBojP5ohPjoje5ok+YIjz5pkx7pjOZoklbpfwjplObokZ5pmX7pko7p jbhpl3ZplPZpmAZqkH5pnM5onB5qmCZppWbqldZop67pom5pqBbpnW5qpH5qqqZplJ7qojZq no5qrpZqrJ7qkw5qm/ZqngDqlkbrqw7qrzbrr+5qsD7qss7qlSbqq7brqIZro2brqnZruO7q u/7rn87pw/aItWZrwU5rtOZrp6bruO7ovi5ryS5soUbsuK5sva7qnAZrqdZpnyZsxjZspm5r oFBs0QbtvJZsuX7syX5rmf/ua6yGbJrm7MgObaUu7Mt+68Hmbcbm7c2mbbye7MHG7dMe7qae a+O2bcsG7d/ObdY269Eubdo27tFm7uQ+beFeie1e7ezu7dV2bZCobLsm69l27tiu7etG7N9O b81+7fGWb/SWb8CWbfCWa9mub/FGb/x+b9Keb79O69u2b6/u7NC+7vxmbuRO7ZFg6bs27fiO bvr+65uu8PIOa7IWaeLebOhu7Kxmb922asxecAl/bMeG8LOu6emm7A/X6cvObgzv6fAeau9W 7aROcL/maQ63bxbX8RJ3bvfeCRsXcfX+7wB369028KVubeXm7/BW7SIX7gnfbxWHb/q+cv0u 6Rb/3+oDj3Aoj+wmT++9zvLpHvDW3nIdP2rYFnDRZnEg5/LAZomQnvA6H3AP12z1VvIdb+4w 928AN/Mip/DXpvMeF/CZRm7DZmmhjvPSFuuehu5GB/MLf/AoT+zvZvQ1p+scR2ouL3Q594kQ L/Mpz+wsf3LSNu8+B3MxB/Q2D3Qxh/HvzmxR729Mx2sh/+8YL/X7PvVcN3EA525OT/E7N/Q0 7/RYX3UsVwn2VuykTvYXD+sOV2lEl+7YnnFr3+mYxm9aP3TClnU9t3Uzd3Ynv200F2sjb3U7 13ASd3EQ13PWtvAb9/ZnP/OKtvd7x/d81/d95/d+f2ju9vfXmHELH2to/9/rShf3p55rRY9v 6y74Wa/3gJ8KZBdxz8Z1Mn/1TNdvcsdw4ub1I5f4rOD2F2dydMd4V9d4A2/vD/d4wP7zkJ/4 b9ft/A5zI89t87ZpPzf0PM95HI94mF92hR92mfdxY5dzgnftRVdzdof1Ff/xjgd6kSd6NTd6 Vu/4RNfyDYdyqOdrL0f3qIeKkdf6Tq/5o3fvw1Z5QT9rRqdysJf6L595jzd7ot71jR96tTdt tif0n3d71LbqeA9saW92pj91gn9wo49urO/7xWf8xnf8oaiHx5d8ig6Eybd8VQL4y/8Kbffs jP/4sh94zn/0RHf5ET/v2Ub0ac92vmf85c7wQ/5fagi/+zJHeTQn+88f9LpOe3CHe823fccW 99gH8dn3fCp3/c43+YcH/d1H8svn+qz//A1X/ZpX95MXfjaf++XXftoH+sNvd7T3+q7P+oYX +3U/ffEvexJv8tRH+Ob3ffiGdtjecuS3/uqP+DSvemXHe9RX+QZ/f/EGCAICCfwbSLDgv4QD ESZsWPBgQ4EOJUqMSLBixIkXLUK06DCjR4wKOz78KPIjypQqV7Js6fIlzJgyZ9KsafMmzpw6 UXbE6BMiUIopT/4cqbHkxKNBSSI1qZQkUahMm+6savUq1qxat3K9arBnUJBGp0Y1qNHsQ7Rf FR41OTVtxa8X18ql6v6xK968evfy7ev3L+DAggcTLmz4MOLEihczbuz4MeTIkidTrmz5MubM mjdz7uz5M+jQokeTLm36NOrUqlezbu36NezYsmfTrm37Nu7cunfz7u37N/DgwocTL278OPLk ypczb+78OfTo0qdTr279Ovbs2rdz7+79O/jw4seTxwkgNz+WmspbB+D+/F74o/nRTx/TPnvv 8uXj5f+ZvkMAvoRfftzt19B78CX4z3sINsggggk9qCBL6VlY3z8YZtiQhRvWd6F9+BEYIIYa ZmgiiB1umFCIAoLIIYomkuiihh+eOGKBrB0IYYQ7QsjfeT5KyKN/H7nIIZIinsgikkwqmf7S kx4GKCWTVK6YpJIEqlhlk11aGWWOOj7I45A+BukQhUWe6VKUT6rYZpNbogSnll9WKaeTU9ZZ 55R95skljmGiRqGECa5J5qFEItpgkVB26eaKcN555ZyP3ljilSH+eSmlcnpqJKhJWiqojhGS aSqip6Y5ZJkDjhoprIDGSWmomdJqJ6yabmolryP6querpKa2I5CptoqqmYquJKmtsjp7q59Z 9pmigM9+uue0XGq7JZjCnlYsgxMiW6h7aKLJKKsqMbvuq4G2y2KMFc74KafwVitijTUG6y2/ iNlYa78B6/UhwQUbfDDCCSu8MMMNO/wwwQJLPLG3UVB8McYZa/68Mccdx/eXuzjx2VfI2sJU skzVesyYoaiu1GijVgU68sl+8oUyyqDm7CXAK7NsLkwxdzWzzWwWvRfONO1stM+O+bfmhOiG myaj5ZK76qmV5gugjS9um62sdO5br9c3enhk2Ge3qLKUW6fY9GFP/wi0y3MnW6zVWRsJ6aN8 f90sroH/iqWoMBZu64Ve/nrvpDzDDZjcicpt7qEH4n0f2M9CO3KH3LYtKp6dik6zpp3v2m2v jZuMGAIZR15ouqwuWHmPLQtd6azB4kj653l6bvreXU+r66TA00s0n8RD+3hfr/f4Ee20H0s3 06oDfivvwH8ubei723x87+BrDTbNzHD/Be7llD9/t/p1A6w8mMSX3y39in+dfbSWYptt8n+b D/mCypS32V1tbulSkLjc9z3DwetSzKJV/UwWPxihzUkVBFyW/qXB0wFKRv97TsnK98ER4gVi JjwhClOowhUWjIQufCEMYyjDGdKwhjacTUAAADs= ------=_NextPart_000_0000_01C6B488.E8D409C0-- From owner-v6ops@ops.ietf.org Mon Jul 31 05:50:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7UPx-0002ie-1l for v6ops-archive@lists.ietf.org; Mon, 31 Jul 2006 05:50:33 -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 1G7THz-00036u-92 for v6ops-archive@lists.ietf.org; Mon, 31 Jul 2006 04:38:15 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7T6L-0000OV-1B for v6ops-archive@lists.ietf.org; Mon, 31 Jul 2006 04:26:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7T3X-000Cao-N4 for v6ops-data@psg.com; Mon, 31 Jul 2006 08:23:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G7T3V-000CaC-1W for v6ops@ops.ietf.org; Mon, 31 Jul 2006 08:23:17 +0000 Received: (qmail 18654 invoked by uid 417); 31 Jul 2006 08:23:15 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 31 Jul 2006 08:23:15 -0000 Received: from ericklaptop ([12.153.127.2]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Mon, 31 Jul 2006 02:23:14 -0600 Message-ID: <003f01c6b47a$8f378cb0$9ac312c6@ftssoft.com> From: "Eric Klein" To: "Jari Arkko" , "Tony Hain" Cc: v6ops@ops.ietf.org References: <071601c6b0e3$3ae1d020$247ba8c0@tndh.net> <44CD09D2.4080509@piuha.net> Subject: Re: Resolution of my discuss comments for draft-ietf-v6ops-nap-02.txt Date: Mon, 31 Jul 2006 11:23:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.0 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Jari Arkko wrote: >>>>tone/language > I re-read the specific examples. Lets go through them one by one. > > Indeed, product marketing departments have > effectively driven a perception that some connectivity and security > concerns can only be solved by using a NAT device, without any > mention of the negative impacts on applications. This is amplified > through the widespread sharing of vendor best practice documents and > sample configurations that do not differentiate the translation > function of address expansion from the state function of limiting > connectivity. > > I wholeheartedly agree with the second sentence. But the first sentence > focuses on the role of the product marketing whereas in reality I believe > the situation was more complicated. The desires of equipment vendors > got mixed with the desires of the service providers, and with real-world > issues with addresses etc. How about this: "Indeed, it is often claimed > that some connectivity and ..." I would think that changing the pharase "product marketing" to "hardware companies" without pointing at marketing as the speciffic group responsible. This should maintain the message while doing away with the word marketing that has been causing so much discussion. > Product marketing departments have widely > sold IPv4 NAT as a security tool and suppliers have been implementing > address translation functionality in their firewalls, though the > misleading nature of those claims has been previously documented in > [2] and [4]. > > I don't have a strong opinion on this, but I would use "NAT has been > sold as a security tool ..." I can live with this suggestion. >>You appear to be assuming desktop/server OS's. Many/most cell-phone/pda >>OS's >>and virtually-none of the embedded appliance implementations include IPsec >>for IPv4. Even when they do they don't include the nat traversal pieces.I >>did add the comment about the helper services not working in all >>situations. >> >> > It is true that such devices are less likely to have IPsec, or > other advanced features. (Features tend to be added to > devices when there is a clear, specific function they enable. > Perhaps more so than IETF mandates, even for IPv6. > For instance, corporate VPN access has been a driver for > IPsec inclusion in higher-end cell phone / pda devices.) > > Would you be happier with the text with s/IPv4/some IPv4/? I aticiapte that in the near future the IP excryption options will cause problems as DPI products (and the associtated service featuers like protocol based QoS are demanded) and enforcable wire tapping aer mandated then the concepts of IPSec in mobile will not be such a widley used feature. - Eric