From owner-v6ops@ops.ietf.org Thu Jun 01 03:26:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlhZj-0000zT-6R for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 03:26:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlhZh-0004iM-Rl for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 03:26:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlhXX-000Oya-1c for v6ops-data@psg.com; Thu, 01 Jun 2006 07:24: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, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [131.107.1.7] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlhXW-000OyI-8z for v6ops@ops.ietf.org; Thu, 01 Jun 2006 07:24:18 +0000 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 00:24:17 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 00:24:17 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 00:24:17 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2706); Thu, 1 Jun 2006 00:24:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 1 Jun 2006 00:23:39 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064CBEF89@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <333AA46E-7743-4915-A212-F624647A4234@icann.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-v6ops-nap-02.txt thread-index: AcaE0gPoMFyEe31EQt6ybx4X+KvrbgAeJyMA From: "Christian Huitema" To: "David Conrad" , "Fred Baker" Cc: "Thomas Narten" , "Jim Bound" , "Tony Hain" , "Brian E Carpenter" , "EricLKlein" , , "Ralph Droms" , , "Lindqvist Erik Kurt" , "Margaret Wasserman" X-OriginalArrivalTime: 01 Jun 2006 07:24:16.0955 (UTC) FILETIME=[641208B0:01C6854C] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > On May 31, 2006, at 8:48 AM, Fred Baker wrote: > > Yes, we support about 3 * 10^38 addresses in the address space. > > That is a mathematically accurate statement. >=20 > No. A mathematically correct statement would be that IPv6 can, in > theory, address up to about 3*10^38 objects. The number of objects > that can actually be supported is, of course, far, far less. The HD ratio equations predict that with 64 bit prefixes, we can number N =3D 2^(hd*64) subnets. The current RIR policy assumes hd >=3D 80%, = which leads to N > 2.59 E+15 subnets. Make that 1E+15 for simplicity.=20 In theory, 64 bits and DAD easily accommodate 2^32 hosts, but in practice the number of hosts in a subnet is dictated by economics and technology. The average subnet may well contain barely more than one node, and is unlikely to have much more than 10 today, leading to 1E+15 to 1E+16 nodes.=20 In the future, we can imagine personal networks containing hundreds of devices, so 1E+17 nodes looks plausible. I cannot really imagine a scenario in which we use 1E+38 addresses. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Jun 01 05:38:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fljd6-0003KD-5z for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 05:38:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fljd4-0003Sw-KO for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 05:38:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fljan-000Ayh-EI for v6ops-data@psg.com; Thu, 01 Jun 2006 09:35:49 +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 [193.65.76.7] (helo=ns2.teleware.fi) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fljal-000Ay2-Ib for v6ops@ops.ietf.org; Thu, 01 Jun 2006 09:35:48 +0000 Received: from localhost (localhost [127.0.0.1]) by ns2.teleware.fi (Postfix) with ESMTP id 5E0EF1C8007 for ; Thu, 1 Jun 2006 12:36:08 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at ns2.teleware.fi Received: from localhost ([127.0.0.1]) by localhost (ns2.teleware.fi [127.0.0.1]) (amavisd-new, port 10024) with SMTP id JI81CJB+uDt8 for ; Thu, 1 Jun 2006 12:36:08 +0300 (EEST) Received: from teleware.fi (unknown [10.204.2.29]) by ns2.teleware.fi (Postfix) with ESMTP id EF1A41C8002 for ; Thu, 1 Jun 2006 12:36:07 +0300 (EEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 1 Jun 2006 12:35:14 +0300 Message-ID: <3A87384B8BB0FD44930C1D3A40C4EADE0AB9F3@hkisrv09.tw.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-v6ops-nap-02.txt Thread-Index: AcaE0gPoMFyEe31EQt6ybx4X+KvrbgAeJyMAAAMCrGA= From: "Anssi Porttikivi" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 About the number of IPv6 addressable objects:=20 The global carrier prefixes are now /35. I guess we expect to always = have less of them than the current ~180 000 IPv4 global routes. Within = one carrier prefix we currently have 2^(48-35) =3D 2^13 =3D 8 K end = customer organization networks at most, because the customer prefix is = 48, currently always. And within a customer, we have 2^(64-48) =3D 2^16 = =3D 64 K subnets maximum. And like Mr. Huitema pointed, subnet sizes are = determined by the link layer technology. So an estimate for a maximum = number of global hosts with the current systems is: (100 K operator prefixes) x (8 K customer organization) x (64 K = subnets) x (10 K hosts in a maximal near-future link network) =3D 512 x K^4 ~ 10^15. Of course we can change the system radically. My favourite would be to = implement UUCP/9P like source routing by embedding local node numbers in = 128 bits: like "2!23!234!145!143!34!3!6". This fits easily to 128 bits = with some nice coding, like fixed 8 bits per hop. Old tricks like "path = alias" databases can provide optimization. We could have a = global/country-specific "well-known" nodes so you could use addresses = like usa!125!221!23!6, and your path alias system would expand that to a = full route.=20 After all, Internet was supposed to push the intelligence to the edges, = and remove "faith sharing" and need for complex and coherent standards = in networks. So why not take the routing out of the networks and put it = to the end nodes? Some may argue that carriers don't want the customer = to control the routing. But a carrier does what the customer pays for. = If a customer does not want to pay for routing, but wants to do his own = routing, there should be a business case. Note that with source routing = networks you can also offer simple, differently priced QoS links as = building blocks for customers, and let them implement the QoS they = desire. Well, then again, let's just migrate all applications to 9P. That's the = beautiful Plan 9 OS socket like abstraction (now supported by Linux = kernel also), which can use TCP/IP or other less intrusive lower layers = (IL/IP, anything), and which can use source routed connections over = dissimilar networks, and which includes a beautiful general security = model.=20 Yours, Anssi app@iki.fi Instructor Teleware Finland -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Christian Huitema Sent: 1. kes=E4kuuta 2006 10:24 To: David Conrad; Fred Baker Cc: Thomas Narten; Jim Bound; Tony Hain; Brian E Carpenter; EricLKlein; = gunter@cisco.com; Ralph Droms; v6ops@ops.ietf.org; Lindqvist Erik Kurt; = Margaret Wasserman Subject: RE: Review of draft-ietf-v6ops-nap-02.txt > On May 31, 2006, at 8:48 AM, Fred Baker wrote: > > Yes, we support about 3 * 10^38 addresses in the address space. > > That is a mathematically accurate statement. >=20 > No. A mathematically correct statement would be that IPv6 can, in > theory, address up to about 3*10^38 objects. The number of objects > that can actually be supported is, of course, far, far less. The HD ratio equations predict that with 64 bit prefixes, we can number N =3D 2^(hd*64) subnets. The current RIR policy assumes hd >=3D 80%, = which leads to N > 2.59 E+15 subnets. Make that 1E+15 for simplicity.=20 In theory, 64 bits and DAD easily accommodate 2^32 hosts, but in practice the number of hosts in a subnet is dictated by economics and technology. The average subnet may well contain barely more than one node, and is unlikely to have much more than 10 today, leading to 1E+15 to 1E+16 nodes.=20 In the future, we can imagine personal networks containing hundreds of devices, so 1E+17 nodes looks plausible. I cannot really imagine a scenario in which we use 1E+38 addresses. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Jun 01 05:38:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FljdF-0003NJ-OR for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 05:38:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FljdE-0003TG-CE for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 05:38:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FljcS-000B6a-F5 for v6ops-data@psg.com; Thu, 01 Jun 2006 09:37: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.6 required=5.0 tests=AWL,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 1FljcR-000B6O-DP for v6ops@ops.ietf.org; Thu, 01 Jun 2006 09:37:31 +0000 Received: (qmail 9670 invoked by uid 417); 1 Jun 2006 09:37:30 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 1 Jun 2006 09:37:30 -0000 Received: from ericklaptop ([132.70.222.113]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 01 Jun 2006 03:37:26 -0600 Message-ID: <003901c68567$3d03e930$6402a8c0@ftssoft.com> From: "Eric Klein" To: "Christian Huitema" , "David Conrad" , "Fred Baker" Cc: "Thomas Narten" , "Jim Bound" , "Tony Hain" , "Brian E Carpenter" , gunter@cisco.com, "Ralph Droms" , v6ops@ops.ietf.org, "Lindqvist Erik Kurt" , "Margaret Wasserman" References: <70C6EFCDFC8AAD418EF7063CD132D064CBEF89@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 1 Jun 2006 12:36:22 +0200 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: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > > On May 31, 2006, at 8:48 AM, Fred Baker wrote: > > > That is a mathematically accurate statement. > > > > No. A mathematically correct statement would be that IPv6 can, in > > From: "Christian Huitema" > In the future, we can imagine personal networks containing hundreds of > devices, so 1E+17 nodes looks plausible. > > I cannot really imagine a scenario in which we use 1E+38 addresses. I appreciate this effort for mathmaticial accuracy, but I think we have lost sight of the originl issue: How many is not an issue in this draft, but the fact that IPv6 < > infinate pool numbers and NAT is not the solution recommended for this reality. From owner-v6ops@ops.ietf.org Thu Jun 01 11:25:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp3M-0000Wo-Uj for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 11:25:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flp3L-0006gR-Mu for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 11:25:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Flp0t-000J3B-MY for v6ops-data@psg.com; Thu, 01 Jun 2006 15:23: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=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham 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 1Flp0t-000J2r-06 for v6ops@ops.ietf.org; Thu, 01 Jun 2006 15:23:07 +0000 Received: from eaglet (127.0.0.1:2275) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 1 Jun 2006 08:23:05 -0700 From: "Tony Hain" To: "'Thomas Narten'" , "'Bound, Jim'" Cc: "'Fred Baker'" , "'Brian E Carpenter'" , "'EricLKlein'" , , "'Ralph Droms'" , , "'Lindqvist Erik Kurt'" , "'Margaret Wasserman'" Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 1 Jun 2006 08:23:00 -0700 Message-ID: <165c01c6858f$44cfe290$5e7ba8c0@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: AcaEu9hXxIc/DqL3T2KQkEEtmHy3BwA0ukRg In-Reply-To: <200605311408.k4VE8DHn003842@cichlid.raleigh.ibm.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Thomas Narten wrote: > That is, given /48s to end sites, stateless address autoconfiguration > and 64-bit interface identifiers, do we undermine our own credibility > by claiming IPv6 supports 10^38 addresses? There are that many addresses no matter how they are allocated. In any case last night I added a qualifier about 10^18 subnets because there have been so many complaints about that being such a big number. Tony From owner-v6ops@ops.ietf.org Thu Jun 01 11:46:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpNb-0004dD-0Y for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 11:46:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpNZ-00004s-OW for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 11:46:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlpN7-000LK7-1J for v6ops-data@psg.com; Thu, 01 Jun 2006 15:46: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, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham 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 1FlpN6-000LJs-2u for v6ops@ops.ietf.org; Thu, 01 Jun 2006 15:46:04 +0000 Received: from eaglet (127.0.0.1:3348) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 1 Jun 2006 08:46:04 -0700 From: "Tony Hain" To: "'Eric Klein'" , "'Christian Huitema'" , "'David Conrad'" , "'Fred Baker'" Cc: "'Thomas Narten'" , "'Jim Bound'" , "'Brian E Carpenter'" , , "'Ralph Droms'" , , "'Lindqvist Erik Kurt'" , "'Margaret Wasserman'" Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 1 Jun 2006 08:45:59 -0700 Message-ID: <166501c68592$7aa2d910$5e7ba8c0@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: AcaFXwPfqxSAIhr9QAO8aiX745MqPAAMqKMQ In-Reply-To: <003901c68567$3d03e930$6402a8c0@ftssoft.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Eric Klein wrote: > I appreciate this effort for mathmaticial accuracy, but I think we have > lost > sight of the originl issue: > How many is not an issue in this draft, but the fact that IPv6 < > > infinate > pool numbers and NAT is not the solution recommended for this reality. Responding to those who believe that cascaded NAT provides an even greater amount of space than IPv6 I have added the following in the middle of the second paragraph of 2.6: ... This happens even though the private use address-space is strictly limited in size. Some deployments have already outgrown that space and have begun cascading NAT to continue expanding. Unfortunately, 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 result is something substantially less than 2^48 possible active application endpoints, rather than the perception of arbitrary utility from the large number of addressable devices. In addition it is highly likely that nodes will become confused because they are not topology aware, though as already mentioned NAT enforces a specific application deployment model. ... Tony From owner-v6ops@ops.ietf.org Thu Jun 01 12:35:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flq9H-0006sk-Bm for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 12:35:51 -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 1FlpTp-0000fN-Ou for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 11:53:01 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlpFu-0004e5-V3 for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 11:38:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlpF1-000KRI-7Q for v6ops-data@psg.com; Thu, 01 Jun 2006 15:37: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.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham 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 1FlpF0-000KR3-6u for v6ops@ops.ietf.org; Thu, 01 Jun 2006 15:37:42 +0000 Received: from eaglet (127.0.0.1:2959) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Thu, 1 Jun 2006 08:37:42 -0700 From: "Tony Hain" To: "'Walt Lazear'" , "'Fred Baker'" , "'Thomas Narten'" Cc: "'Jim Bound'" , "'Brian E Carpenter'" , "'EricLKlein'" , , "'Ralph Droms'" , , "'Lindqvist Erik Kurt'" , "'Margaret Wasserman'" Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 1 Jun 2006 08:37:37 -0700 Message-ID: <166101c68591$4fbaeb80$5e7ba8c0@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: AcaE4krbhiJ/EqaxSuWQoJbyyu/ZqAArWMZA In-Reply-To: <009501c684e2$488021f0$5100a8c0@WaltXP> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -0.6 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Walt Lazear wrote: > I agree! I'm a firm believer in the need for IPv6, but > I get a deja-vu knot in my stomach when I hear some IPv6 > evangelists (such as at an IPv6 Summit) talking about the infinite > address space and great applications it enables. There is > breast beating about Jon Postel wantonly handing out > Class A's to buds in IPv4 land and yet I see the same kind > of large chunks of IPv6 land being distributed freely. > Perhaps we're letting the RIR's head down the same road? > /64's for serial links! 15 quintillion addresses where 2-4 > will suffice?!?!?! > > What's scary are the applications that give addresses to every > retail item so it can be tracked during it's lifetime. No > reuse of addresses is contemplated (because they're infinite). > Imagine the ultimate usage, where nano-things in aerosol sprays each > have an address that is literally "cast to the wind". Is there a > /70 or /80 in every can of this stuff? Why is there no built-in > mandatory recycling of address space for these applications? There appears to be some confusion here. Even if every device that attaches to the network has a lifetime unique tag, its uniqueness is bounded by the subnet that it is attached to. The same tag might be in use in some other part of the network with a different routing prefix. > > We're undoing CIDR-like usage. That is simply not true. Allocations for subnets are done in exactly the same hierarchal manner. The only difference is that the subnet size is fixed and large so an arbitrary number of uses within that may occur. One of the major new security efforts that is simply not possible with the small subnet space in IPv4 is SEND (RFC 3971). The subnet is still contained within a CIDR block, but new capabilities are taking advantage of the larger space. > Hierarchical addressing is > going to be wasteful by nature. I don't know how the IETF > can influence the RIR allocation policy, but it's scary > how much history seems to be repeating itself. We're > at the early end of the cycle, so it may not seem to some > that we're handing out addresses with both hands, but we are. You are focused on the number of addresses, where the IPv6 allocations are done on number of subnets. Even so there are larger blocks being handed out than with IPv4, because fragmentation of the space causes more routing table bloat than the savings. In IPv4 the resource is scarce. In IPv6 it is not infinite, but with the HD ratio change being adopted by the RIRs the lifetime under the current generous allocation practice is projected at over 500 years. This protocol is not the be-all-end-all of protocols. It will be replaced by some thing better before 500 years pass. Tony From owner-v6ops@ops.ietf.org Thu Jun 01 18:16:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvTC-0002ip-PL for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 18:16:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlvTB-0003Yo-A3 for v6ops-archive@lists.ietf.org; Thu, 01 Jun 2006 18:16:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlvPB-0009Bv-JU for v6ops-data@psg.com; Thu, 01 Jun 2006 22:12: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 [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FlvPA-0009Bh-4e for v6ops@ops.ietf.org; Thu, 01 Jun 2006 22:12:36 +0000 Received: (qmail 30446 invoked by uid 1007); 1 Jun 2006 22:12:33 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=f0j5MW1Oh/jtshYeoyRh1GrXf//z0fQvpEUK04jjlwSAfcT0zP+KENhCjC5al2j3 ; Date: Fri, 2 Jun 2006 00:12:33 +0200 From: Gert Doering To: Anssi Porttikivi Cc: v6ops@ops.ietf.org Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Message-ID: <20060601221233.GY53070@Space.Net> References: <3A87384B8BB0FD44930C1D3A40C4EADE0AB9F3@hkisrv09.tw.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3A87384B8BB0FD44930C1D3A40C4EADE0AB9F3@hkisrv09.tw.fi> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi, On Thu, Jun 01, 2006 at 12:35:14PM +0300, Anssi Porttikivi wrote: > About the number of IPv6 addressable objects: > > The global carrier prefixes are now /35. I assume you mean /32 here - /35s have not been assigned since a few years. > I guess we expect to always have less of them than the current > ~180 000 IPv4 global routes. Within one carrier prefix we currently > have 2^(48-35) = 2^13 = 8 K end customer organization networks at > most, because the customer prefix is 48, currently always. Neither. First of all, it's 2^(48-32) = 64K /48s, second, policy changes are on the way in all regions to make assignment of /56s possible, and third, the /32 boundary is not fixed - larger ISPs get larger allocations. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From owner-v6ops@ops.ietf.org Fri Jun 02 05:22:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5rT-00027k-RS for v6ops-archive@lists.ietf.org; Fri, 02 Jun 2006 05:22:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm5rS-0005hQ-7e for v6ops-archive@lists.ietf.org; Fri, 02 Jun 2006 05:22:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fm5mt-0007fc-Ba for v6ops-data@psg.com; Fri, 02 Jun 2006 09:17: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.4 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE,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 1Fm5mr-0007fL-LS for v6ops@ops.ietf.org; Fri, 02 Jun 2006 09:17:45 +0000 Received: (qmail 25787 invoked by uid 417); 2 Jun 2006 09:17:42 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 2 Jun 2006 09:17:42 -0000 Received: from ericklaptop ([132.70.222.113]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Fri, 02 Jun 2006 03:17:35 -0600 Message-ID: <000101c6862d$a2b132d0$6402a8c0@ftssoft.com> From: "Eric Klein" To: v6ops@ops.ietf.org References: <3A87384B8BB0FD44930C1D3A40C4EADE0AB9F3@hkisrv09.tw.fi> <20060601221233.GY53070@Space.Net> Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Fri, 2 Jun 2006 11:17:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01C68636.2F39C930" 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: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a multi-part message in MIME format. ------=_NextPart_000_0132_01C68636.2F39C930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I realize that just how many addresses are available for allocation is = important, and has apparently struck a nerve in the WG, but can we stop = with the mathmatical discussion about how many addresses there are part = of the review of draft-ietf-v6ops-nap-02.txt. This draft is not about how many addresses there are but only referenced = the fact that there were a lot and that NAT is not part of IPv6. If there needs to be a discussion about address pools and their sizes, = can we change the subject to be "How many addresses are there" or some = such and leave this one to be a discussion of the merits and flaws of = this speciffic draft. As one of the co-authors I am loosing the flow of what needs to be = changed in the side topic (and multiple e-mails) related to questions = about numbering and renumbering. Thanks, Eric ------=_NextPart_000_0132_01C68636.2F39C930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I realize that just how many addresses = are=20 available for allocation is important, and has apparently struck a nerve = in the=20 WG, but can we stop with the mathmatical discussion about how many=20 addresses there are part of the review of=20 draft-ietf-v6ops-nap-02.txt.
 
This draft is not about how many = addresses there=20 are but only referenced the fact that there were a lot and that NAT is = not part=20 of IPv6.
 
If there needs to be a discussion about = address=20 pools and their sizes, can we change the subject to be "How many = addresses are=20 there" or some such and leave this one to be a discussion of the merits = and=20 flaws of this speciffic draft.
 
As one of the co-authors I am loosing = the flow of=20 what needs to be changed in the side topic (and multiple e-mails) = related to=20 questions about numbering and renumbering.
 
Thanks,
Eric
------=_NextPart_000_0132_01C68636.2F39C930-- From owner-v6ops@ops.ietf.org Fri Jun 02 16:11:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFhR-0005Kg-DK for v6ops-archive@lists.ietf.org; Fri, 02 Jun 2006 15:52:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFhP-0004tG-RM for v6ops-archive@lists.ietf.org; Fri, 02 Jun 2006 15:52:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmFeq-000EKM-J3 for v6ops-data@psg.com; Fri, 02 Jun 2006 19:50:08 +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 1FmFeo-000EJy-1q for v6ops@ops.ietf.org; Fri, 02 Jun 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 k52Jo2WR028346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FmFek-0008Ib-5k; Fri, 02 Jun 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-addcon-00.txt Message-Id: Date: Fri, 02 Jun 2006 15:50:02 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --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-00.txt Pages : 20 Date : 2006-6-2 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 guideliness 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-00.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-00.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-00.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-6-2142047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-addcon-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-addcon-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-2142047.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jun 02 16:51:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGbt-0005cO-Ni for v6ops-archive@lists.ietf.org; Fri, 02 Jun 2006 16:51:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGbs-0004ua-9v for v6ops-archive@lists.ietf.org; Fri, 02 Jun 2006 16:51:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FmGav-000KjC-Hr for v6ops-data@psg.com; Fri, 02 Jun 2006 20:50: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.5 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 1FmGau-000Kir-Ov for v6ops@ops.ietf.org; Fri, 02 Jun 2006 20:50:08 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2006 13:50:08 -0700 X-IronPort-AV: i="4.05,205,1146466800"; d="scan'208"; a="1818354466:sNHT60971454" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k52Ko7Q8026551 for ; Fri, 2 Jun 2006 13:50:07 -0700 Received: from gvandevewxp (ams3-vpn-dhcp163.cisco.com [10.61.64.163]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k52Ko6Lf000872 for ; Fri, 2 Jun 2006 22:50:06 +0200 (MEST) Reply-To: From: "Gunter Van de Velde \(gvandeve\)" To: Subject: FW: I-D ACTION:draft-ietf-v6ops-addcon-00.txt Date: Fri, 2 Jun 2006 22:50:06 +0200 Message-ID: <181201c68686$21507b20$e7513d0a@emea.cisco.com> 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: AcaGfgOJD7MUAdEsQJ2Ky/Wov9vPbAAB3RpA DKIM-Signature: a=rsa-sha1; q=dns; l=3230; t=1149281408; x=1150145408; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=22Gunter=20Van=20de=20Velde=20\(gvandeve\)=22=20 |Subject:FW=3A=20I-D=20ACTION=3Adraft-ietf-v6ops-addcon-00.txt=20; X=v=3Dcisco.com=3B=20h=3DeS2omhcJvSAo+u8VIvxmszMDRWc=3D; b=OIhvXipf9wOhNoSSFmmFH/mZPIGnLqh9auprJsr/v2JeVzafH3bQg0poE8lu6DhnQ55iYrP4 kiyB66e3Yu0YGP+iclO/fyzTVkGK7WXWYX0YuUkcWljVmEoYSbqjeyld; Authentication-Results: sj-dkim-4.cisco.com; header.From=gvandeve@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: 3002fc2e661cd7f114cb6bae92fe88f1 Dear all, Feedback on this draft is appreciated. Main changes with previous draft are in the embedded-RP section and the anycast section. ISP case study is still in progres with the volunteers from the meeting in dallas. Brgds, G/ -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, June 02, 2006 9:50 PM To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-addcon-00.txt 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-00.txt Pages : 20 Date : 2006-6-2 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 guideliness 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-00.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-00.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-00.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. From carlinaboyer@newsru.com Mon Jun 05 04:36:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnAZJ-0003Je-3k for v6ops-archive@lists.ietf.org; Mon, 05 Jun 2006 04:36:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn9cz-0007yQ-6n for v6ops-archive@lists.ietf.org; Mon, 05 Jun 2006 03:35:57 -0400 Received: from i125-201-158-155.s02.a033.ap.plala.or.jp ([125.201.158.155] helo=BABY) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fn9Ph-0002Rw-Qp for v6ops-archive@lists.ietf.org; Mon, 05 Jun 2006 03:22:15 -0400 Message-Id: <000101c68865$c3853800$8d90f76c@gslhthq> From: "lacie nix" To: "raimundo metcalf" Subject: Refinnace your loan, prince-angel Date: Mon, 05 Jun 2006 02:12:00 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68865.C3853800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68865.C3853800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://medlpl.org/d2/ sea dock spur stone wide-branching gas refrigeration gauge point heat-regulating diethylene dioxide addition product excess-loss steam-wrought shaft feather mackerel bird crow= n gall conch shell cross remainder stamp duty strap oyster self-compassion alpine spring beauty world-waited bi-ischiadic south-preceding muffle kiln ladder shell smoke shelf nature-print heat conductivity frost-concocted birth theory sea room false-fronted ------=_NextPart_000_0001_01C68865.C3853800 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://medlpl.org/d2/

sea dock spur stone wide-branching gas refrigeration gauge point
heat-regulating diethylene dioxide
addition product excess-loss steam-wrought shaft feather mackerel bird crow= n gall
conch shell cross remainder stamp duty strap oyster self-compassion
alpine spring beauty world-waited bi-ischiadic
south-preceding muffle kiln ladder shell
smoke shelf nature-print heat conductivity frost-concocted birth theory
sea room false-fronted
= ------=_NextPart_000_0001_01C68865.C3853800-- From owner-v6ops@ops.ietf.org Mon Jun 05 19:52:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOrm-0007g5-ID for v6ops-archive@lists.ietf.org; Mon, 05 Jun 2006 19:52:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOrk-0003CM-S6 for v6ops-archive@lists.ietf.org; Mon, 05 Jun 2006 19:52:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnOo2-0005xz-OF for v6ops-data@psg.com; Mon, 05 Jun 2006 23:48: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FnOo1-0005x0-0d for v6ops@ops.ietf.org; Mon, 05 Jun 2006 23:48:21 +0000 Received: from [IPv6:2001:620:20:1000:20d:60ff:fe49:c43a] (unknown [IPv6:2001:620:20:1000:20d:60ff:fe49:c43a]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 98A1A67642; Tue, 6 Jun 2006 01:48:11 +0200 (CEST) Subject: Re: Status of Operational issues with Tiny Fragments in IPv6 From: Jeroen Massar To: Vishwas Manral Cc: Fred Baker , v6ops@ops.ietf.org In-Reply-To: <77ead0ec0605302138r768bdaeande4b3991ed5eccbe@mail.gmail.com> References: <77ead0ec0605252207v686b8355n493f47aa4d8de38c@mail.gmail.com> <4476BA9F.1040008@dial.pipex.com> <447AFCDE.604@uninett.no> <024DBDEB-8070-4BD5-8297-F1A36BD6CB03@cisco.com> <1149005228.19401.35.camel@firenze.zurich.ibm.com> <77ead0ec0605302138r768bdaeande4b3991ed5eccbe@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-04Dq/MOPlLJe+QxDlnf6" Organization: Unfix Date: Tue, 06 Jun 2006 01:48:10 +0200 Message-Id: <1149551290.13412.55.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 --=-04Dq/MOPlLJe+QxDlnf6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-05-31 at 10:08 +0530, Vishwas Manral wrote:=20 > Hi Jeroen, >=20 > You have raised some very valid points. I will add the proposal you > define, "e." to the draft. I also agree and will replace Issues with > issue e.g. "Issues with Policy Boxes" with "Issue with policy boxes" >=20 > I am however not sure of the issue you raise with Section 6., as > bogus. The bogus part mostly because it affects already deployed IPv6 stacks and if they don't adhere to the specified behaviour would become broken if the wording like stated would be made mandatory. > I tried reading the text a couple of times, but could not > understand it. The proposal is to make the non-last fragement slightly > lesser than 1280, to address any fragmentation if tunnelling was to be > done. The -02 version reads in section 6: "To prevent such a case a minimum packet size of the non-last fragment should be less then 1280." Thus a non-last fragment should be minimally less than 1280? I guess you mean that it should be AT MOST 1280. But that would mean that anything above 1280 will never be used. This contradicts with the line before it: "The minimum fragment size of the non last fragment could be specified to be 1280 octets, the minimum link MTU [RFC2460]." Which could be a sane thing to specify and most likely what most implementations at the moment do, but it might be that some current implementations don't do this and have a small packet in the middle of the fragments and thus that would cause these implementations to break. > I do not feel it needs to be done that way by all implemntation, > but we can raise the concern that might arise if we make the fragment > size as 1280 or more. Am I missing the point altogather? No not missing the point, just miscommunication ;) Greets, Jeroen --=-04Dq/MOPlLJe+QxDlnf6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEABECADUFAkSEwrkuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I2guAJ93Og2VTXiRBNNXdYC9gPm98sNw HgCeIcft3C7Z5Qj8//w+bIKjvI/7FTI= =HctX -----END PGP SIGNATURE----- --=-04Dq/MOPlLJe+QxDlnf6-- From owner-v6ops@ops.ietf.org Tue Jun 06 13:12:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnf6x-00038l-0e for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 13:12:59 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnf6v-0001jq-Nb for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 13:12:59 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fnf46-0008GG-BS for v6ops-data@psg.com; Tue, 06 Jun 2006 17:10: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,SPF_PASS autolearn=ham version=3.1.1 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fnf43-0008FO-FR for v6ops@ops.ietf.org; Tue, 06 Jun 2006 17:09:59 +0000 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id k56HLocW009860 for ; Tue, 6 Jun 2006 12:21:50 -0500 Received: from [142.133.10.59] (142.133.10.59 [142.133.10.59]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id KYBTQ2LP; Tue, 6 Jun 2006 12:09:57 -0500 Message-ID: <4485B6AC.1040709@ericsson.com> Date: Tue, 06 Jun 2006 13:09:00 -0400 X-Sybari-Trust: 84c0a105 d453c899 d5d42b41 00000139 From: Suresh Krishnan User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Comments on draft-manral-v6ops-tiny-fragments-issues-02.txt 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi Vishwas, I read this draft and acknowledge that the problem described in the draft is very real. I had looked at this issue before and I could not arrive at a reasonable solution. I will talk about each of the 4 presented solutions a. Impose a minimum packet size for the non-last fragments. If a fragment of a lesser size is received, the packet is treated as a malformed packet and is discarded. This is the most feasible solution but it is not very effective. Let's say we arrive at a minimum non-last fragment size X (<1280 of course). It is very possible to make fragments of 1280 octets without containing the ULP header by filling it with useless hop by hop options and extension headers. b. Reassemble all the fragments of the packet, translate the header fields and, glean out relevent information and then pass the original fragments ahead after modifying the relevent fields. c. Reassemble all the fragments of the packet till we have the header fields of the upper layer , glean out relevent information and then pass the original fragments ahead after modifying the relevent fields. b and c will lead to denial of service attacks since an attacker can send enough fragments which DO NOT contain the upper layer protocol port and make the node wait for the last one, thus exhausting memory on the assembling node. d. If upper layer protocol present then the header must be there in the first fragment. The difficult question is what to do if the ULP layer is NOT present in the first fragment (Drop or Permit?) Thanks Suresh From owner-v6ops@ops.ietf.org Tue Jun 06 14:17:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fng7P-0001xy-KO for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 14:17:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fng7O-0001Zd-BM for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 14:17:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fng5V-000DlG-Oh for v6ops-data@psg.com; Tue, 06 Jun 2006 18:15: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.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fng5V-000Dl4-6D for v6ops@ops.ietf.org; Tue, 06 Jun 2006 18:15:33 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 06 Jun 2006 11:15:33 -0700 X-IronPort-AV: i="4.05,214,1146466800"; d="scan'208"; a="1820395272:sNHT40899912" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k56IFWhX031665; Tue, 6 Jun 2006 11:15:32 -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 k56IFWke018900; Tue, 6 Jun 2006 11:15:32 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k56IAsxU019676; Tue, 6 Jun 2006 11:11:48 -0700 In-Reply-To: <4485B6AC.1040709@ericsson.com> References: <4485B6AC.1040709@ericsson.com> 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, Elwyn Davies , Pekka Savola , Suresh Krishnan Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Comments on draft-manral-v6ops-tiny-fragments-issues-02.txt Date: Tue, 6 Jun 2006 11:15:30 -0700 To: vishwas@sinett.com X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-2.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=930; t=1149617732; x=1150481732; 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=20Comments=20on=20draft-manral-v6ops-tiny-fragments-issues-02.txt; X=v=3Dcisco.com=3B=20h=3DZnzTT03dQqU6ygBDzNg9ORaJtTo=3D; b=LB4j5UUhGbl9MXA/jmWDIG+1mDXBc4lpvRvuB/2Ki9oAq8YvH2wRgL56oivFmQYik7pUDNBy 8FJ6LU9QknkUzgsZ7Cyx1Ikw78edFqRwk+6W+3tvEIQBcYLragA/1Yng; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Vishwas: I have gotten some comments off-list, and some comments on. The general consensus of what I'm hearing is that the draft is incomplete, but hits on a real problem, which is that of overlapping fragments resulting in a variety of attack. Your primary concern is not that, however, it is the matter of the first fragment managing to enable a firewall to mis-apply a rule, allowing a packet to get through because the port number is in the second fragment. The security overview document draft-ietf-v6ops-security- overview-04.txt, in sections 2.1.10 and 2.1.11, addresses fragmentation-related issues. The IESG has bounced that back with a number of comments, and so there will need to be a new draft posted. I would suggest that you correspond with the authors, copied; I believe that you will find that they are willing to make sure your issues are covered in that draft. Fred From owner-v6ops@ops.ietf.org Tue Jun 06 14:18:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fng8I-000297-KT for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 14:18:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fng8H-0001bC-8K for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 14:18:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fng7q-000DvU-Ib for v6ops-data@psg.com; Tue, 06 Jun 2006 18:17: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.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [66.249.82.199] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fng7p-000DvH-Rg for v6ops@ops.ietf.org; Tue, 06 Jun 2006 18:17:57 +0000 Received: by wx-out-0102.google.com with SMTP id i26so1043455wxd for ; Tue, 06 Jun 2006 11:17:57 -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=IRBbQmbsGnOLcWxG7L+2hXVFNjcVYCxXX9M+KNLvaqIOI9OZd2sCcVN/bGRXQWWaC7pOLpASrwN9I1khKzA3s2ic4Pk7tT1WCliDYnRaPN+H9oKYDIHKoxteZULocKakse7XhuW9bc3gmXl/0KuLlaa1kPKnHOwjEUk6Qe986sY= Received: by 10.70.19.5 with SMTP id 5mr7911335wxs; Tue, 06 Jun 2006 11:17:56 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Tue, 6 Jun 2006 11:17:56 -0700 (PDT) Message-ID: <77ead0ec0606061117v2019665dwfe270804ada30395@mail.gmail.com> Date: Tue, 6 Jun 2006 23:47:56 +0530 From: "Vishwas Manral" To: "Suresh Krishnan" Subject: Re: Comments on draft-manral-v6ops-tiny-fragments-issues-02.txt Cc: v6ops@ops.ietf.org In-Reply-To: <4485B6AC.1040709@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4485B6AC.1040709@ericsson.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi Suresh, Thanks for the review of the document. I will add further comments for each of the options described. I agree with most of the points, however option b. and c.. provide the best solution for most cases as reordered fragments etc can also be treated correctly(to prevent memory exhaustion, we wait for reassembly for only a particular configurable short period of time, besides having a limit on the number of such framents we will assemble at any one time). Besides that I think for option d. we should deny the packet and will add that to the next version of the draft. Do let me know iif you disagree? Another issue I would like to add to the draft is, that raised by Jim Bound about what to do with unrecognized extension headers in middle boxes . I will also add the option of dropping overlapping fragments as mentioned by Elwyn and Stig quite a few times in the working group. Thanks, Vishwas On 6/6/06, Suresh Krishnan wrote: > Hi Vishwas, > I read this draft and acknowledge that the problem described in the > draft is very real. I had looked at this issue before and I could not > arrive at a reasonable solution. I will talk about each of the 4 > presented solutions > > a. Impose a minimum packet size for the non-last fragments. If a > fragment of a lesser size is received, the packet is treated as a > malformed packet and is discarded. > > This is the most feasible solution but it is not very effective. Let's > say we arrive at a minimum non-last fragment size X (<1280 of course). > It is very possible to make fragments of 1280 octets without containing > the ULP header by filling it with useless hop by hop options and > extension headers. > > b. Reassemble all the fragments of the packet, translate the header > fields and, glean out relevent information and then pass the original > fragments ahead after modifying the relevent fields. > > c. Reassemble all the fragments of the packet till we have the header > fields of the upper layer , glean out relevent information and then > pass the original fragments ahead after modifying the relevent > fields. > > b and c will lead to denial of service attacks since an attacker can > send enough fragments which DO NOT contain the upper layer protocol port > and make the node wait for the last one, thus exhausting memory on the > assembling node. > > d. If upper layer protocol present then the header must be there in > the first fragment. > > The difficult question is what to do if the ULP layer is NOT present in > the first fragment (Drop or Permit?) > > > Thanks > Suresh > > From owner-v6ops@ops.ietf.org Tue Jun 06 14:20:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngAJ-0003fg-KR for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 14:20:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngAI-0001hf-7u for v6ops-archive@lists.ietf.org; Tue, 06 Jun 2006 14:20:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FngA7-000EBO-1T for v6ops-data@psg.com; Tue, 06 Jun 2006 18: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 [66.249.82.199] (helo=wx-out-0102.google.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FngA6-000EB0-6i for v6ops@ops.ietf.org; Tue, 06 Jun 2006 18:20:18 +0000 Received: by wx-out-0102.google.com with SMTP id i26so1043867wxd for ; Tue, 06 Jun 2006 11:20:17 -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=Cr+hoPPH92ubiT29HKRilY31focZwEmmUqUalU3L8tELTTR38C6kdj1Ll5uceQVIknoyHfkCkjNoHvA7HgvisQYO3/O2l2Obqj7pd3x30vM5rsw1Ye0o98yyufHsnF+R8OhPkWW8HpaT23/eTiU1RrHNZJ5X27EoOcZdZYn1t28= Received: by 10.70.27.12 with SMTP id a12mr7871163wxa; Tue, 06 Jun 2006 11:20:13 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Tue, 6 Jun 2006 11:20:12 -0700 (PDT) Message-ID: <77ead0ec0606061120s69cf078eh9e835f0d0fea4ae4@mail.gmail.com> Date: Tue, 6 Jun 2006 23:50:12 +0530 From: "Vishwas Manral" To: "Suresh Krishnan" Subject: Re: Comments on draft-manral-v6ops-tiny-fragments-issues-02.txt Cc: v6ops@ops.ietf.org In-Reply-To: <77ead0ec0606061117v2019665dwfe270804ada30395@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4485B6AC.1040709@ericsson.com> <77ead0ec0606061117v2019665dwfe270804ada30395@mail.gmail.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Forgot to mention, I am evaluating the need to to add an option E to the draft the Joeroen mentioned, though I think it is the same as option C, mentioned in the draft. Thanks, Vishwas On 6/6/06, Vishwas Manral wrote: > Hi Suresh, > > Thanks for the review of the document. I will add further comments for > each of the options described. > > I agree with most of the points, however option b. and c.. provide the > best solution for most cases as reordered fragments etc can also be > treated correctly(to prevent memory exhaustion, we wait for reassembly > for only a particular configurable short period of time, besides > having a limit on the number of such framents we will assemble at any > one time). Besides that I think for option d. we should deny the > packet and will add that to the next version of the draft. Do let me > know iif you disagree? > > Another issue I would like to add to the draft is, that raised by Jim > Bound about what to do with unrecognized extension headers in middle > boxes . I will also add the option of dropping overlapping fragments > as mentioned by Elwyn and Stig quite a few times in the working group. > > Thanks, > Vishwas > > On 6/6/06, Suresh Krishnan wrote: > > Hi Vishwas, > > I read this draft and acknowledge that the problem described in the > > draft is very real. I had looked at this issue before and I could not > > arrive at a reasonable solution. I will talk about each of the 4 > > presented solutions > > > > a. Impose a minimum packet size for the non-last fragments. If a > > fragment of a lesser size is received, the packet is treated as a > > malformed packet and is discarded. > > > > This is the most feasible solution but it is not very effective. Let's > > say we arrive at a minimum non-last fragment size X (<1280 of course). > > It is very possible to make fragments of 1280 octets without containing > > the ULP header by filling it with useless hop by hop options and > > extension headers. > > > > b. Reassemble all the fragments of the packet, translate the header > > fields and, glean out relevent information and then pass the original > > fragments ahead after modifying the relevent fields. > > > > c. Reassemble all the fragments of the packet till we have the header > > fields of the upper layer , glean out relevent information and then > > pass the original fragments ahead after modifying the relevent > > fields. > > > > b and c will lead to denial of service attacks since an attacker can > > send enough fragments which DO NOT contain the upper layer protocol port > > and make the node wait for the last one, thus exhausting memory on the > > assembling node. > > > > d. If upper layer protocol present then the header must be there in > > the first fragment. > > > > The difficult question is what to do if the ULP layer is NOT present in > > the first fragment (Drop or Permit?) > > > > > > Thanks > > Suresh > > > > > From owner-v6ops@ops.ietf.org Wed Jun 07 16:48:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4xC-0006wV-Vh for v6ops-archive@lists.ietf.org; Wed, 07 Jun 2006 16:48:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4xB-00017P-Iy for v6ops-archive@lists.ietf.org; Wed, 07 Jun 2006 16:48:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fo4tx-000N0g-VT for v6ops-data@psg.com; Wed, 07 Jun 2006 20:45:17 +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 1Fo4tw-000N0N-8u for v6ops@ops.ietf.org; Wed, 07 Jun 2006 20:45:16 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 07 Jun 2006 13:45:15 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k57KjFFq004115; Wed, 7 Jun 2006 13:45:15 -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 k57Kj8ke027408; Wed, 7 Jun 2006 13:45:13 -0700 (PDT) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k57KfHAw022348; Wed, 7 Jun 2006 13:41:17 -0700 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37AC477C-E197-41FE-982D-BB546AE07E54@cisco.com> Cc: Lindqvist Erik Kurt , David Kessens Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Preliminary agenda, for comment Date: Wed, 7 Jun 2006 13:45:03 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.750) Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1708; t=1149713115; x=1150577115; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Preliminary=20agenda,=20for=20comment; X=v=3Dcisco.com=3B=20h=3DxPHFBw9LS0jzn+wqZyU/Riz8JI4=3D; b=GY3OQSSbg1Ub996TrMQ0rX5Oy3SNfaz0nxxOw0aYI5OGL0TI8Cl+2wnJIUq1xFvTUVsT0P8Y M1S5f4/eIeqJ0mgLY+9kusI2fLW6TcfTEeWCLj3ImOPpvVOcSCwlSFtY; Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 I sent a note out to folks who have drafts that have been posted since the last IETF meeting. I currently have four requests for slots in the upcoming IETF meeting: draft-ietf-v6ops-security-overview draft-vandevelde-v6ops-addcon draft-blanchet-v6ops-routing-guidelines draft-ietf-v6ops-802-16-deployment-scenarios Two others advised me that they didn't need slots. Currently, the IESG is discussing draft-ietf-v6ops-natpt-to-exprmntl draft-ietf-v6ops-nap draft-ietf-v6ops-security-overview While it is not formally in the "Revised ID Needed" state, the IESG has requested updates to the Security Overview, which is why it is on the discussion agenda. I expect they will also ask for an updated version of the Network Architecture Protection document; their comments suggested that they already had a document that said "NAT bad", and what they needed here was something to say "how to do the things people use NAT for using IPv6 without NAT" without especially commenting on NAT. The IESG has also requested updates to draft-ietf-v6ops-ent-analysis draft-ietf-v6ops-bb-deployment-scenarios I am waiting for an update to draft-ietf-v6ops-icmpv6-filtering-recs and draft-ietf-v6ops-ipsec-tunnels prior to mailing them off to the IESG. At the last IETF meeting, I was told that there would be updated versions of draft-ietf-v6ops-campus-transition draft-ietf-v6ops-port-scanning that would enable me to open a WGLC on them. I have not seen these yet. The magic date for new drafts is June 19 for -00 drafts and June 26 for updates. If there is anything else for the working group agenda, please let us know. From owner-v6ops@ops.ietf.org Thu Jun 08 02:40:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoECF-0006F5-Rg for v6ops-archive@lists.ietf.org; Thu, 08 Jun 2006 02:40:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoECD-0005TR-0h for v6ops-archive@lists.ietf.org; Thu, 08 Jun 2006 02:40:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FoE8J-000NMS-92 for v6ops-data@psg.com; Thu, 08 Jun 2006 06:36: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.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,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 1FoE8H-000NMC-3k for v6ops@ops.ietf.org; Thu, 08 Jun 2006 06:36:41 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 23:36:39 -0700 X-IronPort-AV: i="4.05,219,1146466800"; d="txt'?scan'208,217"; a="291211182:sNHT82916454" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k586acio012573; Wed, 7 Jun 2006 23:36:39 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k586acku013301; Thu, 8 Jun 2006 02:36:38 -0400 (EDT) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 02:36:38 -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_01C68AC5.E4D174C3" Subject: IPv6 Benchmarking Draft - Please provide feedback Date: Thu, 8 Jun 2006 02:36:36 -0400 Message-ID: <3D1C81E7AA3CD64FA20B04D269FEF7F4019F538D@xmb-rtp-213.amer.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPv6 Benchmarking Draft - Please provide feedback Thread-Index: AcaKxePv1/2QP8eAStG6xB5LS1gYjA== From: "Chip Popoviciu \(cpopovic\)" To: Cc: "Ahmed Hamza \(ahamza\)" , "Gunter Van de Velde \(gvandeve\)" , "Diego Dugatkin" , "Kine, Bill" , "Chip Popoviciu \(cpopovic\)" X-OriginalArrivalTime: 08 Jun 2006 06:36:38.0407 (UTC) FILETIME=[E5227970:01C68AC5] DKIM-Signature: a=rsa-sha1; q=dns; l=54778; t=1149748599; x=1150612599; c=relaxed/simple; s=sjdkim2001; 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=20Draft=20-=20Please=20provide=20feedback; X=v=3Dcisco.com=3B=20h=3DEfHssjTyJq+nJlKpDVJlOi4ysrw=3D; b=cIs7PRi6dJG8Tz9ZPDuHWbJjRVkClJy8d33SasL1aEm5bFXK1LE6aBK4pXbLbAn2xwdwkg1v KDsmepWw/nCPeSNgN2nLOEJ+T6BXmVcNZ4Ty8FRavXrrdrgV8h3zDyfv; Authentication-Results: sj-dkim-2.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: 12866e56e287fcb9ed724727fee710b4 This is a multi-part message in MIME format. ------_=_NextPart_001_01C68AC5.E4D174C3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C68AC5.E4D174C3" ------_=_NextPart_002_01C68AC5.E4D174C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear v6ops WG members, =20 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.=20 =20 This draft follows, in structure and format, the recommendation of BMWG to be an IPv6 specific complement to RFC 2544 and not its replacement. As such, this document is referring the reader to RFC 2544 wherever possible and provides IPv6 specific updates wherever necessary. Recommendations are made on evaluating performance with mixed IPv4-IPv6 traffic as well. Note that in keeping with the spirit of RFC 2544, no benchmarking recommendations are made for tunneling mechanisms, the focus remaining on native forwarding. The attached version incorporates the feedback received on version -00 from BWMG members. =20 Considering the IPv6 operational expertise of this group, your comments and suggestions would be extremely valuable in developing and improving this document. Your feedback is most appreciated. =20 Best Regards, Ciprian Popoviciu for the authors of the draft ------_=_NextPart_002_01C68AC5.E4D174C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = v6ops WG=20 members,
 
We = would like to ask=20 for your feedback on an "IPv6 Benchmarking" draft (attached) we are = working=20 on within the Benchmarking Working Group. This work was started and is = driven by=20 the great=20 demand we see for benchmarking guidelines on evaluating the IPv6 = performance of=20 network devices. This is a subject of great interest to those who = deployed=20 or consider the deployment of IPv6.
 
This = draft follows,=20 in structure and format, the recommendation of BMWG to be an IPv6 = specific=20 complement to RFC 2544 and not its replacement. As such, this = document is=20 referring the reader to RFC 2544 wherever possible and provides IPv6 = specific=20 updates wherever necessary. Recommendations are made on evaluating = performance=20 with mixed IPv4-IPv6 traffic as well. Note that in keeping with the = spirit of=20 RFC 2544, no benchmarking recommendations are made for tunneling = mechanisms, the=20 focus remaining on native forwarding. The attached version incorporates = the=20 feedback received on version -00 from BWMG members.
 
Considering the IPv6=20 operational expertise of this group, your comments and suggestions would = be=20 extremely valuable in developing and improving this document. Your = feedback is=20 most appreciated.
 
Best=20 Regards,
Ciprian=20 Popoviciu
for = the authors of=20 the draft
------_=_NextPart_002_01C68AC5.E4D174C3-- ------_=_NextPart_001_01C68AC5.E4D174C3 Content-Type: text/plain; name="draft-popoviciu-bmwg-ipv6benchmarking-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-popoviciu-bmwg-ipv6benchmarking-01.txt Content-Disposition: attachment; filename="draft-popoviciu-bmwg-ipv6benchmarking-01.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQy4gUG9wb3ZpY2l1DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQS4gSGFtemENCkV4cGlyZXM6IE9jdG9iZXIg MywgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEcuIFZhbiBkZSBWZWxkZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBDaXNjbyBTeXN0ZW1zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRC4gRHVnYXRraW4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSVhJQQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBCLiBLaW5lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFNwaXJlbnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAwNg0KDQoNCiAgICAgICAg ICAgICAgICAgICAgIElQdjYgQmVuY2htYXJraW5nIE1ldGhvZG9sb2d5DQogICAgICAgICAgICAg PGRyYWZ0LXBvcG92aWNpdS1ibXdnLWlwdjZiZW5jaG1hcmtpbmctMDEudHh0Pg0KDQpTdGF0dXMg b2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFj aCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3Ro ZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBv ciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0K ICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYg b2YgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVh cywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFm dHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwg b3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoN CiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBh dA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBU aGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz c2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIElu dGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE9jdG9iZXIgMywgMjAwNi4NCg0KQ29weXJpZ2h0 IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2KS4N Cg0KQWJzdHJhY3QNCg0KICAgVGhlIEJlbmNobWFya2luZyBNZXRob2RvbG9naWVzIGRlZmluZWQg aW4gUkZDMjU0NCBbMV0gYXJlIElQIHZlcnNpb24NCiAgIGluZGVwZW5kZW50IGhvd2V2ZXIsIHRo ZXkgZG8gbm90IGFkZHJlc3Mgc29tZSBvZiB0aGUgc3BlY2lmaWNpdGllcyBvZg0KICAgSVB2Ni4g IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYWRkaXRpb25hbCBiZW5jaG1hcmtpbmcgZ3VpZGVsaW5l cw0KDQoNCg0KUG9wb3ZpY2l1LCBldCBhbC4gICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA2 ICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgSVB2NiBQ ZXJmb3JtYW5jZSBCZW5jaG1hcmtpbmcgICAgICAgICAgIEFwcmlsIDIwMDYNCg0KDQogICB3aGlj aCBpbiBjb25qdW5jdGlvbiB3aXRoIFJGQzI1NDQgd2lsbCBsZWFkIHRvIGEgbW9yZSBjb21wbGV0 ZSBhbmQNCiAgIHJlYWxpc3RpYyBldmFsdWF0aW9uIG9mIHRoZSBJUHY2IHBlcmZvcm1hbmNlIG9m IG5ldHdvcmsgZWxlbWVudHMuDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJv ZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzDQogICAyLiAgVGVzdHMgYW5kIFJlc3VsdHMgRXZhbHVhdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDMuICBUZXN0IEVudmlyb25tZW50IFNldCBVcCAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgNC4gIFRlc3QgVHJhZmZp YyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQog ICAgIDQuMS4gIEZyYW1lIEZvcm1hdHMgYW5kIFNpemVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDQNCiAgICAgICA0LjEuMS4gIEZyYW1lIFNpemVzIHRvIGJlIHVzZWQgb24g RXRoZXJuZXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAgIDQuMS4yLiAgRnJhbWUgU2l6 ZXMgdG8gYmUgdXNlZCBvbiBTT05FVCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAgIDQu Mi4gIFByb3RvY29sIEFkZHJlc3NlcyBTZWxlY3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUNCiAgICAgICA0LjIuMS4gIERVVCBQcm90b2NvbCBBZGRyZXNzZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAgIDQuMi4yLiAgVGVzdCBUcmFmZmljIFBy b3RvY29sIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgIDQuMy4gIFRy YWZmaWMgd2l0aCBFeHRlbnNpb24gSGVhZGVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDYNCiAgICAgNC40LiAgVHJhZmZpYyBzZXQgdXAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgNS4gIE1vZGlmaWVycyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgIDUuMS4gIE1hbmFnZW1l bnQgYW5kIFJvdXRpbmcgVHJhZmZpYyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAg ICAgNS4yLiAgRmlsdGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgOA0KICAgICAgIDUuMi4xLiAgRmlsdGVyIEZvcm1hdCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgICAgNS4yLjIuICBGaWx0ZXIgVHlw ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDYuICBC ZW5jaG1hcmtpbmcgVGVzdHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMA0KICAgICA2LjEuICBUaHJvdWdocHV0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICAgIDYuMi4gIExhdGVuY3kgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgICAgNi4zLiAgRnJh bWUgTG9zcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx Mg0KICAgICA2LjQuICBCYWNrLXRvLUJhY2sgRnJhbWVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEyDQogICAgIDYuNS4gIFN5c3RlbSBSZWNvdmVyeSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgICAgNi42LiAgUmVzZXQgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAg Ny4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDEyDQogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgIDkuICBDb25jbHVzaW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KICAgMTAuIEFj a25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDEzDQogICAxMS4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAgMTEuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KICAgICAxMS4yLiBJbmZv cm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEz DQogICBBcHBlbmRpeCBBLiAgTWF4aW11bSBGcmFtZSBSYXRlcyBSZWZlcmVuY2UgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTQNCiAgICAgQS4xLiAgRXRoZXJuZXQgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgICBBLjIuICBQYWNrZXQgb3Zl ciBTT05FVCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQogICBB dXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTYNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRl bWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KDQoNCg0KDQoNCg0KDQoNCg0KUG9wb3ZpY2l1 LCBldCBhbC4gICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA2ICAgICAgICAgICAgICAgIFtQ YWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgSVB2NiBQZXJmb3JtYW5jZSBCZW5jaG1h cmtpbmcgICAgICAgICAgIEFwcmlsIDIwMDYNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRo ZSBiZW5jaG1hcmtpbmcgbWV0aG9kb2xvZ2llcyBkZWZpbmVkIGJ5IFJGQzI1NDQgWzFdIGFyZSBw cm92aW5nIHRvDQogICBiZSB2ZXJ5IHVzZWZ1bCBpbiBjb25zaXN0ZW50bHkgZXZhbHVhdGluZyBJ UHY0IGZvcndhcmRpbmcgcGVyZm9ybWFuY2UNCiAgIG9mIG5ldHdvcmsgZWxlbWVudHMuICBBZGhl cmVuY2UgdG8gdGhlc2UgdGVzdGluZyBhbmQgcmVzdWx0IGFuYWx5c2lzDQogICBwcm9jZWR1cmVz IGZhY2lsaXRhdGVzIHRoZSBvYmplY3RpdmUgY29tcGFyaXNvbiBvZiBwcm9kdWN0IElQdjQNCiAg IHBlcmZvcm1hbmNlLiAgV2hpbGUgdGhlIHByaW5jaXBsZXMgYmVoaW5kIHRoZSBtZXRob2RvbG9n aWVzDQogICBpbnRyb2R1Y2VkIGluIFJGQzI1NDQgYXJlIGxhcmdlbHkgSVAgdmVyc2lvbiBpbmRl cGVuZGVudCwgdGhlDQogICBwcm90b2NvbCBjb250aW51ZWQgdG8gZXZvbHZlLCBwYXJ0aWN1bGFy bHkgaW4gaXRzIHZlcnNpb24gNiAoSVB2NikuDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg YmVuY2htYXJraW5nIG1ldGhvZG9sb2d5IHJlY29tbWVuZGF0aW9ucyB0aGF0DQogICBhZGRyZXNz IElQdjYgc3BlY2lmaWMgYXNwZWN0cyBzdWNoIGFzIGV2YWx1YXRpbmcgdGhlIGZvcndhcmRpbmcN CiAgIHBlcmZvcm1hbmNlIG9mIHRyYWZmaWMgY29udGFpbmluZyBFeHRlbnNpb24gSGVhZGVycyBh cyBkZWZpbmVkIGluDQogICBSRkMyNDYwIFs0XS4gIFRoZXNlIHJlY29tbWVuZGF0aW9ucyBhcmUg ZGVmaW5lZCB3aXRoaW4gdGhlIFJGQzI1NDQNCiAgIGZyYW1ld29yayBhbmQgYXJlIG1lYW50IHRv IGNvbXBsZW1lbnQgdGhlIHRlc3QgYW5kIHJlc3VsdCBhbmFseXNpcw0KICAgcHJvY2VkdXJlcyBk ZXNjcmliZWQgaW4gUkZDMjU0NCBhbmQgbm90IHRvIHJlcGxhY2UgdGhlbS4NCg0KICAgVGhlIHRl cm1zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCByZW1haW4gY29uc2lzdGVudCB3aXRoIHRob3NlIGRl ZmluZWQNCiAgIGluICJCZW5jaG1hcmtpbmcgVGVybWlub2xvZ3kgZm9yIE5ldHdvcmsgSW50ZXJj b25uZWN0IERldmljZXMiIFsyXS4NCiAgIFRoaXMgdGVybWlub2xvZ3kgZG9jdW1lbnQgU0hPVUxE IGJlIGNvbnN1bHRlZCBiZWZvcmUgdXNpbmcgb3INCiAgIGFwcGx5aW5nIHRoZSByZWNvbW1lbmRh dGlvbnMgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgQW55IG1ldGhvZG9sb2d5IGFzcGVjdHMgbm90 IGNvdmVyZWQgaW4gdGhpcyBkb2N1bWVudCBTSE9VTEQgYmUNCiAgIGFzc3VtZWQgdG8gYmUgdHJl YXRlZCBiYXNlZCBvbiB0aGUgUkZDMjU0NCByZWNvbW1lbmRhdGlvbnMuDQoNCg0KMi4gIFRlc3Rz IGFuZCBSZXN1bHRzIEV2YWx1YXRpb24NCg0KICAgVGhlIHJlY29tbWVuZGVkIHBlcmZvcm1hbmNl IGV2YWx1YXRpb24gdGVzdHMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uDQogICA2IG9mIHRoaXMg ZG9jdW1lbnQuICBOb3QgYWxsIHRoZXNlIHRlc3RzIGFyZSBhcHBsaWNhYmxlIHRvIGFsbA0KICAg bmV0d29yayBlbGVtZW50IHR5cGVzLiAgTmV2ZXJ0aGVsZXNzLCBmb3IgZWFjaCBldmFsdWF0ZWQg ZGV2aWNlLCBhbGwNCiAgIGFwcGxpY2FibGUgdGVzdHMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNiBN VVNUIGJlIHBlcmZvcm1lZC4NCg0KICAgVGVzdCBleGVjdXRpb24gYW5kIHRoZSByZXN1bHRzIGFu YWx5c2lzIE1VU1QgYmUgcGVyZm9ybWVkIHdoaWxlDQogICBvYnNlcnZpbmcgZ2VuZXJhbGx5IGFj Y2VwdGVkIHRlc3RpbmcgcHJhY3RpY2VzIHJlZ2FyZGluZw0KICAgcmVwZWF0YWJpbGl0eSwgdmFy aWFuY2UgYW5kIHN0YXRpc3RpY2FsIHNpZ25pZmljYW5jZSBvZiBzbWFsbCBudW1iZXJzDQogICBv ZiB0cmlhbHMuDQoNCg0KMy4gIFRlc3QgRW52aXJvbm1lbnQgU2V0IFVwDQoNCiAgIFRoZSB0ZXN0 IGVudmlyb25tZW50IHNldHVwIG9wdGlvbnMgcmVjb21tZW5kZWQgZm9yIHRoZSBJUHY2DQogICBw ZXJmb3JtYW5jZSBldmFsdWF0aW9uIGFyZSB0aGUgc2FtZSB0byB0aGUgb25lcyBkZXNjcmliZWQg aW4gU2VjdGlvbg0KICAgNiBvZiBSRkMyNTQ0LCBpbiBib3RoIHNpbmdsZS1wb3J0IGFuZCBtdWx0 aS1wb3J0IHNjZW5hcmlvcy4gIFNpbmdsZS0NCiAgIHBvcnQgdGVzdGluZyBpcyB1c2VkIGluIG1l YXN1cmluZyBwZXIgaW50ZXJmYWNlIGZvcndhcmRpbmcNCiAgIHBlcmZvcm1hbmNlIHdoaWxlIG11 bHRpLXBvcnQgdGVzdGluZyBpcyB1c2VkIHRvIG1lYXN1cmUgdGhlDQogICBzY2FsYWJpbGl0eSBv ZiB0aGlzIHBlcmZvcm1hbmNlIGFjcm9zcyB0aGUgZW50aXJlIHBsYXRmb3JtLg0KDQoNCg0KDQpQ b3BvdmljaXUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMsIDIwMDYgICAgICAgICAg ICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBJUHY2IFBlcmZvcm1hbmNl IEJlbmNobWFya2luZyAgICAgICAgICAgQXByaWwgMjAwNg0KDQoNCiAgIFRocm91Z2hvdXQgdGhl IHRlc3QsIHRoZSBEVVQgTVVTVCBiZSBtb25pdG9yZWQgZm9yIHJlbGV2YW50IHJlc291cmNlDQog ICAoUHJvY2Vzc29yLCBNZW1vcnksIGV0Yy4pIHV0aWxpemF0aW9uLiAgVGhpcyBkYXRhIGlzIGlt cG9ydGFudCBpbg0KICAgdW5kZXJzdGFuZGluZyB0cmFmZmljIHByb2Nlc3NpbmcgYnkgZWFjaCBE VVQgYW5kIHRoZSByZXNvdXJjZXMgdGhhdA0KICAgbXVzdCBiZSBhbGxvY2F0ZWQgZm9yIElQdjYu ICBJdCByZXZlYWxzIGlmIHRoZSBJUHY2IGlzIHByb2Nlc3NlZCBpbg0KICAgaGFyZHdhcmUsIGJ5 IGFwcGxpY2FibGUgZGV2aWNlcywgdW5kZXIgYWxsIHRlc3QgY29uZGl0aW9ucyBvciBpdCBpcw0K ICAgcHVudGVkIGluIHRoZSBzb2Z0d2FyZSBzd2l0Y2hlZCBwYXRoLiAgVGhlIGRhdGEgY29sbGVj dGlvbiBNVVNUIGJlDQogICBkb25lIG91dCBvZiBiYW5kIGFuZCBpbmRlcGVuZGVudCBvZiBhbnkg bWFuYWdlbWVudCBkYXRhIHRoYXQgbWlnaHQgYmUNCiAgIHJlY29tbWVuZGVkIHRvIGJlIGNvbGxl Y3RlZCB0aHJvdWdoIHRoZSBpbnRlcmZhY2VzIGZvcndhcmRpbmcgdGhlDQogICB0ZXN0IHRyYWZm aWMuDQoNCiAgIE5vdGU6IER1cmluZyB0ZXN0aW5nLCBlaXRoZXIgc3RhdGljIG9yIGR5bmFtaWMg TmVpZ2hib3IgRGlzY292ZXJ5IGNhbg0KICAgYmUgdXNlZC4gIFRoZSBzdGF0aWMgb3B0aW9uIGNh biBiZSB1c2VkIGFzIGxvbmcgYXMgaXQgaXMgc3VwcG9ydGVkIGJ5DQogICB0aGUgdGVzdCB0b29s cy4gIFRoZSBkeW5hbWljIG9wdGlvbiBpcyBob3dldmVyIHByZWZlcnJlZCBpZiB0aGUgdGVzdA0K ICAgdG9vbCBpbnRlcmFjdHMgd2l0aCB0aGUgRFVUIGR1cmluZyB0aGUgZHVyYXRpb24gb2YgdGhl IHRlc3QgaW4gb3JkZXINCiAgIHRvIG1haW50YWluIHRoZSByZXNwZWN0aXZlIG5laWdoYm9yIGNh Y2hlcyBhY3RpdmUuICBUaGUgYWJvdmUNCiAgIGRlc2NyaWJlZCB0ZXN0IHNjZW5hcmlvcyBzdGVt IGZyb20gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgdGVzdA0KICAgdHJhZmZpYyBlbmQgcG9pbnRz LCB0aGUgSVB2NiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBhcmUgbm90DQogICBk aXJlY3RseSBhdHRhY2hlZCB0byB0aGUgRFVULCBidXQgaXMgc2VlbiBhcyBvbmUgaG9wIGJleW9u ZCwgdG8gYXZvaWQNCiAgIE5laWdoYm9yIFNvbGljaXRhdGlvbiAoTlMpIGFuZCBOZWlnaGJvciBB ZHZlcnRpc2VtZW50IChOQSkgc3Rvcm1zIGR1ZQ0KICAgdG8gdGhlIE5laWdoYm9yIFVucmVhY2hh YmlsaXR5IERldGVjdGlvbiAoTlVEKSBtZWNoYW5pc20gWzVdLg0KDQoNCjQuICBUZXN0IFRyYWZm aWMNCg0KICAgVGhlIHRyYWZmaWMgdXNlZCBmb3IgYWxsIHRlc3RzIGRlc2NyaWJlZCBpbiB0aGlz IGRvY3VtZW50IFNIT1VMRCBtZWV0DQogICB0aGUgcmVxdWlyZW1lbnRzIGRlc2NyaWJlZCBpbiB0 aGlzIHNlY3Rpb24uICBUaGVzZSByZXF1aXJlbWVudHMgYXJlDQogICBkZXNpZ25lZCB0byByZWZs ZWN0IHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgSVB2NiB1bmljYXN0IHRyYWZmaWMgaW4NCiAgIGFs bCBpdHMgYXNwZWN0cy4gIFVzaW5nIHRoaXMgSVB2NiB0cmFmZmljIGxlYWRzIHRvIGEgY29tcGxl dGUNCiAgIGV2YWx1YXRpb24gb2YgdGhlIG5ldHdvcmsgZWxlbWVudCBwZXJmb3JtYW5jZS4NCg0K NC4xLiAgRnJhbWUgRm9ybWF0cyBhbmQgU2l6ZXMNCg0KICAgVHdvIHR5cGVzIG9mIG1lZGlhIGFy ZSBjb21tb25seSBkZXBsb3llZCBhbmQgU0hPVUxEIGJlIHRlc3RlZDoNCiAgIEV0aGVybmV0IGFu ZCBTT05FVC4gIFRoaXMgc2VjdGlvbiBpZGVudGlmaWVzIHRoZSBmcmFtZSBzaXplcyB0aGF0DQog ICBTSE9VTEQgYmUgdXNlZCBmb3IgZWFjaCBtZWRpYSB0eXBlLiAgRm9yIGFsbCBvdGhlciBtZWRp YSB0eXBlcyByZWZlcg0KICAgdG8gdGhlIHJlY29tbWVuZGF0aW9ucyBvZiBSRkMyNTQ0Lg0KDQog ICBTaW1pbGFyIHRvIElQdjQsIHNtYWxsIGZyYW1lIHNpemVzIGhlbHAgY2hhcmFjdGVyaXplIHRo ZSBwZXItZnJhbWUNCiAgIHByb2Nlc3Npbmcgb3ZlcmhlYWQgb2YgdGhlIERVVC4gIE5vdGUgdGhh dCB0aGUgbWluaW11bSBzaXplIG9mIGENCiAgIHJlbGV2YW50IElQdjYgcGFja2V0IChpdCBjYXJy aWVzIG1pbmltYWwgdXBwZXIgbGF5ZXIgaW5mb3JtYXRpb24pIGlzDQogICBsYXJnZXIgdGhhbiB0 aGF0IG9mIGFuIElQdjQgcGFja2V0IGJlY2F1c2UgdGhlIGZvcm1lciBoYXMgYSA0MCBieXRlcw0K ICAgbG9uZyBoZWFkZXIgd2hpbGUgdGhlIGxhdGVyIGhhcyBhIG1pbmltdW0gaGVhZGVyIG9mIDIw IGJ5dGVzLg0KDQogICBUaGUgZnJhbWUgc2l6ZXMgbGlzdGVkIGZvciBJUHY2IGluY2x1ZGUgdGhl IGV4dGVuc2lvbiBoZWFkZXJzIHVzZWQgaW4NCiAgIHRlc3RpbmcgKHNlZSBzZWN0aW9uIDQuMyku ICBCeSBkZWZpbml0aW9uLCBleHRlbnNpb24gaGVhZGVycyBhcmUgcGFydA0KICAgb2YgdGhlIElQ djYgcGFja2V0IHBheWxvYWQuICBEZXBlbmRpbmcgb24gdGhlIHRvdGFsIGxlbmd0aCBvZiB0aGUN CiAgIGV4dGVuc2lvbiBoZWFkZXJzLCB0aGVpciB1c2UgbWlnaHQgbm90IGJlIHBvc3NpYmxlIGF0 IHRoZSBzbWFsbGVzdA0KICAgZnJhbWUgc2l6ZXMuDQoNCg0KDQpQb3BvdmljaXUsIGV0IGFsLiAg ICAgICAgRXhwaXJlcyBPY3RvYmVyIDMsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICBJUHY2IFBlcmZvcm1hbmNlIEJlbmNobWFya2luZyAgICAg ICAgICAgQXByaWwgMjAwNg0KDQoNCjQuMS4xLiAgRnJhbWUgU2l6ZXMgdG8gYmUgdXNlZCBvbiBF dGhlcm5ldA0KDQogICBFdGhlcm5ldCBpbiBhbGwgaXRzIHR5cGVzIGhhcyBiZWNvbWUgdGhlIG1v c3QgY29tbW9ubHkgZGVwbG95ZWQNCiAgIGludGVyZmFjZSBpbiB0b2RheSdzIG5ldHdvcmtzLiAg VGhlIGZvbGxvd2luZyBmcmFtZSBzaXplcyBTSE9VTEQgYmUNCiAgIHVzZWQgZm9yIHRlc3Rpbmcg dGhlIElQdjYgZm9yd2FyZGluZyBwZXJmb3JtYW5jZSBvdmVyIHRoaXMgbWVkaWENCiAgIHR5cGU6 IDY0LCAxMjgsIDI1NiwgNTEyLCAxMDI0LCAxMjgwLCAxNTE4IGJ5dGVzLiAgVGhlIG1heGltdW0g ZnJhbWUNCiAgIHJhdGVzIGZvciBlYWNoIGZyYW1lIHNpemUgYW5kIHRoZSB2YXJpb3VzIEV0aGVy bmV0IGludGVyZmFjZSB0eXBlcw0KICAgYXJlIHByb3ZpZGVkIGluIEFwcGVuZGl4IEEuDQoNCjQu MS4yLiAgRnJhbWUgU2l6ZXMgdG8gYmUgdXNlZCBvbiBTT05FVA0KDQogICBUaGUgUGFja2V0IG92 ZXIgU09ORVQgKFBvUykgaW50ZXJmYWNlcyBhcmUgY29tbW9ubHkgdXNlZCBmb3IgY29yZQ0KICAg dXBsaW5rcyBhbmQgaGlnaCBiYW5kd2lkdGggY29yZSBsaW5rcy4gIEZvciB0aGlzIHJlYXNvbiBp dCBpcw0KICAgcmVjb21tZW5kZWQgdG8gZXZhbHVhdGUgdGhlIGZvcndhcmRpbmcgcGVyZm9ybWFu Y2Ugb2Ygc3VjaCBpbnRlcmZhY2VzDQogICBpZiBwcmVzZW50IG9yIGFyZSBhbiBvcHRpb24gaW4g dGhlIERVVC4gIFRoZSByZWNvbW1lbmRlZCBsYXllciAyDQogICBwYWNrZXQgc2l6ZXMgZm9yIHRo aXMgbWVkaWEgdHlwZSBhcmU6IDY0LCAxMjgsIDI1NiwgNTEyLCAxMDI0LCAxMjgwLA0KICAgMTUx OCwgMjA0OCwgNDA5NiBieXRlcy4gIFRoZSBtYXhpbXVtIGZyYW1lIHJhdGVzIGZvciBlYWNoIGZy YW1lIHNpemUNCiAgIGFuZCB0aGUgdmFyaW91cyBFdGhlcm5ldCBpbnRlcmZhY2UgdHlwZXMgYXJl IHByb3ZpZGVkIGluIEFwcGVuZGl4IEEuDQoNCjQuMi4gIFByb3RvY29sIEFkZHJlc3NlcyBTZWxl Y3Rpb24NCg0KICAgVGhlcmUgYXJlIHR3byBhc3BlY3RzIG9mIHRoZSBJUHY2IGJlbmNobWFya2lu ZyB0ZXN0aW5nIHdoZXJlIElQDQogICBhZGRyZXNzIHNlbGVjdGlvbiBjb25zaWRlcmF0aW9ucyBN VVNUIGJlIGFuYWx5emVkOiBUaGUgc2VsZWN0aW9uIG9mDQogICBJUCBhZGRyZXNzZXMgZm9yIHRo ZSBEVVQgYW5kIHRoZSBzZWxlY3Rpb24gb2YgYWRkcmVzc2VzIGZvciB0aGUgdGVzdA0KICAgdHJh ZmZpYy4NCg0KNC4yLjEuICBEVVQgUHJvdG9jb2wgQWRkcmVzc2VzDQoNCiAgIFRoZXJlIGlzIG5v IElQdjYgYWRkcmVzcyByYW5nZSByZXNlcnZlZCBmb3IgdGhlIEJlbmNobWFya2luZw0KICAgTWV0 aG9kb2xvZ3kgV29ya2luZyBHcm91cC4gIEluIG9yZGVyIHRvIG1haW50YWluIHRoZSBjb25zaXN0 ZW5jeSB3aXRoDQogICB0aGUgSVB2NCBiZW5jaG1hcmtpbmcgcmVjb21tZW5kYXRpb25zLCBJQU5B IFNIT1VMRCByZXNlcnZlIGFuIElQdjYNCiAgIGJlbmNobWFya2luZyBwcmVmaXggc2ltaWxhciB0 byAxOTIuMTguMC4wIGluIFJGQyAzMzMwIFs3XS4gIFNpbWlsYXINCiAgIHRvIHRoZSBSRkMyNTQ0 LCBBcHBlbmRpeCBDLCBhZGRyZXNzZXMgZnJvbSB0aGUgZmlyc3QgaGFsZiBvZiB0aGlzDQogICBy YW5nZSBTSE9VTEQgYmUgdXNlZCBmb3IgdGhlIHBvcnRzIHZpZXdlZCBhcyBpbnB1dCBhbmQgYWRk cmVzc2VzIGZyb20NCiAgIHRoZSBvdGhlciBoYWxmIG9mIHRoZSByYW5nZSBmb3IgdGhlIG91dHB1 dCBwb3J0cy4NCg0KICAgVGhlIHByZWZpeCBsZW5ndGggb2YgdGhlIElQdjYgYWRkcmVzc2VzIGNv bmZpZ3VyZWQgb24gdGhlIERVVA0KICAgaW50ZXJmYWNlcyBNVVNUIGZhbGwgaW50byBlaXRoZXIg b25lIG9mIHRoZSBmb2xsb3dpbmcgdHdvIGNhdGVnb3JpZXM6DQogICBvICBQcmVmaXggbGVuZ3Ro IGlzIC8xMjYgd2hpY2ggd291bGQgc2ltdWxhdGUgYSBwb2ludC10by1wb2ludCBsaW5rDQogICAg ICBmb3IgYSBjb3JlIHJvdXRlci4NCiAgIG8gIFByZWZpeCBsZW5ndGggaXMgc21hbGxlciBvciBl cXVhbCB0byAvNjQuDQogICBObyBwcmVmaXggbGVuZ3RocyBTSE9VTEQgYmUgc2VsZWN0ZWQgaW4g dGhlIHJhbmdlIGJldHdlZW4gNjQgYW5kIDEyOA0KICAgZXhjZXB0IHRoZSAxMjYgdmFsdWUgbWVu dGlvbmVkIGFib3ZlLg0KDQogICBOb3RlIHRoYXQgLzEyNiBwcmVmaXhlcyBtaWdodCBub3QgYmUg YWx3YXlzIHRoZSBiZXN0IGNob2ljZSBmb3INCiAgIGFkZHJlc3NpbmcgcG9pbnQtdG8tcG9pbnQg bGlua3Mgc3VjaCBhcyBiYWNrLXRvLWJhY2sgRXRoZXJuZXQgdW5sZXNzDQogICB0aGUgYXV0b3By b3Zpc2lvbmluZyBtZWNoYW5pc20gaXMgZGlzYWJsZWQuICBBbHNvLCBub3QgYWxsIG5ldHdvcmsN CiAgIGVsZW1lbnRzIHN1cHBvcnQgdGhpcyB0eXBlIG9mIGFkZHJlc3Nlcy4NCg0KDQoNClBvcG92 aWNpdSwgZXQgYWwuICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMywgMjAwNiAgICAgICAgICAgICAg ICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIElQdjYgUGVyZm9ybWFuY2UgQmVu Y2htYXJraW5nICAgICAgICAgICBBcHJpbCAyMDA2DQoNCg0KICAgV2hpbGUgd2l0aCBJUHY2LCB0 aGUgRFVUIGludGVyZmFjZXMgY2FuIGJlIGNvbmZpZ3VyZWQgd2l0aCBtdWx0aXBsZQ0KICAgZ2xv YmFsIHVuaWNhc3QgcHJlZml4ZXMsIHRoZSBtZXRob2RvbG9neSBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudA0KICAgZG9lcyBub3QgcmVxdWlyZSB0ZXN0aW5nIHN1Y2ggYSBzY2VuYXJpby4gIEl0 IGlzIG5vdCBleHBlY3RlZCB0aGF0DQogICBzdWNoIGFuIGV2YWx1YXRpb24gd291bGQgYnJpbmcg YWRkaXRpb25hbCBkYXRhIHdpdGggcmVzcGVjdCB0byB0aGUNCiAgIHBlcmZvcm1hbmNlIG9mIHRo ZSBuZXR3b3JrIGVsZW1lbnQuDQoNCiAgIFRoZSBJbnRlcmZhY2UgSUQgcG9ydGlvbiBvZiB0aGUg R2xvYmFsIFVuaWNhc3QgSVB2NiBEVVQgYWRkcmVzc2VzDQogICBNVVNUIGJlIHNldCB0byA6OjEu ICBUaGVyZSBhcmUgbm8gcmVxdWlyZW1lbnRzIGluIHRoZSBzZWxlY3Rpb24gb2YNCiAgIHRoZSBJ bnRlcmZhY2UgSUQgcG9ydGlvbiBvZiB0aGUgTGluayBMb2NhbCBJUHY2IGFkZHJlc3Nlcy4NCg0K ICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBtdWx0aXBsZSBpdGVyYXRpb25zIG9mIHRoZSBiZW5j aG1hcmsgdGVzdHMgYmUNCiAgIGNvbmR1Y3RlZCB1c2luZyB0aGUgZm9sbG93aW5nIHByZWZpeCBs ZW5ndGhzOiAzMiwgNDgsIDY0LCAxMjYgYW5kDQogICAxMjguICBPdGhlciBwcmVmaXggbGVuZ3Ro cyBjYW4gYWxzbyBiZSB1c2VkIGlmIGRlc2lyZWQsIGhvd2V2ZXIgdGhlDQogICBpbmRpY2F0ZWQg cmFuZ2Ugc2hvdWxkIGJlIHN1ZmZpY2llbnQgdG8gZXN0YWJsaXNoIGJhc2VsaW5lDQogICBwZXJm b3JtYW5jZSBtZXRyaWNzLg0KDQo0LjIuMi4gIFRlc3QgVHJhZmZpYyBQcm90b2NvbCBBZGRyZXNz ZXMNCg0KICAgVGhlIElQdjYgYWRkcmVzc2VzIHVzZWQgYXMgc291cmNlcyBhbmQgZGVzdGluYXRp b25zIGZvciB0aGUgdGVzdA0KICAgc3RyZWFtcyBTSE9VTEQgYmVsb25nIHRvIHRoZSBJUHY2IHJh bmdlIHRvIGJlIGFzc2lnbmVkIGJ5IElBTkEgYXMNCiAgIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDQu Mi4xLiAgVGhlIHNvdXJjZSBhZGRyZXNzZXMgU0hPVUxEIGJlbG9uZyB0bw0KICAgb25lIGhhbGYg b2YgdGhlIHJhbmdlIGFuZCB0aGUgZGVzdGluYXRpb24gYWRkcmVzc2VzIHRvIHRoZSBvdGhlciwN CiAgIHJlZmxlY3RpbmcgdGhlIERVVCBpbnRlcmZhY2UgSVB2NiBhZGRyZXNzIHNlbGVjdGlvbi4N Cg0KICAgVGVzdHMgU0hPVUxEIGZpcnN0IGJlIGV4ZWN1dGVkIHdpdGggYSBzaW5nbGUgc3RyZWFt IGxldmVyYWdpbmcgYQ0KICAgc2luZ2xlIHNvdXJjZS1kZXN0aW5hdGlvbiBhZGRyZXNzIHBhaXIu ICBUaGUgdGVzdHMgU0hPVUxEIHRoZW4gYmUNCiAgIHJlcGVhdGVkIHdpdGggdHJhZmZpYyB1c2lu ZyBhIHJhbmRvbSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZQ0KICAgY29ycmVzcG9uZGluZyBy YW5nZS4gIElmIHRoZSBuZXR3b3JrIGVsZW1lbnQgcHJlZml4IGxvb2t1cA0KICAgY2FwYWJpbGl0 aWVzIGFyZSBldmFsdWF0ZWQsIHRoZSB0ZXN0cyBTSE9VTEQgZm9jdXMgb24gdGhlIElQdjYNCiAg IHJlbGV2YW50IHByZWZpeCBib3VuZGFyaWVzOiAwLTY0LCAxMjYgYW5kIDEyOC4NCg0KICAgU3Bl Y2lhbCBjYXJlIG5lZWRzIHRvIGJlIHRha2VuIGFib3V0IHRoZSBOZWlnaGJvciBVbnJlYWNoYWJp bGl0eQ0KICAgRGV0ZWN0aW9uIChOVUQpIFs1XSBwcm9jZXNzLiAgVGhlIElQdjYgcHJlZml4IHJl YWNoYWJsZSB0aW1lIGluIHRoZQ0KICAgUm91dGVyIEFkdmVydGlzZW1lbnQgU0hPVUxEIGJlIHNl dCB0byAzMCBzZWNvbmRzIGFuZCBhbGxvdyA1MCUNCiAgIGppdHRlci4gIFRoZSBJUHY2IHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzc2VzIFNIT1VMRCBhcHBlYXIgbm90DQogICB0byBiZSBk aXJlY3RseSBjb25uZWN0ZWQgdG8gdGhlIE5VRCB0byBhdm9pZCBOZWlnaGJvciBTb2xpY2l0YXRp b24NCiAgIChOUykgYW5kIE5laWdoYm9yIEFkdmVydGlzZW1lbnQgKE5BKSBzdG9ybXMgZHVlIHRv IG11bHRpcGxlIHRlc3QNCiAgIHRyYWZmaWMgZmxvd3MuDQoNCjQuMy4gIFRyYWZmaWMgd2l0aCBF eHRlbnNpb24gSGVhZGVycw0KDQogICBFeHRlbnNpb24gSGVhZGVycyAoRUgpIGFyZSBhbiBpbnRy aW5zaWMgcGFydCBvZiB0aGUgSVB2NiBhcmNoaXRlY3R1cmUNCiAgIFs0XSAuICBUaGV5IGFyZSB1 c2VkIHdpdGggdmFyaW91cyB0eXBlcyBvZiBwcmFjdGljYWwgdHJhZmZpYyBzdWNoIGFzOg0KICAg RnJhZ21lbnRlZCB0cmFmZmljLCBNb2JpbGl0eSBiYXNlZCB0cmFmZmljLCBBdXRoZW50aWNhdGVk IGFuZA0KICAgRW5jcnlwdGVkIHRyYWZmaWMuICBGb3IgdGhlc2UgcmVhc29ucywgYWxsIHRlc3Rz IGRlc2NyaWJlZCBpbiB0aGlzDQogICBkb2N1bWVudCBTSE9VTEQgYmUgcGVyZm9ybWVkIHdpdGgg Ym90aCB0cmFmZmljIHRoYXQgaGFzIG5vIEVIIGFuZA0KICAgdHJhZmZpYyB0aGF0IGhhcyBhIHNl dCBvZiBFSCBzZWxlY3RlZCBmcm9tIHRoZSBmb2xsb3dpbmcgbGlzdDoNCg0KDQoNCg0KUG9wb3Zp Y2l1LCBldCBhbC4gICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA2ICAgICAgICAgICAgICAg IFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgSVB2NiBQZXJmb3JtYW5jZSBCZW5j aG1hcmtpbmcgICAgICAgICAgIEFwcmlsIDIwMDYNCg0KDQogICBvICBIb3AtYnktSG9wIGhlYWRl cg0KICAgbyAgRGVzdGluYXRpb24gT3B0aW9ucyBoZWFkZXINCiAgIG8gIFJvdXRpbmcgaGVhZGVy DQogICBvICBGcmFnbWVudCBoZWFkZXINCiAgIG8gIEF1dGhlbnRpY2F0aW9uIGhlYWRlcg0KICAg byAgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBQYXlsb2FkIGhlYWRlcg0KICAgbyAgRGVzdGluYXRp b24gT3B0aW9ucyBoZWFkZXINCiAgIG8gIE1vYmlsaXR5IGhlYWRlcg0KDQogICBUaGUgSG9wLWJ5 LUhvcCBleHRlbnNpb24gaGVhZGVyIE1VU1QgYmUgcHJvY2Vzc2VkIGJ5IGVhY2ggbm9kZSBzbyBh DQogICB0ZXN0IHdpdGggdHJhZmZpYyBjb250YWluaW5nIHRoaXMgRUggdHlwZSB3aWxsIG5vdCBt ZWFzdXJlIHRoZQ0KICAgZm9yd2FyZGluZyBwZXJmb3JtYW5jZSBvZiB0aGUgRFVUIGJ1dCByYXRo ZXIgaXRzIEVIIHByb2Nlc3NpbmcNCiAgIGFiaWxpdHkgd2hpY2ggaXMgZGVwZW5kZW50IG9uIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgYnkgdGhlIEVILg0KICAgVGhlIHByb2Nlc3Npbmcgb2Yg SVB2NiBwYWNrZXRzIHdpdGggSG9wLWJ5LUhvcCBFSCBieSBuZXR3b3JrIGVsZW1lbnRzDQogICBp cyBzaW1pbGFyIHRvIHRoZSBwcm9jZXNzaW5nIG9mIElQdjQgcGFja2V0cyB3aXRoIElQIG9wdGlv bnMuICBUaGlzDQogICBpcyBkaXN0aW5jdGx5IGRpZmZlcmVudCBmcm9tIHRoZSB3YXkgdGhlIG90 aGVyIElQdjYgRUggbXVzdCBiZQ0KICAgaGFuZGxlZCB3aGVyZSB0aGUgdHJhZmZpYyBjYW4gYmUg Zm9yd2FyZGVkIGluIHRoZSBmYXN0IHBhdGggd2l0aG91dA0KICAgZnVsbCBFSCBwcm9jZXNzaW5n LiAgSW4gYWdyZWVtZW50IHdpdGggUkZDMjU0NCBvbWlzc2lvbiBvZiB0ZXN0cyB3aXRoDQogICBJ UHY0IHRyYWZmaWMgdGhhdCBpbmNsdWRlcyBJUCBvcHRpb25zLCB0aGlzIGRvY3VtZW50IG1ha2Vz IG5vDQogICBiZW5jaG1hcmtpbmcgcmVjb21tZW5kYXRpb25zIGZvciB0cmFmZmljIHdpdGggSVB2 NiB0cmFmZmljIHdpdGggdGhlDQogICBIb3AtYnktSG9wIGV4dGVuc2lvbiBoZWFkZXIuDQoNCiAg IEFsbCBJUHY2IHRlc3QgdHJhZmZpYyBjb250YWluaW5nIGV4dGVuc2lvbiBoZWFkZXJzIFNIT1VM RCBjb250YWluIGENCiAgIGNvbWJpbmF0aW9uIG9mIHR3byBvciBtb3JlIEVILiAgU2luY2UgdGhl IERVVCBpcyBub3QgYW5hbHl6aW5nIHRoZQ0KICAgY29udGVudCBvZiB0aGUgRUgsIGEgY29tYmlu YXRpb24gb2Ygc3RydWN0dXJlLWxlc3MgRUggY2FuIGJlIHVzZWQgaW4NCiAgIHRlc3Rpbmcgc3Vj aCBhczoNCiAgIG8gIERlc3RpbmF0aW9uIE9wdGlvbnMgaGVhZGVyIC0gOCBieXRlcw0KICAgbyAg Um91dGluZyBoZWFkZXIgLSAyNC0zMiBieXRlcw0KICAgbyAgRnJhZ21lbnQgaGVhZGVyIC0gOCBi eXRlcw0KICAgbyAgQXV0aGVudGljYXRpb24gaGVhZGVyIC0gMTYgYnl0ZXMNCg0KICAgVGhlIHJl Y29tbWVuZGVkIHNldCBleGNsdWRlcyB0aGUgSG9wLWJ5LUhvcCBFSCBiYXNlZCBvbiB0aGUgYWJv dmUNCiAgIGFuYWx5c2lzLiAgSXQgYWxzbyBleGNsdWRlcyB0aGUgRVNQIEVIIHNpbmNlIHRyYWZm aWMgd2l0aCBhbg0KICAgZW5jcnlwdGVkIHBheWxvYWQgY291bGQgbm90IGJlIHVzZWQgaW4gdGVz dHMgd2l0aCBtb2RpZmllcnMgc3VjaCBhcw0KICAgZmlsdGVycyBiYXNlZCBvbiB1cHBlciBsYXll ciBpbmZvcm1hdGlvbiAoc2VlIFNlY3Rpb24gNSkuICBUaGUNCiAgIHJlY29tbWVuZGVkIGhlYWRl cnMgYXJlIGNvbW1vbmx5IHVzZWQgd2l0aCBJUHY2IHRyYWZmaWMgZm9yIHZhcmlvdXMNCiAgIHNl cnZpY2VzLiAgVGhlIGxpc3RlZCBFSCBsZW5ndGhzIHJlcHJlc2VudCB0ZXN0IHRvb2wgZGVmYXVs dHMuICBUaGUNCiAgIHRvdGFsIGxlbmd0aCBvZiB0aGUgRUggY2hhaW4gU0hPVUxEIGJlIGxhcmdl ciB0aGFuIDMyIGJ5dGVzLg0KDQogICBUaGVzZSBleHRlbnNpb24gaGVhZGVycyBhZGQgZXh0cmEg Ynl0ZXMgdG8gdGhlIHBheWxvYWQgc2l6ZSBvZiB0aGUgSVANCiAgIHBhY2tldHMgd2hpY2ggTVVT VCBiZSBmYWN0b3JlZCBpbiB3aGVuIHVzZWQgaW4gdGVzdGluZyBhdCBsb3cgZnJhbWUNCiAgIHNp emVzLiAgVGhlaXIgcHJlc2VuY2Ugd2lsbCBtb2RpZnkgdGhlIG1pbmltdW0gc2l6ZSB1c2VkIGlu IHRlc3RpbmcuDQogICBGb3IgZGlyZWN0IGNvbXBhcmlzb24gYmV0d2VlbiB0aGUgZGF0YSBvYnRh aW5lZCB3aXRoIHRyYWZmaWMgdGhhdCBoYXMNCiAgIEVIIGFuZCB3aXRoIHRyYWZmaWMgdGhhdCBk b2Vzbid0IGhhdmUgdGhlbSwgYXQgbG93IGZyYW1lIHNpemUsIGENCiAgIGNvbW1vbiBib3R0b20g c2l6ZSBTSE9VTEQgYmUgc2VsZWN0ZWQgZm9yIGJvdGggdHlwZXMgb2YgdHJhZmZpYy4NCg0KICAg Rm9yIHRoZSBtb3N0IGNhc2VzLCB0aGUgbmV0d29yayBlbGVtZW50cyBpZ25vcmUgdGhlIEVIIHdo ZW4NCiAgIGZvcndhcmRpbmcgSVB2NiB0cmFmZmljLiAgRm9yIHRoZXNlIHJlYXNvbnMgaXQgaXMg bW9zdCBsaWtlbHkgdGhhdA0KDQoNCg0KUG9wb3ZpY2l1LCBldCBhbC4gICAgICAgIEV4cGlyZXMg T2N0b2JlciAzLCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgSVB2NiBQZXJmb3JtYW5jZSBCZW5jaG1hcmtpbmcgICAgICAgICAgIEFwcmlsIDIw MDYNCg0KDQogICB0aGUgRUggcmVsYXRlZCBwZXJmb3JtYW5jZSBpbXBhY3Qgd2lsbCBiZSBvYnNl cnZlZCBvbmx5IHdoZW4gdGVzdGluZw0KICAgdGhlIERVVCB3aXRoIHRyYWZmaWMgZmlsdGVycyB0 aGF0IGNvbnRhaW4gbWF0Y2hpbmcgY29uZGl0aW9ucyBmb3IgdGhlDQogICB1cHBlciBsYXllciBw cm90b2NvbCBpbmZvcm1hdGlvbi4gIEluIHRob3NlIGNhc2VzLCB0aGUgRFVUIE1VU1QNCiAgIHRy YXZlcnNlIHRoZSBjaGFpbiBvZiBFSCwgYSBwcm9jZXNzIHRoYXQgY291bGQgaW1wYWN0IHBlcmZv cm1hbmNlLg0KDQo0LjQuICBUcmFmZmljIHNldCB1cA0KDQogICBBbGwgdGVzdHMgcmVjb21tZW5k ZWQgaW4gdGhpcyBkb2N1bWVudCBTSE9VTEQgYmUgcGVyZm9ybWVkIHdpdGggYmktDQogICBkaXJl Y3Rpb25hbCB0cmFmZmljLiAgRm9yIGFzeW1tZXRyaWMgc2l0dWF0aW9ucywgdGVzdHMgTUFZIGJl DQogICBwZXJmb3JtZWQgd2l0aCB1bmlkaXJlY3Rpb25hbCB0cmFmZmljIGZvciBhIG1vcmUgZ3Jh bnVsYXINCiAgIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlIERVVCBwZXJmb3JtYW5jZS4gIEluIHRo ZXNlIGNhc2VzLCB0aGUNCiAgIGJpZGlyZWN0aW9uYWwgdHJhZmZpYyB0ZXN0aW5nIHdvdWxkIHJl dmVhbCBvbmx5IHRoZSB3b3JzdCBwZXJmb3JtYW5jZQ0KICAgYmV0d2VlbiB0aGUgdHdvIGRpcmVj dGlvbnMuDQoNCiAgIEFsbCBvdGhlciB0cmFmZmljIHByb2ZpbGUgY2hhcmFjdGVyaXN0aWNzIGRl c2NyaWJlZCBpbiBSRkMyNTQ0IFNIT1VMRA0KICAgYmUgYXBwbGllZCBpbiB0aGlzIHRlc3Rpbmcg YXMgd2VsbC4NCg0KDQo1LiAgTW9kaWZpZXJzDQoNCiAgIFJGQzI1NDQgdW5kZXJsaW5lcyB0aGUg aW1wb3J0YW5jZSBvZiBldmFsdWF0aW5nIHRoZSBwZXJmb3JtYW5jZSBvZg0KICAgbmV0d29yayBl bGVtZW50cyB1bmRlciBjZXJ0YWluIG9wZXJhdGlvbmFsIGNvbmRpdGlvbnMuICBUaGUNCiAgIGNv bmRpdGlvbnMgZGVmaW5lZCBpbiBSRkMyNTQ0IFNlY3Rpb24gMTEgYXJlIGNvbW1vbiB0byBJUHY0 IGFuZCBJUHY2DQogICB3aXRoIHRoZSBleGNlcHRpb24gb2YgQnJvYWRjYXN0IEZyYW1lcy4gIElQ djYgZG9lcyBub3QgdXNlIGxheWVyIDIgb3INCiAgIGxheWVyIDMgYnJvYWRjYXN0cy4gIFRoaXMg c2VjdGlvbiBwcm92aWRlcyBhZGRpdGlvbmFsIGNvbmRpdGlvbnMgdGhhdA0KICAgYXJlIHNwZWNp ZmljIHRvIElQdjYuICBUaGUgc3VpdGUgb2YgdGVzdHMgcmVjb21tZW5kZWQgaW4gdGhpcw0KICAg ZG9jdW1lbnQgU0hPVUxEIGJlIGZpcnN0IGV4ZWN1dGVkIGluIHRoZSBhYnNlbmNlIG9mIHRoZXNl IGNvbmRpdGlvbnMNCiAgIGFuZCB0aGVuIHJlcGVhdGVkIHVuZGVyIGVhY2ggb2YgdGhlIGNvbmRp dGlvbnMgc2VwYXJhdGVseS4NCg0KNS4xLiAgTWFuYWdlbWVudCBhbmQgUm91dGluZyBUcmFmZmlj DQoNCiAgIFRoZSBwcm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDMjU0NCBzZWN0aW9ucyAxMS4yIGFu ZCAxMS4zIGFyZQ0KICAgYXBwbGljYWJsZSBmb3IgSVB2NiBNYW5hZ2VtZW50IGFuZCBSb3V0aW5n IFVwZGF0ZSBGcmFtZXMgYXMgd2VsbC4NCg0KNS4yLiAgRmlsdGVycw0KDQogICBUaGUgZmlsdGVy cyBkZWZpbmVkIGluIFNlY3Rpb24gMTEuNCBvZiBSRkMyNTQ0IGFwcGx5IHRvIElQdjYNCiAgIGJl bmNobWFya2luZyBhcyB3ZWxsLiAgVGhlIGZpbHRlciBkZWZpbml0aW9ucyBob3dldmVyIG11c3Qg YmUNCiAgIGV4cGFuZGVkIHRvIGluY2x1ZGUgdXBwZXIgbGF5ZXIgcHJvdG9jb2wgaW5mb3JtYXRp b24gbWF0Y2hpbmcgaW4NCiAgIG9yZGVyIHRvIGFuYWx5emUgdGhlIGhhbmRsaW5nIG9mIHRyYWZm aWMgd2l0aCBFeHRlbnNpb24gSGVhZGVycyAoRUgpDQogICB3aGljaCBhcmUgYW4gaW1wb3J0YW50 IGFyY2hpdGVjdHVyYWwgY29tcG9uZW50IG9mIElQdjYuDQoNCjUuMi4xLiAgRmlsdGVyIEZvcm1h dA0KDQogICBUaGUgZmlsdGVyIGZvcm1hdCBkZWZpbmVkIGluIFJGQzI1NDQgaXMgYXBwbGljYWJs ZSB0byBJUHY2IGFzIHdlbGwNCiAgIGV4Y2VwdCB0aGF0IHRoZSBTb3VyY2UgQWRkcmVzc2VzIChT QSkgYW5kIERlc3RpbmF0aW9uIEFkZHJlc3NlcyAoREEpDQogICBhcmUgSVB2Ni4gIEluIGFkZGl0 aW9uIHRvIHRoZXNlIGJhc2ljIGZpbHRlcnMsIHRoZSBldmFsdWF0aW9uIG9mIElQdjYNCiAgIHBl cmZvcm1hbmNlIFNIT1VMRCBhbmFseXplIHRoZSBoYW5kbGluZyBvZiB0cmFmZmljIHdpdGggRXh0 ZW5zaW9uDQoNCg0KDQpQb3BvdmljaXUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMs IDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBJ UHY2IFBlcmZvcm1hbmNlIEJlbmNobWFya2luZyAgICAgICAgICAgQXByaWwgMjAwNg0KDQoNCiAg IEhlYWRlcnMuDQoNCiAgIFdoaWxlIHRoZSBpbnRlbnQgaXMgbm90IHRvIGV2YWx1YXRlIGEgcGxh dGZvcm0ncyBjYXBhYmlsaXR5IHRvDQogICBwcm9jZXNzIHRoZSB2YXJpb3VzIGV4dGVuc2lvbiBo ZWFkZXIgdHlwZXMsIHRoZSBnb2FsIGlzIHRvIG1lYXN1cmUNCiAgIHRoZSBpbXBhY3Qgb24gcGVy Zm9ybWFuY2Ugd2hlbiB0aGUgbmV0d29yayBlbGVtZW50IG11c3QgcGFyc2UgdGhyb3VnaA0KICAg dGhlIEVIIGluIG9yZGVyIHRvIHJlYWNoIHVwcGVyIGxheWVyIGluZm9ybWF0aW9uLiAgSW4gSVB2 NiByb3V0ZXJzIGRvDQogICBub3QgaGF2ZSB0byBwYXJzZSB0aHJvdWdoIHRoZSBleHRlbnNpb24g aGVhZGVycyAob3RoZXIgdGhhbiBIb3AtYnktDQogICBIb3ApIHVubGVzcyB0aGUgdXBwZXIgbGF5 ZXIgaW5mb3JtYXRpb24gaGFzIHRvIGJlIGFuYWx5emVkIGR1ZSB0bw0KICAgZmlsdGVycyBmb3Ig ZXhhbXBsZS4NCg0KICAgRm9yIHRoaXMgcmVhc29ucywgaW4gb3JkZXIgdG8gZXZhbHVhdGUgdGhl IG5ldHdvcmsgZWxlbWVudCBoYW5kbGluZw0KICAgb2YgSVB2NiB0cmFmZmljIHdpdGggRUgsIHRo ZSBkZWZpbml0aW9uIG9mIHRoZSBmaWx0ZXJzIG11c3QgYmUNCiAgIGV4dGVuZGVkIHRvIGluY2x1 ZGUgY29uZGl0aW9ucyBhcHBsaWVkIHRvIHVwcGVyIGxheWVyIHByb3RvY29sDQogICBpbmZvcm1h dGlvbi4gIFRoZSBmb2xsb3dpbmcgZmlsdGVyIGZvcm1hdCBTSE9VTEQgYmUgdXNlIGZvciB0aGlz IHR5cGUNCiAgIG9mIGV2YWx1YXRpb246DQoNCg0KICAgICAgICBbcGVybWl0fGRlbnldICBbcHJv dG9jb2xdIFtTQV0gW0RBXQ0KDQoNCiAgIHdoZXJlIHBlcm1pdCBvciBkZW55IGluZGljYXRlcyB0 aGUgYWN0aW9uIHRvIGFsbG93IG9yIGRlbnkgYSBwYWNrZXQNCiAgIHRocm91Z2ggdGhlIGludGVy ZmFjZSB0aGUgZmlsdGVyIGlzIGFwcGxpZWQgdG8uICBUaGUgUHJvdG9jb2wgZmllbGQNCiAgIGlz IGRlZmluZWQgYXM6DQogICBvICBpcHY2OiBhbnkgSVAgVmVyc2lvbiA2IHRyYWZmaWMNCiAgIG8g IHRjcDogVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJvdG9jb2wNCiAgIG8gIHVkcDogVXNlciBEYXRh Z3JhbSBQcm90b2NvbA0KICAgYW5kIFNBIHN0YW5kcyBmb3IgdGhlIFNvdXJjZSBBZGRyZXNzIGFu ZCBEQSBmb3IgdGhlIERlc3RpbmF0aW9uDQogICBBZGRyZXNzLg0KDQo1LjIuMi4gIEZpbHRlciBU eXBlcw0KDQogICBCYXNlZCBvbiB0aGUgUkZDMjU0NCByZWNvbW1lbmRhdGlvbnMsIHR3byB0eXBl cyBvZiB0ZXN0cyBhcmUgZXhlY3V0ZWQNCiAgIHdoZW4gZXZhbHVhdGluZyBwZXJmb3JtYW5jZSBp biB0aGUgcHJlc2VuY2Ugb2YgbW9kaWZpZXJzLiAgT25lIHdpdGggYQ0KICAgc2luZ2xlIGZpbHRl ciBhbmQgb25lIHdpdGggMjUgZmlsdGVycy4gIFRoZSByZWNvbW1lbmRlZCBmaWx0ZXJzIGFyZQ0K ICAgZXhlbXBsaWZpZWQgd2l0aCB0aGUgaGVscCBvZiB0aGUgSVB2NiBkb2N1bWVudGF0aW9uIHBy ZWZpeCBbOF0gMjAwMToNCiAgIERCODo6Lg0KDQogICBFeGFtcGxlcyBvZiBzaW5nbGUgZmlsdGVy cyBhcmU6DQoNCiAgICAgIEZpbHRlciBmb3IgVENQIHRyYWZmaWMgLSBwZXJtaXQgdGNwIDIwMDE6 REI4OjoxIDIwMDE6REI4OjoyDQogICAgICBGaWx0ZXIgZm9yIFVEUCB0cmFmZmljIC0gcGVybWl0 IHVkcCAyMDAxOkRCODo6MSAyMDAxOkRCODo6Mg0KICAgICAgRmlsdGVyIGZvciBJUHY2IHRyYWZm aWMgLSBwZXJtaXQgaXB2NiAyMDAxOkRCODo6MSAyMDAxOkRCODo6Mg0KDQogICBUaGUgc2luZ2xl IGxpbmUgZmlsdGVyIGNhc2UgU0hPVUxEIHZlcmlmeSB0aGF0IHRoZSBuZXR3b3JrIGVsZW1lbnQN CiAgIHBlcm1pdHMgYWxsIFRDUC9VRFAvSVB2NiB0cmFmZmljIHdpdGggb3Igd2l0aG91dCBhbnkg bnVtYmVyIG9mDQogICBFeHRlbnNpb24gSGVhZGVycyBmcm9tIElQdjYgU0EgMjAwMTpEQjg6OjEg dG8gSVB2NiBEQSAyMDAxOkRCODo6MiBhbmQNCiAgIGRlbnkgYWxsIG90aGVyIHRyYWZmaWMuDQoN Cg0KDQoNClBvcG92aWNpdSwgZXQgYWwuICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMywgMjAwNiAg ICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIElQdjYgUGVy Zm9ybWFuY2UgQmVuY2htYXJraW5nICAgICAgICAgICBBcHJpbCAyMDA2DQoNCg0KICAgRXhhbXBs ZSBvZiAyNSBmaWx0ZXJzOg0KDQogICAgICBkZW55IHRjcCAyMDAxOkRCODoxOjoxIDIwMDE6REI4 OjE6OjINCiAgICAgIGRlbnkgdGNwIDIwMDE6REI4OjI6OjEgMjAwMTpEQjg6Mjo6Mg0KICAgICAg ZGVueSB0Y3AgMjAwMTpEQjg6Mzo6MSAyMDAxOkRCODozOjoyDQogICAgICAuLi4NCiAgICAgIGRl bnkgdGNwIDIwMDE6REI4OkM6OjEgMjAwMTpEQjg6Qzo6Mg0KICAgICAgcGVybWl0IHRjcCAyMDAx OkRCODo5OTo6MSAyMDAxOkRCODo5OTo6Mg0KICAgICAgZGVueSB0Y3AgMjAwMTpEQjg6RDo6MSAy MDAxOkRCODpEOjoyDQogICAgICBkZW55IHRjcCAyMDAxOkRCODpFOjoxIDIwMDE6REI4OkU6OjIN CiAgICAgIC4uLg0KICAgICAgZGVueSB0Y3AgMjAwMTpEQjg6MTk6OjEgMjAwMTpEQjg6MTk6OjIN CiAgICAgIGRlbnkgaXB2NiBhbnkgYW55DQoNCiAgIFRoZSByb3V0ZXIgU0hPVUxEIGRlbnkgYWxs IHRyYWZmaWMgd2l0aCBvciB3aXRob3V0IGV4dGVuc2lvbiBoZWFkZXJzDQogICBleGNlcHQgVENQ IHRyYWZmaWMgd2l0aCBTQSAyMDAxOkRCODo5OTo6MSBhbmQgREEgMjAwMTpEQjg6OTk6OjIuDQoN Cg0KNi4gIEJlbmNobWFya2luZyBUZXN0cw0KDQogICBUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMg dGhlIHNhbWUgYmVuY2htYXJraW5nIHRlc3RzIGRlc2NyaWJlZCBpbg0KICAgUkZDMjU0NCB3aGls ZSBvYnNlcnZpbmcgdGhlIERVVCBzZXR1cCBhbmQgdGhlIHRyYWZmaWMgc2V0dXANCiAgIGNvbnNp ZGVyYXRpb25zIGRlc2NyaWJlZCBhYm92ZS4gIFRoZSBmb2xsb3dpbmcgc2VjdGlvbnMgc3RhdGUg dGhlDQogICB0ZXN0IHR5cGVzIGV4cGxpY2l0bHkgYW5kIGhpZ2hsaWdodCBvbmx5IHRoZSBtZXRo b2RvbG9neSBkaWZmZXJlbmNlcw0KICAgdGhhdCBtaWdodCBleGlzdCB3aXRoIHJlc3BlY3QgdG8g dGhvc2UgZGVzY3JpYmVkIGluIFNlY3Rpb24gMjYgb2YNCiAgIFJGQzI1NDQuDQoNCiAgIFRoZSBz cGVjaWZpY2l0aWVzIG9mIElQdjYsIHBhcnRpY3VsYXJseSB0aGUgZGVmaW5pdGlvbiBvZiBFSA0K ICAgcHJvY2Vzc2luZywgcmVxdWlyZSBhZGRpdGlvbmFsIGJlbmNobWFya2luZyBzdGVwcy4gIElu IHRoaXMgc2Vuc2UsDQogICB0aGUgdGVzdHMgcmVjb21tZW5kZWQgYnkgUkZDMjU0NCBNVVNUIGJl IHJlcGVhdGVkIGZvciBJUHY2IHRyYWZmaWMNCiAgIHdpdGhvdXQgYW5kIHdpdGggb25lIG9yIG11 bHRpcGxlIGV4dGVuc2lvbiBoZWFkZXIuICBUaGUgdGVzdGluZw0KICAgYXBwcm9hY2ggdGhhdCBh ZGRyZXNzZXMgdGhpcyBhc3BlY3Qgb2YgdGhlIHByb3RvY29sIGluIGEgc3lzdGVtYXRpYw0KICAg bWFubmVyIGlzIHByZXNlbnRlZCBiZWxvdy4NCg0KICAgVGhlIGJlbmNobWFya2luZyB0ZXN0cyBk ZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIFNIT1VMRCBiZSBwZXJmb3JtZWQNCiAgIHVuZGVyIGVh Y2ggb2YgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zOg0KDQogICAgICBJUHY2IHRyYWZmaWMgd2l0 aCBubyBleHRlbnNpb24gaGVhZGVycw0KICAgICAgSVB2NiB0cmFmZmljIHdpdGggb25lIGV4dGVu c2lvbiBoZWFkZXIgZnJvbSB0aGUgbGlzdCBpbiBzZWN0aW9uDQogICAgICA1LjMNCiAgICAgIElQ djYgdHJhZmZpYyB3aXRoIHRoZSBjaGFpbiBvZiBleHRlbnNpb24gaGVhZGVycyBkZXNjcmliZWQg aW4NCiAgICAgIHNlY3Rpb24gNS4zDQoNCiAgIFRoZSBtb2RpZmllcnMgZGVmaW5lZCBhcmUgaW5k ZXBlbmRlbnQgb2YgRUggdHlwZSBzbyB0aGV5IGNhbiBiZQ0KICAgYXBwbGllZCBlcXVhbGx5IHRv IGVhY2ggb25lIG9mIHRoZSBhYm92ZSB0ZXN0cy4NCg0KICAgSVB2NidzIGRlcGxveW1lbnQgaW4g ZXhpc3RlbnQgSVB2NCBlbnZpcm9ubWVudHMgYW5kIHRoZSBleHBlY3RlZCBsb25nDQogICBjby1l eGlzdGVuY2Ugb2YgdGhlIHR3byBwcm90b2NvbHMgbGVhZHMgbmV0d29yayBvcGVyYXRvcnMgdG8g cGxhY2UNCg0KDQoNClBvcG92aWNpdSwgZXQgYWwuICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMywg MjAwNiAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIElQ djYgUGVyZm9ybWFuY2UgQmVuY2htYXJraW5nICAgICAgICAgICBBcHJpbCAyMDA2DQoNCg0KICAg Z3JlYXQgZW1waGFzaXMgb24gdW5kZXJzdGFuZGluZyB0aGUgcGVyZm9ybWFuY2Ugb2YgcGxhdGZv cm1zDQogICBmb3J3YXJkaW5nIGJvdGggdHlwZXMgb2YgdHJhZmZpYy4gIFdoaWxlIHJlc291cmNl IHNoYXJpbmcgYmV0d2VlbiB0aGUNCiAgIHR3byBwcm90b2NvbHMsIGl0IGlzIGltcG9ydGFudCBm b3IgSVB2NiBlbmFibGVkIHBsYXRmb3JtcyB0byBub3QNCiAgIGV4cGVyaWVuY2UgZGVncmFkZWQg SVB2NCBwZXJmb3JtYW5jZS4gIEluIHRoaXMgY29udGV4dCB0aGUgSVB2Ng0KICAgYmVuY2htYXJr aW5nIFNIT1VMRCBiZSBwZXJmb3JtZWQgaW4gdGhlIGNvbnRleHQgb2YgYSBzdGFuZCBhbG9uZQ0K ICAgcHJvdG9jb2wgYXMgd2VsbCBhcyBpbiB0aGUgY29udGV4dCBvZiBpdHMgY28tZXhpc3RlbmNl IHdpdGggSVB2NC4NCg0KICAgVGhlIGJlbmNobWFya2luZyB0ZXN0cyBkZXNjcmliZWQgaW4gdGhp cyBzZWN0aW9uIFNIT1VMRCBiZSBwZXJmb3JtZWQNCiAgIHVuZGVyIGVhY2ggb2YgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zIGV2YWx1YXRpbmcgdGhlIElQdjYtSVB2NCBjby0NCiAgIGV4aXN0ZW5j ZToNCg0KICAgICAgSVB2NCBPTkxZIHRyYWZmaWMgYmVuY2htYXJraW5nDQogICAgICBJUHY2IE9O TFkgdHJhZmZpYyBiZW5jaG1hcmtpbmcNCiAgICAgIElQdjQtSVB2NiB0cmFmZmljIG1peCB3aXRo IHRoZSByYXRpb24gOTAlIHZzIDEwJQ0KICAgICAgSVB2NC1JUHY2IHRyYWZmaWMgbWl4IHdpdGgg dGhlIHJhdGlvbiA1MCUgdnMgNTAlDQogICAgICBJUHY0LUlQdjYgdHJhZmZpYyBtaXggd2l0aCB0 aGUgcmF0aW9uIDEwJSB2cyA5MCUNCg0KICAgQ29tYmluaW5nIHRoZSB0ZXN0IGNvbmRpdGlvbnMg bGlzdGVkIGZvciBiZW5jaG1hcmtpbmcgSVB2NiBhcyBhDQogICBzdGFuZC1hbG9uZSBwcm90b2Nv bCBhbmQgdGhlIGNvLWV4aXN0ZW5jZSB0ZXN0cyBsZWFkcyB0byBhIGxhcmdlDQogICBjb3ZlcmFn ZSBtYXRyaXguICBBIG1pbmltdW0gcmVxdWlyZW1lbnQgaXMgdG8gY292ZXIgdGhlIGNvLWV4aXN0 ZW5jZQ0KICAgY29uZGl0aW9ucyBpbiB0aGUgY2FzZSBvZiB3aGVyZSBJUHY2IHdpdGggbm8gZXh0 ZW5zaW9uIGhlYWRlcnMgaXMNCiAgIHVzZWQuDQoNCiAgIFRoZSBzdWJzZXF1ZW50IHNlY3Rpb25z IGRlc2NyaWJlIGVhY2ggc3BlY2lmaWMgdGVzdHMgdGhhdCBNVVNUIGJlDQogICBleGVjdXRlZCB1 bmRlciB0aGUgY29uZGl0aW9ucyBsaXN0ZWQgYWJvdmUgZm9yIGEgY29tcGxldGUNCiAgIGJlbmNo bWFya2luZyBvZiBJUHY2IGZvcndhcmRpbmcgcGVyZm9ybWFuY2UuDQoNCjYuMS4gIFRocm91Z2hw dXQNCg0KICAgT2JqZWN0aXZlOiBUbyBkZXRlcm1pbmUgdGhlIERVVCB0aHJvdWdocHV0IGFzIGRl ZmluZWQgaW4gUkZDMTI0Mi4NCg0KICAgUHJvY2VkdXJlOiBTYW1lIGFzIFJGQzI1NDQuDQoNCiAg IFJlcG9ydGluZyBGb3JtYXQ6IFNhbWUgYXMgUkZDMjU0NC4gIFdoaWxlIHJlcG9ydGluZyB0aGUg bmV0d29yaw0KICAgZWxlbWVudCBwZXJmb3JtYW5jZSBhdCB0aGUgbWluaW11bSBmcmFtZSBzaXpl IG1pZ2h0IGJlIG9mIGludGVyZXN0LA0KICAgaXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgcGVy Zm9ybWFuY2UgYXQgdGhlIElNSVggYXZlcmFnZSBmcmFtZSBzaXplDQogICBvciBoaWdoZXIgU0hP VUxEIGFsc28gYmUgcmVwb3J0ZWQuICBUaGlzIGRhdGEgcG9pbnQgd291bGQgaGF2ZSBhIG1vcmUN CiAgIHVzZWZ1bCB2YWx1ZSBpbiBwcmFjdGljZS4NCg0KNi4yLiAgTGF0ZW5jeQ0KDQogICBPYmpl Y3RpdmU6IFRvIGRldGVybWluZSB0aGUgbGF0ZW5jeSBhcyBkZWZpbmVkIGluIFJGQzEyNDIuDQoN CiAgIFByb2NlZHVyZTogU2FtZSBhcyBSRkMyNTQ0Lg0KDQogICBSZXBvcnRpbmcgRm9ybWF0OiBT YW1lIGFzIFJGQzI1NDQuDQoNCg0KDQoNCg0KUG9wb3ZpY2l1LCBldCBhbC4gICAgICAgIEV4cGly ZXMgT2N0b2JlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgSVB2NiBQZXJmb3JtYW5jZSBCZW5jaG1hcmtpbmcgICAgICAgICAgIEFwcmls IDIwMDYNCg0KDQo2LjMuICBGcmFtZSBMb3NzDQoNCiAgIE9iamVjdGl2ZTogVG8gZGV0ZXJtaW5l IHRoZSBmcmFtZSBsb3NzIHJhdGUsIGFzIGRlZmluZWQgaW4gUkZDMTI0MiwNCiAgIG9mIGEgRFVU IHRocm91Z2hvdXQgdGhlIGVudGlyZSByYW5nZSBvZiBpbnB1dCBkYXRhIHJhdGVzIGFuZCBmcmFt ZQ0KICAgc2l6ZXMuDQoNCiAgIFByb2NlZHVyZTogU2FtZSBhcyBSRkMyNTQ0Lg0KDQogICBSZXBv cnRpbmcgRm9ybWF0OiBTYW1lIGFzIFJGQzI1NDQuDQoNCjYuNC4gIEJhY2stdG8tQmFjayBGcmFt ZXMNCg0KICAgT2JqZWN0aXZlOiBUbyBjaGFyYWN0ZXJpemUgdGhlIGFiaWxpdHkgb2YgYSBEVVQg dG8gcHJvY2VzcyBiYWNrLXRvLQ0KICAgYmFjayBmcmFtZXMgYXMgZGVmaW5lZCBpbiBSRkMxMjQy Lg0KDQogICBQcm9jZWR1cmU6IFNhbWUgYXMgUkZDMjU0NC4NCg0KICAgUmVwb3J0aW5nIEZvcm1h dDogU2FtZSBhcyBSRkMyNTQ0Lg0KDQo2LjUuICBTeXN0ZW0gUmVjb3ZlcnkNCg0KICAgT2JqZWN0 aXZlOiBUbyBjaGFyYWN0ZXJpemUgdGhlIHNwZWVkIGF0IHdoaWNoIGEgRFVUIHJlY292ZXJzIGZy b20gYW4NCiAgIG92ZXJsb2FkIGNvbmRpdGlvbi4NCg0KICAgUHJvY2VkdXJlOiBTYW1lIGFzIFJG QzI1NDQuDQoNCiAgIFJlcG9ydGluZyBGb3JtYXQ6IFNhbWUgYXMgUkZDMjU0NC4NCg0KNi42LiAg UmVzZXQNCg0KICAgT2JqZWN0aXZlOiBUbyBjaGFyYWN0ZXJpemUgdGhlIHNwZWVkIGF0IHdoaWNo IGEgRFVUIHJlY292ZXJzIGZyb20gYQ0KICAgZGV2aWNlIG9yIHNvZnR3YXJlIHJlc2V0Lg0KDQog ICBQcm9jZWR1cmU6IFNhbWUgYXMgUkZDMjU0NC4NCg0KICAgUmVwb3J0aW5nIEZvcm1hdDogU2Ft ZSBhcyBSRkMyNTQ0Lg0KDQoNCjcuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIElBTkEgU0hP VUxEIHJlc2VydmUgYW4gSVB2NiBwcmVmaXggZm9yIGJlbmNobWFya2luZyBwdXJwb3NlcyBzaW1p bGFyDQogICB0byAxOTIuMTguMC4wIGluIFJGQyAzMzMwIFs3XS4NCg0KDQo4LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMNCg0KICAgVGhlcmUgYXJlIG5vIHNlY3VyaXR5IGlzc3VlcyB0aGF0IGFy ZSBvciBuZWVkIHRvIGJlIGFkZHJlc3NlZCBpbiB0aGlzDQogICBkb2N1bWVudC4NCg0KDQoNClBv cG92aWNpdSwgZXQgYWwuICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMywgMjAwNiAgICAgICAgICAg ICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIElQdjYgUGVyZm9ybWFuY2Ug QmVuY2htYXJraW5nICAgICAgICAgICBBcHJpbCAyMDA2DQoNCg0KOS4gIENvbmNsdXNpb25zDQoN CiAgIFRoZSBCZW5jaG1hcmtpbmcgTWV0aG9kb2xvZ3kgZm9yIE5ldHdvcmsgSW50ZXJjb25uZWN0 IERldmljZXMNCiAgIGRvY3VtZW50LCBSRkMyNTQ0IFsxXSwgaXMgZm9yIHRoZSBtb3N0IHBhcnQg YXBwbGljYWJsZSB0byBldmFsdWF0aW5nDQogICB0aGUgSVB2NiBwZXJmb3JtYW5jZSBvZiBuZXR3 b3JrIGVsZW1lbnRzLiAgVGhpcyBkb2N1bWVudCBpcw0KICAgYWRkcmVzc2luZyB0aGUgSVB2NiBz cGVjaWZpYyByZXF1aXJlbWVudHMgdGhhdCBNVVNUIGJlIG9ic2VydmVkIHdoZW4NCiAgIGFwcGx5 aW5nIHRoZSByZWNvbW1lbmRhdGlvbnMgb2YgUkZDMjU0NC4gIFRoZXNlIGFkZGl0aW9uYWwNCiAg IHJlcXVpcmVtZW50cyBzdGVtIGZyb20gdGhlIGFyY2hpdGVjdHVyZSBjaGFyYWN0ZXJpc3RpY3Mg b2YgSVB2Ni4NCiAgIFRoaXMgZG9jdW1lbnQgaXMgbm90IGEgcmVwbGFjZW1lbnQgb2YgYnV0IGEg Y29tcGxlbWVudCB0byBSRkMyNTQ0Lg0KDQoNCjEwLiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBT Y290dCBCcmFkbmVyIHByb3ZpZGVkIHZhbHVhYmxlIGd1aWRhbmNlIGFuZCByZWNvbW1lbmRhdGlv bnMgZm9yIHRoaXMNCiAgIGRvY3VtZW50LiAgVGhlIGF1dGhvcnMgYWNrbm93bGVkZ2UgdGhlIHdv cmsgZG9uZSBieSBDeW50aGlhIE1hcnRpbg0KICAgYW5kIEplZmYgRHVubiB3aXRoIHJlc3BlY3Qg dG8gZGVmaW5pbmcgdGhlIHRlcm1pbm9sb2d5IGZvciBJUHY2DQogICBiZW5jaG1hcmtpbmcuICBU aGUgYXV0aG9ycyB3b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmsgQmVub2l0IExvdXJkZWxldA0KICAg Zm9yIGhpcyBmZWVkYmFjay4NCg0KDQoxMS4gIFJlZmVyZW5jZXMNCg0KMTEuMS4gIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzDQoNCiAgIFsxXSAgQnJhZG5lciwgUy4gYW5kIEouIE1jUXVhaWQsICJCZW5j aG1hcmtpbmcgTWV0aG9kb2xvZ3kgZm9yDQogICAgICAgIE5ldHdvcmsgSW50ZXJjb25uZWN0IERl dmljZXMiLCBSRkMgMjU0NCwgTWFyY2ggMTk5OS4NCg0KMTEuMi4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMNCg0KICAgWzJdICBCcmFkbmVyLCBTLiwgIkJlbmNobWFya2luZyB0ZXJtaW5vbG9neSBm b3IgbmV0d29yaw0KICAgICAgICBpbnRlcmNvbm5lY3Rpb24gZGV2aWNlcyIsIFJGQyAxMjQyLCBK dWx5IDE5OTEuDQoNCiAgIFszXSAgU2ltcHNvbiwgVy4sICJQUFAgaW4gSERMQy1saWtlIEZyYW1p bmciLCBTVEQgNTEsIFJGQyAxNjYyLA0KICAgICAgICBKdWx5IDE5OTQuDQoNCiAgIFs0XSAgRGVl cmluZywgUy4gYW5kIFIuIEhpbmRlbiwgIkludGVybmV0IFByb3RvY29sLCBWZXJzaW9uIDYgKElQ djYpDQogICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMgMjQ2MCwgRGVjZW1iZXIgMTk5OC4NCg0K ICAgWzVdICBOYXJ0ZW4sIFQuLCBOb3JkbWFyaywgRS4sIGFuZCBXLiBTaW1wc29uLCAiTmVpZ2hi b3IgRGlzY292ZXJ5DQogICAgICAgIGZvciBJUCBWZXJzaW9uIDYgKElQdjYpIiwgUkZDIDI0NjEs IERlY2VtYmVyIDE5OTguDQoNCiAgIFs2XSAgTWFsaXMsIEEuIGFuZCBXLiBTaW1wc29uLCAiUFBQ IG92ZXIgU09ORVQvU0RIIiwgUkZDIDI2MTUsDQogICAgICAgIEp1bmUgMTk5OS4NCg0KICAgWzdd ICBJQU5BLCAiU3BlY2lhbC1Vc2UgSVB2NCBBZGRyZXNzZXMiLCBSRkMgMzMzMCwgU2VwdGVtYmVy IDIwMDIuDQoNCiAgIFs4XSAgSHVzdG9uLCBHLiwgTG9yZCwgQS4sIGFuZCBQLiBTbWl0aCwgIklQ djYgQWRkcmVzcyBQcmVmaXgNCiAgICAgICAgUmVzZXJ2ZWQgZm9yIERvY3VtZW50YXRpb24iLCBS RkMgMzg0OSwgSnVseSAyMDA0Lg0KDQoNCg0KUG9wb3ZpY2l1LCBldCBhbC4gICAgICAgIEV4cGly ZXMgT2N0b2JlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgSVB2NiBQZXJmb3JtYW5jZSBCZW5jaG1hcmtpbmcgICAgICAgICAgIEFwcmls IDIwMDYNCg0KDQpBcHBlbmRpeCBBLiAgTWF4aW11bSBGcmFtZSBSYXRlcyBSZWZlcmVuY2UNCg0K ICAgVGhpcyBhcHBlbmRpeCBwcm92aWRlcyB0aGUgZm9ybXVsYXMgdG8gY2FsY3VsYXRlIGFuZCB0 aGUgdmFsdWVzIGZvcg0KICAgdGhlIG1heGltdW0gZnJhbWUgcmF0ZXMgZm9yIHR3byBtZWRpYSB0 eXBlczogRXRoZXJuZXQgYW5kIFNPTkVULg0KDQpBLjEuICBFdGhlcm5ldA0KDQogICBUaGUgbWF4 aW11bSB0aHJvdWdocHV0IGluIGZyYW1lcyBwZXIgc2Vjb25kIChmcHMpIGZvciB2YXJpb3VzDQog ICBFdGhlcm5ldCBpbnRlcmZhY2UgdHlwZXMgYW5kIGZvciBhIGZyYW1lIHNpemUgWCBjYW4gYmUg Y2FsY3VsYXRlZA0KICAgd2l0aCB0aGUgZm9sbG93aW5nIGZvcm11bGE6DQoNCiAgICAgICAgICAg ICAgICAgICAgTGluZSBSYXRlIChicHMpDQogICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgKDhiaXRzL2J5dGUpKihYKzIwKWJ5dGVzL2ZyYW1l DQoNCiAgIFRoZSAyMCBieXRlcyBpbiB0aGUgZm9ybXVsYSBpcyB0aGUgc3VtIG9mIHRoZSBQcmVh bWJsZSAoOCBieXRlcykgYW5kDQogICB0aGUgSW50ZXIgRnJhbWUgR2FwICgxMiBieXRlcykuICBU aGUgY2FsY3VsYXRlZCBtYXhpbXVtIHRocm91Z2hwdXQNCiAgIHZhbHVlcyBmb3IgZWFjaCBFdGhl cm5ldCBpbnRlcmZhY2UgdHlwZSBhbmQgZnJhbWUgc2l6ZSBjYW4gYmUgZm91bmQNCiAgIGluIEFw cGVuZGl4IEIgb2YgUkZDMjU0NC4NCg0KQS4yLiAgUGFja2V0IG92ZXIgU09ORVQNCg0KICAgQU5T SSBUMS4xMDUgU09ORVQgcHJvdmlkZXMgdGhlIGZvcm11bGEgZm9yIGNhbGN1bGF0aW5nIHRoZSBt YXhpbXVtDQogICBhdmFpbGFibGUgYmFuZHdpZHRoIGZvciB0aGUgdmFyaW91cyBQYWNrZXQgb3Zl ciBTT05FVCAoUG9TKSBpbnRlcmZhY2UNCiAgIHR5cGVzOg0KDQogICAgICAgICAgICAgU1RTLU5j IChOID0gM1gsIHdoZXJlIFg9MSwyLDMsZXRjKQ0KDQogICAgICAgICAgICAgWyhOKjg3KSAtIE4v M10qKDkgcm93cykqKDggYml0L2J5dGUpKig4MDAwIGZyYW1lcy9zZWMpDQoNCiAgIFBhY2tldHMg b3ZlciBTT05FVCBjYW4gdXNlIHZhcmlvdXMgZW5jYXBzdWxhdGlvbnM6IFBQUCBbNl0sIEhETEMg WzNdDQogICBhbmQgRnJhbWUgUmVsYXkuICBBbGwgdGhlc2UgZW5jYXBzdWxhdGlvbnMgdXNlIGEg NCBieXRlcyBoZWFkZXIsIGEgMg0KICAgb3IgNCBieXRlcyBGQ1MgZmllbGQgYW5kIGEgMSBieXRl IEZsYWcuICBUaGUgbWF4aW11bSBmcmFtZSByYXRlIGZvcg0KICAgdmFyaW91cyBpbnRlcmZhY2Ug dHlwZXMgY2FuIGJlIGNhbGN1bGF0ZWQgd2l0aCB0aGUgZm9ybXVsYToNCg0KICAgICAgICAgICAg ICAgICAgICBMaW5lIFJhdGUgKGJwcykNCiAgICAgICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAoOGJpdHMvYnl0ZSkqKFgrMSlieXRlcy9mcmFtZQ0K DQogICBUaGUgbWF4aW11bSB0aHJvdWdocHV0IGZvciB2YXJpb3VzIFBvUyBpbnRlcmZhY2UgdHlw ZXMgYW5kIGZyYW1lDQogICBzaXplczoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUG9wb3ZpY2l1LCBl dCBhbC4gICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2Ug MTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgSVB2NiBQZXJmb3JtYW5jZSBCZW5jaG1hcmtp bmcgICAgICAgICAgIEFwcmlsIDIwMDYNCg0KDQogICAgICAgICAgICAgU2l6ZSAgIE9DLTMgICAg IE9DLTEyICAgICAgT0MtNDggICAgICBPQy0xOTIgICAgICBPQy03NjgNCiAgICAgICAgICAgICBC eXRlcyAgZnBzICAgICAgZnBzICAgICAgICBmcHMgICAgICAgIGZwcyAgICAgICAgIGZwcw0KDQog ICAgICAgICAgICAgNjQgICAgIDI4OCwwMDAgIDEsMTUyLDAwMCAgNCw2MDgsMDAwICAxOCw0MzIs MDAwICA3Myw3MjgsMDAwDQogICAgICAgICAgICAgMTI4ICAgIDE0NSwxMTYgIDU4MCw0NjUgICAg MiwzMjEsODYwICA5LDI4Nyw0NDIgICAzNywxNDksNzY3DQogICAgICAgICAgICAgMjU2ICAgIDcy LDg0MCAgIDI5MSwzNjIgICAgMSwxNjUsNDQ3ICA0LDY2MSw3OTAgICAxOCw2NDcsMTYwDQogICAg ICAgICAgICAgNTEyICAgIDM2LDQ5MSAgIDE0NSw5NjUgICAgNTgzLDg2MCAgICAyLDMzNSw0Mzkg ICA5LDM0MSw3NTQNCiAgICAgICAgICAgICAxMDI0ICAgMTgsMjYzICAgNzMsMDU0ICAgICAyOTIs MjE1ICAgIDEsMTY4LDg1OSAgIDQsNjc1LDQzNA0KICAgICAgICAgICAgIDIwNDggICA5LDEzNiAg ICAzNiw1NDUgICAgIDE0NiwxNzkgICAgNTg0LDcxNCAgICAgMiwzMzgsODU4DQogICAgICAgICAg ICAgNDA5NiAgIDQsNTY5ICAgIDE4LDI3NyAgICAgNzMsMTA3ICAgICAyOTIsNDI5ICAgICAxLDE2 OSw3MTQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQb3BvdmljaXUsIGV0IGFsLiAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDMsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICBJUHY2IFBlcmZvcm1hbmNlIEJlbmNobWFya2luZyAgICAgICAgICAg QXByaWwgMjAwNg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBDaXByaWFuIFBvcG92aWNp dQ0KICAgQ2lzY28gU3lzdGVtcw0KICAgS2l0IENyZWVrIFJvYWQNCiAgIFJUUCwgTm9ydGggQ2Fy b2xpbmEgIDI3NzA5DQogICBVU0ENCg0KICAgUGhvbmU6IDkxOSA3ODcgODE2Mg0KICAgRW1haWw6 IGNwb3BvdmljQGNpc2NvLmNvbQ0KDQoNCiAgIEFobWVkIEhhbXphDQogICBDaXNjbyBTeXN0ZW1z DQogICAzMDAwIElubm92YXRpb24gRHJpdmUNCiAgIEthbmF0YSAgSzJLIDNFOA0KICAgQ2FuYWRh DQoNCiAgIFBob25lOiA2MTMgMjU0IDM2NTYNCiAgIEVtYWlsOiBhaGFtemFAY2lzY28uY29tDQoN Cg0KICAgR3VudGVyIFZhbiBkZSBWZWxkZQ0KICAgQ2lzY28gU3lzdGVtcw0KICAgRGUgS2xlZXRs YWFuIDZhDQogICBEaWVnZW0gIDE4MzENCiAgIEJlbGdpdW0NCg0KICAgUGhvbmU6ICszMiAyNzA0 IDU0NzMNCiAgIEVtYWlsOiBndW50ZXJAY2lzY28uY29tDQoNCg0KICAgRGllZ28gRHVnYXRraW4N CiAgIElYSUENCiAgIDI2NjAxIFdlc3QgQWdvdXJhIFJkDQogICBDYWxhYmFzYXMgIDkxMzAyDQog ICBVU0ENCg0KICAgUGhvbmU6IDgxOCA0NDQgMzEyNA0KICAgRW1haWw6IGRpZWdvQGl4aWFjb20u Y29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUG9wb3ZpY2l1LCBldCBhbC4gICAgICAgIEV4cGly ZXMgT2N0b2JlciAzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgSVB2NiBQZXJmb3JtYW5jZSBCZW5jaG1hcmtpbmcgICAgICAgICAgIEFwcmls IDIwMDYNCg0KDQogICBCaWxsIEtpbmUNCiAgIFNwaXJlbnQNCiAgIDE1MTUgU2VhbCBXYXkNCiAg IFNlYWwgQmVhY2ggIDkwNzQwDQogICBVU0ENCg0KICAgUGhvbmU6IDU2MiA1OTggMDYzMQ0KICAg RW1haWw6IEJpbGwuS2luZUBTcGlyZW50Q29tLkNPTQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQpQb3BvdmljaXUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDMsIDIwMDYgICAg ICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBJUHY2IFBlcmZv cm1hbmNlIEJlbmNobWFya2luZyAgICAgICAgICAgQXByaWwgMjAwNg0KDQoNCkludGVsbGVjdHVh bCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVn YXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9w ZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAg cGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRl c2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBs aWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxh YmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVw ZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0K ICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1l bnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBv ZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQog ICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVz dWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9y IHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5 IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBv YnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVk IHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRl bnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdo dHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBs ZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24g dG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkRpc2NsYWltZXIgb2Yg VmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09O VFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQ T05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5F VA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQ UkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FS UkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9U IElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVS Q0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkNv cHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0 eSAoMjAwNikuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdodHMsIGxp Y2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kDQogICBleGNl cHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmln aHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9y IGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2ll dHkuDQoNCg0KDQoNClBvcG92aWNpdSwgZXQgYWwuICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMywg MjAwNiAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KDQo= ------_=_NextPart_001_01C68AC5.E4D174C3-- From owner-v6ops@ops.ietf.org Thu Jun 08 15:54:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoQa9-0002Ii-CZ for v6ops-archive@lists.ietf.org; Thu, 08 Jun 2006 15:54:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoQa8-0003Bi-2D for v6ops-archive@lists.ietf.org; Thu, 08 Jun 2006 15:54:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FoQW3-000PPP-T4 for v6ops-data@psg.com; Thu, 08 Jun 2006 19:50:03 +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 1FoQW3-000POn-14 for v6ops@ops.ietf.org; Thu, 08 Jun 2006 19:50:03 +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 k58Jo1WR007595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FoQW1-0003gN-Be; Thu, 08 Jun 2006 15: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-bb-deployment-scenarios-05.txt Message-Id: Date: Thu, 08 Jun 2006 15:50:01 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --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 : ISP IPv6 Deployment Scenarios in Broadband Access Networks Author(s) : S. Asadullah, et al. Filename : draft-ietf-v6ops-bb-deployment-scenarios-05.txt Pages : 79 Date : 2006-6-8 This document provides detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP) Broadband (BB) networks in coexistence with deployed IPv4 services. Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks and their differences from IPv4 BB networks and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-05.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-bb-deployment-scenarios-05.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-bb-deployment-scenarios-05.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-6-8111343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-bb-deployment-scenarios-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-8111343.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Sun Jun 11 21:52:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpbbk-0004UG-Ks for v6ops-archive@lists.ietf.org; Sun, 11 Jun 2006 21:52:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpbbj-0007M1-Am for v6ops-archive@lists.ietf.org; Sun, 11 Jun 2006 21:52:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpbXU-000IC5-Jh for v6ops-data@psg.com; Mon, 12 Jun 2006 01:48:24 +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, 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 1FpbXT-000IBt-Rx for v6ops@ops.ietf.org; Mon, 12 Jun 2006 01:48:23 +0000 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 11 Jun 2006 18:48:23 -0700 X-IronPort-AV: i="4.05,228,1146466800"; d="scan'208"; a="292930172:sNHT33081792" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5C1mNUk016156; Sun, 11 Jun 2006 18:48:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5C1mMcL005532; Sun, 11 Jun 2006 18:48:22 -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); Sun, 11 Jun 2006 18:48:22 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 11 Jun 2006 18:48:21 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: Fred Baker , Lindqvist Erik Kurt , "Dan ((Dan)) Romascanu" , David Kessens , session-request@ietf.org, v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: V6OPS - Requested session has been scheduled for IETF 66 Date: Sun, 11 Jun 2006 18:48:19 -0700 To: IETF Secretariat X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 12 Jun 2006 01:48:21.0625 (UTC) FILETIME=[4919FE90:01C68DC2] DKIM-Signature: a=rsa-sha1; q=dns; l=856; t=1150076903; x=1150940903; c=relaxed/simple; s=sjdkim7001; 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=20V6OPS=20-=20Requested=20session=20has=20been=20scheduled=20for=2 0IETF=2066=20; X=v=3Dcisco.com=3B=20h=3DzzuutODEfuv9QKvfjm0KymBVcbw=3D; b=YUekqUPN34rQ42gehc4Xfi/g4apT7OEN/QlkGT/FWZEBCrOAnrHXidu8W1nNf+tj69kwe2WR PGxEdYUXeYZzJi4P9PmE71WFIUoyfzs0tTzvABlbyyoY+9bV/DTWay8W; Authentication-Results: sj-dkim-7.cisco.com; header.From=fred@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: 69a74e02bbee44ab4f8eafdbcedd94a1 Thanks much. On Jun 11, 2006, at 11:50 AM, IETF Secretariat wrote: > Dear Fred Baker, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > V6OPS Session 1 (2 hours) > Wednesday, Morning Session I 0900-1130 > Room Name: Room 515 > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: v6ops > Area Name: Operations and Management Area > Session Requester: Fred Baker > > Number of Sessions: 1 > Length of Session(s): 2 hours > > > Number of Attendees: 100 > Conflicts to Avoid: > First Priority: tsvwg tcpm shim6 ospf ieprep > Second Priority: opsarea > > Special Requests: > > --------------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Jun 12 08:42:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fplkb-0002QY-NP for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 08:42:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FplkX-00040D-8p for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 08:42:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fplhw-000LJ6-Lo for v6ops-data@psg.com; Mon, 12 Jun 2006 12:39: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=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 1Fplhv-000LIe-CC for v6ops@ops.ietf.org; Mon, 12 Jun 2006 12:39:51 +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 k5CCdkVG024834 for ; Mon, 12 Jun 2006 13:39:46 +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 k5CCde6t012558 for ; Mon, 12 Jun 2006 13:39:40 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k5CCdaxU022075 for v6ops@ops.ietf.org; Mon, 12 Jun 2006 13:39:36 +0100 Date: Mon, 12 Jun 2006 13:39:36 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: FW: Review of draft-ietf-v6ops-nap-02.txt Message-ID: <20060612123936.GA19058@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <7D1EF5F6-0D92-46FE-8917-758D75782D6F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D1EF5F6-0D92-46FE-8917-758D75782D6F@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: e1e48a527f609d1be2bc8d8a70eb76cb On Fri, May 26, 2006 at 09:05:56AM -0700, Fred Baker wrote: > FYI. Margaret's original message seems to have not made it to v6ops, > or at least through it to me and reportedly several of you. > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] On Behalf Of > Margaret Wasserman > Sent: Wednesday, May 24, 2006 7:06 PM > To: 'iesg@ietf.org'; 'v6ops@ops.ietf.org' > Subject: Review of draft-ietf-v6ops-nap-02.txt > > Hi All, > > I reviewed draft-ietf-v6ops-nap-02.txt, and I found a number of serious > issues with the document. I realize that the Last Calls have already > completed and that this document is on the agenda for this week's IESG > telechat, but I consider these issues to be serious enough that they are > worth raising as late objections. Hi, I think Margaret's objections boil down into four areas: 1) Some 'overenthusiastic' language. Maybe some words can be toned down, I don't see a huge issue there, but it's a fair point if you want to get NAT advocates to read it all. 2) Renumbering. This should get an extra section I agree. Note there are now movements towards IPv6 PI swamp space. There are different classes of network for which renumbering varies in complexity. 3) Untraceable addresses and host routes - I agreed at the time that these seemed impractical to use. My own feeling is to progress the document, toning down some words, adding some clarification on renumbering, and pushing (3) to a theoretical appendix. There's been general consensus on the messages of the draft, and I have seen good feedback on it. A major overhaul isn't needed. tim From owner-v6ops@ops.ietf.org Mon Jun 12 13:18:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq3V-0003JP-64 for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 13:18:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpq3T-0005dg-Sh for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 13:18:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fpq1K-000LQN-6i for v6ops-data@psg.com; Mon, 12 Jun 2006 17: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=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 1Fpq1J-000LQB-C8 for v6ops@ops.ietf.org; Mon, 12 Jun 2006 17:16:09 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 10:16:05 -0700 X-IronPort-AV: i="4.05,229,1146466800"; d="scan'208"; a="1824083634:sNHT2782347016" 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/8.12.11) with ESMTP id k5CHG5C0029549; Mon, 12 Jun 2006 10:16:05 -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 k5CHG4CU002370; Mon, 12 Jun 2006 10:16:04 -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); Mon, 12 Jun 2006 10:16:04 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 10:16:03 -0700 In-Reply-To: <20060612123936.GA19058@login.ecs.soton.ac.uk> References: <7D1EF5F6-0D92-46FE-8917-758D75782D6F@cisco.com> <20060612123936.GA19058@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: Fred Baker Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Mon, 12 Jun 2006 10:15:54 -0700 To: Tim Chown X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 12 Jun 2006 17:16:04.0043 (UTC) FILETIME=[E27CF1B0:01C68E43] DKIM-Signature: a=rsa-sha1; q=dns; l=449; t=1150132565; x=1150996565; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Review=20of=20draft-ietf-v6ops-nap-02.txt; X=v=3Dcisco.com=3B=20h=3DLZ/B036V6ovdCoVY3YNrfpOy7CU=3D; b=BnCPSJ3Ed2xGd/YWW9Oiuin2SZASja+pmRCcn7On6MqpMHe/BE/5YMntBMAJ4e+V90TG682a YAo9GlxNIVk40SmplIhXGK5C29W26Iz1ulNQ67IvvEh4+vDqIQAhoqkH; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad On Jun 12, 2006, at 5:39 AM, Tim Chown wrote: > A major overhaul isn't needed. I agree. Can we get the discuss comments and other review comments addressed by the 26 Jun cut-off date? Do we nee to discuss this in the coming meeting? I would guess not, but I'm willing to give you a slot if you want one. I'm supposed to post an agenda by next Monday. Still looking for the update port-scanning document to put it into WGLC... From owner-v6ops@ops.ietf.org Mon Jun 12 15:14:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprrY-00022j-KX for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 15:14:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FprrW-000149-Ki for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 15:14:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FprpY-00065B-8g for v6ops-data@psg.com; Mon, 12 Jun 2006 19:12: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=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [195.20.121.7] (helo=mail1.cluenet.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FprpX-00064t-3a for v6ops@ops.ietf.org; Mon, 12 Jun 2006 19:12:07 +0000 Received: by mail1.cluenet.de (Postfix, from userid 500) id 2EB2D179C7; Mon, 12 Jun 2006 21:12:06 +0200 (CEST) Date: Mon, 12 Jun 2006 21:12:06 +0200 From: Daniel Roesen To: v6ops@ops.ietf.org Subject: Re: IPv6 Benchmarking Draft - Please provide feedback Message-ID: <20060612191206.GA9705@srv01.cluenet.de> Mail-Followup-To: v6ops@ops.ietf.org References: <3D1C81E7AA3CD64FA20B04D269FEF7F4019F538D@xmb-rtp-213.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D1C81E7AA3CD64FA20B04D269FEF7F4019F538D@xmb-rtp-213.amer.cisco.com> User-Agent: Mutt/1.4.1i Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Thu, Jun 08, 2006 at 02:36:36AM -0400, Chip Popoviciu (cpopovic) wrote: > Note that in keeping with the spirit of RFC 2544, no > benchmarking recommendations are made for tunneling mechanisms, the > focus remaining on native forwarding. I feel that performance of the various tunnelling mechanisms relating to IPv6 (this includes GRE!) is a very important factor for years to come, given that many folks will need to use them in the transition phase. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From owner-v6ops@ops.ietf.org Mon Jun 12 18:21:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpumz-0002DD-E5 for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 18:21:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpumv-0007YN-3B for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 18:21:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fpukq-000IyI-PK for v6ops-data@psg.com; Mon, 12 Jun 2006 22:19:28 +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, 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 1Fpukq-000Iy6-8V for v6ops@ops.ietf.org; Mon, 12 Jun 2006 22:19:28 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 15:19:28 -0700 X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="1824317313:sNHT31889198" 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 k5CMJRXL031961; Mon, 12 Jun 2006 15:19:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5CMJRkg012600; Mon, 12 Jun 2006 15:19:27 -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); Mon, 12 Jun 2006 15:19:27 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 15:19:26 -0700 In-Reply-To: <20060612191206.GA9705@srv01.cluenet.de> References: <3D1C81E7AA3CD64FA20B04D269FEF7F4019F538D@xmb-rtp-213.amer.cisco.com> <20060612191206.GA9705@srv01.cluenet.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0963F4D9-F0D0-48C1-A172-2EF5E6ACF32F@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: IPv6 Benchmarking Draft - Please provide feedback Date: Mon, 12 Jun 2006 15:19:25 -0700 To: Daniel Roesen X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 12 Jun 2006 22:19:27.0007 (UTC) FILETIME=[444CD2F0:01C68E6E] DKIM-Signature: a=rsa-sha1; q=dns; l=895; t=1150150767; x=1151014767; c=relaxed/simple; s=sjdkim4001; 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=20IPv6=20Benchmarking=20Draft=20-=20Please=20provide=20feedback; X=v=3Dcisco.com=3B=20h=3DdoelbMq5NbphPGfCscNRrKmFW/g=3D; b=gluoQC5uoeG7L719GrJ8+gDb0weW/dJv1aBGZhTTuY3sGKJaMXcSqcVAUsvUN74gyO6Wk3SM Ibx+2Ei1ikcphP6P/L7UCxsXc/NRJkKfL/4t9ZuER1czKTY0TBWtdrIm; 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: 2409bba43e9c8d580670fda8b695204a maybe the right answer is to go back to the benchmarking folks and ask them for a way of benchmarking tunneling solutions. Such a solution could be targeted at IPSEC tunnel mode in IPv4 and IPv6, GRE in IPv4 and IPv6, MPLS, L2TP, ... On Jun 12, 2006, at 12:12 PM, Daniel Roesen wrote: > On Thu, Jun 08, 2006 at 02:36:36AM -0400, Chip Popoviciu (cpopovic) > wrote: >> Note that in keeping with the spirit of RFC 2544, no >> benchmarking recommendations are made for tunneling mechanisms, the >> focus remaining on native forwarding. > > I feel that performance of the various tunnelling mechanisms relating > to IPv6 (this includes GRE!) is a very important factor for years to > come, given that many folks will need to use them in the transition > phase. > > > Regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From owner-v6ops@ops.ietf.org Mon Jun 12 18:34:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpuz7-0001xV-Ak for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 18:34:13 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpuz2-0000DH-Sp for v6ops-archive@lists.ietf.org; Mon, 12 Jun 2006 18:34:13 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FpuyN-000JyA-Ck for v6ops-data@psg.com; Mon, 12 Jun 2006 22:33: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, 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 1FpuyM-000Jxy-KL for v6ops@ops.ietf.org; Mon, 12 Jun 2006 22:33:26 +0000 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 12 Jun 2006 15:33:12 -0700 X-IronPort-AV: i="4.06,124,1149490800"; d="scan'208"; a="1824325086:sNHT5312232600" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5CMXBGa013313; Mon, 12 Jun 2006 15:33:11 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5CMXBcL002315; Mon, 12 Jun 2006 15:33:11 -0700 (PDT) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 18:33:10 -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: IPv6 Benchmarking Draft - Please provide feedback Date: Mon, 12 Jun 2006 18:33:09 -0400 Message-ID: <3D1C81E7AA3CD64FA20B04D269FEF7F401A6441A@xmb-rtp-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Benchmarking Draft - Please provide feedback Thread-Index: AcaObrTC36sr002CQ1qQbdfH1T+QPwAAPEfQ From: "Chip Popoviciu \(cpopovic\)" To: "Fred Baker \(fred\)" , "Daniel Roesen" Cc: X-OriginalArrivalTime: 12 Jun 2006 22:33:10.0918 (UTC) FILETIME=[2F63AA60:01C68E70] DKIM-Signature: a=rsa-sha1; q=dns; l=1439; t=1150151591; x=1151015591; c=relaxed/simple; s=sjdkim5001; 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:RE=3A=20IPv6=20Benchmarking=20Draft=20-=20Please=20provide=20feedback; X=v=3Dcisco.com=3B=20h=3DtyMr+O+PPSe3qdomlwdHm30l8+o=3D; b=tojTLa13DT5XMQs+aWiHnV3WEMKs6u+4AfJVS0azR89WaU+RTYKYQOOSHZuM8Z2KppLOwNsj DuJhUkivOLcSyjJnmNEBBrfqZ0ASiXo54d3vLvxarUkQ1ovcEiWicmqH; Authentication-Results: sj-dkim-5.cisco.com; header.From=cpopovic@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: 4adaf050708fb13be3316a9eee889caa Fred, I totally agree with this approach which would address a need for this type of benchmarking for both IPv4 and IPv6 within a common framework, specific to tunneling solutions. We will bring this suggestion to BMWG in Montreal. Best Regards, Chip -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker (fred) Sent: Monday, June 12, 2006 6:19 PM To: Daniel Roesen Cc: v6ops@ops.ietf.org Subject: Re: IPv6 Benchmarking Draft - Please provide feedback maybe the right answer is to go back to the benchmarking folks and ask them for a way of benchmarking tunneling solutions. Such a solution could be targeted at IPSEC tunnel mode in IPv4 and IPv6, GRE in IPv4 and IPv6, MPLS, L2TP, ... On Jun 12, 2006, at 12:12 PM, Daniel Roesen wrote: > On Thu, Jun 08, 2006 at 02:36:36AM -0400, Chip Popoviciu (cpopovic) > wrote: >> Note that in keeping with the spirit of RFC 2544, no benchmarking=20 >> recommendations are made for tunneling mechanisms, the focus=20 >> remaining on native forwarding. > > I feel that performance of the various tunnelling mechanisms relating=20 > to IPv6 (this includes GRE!) is a very important factor for years to=20 > come, given that many folks will need to use them in the transition=20 > phase. > > > Regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From owner-v6ops@ops.ietf.org Tue Jun 13 03:28:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3Js-0007Qs-84 for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 03:28:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3Jp-0000SI-Tb for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 03:28:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq3Gu-0006mv-Kr for v6ops-data@psg.com; Tue, 13 Jun 2006 07:25: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=AWL,BAYES_00,SPF_PASS autolearn=ham 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 1Fq3Gt-0006mI-2N for v6ops@ops.ietf.org; Tue, 13 Jun 2006 07:25:07 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k5D7P24k189720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Jun 2006 07:25:04 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 k5D7QGGv122240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jun 2006 08:26:16 +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 k5D7P1CZ030142 for ; Tue, 13 Jun 2006 08:25:01 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5D7P1Mw030096 for ; Tue, 13 Jun 2006 08:25:01 +0100 Received: from zurich.ibm.com (sig-9-146-218-200.de.ibm.com [9.146.218.200]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA46960 for ; Tue, 13 Jun 2006 09:25:00 +0200 Message-ID: <448E684C.8080507@zurich.ibm.com> Date: Tue, 13 Jun 2006 09:25: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: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-addcon-00.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: e1e48a527f609d1be2bc8d8a70eb76cb Just a few comments on this: > 1. Introduction > > The Internet Protocol Version 6 (IPv6) Addressing Architecture [23] > defines three main types of addresses: unicast, anycast and > multicast. This document focuses on unicast addresses, for which > there are currently three principal allocated types: Global Unique > Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs) > and 6bone address space [3]. It's a bit odd to include 6bone space as a "focus" item since all you say is that it's history. > 2.2. Unique Local IPv6 Addresses ... > Because a ULA and a global site prefix are both /48 length, an > administrator can choose to use the same subnetting (and host > addressing) plan for both prefixes. The RIRs are moving away from a rigid /48 policy. It would be safer to start this sentence with "When" instead of "Because". And on the same topic... > 2.4. Network Level Design Considerations I suggest adding a bullet at the end of this section along these lines: o It is possible that as registry policies evolve, a small site may experience an increase in prefix length when renumbering, e.g. from /48 to /56. For this reason, the best practice is number subnets compactly rather than sparsely, and to use low-order bits as much as possible when numbering subnets. In other words, even if a /48 is allocated, act as though only a /56 is available. Clearly, this advice does not apply to large sites and enterprises that have an intrinsic need for a /48 prefix. Brian From owner-v6ops@ops.ietf.org Tue Jun 13 04:58:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq4iw-0004Cg-QU for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 04:58:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq4iv-0001hE-Gj for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 04:58:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq4gz-000EpA-2G for v6ops-data@psg.com; Tue, 13 Jun 2006 08:56: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.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 1Fq4gx-000Eol-UT for v6ops@ops.ietf.org; Tue, 13 Jun 2006 08:56:07 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2006 01:56:06 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5D8u6vc007057; Tue, 13 Jun 2006 01:56:06 -0700 Received: from gvandevewxp (ams3-vpn-dhcp232.cisco.com [10.61.64.232]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5D8u5ke020187; Tue, 13 Jun 2006 01:56:05 -0700 (PDT) Reply-To: From: "Gunter Van de Velde \(gvandeve\)" To: "'Brian E Carpenter'" , Subject: RE: I-D ACTION:draft-ietf-v6ops-addcon-00.txt Date: Tue, 13 Jun 2006 10:56:05 +0200 Message-ID: <035a01c68ec7$352dfc00$64413d0a@emea.cisco.com> 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: AcaOuwYo2tDvvye7RPyEetnG2RWE1wACvTcA In-Reply-To: <448E684C.8080507@zurich.ibm.com> DKIM-Signature: a=rsa-sha1; q=dns; l=1874; t=1150188966; x=1151052966; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=22Gunter=20Van=20de=20Velde=20\(gvandeve\)=22=20 |Subject:RE=3A=20I-D=20ACTION=3Adraft-ietf-v6ops-addcon-00.txt; X=v=3Dcisco.com=3B=20h=3DC4ierq7u9P9t+13qZg9RdLdZPDs=3D; b=tbcYeWoUT4CFlfqE4Mqcst+B8Bmf7MMaabe4AmpHzXpsKmLsZHittL6rv4ZgmwvG5E+jWza7 RXo9I/7g7QzsqhOFxfCBxjK9hfrxE+y/3yMadzlHYqLN0fWUhX2/AewQ; Authentication-Results: sj-dkim-3.cisco.com; header.From=gvandeve@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: f4c2cf0bccc868e4cc88dace71fb3f44 Hi Brian, Many thanks for this swift response. See inline GV> > 1. Introduction > > The Internet Protocol Version 6 (IPv6) Addressing Architecture [23] > defines three main types of addresses: unicast, anycast and > multicast. This document focuses on unicast addresses, for which > there are currently three principal allocated types: Global Unique > Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs) > and 6bone address space [3]. It's a bit odd to include 6bone space as a "focus" item since all you say is that it's history. GV> maybe a rewording would help here. The intention was to mention that the focus area is unicast addresses. The address ranges were just given as the three principal allocated types. > 2.2. Unique Local IPv6 Addresses ... > Because a ULA and a global site prefix are both /48 length, an > administrator can choose to use the same subnetting (and host > addressing) plan for both prefixes. The RIRs are moving away from a rigid /48 policy. It would be safer to start this sentence with "When" instead of "Because". And on the same topic... GV> sounds ok to me. > 2.4. Network Level Design Considerations I suggest adding a bullet at the end of this section along these lines: o It is possible that as registry policies evolve, a small site may experience an increase in prefix length when renumbering, e.g. from /48 to /56. For this reason, the best practice is number subnets compactly rather than sparsely, and to use low-order bits as much as possible when numbering subnets. In other words, even if a /48 is allocated, act as though only a /56 is available. Clearly, this advice does not apply to large sites and enterprises that have an intrinsic need for a /48 prefix. GV> ok. Groetjes, G/ From owner-v6ops@ops.ietf.org Tue Jun 13 05:28:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5CF-0001Ra-5I for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 05:28:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq5CC-0003zH-PQ for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 05:28:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq5Av-000HVX-19 for v6ops-data@psg.com; Tue, 13 Jun 2006 09: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.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 1Fq5Au-000HVK-8w for v6ops@ops.ietf.org; Tue, 13 Jun 2006 09:27:04 +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 k5D9P5jK047514 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 13 Jun 2006 11:25:05 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <448DB926.50306@hotnic.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D144414-6F58-4B79-AE88-8F696ED2BEFF@muada.com> Cc: Kevin Loch , v6ops@ops.ietf.org, Elwyn Davies Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: IETF IPv6 platform configuration Date: Tue, 13 Jun 2006 11:26:16 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On 12-jun-2006, at 23:03, Pekka Savola wrote: >> Is there a compelling reason to filter ICMP at all? > IMHO, this is a valid question. Don't bother thinking about an answer, people are going to do it anyway. An important problem with all kinds of filtering in IPv6 is that most filters don't support the "protocol chain" concept so if you have a fragment header or an AH header or some such between the IPv6 header and the payload protocol, you're out of luck and the payload protocol isn't recognized. > There also happens to be a document, draft-ietf-v6ops-icmpv6- > filtering-recs-00.txt that discusses this very issue. It might be > interesting to have folks read that and provide feedback to v6ops > list (v6ops@ops.ietf.org) if they think there's something amiss > with it. Please use "hop limit" rather than "hop count" as the former is the official name of the field. And do we really need 34 pages just to say "if you're so paranoid that you want to filter ICMPv6, at least have the sense to let these ones through"? We live in an age of information overload, conciseness is a virtue! From owner-v6ops@ops.ietf.org Tue Jun 13 06:24:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq64u-0001HL-EA for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 06:24:56 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq64s-0001IV-H5 for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 06:24:56 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq63B-000MR1-Hi for v6ops-data@psg.com; Tue, 13 Jun 2006 10:23: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.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 1Fq63A-000MQl-7Q for v6ops@ops.ietf.org; Tue, 13 Jun 2006 10:23:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k5DAM8wI022002; Tue, 13 Jun 2006 13:22:08 +0300 Date: Tue, 13 Jun 2006 13:22:08 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Kevin Loch , v6ops@ops.ietf.org, Elwyn Davies Subject: Re: IETF IPv6 platform configuration In-Reply-To: <3D144414-6F58-4B79-AE88-8F696ED2BEFF@muada.com> Message-ID: References: <448DB926.50306@hotnic.net> <3D144414-6F58-4B79-AE88-8F696ED2BEFF@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 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: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, 13 Jun 2006, Iljitsch van Beijnum wrote: > And do we really need 34 pages just to say "if you're so paranoid that you > want to filter ICMPv6, at least have the sense to let these ones through"? > > We live in an age of information overload, conciseness is a virtue! While I agree that some parts of the doc could possibly be a bit shorter, I still think the document is about the right length. The main meat is about 15 pages. The question at this point is, I guess, whether all the appendices are useful enough. At least the text in the main body is required when a reader starts to think "but, I really want to block [foo]. Why shouldn't I just go ahead and do so?" That said, maybe it wouldn't hurt to put some conclusions to the abstract, introduction, a new section or call them out more explicitly from the existing text. -- 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 Tue Jun 13 09:00:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq8Uz-0006ic-By for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 09:00:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq8Ux-0006od-SH for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 09:00:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8T4-0009kY-MB for v6ops-data@psg.com; Tue, 13 Jun 2006 12:58: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.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8T3-0009k9-3F for v6ops@ops.ietf.org; Tue, 13 Jun 2006 12:58:01 +0000 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Fq8T1-0006gr-1M; Tue, 13 Jun 2006 13:57:59 +0100 Message-ID: <448EB701.1090207@dial.pipex.com> Date: Tue, 13 Jun 2006 14:00:49 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= CC: v6ops@ops.ietf.org Subject: Re: WGLC draft-ietf-v6ops-icmpv6-filtering-recs-00.txt References: <200604272102.31270@auguste.remlab.net> In-Reply-To: <200604272102.31270@auguste.remlab.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Apologies for the long delay in answering: Comments below - updates in new -01 version appearing shortly. /Elwyn Rémi Denis-Courmont wrote: > Le Mercredi 26 Avril 2006 21:58, vous avez écrit : > >> Per the WG decision in the meeting last month, I am opening a working >> group last call on the filtering document >> >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6- >> filtering-recs-00.txt >> "Best Current Practice for Filtering ICMPv6 Messages in Firewalls" >> > > A few minor notes: > > 1/ The specification does not seem to consider what should be made with > filtered packets, and seems to assume they will be dropped. In some > case (such as the _currently_ undefined ICMP codes), it might be nicer, > so long as the local policy permits, to cause the firewall to craft an > Administratively prohibited error or something like that (à > la “ip6tables -j REJECT”), maybe... though I guess some kind of rate > limiting would obviously be required in that case. > RFC2463 explicitly requires that undefined informational messages are silently dropped. Responding to error messages with an error message would not be clever. There are a couple of other cases where it might be possible, but on due consideration, I think that, on security grounds, dropping is the right answer > > 2/ When I see sample rules like these: > “ > # Deny icmps to/from link local addresses > ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP > ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP > ”... I'm becoming worried that the forwarding/routing software from > Linux IPv6 stack actually let this packets through by default > (particularly the first rule). I'm pretty sure the first one is > redumdant, and I hope the second one is also. That's not to say > firewall admin should not use them for the sake of verbosity and/or > quietness of mind, but it might be worth adding a comment that these > are already sort of built-in. > Done. > By the way, if anyone can confirm that these rules are actually > redumdant... > > > 3/ I believe filter Echo requests is fairly lame, and I did complain > that Teredo needs it to work at all. Now Teredo is mentioned and Echo > requests were promoted from "Should not be blocked" to "Must not be > blocked" :) Some other yet-to-be-defined protocols/schemes might also > rely on incoming Echo requests to not be firewalled, and I surely hope > not so many company and SOHO firewalls will block IPv6 echo requests, > as IPv4 echo requests.... but as far as Teredo is concerned, only Echo > requests coming from the Teredo prefix (2001:0::/32) needs to be passed > (and of course Echo replies, only the other way). > I don't think this requires any action. The draft recommends never dropping Echo Requests or Echo Responses. /Elwyn > Regards, > > From owner-v6ops@ops.ietf.org Tue Jun 13 09:09:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq8dq-0004J8-Kw for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 09:09:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq8dp-0007Zj-Bq for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 09:09:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8dO-000Ae6-TO for v6ops-data@psg.com; Tue, 13 Jun 2006 13:08: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.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fq8dO-000Adk-1y for v6ops@ops.ietf.org; Tue, 13 Jun 2006 13:08:42 +0000 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Fq8dJ-0007Ly-3i; Tue, 13 Jun 2006 14:08:37 +0100 Message-ID: <448EB97F.6050005@dial.pipex.com> Date: Tue, 13 Jun 2006 14:11:27 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola CC: Iljitsch van Beijnum , Kevin Loch , v6ops@ops.ietf.org Subject: Re: IETF IPv6 platform configuration References: <448DB926.50306@hotnic.net> <3D144414-6F58-4B79-AE88-8F696ED2BEFF@muada.com> 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: 52e1467c2184c31006318542db5614d5 Pekka Savola wrote: > On Tue, 13 Jun 2006, Iljitsch van Beijnum wrote: >> And do we really need 34 pages just to say "if you're so paranoid >> that you want to filter ICMPv6, at least have the sense to let these >> ones through"? >> >> We live in an age of information overload, conciseness is a virtue! > > While I agree that some parts of the doc could possibly be a bit > shorter, I still think the document is about the right length. The > main meat is about 15 pages. The question at this point is, I guess, > whether all the appendices are useful enough. At least the text in > the main body is required when a reader starts to think "but, I really > want to block [foo]. Why shouldn't I just go ahead and do so?" The actual recommendations run to 7 pages and the example script (Appendix B) is about the same length - given the two cases and the number of different messages I don't think you can get much more concise if you want a bit of reasoning and a decent layout. Appendix A provides the detailed analysis: discarding this would be possible, but the result is people have to reinvent the logic sometime in the future. > > That said, maybe it wouldn't hurt to put some conclusions to the > abstract, introduction, a new section or call them out more explicitly > from the existing text. > I can't see a very simple way to add a *brief* conclusion to the abstract/intro. What I have done is to add a paragraph pointing directly to the recommendations for those who think they know about (or don't care about) ICMPv6 and what security attacks might eventuate. /Elwyn From owner-v6ops@ops.ietf.org Tue Jun 13 15:52:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqEw5-0006M6-I6 for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 15:52:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqEw4-0007nt-5H for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 15:52:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqEtp-000GOW-Ts for v6ops-data@psg.com; Tue, 13 Jun 2006 19:50:05 +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.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqEto-000GNt-W4 for v6ops@ops.ietf.org; Tue, 13 Jun 2006 19:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5DJo2Rx021305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqEtm-0007gU-1o; Tue, 13 Jun 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-ent-analysis-06.txt Message-Id: Date: Tue, 13 Jun 2006 15:50:02 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --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 Enterprise Network Analysis Author(s) : J. Bound, et al. Filename : draft-ietf-v6ops-ent-analysis-06.txt Pages : 43 Date : 2006-6-13 This document analyzes the transition to IPv6 in enterprise networks. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-06.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-ent-analysis-06.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-ent-analysis-06.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-6-13143804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-analysis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-analysis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-13143804.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jun 13 16:56:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFwA-0005Ow-7S for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 16:56:34 -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 1FqFP4-0002eY-Kg for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 16:22:22 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqEwp-000394-6p for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 15:53:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqEwO-000Gbg-L6 for v6ops-data@psg.com; Tue, 13 Jun 2006 19:52:44 +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, 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 1FqEwN-000GbR-HY for v6ops@ops.ietf.org; Tue, 13 Jun 2006 19:52:43 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 13 Jun 2006 12:52:43 -0700 X-IronPort-AV: i="4.06,128,1149490800"; d="scan'208"; a="1824935782:sNHT45079560" 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 k5DJqhwN002669; Tue, 13 Jun 2006 12:52:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5DJqd9u010562; Tue, 13 Jun 2006 12:52:39 -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); Tue, 13 Jun 2006 12:52:39 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 12:52:31 -0700 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: iesg-secretary@ietf.org, v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: draft-ietf-v6ops-icmpv6-filtering-recs to informational Date: Tue, 13 Jun 2006 12:52:29 -0700 To: David Kessens X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 13 Jun 2006 19:52:31.0674 (UTC) FILETIME=[E85D81A0:01C68F22] DKIM-Signature: a=rsa-sha1; q=dns; l=7641; t=1150228363; x=1151092363; 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:draft-ietf-v6ops-icmpv6-filtering-recs=20to=20informational; X=v=3Dcisco.com=3B=20h=3D2+Q/FbuKFzjA9wOkp7F4uisYr1o=3D; b=hAlQu9dYG4bxnAzrp3K7HAsFKN6dIgCl91avlPWLNZtPpqBoZdvc/Zk6D5nImVqa1J9ZJtsf iiAP9stLy+RVb6y+ua6956UFNI1CC4MzKd6qG7n+yx9Tdqpd20aYlHCd; 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: -2.3 (--) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba > 1.a) Have the chairs personally reviewed this version of the > Internet > Draft (ID), and in particular, do they believe this ID is > ready > to forward to the IESG for publication? Which chair is the WG > Chair Shepherd for this document? Yes, I have reviewed the document, and I plan to shepherd it. I believe that it gives practical advice on who firewalls and other security middleware may be configured to manage IPv6 ICMP traffic, which one must expect to be used as IPv4 ICMP traffic has been used in fomenting attacks. The real value in this document, besides suggesting appropriate firewall configurations, is in the lines of reasoning presented for the configuration elements. For example, a router solicitation by definition travels from a host seeking a first hop router to a system that it is directly connected to at a lower layer such as a wired or wireless Ethernet. The document recommends that this class of message never be forwarded, and one in fact hopes that not only would it not be forwarded, but that the originator would set TTL=1 to prevent the occurrence even if the router were misconfigured. As such, the document collects a fair bit of wisdom from which the unschooled can learn. > 1.b) Has the document had adequate review from both key WG members > and key non-WG members? Do you have any concerns about the > depth or breadth of the reviews that have been performed? This document has been through working group review since its introduction about a year ago. This version responds to comments presented during working group last call in May 2006. I believe that it has had adequate review. > 1.c) Do you have concerns that the document needs more review > from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, internationalization, > XML, etc.)? Since it deals with security issues, a review from the security area may be of value. > 1.d) Do you have any specific concerns/issues with this document > that > you believe the ADs and/or IESG should be aware of? For > example, perhaps you are uncomfortable with certain parts > of the > document, or have concerns whether there really is a need for > it. In any event, if your issues have been discussed in > the WG > and the WG has indicated it that it still wishes to advance > the > document, detail those concerns in the write-up. The document was originally proposed for BCP status, and was downgraded to informational based on the notion that we should get experience with the document before giving it that class of approbation. We expect to review the document about a year hence in view of operational experience. Apart from that, the working group has been supportive. > 1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? v6ops is, as a group, quiet. One therefore has to describe this as having strong proponents rather than an avalanch of support. My observation, however, is that when v6ops does not support something, they tell us, and this has not happened. I conclude that there is operational support and little if any dissent. > 1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email to the Responsible Area Director. (It > should be > separate email because this questionnaire will be entered into > the tracker). no > 1.g) Have the chairs verified that the document checks out against > all the ID nits? (see http://www.ietf.org/ID-Checklist.html). > Boilerplate checks are not enough; this check needs to be > thorough. draft-ietf-v6ops-icmpv6-filtering-recs-01.txt was run through idnits 1.102 on 13 June. It reported no issues. I also ran it through ispell on a Solaris system. It revealed some disagreements between British and American versions of English. The Brits can't spill there wards rite. > 1.h) Has the document split its references into normative and > informative? Are there normative references to IDs, where the > IDs are not also ready for advancement or are otherwise in an > unclear state? The RFC Editor will not publish an RFC with > normative references to IDs (will delay the publication until > all such IDs are also ready for RFC publicatioin). If the > normative references are behind, what is the strategy for > their > completion? On a related matter, are there normative > references > that are downward references, as described in BCP 97, RFC 3967 > RFC 3967 [RFC3967]? Listing these supports the Area > Director in > the Last Call downref procedure specified in RFC 3967. The references are so divided. There are two normative references to internet drafts, draft-ietf- ipngwg-icmp-name-lookups and draft-ietf-ipngwg-icmp-v3. The former is in the RFC Editor's queue, and the latter was recently published as RFC 4443, which is also listed as a normative reference. In addition, there are two informative references to internet drafts. draft-chown-v6ops-port-scanning-implications will, in the coming weeks, be replaced by draft-ietf-v6ops-scanning-implications, and will in all likelihood be sent to the IESG following a working group last call in July. draft-gont-tcpm-icmp-attacks has been replaced by draft-ietf-tcpm-icmp-attacks, which was placed in the "AD is watching" state by Lars Eggert last March. I would recommend that the RFC Editor update these references to the appropriate RFC references during the edit-for-publication process. > 1.i) For Standards Track and BCP documents, the IESG approval > announcement includes a write-up section with the following > sections: > > * Technical Summary 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. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. 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. > * Working Group Summary This was approved by the IPv6 Operations Working Group following an extended discussion. > * Protocol Quality This is not a protocol, but it describes operational configurations for mnaging a protocol whose counterpart has warranted similar controls in the IPv4 Internet. The working group believes that the logic it presents and the configuration paradigm it espouses are correct. v6ops plans to review deployment experience and recommend elevation to BCP status in 12-24 months. From owner-v6ops@ops.ietf.org Tue Jun 13 18:22:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHHa-0002iq-NX for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 18:22:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHHZ-00078w-CS for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 18:22:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqHFh-0000yA-Eu for v6ops-data@psg.com; Tue, 13 Jun 2006 22:20:49 +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 1FqHFg-0000xx-73 for v6ops@ops.ietf.org; Tue, 13 Jun 2006 22:20:48 +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 k5DMJRY5059956 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Jun 2006 00:19:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> Cc: David Kessens , iesg-secretary@ietf.org, v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Date: Wed, 14 Jun 2006 00:20:38 +0200 To: Fred Baker X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On 13-jun-2006, at 21:52, Fred Baker wrote: > The real value in this document, besides suggesting appropriate > firewall configurations, is in the lines of reasoning presented for > the configuration elements. For example, a router solicitation by > definition travels from a host seeking a first hop router to a > system that it is directly connected to at a lower layer such as a > wired or wireless Ethernet. The document recommends that this class > of message never be forwarded, and one in fact hopes that not only > would it not be forwarded, but that the originator would set TTL=1 > to prevent the occurrence even if the router were misconfigured. RFC 2461: 6.1.1. Validation of Router Solicitation Messages Hosts MUST silently discard any received Router Solicitation Messages. A router MUST silently discard any received Router Solicitation messages that do not satisfy all of the following validity checks: - The IP Hop Limit field has a value of 255, i.e., the packet could not possibly have been forwarded by a router. Although the document mentions using the hop limit at 255 as a security feature, I think this could be more prominent, as it may give people a reason to forego some or even all ICMPv6 filtering. > As such, the document collects a fair bit of wisdom from which the > unschooled can learn. You're making me bite my tongue here, Fred... >> 1.b) Has the document had adequate review from both key WG members >> and key non-WG members? Do you have any concerns about the >> depth or breadth of the reviews that have been performed? > This document has been through working group review since its > introduction about a year ago. This version responds to comments > presented during working group last call in May 2006. I believe > that it has had adequate review. Please have the use of "hop count" changed to "hop limit" in the document to reflect the actual name of the field. From owner-v6ops@ops.ietf.org Tue Jun 13 18:49:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHhq-0006UH-Ev for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 18:49:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHhp-0003MJ-1Q for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 18:49:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqHgo-0003F6-LQ for v6ops-data@psg.com; Tue, 13 Jun 2006 22:48: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, 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 1FqHgo-0003Es-3Q for v6ops@ops.ietf.org; Tue, 13 Jun 2006 22:48:50 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 13 Jun 2006 15:48:49 -0700 X-IronPort-AV: i="4.06,128,1149490800"; d="scan'208"; a="1825080742:sNHT143360362" 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 k5DMmnmA019576; Tue, 13 Jun 2006 15:48:49 -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 k5DMmfAS022312; Tue, 13 Jun 2006 15:48:49 -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); Tue, 13 Jun 2006 15:48:48 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 15:48:47 -0700 In-Reply-To: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> Cc: David Kessens , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Date: Tue, 13 Jun 2006 15:48:44 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 13 Jun 2006 22:48:47.0814 (UTC) FILETIME=[883C6660:01C68F3B] DKIM-Signature: a=rsa-sha1; q=dns; l=2785; t=1150238929; x=1151102929; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20draft-ietf-v6ops-icmpv6-filtering-recs=20to=20informational; X=v=3Dcisco.com=3B=20h=3DypwoY0zpOVmspMUvCT7kBUlzEO0=3D; b=nosRV8oFAH44WU1C1byMS23sxTkYXRcwxuUykuV+VvFLVNLWHGpqFzVY40RhwgyUQkMqe7bl qP9r6FAaM1PaFL+g6mQgkrch6Hu38Z9ufGFoQQjr/k5NW52DlNXbR62d; 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: 082a9cbf4d599f360ac7f815372a6a15 Let's see. How long have you had to review this, and when did the WGLC close? Remind me? There will not be an IETF Last Call, as this is an informational document. If there were, I would encourage you to make the comment in response to the IETF last call. If the ADs send the document back for a new I-D for some reason, I will expect the authors to respond to this. I'm not going to hold it up for this, though. The document makes rather a point that there is significant value to ICMP filtering, so I can't imagine the comment really being interpreted as a reason to not filter. On Jun 13, 2006, at 3:20 PM, Iljitsch van Beijnum wrote: > On 13-jun-2006, at 21:52, Fred Baker wrote: > >> The real value in this document, besides suggesting appropriate >> firewall configurations, is in the lines of reasoning presented >> for the configuration elements. For example, a router solicitation >> by definition travels from a host seeking a first hop router to a >> system that it is directly connected to at a lower layer such as a >> wired or wireless Ethernet. The document recommends that this >> class of message never be forwarded, and one in fact hopes that >> not only would it not be forwarded, but that the originator would >> set TTL=1 to prevent the occurrence even if the router were >> misconfigured. > > RFC 2461: > > 6.1.1. Validation of Router Solicitation Messages > > Hosts MUST silently discard any received Router Solicitation > Messages. > > A router MUST silently discard any received Router Solicitation > messages that do not satisfy all of the following validity checks: > > - The IP Hop Limit field has a value of 255, i.e., the packet > could not possibly have been forwarded by a router. > > Although the document mentions using the hop limit at 255 as a > security feature, I think this could be more prominent, as it may > give people a reason to forego some or even all ICMPv6 filtering. > >> As such, the document collects a fair bit of wisdom from which the >> unschooled can learn. > > You're making me bite my tongue here, Fred... > >>> 1.b) Has the document had adequate review from both key WG >>> members >>> and key non-WG members? Do you have any concerns about the >>> depth or breadth of the reviews that have been performed? > >> This document has been through working group review since its >> introduction about a year ago. This version responds to comments >> presented during working group last call in May 2006. I believe >> that it has had adequate review. > > Please have the use of "hop count" changed to "hop limit" in the > document to reflect the actual name of the field. From owner-v6ops@ops.ietf.org Tue Jun 13 18:50:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHiU-0006wq-1M for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 18:50:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHiS-0003Pd-Kc for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 18:50:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqHiM-0003OB-Hp for v6ops-data@psg.com; Tue, 13 Jun 2006 22:50:26 +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.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqHiL-0003MS-Q6 for v6ops@ops.ietf.org; Tue, 13 Jun 2006 22:50:25 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5DMo1Rx028016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqHhx-0006dl-ME; Tue, 13 Jun 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-icmpv6-filtering-recs-01.txt Message-Id: Date: Tue, 13 Jun 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 : Recommendations for Filtering ICMPv6 Messages in Firewalls Author(s) : E. Davies, J. Mohacsi Filename : draft-ietf-v6ops-icmpv6-filtering-recs-01.txt Pages : 35 Date : 2006-6-13 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. A number of security risks are associated with uncontrolled forwarding of ICMPv6 messages. On the other hand, compared with IPv4 and the corresponding protocol ICMP, ICMPv6 is essential to the functioning of IPv6 rather than a useful auxiliary. 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-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-icmpv6-filtering-recs-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-icmpv6-filtering-recs-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-6-13155638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-recs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-icmpv6-filtering-recs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-13155638.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jun 13 19:22:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqICd-0001QV-Oq for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 19:21:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqI4F-0005rn-Gd for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 19:13:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqI3W-0005Em-FM for v6ops-data@psg.com; Tue, 13 Jun 2006 23: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=-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 1FqI3V-0005EZ-Ku for v6ops@ops.ietf.org; Tue, 13 Jun 2006 23:12:17 +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 k5DNAwpK060832 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Jun 2006 01:10:59 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David Kessens , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Date: Wed, 14 Jun 2006 01:12:10 +0200 To: Fred Baker X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On 14-jun-2006, at 0:48, Fred Baker wrote: > Let's see. How long have you had to review this, and when did the > WGLC close? Remind me? I didn't read the document until a week ago or so when Pekka linked to it on the IETF list and asked for comments. > There will not be an IETF Last Call, as this is an informational > document. If there were, I would encourage you to make the comment > in response to the IETF last call. If the ADs send the document > back for a new I-D for some reason, I will expect the authors to > respond to this. I'm not going to hold it up for this, though. The > document makes rather a point that there is significant value to > ICMP filtering, so I can't imagine the comment really being > interpreted as a reason to not filter. No, why would we point out to people that our protocols are clever enough to not require any filtering? Or use the same name for the same field in different documents? That's way too much trouble with all those RFCs we have to write that no one in operations reads anyway because they're too long and too hard to read, and which are too hard to find out that they exist in the first place. The fact that you talked about TTL=1 while claiming to have reviewed the document proves several of these points. Refusal to make changes proves a few more. I know running a standards organization based 90% on volunteer effort is hard, but producing sub-par documents is not part of the solution. The IETF seems fundamentally incapable of doing things fast, so getting things right is all the more important. Last but not least: is "don't bother reviewing documents as we're going to ignore feedback" really the message you want to send? As soon as someone pays me to do IETF work I promise I'll get in my comments before last calls expire. Until that time, other work will have to take precedence. From owner-v6ops@ops.ietf.org Tue Jun 13 20:32:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqJJ7-0002Kr-DI for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 20:32:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqJJ5-0006B9-V2 for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 20:32:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqJGf-000B5k-FZ for v6ops-data@psg.com; Wed, 14 Jun 2006 00: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=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham 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 1FqJGe-000B5P-LN for v6ops@ops.ietf.org; Wed, 14 Jun 2006 00:29:56 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2006 17:29:56 -0700 X-IronPort-AV: i="4.06,128,1149490800"; d="scan'208"; a="294239282:sNHT92348196" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5E0TurN003481; Tue, 13 Jun 2006 17:29:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5E0Ttke020855; Tue, 13 Jun 2006 17:29:56 -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, 13 Jun 2006 17:29:55 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Jun 2006 17:29:55 -0700 In-Reply-To: References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9344B322-C7AF-4E31-964C-E44B8F308978@cisco.com> Cc: David Kessens , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Date: Tue, 13 Jun 2006 17:29:53 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 14 Jun 2006 00:29:55.0294 (UTC) FILETIME=[A8BC5FE0:01C68F49] DKIM-Signature: a=rsa-sha1; q=dns; l=3518; t=1150244996; x=1151108996; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20draft-ietf-v6ops-icmpv6-filtering-recs=20to=20informational; X=v=3Dcisco.com=3B=20h=3DypwoY0zpOVmspMUvCT7kBUlzEO0=3D; b=Oe8J6mwidNhbtZgXQdtdEmr5fzRKLqdaW47aoZyCWssuySI4NQ/gbh5kOMWvWWPx1mCwhVOR RWjuT3IKqlztaYfVIaFRbLfkzKYrsWoNycfmB6Jbhy5SqEy+QSjpBP9J; 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: f60d0f7806b0c40781eee6b9cd0b2135 No, I'm not trying to say "we're not going to do anything with the feedback". I *am*, however, saying that feedback needs to be timely, and given all the delays built into the system (one of which is me) and the number of times that the working group (which you are a part of) has been asked for comment, sending small comments in immediately after I *finally* send the document off to the IESG is *really*late*, and expecting the authors and the working group to spin on a dime to fix them isn't very realistic. If you want to discuss delays in process in detail, I would suggest you take Jim Bound or Yannick Pouffary aside and ask them what they really think about that silly chair of the v6ops WG delaying things every time just to get the document right... We'll pick these comments up if the IESG asks for a revision. As to my comment on the Hop Limit, I did read the document. It states, in several places, that the recommendation is that the Hop Limit be set to 255 and tested for still being 255 on receipt. What I stated was that I would go at it a different way. If the packet is sent with Hop Limit = 1, it cannot pass a compliant router or firewall, so there is no need to test for whether it did or didn't. My way is, I think, more robust - it depends only on the sender, not the sender and the receiver. But you note that I didn't require a change to suit my fancy either. On Jun 13, 2006, at 4:12 PM, Iljitsch van Beijnum wrote: > On 14-jun-2006, at 0:48, Fred Baker wrote: > >> Let's see. How long have you had to review this, and when did the >> WGLC close? Remind me? > > I didn't read the document until a week ago or so when Pekka linked > to it on the IETF list and asked for comments. > >> There will not be an IETF Last Call, as this is an informational >> document. If there were, I would encourage you to make the comment >> in response to the IETF last call. If the ADs send the document >> back for a new I-D for some reason, I will expect the authors to >> respond to this. I'm not going to hold it up for this, though. The >> document makes rather a point that there is significant value to >> ICMP filtering, so I can't imagine the comment really being >> interpreted as a reason to not filter. > > No, why would we point out to people that our protocols are clever > enough to not require any filtering? Or use the same name for the > same field in different documents? That's way too much trouble with > all those RFCs we have to write that no one in operations reads > anyway because they're too long and too hard to read, and which are > too hard to find out that they exist in the first place. > > The fact that you talked about TTL=1 while claiming to have > reviewed the document proves several of these points. Refusal to > make changes proves a few more. > > I know running a standards organization based 90% on volunteer > effort is hard, but producing sub-par documents is not part of the > solution. > > The IETF seems fundamentally incapable of doing things fast, so > getting things right is all the more important. > > Last but not least: is "don't bother reviewing documents as we're > going to ignore feedback" really the message you want to send? As > soon as someone pays me to do IETF work I promise I'll get in my > comments before last calls expire. Until that time, other work will > have to take precedence. From owner-v6ops@ops.ietf.org Tue Jun 13 22:53:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqLVH-0006To-Eb for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 22:53:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqLV2-00073p-L2 for v6ops-archive@lists.ietf.org; Tue, 13 Jun 2006 22:53:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqLSa-000Mgs-Vp for v6ops-data@psg.com; Wed, 14 Jun 2006 02:50:25 +0000 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqLS3-000MdG-Ii for v6ops@ops.ietf.org; Wed, 14 Jun 2006 02:50:24 +0000 Received: from eaglet (127.0.0.1:2367) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 13 Jun 2006 19:49:30 -0700 From: "Tony Hain" To: "'Fred Baker'" , "'Tim Chown'" Cc: Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Tue, 13 Jun 2006 19:49:22 -0700 Message-ID: <0ce501c68f5d$23cee550$7abe838e@tndh.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0CE6_01C68F22.77700D50" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaORGFrfQ3OW/cEQBeMsFk9396AsgBFxRCg In-Reply-To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 2.3 (++) X-Scan-Signature: b80cbe8936c7ca54b64c901f76eab4f9 This is a multi-part message in MIME format. ------=_NextPart_000_0CE6_01C68F22.77700D50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. Tony https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=5 2102 I put in an arbitrary 50k number as a scale reference. 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. https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=5 2051 This one is somewhat all over the place. Lack of understanding of the technology by an IESG member should not override a working group consensus. 2.2 has already been reworked. 3.4 does not oversell if you understand how MIPv6 really works. 4.2 -2 does not oversell IPsec, it simply states the real situation. 4.3 has additional text, though this is one where the IESG has lost the context of this being wrt a nat deployment. 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. 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. https://datatracker.ietf.org/public/pidtracker.cgi?command=view_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. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Fred Baker > Sent: Monday, June 12, 2006 10:16 AM > To: Tim Chown > Cc: v6ops@ops.ietf.org > Subject: Re: Review of draft-ietf-v6ops-nap-02.txt > > On Jun 12, 2006, at 5:39 AM, Tim Chown wrote: > > A major overhaul isn't needed. > > I agree. Can we get the discuss comments and other review comments > addressed by the 26 Jun cut-off date? > > Do we nee to discuss this in the coming meeting? I would guess not, > but I'm willing to give you a slot if you want one. I'm supposed to > post an agenda by next Monday. > > Still looking for the update port-scanning document to put it into > WGLC... ------=_NextPart_000_0CE6_01C68F22.77700D50 Content-Type: text/html; name="rfcdiff-nap-02-03-draft0.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rfcdiff-nap-02-03-draft0.htm" =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Diff: draft-ietf-v6ops-nap-03.txt - = draft-ietf-v6ops-nap-02.txt=20 =20 =20 =20 =20 =20 = = = = = = = = = = = = = =
 draft-ietf-v6ops-nap-03.txt  =  draft-ietf-v6ops-nap-02.txt 
Network Working Group = G. Van de Velde Network Working Group = G. Van de Velde
Internet-Draft = T. Hain Internet-Draft = T. Hain
Expires: December 4, 2006 = R. Droms Expires: April 25, 2006 = R. Droms
= Cisco = Systems = Cisco Systems
= B. = Carpenter = B. Carpenter
= IBM = Corporation = IBM Corporation
= E. = Klein = E. Klein
= Tel Aviv = University = Tel Aviv University
= June 2, 2006 = October 22, 2005
= IPv6 Network Architecture Protection IPv6 Network Architecture = Protection
= <draft-ietf-v6ops-nap-03.txt> = <draft-ietf-v6ops-nap-02.txt>
Status of this Memo Status of this Memo
= By submitting this Internet-Draft, each author represents that = any By submitting this = Internet-Draft, each author represents that any
= applicable patent or other IPR claims of which he or she is = aware applicable patent or other = IPR claims of which he or she is aware
= have been or will be disclosed, and any of which he or she = becomes have been or will be = disclosed, and any of which he or she becomes
= aware will be disclosed, in accordance with Section 6 of BCP = 79. aware will be disclosed, in = accordance with Section 6 of BCP 79.
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
= Task Force (IETF), its areas, and its working groups. Note = that Task Force (IETF), its areas, = and its working groups. Note that
=
skipping to change at page 1, line 39 = skipping to change at = page 1, line 39
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, = or obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work = in progress."
= The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed = at
= http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
= The list of Internet-Draft Shadow Directories can be accessed = at The list of Internet-Draft = Shadow Directories can be accessed at
= http://www.ietf.org/shadow.html. = http://www.ietf.org/shadow.html.
= This Internet-Draft will expire on December = 4, 2006. This = Internet-Draft will expire on April 25, = 2006.
Copyright Notice Copyright Notice
= Copyright (C) The Internet Society (2006). = Copyright (C) The Internet Society (2005).
Abstract Abstract
= Although there are many perceived benefits to Network Address = Although there are many perceived benefits = to Network Address
= Translation (NAT), its primary benefit of "amplifying" = available Translation (NAT), its = primary benefit of "amplifying" available
= address space is not needed in IPv6. In addition to NAT's many = address space is not needed in IPv6. In = addition to NAT's many
= serious disadvantages, there is a perception that other = benefits serious disadvantages, = there is a perception that other benefits
= exist, such as a variety of management and security attributes = that exist, such as a variety of = management and security attributes that
= could be useful for an Internet Protocol site. IPv6 does not = support could be useful for an = Internet Protocol site. IPv6 does not support
= NAT by design and this document shows how Network Architecture = NAT by design and this document shows how = Network Architecture
= Protection (NAP) using IPv6 can provide the same or more = benefits Protection (NAP) using = IPv6 can provide the same or more benefits
= without the need for NAT. without = the need for NAT.
Table of Contents Table = of Contents
= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 4 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . . 4
= 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . = 7 2. = Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 6
= 2.1. Simple Gateway between Internet and Private Network . . . = 7 = 2.1. Simple Gateway between Internet and Private Network . . . 6
= 2.2. Simple Security due to Stateful Filter Implementation . . = 8 = 2.2. Simple Security due to Stateful Filter Implementation . . 6
= 2.3. User/Application tracking . . . . . . . . . . . . . . . . = 8 = 2.3. User/Application tracking . . . . . . . . . . . . . . . . 7
= 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . = 9 = 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 8
= 2.5. Independent Control of Addressing in a Private Network . . = 10 = 2.5. Independent Control of Addressing in a Private Network . . 9
= 2.6. Global Address Pool Conservation . . . . . . . . . . . . . = 10 = 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 9
= 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . = 11 = 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 10
= 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . = 11 = 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 10
= 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . = 12 = 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 10
= 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . = 12 = 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 11
= 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . = 13 = 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 12
= 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . = 13 = 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 12
= 4. Using IPv6 Technology to Provide the Market Perceived = 4. Using IPv6 Technology to Provide the = Market Perceived
= Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . = 14 = Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 13
= 4.1. Simple Gateway between Internet and Internal Network . . . = 14 = 4.1. Simple Gateway between Internet and Internal Network . . . 13
= 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . = 15 = 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 13
= 4.3. User/Application Tracking . . . . . . . . . . . . . . . . = 17 = 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 15
= 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . = 17 = 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 15
= 4.5. Independent Control of Addressing in a Private Network . . = 19 = 4.5. Independent Control of Addressing in a Private Network . . 16
= 4.6. Global Address Pool Conservation . . . . . . . . . . . . . = 20 = 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 17
= 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . = 20 = 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 17
= 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . = 21 = 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 18
= 5.1. Medium/large private networks . . . . . . . . . . . . . . = 21 = 5.1. Medium/large private networks . . . . . . . . . . . . . . 18
= 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . = 23 = 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 20
= 5.3. Single User Connection . . . . . . . . . . . . . . . . . . = 24 = 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 21
= 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . = 25 = 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 22
= 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . = 26 = 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 23
= 6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . = 26 = 6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . 23
= 6.2. Minimal Traceability of Privacy Addresses . . . . . . . . = 26 = 6.2. Minimal Traceability of Privacy Addresses . . . . . . . . 23
= 6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . = 27 = 6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . 23
= 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . = 27 = 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 24
= 6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . = 27 = 6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . 24
= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 27 = 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
= 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 27 = 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
= 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . = 28 = 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
= 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 28 = 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 28 = 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
= 11.1. Normative References . . . . . . . . . . . . . . . . . . . = 28 = 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
= 11.2. Informative References . . . . . . . . . . . . . . . . . . = 29 = 11.2. Informative References . . . . . . . . . . . . . . . . . . 26
= Appendix A. Additional Benefits due to Native IPv6 and = Appendix A. Additional Benefits due to = Native IPv6 and
= Universal Unique Addressing . . . . . . . . . . . . . = 30 = Universal Unique Addressing . . . . . . . . . . . . . 27
= A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . = 30 = A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 27
= A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . = 30 = A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 27
= A.3. Native Multicast Services . . . . . . . . . . . . . . . . = 31 = A.3. Native Multicast Services . . . . . . . . . . . . . . . . 28
= A.4. Increased Security Protection . . . . . . . . . . . . . . = 31 = A.4. Increased Security Protection . . . . . . . . . . . . . . 28
= A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . = 32 = A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 29
= A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . = 32 = A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 29
= A.7. Community of interest . . . . . . . . . . . . . . . . . . = 32 = A.7. Community of interest . . . . . . . . . . . . . . . . . . 29
= Appendix B. Revision history . . . . . . . . . . . . . . . . . . = 33 = Appendix B. Revision history . . . . . . . . . . . . . . . . . . 30
= B.1. Changes from *-vandevelde-v6ops-nap-00 to B.1. Changes from *-vandevelde-v6ops-nap-00 = to
= *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . = 33 = *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 30
= B.2. Changes from *-vandevelde-v6ops-nap-01 to B.2. Changes from *-vandevelde-v6ops-nap-01 = to
= *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . = 33 = *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 30
= B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . = 33 = B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 30
= B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . = 33 = B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 30
B.5. Changes from = *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 37 = Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . . 35
B.6. Changes from = *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38 = Intellectual Property and Copyright = Statements . . . . . . . . . . 36
= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . = 40
= Intellectual Property and Copyright Statements . . . . . . . . . . = 41
1. = Introduction 1. Introduction
= Although there are many perceived benefits to Network Address = Although there are many perceived benefits = to Network Address
= Translation (NAT), its primary benefit of "amplifying" = available Translation (NAT), its = primary benefit of "amplifying" available
= address space is not needed in IPv6. The serious disadvantages and = address space is not needed in IPv6. The serious disadvantages of
impact on applications = by ambiguous "private" address space and ambiguous "private" address space and of Network Address Translation
= Network Address Translation (NAT) [1] = [5] have been well documented = (NAT) [1][5] have been well documented = [4][6]. However, given its
= [4] [6] so there will not be much additional = discussion here. wide = market acceptance NAT undoubtedly has some perceived benefits.
= However, given its wide market acceptance NAT undoubtedly has = some Indeed, in an Internet model = based on universal any-to-any
= perceived benefits. Indeed, in an Internet model based on = universal connectivity, product = marketing departments have driven a perception
= any-to-any connectivity, product marketing departments have driven = a hat some connectivity and security concerns can = only be solved by
= perception that some connectivity and = security concerns can only be = using a NAT device or by using logically separated Local Area Network
= solved by using a NAT device or by using logically separated = address = (LAN) address spaces. This document describes the reasons for
= spaces. This document describes the goals for utilizing a NAT device = utilizing a NAT device in an IPv4 = environment that are regularly
= in an IPv4 environment that are regularly cited as solutions for cited in marketing = pronouncements. It then shows how these needs can
perceived problems. = It then shows how these needs can be met without be met without using NAT in an IPv6 network. Some of the IPv6
= using the header modification feature of = NAT in an IPv6 network. The solutions offer advantages beyond the equivalent = IPv4 NAT solution.
= use of the facilities from IPv6 described in this document avoids = the The use of the facilities from = IPv6 described in this document avoids
= negative impacts on applications of = address translation while meeting = the negative impacts of address translation.
or exceeding the comparable = IPv4+NAT equivlent goal.
= As far as security and privacy are = concerned, this document considers = As far as security and privacy is = concerned, this document considers
= how to mitigate a number of threats. Some are obviously = external, how to mitigate a number = of threats. Some are obviously external,
= such as having a hacker or a worm infected machine outside trying = to such as having a hacker trying to penetrate your network, or having a
= penetrate and attack the local network. Some are local such as = a worm infected machine outside = your network trying to attack it. Some
= disgruntled employee disrupting business operations, or the = are local such as a disgruntled employee = disrupting business
= unintentional negligence of a user downloading some malware = which operations, or the = unintentional negligence of a user downloading
= then proceeds to attack from within. = Some may be inherent in the some = malware which then proceeds to attack any device = on the LAN.
= device hardware ("embedded") such as having some firmware in = a Some may be inherent in the = device hardware ("embedded") such as
= domestic appliance "call home" to its manufacturer without the = user's having some firmware in a = domestic appliance "call home" to its
= consent. manufacturer without = the user's consent.
= =
= Another consideration discussed is the view = that NAT can be used to
fulfill the goals of a = security policy. At a technical level the
translation process = fundamentally can not produce security because
mangling the address in the = header does not fulfill any useful
security functions, it only = breaks the ability to track what is going
on. 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 = 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).
= This document describes several techniques that may be combined in an This = document describes several techniques that may be combined on an
= IPv6 deployment to protect the integrity = of its network architecture. IPv6 = site to protect the integrity of its = network architecture.
= It will focus on the 'how to acomplish a goal' = perspective, leaving These = techniques, known collectively as Network Architecture
most of the 'why that goal' = perspective for other documents. These Protection (NAP), retain the concept of a well = defined boundary
= techniques, known collectively as Network Architecture = Protection between "inside" and = "outside" the private network, and allow
= (NAP), retain the concept of a well defined boundary between = "inside" firewalling, topology = hiding, and privacy. NAP will achieve these
= and "outside" the private network, and allow firewalling, = topology security goals without = address translation whilst maintaining = any-to-
= hiding, and privacy. NAP will achieve these security goals = without = any connectivity.
= address translation whilst regaining the = ability for arbitrary any-
to-any = connectivity.
= IPv6 Network Architecture Protection can be summarized in the = IPv6 Network Architecture Protection can be = summarized in the
= following table. It presents the marketed "benefits" of IPv4+NAT = following table. It presents the marketed "benefits" of NAT with a
= with a cross-reference of how those are delivered in both the = IPv4 cross-reference of how those = are delivered in both the IPv4 and IPv6
= and IPv6 environments. = environments.
= Goal IPv4 = IPv6 benefit IPv4 = IPv6
= +------------------+-----------------------+-----------------------+ = +------------------+-----------------------+-----------------------+
= | Simple Gateway | DHCP - single | DHCP-PD - arbitrary = | | Simple Gateway | DHCP - = single | DHCP-PD - arbitrary |
= | as default router| address upstream | length customer = | | as default router| address = upstream | length customer |
= | and address pool | DHCP - limited | prefix upstream = | | and address pool | DHCP - = limited | prefix upstream |
= | manager | number of individual | SLAAC via RA = | | manager | number of = individual | SLAAC via RA |
= | | devices downstream | downstream = | | | devices = downstream | downstream |
= | | see section 2.1 | see section 4.1 = | | | see section = 2.1 | see section 4.1 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Simple Security | Filtering side | Explicit Context = | | Simple Security | Filtering = side | Explicit Context |
= | | effect due to lack | Based Access Control = | | | effect due = to lack | Based Access Control |
=
skipping to change at page 6, line 34 = skipping to change at = page 5, line 34
= | privacy | device ID bits in | privacy addresses = | | privacy | device ID = bits in | privacy addresses |
= | | the address | = | | | the address = | |
= | | see section 2.4 | see section 4.4 = | | | see section = 2.4 | see section 4.4 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Topology hiding | NAT transforms | Untraceable = addresses| | Topology hiding | = NAT transforms | Untraceable addresses|
= | | subnet bits in the | using IGP host = routes| | | = subnet bits in the | using IGP host routes|
= | | address | /or MIPv6 tunnels = for| | | address = | /or MIPv6 tunnels for|
= | | | stationary systems = | | | = | stationary systems |
= | | see section 2.4 | see section 4.4 = | | | see section = 2.4 | see section 4.4 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Addressing | RFC 1918 | RFC 3177 & 4193 | = | Addressing | RFC 1918 | RFC 3177 & ULA |
= | Autonomy | | = | | Autonomy | = | |
= | | see section 2.5 | see section 4.5 = | | | see section = 2.5 | see section 4.5 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Global Address | RFC 1918 | 18*10^18 subnets | | Global Address | RFC 1918 | 340,282,366,920,938, |
= | Pool | << 2^48 = application | 3.4*10^38 addresses = | | Pool | = | 463,463,374,607,431, = |
= | Conservation | end points = | unrestricted | = | Conservation | = | 768,211,456 |
= | | topology restricted = | | | = | | (3.4*10^38) addresses|
= | | see section 2.6 | see section 4.6 = | | | see section = 2.6 | see section 4.6 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Renumbering and | Address translation | Preferred lifetime = | | Renumbering and | Address = translation | Preferred lifetime |
= | Multi-homing | at border | per prefix & = Multiple| | Multi-homing | at = border | per prefix & Multiple|
= | | | addresses per = | | | = | addresses per |
= | | | interface = | | | = | interface |
= | | see section 2.7 | see section 4.7 = | | | see section = 2.7 | see section 4.7 |
= +------------------+-----------------------+-----------------------+ = +------------------+-----------------------+-----------------------+
=
= This document first identifies the perceived benefits of NAT in = more This document first identifies = the perceived benefits of NAT in more
= detail, and then shows how IPv6 NAP can provide each of them. = It detail, and then shows how IPv6 = NAP can provide each of them. It
= concludes with a IPv6 NAP case study and a gap analysis of work = that concludes with a IPv6 NAP case = study and a gap analysis of work that
= remains to be done for a complete NAP solution. remains to be done for a complete NAP = solution.
2. = Perceived Benefits of NAT and its Impact on IPv4 2. Perceived Benefits of NAT and its Impact on = IPv4
= This section provides insight into the generally perceived = benefits This section provides = insight into the generally perceived benefits
= of the use of IPv4 NAT which are frequently = reinforced by product of = the use of IPv4 NAT as extolled by product = marketing. The goal of
= marketing. The goal of this description is not to analyze = these this description is not to = analyze these benefits or discuss = the
= benefits or the accuracy of the perception (detailed discussions = in accuracy of the perception = (detailed discussions in [4]), but to
= [4]), but to describe the deployment requirements and set a = context describe the deployment = requirements and set a context for the later
= for the later descriptions of the IPv6 approaches for dealing = with descriptions of the IPv6 = approaches for dealing with those
= those requirements. = requirements.
2.1. Simple Gateway between Internet and Private = Network 2.1. Simple Gateway between = Internet and Private Network
= A NAT device can connect a private network with addresses allocated A NAT device can connect a private network with any = kind of address
from any part of the space = (ambiguous [RFC 1918] or global registered (ambiguous [RFC 1918] or global registered address) = towards the
= address) towards the Internet, though extra = effort is needed when the = Internet. The address space of the = private network can be built from
same range exists on both = sides of the NAT. The address space of the globally unique addresses, from ambiguous address = space or from both
= private network can be built from globally unique addresses, = from simultaneously. Without needing specific configuration, the NAT
= ambiguous address space or from both simultaneously. In the simple device enables access between the client side of a = distributed
case of private use = addresses, without needing specific configuration client-server application in the private network and = the server side
= the NAT device enables access between the client side of a = in the public Internet.
= distributed client-server application in the private network and = the
= server side located in the public = Internet.
= Wide-scale deployments have shown that using NAT to attach a = private Wide-scale deployments have = shown that using NAT to attach a private
= IPv4 network to the Internet is simple and practical for the = non- IPv4 network to the Internet = is simple and practical for the non-
= technical end user. Frequently a simple user interface, or even = a technical end user. Frequently a = simple user interface, or even a
= default configuration is sufficient for configuring both device = and default configuration is = sufficient for configuring both device and
= application access rights. = application access rights.
= This simplicity comes at a price as the = resulting topology puts
restrictions on applications. = The NAT simplicity works well when the
applications are limited to a = client/server model with the server
deployed on the public side = of the NAT. For peer-to-peer, multi-
party, or servers deployed on = the private side of the NAT, helper
technologies must be = available. These helper technologies are
frequently complex to develop = and manage, creating a hidden cost to
this 'simple = gateway'.
= =
= Additionally, thanks to successful marketing campaigns it is = Additionally, thanks to successful marketing = campaigns it is
= perceived by end users that by installing a NAT = as the gateway, their = perceived by end users that their equipment is protected from = the
= equipment is protected from the malicious entities and attackers = on malicious entities and = attackers on the public IPv4 Internet.
= the public IPv4 Internet.
2.2. Simple Security due to Stateful Filter = Implementation 2.2. Simple Security = due to Stateful Filter Implementation
A firewall doesn't fully secure a network, because 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.
A distributed security mechanism to protect the = end-systems may help
in the above situation; however, to deploy such a = system is quite
complex and may depend upon behaviour per operating = system and
release version. Also it will only be reliable if a = mechanism such
as 'trusted computing' is implemented in the = end-system; without this
enhancement administrators will be unwilling to = trust the behavior of
end-systems. As a result it will probably not be = available in the
next couple of years for end-user organizations. = End-system-only
security mechanisms do not protect the network = infrastructure from
being misused for transit, or against Distributed = Denial of Service
(DDOS) attacks against individual systems inside: = and this is the
area where a NAT device is perceived to provide some = protection.
=
= It is frequently believed that through its session-oriented = It is frequently believed that through its = session-oriented
= operation, NAT puts in an extra barrier to keep the private = network operation, NAT puts in an = extra barrier to keep the private network
= protected from outside influences. Since a NAT device = typically protected from outside = influences. Since a NAT device typically
= keeps state only for individual sessions, attackers, worms, = etc. keeps state only for = individual sessions, attackers, worms, etc.
= cannot exploit this state to attack a specific host on any other = cannot exploit this state to attack a host in = general and on any
port, though in the port = overload case of NAPT attacking all active port. This benefit = may be partially real, however, experienced
ports will impact a = potentially wide number of hosts. This benefit hackers are well aware of NAT devices and are very = familiar with
= may be partially real, however, experienced hackers are well aware = of private address space, and have = devised methods of attack (such as
= NAT devices and are very familiar with private address space, = and trojan horses) that readily = penetrate NAT boundaries. For these
= have devised methods of attack (such as trojan horses) that = readily reasons the sense of = security provided by NAT is actually an
= penetrate NAT boundaries. For these reasons the sense of = security illusion.
= provided by NAT is actually an illusion.
= The act of address translation does not = provide security in itself; Address translation does not provide security in = itself; for example,
= for example, consider a configuration with static NAT translation = and consider a configuration with = static NAT translation and all inbound
= all inbound ports translating to a single machine. In such a = ports translating to a single machine. In = such a scenario the
= scenario the security risk for that machine is identical to the = case security risk for that = machine is identical to the case with no NAT
= with no NAT device in the communication path. As result there is = no device in the communication = path. As result there is no specific
= specific security value in the address translation function. = The security value in the address = translation function. The perceived
= perceived security in this case comes = from the lack of pre- security comes from the lack of pre-established or permanent mapping
established or = permanent mapping state. Dynamically establishing state. Dynamically establishing state in response = to internal
= state in response to internal requests reduces the threat of = requests reduces the threat of unexpected = external connections to
= unexpected external connections to internal devices. This role, = internal devices.
marketed as a firewall, is = really an arbitrary artifact while a real
firewall has explicit = management controls.
= In some cases, NAT operators (including domestic users) may be = In some cases, NAT operators (including = domestic users) may be
= obliged to configure quite complex port mapping rules to allow = obliged to configure quite complex port = mapping rules to allow
= external access to local applications such as a multi-player game = or external access to local = applications such as a multi-player game or
= web servers. In this case the NAT actually adds management = web servers. In this case the NAT actually = adds management
= complexity compared to a simple router. In situations where two = or complexity compared to a simple = router. In situations where two or
= more devices need to host the same application or otherwise use the more devices need to host the same application this = complexity shifts
same public port this = complexity shifts from difficult to impossible. from difficult to impossible.
2.3. User/Application tracking 2.3. User/Application tracking
= One usage of NAT is for the local network = administrator to track user = Although NATs create temporary state for active sessions, in = general
and application = traffic. Although NATs create temporary state for = they provide limited capabilities for the = administrator of the NAT to
= active sessions, in general they provide limited capabilities for = the gather information about who = in the private network is requesting
= administrator of the NAT to gather information about who in = the access to which Internet = location. This could in theory be done = by
= private network is requesting access to which Internet = location. logging the network = address translation details of the private and
= This is done by periodically logging the network address = translation the public addresses = from the NAT device's state database.
= details of the private and the public addresses from the NAT = device's
= state database.
= The subsequent checking of this database = is not always a simple task, The = checking of this database is not always a simple task, = especially
= especially if Port Address Translation is used. It also has = an if Port Address Translation is = used. It also has an unstated
= unstated assumption that the administrative instance has a = mapping assumption that the = administrative instance has a mapping between an
= between a private IPv4-address and a = network element or user at all = IPv4-address and a network element or user at all times, or the
= times, or the administrator has a time-correlated list of the = administrator has a time-correlated list of = the address/port
= address/port mappings. = mappings.
2.4. Privacy and Topology Hiding 2.4. Privacy and Topology Hiding
= The goal of 'topology hiding' is to prevent external entities = from The goal of 'topology = hiding' is to provide devices on the = private
= making a correlation between the topological location of devices on network with an identifier = (IPv4 address) which an entity outside the
= the local network. The ability of NAT to provide Internet access = to network = can use to communicate with or to reference the private
= a large community of users by the use of a single (or a few) = global = network devices in protocols but prevents the external entity making
= IPv4 routable addresses offers a simple mechanism to hide the = a correlation between the topological = location of the private device
= internal topology of a network. In this scenario the large = community = and the address on the local network.
= will be represented in the Internet by a single (or a few) = IPv4 =
= address(es). The ability of NAT = to provide Internet access to a large community of
users by the use = of a single (or a few) global IPv4 routable
addresses offers = a simple mechanism to hide the internal topology of
a network. In = this scenario the large community will be represented
in the Internet = by a single (or a few) IPv4 address(es).
= The use of NAT then results in a user behind a NAT gateway = actually The use of NAT then = results in a user behind a NAT gateway actually
= appearing on the Internet as a user inside the NAT box itself; = i.e., appearing on the Internet as = a user inside the NAT box itself; i.e.,
= the IPv4 address that appears on the Internet is only sufficient = to the IPv4 address that appears on = the Internet is only sufficient to
= identify the NAT. When concealed behind a NAT it is impossible = to identify the NAT. When = concealed behind a NAT it is impossible to
= tell from the outside which member of a family, which customer of = an tell from the outside which = member of a family, which customer of an
= Internet cafe, or which employee of a company generated or received = a Internet cafe, or which employee = of a company generated or received a
= particular packet. Thus, although NATs do nothing to provide = particular packet. Thus, although NATs do = nothing to provide
= application level privacy, they do prevent the external tracking = and application level privacy, they = do prevent the external tracking and
= profiling of individual host computers by means of their IP = profiling of individual host computers by = means of their IP
= addresses, usually known as 'device profiling'. At the same time = a addresses, usually known as = 'device profiling'. At the same time a
= NAT creates a smaller pool of addresses for a much more focused = point NAT creates a smaller pool of = addresses for a much more focused point
= of attack, where the adversary does not need to = scan the entire of attack.
network. By periodically = scanning the limited 16 bit port range on
the public side of the NAT, = the attack will eventually find ports
that are open to active = nodes.
= There is a similarity with privacy based on application level = There is a similarity with privacy based on = application level
= proxies. When using an application level gateway for browsing = the proxies. When using an = application level gateway for browsing the
= web for example, the 'privacy' of a web user can be provided by = web for example, the 'privacy' of a web user = can be provided by
= masking the true identity of the original web user towards the = masking the true identity of the original = web user towards the
= outside world (although the details of what is - or is not - = logged outside world (although the = details of what is - or is not - logged
= at the NAT/proxy will be different). = at the NAT/proxy will be different).
= Some enterprises prefer to hide as much as possible of their = internal Some enterprises prefer to = hide as much as possible of their internal
= network topology from outsiders. Mostly this is achieved by = blocking network topology from = outsiders. Mostly this is achieved by blocking
=
skipping to change at page 10, line = 20 skipping to = change at page 9, line 26
= 80. Any vulnerable open ports could be used for initiating = attacks 80. Any vulnerable open = ports could be used for initiating attacks
= on an end system. on an end = system.
2.5. Independent Control of Addressing in a Private = Network 2.5. Independent Control of = Addressing in a Private Network
= Many private IPv4 networks take benefit from using the address = space Many private IPv4 networks = take benefit from using the address space
= defined in RFC 1918 to enlarge the available addressing space = for defined in RFC 1918 to enlarge = the available addressing space for
= their private network, and at the same time reduce their need = for their private network, and at = the same time reduce their need for
= globally routable addresses. This type of local control of = address globally routable = addresses. This type of local control of address
= resources allows a clean and hierarchical addressing structure in = the resources allows a clean and = hierarchical addressing structure in the
= local network. network.
= Another benefit is due to the usage of independent addresses on = Another benefit is due to the usage of = independent addresses on
= majority of the network infrastructure there is an increased = ability majority of the network = infrastructure there is an increased ability
= to change provider with less operational difficulties. to change provider with less operational = difficulties.
= Section 2.7 describes some disadvantages that appear if = independent Section 2.7 describes = some disadvantages that appear if independent
= networks using [RFC1918] addresses have to be merged. networks using [RFC1918] addresses have to be = merged.
2.6. Global Address Pool Conservation 2.6. Global Address Pool Conservation
= While the widespread use of IPv4+NAT has = reduced the potential Due to the ongoing depletion of the IPv4 address = range, the remaining
consumption rate, due = to the ongoing depletion of the IPv4 address pool of unallocated IPv4 addresses is below 30%. While mathematical
= range the remaining pool of unallocated = IPv4 addresses is already = models based on historical IPv4 prefix = consumption periodically
= below 25%. While mathematical models = based on historical IPv4 prefix = attempt to predict the future exhaustion date of the IPv4 = address
= consumption periodically attempt to predict the future = exhaustion pool, a direct result = of this continuous resource consumption is that
= date of the IPv4 address pool, a direct result of this = continuous the administrative = overhead for acquiring globally unique IPv4
= resource consumption is that the administrative overhead for = addresses will continue increasing in = direct response to tightening
= acquiring globally unique IPv4 addresses will continue increasing = in allocation policies. In = response to the increasing administrative
= direct response to tightening allocation policies. overhead many Internet Service Providers (ISPs) have = already resorted
= = to the ambiguous addresses = defined in RFC 1918 behind a NAT for the
= In response to the increasing administrative overhead many = Internet various services they = provide as well as connections for their end
= Service Providers (ISPs) have already resorted to the = ambiguous customers. This happens = even though that private address-space = is
= addresses defined in RFC 1918 behind a NAT for the various = services strictly limited in size. = In turn this has restricted the number = of
= they provide as well as connections for their end customers. = This and types of applications = that can be deployed by these ISPs and
= happens even though the private use address-space is strictly limited = their customers. Forced into this limiting situation = such customers
= in size. Some deployments have already = outgrown that space and have
begun cascading NAT to = continue expanding. Unfortunately, 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
result is something = substantially less than 2^48 possible active
application endpoints, rather = than the perception of arbitrary
utility one might expect from = the large number of addressable
devices. In addition it is = highly likely that nodes will become
confused because they are not = topology aware, though as already
mentioned NAT enforces = specific topologies on the application
deployment model. = Forced into this limiting situation such customers
= can rightly claim that despite the optimistic predictions of = can rightly claim that despite the = optimistic predictions of
= mathematical models the global pool of IPv4 addresses is = effectively mathematical models the = global pool of IPv4 addresses is effectively
= already exhausted, especially for larger enterprises. already exhausted, especially for larger = enterprises.
2.7. Multihoming and Renumbering with NAT = 2.7. Multihoming and Renumbering with = NAT
= Allowing a network to be multihomed and renumbering a network = are Allowing a network to be = multihomed and renumbering a network are
= quite different functions. However these are = argued together as quite = different functions. However, making a = network multihomed is
reasons for using NAT, = because making a network multihomed is often a often a transitional state required as part of = network renumbering,
= transitional state required as part of network renumbering, and = NAT and NAT interacts with both in = the same way.
= interacts with both in the same way.
= For enterprise networks, it is highly desirable to provide = resiliency For enterprise networks, = it is highly desirable to provide resiliency
= and load-balancing to be connected to more than one Internet = Service and load-balancing to be = connected to more than one Internet Service
= Provider (ISP) and to be able to change ISPs at will. This = means Provider (ISP) and to be able = to change ISPs at will. This means
= that a site must be able to operate under more than one CIDR = prefix that a site must be able to = operate under more than one CIDR prefix
= [14] and/or readily change its CIDR prefix. Unfortunately, IPv4 = was [14] and/or readily change its = CIDR prefix. Unfortunately, IPv4 was
= not designed to facilitate either of these maneuvers. However, if = a not designed to facilitate either = of these maneuvers. However, if a
= site is connected to its ISPs via NAT boxes, only those boxes need = to site is connected to its ISPs = via NAT boxes, only those boxes need to
= deal with multihoming and renumbering issues. deal with multihoming and renumbering issues.
=
skipping to change at page 12, line = 32 skipping to = change at page 11, line 25
= other information collectors to identify when addresses used in = other information collectors to identify = when addresses used in
= different transactions actually correspond to the same node. A = different transactions actually correspond = to the same node. A
= relatively short valid lifetime for the privacy address also has = the 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 side effect of reducing the = attack profile of a device, as it is not
= directly attackable once it stops answering at the temporary = use directly attackable once it = stops answering at the temporary use
= address. address.
= While the primary implementation and source of randomized RFC = 3041 While the primary = implementation and source of randomized RFC 3041
= addresses is expected to be from end-systems running stateless = addresses is expected to be from end-systems = running stateless
= autoconfiguration, there is nothing that prevents a DHCP server = from autoconfiguration, there is = nothing that prevents a DHCP server from
= running the RFC 3041 algorithm for any new IEEE identifier it hears = running the RFC 3041 algorithm for any new IEEE identifier it hears,
in a request, then = remembering that for future queries. This would then remembering that for future queries. This = would allow using
= allow using them in DNS for registered services since the = assumption them in DNS for = registered services since the assumption of a server
= of a DHCP server based deployment would = be a persistent value that based = deployment would be a persistent value that minimizes DNS
= minimizes DNS churn. A DHCP based deployment would also allow = for churn. A DHCP based = deployment would also allow for local policy to
= local policy to periodically change the entire collection of = end periodically change the entire = collection of end device addresses
= device addresses while maintaining some degree of central = knowledge while maintaining some = degree of central knowledge and control over
= and control over which addresses should be in use at any point = in which addresses should be in = use at any point in time.
= time.
= Randomizing the IID, as defined in RFC 3041, is = effectively a sparse = Randomizing the IID, as defined in RFC 3041, only precludes = tracking
allocation technique = which only precludes tracking of the lower 64 of the lower 64 bits of the IPv6 address. Masking = of the subnet ID
= bits of the IPv6 address. Masking of the subnet ID will = require will require additional = approaches as discussed below in 3.4.
= additional approaches as discussed below in 3.4. Additional = Additional considerations are discussed in = [17].
= considerations are discussed in [17].
3.2. Unique Local Addresses 3.2. Unique Local Addresses
= Acheiving the goal of autonomy is required for = local network and Local network and application services stability = during periods of
= application services stability during periods of intermittent = intermittent connectivity between one or = more providers requires
= connectivity between one or more providers. Such autonomy in a address management = autonomy. Such autonomy in a single routing
= single routing prefix environment would lead to massive expansion = of prefix environment would lead = to massive expansion of the global
= the global routing tables (as seen in = IPv4), so IPv6 provides for = routing tables, so IPv6 provides for = simultaneous use of multiple
= simultaneous use of multiple prefixes. The Unique Local = Address prefixes. The Unique = Local Address prefix (ULA) [13] has been set
= prefix (ULA) [13] has been set aside for use in local = communications. aside for use in = local communications. The ULA address prefix for
= The ULA address prefix for any network is routable over a = locally any network is routable = over a locally defined collection of routers.
= defined collection of routers. These prefixes are not intended to = be These prefixes are not intended = to be routed on the public global
= routed on the public global Internet as = large scale inter-domain Internet; large scale inter-domain distribution = of routes to ULA
= distribution of routes for ULA prefixes = would have a negative impact = prefixes would have a negative impact on global route = aggregation.
= on global route aggregation.
= ULAs have the following characteristics: ULAs have the following characteristics:
= o Globally unique prefix o = Globally unique prefix
= * Allows networks to be combined or privately = interconnected * Allows = networks to be combined or privately interconnected
= without creating address conflicts or requiring renumbering = of without creating any address conflicts or requiring = renumbering
= interfaces using these prefixes of interfaces using these prefixes
= * If accidentally leaked outside of a network via routing or = DNS, * If accidentally leaked = outside of a network via routing or DNS,
= it is highly unlikely that there will be a conflict with = any it is highly unlikely = that there will be a conflict with any
= other addresses other = addresses
= o ISP independent and can be used for communications inside of = a o ISP independent and can be = used for communications inside of a
= network without having any permanent or or = only intermittent = network without having any permanent or intermittent Internet
= Internet connectivity = connectivity
= o Well-known prefix to allow for easy filtering at network = o Well-known prefix to allow for easy = filtering at network
= boundaries preventing leakage of local routes and packets. = boundaries preventing leakage of local = routes and packets.
= o In practice, applications may treat these addresses like = global o In practice, applications = may treat these addresses like global
= scoped addresses but address selection algorithms may need to = scoped addresses but address selection algorithms need to
= distinguish between ULAs and ordinary global scope unicast = distinguish between ULAs and ordinary = global scope unicast
= addresses to assure stability. The policy = table defined in [10] = addresses. Mixing the two kinds of = addresses is likely to lead to
is one way to bias this = selection, by giving higher preference to undeliverable = packets.
FC00::/7 over = 2001::/3. Mixing the two kinds of addresses may
lead to undeliverable = packets during times of instability, but
that mixing is = not likely to happen when the rules of RFC 3484 are =
followed. =
3.3. DHCPv6 Prefix Delegation 3.3. DHCPv6 Prefix Delegation
= One of the functions of a simple gateway is = managing the local use The = Prefix Delegation (DHCP-PD) options [11] provide a mechanism for
address range. The = Prefix Delegation (DHCP-PD) options [11] provide automated delegation of IPv6 prefixes using the = Dynamic Host
= a mechanism for automated delegation of IPv6 prefixes using = the Configuration Protocol (DHCP) = [9]. This mechanism (DHCP-PD) is
= Dynamic Host Configuration Protocol (DHCP) [9]. This = mechanism intended for delegating = a long-lived prefix from a delegating router
= (DHCP-PD) is intended for delegating a long-lived prefix from = a (incorporating a DHCPv6 server) to a requesting = router, possibly
= delegating router (possibly = incorporating a DHCPv6 server) to a across an administrative boundary, where the = delegating router does
= requesting router, possibly across an administrative boundary, = where not require knowledge about = the topology of the links in the network
= the delegating router does not require knowledge about the = topology to which the prefixes = will be assigned.
= of the links in the network to which the prefixes will be = assigned.
3.4. Untraceable IPv6 Addresses 3.4. Untraceable IPv6 Addresses
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. This correlation could be = done by
generating IPv6 host route entries or by utilizing = an indirection
device such as a Mobile IPv6 Home = Agent.
=
= The main goal of untraceable IPv6 addresses is to create an = The main goal of untraceable IPv6 addresses = is to create an
= apparently amorphous network infrastructure as seen from = external apparently amorphous = network infrastructure as seen from external
= networks to protect the local infrastructure from malicious = outside networks to protect the = local infrastructure from malicious outside
= influences and from mapping of any correlation between the = network influences and from mapping = of any correlation between the network
= activities of multiple devices from external networks. When = using activities of multiple = devices from external networks. When using
= untraceable IPv6 addresses, it could be that two apparently = untraceable IPv6 addresses, it could be that = two apparently
= sequential addresses are allocated to devices on very different = parts sequential addresses are = allocated to devices on very different parts
= of the local network instead of belonging to devices adjacent to = each of the local network instead = of belonging to devices adjacent to each
= other on the same subnet. other on = the same subnet.
= 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.
= =
4. = Using IPv6 Technology to Provide the Market Perceived Benefits = of 4. Using IPv6 Technology to = Provide the Market Perceived Benefits of
= NAT NAT
= The facilities in IPv6 described in Section 3 can be used to = provide The facilities in IPv6 = described in Section 3 can be used to provide
= the protection perceived to be associated with IPv4 NAT. This = the protection perceived to be associated = with IPv4 NAT. This
= section gives some examples of how IPv6 can be used securely. = section gives some examples of how IPv6 can = be used securely.
4.1. Simple Gateway between Internet and Internal = Network 4.1. Simple Gateway between = Internet and Internal Network
= As a simple gateway, the device manages both packet routing and = local As a simple gateway, the = device manages both packet routing and local
= address management. A basic IPv6 router should have a default address management. A basic IPv6 router could have a default
= configuration to advertise inside the site a locally generated = random configuration to advertise = inside the site a locally generated random
= ULA prefix, independently from the state of any external = ULA prefix, independently from the state of = any external
= connectivity. This would allow local nodes to communicate = amongst connectivity. This would = allow local nodes to communicate amongst
= themselves independent of the state of a = global connection. If the = themselves prior to establishing a global = connection. If the network
= network happened to concatenate with another local network, the = happened to concatenate with another local network, this is highly
randomness in ULA = creation is highly unlikely to result in address = unlikely to result in address collisions. = A more secure network
= collisions. = environment can be established by having the referenced ULA = addresses
statically configured on the network devices as this = decreases the
dynamic aspects of the network, however the = operational overhead is
increased.
= With external connectivity the simple gateway should use DHCP-PD to With external connectivity the simple gateway could also use DHCP-PD
= acquire a routing prefix from the service provider for use = when to acquire a routing prefix = from the service provider for use when
= connecting to the global Internet. End-system connections = involving connecting to the global = Internet. End-system connections involving
= other nodes on the global Internet will always use the global = IPv6 other nodes on the global = Internet will always use the global IPv6
= addresses derived from this prefix delegation. It should be = noted addresses [9] derived from this prefix delegation. It = should be
= that the address selection policy table in end-systems defined in RFC noted that the address selection policy table in = end-systems needs to
3484 should be = configured to prefer the ULA prefix range = over the be correctly set up so that true global prefixes are = distinguished
= DHCP-PD prefix range when the goal is to keep local = communications from ULAs and will be used for the source address in preference when
stable during periods of = transient external connectivity. the destination is = not a ULA.
= In the very simple case there is no explicit routing protocol on In the = very simple case there is no explicit routing protocol and a
either side of the = gateway, and a single default route is used single default route is used out to the global = Internet. A slightly
= internally pointing out to the global = Internet. A slightly more more = complex case might involve local routing protocols, but with the
= complex case might involve local internal routing protocols, but with = entire local network sharing a common = global prefix there would still
= the entire local network sharing a common global prefix there = would not be a need for an = external routing protocol as a default = route
= still not be a need for an external routing protocol as the service = would continue to be consistent with the = connectivity.
provider could install = a route for the delegated prefix = pointing
toward the connecting link.
4.2. IPv6 and Simple Security 4.2. IPv6 and Simple Security
= The vulnerability of an IPv6 host is similar to that of an IPv4 = host The vulnerability of an IPv6 = host is similar to that of an IPv4 host
= directly connected towards the Internet. The use of firewall = and directly connected towards the = Internet. The use of firewall and
= Intrusion Detection Systems (IDS) is recommended for those that want = Intrusion Detection Systems (IDS) is recommended. A proxy may be
boundary protection in = addition to host defences. A proxy may be
= used for certain applications, but with the caveat that the end = to used for certain applications, = but with the caveat that the end to
= end transparency is broken. However, = with IPv6, the following end = transparancy is broken. However, with = IPv6, the following
= protections are available without the use of NAT while = maintaining protections are = available without the use of NAT while maintaining
= end-to-end reachability: end-to-end = reachability:
= 1. Short lifetimes on privacy extension suffixes reduce the = attack 1. Short lifetimes on = privacy extension suffixes reduce the attack
= profile since the node will not respond to the address once its = profile since the node will not respond to the address once the
lifetime becomes = invalid. address is no longer valid.
= 2. IPsec is a mandatory service for IPv6 implementations. = IPsec 2. IPsec is a mandatory = service for IPv6 implementations. IPsec
= functions to prevent session hijacking, prevent content = functions to prevent session hijacking, = prevent content
= tampering, and optionally masks the packet contents. While = IPsec tampering, and optionally = masks the packet contents. While IPsec
= works the same way and might be = available in IPv4 might be = available in IPv4 implementations, deployment in NAT
= implementations, deployment in NAT environments either breaks = the environments either breaks = the protocol or requires complex
= protocol or requires complex helper services with limited = helper services with limited = functionality or efficiency.
= functionality or efficiency.
= 3. The size of the address space of a typical subnet (64 bits = of 3. The size of the address = space of a typical subnet (64 bits of
= IID) will make a complete subnet = ping sweep virtually impossible = IID) will make an effective network ping = sweep and resulting
= due to the number of possible combinations available. Reducing port-scan = virtually impossible due to the number of possible
the security threat of = port scans on identified nodes requires combinations available, = provided that IIDs are essentially
sparse distribution = within the subnet to minimize the list of randomly distributed across the available space. This protection
known nodes. = Provided that IIDs are essentially randomly is nullified if = the attacker has no access to a local = connection.
= distributed across the available space, = address scanning based = If an attacker has local access then he could use ND [3] and
attacks will fail. = This protection exists if the attacker = has no ping6 to ff02::1 to = detect local neighbors. (Of course, a
= direct access to the specific subnet. If an attacker has = local
= access then he could use ND [3] and ping6 to the link-scope
multicast ff02::1 = to detect local neighbors. (Of course, a
= locally connected attacker has many scanning options with IPv4 = as locally connected attacker = has many scanning options with IPv4 as
= well.) This scanning protection = will also be nullified if IIDs = well.) It is recommended for site administrators = to take [18]
= are configured in a group near the start of the IID = space. = into consideration to achieve the expected goal. This = protection
= = will also be nullified if = IIDs are configured in a group near the
= Assuming the network administrator is aware of = [18]the increased size = start of the IID space.
of the IPv6 address will make = topology probing much harder, and
almost impossible for IPv6 = devices. The intention of topology
probing is to identify a = selection of the available hosts inside an
enterprise. This mostly = starts with a ping-sweep. Since the IPv6
subnets are 64 bits worth of = address space, this means that an
attacker has to send out a = simply unrealistic number of pings to map
the network, and virus/worm = propagation will be thwarted in the
process. At full rate 40Gbps = (400 times the typical 100Mbps LAN, and
13,000 times the typical = DSL/Cable access link) it takes over 5000
years to scan a single 64 bit = space.
= IPv4 NAT was not developed as a security mechanism. Despite = IPv4 NAT was not developed as a security = mechanism. Despite
= marketing messages to the contrary it is not a security = mechanism, marketing messages to = the contrary it is not a security mechanism,
= and hence it will offer some security holes while many people = assume 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 their network is secure due to = the usage of NAT. IPv6 security best
= practices will avoid this kind of illusory security but can = only practices will avoid this = kind of illusory security but can only do
= address the same threats if correctly = configured firewalls and IDS this if correctly configured firewalls and = IDS systems are used at
= systems are used at the perimeter where some IPv4 networks = have the perimeter where some IPv4 = networks have relied on NATs.
= relied on NATs.
= =
= 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.
= To implement simple security for IPv6 in, for example, a DSL = To implement simple security for IPv6 in, = for example, a DSL
= connected home network, the DSL broadband gateway/router should = be connected home network, the DSL = broadband gateway/router should be
= equipped with stateful firewall capabilities. These should provide = a equipped with stateful firewall = capabilities. These should provide a
= default configuration where incoming = traffic is limited to return = default configuration which provides a minimum set of = connectivity
= traffic resulting from outgoing packets (sometimes known as = for users in the = home network (e.g., just to external HTTP servers)
= reflective session state). There should also = be an easy interface with incoming traffic limited to return = traffic resulting from
= which allows users to create inbound = 'pinholes' for specific purposes = outgoing packets (sometimes known as = reflective session state) with
such as online-gaming. = Another consideration would be the capability an easy interface which allows users to create additional 'pinholes'
for service provider mediated = pinhole management where things like for specific purposes.
voice call signalling could = dynamically establish pinholes based on
predefined = rules.
= Administrators and the designers of configuration interfaces = for Administrators and the = designers of configuration interfaces for
= simple IPv6 Firewalls need to provide a means of documenting = the simple IPv6 Firewalls need to = provide a means of documenting the
= security caveats that arise from a given set configuration rules = so security caveats that arise from = a given set configuration rules so
= that users (who are normally oblivious to such things) can be = made that users (who are normally = oblivious to such things) can be made
= aware of the risks. As rules are improved iteratively, the goal = will aware of the risks. As rules = are improved iteratively, the goal will
= be to make use of the IPv6 Internet more secure for oblivious = users. be to make use of the IPv6 = Internet more secure for oblivious users.
Assuming the network administrator is aware of [18] the = increased
size of the IPv6 address will make topology probing = much harder, and
almost impossible for IPv6 devices. The intention = of topology
probing is to identify a selection of the available = hosts inside an
enterprise. This mostly starts with a ping-sweep. = Since the IPv6
subnets are 64 bits worth of address space, this = means that an
attacker has to send out a simply unrealistic number = of pings to map
the network, and virus/worm propagation will be = thwarted in the
process. At full rate 40Gbps (400 times the typical = 100Mbps LAN, and
13,000 times the typical DSL/Cable access link) it = takes over 5000
years to scan a single 64 bit space.
=
4.3. User/Application Tracking 4.3. User/Application Tracking
= IPv6 enables the collection of information about data flows. Due = to IPv6 enables the collection of = information about data flows. Due to
= the fact that all addresses used for Internet and = intra-/inter-site the fact that all = addresses used for Internet and intra-/inter-site
= communication are unique, it is possible for an enterprise or ISP = to communication are unique, it is = possible for an enterprise or ISP to
= get very detailed information on any communication exchange = between get very detailed = information on any communication exchange between
= two or more devices. This enhances the capability of data-flow = two or more devices. This enhances the = capability of data-flow
= tracking for security audits compared with IPv4 NAT, because in = IPv6 tracking for security audits = compared with IPv4 NAT, because in IPv6
= a flow between a sender and receiver will always be uniquely = a flow between a sender and receiver will = always be uniquely
= identified due to the unique IPv6 source and destination = addresses. identified due to the = unique IPv6 source and destination addresses.
= At the same time, this tracking is per address. = In environments
where the goal is tracking = back to the user, additional external
information will be necessary = coorelating a user with an address. In
the case of short lifetime = privacy address usage, this external
information will need to be = based on more stable information such as
the layer 2 media = address.
= =
4.4. Privacy and Topology Hiding using IPv6 = 4.4. Privacy and Topology Hiding using = IPv6
= Partial host privacy is achieved in IPv6 using pseudo-random = privacy Partial host privacy is = achieved in IPv6 using pseudo-random privacy
= addresses [RFC 3041] which are generated as required, so that a = addresses [RFC 3041] which are generated as = required, so that a
= session can use an address that is valid only for a limited = time. session can use an address = that is valid only for a limited time.
= This only allows such a session to be = traced back to the subnet that = Exactly as with IPv4 NAT, this only allows = such a session to be
= originates it, but not immediately to the actual host, where IPv4 NAT traced back to the subnet that originates it, but = not immediately to
is only tracable to the most = public NAT interface. the = actual host.
= Due to the large IPv6 address space available there is plenty = of Due to the large IPv6 address = space available there is plenty of
= freedom to randomize subnet allocations. By doing this, it is = freedom to randomize subnet allocations. By = doing this, it is
= possible to reduce the correlation between a subnet and its = location. possible to reduce the = correlation between a subnet and its location.
= When doing both subnet and IID randomization [RFC 3041] a = casual When doing both subnet and = IID randomization [RFC 3041] a casual
= snooper won't be able to deduce much about the networks = topology. snooper won't be able to = deduce much about the networks topology.
= The obtaining of a single address will tell the snooper very = little The obtaining of a single = address will tell the snooper very little
= about other addresses. This is different from IPv4 where = address about other addresses. = This is different from IPv4 where address
= space limitations cause this to be not true. In most usage = cases space limitations cause this = to be not true. In most usage cases
= this concept should be sufficient for address privacy and = topology this concept should be = sufficient for address privacy and topology
= hiding, with the cost being a more complex = internal routing hiding.
= configuration.
= In the case where a network administrator wishes to fully isolate the = In the case where a network administrator wishes to fully conceal the
= internal IPv6 topology, and the majority of its host computer = internal IPv6 topology, and the majority of = its host computer
= addresses, a possible option is to run all internal traffic = using addresses, a possible option = is to run all internal traffic using
= Unique Local Addresses (ULA) since by definition external traffic Unique Local Addresses (ULA) since such packets can by definition
will never reach the site. For the = set of hosts that do in fact need never exit the site. = For hosts that do in fact need to generate
= to interact externally, by using = multiple IPv6 addresses (ULAs and external traffic, by = using multiple IPv6 addresses (ULAs and one or
= one or more global addresses), it will be possible to hide and = mask more global addresses), it = will be possible to hide and mask some or
= some or all of the internal network. As discussed in Section = 3.1, all of the internal network. = As discussed in Section 3.1, there are
= there are multiple parts to the IPv6 address, and different = multiple parts to the IPv6 address, and = different techniques to
= techniques to manage privacy for each which may = be combined to manage = privacy for each.
protect the entire = address.
= There are other possible scenarios for = the extreme situation when a There = are two possible scenarios for the extreme = situation when a
= network manager also wishes to fully conceal the internal IPv6 = network manager also wishes to fully conceal = the internal IPv6
= topology. In these cases the goal in replacing = the IPv4 NAT approach = topology.
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 o One could use = explicit host routes and remove the correlation
= between location and IPv6 address. In the = figure below the hosts = between location and IPv6 address. This solution does however
would be allocated = prefixes from one or more logical subnets, and show severe scalability issues.
would inject host routes = to internally identify their real o The other = technology to fully hide the internal topology would be
attachment point. = This solution does however show severe to use a tunneling mechanism. Mobile IPv6 = without route
= scalability issues and should be limited to = uses with optimization = is one example. In this example the public facing
substantially fewer than = the maximum number of routes that the IGP addresses are indirected via an edge Home Agent (HA). This
can support (generally = about 50,000). = indirection method truly masks the internal topology as all = nodes
= o Another technology to fully hide the = internal topology would be to = with global access appear to share a common = prefix. The downside
= use a tunneling mechanism. Mobile IPv6 without route = optimization of using this = method is that it makes usage of middleware like a
= is one example. In this example the public facing addresses = are Home Agent (HA).
= indirected via the edge Home Agent = (HA). This indirection method
= truly masks the internal topology as all nodes with global = access
= appear to share the prefix of one or more = logical subnets attached
to the HA. While turning = off all binding updates would appear to
be necessary to prevent = leakage of topology information, that
approach would also force = all internal traffic to route via the HA
tunnel. A better method = would be to allow internal route
optimizations while = dropping outbound binding updates at the
firewall. The = downsides of using this tunneling method is that it
= makes usage of middleware like a Home Agent (HA) and consumes
slightly more bandwidth = for the tunnel overhead.
o Another method where the = layer 2 topology allows would be to use a
virtual lan approach to = logically attach the devices to one or
more subnets on the edge = router. The downsides of this approach
is that all internal = traffic would be directed over sub-optimal
paths via the edge router, = as well as the complexity of managing a
distributed logical = lan.
= Internet
= |
= \
= |
= +------------------+
| Simple = Gateway | Logical subnet
| or Home = Agent |-+-+-+-+-+-+-+-+--
= +------------------+ for topology
= | hidden nodes
= |
Real internal = -------------+-
topology | = |
| = -+----------
= -----------+--------+
= |
4.5. Independent Control of Addressing in a Private = Network 4.5. Independent Control of = Addressing in a Private Network
= IPv6 provides for autonomy in local use addresses through ULAs. = At IPv6 provides for autonomy in = local use addresses through ULAs. At
= the same time IPv6 simplifies simultaneous use of multiple = addresses the same time IPv6 = simplifies simultaneous use of multiple addresses
= per interface so that an IPv6 NAT is not required between the ULA = and per interface so that an IPv6 = NAT is not required between the ULA and
= the public Internet because nodes that = need access to the public the = public Internet. Nodes that need access = to the public Internet
= Internet will have a global use address as = well. When using IPv6, = may have a ULA for local use, and will = have a global use address
= the need to ask for more address space = will become far less likely = because the = global use IPv6 address space is not a scarce resource
due to the increased size of = the subnets, along with an allocation like the global use IPv4 = space. While global IPv6 allocation policy
policy that recognizes table = fragmentation is also an = important is managed = through the Regional Internet Registries, it is expected
consideration. While = global IPv6 allocation policy is managed that they will continue with derivatives of [RFC 3177] for the
= through the Regional Internet Registries, it is expected that = they foreseeable future.
= will continue with derivatives of [8] = for the foreseeable future so =
= the number of subnet prefixes available to an organization should not When using IPv6, the = need to ask for more address space will = become
be a limitation which would = create an artifical demand for NAT. far less likely due to the = increased size of the subnets. = These
subnets typically allow 2^64 addresses per = subnet and an enterprise
will typically receive a /48 which allows = segmentation into at least
2^16 different subnets.
= The ongoing subnet size maintenance may become simpler when = IPv6 The ongoing subnet size = maintenance may become simpler when IPv6
= technology is utilised. Under IPv4 = address space policy technology is utilised. If IPv4 address space is optimised one has
restrictions, each subnet = must be optimised so one has to = look to look periodically into the = number of hosts on a segment and the
= periodically into the number of hosts on a segment and the = subnet subnet size allocated to = the segment; an enterprise today may have = a
= size allocated to the segment and rebalance. = For example an mix of /28 - = /23 size subnets for example, and may = shrink/grow these
= enterprise today may have a mix of /28 - /23 size subnets, and may as their network user base changes. For IPv6 all = subnets have /64
= shrink/grow these as their network user base changes. For IPv6 = all prefixes.
= subnets have /64 prefixes which will reduce the = operational and
configuration = overhead.
4.6. Global Address Pool Conservation 4.6. Global Address Pool Conservation
= IPv6 provides sufficient space to completely avoid the need for = IPv6 provides sufficient space to completely = avoid the need for
= overlapping address space with the total = possible addresses being overlapping address space,
= 340,282,366,920,938,463,463,374,607,431,768,211,456 = (3.4*10^38). 340,282,366,920,938,463,463,374,607,431,768,211,456 = (3.4*10^38) total
Since allocations in IPv6 are = based on subnets rather than hosts a possible addresses. = As previously discussed, the serious
more reasonable way to look = at the pool is that there are about disadvantages of ambiguous address space have been = well documented,
17,293,822,569,102,704,640 = (17*10^18) unique subnet values where and with sufficient space there is no need to = continue the
sparse allocation practice = within those provdes for new opportunities increasingly aggressive conservation practices that = are necessary
such as . As = previously discussed, the serious disadvantages of with IPv4. While IPv6 allocation policies and ISP = business practice
= ambiguous address space have been well documented, and with = will continue to evolve, the = recommendations in RFC 3177 are based on
= sufficient space there is no need to continue the = increasingly the technical = potential of the vast IPv6 address space. That
= aggressive conservation practices that are necessary with = IPv4. document demonstrates that = there is no resource limitation which will
= While IPv6 allocation policies and ISP business practice will = require the adoption of the IPv4 workaround = of ambiguous space behind
= continue to evolve, the recommendations in RFC 3177 are based on = the a NAT. As an example of the = direct contrast, many expansion oriented
= technical potential of the vast IPv6 address space. That = document IPv6 deployment scenarios = result in multiple IPv6 addresses per
= demonstrates that there is no resource limitation which will = require device, as opposed to the = constriction of IPv4 scenarios where
= the adoption of the IPv4 workaround of ambiguous space behind a = NAT. multiple devices are forced = to share a scarce global address.
= As an example of the direct contrast, many expansion oriented = IPv6
= deployment scenarios result in multiple IPv6 addresses per device, = as
= opposed to the constriction of IPv4 scenarios where multiple = devices
= are forced to share a scarce global address = through a NAT.
4.7. Multihoming and Renumbering 4.7. Multihoming and Renumbering
= Multihoming and renumbering remain technically challenging with = IPv6 Multihoming and renumbering = remain technically challenging with IPv6
= (see the Gap Analysis below). However, IPv6 was designed to = allow (see the Gap Analysis below). = However, IPv6 was designed to allow
= sites and hosts to run with several simultaneous CIDR allocated sites and hosts to run with several simultaneous = CIDR-like prefixes
prefixes, and thus = with several simultaneous ISPs. An address and thus with several simultaneous ISPs. An address = selection
= selection mechanism [10] is specified so that hosts will = behave mechanism [10] is specified = so that hosts will behave consistently
= consistently when several addresses are simultaneously valid. = The when several addresses are = simultaneously valid. The fundamental
= fundamental difficulty that IPv4 has in regard to multiple addresses difficulty that IPv4 has in this regard therefore does not apply to
= therefore does not apply to IPv6. IPv6 sites can and do run = today IPv6. IPv6 sites can and do = run today with multiple ISPs active, and
= with multiple ISPs active, and the processes for adding and = removing the processes for adding = and removing active prefixes at a site have
= active prefixes at a site have been documented in [12] and [19]. been documented [12] and [19].
= The IPv6 address space allocated by the ISP will be dependent = upon The IPv6 address space = allocated by the ISP will be dependent upon
= the connecting Service provider. This will = likely result in a the = connecting Service provider. This may = result in a renumbering
= renumbering effort when the network = changes between service effort if the network = changes from Service Provider. When = changing
providers. When = changing ISPs or ISPs readjusting their addressing ISPs or ISPs readjusting their addressing pool, = DHCP-PD [11] can be
= pool, DHCP-PD [11] can be used as an almost zero-touch = external used as an almost = zero-touch external mechanism for prefix change in
= mechanism for prefix change in conjunction with a ULA prefix = for conjunction with a ULA prefix = for internal connection stability.
= internal connection stability. With appropriate management of = the With appropriate management of = the lifetime values and overlap of the
= lifetime values and overlap of the external prefixes, a smooth make- = external prefixes, a smooth make-before-break transition is possible
before-break = transition is possible as existing communications will as existing communications will continue on the old = prefix as long as
= continue on the old prefix as long as it remains valid, while any = new it remains valid, while any = new communications will use the new
= communications will use the new prefix. prefix.
5. = Case Studies 5. Case Studies
= In presenting these case studies we have chosen to consider = In presenting these case studies we have = chosen to consider
= categories of network divided first according to their function = categories of network divided first = according to their function
= either as carrier/ISP networks or end user (such as enterprise) = either as carrier/ISP networks or end user = (such as enterprise)
= networks with the latter category broken down according to the = number networks with the latter = category broken down according to the number
= of connected end hosts. For each category of networks we can = use of connected end hosts. For = each of these category of networks = we
= IPv6 Network Architecture Protection to achieve a secure and = flexible can use IPv6 Network = Architecture Protection to achieve a secure and
= infrastructure, which provides an enhanced network functionality = in flexible infrastructure, which = provides an enhanced network
= comparison with the usage of address translation. functionality in comparison with the usage of = address translation.
= o Medium/Large Private Networks (typically >10 connections) = o Medium/Large Private Networks (typically = >10 connections)
= o Small Private Networks (typically 1 to 10 connections) = o Small Private Networks (typically 1 to 10 = connections)
= o Single User Connection (typically 1 connection) o Single User Connection (typically 1 = connection)
= o ISP/Carrier Customer Networks o = ISP/Carrier Customer Networks
5.1. Medium/large private networks 5.1. Medium/large private networks
= The majority of private enterprise networks fall into this = category. The majority of private = enterprise networks fall into this category.
= Many of these networks have one or more exit points to the = Internet. Many of these networks = have one or more exit points to the Internet.
= Though these organizations have sufficient resources to acquire = Though these organizations have sufficient = resources to acquire
= addressing independence when using IPv4 there are several reasons = why 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 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- = no need to import the IPv4 address range = from the remote end-
= customer, which facilitates IPv4 route summarization. The = customer customer, which = facilitates IPv4 route summarization. The customer
= can use a larger IPv4 address range (probably with less- = can use a larger IPv4 address range = (probably with less-
= administrative overhead) by the use of RFC 1918 and NAT. The = administrative overhead) by the use of RFC = 1918 and NAT. The
= customer also reduces the overhead in changing to a new ISP, = because 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 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 changed when the customer is = assigned a different address by a new
= ISP. By using address translation in = IPv4 one avoids the expensive = ISP. By using address translation one avoids the need for network
process of network = renumbering. Finally, the customer can provide renumbering. Finally, the customer can provide = privacy for its hosts
= privacy for its hosts and the topology of its internal network if = the and the topology of its = internal network if the internal addresses
= internal addresses are mapped through NAT. are mapped through NAT.
= It is expected that there will be enough IPv6 addresses available = for It is expected that there will = be enough IPv6 addresses available for
= all networks and appliances for the foreseeable future. The = basic all networks and appliances = for the foreseeable future. The basic
= IPv6 address range an ISP allocates for a private network is = large IPv6 address range an ISP = allocates for a private network is large
= enough (currently /48) for most of the medium and large = enterprises, enough (currently /48) = for most of the medium and large enterprises,
= while for the very large private enterprise networks = address-ranges while for the very = large private enterprise networks address-ranges
= can be concatenated. The goal of this assignment mechanism is = to can be concatenated. A single /48 allocation provides an = enterprise
= decrease the total amount of entries in the public Internet routing network with 65536 different = /64 prefixes.
= table. A single /48 allocation provides = an enterprise network with =
65536 different /64 subnet = prefixes. The summarization benefit for the ISP results from = the IPv6
allocation rules. This means that the ISP will = provide the
enterprise with an IPv6 address-range (typically one = or multiple
range(s) of '/48') from its RIR assigned IPv6 = address-space. The
goal of this = assignment mechanism is to decrease the total amount of
entries in the = internet routing table. If the ISP adopts appropriate
policies there is high probability that an = enterprise requiring
additional space could acquire an adjacent address = block.
= To mask the identity of a user on a network of this type, the = usage To mask the identity of a = user on a network of this type, the usage
= of IPv6 privacy extensions may be advised. This technique is = useful of IPv6 privacy extensions = may be advised. This technique is useful
= when an external element wants to track and collect all = information when an external = element wants to track and collect all information
= sent and received by a certain host with known IPv6 address. = Privacy sent and received by a = certain host with known IPv6 address. Privacy
= extensions add a random time-limited = factor to the host part of an = extensions add a random factor to the host part of an IPv6 = address
= IPv6 address and will make it very hard for an external element = to and will make it very hard for = an external element to keep
= keep correlating the IPv6 address to a specific host on the inside correlating the IPv6 address to a host on the inside = network. The
= network. The usage of IPv6 privacy extensions does not mask = the usage of IPv6 privacy = extensions does not mask the internal network
= internal network structure of an enterprise network. structure of an enterprise network.
= If there is need to mask the internal structure towards the = external If there is need to mask = the internal structure towards the external
= IPv6 Internet, then some form of = 'untraceable' addresses may be used. = IPv6 internet, then some form of = 'untraceable' addresses may be used.
= These addresses will be derived from a local pool, and may be = These addresses will be derived from a local = pool, and may be
= assigned to those hosts for which topology masking is required = or assigned to those hosts for = which topology masking is required or
= which want to reach the IPv6 Internet or other external = networks. which want to reach the = IPv6 Internet or other external networks.
= The technology to assign these addresses to the hosts could be = based The technology to assign = these addresses to the hosts could be based
= on DHCPv6 or static configuration. To = complement the 'Untraceable' on = DHCPv6. To complement the 'Untraceable' = addresses it is needed to
= addresses it is needed to have at least awareness of the IPv6 = address have at least awareness of = the IPv6 address location when routing an
= location when routing an IPv6 packet through the internal = network. IPv6 packet through the = internal network. This could be achieved by
= This could be achieved by 'route-injection' in the local network 'route-injection' in the network infrastructure. = This route-
= infrastructure. This route-injection = could be done based on /128 injection could be done based on /128 = host-routes to each device that
= host-routes to each device that wants to connect to the = Internet wants to connect to the = Internet using an untraceable address. This
= using an untraceable address. This will provide the most = dynamic will provide the most = dynamic masking, but will have a scalability
= masking, but will have a scalability limitation, as an IGP is = limitation, as an IGP is typically not = designed to carry many
= typically not designed to carry many thousands of IPv6 prefixes. = A thousands of IPv6 prefixes. A = large enterprise may have thousands of
= large enterprise may have thousands of hosts willing to connect = to hosts willing to connect to the = Internet. Less flexible masking
= the Internet. could be to have = time-based IPv6 prefixes per link or subnet. This
= = may = reduce the amount of route entries in the IGP = by a significant
= An alternative for larger deployments is = to leverage the tunneling factor, but has as = trade-off that masking is time and subnet based.
aspect of MIPv6 even for non-mobile devices. With the = logical subnet
being allocated as = attached to the edge Home Agent, the = real
attachment and internal = topology are masked from the outside.
Dropping outbound binding = updates at the firewall is also = necessary
to avoid leaking the = attachment information.
= Less flexible masking could be to have = time-based IPv6 prefixes per = The dynamic allocation of 'Untraceable' = addresses can also limit the
link or subnet. This may = reduce the amount of route entries in the IPv6 access between local and external hosts to = those local hosts
IGP by a significant factor, = but has as trade-off that masking is being authorized for this capability. Dynamically = allocated
time and subnet = based.The dynamic allocation of 'Untraceable' 'Untraceable' addresses may also facilitate and = simplify the
= addresses can also limit the IPv6 access between local and = external connectivity to the = outside networks during renumbering, because the
= hosts to those local hosts being authorized for this = capability. existing IPv6 central = address pool could be swapped for the newly
= Dynamically allocated 'Untraceable' addresses may also facilitate = and allocated IPv6 address = pool.
= simplify the connectivity to the outside networks during = renumbering,
= because the existing IPv6 central address pool could be swapped = for
= the newly allocated IPv6 address pool.
= The use of permanent ULA addresses on a site provides the = benefit The use of permanent ULA = addresses on a site provides the benefit
= that even if an enterprise would change its ISP, the renumbering = will that even if an enterprise = would change its ISP, the renumbering will
= only affect those devices that have a wish to connect beyond = the only affect those devices that = have a wish to connect beyond the
= site. Internal servers and services would not change their = allocated site. Internal servers = and services would not change their allocated
= IPv6 ULA address, and the service would remain available even = during IPv6 ULA address, and the = service would remain available even during
= global address renumbering. global = address renumbering.
5.2. Small Private Networks 5.2. Small Private Networks
=
skipping to change at page 23, line = 37 skipping to = change at page 20, line 40
= blocks, or IPv4 prefixes that are static over time, due to the = larger blocks, or IPv4 prefixes = that are static over time, due to the larger
= public address pool each of those requires. public address pool each of those requires.
= As a direct response to explicit charges per public address most = of As a direct response to explicit = charges per public address most of
= this category has deployed NAPT (port demultiplexing NAT) to = minimize this category has deployed = NAPT (port demultiplexing NAT) to minimize
= the number of addresses in use. Unfortunately this also limits = the the number of addresses in use. = Unfortunately this also limits the
= Internet capability of the equipment to being mainly a receiver = of Internet capability of the = equipment to being mainly a receiver of
= Internet data (client), and makes it quite hard for the equipment = to Internet data (client), and = makes it quite hard for the equipment to
= become a world wide Internet server (i.e. HTTP, FTP, etc.) due = to become a world wide Internet = server (i.e. HTTP, FTP, etc.) due to
= the stateful operation of the NAT equipment. Even when there = is the stateful operation of the = NAT equipment. Even when there is
= sufficient technical knowledge to manage the NAT to enable external = sufficient technical knowledge to manage the NAT to enable a = server,
access to a server, = only one server can be mapped per = protocol/port only one = server of any given protocol type is = possible per address,
number per address, = and then only when the address from the ISP is and then only when the address from the ISP is = public.
= public. When there is an upstream NAT = providing private address
space to the ISP side of the = private NAT, additional negotiation with
the ISP will be necessary to = provide an inbound mapping, if that is
even = possible.
= When deploying IPv6 NAP in this environment, there are two = approaches When deploying IPv6 NAP = in this environment, there are two approaches
= possible with respect to IPv6 addressing. possible with respect to IPv6 addressing.
= o DHCPv6 Prefix-Delegation o = DHCPv6 Prefix-Delegation
= o ISP provides a static IPv6 address-range o ISP provides a static IPv6 address-range
= For the DHCPv6-PD solution, a dynamic address allocation approach = is For the DHCPv6-PD solution, a = dynamic address allocation approach is
= chosen. By means of the enhanced DHCPv6 protocol it is possible = to chosen. By means of the = enhanced DHCPv6 protocol it is possible to
= have the ISP push down an IPv6 prefix range automatically towards = the have the ISP push down an IPv6 = prefix range automatically towards the
= small private network and populate all interfaces in that small = small private network and populate all = interfaces in that small
=
skipping to change at page 24, line = 30 skipping to = change at page 21, line 29
= While a full prefix is expected to be the primary deployment = model While a full prefix is = expected to be the primary deployment model
= there may be cases where the ISP provides a single IPv6 address = for there may be cases where the = ISP provides a single IPv6 address for
= use on a single piece of equipment (PC, PDA, etc.). This is = expected use on a single piece of = equipment (PC, PDA, etc.). This is expected
= to be rare though, because in the IPv6 world the assumption is = that to be rare though, because in = the IPv6 world the assumption is that
= there is an unrestricted availability of a large amount of = globally there is an unrestricted = availability of a large amount of globally
= routable and unique address space. If scarcity was the = motivation routable and unique = address space. If scarcity was the motivation
= with IPv4 to provide RFC 1918 addresses, in this environment the = ISP with IPv4 to provide RFC 1918 = addresses, in this environment the ISP
= will not be motivated to allocate private addresses towards the = will not be motivated to allocate private = addresses towards the
= single user connection because there are enough global = addresses single user connection = because there are enough global addresses
= available at essentially the same cost. Also it will be likely that available at essentially the same cost. Also if the single device
= the single device wants to mask its identity to the called party = or wants to mask its identity to = the called party or its attack profile
= its attack profile over a shorter time = window than the life of the = over a short = time window it will need to enable IPv6 privacy
ISP attachment, so it = will need to enable IPv6 privacy extensions = extensions, which in turn leads to the = need for a minimum allocation
= which in turn leads to the need for a minimum allocation of a = /64 of a /64 prefix rather than a = single address.
= prefix rather than a single address.
5.3. Single User Connection 5.3. Single User Connection
= This group identifies the users which are connected via a single = IPv4 This group identifies the = users which are connected via a single IPv4
= address and use a single piece of equipment (PC, PDA, etc.). = This address and use a single piece = of equipment (PC, PDA, etc.). This
= user may get an ambiguous IPv4 address (frequently imposed by = the user may get an ambiguous IPv4 = address (frequently imposed by the
= ISP) from the service provider which is based on RFC 1918. If = ISP) from the service provider which is = based on RFC 1918. If
= ambiguous addressing is utilized, the service provider will = execute ambiguous addressing is = utilized, the service provider will execute
= NAT on the allocated IPv4 address for global Internet = connectivity. NAT on the allocated = IPv4 address for global Internet connectivity.
= This also limits the internet capability of the equipment to = being This also limits the internet = capability of the equipment to being
=
skipping to change at page 25, line = 17 skipping to = change at page 22, line 16
= availability of a large amount of globally routable and unique = IPv6 availability of a large amount = of globally routable and unique IPv6
= addresses. The ISP will not be motivated to allocate private = addresses. The ISP will not be motivated to = allocate private
= addresses towards the single user connection because he has = enough addresses towards the single = user connection because he has enough
= global addresses available, if scarcity was the motivation with = IPv4 global addresses available, if = scarcity was the motivation with IPv4
= to provide RFC 1918 addresses. If the single user wants to mask = his to provide RFC 1918 addresses. = If the single user wants to mask his
= identity, he may choose to enable IPv6 privacy extensions. = identity, he may choose to enable IPv6 = privacy extensions.
5.4. ISP/Carrier Customer Networks 5.4. ISP/Carrier Customer Networks
= This group refers to the actual service providers that are = providing This group refers to the = actual service providers that are providing
= the IP access and transport services. = They tend to have three the IPv4 access and transport services. They tend = to have three
= separate IP domains that they = support: separate IPv4 domains that they support:
= o For the first they fall into the Medium/large private = networks o For the first they fall = into the Medium/large private networks
= category (above) for their own internal networks, LANs etc. = category (above) for their own internal = networks, LANs etc.
= o The second is the Operations network which addresses their = o The second is the Operations network = which addresses their
= backbone and access switches, and other hardware, this is = separate backbone and access = switches, and other hardware, this is separate
= for both engineering reasons as well as simplicity in managing = the for both engineering reasons = as well as simplicity in managing the
= security of the backbone. = security of the backbone.
= o The third is the IP addresses (single or blocks) that they = assign o The third is the IP = addresses (single or blocks) that they assign
= to customers. These can be registered addresses (usually given = to to customers. These can be = registered addresses (usually given to
= category 5.1 and 5.2 and sometimes 5.3) or can be from a pool = of category 5.1 and 5.2 and = sometimes 5.3) or can be from a pool of
= RFC 1918 addresses used with IPv4 NAT = for single user connections. = RFC 1918 addresses used with NAT for single user connections.
= Therefore they can actually have two different NAT domains = that Therefore they can actually = have two different NAT domains that
= are not connected (internal LAN and single user customers). = are not connected (internal LAN and = single user customers).
= When IPv6 NAP is utilized in these three domains then for the = first When IPv6 NAP is utilized in = these three domains then for the first
= category it will be possible to use the same solutions as = described category it will be = possible to use the same solutions as described
= in Section 5.1. The second domain of the ISP/carrier is the = in Section 5.1. The second domain of the = ISP/carrier is the
= Operations network. This environment tends to be a closed = Operations network. This environment tends = to be a closed
= environment, and consequently communication can be done based on = ULA environment, and consequently = communication can be done based on ULA
= addresses, however, in this environment, stable IPv6 Provider = addresses, however, in this environment, = stable IPv6 Provider
= Independent addresses can be used. This = would give a solid and Independent = addresses can be used in preference to ULA = addresses.
= scalable configuration with respect to a local IPv6 address plan. = By This would give a solid and = scalable configuration with respect to a
= the usage of proper network edge filters, outside access to = the local IPv6 address plan. By = the usage of proper network edge
= closed environment can be avoided. The third is the IPv6 = addresses filters, outside access = to the closed environment can be avoided.
= that ISP/carrier network assign to customers. These will = typically The third is the IPv6 = addresses that ISP/carrier network assign to
= be assigned with prefix lengths terminating on nibble boundaries = to customers. These will = typically be assigned with prefix lengths
= be consistent with the DNS PTR records. As scarcity of IPv6 = terminating on nibble boundaries to be = consistent with the DNS PTR
= addresses is not a concern, it will be possible for the ISP = to records. As scarcity of IPv6 = addresses is not a concern, it will be
= provide global routable IPv6 prefixes without a requirement = for possible for the ISP to = provide global routable IPv6 prefixes without
= address translation. An ISP may for commercial reasons still = decide a requirement for address = translation. An ISP may for commercial
= to restrict the capabilities of the end users by other means = like reasons still decide to = restrict the capabilities of the end users by
= traffic and/or route filtering etc. other means like traffic and/or route filtering = etc.
= If the carrier network is a mobile provider, then IPv6 is = encouraged If the carrier network = is a mobile provider, then IPv6 is encouraged
= in comparison with the combination of IPv4+NAT for 3GPP = attached in comparison with the = combination of IPv4+NAT for 3GPP attached
= devices. When looking in chapter 2.3 of RFC3314 'Recommendations = for devices. When looking in = chapter 2.3 of RFC3314 'Recommendations for
= IPv6 in 3GPP Standards' [15] it is found that the IPv6 WG = recommends IPv6 in 3GPP Standards' = [15] it is found that the IPv6 WG recommends
= that one or more /64 prefixes should be assigned to each primary = PDP that one or more /64 prefixes = should be assigned to each primary PDP
= context. This will allow sufficient address space for a 3GPP- = context. This will allow sufficient address = space for a 3GPP-
= attached node to allocate privacy addresses and/or route to a = multi- attached node to allocate = privacy addresses and/or route to a multi-
= link subnet, and will discourage the use of NAT within = 3GPP-attached link subnet, and will = discourage the use of NAT within 3GPP-attached
= devices. devices.
=
skipping to change at page 26, line = 26 skipping to = change at page 23, line 24
= continues as deployments are ongoing. This section discusses = several continues as deployments = are ongoing. This section discusses several
= topics for which additional standardization, or documentation of = best topics for which additional = standardization, or documentation of best
= practice, is required to fully realize the benefits of NAP. None = of practice, is required to fully = realize the benefits of NAP. None of
= these items are show-stoppers for immediate usage of NAP in = roles these items are show-stoppers = for immediate usage of NAP in roles
= where there are no current gaps. = where there are no current gaps.
6.1. Subnet Topology Masking 6.1. Subnet Topology Masking
= There really is no functional gap here as a centrally assigned = pool There really is no functional = gap here as a centrally assigned pool
= of addresses in combination with host routes in the IGP is an = of addresses in combination with host routes = in the IGP is an
= effective way to mask topology for smaller = deployments. If necessary = effective way to mask topology. If = necessary a best practice
= a best practice document could be developed describing the = document could be developed describing the = interaction between DHCP
= interaction between DHCP and various IGPs which would in = effect and various IGPs which = would in effect define Untraceable Addresses.
= define Untraceable Addresses.
= As an alternative for larger deployments, there = is no gap in the HA = As an alternative, = some work in Mobile IP to define a policy = message
tunneling approach when = firewalls are configured to block = outbound where a mobile node would learn from the = Home Agent. It should not
binding update = messages. A border Home Agent using internal try to inform its correspondent about route optimization and = thereby
= tunneling to the logical mobile node (potentially rack mounted) can expose its real = location. A border Home Agent using internal
tunneling to the = logical mobile node (potentially static) = can
= completely mask all internal topology, while avoiding the strain = from completely mask all internal = topology, while avoiding the strain from
= a large number of host routes in the IGP. Some = optimization work a large = number of host routes in the IGP. This work should be
could be done in Mobile IP to = define a policy message where a mobile
node would learn from the = Home Agent that it should not try to inform
its correspondent about route = optimization and thereby expose its
real location. This = optimization which reduces the load on the
firewall would result in less = optimal internal traffic routing as
that would also transit the = HA. This optimization work should = be
= pursued in the IETF. pursued in the = IETF.
6.2. Minimal Traceability of Privacy Addresses = 6.2. Minimal Traceability of Privacy = Addresses
= Privacy addresses (RFC 3041) may certainly be used to limit the = Privacy addresses (RFC 3041) may certainly = be used to limit the
= traceability of external traffic flows back to specific hosts, = but traceability of external = traffic flows back to specific hosts, but
= lacking a topology masking component above they would still = reveal lacking a topology masking = component above they would still reveal
= the subnet address bits. For complete privacy a best practice = the subnet address bits. For complete = privacy a best practice
= document describing the combination of privacy addresses with = document describing the combination of = privacy addresses with
= topology masking may be required. This work remains to be done, = and topology masking may be = required. This work remains to be done, and
= should be pursued by the IETF. = should be pursued by the IETF.
6.3. Renumbering Procedure 6.3. Renumbering Procedure
= Site renumbering procedures are discussed in [12]. It should also be Documentation of site = renumbering procedures [12] is completed and = is
= noticed that ULAs may help here too, since a change of ISP = prefix in the RFC-editor's queue. It should also be = noticed that ULAs may
= will only affect hosts that are communicating = externally. help here too, = since a change of ISP prefix will only affect hosts
that need an externally routeable address as well as an = ULA.
6.4. Site Multihoming 6.4. Site Multihoming
= This complex problem has never been completely solved for IPv4, = which This complex problem has = never been completely solved for IPv4, which
= is exactly why NAT has been used as a partial solution. For = IPv6, is exactly why NAT has been = used as a partial solution. For IPv6,
= after several years of work, the IETF = has converged on an after several = years' work, the IETF has converged on an = architectural
= architectural approach intended with service restoration as = initial approach intended with = service restoration as initial aim [20].
= aim [20]. Again, ULAs may help since they will provide = stable Again, ULAs may help since = they will provide stable addressing for
= addressing for internal communications that are not affected = by internal communications that = are not affected by multihoming.
= multihoming.
6.5. Untraceable Addresses 6.5. Untraceable Addresses
= The details of the untraceable addresses, along with any = associated The details of the = untraceable addresses, along with any associated
= mechanisms such as route injection, must be worked out and = specified. mechanisms such as route = injection, must be worked out and specified.
7. = IANA Considerations 7. IANA = Considerations
= This document requests no action by IANA This document requests no action by IANA
8. = Security Considerations 8. Security = Considerations
= While issues which are potentially security related are = discussed While issues which are = potentially security related are discussed
= throughout the document, the approaches herein do not introduce = any throughout the document, the = approaches herein do not introduce any
= new security concerns. Product marketing departments have = widely new security concerns. = Product marketing departments have widely
= sold IPv4 NAT as a security tool and suppliers have been = implementing sold IPv4 NAT as a = security tool and suppliers have been implementing
= address translation functionality in their firewalls, though = the address translation = functionality in their firewalls, though the
= misleading nature of those claims has been previously documented = in misleading nature of those = claims has been previously documented in
= [2] and [4]. RFC 2663 [2] and RFC = 2993 [4].
= This document defines IPv6 approaches which collectively achieve = the This document defines IPv6 = approaches which collectively achieve the
= goals of the network manager without the negative impact on = goals of the network manager without the = negative impact on
= applications or security that are inherent in a NAT approach. To = the applications or security that = are inherent in a NAT approach. To the
= degree that these techniques improve a network manager's ability = to degree that these techniques = improve a network manager's ability to
= explicitly know about or control access, and thereby manage the = explicitly know about or control access, and = thereby manage the
= overall attack exposure of local resources, they act to improve = local overall attack exposure of = local resources, they act to improve local
= network security. In particular the explicit nature of a = content network security. In = particular the explicit nature of a content
= aware firewall in NAP will be a vast security improvement over = the aware firewall in NAP will be a = vast security improvement over the
= NAT artifact where lack of translation state has been widely sold = as NAT artifact where lack of = translation state has been widely sold as
=
skipping to change at page 29, line = 32 skipping to = change at page 26, line 25
= Carney, "Dynamic Host Configuration Protocol for IPv6 = Carney, "Dynamic Host Configuration = Protocol for IPv6
= (DHCPv6)", RFC 3315, July 2003. = (DHCPv6)", RFC 3315, July 2003.
= [10] Draves, R., "Default Address Selection for Internet = Protocol [10] Draves, R., "Default = Address Selection for Internet Protocol
= version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February = 2003.
= [11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic = Host [11] Troan, O. and R. Droms, = "IPv6 Prefix Options for Dynamic Host
= Configuration Protocol (DHCP) version 6", RFC 3633, = Configuration Protocol (DHCP) version = 6", RFC 3633,
= December 2003. December = 2003.
= [12] Baker, F., Lear, E., and R. Droms, = "Procedures for Renumbering [12] = Baker, F., "Procedures for Renumbering an IPv6 Network without
= an IPv6 Network without a Flag Day", RFC = 4192, September 2005. = a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work = in
progress), March 2005.
= [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast = [13] Hinden, R. and B. Haberman, "Unique = Local IPv6 Unicast
= Addresses", RFC 4193, October = 2005. Addresses", draft-ietf-ipv6-unique-local-addr-09 (work = in
progress), January 2005.
11.2. Informative References 11.2. Informative References
= [14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless = Inter- [14] Fuller, V., Li, T., = Yu, J., and K. Varadhan, "Classless Inter-
= Domain Routing (CIDR): an Address Assignment and = Aggregation Domain Routing = (CIDR): an Address Assignment and Aggregation
= Strategy", RFC 1519, September 1993. Strategy", RFC 1519, September 1993.
= [15] Wasserman, M., "Recommendations for IPv6 in Third = Generation [15] Wasserman, M., = "Recommendations for IPv6 in Third Generation
= Partnership Project (3GPP) Standards", RFC 3314, Partnership Project (3GPP) Standards", RFC = 3314,
= September 2002. = September 2002.
=
skipping to change at page 31, line = 13 skipping to = change at page 28, line 7
= IPv6 offers a scalable approach to minimizing human interaction = and IPv6 offers a scalable approach = to minimizing human interaction and
= device configuration. Whereas IPv4 implementations require = touching device configuration. = Whereas IPv4 implementations require touching
= each end system to indicate the use of DHCP vs. a static address = and each end system to indicate the = use of DHCP vs. a static address and
= management of a server with the pool size large enough for the = management of a server with the pool size = large enough for the
= potential number of connected devices, IPv6 uses an indication = from potential number of connected = devices, IPv6 uses an indication from
= the router to instruct the end systems to use DHCP or the = stateless the router to instruct = the end systems to use DHCP or the stateless
= auto configuration approach supporting a virtually limitless = number auto configuration approach = supporting a virtually limitless number
= of devices on the subnet. This minimizes the number of systems = that of devices on the subnet. = This minimizes the number of systems that
= require human interaction as well as improves consistency between = all require human interaction as = well as improves consistency between all
= the systems on a subnet. In the case that there is no router = to the systems on a subnet. In the = case that there is no router to
= provide this indication, an address for use only on the local link provide this indication, an address for use on the local link only
= will be derived from the interface media layer address. = will be derived from the interface media = layer address.
A.3. Native Multicast Services A.3. Native Multicast Services
= Multicast services in IPv4 were severely restricted by the = limited Multicast services in IPv4 = were severely restricted by the limited
= address space available to use for group assignments and an = implicit address space available to = use for group assignments and an implicit
= locally defined range for group membership. IPv6 multicast = corrects locally defined range for = group membership. IPv6 multicast corrects
= this situation by embedding explicit scope indications as well = as this situation by embedding = explicit scope indications as well as
= expanding to 4 billion groups per scope. In the source = specific expanding to 4 billion = groups per scope. In the source specific
= multicast case, this is further expanded to 4 billion groups = per multicast case, this is further = expanded to 4 billion groups per
=
skipping to change at page 32, line = 38 skipping to = change at page 29, line 29
= connection establishment in either protocol version, IPv6 = mobile connection establishment in = either protocol version, IPv6 mobile
= nodes are able to optimize the path between them using the = MIPv6 nodes are able to optimize = the path between them using the MIPv6
= option header while IPv4 mobile nodes are required to triangle = route option header while IPv4 = mobile nodes are required to triangle route
= all packets. In general terms this will minimize the network = all packets. In general terms this will = minimize the network
= resources used and maximize the quality of the communication. = resources used and maximize the quality of = the communication.
A.6. Merging Networks A.6. Merging Networks
= When two IPv4 networks want to merge it is not guaranteed that = both When two IPv4 networks want to = merge it is not guaranteed that both
= networks would be using different address-ranges on some parts of = the networks would be using = different address-ranges on some parts of the
= network infrastructure due to the usage of RFC 1918 private = network infrastructure due to the legitimate usage of RFC 1918
= addressing. This potential overlap in address space may complicate = a private addressing. This = potential overlap in address space may
= merge of two and more networks dramatically due to the = additional complicate a merge of = two and more networks dramatically due to the
= IPv4 renumbering effort. i.e. when the first network has a = service additional IPv4 = renumbering effort. i.e. when the first network has a
= running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed = by service running (NTP, DNS, = DHCP, HTTP, etc..) which need to be
= the 2nd merging network. Similar address conflicts can happen = when accessed by the 2nd merging = network. Similar address conflicts can
= two network devices from these merging networks want to = communicate. happen when two = network devices from these merging networks want to
= communicate.
= With the usage of IPv6 the addressing overlap will not exist = because With the usage of IPv6 the = addressing overlap will not exist because
= of the existence of the Unique Local Address usage for private = and of the existence of the Unique = Local Address usage for private and
= local addressing. local = addressing.
A.7. Community of interest A.7. Community of interest
= Although some Internet-enabled devices will function as = fully-fledged Although some = Internet-enabled devices will function as fully-fledged
= Internet hosts, it is believed that many will be operated in a = highly Internet hosts, it is = believed that many will be operated in a highly
= restricted manner functioning largely or entirely within a = Community restricted manner = functioning largely or entirely within a Community
= of Interest. By Community of Interest we mean a collection of = hosts of Interest. By Community of = Interest we mean a collection of hosts
= that are logically part of a group reflecting their ownership = or that are logically part of a = group reflecting their ownership or
= function. Typically, members of a Community of Interest need = to function. Typically, members of = a Community of Interest need to
= communicate within the community but should not be generally = communicate within the community but should = not be generally
= accessible on the Internet. They want the benefits of the = accessible on the Internet. They want the = benefits of the
= connectivity provided by the Internet, but do not want to be = exposed connectivity provided by = the Internet, but do not want to be exposed
= to the rest of the world. The ability in NAP = to virtualize the to the = rest of the world. This functionality will be = available
= topology to mask it is applied to the = cluster, creating arbitrary = through the = usage of NAP and native IPv6 dataflows, without = any
groupings or = communities. It will also allow to build virtual = stateful device = in the middle. It will also allow = to build virtual
= organization networks on the fly, which is very difficult to do = in organization networks on the = fly, which is very difficult to do in
= IPv4+NAT scenarios. IPv4+NAT = scenarios.
Appendix B. Revision history Appendix B. Revision history
B.1. Changes from *-vandevelde-v6ops-nap-00 to = B.1. Changes from *-vandevelde-v6ops-nap-00 = to
= *-vandevelde-v6ops-nap-01 = *-vandevelde-v6ops-nap-01
= o Document introduction has been revised and overview table = added o Document introduction has = been revised and overview table added
= o Comments and suggestions from nap-00 draft have been = included. o Comments and = suggestions from nap-00 draft have been included.
= o Initial section of -00 draft 2.6 and 4.6 have been aggregated = into o Initial section of -00 = draft 2.6 and 4.6 have been aggregated into
=
skipping to change at page 37, line = 47 skipping to = change at page 35, line 5
= ULA specification is in the RFC-editor queue. ULA specification is in the RFC-editor = queue.
= o Section 6.3: (Minimal Traceability) Better to say "topology = o Section 6.3: (Minimal Traceability) = Better to say "topology
= masking _may be_ required" instead of "is required", because = masking _may be_ required" instead of "is = required", because
= whether this is needed or not is a value judgment. whether this is needed or not is a value = judgment.
= o Section 6.4: (Renumbering Procedure) Renumbering procedure is = in o Section 6.4: (Renumbering = Procedure) Renumbering procedure is in
= RFC queue. The section corrected in the current state? = RFC queue. The section corrected in the = current state?
= o Section 6.4: s/well solved/completely solved/ o Section 6.4: s/well solved/completely = solved/
= o In general the whole chapter 6 has been revised to reflect = current o In general the whole = chapter 6 has been revised to reflect current
= status status
B.5. Changes from = *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02
o
B.6. Changes from = *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03
o Editorial changes in = response to IESG review comments and
questions. =
o Introduction: clarified = impact & goal for limited additional NAT
discussion here / modified = tone wrt marketing / grammar cleanup
o Introduction: added = paragraph about why nat !=3D security
o Table1: s/benefit/Goal/ = s/ULA/4193/ removed long numeric string /
added app end points & = number of subnets
o Section 2: tone reduction = about marketing
o Section 2.1: grammar = cleanup / clarified point about use of public
space / added paragraph = about topology restrictions
o Section 2.2: moved = paragraph about firewalls to 4.2 / deleted
discussion about = distributed security / clarified point about port =
overload =
o Section 2.3: Added opening = sentence to explain the goal of the
section / deleted comment = about theory
o Section 2.4: deleted = confusing/redundant comments about identifier
/ added clarification that = focused scanning on the port range
reaches active = nodes
o Section 2.5: clarified = that the impact was on the local network
o Section 2.6: added point = about limitations of cascaded nat
o Section 2.7: clarification = about why multihoming & renumbering are
discussed together / point = about sparse allocation
o Section 3.2: grammer = cleanup / updated reference from ID to RFC
added point about policy = table to bias ULA over ISP block
o Section 3.3: Clarification = about goal for section
o Section 3.4: reorder = paragraphs to put goal up front
o Section 4.1: = s/could/should/ s/prior to establishing/independent =
of the state of/ clarified = why concatenation would not collide /
another comment about the = policy table for ULA biasing / clarified
point about lack of = routing protocol
o Section 4.2: clarified = point about firewall for boundary / 1.
clarified point about = valid lifetime / 2. clarified point that
IPsec works the same w/o = NAT / 3. clarified that the scanning
threat is addresses as = ports are the same once an address is known
/ rearranged paragraph to = keep scanning thread together /
clarified role of simple = firewall / added comment about service
provider mediated pinhole = management
o Section 4.3: added = paragraph about tracking privacy address use
o Section 4.4: clarified = point about tracking wrt NAT / added
comment about IGP = complexity / s/conceal/isolate/ reworded ULA
description which was = technically backwards / additional
description of the goal / = added picture and referenced it from
descriptions / added vlan = option
o Section 4.5: Grammar = cleanup / clarification about policy
o Section 4.6: added = discussion about policy focus on subnets
o Section 4.7: = s/CIDR-like/CIDR allocated/ s/this/to multiple
addresses/ s/may/will = likely/ s/if/when/ s/from SP/between sp/
o Section 5: d/of = these/
o Section 5.1: deleted = redundant discussion about /48 allocation /
added discussion about = larger deployments using tunneling
o Section 5.2: clarification = of overload on port vs. protocol /
added comment about = upstream NAT / clarified 3041 use
o Section 5.4: s/IPv4/IP as = role is not version specific / deleted
comment about preference = to ULA.
o Section 6.1: added comment = about deployment scale / added comment
about firewall blocking BU = / clarified point about future work
being an optimization to = reduce firewall load
o Section 6.3: replaced = reference to renumbering draft w/RFC
o Section 6.4: grammar = cleanup
o Section A.2: word order - = moved 'only'
o Section A.6: deleted = 'legitimate'
o Section A.7: clarified how = NAP delivers community of interest
o Section B.5: added place = holder for missing change log -01 to -02
= =
Authors' Addresses Authors' Addresses
= Gunter Van de Velde Gunter Van de = Velde
= Cisco Systems Cisco Systems
= De Kleetlaan 6a De Kleetlaan = 6a
= Diegem 1831 Diegem 1831
= Belgium Belgium
= Phone: +32 2704 5473 Phone: +32 = 2704 5473
= Email: gunter@cisco.com Email: = gunter@cisco.com
=
skipping to change at page 41, line = 41 skipping to = change at page 36, line 41
= This document and the information contained herein are provided on = an This document and the = information contained herein are provided on an
= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS "AS IS" basis and THE = CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE = INTERNET OR IS SPONSORED BY (IF = ANY), THE INTERNET SOCIETY AND THE INTERNET
= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR = IMPLIED, ENGINEERING TASK FORCE = DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE = INCLUDING BUT NOT LIMITED TO ANY WARRANTY = THAT THE USE OF THE
= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED = INFORMATION HEREIN WILL NOT INFRINGE ANY = RIGHTS OR ANY IMPLIED
= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR = PURPOSE. WARRANTIES OF = MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
= Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2005). This document is subject
= to the rights, licenses and restrictions contained in BCP 78, = and to the rights, licenses and = restrictions contained in BCP 78, and
= except as set forth therein, the authors retain all their = rights. except as set forth = therein, the authors retain all their rights.
Acknowledgment Acknowledgment
= Funding for the RFC Editor function is currently provided by = the Funding for the RFC Editor = function is currently provided by the
= Internet Society. Internet = Society.
 End of changes. 96 change blocks. 
666 lines changed or = deleted 491 lines changed or = added

This = html diff was produced by rfcdiff 1.32. The latest version is available = from http://www.levkowetz.com/ietf/tools/rfcdiff/
------=_NextPart_000_0CE6_01C68F22.77700D50 Content-Type: text/plain; name="draft-ietf-v6ops-nap-03-draft0.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-v6ops-nap-03-draft0.txt" =0A= =0A= =0A= Network Working Group G. Van de Velde=0A= Internet-Draft T. Hain=0A= Expires: December 4, 2006 R. Droms=0A= Cisco Systems=0A= B. Carpenter=0A= IBM Corporation=0A= E. Klein=0A= Tel Aviv University=0A= June 2, 2006=0A= =0A= =0A= IPv6 Network Architecture Protection=0A= =0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on December 4, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= Although there are many perceived benefits to Network Address=0A= Translation (NAT), its primary benefit of "amplifying" available=0A= address space is not needed in IPv6. In addition to NAT's many=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 1]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= serious disadvantages, there is a perception that other benefits=0A= exist, such as a variety of management and security attributes that=0A= could be useful for an Internet Protocol site. IPv6 does not support=0A= NAT by design and this document shows how Network Architecture=0A= Protection (NAP) using IPv6 can provide the same or more benefits=0A= without the need for NAT.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 7=0A= 2.1. Simple Gateway between Internet and Private Network . . . 7=0A= 2.2. Simple Security due to Stateful Filter Implementation . . 8=0A= 2.3. User/Application tracking . . . . . . . . . . . . . . . . 8=0A= 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9=0A= 2.5. Independent Control of Addressing in a Private Network . . 10=0A= 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10=0A= 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11=0A= 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 11=0A= 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12=0A= 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 12=0A= 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13=0A= 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13=0A= 4. Using IPv6 Technology to Provide the Market Perceived=0A= Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14=0A= 4.1. Simple Gateway between Internet and Internal Network . . . 14=0A= 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15=0A= 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17=0A= 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 17=0A= 4.5. Independent Control of Addressing in a Private Network . . 19=0A= 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 20=0A= 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 20=0A= 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21=0A= 5.1. Medium/large private networks . . . . . . . . . . . . . . 21=0A= 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 23=0A= 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 24=0A= 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 25=0A= 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 26=0A= 6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . 26=0A= 6.2. Minimal Traceability of Privacy Addresses . . . . . . . . 26=0A= 6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . 27=0A= 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 27=0A= 6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . 27=0A= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27=0A= 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28=0A= 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 2]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28=0A= 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28=0A= 11.2. Informative References . . . . . . . . . . . . . . . . . . 29=0A= Appendix A. Additional Benefits due to Native IPv6 and=0A= Universal Unique Addressing . . . . . . . . . . . . . 30=0A= A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 30=0A= A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 30=0A= A.3. Native Multicast Services . . . . . . . . . . . . . . . . 31=0A= A.4. Increased Security Protection . . . . . . . . . . . . . . 31=0A= A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 32=0A= A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 32=0A= A.7. Community of interest . . . . . . . . . . . . . . . . . . 32=0A= Appendix B. Revision history . . . . . . . . . . . . . . . . . . 33=0A= B.1. Changes from *-vandevelde-v6ops-nap-00 to=0A= *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 33=0A= B.2. Changes from *-vandevelde-v6ops-nap-01 to=0A= *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 33=0A= B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 33=0A= B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 33=0A= B.5. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 37=0A= B.6. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 41=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 3]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= Although there are many perceived benefits to Network Address=0A= Translation (NAT), its primary benefit of "amplifying" available=0A= address space is not needed in IPv6. The serious disadvantages and=0A= impact on applications by ambiguous "private" address space and=0A= Network Address Translation (NAT) [1] [5] have been well documented=0A= [4] [6] so there will not be much additional discussion here.=0A= However, given its wide market acceptance NAT undoubtedly has some=0A= perceived benefits. Indeed, in an Internet model based on universal=0A= any-to-any connectivity, product marketing departments have driven a=0A= perception that some connectivity and security concerns can only be=0A= solved by using a NAT device or by using logically separated address=0A= spaces. This document describes the goals for utilizing a NAT device=0A= in an IPv4 environment that are regularly cited as solutions for=0A= perceived problems. It then shows how these needs can be met without=0A= using the header modification feature of NAT in an IPv6 network. The=0A= use of the facilities from IPv6 described in this document avoids the=0A= negative impacts on applications of address translation while meeting=0A= or exceeding the comparable IPv4+NAT equivlent goal.=0A= =0A= As far as security and privacy are concerned, this document considers=0A= how to mitigate a number of threats. Some are obviously external,=0A= such as having a hacker or a worm infected machine outside trying to=0A= penetrate and attack the local network. Some are local such as a=0A= disgruntled employee disrupting business operations, or the=0A= unintentional negligence of a user downloading some malware which=0A= then proceeds to attack from within. Some may be inherent in the=0A= device hardware ("embedded") such as having some firmware in a=0A= domestic appliance "call home" to its manufacturer without the user's=0A= consent.=0A= =0A= Another consideration discussed is the view that NAT can be used to=0A= fulfill the goals of a security policy. At a technical level the=0A= translation process fundamentally can not produce security because=0A= mangling the address in the header does not fulfill any useful=0A= security functions, it only breaks the ability to track what is going=0A= on. The artifacts of NAT devices do provide some value.=0A= 1. the need to establish state before anything gets through from=0A= outside to inside solves one set of problems.=0A= 2. the need to stop receiving any packets when finished with a flow=0A= solves a set of problems=0A= 3. the need to appear to be at the edge of the network solves a set=0A= of problems=0A= 4. and the ability to have addresses that are not publicly routed=0A= solves yet another set (mostly changes where the state is and=0A= scale requirements for the first one).=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 4]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= This document describes several techniques that may be combined in an=0A= IPv6 deployment to protect the integrity of its network architecture.=0A= It will focus on the 'how to acomplish a goal' perspective, leaving=0A= most of the 'why that goal' perspective for other documents. These=0A= techniques, known collectively as Network Architecture Protection=0A= (NAP), retain the concept of a well defined boundary between "inside"=0A= and "outside" the private network, and allow firewalling, topology=0A= hiding, and privacy. NAP will achieve these security goals without=0A= address translation whilst regaining the ability for arbitrary any-=0A= to-any connectivity.=0A= =0A= IPv6 Network Architecture Protection can be summarized in the=0A= following table. It presents the marketed "benefits" of IPv4+NAT=0A= with a cross-reference of how those are delivered in both the IPv4=0A= and IPv6 environments.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 5]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Goal IPv4 IPv6=0A= +------------------+-----------------------+-----------------------+=0A= | Simple Gateway | DHCP - single | DHCP-PD - arbitrary |=0A= | as default router| address upstream | length customer |=0A= | and address pool | DHCP - limited | prefix upstream |=0A= | manager | number of individual | SLAAC via RA |=0A= | | devices downstream | downstream |=0A= | | see section 2.1 | see section 4.1 |=0A= +------------------|-----------------------|-----------------------+=0A= | Simple Security | Filtering side | Explicit Context |=0A= | | effect due to lack | Based Access Control |=0A= | | of translation state | (Reflexive ACL) |=0A= | | see section 2.2 | see section 4.2 |=0A= +------------------|-----------------------|-----------------------+=0A= | Local usage | NAT state table | Address uniqueness |=0A= | tracking | | |=0A= | | see section 2.3 | see section 4.3 |=0A= +------------------|-----------------------|-----------------------+=0A= | End-system | NAT transforms | Temporary use |=0A= | privacy | device ID bits in | privacy addresses |=0A= | | the address | |=0A= | | see section 2.4 | see section 4.4 |=0A= +------------------|-----------------------|-----------------------+=0A= | Topology hiding | NAT transforms | Untraceable addresses|=0A= | | subnet bits in the | using IGP host routes|=0A= | | address | /or MIPv6 tunnels for|=0A= | | | stationary systems |=0A= | | see section 2.4 | see section 4.4 |=0A= +------------------|-----------------------|-----------------------+=0A= | Addressing | RFC 1918 | RFC 3177 & 4193 |=0A= | Autonomy | | |=0A= | | see section 2.5 | see section 4.5 |=0A= +------------------|-----------------------|-----------------------+=0A= | Global Address | RFC 1918 | 18*10^18 subnets |=0A= | Pool | << 2^48 application | 3.4*10^38 addresses |=0A= | Conservation | end points | unrestricted |=0A= | | topology restricted | |=0A= | | see section 2.6 | see section 4.6 |=0A= +------------------|-----------------------|-----------------------+=0A= | Renumbering and | Address translation | Preferred lifetime |=0A= | Multi-homing | at border | per prefix & Multiple|=0A= | | | addresses per |=0A= | | | interface |=0A= | | see section 2.7 | see section 4.7 |=0A= +------------------+-----------------------+-----------------------+=0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 6]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= This document first identifies the perceived benefits of NAT in more=0A= detail, and then shows how IPv6 NAP can provide each of them. It=0A= concludes with a IPv6 NAP case study and a gap analysis of work that=0A= remains to be done for a complete NAP solution.=0A= =0A= =0A= 2. Perceived Benefits of NAT and its Impact on IPv4=0A= =0A= This section provides insight into the generally perceived benefits=0A= of the use of IPv4 NAT which are frequently reinforced by product=0A= marketing. The goal of this description is not to analyze these=0A= benefits or the accuracy of the perception (detailed discussions in=0A= [4]), but to describe the deployment requirements and set a context=0A= for the later descriptions of the IPv6 approaches for dealing with=0A= those requirements.=0A= =0A= 2.1. Simple Gateway between Internet and Private Network=0A= =0A= A NAT device can connect a private network with addresses allocated=0A= from any part of the space (ambiguous [RFC 1918] or global registered=0A= address) towards the Internet, though extra effort is needed when the=0A= same range exists on both sides of the NAT. The address space of the=0A= private network can be built from globally unique addresses, from=0A= ambiguous address space or from both simultaneously. In the simple=0A= case of private use addresses, without needing specific configuration=0A= the NAT device enables access between the client side of a=0A= distributed client-server application in the private network and the=0A= server side located in the public Internet.=0A= =0A= Wide-scale deployments have shown that using NAT to attach a private=0A= IPv4 network to the Internet is simple and practical for the non-=0A= technical end user. Frequently a simple user interface, or even a=0A= default configuration is sufficient for configuring both device and=0A= application access rights.=0A= =0A= This simplicity comes at a price as the resulting topology puts=0A= restrictions on applications. The NAT simplicity works well when the=0A= applications are limited to a client/server model with the server=0A= deployed on the public side of the NAT. For peer-to-peer, multi-=0A= party, or servers deployed on the private side of the NAT, helper=0A= technologies must be available. These helper technologies are=0A= frequently complex to develop and manage, creating a hidden cost to=0A= this 'simple gateway'.=0A= =0A= Additionally, thanks to successful marketing campaigns it is=0A= perceived by end users that by installing a NAT as the gateway, their=0A= equipment is protected from the malicious entities and attackers on=0A= the public IPv4 Internet.=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 7]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 2.2. Simple Security due to Stateful Filter Implementation=0A= =0A= It is frequently believed that through its session-oriented=0A= operation, NAT puts in an extra barrier to keep the private network=0A= protected from outside influences. Since a NAT device typically=0A= keeps state only for individual sessions, attackers, worms, etc.=0A= cannot exploit this state to attack a specific host on any other=0A= port, though in the port overload case of NAPT attacking all active=0A= ports will impact a potentially wide number of hosts. This benefit=0A= may be partially real, however, experienced hackers are well aware of=0A= NAT devices and are very familiar with private address space, and=0A= have devised methods of attack (such as trojan horses) that readily=0A= penetrate NAT boundaries. For these reasons the sense of security=0A= provided by NAT is actually an illusion.=0A= =0A= The act of address translation does not provide security in itself;=0A= for example, consider a configuration with static NAT translation and=0A= all inbound ports translating to a single machine. In such a=0A= scenario the security risk for that machine is identical to the case=0A= with no NAT device in the communication path. As result there is no=0A= specific security value in the address translation function. The=0A= perceived security in this case comes from the lack of pre-=0A= established or permanent mapping state. Dynamically establishing=0A= state in response to internal requests reduces the threat of=0A= unexpected external connections to internal devices. This role,=0A= marketed as a firewall, is really an arbitrary artifact while a real=0A= firewall has explicit management controls.=0A= =0A= In some cases, NAT operators (including domestic users) may be=0A= obliged to configure quite complex port mapping rules to allow=0A= external access to local applications such as a multi-player game or=0A= web servers. In this case the NAT actually adds management=0A= complexity compared to a simple router. In situations where two or=0A= more devices need to host the same application or otherwise use the=0A= same public port this complexity shifts from difficult to impossible.=0A= =0A= 2.3. User/Application tracking=0A= =0A= One usage of NAT is for the local network administrator to track user=0A= and application traffic. Although NATs create temporary state for=0A= active sessions, in general they provide limited capabilities for the=0A= administrator of the NAT to gather information about who in the=0A= private network is requesting access to which Internet location.=0A= This is done by periodically logging the network address translation=0A= details of the private and the public addresses from the NAT device's=0A= state database.=0A= =0A= The subsequent checking of this database is not always a simple task,=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 8]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= especially if Port Address Translation is used. It also has an=0A= unstated assumption that the administrative instance has a mapping=0A= between a private IPv4-address and a network element or user at all=0A= times, or the administrator has a time-correlated list of the=0A= address/port mappings.=0A= =0A= 2.4. Privacy and Topology Hiding=0A= =0A= The goal of 'topology hiding' is to prevent external entities from=0A= making a correlation between the topological location of devices on=0A= the local network. The ability of NAT to provide Internet access to=0A= a large community of users by the use of a single (or a few) global=0A= IPv4 routable addresses offers a simple mechanism to hide the=0A= internal topology of a network. In this scenario the large community=0A= will be represented in the Internet by a single (or a few) IPv4=0A= address(es).=0A= =0A= The use of NAT then results in a user behind a NAT gateway actually=0A= appearing on the Internet as a user inside the NAT box itself; i.e.,=0A= the IPv4 address that appears on the Internet is only sufficient to=0A= identify the NAT. When concealed behind a NAT it is impossible to=0A= tell from the outside which member of a family, which customer of an=0A= Internet cafe, or which employee of a company generated or received a=0A= particular packet. Thus, although NATs do nothing to provide=0A= application level privacy, they do prevent the external tracking and=0A= profiling of individual host computers by means of their IP=0A= addresses, usually known as 'device profiling'. At the same time a=0A= NAT creates a smaller pool of addresses for a much more focused point=0A= of attack, where the adversary does not need to scan the entire=0A= network. By periodically scanning the limited 16 bit port range on=0A= the public side of the NAT, the attack will eventually find ports=0A= that are open to active nodes.=0A= =0A= There is a similarity with privacy based on application level=0A= proxies. When using an application level gateway for browsing the=0A= web for example, the 'privacy' of a web user can be provided by=0A= masking the true identity of the original web user towards the=0A= outside world (although the details of what is - or is not - logged=0A= at the NAT/proxy will be different).=0A= =0A= Some enterprises prefer to hide as much as possible of their internal=0A= network topology from outsiders. Mostly this is achieved by blocking=0A= "traceroute" etc., but NAT of course entirely hides the internal=0A= subnet topology, which some network managers believe is a useful=0A= precaution to mitigate scanning attacks. Scanning for IPv6 can be=0A= much harder in comparison with IPv4 as described in [18].=0A= =0A= Once a list of available devices and IP addresses has been mapped, a=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 9]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= port-scan on these IP addresses can be performed. Scanning works by=0A= tracking which ports do not receive unreachable errors from either=0A= the firewall or host. With the list of open ports an attacker can=0A= optimize the time needed for a successful attack by correlating it=0A= with known vulnerabilities to reduce the number of attempts. For=0A= example, FTP usually runs on port 21, and HTTP usually runs on port=0A= 80. Any vulnerable open ports could be used for initiating attacks=0A= on an end system.=0A= =0A= 2.5. Independent Control of Addressing in a Private Network=0A= =0A= Many private IPv4 networks take benefit from using the address space=0A= defined in RFC 1918 to enlarge the available addressing space for=0A= their private network, and at the same time reduce their need for=0A= globally routable addresses. This type of local control of address=0A= resources allows a clean and hierarchical addressing structure in the=0A= local network.=0A= =0A= Another benefit is due to the usage of independent addresses on=0A= majority of the network infrastructure there is an increased ability=0A= to change provider with less operational difficulties.=0A= =0A= Section 2.7 describes some disadvantages that appear if independent=0A= networks using [RFC1918] addresses have to be merged.=0A= =0A= 2.6. Global Address Pool Conservation=0A= =0A= While the widespread use of IPv4+NAT has reduced the potential=0A= consumption rate, due to the ongoing depletion of the IPv4 address=0A= range the remaining pool of unallocated IPv4 addresses is already=0A= below 25%. While mathematical models based on historical IPv4 prefix=0A= consumption periodically attempt to predict the future exhaustion=0A= date of the IPv4 address pool, a direct result of this continuous=0A= resource consumption is that the administrative overhead for=0A= acquiring globally unique IPv4 addresses will continue increasing in=0A= direct response to tightening allocation policies.=0A= =0A= In response to the increasing administrative overhead many Internet=0A= Service Providers (ISPs) have already resorted to the ambiguous=0A= addresses defined in RFC 1918 behind a NAT for the various services=0A= they provide as well as connections for their end customers. This=0A= happens even though the private use address-space is strictly limited=0A= in size. Some deployments have already outgrown that space and have=0A= begun cascading NAT to continue expanding. Unfortunately, the number=0A= of and types of applications that can be deployed by these ISPs and=0A= their customers is restricted by the ability to overload the port=0A= range on the public side of the most public NAT in the path. The=0A= result is something substantially less than 2^48 possible active=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 10]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= application endpoints, rather than the perception of arbitrary=0A= utility one might expect from the large number of addressable=0A= devices. In addition it is highly likely that nodes will become=0A= confused because they are not topology aware, though as already=0A= mentioned NAT enforces specific topologies on the application=0A= deployment model. Forced into this limiting situation such customers=0A= can rightly claim that despite the optimistic predictions of=0A= mathematical models the global pool of IPv4 addresses is effectively=0A= already exhausted, especially for larger enterprises.=0A= =0A= 2.7. Multihoming and Renumbering with NAT=0A= =0A= Allowing a network to be multihomed and renumbering a network are=0A= quite different functions. However these are argued together as=0A= reasons for using NAT, because making a network multihomed is often a=0A= transitional state required as part of network renumbering, and NAT=0A= interacts with both in the same way.=0A= =0A= For enterprise networks, it is highly desirable to provide resiliency=0A= and load-balancing to be connected to more than one Internet Service=0A= Provider (ISP) and to be able to change ISPs at will. This means=0A= that a site must be able to operate under more than one CIDR prefix=0A= [14] and/or readily change its CIDR prefix. Unfortunately, IPv4 was=0A= not designed to facilitate either of these maneuvers. However, if a=0A= site is connected to its ISPs via NAT boxes, only those boxes need to=0A= deal with multihoming and renumbering issues.=0A= =0A= Similarly, if two enterprise IPv4 networks need to be merged and=0A= RFC1918 addresses are used, there is a high probability of address=0A= overlaps. In those situations it may well be that installing a NAT=0A= box between them will avoid the need to renumber one or both. For=0A= any enterprise, this can be a short term financial saving, and allow=0A= more time to renumber the network components. The long term solution=0A= is a single network without usage of NAT to avoid the ongoing=0A= operational complexity of overlapping addresses.=0A= =0A= The addition of an extra NAT as a solution may be sufficient for some=0A= networks; however when the merging networks were already using=0A= address translation it will create huge problems due to=0A= administrative difficulties of overlapping address speaces in the=0A= merged networks.=0A= =0A= =0A= 3. Description of the IPv6 Tools=0A= =0A= This section describes several features that can be used as part of=0A= the NAP solution to emulate the protection features associated with=0A= IPv4 NAT.=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 11]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 3.1. Privacy Addresses (RFC 3041)=0A= =0A= There are situations where it is desirable to prevent device=0A= profiling, for example by web sites that are accessed from the=0A= device; IPv6 privacy addresses were defined to provide that=0A= capability. IPv6 addresses consist of a routing prefix, subnet-id=0A= part (SID) and an interface identifier part (IID). For interfaces=0A= that contain embedded IEEE Link Identifiers the interface identifier=0A= is typically derived from it, though this practice facilitates=0A= tracking and profiling of a device as it moves around the Internet.=0A= RFC 3041 describes an extension to IPv6 stateless address=0A= autoconfiguration (SLAAC) for interfaces [7]. Use of the privacy=0A= address extension causes nodes to generate global-scope addresses=0A= from interface identifiers that change over time, even in cases where=0A= the interface contains an embedded IEEE link identifier. Changing=0A= the interface identifier (thus the global-scope addresses generated=0A= from it) over time makes it more difficult for eavesdroppers and=0A= other information collectors to identify when addresses used in=0A= different transactions actually correspond to the same node. A=0A= relatively short valid lifetime for the privacy address also has the=0A= side effect of reducing the attack profile of a device, as it is not=0A= directly attackable once it stops answering at the temporary use=0A= address.=0A= =0A= While the primary implementation and source of randomized RFC 3041=0A= addresses is expected to be from end-systems running stateless=0A= autoconfiguration, there is nothing that prevents a DHCP server from=0A= running the RFC 3041 algorithm for any new IEEE identifier it hears=0A= in a request, then remembering that for future queries. This would=0A= allow using them in DNS for registered services since the assumption=0A= of a DHCP server based deployment would be a persistent value that=0A= minimizes DNS churn. A DHCP based deployment would also allow for=0A= local policy to periodically change the entire collection of end=0A= device addresses while maintaining some degree of central knowledge=0A= and control over which addresses should be in use at any point in=0A= time.=0A= =0A= Randomizing the IID, as defined in RFC 3041, is effectively a sparse=0A= allocation technique which only precludes tracking of the lower 64=0A= bits of the IPv6 address. Masking of the subnet ID will require=0A= additional approaches as discussed below in 3.4. Additional=0A= considerations are discussed in [17].=0A= =0A= 3.2. Unique Local Addresses=0A= =0A= Acheiving the goal of autonomy is required for local network and=0A= application services stability during periods of intermittent=0A= connectivity between one or more providers. Such autonomy in a=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 12]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= single routing prefix environment would lead to massive expansion of=0A= the global routing tables (as seen in IPv4), so IPv6 provides for=0A= simultaneous use of multiple prefixes. The Unique Local Address=0A= prefix (ULA) [13] has been set aside for use in local communications.=0A= The ULA address prefix for any network is routable over a locally=0A= defined collection of routers. These prefixes are not intended to be=0A= routed on the public global Internet as large scale inter-domain=0A= distribution of routes for ULA prefixes would have a negative impact=0A= on global route aggregation.=0A= =0A= ULAs have the following characteristics:=0A= o Globally unique prefix=0A= * Allows networks to be combined or privately interconnected=0A= without creating address conflicts or requiring renumbering of=0A= interfaces using these prefixes=0A= * If accidentally leaked outside of a network via routing or DNS,=0A= it is highly unlikely that there will be a conflict with any=0A= other addresses=0A= o ISP independent and can be used for communications inside of a=0A= network without having any permanent or or only intermittent=0A= Internet connectivity=0A= o Well-known prefix to allow for easy filtering at network=0A= boundaries preventing leakage of local routes and packets.=0A= o In practice, applications may treat these addresses like global=0A= scoped addresses but address selection algorithms may need to=0A= distinguish between ULAs and ordinary global scope unicast=0A= addresses to assure stability. The policy table defined in [10]=0A= is one way to bias this selection, by giving higher preference to=0A= FC00::/7 over 2001::/3. Mixing the two kinds of addresses may=0A= lead to undeliverable packets during times of instability, but=0A= that mixing is not likely to happen when the rules of RFC 3484 are=0A= followed.=0A= =0A= 3.3. DHCPv6 Prefix Delegation=0A= =0A= One of the functions of a simple gateway is managing the local use=0A= address range. The Prefix Delegation (DHCP-PD) options [11] provide=0A= a mechanism for automated delegation of IPv6 prefixes using the=0A= Dynamic Host Configuration Protocol (DHCP) [9]. This mechanism=0A= (DHCP-PD) is intended for delegating a long-lived prefix from a=0A= delegating router (possibly incorporating a DHCPv6 server) to a=0A= requesting router, possibly across an administrative boundary, where=0A= the delegating router does not require knowledge about the topology=0A= of the links in the network to which the prefixes will be assigned.=0A= =0A= 3.4. Untraceable IPv6 Addresses=0A= =0A= The main goal of untraceable IPv6 addresses is to create an=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 13]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= apparently amorphous network infrastructure as seen from external=0A= networks to protect the local infrastructure from malicious outside=0A= influences and from mapping of any correlation between the network=0A= activities of multiple devices from external networks. When using=0A= untraceable IPv6 addresses, it could be that two apparently=0A= sequential addresses are allocated to devices on very different parts=0A= of the local network instead of belonging to devices adjacent to each=0A= other on the same subnet.=0A= =0A= These should be globally routable IPv6 addresses which can be=0A= randomly and independently assigned to IPv6 devices.=0A= =0A= The random assignment is intended to mislead the outside world about=0A= the structure of the local network. However the local network needs=0A= to maintain a correlation between the location of the device and the=0A= untraceable IPv6 address. For smaller deployments this correlation=0A= could be done by generating IPv6 host route entries, or for larger=0A= ones by utilizing an indirection device such as a Mobile IPv6 Home=0A= Agent. Additional details are in section 4.7.=0A= =0A= =0A= 4. Using IPv6 Technology to Provide the Market Perceived Benefits of=0A= NAT=0A= =0A= The facilities in IPv6 described in Section 3 can be used to provide=0A= the protection perceived to be associated with IPv4 NAT. This=0A= section gives some examples of how IPv6 can be used securely.=0A= =0A= 4.1. Simple Gateway between Internet and Internal Network=0A= =0A= As a simple gateway, the device manages both packet routing and local=0A= address management. A basic IPv6 router should have a default=0A= configuration to advertise inside the site a locally generated random=0A= ULA prefix, independently from the state of any external=0A= connectivity. This would allow local nodes to communicate amongst=0A= themselves independent of the state of a global connection. If the=0A= network happened to concatenate with another local network, the=0A= randomness in ULA creation is highly unlikely to result in address=0A= collisions.=0A= =0A= With external connectivity the simple gateway should use DHCP-PD to=0A= acquire a routing prefix from the service provider for use when=0A= connecting to the global Internet. End-system connections involving=0A= other nodes on the global Internet will always use the global IPv6=0A= addresses derived from this prefix delegation. It should be noted=0A= that the address selection policy table in end-systems defined in RFC=0A= 3484 should be configured to prefer the ULA prefix range over the=0A= DHCP-PD prefix range when the goal is to keep local communications=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 14]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= stable during periods of transient external connectivity.=0A= =0A= In the very simple case there is no explicit routing protocol on=0A= either side of the gateway, and a single default route is used=0A= internally pointing out to the global Internet. A slightly more=0A= complex case might involve local internal routing protocols, but with=0A= the entire local network sharing a common global prefix there would=0A= still not be a need for an external routing protocol as the service=0A= provider could install a route for the delegated prefix pointing=0A= toward the connecting link.=0A= =0A= 4.2. IPv6 and Simple Security=0A= =0A= The vulnerability of an IPv6 host is similar to that of an IPv4 host=0A= directly connected towards the Internet. The use of firewall and=0A= Intrusion Detection Systems (IDS) is recommended for those that want=0A= boundary protection in addition to host defences. A proxy may be=0A= used for certain applications, but with the caveat that the end to=0A= end transparency is broken. However, with IPv6, the following=0A= protections are available without the use of NAT while maintaining=0A= end-to-end reachability:=0A= 1. Short lifetimes on privacy extension suffixes reduce the attack=0A= profile since the node will not respond to the address once its=0A= lifetime becomes invalid.=0A= 2. IPsec is a mandatory service for IPv6 implementations. IPsec=0A= functions to prevent session hijacking, prevent content=0A= tampering, and optionally masks the packet contents. While IPsec=0A= works the same way and might be available in IPv4=0A= implementations, deployment in NAT environments either breaks the=0A= protocol or requires complex helper services with limited=0A= functionality or efficiency.=0A= 3. The size of the address space of a typical subnet (64 bits of=0A= IID) will make a complete subnet ping sweep virtually impossible=0A= due to the number of possible combinations available. Reducing=0A= the security threat of port scans on identified nodes requires=0A= sparse distribution within the subnet to minimize the list of=0A= known nodes. Provided that IIDs are essentially randomly=0A= distributed across the available space, address scanning based=0A= attacks will fail. This protection exists if the attacker has no=0A= direct access to the specific subnet. If an attacker has local=0A= access then he could use ND [3] and ping6 to the link-scope=0A= multicast ff02::1 to detect local neighbors. (Of course, a=0A= locally connected attacker has many scanning options with IPv4 as=0A= well.) This scanning protection will also be nullified if IIDs=0A= are configured in a group near the start of the IID space.=0A= =0A= Assuming the network administrator is aware of [18]the increased size=0A= of the IPv6 address will make topology probing much harder, and=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 15]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= almost impossible for IPv6 devices. The intention of topology=0A= probing is to identify a selection of the available hosts inside an=0A= enterprise. This mostly starts with a ping-sweep. Since the IPv6=0A= subnets are 64 bits worth of address space, this means that an=0A= attacker has to send out a simply unrealistic number of pings to map=0A= the network, and virus/worm propagation will be thwarted in the=0A= process. At full rate 40Gbps (400 times the typical 100Mbps LAN, and=0A= 13,000 times the typical DSL/Cable access link) it takes over 5000=0A= years to scan a single 64 bit space.=0A= =0A= IPv4 NAT was not developed as a security mechanism. Despite=0A= marketing messages to the contrary it is not a security mechanism,=0A= and hence it will offer some security holes while many people assume=0A= their network is secure due to the usage of NAT. IPv6 security best=0A= practices will avoid this kind of illusory security but can only=0A= address the same threats if correctly configured firewalls and IDS=0A= systems are used at the perimeter where some IPv4 networks have=0A= relied on NATs.=0A= =0A= It must be noted that even a firewall doesn't fully secure a network.=0A= Many attacks come from inside or are at a layer higher than the=0A= firewall can protect against. In the final analysis, every system=0A= has to be responsible for its own security, and every process running=0A= on a system has to be robust in the face of challenges like stack=0A= overflows etc. What a firewall does is prevent a network=0A= administration from having to pay for bandwidth to carry unauthorized=0A= traffic, and in so doing reduce the probability of certain kinds of=0A= attacks across the protected boundary.=0A= =0A= To implement simple security for IPv6 in, for example, a DSL=0A= connected home network, the DSL broadband gateway/router should be=0A= equipped with stateful firewall capabilities. These should provide a=0A= default configuration where incoming traffic is limited to return=0A= traffic resulting from outgoing packets (sometimes known as=0A= reflective session state). There should also be an easy interface=0A= which allows users to create inbound 'pinholes' for specific purposes=0A= such as online-gaming. Another consideration would be the capability=0A= for service provider mediated pinhole management where things like=0A= voice call signalling could dynamically establish pinholes based on=0A= predefined rules.=0A= =0A= Administrators and the designers of configuration interfaces for=0A= simple IPv6 Firewalls need to provide a means of documenting the=0A= security caveats that arise from a given set configuration rules so=0A= that users (who are normally oblivious to such things) can be made=0A= aware of the risks. As rules are improved iteratively, the goal will=0A= be to make use of the IPv6 Internet more secure for oblivious users.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 16]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 4.3. User/Application Tracking=0A= =0A= IPv6 enables the collection of information about data flows. Due to=0A= the fact that all addresses used for Internet and intra-/inter-site=0A= communication are unique, it is possible for an enterprise or ISP to=0A= get very detailed information on any communication exchange between=0A= two or more devices. This enhances the capability of data-flow=0A= tracking for security audits compared with IPv4 NAT, because in IPv6=0A= a flow between a sender and receiver will always be uniquely=0A= identified due to the unique IPv6 source and destination addresses.=0A= =0A= At the same time, this tracking is per address. In environments=0A= where the goal is tracking back to the user, additional external=0A= information will be necessary coorelating a user with an address. In=0A= the case of short lifetime privacy address usage, this external=0A= information will need to be based on more stable information such as=0A= the layer 2 media address.=0A= =0A= 4.4. Privacy and Topology Hiding using IPv6=0A= =0A= Partial host privacy is achieved in IPv6 using pseudo-random privacy=0A= addresses [RFC 3041] which are generated as required, so that a=0A= session can use an address that is valid only for a limited time.=0A= This only allows such a session to be traced back to the subnet that=0A= originates it, but not immediately to the actual host, where IPv4 NAT=0A= is only tracable to the most public NAT interface.=0A= =0A= Due to the large IPv6 address space available there is plenty of=0A= freedom to randomize subnet allocations. By doing this, it is=0A= possible to reduce the correlation between a subnet and its location.=0A= When doing both subnet and IID randomization [RFC 3041] a casual=0A= snooper won't be able to deduce much about the networks topology.=0A= The obtaining of a single address will tell the snooper very little=0A= about other addresses. This is different from IPv4 where address=0A= space limitations cause this to be not true. In most usage cases=0A= this concept should be sufficient for address privacy and topology=0A= hiding, with the cost being a more complex internal routing=0A= configuration.=0A= =0A= In the case where a network administrator wishes to fully isolate the=0A= internal IPv6 topology, and the majority of its host computer=0A= addresses, a possible option is to run all internal traffic using=0A= Unique Local Addresses (ULA) since by definition external traffic=0A= will never reach the site. For the set of hosts that do in fact need=0A= to interact externally, by using multiple IPv6 addresses (ULAs and=0A= one or more global addresses), it will be possible to hide and mask=0A= some or all of the internal network. As discussed in Section 3.1,=0A= there are multiple parts to the IPv6 address, and different=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 17]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= techniques to manage privacy for each which may be combined to=0A= protect the entire address.=0A= =0A= There are other possible scenarios for the extreme situation when a=0A= network manager also wishes to fully conceal the internal IPv6=0A= topology. In these cases the goal in replacing the IPv4 NAT approach=0A= is to make all of the topology hidden nodes appear from the outside=0A= to exist at the edge of the network, just as they would when behind a=0A= NAT.=0A= =0A= o One could use explicit host routes and remove the correlation=0A= between location and IPv6 address. In the figure below the hosts=0A= would be allocated prefixes from one or more logical subnets, and=0A= would inject host routes to internally identify their real=0A= attachment point. This solution does however show severe=0A= scalability issues and should be limited to uses with=0A= substantially fewer than the maximum number of routes that the IGP=0A= can support (generally about 50,000).=0A= o Another technology to fully hide the internal topology would be to=0A= use a tunneling mechanism. Mobile IPv6 without route optimization=0A= is one example. In this example the public facing addresses are=0A= indirected via the edge Home Agent (HA). This indirection method=0A= truly masks the internal topology as all nodes with global access=0A= appear to share the prefix of one or more logical subnets attached=0A= to the HA. While turning off all binding updates would appear to=0A= be necessary to prevent leakage of topology information, that=0A= approach would also force all internal traffic to route via the HA=0A= tunnel. A better method would be to allow internal route=0A= optimizations while dropping outbound binding updates at the=0A= firewall. The downsides of using this tunneling method is that it=0A= makes usage of middleware like a Home Agent (HA) and consumes=0A= slightly more bandwidth for the tunnel overhead.=0A= o Another method where the layer 2 topology allows would be to use a=0A= virtual lan approach to logically attach the devices to one or=0A= more subnets on the edge router. The downsides of this approach=0A= is that all internal traffic would be directed over sub-optimal=0A= paths via the edge router, as well as the complexity of managing a=0A= distributed logical lan.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 18]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Internet=0A= |=0A= \=0A= |=0A= +------------------+=0A= | Simple Gateway | Logical subnet=0A= | or Home Agent |-+-+-+-+-+-+-+-+--=0A= +------------------+ for topology=0A= | hidden nodes=0A= |=0A= Real internal -------------+-=0A= topology | |=0A= | -+----------=0A= -----------+--------+=0A= |=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 4.5. Independent Control of Addressing in a Private Network=0A= =0A= IPv6 provides for autonomy in local use addresses through ULAs. At=0A= the same time IPv6 simplifies simultaneous use of multiple addresses=0A= per interface so that an IPv6 NAT is not required between the ULA and=0A= the public Internet because nodes that need access to the public=0A= Internet will have a global use address as well. When using IPv6,=0A= the need to ask for more address space will become far less likely=0A= due to the increased size of the subnets, along with an allocation=0A= policy that recognizes table fragmentation is also an important=0A= consideration. While global IPv6 allocation policy is managed=0A= through the Regional Internet Registries, it is expected that they=0A= will continue with derivatives of [8] for the foreseeable future so=0A= the number of subnet prefixes available to an organization should not=0A= be a limitation which would create an artifical demand for NAT.=0A= =0A= The ongoing subnet size maintenance may become simpler when IPv6=0A= technology is utilised. Under IPv4 address space policy=0A= restrictions, each subnet must be optimised so one has to look=0A= periodically into the number of hosts on a segment and the subnet=0A= size allocated to the segment and rebalance. For example an=0A= enterprise today may have a mix of /28 - /23 size subnets, and may=0A= shrink/grow these as their network user base changes. For IPv6 all=0A= subnets have /64 prefixes which will reduce the operational and=0A= configuration overhead.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 19]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 4.6. Global Address Pool Conservation=0A= =0A= IPv6 provides sufficient space to completely avoid the need for=0A= overlapping address space with the total possible addresses being=0A= 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38).=0A= Since allocations in IPv6 are based on subnets rather than hosts a=0A= more reasonable way to look at the pool is that there are about=0A= 17,293,822,569,102,704,640 (17*10^18) unique subnet values where=0A= sparse allocation practice within those provdes for new opportunities=0A= such as . As previously discussed, the serious disadvantages of=0A= ambiguous address space have been well documented, and with=0A= sufficient space there is no need to continue the increasingly=0A= aggressive conservation practices that are necessary with IPv4.=0A= While IPv6 allocation policies and ISP business practice will=0A= continue to evolve, the recommendations in RFC 3177 are based on the=0A= technical potential of the vast IPv6 address space. That document=0A= demonstrates that there is no resource limitation which will require=0A= the adoption of the IPv4 workaround of ambiguous space behind a NAT.=0A= As an example of the direct contrast, many expansion oriented IPv6=0A= deployment scenarios result in multiple IPv6 addresses per device, as=0A= opposed to the constriction of IPv4 scenarios where multiple devices=0A= are forced to share a scarce global address through a NAT.=0A= =0A= 4.7. Multihoming and Renumbering=0A= =0A= Multihoming and renumbering remain technically challenging with IPv6=0A= (see the Gap Analysis below). However, IPv6 was designed to allow=0A= sites and hosts to run with several simultaneous CIDR allocated=0A= prefixes, and thus with several simultaneous ISPs. An address=0A= selection mechanism [10] is specified so that hosts will behave=0A= consistently when several addresses are simultaneously valid. The=0A= fundamental difficulty that IPv4 has in regard to multiple addresses=0A= therefore does not apply to IPv6. IPv6 sites can and do run today=0A= with multiple ISPs active, and the processes for adding and removing=0A= active prefixes at a site have been documented in [12] and [19].=0A= =0A= The IPv6 address space allocated by the ISP will be dependent upon=0A= the connecting Service provider. This will likely result in a=0A= renumbering effort when the network changes between service=0A= providers. When changing ISPs or ISPs readjusting their addressing=0A= pool, DHCP-PD [11] can be used as an almost zero-touch external=0A= mechanism for prefix change in conjunction with a ULA prefix for=0A= internal connection stability. With appropriate management of the=0A= lifetime values and overlap of the external prefixes, a smooth make-=0A= before-break transition is possible as existing communications will=0A= continue on the old prefix as long as it remains valid, while any new=0A= communications will use the new prefix.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 20]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 5. Case Studies=0A= =0A= In presenting these case studies we have chosen to consider=0A= categories of network divided first according to their function=0A= either as carrier/ISP networks or end user (such as enterprise)=0A= networks with the latter category broken down according to the number=0A= of connected end hosts. For each category of networks we can use=0A= IPv6 Network Architecture Protection to achieve a secure and flexible=0A= infrastructure, which provides an enhanced network functionality in=0A= comparison with the usage of address translation.=0A= =0A= o Medium/Large Private Networks (typically >10 connections)=0A= o Small Private Networks (typically 1 to 10 connections)=0A= o Single User Connection (typically 1 connection)=0A= o ISP/Carrier Customer Networks=0A= =0A= =0A= 5.1. Medium/large private networks=0A= =0A= The majority of private enterprise networks fall into this category.=0A= Many of these networks have one or more exit points to the Internet.=0A= Though these organizations have sufficient resources to acquire=0A= addressing independence when using IPv4 there are several reasons why=0A= they might choose to use NAT in such a network. For the ISP there is=0A= no need to import the IPv4 address range from the remote end-=0A= customer, which facilitates IPv4 route summarization. The customer=0A= can use a larger IPv4 address range (probably with less-=0A= administrative overhead) by the use of RFC 1918 and NAT. The=0A= customer also reduces the overhead in changing to a new ISP, because=0A= the addresses assigned to devices behind the NAT do not need to be=0A= changed when the customer is assigned a different address by a new=0A= ISP. By using address translation in IPv4 one avoids the expensive=0A= process of network renumbering. Finally, the customer can provide=0A= privacy for its hosts and the topology of its internal network if the=0A= internal addresses are mapped through NAT.=0A= =0A= It is expected that there will be enough IPv6 addresses available for=0A= all networks and appliances for the foreseeable future. The basic=0A= IPv6 address range an ISP allocates for a private network is large=0A= enough (currently /48) for most of the medium and large enterprises,=0A= while for the very large private enterprise networks address-ranges=0A= can be concatenated. The goal of this assignment mechanism is to=0A= decrease the total amount of entries in the public Internet routing=0A= table. A single /48 allocation provides an enterprise network with=0A= 65536 different /64 subnet prefixes.=0A= =0A= To mask the identity of a user on a network of this type, the usage=0A= of IPv6 privacy extensions may be advised. This technique is useful=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 21]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= when an external element wants to track and collect all information=0A= sent and received by a certain host with known IPv6 address. Privacy=0A= extensions add a random time-limited factor to the host part of an=0A= IPv6 address and will make it very hard for an external element to=0A= keep correlating the IPv6 address to a specific host on the inside=0A= network. The usage of IPv6 privacy extensions does not mask the=0A= internal network structure of an enterprise network.=0A= =0A= If there is need to mask the internal structure towards the external=0A= IPv6 Internet, then some form of 'untraceable' addresses may be used.=0A= These addresses will be derived from a local pool, and may be=0A= assigned to those hosts for which topology masking is required or=0A= which want to reach the IPv6 Internet or other external networks.=0A= The technology to assign these addresses to the hosts could be based=0A= on DHCPv6 or static configuration. To complement the 'Untraceable'=0A= addresses it is needed to have at least awareness of the IPv6 address=0A= location when routing an IPv6 packet through the internal network.=0A= This could be achieved by 'route-injection' in the local network=0A= infrastructure. This route-injection could be done based on /128=0A= host-routes to each device that wants to connect to the Internet=0A= using an untraceable address. This will provide the most dynamic=0A= masking, but will have a scalability limitation, as an IGP is=0A= typically not designed to carry many thousands of IPv6 prefixes. A=0A= large enterprise may have thousands of hosts willing to connect to=0A= the Internet.=0A= =0A= An alternative for larger deployments is to leverage the tunneling=0A= aspect of MIPv6 even for non-mobile devices. With the logical subnet=0A= being allocated as attached to the edge Home Agent, the real=0A= attachment and internal topology are masked from the outside.=0A= Dropping outbound binding updates at the firewall is also necessary=0A= to avoid leaking the attachment information.=0A= =0A= Less flexible masking could be to have time-based IPv6 prefixes per=0A= link or subnet. This may reduce the amount of route entries in the=0A= IGP by a significant factor, but has as trade-off that masking is=0A= time and subnet based.The dynamic allocation of 'Untraceable'=0A= addresses can also limit the IPv6 access between local and external=0A= hosts to those local hosts being authorized for this capability.=0A= Dynamically allocated 'Untraceable' addresses may also facilitate and=0A= simplify the connectivity to the outside networks during renumbering,=0A= because the existing IPv6 central address pool could be swapped for=0A= the newly allocated IPv6 address pool.=0A= =0A= The use of permanent ULA addresses on a site provides the benefit=0A= that even if an enterprise would change its ISP, the renumbering will=0A= only affect those devices that have a wish to connect beyond the=0A= site. Internal servers and services would not change their allocated=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 22]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= IPv6 ULA address, and the service would remain available even during=0A= global address renumbering.=0A= =0A= 5.2. Small Private Networks=0A= =0A= Also known as SOHO (Small Office/Home Office) networks, this category=0A= describes those networks which have few routers in the topology, and=0A= usually have a single network egress point. Typically these networks=0A= are:=0A= =0A= o connected via either a dial-up connection or broadband access=0A= o don't have dedicated Network Operation Center (NOC)=0A= o and through economic pressure are typically forced today to use=0A= NAT=0A= =0A= In most cases the received global IPv4 prefix is not fixed over time=0A= and is too long (very often just a /32 just giving a single address)=0A= to provide every node in the private network with a unique globally=0A= usable address. Fixing either of those issues typically adds an=0A= administrative overhead for address management to the user. This=0A= category may even be limited to receiving ambiguous IPv4 addresses=0A= from the service provider based on RFC 1918. An ISP will typically=0A= pass along the higher administration cost attached to larger address=0A= blocks, or IPv4 prefixes that are static over time, due to the larger=0A= public address pool each of those requires.=0A= =0A= As a direct response to explicit charges per public address most of=0A= this category has deployed NAPT (port demultiplexing NAT) to minimize=0A= the number of addresses in use. Unfortunately this also limits the=0A= Internet capability of the equipment to being mainly a receiver of=0A= Internet data (client), and makes it quite hard for the equipment to=0A= become a world wide Internet server (i.e. HTTP, FTP, etc.) due to=0A= the stateful operation of the NAT equipment. Even when there is=0A= sufficient technical knowledge to manage the NAT to enable external=0A= access to a server, only one server can be mapped per protocol/port=0A= number per address, and then only when the address from the ISP is=0A= public. When there is an upstream NAT providing private address=0A= space to the ISP side of the private NAT, additional negotiation with=0A= the ISP will be necessary to provide an inbound mapping, if that is=0A= even possible.=0A= =0A= When deploying IPv6 NAP in this environment, there are two approaches=0A= possible with respect to IPv6 addressing.=0A= o DHCPv6 Prefix-Delegation=0A= o ISP provides a static IPv6 address-range=0A= =0A= For the DHCPv6-PD solution, a dynamic address allocation approach is=0A= chosen. By means of the enhanced DHCPv6 protocol it is possible to=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 23]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= have the ISP push down an IPv6 prefix range automatically towards the=0A= small private network and populate all interfaces in that small=0A= private network dynamically. This reduces the burden for=0A= administrative overhead because everything happens automatically.=0A= =0A= For the static configuration the mechanisms used could be the same as=0A= for the medium/large enterprises. Typically the need for masking the=0A= topology will not be of high priority for these users, and the usage=0A= of IPv6 privacy extensions could be sufficient.=0A= =0A= For both alternatives the ISP has the unrestricted capability for=0A= summarization of its RIR allocated IPv6 prefix, while the small=0A= private network administrator has all flexibility in using the=0A= received IPv6 prefix to its advantage because it will be of=0A= sufficient size to allow all the local nodes to have a public address=0A= and full range of ports available whenever necessary.=0A= =0A= While a full prefix is expected to be the primary deployment model=0A= there may be cases where the ISP provides a single IPv6 address for=0A= use on a single piece of equipment (PC, PDA, etc.). This is expected=0A= to be rare though, because in the IPv6 world the assumption is that=0A= there is an unrestricted availability of a large amount of globally=0A= routable and unique address space. If scarcity was the motivation=0A= with IPv4 to provide RFC 1918 addresses, in this environment the ISP=0A= will not be motivated to allocate private addresses towards the=0A= single user connection because there are enough global addresses=0A= available at essentially the same cost. Also it will be likely that=0A= the single device wants to mask its identity to the called party or=0A= its attack profile over a shorter time window than the life of the=0A= ISP attachment, so it will need to enable IPv6 privacy extensions=0A= which in turn leads to the need for a minimum allocation of a /64=0A= prefix rather than a single address.=0A= =0A= 5.3. Single User Connection=0A= =0A= This group identifies the users which are connected via a single IPv4=0A= address and use a single piece of equipment (PC, PDA, etc.). This=0A= user may get an ambiguous IPv4 address (frequently imposed by the=0A= ISP) from the service provider which is based on RFC 1918. If=0A= ambiguous addressing is utilized, the service provider will execute=0A= NAT on the allocated IPv4 address for global Internet connectivity.=0A= This also limits the internet capability of the equipment to being=0A= mainly a receiver of Internet data, and makes it quite hard for the=0A= equipment to become a world wide internet server (i.e. HTTP, FTP,=0A= etc.) due to the stateful operation of the NAT equipment.=0A= =0A= When using IPv6 NAP, this group will identify the users which are=0A= connected via a single IPv6 address and use a single piece of=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 24]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= equipment (PC, PDA, etc.).=0A= =0A= In IPv6 world the assumption is that there is unrestricted=0A= availability of a large amount of globally routable and unique IPv6=0A= addresses. The ISP will not be motivated to allocate private=0A= addresses towards the single user connection because he has enough=0A= global addresses available, if scarcity was the motivation with IPv4=0A= to provide RFC 1918 addresses. If the single user wants to mask his=0A= identity, he may choose to enable IPv6 privacy extensions.=0A= =0A= 5.4. ISP/Carrier Customer Networks=0A= =0A= This group refers to the actual service providers that are providing=0A= the IP access and transport services. They tend to have three=0A= separate IP domains that they support:=0A= o For the first they fall into the Medium/large private networks=0A= category (above) for their own internal networks, LANs etc.=0A= o The second is the Operations network which addresses their=0A= backbone and access switches, and other hardware, this is separate=0A= for both engineering reasons as well as simplicity in managing the=0A= security of the backbone.=0A= o The third is the IP addresses (single or blocks) that they assign=0A= to customers. These can be registered addresses (usually given to=0A= category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of=0A= RFC 1918 addresses used with IPv4 NAT for single user connections.=0A= Therefore they can actually have two different NAT domains that=0A= are not connected (internal LAN and single user customers).=0A= =0A= When IPv6 NAP is utilized in these three domains then for the first=0A= category it will be possible to use the same solutions as described=0A= in Section 5.1. The second domain of the ISP/carrier is the=0A= Operations network. This environment tends to be a closed=0A= environment, and consequently communication can be done based on ULA=0A= addresses, however, in this environment, stable IPv6 Provider=0A= Independent addresses can be used. This would give a solid and=0A= scalable configuration with respect to a local IPv6 address plan. By=0A= the usage of proper network edge filters, outside access to the=0A= closed environment can be avoided. The third is the IPv6 addresses=0A= that ISP/carrier network assign to customers. These will typically=0A= be assigned with prefix lengths terminating on nibble boundaries to=0A= be consistent with the DNS PTR records. As scarcity of IPv6=0A= addresses is not a concern, it will be possible for the ISP to=0A= provide global routable IPv6 prefixes without a requirement for=0A= address translation. An ISP may for commercial reasons still decide=0A= to restrict the capabilities of the end users by other means like=0A= traffic and/or route filtering etc.=0A= =0A= If the carrier network is a mobile provider, then IPv6 is encouraged=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 25]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= in comparison with the combination of IPv4+NAT for 3GPP attached=0A= devices. When looking in chapter 2.3 of RFC3314 'Recommendations for=0A= IPv6 in 3GPP Standards' [15] it is found that the IPv6 WG recommends=0A= that one or more /64 prefixes should be assigned to each primary PDP=0A= context. This will allow sufficient address space for a 3GPP-=0A= attached node to allocate privacy addresses and/or route to a multi-=0A= link subnet, and will discourage the use of NAT within 3GPP-attached=0A= devices.=0A= =0A= =0A= 6. IPv6 Gap Analysis=0A= =0A= Like IPv4 and any major standards effort, IPv6 standardization work=0A= continues as deployments are ongoing. This section discusses several=0A= topics for which additional standardization, or documentation of best=0A= practice, is required to fully realize the benefits of NAP. None of=0A= these items are show-stoppers for immediate usage of NAP in roles=0A= where there are no current gaps.=0A= =0A= 6.1. Subnet Topology Masking=0A= =0A= There really is no functional gap here as a centrally assigned pool=0A= of addresses in combination with host routes in the IGP is an=0A= effective way to mask topology for smaller deployments. If necessary=0A= a best practice document could be developed describing the=0A= interaction between DHCP and various IGPs which would in effect=0A= define Untraceable Addresses.=0A= =0A= As an alternative for larger deployments, there is no gap in the HA=0A= tunneling approach when firewalls are configured to block outbound=0A= binding update messages. A border Home Agent using internal=0A= tunneling to the logical mobile node (potentially rack mounted) can=0A= completely mask all internal topology, while avoiding the strain from=0A= a large number of host routes in the IGP. Some optimization work=0A= could be done in Mobile IP to define a policy message where a mobile=0A= node would learn from the Home Agent that it should not try to inform=0A= its correspondent about route optimization and thereby expose its=0A= real location. This optimization which reduces the load on the=0A= firewall would result in less optimal internal traffic routing as=0A= that would also transit the HA. This optimization work should be=0A= pursued in the IETF.=0A= =0A= 6.2. Minimal Traceability of Privacy Addresses=0A= =0A= Privacy addresses (RFC 3041) may certainly be used to limit the=0A= traceability of external traffic flows back to specific hosts, but=0A= lacking a topology masking component above they would still reveal=0A= the subnet address bits. For complete privacy a best practice=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 26]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= document describing the combination of privacy addresses with=0A= topology masking may be required. This work remains to be done, and=0A= should be pursued by the IETF.=0A= =0A= 6.3. Renumbering Procedure=0A= =0A= Site renumbering procedures are discussed in [12]. It should also be=0A= noticed that ULAs may help here too, since a change of ISP prefix=0A= will only affect hosts that are communicating externally.=0A= =0A= 6.4. Site Multihoming=0A= =0A= This complex problem has never been completely solved for IPv4, which=0A= is exactly why NAT has been used as a partial solution. For IPv6,=0A= after several years of work, the IETF has converged on an=0A= architectural approach intended with service restoration as initial=0A= aim [20]. Again, ULAs may help since they will provide stable=0A= addressing for internal communications that are not affected by=0A= multihoming.=0A= =0A= 6.5. Untraceable Addresses=0A= =0A= The details of the untraceable addresses, along with any associated=0A= mechanisms such as route injection, must be worked out and specified.=0A= =0A= =0A= 7. IANA Considerations=0A= =0A= This document requests no action by IANA=0A= =0A= =0A= 8. Security Considerations=0A= =0A= While issues which are potentially security related are discussed=0A= throughout the document, the approaches herein do not introduce any=0A= new security concerns. Product marketing departments have widely=0A= sold IPv4 NAT as a security tool and suppliers have been implementing=0A= address translation functionality in their firewalls, though the=0A= misleading nature of those claims has been previously documented in=0A= [2] and [4].=0A= =0A= This document defines IPv6 approaches which collectively achieve the=0A= goals of the network manager without the negative impact on=0A= applications or security that are inherent in a NAT approach. To the=0A= degree that these techniques improve a network manager's ability to=0A= explicitly know about or control access, and thereby manage the=0A= overall attack exposure of local resources, they act to improve local=0A= network security. In particular the explicit nature of a content=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 27]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= aware firewall in NAP will be a vast security improvement over the=0A= NAT artifact where lack of translation state has been widely sold as=0A= a form of protection.=0A= =0A= =0A= 9. Conclusion=0A= =0A= This document has described a number of techniques that may be=0A= combined on an IPv6 site to protect the integrity of its network=0A= architecture. These techniques, known collectively as Network=0A= Architecture Protection, retain the concept of a well defined=0A= boundary between "inside" and "outside" the private network, and=0A= allow firewalling, topology hiding, and privacy. However, because=0A= they preserve address transparency where it is needed, they achieve=0A= these goals without the disadvantage of address translation. Thus,=0A= Network Architecture Protection in IPv6 can provide the benefits of=0A= IPv4 Network Address Translation without the corresponding=0A= disadvantages.=0A= =0A= The document has also identified a few ongoing IETF work items that=0A= are needed to realize 100% of the benefits of NAP.=0A= =0A= =0A= 10. Acknowledgements=0A= =0A= Christian Huitema has contributed during the initial round table to=0A= discuss the scope and goal of the document, while the European Union=0A= IST 6NET project acted as a catalyst for the work documented in this=0A= note. Editorial comments and contributions have been received from:=0A= Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar,=0A= Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark=0A= Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith,=0A= Elwyn Davies, Daniel Senie, Soininen Jonne, Lindqvist Erik Kurt and=0A= other members of the v6ops WG.=0A= =0A= =0A= 11. References=0A= =0A= 11.1. Normative References=0A= =0A= [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.=0A= Lear, "Address Allocation for Private Internets", BCP 5,=0A= RFC 1918, February 1996.=0A= =0A= [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator=0A= (NAT) Terminology and Considerations", RFC 2663, August 1999.=0A= =0A= [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 28]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= for IP Version 6 (IPv6)", RFC 2461, December 1998.=0A= =0A= [4] Hain, T., "Architectural Implications of NAT", RFC 2993,=0A= November 2000.=0A= =0A= [5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address=0A= Translator (Traditional NAT)", RFC 3022, January 2001.=0A= =0A= [6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the=0A= IP Network Address Translator", RFC 3027, January 2001.=0A= =0A= [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless=0A= Address Autoconfiguration in IPv6", RFC 3041, January 2001.=0A= =0A= [8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address=0A= Allocations to Sites", RFC 3177, September 2001.=0A= =0A= [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.=0A= Carney, "Dynamic Host Configuration Protocol for IPv6=0A= (DHCPv6)", RFC 3315, July 2003.=0A= =0A= [10] Draves, R., "Default Address Selection for Internet Protocol=0A= version 6 (IPv6)", RFC 3484, February 2003.=0A= =0A= [11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host=0A= Configuration Protocol (DHCP) version 6", RFC 3633,=0A= December 2003.=0A= =0A= [12] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering=0A= an IPv6 Network without a Flag Day", RFC 4192, September 2005.=0A= =0A= [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast=0A= Addresses", RFC 4193, October 2005.=0A= =0A= 11.2. Informative References=0A= =0A= [14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-=0A= Domain Routing (CIDR): an Address Assignment and Aggregation=0A= Strategy", RFC 1519, September 1993.=0A= =0A= [15] Wasserman, M., "Recommendations for IPv6 in Third Generation=0A= Partnership Project (3GPP) Standards", RFC 3314,=0A= September 2002.=0A= =0A= [16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point=0A= (RP) Address in an IPv6 Multicast Address", RFC 3956,=0A= November 2004.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 29]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= [17] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful=0A= (draft-dupont-ipv6-rfc3041harmful-05.txt)", June 2004.=0A= =0A= [18] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown-=0A= v6ops-port-scanning-implications-01.txt)", July 2004.=0A= =0A= [19] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to=0A= think about when Renumbering an IPv6 network=0A= (draft-chown-v6ops-renumber-thinkabout-03)", October 2004.=0A= =0A= [20] Huston, G., "Architectural Commentary on Site Multi-homing=0A= using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)",=0A= July 2004.=0A= =0A= =0A= Appendix A. Additional Benefits due to Native IPv6 and Universal Unique=0A= Addressing=0A= =0A= The users of native IPv6 technology and global unique IPv6 addresses=0A= have the potential to make use of the enhanced IPv6 capabilities, in=0A= addition to the benefits offered by the IPv4 technology.=0A= =0A= A.1. Universal Any-to-Any Aonnectivity=0A= =0A= One of the original design points of the Internet was any-to-any=0A= connectivity. The dramatic growth of Internet connected systems=0A= coupled with the limited address space of the IPv4 protocol spawned=0A= address conservation techniques. NAT was introduced as a tool to=0A= reduce demand on the limited IPv4 address pool, but the side effect=0A= of the NAT technology was to remove the any-to-any connectivity=0A= capability. By removing the need for address conservation (and=0A= therefore NAT), IPv6 returns the any-to-any connectivity model and=0A= removes the limitations on application developers. With the freedom=0A= to innovate unconstrained by NAT traversal efforts, developers will=0A= be able to focus on new advanced network services (i.e. peer-to-peer=0A= applications, IPv6 embedded IPsec communication between two=0A= communicating devices, instant messaging, Internet telephony, etc..)=0A= rather than focusing on discovering and traversing the increasingly=0A= complex NAT environment.=0A= =0A= It will also allow application and service developers to rethink the=0A= security model involved with any-to-any connectivity, as the current=0A= edge firewall solution in IPv4 may not be sufficient for Any-to-any=0A= service models.=0A= =0A= A.2. Auto-configuration=0A= =0A= IPv6 offers a scalable approach to minimizing human interaction and=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 30]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= device configuration. Whereas IPv4 implementations require touching=0A= each end system to indicate the use of DHCP vs. a static address and=0A= management of a server with the pool size large enough for the=0A= potential number of connected devices, IPv6 uses an indication from=0A= the router to instruct the end systems to use DHCP or the stateless=0A= auto configuration approach supporting a virtually limitless number=0A= of devices on the subnet. This minimizes the number of systems that=0A= require human interaction as well as improves consistency between all=0A= the systems on a subnet. In the case that there is no router to=0A= provide this indication, an address for use only on the local link=0A= will be derived from the interface media layer address.=0A= =0A= A.3. Native Multicast Services=0A= =0A= Multicast services in IPv4 were severely restricted by the limited=0A= address space available to use for group assignments and an implicit=0A= locally defined range for group membership. IPv6 multicast corrects=0A= this situation by embedding explicit scope indications as well as=0A= expanding to 4 billion groups per scope. In the source specific=0A= multicast case, this is further expanded to 4 billion groups per=0A= scope per subnet by embedding the 64 bits of subnet identifier into=0A= the multicast address.=0A= =0A= IPv6 allows also for innovative usage of the IPv6 address length, and=0A= makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)=0A= [16] directly in the IPv6 multicast address when using ASM multicast.=0A= this is not possible with limited size of the IPv4 address. This=0A= approach also simplifies the multicast model considerably, making it=0A= easier to understand and deploy.=0A= =0A= A.4. Increased Security Protection=0A= =0A= The security protection offered by native IPv6 technology is more=0A= advanced than IPv4 technology. There are various transport=0A= mechanisms enhanced to allow a network to operate more securely with=0A= less performance impact:=0A= o IPv6 has the IPsec technology directly embedded into the IPv6=0A= protocol. This allows for simpler peer-to-peer encryption and=0A= authentication, once a simple key/trust management model is=0A= developed, while the usage of some other less secure mechanisms is=0A= avoided (i.e. md5 password hash for neighbor authentication).=0A= o On a local network, any user will have more security awareness.=0A= This awareness will motivate the usage of simple firewall=0A= applications/devices to be inserted on the border between the=0A= external network and the local (or home network) as there is no=0A= Address Translater and hance no false safety perception.=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 31]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o All flows on the Internet will be better traceable due to a unique=0A= and globally routable source and destination IPv6 address. This=0A= may facilitate an easier methodology for back-tracing DoS attacks=0A= and avoid illegal access to network resources by simpler traffic=0A= filtering.=0A= o The usage of private address-space in IPv6 is now provided by=0A= Unique Local Addresses, which will avoid conflict situations when=0A= merging networks and securing the internal communication on a=0A= local network infrastructure due to simpler traffic filtering=0A= policy.=0A= o The technology to enable source-routing on a network=0A= infrastructure has been enhanced to allow this feature to=0A= function, without impacting the processing power of intermediate=0A= network devices. The only devices impacted with the source-=0A= routing will be the source and destination node and the=0A= intermediate source-routed nodes. This impact behavior is=0A= different if IPv4 is used, because then all intermediate devices=0A= would have had to look into the source-route header.=0A= =0A= A.5. Mobility=0A= =0A= Anytime, anywhere, universal access requires MIPv6 services in=0A= support of mobile nodes. While a Home Agent is required for initial=0A= connection establishment in either protocol version, IPv6 mobile=0A= nodes are able to optimize the path between them using the MIPv6=0A= option header while IPv4 mobile nodes are required to triangle route=0A= all packets. In general terms this will minimize the network=0A= resources used and maximize the quality of the communication.=0A= =0A= A.6. Merging Networks=0A= =0A= When two IPv4 networks want to merge it is not guaranteed that both=0A= networks would be using different address-ranges on some parts of the=0A= network infrastructure due to the usage of RFC 1918 private=0A= addressing. This potential overlap in address space may complicate a=0A= merge of two and more networks dramatically due to the additional=0A= IPv4 renumbering effort. i.e. when the first network has a service=0A= running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by=0A= the 2nd merging network. Similar address conflicts can happen when=0A= two network devices from these merging networks want to communicate.=0A= =0A= With the usage of IPv6 the addressing overlap will not exist because=0A= of the existence of the Unique Local Address usage for private and=0A= local addressing.=0A= =0A= A.7. Community of interest=0A= =0A= Although some Internet-enabled devices will function as fully-fledged=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 32]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Internet hosts, it is believed that many will be operated in a highly=0A= restricted manner functioning largely or entirely within a Community=0A= of Interest. By Community of Interest we mean a collection of hosts=0A= that are logically part of a group reflecting their ownership or=0A= function. Typically, members of a Community of Interest need to=0A= communicate within the community but should not be generally=0A= accessible on the Internet. They want the benefits of the=0A= connectivity provided by the Internet, but do not want to be exposed=0A= to the rest of the world. The ability in NAP to virtualize the=0A= topology to mask it is applied to the cluster, creating arbitrary=0A= groupings or communities. It will also allow to build virtual=0A= organization networks on the fly, which is very difficult to do in=0A= IPv4+NAT scenarios.=0A= =0A= =0A= Appendix B. Revision history=0A= =0A= B.1. Changes from *-vandevelde-v6ops-nap-00 to=0A= *-vandevelde-v6ops-nap-01=0A= o Document introduction has been revised and overview table added=0A= o Comments and suggestions from nap-00 draft have been included.=0A= o Initial section of -00 draft 2.6 and 4.6 have been aggregated into=0A= a new case study section 5.=0A= o The list of additional IPv6 benefits has been been placed into=0A= appendix.=0A= o new security considerations section added.=0A= o GAP analysis revised.=0A= o Section 2.6 and 4.6 have been included.=0A= =0A= B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00=0A= o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-ietf-=0A= v6ops-nap-00.txt.=0A= o Editorial changes.=0A= =0A= B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01=0A= o Added text in Chapter 2.2 and 4.2 to address more details on=0A= firewall and proxy=0A= o Revised Eric Klein contact details=0A= o Added note in 4.2 that control over the proposed statefull-filter=0A= should be by a simple user-interface=0A= =0A= B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02=0A= o General Note: Header more consistent capitelized.=0A= o Section 1: para 3: s/...and privacy and will... translation./=0A= ...and privacy. NAP will achieve these security goals without=0A= address transaltion whilst maintaining any-to-any connectivity./=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 33]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 1: Various editorial changes happened=0A= o Section 2.1: Changed: 'Frequently a simple user interface is=0A= sufficient for configuring'.into 'Frequently a simple user=0A= interface, or no user interface is sufficient'=0A= o Section 2.2: (Simple Security ) Better not to use the word -evil-=0A= in the text=0A= o Section 2.2: changed 'provided by NAT are actually ' into=0A= 'provided by NAT is actually'=0A= o Section 2.2: para 3: s/actually false/actually an illusion/=0A= o Section 2.2: para 2: added 'Also it will only be reliable if a=0A= mechanism such as 'trusted computing' is implemented in the end-=0A= system; without this enhancement administrators will be unwilling=0A= to trust the behavior of end-systems.=0A= o Section 2.3: para 1: s/of the NAT devices state/from the NAT=0A= device's state/=0A= o Section 2.4: para1: clarified the definition of topology hiding=0A= o Section 2.4: last sentence of next-to-last paragraph, added=0A= punctuation at end of sentence.=0A= o Section 2.4: added first line: When mentioning 'topology hiding'=0A= the goal is to make a reference that an entity outside the network=0A= can not make a correlation between the location of a device and=0A= the address of a device on the local network.=0A= o Section 2.4: para 1: s/reflected/represented/=0A= o Section 2.5: last par: added reference: 'Section 2.7 describes=0A= some disadvantages that appear if independednt networks using=0A= [RFC1918] addresses have to be merged.'=0A= o Section 2.6: Added text that private address-space is not=0A= limitless=0A= o Section 2.6: Various editorial changes=0A= o Section 2.7: Para 1 editorial revised=0A= o Section 2.7: last para: s/This solution/The addition of an extra=0A= NAT as a solution/=0A= o Section 2.7: s/highly desirable to be/highly desirable due to=0A= resiliency and load-balancing to be/=0A= o Section 2.7: added text on the reason why there are overlapping=0A= addresses=0A= o Section 2.7: last para: s/merged address space/overlapping address=0A= speaces in the merged networks/=0A= o Section 3.1: Para 1 editorial changes=0A= o Section 3.1: s/by contacted web sites, so IPv6/by web sites that=0A= are accessed from the device: IPv6 /=0A= o Section 3.1: s/as that would have a serious negative impact on=0A= global routing/as that would have a negative effect on global=0A= route aggregation=0A= o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in=0A= global routing table is not scalable=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 34]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 3.2: s3.2: Noted that it is not always interresting to mix=0A= ULA with global as that may lead to SAS issues=0A= o Section 3.3: last para: s/delegating router/delegating router=0A= (incorporating a DHCPv6 server)/, s/across an administrative/=0A= possibly across an administrative/=0A= o Section 3.4: Changed: 'random assignment has as purpose' to=0A= 'random assignment has a purpose'=0A= o Section 3.4: para 2: Replace first sentence with: 'The random=0A= assignment is intended to mislead the outside world about the=0A= structure of the local network.'=0A= o Section 3.4: para 2: s/there is a correlation/needs to maintain a=0A= correlation/=0A= o Section 3.4: para 2: s/like a/such as a/=0A= o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from=0A= mapping/and from mapping of/=0A= o Section 3.4: para 3: s/are reachable on/are allocated to devices=0A= on/=0A= o Section 3.4: para 3: s/belonging to the same subnet next to each=0A= other/belonging to devices adjacent to each other on the same=0A= subnet/=0A= o Section 3.4: s/aggregation device/indirection device/=0A= o Section 4.1: splitted the 1 section up into 2 separate sections=0A= o Section 4.1: s/ End node connections involving other nodes on the=0A= global Internet will always use the global IPv6 addresses [9]=0A= derived from this prefix delegation./ End node connections=0A= involving other nodes on the global Internet will always use the=0A= global IPv6 addresses [9] derived from this prefix delegation. It=0A= should be noted that the policy table needs to be correctly set up=0A= so that true global prefixes are distinguished from ULAs and will=0A= be used for the source address in preference when the destination=0A= is not a ULA/=0A= o Section 4.1: A more secure network environment can be established=0A= by having the referenced ULA addresses statically configured on=0A= the network devices as this decreases the dynamic aspects of the=0A= network, however the operational overhead is increased.=0A= o Section 4.2:Added note that IID should be randomized for port-scan=0A= protection=0A= o Section 4.2: Removed text: This is an automated procedure of=0A= sending Internet Control Message Protocol (ICMP) echo requests=0A= (also known as PINGs) to a range of IP addresses and recording=0A= replies. This can enable an attacker to map the network.=0A= o Section 4.2: paragraph beginning: "This simple rule...". The=0A= first sentence in this paragraph was overly-long. The sentence=0A= has been fragmented=0A= o Section 4.2: para 1: s/similar as for an/similar to that of an/=0A= o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/=0A= Internet. The use of firewall and Intrusion Detection Systems=0A= (IDS) is/=0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 35]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 4.2: para 1: s/but has/but with/=0A= o Section 4.2: para 1: s/end to end/end-to-end/=0A= o Section 4.2: Item 3: s/amount/number/=0A= o Section 4.2: Item 3: s/This goes from the assumption that the=0A= attacker has no/This protection is nullified if the attacker has/=0A= o Section 4.2: para after Item 3: s/pose/offer/ (or provide).=0A= o Section 4.2: para after Item 3: s/best- practices/best practices/=0A= o Section 4.2: para after example firewall rules: s/create similar=0A= protection and security holes the typical IPv4 NAT device will=0A= offer/provide (non-)protection and create security holes similar=0A= to those offered to a network using a typical IPv4 NAT device/=0A= o Section 4.2: para next but one after firewall rules: s/What one=0A= does when topology probing is to get an idea of the available=0A= hosts/The intention of topology probing is to identify a selection=0A= of the available hosts/=0A= o Section 4.2: s/This is directly the opposite of what IPv6 security=0A= best practices are trying to achieve./IPv6 security best practices=0A= will avoid this kind of illusory security but can only do this if=0A= correctly configured firewalls and IDS systems are used at the=0A= perimeter where some IPv4 networks have relied on NATs.=0A= o Section 4.2: s/ It is recommended for site administrators to take=0A= [17] into consideration to achieve the expected goal./ It is=0A= recommended for site administrators to take [17] into=0A= consideration to achieve the expected goal. This protection will=0A= also be nullified if IIDs are configured in a group near the start=0A= of the IID space./=0A= o Section 4.2: Removed the example study and added complementiory=0A= text to describe a potential behavior=0A= o Section 4.4: rewrite of the section to reduce the importance of=0A= the MIpv^ and tunneled solution=0A= o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested=0A= in the text, however text is added that any kind of tunneling=0A= should do the trick.=0A= o Section 4.4: para 2: after 'As discussed above' inserted '(see=0A= Section 3.1)'=0A= o Section 4.4: para 3: s/consolidated on/indirected via/=0A= o Section 4.4: para 3: s/topololgy masked/each topology masked/=0A= o Section 4.4: para 3: Expanded acronym COA=0A= o Section 4.4: para 3: s/rack mounted/static/=0A= o Section 4.4: Rephrasing of text happened in this section=0A= o Section 4.5: change: "so that a NAT is not required" to: "so that=0A= IPv6 address translation is not required".=0A= o Section 4.5: changed 'periodically to look' into 'to look=0A= periodically'=0A= o Section 4.5: change: "2^64 hosts" to: "2^64 addresses".=0A= o Section 4.5: Removed the statement '(or even defined)=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 36]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 4.6: last para: s/which will lead to the IPv4 practice/=0A= which will require the adoption of the IPv4 workaround/=0A= o Section 4.6: s/the IPv4 constricting scenarios of multiple devices=0A= sharing a/the constriction of IPv4 scenarios where multiple devies=0A= are forced to share a/=0A= o Section 4.7: s/as the zero-touch external/as an almost zero-touch=0A= external/=0A= o Section 5: Replaced first three sentences with: In presenting=0A= these case studies we have chosen to consider categories of=0A= network divided first according to their function either as=0A= carrier/ISP networks or end user (such as enterprise) networks=0A= with the latter category broken down according to the number of=0A= connected end hosts.=0A= o Section 5: bullet points: s/connection/connected end hosts/=0A= o Section 5.1: s/addressing independence/addressing independence=0A= when using IPv4/=0A= o Section 5.1: last para: s/is only affecting/will only affect/=0A= o Section 5.1: changed 'alloaction' into 'allocation'=0A= o Section 5.1: changed: '(typically a one or' into '(typically one=0A= or'=0A= o section 5.1: changed: s/allocation/assignment/ in one of the=0A= paragraphs=0A= o section 5.2: para 1: s?is too long?is too long (very often just a=0A= /32 just giving a single address)?=0A= o Section 5.4: (Case study: ISP networks) ULA usage for ISP/=0A= Carrier-grade networks is mentioned in the draft, while it was=0A= suggested that for these NW the PI addresses are already very=0A= stable and they should be qualified for setting up proper=0A= filtering -> removed ULA from this section.=0A= o Section 5.4: changed 'intra- communication' into 'communication'=0A= o Section 5.4: s/chapter 5.1/Section 5.1/=0A= o Section 6.1: (Completion of work on ULAs) Text revision to reflect=0A= current state of ULA or remove the chapter? Chapter removed ...=0A= ULA specification is in the RFC-editor queue.=0A= o Section 6.3: (Minimal Traceability) Better to say "topology=0A= masking _may be_ required" instead of "is required", because=0A= whether this is needed or not is a value judgment.=0A= o Section 6.4: (Renumbering Procedure) Renumbering procedure is in=0A= RFC queue. The section corrected in the current state?=0A= o Section 6.4: s/well solved/completely solved/=0A= o In general the whole chapter 6 has been revised to reflect current=0A= status=0A= =0A= B.5. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02=0A= o=0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 37]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= B.6. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03=0A= o Editorial changes in response to IESG review comments and=0A= questions.=0A= o Introduction: clarified impact & goal for limited additional NAT=0A= discussion here / modified tone wrt marketing / grammar cleanup=0A= o Introduction: added paragraph about why nat !=3D security=0A= o Table1: s/benefit/Goal/ s/ULA/4193/ removed long numeric string /=0A= added app end points & number of subnets=0A= o Section 2: tone reduction about marketing=0A= o Section 2.1: grammar cleanup / clarified point about use of public=0A= space / added paragraph about topology restrictions=0A= o Section 2.2: moved paragraph about firewalls to 4.2 / deleted=0A= discussion about distributed security / clarified point about port=0A= overload=0A= o Section 2.3: Added opening sentence to explain the goal of the=0A= section / deleted comment about theory=0A= o Section 2.4: deleted confusing/redundant comments about identifier=0A= / added clarification that focused scanning on the port range=0A= reaches active nodes=0A= o Section 2.5: clarified that the impact was on the local network=0A= o Section 2.6: added point about limitations of cascaded nat=0A= o Section 2.7: clarification about why multihoming & renumbering are=0A= discussed together / point about sparse allocation=0A= o Section 3.2: grammer cleanup / updated reference from ID to RFC=0A= added point about policy table to bias ULA over ISP block=0A= o Section 3.3: Clarification about goal for section=0A= o Section 3.4: reorder paragraphs to put goal up front=0A= o Section 4.1: s/could/should/ s/prior to establishing/independent=0A= of the state of/ clarified why concatenation would not collide /=0A= another comment about the policy table for ULA biasing / clarified=0A= point about lack of routing protocol=0A= o Section 4.2: clarified point about firewall for boundary / 1.=0A= clarified point about valid lifetime / 2. clarified point that=0A= IPsec works the same w/o NAT / 3. clarified that the scanning=0A= threat is addresses as ports are the same once an address is known=0A= / rearranged paragraph to keep scanning thread together /=0A= clarified role of simple firewall / added comment about service=0A= provider mediated pinhole management=0A= o Section 4.3: added paragraph about tracking privacy address use=0A= o Section 4.4: clarified point about tracking wrt NAT / added=0A= comment about IGP complexity / s/conceal/isolate/ reworded ULA=0A= description which was technically backwards / additional=0A= description of the goal / added picture and referenced it from=0A= descriptions / added vlan option=0A= o Section 4.5: Grammar cleanup / clarification about policy=0A= o Section 4.6: added discussion about policy focus on subnets=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 38]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 4.7: s/CIDR-like/CIDR allocated/ s/this/to multiple=0A= addresses/ s/may/will likely/ s/if/when/ s/from SP/between sp/=0A= o Section 5: d/of these/=0A= o Section 5.1: deleted redundant discussion about /48 allocation /=0A= added discussion about larger deployments using tunneling=0A= o Section 5.2: clarification of overload on port vs. protocol /=0A= added comment about upstream NAT / clarified 3041 use=0A= o Section 5.4: s/IPv4/IP as role is not version specific / deleted=0A= comment about preference to ULA.=0A= o Section 6.1: added comment about deployment scale / added comment=0A= about firewall blocking BU / clarified point about future work=0A= being an optimization to reduce firewall load=0A= o Section 6.3: replaced reference to renumbering draft w/RFC=0A= o Section 6.4: grammar cleanup=0A= o Section A.2: word order - moved 'only'=0A= o Section A.6: deleted 'legitimate'=0A= o Section A.7: clarified how NAP delivers community of interest=0A= o Section B.5: added place holder for missing change log -01 to -02=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 39]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Authors' Addresses=0A= =0A= Gunter Van de Velde=0A= Cisco Systems=0A= De Kleetlaan 6a=0A= Diegem 1831=0A= Belgium=0A= =0A= Phone: +32 2704 5473=0A= Email: gunter@cisco.com=0A= =0A= =0A= Tony Hain=0A= Cisco Systems=0A= 500 108th Ave. NE=0A= Bellevue, Wa.=0A= USA=0A= =0A= Email: alh-ietf@tndh.net=0A= =0A= =0A= Ralph Droms=0A= Cisco Systems=0A= 1414 Massachusetts Avenue=0A= Boxborough, MA 01719=0A= USA=0A= =0A= Email: rdroms@cisco.com=0A= =0A= =0A= Brian Carpenter=0A= IBM Corporation=0A= Sauemerstrasse 4=0A= Rueschlikon, 8803=0A= Switzerland=0A= =0A= Email: brc@zurich.ibm.com=0A= =0A= =0A= Eric Klein=0A= Tel Aviv University=0A= Tel Aviv,=0A= Israel=0A= =0A= Phone:=0A= Email: ericlklein@softhome.net=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 40]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires December 4, 2006 [Page 41]=0A= =0C=0A= ------=_NextPart_000_0CE6_01C68F22.77700D50-- From owner-v6ops@ops.ietf.org Wed Jun 14 01:02:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqNWM-0008BC-Eh for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 01:02:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqNWL-00056V-6g for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 01:02:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqNTc-0006nw-7X for v6ops-data@psg.com; Wed, 14 Jun 2006 04:59: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.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 1FqNTb-0006nh-8u for v6ops@ops.ietf.org; Wed, 14 Jun 2006 04:59:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k5E4xRBq022088; Wed, 14 Jun 2006 07:59:27 +0300 Date: Wed, 14 Jun 2006 07:59:27 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: Fred Baker , David Kessens , v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational In-Reply-To: Message-ID: References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 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: de4f315c9369b71d7dd5909b42224370 On Wed, 14 Jun 2006, Iljitsch van Beijnum wrote: > No, why would we point out to people that our protocols are clever enough to > not require any filtering? Or use the same name for the same field in > different documents? That's way too much trouble with all those RFCs we have > to write that no one in operations reads anyway because they're too long and > too hard to read, and which are too hard to find out that they exist in the > first place. This is what section 4.3.3 is about. I grant you that it doesn't seem to spell out our protocol design wisdom :-), but it does mention TTL=255 checking. -- 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 Jun 14 01:32:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqNzh-0005Gc-Uj for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 01:32:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqNzf-00010G-Ln for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 01:32:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqNyp-0009oy-6i for v6ops-data@psg.com; Wed, 14 Jun 2006 05:31:51 +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 1FqNyo-0009oh-9a for v6ops@ops.ietf.org; Wed, 14 Jun 2006 05:31:50 +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 k5E5UNRR066103 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 14 Jun 2006 07:30:24 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <9344B322-C7AF-4E31-964C-E44B8F308978@cisco.com> References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> <9344B322-C7AF-4E31-964C-E44B8F308978@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: David Kessens , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Date: Wed, 14 Jun 2006 07:31:33 +0200 To: Fred Baker X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On 14-jun-2006, at 2:29, Fred Baker wrote: > As to my comment on the Hop Limit, I did read the document. It > states, in several places, that the recommendation is that the Hop > Limit be set to 255 and tested for still being 255 on receipt. That's not a recommendation, it's a requirement. > What I stated was that I would go at it a different way. If the > packet is sent with Hop Limit = 1, it cannot pass a compliant > router or firewall, so there is no need to test for whether it did > or didn't. My way is, I think, more robust - it depends only on the > sender, not the sender and the receiver. But you note that I didn't > require a change to suit my fancy either. Setting and checking for 255 is a security feature: this makes it impossible for an attacker sitting behind one or more routers to spoof a packet that seems to originate on the local link, which can be done with 1. And of course setting the hop limit to 1 and checking for 255 doesn't work, as we learned when trying to apply the same mechanism to BGP. If vendors don't bother implementing the check for 255, the solution is for users to find a better vendor, not reward that behavior by relaxing security features. From owner-v6ops@ops.ietf.org Wed Jun 14 08:57:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUvc-0001QU-44 for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 08:57:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUmD-0006Lx-0B for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 08:47:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqUjm-000IAY-8H for v6ops-data@psg.com; Wed, 14 Jun 2006 12:44: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.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 1FqUjk-000IAC-QW for v6ops@ops.ietf.org; Wed, 14 Jun 2006 12:44:45 +0000 Received: from 203-173-30-181.dyn.iinet.net.au (HELO mail.nosense.org) ([203.173.30.181]) by mail-ihug.icp-qv1-irony1.iinet.net.au with ESMTP; 14 Jun 2006 20:44:42 +0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,131,1149436800"; d="scan'208"; a="524333639:sNHT46645480" Received: from ubu.nosense.org (localhost.localdomain [127.0.0.1]) by mail.nosense.org (Postfix) with SMTP id A68087F04; Wed, 14 Jun 2006 22:14:39 +0930 (CST) Date: Wed, 14 Jun 2006 22:14:39 +0930 From: Mark Smith To: Brian E Carpenter Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-addcon-00.txt Message-Id: <20060614221439.6c38a2d6.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <448E684C.8080507@zurich.ibm.com> References: <448E684C.8080507@zurich.ibm.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; 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: e8a67952aa972b528dd04570d58ad8fe Hi, On Tue, 13 Jun 2006 09:25:00 +0200 Brian E Carpenter wrote: > Just a few comments on this: > > > 2.4. Network Level Design Considerations > > I suggest adding a bullet at the end of this section along these > lines: > > o It is possible that as registry policies evolve, a small site > may experience an increase in prefix length when renumbering, > e.g. from /48 to /56. For this reason, the best practice is > number subnets compactly rather than sparsely, and to > use low-order bits as much as possible when numbering subnets. > In other words, even if a /48 is allocated, act as though > only a /56 is available. Clearly, this advice does not apply > to large sites and enterprises that have an intrinsic need > for a /48 prefix. > Other than knowing it has been going on, I'm not up to date with what has been discussed regarding this policy change. From the brief info I read a while back, the proposal was two sizes of allocations, /48s or /56s. Has that changed at all to being a varying prefix value between /48 and /56 ? In either case, I'm wondering if there are methods of address management from the ISP side of things to allow for smaller customers who might exceed a /56 allocation. For example, very quickly off of the top of my head, one way an ISP could handle this would be allocate each small customer a /48, but only assign them the first /56 out of it. If the customer needs more address space they then get the full /48 that was pre-allocated for them. Of course, that means the ISP may end up effectively running out of address space before much of it has actually been used. At that point the ISP could then start allocating further /56s out of the previously allocated /48s (best out of only one of them until it is used up I'm sure), although the problem of course is out of which customers allocated /48 to the new /56s come from. If the allocations sizes are fixed at /48 and /56, I suppose if the customer who's previous /48 the new, different customer's /56 was allocated does exceed their original /56, then they could renumber to a new /48 allocation. At least then their addressing would have been stable for quite a while. Maybe if the new /56 was allocated out of the first ever allocated /48, then it is fairly likely the first customer will probably never grow beyond their original /56 assignment, as I'd guess there would have been quite a length of time from between the first /48 allocation and the last. Anyway, I haven't put much thought into it, so there may be far better ways to deal with the ISP side of the /48, /56 policy change. I think it would be good to cover any methods of dealing with it in this draft if possible. Regards, Mark. From owner-v6ops@ops.ietf.org Wed Jun 14 10:01:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVwP-0006Ky-AN for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 10:01:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVvk-0006WD-Vf for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 10:01:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqVvL-000Pb5-BM for v6ops-data@psg.com; Wed, 14 Jun 2006 14:00: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=BAYES_00 autolearn=ham version=3.1.1 Received: from [202.33.8.242] (helo=inc.inetcore.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqVvI-000PaQ-GD for v6ops@ops.ietf.org; Wed, 14 Jun 2006 14:00:44 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by inc.inetcore.com (Postfix) with ESMTP id 3627CD51D0C; Wed, 14 Jun 2006 23:00:43 +0900 (JST) In-Reply-To: <37AC477C-E197-41FE-982D-BB546AE07E54@cisco.com> References: <37AC477C-E197-41FE-982D-BB546AE07E54@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CC0C24A-58D5-44D6-8324-DA0C95F61E4F@inetcore.com> Cc: v6ops Content-Transfer-Encoding: 7bit From: Ruri Hiromi Subject: Re: Preliminary agenda, for comment Date: Wed, 14 Jun 2006 23:00:40 +0900 To: Fred Baker , Lindqvist Erik Kurt , David Kessens X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c To Chairs; Hello. I am Ruri Hiromi, I would like to give a talk about draft- arifumi-v6ops-addr-select-ps-00.txt. http://www1.ietf.org/mail-archive/web/i-d-announce/current/msg10520.html Could you give us 10-15 minutes? On 2006/06/08, at 5:45, Fred Baker wrote: > I sent a note out to folks who have drafts that have been posted > since the last IETF meeting. I currently have four requests for > slots in the upcoming IETF meeting: > > draft-ietf-v6ops-security-overview > draft-vandevelde-v6ops-addcon > draft-blanchet-v6ops-routing-guidelines > draft-ietf-v6ops-802-16-deployment-scenarios > > Two others advised me that they didn't need slots. > > Currently, the IESG is discussing > > draft-ietf-v6ops-natpt-to-exprmntl > draft-ietf-v6ops-nap > draft-ietf-v6ops-security-overview > > While it is not formally in the "Revised ID Needed" state, the IESG > has requested updates to the Security Overview, which is why it is > on the discussion agenda. I expect they will also ask for an > updated version of the Network Architecture Protection document; > their comments suggested that they already had a document that said > "NAT bad", and what they needed here was something to say "how to > do the things people use NAT for using IPv6 without NAT" without > especially commenting on NAT. > > The IESG has also requested updates to > > draft-ietf-v6ops-ent-analysis > draft-ietf-v6ops-bb-deployment-scenarios > > I am waiting for an update to draft-ietf-v6ops-icmpv6-filtering- > recs and draft-ietf-v6ops-ipsec-tunnels prior to mailing them off > to the IESG. > > At the last IETF meeting, I was told that there would be updated > versions of > > draft-ietf-v6ops-campus-transition > draft-ietf-v6ops-port-scanning > > that would enable me to open a WGLC on them. I have not seen these > yet. The magic date for new drafts is June 19 for -00 drafts and > June 26 for updates. > > If there is anything else for the working group agenda, please let > us know. > ------------------------------- Ruri Hiromi hiromi@inetcore.com From owner-v6ops@ops.ietf.org Wed Jun 14 10:02:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVxK-0006Rm-Md for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 10:02:50 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVpo-0005uU-By for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 09:55:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqVoT-000Ots-NJ for v6ops-data@psg.com; Wed, 14 Jun 2006 13:53:41 +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 [202.33.8.242] (helo=inc.inetcore.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqVoR-000Ota-OW for v6ops@ops.ietf.org; Wed, 14 Jun 2006 13:53:40 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by inc.inetcore.com (Postfix) with ESMTP id 25836D51D0C for ; Wed, 14 Jun 2006 22:53:38 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v750) References: Content-Type: text/plain; charset=ISO-2022-JP; delsp=yes; format=flowed Message-Id: <5AB2BB9D-E403-4079-8BE3-9646E75DCB53@inetcore.com> Content-Transfer-Encoding: 7bit From: Ruri Hiromi Subject: Fwd: I-D ACTION:draft-arifumi-v6ops-addr-select-ps-00.txt Date: Wed, 14 Jun 2006 22:53:33 +0900 To: v6ops X-Mailer: Apple Mail (2.750) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Hi list, As co-author, I post this to this mailing-list. We would like to share the problematic situation when multiple prefix go into one host then consider about solutions. We would be happy if someone put any input, reviews, and comments. TIA. Best regards, Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 2006$BG/(B6$B7n(B14$BF|(B 7:50:01:JST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-arifumi-v6ops-addr-select-ps-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Problem Statement of Default Address > Selection in Multi-prefix Environment: > Operational Issues of RFC3484 Default Rules > Author(s) : A. Matsumoto, et al. > Filename : draft-arifumi-v6ops-addr-select-ps-00.txt > Pages : 15 > Date : 2006-6-13 > > One physical network can carry multiple logical networks. Moreover, > we can use multiple physical networks at the same time in a host. In > that environment, end-hosts might have multiple IP addresses and be > required to use them selectively. Without an appropriate source/ > destination address selection mechanism, the host will experience > some trouble in the communication. RFC 3484 defines both the source > and destination address selection algorithms, but the multi-prefix > environment considered here needs additional rules beyond the default > operation. This document describes the possible problems that end- > hosts could encounter in an environment with multiple logical > networks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-arifumi-v6ops-addr-select- > ps-00.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-arifumi-v6ops-addr-select-ps-00.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-arifumi-v6ops-addr-select-ps-00.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. > Content-Type: text/plain > Content-ID: <2006-6-13154349.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce ------------------------------- Ruri Hiromi hiromi@inetcore.com From owner-v6ops@ops.ietf.org Wed Jun 14 11:29:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXJd-0001E2-5P for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 11:29:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXJb-0003Vf-MS for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 11:29:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqXHz-0007FR-Fb for v6ops-data@psg.com; Wed, 14 Jun 2006 15:28: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqXHw-0007FB-DK for v6ops@ops.ietf.org; Wed, 14 Jun 2006 15:28:12 +0000 Received: (qmail 37777 invoked by uid 1007); 14 Jun 2006 15:28:11 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=bnuPFl9Z9k8Jr6AQFxAEHpg19z1RXXhUHIhWOEiQShZyw0zkLzDQhTBuVMgSJDta ; Date: Wed, 14 Jun 2006 17:28:11 +0200 From: Gert Doering To: Fred Baker Cc: Iljitsch van Beijnum , David Kessens , v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Message-ID: <20060614152811.GK53070@Space.Net> References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> <9344B322-C7AF-4E31-964C-E44B8F308978@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9344B322-C7AF-4E31-964C-E44B8F308978@cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi, On Tue, Jun 13, 2006 at 05:29:53PM -0700, Fred Baker wrote: > As to my comment on the Hop Limit, I did read the document. It > states, in several places, that the recommendation is that the Hop > Limit be set to 255 and tested for still being 255 on receipt. What I > stated was that I would go at it a different way. If the packet is > sent with Hop Limit = 1, it cannot pass a compliant router or > firewall, so there is no need to test for whether it did or didn't. > My way is, I think, more robust - it depends only on the sender, not > the sender and the receiver. Well, actually I tend to disagree. If you're concerned about security, you must assume that the sender will do everything possible to break things - and that way, he will NOT be well-behaved and send out packets with a TTL of 1. Making the TTL=255? check on the receiver makes sure that the packet MUST come from a directly connected host - no matter how ill the intentions of the sender. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From owner-v6ops@ops.ietf.org Wed Jun 14 13:49:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZUU-0002gS-HO for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 13:49:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZUS-0004Ax-UT for v6ops-archive@lists.ietf.org; Wed, 14 Jun 2006 13:49:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqZSJ-000JBK-Cf for v6ops-data@psg.com; Wed, 14 Jun 2006 17:47:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, SPF_PASS autolearn=no version=3.1.1 Received: from [209.123.233.211] (helo=smtp-out1.oct.nac.net) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqZSG-000JB3-8r for v6ops@ops.ietf.org; Wed, 14 Jun 2006 17:47:00 +0000 Received: (qmail 24190 invoked by uid 0); 14 Jun 2006 13:46:58 -0400 Received: from 209.123.118.212 by smtp-out1.oct (envelope-from , uid 0) with qmail-scanner-1.25 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1(209.123.118.212):. Processed in 0.40279 secs); 14 Jun 2006 17:46:58 -0000 Received: from unknown (HELO webmail.nac.net) (209.123.118.212) by smtp-out1.oct.nac.net with SMTP; 14 Jun 2006 13:46:58 -0400 Received: from 67.83.27.139 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Wed, 14 Jun 2006 13:46:59 -0400 (EDT) Message-ID: <33405.67.83.27.139.1150307219.squirrel@webmail.nac.net> In-Reply-To: <20060614152811.GK53070@Space.Net> References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> <9344B322-C7AF-4E31-964C-E44B8F308978@cisco.com> <20060614152811.GK53070@Space.Net> Date: Wed, 14 Jun 2006 13:46:59 -0400 (EDT) Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational From: rfgraveman@nac.net To: "Fred Baker" , "Iljitsch van Beijnum" , "David Kessens" , "Gert Doering" Cc: v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Just a couple of comments on this. First, we should remember that all this hop count checking is pretty weak security for protocols that have mechanisms like IPsec and SEND available. Anyone who sees a packet can mess around with it and resend it wherever one chooses. Second, I don't see much benefit to the hop count = 1 trick. If the sender wants the packet not to be routed, send it to a destination address on the same segment. Third, the hop count = 255 trick may have some benefit if routers and other packet forwarders (we have lots of them in IPv6) are behaving properly. But remember, for example, that packets from anywhere popping out an IPv6-in-IPv4 transition mechanism tunnel don't typically get their hop count decremented, so 255 can mean anything at that point. Rich Graveman > On Tue, Jun 13, 2006 at 05:29:53PM -0700, Fred Baker wrote: >> As to my comment on the Hop Limit, I did read the document. It >> states, in several places, that the recommendation is that the Hop >> Limit be set to 255 and tested for still being 255 on receipt. What I >> stated was that I would go at it a different way. If the packet is >> sent with Hop Limit = 1, it cannot pass a compliant router or >> firewall, so there is no need to test for whether it did or didn't. >> My way is, I think, more robust - it depends only on the sender, not >> the sender and the receiver. > > Well, actually I tend to disagree. If you're concerned about security, > you must assume that the sender will do everything possible to break > things - and that way, he will NOT be well-behaved and send out packets > with a TTL of 1. > > Making the TTL=255? check on the receiver makes sure that the packet MUST > come from a directly connected host - no matter how ill the intentions of > the sender. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 92315 > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > D- 80807 Muenchen Fax : +49-89-32356-234 > > > From owner-v6ops@ops.ietf.org Thu Jun 15 06:58:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqpYI-0003LN-In for v6ops-archive@lists.ietf.org; Thu, 15 Jun 2006 06:58:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqpYH-0007Fx-6G for v6ops-archive@lists.ietf.org; Thu, 15 Jun 2006 06:58:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FqpTw-00016n-Gt for v6ops-data@psg.com; Thu, 15 Jun 2006 10:53: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=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 1FqpTv-00016Y-Bk for v6ops@ops.ietf.org; Thu, 15 Jun 2006 10:53:47 +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 k5FArgWv001162 for ; Thu, 15 Jun 2006 11:53:42 +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 k5FAra1m007951 for ; Thu, 15 Jun 2006 11:53:36 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k5FArWrR031209 for v6ops@ops.ietf.org; Thu, 15 Jun 2006 11:53:32 +0100 Date: Thu, 15 Jun 2006 11:53:32 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Message-ID: <20060615105332.GH27999@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> <9344B322-C7AF-4E31-964C-E44B8F308978@cisco.com> <20060614152811.GK53070@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060614152811.GK53070@Space.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: 9466e0365fc95844abaf7c3f15a05c7d On Wed, Jun 14, 2006 at 05:28:11PM +0200, Gert Doering wrote: > Hi, > > On Tue, Jun 13, 2006 at 05:29:53PM -0700, Fred Baker wrote: > > As to my comment on the Hop Limit, I did read the document. It > > states, in several places, that the recommendation is that the Hop > > Limit be set to 255 and tested for still being 255 on receipt. What I > > stated was that I would go at it a different way. If the packet is > > sent with Hop Limit = 1, it cannot pass a compliant router or > > firewall, so there is no need to test for whether it did or didn't. > > My way is, I think, more robust - it depends only on the sender, not > > the sender and the receiver. > > Well, actually I tend to disagree. If you're concerned about security, > you must assume that the sender will do everything possible to break > things - and that way, he will NOT be well-behaved and send out packets > with a TTL of 1. > > Making the TTL=255? check on the receiver makes sure that the packet MUST > come from a directly connected host - no matter how ill the intentions of > the sender. Hmm, this discussion looks very familiar ;) -- Tim/::1 From owner-v6ops@ops.ietf.org Fri Jun 16 20:36:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrOnY-0002ga-Ac for v6ops-archive@lists.ietf.org; Fri, 16 Jun 2006 20:36:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrOnX-0007TF-0o for v6ops-archive@lists.ietf.org; Fri, 16 Jun 2006 20:36:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FrOjj-000GnQ-Qz for v6ops-data@psg.com; Sat, 17 Jun 2006 00: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.5 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 1FrOjj-000GnF-7b for v6ops@ops.ietf.org; Sat, 17 Jun 2006 00:32:27 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2006 17:32:27 -0700 X-IronPort-AV: i="4.06,144,1149490800"; d="scan'208"; a="1827263585:sNHT31335424" 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/8.12.11) with ESMTP id k5H0WQOb015039; Fri, 16 Jun 2006 17:32:26 -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 k5H0WQCU010151; Fri, 16 Jun 2006 17:32:26 -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.211); Fri, 16 Jun 2006 17:32:26 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Jun 2006 17:32:25 -0700 Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <7A29E7CE-5D77-499E-A47B-8AFDC2847753@cisco.com> Cc: kurtis@kurtis.pp.se, david.kessens@nokia.com, agenda@ietf.org Content-Transfer-Encoding: quoted-printable From: Fred Baker Subject: v6ops agenda Date: Fri, 16 Jun 2006 17:32:24 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 17 Jun 2006 00:32:25.0755 (UTC) FILETIME=[81A826B0:01C691A5] DKIM-Signature: a=rsa-sha1; q=dns; l=908; t=1150504346; x=1151368346; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:v6ops=20agenda; X=v=3Dcisco.com=3B=20h=3DXESc7CN5/mdONzE8J+1a4zbPZEQ=3D; b=X6Z44DpoIwpgcX1cIDzhWYIQxHnXJbQaRoDyx0dhk6+DSQJqON8I43x/UpYTrXYrTdWciduK RvpcKS3STKYonvo9rh6SlA6Qubl6NYqu0AgwwjFGPBcMRROq5hBjqpJY; 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: 93238566e09e6e262849b4f805833007 We have seven items on our agenda: draft-ietf-v6ops-security-overview draft-ietf-v6ops-addcon draft-blanchet-v6ops-routing-guidelines draft-ietf-v6ops-802-16-deployment-scenarios draft-ietf-v6ops-scanning-implications draft-arifumi-v6ops-addr-select-ps Alain Durand's draft if posted We will give each about 15 minutes, some will need less. Any slides =20 that the presenters put together, please mail them to me by 1 July, =20 as I need to post them at the IETF site. I am expecting a draft of=A0draft-ietf-v6ops-ipsec-tunnels to take to =20= working group last call, but we have not been asked for discussion =20 time on that. If the authors and those commenting can't get it done =20 by July, it may be worthwhile to add this to the agenda. I am similarly awaiting an updated version of=A0draft-ietf-v6ops-campus-=20= transition, as an outcome of last March's meeting. From owner-v6ops@ops.ietf.org Mon Jun 19 10:29:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKlH-0000YD-Mr for v6ops-archive@lists.ietf.org; Mon, 19 Jun 2006 10:29:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKgX-0001lU-4m for v6ops-archive@lists.ietf.org; Mon, 19 Jun 2006 10:25:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsKd2-0003zZ-PW for v6ops-data@psg.com; Mon, 19 Jun 2006 14:21:24 +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.228.20.171] (helo=mgw-ext12.nokia.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsKd0-0003zH-J8 for v6ops@ops.ietf.org; Mon, 19 Jun 2006 14:21:23 +0000 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5JELGr6005440; Mon, 19 Jun 2006 17:21:19 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 17:21:04 +0300 Received: from dadhcp-172019068136.americas.nokia.com ([172.18.141.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 19 Jun 2006 17:21:03 +0300 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id k5JEL1qQ000303; Mon, 19 Jun 2006 07:21:01 -0700 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id k5JEL0D6000301; Mon, 19 Jun 2006 07:21:00 -0700 Date: Mon, 19 Jun 2006 07:21:00 -0700 From: David Kessens To: Fred Baker Cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Message-ID: <20060619142100.GF31576@nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 19 Jun 2006 14:21:03.0489 (UTC) FILETIME=[988FCF10:01C693AB] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Fred, I have requested the secretariat to do a last call on this document. Strictly speaking, that is not required but I believe that there might be a wider audience that is interested in this work than the standard v6ops crowd. Also, this can give you a chance/a bit of time to possibly find a resolution with (some of) Iljitsch comments. David Kessens --- On Tue, Jun 13, 2006 at 12:52:29PM -0700, Fred Baker wrote: > > 1.a) Have the chairs personally reviewed this version of the > >Internet > > Draft (ID), and in particular, do they believe this ID is > >ready > > to forward to the IESG for publication? Which chair is the WG > > Chair Shepherd for this document? > > Yes, I have reviewed the document, and I plan to shepherd it. I > believe that it gives practical advice on who firewalls and other > security middleware may be configured to manage IPv6 ICMP traffic, > which one must expect to be used as IPv4 ICMP traffic has been used > in fomenting attacks. > > The real value in this document, besides suggesting appropriate > firewall configurations, is in the lines of reasoning presented for > the configuration elements. For example, a router solicitation by > definition travels from a host seeking a first hop router to a system > that it is directly connected to at a lower layer such as a wired or > wireless Ethernet. The document recommends that this class of message > never be forwarded, and one in fact hopes that not only would it not > be forwarded, but that the originator would set TTL=1 to prevent the > occurrence even if the router were misconfigured. As such, the > document collects a fair bit of wisdom from which the unschooled can > learn. > > > 1.b) Has the document had adequate review from both key WG members > > and key non-WG members? Do you have any concerns about the > > depth or breadth of the reviews that have been performed? > > This document has been through working group review since its > introduction about a year ago. This version responds to comments > presented during working group last call in May 2006. I believe that > it has had adequate review. > > > 1.c) Do you have concerns that the document needs more review > >from a > > particular (broader) perspective (e.g., security, operational > > complexity, someone familiar with AAA, internationalization, > > XML, etc.)? > > Since it deals with security issues, a review from the security area > may be of value. > > > 1.d) Do you have any specific concerns/issues with this document > >that > > you believe the ADs and/or IESG should be aware of? For > > example, perhaps you are uncomfortable with certain parts > >of the > > document, or have concerns whether there really is a need for > > it. In any event, if your issues have been discussed in > >the WG > > and the WG has indicated it that it still wishes to advance > >the > > document, detail those concerns in the write-up. > > The document was originally proposed for BCP status, and was > downgraded to informational based on the notion that we should get > experience with the document before giving it that class of > approbation. We expect to review the document about a year hence in > view of operational experience. Apart from that, the working group > has been supportive. > > > 1.e) How solid is the WG consensus behind this document? Does it > > represent the strong concurrence of a few individuals, with > > others being silent, or does the WG as a whole understand and > > agree with it? > > v6ops is, as a group, quiet. One therefore has to describe this as > having strong proponents rather than an avalanch of support. My > observation, however, is that when v6ops does not support something, > they tell us, and this has not happened. I conclude that there is > operational support and little if any dissent. > > > 1.f) Has anyone threatened an appeal or otherwise indicated extreme > > discontent? If so, please summarise the areas of conflict in > > separate email to the Responsible Area Director. (It > >should be > > separate email because this questionnaire will be entered into > > the tracker). > > no > > > 1.g) Have the chairs verified that the document checks out against > > all the ID nits? (see http://www.ietf.org/ID-Checklist.html). > > Boilerplate checks are not enough; this check needs to be > > thorough. > > draft-ietf-v6ops-icmpv6-filtering-recs-01.txt was run through idnits > 1.102 on 13 June. It reported no issues. > > I also ran it through ispell on a Solaris system. It revealed some > disagreements between British and American versions of English. The > Brits can't spill there wards rite. > > > 1.h) Has the document split its references into normative and > > informative? Are there normative references to IDs, where the > > IDs are not also ready for advancement or are otherwise in an > > unclear state? The RFC Editor will not publish an RFC with > > normative references to IDs (will delay the publication until > > all such IDs are also ready for RFC publicatioin). If the > > normative references are behind, what is the strategy for > >their > > completion? On a related matter, are there normative > >references > > that are downward references, as described in BCP 97, RFC 3967 > > RFC 3967 [RFC3967]? Listing these supports the Area > >Director in > > the Last Call downref procedure specified in RFC 3967. > > The references are so divided. > > There are two normative references to internet drafts, draft-ietf- > ipngwg-icmp-name-lookups and draft-ietf-ipngwg-icmp-v3. The former is > in the RFC Editor's queue, and the latter was recently published as > RFC 4443, which is also listed as a normative reference. > > In addition, there are two informative references to internet drafts. > draft-chown-v6ops-port-scanning-implications will, in the coming > weeks, be replaced by draft-ietf-v6ops-scanning-implications, and > will in all likelihood be sent to the IESG following a working group > last call in July. draft-gont-tcpm-icmp-attacks has been replaced by > draft-ietf-tcpm-icmp-attacks, which was placed in the "AD is > watching" state by Lars Eggert last March. > > I would recommend that the RFC Editor update these references to the > appropriate RFC references during the edit-for-publication process. > > > 1.i) For Standards Track and BCP documents, the IESG approval > > announcement includes a write-up section with the following > > sections: > > > > * Technical Summary > > 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. A number of security risks are associated with uncontrolled > forwarding of ICMPv6 messages. On the other hand, compared with IPv4 > and the corresponding protocol ICMP, ICMPv6 is essential to the > functioning of IPv6 rather than a useful auxiliary. 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. > > > * Working Group Summary > > This was approved by the IPv6 Operations Working Group following an > extended discussion. > > > * Protocol Quality > > This is not a protocol, but it describes operational configurations > for mnaging a protocol whose counterpart has warranted similar > controls in the IPv4 Internet. The working group believes that the > logic it presents and the configuration paradigm it espouses are > correct. v6ops plans to review deployment experience and recommend > elevation to BCP status in 12-24 months. David Kessens --- From owner-v6ops@ops.ietf.org Mon Jun 19 10:40:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsKvb-0006cn-EA for v6ops-archive@lists.ietf.org; Mon, 19 Jun 2006 10:40:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsKva-0003Oo-4a for v6ops-archive@lists.ietf.org; Mon, 19 Jun 2006 10:40:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsKv3-0005Qs-2D for v6ops-data@psg.com; Mon, 19 Jun 2006 14:40: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.5 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 1FsKv1-0005QH-TL for v6ops@ops.ietf.org; Mon, 19 Jun 2006 14:39:59 +0000 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2006 07:40:00 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5JEdxTn030898; Mon, 19 Jun 2006 07:39:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5JEdxke005672; Mon, 19 Jun 2006 07:39:59 -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); Mon, 19 Jun 2006 07:39:32 -0700 Received: from [192.168.2.83] ([10.21.121.37]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 07:39:31 -0700 In-Reply-To: <20060619142100.GF31576@nokia.com> References: <20060619142100.GF31576@nokia.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <148EE44C-5D74-4396-81CF-494477732EF7@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational Date: Mon, 19 Jun 2006 07:39:27 -0700 To: David Kessens X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 19 Jun 2006 14:39:31.0925 (UTC) FILETIME=[2D3DB850:01C693AE] DKIM-Signature: a=rsa-sha1; q=dns; l=183; t=1150727999; x=1151591999; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20draft-ietf-v6ops-icmpv6-filtering-recs=20to=20informational; X=v=3Dcisco.com=3B=20h=3DypwoY0zpOVmspMUvCT7kBUlzEO0=3D; b=c5h1jxPIb/hT1qmkZ7bsH5TqhuokyQpBjAgBTABk8hTKBhcv/qNPynrKb8/OwiNSg3bzs3g7 fDobZMWN4X2QJDQv0WUrTKJTDtAiAC/fRZeUToxeRfo0VxG0wlqaSbNt; 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: 08e48e05374109708c00c6208b534009 On Jun 19, 2006, at 7:21 AM, David Kessens wrote: > Also, this can give you a chance/a bit of time to possibly find a > resolution with (some of) Iljitsch comments. Thanks. From owner-v6ops@ops.ietf.org Mon Jun 19 16:40:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQYG-0002f9-Ge for v6ops-archive@lists.ietf.org; Mon, 19 Jun 2006 16:40: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 1FsQFe-0006un-U0 for v6ops-archive@lists.ietf.org; Mon, 19 Jun 2006 16:21:38 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsPnM-0005R4-1z for v6ops-archive@lists.ietf.org; Mon, 19 Jun 2006 15:52:30 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsPlE-0002yj-NG for v6ops-data@psg.com; Mon, 19 Jun 2006 19:50:12 +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.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FsPlE-0002yO-20 for v6ops@ops.ietf.org; Mon, 19 Jun 2006 19:50:12 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo2Hp007647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl4-0007aa-F7; Mon, 19 Jun 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-routing-guidelines-00.txt Message-Id: Date: Mon, 19 Jun 2006 15:50:02 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --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 Routing Policies Guidelines Author(s) : M. Blanchet Filename : draft-ietf-v6ops-routing-guidelines-00.txt Pages : 8 Date : 2006-6-19 Guidelines on how to manage IPv6 routes are needed for operators of networks, either providers or enterprises. This document is a followup on RFC2772 work but for the production IPv6 Internet. RFC2772 becomes historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-routing-guidelines-00.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-routing-guidelines-00.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-routing-guidelines-00.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-6-19144713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-routing-guidelines-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-routing-guidelines-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19144713.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Jun 21 16:28:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8lg-00066i-5Y for v6ops-archive@lists.ietf.org; Wed, 21 Jun 2006 15:53:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8lc-0003YN-Tm for v6ops-archive@lists.ietf.org; Wed, 21 Jun 2006 15:53:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft8iE-000DlO-J2 for v6ops-data@psg.com; Wed, 21 Jun 2006 19:50:06 +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.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ft8iD-000DkI-Fe for v6ops@ops.ietf.org; Wed, 21 Jun 2006 19:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5LJo1Rx031575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ft8i9-0003l4-C8; Wed, 21 Jun 2006 15: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-scanning-implications-00.txt Message-Id: Date: Wed, 21 Jun 2006 15:50:01 -0400 Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 Implications for Network Scanning Author(s) : T. Chown Filename : draft-ietf-v6ops-scanning-implications-00.txt Pages : 11 Date : 2006-6-21 The 128 bits of IPv6 address space is considerably bigger than the 32 bits of address space in IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space. As a result, traditional methods of remote TCP or UDP port scanning to discover open or running services on a host will potentially become far less computationally feasible, due to the larger search space in the subnet. This document discusses that property of IPv6 subnets, and describes related issues for site administrators of IPv6 networks to consider, which may be of importance when planning site address allocation and management strategies. While traditional port scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware of other methods attackers may use to discover IPv6 addresses on a target subnet, and take appropriate measures to preempt these. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-scanning-implications-00.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-scanning-implications-00.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-scanning-implications-00.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-6-21101733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-scanning-implications-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-scanning-implications-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-21101733.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jun 22 12:36:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSAD-0007eE-5b for v6ops-archive@lists.ietf.org; Thu, 22 Jun 2006 12:36:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSAB-0008I9-Re for v6ops-archive@lists.ietf.org; Thu, 22 Jun 2006 12:36:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FtS6L-000N0O-UB for v6ops-data@psg.com; Thu, 22 Jun 2006 16:32:17 +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, 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 1FtS6L-000N0C-BM for v6ops@ops.ietf.org; Thu, 22 Jun 2006 16:32:17 +0000 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 22 Jun 2006 09:31:46 -0700 X-IronPort-AV: i="4.06,166,1149490800"; d="scan'208"; a="1830700530:sNHT85237965728" 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/8.12.11) with ESMTP id k5MGVjHV007325; Thu, 22 Jun 2006 09:31:45 -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 k5MGVjCU028029; Thu, 22 Jun 2006 09:31:45 -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.211); Thu, 22 Jun 2006 09:31:45 -0700 Received: from [192.168.2.83] ([10.21.146.109]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 09:31:44 -0700 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: Fred Baker Subject: IESG review of draft-ietf-v6ops-ent-analysis-06.txt Date: Thu, 22 Jun 2006 09:31:45 -0700 To: green@commandinformation.com, Jim Bound , sklynsma@mitre.org, Tim Chown , Yanick Pouffary X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 Jun 2006 16:31:44.0537 (UTC) FILETIME=[596E0890:01C69619] DKIM-Signature: a=rsa-sha1; q=dns; l=370; t=1150993905; x=1151857905; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:IESG=20review=20of=20draft-ietf-v6ops-ent-analysis-06.txt; X=v=3Dcisco.com=3B=20h=3Dw8kzrcxdQzKb40Q8icOSVXy6r/0=3D; b=u1XgZifPawlzUkJiu46DICTNBYK9ZiBELms/SH7Ve17nszgwmfZrHPQB4tcGdOqood5xu43q tGSHILqiH/hAHPZAdAlK49GQHf6k9liSkrc3BB9bnIpuVitYg2t3gUmM; 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: d17f825e43c9aed4fd65b7edddddec89 Folks: In the past 24 hours there has been a flurry of activity on the IESG's part, including two "discuss" comments. Would you please go through https://datatracker.ietf.org/public/pidtracker.cgi? command=view_id&dTag=12296&rfc_flag=0, discuss the comments as necessary with the various ADs, and address their issues in an updated document? Thanks From owner-v6ops@ops.ietf.org Fri Jun 23 10:59:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftn89-0006Mj-Le for v6ops-archive@lists.ietf.org; Fri, 23 Jun 2006 10:59:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftn83-0000BV-AU for v6ops-archive@lists.ietf.org; Fri, 23 Jun 2006 10:59:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftn4f-000P0K-Gq for v6ops-data@psg.com; Fri, 23 Jun 2006 14:55:57 +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.247] (helo=tayrelbas04.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ftn4b-000OzZ-JX for v6ops@ops.ietf.org; Fri, 23 Jun 2006 14:55:53 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6B903341CE; Fri, 23 Jun 2006 10:55:50 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 10:55:49 -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: IESG review of draft-ietf-v6ops-ent-analysis-06.txt Date: Fri, 23 Jun 2006 10:55:48 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC198CA0@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG review of draft-ietf-v6ops-ent-analysis-06.txt Thread-Index: AcaWGW5pglJvf446RDaImE1cRgfSwQAu48pQ From: "Bound, Jim" To: "Fred Baker" , , , "Tim Chown" , "Pouffary, Yanick" Cc: X-OriginalArrivalTime: 23 Jun 2006 14:55:49.0845 (UTC) FILETIME=[1DC77850:01C696D5] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Fred, Yes we will do this. /jim=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Thursday, June 22, 2006 12:32 PM > To: green@commandinformation.com; Bound, Jim;=20 > sklynsma@mitre.org; Tim Chown; Pouffary, Yanick > Cc: v6ops@ops.ietf.org > Subject: IESG review of draft-ietf-v6ops-ent-analysis-06.txt >=20 > Folks: >=20 > In the past 24 hours there has been a flurry of activity on=20 > the IESG's part, including two "discuss" comments. Would you=20 > please go through=20 > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D12296&rfc_flag=3D0, discuss the comments as necessary=20 > with the various ADs, and address their issues in an updated document? >=20 > Thanks >=20 From owner-v6ops@ops.ietf.org Wed Jun 28 05:59:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvWpX-0006Oc-D9 for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 05:59:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvWpT-0004nl-Sz for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 05:59:31 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvWm6-000Oqs-K3 for v6ops-data@psg.com; Wed, 28 Jun 2006 09:55: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.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvWm5-000OqT-7a for v6ops@ops.ietf.org; Wed, 28 Jun 2006 09:55:57 +0000 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FvWm0-0001rO-LB; Wed, 28 Jun 2006 10:55:52 +0100 Message-ID: <44A252DE.1070104@dial.pipex.com> Date: Wed, 28 Jun 2006 10:58:54 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Fred Baker , David Kessens , v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> In-Reply-To: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> 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: e8a67952aa972b528dd04570d58ad8fe [Having returned from holiday..] Note: We are talking about draft-v6ops-icmpv6-filtering-recs-01. Iljitsch van Beijnum wrote: > On 13-jun-2006, at 21:52, Fred Baker wrote: > >> The real value in this document, besides suggesting appropriate >> firewall configurations, is in the lines of reasoning presented for >> the configuration elements. For example, a router solicitation by >> definition travels from a host seeking a first hop router to a system >> that it is directly connected to at a lower layer such as a wired or >> wireless Ethernet. The document recommends that this class of message >> never be forwarded, and one in fact hopes that not only would it not >> be forwarded, but that the originator would set TTL=1 to prevent the >> occurrence even if the router were misconfigured. > > RFC 2461: > > 6.1.1. Validation of Router Solicitation Messages > > Hosts MUST silently discard any received Router Solicitation > Messages. > > A router MUST silently discard any received Router Solicitation > messages that do not satisfy all of the following validity checks: > > - The IP Hop Limit field has a value of 255, i.e., the packet > could not possibly have been forwarded by a router. > > Although the document mentions using the hop limit at 255 as a > security feature, I think this could be more prominent, as it may give > people a reason to forego some or even all ICMPv6 filtering. > >> As such, the document collects a fair bit of wisdom from which the >> unschooled can learn. > > You're making me bite my tongue here, Fred... The draft itself is quite clear and accurate about the hop limit field in Router Solicitations (s 4.2.3 notes they must be received with hop limit = 255). Fred's gloss needs to be corrected - a different example in the proto questionnaire would be better! > >>> 1.b) Has the document had adequate review from both key WG members >>> and key non-WG members? Do you have any concerns about the >>> depth or breadth of the reviews that have been performed? > >> This document has been through working group review since its >> introduction about a year ago. This version responds to comments >> presented during working group last call in May 2006. I believe that >> it has had adequate review. > > Please have the use of "hop count" changed to "hop limit" in the > document to reflect the actual name of the field. > This was corrected in the changes from -00 to -01. Regards, Elwyn From owner-v6ops@ops.ietf.org Wed Jun 28 06:44:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXWs-0000BT-Px for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 06:44:18 -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 1FvX6G-0006mk-3X for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 06:16:48 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvWxM-0003Rh-ED for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 06:07:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvWwn-000Ps0-0c for v6ops-data@psg.com; Wed, 28 Jun 2006 10:07: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 autolearn=no version=3.1.1 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvWwm-000Prf-6T for v6ops@ops.ietf.org; Wed, 28 Jun 2006 10:07:00 +0000 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FvWwh-0002yg-Hd; Wed, 28 Jun 2006 11:06:55 +0100 Message-ID: <44A25575.7010809@dial.pipex.com> Date: Wed, 28 Jun 2006 11:09:57 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola CC: Iljitsch van Beijnum , Fred Baker , David Kessens , v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-icmpv6-filtering-recs to informational References: <920B9F26-1848-42A2-AF1D-64837FABBD4A@muada.com> <8811945A-7AFD-4C5B-9A7F-3FEB6E3C573D@cisco.com> 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: -2.2 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Pekka Savola wrote: > On Wed, 14 Jun 2006, Iljitsch van Beijnum wrote: >> No, why would we point out to people that our protocols are clever >> enough to not require any filtering? Or use the same name for the >> same field in different documents? That's way too much trouble with >> all those RFCs we have to write that no one in operations reads >> anyway because they're too long and too hard to read, and which are >> too hard to find out that they exist in the first place. > > This is what section 4.3.3 is about. I grant you that it doesn't seem > to spell out our protocol design wisdom :-), but it does mention > TTL=255 checking. > Iljitsch's previous comments *were* actioned. v01 (which is the one that Fred was referring to and has gone to IETF Last Call) already had the hop count/hop limit issue fixed and an added note in s1 to direct impatient ICMPv6 experts straight to the rules section. Hopefully we can publicise this document more widely once it has been approved/published so that those real operations people can read it. /Elwyn From owner-v6ops@ops.ietf.org Wed Jun 28 15:36:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfqC-0006xt-MC for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 15:36:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfqA-0002Cg-CO for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 15:36:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvfmv-000NRp-Im for v6ops-data@psg.com; Wed, 28 Jun 2006 19:33:25 +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=BAYES_00,DNS_FROM_RFC_POST, SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=no 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 1Fvfms-000NQk-VF for v6ops@ops.ietf.org; Wed, 28 Jun 2006 19:33:23 +0000 Received: from ([172.27.14.137]) by mail04.frontiercorp.com with ESMTP id 4028772.72884304; Wed, 28 Jun 2006 15:05:09 -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: v6 multihoming and route filters Date: Wed, 28 Jun 2006 12:32:57 -0700 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters Thread-Index: Acaa6akLI2IKWZ+pQLqDVmTb5ZBbcw== From: "Azinger, Marla" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello- I have reviewed Marc Banchets document on IP V6 Routing Policy = Guidelines Filename: draft-ietf-v6ops-routing-guidelines-00.txt I am concerned that the current draft does not include detailed routing = guidelines for multihoming. This document does not include guidelines = for multihoming in the current V6 routing framework. V6 can be used = identically like V4 to do multihoming and this is what I would like to = do with V6.=20 I currently have customers asking for this ability and none of them wish = to wait for solutions that may not be fully developed for a couple more = years. Also, my customers don't want to get PI space (even under the = new V6 PI policy), so this means I need to give them a /48 and set up = multihoming. However, as all policy and practices sit right now, = everyone filters on a /32. I ask the V6 WG to create a "best practice for multihoming" that can be = utilized today. I ask that you please insert the solution to filter at = /48 thus allowing "upstream providers" to provide multihoming to their = customers. This solution is needed to support providers creating V6 = networks and this solution can easily be added into Marc's "IP V6 = Routing Policy Guidelines" document.=20 Thank you for your time Marla Azinger IP Engineering Frontier Communications From owner-v6ops@ops.ietf.org Wed Jun 28 15:41:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfuM-0007zs-Ez for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 15:41:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfuJ-0002gG-Sh for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 15:41:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvfta-000O26-CK for v6ops-data@psg.com; Wed, 28 Jun 2006 19:40: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=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 1FvftY-000O1r-SY for v6ops@ops.ietf.org; Wed, 28 Jun 2006 19:40:17 +0000 Received: from [66.205.89.194] (account margaret HELO ceili) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1074454; Wed, 28 Jun 2006 15:40:16 -0400 From: "Margaret Wasserman" To: "'Tony Hain'" , "'Fred Baker'" , "'Tim Chown'" Cc: Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 28 Jun 2006 15:40:02 -0400 Message-ID: <009501c69aea$a75e7cd0$f66514ac@corp.devicescape.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0ce501c68f5d$23cee550$7abe838e@tndh.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaORGFrfQ3OW/cEQBeMsFk9396AsgBFxRCgAuGoVUA= Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 2.3 (++) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 Wed Jun 28 16:01:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgEL-0002dW-Fj for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 16:01:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgEK-0005dT-5W for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 16:01:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvgD9-00005x-1E for v6ops-data@psg.com; Wed, 28 Jun 2006 20:00: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, 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 1FvgD8-00005i-FT for v6ops@ops.ietf.org; Wed, 28 Jun 2006 20:00:30 +0000 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 28 Jun 2006 13:00:30 -0700 X-IronPort-AV: i="4.06,189,1149490800"; d="scan'208"; a="325960723:sNHT32173664" 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/8.12.11) with ESMTP id k5SK0UF2024054; Wed, 28 Jun 2006 13:00:30 -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 k5SK0TCU006985; Wed, 28 Jun 2006 13:00:29 -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, 28 Jun 2006 13:00:29 -0700 Received: from [10.242.24.94] ([10.21.80.113]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 13:00:29 -0700 In-Reply-To: <009501c69aea$a75e7cd0$f66514ac@corp.devicescape.com> References: <009501c69aea$a75e7cd0$f66514ac@corp.devicescape.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41F33174-1690-4B85-8949-1639AD647AE8@cisco.com> Cc: "'Tony Hain'" , "'Tim Chown'" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 28 Jun 2006 13:00:26 -0700 To: Margaret Wasserman , Dave Oran , radia.perlman@eng.sun.com X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 28 Jun 2006 20:00:29.0395 (UTC) FILETIME=[814E3230:01C69AED] DKIM-Signature: a=rsa-sha1; q=dns; l=1163; t=1151524830; x=1152388830; 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=20Review=20of=20draft-ietf-v6ops-nap-02.txt; X=v=3Dcisco.com=3B=20h=3DL7dXh/0Y+wnU5NCMyPFRtjvkHMY=3D; b=P3jhvL8+IL2Z/cuWRZDl57LbQWkSitcG9AkgeN6YTD6GltCJ0TH+k3nzPsDF7TTb7mU20PjR xvaIrTyZZMRkMsUjNaVqjoHct3MEcXWOTHFR8aG28JVIUsV+P6S9zIr8; 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: ea4ac80f790299f943f0a53be7e1a21a 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 Jun 28 16:29:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgfX-000506-EN for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 16:29:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgfW-0008Gb-17 for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 16:29:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvgeU-0002nf-2s for v6ops-data@psg.com; Wed, 28 Jun 2006 20:28: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.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 1FvgeT-0002nU-GA for v6ops@ops.ietf.org; Wed, 28 Jun 2006 20:28:45 +0000 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2006 13:28:45 -0700 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/8.12.11) with ESMTP id k5SKSjsQ020945; Wed, 28 Jun 2006 13:28:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5SKShAG014276; Wed, 28 Jun 2006 13:28:44 -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.211); Wed, 28 Jun 2006 13:28:43 -0700 Received: from [10.242.24.94] ([10.21.80.113]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 13:28:42 -0700 In-Reply-To: <1DA3363E-9413-411E-972A-0D0EC5C125C4@cisco.com> References: <009501c69aea$a75e7cd0$f66514ac@corp.devicescape.com> <41F33174-1690-4B85-8949-1639AD647AE8@cisco.com> <1DA3363E-9413-411E-972A-0D0EC5C125C4@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Margaret Wasserman , David R Oran , radia.perlman@eng.sun.com, Tony Hain , Tim Chown , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Wed, 28 Jun 2006 13:28:41 -0700 To: Tony Li X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 28 Jun 2006 20:28:42.0694 (UTC) FILETIME=[72971E60:01C69AF1] DKIM-Signature: a=rsa-sha1; q=dns; l=2556; t=1151526525; x=1152390525; c=relaxed/simple; s=sjdkim3001; 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=20Review=20of=20draft-ietf-v6ops-nap-02.txt; X=v=3Dcisco.com=3B=20h=3DL7dXh/0Y+wnU5NCMyPFRtjvkHMY=3D; b=hsRcnAlBXAOIUdP9UAPIJSpcHxMCOTVWEhU03tKXynKdi4tcRN/m3AqEbvqQ4A8wDB3FD2G8 coj7qY+XmxvOgA123bMj1J0M81QH/3KnA8PDCkjDBOOq03KYWlLgNgz+; 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: 538aad3a3c4f01d8b6a6477ca4248793 Tony, do you have any comment on this? My initial thought is to identify the things that impact scalability, and make recommendations - perhaps in a separate document or in an appendix to this one. This comes from Dave's comments regarding "a gigabyte of more of memory, gigE's for interfaces, and multi-CPU route processors." While routers most certainly exist that have this, such routers are not found on the shelf at Fry's... On Jun 28, 2006, at 1:19 PM, David R Oran wrote: > On Jun 28, 2006, at 4:00 PM, Fred Baker wrote: >> 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? > > Nothing recent. Tony Li did some testing with IOS ISIS and host > routes about 10 years ago which as I recall scaled to about 10**4 > as opposed to 10**3. This was on much wimpier boxes than we have > today and the details are lost to me in the mists of time. > > My intuition is that 10**3 is very low, even with moderately high > updates rates due to host movement (Tony was looking into host > routes as a host mobility solution). It would be useful to add him > to this thread. > > I'm not close to this stuff anymore so appropriately de-rate my > opinion, but 50K host routes in an ISIS area does not sound the > least bit scary to me on today's boxes with a gigabyte of more of > memory, gigE's for interfaces, and multi-CPU route processors. > >> 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 Jun 28 18:02:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvi7B-0000oX-4f for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 18:02:29 -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 1FvhaF-0007zD-8e for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 17:28:27 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvhRS-00077y-GQ for v6ops-archive@lists.ietf.org; Wed, 28 Jun 2006 17:19:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvhPh-0007Re-2N for v6ops-data@psg.com; Wed, 28 Jun 2006 21:17: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.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 1FvhPg-0007RP-0h for v6ops@ops.ietf.org; Wed, 28 Jun 2006 21:17:32 +0000 Received: from [66.205.89.194] (account margaret HELO ceili) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1074748; Wed, 28 Jun 2006 17:17:28 -0400 From: "Margaret Wasserman" 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 Date: Wed, 28 Jun 2006 17:17:16 -0400 Message-ID: <00ba01c69af8$3bb2d360$f66514ac@corp.devicescape.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <41F33174-1690-4B85-8949-1639AD647AE8@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acaa7YGqTpvoYjrjSwKGCEGLZ5NBfgABrhHg Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Thu Jun 29 00:49:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvoSe-000737-Ih for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 00:49:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvoSd-0005P1-0s for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 00:49:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvoP1-000E9X-UH for v6ops-data@psg.com; Thu, 29 Jun 2006 04:45: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 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 1FvoP0-000E9I-FY for v6ops@ops.ietf.org; Thu, 29 Jun 2006 04:45:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k5T4jDKX014771; Thu, 29 Jun 2006 07:45:14 +0300 Date: Thu, 29 Jun 2006 07:45:13 +0300 (EEST) From: Pekka Savola To: "Azinger, Marla" cc: v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> Message-ID: References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1572/Wed Jun 28 17:49:41 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: 79899194edc4f33a41f49410777972f8 On Wed, 28 Jun 2006, Azinger, Marla wrote: > I ask the V6 WG to create a "best practice for multihoming" that can > be utilized today. I ask that you please insert the solution to > filter at /48 thus allowing "upstream providers" to provide > multihoming to their customers. This solution is needed to support > providers creating V6 networks and this solution can easily be added > into Marc's "IP V6 Routing Policy Guidelines" document. This is unlikely to get traction in the WG. The initial draft was basically like that but was changed. Many people (myself included) opposed (and will oppose) recommeding opening filters up to /48. Let's not create a swamp out of v6 address space with more specific junk. -- 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 Jun 29 03:26:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvqur-0005x4-Na for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 03:26: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 1FvpZB-0001me-T9 for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 01:59:53 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvpIW-0001IO-8u for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 01:42:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvpHN-000INx-JQ for v6ops-data@psg.com; Thu, 29 Jun 2006 05:41: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.6 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [208.17.35.58] (helo=cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvpHM-000INi-BV for v6ops@ops.ietf.org; Thu, 29 Jun 2006 05:41:28 +0000 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.21919749; Thu, 29 Jun 2006 01:41:05 -0400 Received: from PACDCEXCMB03.cable.comcast.com ([10.20.10.86]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 01:41:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Date: Thu, 29 Jun 2006 01:41:04 -0400 Message-ID: <4884CD6C1DF0A8429DD8DAD942BF9D9610292F@PACDCEXCMB03.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-v6ops-nap-02.txt Thread-Index: Acaa7YGqTpvoYjrjSwKGCEGLZ5NBfgABrhHgABKYnA8= From: "Durand, Alain" To: , Cc: , , , , , , , , , X-OriginalArrivalTime: 29 Jun 2006 05:41:05.0435 (UTC) FILETIME=[9D340EB0:01C69B3E] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 TWFyZ2FyZXQsDQoNCkkgdGhpbmsgSSBzaGFyZSBzb21lIG9mIHlvdXIgY29uY2VybnMgdGhhdCB0 aGUgc3VnZ2VzdGVkIHNvbHV0aW9uIGludHJvZHVjZXMgcmVhbCBvcGVyYXRpb25hbCBjb21wbGV4 aXRpZXMgZm9yIHNvbWVob3cgZG91YnRmdWwgYmVuZWZpdHMuDQoNCk9uZSBjb3VsZCBhbHNvIG9i c2VydmVkIHRoYXQgdGhlIHNvbHV0aW9uIG9ubHkgcGFydGlhbGx5IGhpZGUgdGhlIGludGVybmFs IHRvcG9sb2d5LCBhcywgYXQgdGhlIElQIGxheWVyLCB0aGUgZmFjdCB0aGF0IG11bHRpcGxlIGlu c2lkZSBob3N0cyBhcmUgcHJlc2VudCBpcyB2aXNpYmxlIGZyb20gdGhlIG91dHNpZGUgd2hpbGUg d2l0aCBOQVQsIG9ubHkgb25lIGFkZHJlc3Mgd2FzIHZpc2libGUuLi4NCg0KQWx0aG91Z2ggSSBz dWJzY3JpYmUgdG8gdGhlIG9yaWdpbmFsIGdvYWwgb2YgdGhlIGRvY3VtZW50IHRvIHNob3cgdGhh dCBtYW55IG9mIHRoZSBhbGxlZGdlZCBiZW5lZml0cyBmcm9tIE5BVCBjYW4gYmUgYWNoaWV2ZWQg dXNpbmcgc2ltcGxlIHRlY2huaXF1ZXMgd2l0aCBJUHY2LCBJIHRoaW5rIHdlIGFyZSBub3cgd2F5 IHBhc3QgdGhlIHBvaW50IG9mIGRpbWluaXNoaW5nIHJldHVybiBhbmQgbWFraW5nIGRldGFpbGVk IHJlY29tbWVuZGF0aW9ucyBmb3IgYSB2ZXJ5IGNvbXBsZXggdG9wb2xvZ3kgaGlkaW5nIGFyY2hp dGVjdHVyZSBkZWZlYXQgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudC4NCg0KSU1ITywgd2Un bGwgYmUgbXVjaCBiZXR0ZXIgb2YgbGlzdGluZyB0b3BvbG9neSBoaWRpbmcgYXMgYSBmZWF0dXJl IG9mIE5BVC4NCg0KICAgLSBBbGFpbi4NCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCkZyb206IG93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZyA8b3duZXItdjZvcHNAb3BzLmlldGYu b3JnPg0KVG86IHY2b3BzQG9wcy5pZXRmLm9yZyA8djZvcHNAb3BzLmlldGYub3JnPg0KQ2M6ICdU b255IEhhaW4nIDxhbGgtaWV0ZkB0bmRoLm5ldD47ICdUaW0gQ2hvd24nIDx0amNAZWNzLnNvdG9u LmFjLnVrPjsgJ1JhZGlhIFBlcmxtYW4nIDxSYWRpYS5QZXJsbWFuQHN1bi5jb20+OyAnQWxleCBa aW5pbicgPHppbmluQHBzZy5jb20+OyAnRXJpayBOb3JkbWFyaycgPGVyaWsubm9yZG1hcmtAc3Vu LmNvbT47IERvbmFsZC5FYXN0bGFrZUBtb3Rvcm9sYS5jb20gPERvbmFsZC5FYXN0bGFrZUBtb3Rv cm9sYS5jb20+OyAnRGF2ZSBPcmFuJyA8b3JhbkBjaXNjby5jb20+OyAnQmlsbCBGZW5uZXInIDxm ZW5uZXJAcmVzZWFyY2guYXR0LmNvbT47ICdKYXJpIEFya2tvJyA8amFyaS5hcmtrb0BwaXVoYS5u ZXQ+OyBkYXZpZC5rZXNzZW5zQG5va2lhLmNvbSA8ZGF2aWQua2Vzc2Vuc0Bub2tpYS5jb20+DQpT ZW50OiBXZWQgSnVuIDI4IDE3OjE3OjE2IDIwMDYNClN1YmplY3Q6IFJFOiBSZXZpZXcgb2YgZHJh ZnQtaWV0Zi12Nm9wcy1uYXAtMDIudHh0DQoNCg0KSGkgQWxsLA0KDQpBcyBJIHVuZGVyc3RhbmQg aXQsIHRoZXJlIGlzIGEgY3VycmVudCBwcm9wb3NhbCBpbiB0aGUgdjZvcHMgV0cgKGluDQpkcmFm dC1pZXRmLXY2b3BzLW5hcC0wMy1kcmFmdDAudHh0KSB0byBwdWJsaXNoIHRoZSBmb2xsb3dpbmcg cmVjb21tZW5kYXRpb246DQoNCiAgIFRoZXJlIGFyZSBvdGhlciBwb3NzaWJsZSBzY2VuYXJpb3Mg Zm9yIHRoZSBleHRyZW1lIHNpdHVhdGlvbiB3aGVuIGENCiAgIG5ldHdvcmsgbWFuYWdlciBhbHNv IHdpc2hlcyB0byBmdWxseSBjb25jZWFsIHRoZSBpbnRlcm5hbCBJUHY2DQogICB0b3BvbG9neS4g IEluIHRoZXNlIGNhc2VzIHRoZSBnb2FsIGluIHJlcGxhY2luZyB0aGUgSVB2NCBOQVQgYXBwcm9h Y2gNCiAgIGlzIHRvIG1ha2UgYWxsIG9mIHRoZSB0b3BvbG9neSBoaWRkZW4gbm9kZXMgYXBwZWFy IGZyb20gdGhlIG91dHNpZGUNCiAgIHRvIGV4aXN0IGF0IHRoZSBlZGdlIG9mIHRoZSBuZXR3b3Jr LCBqdXN0IGFzIHRoZXkgd291bGQgd2hlbiBiZWhpbmQgYQ0KICAgTkFULg0KDQogICBvICBPbmUg Y291bGQgdXNlIGV4cGxpY2l0IGhvc3Qgcm91dGVzIGFuZCByZW1vdmUgdGhlIGNvcnJlbGF0aW9u DQogICAgICBiZXR3ZWVuIGxvY2F0aW9uIGFuZCBJUHY2IGFkZHJlc3MuICBJbiB0aGUgZmlndXJl IGJlbG93IHRoZSBob3N0cw0KICAgICAgd291bGQgYmUgYWxsb2NhdGVkIHByZWZpeGVzIGZyb20g b25lIG9yIG1vcmUgbG9naWNhbCBzdWJuZXRzLCBhbmQNCiAgICAgIHdvdWxkIGluamVjdCBob3N0 IHJvdXRlcyB0byBpbnRlcm5hbGx5IGlkZW50aWZ5IHRoZWlyIHJlYWwNCiAgICAgIGF0dGFjaG1l bnQgcG9pbnQuICBUaGlzIHNvbHV0aW9uIGRvZXMgaG93ZXZlciBzaG93IHNldmVyZQ0KICAgICAg c2NhbGFiaWxpdHkgaXNzdWVzIGFuZCBzaG91bGQgYmUgbGltaXRlZCB0byB1c2VzIHdpdGgNCiAg ICAgIHN1YnN0YW50aWFsbHkgZmV3ZXIgdGhhbiB0aGUgbWF4aW11bSBudW1iZXIgb2Ygcm91dGVz IHRoYXQgdGhlIElHUA0KICAgICAgY2FuIHN1cHBvcnQgKGdlbmVyYWxseSBhYm91dCA1MCwwMDAp Lg0KDQpbLi4uc25pcC4uLl0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbnRlcm5l dA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAg ICAgICAgICB8IFNpbXBsZSBHYXRld2F5ICAgfCAgTG9naWNhbCBzdWJuZXQNCiAgICAgICAgICAg ICAgICAgICAgICAgfCBvciBIb21lIEFnZW50ICAgIHwtKy0rLSstKy0rLSstKy0rLS0NCiAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgIGZvciB0b3BvbG9neQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgaGlkZGVuIG5vZGVzDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICBSZWFsIGlu dGVybmFsICAtLS0tLS0tLS0tLS0tKy0NCiAgICAgICAgICAgICAgIHRvcG9sb2d5ICAgICAgIHwg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAt Ky0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0tLSstLS0tLS0tLSsNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KDQoNClRoZSBtb3JlIEkg dGhpbmsgYWJvdXQgdGhpcyBwcm9wb3NhbCwgdGhlIG1vcmUgcXVlc3Rpb25zIGFyaXNlLCBzdWNo IGFzOg0KDQooMSkgRG8gd2UgcmVhbGx5IG1lYW4gdGhhdCB0aGUgcm91dGVyIGluIHRoaXMgcGlj dHVyZSB3b3VsZCBiZSBhICJzaW1wbGUNCmdhdGV3YXkgb3IgaG9tZSBhZ2VudCI/ICBJIGRvbid0 IHRoaW5rIHRoYXQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBpZGVhIHRoYXQNCml0IGNvdWxkIGhh bmRsZSA1MCwwMDAgcm91dGVzLiAgT3IgdGhhdCBpdCB3b3VsZCBydW4gYW4gSUdQLCBmb3IgdGhh dA0KbWF0dGVyLg0KDQooMikgV2hhdCBtZWNoYW5pc20gd291bGQgaG9zdHMgdXNlIHRvIGluamVj dCBob3N0IHJvdXRlcyBpbnRvIHRoZSBJR1A/ICBIb3cNCmlzIHRoYXQgc2VjdXJlZD8NCg0KKDMp IEhvdyB3aWxsIGxvY2FsIG5vZGVzIGtub3cgdG8gdXNlIHRvcG9sb2d5LXNwZWNpZmljIFVMQSBh ZGRyZXNzZXMgZm9yDQpsb2NhbCBjb21tdW5pY2F0aW9uPyAgV2hhdCBoYXBwZW5zIGlmIHRoZXkg ZG9uJ3Q/ICBDb3VsZCB0aGlzIHJlc3VsdCBpbiBhDQpsYXJnZSBhbW91bnQgb2YgaW50ZXJuYWwg dHJhZmZpYyBib3VuY2luZyBvZmYgb2YgdGhlICJzaW1wbGUgZ2F0ZXdheSBvciBob21lDQphZ2Vu dCI/DQoNCig0KSBIb3cgZG9lcyB0aGlzIGludGVyYWN0IHdpdGggbXVsdGljYXN0IHRyYWZmaWMg YW5kIE5ELiAgQ2FuIGEgbm9kZSBvbiB0aGUNCiJsb2dpY2FsIHN1Ym5ldCIgc2VuZCBhIGxpbmst bG9jYWwgbXVsdGljYXN0IHBhY2tldCBvbiB0aGUgbG9naWNhbCBzdWJuZXQNCmFuZCBzYWZlbHkg YXNzdW1lIHRoYXQgaXQgd2lsbCByZWFjaCBhbGwgb2YgdGhlIG5vZGVzIG9uIHRoYXQgc3VibmV0 IGFuZCBubw0Kb25lIGVsc2U/ICBJZiBub3QsIGhvdyBkb2VzIHRoaXMgaW50ZXJhY3Qgd2l0aCBO RD8gIA0KDQooNSkgV291bGQgYXV0b2NvbmZpZ3VyYXRpb24gYmUgdXNlZCBvbiB0aGUgbG9naWNh bCBzdWJuZXQsIG9yIHdvdWxkIGhvc3RzIGJlDQpleHBlY3RlZCB0byBnZXQgdGhvc2UgYWRkcmVz c2VzIHRocm91Z2ggb3RoZXIgbWVhbnM/DQoNCig2KSBXaGF0IGFkdmFudGFnZXMgKGlmIGFueSkg ZG9lcyB0aGlzIGFwcHJvYWNoIGhhdmUgb3ZlciB1c2luZyBhIHNpbmdsZQ0Kc3VibmV0IGludGVy bmFsbHkgYW5kIHVzaW5nIEwyIHN3aXRjaGVzIGFuZCBWTEFOcyB0byBoYW5kbGUgaW50ZXJuYWwg cGFja2V0DQpkZWxpdmVyeT8gIFdoYXQgZGlzYWR2YW50YWdlcyBkb2VzIGl0IGhhdmUgd2hlbiBj b21wYXJlZCB0byB0aGF0IGFwcHJvYWNoPw0KDQooNykgSG93IGRvZXMgdGhpcyBwcm9wb3NhbCBy ZWxhdGUgdG8gdGhlIHdvcmsgY3VycmVudGx5IHVuZGVyd2F5IGluIHRoZQ0KVFJJTEwgV0c/DQoN CklmIHdlIGRlY2lkZSB0aGF0IHdlIGFjdHVhbGx5IHdhbnQgdG8gbWFrZSB0aGlzIHJlY29tbWVu ZGF0aW9uLCBJJ2QgcHJlZmVyDQp0aGF0IHdlIHJlbW92ZSBpdCBmcm9tIHRoaXMgZG9jdW1lbnQg YW5kIG1ha2UgdGhpcyByZWNvbW1lbmRhdGlvbiBpbiBhDQpzZXBhcmF0ZSBkb2N1bWVudCB0aGF0 IGNvdmVycyB0aGUgc2NhbGFiaWxpdHkgaXNzdWVzLCB0aGUgYW5zd2VycyBteQ0KcXVlc3Rpb25z IGFib3ZlLCBhbmQgYW55IG90aGVyIGZhY3RvcnMgdGhhdCBtYXkgYWZmZWN0IHRoZSBhcHBsaWNh YmlsaXR5IG9mDQp0aGlzIHNvbHV0aW9uLg0KDQpNYXJnYXJldA0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRnJlZCBCYWtlciBbbWFpbHRvOmZyZWRAY2lzY28uY29t XSANCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDI4LCAyMDA2IDQ6MDAgUE0NCj4gVG86IE1hcmdh cmV0IFdhc3Nlcm1hbjsgRGF2ZSBPcmFuOyByYWRpYS5wZXJsbWFuQGVuZy5zdW4uY29tDQo+IENj OiAnVG9ueSBIYWluJzsgJ1RpbSBDaG93bic7IHY2b3BzQG9wcy5pZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogUmV2aWV3IG9mIGRyYWZ0LWlldGYtdjZvcHMtbmFwLTAyLnR4dA0KPiANCj4gUmFkaWEg YW5kIERhdmU6DQo+IA0KPiBUaGVyZSBpcyBhIGRpc3B1dGUgZ29pbmcgb24gcmVnYXJkaW5nIHRo ZSBzY2FsYWJpbGl0eSBvZiANCj4gdG9wb2xvZ3kgaGlkaW5nIGJ5IHdoYXQgYW1vdW50cyB0byBJ Uy1JUyBsZXZlbCAxIHJvdXRpbmcgDQo+IChpZGVudGlmeWluZyBob3N0cyBpbiBhIG11bHRpLUxB TiBuZXR3b3JrIGJ5IHRoZWlyIGhvc3QgDQo+IGlkZW50aWZpZXIgYW5kIHVzaW5nIGEgY29tbW9u IHN1Ym5ldCBJRCBmb3IgdGhlIGRvbWFpbikuIERvIA0KPiB5b3Uga25vdyBvZiBhdmFpbGFibGUg ZG9jdW1lbnRhdGlvbiBvZiBJUy1JUyBsZXZlbCAxIHJvdXRpbmcgDQo+IGFuZCBpdHMgdGVzdGVk IHNjYWxhYmlsaXR5Pw0KPiANCj4gQXMgUmFkaWEga25vd3MsIHRoaXMgcXVlc3Rpb24gaXMgYWxz byBiZWluZyBsb29rZWQgYXQgaW4gSUVFRSANCj4gODAyLjEsIHdoaWNoIHByZXN1bWVzIHRoYXQg dGhlcmUgaXMgb25seSBhIHNpbmdsZSANCj4gbXVsdGktTEFOLUxBTiwgYW5kIHRoYXQgTUFDIGFk ZHJlc3NlcyBhcmUgdXNlZCB0byByb3V0ZSB3aXRoaW4gaXQuDQo+IA0KPiBGcmVkDQo+IA0KPiBP biBKdW4gMjgsIDIwMDYsIGF0IDEyOjQwIFBNLCBNYXJnYXJldCBXYXNzZXJtYW4gd3JvdGU6DQo+ IA0KPiA+IDUwSyBpcyBhbiBvcmRlciBvZiBtYWduaXR1ZGUgaGlnaGVyIHRoYW4gdGhlIGFuYWx5 c2lzIGluIA0KPiBBbGV4IFppbmluJ3MgDQo+ID4gcHJlc2VudGF0aW9uIHdvdWxkIHNlZW0gdG8g aW5kaWNhdGUuICBIaXMgcHJlc2VudGF0aW9uIA0KPiBpbmRpY2F0ZXMgdGhhdCANCj4gPiBmbGF0 DQo+ID4gcm91dGluZyB3aWxsIG9ubHkgc2NhbGUgdG8gc29tZXRoaW5nIG9uIHRoZSBvcmRlciBv ZiAxSyBub2Rlcy4gICANCj4gPiBQbGVhc2UgZmVlbA0KPiA+IGZyZWUgdG8gY2hlY2sgd2l0aCBB bGV4LCB0aG91Z2gsIGFzIGhlIGNlcnRhaW5seSBoYXMgbW9yZSANCj4gPiB1bmRlcnN0YW5kaW5n IG9mIElHUCBzY2FsaW5nIHRoYW4gSSBkby4NCj4gPiBbc25pcF0NCj4gPiBJZiB0aGlzIGRvY3Vt ZW50IGlzIGdvaW5nIHRvIHJlY29tbWVuZCBkb2luZyBmbGF0IHJvdXRpbmcgDQo+IGZvciB0b3Bv bG9neSANCj4gPiBoaWRpbmcsIEkgdGhpbmsgdGhhdCB0aGUgV0cgbmVlZHMgdG8gZG8gdGhlIGFu YWx5c2lzIHRvIA0KPiBkZXRlcm1pbmUgdGhhdCANCj4gPiB0aGlzIGlzIGEgdmFsaWQgYW5kIHNj YWxhYmxlIHRlY2huaXF1ZS4NCj4gDQoNCg0K From owner-v6ops@ops.ietf.org Thu Jun 29 04:30:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvruX-0001Rh-PC for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 04:30:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvruT-0005mh-EB for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 04:30:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvrsS-0006CO-1Z for v6ops-data@psg.com; Thu, 29 Jun 2006 08:27: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,SPF_PASS autolearn=ham version=3.1.1 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvrsQ-0006Bl-Hb for v6ops@ops.ietf.org; Thu, 29 Jun 2006 08:27:54 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k5T8Rpl0050080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 29 Jun 2006 08:27:51 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 k5T8TDdE115820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jun 2006 09:29:14 +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 k5T8RnLI009631 for ; Thu, 29 Jun 2006 09:27:49 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5T8Rndp009622; Thu, 29 Jun 2006 09:27:49 +0100 Received: from zurich.ibm.com (sig-9-146-223-179.de.ibm.com [9.146.223.179]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA52924; Thu, 29 Jun 2006 10:27:48 +0200 Message-ID: <44A38F07.6050702@zurich.ibm.com> Date: Thu, 29 Jun 2006 10:27:51 +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: "Azinger, Marla" , v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@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.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Pekka Savola wrote: > On Wed, 28 Jun 2006, Azinger, Marla wrote: > >> I ask the V6 WG to create a "best practice for multihoming" that can >> be utilized today. I ask that you please insert the solution to >> filter at /48 thus allowing "upstream providers" to provide >> multihoming to their customers. This solution is needed to support >> providers creating V6 networks and this solution can easily be added >> into Marc's "IP V6 Routing Policy Guidelines" document. > > > This is unlikely to get traction in the WG. The initial draft was > basically like that but was changed. Many people (myself included) > opposed (and will oppose) recommeding opening filters up to /48. > > Let's not create a swamp out of v6 address space with more specific junk. > See RFC 4177 section 5.1: "This approach generally meets all the goals for multi-homing approaches with one notable exception: scaleability." Brian From owner-v6ops@ops.ietf.org Thu Jun 29 04:33:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvrxO-0001k5-6L for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 04:33:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvrxK-0005rr-Dc for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 04:33:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvrxB-0006Zq-RU for v6ops-data@psg.com; Thu, 29 Jun 2006 08:32:49 +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 [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvrxA-0006ZM-2V for v6ops@ops.ietf.org; Thu, 29 Jun 2006 08:32:48 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.6/8.13.6) with ESMTP id k5T8WhPl167284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 29 Jun 2006 08:32:44 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 k5T8ZFCe139394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jun 2006 10:35:17 +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 k5T8WeoC020367 for ; Thu, 29 Jun 2006 10:32:41 +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 k5T8WdDO020337; Thu, 29 Jun 2006 10:32:39 +0200 Received: from zurich.ibm.com (sig-9-146-223-179.de.ibm.com [9.146.223.179]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA27430; Thu, 29 Jun 2006 10:32:36 +0200 Message-ID: <44A39028.2090009@zurich.ibm.com> Date: Thu, 29 Jun 2006 10:32:40 +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: "Durand, Alain" CC: margaret@thingmagic.com, v6ops@ops.ietf.org, alh-ietf@tndh.net, tjc@ecs.soton.ac.uk, Radia.Perlman@sun.com, zinin@psg.com, erik.nordmark@sun.com, Donald.Eastlake@motorola.com, oran@cisco.com, fenner@research.att.com, jari.arkko@piuha.net, david.kessens@nokia.com Subject: Re: Review of draft-ietf-v6ops-nap-02.txt References: <4884CD6C1DF0A8429DD8DAD942BF9D9610292F@PACDCEXCMB03.cable.comcast.com> In-Reply-To: <4884CD6C1DF0A8429DD8DAD942BF9D9610292F@PACDCEXCMB03.cable.comcast.com> 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: 0e9ebc0cbd700a87c0637ad0e2c91610 Alain (co-author hat on) I understand the objections to this text. As I've already suggested to my co-authors, I think we need to be more explicit in identifying the parts of the document that refer to fully defined solutions and the parts that refer to potential solutions, and that is what this part is. The original intention was not to assert that everything is done, but rather that potential solutions exist (and those are where we should put effort). So Margaret is probably correct that a separate document is needed, but I believe it is appropriate in the NAP document to show that there are potential solutions. In fact, that's why we have the "gap analysis" section. Brian Durand, Alain wrote: > Margaret, > > I think I share some of your concerns that the suggested solution introduces real operational complexities for somehow doubtful benefits. > > One could also observed that the solution only partially hide the internal topology, as, at the IP layer, the fact that multiple inside hosts are present is visible from the outside while with NAT, only one address was visible... > > Although I subscribe to the original goal of the document to show that many of the alledged benefits from NAT can be achieved using simple techniques with IPv6, I think we are now way past the point of diminishing return and making detailed recommendations for a very complex topology hiding architecture defeat the purpose of this document. > > IMHO, we'll be much better of listing topology hiding as a feature of NAT. > > - Alain. > > > > ----- Original Message ----- > From: owner-v6ops@ops.ietf.org > To: v6ops@ops.ietf.org > Cc: 'Tony Hain' ; 'Tim Chown' ; 'Radia Perlman' ; 'Alex Zinin' ; 'Erik Nordmark' ; Donald.Eastlake@motorola.com ; 'Dave Oran' ; 'Bill Fenner' ; 'Jari Arkko' ; david.kessens@nokia.com > Sent: Wed Jun 28 17:17:16 2006 > 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 Thu Jun 29 05:05:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsSa-00038u-2g for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 05:05:16 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvsSV-0008S0-Tc for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 05:05:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FvsRQ-0009Kt-TW for v6ops-data@psg.com; Thu, 29 Jun 2006 09:04: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,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 1FvsRP-0009Kf-HG for v6ops@ops.ietf.org; Thu, 29 Jun 2006 09:04:03 +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 k5T93wQG015218 for ; Thu, 29 Jun 2006 10:03:58 +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 k5T93YrT025399 for ; Thu, 29 Jun 2006 10:03:35 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k5T93Tww016586 for v6ops@ops.ietf.org; Thu, 29 Jun 2006 10:03:29 +0100 Date: Thu, 29 Jun 2006 10:03:29 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Review of draft-ietf-v6ops-nap-02.txt Message-ID: <20060629090329.GF15846@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <4884CD6C1DF0A8429DD8DAD942BF9D9610292F@PACDCEXCMB03.cable.comcast.com> <44A39028.2090009@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A39028.2090009@zurich.ibm.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: 7655788c23eb79e336f5f8ba8bce7906 On Thu, Jun 29, 2006 at 10:32:40AM +0200, Brian E Carpenter wrote: > Alain > > (co-author hat on) > > I understand the objections to this text. As I've already suggested to > my co-authors, I think we need to be more explicit in identifying the > parts of the document that refer to fully defined solutions and the > parts that refer to potential solutions, and that is what this part > is. The original intention was not to assert that everything is done, > but rather that potential solutions exist (and those are where we should > put effort). > > So Margaret is probably correct that a separate document is needed, but > I believe it is appropriate in the NAP document to show that there > are potential solutions. In fact, that's why we have the "gap analysis" > section. I agree, and recall suggesting it was moved to an appendix for the same reason, i.e. cited, but clearly not part of the 'can do now' text. Tim From owner-v6ops@ops.ietf.org Thu Jun 29 11:53:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvypG-00012L-RI for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 11:53:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvypG-0002OY-7e for v6ops-archive@lists.ietf.org; Thu, 29 Jun 2006 11:53:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Fvym3-000Nd4-35 for v6ops-data@psg.com; Thu, 29 Jun 2006 15:49:47 +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=BAYES_00,DNS_FROM_RFC_POST, SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=no 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 1Fvym1-000Ncj-IC for v6ops@ops.ietf.org; Thu, 29 Jun 2006 15:49:45 +0000 Received: from ([172.27.14.137]) by mail04.frontiercorp.com with ESMTP id 4028772.73005363; Thu, 29 Jun 2006 11:10:25 -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: Thu, 29 Jun 2006 08:38:21 -0700 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters Thread-Index: AcabNuG2JwI7QwklRp6BP9aTO6LzjgAV4UMQ From: "Azinger, Marla" To: "Pekka Savola" Cc: , Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 If the IETF V6ops WG doesn't give traction to this solution then this WG = will push this to become resolved in other conference mediums. The = charter for IETF appears to involve this type of work and to me appears = to be the most appropriate place. =20 There are a large number of people who would like to open filters to /48 = so we can freely multihome. However, it is shut down comments like this = that scare many people off from participating in discussion and using = their voice to say what they would like to see done with routing. I may = appear as one small voice, but there are allot of unheard ones out there = that agree with the /48 filter. Due to the lack of another solution for upstream providers to provide = multihoming, I see it as good solution. I also believe that this = solution should be given serious consideration. Weigh out the pro's and = con's. Not having a solution for upstream providers to provide = multihoming is a very large con for not using an available solution = today. Especially since without our V6 capable networks, v6 wont be = routed or used at all.=20 As for swamp. It won't be swamp if no other solution is created, and as = of today their is large conflict over what solution and if that = developed solution will even work. So it may never become swamp. And = if it does, I'm sure we can adapt and overcome. Thank you for your time Marla Azinger Frontier Communications -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, June 28, 2006 9:45 PM To: Azinger, Marla Cc: v6ops@ops.ietf.org Subject: Re: v6 multihoming and route filters autolearn=3Dham version=3D3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on = otso.netcore.fi X-esp: ESP<17>=3DRBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> = SenderID:<0> Spam Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0> Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0> Embed HTML Dictionary (TRU10):<0> Float Dictionary (TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time Signatures:<0> Spam Dictionary 2 (TRU10):<0>=20 Return-Path: pekkas@netcore.fi X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) = FILETIME=3D[E192EE80:01C69B36] On Wed, 28 Jun 2006, Azinger, Marla wrote: > I ask the V6 WG to create a "best practice for multihoming" that can=20 > be utilized today. I ask that you please insert the solution to=20 > filter at /48 thus allowing "upstream providers" to provide=20 > multihoming to their customers. This solution is needed to support=20 > providers creating V6 networks and this solution can easily be added=20 > into Marc's "IP V6 Routing Policy Guidelines" 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 From owner-v6ops@ops.ietf.org Fri Jun 30 03:44:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwDfb-0004Uf-CO for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 03:44:07 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwDfX-0002nn-QC for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 03:44:07 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwDcC-000Mqu-G5 for v6ops-data@psg.com; Fri, 30 Jun 2006 07:40: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.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwDc9-000MqP-Qk for v6ops@ops.ietf.org; Fri, 30 Jun 2006 07:40:33 +0000 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2006 09:40:34 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5U7eVrq023190; Fri, 30 Jun 2006 09:40:31 +0200 (MEST) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jun 2006 09:40:31 +0200 Received: from [196.217.253.131] ([10.61.64.21]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Jun 2006 09:40:30 +0200 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D63@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: "Pekka Savola" , , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: v6 multihoming and route filters Date: Fri, 30 Jun 2006 07:40:28 +0000 To: "Azinger, Marla" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Jun 2006 07:40:30.0507 (UTC) FILETIME=[765507B0:01C69C18] Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 My opinion - and please note that it is just that, not an edict of any kinds - is that in the final analysis it is not the IETF but operational reality that controls the issues here. If your customer will pay you enough to advertise a prefix that you don't own and to arrange corresponding ingress filter and route management with your upstream networks, you're going to do so regardless of what any RFC says, and it will in fact work because you will make the necessary business and routing arrangements to support it. That said, the level of effort involved will make the price fairly high, which means that you will not be doing a lot of this. A "Best Current Practice" is not something with those business constraints, I should think. By the way, threatening people is not a very convincing argument style. If you want something done, how about helping us do it, and honestly addressing the issues and concerns raised? What may have applicability is Steve Deering's concept of Metropolitan Addressing, which it looks like someone needs to describe in an Internet Draft (it is in the slides at ftp:// ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/ presentations/allocation/deering.slides.ps). In short, his proposal was that a regional entity such as a civil community of some size gets a prefix and the ISPs that serve it agree to carry its routes such that a user can multihome within the community and outside it one routes to the community. This scales in the same way that Provider Addressing scales, with the caveats that each provider will have full /48 (or /56 I imagine) routes for community on the set of machines that serves it, and will need fairly explicit controls to ensure that the routing doesn't leak. Would you like to come to the working group and discuss the issues with us in Montreal? I think that would be more productive than this discussion is being right now. On Jun 29, 2006, at 3:38 PM, Azinger, Marla wrote: > If the IETF V6ops WG doesn't give traction to this solution then > this WG will push this to become resolved in other conference > mediums. The charter for IETF appears to involve this type of work > and to me appears to be the most appropriate place. > > There are a large number of people who would like to open filters > to /48 so we can freely multihome. However, it is shut down > comments like this that scare many people off from participating in > discussion and using their voice to say what they would like to see > done with routing. I may appear as one small voice, but there are > allot of unheard ones out there that agree with the /48 filter. > > Due to the lack of another solution for upstream providers to > provide multihoming, I see it as good solution. I also believe > that this solution should be given serious consideration. Weigh > out the pro's and con's. Not having a solution for upstream > providers to provide multihoming is a very large con for not using > an available solution today. Especially since without our V6 > capable networks, v6 wont be routed or used at all. > > As for swamp. It won't be swamp if no other solution is created, > and as of today their is large conflict over what solution and if > that developed solution will even work. So it may never become > swamp. And if it does, I'm sure we can adapt and overcome. > > Thank you for your time > Marla Azinger > Frontier Communications > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, June 28, 2006 9:45 PM > To: Azinger, Marla > Cc: v6ops@ops.ietf.org > Subject: Re: v6 multihoming and route filters > > > autolearn=ham version=3.1.2 > X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on > otso.netcore.fi > X-esp: ESP<17>=RBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> > SenderID:<0> Spam > Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0> > Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0> > Embed HTML Dictionary (TRU10):<0> Float Dictionary > (TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time > Signatures:<0> Spam Dictionary 2 (TRU10):<0> > Return-Path: pekkas@netcore.fi > X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME= > [E192EE80:01C69B36] > > On Wed, 28 Jun 2006, Azinger, Marla wrote: >> I ask the V6 WG to create a "best practice for multihoming" that can >> be utilized today. I ask that you please insert the solution to >> filter at /48 thus allowing "upstream providers" to provide >> multihoming to their customers. This solution is needed to support >> providers creating V6 networks and this solution can easily be added >> into Marc's "IP V6 Routing Policy Guidelines" document. > > This is unlikely to get traction in the WG. The initial draft was > basically like that but was changed. Many people (myself included) > opposed (and will oppose) recommeding opening filters up to /48. > > Let's not create a swamp out of v6 address space with more specific > junk. > > -- > 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 Fri Jun 30 06:32:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwGIp-0003bq-D4 for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 06:32:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwGIm-0007jQ-VR for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 06:32:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwGGS-000Muq-4j for v6ops-data@psg.com; Fri, 30 Jun 2006 10:30: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,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 1FwGGP-000MuK-C3 for v6ops@ops.ietf.org; Fri, 30 Jun 2006 10:30:17 +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 k5UAUBUL023294 for ; Fri, 30 Jun 2006 11:30:11 +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 k5UAU4f7016752 for ; Fri, 30 Jun 2006 11:30:04 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.12.11.20060308/8.11.6) id k5UAU1pk013507 for v6ops@ops.ietf.org; Fri, 30 Jun 2006 11:30:01 +0100 Date: Fri, 30 Jun 2006 11:30:01 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-chown-v6ops-campus-transition-03.txt Message-ID: <20060630103001.GF12184@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 8abaac9e10c826e8252866cbe6766464 Hi, I have given this personal draft an update. If there is any interest in the WG in such a document then we're happy to continue it further. The initial idea was to validate the Enterprise Scenarios text, which we feel it did for our scenario, and it was subsequently expanded to be a more detailed view of our transition (or rather integration) process. Tim Title : IPv6 Campus Transition Scenario Description and Analysis Author(s) : T. Chown Filename : draft-chown-v6ops-campus-transition-03.txt Pages : 29 Date : 2006-6-29 In this document we consider and analyse the specific scenario of IPv6 transition and deployment in a large department of a university campus network. The department is large enough to operate its own instances of all the conventional university services including (for example) web, DNS, email, filestore, interactive logins, and remote and wireless access. The scenario is a dual-stack one, i.e. transition to IPv6 means deploying IPv6 in the first instance alongside IPv4. This analysis identifies the available (and still missing) components for IPv6 transition, while validating the applicability of the IPv6 Enterprise Network Scenarios informational text. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-v6ops-campus-transition-03.txt From owner-v6ops@ops.ietf.org Fri Jun 30 11:22:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKos-0000kE-2c for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 11:22:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKop-0005Fj-Lt for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 11:22:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwKm9-000BCM-Ne for v6ops-data@psg.com; Fri, 30 Jun 2006 15:19: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,SPF_PASS autolearn=ham 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 1FwKm8-000BC8-GH for v6ops@ops.ietf.org; Fri, 30 Jun 2006 15:19:20 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k5UFJHUe105696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Jun 2006 15:19:18 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5UFKfis109522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jun 2006 16:20:42 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5UFJGMq003924 for ; Fri, 30 Jun 2006 16:19:17 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5UFJG33003918; Fri, 30 Jun 2006 16:19:16 +0100 Received: from zurich.ibm.com (sig-9-145-253-85.de.ibm.com [9.145.253.85]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA43686; Fri, 30 Jun 2006 17:19:14 +0200 Message-ID: <44A540F5.7030906@zurich.ibm.com> Date: Fri, 30 Jun 2006 17:19:17 +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: Fred Baker CC: "Azinger, Marla" , Pekka Savola , v6ops@ops.ietf.org, ppml@arin.net Subject: Re: v6 multihoming and route filters References: <10ECB7F03C568F48B9213EF9E7F790D202100D63@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.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c > Would you like to come to the working group and discuss the issues with > us in Montreal? I think that would be more productive than this > discussion is being right now. > Let me echo that suggestion. I think we fully understand that there is pressure on operators, but operators need to be very, very frightened at the prospect of a network with say 10 million enterprises all asking for their /48 to be routed. This isn't even an alarmist number, it's just a direct consequence of the scaling that IPv6 allows and the size of the world economy. Brian From owner-v6ops@ops.ietf.org Fri Jun 30 11:57:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLMm-00019K-6N for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 11:57:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwLMj-0001ZN-LA for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 11:57:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwLLb-000Fw2-BW for v6ops-data@psg.com; Fri, 30 Jun 2006 15:55:59 +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 1FwLLa-000Fvk-0Q for v6ops@ops.ietf.org; Fri, 30 Jun 2006 15:55:58 +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 k5UFteVQ086125 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 30 Jun 2006 17:55:40 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D202100D63@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: <955B63C3-3539-44E8-80F5-99EBAEBFD81B@muada.com> Cc: "Azinger, Marla" , "Pekka Savola" , , Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Fri, 30 Jun 2006 17:55:39 +0200 To: Fred Baker X-Mailer: Apple Mail (2.752.2) Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On 30-jun-2006, at 9:40, Fred Baker wrote: > My opinion - and please note that it is just that, not an edict of > any kinds - is that in the final analysis it is not the IETF but > operational reality that controls the issues here. There are two issues with having people inject /48s into the routing system without limitations: 1. At some point in the future, the number of routes in the DFZ could become so large that the routing system can't support it any more. This is the scaling problem that many people in the IETF are worried about. 2. A more operational and more immediate risk is leaking of more specifics. Due to the way they handle their internal and external routing, and the relationship between the two, it's not uncommon for larger networks to leak internal more specific routes into BGP. This way, an ISP with a /16 with a number of customers that each have a / 24 may leak those /24s. In IPv6 this is very dangerous, because a single ISP with a /32 can have a maximum of no less than 65536 /48s that can potentially be deaggregated. So one ISP could potentially leak a number of routes equal to a third of the global IPv4 routing table. The second issue could largely be solved by giving multihomed customers a prefix that is shorter than a /48 and then filter out / 48s but allow /47 and shorter. But that's not the way things work today. > What may have applicability is Steve Deering's concept of > Metropolitan Addressing, which it looks like someone needs to > describe in an Internet Draft (it is in the slides at ftp:// > ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/ > presentations/allocation/deering.slides.ps). I've written a draft that takes this idea a bit further a couple of years ago, have a look at: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt From owner-v6ops@ops.ietf.org Fri Jun 30 14:37:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwNro-0007aI-Pd for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 14:37:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwNrm-0005Am-9u for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 14:37:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwNpD-000Djs-Iv for v6ops-data@psg.com; Fri, 30 Jun 2006 18:34: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=BAYES_00,DNS_FROM_RFC_ABUSE, SPF_PASS autolearn=no 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 1FwNpC-000DjX-7N for v6ops@ops.ietf.org; Fri, 30 Jun 2006 18:34:42 +0000 Received: by nf-out-0910.google.com with SMTP id g2so319069nfe for ; Fri, 30 Jun 2006 11:34:40 -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=AkADjTxfUKVR0y6XtUpDckqsI5hgX1r3tdnWZQKuIrxulpy54MEBkAmPYAop4Z4sKcyaITMvxMd2smMhAuTqqEhnZMfMNvR9ld16ryN+gBcs0srgOXZ7z/H//FYvxA6yu2DAxfp0Ni5uamtXzeJTrbSDlMVCpZDm9dXahsKvT64= Received: by 10.49.93.8 with SMTP id v8mr542871nfl; Fri, 30 Jun 2006 11:34:40 -0700 (PDT) Received: by 10.48.254.12 with HTTP; Fri, 30 Jun 2006 11:34:40 -0700 (PDT) Message-ID: <1c16a4870606301134q1bf2e373v8d620efdfbadf629@mail.gmail.com> Date: Fri, 30 Jun 2006 11:34:40 -0700 From: "Stacy Taylor" To: "Azinger, Marla" Subject: Re: [ppml] v6 multihoming and route filters Cc: "Pekka Savola" , v6ops@ops.ietf.org, ppml@arin.net In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <10ECB7F03C568F48B9213EF9E7F790D202100D63@wava00s2ke2k01.corp.pvt> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hello, What we are calling for is IETF support for what we perceive to be an operational inevitability. It is well known that carriers are market driven. If enough of our customers will pay for v6 multihoming, our marketing departments will offer it, and we will have to support it. All of that is obviously moot if other carriers are filtering on a shorter prefix length. The ARIN region is implementing the policy for /48s for end sites, and these prefixes will need to be routed and globally reachable. We all are leery of creating the v6 swamp, but this issue is pressing and necessary to implement v6 in the current environment. Thank you, Stacy Taylor On 6/29/06, Azinger, Marla wrote: > If the IETF V6ops WG doesn't give traction to this solution then this WG will push this to become resolved in other conference mediums. The charter for IETF appears to involve this type of work and to me appears to be the most appropriate place. > > There are a large number of people who would like to open filters to /48 so we can freely multihome. However, it is shut down comments like this that scare many people off from participating in discussion and using their voice to say what they would like to see done with routing. I may appear as one small voice, but there are allot of unheard ones out there that agree with the /48 filter. > > Due to the lack of another solution for upstream providers to provide multihoming, I see it as good solution. I also believe that this solution should be given serious consideration. Weigh out the pro's and con's. Not having a solution for upstream providers to provide multihoming is a very large con for not using an available solution today. Especially since without our V6 capable networks, v6 wont be routed or used at all. > > As for swamp. It won't be swamp if no other solution is created, and as of today their is large conflict over what solution and if that developed solution will even work. So it may never become swamp. And if it does, I'm sure we can adapt and overcome. > > Thank you for your time > Marla Azinger > Frontier Communications > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, June 28, 2006 9:45 PM > To: Azinger, Marla > Cc: v6ops@ops.ietf.org > Subject: Re: v6 multihoming and route filters > > > autolearn=ham version=3.1.2 > X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi > X-esp: ESP<17>=RBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> SenderID:<0> Spam > Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0> > Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0> > Embed HTML Dictionary (TRU10):<0> Float Dictionary > (TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time > Signatures:<0> Spam Dictionary 2 (TRU10):<0> > Return-Path: pekkas@netcore.fi > X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME=[E192EE80:01C69B36] > > On Wed, 28 Jun 2006, Azinger, Marla wrote: > > I ask the V6 WG to create a "best practice for multihoming" that can > > be utilized today. I ask that you please insert the solution to > > filter at /48 thus allowing "upstream providers" to provide > > multihoming to their customers. This solution is needed to support > > providers creating V6 networks and this solution can easily be added > > into Marc's "IP V6 Routing Policy Guidelines" document. > > This is unlikely to get traction in the WG. The initial draft was > basically like that but was changed. Many people (myself included) > opposed (and will oppose) recommeding opening filters up to /48. > > Let's not create a swamp out of v6 address space with more specific > junk. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ > PPML mailing list > PPML@arin.net > http://lists.arin.net/mailman/listinfo/ppml > From owner-v6ops@ops.ietf.org Fri Jun 30 15:41:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOrk-0006vt-I3 for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 15:41:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOrS-0000zj-LE for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 15:41:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwOpW-000NgI-NC for v6ops-data@psg.com; Fri, 30 Jun 2006 19:39:06 +0000 Received: from [66.15.163.216] (helo=tndh.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwOoI-000NIz-3J for v6ops@ops.ietf.org; Fri, 30 Jun 2006 19:39:06 +0000 Received: from eaglet (127.0.0.1:3002) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 30 Jun 2006 12:37:09 -0700 From: "Tony Hain" To: "'Margaret Wasserman'" , "'Fred Baker'" , "'Tim Chown'" Cc: Subject: RE: Review of draft-ietf-v6ops-nap-02.txt Date: Fri, 30 Jun 2006 12:37:16 -0700 Message-ID: <07f901c69c7c$9880e660$1c7ba8c0@tndh.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_07FA_01C69C41.EC220E60" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaORGFrfQ3OW/cEQBeMsFk9396AsgBFxRCgAuGoVUAAZRtdoA== In-Reply-To: <009501c69aea$a75e7cd0$f66514ac@corp.devicescape.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 2.9 (++) X-Scan-Signature: 3adfe80a67cad062376714ff1d7f2038 This is a multi-part message in MIME format. ------=_NextPart_000_07FA_01C69C41.EC220E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 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? ------=_NextPart_000_07FA_01C69C41.EC220E60 Content-Type: text/plain; name="draft-ietf-v6ops-nap-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-v6ops-nap-03.txt" =0A= =0A= =0A= =0A= Network Working Group G. Van de Velde=0A= Internet-Draft T. Hain=0A= Expires: January 1, 2007 R. Droms=0A= Cisco Systems=0A= B. Carpenter=0A= IBM Corporation=0A= E. Klein=0A= Tel Aviv University=0A= June 30, 2006=0A= =0A= =0A= IPv6 Network Architecture Protection=0A= =0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on January 1, 2007.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= Although there are many perceived benefits to Network Address=0A= Translation (NAT), its primary benefit of "amplifying" available=0A= address space is not needed in IPv6. In addition to NAT's many=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 1]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= serious disadvantages, there is a perception that other benefits=0A= exist, such as a variety of management and security attributes that=0A= could be useful for an Internet Protocol site. IPv6 does not support=0A= NAT by design and this document shows how Network Architecture=0A= Protection (NAP) using IPv6 can provide the same or more benefits=0A= without the need for address translation.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 7=0A= 2.1. Simple Gateway between Internet and Private Network . . . 7=0A= 2.2. Simple Security due to Stateful Filter Implementation . . 7=0A= 2.3. User/Application tracking . . . . . . . . . . . . . . . . 8=0A= 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9=0A= 2.5. Independent Control of Addressing in a Private Network . 10=0A= 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10=0A= 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11=0A= 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 12=0A= 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12=0A= 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 13=0A= 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 14=0A= 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 14=0A= 4. Using IPv6 Technology to Provide the Market Perceived=0A= Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14=0A= 4.1. Simple Gateway between Internet and Internal Network . . . 14=0A= 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15=0A= 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17=0A= 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 17=0A= 4.5. Independent Control of Addressing in a Private Network . 20=0A= 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 20=0A= 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21=0A= 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21=0A= 5.1. Medium/large private networks . . . . . . . . . . . . . . 22=0A= 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 23=0A= 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25=0A= 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 25=0A= 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 26=0A= 6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 27=0A= 6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 27=0A= 6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 27=0A= 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28=0A= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28=0A= 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28=0A= 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29=0A= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 2]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29=0A= 11.2. Informative References . . . . . . . . . . . . . . . . . . 30=0A= Appendix A. Additional Benefits due to Native IPv6 and=0A= Universal Unique Addressing . . . . . . . . . . . . 31=0A= A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 31=0A= A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 31=0A= A.3. Native Multicast Services . . . . . . . . . . . . . . . . 32=0A= A.4. Increased Security Protection . . . . . . . . . . . . . . 32=0A= A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 33=0A= A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 33=0A= A.7. Community of interest . . . . . . . . . . . . . . . . . . 33=0A= Appendix B. Revision history . . . . . . . . . . . . . . . . . . 34=0A= B.1. Changes from *-vandevelde-v6ops-nap-00 to=0A= *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 34=0A= B.2. Changes from *-vandevelde-v6ops-nap-01 to=0A= *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 34=0A= B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 34=0A= B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 34=0A= B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 42=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 3]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= There have been periodic claims that IPv6 will require a Network=0A= Address Translation (NAT), because in IPv4 people use NAT to=0A= accomplish that person's preferred task. This document will explain=0A= why those pronouncements are false by showing how to accomplish the=0A= task goal without address translation. Although there are many=0A= perceived benefits to NAT, its primary benefit of "amplifying"=0A= available address space is not needed in IPv6. The serious=0A= disadvantages and impact on applications by ambiguous address space=0A= and Network Address Translation [1] [5] have been well documented [4]=0A= [6] so there will not be much additional discussion here. However,=0A= given its wide deployment NAT undoubtedly has some perceived=0A= benefits, though the bulk of those using it have not evaluated the=0A= technical trade-offs. Indeed, product marketing departments have=0A= effectively driven a perception that some connectivity and security=0A= concerns can only be solved by using a NAT device, without any=0A= mention of the negative impacts on applications. This is amplified=0A= through the widespread sharing of vendor best practice documents and=0A= sample configurations that do not differentiate the translation=0A= function of address expansion from the state function of limiting=0A= connectivity.=0A= =0A= This document describes the goals for utilizing a NAT device in an=0A= IPv4 environment that are regularly cited as solutions for perceived=0A= problems. It then shows how these needs can be met without using the=0A= header modification feature of NAT in an IPv6 network. It should be=0A= noted that this document is 'informational', as it discusses=0A= approaches that will work to accomplish the goals. It is=0A= specifically not a BCP that is recommending any one approach.=0A= =0A= As far as security and privacy are concerned, this document considers=0A= how to mitigate a number of threats. Some are obviously external,=0A= such as having a hacker or a worm infected machine outside trying to=0A= penetrate and attack the local network. Some are local such as a=0A= disgruntled employee disrupting business operations, or the=0A= unintentional negligence of a user downloading some malware which=0A= then proceeds to attack from within. Some may be inherent in the=0A= device hardware ("embedded") such as having some firmware in a=0A= domestic appliance "call home" to its manufacturer without the user's=0A= consent.=0A= =0A= Another consideration discussed is the view that NAT can be used to=0A= fulfill the goals of a security policy. At a technical level the=0A= translation process fundamentally can not produce security because=0A= mangling the address in the header does not fulfill any useful=0A= security functions; in fact it breaks the ability to produce an audit=0A= trail which is a fundamental security tool. That said, the artifacts=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 4]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= of NAT devices do provide some value.=0A= 1. The need to establish state before anything gets through from=0A= outside to inside solves one set of problems.=0A= 2. The need to stop receiving any packets when finished with a flow=0A= solves a set of problems=0A= 3. the need to appear to be attached at the edge of the network=0A= solves a set of problems=0A= 4. and the ability to have addresses that are not publicly routed=0A= solves yet another set (mostly changes where the state is and=0A= scale requirements for the first one).=0A= =0A= This document describes several techniques that may be combined in an=0A= IPv6 deployment to protect the integrity of its network architecture.=0A= It will focus on the 'how to accomplish a goal' perspective, leaving=0A= most of the 'why that goal' perspective for other documents. These=0A= techniques, known collectively as Network Architecture Protection=0A= (NAP), retain the concept of a well defined boundary between "inside"=0A= and "outside" the private network, and allow firewalling, topology=0A= hiding, and privacy. NAP will achieve these security goals without=0A= address translation whilst regaining the ability for arbitrary any-=0A= to-any connectivity.=0A= =0A= IPv6 Network Architecture Protection can be summarized in the=0A= following table. It presents the marketed "benefits" of IPv4+NAT=0A= with a cross-reference of how those are delivered in both the IPv4=0A= and IPv6 environments.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 5]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Goal IPv4 IPv6=0A= +------------------+-----------------------+-----------------------+=0A= | Simple Gateway | DHCP - single | DHCP-PD - arbitrary |=0A= | as default router| address upstream | length customer |=0A= | and address pool | DHCP - limited | prefix upstream |=0A= | manager | number of individual | SLAAC via RA |=0A= | | devices downstream | downstream |=0A= | | see section 2.1 | see section 4.1 |=0A= +------------------|-----------------------|-----------------------+=0A= | Simple Security | Filtering side | Explicit Context |=0A= | | effect due to lack | Based Access Control |=0A= | | of translation state | (Reflexive ACL) |=0A= | | see section 2.2 | see section 4.2 |=0A= +------------------|-----------------------|-----------------------+=0A= | Local usage | NAT state table | Address uniqueness |=0A= | tracking | | |=0A= | | see section 2.3 | see section 4.3 |=0A= +------------------|-----------------------|-----------------------+=0A= | End-system | NAT transforms | Temporary use |=0A= | privacy | device ID bits in | privacy addresses |=0A= | | the address | |=0A= | | see section 2.4 | see section 4.4 |=0A= +------------------|-----------------------|-----------------------+=0A= | Topology hiding | NAT transforms | Untraceable addresses|=0A= | | subnet bits in the | using IGP host routes|=0A= | | address | /or MIPv6 tunnels |=0A= | | see section 2.4 | see section 4.4 |=0A= +------------------|-----------------------|-----------------------+=0A= | Addressing | RFC 1918 | RFC 3177 & 4193 |=0A= | Autonomy | see section 2.5 | see section 4.5 |=0A= +------------------|-----------------------|-----------------------+=0A= | Global Address | RFC 1918 | 17*10^18 subnets |=0A= | Pool | << 2^48 application | 3.4*10^38 addresses |=0A= | Conservation | end points | full port list / addr |=0A= | | topology restricted | unrestricted topology |=0A= | | see section 2.6 | see section 4.6 |=0A= +------------------|-----------------------|-----------------------+=0A= | Renumbering and | Address translation | Preferred lifetime |=0A= | Multi-homing | at border | per prefix & Multiple|=0A= | | | addresses per |=0A= | | | interface |=0A= | | see section 2.7 | see section 4.7 |=0A= +------------------+-----------------------+-----------------------+=0A= =0A= =0A= This document first identifies the perceived benefits of NAT in more=0A= detail, and then shows how IPv6 NAP can provide each of them. It=0A= concludes with a IPv6 NAP case study and a gap analysis of work that=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 6]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= remains to be done for a complete NAP solution.=0A= =0A= =0A= 2. Perceived Benefits of NAT and its Impact on IPv4=0A= =0A= This section provides insight into the generally perceived benefits=0A= of the use of IPv4 NAT. The goal of this description is not to=0A= analyze these benefits or the accuracy of the perception (detailed=0A= discussions in [4]), but to describe the deployment requirements and=0A= set a context for the later descriptions of the IPv6 approaches for=0A= dealing with those requirements.=0A= =0A= 2.1. Simple Gateway between Internet and Private Network=0A= =0A= A NAT device can connect a private network with addresses allocated=0A= from any part of the space (ambiguous [RFC 1918] or global registered=0A= & unregistered address) towards the Internet, though extra effort is=0A= needed when the same range exists on both sides of the NAT. The=0A= address space of the private network can be built from globally=0A= unique addresses, from ambiguous address space or from both=0A= simultaneously. In the simple case of private use addresses, without=0A= needing specific configuration the NAT device enables access between=0A= the client side of a distributed client-server application in the=0A= private network and the server side located in the public Internet.=0A= =0A= Wide-scale deployments have shown that using NAT to act as a simple=0A= gateway attaching a private IPv4 network to the Internet is simple=0A= and practical for the non-technical end user. Frequently a simple=0A= user interface, or even a default configuration is sufficient for=0A= configuring both device and application access rights.=0A= =0A= This simplicity comes at a price as the resulting topology puts=0A= restrictions on applications. The NAT simplicity works well when the=0A= applications are limited to a client/server model with the server=0A= deployed on the public side of the NAT. For peer-to-peer, multi-=0A= party, or servers deployed on the private side of the NAT, helper=0A= technologies must be available. These helper technologies are=0A= frequently complex to develop and manage, creating a hidden cost to=0A= this 'simple gateway'.=0A= =0A= 2.2. Simple Security due to Stateful Filter Implementation=0A= =0A= It is frequently believed that through its session-oriented=0A= operation, NAT puts in an extra barrier to keep the private network=0A= protected from outside influences. Since a NAT device typically=0A= keeps state only for individual sessions, attackers, worms, etc.=0A= cannot exploit this state to attack a specific host on any other=0A= port, though in the port overload case of NAPT attacking all active=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 7]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= ports will impact a potentially wide number of hosts. This benefit=0A= may be partially real, however, experienced hackers are well aware of=0A= NAT devices and are very familiar with private address space, and=0A= have devised methods of attack (such as trojan horses) that readily=0A= penetrate NAT boundaries. For these reasons the sense of security=0A= provided by NAT is actually an illusion.=0A= =0A= The act of address translation does not provide security in itself;=0A= for example, consider a configuration with static NAT translation and=0A= all inbound ports translating to a single machine. In such a=0A= scenario the security risk for that machine is identical to the case=0A= with no NAT device in the communication path. As result there is no=0A= specific security value in the address translation function. The=0A= perceived security of NAT comes from the lack of pre- established or=0A= permanent mapping state. Dynamically establishing state in response=0A= to internal requests reduces the threat of unexpected external=0A= connections to internal devices. This role, often marketed as a=0A= firewall, is really an arbitrary artifact while a real firewall has=0A= explicit management controls.=0A= =0A= In some cases, NAT operators (including domestic users) may be=0A= obliged to configure quite complex port mapping rules to allow=0A= external access to local applications such as a multi-player game or=0A= web servers. In this case the NAT actually adds management=0A= complexity compared to a simple router. In situations where two or=0A= more devices need to host the same application or otherwise use the=0A= same public port this complexity shifts from difficult to impossible.=0A= =0A= 2.3. User/Application tracking=0A= =0A= One usage of NAT is for the local network administrator to track user=0A= and application traffic. Although NATs create temporary state for=0A= active sessions, in general they provide limited capabilities for the=0A= administrator of the NAT to gather information about who in the=0A= private network is requesting access to which Internet location.=0A= This is done by periodically logging the network address translation=0A= details of the private and the public addresses from the NAT device's=0A= state database.=0A= =0A= The subsequent checking of this database is not always a simple task,=0A= especially if Port Address Translation is used. It also has an=0A= unstated assumption that the administrative instance has a mapping=0A= between a private IPv4-address and a network element or user at all=0A= times, or the administrator has a time-correlated list of the=0A= address/port mappings.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 8]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 2.4. Privacy and Topology Hiding=0A= =0A= One goal of 'topology hiding' is to prevent external entities from=0A= making a correlation between the topological location of devices on=0A= the local network. The ability of NAT to provide Internet access to=0A= a large community of users by the use of a single (or a few) global=0A= IPv4 routable addresses offers a simple mechanism to hide the=0A= internal topology of a network. In this scenario the large community=0A= will be represented in the Internet by a single (or a few) IPv4=0A= address(es).=0A= =0A= The use of NAT then results in a user behind a NAT gateway actually=0A= appearing from the Internet as a user inside the NAT box itself;=0A= i.e., the IPv4 address that appears on the Internet is only=0A= sufficient to identify the NAT so all internal nodes appear to exist=0A= at the demarcation edge. When concealed behind a NAT it is=0A= impossible to tell from the outside which member of a family, which=0A= customer of an Internet cafe, or which employee of a company=0A= generated or received a particular packet. Thus, although NATs do=0A= nothing to provide application level privacy, they do prevent the=0A= external tracking and profiling of individual systems by means of=0A= their IP addresses, usually known as 'device profiling'.=0A= =0A= At the same time a NAT creates a smaller pool of addresses for a much=0A= more focused point of attack, where the adversary does not need to=0A= scan the entire local network but can instead concentrate on the=0A= active ports associated with the NAT adress. By periodically=0A= scanning the limited 16 bit port range on the public side of the NAT,=0A= the attack will routinely find all ports that are open to active=0A= nodes.=0A= =0A= There is a similarity with privacy based on application level=0A= proxies. When using an application level gateway for browsing the=0A= web for example, the 'privacy' of a web user can be provided by=0A= masking the true identity of the original web user towards the=0A= outside world (although the details of what is - or is not - logged=0A= at the NAT/proxy will be different).=0A= =0A= Some network managers prefer to hide as much as possible of their=0A= internal network topology from outsiders as a useful precaution to=0A= mitigate scanning attacks. Mostly this is achieved by blocking=0A= "traceroute" etc., though NAT entirely hides the internal subnet=0A= topology. Scanning is a particular concern in IPv4 networks because=0A= the subnet size is small enough that once the topology is known it is=0A= easy to find all the hosts, then start scanning them for vulnerable=0A= ports. Once a list of available devices has been mapped, a port-scan=0A= on these IP addresses can be performed. Scanning works by tracking=0A= which ports do not receive unreachable errors from either the=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 9]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= firewall or host. With the list of open ports an attacker can=0A= optimize the time needed for a successful attack by correlating it=0A= with known vulnerabilities to reduce the number of attempts. For=0A= example, FTP usually runs on port 21, and HTTP usually runs on port=0A= 80. Any vulnerable open ports could be used for access to an end=0A= system to command it to start initiating attacks on others.=0A= =0A= 2.5. Independent Control of Addressing in a Private Network=0A= =0A= Many private IPv4 networks take benefit from using the address space=0A= defined in RFC 1918 to enlarge the available addressing space for=0A= their private network, and at the same time reduce their need for=0A= globally routable addresses. This type of local control of address=0A= resources allows a sufficiently large pool for a clean and=0A= hierarchical addressing structure in the local network.=0A= =0A= Another benefit is due to the usage of independent addresses on=0A= majority of the network infrastructure there is an increased ability=0A= to change provider with less operational difficulties.=0A= =0A= Section 2.7 describes some disadvantages that appear if independent=0A= networks using [RFC1918] addresses have to be merged.=0A= =0A= 2.6. Global Address Pool Conservation=0A= =0A= While the widespread use of IPv4+NAT has reduced the potential=0A= consumption rate, the ongoing depletion of the IPv4 address range has=0A= already taken the remaining pool of unallocated IPv4 addresses below=0A= 25%. While mathematical models based on historical IPv4 prefix=0A= consumption periodically attempt to predict the future exhaustion=0A= date of the IPv4 address pool, a direct result of this continuous=0A= resource consumption is that the administrative overhead for=0A= acquiring globally unique IPv4 addresses will continue increasing in=0A= direct response to tightening allocation policies.=0A= =0A= In response to the increasing administrative overhead many Internet=0A= Service Providers (ISPs) have already resorted to the ambiguous=0A= addresses defined in RFC 1918 behind a NAT for the various services=0A= they provide as well as connections for their end customers. This=0A= happens even though the private use address-space is strictly limited=0A= in size. Some deployments have already outgrown that space and have=0A= begun cascading NAT to continue expanding, though this practice=0A= eventually breaks down over routing ambiguity. Additionally, while=0A= we are unlikely to know the full extent of the practice (because it=0A= is hidden behind a nat), service providers have been known to=0A= announce previously unallocated public space to their customers (to=0A= avoid the problems associated with the same address space appearing=0A= on both sides), only to find that once that space was formally=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 10]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= allocated and being publicly announced their customers couldn't reach=0A= the registered networks.=0A= =0A= The number of and types of applications that can be deployed by these=0A= ISPs and their customers is restricted by the ability to overload the=0A= port range on the public side of the most public NAT in the path.=0A= The limit of this approach is something substantially less than 2^48=0A= possible active **application** endpoints (approximately [2^32 minus=0A= 2^29] * [2* 2^16 minus well known port space]), as distinct from=0A= addressable devices each with their own application endpoint range.=0A= Those who advocate layering of NAT frequently forget to mention that=0A= there are topology restrictions placed on the applications. Forced=0A= into this limiting situation such customers can rightly claim that=0A= despite the optimistic predictions of mathematical models, the global=0A= pool of IPv4 addresses is effectively already exhausted.=0A= =0A= 2.7. Multihoming and Renumbering with NAT=0A= =0A= Allowing a network to be multihomed and renumbering a network are=0A= quite different functions. However these are argued together as=0A= reasons for using NAT, because making a network multihomed is often a=0A= transitional state required as part of network renumbering, and NAT=0A= interacts with both in the same way.=0A= =0A= For enterprise networks, it is highly desirable to provide resiliency=0A= and load-balancing to be connected to more than one Internet Service=0A= Provider (ISP) and to be able to change ISPs at will. This means=0A= that a site must be able to operate under more than one CIDR prefix=0A= [15] and/or readily change its CIDR prefix. Unfortunately, IPv4 was=0A= not designed to facilitate either of these maneuvers. However, if a=0A= site is connected to its ISPs via NAT boxes, only those boxes need to=0A= deal with multihoming and renumbering issues.=0A= =0A= Similarly, if two enterprise IPv4 networks need to be merged and=0A= RFC1918 addresses are used, there is a high probability of address=0A= overlaps. In those situations it may well be that installing a NAT=0A= box between them will avoid the need to renumber one or both. For=0A= any enterprise, this can be a short term financial saving, and allow=0A= more time to renumber the network components. The long term solution=0A= is a single network without usage of NAT to avoid the ongoing=0A= operational complexity of overlapping addresses.=0A= =0A= The addition of an extra NAT as a solution may be sufficient for some=0A= networks; however when the merging networks were already using=0A= address translation it will create huge problems due to=0A= administrative difficulties of overlapping address spaces in the=0A= merged networks.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 11]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 3. Description of the IPv6 Tools=0A= =0A= This section describes several features that can be used as part of=0A= the NAP solution to replace the protection features associated with=0A= IPv4 NAT.=0A= =0A= The reader must clearly distinguish between features of IPv6 that=0A= were fully defined when this document was drafted and those that were=0A= potential features that still required more work to define them. The=0A= latter are summarized later in the 'Gap Analysis' section of this=0A= document. However, we do not distinguish in this document between=0A= fully defined features of IPv6 and those that were already widely=0A= implemented at the time of writing.=0A= =0A= 3.1. Privacy Addresses (RFC 3041)=0A= =0A= There are situations where it is desirable to prevent device=0A= profiling, for example by web sites that are accessed from the device=0A= as it moves around the Internet. IPv6 privacy addresses were defined=0A= to provide that capability. IPv6 addresses consist of a routing=0A= prefix, subnet-id part (SID) and an interface identifier part (IID).=0A= As originally defined, IPv6 stateless address auto-configuration=0A= (SLAAC) will typically embed the IEEE Link Identifier of the=0A= interface as the IID part, though this practice facilitates tracking=0A= and profiling of a device through the consistent IID. RFC 3041 [7]=0A= describes an extension to SLAAC to enhance device privacy. Use of=0A= the privacy address extension causes nodes to generate global-scope=0A= addresses from interface identifiers that change over time,=0A= consistent with system administrator policy. Changing the interface=0A= identifier (thus the global-scope addresses generated from it) over=0A= time makes it more difficult for eavesdroppers and other information=0A= collectors to identify when addresses used in different transactions=0A= actually correspond to the same node. A relatively short valid=0A= lifetime for the privacy address also has the side effect of reducing=0A= the attack profile of a device, as it is not directly attackable once=0A= it stops answering at the temporary use address.=0A= =0A= While the primary implementation and source of randomized RFC 3041=0A= addresses is expected to be from end-systems running stateless auto-=0A= configuration, there is nothing that prevents a DHCP server from=0A= running the RFC 3041 algorithm for any new IEEE identifier it hears=0A= in a request, then remembering that for future queries. This would=0A= allow using them in DNS for registered services since the assumption=0A= of a DHCP server based deployment would be a persistent value that=0A= minimizes DNS churn. A DHCP based deployment would also allow for=0A= local policy to periodically change the entire collection of end=0A= device addresses while maintaining some degree of central knowledge=0A= and control over which addresses should be in use at any point in=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 12]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= time.=0A= =0A= Randomizing the IID, as defined in RFC 3041, is effectively a sparse=0A= allocation technique which only precludes tracking of the lower 64=0A= bits of the IPv6 address. Masking of the subnet ID will require=0A= additional approaches as discussed below in 3.4. Additional=0A= considerations are discussed in [18].=0A= =0A= 3.2. Unique Local Addresses=0A= =0A= Achieving the goal of autonomy, that many perceive as a value of NAT,=0A= is required for local network and application services stability=0A= during periods of intermittent connectivity or moving between one or=0A= more providers. Such autonomy in a single routing prefix environment=0A= would lead to massive expansion of the global routing tables (as seen=0A= in IPv4), so IPv6 provides for simultaneous use of multiple prefixes.=0A= The Unique Local Address prefix (ULA) [14] has been set aside for use=0A= in local communications. The ULA address prefix for any network is=0A= routable over a locally defined collection of routers. These=0A= prefixes are not intended to be routed on the public global Internet=0A= as large scale inter-domain distribution of routes for ULA prefixes=0A= would have a negative impact on global route aggregation.=0A= =0A= ULAs have the following characteristics:=0A= o For all practical purposes a globally unique prefix=0A= * Allows networks to be combined or privately interconnected=0A= without creating address conflicts or requiring renumbering of=0A= interfaces using these prefixes=0A= * If accidentally leaked outside of a network via routing or DNS,=0A= it is highly unlikely that there will be a conflict with any=0A= other addresses=0A= o ISP independent and can be used for communications inside of a=0A= network without having any permanent or only intermittent Internet=0A= connectivity=0A= o Well-known prefix to allow for easy filtering at network=0A= boundaries preventing leakage of local routes and packets.=0A= o In practice, applications may treat these addresses like global=0A= scoped addresses but address selection algorithms may need to=0A= distinguish between ULAs and ordinary global scope unicast=0A= addresses to assure stability. The policy table defined in [10]=0A= is one way to bias this selection, by giving higher preference to=0A= FC00::/7 over 2001::/3. Mixing the two kinds of addresses may=0A= lead to undeliverable packets during times of instability, but=0A= that mixing is not likely to happen when the rules of RFC 3484 are=0A= followed.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 13]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 3.3. DHCPv6 Prefix Delegation=0A= =0A= One of the functions of a simple gateway is managing the local use=0A= address range. The Prefix Delegation (DHCP-PD) options [11] provide=0A= a mechanism for automated delegation of IPv6 prefixes using the=0A= Dynamic Host Configuration Protocol (DHCP) [9]. This mechanism=0A= (DHCP-PD) is intended for delegating a long-lived prefix from a=0A= delegating router (possibly incorporating a DHCPv6 server) to a=0A= requesting router, possibly across an administrative boundary, where=0A= the delegating router does not require knowledge about the topology=0A= of the links in the network to which the prefixes will be assigned.=0A= =0A= 3.4. Untraceable IPv6 Addresses=0A= =0A= The main goal of untraceable IPv6 addresses is to create an=0A= apparently amorphous network infrastructure as seen from external=0A= networks to protect the local infrastructure from malicious outside=0A= influences and from mapping of any correlation between the network=0A= activities of multiple devices from external networks. When using=0A= untraceable IPv6 addresses, it could be that two apparently=0A= sequential addresses are allocated to devices on very different parts=0A= of the local network instead of belonging to devices adjacent to each=0A= other on the same subnet.=0A= =0A= These should be globally routable IPv6 addresses which can be=0A= randomly and independently assigned to IPv6 devices. The random=0A= assignment is intended to mislead the outside world about the=0A= structure of the local network. However the local network needs to=0A= maintain a correlation between the location of the device and the=0A= untraceable IPv6 address. For smaller deployments this correlation=0A= could be done by generating IPv6 host route entries, or for larger=0A= ones by utilizing an indirection device such as a Mobile IPv6 Home=0A= Agent. Additional details are in section 4.7.=0A= =0A= =0A= 4. Using IPv6 Technology to Provide the Market Perceived Benefits of=0A= NAT=0A= =0A= The facilities in IPv6 described in Section 3 can be used to provide=0A= the protection perceived to be associated with IPv4 NAT. This=0A= section gives some examples of how IPv6 can be used securely.=0A= =0A= 4.1. Simple Gateway between Internet and Internal Network=0A= =0A= As a simple gateway, the device manages both packet routing and local=0A= address management. A basic IPv6 router should have a default=0A= configuration to advertise inside the site a locally generated random=0A= ULA prefix, independently from the state of any external=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 14]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= connectivity. This would allow local nodes to communicate amongst=0A= themselves independent of the state of a global connection. If the=0A= network happened to concatenate with another local network, the=0A= randomness in ULA creation is highly unlikely to result in address=0A= collisions.=0A= =0A= With external connectivity the simple gateway should use DHCP-PD to=0A= acquire a routing prefix from the service provider for use when=0A= connecting to the global Internet. End-system connections involving=0A= other nodes on the global Internet will always use the global IPv6=0A= addresses derived from this prefix delegation. It should be noted=0A= that the address selection policy table in end-systems defined in RFC=0A= 3484 should be configured to prefer the ULA prefix range over the=0A= DHCP-PD prefix range when the goal is to keep local communications=0A= stable during periods of transient external connectivity.=0A= =0A= In the very simple case there is no explicit routing protocol on=0A= either side of the gateway, and a single default route is used=0A= internally pointing out to the global Internet. A slightly more=0A= complex case might involve local internal routing protocols, but with=0A= the entire local network sharing a common global prefix there would=0A= still not be a need for an external routing protocol as the service=0A= provider could install a route for the prefix delegated via DHCP-PD=0A= pointing toward the connecting link.=0A= =0A= 4.2. IPv6 and Simple Security=0A= =0A= The vulnerability of an IPv6 host is similar to that of an IPv4 host=0A= directly connected towards the Internet. The use of firewall and=0A= Intrusion Detection Systems (IDS) is recommended for those that want=0A= boundary protection in addition to host defenses. A proxy may be=0A= used for certain applications, but with the caveat that the end to=0A= end transparency is broken. However, with IPv6, the following=0A= protections are available without the use of NAT while maintaining=0A= end-to-end reachability:=0A= 1. Short lifetimes on privacy extension suffixes reduce the attack=0A= profile since the node will not respond to the address once its=0A= lifetime becomes invalid.=0A= 2. IPsec is a mandatory service for IPv6 implementations. IPsec=0A= functions to authenticate the correspondent, prevent session=0A= hijacking, prevent content tampering, and optionally masks the=0A= packet contents. While IPsec might be available in IPv4=0A= implementations and works the same way, deployment in NAT=0A= environments either breaks the protocol or requires complex=0A= helper services with limited functionality or efficiency.=0A= 3. The size of the address space of a typical subnet (64 bits of=0A= IID) will make a complete subnet ping sweep virtually impossible=0A= due to the potential number of combinations available. Reducing=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 15]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= the security threat of port scans on identified nodes requires=0A= sparse distribution within the subnet to minimize the probability=0A= of scans finding adjacent nodes. Provided that IIDs are=0A= essentially randomly distributed across the available space,=0A= address scanning based attacks will effectively fail. This=0A= protection exists if the attacker has no direct access to the=0A= specific subnet and therefore is trying to scan it remotely. If=0A= an attacker has local access then he could use ND [3] and ping6=0A= to the link-scope multicast ff02::1 to detect the IEEE based=0A= address of local neighbors, then apply the global prefix to those=0A= to simplify its search (of course, a locally connected attacker=0A= has many scanning options with IPv4 as well). This scanning=0A= protection will be nullified if IIDs are configured in any=0A= structured groupings within the IID space.=0A= =0A= Assuming the network administrator is aware of [19] the increased=0A= size of the IPv6 address will make topology probing much harder, and=0A= almost impossible for IPv6 devices. The intention of topology=0A= probing is to identify a selection of the available hosts inside an=0A= enterprise. This mostly starts with a ping-sweep. Since the IPv6=0A= subnets are 64 bits worth of address space, this means that an=0A= attacker has to send out a simply unrealistic number of pings to map=0A= the network, and virus/worm propagation will be thwarted in the=0A= process. At full-rate full-duplex 40Gbps (400 times the typical=0A= 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it=0A= takes over 5000 years to scan the entirety of a single 64 bit subnet.=0A= =0A= IPv4 NAT was not developed as a security mechanism. Despite=0A= marketing messages to the contrary it is not a security mechanism,=0A= and hence it will offer some security holes while many people assume=0A= their network is secure due to the usage of NAT. IPv6 security best=0A= practices will avoid this kind of illusory security but can only=0A= address the same threats if correctly configured firewalls and IDS=0A= systems are used at the perimeter.=0A= =0A= =0A= It must be noted that even a firewall doesn't fully secure=0A= a network. Many attacks come from inside or are at a layer=0A= higher than the firewall can protect against. In the final=0A= analysis, every system has to be responsible for its own=0A= security, and every process running on a system has to be=0A= robust in the face of challenges like stack overflows etc.=0A= What a firewall does is prevent a network administration=0A= from having to pay for bandwidth to carry unauthorized=0A= traffic, and in so doing reduce the probability of certain=0A= kinds of attacks across the protected boundary.=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 16]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= To implement simple security for IPv6 in, for example, a DSL=0A= connected home network, the DSL broadband gateway/router should be=0A= equipped with stateful firewall capabilities. These should provide a=0A= default configuration where incoming traffic is limited to return=0A= traffic resulting from outgoing packets (sometimes known as=0A= reflective session state). There should also be an easy interface=0A= which allows users to create inbound 'pinholes' for specific purposes=0A= such as online-gaming. Another consideration would be the capability=0A= for service provider mediated pinhole management where things like=0A= voice call signaling could dynamically establish pinholes based on=0A= predefined authentication rules.=0A= =0A= Administrators and the designers of configuration interfaces for=0A= simple IPv6 firewalls need to provide a means of documenting the=0A= security caveats that arise from a given set configuration rules so=0A= that users (who are normally oblivious to such things) can be made=0A= aware of the risks. As rules are improved iteratively, the goal will=0A= be to make use of the IPv6 Internet more secure without increasing=0A= the perceived complexity for users who just want to accomplish a=0A= task.=0A= =0A= 4.3. User/Application Tracking=0A= =0A= IPv6 enables the collection of information about data flows. Due to=0A= the fact that all addresses used for Internet and intra-/inter- site=0A= communication are unique, it is possible for an enterprise or ISP to=0A= get very detailed information on any communication exchange between=0A= two or more devices. This enhances the capability of data- flow=0A= tracking for security audits compared with IPv4 NAT, because in IPv6=0A= a flow between a sender and receiver will always be uniquely=0A= identified due to the unique IPv6 source and destination addresses.=0A= =0A= At the same time, this tracking is per address. In environments=0A= where the goal is tracking back to the user, additional external=0A= information will be necessary correlating a user with an address. In=0A= the case of short lifetime privacy address usage, this external=0A= information will need to be based on more stable information such as=0A= the layer 2 media address.=0A= =0A= 4.4. Privacy and Topology Hiding using IPv6=0A= =0A= Partial host privacy is achieved in IPv6 using pseudo-random privacy=0A= addresses [RFC 3041] which are generated as required, so that a=0A= session can use an address that is valid only for a limited time.=0A= This only allows such a session to be traced back to the subnet that=0A= originates it, but not immediately to the actual host, where IPv4 NAT=0A= is only traceable to the most public NAT interface.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 17]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Due to the large IPv6 address space available there is plenty of=0A= freedom to randomize subnet allocations. By doing this, it is=0A= possible to reduce the correlation between a subnet and its location.=0A= When doing both subnet and IID randomization [RFC 3041] a casual=0A= snooper won't be able to deduce much about the networks topology.=0A= The obtaining of a single address will tell the snooper very little=0A= about other addresses. This is different from IPv4 where address=0A= space limitations cause this to be not true. In most usage cases=0A= this concept should be sufficient for address privacy and topology=0A= hiding, with the cost being a more complex internal routing=0A= configuration.=0A= =0A= As discussed in Section 3.1, there are multiple parts to the IPv6=0A= address, and different techniques to manage privacy for each which=0A= may be combined to protect the entire address. In the case where a=0A= network administrator wishes to fully isolate the internal IPv6=0A= topology, and the majority of its internal use addresses, one option=0A= is to run all internal traffic using Unique Local Addresses (ULA).=0A= By definition this prefix block is not to be advertised into the=0A= public routing system, so without a routing path external traffic=0A= will never reach the site. For the set of hosts that do in fact need=0A= to interact externally, by using multiple IPv6 prefixes (ULAs and one=0A= or more global addresses) all of the internal nodes that do not need=0A= external connectivity, and the internally used addresses of those=0A= that do will be masked from the outside. The policy table defined in=0A= [10] provides a mechanism to bias the selection process when multiple=0A= prefixes are in use such that the ULA would be preferred when the=0A= correspondent is also local.=0A= =0A= There are other scenarios for the extreme situation when a network=0A= manager also wishes to fully conceal the internal IPv6 topology. In=0A= these cases the goal in replacing the IPv4 NAT approach is to make=0A= all of the topology hidden nodes appear from the outside to logically=0A= exist at the edge of the network, just as they would when behind a=0A= NAT.=0A= =0A= o One approach uses explicit host routes in the IGP to remove the=0A= external correlation between physical topology attachment point=0A= and end-to-end IPv6 address. In the figure below the hosts would=0A= be allocated prefixes from one or more logical subnets, and would=0A= inject host routes to internally identify their real attachment=0A= point. This solution does however show severe scalability issues=0A= and requires hosts to participate in the IGP, as well as having=0A= the firewall block all external to internal traceroute for the=0A= logical subnet. The specific limitations are dependent on the IGP=0A= protocol, the physical topology, and the stability of the system.=0A= In any case the approach should be limited to uses with=0A= substantially fewer than the maximum number of routes that the IGP=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 18]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= can support (generally between 5,000 and 50,000 total entries=0A= including subnet routes).=0A= o Another technical approach to fully hide the internal topology is=0A= use of a tunneling mechanism. Mobile IPv6 without route=0A= optimization is one approach for using an automated tunnel, as it=0A= always starts in tunnel mode via the Home Agent (HA). In this=0A= deployment model the application perceived addresses of the nodes=0A= are routed via the edge HA. This indirection method truly masks=0A= the internal topology, as from outside the local network all nodes=0A= with global access appear to share the prefix of one or more=0A= logical subnets attached to the HA rather than their real=0A= attachment point. While turning off all binding updates would=0A= appear to be necessary to prevent leakage of topology information,=0A= that approach would also force all internal traffic using the home=0A= address to route via the HA tunnel, which may be undesirable. A=0A= more efficient method would be to allow internal route=0A= optimizations while dropping outbound binding updates at the=0A= firewall. Another approach for the internal routes would be to=0A= use the policy table of RFC 3484 to bias a ULA prefix as preferred=0A= internally, leaving the Home Address external for use. The=0A= downsides of using the MIPv6 tunneling method is that it makes=0A= usage of middleware like a Home Agent (HA) and consumes slightly=0A= more bandwidth for the tunnel overhead.=0A= o Another method (where the layer 2 topology allows) uses a virtual=0A= lan approach to logically attach the devices to one or more=0A= subnets on the edge router. The downsides of this approach is=0A= that all internal traffic would be directed over sub-optimal paths=0A= via the edge router, as well as the complexity of managing a=0A= distributed logical lan.=0A= =0A= =0A= =0A= Internet=0A= |=0A= \=0A= |=0A= +------------------+=0A= | Simple Gateway |-+-+-+-+-+-+-+-+--=0A= | or Home Agent | Logical subnets=0A= | |-+-+-+-+-+-+-+-+--=0A= +------------------+ for topology=0A= | hidden nodes=0A= |=0A= Real internal -------------+-=0A= topology | |=0A= | -+----------=0A= -----------+--------+=0A= |=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 19]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= |=0A= |=0A= =0A= =0A= =0A= =0A= =0A= 4.5. Independent Control of Addressing in a Private Network=0A= =0A= IPv6 provides for autonomy in local use addresses through ULAs. At=0A= the same time IPv6 simplifies simultaneous use of multiple addresses=0A= per interface so that an IPv6 NAT is not required between the ULA and=0A= the public Internet because nodes that need access to the public=0A= Internet will have a global use address as well. When using IPv6,=0A= the need to ask for more address space will become far less likely=0A= due to the increased size of the subnets, along with an allocation=0A= policy that recognizes table fragmentation is also an important=0A= consideration. While global IPv6 allocation policy is managed=0A= through the Regional Internet Registries, it is expected that they=0A= will continue with derivatives of [8] for the foreseeable future so=0A= the number of subnet prefixes available to an organization should not=0A= be a limitation which would create an artificial demand for NAT.=0A= =0A= Ongoing subnet address maintenance may become simpler when IPv6=0A= technology is utilized. Under IPv4 address space policy restrictions=0A= each subnet must be optimized, so one has to look periodically into=0A= the number of hosts on a segment and the subnet size allocated to the=0A= segment and rebalance. For example an enterprise today may have a=0A= mix of IPv4 /28 - /23 size subnets, and may shrink/grow these as=0A= their network user base changes. For IPv6 all subnets have /64=0A= prefixes which will reduce the operational and configuration=0A= overhead.=0A= =0A= 4.6. Global Address Pool Conservation=0A= =0A= IPv6 provides sufficient space to completely avoid the need for=0A= overlapping address space. Since allocations in IPv6 are based on=0A= subnets rather than hosts a reasonable way to look at the pool is=0A= that there are about 17*10^18 unique subnet values where sparse=0A= allocation practice within those provides for new opportunities such=0A= as SEND 3971 [12]. As previously discussed, the serious=0A= disadvantages of ambiguous address space have been well documented,=0A= and with sufficient space there is no need to continue the=0A= increasingly aggressive conservation practices that are necessary=0A= with IPv4. While IPv6 allocation policies and ISP business practice=0A= will continue to evolve, the recommendations in RFC 3177 are based on=0A= the technical potential of the vast IPv6 address space. That=0A= document demonstrates that there is no resource limitation which will=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 20]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= require the adoption of the IPv4 workaround of ambiguous space behind=0A= a NAT. As an example of the direct contrast, many expansion oriented=0A= IPv6 deployment scenarios result in multiple IPv6 addresses per=0A= device, as opposed to the constriction of IPv4 scenarios where=0A= multiple devices are forced to share a scarce global address through=0A= a NAT.=0A= =0A= 4.7. Multihoming and Renumbering=0A= =0A= Multihoming and renumbering remain technically challenging with IPv6=0A= (see the Gap Analysis below). However, IPv6 was designed to allow=0A= sites and hosts to run with several simultaneous CIDR allocated=0A= prefixes, and thus with several simultaneous ISPs. An address=0A= selection mechanism [10] is specified so that hosts will behave=0A= consistently when several addresses are simultaneously valid. The=0A= fundamental difficulty that IPv4 has in regard to multiple addresses=0A= therefore does not apply to IPv6. IPv6 sites can and do run today=0A= with multiple ISPs active, and the processes for adding, removing,=0A= and renumbering active prefixes at a site have been documented in=0A= [13] and [20].=0A= =0A= The IPv6 address space allocated by the ISP will be dependent upon=0A= the connecting Service provider. This will likely result in a=0A= renumbering effort when the network changes between service=0A= providers. When changing ISPs or ISPs readjusting their addressing=0A= pool, DHCP-PD [11] can be used as an almost zero- touch external=0A= mechanism for prefix change in conjunction with a ULA prefix for=0A= internal connection stability. With appropriate management of the=0A= lifetime values and overlap of the external prefixes, a smooth make-=0A= before-break transition is possible as existing communications will=0A= continue on the old prefix as long as it remains valid, while any new=0A= communications will use the new prefix.=0A= =0A= =0A= 5. Case Studies=0A= =0A= In presenting these case studies we have chosen to consider=0A= categories of network divided first according to their function=0A= either as carrier/ISP networks or end user (such as enterprise)=0A= networks with the latter category broken down according to the number=0A= of connected end hosts. For each category of networks we can use=0A= IPv6 Network Architecture Protection to achieve a secure and flexible=0A= infrastructure, which provides an enhanced network functionality in=0A= comparison with the usage of address translation.=0A= =0A= o Medium/Large Private Networks (typically >10 connections)=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 21]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Small Private Networks (typically 1 to 10 connections)=0A= o Single User Connection (typically 1 connection)=0A= o ISP/Carrier Customer Networks=0A= =0A= =0A= 5.1. Medium/large private networks=0A= =0A= The majority of private enterprise, academic, research, or government=0A= networks fall into this category. Many of these networks have one or=0A= more exit points to the Internet. Though these organizations have=0A= sufficient resources to acquire addressing independence when using=0A= IPv4 there are several reasons why they might choose to use NAT in=0A= such a network. For the ISP there is no need to import the IPv4=0A= address range from the remote end-customer, which facilitates IPv4=0A= route summarization. The customer can use a larger IPv4 address=0A= range (probably with less-administrative overhead) by the use of RFC=0A= 1918 and NAT. The customer also reduces the overhead in changing to=0A= a new ISP, because the addresses assigned to devices behind the NAT=0A= do not need to be changed when the customer is assigned a different=0A= address by a new ISP. By using address translation in IPv4 one=0A= avoids the expensive process of network renumbering. Finally, the=0A= customer can provide privacy for its hosts and the topology of its=0A= internal network if the internal addresses are mapped through NAT.=0A= =0A= It is expected that there will be enough IPv6 addresses available for=0A= all networks and appliances for the foreseeable future. The basic=0A= IPv6 address range an ISP allocates for a private network is large=0A= enough (currently /48) for most of the medium and large enterprises,=0A= while for the very large private enterprise networks address-ranges=0A= can be concatenated. The goal of this assignment mechanism is to=0A= decrease the total amount of entries in the public Internet routing=0A= table. A single /48 allocation provides an enterprise network with=0A= 65536 different /64 subnet prefixes.=0A= =0A= To mask the identity of a user on a network of this type, the usage=0A= of IPv6 privacy extensions may be advised. This technique is useful=0A= when an external element wants to track and collect all information=0A= sent and received by a certain host with known IPv6 address. Privacy=0A= extensions add a random time-limited factor to the host part of an=0A= IPv6 address and will make it very hard for an external element to=0A= keep correlating the IPv6 address to a specific host on the inside=0A= network. The usage of IPv6 privacy extensions does not mask the=0A= internal network structure of an enterprise network.=0A= =0A= When there is need to mask the internal structure towards the=0A= external IPv6 Internet, then some form of 'untraceable' addresses may=0A= be used. These addresses will appear to exist at the external edge=0A= of the network, and may be assigned to those hosts for which topology=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 22]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= masking is required or which want to reach the IPv6 Internet or other=0A= external networks. The technology to assign these addresses to the=0A= hosts could be based on DHCPv6 or static configuration. To=0A= complement the 'Untraceable' addresses it is needed to have at least=0A= awareness of the IPv6 address location when routing an IPv6 packet=0A= through the internal network. This could be achieved by 'host based=0A= route- injection' in the local network infrastructure. This route-=0A= injection could be done based on /128 host-routes to each device that=0A= wants to connect to the Internet using an untraceable address. This=0A= will provide the most dynamic masking, but will have a scalability=0A= limitation, as an IGP is typically not designed to carry many=0A= thousands of IPv6 prefixes. A large enterprise may have thousands of=0A= hosts willing to connect to the Internet.=0A= =0A= An alternative for larger deployments is to leverage the tunneling=0A= aspect of MIPv6 even for non-mobile devices. With the logical subnet=0A= being allocated as attached to the edge Home Agent, the real=0A= attachment and internal topology are masked from the outside.=0A= Dropping outbound binding updates at the firewall is also necessary=0A= to avoid leaking the attachment information.=0A= =0A= Less flexible masking could be to have time-based IPv6 prefixes per=0A= link or subnet. This may reduce the amount of route entries in the=0A= IGP by a significant factor, but has as trade-off that masking is=0A= time and subnet based which will complicate auditing systems. The=0A= dynamic allocation of 'Untraceable' addresses can also limit the IPv6=0A= access between local and external hosts to those local hosts being=0A= authorized for this capability.=0A= =0A= The use of permanent ULA addresses on a site provides the benefit=0A= that even if an enterprise would change its ISP, the renumbering will=0A= only affect those devices that have a wish to connect beyond the=0A= site. Internal servers and services would not change their allocated=0A= IPv6 ULA address, and the service would remain available even during=0A= global address renumbering.=0A= =0A= 5.2. Small Private Networks=0A= =0A= Also known as SOHO (Small Office/Home Office) networks, this category=0A= describes those networks which have few routers in the topology, and=0A= usually have a single network egress point. Typically these networks=0A= are:=0A= =0A= o connected via either a dial-up connection or broadband access=0A= o don't have dedicated Network Operation Center (NOC)=0A= o and through economic pressure are typically forced today to use=0A= NAT=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 23]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= In most cases the received global IPv4 prefix is not fixed over time=0A= and is too long (very often just a /32 just giving a single address)=0A= to provide every node in the private network with a unique globally=0A= usable address. Fixing either of those issues typically adds an=0A= administrative overhead for address management to the user. This=0A= category may even be limited to receiving ambiguous IPv4 addresses=0A= from the service provider based on RFC 1918. An ISP will typically=0A= pass along the higher administration cost attached to larger address=0A= blocks, or IPv4 prefixes that are static over time, due to the larger=0A= public address pool each of those requires.=0A= =0A= As a direct response to explicit charges per public address most of=0A= this category has deployed NAPT (port demultiplexing NAT) to minimize=0A= the number of addresses in use. Unfortunately this also limits the=0A= Internet capability of the equipment to being mainly a receiver of=0A= Internet data (client), and makes it quite hard for the equipment to=0A= become a world wide Internet server (i.e. HTTP, FTP, etc.) due to=0A= the stateful operation of the NAT equipment. Even when there is=0A= sufficient technical knowledge to manage the NAT to enable external=0A= access to a server, only one server can be mapped per protocol/=0A= port-number per address, and then only when the address from the ISP=0A= is publicly routed. When there is an upstream NAT providing private=0A= address space to the ISP side of the private NAT, additional=0A= negotiation with the ISP will be necessary to provide an inbound=0A= mapping, if that is even possible.=0A= =0A= When deploying IPv6 NAP in this environment, there are two approaches=0A= possible with respect to IPv6 addressing.=0A= o DHCPv6 Prefix-Delegation=0A= o ISP provides a static IPv6 address-range=0A= =0A= For the DHCPv6-PD solution, a dynamic address allocation approach is=0A= chosen. By means of the enhanced DHCPv6 protocol it is possible to=0A= have the ISP push down an IPv6 prefix range automatically towards the=0A= small private network and populate all interfaces in that small=0A= private network dynamically. This reduces the burden for=0A= administrative overhead because everything happens automatically.=0A= =0A= For the static configuration the mechanisms used could be the same as=0A= for the medium/large enterprises. Typically the need for masking the=0A= topology will not be of high priority for these users, and the usage=0A= of IPv6 privacy extensions could be sufficient.=0A= =0A= For both alternatives the ISP has the unrestricted capability for=0A= summarization of its RIR allocated IPv6 prefix, while the small=0A= private network administrator has all flexibility in using the=0A= received IPv6 prefix to its advantage because it will be of=0A= sufficient size to allow all the local nodes to have a public address=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 24]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= and full range of ports available whenever necessary.=0A= =0A= While a full prefix is expected to be the primary deployment model=0A= there may be cases where the ISP provides a single IPv6 address for=0A= use on a single piece of equipment (PC, PDA, etc.). This is expected=0A= to be rare though, because in the IPv6 world the assumption is that=0A= there is an unrestricted availability of a large amount of globally=0A= routable and unique address space. If scarcity was the motivation=0A= with IPv4 to provide RFC 1918 addresses, in this environment the ISP=0A= will not be motivated to allocate private addresses towards the=0A= single user connection because there are enough global addresses=0A= available at essentially the same cost. Also it will be likely that=0A= the single device wants to mask its identity to the called party or=0A= its attack profile over a shorter time window than the life of the=0A= ISP attachment, so it will need to enable IPv6 privacy extensions=0A= which in turn leads to the need for a minimum allocation of a /64=0A= prefix rather than a single address.=0A= =0A= 5.3. Single User Connection=0A= =0A= This group identifies the users which are connected via a single IPv4=0A= address and use a single piece of equipment (PC, PDA, etc.). This=0A= user may get an ambiguous IPv4 address (frequently imposed by the=0A= ISP) from the service provider which is based on RFC 1918. If=0A= ambiguous addressing is utilized, the service provider will execute=0A= NAT on the allocated IPv4 address for global Internet connectivity.=0A= This also limits the Internet capability of the equipment to being=0A= mainly a receiver of Internet data, and makes it quite hard for the=0A= equipment to become a world wide Internet server (i.e. HTTP, FTP,=0A= etc.) due to the stateful operation of the NAT equipment.=0A= =0A= When using IPv6 NAP, this group will identify the users which are=0A= connected via a single IPv6 address and use a single piece of=0A= equipment (PC, PDA, etc.).=0A= =0A= In IPv6 world the assumption is that there is unrestricted=0A= availability of a large amount of globally routable and unique IPv6=0A= addresses. The ISP will not be motivated to allocate private=0A= addresses towards the single user connection because he has enough=0A= global addresses available, if scarcity was the motivation with IPv4=0A= to provide RFC 1918 addresses. If the single user wants to mask his=0A= identity, he may choose to enable IPv6 privacy extensions.=0A= =0A= 5.4. ISP/Carrier Customer Networks=0A= =0A= This group refers to the actual service providers that are providing=0A= the IP access and transport services. They tend to have three=0A= separate IP domains that they support:=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 25]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o For the first they fall into the Medium/large private networks=0A= category (above) for their own internal networks, LANs etc.=0A= o The second is the Operations network which addresses their=0A= backbone and access switches, and other hardware, this is separate=0A= for both engineering reasons as well as simplicity in managing the=0A= security of the backbone.=0A= o The third is the IP addresses (single or blocks) that they assign=0A= to customers. These can be registered addresses (usually given to=0A= category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of=0A= RFC 1918 addresses used with IPv4 NAT for single user connections.=0A= Therefore they can actually have two different NAT domains that=0A= are not connected (internal LAN and single user customers).=0A= =0A= When IPv6 NAP is utilized in these three domains then for the first=0A= category it will be possible to use the same solutions as described=0A= in Section 5.1. The second domain of the ISP/carrier is the=0A= Operations network. This environment tends to be a closed=0A= environment, and consequently communication can be done based on ULA=0A= addresses, however, in this environment, stable IPv6 Provider=0A= Independent addresses can be used. This would give a solid and=0A= scalable configuration with respect to a local IPv6 address plan. By=0A= the usage of proper network edge filters, outside access to the=0A= closed environment can be avoided. The third is the IPv6 addresses=0A= that ISP/carrier network assign to customers. These will typically=0A= be assigned with prefix lengths terminating on nibble boundaries to=0A= be consistent with the DNS PTR records. As scarcity of IPv6=0A= addresses is not a concern, it will be possible for the ISP to=0A= provide global routable IPv6 prefixes without a requirement for=0A= address translation. An ISP may for commercial reasons still decide=0A= to restrict the capabilities of the end users by other means like=0A= traffic and/or route filtering etc.=0A= =0A= If the carrier network is a mobile provider, then IPv6 is encouraged=0A= in comparison with the combination of IPv4+NAT for 3GPP attached=0A= devices. When looking in chapter 2.3 of RFC3314 'Recommendations for=0A= IPv6 in 3GPP Standards' [16] it is found that the IPv6 WG recommends=0A= that one or more /64 prefixes should be assigned to each primary PDP=0A= context. This will allow sufficient address space for a 3GPP-=0A= attached node to allocate privacy addresses and/or route to a multi-=0A= link subnet, and will discourage the use of NAT within 3GPP-attached=0A= devices.=0A= =0A= =0A= 6. IPv6 Gap Analysis=0A= =0A= Like IPv4 and any major standards effort, IPv6 standardization work=0A= continues as deployments are ongoing. This section discusses several=0A= topics for which additional standardization, or documentation of best=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 26]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= practice, is required to fully realize the benefits of NAP. None of=0A= these items are show-stoppers for immediate usage of NAP in roles=0A= where there are no current gaps.=0A= =0A= 6.1. Simple Security=0A= =0A= Dynamic pinhole management is an area for further study. Several=0A= partial solutions exist including ICE, UPNP, as well as alternative=0A= proposals for Service Provider based control. The 'simple' aspect of=0A= the security provided by a stateful firewall will require some degree=0A= of automation to mask the technical complexity from the consumer that=0A= only wants a secure environment with working applications.=0A= =0A= 6.2. Subnet Topology Masking=0A= =0A= There really is no functional gap here as a centrally assigned pool=0A= of addresses in combination with host routes in the IGP is an=0A= effective way to mask topology for smaller deployments. If necessary=0A= a best practice document could be developed describing the=0A= interaction between DHCP and various IGPs which would in effect=0A= define Untraceable Addresses.=0A= =0A= As an alternative for larger deployments, there is no gap in the HA=0A= tunneling approach when firewalls are configured to block outbound=0A= binding update messages. A border Home Agent using internal=0A= tunneling to the logical mobile node (potentially rack mounted) can=0A= completely mask all internal topology, while avoiding the strain from=0A= a large number of host routes in the IGP. Some optimization work=0A= could be done in Mobile IP to define a policy message where a mobile=0A= node would learn from the Home Agent that it should not try to inform=0A= its correspondent about route optimization and thereby expose its=0A= real location. This optimization which reduces the load on the=0A= firewall would result in less optimal internal traffic routing as=0A= that would also transit the HA. Trade-off's for this optimization=0A= work should be investigated in the IETF.=0A= =0A= 6.3. Minimal Traceability of Privacy Addresses=0A= =0A= Privacy addresses (RFC 3041) may certainly be used to limit the=0A= traceability of external traffic flows back to specific hosts, but=0A= lacking a topology masking component above they would still reveal=0A= the subnet address bits. For complete privacy a best practice=0A= document describing the combination of privacy addresses with=0A= topology masking may be required. This work remains to be done, and=0A= should be pursued by the IETF.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 27]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= 6.4. Site Multihoming=0A= =0A= This complex problem has never been completely solved for IPv4, which=0A= is exactly why NAT has been used as a partial solution. For IPv6,=0A= after several years of work, the IETF has converged on an=0A= architectural approach intended with service restoration as initial=0A= aim [21]. When this document was drafted, the IETF was actively=0A= defining the details of this approach to the multihoming problem.=0A= The approach appears to be most suitable for small and medium sites,=0A= though it will conflict with firewall state procedures. At this time=0A= there are also active discussions in the address registries=0A= investigating the possibility of assigning provider-independent=0A= address space. Their challenge is finding a reasonable metric for=0A= limiting the number of organizations that would qualify for a global=0A= routing entry. Additional work appears to be necessary to satisfy=0A= the entire range of requirements.=0A= =0A= =0A= 7. IANA Considerations=0A= =0A= This document requests no action by IANA=0A= =0A= =0A= 8. Security Considerations=0A= =0A= While issues which are potentially security related are discussed=0A= throughout the document, the approaches herein do not introduce any=0A= new security concerns. Product marketing departments have widely=0A= sold IPv4 NAT as a security tool and suppliers have been implementing=0A= address translation functionality in their firewalls, though the=0A= misleading nature of those claims has been previously documented in=0A= [2] and [4].=0A= =0A= This document defines IPv6 approaches which collectively achieve the=0A= goals of the network manager without the negative impact on=0A= applications or security that are inherent in a NAT approach. To the=0A= degree that these techniques improve a network manager's ability to=0A= explicitly audit or control access, and thereby manage the overall=0A= attack exposure of local resources, they act to improve local network=0A= security. In particular the explicit nature of a content aware=0A= firewall in NAP will be a vast security improvement over the NAT=0A= artifact where lack of translation state has been widely sold as a=0A= form of protection.=0A= =0A= =0A= 9. Conclusion=0A= =0A= This document has described a number of techniques that may be=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 28]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= combined on an IPv6 site to protect the integrity of its network=0A= architecture. These techniques, known collectively as Network=0A= Architecture Protection, retain the concept of a well defined=0A= boundary between "inside" and "outside" the private network, and=0A= allow firewalling, topology hiding, and privacy. However, because=0A= they preserve address transparency where it is needed, they achieve=0A= these goals without the disadvantage of address translation. Thus,=0A= Network Architecture Protection in IPv6 can provide the benefits of=0A= IPv4 Network Address Translation without the corresponding=0A= disadvantages.=0A= =0A= The document has also identified a few ongoing IETF work items that=0A= are needed to realize 100% of the benefits of NAP.=0A= =0A= =0A= 10. Acknowledgements=0A= =0A= Christian Huitema has contributed during the initial round table to=0A= discuss the scope and goal of the document, while the European Union=0A= IST 6NET project acted as a catalyst for the work documented in this=0A= note. Editorial comments and contributions have been received from:=0A= Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar,=0A= Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark=0A= Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith,=0A= Elwyn Davies, Daniel Senie, Soininen Jonne, Lindqvist Erik Kurt and=0A= other members of the v6ops WG.=0A= =0A= =0A= 11. References=0A= =0A= 11.1. Normative References=0A= =0A= [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.=0A= Lear, "Address Allocation for Private Internets", BCP 5,=0A= RFC 1918, February 1996.=0A= =0A= [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator=0A= (NAT) Terminology and Considerations", RFC 2663, August 1999.=0A= =0A= [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery=0A= for IP Version 6 (IPv6)", RFC 2461, December 1998.=0A= =0A= [4] Hain, T., "Architectural Implications of NAT", RFC 2993,=0A= November 2000.=0A= =0A= [5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address=0A= Translator (Traditional NAT)", RFC 3022, January 2001.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 29]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= [6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the=0A= IP Network Address Translator", RFC 3027, January 2001.=0A= =0A= [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless=0A= Address Autoconfiguration in IPv6", RFC 3041, January 2001.=0A= =0A= [8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address=0A= Allocations to Sites", RFC 3177, September 2001.=0A= =0A= [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.=0A= Carney, "Dynamic Host Configuration Protocol for IPv6=0A= (DHCPv6)", RFC 3315, July 2003.=0A= =0A= [10] Draves, R., "Default Address Selection for Internet Protocol=0A= version 6 (IPv6)", RFC 3484, February 2003.=0A= =0A= [11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host=0A= Configuration Protocol (DHCP) version 6", RFC 3633,=0A= December 2003.=0A= =0A= [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure=0A= Neighbor Discovery (SEND)", RFC 3971, March 2005.=0A= =0A= [13] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering=0A= an IPv6 Network without a Flag Day", RFC 4192, September 2005.=0A= =0A= [14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast=0A= Addresses", RFC 4193, October 2005.=0A= =0A= 11.2. Informative References=0A= =0A= [15] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-=0A= Domain Routing (CIDR): an Address Assignment and Aggregation=0A= Strategy", RFC 1519, September 1993.=0A= =0A= [16] Wasserman, M., "Recommendations for IPv6 in Third Generation=0A= Partnership Project (3GPP) Standards", RFC 3314,=0A= September 2002.=0A= =0A= [17] Savola, P. and B. Haberman, "Embedding the Rendezvous Point=0A= (RP) Address in an IPv6 Multicast Address", RFC 3956,=0A= November 2004.=0A= =0A= [18] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful=0A= (draft-dupont-ipv6-rfc3041harmful-05.txt)", June 2004.=0A= =0A= [19] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning=0A= (chown-v6ops-port-scanning-implications-01.txt)", July 2004.=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 30]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= [20] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to=0A= think about when Renumbering an IPv6 network=0A= (draft-chown-v6ops-renumber-thinkabout-03)", October 2004.=0A= =0A= [21] Huston, G., "Architectural Commentary on Site Multi-homing=0A= using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)",=0A= July 2004.=0A= =0A= =0A= Appendix A. Additional Benefits due to Native IPv6 and Universal=0A= Unique Addressing=0A= =0A= The users of native IPv6 technology and global unique IPv6 addresses=0A= have the potential to make use of the enhanced IPv6 capabilities, in=0A= addition to the benefits offered by the IPv4 technology.=0A= =0A= A.1. Universal Any-to-Any Connectivity=0A= =0A= One of the original design points of the Internet was any-to-any=0A= connectivity. The dramatic growth of Internet connected systems=0A= coupled with the limited address space of the IPv4 protocol spawned=0A= address conservation techniques. NAT was introduced as a tool to=0A= reduce demand on the limited IPv4 address pool, but the side effect=0A= of the NAT technology was to remove the any-to-any connectivity=0A= capability. By removing the need for address conservation (and=0A= therefore NAT), IPv6 returns the any-to-any connectivity model and=0A= removes the limitations on application developers. With the freedom=0A= to innovate unconstrained by NAT traversal efforts, developers will=0A= be able to focus on new advanced network services (i.e. peer-to-peer=0A= applications, IPv6 embedded IPsec communication between two=0A= communicating devices, instant messaging, Internet telephony, etc..)=0A= rather than focusing on discovering and traversing the increasingly=0A= complex NAT environment.=0A= =0A= It will also allow application and service developers to rethink the=0A= security model involved with any-to-any connectivity, as the current=0A= edge firewall solution in IPv4 may not be sufficient for any- to-any=0A= service models.=0A= =0A= A.2. Auto-configuration=0A= =0A= IPv6 offers a scalable approach to minimizing human interaction and=0A= device configuration. Whereas IPv4 implementations require touching=0A= each end system to indicate the use of DHCP vs. a static address and=0A= management of a server with the pool size large enough for the=0A= potential number of connected devices, IPv6 uses an indication from=0A= the router to instruct the end systems to use DHCP or the stateless=0A= auto configuration approach supporting a virtually limitless number=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 31]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= of devices on the subnet. This minimizes the number of systems that=0A= require human interaction as well as improves consistency between all=0A= the systems on a subnet. In the case that there is no router to=0A= provide this indication, an address for use only on the local link=0A= will be derived from the interface media layer address.=0A= =0A= A.3. Native Multicast Services=0A= =0A= Multicast services in IPv4 were severely restricted by the limited=0A= address space available to use for group assignments and an implicit=0A= locally defined range for group membership. IPv6 multicast corrects=0A= this situation by embedding explicit scope indications as well as=0A= expanding to 4 billion groups per scope. In the source specific=0A= multicast case, this is further expanded to 4 billion groups per=0A= scope per subnet by embedding the 64 bits of subnet identifier into=0A= the multicast address.=0A= =0A= IPv6 allows also for innovative usage of the IPv6 address length, and=0A= makes it possible to embed the multicast 'Rendezvous Point' (or RP)=0A= [17] directly in the IPv6 multicast address when using ASM multicast.=0A= This is not possible with limited size of the IPv4 address. This=0A= approach also simplifies the multicast model considerably, making it=0A= easier to understand and deploy.=0A= =0A= A.4. Increased Security Protection=0A= =0A= The security protection offered by native IPv6 technology is more=0A= advanced than IPv4 technology. There are various transport=0A= mechanisms enhanced to allow a network to operate more securely with=0A= less performance impact:=0A= o IPv6 has the IPsec technology directly embedded into the IPv6=0A= protocol. This allows for simpler peer-to-peer authentication and=0A= encryption, once a simple key/trust management model is developed,=0A= while the usage of some other less secure mechanisms is avoided=0A= (i.e. md5 password hash for neighbor authentication).=0A= o On a local network, any user will have more security awareness.=0A= This awareness will motivate the usage of simple firewall=0A= applications/devices to be inserted on the border between the=0A= external network and the local (or home network) as there is no=0A= Address Translator and hence no false safety perception.=0A= o All flows on the Internet will be better traceable due to a unique=0A= and globally routable source and destination IPv6 address. This=0A= may facilitate an easier methodology for back-tracing DoS attacks=0A= and avoid illegal access to network resources by simpler traffic=0A= filtering.=0A= o The usage of private address-space in IPv6 is now provided by=0A= Unique Local Addresses, which will avoid conflict situations when=0A= merging networks and securing the internal communication on a=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 32]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= local network infrastructure due to simpler traffic filtering=0A= policy.=0A= o The technology to enable source-routing on a network=0A= infrastructure has been enhanced to allow this feature to=0A= function, without impacting the processing power of intermediate=0A= network devices. The only devices impacted with the source-=0A= routing will be the source and destination node and the=0A= intermediate source-routed nodes. This impact behavior is=0A= different if IPv4 is used, because then all intermediate devices=0A= would have had to look into the source- route header.=0A= =0A= A.5. Mobility=0A= =0A= Anytime, anywhere, universal access requires MIPv6 services in=0A= support of mobile nodes. While a Home Agent is required for initial=0A= connection establishment in either protocol version, IPv6 mobile=0A= nodes are able to optimize the path between them using the MIPv6=0A= option header while IPv4 mobile nodes are required to triangle route=0A= all packets. In general terms this will minimize the network=0A= resources used and maximize the quality of the communication.=0A= =0A= A.6. Merging Networks=0A= =0A= When two IPv4 networks want to merge it is not guaranteed that both=0A= networks would be using different address-ranges on some parts of the=0A= network infrastructure due to the usage of RFC 1918 private=0A= addressing. This potential overlap in address space may complicate a=0A= merge of two and more networks dramatically due to the additional=0A= IPv4 renumbering effort. i.e. when the first network has a service=0A= running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by=0A= the 2nd merging network. Similar address conflicts can happen when=0A= two network devices from these merging networks want to communicate.=0A= =0A= With the usage of IPv6 the addressing overlap will not exist because=0A= of the existence of the Unique Local Address usage for private and=0A= local addressing.=0A= =0A= A.7. Community of interest=0A= =0A= Although some Internet-enabled devices will function as fully-=0A= fledged Internet hosts, it is believed that many will be operated in=0A= a highly restricted manner functioning largely or entirely within a=0A= Community of Interest. By Community of Interest we mean a collection=0A= of hosts that are logically part of a group reflecting their=0A= ownership or function. Typically, members of a Community of Interest=0A= need to communicate within the community but should not be generally=0A= accessible from the public Internet. They want the benefits of the=0A= connectivity provided by the Internet, but do not want to be exposed=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 33]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= to the rest of the world. The ability in NAP to virtualize the=0A= topology and mask portions of it is applied to the community,=0A= creating arbitrary groupings. It will also allow building virtual=0A= organization networks on the fly, which is very difficult to do in=0A= IPv4+NAT scenarios.=0A= =0A= =0A= Appendix B. Revision history=0A= =0A= B.1. Changes from *-vandevelde-v6ops-nap-00 to=0A= *-vandevelde-v6ops-nap-01=0A= o Document introduction has been revised and overview table added=0A= o Comments and suggestions from nap-00 draft have been included.=0A= o Initial section of -00 draft 2.6 and 4.6 have been aggregated into=0A= a new case study section 5.=0A= o The list of additional IPv6 benefits has been placed into=0A= appendix.=0A= o new security considerations section added.=0A= o GAP analysis revised.=0A= o Section 2.6 and 4.6 have been included.=0A= =0A= B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00=0A= o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-=0A= ietf-v6ops-nap-00.txt.=0A= o Editorial changes.=0A= =0A= B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01=0A= o Added text in Chapter 2.2 and 4.2 to address more details on=0A= firewall and proxy=0A= o Revised Eric Klein contact details=0A= o Added note in 4.2 that control over the proposed statefull-filter=0A= should be by a simple user-interface=0A= =0A= B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02=0A= o General Note: Header more consistent capitalized.=0A= o Section 1: para 3: s/...and privacy and will... translation./=0A= ...and privacy. NAP will achieve these security goals without=0A= address translation whilst maintaining any-to-any connectivity./=0A= o Section 1: Various editorial changes happened=0A= o Section 2.1: Changed: 'Frequently a simple user interface is=0A= sufficient for configuring'. into 'Frequently a simple user=0A= interface, or no user interface is sufficient'=0A= o Section 2.2: (Simple Security ) Better not to use the word -evil-=0A= in the text=0A= o Section 2.2: changed 'provided by NAT are actually ' into=0A= 'provided by NAT is actually'=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 34]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 2.2: para 3: s/actually false/actually an illusion/=0A= o Section 2.2: para 2: added 'Also it will only be reliable if a=0A= mechanism such as 'trusted computing' is implemented in the end-=0A= system; without this enhancement administrators will be unwilling=0A= to trust the behavior of end-systems.=0A= o Section 2.3: para 1: s/of the NAT devices state/from the NAT=0A= device's state/=0A= o Section 2.4: para1: clarified the definition of topology hiding=0A= o Section 2.4: last sentence of next-to-last paragraph, added=0A= punctuation at end of sentence.=0A= o Section 2.4: added first line: When mentioning 'topology hiding'=0A= the goal is to make a reference that an entity outside the network=0A= can not make a correlation between the location of a device and=0A= the address of a device on the local network.=0A= o Section 2.4: para 1: s/reflected/represented/=0A= o Section 2.5: last par: added reference: 'Section 2.7 describes=0A= some disadvantages that appear if independent networks using=0A= [RFC1918] addresses have to be merged.'=0A= o Section 2.6: Added text that private address-space is not=0A= limitless=0A= o Section 2.6: Various editorial changes=0A= o Section 2.7: Para 1 editorial revised=0A= o Section 2.7: last para: s/This solution/The addition of an extra=0A= NAT as a solution/=0A= o Section 2.7: s/highly desirable to be/highly desirable due to=0A= resiliency and load-balancing to be/=0A= o Section 2.7: added text on the reason why there are overlapping=0A= addresses=0A= o Section 2.7: last para: s/merged address space/overlapping address=0A= spaces in the merged networks/=0A= o Section 3.1: Para 1 editorial changes=0A= o Section 3.1: s/by contacted web sites, so IPv6/by web sites that=0A= are accessed from the device: IPv6 /=0A= o Section 3.1: s/as that would have a serious negative impact on=0A= global routing/as that would have a negative effect on global=0A= route aggregation=0A= o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in=0A= global routing table is not scalable=0A= o Section 3.2: s3.2: Noted that it is not always interesting to mix=0A= ULA with global as that may lead to SAS issues=0A= o Section 3.3: last para: s/delegating router/delegating router=0A= (incorporating a DHCPv6 server)/, s/across an administrative/=0A= possibly across an administrative/=0A= o Section 3.4: Changed: 'random assignment has as purpose' to=0A= 'random assignment has a purpose'=0A= o Section 3.4: para 2: Replace first sentence with: 'The random=0A= assignment is intended to mislead the outside world about the=0A= structure of the local network.'=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 35]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 3.4: para 2: s/there is a correlation/needs to maintain a=0A= correlation/=0A= o Section 3.4: para 2: s/like a/such as a/=0A= o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from=0A= mapping/and from mapping of/=0A= o Section 3.4: para 3: s/are reachable on/are allocated to devices=0A= on/=0A= o Section 3.4: para 3: s/belonging to the same subnet next to each=0A= other/belonging to devices adjacent to each other on the same=0A= subnet/=0A= o Section 3.4: s/aggregation device/indirection device/=0A= o Section 4.1: split the 1 section up into 2 separate sections=0A= o Section 4.1: s/ End node connections involving other nodes on the=0A= global Internet will always use the global IPv6 addresses [9]=0A= derived from this prefix delegation./ End node connections=0A= involving other nodes on the global Internet will always use the=0A= global IPv6 addresses [9] derived from this prefix delegation. It=0A= should be noted that the policy table needs to be correctly set up=0A= so that true global prefixes are distinguished from ULAs and will=0A= be used for the source address in preference when the destination=0A= is not a ULA/=0A= o Section 4.1: A more secure network environment can be established=0A= by having the referenced ULA addresses statically configured on=0A= the network devices as this decreases the dynamic aspects of the=0A= network, however the operational overhead is increased.=0A= o Section 4.2: Added note that IID should be randomized for port-=0A= scan protection=0A= o Section 4.2: Removed text: This is an automated procedure of=0A= sending Internet Control Message Protocol (ICMP) echo requests=0A= (also known as PINGs) to a range of IP addresses and recording=0A= replies. This can enable an attacker to map the network.=0A= o Section 4.2: paragraph beginning: "This simple rule...". The=0A= first sentence in this paragraph was overly-long. The sentence=0A= has been fragmented=0A= o Section 4.2: para 1: s/similar as for an/similar to that of an/=0A= o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/=0A= Internet. The use of firewall and Intrusion Detection Systems=0A= (IDS) is/=0A= o Section 4.2: para 1: s/but has/but with/=0A= o Section 4.2: para 1: s/end to end/end-to-end/=0A= o Section 4.2: Item 3: s/amount/number/=0A= o Section 4.2: Item 3: s/This goes from the assumption that the=0A= attacker has no/This protection is nullified if the attacker has/=0A= o Section 4.2: para after Item 3: s/pose/offer/ (or provide).=0A= o Section 4.2: para after Item 3: s/best- practices/best practices/=0A= o Section 4.2: para after example firewall rules: s/create similar=0A= protection and security holes the typical IPv4 NAT device will=0A= offer/provide (non-)protection and create security holes similar=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 36]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= to those offered to a network using a typical IPv4 NAT device/=0A= o Section 4.2: para next but one after firewall rules: s/What one=0A= does when topology probing is to get an idea of the available=0A= hosts/The intention of topology probing is to identify a selection=0A= of the available hosts/=0A= o Section 4.2: s/This is directly the opposite of what IPv6 security=0A= best practices are trying to achieve./IPv6 security best practices=0A= will avoid this kind of illusory security but can only do this if=0A= correctly configured firewalls and IDS systems are used at the=0A= perimeter where some IPv4 networks have relied on NATs.=0A= o Section 4.2: s/ It is recommended for site administrators to take=0A= [17] into consideration to achieve the expected goal./ It is=0A= recommended for site administrators to take [17] into=0A= consideration to achieve the expected goal. This protection will=0A= also be nullified if IIDs are configured in a group near the start=0A= of the IID space./=0A= o Section 4.2: Removed the example study and added complementary=0A= text to describe a potential behavior=0A= o Section 4.4: rewrite of the section to reduce the importance of=0A= the MIPv6 and tunneled solution=0A= o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested=0A= in the text, however text is added that any kind of tunneling=0A= should do the trick.=0A= o Section 4.4: para 2: after 'As discussed above' inserted '(see=0A= Section 3.1)'=0A= o Section 4.4: para 3: s/consolidated on/indirected via/=0A= o Section 4.4: para 3: s/topololgy masked/each topology masked/=0A= o Section 4.4: para 3: Expanded acronym COA=0A= o Section 4.4: para 3: s/rack mounted/static/=0A= o Section 4.4: Rephrasing of text happened in this section=0A= o Section 4.5: change: "so that a NAT is not required" to: "so that=0A= IPv6 address translation is not required".=0A= o Section 4.5: changed 'periodically to look' into 'to look=0A= periodically'=0A= o Section 4.5: change: "2^64 hosts" to: "2^64 addresses".=0A= o Section 4.5: Removed the statement '(or even defined)=0A= o Section 4.6: last para: s/which will lead to the IPv4 practice/=0A= which will require the adoption of the IPv4 workaround/=0A= o Section 4.6: s/the IPv4 constricting scenarios of multiple devices=0A= sharing a/the constriction of IPv4 scenarios where multiple=0A= devices are forced to share a/=0A= o Section 4.7: s/as the zero-touch external/as an almost zero-touch=0A= external/=0A= o Section 5: Replaced first three sentences with: In presenting=0A= these case studies we have chosen to consider categories of=0A= network divided first according to their function either as=0A= carrier/ISP networks or end user (such as enterprise) networks=0A= with the latter category broken down according to the number of=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 37]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= connected end hosts.=0A= o Section 5: bullet points: s/connection/connected end hosts/=0A= o Section 5.1: s/addressing independence/addressing independence=0A= when using IPv4/=0A= o Section 5.1: last para: s/is only affecting/will only affect/=0A= o Section 5.1: changed 'allocation' into 'allocation'=0A= o Section 5.1: changed: '(typically a one or' into '(typically one=0A= or'=0A= o section 5.1: changed: s/allocation/assignment/ in one of the=0A= paragraphs=0A= o section 5.2: para 1: s?is too long?is too long (very often just a=0A= /32 just giving a single address)?=0A= o Section 5.4: (Case study: ISP networks) ULA usage for ISP/=0A= Carrier-grade networks is mentioned in the draft, while it was=0A= suggested that for these NW the PI addresses are already very=0A= stable and they should be qualified for setting up proper=0A= filtering -> removed ULA from this section.=0A= o Section 5.4: changed 'intra- communication' into 'communication'=0A= o Section 5.4: s/chapter 5.1/Section 5.1/=0A= o Section 6.1: (Completion of work on ULAs) Text revision to reflect=0A= current state of ULA or remove the chapter? Chapter removed ...=0A= ULA specification is in the RFC-editor queue.=0A= o Section 6.3: (Minimal Traceability) Better to say "topology=0A= masking _may be_ required" instead of "is required", because=0A= whether this is needed or not is a value judgment.=0A= o Section 6.4: (Renumbering Procedure) Renumbering procedure is in=0A= RFC queue. The section corrected in the current state?=0A= o Section 6.4: s/well solved/completely solved/=0A= o In general the whole chapter 6 has been revised to reflect current=0A= status=0A= =0A= B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03=0A= o Editorial changes in response to IESG review comments and=0A= questions.=0A= o Introduction: clarified impact & goal for limited additional NAT=0A= discussion here / modified tone wrt marketing / grammar cleanup=0A= o Introduction: s/market acceptance/deployment=0A= o Introduction: noted that users do not evaluate technical trade-=0A= offs and that marketing does not mention the downside of address=0A= translation=0A= o Introduction: added paragraph about why nat !=3D security=0A= o Table1: s/benefit/Goal/ s/ULA/4193/ removed long numeric string /=0A= added app end points & number of subnets=0A= o Section 2: tone reduction about marketing=0A= o Section 2.1: grammar cleanup / clarified point about use of public=0A= space / added paragraph about topology restrictions / removed last=0A= paragraph about security=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 38]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= o Section 2.2: moved paragraph about firewalls to 4.2 / deleted=0A= discussion about distributed security / clarified point about port=0A= overload=0A= o Section 2.3: Added opening sentence to explain the goal of the=0A= section / changed comment about theory to an absolute / qualified=0A= logging and checking times=0A= o Section 2.4: deleted confusing/redundant comments about identifier=0A= / clarified point about nodes appearing to be at the edge / added=0A= clarification that focused scanning on the port range reaches=0A= active nodes=0A= o Section 2.5: clarified that the reason for autonomy is large space=0A= & impact was on the local network=0A= o Section 2.6: clarified point about reduction of IPv4 consumption=0A= rate / s/30%/25% / added point about limitations of cascaded nat /=0A= added para about limited app endpoints as well as topology=0A= restrictions=0A= o Section 2.7: clarification about why multihoming & renumbering are=0A= discussed together / point about sparse allocation / s/speaces/=0A= spaces=0A= o Section 3: s/emulate/replace / added para about 'gaps' being=0A= discussed later=0A= o Section 3.1: Cleaned up description of SLAAC & 3041 / specified=0A= server as DHCP / added comment about sparse allocation=0A= o Section 3.2: grammar cleanup / updated reference from ID to RFC=0A= 4193 / added point about policy table in 3484 to bias ULA over ISP=0A= prefix=0A= o Section 3.3: Clarification about goal for section=0A= o Section 3.4: reorder paragraphs to put goal up front=0A= o Section 4.1: s/could/should/ s/prior to establishing/independent=0A= of the state of / clarified why concatenation would not collide /=0A= another comment about the 3484 table for ULA biasing / clarified=0A= point about lack of routing protocol=0A= o Section 4.2: clarified point about firewall at boundary /=0A= clarified point about valid lifetime / clarified point that IPsec=0A= works the same w/o NAT / added point about authenticating=0A= correspondent / clarified that the scanning threat is addresses as=0A= ports are the same once an address is known / rearranged paragraph=0A= to keep scanning thread together / inserted firewall discussion=0A= moved from 2.2 / clarified role of simple firewall / added comment=0A= about service provider mediated pinhole management=0A= o Section 4.3: added paragraph about tracking privacy address use=0A= o Section 4.4: clarified point about tracking wrt NAT / added=0A= comment about IGP complexity / s/conceal/isolate/ s/possible/=0A= potential/ reworded ULA description which was technically=0A= backwards / additional description of the goal / added picture and=0A= referenced it from descriptions converted options to descriptive=0A= list / added discussion about blocking binding updates / added=0A= vlan option / s/would be to use/uses to make it clear this already=0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 39]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= works / para 2 s/prefixes/addresses and replaced last part of the=0A= sentence to clarify what was being hidden.=0A= o Section 4.5: Grammar cleanup / clarification about policy=0A= o Section 4.6: replaced long number string with power qnty of=0A= subnets / added reference to new capabilities like SEND=0A= o Section 4.7: s/CIDR-like/CIDR allocated/ s/this/to multiple=0A= addresses/ s/may/will likely/ s/if/when/ s/from SP/between sp/=0A= Updated reference for renumbering proceedure to RFC 4192=0A= o Section 5: d/of these/=0A= o Section 5.1: s/private enterprise/private enterprise, academic,=0A= research, or government / deleted redundant discussion about /48=0A= allocation / added discussion about larger deployments using=0A= tunneling /=0A= o Section 5.2: clarification of overload on port vs. protocol /=0A= added comment about upstream NAT / clarified 3041 use as short=0A= timeframe=0A= o Section 5.3: capitalize Internet=0A= o Section 5.4: s/IPv4/IP as role is not version specific / deleted=0A= comment about preference to ULA.=0A= o Section 6.1: (security) inserted section discussing need for=0A= dynamic pinhole management=0A= o Section 6.2: (topology mask) added comment about deployment scale=0A= / added comment about firewall blocking BU / clarified point about=0A= future work being an optimization to reduce firewall load=0A= o Section 6.3: (tracability) grammar cleanup=0A= o Section 6.4: (renumbering) Cut section since it is no longer a gap=0A= o Section A.2: word order - moved 'only'=0A= o Section A.6: deleted 'legitimate'=0A= o Section A.7: clarified how NAP delivers community of interest=0A= o Spell check=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 40]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Authors' Addresses=0A= =0A= Gunter Van de Velde=0A= Cisco Systems=0A= De Kleetlaan 6a=0A= Diegem 1831=0A= Belgium=0A= =0A= Phone: +32 2704 5473=0A= Email: gunter@cisco.com=0A= =0A= =0A= Tony Hain=0A= Cisco Systems=0A= 500 108th Ave. NE=0A= Bellevue, Wa.=0A= USA=0A= =0A= Email: alh-ietf@tndh.net=0A= =0A= =0A= Ralph Droms=0A= Cisco Systems=0A= 1414 Massachusetts Avenue=0A= Boxborough, MA 01719=0A= USA=0A= =0A= Email: rdroms@cisco.com=0A= =0A= =0A= Brian Carpenter=0A= IBM Corporation=0A= Sauemerstrasse 4=0A= Rueschlikon, 8803=0A= Switzerland=0A= =0A= Email: brc@zurich.ibm.com=0A= =0A= =0A= Eric Klein=0A= Tel Aviv University=0A= Tel Aviv,=0A= Israel=0A= =0A= Phone:=0A= Email: ericlklein@softhome.net=0A= =0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 41]=0A= =0C=0A= Internet-Draft IPv6 Network Architecture Protection June 2006=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Van de Velde, et al. Expires January 1, 2007 [Page 42]=0A= =0C=0A= =0A= ------=_NextPart_000_07FA_01C69C41.EC220E60 Content-Type: text/html; name="rfcdiff-nap-02-03.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="rfcdiff-nap-02-03.htm" =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Diff: draft-ietf-v6ops-nap-02.txt - = draft-ietf-v6ops-nap-03.txt=20 =20 =20 =20 =20 =20 = = = = = = = = = = = = = = = =
 draft-ietf-v6ops-nap-02.txt  =  draft-ietf-v6ops-nap-03.txt 
Network Working Group = G. Van de Velde Network Working Group = G. Van de Velde
Internet-Draft = T. Hain Internet-Draft = T. Hain
Expires: April 25, 2006 = R. Droms Expires: January 1, 2007 = R. Droms
= Cisco = Systems = Cisco Systems
= B. = Carpenter = B. Carpenter
= IBM = Corporation = IBM Corporation
= E. = Klein = E. Klein
= Tel Aviv = University = Tel Aviv University
= October 22, 2005 = June 30, 2006
= IPv6 Network Architecture Protection IPv6 Network Architecture = Protection
= <draft-ietf-v6ops-nap-02.txt> = <draft-ietf-v6ops-nap-03.txt>
Status of this Memo Status of this Memo
= By submitting this Internet-Draft, each author represents that = any By submitting this = Internet-Draft, each author represents that any
= applicable patent or other IPR claims of which he or she is = aware applicable patent or other = IPR claims of which he or she is aware
= have been or will be disclosed, and any of which he or she = becomes have been or will be = disclosed, and any of which he or she becomes
= aware will be disclosed, in accordance with Section 6 of BCP = 79. aware will be disclosed, in = accordance with Section 6 of BCP 79.
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
= Task Force (IETF), its areas, and its working groups. Note = that Task Force (IETF), its areas, = and its working groups. Note that
=
skipping to change at page 1, line 39 = skipping to change at = page 1, line 39
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, = or obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work = in progress."
= The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed = at
= http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
= The list of Internet-Draft Shadow Directories can be accessed = at The list of Internet-Draft = Shadow Directories can be accessed at
= http://www.ietf.org/shadow.html. = http://www.ietf.org/shadow.html.
= This Internet-Draft will expire on April 25, = 2006. This Internet-Draft = will expire on January 1, 2007.
Copyright Notice Copyright Notice
= Copyright (C) The Internet Society (2005). = Copyright (C) The Internet Society (2006).
Abstract Abstract
= Although there are many perceived benefits to Network Address = Although there are many perceived benefits = to Network Address
= Translation (NAT), its primary benefit of "amplifying" = available Translation (NAT), its = primary benefit of "amplifying" available
= address space is not needed in IPv6. In addition to NAT's many = address space is not needed in IPv6. In = addition to NAT's many
= serious disadvantages, there is a perception that other = benefits serious disadvantages, = there is a perception that other benefits
= exist, such as a variety of management and security attributes = that exist, such as a variety of = management and security attributes that
= could be useful for an Internet Protocol site. IPv6 does not = support could be useful for an = Internet Protocol site. IPv6 does not support
= NAT by design and this document shows how Network Architecture = NAT by design and this document shows how = Network Architecture
= Protection (NAP) using IPv6 can provide the same or more = benefits Protection (NAP) using = IPv6 can provide the same or more benefits
= without the need for NAT. = without the need for address translation.
Table of Contents Table = of Contents
= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 4 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . . 4
= 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . = 6 2. = Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 7
= 2.1. Simple Gateway between Internet and Private Network . . . = 6 = 2.1. Simple Gateway between Internet and Private Network . . . 7
= 2.2. Simple Security due to Stateful Filter Implementation . . = 6 = 2.2. Simple Security due to Stateful Filter Implementation . . 7
= 2.3. User/Application tracking . . . . . . . . . . . . . . . . = 7 = 2.3. User/Application tracking . . . . . . . . . . . . . . . . 8
= 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . = 8 = 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9
= 2.5. Independent Control of Addressing in a Private Network . . 9 = 2.5. Independent Control of Addressing in a Private Network . 10
= 2.6. Global Address Pool Conservation . . . . . . . . . . . . . = 9 = 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10
= 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . = 10 = 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11
= 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . = 10 = 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 12
= 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . = 10 = 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12
= 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . = 11 = 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 13
= 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . = 12 = 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 14
= 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . = 12 = 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 14
= 4. Using IPv6 Technology to Provide the Market Perceived = 4. Using IPv6 Technology to Provide the = Market Perceived
= Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . = 13 = Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14
= 4.1. Simple Gateway between Internet and Internal Network . . . = 13 = 4.1. Simple Gateway between Internet and Internal Network . . . 14
= 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . = 13 = 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15
= 4.3. User/Application Tracking . . . . . . . . . . . . . . . . = 15 = 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17
= 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . = 15 = 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 17
= 4.5. Independent Control of Addressing in a Private Network . . 16 = 4.5. Independent Control of Addressing in a Private Network . 20
= 4.6. Global Address Pool Conservation . . . . . . . . . . . . . = 17 = 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 20
= 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . = 17 = 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21
= 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . = 18 = 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 21
= 5.1. Medium/large private networks . . . . . . . . . . . . . . = 18 = 5.1. Medium/large private networks . . . . . . . . . . . . . . 22
= 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . = 20 = 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 23
= 5.3. Single User Connection . . . . . . . . . . . . . . . . . . = 21 = 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25
= 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . = 22 = 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 25
= 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . = 23 = 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 26
= 6.1. Subnet Topology Masking . . . . . . . = . . . . . . . . . . 23 = 6.1. Simple = Security . . . . . . . . . . . . . . . . . . . . . 27
6.2. Minimal Traceability = of Privacy Addresses . . . . . . . . 23 6.2. Subnet Topology Masking . . . . . . = . . . . . . . . . . . 27
6.3. Renumbering = Procedure . . . . . . . . . . . . . . . . . . 23 6.3. Minimal Traceability of Privacy = Addresses . . . . . . . . 27
6.4. Site = Multihoming . . . . . . . . . . . . . . . . . . . . . 24 6.4. Site Multihoming . . . . . . . . . . = . . . . . . . . . . . 28
6.5. Untraceable = Addresses . . . . . . . . . . . . . . . . . . 24 7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 24 = 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
= 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 24 = 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
= 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . = 24 = 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
= 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 25 = 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 25 = 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
= 11.1. Normative References . . . . . . . . . . . . . . . . . . . = 25 = 11.2. Informative References . . . . . . . . . . . . . . . . . . 30
= 11.2. Informative References . . . . . . . . . . . . . . . . . . = 26
= Appendix A. Additional Benefits due to Native IPv6 and = Appendix A. Additional Benefits due to = Native IPv6 and
= Universal Unique Addressing . . . . . . . . . . . . . 27 = Universal Unique Addressing . . . . . . . . . . . . 31
= A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 27 A.1. = Universal Any-to-Any Connectivity . . . . = . . . . . . . . 31
= A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . = 27 = A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 31
= A.3. Native Multicast Services . . . . . . . . . . . . . . . . = 28 = A.3. Native Multicast Services . . . . . . . . . . . . . . . . 32
= A.4. Increased Security Protection . . . . . . . . . . . . . . = 28 = A.4. Increased Security Protection . . . . . . . . . . . . . . 32
= A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . = 29 = A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 33
= A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . = 29 = A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 33
= A.7. Community of interest . . . . . . . . . . . . . . . . . . = 29 = A.7. Community of interest . . . . . . . . . . . . . . . . . . 33
= Appendix B. Revision history . . . . . . . . . . . . . . . . . . = 30 = Appendix B. Revision history . . . . . . . . . . . . . . . . . . 34
= B.1. Changes from *-vandevelde-v6ops-nap-00 to B.1. Changes from *-vandevelde-v6ops-nap-00 = to
= *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . = 30 = *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 34
= B.2. Changes from *-vandevelde-v6ops-nap-01 to B.2. Changes from *-vandevelde-v6ops-nap-01 = to
= *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . = 30 = *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 34
= B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . = 30 = B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 34
= B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . = 30 = B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 34
= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . = 35 B.5. Changes from = *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 38
= Intellectual Property and Copyright Statements . . . . . . . . . . = 36 = Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual = Property and Copyright Statements . . . . . . . . . . 42
1. = Introduction 1. Introduction
= Although there are many perceived benefits to Network Address There have been periodic = claims that IPv6 will require a Network
Translation (NAT), its = primary benefit of "amplifying" available Address Translation (NAT), = because in IPv4 people use NAT to
= address space is not needed in IPv6. The serious disadvantages of accomplish that person's preferred task. This = document will explain
= ambiguous "private" address space and = of Network Address Translation = why those = pronouncements are false by showing how to accomplish the
= (NAT) [1][5] have been well documented = [4][6]. However, given its = task goal without = address translation. Although there are many
= wide market acceptance NAT undoubtedly = has some perceived benefits. = perceived benefits to NAT, its primary benefit of "amplifying"
= Indeed, in an Internet model based on universal = any-to-any available = address space is not needed in IPv6. The serious
connectivity, product = marketing departments have driven a perception disadvantages and impact on = applications by ambiguous address space
= hat some connectivity and security = concerns can only be solved by and = Network Address Translation [1] [5] have = been well documented [4]
= using a NAT device or by using logically = separated Local Area Network [6] so there will not be much = additional discussion here. However,
(LAN) address spaces. This = document describes the reasons for given its wide deployment NAT undoubtedly has some = perceived
utilizing a NAT device in an = IPv4 environment that are regularly benefits, though the bulk of = those using it have not evaluated the
cited in marketing = pronouncements. It then shows how these needs can = technical = trade-offs. Indeed, product marketing departments have
be met without using NAT in an IPv6 network. Some of the IPv6 effectively driven a perception that some connectivity and security
solutions offer advantages = beyond the equivalent IPv4 NAT = solution. concerns can only = be solved by using a NAT device, without = any
The use of the facilities from IPv6 = described in this document avoids mention of the negative impacts on applications. This is = amplified
= the negative impacts of address translation. 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.
= As far as security and privacy is = concerned, this document considers = This document describes the goals for utilizing a = NAT device in an
IPv4 environment that are regularly cited as = solutions for perceived
problems. It then shows how these needs can be met = without using the
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.
=
As far as = security and privacy are concerned, this = document considers
= how to mitigate a number of threats. Some are obviously = external, how to mitigate a number = of threats. Some are obviously external,
= such as having a hacker trying to penetrate = your network, or having a = such as having a hacker or a worm infected = machine outside trying to
= worm infected machine outside your = network trying to attack it. = Some penetrate and attack the = local network. Some are local such as a
= are local such as a disgruntled employee disrupting business = disgruntled employee disrupting business = operations, or the
= operations, or the unintentional negligence of a user = downloading unintentional = negligence of a user downloading some malware which
= some malware which then proceeds to attack any = device on the LAN. then = proceeds to attack from within. Some may = be inherent in the
= Some may be inherent in the device hardware ("embedded") such = as device hardware ("embedded") = such as having some firmware in a
= having some firmware in a domestic appliance "call home" to = its domestic appliance "call home" = to its manufacturer without the user's
= manufacturer without the user's consent. consent.
= This document describes several techniques that may be combined on an = Another consideration discussed is the view that = NAT can be used to
= IPv6 site to protect the integrity of = its network architecture. fulfill the goals of a security policy. At a = technical level the
= These techniques, known collectively as Network Architecture = translation process = fundamentally can not produce security because
= Protection (NAP), retain the concept of a well defined = boundary = mangling the address in the header does not fulfill any = useful
= between "inside" and "outside" the private network, and allow = security functions; = in fact it breaks the ability to produce an audit
= firewalling, topology hiding, and privacy. NAP will achieve = these trail = which is a fundamental security tool. That said, the = artifacts
= security goals without address translation whilst maintaining any-to- of NAT devices do provide = some value.
any = connectivity. = 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).
=
This document = describes several techniques that may be combined in an
IPv6 deployment to protect the integrity of its = network architecture.
It will focus on the 'how to accomplish a goal' = perspective, leaving
most of the 'why that goal' perspective for other = documents. These
techniques, = known collectively as Network Architecture Protection
(NAP), retain = the concept of a well defined boundary between "inside"
and "outside" = the private network, and allow firewalling, topology
hiding, and = privacy. NAP will achieve these security goals without
address = translation whilst regaining the ability for = arbitrary any-
to-any connectivity.
= IPv6 Network Architecture Protection can be summarized in the = IPv6 Network Architecture Protection can be = summarized in the
= following table. It presents the marketed "benefits" of NAT with a = following table. It presents the marketed "benefits" of IPv4+NAT
= cross-reference of how those are delivered in both the IPv4 and = IPv6 with a cross-reference of how = those are delivered in both the IPv4
= environments. and IPv6 = environments.
= benefit IPv4 = IPv6 Goal IPv4 = IPv6
= +------------------+-----------------------+-----------------------+ = +------------------+-----------------------+-----------------------+
= | Simple Gateway | DHCP - single | DHCP-PD - arbitrary = | | Simple Gateway | DHCP - = single | DHCP-PD - arbitrary |
= | as default router| address upstream | length customer = | | as default router| address = upstream | length customer |
= | and address pool | DHCP - limited | prefix upstream = | | and address pool | DHCP - = limited | prefix upstream |
= | manager | number of individual | SLAAC via RA = | | manager | number of = individual | SLAAC via RA |
= | | devices downstream | downstream = | | | devices = downstream | downstream |
= | | see section 2.1 | see section 4.1 = | | | see section = 2.1 | see section 4.1 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Simple Security | Filtering side | Explicit Context = | | Simple Security | Filtering = side | Explicit Context |
= | | effect due to lack | Based Access Control = | | | effect due = to lack | Based Access Control |
=
skipping to change at page 5, line 30 = skipping to change at = page 6, line 30
= | tracking | | = | | tracking | = | |
= | | see section 2.3 | see section 4.3 = | | | see section = 2.3 | see section 4.3 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | End-system | NAT transforms | Temporary use = | | End-system | NAT = transforms | Temporary use |
= | privacy | device ID bits in | privacy addresses = | | privacy | device ID = bits in | privacy addresses |
= | | the address | = | | | the address = | |
= | | see section 2.4 | see section 4.4 = | | | see section = 2.4 | see section 4.4 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Topology hiding | NAT transforms | Untraceable = addresses| | Topology hiding | = NAT transforms | Untraceable addresses|
= | | subnet bits in the | using IGP host = routes| | | = subnet bits in the | using IGP host routes|
= | | address | /or MIPv6 tunnels for| | = | address | /or MIPv6 tunnels |
| | = | stationary systems |
= | | see section 2.4 | see section 4.4 = | | | see section = 2.4 | see section 4.4 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Addressing | RFC 1918 | RFC 3177 & ULA | = | Addressing | RFC 1918 | RFC 3177 & 4193 |
= | Autonomy | | = | | = Autonomy | see section 2.5 | see section 4.5 = |
| | = see section 2.5 | see section 4.5 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Global Address | RFC 1918 | 340,282,366,920,938, | | Global Address | RFC 1918 | 17*10^18 subnets |
= | Pool | | 463,463,374,607,431, | | Pool | << 2^48 application | 3.4*10^38 addresses |
= | Conservation | | 768,211,456 | | Conservation | end = points | full port list / = addr |
= | | | (3.4*10^38) addresses| | | topology restricted | unrestricted topology = |
= | | see section 2.6 | see section 4.6 = | | | see section = 2.6 | see section 4.6 |
= +------------------|-----------------------|-----------------------+ = +------------------|-----------------------|-----------------------+
= | Renumbering and | Address translation | Preferred lifetime = | | Renumbering and | Address = translation | Preferred lifetime |
= | Multi-homing | at border | per prefix & = Multiple| | Multi-homing | at = border | per prefix & Multiple|
= | | | addresses per = | | | = | addresses per |
= | | | interface = | | | = | interface |
= | | see section 2.7 | see section 4.7 = | | | see section = 2.7 | see section 4.7 |
= +------------------+-----------------------+-----------------------+ = +------------------+-----------------------+-----------------------+
= This document first identifies the perceived benefits of NAT in = more This document first identifies = the perceived benefits of NAT in more
= detail, and then shows how IPv6 NAP can provide each of them. = It detail, and then shows how IPv6 = NAP can provide each of them. It
= concludes with a IPv6 NAP case study and a gap analysis of work = that concludes with a IPv6 NAP case = study and a gap analysis of work that
= remains to be done for a complete NAP solution. remains to be done for a complete NAP = solution.
2. = Perceived Benefits of NAT and its Impact on IPv4 2. Perceived Benefits of NAT and its Impact on = IPv4
= This section provides insight into the generally perceived = benefits This section provides = insight into the generally perceived benefits
= of the use of IPv4 NAT as extolled by product = marketing. The goal of of = the use of IPv4 NAT. The goal of this = description is not to
= this description is not to analyze these benefits or discuss the = analyze these benefits or the accuracy of the perception = (detailed
= accuracy of the perception (detailed discussions in [4]), but = to discussions in [4]), but to = describe the deployment requirements and
= describe the deployment requirements and set a context for the = later set a context for the later = descriptions of the IPv6 approaches for
= descriptions of the IPv6 approaches for dealing with those = dealing with those requirements.
= requirements.
2.1. Simple Gateway between Internet and Private = Network 2.1. Simple Gateway between = Internet and Private Network
= A NAT device can connect a private network with any kind of address A = NAT device can connect a private network with addresses allocated
= (ambiguous [RFC 1918] or global registered address) towards = the = from any part of the space (ambiguous [RFC 1918] or global = registered
= Internet. The address space of the = private network can be built from = & unregistered address) towards the = Internet, though extra effort is
= globally unique addresses, from ambiguous address space or from = both needed = when the same range exists on both sides of the NAT. The
= simultaneously. Without needing = specific configuration, the NAT = address space of the private network can be = built from globally
= device enables access between the client side of a = distributed unique addresses, from = ambiguous address space or from both
= client-server application in the private network and the server = side simultaneously. In the simple case of private use addresses, = without
= in the public Internet. needing = specific configuration the NAT device = enables access between
the client side = of a distributed client-server application in the
private network = and the server side located in the public = Internet.
= Wide-scale deployments have shown that using NAT to attach a private Wide-scale deployments have shown that using NAT to = act as a simple
= IPv4 network to the Internet is simple and practical for the non- gateway attaching a private IPv4 network to = the Internet is simple
technical end user. = Frequently a simple user interface, or even a and practical for the non-technical end user. Frequently a = simple
= default configuration is sufficient for configuring both device = and user interface, or even a = default configuration is sufficient for
= application access rights. = configuring both device and application access rights.
= Additionally, thanks to successful marketing campaigns it is = This simplicity = comes at a price as the resulting topology puts
perceived by end users that = their equipment is protected from the restrictions on applications. = The NAT simplicity works well when the
= malicious entities and attackers on the = public IPv4 Internet. applications are = limited to a client/server model = with the server
deployed on the public side of the NAT. For peer-to-peer, = multi-
party, or servers deployed on the private side of = the NAT, helper
technologies must be available. These helper = technologies are
frequently complex to develop and manage, creating a = hidden cost to
this 'simple gateway'.
2.2. Simple Security due to Stateful Filter = Implementation 2.2. Simple Security = due to Stateful Filter Implementation
= A firewall doesn't fully secure a network, = because 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. =
A distributed security = mechanism to protect the end-systems may help
in the above situation; = however, to deploy such a system is quite
complex and may depend upon = behaviour per operating system and
release version. Also it = will only be reliable if a mechanism such
as 'trusted computing' is = implemented in the end-system; without this
enhancement administrators = will be unwilling to trust the behavior of
end-systems. As a result it = will probably not be available in the
next couple of years for = end-user organizations. End-system-only
security mechanisms do not = protect the network infrastructure from
being misused for transit, or = against Distributed Denial of Service
(DDOS) attacks against = individual systems inside: and this is the
area where a NAT device is = perceived to provide some protection.
= =
= It is frequently believed that through its session-oriented = It is frequently believed that through its = session-oriented
= operation, NAT puts in an extra barrier to keep the private = network operation, NAT puts in an = extra barrier to keep the private network
= protected from outside influences. Since a NAT device = typically protected from outside = influences. Since a NAT device typically
= keeps state only for individual sessions, attackers, worms, = etc. keeps state only for = individual sessions, attackers, worms, etc.
= cannot exploit this state to attack a host in = general and on any cannot = exploit this state to attack a specific = host on any other
= port. This benefit may be partially = real, however, experienced port, though in the port overload case of NAPT = attacking all active
= hackers are well aware of NAT devices and are very familiar = with ports = will impact a potentially wide number of hosts. This = benefit
= private address space, and have devised methods of attack (such = as may be partially real, however, = experienced hackers are well aware of
= trojan horses) that readily penetrate NAT boundaries. For = these NAT devices and are very = familiar with private address space, and
= reasons the sense of security provided by NAT is actually an = have devised methods of attack (such as = trojan horses) that readily
= illusion. penetrate NAT = boundaries. For these reasons the sense of security
provided by NAT = is actually an illusion.
= Address translation does not provide = security in itself; for example, = The act of address translation does not = provide security in itself;
= consider a configuration with static NAT translation and all = inbound for example, consider a = configuration with static NAT translation and
= ports translating to a single machine. In such a scenario = the all inbound ports translating = to a single machine. In such a
= security risk for that machine is identical to the case with no = NAT scenario the security risk for = that machine is identical to the case
= device in the communication path. As result there is no = specific with no NAT device in the = communication path. As result there is no
= security value in the address translation function. The = perceived specific security value = in the address translation function. The
= security comes from the lack of pre-established or permanent mapping = perceived security of NAT comes from the lack of pre- established or
= state. Dynamically establishing state in response to = internal permanent mapping state. = Dynamically establishing state in response
= requests reduces the threat of unexpected external connections = to to internal requests reduces = the threat of unexpected external
= internal devices. connections to = internal devices. This role, often marketed as = a
firewall, is really an arbitrary artifact while a = real firewall has
explicit management controls.
= In some cases, NAT operators (including domestic users) may be = In some cases, NAT operators (including = domestic users) may be
= obliged to configure quite complex port mapping rules to allow = obliged to configure quite complex port = mapping rules to allow
= external access to local applications such as a multi-player game = or external access to local = applications such as a multi-player game or
= web servers. In this case the NAT actually adds management = web servers. In this case the NAT actually = adds management
= complexity compared to a simple router. In situations where two = or complexity compared to a simple = router. In situations where two or
= more devices need to host the same application this complexity = shifts more devices need to host = the same application or otherwise use = the
= from difficult to impossible. same public port this complexity shifts from = difficult to impossible.
2.3. User/Application tracking 2.3. User/Application tracking
= Although NATs create temporary state for active sessions, in = general One = usage of NAT is for the local network administrator to track = user
= they provide limited capabilities for the administrator of the NAT = to and = application traffic. Although NATs create temporary state = for
= gather information about who in the private network is = requesting active sessions, in = general they provide limited capabilities for the
= access to which Internet location. This could = in theory be done by = administrator of the NAT to gather information about who in the
= logging the network address translation details of the private = and private network is requesting = access to which Internet location.
= the public addresses from the NAT device's state database. = This is done = by periodically logging the network = address translation
details of the = private and the public addresses from the NAT device's
state = database.
= The checking of this database is not always a simple task, = especially The subsequent checking of this database is not = always a simple task,
= if Port Address Translation is used. It also has an unstated = especially if Port Address Translation is = used. It also has an
= assumption that the administrative instance has a mapping between = an = unstated assumption that the administrative instance has a = mapping
= IPv4-address and a network element or user at all times, or = the between a private IPv4-address and a network element or = user at all
= administrator has a time-correlated list of the address/port = times, or the administrator has a = time-correlated list of the
= mappings. address/port = mappings.
2.4. Privacy and Topology Hiding 2.4. Privacy and Topology Hiding
= The goal of 'topology hiding' is to = provide devices on the private = One goal of = 'topology hiding' is to prevent external = entities from
network with an identifier = (IPv4 address) which an entity outside the making a correlation between the topological = location of devices on
network can use to = communicate with or to reference the private the local network. The ability of NAT to provide = Internet access to
network devices in protocols = but prevents the external entity = making a large community of users = by the use of a single (or a few) global
= a correlation between the topological location of the private device IPv4 routable addresses offers a simple mechanism to = hide the
and the address on the = local network. internal topology = of a network. In this scenario the large community
= = will be represented in the = Internet by a single (or a few) IPv4
= The ability of NAT to provide Internet access to a large community = of address(es).
= users by the use of a single (or a few) global IPv4 routable =
= addresses offers a simple mechanism to hide the internal topology = of
= a network. In this scenario the large community will be = represented
= in the Internet by a single (or a few) IPv4 address(es). =
= The use of NAT then results in a user behind a NAT gateway = actually The use of NAT then = results in a user behind a NAT gateway actually
= appearing on the Internet as a user = inside the NAT box itself; i.e., = appearing from the Internet as a user = inside the NAT box itself;
= the IPv4 address that appears on the Internet is only sufficient = to i.e., the IPv4 address that = appears on the Internet is only
= identify the NAT. When concealed behind = a NAT it is impossible to = sufficient to identify the NAT so all internal = nodes appear to exist
= tell from the outside which member of a family, which customer of = an at the = demarcation edge. When concealed behind a NAT it is
= Internet cafe, or which employee of a company generated or received = a impossible to tell from the = outside which member of a family, which
= particular packet. Thus, although NATs do nothing to provide = customer of an Internet cafe, or which = employee of a company
= application level privacy, they do prevent the external tracking = and generated or received a = particular packet. Thus, although NATs do
= profiling of individual host computers = by means of their IP nothing to = provide application level privacy, they do prevent the
= addresses, usually known as 'device profiling'. At the same time = a external tracking and profiling = of individual systems by means of
= NAT creates a smaller pool of addresses for a much more focused = point their IP addresses, usually = known as 'device profiling'.
= of attack. =
At the same time = a NAT creates a smaller pool of addresses for a much
more focused = point of attack, where the adversary does not = need to
scan the entire local network but can instead = concentrate on the
active ports associated with the NAT adress. By = periodically
scanning the limited 16 bit port range on the public = side of the NAT,
the attack will routinely find all ports that are = open to active
nodes.
= There is a similarity with privacy based on application level = There is a similarity with privacy based on = application level
= proxies. When using an application level gateway for browsing = the proxies. When using an = application level gateway for browsing the
= web for example, the 'privacy' of a web user can be provided by = web for example, the 'privacy' of a web user = can be provided by
= masking the true identity of the original web user towards the = masking the true identity of the original = web user towards the
= outside world (although the details of what is - or is not - = logged outside world (although the = details of what is - or is not - logged
= at the NAT/proxy will be different). = at the NAT/proxy will be different).
= Some enterprises prefer to hide as much = as possible of their internal Some = network managers prefer to hide as much as = possible of their
= network topology from outsiders. Mostly = this is achieved by blocking = internal network topology from outsiders as a = useful precaution to
= "traceroute" etc., but NAT of course entirely hides the internal = mitigate scanning = attacks. Mostly this is achieved by blocking
= subnet topology, which some network managers = believe is a useful = "traceroute" etc., though NAT entirely hides the internal = subnet
precaution to mitigate scanning attacks. Scanning for IPv6 can be = topology. Scanning is a particular concern in IPv4 networks = because
much harder in comparison = with IPv4 as described in [18]. 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
= Once a list of available devices and IP = addresses has been mapped, a ports. Once a list of = available devices has been mapped, a port-scan
= port-scan on these IP addresses can be performed. Scanning works = by on these IP addresses can be = performed. Scanning works by tracking
= tracking which ports do not receive unreachable errors from = either which ports do not receive = unreachable errors from either the
= the firewall or host. With the list of open ports an attacker = can firewall or host. With the = list of open ports an attacker can
= optimize the time needed for a successful attack by correlating = it optimize the time needed for a = successful attack by correlating it
= with known vulnerabilities to reduce the number of attempts. = For with known vulnerabilities to = reduce the number of attempts. For
= example, FTP usually runs on port 21, and HTTP usually runs on = port example, FTP usually runs on = port 21, and HTTP usually runs on port
= 80. Any vulnerable open ports could be used for initiating = attacks 80. Any vulnerable open = ports could be used for access to an = end
= on an end system. system to command it to = start initiating attacks on others.
2.5. Independent Control of Addressing in a Private = Network 2.5. Independent Control of = Addressing in a Private Network
= Many private IPv4 networks take benefit from using the address = space Many private IPv4 networks = take benefit from using the address space
= defined in RFC 1918 to enlarge the available addressing space = for defined in RFC 1918 to enlarge = the available addressing space for
= their private network, and at the same time reduce their need = for their private network, and at = the same time reduce their need for
= globally routable addresses. This type of local control of = address globally routable = addresses. This type of local control of address
= resources allows a clean and hierarchical addressing structure in = the resources allows a sufficiently large pool for a clean and
= network. hierarchical addressing = structure in the local network.
= Another benefit is due to the usage of independent addresses on = Another benefit is due to the usage of = independent addresses on
= majority of the network infrastructure there is an increased = ability majority of the network = infrastructure there is an increased ability
= to change provider with less operational difficulties. to change provider with less operational = difficulties.
= Section 2.7 describes some disadvantages that appear if = independent Section 2.7 describes = some disadvantages that appear if independent
= networks using [RFC1918] addresses have to be merged. networks using [RFC1918] addresses have to be = merged.
2.6. Global Address Pool Conservation 2.6. Global Address Pool Conservation
= Due to the ongoing depletion of the IPv4 = address range, the remaining = While the widespread = use of IPv4+NAT has reduced the potential
= pool of unallocated IPv4 addresses is = below 30%. While mathematical = consumption = rate, the ongoing depletion of the IPv4 address range has
= models based on historical IPv4 prefix consumption = periodically = already taken the remaining pool of unallocated IPv4 addresses = below
= attempt to predict the future exhaustion date of the IPv4 = address 25%. While mathematical models based on = historical IPv4 prefix
= pool, a direct result of this continuous resource consumption is = that consumption periodically = attempt to predict the future exhaustion
= the administrative overhead for acquiring globally unique = IPv4 date of the IPv4 address = pool, a direct result of this continuous
= addresses will continue increasing in direct response to = tightening resource consumption is = that the administrative overhead for
= allocation policies. In response to the increasing = administrative acquiring globally = unique IPv4 addresses will continue increasing in
= overhead many Internet Service Providers (ISPs) have already = resorted direct response to = tightening allocation policies.
= to the ambiguous addresses defined in RFC 1918 behind a NAT for = the =
= various services they provide as well as connections for their = end In response to the increasing = administrative overhead many Internet
= customers. This happens even though that private address-space is Service Providers (ISPs) have already resorted to = the ambiguous
= strictly limited in size. In turn this = has restricted the number of = addresses defined in RFC 1918 behind a NAT = for the various services
= and types of applications that can be deployed by these ISPs = and they provide as well as = connections for their end customers. This
= their customers. Forced into this = limiting situation such customers = happens even though the private use address-space is strictly limited
= can rightly claim that despite the optimistic predictions of = in size. Some = deployments have already outgrown that space and have
= mathematical models the global pool of = IPv4 addresses is effectively begun cascading NAT to continue expanding, = though this practice
= already exhausted, especially for larger = enterprises. eventually breaks down over routing ambiguity. = Additionally, while
we are unlikely to know the full extent of the = practice (because it
is hidden behind a nat), service providers have been = known to
announce previously unallocated public space to = their customers (to
avoid the problems associated with the same address space appearing
on both sides), only to find that once that space = was formally
allocated and being publicly announced their = customers couldn't reach
the registered networks.
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.
Those who advocate layering of NAT frequently forget = to mention that
there are topology restrictions placed on the = applications. Forced
into this = limiting situation such customers can rightly claim that
despite the = optimistic predictions of mathematical models, the global
pool of IPv4 = addresses is effectively already exhausted.
2.7. Multihoming and Renumbering with NAT = 2.7. Multihoming and Renumbering with = NAT
= Allowing a network to be multihomed and renumbering a network = are Allowing a network to be = multihomed and renumbering a network are
= quite different functions. However, = making a network multihomed is = quite different functions. However these are = argued together as
= often a transitional state required as part of network = renumbering, = reasons for using NAT, because making a network multihomed is = often a
= and NAT interacts with both in the same way. transitional state required as part of network = renumbering, and NAT
interacts with = both in the same way.
= For enterprise networks, it is highly desirable to provide = resiliency For enterprise networks, = it is highly desirable to provide resiliency
= and load-balancing to be connected to more than one Internet = Service and load-balancing to be = connected to more than one Internet Service
= Provider (ISP) and to be able to change ISPs at will. This = means Provider (ISP) and to be able = to change ISPs at will. This means
= that a site must be able to operate under more than one CIDR = prefix that a site must be able to = operate under more than one CIDR prefix
= [14] and/or readily change its CIDR = prefix. Unfortunately, IPv4 was = [15] and/or readily change its CIDR = prefix. Unfortunately, IPv4 was
= not designed to facilitate either of these maneuvers. However, if = a not designed to facilitate either = of these maneuvers. However, if a
= site is connected to its ISPs via NAT boxes, only those boxes need = to site is connected to its ISPs = via NAT boxes, only those boxes need to
= deal with multihoming and renumbering issues. deal with multihoming and renumbering issues.
= Similarly, if two enterprise IPv4 networks need to be merged = and Similarly, if two enterprise = IPv4 networks need to be merged and
= RFC1918 addresses are used, there is a high probability of = address RFC1918 addresses are used, = there is a high probability of address
= overlaps. In those situations it may well be that installing a = NAT overlaps. In those situations = it may well be that installing a NAT
= box between them will avoid the need to renumber one or both. = For box between them will avoid the = need to renumber one or both. For
= any enterprise, this can be a short term financial saving, and = allow any enterprise, this can be a = short term financial saving, and allow
= more time to renumber the network components. The long term = solution more time to renumber the = network components. The long term solution
= is a single network without usage of NAT to avoid the ongoing = is a single network without usage of NAT to = avoid the ongoing
= operational complexity of overlapping addresses. operational complexity of overlapping = addresses.
= The addition of an extra NAT as a solution may be sufficient for = some The addition of an extra NAT = as a solution may be sufficient for some
= networks; however when the merging networks were already using = networks; however when the merging networks = were already using
= address translation it will create huge problems due to = address translation it will create huge = problems due to
= administrative difficulties of overlapping address speaces in the = administrative difficulties of overlapping address spaces in = the
= merged networks. merged = networks.
3. = Description of the IPv6 Tools 3. = Description of the IPv6 Tools
= This section describes several features that can be used as part = of This section describes several = features that can be used as part of
= the NAP solution to emulate the = protection features associated with = the NAP solution to replace the = protection features associated with
= IPv4 NAT. IPv4 NAT.
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.
=
3.1. Privacy Addresses (RFC 3041) 3.1. Privacy Addresses (RFC 3041)
= There are situations where it is desirable to prevent device = There are situations where it is desirable = to prevent device
= profiling, for example by web sites that are accessed from = the profiling, for example by web = sites that are accessed from the device
= device; IPv6 privacy addresses were = defined to provide that as it moves around the Internet. IPv6 = privacy addresses were defined
= capability. IPv6 addresses consist of a routing prefix, = subnet-id to provide that = capability. IPv6 addresses consist of a routing
= part (SID) and an interface identifier part (IID). For interfaces prefix, subnet-id part (SID) and an interface = identifier part (IID).
that contain embedded = IEEE Link Identifiers the interface identifier = As originally defined, IPv6 stateless address = auto-configuration
is typically derived from = it, though this practice facilitates (SLAAC) will typically embed = the IEEE Link Identifier of = the
= tracking and profiling of a device as it moves = around the Internet. = interface as the IID = part, though this practice facilitates tracking
= RFC 3041 describes an extension to IPv6 = stateless address and = profiling of a device through the consistent IID. RFC 3041 [7]
autoconfiguration (SLAAC) for = interfaces [7]. Use of the privacy describes an extension to SLAAC to enhance device privacy. Use of
= address extension causes nodes to generate global-scope = addresses the privacy address = extension causes nodes to generate global-scope
= from interface identifiers that change over time, even in cases where addresses from interface identifiers that change = over time,
the interface contains an = embedded IEEE link identifier. Changing consistent with system = administrator policy. Changing the interface
= the interface identifier (thus the global-scope addresses = generated identifier (thus the = global-scope addresses generated from it) over
= from it) over time makes it more difficult for eavesdroppers = and time makes it more difficult = for eavesdroppers and other information
= other information collectors to identify when addresses used = in collectors to identify when = addresses used in different transactions
= different transactions actually correspond to the same node. = A actually correspond to the same = node. A relatively short valid
= relatively short valid lifetime for the privacy address also has = the lifetime for the privacy = address also has the side effect of reducing
= side effect of reducing the attack profile of a device, as it is = not the attack profile of a = device, as it is not directly attackable once
= directly attackable once it stops answering at the temporary = use it stops answering at the = temporary use address.
= address.
= While the primary implementation and source of randomized RFC = 3041 While the primary = implementation and source of randomized RFC 3041
= addresses is expected to be from end-systems running = stateless addresses is expected to = be from end-systems running stateless auto-
= autoconfiguration, there is nothing that = prevents a DHCP server from configuration, there is nothing that prevents = a DHCP server from
= running the RFC 3041 algorithm for any new IEEE identifier it hears, = running the RFC 3041 algorithm for any new IEEE identifier it hears
= then remembering that for future queries. This would allow = using in a = request, then remembering that for future queries. This = would
= them in DNS for registered services since the assumption of a = server allow using them in DNS for = registered services since the assumption
= based deployment would be a persistent value that minimizes = DNS of a DHCP server based deployment would be a = persistent value that
= churn. A DHCP based deployment would also allow for local policy = to minimizes DNS churn. A DHCP = based deployment would also allow for
= periodically change the entire collection of end device = addresses local policy to = periodically change the entire collection of end
= while maintaining some degree of central knowledge and control = over device addresses while = maintaining some degree of central knowledge
= which addresses should be in use at any point in time. = and control over which addresses should be = in use at any point in
time.
= Randomizing the IID, as defined in RFC 3041, only precludes = tracking Randomizing the IID, as = defined in RFC 3041, is effectively a = sparse
= of the lower 64 bits of the IPv6 address. Masking of the subnet = ID = allocation technique which only precludes tracking of the lower = 64
= will require additional approaches as discussed below in 3.4. = bits of the IPv6 address. Masking of the = subnet ID will require
= Additional considerations are discussed in [17]. = additional approaches as discussed below in 3.4. Additional
considerations = are discussed in [18].
3.2. Unique Local Addresses 3.2. Unique Local Addresses
= Local network and application services = stability during periods of Achieving the goal of autonomy, that many perceive as a = value of NAT,
= intermittent connectivity between one or more providers requires is required for local = network and application services stability
address management = autonomy. Such autonomy in a single routing during periods of intermittent connectivity or moving between one or
= prefix environment would lead to massive expansion of the = global more providers. Such autonomy in a single routing = prefix environment
= routing tables, so IPv6 provides for = simultaneous use of multiple would = lead to massive expansion of the global routing tables (as seen
= prefixes. The Unique Local Address prefix (ULA) [13] has been set in IPv4), so IPv6 = provides for simultaneous use of multiple prefixes.
= aside for use in local communications. The ULA address prefix = for The Unique Local Address = prefix (ULA) [14] has been set aside for = use
= any network is routable over a locally defined collection of = routers. in local communications. = The ULA address prefix for any network is
= These prefixes are not intended to be routed on the public = global routable over a locally = defined collection of routers. These
= Internet; large scale inter-domain = distribution of routes to ULA = prefixes are not intended to be routed on = the public global Internet
= prefixes would have a negative impact on global route = aggregation. = as large scale inter-domain distribution of routes for ULA prefixes
would have a = negative impact on global route aggregation.
= ULAs have the following characteristics: ULAs have the following characteristics:
= o Globally unique prefix = o For all practical = purposes a globally unique prefix
= * Allows networks to be combined or privately = interconnected * Allows = networks to be combined or privately interconnected
= without creating any address = conflicts or requiring renumbering = without creating address conflicts or requiring renumbering = of
= of interfaces using these prefixes interfaces using these prefixes
= * If accidentally leaked outside of a network via routing or = DNS, * If accidentally leaked = outside of a network via routing or DNS,
= it is highly unlikely that there will be a conflict with = any it is highly unlikely = that there will be a conflict with any
= other addresses other = addresses
= o ISP independent and can be used for communications inside of = a o ISP independent and can be = used for communications inside of a
= network without having any permanent or intermittent = Internet network without having = any permanent or only intermittent = Internet
= connectivity = connectivity
= o Well-known prefix to allow for easy filtering at network = o Well-known prefix to allow for easy = filtering at network
= boundaries preventing leakage of local routes and packets. = boundaries preventing leakage of local = routes and packets.
= o In practice, applications may treat these addresses like = global o In practice, applications = may treat these addresses like global
= scoped addresses but address selection algorithms need to = scoped addresses but address selection = algorithms may need to
= distinguish between ULAs and ordinary global scope unicast = distinguish between ULAs and ordinary = global scope unicast
= addresses. Mixing the two kinds of = addresses is likely to lead to = addresses to = assure stability. The policy table defined in [10]
= undeliverable packets. = is one way to = bias this selection, by giving higher preference to
FC00::/7 over 2001::/3. Mixing the two = kinds of addresses may
lead to = undeliverable packets during times of = instability, but
that mixing is not likely to happen when the = rules of RFC 3484 are
followed.
3.3. DHCPv6 Prefix Delegation 3.3. DHCPv6 Prefix Delegation
= The Prefix Delegation (DHCP-PD) options [11] provide a mechanism = for One of = the functions of a simple gateway is managing the local = use
= automated delegation of IPv6 prefixes using the Dynamic Host = address = range. The Prefix Delegation (DHCP-PD) options [11] = provide
= Configuration Protocol (DHCP) [9]. This mechanism (DHCP-PD) = is a mechanism for automated = delegation of IPv6 prefixes using the
= intended for delegating a long-lived prefix from a delegating = router Dynamic Host Configuration = Protocol (DHCP) [9]. This mechanism
= (incorporating a DHCPv6 server) to a = requesting router, possibly = (DHCP-PD) is intended for delegating a long-lived prefix from a
= across an administrative boundary, where the delegating router = does delegating router (possibly incorporating a DHCPv6 server) to = a
= not require knowledge about the topology of the links in the = network requesting router, = possibly across an administrative boundary, where
= to which the prefixes will be assigned. the delegating router does not require knowledge = about the topology
of the links in = the network to which the prefixes will be assigned.
3.4. Untraceable IPv6 Addresses 3.4. Untraceable IPv6 Addresses
= 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. = This correlation could be done by
generating IPv6 host route = entries or by utilizing an indirection
device such as a Mobile IPv6 = Home Agent.
= =
= The main goal of untraceable IPv6 addresses is to create an = The main goal of untraceable IPv6 addresses = is to create an
= apparently amorphous network infrastructure as seen from = external apparently amorphous = network infrastructure as seen from external
= networks to protect the local infrastructure from malicious = outside networks to protect the = local infrastructure from malicious outside
= influences and from mapping of any correlation between the = network influences and from mapping = of any correlation between the network
= activities of multiple devices from external networks. When = using activities of multiple = devices from external networks. When using
= untraceable IPv6 addresses, it could be that two apparently = untraceable IPv6 addresses, it could be that = two apparently
= sequential addresses are allocated to devices on very different = parts sequential addresses are = allocated to devices on very different parts
= of the local network instead of belonging to devices adjacent to = each of the local network instead = of belonging to devices adjacent to each
= other on the same subnet. other on = the same subnet.
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.
=
4. = Using IPv6 Technology to Provide the Market Perceived Benefits = of 4. Using IPv6 Technology to = Provide the Market Perceived Benefits of
= NAT NAT
= The facilities in IPv6 described in Section 3 can be used to = provide The facilities in IPv6 = described in Section 3 can be used to provide
= the protection perceived to be associated with IPv4 NAT. This = the protection perceived to be associated = with IPv4 NAT. This
= section gives some examples of how IPv6 can be used securely. = section gives some examples of how IPv6 can = be used securely.
4.1. Simple Gateway between Internet and Internal = Network 4.1. Simple Gateway between = Internet and Internal Network
= As a simple gateway, the device manages both packet routing and = local As a simple gateway, the = device manages both packet routing and local
= address management. A basic IPv6 router could have a default address management. A basic IPv6 router should have a default
= configuration to advertise inside the site a locally generated = random configuration to advertise = inside the site a locally generated random
= ULA prefix, independently from the state of any external = ULA prefix, independently from the state of = any external
= connectivity. This would allow local nodes to communicate = amongst connectivity. This would = allow local nodes to communicate amongst
= themselves prior to establishing a = global connection. If the network = themselves independent of the state of a = global connection. If the
= happened to concatenate with another local network, this is highly network happened to concatenate with another local = network, the
= unlikely to result in address collisions. A = more secure network randomness in ULA creation is highly unlikely = to result in address
environment can be = established by having the referenced ULA addresses = collisions.
statically configured on the = network devices as this decreases the
dynamic aspects of the = network, however the operational overhead is
increased. =
= With external connectivity the simple gateway could also use DHCP-PD With external connectivity the simple gateway should use DHCP-PD to
= to acquire a routing prefix from the service provider for use = when acquire a routing prefix from = the service provider for use when
= connecting to the global Internet. End-system connections = involving connecting to the global = Internet. End-system connections involving
= other nodes on the global Internet will always use the global = IPv6 other nodes on the global = Internet will always use the global IPv6
= addresses [9] derived from this prefix = delegation. It should be = addresses derived from this prefix delegation. It should be = noted
= noted that the address selection policy table in end-systems needs to = that the address selection policy table in end-systems defined in RFC
be correctly set up so that = true global prefixes are distinguished 3484 should be configured to prefer the ULA prefix range over the
from ULAs and will be = used for the source = address in preference when DHCP-PD prefix range = when the goal is to = keep local communications
= the destination is not a ULA. stable during periods of = transient external connectivity.
= In the very simple case there is no explicit routing protocol and = a In the very simple case there is = no explicit routing protocol on
= single default route is used out to the global Internet. A = slightly = either side of the gateway, and a single default route is = used
= more complex case might involve local routing protocols, but with = the internally pointing out to the global Internet. = A slightly more
= entire local network sharing a common global prefix there would = still complex case might involve = local internal routing protocols, but = with
= not be a need for an external routing protocol as a default route the entire local network sharing a common global = prefix there would
= would continue to be consistent with the = connectivity. still not be a need for an external routing protocol = as the service
provider could install a route for the prefix delegated via DHCP-PD
pointing toward the connecting link.
4.2. IPv6 and Simple Security 4.2. IPv6 and Simple Security
= The vulnerability of an IPv6 host is similar to that of an IPv4 = host The vulnerability of an IPv6 = host is similar to that of an IPv4 host
= directly connected towards the Internet. The use of firewall = and directly connected towards the = Internet. The use of firewall and
= Intrusion Detection Systems (IDS) is recommended. A proxy may be Intrusion Detection Systems (IDS) is recommended for those that want
boundary protection in addition to host = defenses. A proxy may be
= used for certain applications, but with the caveat that the end = to used for certain applications, = but with the caveat that the end to
= end transparancy is broken. However, = with IPv6, the following end = transparency is broken. However, with = IPv6, the following
= protections are available without the use of NAT while = maintaining protections are = available without the use of NAT while maintaining
= end-to-end reachability: end-to-end = reachability:
= 1. Short lifetimes on privacy extension suffixes reduce the = attack 1. Short lifetimes on = privacy extension suffixes reduce the attack
= profile since the node will not respond to the address once the = profile since the node will not respond to the address once its
address is no longer = valid. = lifetime becomes invalid.
= 2. IPsec is a mandatory service for IPv6 implementations. = IPsec 2. IPsec is a mandatory = service for IPv6 implementations. IPsec
= functions to prevent session hijacking, prevent content = functions to authenticate the correspondent, prevent = session
= tampering, and optionally masks the packet contents. While = IPsec hijacking, prevent = content tampering, and optionally masks the
= might be available in IPv4 implementations, deployment in NAT = packet contents. While IPsec might be = available in IPv4
implementations and works the same way, = deployment in NAT
= environments either breaks the protocol or requires complex = environments either breaks the protocol = or requires complex
= helper services with limited functionality or efficiency. = helper services with limited = functionality or efficiency.
= 3. The size of the address space of a typical subnet (64 bits = of 3. The size of the address = space of a typical subnet (64 bits of
= IID) will make an effective network = ping sweep and resulting IID) will make a complete = subnet ping sweep virtually impossible
port-scan = virtually impossible due to the number of possible = due to the potential number of = combinations available. Reducing
= combinations available, provided = that IIDs are essentially the security threat of port scans on identified = nodes requires
= randomly distributed across the available space. This protection sparse distribution = within the subnet to minimize the probability
= is nullified if the attacker has no = access to a local connection. = of scans finding = adjacent nodes. Provided that IIDs are
= If an attacker has local access then he could use ND [3] = and essentially randomly = distributed across the available space,
= ping6 to ff02::1 to detect local neighbors. = (Of course, a address scanning based attacks will effectively = fail. This
= locally connected attacker has many scanning options with IPv4 = as protection exists if the attacker has no direct access to the
= well.) It is recommended for site = administrators to take [18] specific subnet and = therefore is trying to scan it remotely. If
into consideration to = achieve the expected goal. This protection an attacker has local access then he could use = ND [3] and ping6
= will also be nullified if IIDs are = configured in a group near the = to the = link-scope multicast ff02::1 to detect the = IEEE based
= start of the IID space. address of local = neighbors, then apply the global prefix to = those
to simplify its search (of course, a = locally connected attacker
has many = scanning options with IPv4 as well). This = scanning
protection = will be nullified if IIDs are configured in any
structured groupings within the IID = space.
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. The intention = of topology
probing is to identify a selection of the available hosts inside an
enterprise. This mostly starts with a ping-sweep. = Since the IPv6
subnets are 64 bits worth of address space, this means that an
attacker has to send out a simply unrealistic number = of pings to map
the network, and virus/worm propagation will be thwarted in = the
process. At full-rate full-duplex 40Gbps (400 times = the typical
100Mbps LAN, and 13,000 times the typical DSL/Cable = access link) it
takes over 5000 years to scan the entirety of a = single 64 bit subnet.
= IPv4 NAT was not developed as a security mechanism. Despite = IPv4 NAT was not developed as a security = mechanism. Despite
= marketing messages to the contrary it is not a security = mechanism, marketing messages to = the contrary it is not a security mechanism,
= and hence it will offer some security holes while many people = assume 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 their network is secure due to = the usage of NAT. IPv6 security best
= practices will avoid this kind of illusory security but can only do = practices will avoid this kind of illusory security but can only
this if correctly = configured firewalls and IDS systems are used at address the same = threats if correctly configured firewalls and IDS
= the perimeter where some IPv4 networks have = relied on NATs. 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.
= To implement simple security for IPv6 in, for example, a DSL = To implement simple security for IPv6 in, = for example, a DSL
= connected home network, the DSL broadband gateway/router should = be connected home network, the DSL = broadband gateway/router should be
= equipped with stateful firewall capabilities. These should provide = a equipped with stateful firewall = capabilities. These should provide a
= default configuration which provides a minimum = set of connectivity default = configuration where incoming traffic is limited to return
for users in the home network = (e.g., just to external HTTP servers) traffic resulting from outgoing packets (sometimes = known as
with incoming traffic = limited to return traffic resulting from reflective session state). = There should also be an easy interface
= outgoing packets (sometimes known as reflective session state) with = which allows users to create inbound = 'pinholes' for specific purposes
= an easy interface which allows users to create additional 'pinholes' such as online-gaming. = Another consideration would be the capability
= for specific purposes. for service provider mediated = pinhole management where things like
voice call signaling could dynamically establish = pinholes based on
predefined authentication rules.
= Administrators and the designers of configuration interfaces = for Administrators and the = designers of configuration interfaces for
= simple IPv6 Firewalls need to provide a = means of documenting the simple = IPv6 firewalls need to provide a means of = documenting the
= security caveats that arise from a given set configuration rules = so security caveats that arise from = a given set configuration rules so
= that users (who are normally oblivious to such things) can be = made that users (who are normally = oblivious to such things) can be made
= aware of the risks. As rules are improved iteratively, the goal = will aware of the risks. As rules = are improved iteratively, the goal will
= be to make use of the IPv6 Internet more secure for oblivious users. be to make use of the IPv6 Internet more secure = without increasing
the perceived = complexity for users who just want = to accomplish a
Assuming the network = administrator is aware of [18] the increased = task.
size of the IPv6 address will = make topology probing much harder, and
almost impossible for = IPv6 devices. The intention of = topology
probing is to identify a = selection of the available hosts inside an
enterprise. This mostly = starts with a ping-sweep. Since the IPv6
subnets are 64 bits worth of = address space, this means that an
attacker has to send out a = simply unrealistic number of pings to map
the network, and virus/worm = propagation will be thwarted in the
process. At full rate 40Gbps = (400 times the typical 100Mbps LAN, and
13,000 times the typical = DSL/Cable access link) it takes over 5000
years to scan a single 64 bit = space.
4.3. User/Application Tracking 4.3. User/Application Tracking
= IPv6 enables the collection of information about data flows. Due = to IPv6 enables the collection of = information about data flows. Due to
= the fact that all addresses used for Internet and = intra-/inter-site the fact that all = addresses used for Internet and intra-/inter-site
= communication are unique, it is possible for an enterprise or ISP = to communication are unique, it is = possible for an enterprise or ISP to
= get very detailed information on any communication exchange = between get very detailed = information on any communication exchange between
= two or more devices. This enhances the capability of data-flow = two or more devices. This enhances the = capability of data-flow
= tracking for security audits compared with IPv4 NAT, because in = IPv6 tracking for security audits = compared with IPv4 NAT, because in IPv6
= a flow between a sender and receiver will always be uniquely = a flow between a sender and receiver will = always be uniquely
= identified due to the unique IPv6 source and destination = addresses. identified due to the = unique IPv6 source and destination addresses.
At the same time, this tracking is per address. In = environments
where the goal is tracking back to the user, = additional external
information will be necessary correlating a user = with an address. In
the case of short lifetime privacy address usage, = this external
information will need to be based on more stable = information such as
the layer 2 media address.
=
4.4. Privacy and Topology Hiding using IPv6 = 4.4. Privacy and Topology Hiding using = IPv6
= Partial host privacy is achieved in IPv6 using pseudo-random = privacy Partial host privacy is = achieved in IPv6 using pseudo-random privacy
= addresses [RFC 3041] which are generated as required, so that a = addresses [RFC 3041] which are generated as = required, so that a
= session can use an address that is valid only for a limited = time. session can use an address = that is valid only for a limited time.
= Exactly as with IPv4 NAT, this only = allows such a session to be This only allows such a session to be traced = back to the subnet that
= traced back to the subnet that originates it, but not immediately = to originates it, but not = immediately to the actual host, where IPv4 = NAT
= the actual host. is only traceable to the most = public NAT interface.
= Due to the large IPv6 address space available there is plenty = of Due to the large IPv6 address = space available there is plenty of
= freedom to randomize subnet allocations. By doing this, it is = freedom to randomize subnet allocations. By = doing this, it is
= possible to reduce the correlation between a subnet and its = location. possible to reduce the = correlation between a subnet and its location.
= When doing both subnet and IID randomization [RFC 3041] a = casual When doing both subnet and = IID randomization [RFC 3041] a casual
= snooper won't be able to deduce much about the networks = topology. snooper won't be able to = deduce much about the networks topology.
= The obtaining of a single address will tell the snooper very = little The obtaining of a single = address will tell the snooper very little
= about other addresses. This is different from IPv4 where = address about other addresses. = This is different from IPv4 where address
= space limitations cause this to be not true. In most usage = cases space limitations cause this = to be not true. In most usage cases
= this concept should be sufficient for address privacy and = topology this concept should be = sufficient for address privacy and topology
= hiding. hiding, with the cost being a = more complex internal routing
configuration.
= In the case where a network administrator wishes to fully conceal the = As discussed in Section 3.1, there are multiple = parts to the IPv6
= internal IPv6 topology, and the majority of its host computer address, and different = techniques to manage privacy for each which
= addresses, a possible option is to run = all internal traffic using may be combined to protect the entire = address. In the case where a
= Unique Local Addresses (ULA) since such packets = can by definition network = administrator wishes to fully isolate the = internal IPv6
= never exit the site. For hosts that do = in fact need to generate topology, and the majority of its internal use addresses, one option
external traffic, by = using multiple IPv6 addresses (ULAs and = one or is to run all internal = traffic using Unique Local Addresses (ULA).
= more global addresses), it will be possible to = hide and mask some or By definition this = prefix block is not to be advertised into the
= all of the internal network. As = discussed in Section 3.1, there = are = public routing system, so without a routing path external = traffic
multiple parts to the = IPv6 address, and different techniques = to = will never reach the site. For = the set of hosts that do in fact = need
manage privacy for = each. to interact externally, by using multiple IPv6 = prefixes (ULAs and one
or more global = addresses) all of the internal nodes that do not need
external connectivity, and the internally used = addresses of those
that do will be masked from the outside. The policy = table defined in
[10] provides a mechanism to bias the selection = process when multiple
prefixes are in use such that the ULA would be = preferred when the
correspondent is also local.
= There are two possible scenarios for the = extreme situation when a There are = other scenarios for the extreme situation = when a network
= network manager also wishes to fully conceal the internal = IPv6 manager also wishes to fully = conceal the internal IPv6 topology. In
= topology. = these cases the goal in replacing the IPv4 NAT approach is to = make
all of the topology hidden nodes appear from the = outside to logically
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 = o One approach = uses explicit host routes in the IGP = to remove the
= between location and IPv6 address. = This solution does however = external correlation between physical topology attachment point
= show severe scalability issues. = and end-to-end IPv6 address. In the figure below the hosts would
o The other technology to fully hide the internal = topology would be be allocated prefixes from = one or more logical subnets, and would
to use a tunneling = mechanism. Mobile IPv6 without route inject host routes to = internally identify their real attachment
= optimization is one example. In this = example the public = facing = point. This solution does however show severe scalability = issues
= addresses are indirected via an edge Home Agent = (HA). This and requires hosts to participate in the IGP, as = well as having
= indirection method truly masks the internal topology as all nodes the firewall block all = external to internal traceroute for the
= with global access appear to share a common = prefix. The downside = logical = subnet. The specific limitations are = dependent on the IGP
= of using this method is that it makes = usage of middleware like a protocol, the physical topology, and the = stability of the system.
= Home Agent (HA). In any case the approach = should be limited to uses with
substantially fewer than the maximum number of = routes that the IGP
can support (generally between 5,000 and 50,000 = total entries
including subnet routes).
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
deployment model the application perceived addresses of the nodes
are routed via the = edge HA. This indirection method truly = masks
the internal = topology, as from = outside the local network all nodes
with global = access appear to share the prefix of one or = more
logical subnets attached to the HA rather than = their real
attachment point. While turning off all binding = updates would
appear to be necessary to prevent leakage of = topology information,
that approach would also force all internal = traffic using the home
address to route via the HA tunnel, which may be = undesirable. A
more efficient method would be to allow internal = route
optimizations while dropping outbound binding = updates at the
firewall. Another approach for the internal = routes would be to
use the policy table of RFC 3484 to bias a = ULA prefix as preferred
internally, leaving the Home Address external for = use. 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.
o Another method (where the layer 2 topology = allows) uses a virtual
lan approach to logically attach the devices to = one or more
subnets on the edge router. The downsides of = this approach is
that all internal traffic would be directed over = sub-optimal paths
via the edge router, as well as the complexity of = managing a
distributed logical lan.
Internet
|
\
|
= +------------------+
| Simple Gateway = |-+-+-+-+-+-+-+-+--
| or Home Agent | Logical = subnets
| = |-+-+-+-+-+-+-+-+--
+------------------+ for = topology
| hidden = nodes
|
Real internal = -------------+-
topology | = |
| = -+----------
-----------+--------+
|
|
|
4.5. Independent Control of Addressing in a Private = Network 4.5. Independent Control of = Addressing in a Private Network
= IPv6 provides for autonomy in local use addresses through ULAs. = At IPv6 provides for autonomy in = local use addresses through ULAs. At
= the same time IPv6 simplifies simultaneous use of multiple = addresses the same time IPv6 = simplifies simultaneous use of multiple addresses
= per interface so that an IPv6 NAT is not required between the ULA = and per interface so that an IPv6 = NAT is not required between the ULA and
= the public Internet. Nodes that need = access to the public Internet the = public Internet because nodes that need = access to the public
= may have a ULA for local use, and will = have a global use address Internet = will have a global use address as well. When = using IPv6,
= because the global use IPv6 address space is not a scarce resource the need to ask for = more address space will become far less = likely
like the global use IPv4 space. While global IPv6 = allocation policy due to the increased = size of the subnets, along with an allocation
= is managed through the Regional Internet Registries, it is = expected = policy that recognizes table fragmentation is also an = important
= that they will continue with derivatives of [RFC 3177] for the consideration. While = global IPv6 allocation policy is managed
= foreseeable future. through the Regional Internet Registries, it is = expected that they
will continue with derivatives of [8] for the foreseeable future so
When using IPv6, the = need to ask for more address space will = become the number of subnet prefixes = available to an organization should = not
far less likely due to the = increased size of the subnets. = These = be a limitation which would create an artificial demand for = NAT.
subnets typically allow 2^64 = addresses per subnet and an enterprise
will typically receive = a /48 which allows = segmentation into at least
2^16 different = subnets.
= The ongoing subnet size maintenance may become simpler when = IPv6 Ongoing subnet address maintenance may become simpler when = IPv6
= technology is utilised. If IPv4 address = space is optimised one has = technology is utilized. Under IPv4 address space policy restrictions
= to look periodically into the number of hosts on a segment and = the each = subnet must be optimized, so one has to look periodically = into
= subnet size allocated to the segment; an = enterprise today may have a the = number of hosts on a segment and the subnet size allocated to = the
= mix of /28 - /23 size subnets for = example, and may shrink/grow these segment and rebalance. For = example an enterprise today may have a
= as their network user base changes. For IPv6 all subnets have = /64 mix of IPv4 /28 - /23 size subnets, and may shrink/grow these as
= prefixes. their network user base changes. For IPv6 all = subnets have /64
prefixes which will reduce the operational and = configuration
overhead.
4.6. Global Address Pool Conservation 4.6. Global Address Pool Conservation
= IPv6 provides sufficient space to completely avoid the need for = IPv6 provides sufficient space to completely = avoid the need for
= overlapping address space, = overlapping address space. Since allocations in IPv6 are based = on
= 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) = total = subnets rather than hosts a reasonable way to look at the pool = is
possible addresses. = As previously discussed, the serious 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]. As previously discussed, = the serious
= disadvantages of ambiguous address space have been well = documented, disadvantages of = ambiguous address space have been well documented,
= and with sufficient space there is no need to continue the = and with sufficient space there is no need = to continue the
= increasingly aggressive conservation practices that are = necessary increasingly aggressive = conservation practices that are necessary
= with IPv4. While IPv6 allocation policies and ISP business = practice with IPv4. While IPv6 = allocation policies and ISP business practice
= will continue to evolve, the recommendations in RFC 3177 are based = on will continue to evolve, the = recommendations in RFC 3177 are based on
= the technical potential of the vast IPv6 address space. That = the technical potential of the vast IPv6 = address space. That
= document demonstrates that there is no resource limitation which = will document demonstrates that = there is no resource limitation which will
= require the adoption of the IPv4 workaround of ambiguous space = behind require the adoption of the = IPv4 workaround of ambiguous space behind
= a NAT. As an example of the direct contrast, many expansion = oriented a NAT. As an example of = the direct contrast, many expansion oriented
= IPv6 deployment scenarios result in multiple IPv6 addresses per = IPv6 deployment scenarios result in multiple = IPv6 addresses per
= device, as opposed to the constriction of IPv4 scenarios where = device, as opposed to the constriction of = IPv4 scenarios where
= multiple devices are forced to share a scarce global address. = multiple devices are forced to share a scarce global address through
a NAT.
4.7. Multihoming and Renumbering 4.7. Multihoming and Renumbering
= Multihoming and renumbering remain technically challenging with = IPv6 Multihoming and renumbering = remain technically challenging with IPv6
= (see the Gap Analysis below). However, IPv6 was designed to = allow (see the Gap Analysis below). = However, IPv6 was designed to allow
= sites and hosts to run with several simultaneous CIDR-like prefixes sites and hosts to run with several simultaneous = CIDR allocated
= and thus with several simultaneous ISPs. An address = selection = prefixes, and thus with several simultaneous ISPs. An = address
= mechanism [10] is specified so that hosts will behave = consistently selection mechanism = [10] is specified so that hosts will behave
= when several addresses are simultaneously valid. The = fundamental consistently when = several addresses are simultaneously valid. The
= difficulty that IPv4 has in this regard = therefore does not apply to = fundamental difficulty that IPv4 has in regard to = multiple addresses
= IPv6. IPv6 sites can and do run today with multiple ISPs active, = and therefore does not apply to = IPv6. IPv6 sites can and do run today
= the processes for adding and removing active prefixes at a site have = with multiple ISPs active, and the = processes for adding, removing,
= been documented [12] and [19]. and = renumbering active prefixes at a site have = been documented in
[13] and [20].
= The IPv6 address space allocated by the ISP will be dependent = upon The IPv6 address space = allocated by the ISP will be dependent upon
= the connecting Service provider. This may result in a renumbering the connecting Service provider. This will likely result in a
= effort if the network changes from Service Provider. When changing = renumbering effort when the network changes between service
= ISPs or ISPs readjusting their addressing pool, DHCP-PD [11] can = be = providers. When changing ISPs or ISPs readjusting their = addressing
= used as an almost zero-touch external = mechanism for prefix change in = pool, DHCP-PD [11] can be used as an almost zero- = touch external
= conjunction with a ULA prefix for internal connection = stability. mechanism for prefix = change in conjunction with a ULA prefix for
= With appropriate management of the lifetime values and overlap of = the internal connection stability. = With appropriate management of the
= external prefixes, a smooth make-before-break transition is = possible lifetime values and = overlap of the external prefixes, a smooth make-
= as existing communications will continue on the old prefix as long = as = before-break transition is possible as existing communications = will
= it remains valid, while any new communications will use the = new continue on the old prefix as = long as it remains valid, while any new
= prefix. communications will use = the new prefix.
5. = Case Studies 5. Case Studies
= In presenting these case studies we have chosen to consider = In presenting these case studies we have = chosen to consider
= categories of network divided first according to their function = categories of network divided first = according to their function
= either as carrier/ISP networks or end user (such as enterprise) = either as carrier/ISP networks or end user = (such as enterprise)
= networks with the latter category broken down according to the = number networks with the latter = category broken down according to the number
= of connected end hosts. For each of = these category of networks we = of connected end hosts. For each category of networks we can = use
= can use IPv6 Network Architecture Protection to achieve a secure = and IPv6 Network Architecture = Protection to achieve a secure and flexible
= flexible infrastructure, which provides an enhanced network = infrastructure, which provides an enhanced = network functionality in
= functionality in comparison with the usage of address = translation. comparison with the = usage of address translation.
= o Medium/Large Private Networks (typically >10 connections) = o Medium/Large Private Networks (typically = >10 connections)
= o Small Private Networks (typically 1 to 10 connections) = o Small Private Networks (typically 1 to 10 = connections)
= o Single User Connection (typically 1 connection) o Single User Connection (typically 1 = connection)
= o ISP/Carrier Customer Networks o = ISP/Carrier Customer Networks
5.1. Medium/large private networks 5.1. Medium/large private networks
= The majority of private enterprise = networks fall into this category. = The majority of private enterprise, academic, = research, or government
= Many of these networks have one or more exit points to the = Internet. networks fall into this = category. Many of these networks have one or
= Though these organizations have sufficient resources to = acquire more exit points to the = Internet. Though these organizations have
= addressing independence when using IPv4 there are several reasons = why sufficient resources to = acquire addressing independence when using
= they might choose to use NAT in such a network. For the ISP there = is IPv4 there are several reasons = why they might choose to use NAT in
= no need to import the IPv4 address range from the remote end- such = a network. For the ISP there is no need to import the IPv4
customer, which = facilitates IPv4 route summarization. The customer address range from the remote end-customer, which facilitates IPv4
= can use a larger IPv4 address range (probably with less- = route summarization. The customer can use a larger IPv4 address
administrative = overhead) by the use of RFC 1918 and NAT. The range (probably with less-administrative overhead) by the use of = RFC
= customer also reduces the overhead in changing to a new ISP, = because 1918 and NAT. The = customer also reduces the overhead in changing to
= the addresses assigned to devices behind the NAT do not need to = be a new ISP, because the = addresses assigned to devices behind the NAT
= changed when the customer is assigned a different address by a = new do not need to be changed when = the customer is assigned a different
= ISP. By using address translation one avoids the need for network address by a new ISP. By using address translation = in IPv4 one
= renumbering. Finally, the customer can provide privacy for its = hosts avoids the expensive process of network renumbering. = Finally, the
= and the topology of its internal network if the internal = addresses customer can provide = privacy for its hosts and the topology of its
= are mapped through NAT. internal = network if the internal addresses are mapped through NAT.
= It is expected that there will be enough IPv6 addresses available = for It is expected that there will = be enough IPv6 addresses available for
= all networks and appliances for the foreseeable future. The = basic all networks and appliances = for the foreseeable future. The basic
= IPv6 address range an ISP allocates for a private network is = large IPv6 address range an ISP = allocates for a private network is large
= enough (currently /48) for most of the medium and large = enterprises, enough (currently /48) = for most of the medium and large enterprises,
= while for the very large private enterprise networks = address-ranges while for the very = large private enterprise networks address-ranges
= can be concatenated. A single /48 allocation = provides an enterprise can = be concatenated. The goal of this assignment mechanism is to
network with 65536 different = /64 prefixes. decrease the = total amount of entries in the public = Internet routing
table. A single /48 = allocation provides an enterprise network = with
The summarization benefit for = the ISP results from the IPv6 65536 different /64 subnet = prefixes.
allocation rules. This means = that the ISP will provide the
enterprise with an IPv6 = address-range (typically one or multiple
range(s) of '/48') from its = RIR assigned IPv6 address-space. The
= goal of this assignment mechanism is to decrease the total amount = of
= entries in the internet routing table. = If the ISP adopts appropriate =
policies there is high = probability that an enterprise requiring
additional space could = acquire an adjacent address block.
= To mask the identity of a user on a network of this type, the = usage To mask the identity of a = user on a network of this type, the usage
= of IPv6 privacy extensions may be advised. This technique is = useful of IPv6 privacy extensions = may be advised. This technique is useful
= when an external element wants to track and collect all = information when an external = element wants to track and collect all information
= sent and received by a certain host with known IPv6 address. = Privacy sent and received by a = certain host with known IPv6 address. Privacy
= extensions add a random factor to the host part of an IPv6 = address extensions add a random = time-limited factor to the host part of = an
= and will make it very hard for an external element to keep = IPv6 address and will make it very hard for = an external element to
= correlating the IPv6 address to a host on the inside network. = The keep correlating the IPv6 = address to a specific host on the = inside
= usage of IPv6 privacy extensions does not mask the internal = network network. The usage of = IPv6 privacy extensions does not mask the
= structure of an enterprise network. internal network structure of an enterprise = network.
= If there is need to mask the internal = structure towards the external = When there is need to mask the internal = structure towards the
= IPv6 internet, then some form of = 'untraceable' addresses may be used. = external IPv6 Internet, then some form = of 'untraceable' addresses may
= These addresses will be derived from a local = pool, and may be be used. = These addresses will appear to exist at the = external edge
= assigned to those hosts for which topology masking is required = or of the = network, and may be assigned to those hosts for which = topology
= which want to reach the IPv6 Internet or other external = networks. masking is required or = which want to reach the IPv6 Internet or other
= The technology to assign these addresses to the hosts could be = based external networks. The = technology to assign these addresses to the
= on DHCPv6. To complement the = 'Untraceable' addresses it is needed to hosts could be based on DHCPv6 or static configuration. To
= have at least awareness of the IPv6 address location when routing = an complement the 'Untraceable' = addresses it is needed to have at least
= IPv6 packet through the internal network. This could be achieved = by awareness of the IPv6 address = location when routing an IPv6 packet
= 'route-injection' in the network = infrastructure. This route- = through the internal network. This could be achieved by 'host based
route- injection' in the local network infrastructure. This = route-
= injection could be done based on /128 host-routes to each device = that injection could be done based = on /128 host-routes to each device that
= wants to connect to the Internet using an untraceable address. = This wants to connect to the = Internet using an untraceable address. This
= will provide the most dynamic masking, but will have a = scalability will provide the most = dynamic masking, but will have a scalability
= limitation, as an IGP is typically not designed to carry many = limitation, as an IGP is typically not = designed to carry many
= thousands of IPv6 prefixes. A large enterprise may have thousands = of thousands of IPv6 prefixes. A = large enterprise may have thousands of
= hosts willing to connect to the Internet. Less = flexible masking hosts = willing to connect to the Internet.
could be to have time-based = IPv6 prefixes per link or subnet. This
may reduce the amount of = route entries in the IGP by a significant
factor, but has as trade-off = that masking is time and subnet based.
= The dynamic allocation of 'Untraceable' addresses can also limit = the An = alternative for larger deployments is to leverage the = tunneling
= IPv6 access between local and external hosts to those local = hosts = aspect of MIPv6 even for non-mobile devices. With the logical = subnet
= being authorized for this capability. Dynamically allocated being allocated as attached = to the edge Home Agent, the real
'Untraceable' addresses may = also facilitate and simplify the attachment and internal = topology are masked from the outside.
connectivity to the outside = networks during renumbering, because the Dropping outbound binding = updates at the firewall is also necessary
existing IPv6 central address = pool could be swapped for the newly to avoid leaking the = attachment information.
allocated IPv6 address = pool.
Less flexible masking could be to have time-based = IPv6 prefixes per
link or subnet. This may reduce the amount of route = entries in the
IGP by a significant factor, but has as trade-off = that masking is
time and subnet based which will complicate auditing = systems. The
dynamic = allocation of 'Untraceable' addresses can also limit the IPv6
access between = local and external hosts to those local hosts being
authorized for = this capability.
= The use of permanent ULA addresses on a site provides the = benefit The use of permanent ULA = addresses on a site provides the benefit
= that even if an enterprise would change its ISP, the renumbering = will that even if an enterprise = would change its ISP, the renumbering will
= only affect those devices that have a wish to connect beyond = the only affect those devices that = have a wish to connect beyond the
= site. Internal servers and services would not change their = allocated site. Internal servers = and services would not change their allocated
= IPv6 ULA address, and the service would remain available even = during IPv6 ULA address, and the = service would remain available even during
= global address renumbering. global = address renumbering.
5.2. Small Private Networks 5.2. Small Private Networks
=
skipping to change at page 20, line = 40 skipping to = change at page 24, line 22
= blocks, or IPv4 prefixes that are static over time, due to the = larger blocks, or IPv4 prefixes = that are static over time, due to the larger
= public address pool each of those requires. public address pool each of those requires.
= As a direct response to explicit charges per public address most = of As a direct response to explicit = charges per public address most of
= this category has deployed NAPT (port demultiplexing NAT) to = minimize this category has deployed = NAPT (port demultiplexing NAT) to minimize
= the number of addresses in use. Unfortunately this also limits = the the number of addresses in use. = Unfortunately this also limits the
= Internet capability of the equipment to being mainly a receiver = of Internet capability of the = equipment to being mainly a receiver of
= Internet data (client), and makes it quite hard for the equipment = to Internet data (client), and = makes it quite hard for the equipment to
= become a world wide Internet server (i.e. HTTP, FTP, etc.) due = to become a world wide Internet = server (i.e. HTTP, FTP, etc.) due to
= the stateful operation of the NAT equipment. Even when there = is the stateful operation of the = NAT equipment. Even when there is
= sufficient technical knowledge to manage the NAT to enable a = server, sufficient technical = knowledge to manage the NAT to enable external
= only one server of any given protocol type is = possible per address, access to a server, only one server can be mapped per protocol/
= and then only when the address from the ISP is public. port-number per address, and then only when = the address from the ISP
is publicly routed. When there is an upstream NAT = providing private
address space to the ISP side of the private NAT, = additional
negotiation with the ISP will be necessary to = provide an inbound
mapping, if that is even possible.
= When deploying IPv6 NAP in this environment, there are two = approaches When deploying IPv6 NAP = in this environment, there are two approaches
= possible with respect to IPv6 addressing. possible with respect to IPv6 addressing.
= o DHCPv6 Prefix-Delegation o = DHCPv6 Prefix-Delegation
= o ISP provides a static IPv6 address-range o ISP provides a static IPv6 address-range
= For the DHCPv6-PD solution, a dynamic address allocation approach = is For the DHCPv6-PD solution, a = dynamic address allocation approach is
= chosen. By means of the enhanced DHCPv6 protocol it is possible = to chosen. By means of the = enhanced DHCPv6 protocol it is possible to
= have the ISP push down an IPv6 prefix range automatically towards = the have the ISP push down an IPv6 = prefix range automatically towards the
= small private network and populate all interfaces in that small = small private network and populate all = interfaces in that small
=
skipping to change at page 21, line = 29 skipping to = change at page 25, line 15
= While a full prefix is expected to be the primary deployment = model While a full prefix is = expected to be the primary deployment model
= there may be cases where the ISP provides a single IPv6 address = for there may be cases where the = ISP provides a single IPv6 address for
= use on a single piece of equipment (PC, PDA, etc.). This is = expected use on a single piece of = equipment (PC, PDA, etc.). This is expected
= to be rare though, because in the IPv6 world the assumption is = that to be rare though, because in = the IPv6 world the assumption is that
= there is an unrestricted availability of a large amount of = globally there is an unrestricted = availability of a large amount of globally
= routable and unique address space. If scarcity was the = motivation routable and unique = address space. If scarcity was the motivation
= with IPv4 to provide RFC 1918 addresses, in this environment the = ISP with IPv4 to provide RFC 1918 = addresses, in this environment the ISP
= will not be motivated to allocate private addresses towards the = will not be motivated to allocate private = addresses towards the
= single user connection because there are enough global = addresses single user connection = because there are enough global addresses
= available at essentially the same cost. Also if the single device available at essentially the same cost. Also it will be likely that
= wants to mask its identity to the called party or its attack = profile the single device wants to = mask its identity to the called party or
= over a short time window it will need to = enable IPv6 privacy its attack = profile over a shorter time window than the life of the
= extensions, which in turn leads to the = need for a minimum allocation ISP attachment, so it will need to enable = IPv6 privacy extensions
= of a /64 prefix rather than a single address. which in turn leads to the need for a minimum = allocation of a /64
prefix rather = than a single address.
5.3. Single User Connection 5.3. Single User Connection
= This group identifies the users which are connected via a single = IPv4 This group identifies the = users which are connected via a single IPv4
= address and use a single piece of equipment (PC, PDA, etc.). = This address and use a single piece = of equipment (PC, PDA, etc.). This
= user may get an ambiguous IPv4 address (frequently imposed by = the user may get an ambiguous IPv4 = address (frequently imposed by the
= ISP) from the service provider which is based on RFC 1918. If = ISP) from the service provider which is = based on RFC 1918. If
= ambiguous addressing is utilized, the service provider will = execute ambiguous addressing is = utilized, the service provider will execute
= NAT on the allocated IPv4 address for global Internet = connectivity. NAT on the allocated = IPv4 address for global Internet connectivity.
= This also limits the internet capability = of the equipment to being This = also limits the Internet capability of the = equipment to being
= mainly a receiver of Internet data, and makes it quite hard for = the mainly a receiver of Internet = data, and makes it quite hard for the
= equipment to become a world wide internet server (i.e. HTTP, FTP, = equipment to become a world wide Internet server (i.e. HTTP, FTP,
= etc.) due to the stateful operation of the NAT equipment. = etc.) due to the stateful operation of the = NAT equipment.
= When using IPv6 NAP, this group will identify the users which = are When using IPv6 NAP, this group = will identify the users which are
= connected via a single IPv6 address and use a single piece of = connected via a single IPv6 address and use = a single piece of
= equipment (PC, PDA, etc.). = equipment (PC, PDA, etc.).
= In IPv6 world the assumption is that there is unrestricted = In IPv6 world the assumption is that there = is unrestricted
= availability of a large amount of globally routable and unique = IPv6 availability of a large amount = of globally routable and unique IPv6
= addresses. The ISP will not be motivated to allocate private = addresses. The ISP will not be motivated to = allocate private
= addresses towards the single user connection because he has = enough addresses towards the single = user connection because he has enough
= global addresses available, if scarcity was the motivation with = IPv4 global addresses available, if = scarcity was the motivation with IPv4
= to provide RFC 1918 addresses. If the single user wants to mask = his to provide RFC 1918 addresses. = If the single user wants to mask his
= identity, he may choose to enable IPv6 privacy extensions. = identity, he may choose to enable IPv6 = privacy extensions.
5.4. ISP/Carrier Customer Networks 5.4. ISP/Carrier Customer Networks
= This group refers to the actual service providers that are = providing This group refers to the = actual service providers that are providing
= the IPv4 access and transport services. = They tend to have three the IP access and transport services. They tend to = have three
= separate IPv4 domains that they = support: separate IP domains that they support:
=
= o For the first they fall into the Medium/large private = networks o For the first they fall = into the Medium/large private networks
= category (above) for their own internal networks, LANs etc. = category (above) for their own internal = networks, LANs etc.
= o The second is the Operations network which addresses their = o The second is the Operations network = which addresses their
= backbone and access switches, and other hardware, this is = separate backbone and access = switches, and other hardware, this is separate
= for both engineering reasons as well as simplicity in managing = the for both engineering reasons = as well as simplicity in managing the
= security of the backbone. = security of the backbone.
= o The third is the IP addresses (single or blocks) that they = assign o The third is the IP = addresses (single or blocks) that they assign
= to customers. These can be registered addresses (usually given = to to customers. These can be = registered addresses (usually given to
= category 5.1 and 5.2 and sometimes 5.3) or can be from a pool = of category 5.1 and 5.2 and = sometimes 5.3) or can be from a pool of
= RFC 1918 addresses used with NAT for single user = connections. RFC 1918 addresses = used with IPv4 NAT for single user = connections.
= Therefore they can actually have two different NAT domains = that Therefore they can actually = have two different NAT domains that
= are not connected (internal LAN and single user customers). = are not connected (internal LAN and = single user customers).
= When IPv6 NAP is utilized in these three domains then for the = first When IPv6 NAP is utilized in = these three domains then for the first
= category it will be possible to use the same solutions as = described category it will be = possible to use the same solutions as described
= in Section 5.1. The second domain of the ISP/carrier is the = in Section 5.1. The second domain of the = ISP/carrier is the
= Operations network. This environment tends to be a closed = Operations network. This environment tends = to be a closed
= environment, and consequently communication can be done based on = ULA environment, and consequently = communication can be done based on ULA
= addresses, however, in this environment, stable IPv6 Provider = addresses, however, in this environment, = stable IPv6 Provider
= Independent addresses can be used in preference = to ULA addresses. = Independent addresses can be used. This = would give a solid and
= This would give a solid and scalable configuration with respect to = a scalable configuration with = respect to a local IPv6 address plan. By
= local IPv6 address plan. By the usage of proper network edge = the usage of proper network edge filters, = outside access to the
= filters, outside access to the closed environment can be = avoided. closed environment can be = avoided. The third is the IPv6 addresses
= The third is the IPv6 addresses that ISP/carrier network assign = to that ISP/carrier network assign = to customers. These will typically
= customers. These will typically be assigned with prefix = lengths be assigned with prefix = lengths terminating on nibble boundaries to
= terminating on nibble boundaries to be consistent with the DNS = PTR be consistent with the DNS PTR = records. As scarcity of IPv6
= records. As scarcity of IPv6 addresses is not a concern, it will = be addresses is not a concern, it = will be possible for the ISP to
= possible for the ISP to provide global routable IPv6 prefixes = without provide global routable = IPv6 prefixes without a requirement for
= a requirement for address translation. An ISP may for = commercial address translation. = An ISP may for commercial reasons still decide
= reasons still decide to restrict the capabilities of the end users = by to restrict the capabilities of = the end users by other means like
= other means like traffic and/or route filtering etc. traffic and/or route filtering etc.
= If the carrier network is a mobile provider, then IPv6 is = encouraged If the carrier network = is a mobile provider, then IPv6 is encouraged
= in comparison with the combination of IPv4+NAT for 3GPP = attached in comparison with the = combination of IPv4+NAT for 3GPP attached
= devices. When looking in chapter 2.3 of RFC3314 'Recommendations = for devices. When looking in = chapter 2.3 of RFC3314 'Recommendations for
= IPv6 in 3GPP Standards' [15] it is found = that the IPv6 WG recommends IPv6 = in 3GPP Standards' [16] it is found that = the IPv6 WG recommends
= that one or more /64 prefixes should be assigned to each primary = PDP that one or more /64 prefixes = should be assigned to each primary PDP
= context. This will allow sufficient address space for a 3GPP- = context. This will allow sufficient address = space for a 3GPP-
= attached node to allocate privacy addresses and/or route to a = multi- attached node to allocate = privacy addresses and/or route to a multi-
= link subnet, and will discourage the use of NAT within = 3GPP-attached link subnet, and will = discourage the use of NAT within 3GPP-attached
= devices. devices.
6. = IPv6 Gap Analysis 6. IPv6 Gap = Analysis
= Like IPv4 and any major standards effort, IPv6 standardization = work Like IPv4 and any major = standards effort, IPv6 standardization work
= continues as deployments are ongoing. This section discusses = several continues as deployments = are ongoing. This section discusses several
= topics for which additional standardization, or documentation of = best topics for which additional = standardization, or documentation of best
= practice, is required to fully realize the benefits of NAP. None = of practice, is required to fully = realize the benefits of NAP. None of
= these items are show-stoppers for immediate usage of NAP in = roles these items are show-stoppers = for immediate usage of NAP in roles
= where there are no current gaps. = where there are no current gaps.
6.1. Subnet Topology Masking 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.
6.2. Subnet Topology Masking
= There really is no functional gap here as a centrally assigned = pool There really is no functional = gap here as a centrally assigned pool
= of addresses in combination with host routes in the IGP is an = of addresses in combination with host routes = in the IGP is an
= effective way to mask topology. If = necessary a best practice = effective way to mask topology for smaller = deployments. If necessary
= document could be developed describing the interaction between = DHCP a best practice document = could be developed describing the
= and various IGPs which would in effect define Untraceable = Addresses. interaction between = DHCP and various IGPs which would in effect
define = Untraceable Addresses.
= As an alternative, some work in Mobile IP to define a policy message = As an alternative = for larger deployments, there is no gap in the HA
where a mobile node would = learn from the Home Agent. It should = not = tunneling approach when firewalls are configured to block outbound
try to inform its correspondent about route optimization and = thereby binding update messages. A border Home Agent = using internal
expose its real = location. A border Home Agent using internal tunneling to the logical mobile node (potentially = rack mounted) can
= tunneling to the logical mobile node (potentially static) can
= completely mask all internal topology, while avoiding the strain = from completely mask all internal = topology, while avoiding the strain from
= a large number of host routes in the IGP. This work should = be a large number of host routes = in the IGP. Some optimization = work
= pursued in the IETF. could be done in Mobile IP to = define a policy message where a mobile
node would learn from the Home Agent that it should = not try to inform
its correspondent about route optimization and = thereby expose its
real location. This optimization which reduces the load on = the
firewall would result in less optimal internal = traffic routing as
that would also transit the HA. Trade-off's for = this optimization
work should be = investigated in the IETF.
6.2. Minimal = Traceability of Privacy Addresses 6.3. Minimal = Traceability of Privacy Addresses
= Privacy addresses (RFC 3041) may certainly be used to limit the = Privacy addresses (RFC 3041) may certainly = be used to limit the
= traceability of external traffic flows back to specific hosts, = but traceability of external = traffic flows back to specific hosts, but
= lacking a topology masking component above they would still = reveal lacking a topology masking = component above they would still reveal
= the subnet address bits. For complete privacy a best practice = the subnet address bits. For complete = privacy a best practice
= document describing the combination of privacy addresses with = document describing the combination of = privacy addresses with
= topology masking may be required. This work remains to be done, = and topology masking may be = required. This work remains to be done, and
= should be pursued by the IETF. = should be pursued by the IETF.
6.3. Renumbering = Procedure
Documentation of site = renumbering procedures [12] is completed and is
in the RFC-editor's queue. = It should also be noticed that ULAs may
help here too, since a change = of ISP prefix will only affect hosts
that need an externally = routeable address as well as an ULA.
= =
6.4. Site Multihoming 6.4. Site Multihoming
= This complex problem has never been completely solved for IPv4, = which This complex problem has = never been completely solved for IPv4, which
= is exactly why NAT has been used as a partial solution. For = IPv6, is exactly why NAT has been = used as a partial solution. For IPv6,
= after several years' work, the IETF has = converged on an architectural = after several years of work, the IETF has = converged on an
= approach intended with service restoration as initial aim [20]. = architectural approach intended with service restoration as = initial
Again, ULAs may help since = they will provide stable addressing for aim [21]. When this document = was drafted, the IETF was actively
internal communications that = are not affected by multihoming. defining the details = of this approach to the multihoming problem.
The approach appears = to be most suitable for small and = medium sites,
6.5. Untraceable = Addresses though it will conflict with firewall state = procedures. At this time
there are also active = discussions in the address registries
The details of the = untraceable addresses, along with any = associated investigating the possibility of assigning = provider-independent
mechanisms such as route = injection, must be worked out and = specified. address space. Their = challenge is finding a reasonable metric for
limiting the number of organizations that would = qualify for a global
routing entry. Additional work appears to be = necessary to satisfy
the entire range of requirements.
7. = IANA Considerations 7. IANA = Considerations
= This document requests no action by IANA This document requests no action by IANA
8. = Security Considerations 8. Security = Considerations
= While issues which are potentially security related are = discussed While issues which are = potentially security related are discussed
= throughout the document, the approaches herein do not introduce = any throughout the document, the = approaches herein do not introduce any
= new security concerns. Product marketing departments have = widely new security concerns. = Product marketing departments have widely
= sold IPv4 NAT as a security tool and suppliers have been = implementing sold IPv4 NAT as a = security tool and suppliers have been implementing
= address translation functionality in their firewalls, though = the address translation = functionality in their firewalls, though the
= misleading nature of those claims has been previously documented = in misleading nature of those = claims has been previously documented in
= RFC 2663 [2] and RFC 2993 [4]. = [2] and = [4].
= This document defines IPv6 approaches which collectively achieve = the This document defines IPv6 = approaches which collectively achieve the
= goals of the network manager without the negative impact on = goals of the network manager without the = negative impact on
= applications or security that are inherent in a NAT approach. To = the applications or security that = are inherent in a NAT approach. To the
= degree that these techniques improve a network manager's ability = to degree that these techniques = improve a network manager's ability to
= explicitly know about or control access, = and thereby manage the explicitly = audit or control access, and thereby = manage the overall
= overall attack exposure of local resources, they act to improve = local attack exposure of local = resources, they act to improve local network
= network security. In particular the explicit nature of a = content security. In particular = the explicit nature of a content aware
= aware firewall in NAP will be a vast security improvement over = the firewall in NAP will be a vast = security improvement over the NAT
= NAT artifact where lack of translation state has been widely sold = as artifact where lack of = translation state has been widely sold as a
= a form of protection. form of = protection.
9. = Conclusion 9. Conclusion
= This document has described a number of techniques that may be = This document has described a number of = techniques that may be
= combined on an IPv6 site to protect the integrity of its = network combined on an IPv6 site to = protect the integrity of its network
= architecture. These techniques, known collectively as Network = architecture. These techniques, known = collectively as Network
= Architecture Protection, retain the concept of a well defined = Architecture Protection, retain the concept = of a well defined
= boundary between "inside" and "outside" the private network, = and boundary between "inside" and = "outside" the private network, and
= allow firewalling, topology hiding, and privacy. However, = because allow firewalling, topology = hiding, and privacy. However, because
= they preserve address transparency where it is needed, they = achieve they preserve address = transparency where it is needed, they achieve
=
skipping to change at page 26, line = 25 skipping to = change at page 30, line 25
= Carney, "Dynamic Host Configuration Protocol for IPv6 = Carney, "Dynamic Host Configuration = Protocol for IPv6
= (DHCPv6)", RFC 3315, July 2003. = (DHCPv6)", RFC 3315, July 2003.
= [10] Draves, R., "Default Address Selection for Internet = Protocol [10] Draves, R., "Default = Address Selection for Internet Protocol
= version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February = 2003.
= [11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic = Host [11] Troan, O. and R. Droms, = "IPv6 Prefix Options for Dynamic Host
= Configuration Protocol (DHCP) version 6", RFC 3633, = Configuration Protocol (DHCP) version = 6", RFC 3633,
= December 2003. December = 2003.
= [12] Baker, F., "Procedures for Renumbering an = IPv6 Network without [12] = Arkko, J., Kempf, J., Zill, B., and P. Nikander, = "SEcure
a Flag Day", = draft-ietf-v6ops-renumbering-procedure-05 (work in = Neighbor = Discovery (SEND)", RFC 3971, March 2005.
progress), March = 2005.
= [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast = [13] Baker, F., = Lear, E., and R. Droms, "Procedures for Renumbering
= Addresses", draft-ietf-ipv6-unique-local-addr-09 (work = in = an IPv6 Network without a Flag Day", RFC 4192, September = 2005.
progress), = January 2005.
[14] Hinden, R. and B. Haberman, "Unique = Local IPv6 Unicast
= Addresses", RFC 4193, October = 2005.
11.2. Informative References 11.2. Informative References
= [14] Fuller, V., Li, T., Yu, J., and K. = Varadhan, "Classless Inter- = [15] Fuller, V., Li, T., Yu, J., and K. = Varadhan, "Classless Inter-
= Domain Routing (CIDR): an Address Assignment and = Aggregation Domain Routing = (CIDR): an Address Assignment and Aggregation
= Strategy", RFC 1519, September 1993. Strategy", RFC 1519, September 1993.
= [15] Wasserman, M., "Recommendations = for IPv6 in Third Generation = [16] Wasserman, M., "Recommendations for = IPv6 in Third Generation
= Partnership Project (3GPP) Standards", RFC 3314, Partnership Project (3GPP) Standards", RFC = 3314,
= September 2002. = September 2002.
= [16] Savola, P. and B. Haberman, = "Embedding the Rendezvous Point = [17] Savola, P. and B. Haberman, = "Embedding the Rendezvous Point
= (RP) Address in an IPv6 Multicast Address", RFC 3956, = (RP) Address in an IPv6 Multicast = Address", RFC 3956,
= November 2004. November = 2004.
= [17] Dupont, F. and P. Savola, "RFC = 3041 Considered Harmful [18] Dupont, F. and P. Savola, "RFC 3041 = Considered Harmful
= (draft-dupont-ipv6- rfc3041harmful-05.txt)", June = 2004. (draft-dupont-ipv6- = rfc3041harmful-05.txt)", June 2004.
= [18] Chown, T., "IPv6 Implications for = TCP/UDP Port Scanning (chown- = [19] Chown, = T., "IPv6 Implications for TCP/UDP Port Scanning
v6ops- = port-scanning-implications-01.txt)", July 2004. (chown-v6ops-port-scanning-implications-01.txt)",= July 2004.
= [19] Chown, T., Tompson, M., Ford, A., = and S. Venaas, "Things to [20] Chown, T., Tompson, M., Ford, A., and S. = Venaas, "Things to
= think about when Renumbering an IPv6 network think about when Renumbering an IPv6 = network
= (draft-chown-v6ops-renumber-thinkabout-03)", October = 2004. = (draft-chown-v6ops-renumber-thinkabout-03)", October 2004.
= [20] Huston, G., "Architectural = Commentary on Site Multi-homing = [21] Huston, G., "Architectural = Commentary on Site Multi-homing
= using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)", = using a Level 3 Shim = (draft-ietf-shim6-arch-00.txt)",
= July 2004. July = 2004.
Appendix A. Additional Benefits due to Native IPv6 and = Universal Unique Appendix A. = Additional Benefits due to Native IPv6 and Universal
= Addressing = Unique Addressing
= The users of native IPv6 technology and global unique IPv6 = addresses The users of native IPv6 = technology and global unique IPv6 addresses
= have the potential to make use of the enhanced IPv6 capabilities, = in have the potential to make use = of the enhanced IPv6 capabilities, in
= addition to the benefits offered by the IPv4 technology. = addition to the benefits offered by the IPv4 = technology.
A.1. Universal Any-to-Any Aonnectivity A.1. Universal Any-to-Any Connectivity
= One of the original design points of the Internet was = any-to-any One of the original = design points of the Internet was any-to-any
= connectivity. The dramatic growth of Internet connected = systems connectivity. The dramatic = growth of Internet connected systems
= coupled with the limited address space of the IPv4 protocol = spawned coupled with the limited = address space of the IPv4 protocol spawned
= address conservation techniques. NAT was introduced as a tool = to address conservation techniques. = NAT was introduced as a tool to
= reduce demand on the limited IPv4 address pool, but the side = effect reduce demand on the limited = IPv4 address pool, but the side effect
= of the NAT technology was to remove the any-to-any connectivity = of the NAT technology was to remove the = any-to-any connectivity
= capability. By removing the need for address conservation (and = capability. By removing the need for = address conservation (and
= therefore NAT), IPv6 returns the any-to-any connectivity model = and therefore NAT), IPv6 returns = the any-to-any connectivity model and
= removes the limitations on application developers. With the = freedom removes the limitations on = application developers. With the freedom
= to innovate unconstrained by NAT traversal efforts, developers = will to innovate unconstrained by = NAT traversal efforts, developers will
= be able to focus on new advanced network services (i.e. = peer-to-peer be able to focus on = new advanced network services (i.e. peer-to-peer
= applications, IPv6 embedded IPsec communication between two = applications, IPv6 embedded IPsec = communication between two
= communicating devices, instant messaging, Internet telephony, = etc..) communicating devices, = instant messaging, Internet telephony, etc..)
= rather than focusing on discovering and traversing the = increasingly rather than focusing = on discovering and traversing the increasingly
= complex NAT environment. complex = NAT environment.
= It will also allow application and service developers to rethink = the It will also allow application = and service developers to rethink the
= security model involved with any-to-any connectivity, as the = current security model involved = with any-to-any connectivity, as the current
= edge firewall solution in IPv4 may not be sufficient for Any-to-any = edge firewall solution in IPv4 may not be sufficient for any- to-any
= service models. service = models.
A.2. Auto-configuration A.2. Auto-configuration
= IPv6 offers a scalable approach to minimizing human interaction = and IPv6 offers a scalable approach = to minimizing human interaction and
= device configuration. Whereas IPv4 implementations require = touching device configuration. = Whereas IPv4 implementations require touching
= each end system to indicate the use of DHCP vs. a static address = and each end system to indicate the = use of DHCP vs. a static address and
= management of a server with the pool size large enough for the = management of a server with the pool size = large enough for the
= potential number of connected devices, IPv6 uses an indication = from potential number of connected = devices, IPv6 uses an indication from
= the router to instruct the end systems to use DHCP or the = stateless the router to instruct = the end systems to use DHCP or the stateless
= auto configuration approach supporting a virtually limitless = number auto configuration approach = supporting a virtually limitless number
= of devices on the subnet. This minimizes the number of systems = that of devices on the subnet. = This minimizes the number of systems that
= require human interaction as well as improves consistency between = all require human interaction as = well as improves consistency between all
= the systems on a subnet. In the case that there is no router = to the systems on a subnet. In the = case that there is no router to
= provide this indication, an address for use on = the local link only provide = this indication, an address for use only on the = local link
= will be derived from the interface media layer address. = will be derived from the interface media = layer address.
A.3. Native Multicast Services A.3. Native Multicast Services
= Multicast services in IPv4 were severely restricted by the = limited Multicast services in IPv4 = were severely restricted by the limited
= address space available to use for group assignments and an = implicit address space available to = use for group assignments and an implicit
= locally defined range for group membership. IPv6 multicast = corrects locally defined range for = group membership. IPv6 multicast corrects
= this situation by embedding explicit scope indications as well = as this situation by embedding = explicit scope indications as well as
= expanding to 4 billion groups per scope. In the source = specific expanding to 4 billion = groups per scope. In the source specific
= multicast case, this is further expanded to 4 billion groups = per multicast case, this is further = expanded to 4 billion groups per
= scope per subnet by embedding the 64 bits of subnet identifier = into scope per subnet by embedding = the 64 bits of subnet identifier into
= the multicast address. the = multicast address.
= IPv6 allows also for innovative usage of the IPv6 address length, = and IPv6 allows also for innovative = usage of the IPv6 address length, and
= makes it possible to embed the multicast 'Rendez-Vous Point' (or RP) makes it possible to embed the multicast 'Rendezvous Point' (or RP)
= [16] directly in the IPv6 multicast = address when using ASM multicast. = [17] directly in the IPv6 multicast = address when using ASM multicast.
= this is not possible with limited size = of the IPv4 address. This This is not possible with limited size of the = IPv4 address. This
= approach also simplifies the multicast model considerably, making = it approach also simplifies the = multicast model considerably, making it
= easier to understand and deploy. = easier to understand and deploy.
A.4. Increased Security Protection A.4. Increased Security Protection
= The security protection offered by native IPv6 technology is = more The security protection = offered by native IPv6 technology is more
= advanced than IPv4 technology. There are various transport = advanced than IPv4 technology. There are = various transport
= mechanisms enhanced to allow a network to operate more securely = with mechanisms enhanced to allow a = network to operate more securely with
= less performance impact: less = performance impact:
= o IPv6 has the IPsec technology directly embedded into the = IPv6 o IPv6 has the IPsec = technology directly embedded into the IPv6
= protocol. This allows for simpler peer-to-peer encryption and protocol. This allows for simpler peer-to-peer = authentication and
= authentication, once a simple = key/trust management model is = encryption, once a simple key/trust = management model is developed,
= developed, while the usage of some other less secure mechanisms = is while the usage of some = other less secure mechanisms is avoided
= avoided (i.e. md5 password hash for neighbor = authentication). (i.e. md5 = password hash for neighbor authentication).
= o On a local network, any user will have more security = awareness. o On a local network, = any user will have more security awareness.
= This awareness will motivate the usage of simple firewall = This awareness will motivate the usage of = simple firewall
= applications/devices to be inserted on the border between = the applications/devices to be = inserted on the border between the
= external network and the local (or home network) as there is = no external network and the = local (or home network) as there is no
= Address Translater and hance no false = safety perception. Address = Translator and hence no false safety = perception.
= o All flows on the Internet will be better traceable due to a = unique o All flows on the Internet = will be better traceable due to a unique
= and globally routable source and destination IPv6 address. = This and globally routable = source and destination IPv6 address. This
= may facilitate an easier methodology for back-tracing DoS = attacks may facilitate an easier = methodology for back-tracing DoS attacks
= and avoid illegal access to network resources by simpler = traffic and avoid illegal access = to network resources by simpler traffic
= filtering. filtering.
= o The usage of private address-space in IPv6 is now provided = by o The usage of private = address-space in IPv6 is now provided by
= Unique Local Addresses, which will avoid conflict situations = when Unique Local Addresses, = which will avoid conflict situations when
= merging networks and securing the internal communication on = a merging networks and securing = the internal communication on a
= local network infrastructure due to simpler traffic = filtering local network = infrastructure due to simpler traffic filtering
= policy. policy.
=
skipping to change at page 29, line = 29 skipping to = change at page 33, line 29
= connection establishment in either protocol version, IPv6 = mobile connection establishment in = either protocol version, IPv6 mobile
= nodes are able to optimize the path between them using the = MIPv6 nodes are able to optimize = the path between them using the MIPv6
= option header while IPv4 mobile nodes are required to triangle = route option header while IPv4 = mobile nodes are required to triangle route
= all packets. In general terms this will minimize the network = all packets. In general terms this will = minimize the network
= resources used and maximize the quality of the communication. = resources used and maximize the quality of = the communication.
A.6. Merging Networks A.6. Merging Networks
= When two IPv4 networks want to merge it is not guaranteed that = both When two IPv4 networks want to = merge it is not guaranteed that both
= networks would be using different address-ranges on some parts of = the networks would be using = different address-ranges on some parts of the
= network infrastructure due to the legitimate usage of RFC 1918 network infrastructure due to the usage of RFC 1918 = private
= private addressing. This potential overlap in address space = may addressing. This potential = overlap in address space may complicate a
= complicate a merge of two and more networks dramatically due to = the merge of two and more networks = dramatically due to the additional
= additional IPv4 renumbering effort. i.e. when the first network has = a IPv4 renumbering effort. i.e. = when the first network has a service
= service running (NTP, DNS, DHCP, HTTP, etc..) which need to = be running (NTP, DNS, DHCP, HTTP, = etc..) which need to be accessed by
= accessed by the 2nd merging network. Similar address conflicts = can the 2nd merging network. = Similar address conflicts can happen when
= happen when two network devices from these merging networks want = to two network devices from these = merging networks want to communicate.
= communicate.
= With the usage of IPv6 the addressing overlap will not exist = because With the usage of IPv6 the = addressing overlap will not exist because
= of the existence of the Unique Local Address usage for private = and of the existence of the Unique = Local Address usage for private and
= local addressing. local = addressing.
A.7. Community of interest A.7. Community of interest
= Although some Internet-enabled devices will function as fully-fledged Although some Internet-enabled devices will function = as fully-
= Internet hosts, it is believed that many will be operated in a = highly = fledged Internet hosts, it is believed that many will be operated = in
= restricted manner functioning largely or entirely within a = Community a highly restricted = manner functioning largely or entirely within a
= of Interest. By Community of Interest we mean a collection of = hosts Community of Interest. By = Community of Interest we mean a collection
= that are logically part of a group reflecting their ownership = or of hosts that are logically = part of a group reflecting their
= function. Typically, members of a Community of Interest need = to ownership or function. = Typically, members of a Community of Interest
= communicate within the community but should not be generally = need to communicate within the community = but should not be generally
= accessible on the Internet. They want = the benefits of the accessible = from the public Internet. They want the benefits of = the
= connectivity provided by the Internet, but do not want to be = exposed connectivity provided by = the Internet, but do not want to be exposed
= to the rest of the world. This functionality = will be available to the = rest of the world. The ability in NAP = to virtualize the
through the usage of = NAP and native IPv6 dataflows, without = any = topology and mask portions of it is = applied to the community,
stateful device in the = middle. It will also allow to build virtual creating arbitrary = groupings. It will also allow building virtual
= organization networks on the fly, which is very difficult to do = in organization networks on the = fly, which is very difficult to do in
= IPv4+NAT scenarios. IPv4+NAT = scenarios.
Appendix B. Revision history Appendix B. Revision history
B.1. Changes from *-vandevelde-v6ops-nap-00 to = B.1. Changes from *-vandevelde-v6ops-nap-00 = to
= *-vandevelde-v6ops-nap-01 = *-vandevelde-v6ops-nap-01
= o Document introduction has been revised and overview table = added o Document introduction has = been revised and overview table added
= o Comments and suggestions from nap-00 draft have been = included. o Comments and = suggestions from nap-00 draft have been included.
= o Initial section of -00 draft 2.6 and 4.6 have been aggregated = into o Initial section of -00 = draft 2.6 and 4.6 have been aggregated into
= a new case study section 5. a = new case study section 5.
= o The list of additional IPv6 benefits has been been placed into o The list of additional IPv6 benefits has been = placed into
= appendix. appendix.
= o new security considerations section added. o new security considerations section added.
= o GAP analysis revised. o GAP = analysis revised.
= o Section 2.6 and 4.6 have been included. o Section 2.6 and 4.6 have been included.
B.2. Changes from *-vandevelde-v6ops-nap-01 to = *-ietf-v6ops-nap-00 B.2. Changes from = *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00
= o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-ietf- o = Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-
= v6ops-nap-00.txt. ietf-v6ops-nap-00.txt.
= o Editorial changes. o Editorial = changes.
B.3. Changes from *-ietf-v6ops-nap-00 to = *-ietf-v6ops-nap-01 B.3. Changes from = *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01
= o Added text in Chapter 2.2 and 4.2 to address more details on = o Added text in Chapter 2.2 and 4.2 to = address more details on
= firewall and proxy firewall = and proxy
= o Revised Eric Klein contact details = o Revised Eric Klein contact details
= o Added note in 4.2 that control over the proposed = statefull-filter o Added note in = 4.2 that control over the proposed statefull-filter
= should be by a simple user-interface should be by a simple user-interface
B.4. Changes from *-ietf-v6ops-nap-01 to = *-ietf-v6ops-nap-02 B.4. Changes from = *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02
= o General Note: Header more consistent capitelized. o = General Note: Header more consistent capitalized.
= o Section 1: para 3: s/...and privacy and will... = translation./ o Section 1: para 3: = s/...and privacy and will... translation./
= ...and privacy. NAP will achieve these security goals = without ...and privacy. NAP = will achieve these security goals without
= address transaltion whilst = maintaining any-to-any connectivity./ address translation = whilst maintaining any-to-any connectivity./
= o Section 1: Various editorial changes happened o Section 1: Various editorial changes = happened
= o Section 2.1: Changed: 'Frequently a simple user interface is = o Section 2.1: Changed: 'Frequently a = simple user interface is
= sufficient for configuring'. into 'Frequently a simple user = sufficient for configuring'. into = 'Frequently a simple user
= interface, or no user interface is sufficient' interface, or no user interface is = sufficient'
= o Section 2.2: (Simple Security ) Better not to use the word = -evil- o Section 2.2: (Simple = Security ) Better not to use the word -evil-
= in the text in the = text
= o Section 2.2: changed 'provided by NAT are actually ' into = o Section 2.2: changed 'provided by NAT are = actually ' into
= 'provided by NAT is actually' = 'provided by NAT is actually'
= o Section 2.2: para 3: s/actually false/actually an illusion/ = o Section 2.2: para 3: s/actually = false/actually an illusion/
= o Section 2.2: para 2: added 'Also it will only be reliable if = a o Section 2.2: para 2: added = 'Also it will only be reliable if a
=
skipping to change at page 31, line = 20 skipping to = change at page 35, line 20
= device's state/ device's = state/
= o Section 2.4: para1: clarified the definition of topology = hiding o Section 2.4: para1: = clarified the definition of topology hiding
= o Section 2.4: last sentence of next-to-last paragraph, added = o Section 2.4: last sentence of = next-to-last paragraph, added
= punctuation at end of sentence. = punctuation at end of sentence.
= o Section 2.4: added first line: When mentioning 'topology = hiding' o Section 2.4: added first = line: When mentioning 'topology hiding'
= the goal is to make a reference that an entity outside the = network the goal is to make a = reference that an entity outside the network
= can not make a correlation between the location of a device = and can not make a correlation = between the location of a device and
= the address of a device on the local network. the address of a device on the local = network.
= o Section 2.4: para 1: s/reflected/represented/ o Section 2.4: para 1: = s/reflected/represented/
= o Section 2.5: last par: added reference: 'Section 2.7 = describes o Section 2.5: last par: = added reference: 'Section 2.7 describes
= some disadvantages that appear if independednt networks using some disadvantages that appear if independent = networks using
= [RFC1918] addresses have to be merged.' [RFC1918] addresses have to be merged.'
= o Section 2.6: Added text that private address-space is not = o Section 2.6: Added text that private = address-space is not
= limitless limitless
= o Section 2.6: Various editorial changes o Section 2.6: Various editorial changes
= o Section 2.7: Para 1 editorial revised o Section 2.7: Para 1 editorial revised
= o Section 2.7: last para: s/This solution/The addition of an = extra o Section 2.7: last para: = s/This solution/The addition of an extra
= NAT as a solution/ NAT as a = solution/
= o Section 2.7: s/highly desirable to be/highly desirable due = to o Section 2.7: s/highly = desirable to be/highly desirable due to
= resiliency and load-balancing to be/ resiliency and load-balancing to be/
= o Section 2.7: added text on the reason why there are = overlapping o Section 2.7: added = text on the reason why there are overlapping
= addresses addresses
= o Section 2.7: last para: s/merged address space/overlapping = address o Section 2.7: last para: = s/merged address space/overlapping address
= speaces in the merged = networks/ spaces in the merged = networks/
= o Section 3.1: Para 1 editorial changes o Section 3.1: Para 1 editorial changes
= o Section 3.1: s/by contacted web sites, so IPv6/by web sites = that o Section 3.1: s/by contacted = web sites, so IPv6/by web sites that
= are accessed from the device: IPv6 / are accessed from the device: IPv6 /
= o Section 3.1: s/as that would have a serious negative impact = on o Section 3.1: s/as that would = have a serious negative impact on
= global routing/as that would have a negative effect on = global global routing/as that = would have a negative effect on global
= route aggregation route = aggregation
= o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA = in o Section 3.2: s3.2: Par 1 = editorial revised and noted that ULA in
= global routing table is not scalable global routing table is not scalable
= o Section 3.2: s3.2: Noted that it is not always interresting to mix o Section 3.2: s3.2: Noted that it is not always = interesting to mix
= ULA with global as that may lead to SAS issues ULA with global as that may lead to SAS = issues
= o Section 3.3: last para: s/delegating router/delegating = router o Section 3.3: last para: = s/delegating router/delegating router
= (incorporating a DHCPv6 server)/, s/across an = administrative/ (incorporating a = DHCPv6 server)/, s/across an administrative/
= possibly across an administrative/ = possibly across an administrative/
= o Section 3.4: Changed: 'random assignment has as purpose' to = o Section 3.4: Changed: 'random assignment = has as purpose' to
= 'random assignment has a purpose' = 'random assignment has a purpose'
= o Section 3.4: para 2: Replace first sentence with: 'The = random o Section 3.4: para 2: = Replace first sentence with: 'The random
= assignment is intended to mislead the outside world about = the assignment is intended to = mislead the outside world about the
= structure of the local network.' = structure of the local network.'
= o Section 3.4: para 2: s/there is a correlation/needs to maintain = a o Section 3.4: para 2: s/there = is a correlation/needs to maintain a
= correlation/ = correlation/
= o Section 3.4: para 2: s/like a/such as a/ o Section 3.4: para 2: s/like a/such as a/
= o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from = o Section 3.4: para 3: = s/unpredictable/amorphous/, s/or from
= mapping/and from mapping of/ = mapping/and from mapping of/
= o Section 3.4: para 3: s/are reachable on/are allocated to = devices o Section 3.4: para 3: = s/are reachable on/are allocated to devices
= on/ on/
= o Section 3.4: para 3: s/belonging to the same subnet next to = each o Section 3.4: para 3: = s/belonging to the same subnet next to each
= other/belonging to devices adjacent to each other on the = same other/belonging to devices = adjacent to each other on the same
= subnet/ subnet/
= o Section 3.4: s/aggregation device/indirection device/ = o Section 3.4: s/aggregation = device/indirection device/
= o Section 4.1: splitted the 1 section = up into 2 separate sections o = Section 4.1: split the 1 section up into 2 separate sections
= o Section 4.1: s/ End node connections involving other nodes on = the o Section 4.1: s/ End node = connections involving other nodes on the
= global Internet will always use the global IPv6 addresses = [9] global Internet will always = use the global IPv6 addresses [9]
= derived from this prefix delegation./ End node connections = derived from this prefix delegation./ End = node connections
= involving other nodes on the global Internet will always use = the involving other nodes on the = global Internet will always use the
= global IPv6 addresses [9] derived from this prefix delegation. = It global IPv6 addresses [9] = derived from this prefix delegation. It
= should be noted that the policy table needs to be correctly set = up should be noted that the = policy table needs to be correctly set up
= so that true global prefixes are distinguished from ULAs and = will so that true global = prefixes are distinguished from ULAs and will
= be used for the source address in preference when the = destination be used for the = source address in preference when the destination
= is not a ULA/ is not a = ULA/
= o Section 4.1: A more secure network environment can be = established o Section 4.1: A more = secure network environment can be established
= by having the referenced ULA addresses statically configured = on by having the referenced ULA = addresses statically configured on
= the network devices as this decreases the dynamic aspects of = the the network devices as this = decreases the dynamic aspects of the
= network, however the operational overhead is increased. = network, however the operational overhead = is increased.
= o Section 4.2:Added note that IID = should be randomized for port-scan = o Section 4.2: Added note that IID should = be randomized for port-
= protection scan protection
= o Section 4.2: Removed text: This is an automated procedure of = o Section 4.2: Removed text: This is an = automated procedure of
= sending Internet Control Message Protocol (ICMP) echo = requests sending Internet = Control Message Protocol (ICMP) echo requests
= (also known as PINGs) to a range of IP addresses and = recording (also known as PINGs) = to a range of IP addresses and recording
= replies. This can enable an attacker to map the network. = replies. This can enable an attacker to = map the network.
= o Section 4.2: paragraph beginning: "This simple rule...". = The o Section 4.2: paragraph = beginning: "This simple rule...". The
= first sentence in this paragraph was overly-long. The = sentence first sentence in this = paragraph was overly-long. The sentence
= has been fragmented has been = fragmented
= o Section 4.2: para 1: s/similar as for an/similar to that of = an/ o Section 4.2: para 1: = s/similar as for an/similar to that of an/
= o Section 4.2: para 1: s/Internet, and firewall and IDS systems = are/ o Section 4.2: para 1: = s/Internet, and firewall and IDS systems are/
= Internet. The use of firewall and Intrusion Detection = Systems Internet. The use of = firewall and Intrusion Detection Systems
=
skipping to change at page 33, line = 20 skipping to = change at page 37, line 20
= best practices are trying to achieve./IPv6 security best = practices best practices are = trying to achieve./IPv6 security best practices
= will avoid this kind of illusory security but can only do this = if will avoid this kind of = illusory security but can only do this if
= correctly configured firewalls and IDS systems are used at = the correctly configured = firewalls and IDS systems are used at the
= perimeter where some IPv4 networks have relied on NATs. = perimeter where some IPv4 networks have = relied on NATs.
= o Section 4.2: s/ It is recommended for site administrators to = take o Section 4.2: s/ It is = recommended for site administrators to take
= [17] into consideration to achieve the expected goal./ It is = [17] into consideration to achieve the = expected goal./ It is
= recommended for site administrators to take [17] into = recommended for site administrators to = take [17] into
= consideration to achieve the expected goal. This protection = will consideration to achieve = the expected goal. This protection will
= also be nullified if IIDs are configured in a group near the = start also be nullified if IIDs = are configured in a group near the start
= of the IID space./ of the IID = space./
= o Section 4.2: Removed the example study and added complementiory o = Section 4.2: Removed the example study and added complementary
= text to describe a potential behavior text to describe a potential behavior
= o Section 4.4: rewrite of the section to reduce the importance = of o Section 4.4: rewrite of the = section to reduce the importance of
= the MIpv^ and tunneled = solution the MIPv6 and tunneled solution
= o Section 4.4: (Privacy and Topology Hiding) Mobile IP is = suggested o Section 4.4: (Privacy = and Topology Hiding) Mobile IP is suggested
= in the text, however text is added that any kind of = tunneling in the text, however = text is added that any kind of tunneling
= should do the trick. should = do the trick.
= o Section 4.4: para 2: after 'As discussed above' inserted = '(see o Section 4.4: para 2: after = 'As discussed above' inserted '(see
= Section 3.1)' Section = 3.1)'
= o Section 4.4: para 3: s/consolidated on/indirected via/ = o Section 4.4: para 3: s/consolidated = on/indirected via/
= o Section 4.4: para 3: s/topololgy masked/each topology = masked/ o Section 4.4: para 3: = s/topololgy masked/each topology masked/
= o Section 4.4: para 3: Expanded acronym COA o Section 4.4: para 3: Expanded acronym COA
= o Section 4.4: para 3: s/rack mounted/static/ o Section 4.4: para 3: s/rack = mounted/static/
= o Section 4.4: Rephrasing of text happened in this section = o Section 4.4: Rephrasing of text happened = in this section
= o Section 4.5: change: "so that a NAT is not required" to: "so = that o Section 4.5: change: "so = that a NAT is not required" to: "so that
= IPv6 address translation is not required". IPv6 address translation is not required".
= o Section 4.5: changed 'periodically to look' into 'to look = o Section 4.5: changed 'periodically to = look' into 'to look
= periodically' = periodically'
= o Section 4.5: change: "2^64 hosts" to: "2^64 addresses". = o Section 4.5: change: "2^64 hosts" to: = "2^64 addresses".
= o Section 4.5: Removed the statement '(or even defined) = o Section 4.5: Removed the statement '(or = even defined)
= o Section 4.6: last para: s/which will lead to the IPv4 = practice/ o Section 4.6: last = para: s/which will lead to the IPv4 practice/
= which will require the adoption of the IPv4 workaround/ = which will require the adoption of the = IPv4 workaround/
= o Section 4.6: s/the IPv4 constricting scenarios of multiple = devices o Section 4.6: s/the IPv4 = constricting scenarios of multiple devices
= sharing a/the constriction of IPv4 scenarios where multiple devies = sharing a/the constriction of IPv4 scenarios where multiple
= are forced to share a/ = devices are forced to share a/
= o Section 4.7: s/as the zero-touch external/as an almost = zero-touch o Section 4.7: s/as the = zero-touch external/as an almost zero-touch
= external/ external/
= o Section 5: Replaced first three sentences with: In = presenting o Section 5: Replaced = first three sentences with: In presenting
= these case studies we have chosen to consider categories of = these case studies we have chosen to = consider categories of
= network divided first according to their function either as = network divided first according to their = function either as
= carrier/ISP networks or end user (such as enterprise) = networks carrier/ISP networks or = end user (such as enterprise) networks
= with the latter category broken down according to the number = of with the latter category = broken down according to the number of
= connected end hosts. = connected end hosts.
= o Section 5: bullet points: s/connection/connected end hosts/ = o Section 5: bullet points: = s/connection/connected end hosts/
= o Section 5.1: s/addressing independence/addressing = independence o Section 5.1: = s/addressing independence/addressing independence
= when using IPv4/ when using = IPv4/
= o Section 5.1: last para: s/is only affecting/will only = affect/ o Section 5.1: last para: = s/is only affecting/will only affect/
= o Section 5.1: changed 'alloaction' = into 'allocation' o Section 5.1: = changed 'allocation' into = 'allocation'
= o Section 5.1: changed: '(typically a one or' into '(typically = one o Section 5.1: changed: = '(typically a one or' into '(typically one
= or' or'
= o section 5.1: changed: s/allocation/assignment/ in one of the = o section 5.1: changed: = s/allocation/assignment/ in one of the
= paragraphs paragraphs
= o section 5.2: para 1: s?is too long?is too long (very often just = a o section 5.2: para 1: s?is too = long?is too long (very often just a
= /32 just giving a single address)? = /32 just giving a single address)?
= o Section 5.4: (Case study: ISP networks) ULA usage for ISP/ = o Section 5.4: (Case study: ISP networks) = ULA usage for ISP/
= Carrier-grade networks is mentioned in the draft, while it = was Carrier-grade networks is = mentioned in the draft, while it was
= suggested that for these NW the PI addresses are already = very suggested that for these NW = the PI addresses are already very
= stable and they should be qualified for setting up proper = stable and they should be qualified for = setting up proper
=
skipping to change at page 35, line 5 = skipping to change at = page 38, line 35
= ULA specification is in the RFC-editor queue. ULA specification is in the RFC-editor = queue.
= o Section 6.3: (Minimal Traceability) Better to say "topology = o Section 6.3: (Minimal Traceability) = Better to say "topology
= masking _may be_ required" instead of "is required", because = masking _may be_ required" instead of "is = required", because
= whether this is needed or not is a value judgment. whether this is needed or not is a value = judgment.
= o Section 6.4: (Renumbering Procedure) Renumbering procedure is = in o Section 6.4: (Renumbering = Procedure) Renumbering procedure is in
= RFC queue. The section corrected in the current state? = RFC queue. The section corrected in the = current state?
= o Section 6.4: s/well solved/completely solved/ o Section 6.4: s/well solved/completely = solved/
= o In general the whole chapter 6 has been revised to reflect = current o In general the whole = chapter 6 has been revised to reflect current
= status status
B.5. Changes from *-ietf-v6ops-nap-02 to = *-ietf-v6ops-nap-03
o Editorial changes in response to IESG review = comments and
questions.
o Introduction: clarified impact & goal for = limited additional NAT
discussion here / modified tone wrt marketing / = grammar cleanup
o Introduction: s/market = acceptance/deployment
o Introduction: noted that users do not evaluate = technical trade-
offs and that marketing does not mention the = downside of address
translation
o Introduction: added paragraph about why nat !=3D = security
o Table1: s/benefit/Goal/ s/ULA/4193/ removed long = numeric string /
added app end points & number of = subnets
o Section 2: tone reduction about = marketing
o Section 2.1: grammar cleanup / clarified point = about use of public
space / added paragraph about topology = restrictions / removed last
paragraph about security
o Section 2.2: moved paragraph about firewalls to = 4.2 / deleted
discussion about distributed security / clarified = point about port
overload
o Section 2.3: Added opening sentence to explain = the goal of the
section / changed comment about theory to an = absolute / qualified
logging and checking times
o Section 2.4: deleted confusing/redundant comments = about identifier
/ clarified point about nodes appearing to be at = the edge / added
clarification that focused scanning on the port = range reaches
active nodes
o Section 2.5: clarified that the reason for = autonomy is large space
& impact was on the local = network
o Section 2.6: clarified point about reduction of = IPv4 consumption
rate / s/30%/25% / added point about limitations = of cascaded nat /
added para about limited app endpoints as well as = topology
restrictions
o Section 2.7: clarification about why multihoming = & renumbering are
discussed together / point about sparse = allocation / s/speaces/
spaces
o Section 3: s/emulate/replace / added para about = 'gaps' being
discussed later
o Section 3.1: Cleaned up description of SLAAC = & 3041 / specified
server as DHCP / added comment about sparse = allocation
o Section 3.2: grammar cleanup / updated reference = from ID to RFC
4193 / added point about policy table in 3484 to = bias ULA over ISP
prefix
o Section 3.3: Clarification about goal for = section
o Section 3.4: reorder paragraphs to put goal up = front
o Section 4.1: s/could/should/ s/prior to = establishing/independent
of the state of / clarified why concatenation = would not collide /
another comment about the 3484 table for ULA = biasing / clarified
point about lack of routing = protocol
o Section 4.2: clarified point about firewall at = boundary /
clarified point about valid lifetime / clarified = point that IPsec
works the same w/o NAT / added point about = authenticating
correspondent / clarified that the scanning = threat is addresses as
ports are the same once an address is known / = rearranged paragraph
to keep scanning thread together / inserted = firewall discussion
moved from 2.2 / clarified role of simple = firewall / added comment
about service provider mediated pinhole = management
o Section 4.3: added paragraph about tracking = privacy address use
o Section 4.4: clarified point about tracking wrt = NAT / added
comment about IGP complexity / s/conceal/isolate/ = s/possible/
potential/ reworded ULA description which was = technically
backwards / additional description of the goal / = added picture and
referenced it from descriptions converted options = to descriptive
list / added discussion about blocking binding = updates / added
vlan option / s/would be to use/uses to make it = clear this already
works / para 2 s/prefixes/addresses and replaced = last part of the
sentence to clarify what was being = hidden.
o Section 4.5: Grammar cleanup / clarification = about policy
o Section 4.6: replaced long number string with = power qnty of
subnets / added reference to new capabilities = like SEND
o Section 4.7: s/CIDR-like/CIDR allocated/ = s/this/to multiple
addresses/ s/may/will likely/ s/if/when/ s/from = SP/between sp/
Updated reference for renumbering proceedure to = RFC 4192
o Section 5: d/of these/
o Section 5.1: s/private enterprise/private = enterprise, academic,
research, or government / deleted redundant = discussion about /48
allocation / added discussion about larger = deployments using
tunneling /
o Section 5.2: clarification of overload on port = vs. protocol /
added comment about upstream NAT / clarified 3041 = use as short
timeframe
o Section 5.3: capitalize Internet
o Section 5.4: s/IPv4/IP as role is not version = specific / deleted
comment about preference to ULA.
o Section 6.1: (security) inserted section = discussing need for
dynamic pinhole management
o Section 6.2: (topology mask) added comment about = deployment scale
/ added comment about firewall blocking BU / = clarified point about
future work being an optimization to reduce = firewall load
o Section 6.3: (tracability) grammar = cleanup
o Section 6.4: (renumbering) Cut section since it = is no longer a gap
o Section A.2: word order - moved = 'only'
o Section A.6: deleted 'legitimate'
o Section A.7: clarified how NAP delivers community = of interest
o Spell check
=
Authors' Addresses Authors' Addresses
= Gunter Van de Velde Gunter Van de = Velde
= Cisco Systems Cisco Systems
= De Kleetlaan 6a De Kleetlaan = 6a
= Diegem 1831 Diegem 1831
= Belgium Belgium
= Phone: +32 2704 5473 Phone: +32 = 2704 5473
= Email: gunter@cisco.com Email: = gunter@cisco.com
=
skipping to change at page 36, line = 41 skipping to = change at page 42, line 41
= This document and the information contained herein are provided on = an This document and the = information contained herein are provided on an
= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE = REPRESENTS "AS IS" basis and THE = CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE = INTERNET OR IS SPONSORED BY (IF = ANY), THE INTERNET SOCIETY AND THE INTERNET
= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR = IMPLIED, ENGINEERING TASK FORCE = DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE = INCLUDING BUT NOT LIMITED TO ANY WARRANTY = THAT THE USE OF THE
= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED = INFORMATION HEREIN WILL NOT INFRINGE ANY = RIGHTS OR ANY IMPLIED
= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR = PURPOSE. WARRANTIES OF = MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
= Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
= to the rights, licenses and restrictions contained in BCP 78, = and to the rights, licenses and = restrictions contained in BCP 78, and
= except as set forth therein, the authors retain all their = rights. except as set forth = therein, the authors retain all their rights.
Acknowledgment Acknowledgment
= Funding for the RFC Editor function is currently provided by = the Funding for the RFC Editor = function is currently provided by the
= Internet Society. Internet = Society.
 End of changes. 137 change = blocks. 
629 lines changed or = deleted 883 lines changed or = added

This = html diff was produced by rfcdiff 1.32. The latest version is available = from http://www.levkowetz.com/ietf/tools/rfcdiff/
------=_NextPart_000_07FA_01C69C41.EC220E60-- From owner-v6ops@ops.ietf.org Fri Jun 30 16:57:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwQ3g-0007Wv-8a for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 16:57:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwQ3c-0000Jm-Np for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 16:57:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwQ1O-0005mp-Ii for v6ops-data@psg.com; Fri, 30 Jun 2006 20:55:26 +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=BAYES_00,DNS_FROM_RFC_POST, SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=no 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 1FwQ1L-0005m7-JA for v6ops@ops.ietf.org; Fri, 30 Jun 2006 20:55:23 +0000 Received: from ([172.27.14.137]) by mail04.frontiercorp.com with ESMTP id 4028772.73181690; Fri, 30 Jun 2006 16:26:48 -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: Fri, 30 Jun 2006 13:54:54 -0700 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D20295A689@wava00s2ke2k01.corp.pvt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v6 multihoming and route filters Thread-Index: AcacGKVmGiNwLGf4TG2szeKrqB2gfwAbeJ2Q From: "Azinger, Marla" To: "Fred Baker" Cc: "Pekka Savola" , , Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Fred- Thank you. If it read as a threat, I'am sorry. That isnt my = intent by any means. I meant it more like a factual progression. = Eventually someone with some solution will need to step forward. After = much debate on ppml it seemed as though many felt it should be resolved = at IETF, but if its not then something needs to be decided somewhere = else. I hope thats more clear, because I am not the threatening type. = So sorry for any bad wording I may have sent forward. I would really like to come to IETF and meet with the working group. = Thank you for asking. I will work on trying to find funding. My whole = intent is to try to help the situation and help work on a solution. Not = create angst. Thank you Marla Azinger -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Friday, June 30, 2006 12:40 AM To: Azinger, Marla Cc: Pekka Savola; v6ops@ops.ietf.org; ppml@arin.net Subject: Re: v6 multihoming and route filters My opinion - and please note that it is just that, not an edict of =20 any kinds - is that in the final analysis it is not the IETF but =20 operational reality that controls the issues here. If your customer =20 will pay you enough to advertise a prefix that you don't own and to =20 arrange corresponding ingress filter and route management with your =20 upstream networks, you're going to do so regardless of what any RFC =20 says, and it will in fact work because you will make the necessary =20 business and routing arrangements to support it. That said, the level =20 of effort involved will make the price fairly high, which means that =20 you will not be doing a lot of this. A "Best Current Practice" is not something with those business =20 constraints, I should think. By the way, threatening people is not a very convincing argument =20 style. If you want something done, how about helping us do it, and =20 honestly addressing the issues and concerns raised? What may have applicability is Steve Deering's concept of =20 Metropolitan Addressing, which it looks like someone needs to =20 describe in an Internet Draft (it is in the slides at ftp://=20 ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/=20 presentations/allocation/deering.slides.ps). In short, his proposal =20 was that a regional entity such as a civil community of some size =20 gets a prefix and the ISPs that serve it agree to carry its routes =20 such that a user can multihome within the community and outside it =20 one routes to the community. This scales in the same way that =20 Provider Addressing scales, with the caveats that each provider will =20 have full /48 (or /56 I imagine) routes for community on the set of =20 machines that serves it, and will need fairly explicit controls to =20 ensure that the routing doesn't leak. Would you like to come to the working group and discuss the issues =20 with us in Montreal? I think that would be more productive than this =20 discussion is being right now. On Jun 29, 2006, at 3:38 PM, Azinger, Marla wrote: > If the IETF V6ops WG doesn't give traction to this solution then =20 > this WG will push this to become resolved in other conference =20 > mediums. The charter for IETF appears to involve this type of work =20 > and to me appears to be the most appropriate place. > > There are a large number of people who would like to open filters =20 > to /48 so we can freely multihome. However, it is shut down =20 > comments like this that scare many people off from participating in =20 > discussion and using their voice to say what they would like to see =20 > done with routing. I may appear as one small voice, but there are =20 > allot of unheard ones out there that agree with the /48 filter. > > Due to the lack of another solution for upstream providers to =20 > provide multihoming, I see it as good solution. I also believe =20 > that this solution should be given serious consideration. Weigh =20 > out the pro's and con's. Not having a solution for upstream =20 > providers to provide multihoming is a very large con for not using =20 > an available solution today. Especially since without our V6 =20 > capable networks, v6 wont be routed or used at all. > > As for swamp. It won't be swamp if no other solution is created, =20 > and as of today their is large conflict over what solution and if =20 > that developed solution will even work. So it may never become =20 > swamp. And if it does, I'm sure we can adapt and overcome. > > Thank you for your time > Marla Azinger > Frontier Communications > > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, June 28, 2006 9:45 PM > To: Azinger, Marla > Cc: v6ops@ops.ietf.org > Subject: Re: v6 multihoming and route filters > > > autolearn=3Dham version=3D3.1.2 > X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on =20 > otso.netcore.fi > X-esp: ESP<17>=3DRBL:<22> SHA:<0> UHA:<0> SLS:<0> BAYES:<-5> =20 > SenderID:<0> Spam > Dictionary (TRU10):<0> Obscenities Dictionary (TRU10):<0> > Scam Dictionary (TRU10):<0> Adult Dictionary (TRU10):<0> > Embed HTML Dictionary (TRU10):<0> Float Dictionary > (TRU10):<0> HTML Dictionary (TRU10):<0> URL Real-Time > Signatures:<0> Spam Dictionary 2 (TRU10):<0> > Return-Path: pekkas@netcore.fi > X-OriginalArrivalTime: 29 Jun 2006 04:45:44.0168 (UTC) FILETIME=3D=20 > [E192EE80:01C69B36] > > On Wed, 28 Jun 2006, Azinger, Marla wrote: >> I ask the V6 WG to create a "best practice for multihoming" that can >> be utilized today. I ask that you please insert the solution to >> filter at /48 thus allowing "upstream providers" to provide >> multihoming to their customers. This solution is needed to support >> providers creating V6 networks and this solution can easily be added >> into Marc's "IP V6 Routing Policy Guidelines" document. > > This is unlikely to get traction in the WG. The initial draft was > basically like that but was changed. Many people (myself included) > opposed (and will oppose) recommeding opening filters up to /48. > > Let's not create a swamp out of v6 address space with more specific > 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 From owner-v6ops@ops.ietf.org Fri Jun 30 16:59:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwQ5M-0007aZ-8U for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 16:59:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwQ5H-0000Lh-Uj for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 16:59:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwQ58-0006I0-3l for v6ops-data@psg.com; Fri, 30 Jun 2006 20:59: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, FORGED_RCVD_HELO,SPF_HELO_PASS,SPF_PASS autolearn=ham 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 1FwQ57-0006Hm-55 for v6ops@ops.ietf.org; Fri, 30 Jun 2006 20:59:17 +0000 Received: from eaglet (127.0.0.1:2496) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Fri, 30 Jun 2006 13:58:56 -0700 From: "Tony Hain" To: "'Iljitsch van Beijnum'" , "'Fred Baker'" Cc: "'Azinger, Marla'" , "'Pekka Savola'" , , Subject: RE: v6 multihoming and route filters Date: Fri, 30 Jun 2006 13:59:07 -0700 Message-ID: <083d01c69c88$072b6e90$1c7ba8c0@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: AcacXeCPnd66g+c3Q1eTkR2dHW9bYwAKKE3A In-Reply-To: <955B63C3-3539-44E8-80F5-99EBAEBFD81B@muada.com> Sender: owner-v6ops@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Iljitsch van Beijnum wrote: > ... > 1. At some point in the future, the number of routes in the DFZ could > become so large that the routing system can't support it any more. > This is the scaling problem that many people in the IETF are worried > about. What keeps being overlooked here is that the concept of a global DFZ is artificial, and was originally specifically intended to sort out the players who could afford serious routers from the rest. There is no technical need for every organization to know the gory details of every other organization, the basis for maintain the myth is purely an ego driven desire to be considered a peer. > > > I've written a draft that takes this idea a bit further a couple of > years ago, have a look at: > > http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt That was good work looking at the alternatives. I have also been maintaining one without ties to political entities, currently draft-hain-ipv6-pi-addr-09.txt. At the end of the day we need to revisit the assumption that the only viable aggregation unit is provider based. There are trade-offs here, and with a small shift toward structured topology we could put a lid on the routing table problem. Tony From owner-v6ops@ops.ietf.org Fri Jun 30 20:10:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwT4K-0007Ln-Qh for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 20:10:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwT4J-0004jk-HY for v6ops-archive@lists.ietf.org; Fri, 30 Jun 2006 20:10:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FwT0G-0007RP-4z for v6ops-data@psg.com; Sat, 01 Jul 2006 00:06:28 +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 1FwT0F-0007RA-9m for v6ops@ops.ietf.org; Sat, 01 Jul 2006 00:06:27 +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 k6106Kvo094460 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 1 Jul 2006 02:06:21 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D202100D5D@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: v6ops@ops.ietf.org, ppml@arin.net Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: v6 multihoming and route filters Date: Sat, 1 Jul 2006 02:06:19 +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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Marla, On 28-jun-2006, at 21:32, Azinger, Marla wrote: > I currently have customers asking for this ability and none of them > wish to wait for solutions that may not be fully developed for a > couple more years. Also, my customers don't want to get PI space > (even under the new V6 PI policy), so this means I need to give > them a /48 and set up multihoming. However, as all policy and > practices sit right now, everyone filters on a /32. I see there is a long discussion on ppml that I hadn't noticed before about this subject. Scott Leibrand made some good points on both the usefulness and the limitations of multihoming using PA space. It's too bad that some others are pushing for PI. PI ALWAYS needs a place in the global routing table, while with shooting holes in PA, the more specific only needs to be visible in part of the network. As long as that part is big enough to provide reasonable multihoming benefits, this works out well of all parties involved. Unlike PI, PA multihoming is compatible with what we're trying to do in shim6, which may or may not be an advantage, but it can't hurt. (If anyone has questions about shim6, email me off-list.) Thinking in practical terms, I don't see an "allow all /48s" policy adopted by most network operators any time soon, as it commits them to something that may not give them trouble now, but has the potential to do so in the future. An alternative would be to come up with a BGP community to tag /48s that are used in multihoming so that it's possible to selectively allow those while still rejecting /48s that are deaggregated by accident. It will probably still take some time to get this adopted, but ISPs are smart enough to realize that more multihoming is more business for everyone, so I expect that something like this will be accepted unless there are problems that make this solution unattractive. I would be happy to co-author a document outlining this.