idnits 2.17.1 draft-ietf-v6ops-nap-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2071. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2089. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2095. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 10, 2007) is 6288 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC1918' on line 1632 -- Looks like a reference, but probably isn't: 'RFC3948' on line 1915 -- Looks like a reference, but probably isn't: 'RFC3041' on line 1919 == Unused Reference: '1' is defined on line 1368, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1379, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1397, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1405, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1408, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1416, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1426, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. '1') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '4') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '8') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '9') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '11') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '12') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '13') (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-chown-v6ops-renumber-thinkabout-03 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-11 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Van de Velde 3 Internet-Draft T. Hain 4 Intended status: Informational R. Droms 5 Expires: July 14, 2007 Cisco Systems 6 B. Carpenter 7 IBM 8 E. Klein 9 Tel Aviv University 10 January 10, 2007 12 Local Network Protection for IPv6 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 14, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2007). 44 Abstract 46 Although there are many perceived benefits to Network Address 47 Translation (NAT), its primary benefit of "amplifying" available 48 address space is not needed in IPv6. In addition to NAT's many 49 serious disadvantages, there is a perception that other benefits 50 exist, such as a variety of management and security attributes that 51 could be useful for an Internet Protocol site. IPv6 was designed 52 with the intention of making NAT unnecessary, and this document shows 53 how Local Network Protection (LNP) using IPv6 can provide the same or 54 more benefits without the need for address translation. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 7 60 2.1. Simple Gateway between Internet and Private Network . . . 7 61 2.2. Simple Security due to Stateful Filter Implementation . . 7 62 2.3. User/Application tracking . . . . . . . . . . . . . . . . 8 63 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 9 64 2.5. Independent Control of Addressing in a Private Network . . 10 65 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 10 66 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 11 67 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 12 68 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 12 69 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 13 70 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 14 71 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 14 72 4. Using IPv6 Technology to Provide the Market Perceived 73 Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.1. Simple Gateway between Internet and Internal Network . . . 15 75 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15 76 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 18 77 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 18 78 4.5. Independent Control of Addressing in a Private Network . . 21 79 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 22 80 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 22 81 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 5.1. Medium/large private networks . . . . . . . . . . . . . . 23 83 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 25 84 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 26 85 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 27 86 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 28 87 6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 28 88 6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 28 89 6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 29 90 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 29 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 93 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 31 98 Appendix A. Additional Benefits due to Native IPv6 and 99 Universal Unique Addressing . . . . . . . . . . . . . 32 100 A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 33 101 A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 33 102 A.3. Native Multicast Services . . . . . . . . . . . . . . . . 33 103 A.4. Increased Security Protection . . . . . . . . . . . . . . 34 104 A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34 105 A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 35 106 Appendix B. Revision history . . . . . . . . . . . . . . . . . . 35 107 B.1. Changes from *-vandevelde-v6ops-nap-00 to 108 *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 35 109 B.2. Changes from *-vandevelde-v6ops-nap-01 to 110 *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 35 111 B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 35 112 B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 36 113 B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 . 40 114 B.6. Changes from *-ietf-v6ops-nap-03 to *-ietf-v6ops-nap-04 . 42 115 B.7. Changes from *-ietf-v6ops-nap-04 to *-ietf-v6ops-nap-05 . 43 116 B.8. Changes from *-ietf-v6ops-nap-05 to *-ietf-v6ops-nap-06 . 44 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 118 Intellectual Property and Copyright Statements . . . . . . . . . . 46 120 1. Introduction 122 There have been periodic claims that IPv6 will require a Network 123 Address Translation (NAT), because network administrators use NAT to 124 meet a variety of needs when using IPv4 and those needs will also 125 have to be met when using IPv6. Although there are many perceived 126 benefits to NAT, its primary benefit of "amplifying" available 127 address space is not needed in IPv6. The serious disadvantages and 128 impact on applications by ambiguous address space and Network Address 129 Translation [2] [6]have been well documented [5] [7]so there will not 130 be much additional discussion here. However, given its wide 131 deployment NAT undoubtedly has some perceived benefits, though the 132 bulk of those using it have not evaluated the technical trade-offs. 133 Indeed, it is often claimed that some connectivity and security 134 concerns can only be solved by using a NAT device, without any 135 mention of the negative impacts on applications. This is amplified 136 through the widespread sharing of vendor best practice documents and 137 sample configurations that do not differentiate the translation 138 function of address expansion from the state function of limiting 139 connectivity. 141 This document describes the uses of a NAT device in an IPv4 142 environment that are regularly cited as 'solutions' for perceived 143 problems. It then shows how the goals of the network manager can be 144 met in an IPv6 network without using the header modification feature 145 of NAT. It should be noted that this document is 'informational', as 146 it discusses approaches that will work to accomplish the goals of the 147 network manager. It is specifically not a BCP that is recommending 148 any one approach, or a manual on how to configure a network. 150 As far as security and privacy are concerned, this document considers 151 how to mitigate a number of threats. Some are obviously external, 152 such as having a hacker or a worm infected machine outside trying to 153 penetrate and attack the local network. Some are local such as a 154 disgruntled employee disrupting business operations, or the 155 unintentional negligence of a user downloading some malware which 156 then proceeds to attack from within. Some may be inherent in the 157 device hardware ("embedded") such as having some firmware in a 158 domestic appliance "call home" to its manufacturer without the user's 159 consent. 161 Another consideration discussed is the view that NAT can be used to 162 fulfill the goals of a security policy. On the one hand, NAT does 163 satisfy some policy goals, such as topology hiding; at the same time 164 it defeats others, such as the ability to produce an end-to-end audit 165 trail at network level. That said, there are artifacts of NAT 166 devices that do provide some value. 168 1. The need to establish state before anything gets through from 169 outside to inside solves one set of problems. 170 2. The expiration of state to stop receiving any packets when 171 finished with a flow solves a set of problems 172 3. The ability for nodes to appear to be attached at the edge of the 173 network solves a set of problems 174 4. The ability to have addresses that are not publicly routed solves 175 yet another set (mostly changes where the state is and scale 176 requirements for the first one). 178 This document describes several techniques that may be combined in an 179 IPv6 deployment to protect the integrity of its network architecture. 180 It will focus on the 'how to accomplish a goal' perspective, leaving 181 most of the 'why that goal is useful' perspective for other 182 documents. These techniques, known collectively as Local Network 183 Protection (LNP), retain the concept of a well defined boundary 184 between "inside" and "outside" the private network, while allowing 185 firewalling, topology hiding, and privacy. LNP will achieve these 186 security goals without address translation whilst regaining the 187 ability for arbitrary any-to-any connectivity. 189 IPv6 Local Network Protection can be summarized in the following 190 table. It presents the marketed benefits of IPv4+NAT with a cross- 191 reference of how those are delivered in both the IPv4 and IPv6 192 environments. 194 Goal IPv4 IPv6 195 +------------------+-----------------------+-----------------------+ 196 | Simple Gateway | DHCP - single | DHCP-PD - arbitrary | 197 | as default router| address upstream | length customer | 198 | and address pool | DHCP - limited | prefix upstream | 199 | manager | number of individual | SLAAC via RA | 200 | | devices downstream | downstream | 201 | | see section 2.1 | see section 4.1 | 202 +------------------|-----------------------|-----------------------+ 203 | Simple Security | Filtering side | Explicit Context | 204 | | effect due to lack | Based Access Control | 205 | | of translation state | (Reflexive ACL) | 206 | | see section 2.2 | see section 4.2 | 207 +------------------|-----------------------|-----------------------+ 208 | Local usage | NAT state table | Address uniqueness | 209 | tracking | | | 210 | | see section 2.3 | see section 4.3 | 211 +------------------|-----------------------|-----------------------+ 212 | End-system | NAT transforms | Temporary use | 213 | privacy | device ID bits in | privacy addresses | 214 | | the address | | 215 | | see section 2.4 | see section 4.4 | 216 +------------------|-----------------------|-----------------------+ 217 | Topology hiding | NAT transforms | Untraceable addresses| 218 | | subnet bits in the | using IGP host routes| 219 | | address | /or MIPv6 tunnels | 220 | | see section 2.4 | see section 4.4 | 221 +------------------|-----------------------|-----------------------+ 222 | Addressing | RFC 1918 | RFC 3177 & 4193 | 223 | Autonomy | see section 2.5 | see section 4.5 | 224 +------------------|-----------------------|-----------------------+ 225 | Global Address | RFC 1918 | 17*10^18 subnets | 226 | Pool | << 2^48 application | 3.4*10^38 addresses | 227 | Conservation | end points | full port list / addr | 228 | | topology restricted | unrestricted topology | 229 | | see section 2.6 | see section 4.6 | 230 +------------------|-----------------------|-----------------------+ 231 | Renumbering and | Address translation | Preferred lifetime | 232 | Multi-homing | at border | per prefix & Multiple| 233 | | | addresses per | 234 | | | interface | 235 | | see section 2.7 | see section 4.7 | 236 +------------------+-----------------------+-----------------------+ 238 This document first identifies the perceived benefits of NAT in more 239 detail, and then shows how IPv6 LNP can provide each of them. It 240 concludes with a IPv6 LNP case study and a gap analysis of standards 241 work that remains to be done for an optimal LNP solution. 243 2. Perceived Benefits of NAT and its Impact on IPv4 245 This section provides insight into the generally perceived benefits 246 of the use of IPv4 NAT. The goal of this description is not to 247 analyze these benefits or the accuracy of the perception (detailed 248 discussions in [5]), but to describe the deployment requirements and 249 set a context for the later descriptions of the IPv6 approaches for 250 dealing with those requirements. 252 2.1. Simple Gateway between Internet and Private Network 254 A NAT device can connect a private network with addresses allocated 255 from any part of the space (ambiguous [2]or global registered & 256 unregistered address) towards the Internet, though extra effort is 257 needed when the same range exists on both sides of the NAT. The 258 address space of the private network can be built from globally 259 unique addresses, from ambiguous address space or from both 260 simultaneously. In the simple case of private use addresses, without 261 needing specific configuration the NAT device enables access between 262 the client side of a distributed client-server application in the 263 private network and the server side located in the public Internet. 265 Wide-scale deployments have shown that using NAT to act as a simple 266 gateway attaching a private IPv4 network to the Internet is simple 267 and practical for the non-technical end user. Frequently a simple 268 user interface, or even a default configuration is sufficient for 269 configuring both device and application access rights. 271 This simplicity comes at a price, as the resulting topology puts 272 restrictions on applications. The NAT simplicity works well when the 273 applications are limited to a client/server model with the server 274 deployed on the public side of the NAT. For peer-to-peer, multi- 275 party, or servers deployed on the private side of the NAT, helper 276 technologies must also be deployed. These helper technologies are 277 frequently complex to develop and manage, creating a hidden cost to 278 this 'simple gateway'. 280 2.2. Simple Security due to Stateful Filter Implementation 282 It is frequently believed that through its session-oriented 283 operation, NAT puts in an extra barrier to keep the private network 284 protected from outside influences. Since a NAT device typically 285 keeps state only for individual sessions, attackers, worms, etc. 287 cannot exploit this state to attack a specific host on any other 288 port, though in the port overload case of NAPT attacking all active 289 ports will impact a potentially wide number of hosts. This benefit 290 may be partially real, however, experienced hackers are well aware of 291 NAT devices and are very familiar with private address space, and 292 have devised methods of attack (such as trojan horses) that readily 293 penetrate NAT boundaries. While the stateful filtering offered by 294 NAT offers a measure of protection against a variety of 295 straightforward network attacks, it does not protect against all 296 attacks despite being presented as a one-size-fits-all answer. 298 The act of translating address bits within the header does not 299 provide security in itself. For example consider a configuration 300 with static NAT translation and all inbound ports translating to a 301 single machine. In such a scenario the security risk for that 302 machine is identical to the case with no NAT device in the 303 communication path, as any connection to the pubic address will be 304 delivered to the mapped target. 306 The perceived security of NAT comes from the lack of pre- established 307 or permanent mapping state. This is often used as a 'better than 308 nothing' level of protection because it doesn't require complex 309 management to filter out unwanted traffic. Dynamically establishing 310 state in response to internal requests reduces the threat of 311 unexpected external connections to internal devices, and this level 312 of protection would also be available from a basic firewall. (A 313 basic firewall, supporting clients accessing public side servers, 314 would improve on that level of protection by avoiding the problem of 315 state persisting as different clients use the same private side 316 address over time.) This role, often marketed as a firewall, is 317 really an arbitrary artifact while a real firewall has often offers 318 explicit and more comprehensive management controls. 320 In some cases, NAT operators (including domestic users) may be 321 obliged to configure quite complex port mapping rules to allow 322 external access to local applications such as a multi-player game or 323 web servers. In this case the NAT actually adds management 324 complexity compared to the simple router discussed in 2.1. In 325 situations where two or more devices need to host the same 326 application or otherwise use the same public port, this complexity 327 shifts from difficult to impossible. 329 2.3. User/Application tracking 331 One usage of NAT is for the local network administrator to track user 332 and application traffic. Although NATs create temporary state for 333 active sessions, in general they provide limited capabilities for the 334 administrator of the NAT to gather information about who in the 335 private network is requesting access to which Internet location. 336 This is done by periodically logging the network address translation 337 details of the private and the public addresses from the NAT device's 338 state database. 340 The subsequent checking of this database is not always a simple task, 341 especially if Port Address Translation is used. It also has an 342 unstated assumption that the administrative instance has a mapping 343 between a private IPv4-address and a network element or user at all 344 times, or the administrator has a time-correlated list of the 345 address/port mappings. 347 2.4. Privacy and Topology Hiding 349 One goal of 'topology hiding' is to prevent external entities from 350 making a correlation between the topological location of devices on 351 the local network. The ability of NAT to provide Internet access to 352 a large community of users by the use of a single (or a few) global 353 IPv4 routable address(es) offers a simple mechanism to hide the 354 internal topology of a network. In this scenario the large community 355 will be represented in the Internet by a single (or a few) IPv4 356 address(es). 358 By using NAT a system appears to the Internet as if it originated 359 inside the NAT box itself; i.e., the IPv4 address that appears on the 360 Internet is only sufficient to identify the NAT so all internal nodes 361 appear to exist at the demarcation edge. When concealed behind a NAT 362 it is impossible to tell from the outside which member of a family, 363 which customer of an Internet cafe, or which employee of a company 364 generated or received a particular packet. Thus, although NATs do 365 nothing to provide application level privacy, they do prevent the 366 external tracking and profiling of individual systems by means of 367 their IP addresses, usually known as 'device profiling'. 369 There is a similarity with privacy based on application level 370 proxies. When using an application level gateway for browsing the 371 web for example, the 'privacy' of a web user can be provided by 372 masking the true identity of the original web user towards the 373 outside world (although the details of what is - or is not - logged 374 at the NAT/proxy will be different). 376 Some network managers prefer to hide as much as possible of their 377 internal network topology from outsiders as a useful precaution to 378 mitigate scanning attacks. Mostly this is achieved by blocking 379 "traceroute" etc., though NAT entirely hides the internal subnet 380 topology. Scanning is a particular concern in IPv4 networks because 381 the subnet size is small enough that once the topology is known it is 382 easy to find all the hosts, then start scanning them for vulnerable 383 ports. Once a list of available devices has been mapped, a port-scan 384 on these IP addresses can be performed. Scanning works by tracking 385 which ports do not receive unreachable errors from either the 386 firewall or host. With the list of open ports an attacker can 387 optimize the time needed for a successful attack by correlating it 388 with known vulnerabilities to reduce the number of attempts. For 389 example, FTP usually runs on port 21, and HTTP usually runs on port 390 80. Any vulnerable open ports could be used for access to an end 391 system to command it to start initiating attacks on others. 393 2.5. Independent Control of Addressing in a Private Network 395 Many private IPv4 networks make use of the address space defined in 396 RFC 1918 to enlarge the available addressing space for their private 397 network, and at the same time reduce their need for globally routable 398 addresses. This type of local control of address resources allows a 399 sufficiently large pool for a clean and hierarchical addressing 400 structure in the local network. 402 Another benefit is the ability to change providers with minimal 403 operational difficulty due to the usage of independent addresses on 404 majority of the network infrastructure. Changing the addresses on 405 the public side of the NAT avoids the administrative challenge of 406 changing every device in the network. 408 Section 2.7 describes some disadvantages that appear if independent 409 networks using ambiguous addresses [2]have to be merged. 411 2.6. Global Address Pool Conservation 413 While the widespread use of IPv4+NAT has reduced the potential 414 consumption rate, the ongoing depletion of the IPv4 address range has 415 already taken the remaining pool of unallocated IPv4 addresses well 416 below 25%. While mathematical models based on historical IPv4 prefix 417 consumption periodically attempt to predict the future exhaustion 418 date of the IPv4 address pool, a direct result of this continuous 419 resource consumption is that the administrative overhead for 420 acquiring globally unique IPv4 addresses will continue increasing in 421 direct response to tightening allocation policies. 423 In response to the increasing administrative overhead many Internet 424 Service Providers (ISPs) have already resorted to the ambiguous 425 addresses defined in RFC 1918 behind a NAT for the various services 426 they provide as well as connections for their end customers. This 427 happens even though the private use address-space is strictly limited 428 in size. Some deployments have already outgrown that space and have 429 begun cascading NAT to continue expanding, though this practice 430 eventually breaks down over routing ambiguity. Additionally, while 431 we are unlikely to know the full extent of the practice (because it 432 is hidden behind a nat), service providers have been known to 433 announce previously unallocated public space to their customers (to 434 avoid the problems associated with the same address space appearing 435 on both sides), only to find that once that space was formally 436 allocated and being publicly announced their customers couldn't reach 437 the registered networks. 439 The number of and types of applications that can be deployed by these 440 ISPs and their customers is restricted by the ability to overload the 441 port range on the public side of the most public NAT in the path. 442 The limit of this approach is something substantially less than 2^48 443 possible active **application** endpoints (approximately [2^32 minus 444 2^29] * [2* 2^16 minus well known port space]), as distinct from 445 addressable devices each with their own application endpoint range. 446 Those who advocate layering of NAT frequently forget to mention that 447 there are topology restrictions placed on the applications. Forced 448 into this limiting situation such customers can rightly claim that 449 despite the optimistic predictions of mathematical models, the global 450 pool of IPv4 addresses is effectively already exhausted. 452 2.7. Multihoming and Renumbering with NAT 454 Allowing a network to be multihomed and renumbering a network are 455 quite different functions. However these are argued together as 456 reasons for using NAT, because making a network multihomed is often a 457 transitional state required as part of network renumbering, and NAT 458 interacts with both in the same way. 460 For enterprise networks, it is highly desirable to provide resiliency 461 and load-balancing to be connected to more than one Internet Service 462 Provider (ISP) and to be able to change ISPs at will. This means 463 that a site must be able to operate under more than one CIDR prefix 464 [1]and/or readily change its CIDR prefix. Unfortunately, IPv4 was 465 not designed to facilitate either of these maneuvers. However, if a 466 site is connected to its ISPs via NAT boxes, only those boxes need to 467 deal with multihoming and renumbering issues. 469 Similarly, if two enterprise IPv4 networks need to be merged and 470 RFC1918 addresses are used, there is a high probability of address 471 overlaps. In those situations it may well be that installing a NAT 472 box between them will avoid the need to renumber one or both. For 473 any enterprise, this can be a short term financial saving, and allow 474 more time to renumber the network components. The long term solution 475 is a single network without usage of NAT to avoid the ongoing 476 operational complexity of overlapping addresses. 478 The addition of an extra NAT as a solution may be sufficient for some 479 networks; however when the merging networks were already using 480 address translation it will create major problems due to 481 administrative difficulties of overlapping address spaces in the 482 merged networks. 484 3. Description of the IPv6 Tools 486 This section describes several features that can be used as part of 487 the LNP solution to replace the protection features associated with 488 IPv4 NAT. 490 The reader must clearly distinguish between features of IPv6 that 491 were fully defined when this document was drafted and those that were 492 potential features that still required more work to define them. The 493 latter are summarized later in the 'Gap Analysis' section of this 494 document. However, we do not distinguish in this document between 495 fully defined features of IPv6 and those that were already widely 496 implemented at the time of writing. 498 3.1. Privacy Addresses (RFC 3041) 500 There are situations where it is desirable to prevent device 501 profiling, for example by web sites that are accessed from the device 502 as it moves around the Internet. IPv6 privacy addresses were defined 503 to provide that capability. IPv6 addresses consist of a routing 504 prefix, subnet-id part (SID) and an interface identifier part (IID). 505 As originally defined, IPv6 stateless address auto-configuration 506 (SLAAC) will typically embed the IEEE Link Identifier of the 507 interface as the IID part, though this practice facilitates tracking 508 and profiling of a device through the consistent IID. RFC 3041 509 [8]describes an extension to SLAAC to enhance device privacy. Use of 510 the privacy address extension causes nodes to generate global-scope 511 addresses from interface identifiers that change over time, 512 consistent with system administrator policy. Changing the interface 513 identifier (thus the global-scope addresses generated from it) over 514 time makes it more difficult for eavesdroppers and other information 515 collectors to identify when addresses used in different transactions 516 actually correspond to the same node. A relatively short valid 517 lifetime for the privacy address also has the effect of reducing the 518 attack profile of a device, as it is not directly attackable once it 519 stops answering at the temporary use address. 521 While the primary implementation and source of randomized RFC 3041 522 addresses is expected to be from end-systems running stateless auto- 523 configuration, there is nothing that prevents a DHCP server from 524 running the RFC 3041 algorithm for any new IEEE identifier it hears 525 in a request, then remembering that for future queries. This would 526 allow using them in DNS for registered services since the assumption 527 of a DHCP server based deployment would be a persistent value that 528 minimizes DNS churn. A DHCP based deployment would also allow for 529 local policy to periodically change the entire collection of end 530 device addresses while maintaining some degree of central knowledge 531 and control over which addresses should be in use at any point in 532 time. 534 Randomizing the IID, as defined in RFC 3041, is effectively a sparse 535 allocation technique which only precludes tracking of the lower 64 536 bits of the IPv6 address. Masking of the subnet ID will require 537 additional approaches as discussed below in 3.4. Additional 538 considerations are discussed in [19]. 540 3.2. Unique Local Addresses 542 Achieving the goal of autonomy, that many perceive as a value of NAT, 543 is required for local network and application services stability 544 during periods of intermittent connectivity or moving between one or 545 more providers. Such autonomy in a single routing prefix environment 546 would lead to massive expansion of the global routing tables (as seen 547 in IPv4), so IPv6 provides for simultaneous use of multiple prefixes. 548 The Unique Local Address prefix (ULA) [18]has been set aside for use 549 in local communications. The ULA address prefix for any network is 550 routable over a locally defined collection of routers. These 551 prefixes are not intended to be routed on the public global Internet 552 as large scale inter-domain distribution of routes for ULA prefixes 553 would have a negative impact on global route aggregation. 555 ULAs have the following characteristics: 556 o For all practical purposes a globally unique prefix 557 * Allows networks to be combined or privately interconnected 558 without creating address conflicts or requiring renumbering of 559 interfaces using these prefixes 560 * If accidentally leaked outside of a network via routing or DNS, 561 it is highly unlikely that there will be a conflict with any 562 other addresses 563 o ISP independent and can be used for communications inside of a 564 network without having any permanent or only intermittent Internet 565 connectivity 566 o Well-known prefix to allow for easy filtering at network 567 boundaries preventing leakage of routes and packets that should 568 remain local. 569 o In practice, applications may treat these addresses like global 570 scoped addresses but address selection algorithms may need to 571 distinguish between ULAs and ordinary global scope unicast 572 addresses to assure stability. The policy table defined in [12]is 573 one way to bias this selection, by giving higher preference to 574 FC00::/7 over 2001::/3. Mixing the two kinds of addresses may 575 lead to undeliverable packets during times of instability, but 576 that mixing is not likely to happen when the rules of RFC 3484 are 577 followed. 578 o ULAs have no intrinsic security properties. However, they have 579 the useful property that their routing scope is limited by default 580 within an administrative boundary. Their usage is suggested at 581 several points in this document, as a matter of administrative 582 convenience. 584 3.3. DHCPv6 Prefix Delegation 586 One of the functions of a simple gateway is managing the local use 587 address range. The Prefix Delegation (DHCP-PD) options [13]provide a 588 mechanism for automated delegation of IPv6 prefixes using the Dynamic 589 Host Configuration Protocol (DHCP) [11]. This mechanism (DHCP-PD) is 590 intended for delegating a long-lived prefix from a delegating router 591 (possibly incorporating a DHCPv6 server) to a requesting router, 592 possibly across an administrative boundary, where the delegating 593 router does not require knowledge about the topology of the links in 594 the network to which the prefixes will be assigned. 596 3.4. Untraceable IPv6 Addresses 598 The main goal of untraceable IPv6 addresses is to create an 599 apparently amorphous network infrastructure, as seen from external 600 networks, to protect the local infrastructure from malicious outside 601 influences and from mapping of any correlation between the network 602 activities of multiple devices from external networks. When using 603 untraceable IPv6 addresses, it could be that two apparently 604 sequential addresses are allocated to devices on very different parts 605 of the local network instead of belonging to devices adjacent to each 606 other on the same subnet. 608 Since IPv6 addresses will not be in short supply even within a single 609 /64 (or shorter) prefix, it is possible to generate them effectively 610 at random when untraceability is required. They will be globally 611 routable IPv6 addresses under the site's prefix, which can be 612 randomly and independently assigned to IPv6 devices. The random 613 assignment is intended to mislead the outside world about the 614 structure of the local network. In particular the subnet structure 615 may be invisible in the address. Thus a flat routing mechanism will 616 be needed within the site. The local routers need to maintain a 617 correlation between the topological location of the device and the 618 untraceable IPv6 address. For smaller deployments this correlation 619 could be done by generating IPv6 host route entries, or for larger 620 ones by utilizing an indirection device such as a Mobile IPv6 Home 621 Agent. Additional details are in section 4.7. 623 4. Using IPv6 Technology to Provide the Market Perceived Benefits of 624 NAT 626 The facilities in IPv6 described in Section 3 can be used to provide 627 the protection perceived to be associated with IPv4 NAT. This 628 section gives some examples of how IPv6 can be used securely. 630 4.1. Simple Gateway between Internet and Internal Network 632 As a simple gateway, the device manages both packet routing and local 633 address management. A basic IPv6 router should have a default 634 configuration to advertise inside the site a locally generated random 635 ULA prefix, independently from the state of any external 636 connectivity. This would allow local nodes in a topology more 637 complex than a single link to communicate amongst themselves 638 independent of the state of a global connection. If the network 639 happened to concatenate with another local network, the randomness in 640 ULA creation is highly unlikely to result in address collisions. 642 With external connectivity the simple gateway should use DHCP-PD to 643 acquire a routing prefix from the service provider for use when 644 connecting to the global Internet. End-system connections involving 645 other nodes on the global Internet that follow the policy table in 646 RFC 3484 will always use the global IPv6 addresses derived from this 647 prefix delegation. It should be noted that the address selection 648 policy table should be configured to prefer the ULA prefix range over 649 the DHCP-PD prefix range when the goal is to keep local 650 communications stable during periods of transient external 651 connectivity. 653 In the very simple case there is no explicit routing protocol on 654 either side of the gateway, and a single default route is used 655 internally pointing out to the global Internet. A slightly more 656 complex case might involve local internal routing protocols, but with 657 the entire local network sharing a common global prefix there would 658 still not be a need for an external routing protocol as the service 659 provider could install a route for the prefix delegated via DHCP-PD 660 pointing toward the connecting link. 662 4.2. IPv6 and Simple Security 664 The vulnerability of an IPv6 host directly connected towards the 665 Internet is similar to that of an IPv4 host. The use of firewall and 666 Intrusion Detection Systems (IDS) is recommended for those that want 667 boundary protection in addition to host defenses. A proxy may be 668 used for certain applications, but with the caveat that the end to 669 end transparency is broken. However, with IPv6, the following 670 protections are available without the use of NAT while maintaining 671 end-to-end reachability: 672 1. Short lifetimes on privacy extension suffixes reduce the attack 673 profile since the node will not respond to the address once its 674 lifetime becomes invalid. 675 2. IPsec is often cited as the reason for improved security because 676 it is a mandatory service for IPv6 implementations. Broader 677 availability does not by itself improve security because its use 678 is still regulated by the availability of a key infrastructure. 679 IPsec functions to authenticate the correspondent, prevent 680 session hijacking, prevent content tampering, and optionally 681 masks the packet contents. While IPsec is commonly available in 682 some IPv4 implementations and with extensions can support NAT 683 traversals, NAT support has limitations and does not work in all 684 situations. The use of IPsec with NATs requires an additional 685 UDP encapsulation and keepalive overhead [14]. In the IPv4/NAT 686 environment, the usage of IPSec has been largely limited to edge- 687 to-edge VPN deployments. The potential for end-to-end IPsec use 688 is significantly enhanced when NAT is removed from the network, 689 as connections can be initiated from either end. It should be 690 noted that encrypted IPsec traffic will bypass content-aware 691 firewalls, which is presumed to be acceptable for parties with 692 whom the site has established a security association. 693 3. The size of the address space of a typical subnet (64 bits of 694 IID) will make a complete subnet ping sweep usually significantly 695 harder and more expensive than for IPv4[20]. Reducing the 696 security threat of port scans on identified nodes requires sparse 697 distribution within the subnet to minimize the probability of 698 scans finding adjacent nodes. This scanning protection will be 699 nullified if IIDs are configured in any structured groupings 700 within the IID space. Provided that IIDs are essentially 701 randomly distributed across the available space, address scanning 702 based attacks will effectively fail. This protection exists if 703 the attacker has no direct access to the specific subnet and 704 therefore is trying to scan it remotely. If an attacker has 705 local access then he could use ND [4]and ping6 to the link-scope 706 multicast ff02::1 to detect the IEEE based address of local 707 neighbors, then apply the global prefix to those to simplify its 708 search (of course, a locally connected attacker has many scanning 709 options with IPv4 as well). 711 Assuming the network administrator is aware of [20]the increased size 712 of the IPv6 address will make topology probing much harder, and 713 almost impossible for IPv6 devices. The intention of topology 714 probing is to identify a selection of the available hosts inside an 715 enterprise. This mostly starts with a ping-sweep. Since the IPv6 716 subnets are 64 bits worth of address space, this means that an 717 attacker has to send out a simply unrealistic number of pings to map 718 the network, and virus/worm propagation will be thwarted in the 719 process. At full-rate full-duplex 40Gbps (400 times the typical 720 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it 721 takes over 5000 years to scan the entirety of a single 64 bit subnet. 723 IPv4 NAT was not developed as a security mechanism. Despite 724 marketing messages to the contrary it is not a security mechanism, 725 and hence it will offer some security holes while many people assume 726 their network is secure due to the usage of NAT. IPv6 security best 727 practices will avoid this kind of illusory security but can only 728 address the same threats if correctly configured firewalls and IDS 729 systems are used at the perimeter. 731 It must be noted that even a firewall doesn't fully secure 732 a network. Many attacks come from inside or are at a layer 733 higher than the firewall can protect against. In the final 734 analysis, every system has to be responsible for its own 735 security, and every process running on a system has to be 736 robust in the face of challenges like stack overflows etc. 737 What a firewall does is prevent a network administration 738 from having to carry unauthorized 739 traffic, and in so doing reduce the probability of certain 740 kinds of attacks across the protected boundary. 742 To implement simple security for IPv6 in, for example a DSL or Cable 743 Modem connected home network, the broadband gateway/router should be 744 equipped with stateful firewall capabilities. These should provide a 745 default configuration where incoming traffic is limited to return 746 traffic resulting from outgoing packets (sometimes known as 747 reflective session state). There should also be an easy interface 748 which allows users to create inbound 'pinholes' for specific purposes 749 such as online-gaming. 751 Administrators and the designers of configuration interfaces for 752 simple IPv6 firewalls need to provide a means of documenting the 753 security caveats that arise from a given set configuration rules so 754 that users (who are normally oblivious to such things) can be made 755 aware of the risks. As rules are improved iteratively, the goal will 756 be to make use of the IPv6 Internet more secure without increasing 757 the perceived complexity for users who just want to accomplish a 758 task. 760 4.3. User/Application Tracking 762 IPv6 enables the collection of information about data flows. Due to 763 the fact that all addresses used for Internet and intra-/inter- site 764 communication are unique, it is possible for an enterprise or ISP to 765 get very detailed information on any communication exchange between 766 two or more devices. Unless privacy addresses [8]are in use, this 767 enhances the capability of data- flow tracking for security audits 768 compared with IPv4 NAT, because in IPv6 a flow between a sender and 769 receiver will always be uniquely identified due to the unique IPv6 770 source and destination addresses. 772 At the same time, this tracking is per address. In environments 773 where the goal is tracking back to the user, additional external 774 information will be necessary correlating a user with an address. In 775 the case of short lifetime privacy address usage, this external 776 information will need to be based on more stable information such as 777 the layer 2 media address. 779 4.4. Privacy and Topology Hiding using IPv6 781 Partial host privacy is achieved in IPv6 using RFC 3041 pseudo-random 782 privacy addresses [8]which are generated as required, so that a 783 session can use an address that is valid only for a limited time. 784 This only allows such a session to be traced back to the subnet that 785 originates it, but not immediately to the actual host, where IPv4 NAT 786 is only traceable to the most public NAT interface. 788 Due to the large IPv6 address space available there is plenty of 789 freedom to randomize subnet allocations. By doing this, it is 790 possible to reduce the correlation between a subnet and its location. 791 When doing both subnet and IID randomization a casual snooper won't 792 be able to deduce much about the networks topology. The obtaining of 793 a single address will tell the snooper very little about other 794 addresses. This is different from IPv4 where address space 795 limitations cause this to be not true. In most usage cases this 796 concept should be sufficient for address privacy and topology hiding, 797 with the cost being a more complex internal routing configuration. 799 As discussed in Section 3.1, there are multiple parts to the IPv6 800 address, and different techniques to manage privacy for each which 801 may be combined to protect the entire address. In the case where a 802 network administrator wishes to fully isolate the internal IPv6 803 topology, and the majority of its internal use addresses, one option 804 is to run all internal traffic using Unique Local Addresses (ULA). 805 By definition this prefix block is not to be advertised into the 806 public routing system, so without a routing path external traffic 807 will never reach the site. For the set of hosts that do in fact need 808 to interact externally, by using multiple IPv6 prefixes (ULAs and one 809 or more global addresses) all of the internal nodes that do not need 810 external connectivity, and the internally used addresses of those 811 that do will be masked from the outside. The policy table defined in 812 [12]provides a mechanism to bias the selection process when multiple 813 prefixes are in use such that the ULA would be preferred when the 814 correspondent is also local. 816 There are other scenarios for the extreme situation when a network 817 manager also wishes to fully conceal the internal IPv6 topology. In 818 these cases the goal in replacing the IPv4 NAT approach is to make 819 all of the topology hidden nodes appear from the outside to logically 820 exist at the edge of the network, just as they would when behind a 821 NAT. This figure shows the relationship between the logical subnets 822 and the topology masking router discussed in the bullet points that 823 follow. 825 Internet 826 | 827 \ 828 | 829 +------------------+ 830 | topology |-+-+-+-+-+-+-+-+-- 831 | masking | Logical subnets 832 | router |-+-+-+-+-+-+-+-+-- 833 +------------------+ for topology 834 | hidden nodes 835 | 836 Real internal -------------+- 837 topology | | 838 | -+---------- 839 -----------+--------+ 840 | 841 | 842 | 844 o One approach uses explicit host routes in the IGP to remove the 845 external correlation between physical topology attachment point 846 and end-to-end IPv6 address. In the figure above the hosts would 847 be allocated prefixes from one or more logical subnets, and would 848 inject host routes into the IGP to internally identify their real 849 attachment point. This solution does however show severe 850 scalability issues and requires hosts to securely participate in 851 the IGP, as well as having the firewall block all external to 852 internal traceroute for the logical subnet. The specific 853 limitations are dependent on the IGP protocol, the physical 854 topology, and the stability of the system. In any case the 855 approach should be limited to uses with substantially fewer than 856 the maximum number of routes that the IGP can support (generally 857 between 5,000 and 50,000 total entries including subnet routes). 858 Hosts should also listen to the IGP for duplicate use before 859 finalizing an interface address assignment as the duplicate 860 address detection will only check for use on the attached segment, 861 not the logical subnet. 862 o Another technical approach to fully hide the internal topology is 863 use of a tunneling mechanism. Mobile IPv6 without route 864 optimization is one approach for using an automated tunnel, as it 865 always starts in tunnel mode via the Home Agent (HA). In this 866 deployment model the application perceived addresses of the nodes 867 are routed via the edge HA acting as the topology masking router 868 (above). This indirection method truly masks the internal 869 topology, as from outside the local network all nodes with global 870 access appear to share the prefix of one or more logical subnets 871 attached to the HA rather than their real attachment point. Note 872 that in this usage context the HA is replacing the NAT function at 873 the edge of the network, so concerns about additional latency for 874 routing through a tunnel to the HA do not apply because it is 875 effectively on the same path that the NAT traffic would have 876 taken. Duplicate address detection is handled as a normal process 877 of the HA binding update. While turning off all binding updates 878 with the coorespondent node would appear to be necessary to 879 prevent leakage of topology information, that approach would also 880 force all internal traffic using the home address to route via the 881 HA tunnel, which may be undesirable. A more efficient method 882 would be to allow internal route optimizations while dropping 883 outbound binding update messages at the firewall. Another 884 approach for the internal traffic would be to use the policy table 885 of RFC 3484 to bias a ULA prefix as preferred internally, leaving 886 the logical subnet Home Address external for use. The downsides 887 with a Mobile IPv6 based solution is that it requires a home agent 888 in the network, the configuration of a security association with 889 the HA for each hidden node, and consumes some amount of bandwidth 890 for tunnel overhead. 892 o Another method (where the layer 2 topology allows) uses a virtual 893 lan approach to logically attach the devices to one or more 894 subnets on the edge router. This approach leads the end nodes to 895 believe they actually share a common segment. The downsides of 896 this approach is that all internal traffic would be directed over 897 sub-optimal paths via the edge router, as well as the complexity 898 of managing a distributed logical lan. 900 One issue to be aware of is that subnet scope multicast will not work 901 for the logical hidden subnets, except in the vlan case. While a 902 limited scope multicast to a collection of nodes that are arbitrarily 903 scattered makes no technical sense, care should be exercised to avoid 904 deploying applications that expect limited scope multicast in 905 conjunction with topology hiding. 907 Another issue that this document will not define is the mechanism for 908 a topology hidden node to learn its logical subnet. While manual 909 configuration would clearly be sufficient, DHCP could be used for 910 address assignment, with the recipient node discovering it is in a 911 hidden mode when the attached subnet prefix doesn't match the one 912 assigned. 914 4.5. Independent Control of Addressing in a Private Network 916 IPv6 provides for autonomy in local use addresses through ULAs. At 917 the same time IPv6 simplifies simultaneous use of multiple addresses 918 per interface so that an IPv6 NAT is not required between the ULA and 919 the public Internet because nodes that need access to the public 920 Internet will have a global use address as well. When using IPv6, 921 the need to ask for more address space will become far less likely 922 due to the increased size of the subnets, along with an allocation 923 policy that recognizes table fragmentation is also an important 924 consideration. While global IPv6 allocation policy is managed 925 through the Regional Internet Registries, it is expected that they 926 will continue with derivatives of [9]for the foreseeable future so 927 the number of subnet prefixes available to an organization should not 928 be a limitation which would create an artificial demand for NAT. 930 Ongoing subnet address maintenance may become simpler when IPv6 931 technology is utilized. Under IPv4 address space policy restrictions 932 each subnet must be optimized, so one has to look periodically into 933 the number of hosts on a segment and the subnet size allocated to the 934 segment and rebalance. For example an enterprise today may have a 935 mix of IPv4 /28 - /23 size subnets, and may shrink/grow these as 936 their network user base changes. For IPv6 all subnets have /64 937 prefixes which will reduce the operational and configuration 938 overhead. 940 4.6. Global Address Pool Conservation 942 IPv6 provides sufficient space to completely avoid the need for 943 overlapping address space. Since allocations in IPv6 are based on 944 subnets rather than hosts a reasonable way to look at the pool is 945 that there are about 17*10^18 unique subnet values where sparse 946 allocation practice within those provides for new opportunities such 947 as SEND 3971 [16]. As previously discussed, the serious 948 disadvantages of ambiguous address space have been well documented, 949 and with sufficient space there is no need to continue the 950 increasingly aggressive conservation practices that are necessary 951 with IPv4. While IPv6 allocation policies and ISP business practice 952 will continue to evolve, the recommendations in RFC 3177 are based on 953 the technical potential of the vast IPv6 address space. That 954 document demonstrates that there is no resource limitation which will 955 require the adoption of the IPv4 workaround of ambiguous space behind 956 a NAT. As an example of the direct contrast, many expansion oriented 957 IPv6 deployment scenarios result in multiple IPv6 addresses per 958 device, as opposed to the constriction of IPv4 scenarios where 959 multiple devices are forced to share a scarce global address through 960 a NAT. 962 4.7. Multihoming and Renumbering 964 IPv6 was designed to allow sites and hosts to run with several 965 simultaneous CIDR allocated prefixes, and thus with several 966 simultaneous ISPs. An address selection mechanism [12]is specified 967 so that hosts will behave consistently when several addresses are 968 simultaneously valid. The fundamental difficulty that IPv4 has in 969 regard to multiple addresses therefore does not apply to IPv6. IPv6 970 sites can and do run today with multiple ISPs active, and the 971 processes for adding, removing, and renumbering active prefixes at a 972 site have been documented in [17]and [21]. However, multihoming and 973 renumbering remain technically challenging even with IPv6 with 974 regards to session continuity across multihoming events or 975 interactions with ingress filtering (see the Gap Analysis below). 977 The IPv6 address space allocated by the ISP will be dependent upon 978 the connecting Service provider. This will likely result in a 979 renumbering effort when the network changes between service 980 providers. When changing ISPs or ISPs readjusting their addressing 981 pool, DHCP-PD [13]can be used as an almost zero- touch external 982 mechanism for prefix change in conjunction with a ULA prefix for 983 internal connection stability. With appropriate management of the 984 lifetime values and overlap of the external prefixes, a smooth make- 985 before-break transition is possible as existing communications will 986 continue on the old prefix as long as it remains valid, while any new 987 communications will use the new prefix. 989 5. Case Studies 991 In presenting these case studies we have chosen to consider 992 categories of network divided first according to their function 993 either as carrier/ISP networks or end user (such as enterprise) 994 networks with the latter category broken down according to the number 995 of connected end hosts. For each category of networks we can use 996 IPv6 Local Network Protection to achieve a secure and flexible 997 infrastructure, which provides an enhanced network functionality in 998 comparison with the usage of address translation. 1000 o Medium/Large Private Networks (typically >10 connections) 1001 o Small Private Networks (typically 1 to 10 connections) 1002 o Single User Connection (typically 1 connection) 1003 o ISP/Carrier Customer Networks 1005 5.1. Medium/large private networks 1007 The majority of private enterprise, academic, research, or government 1008 networks fall into this category. Many of these networks have one or 1009 more exit points to the Internet. Though these organizations have 1010 sufficient resources to acquire addressing independence when using 1011 IPv4 there are several reasons why they might choose to use NAT in 1012 such a network. For the ISP there is no need to import the IPv4 1013 address range from the remote end-customer, which facilitates IPv4 1014 route summarization. The customer can use a larger IPv4 address 1015 range (probably with less-administrative overhead) by the use of RFC 1016 1918 and NAT. The customer also reduces the overhead in changing to 1017 a new ISP, because the addresses assigned to devices behind the NAT 1018 do not need to be changed when the customer is assigned a different 1019 address by a new ISP. By using address translation in IPv4 one 1020 avoids the expensive process of network renumbering. Finally, the 1021 customer can provide privacy for its hosts and the topology of its 1022 internal network if the internal addresses are mapped through NAT. 1024 It is expected that there will be enough IPv6 addresses available for 1025 all networks and appliances for the foreseeable future. The basic 1026 IPv6 address range an ISP allocates for a private network is large 1027 enough (currently /48) for most of the medium and large enterprises, 1028 while for the very large private enterprise networks address-ranges 1029 can be concatenated. The goal of this assignment mechanism is to 1030 decrease the total amount of entries in the public Internet routing 1031 table. A single /48 allocation provides an enterprise network with 1032 65536 different /64 subnet prefixes. 1034 To mask the identity of a user on a network of this type, the usage 1035 of IPv6 privacy extensions may be advised. This technique is useful 1036 when an external element wants to track and collect all information 1037 sent and received by a certain host with known IPv6 address. Privacy 1038 extensions add a random time-limited factor to the host part of an 1039 IPv6 address and will make it very hard for an external element to 1040 keep correlating the IPv6 address to a specific host on the inside 1041 network. The usage of IPv6 privacy extensions does not mask the 1042 internal network structure of an enterprise network. 1044 When there is need to mask the internal structure towards the 1045 external IPv6 Internet, then some form of 'untraceable' addresses may 1046 be used. These addresses will appear to exist at the external edge 1047 of the network, and may be assigned to those hosts for which topology 1048 masking is required or which want to reach the IPv6 Internet or other 1049 external networks. The technology to assign these addresses to the 1050 hosts could be based on DHCPv6 or static configuration. To 1051 complement the 'Untraceable' addresses it is needed to have at least 1052 awareness of the IPv6 address location when routing an IPv6 packet 1053 through the internal network. This could be achieved by 'host based 1054 route- injection' in the local network infrastructure. This route- 1055 injection could be done based on /128 host-routes to each device that 1056 wants to connect to the Internet using an untraceable address. This 1057 will provide the most dynamic masking, but will have a scalability 1058 limitation, as an IGP is typically not designed to carry many 1059 thousands of IPv6 prefixes. A large enterprise may have thousands of 1060 hosts willing to connect to the Internet. 1062 An alternative for larger deployments is to leverage the tunneling 1063 aspect of MIPv6 even for non-mobile devices. With the logical subnet 1064 being allocated as attached to the edge Home Agent, the real 1065 attachment and internal topology are masked from the outside. 1066 Dropping outbound binding updates at the firewall is also necessary 1067 to avoid leaking the attachment information. 1069 Less flexible masking could be to have time-based IPv6 prefixes per 1070 link or subnet. This may reduce the amount of route entries in the 1071 IGP by a significant factor, but has as trade-off that masking is 1072 time and subnet based which will complicate auditing systems. The 1073 dynamic allocation of 'Untraceable' addresses can also limit the IPv6 1074 access between local and external hosts to those local hosts being 1075 authorized for this capability. 1077 The use of permanent ULA addresses on a site provides the benefit 1078 that even if an enterprise would change its ISP, the renumbering will 1079 only affect those devices that have a wish to connect beyond the 1080 site. Internal servers and services would not change their allocated 1081 IPv6 ULA address, and the service would remain available even during 1082 global address renumbering. 1084 5.2. Small Private Networks 1086 Also known as SOHO (Small Office/Home Office) networks, this category 1087 describes those networks which have few routers in the topology, and 1088 usually have a single network egress point. Typically these networks 1089 are: 1091 o connected via either a dial-up connection or broadband access 1092 o don't have dedicated Network Operation Center (NOC) 1093 o and today typically use NAT as the cheapest available solution for 1094 connectivity and address management 1096 In most cases the received global IPv4 prefix is not fixed over time 1097 and is too long (very often just a /32 just giving a single address) 1098 to provide every node in the private network with a unique globally 1099 usable address. Fixing either of those issues typically adds an 1100 administrative overhead for address management to the user. This 1101 category may even be limited to receiving ambiguous IPv4 addresses 1102 from the service provider based on RFC 1918. An ISP will typically 1103 pass along the higher administration cost attached to larger address 1104 blocks, or IPv4 prefixes that are static over time, due to the larger 1105 public address pool each of those requires. 1107 As a direct response to explicit charges per public address most of 1108 this category has deployed NAPT (port demultiplexing NAT) to minimize 1109 the number of addresses in use. Unfortunately this also limits the 1110 Internet capability of the equipment to being mainly a receiver of 1111 Internet data (client), and makes it quite hard for the equipment to 1112 become a world wide Internet server (i.e. HTTP, FTP, etc.) due to 1113 the stateful operation of the NAT equipment. Even when there is 1114 sufficient technical knowledge to manage the NAT to enable external 1115 access to a server, only one server can be mapped per protocol/ 1116 port-number per address, and then only when the address from the ISP 1117 is publicly routed. When there is an upstream NAT providing private 1118 address space to the ISP side of the private NAT, additional 1119 negotiation with the ISP will be necessary to provide an inbound 1120 mapping, if that is even possible. 1122 When deploying IPv6 LNP in this environment, there are two approaches 1123 possible with respect to IPv6 addressing. 1124 o DHCPv6 Prefix-Delegation 1125 o ISP provides a static IPv6 address-range 1127 For the DHCPv6-PD solution, a dynamic address allocation approach is 1128 chosen. By means of the enhanced DHCPv6 protocol it is possible to 1129 have the ISP push down an IPv6 prefix range automatically towards the 1130 small private network and populate all interfaces in that small 1131 private network dynamically. This reduces the burden for 1132 administrative overhead because everything happens automatically. 1134 For the static configuration the mechanisms used could be the same as 1135 for the medium/large enterprises. Typically the need for masking the 1136 topology will not be of high priority for these users, and the usage 1137 of IPv6 privacy extensions could be sufficient. 1139 For both alternatives the ISP has the unrestricted capability for 1140 summarization of its RIR allocated IPv6 prefix, while the small 1141 private network administrator has all flexibility in using the 1142 received IPv6 prefix to its advantage because it will be of 1143 sufficient size to allow all the local nodes to have a public address 1144 and full range of ports available whenever necessary. 1146 While a full prefix is expected to be the primary deployment model 1147 there may be cases where the ISP provides a single IPv6 address for 1148 use on a single piece of equipment (PC, PDA, etc.). This is expected 1149 to be rare though, because in the IPv6 world the assumption is that 1150 there is an unrestricted availability of a large amount of globally 1151 routable and unique address space. If scarcity was the motivation 1152 with IPv4 to provide RFC 1918 addresses, in this environment the ISP 1153 will not be motivated to allocate private addresses towards the 1154 single user connection because there are enough global addresses 1155 available at essentially the same cost. Also it will be likely that 1156 the single device wants to mask its identity to the called party or 1157 its attack profile over a shorter time window than the life of the 1158 ISP attachment, so it will need to enable IPv6 privacy extensions 1159 which in turn leads to the need for a minimum allocation of a /64 1160 prefix rather than a single address. 1162 5.3. Single User Connection 1164 This group identifies the users which are connected via a single IPv4 1165 address and use a single piece of equipment (PC, PDA, etc.). This 1166 user may get an ambiguous IPv4 address (frequently imposed by the 1167 ISP) from the service provider which is based on RFC 1918. If 1168 ambiguous addressing is utilized, the service provider will execute 1169 NAT on the allocated IPv4 address for global Internet connectivity. 1170 This also limits the Internet capability of the equipment to being 1171 mainly a receiver of Internet data, and makes it quite hard for the 1172 equipment to become a world wide Internet server (i.e. HTTP, FTP, 1173 etc.) due to the stateful operation of the NAT equipment. 1175 When using IPv6 LNP, this group will identify the users which are 1176 connected via a single IPv6 address and use a single piece of 1177 equipment (PC, PDA, etc.). 1179 In IPv6 world the assumption is that there is unrestricted 1180 availability of a large amount of globally routable and unique IPv6 1181 addresses. The ISP will not be motivated to allocate private 1182 addresses towards the single user connection because he has enough 1183 global addresses available, if scarcity was the motivation with IPv4 1184 to provide RFC 1918 addresses. If the single user wants to mask his 1185 identity, he may choose to enable IPv6 privacy extensions. 1187 5.4. ISP/Carrier Customer Networks 1189 This group refers to the actual service providers that are providing 1190 the IP access and transport services. They tend to have three 1191 separate IP domains that they support: 1192 o For the first they fall into the Medium/large private networks 1193 category (above) for their own internal networks, LANs etc. 1194 o The second is the Operations network which addresses their 1195 backbone and access switches, and other hardware, this is separate 1196 for both engineering reasons as well as simplicity in managing the 1197 security of the backbone. 1198 o The third is the IP addresses (single or blocks) that they assign 1199 to customers. These can be registered addresses (usually given to 1200 category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of 1201 RFC 1918 addresses used with IPv4 NAT for single user connections. 1202 Therefore they can actually have two different NAT domains that 1203 are not connected (internal LAN and single user customers). 1205 When IPv6 LNP is utilized in these three domains then for the first 1206 category it will be possible to use the same solutions as described 1207 in Section 5.1. The second domain of the ISP/carrier is the 1208 Operations network. This environment tends to be a closed 1209 environment, and consequently communication can be done based on ULA 1210 addresses, however, in this environment, stable IPv6 Provider 1211 Independent addresses can be used. This would give a solid and 1212 scalable configuration with respect to a local IPv6 address plan. By 1213 the usage of proper network edge filters, outside access to the 1214 closed environment can be avoided. The third is the IPv6 addresses 1215 that ISP/carrier network assign to customers. These will typically 1216 be assigned with prefix lengths terminating on nibble boundaries to 1217 be consistent with the DNS PTR records. As scarcity of IPv6 1218 addresses is not a concern, it will be possible for the ISP to 1219 provide global routable IPv6 prefixes without a requirement for 1220 address translation. An ISP may for commercial reasons still decide 1221 to restrict the capabilities of the end users by other means like 1222 traffic and/or route filtering etc. 1224 If the carrier network is a mobile provider, then IPv6 is encouraged 1225 in comparison with the combination of IPv4+NAT for 3GPP attached 1226 devices. When looking in chapter 2.3 of RFC3314 'Recommendations for 1227 IPv6 in 3GPP Standards' [10]it is found that the IPv6 WG recommends 1228 that one or more /64 prefixes should be assigned to each primary PDP 1229 context. This will allow sufficient address space for a 3GPP- 1230 attached node to allocate privacy addresses and/or route to a multi- 1231 link subnet, and will discourage the use of NAT within 3GPP-attached 1232 devices. 1234 6. IPv6 Gap Analysis 1236 Like IPv4 and any major standards effort, IPv6 standardization work 1237 continues as deployments are ongoing. This section discusses several 1238 topics for which additional standardization, or documentation of best 1239 practice, is required to fully realize the benefits or provide 1240 optimizations when deploying LNP. From a standardization perspective 1241 there is no obstacle to immediate deployment of the LNP approach in 1242 many scenarios, though product implimentations may lag the 1243 standardization efforts. That said, the list below identifies 1244 additional work that should be undertaken to cover the missing 1245 scenarios. 1247 6.1. Simple Security 1249 Firewall traversal by dynamic pinhole management requires further 1250 study. Several partial solutions exist including ICE [23], UPNP 1251 [24]. Alternative approaches are looking to define service provider 1252 mediated pinhole management, where things like voice call signaling 1253 could dynamically establish pinholes based on predefined 1254 authentication rules. The basic security provided by a stateful 1255 firewall will require some degree of default configuration and 1256 automation to mask the technical complexity from a consumer who 1257 merely wants a secure environment with working applications. There 1258 is no reason a stateful IPv6 firewall product cannot be shipped with 1259 default protection that is equal to or better than that offered by 1260 today's IPv4/NAT products. 1262 6.2. Subnet Topology Masking 1264 There really is no functional standards gap here as a centrally 1265 assigned pool of addresses in combination with host routes in the IGP 1266 is an effective way to mask topology for smaller deployments. If 1267 necessary a best practice document could be developed describing the 1268 interaction between DHCP and various IGPs which would in effect 1269 define Untraceable Addresses. 1271 As an alternative for larger deployments, there is no gap in the HA 1272 tunneling approach when firewalls are configured to block outbound 1273 binding update messages. A border Home Agent using internal 1274 tunneling to the logical mobile (potentially rack mounted) node can 1275 completely mask all internal topology, while avoiding the strain from 1276 a large number of host routes in the IGP. Some optimization work 1277 could be done in Mobile IP to define a policy message where a mobile 1278 node would learn from the Home Agent that it should not try to inform 1279 its correspondent about route optimization and thereby expose its 1280 real location. This optimization, which reduces the load on the 1281 firewall, would result in less optimal internal traffic routing as 1282 that would also transit the HA unless ULAs were used internally. 1283 Trade-off's for this optimization work should be investigated in the 1284 IETF. 1286 6.3. Minimal Traceability of Privacy Addresses 1288 Privacy addresses [8]may certainly be used to limit the traceability 1289 of external traffic flows back to specific hosts, but lacking a 1290 topology masking component above they would still reveal the subnet 1291 address bits. For complete privacy a best practice document 1292 describing the combination of privacy addresses with topology masking 1293 may be required. This work remains to be done, and should be pursued 1294 by the IETF. 1296 6.4. Site Multihoming 1298 This complex problem has never been completely solved for IPv4, which 1299 is exactly why NAT has been used as a partial solution. For IPv6, 1300 after several years of work, the IETF has converged on an 1301 architectural approach intended with service restoration as initial 1302 aim [22]. When this document was drafted, the IETF was actively 1303 defining the details of this approach to the multihoming problem. 1304 The approach appears to be most suitable for small and medium sites, 1305 though it will conflict with existing firewall state procedures. At 1306 this time there are also active discussions in the address registries 1307 investigating the possibility of assigning provider-independent 1308 address space. Their challenge is finding a reasonable metric for 1309 limiting the number of organizations that would qualify for a global 1310 routing entry. Additional work appears to be necessary to satisfy 1311 the entire range of requirements. 1313 7. IANA Considerations 1315 This document requests no action by IANA 1317 8. Security Considerations 1319 While issues which are potentially security related are discussed 1320 throughout the document, the approaches herein do not introduce any 1321 new security concerns. IPv4 NAT has been widely sold as a security 1322 tool, and suppliers have been implementing address translation 1323 functionality in their firewalls, though the true impact of NATs on 1324 security has been previously documented in [3] and [5]. 1326 This document defines IPv6 approaches which collectively achieve the 1327 goals of the network manager without the negative impact on 1328 applications or security that are inherent in a NAT approach. While 1329 section 6 identifies additional optimization work, to the degree that 1330 these techniques improve a network manager's ability to explicitly 1331 audit or control access, and thereby manage the overall attack 1332 exposure of local resources, they act to improve local network 1333 security. 1335 9. Conclusion 1337 This document has described a number of techniques that may be 1338 combined on an IPv6 site to protect the integrity of its network 1339 architecture. These techniques, known collectively as Local Network 1340 Protection, retain the concept of a well defined boundary between 1341 "inside" and "outside" the private network, and allow firewalling, 1342 topology hiding, and privacy. However, because they preserve address 1343 transparency where it is needed, they achieve these goals without the 1344 disadvantage of address translation. Thus, Local Network Protection 1345 in IPv6 can provide the benefits of IPv4 Network Address Translation 1346 without the corresponding disadvantages. 1348 The document has also identified a few ongoing IETF work items that 1349 are needed to realize 100% of the benefits of LNP. 1351 10. Acknowledgements 1353 Christian Huitema has contributed during the initial round table to 1354 discuss the scope and goal of the document, while the European Union 1355 IST 6NET project acted as a catalyst for the work documented in this 1356 note. Editorial comments and contributions have been received from: 1357 Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar, 1358 Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark 1359 Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith, 1360 Elwyn Davies, Daniel Senie, Soininen Jonne, Lindqvist Erik Kurt, 1361 Cullen Jennings and other members of the v6ops WG and IESG. 1363 11. References 1364 11.1. Normative References 1366 11.2. Informative References 1368 [1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- 1369 Domain Routing (CIDR): an Address Assignment and Aggregation 1370 Strategy", RFC 1519, September 1993. 1372 [2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 1373 Lear, "Address Allocation for Private Internets", BCP 5, 1374 RFC 1918, February 1996. 1376 [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1377 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1379 [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1380 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1382 [5] Hain, T., "Architectural Implications of NAT", RFC 2993, 1383 November 2000. 1385 [6] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1386 Translator (Traditional NAT)", RFC 3022, January 2001. 1388 [7] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 1389 IP Network Address Translator", RFC 3027, January 2001. 1391 [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1392 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1394 [9] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 1395 Allocations to Sites", RFC 3177, September 2001. 1397 [10] Wasserman, M., "Recommendations for IPv6 in Third Generation 1398 Partnership Project (3GPP) Standards", RFC 3314, 1399 September 2002. 1401 [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1402 Carney, "Dynamic Host Configuration Protocol for IPv6 1403 (DHCPv6)", RFC 3315, July 2003. 1405 [12] Draves, R., "Default Address Selection for Internet Protocol 1406 version 6 (IPv6)", RFC 3484, February 2003. 1408 [13] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1409 Configuration Protocol (DHCP) version 6", RFC 3633, 1410 December 2003. 1412 [14] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1413 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, 1414 January 2005. 1416 [15] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 1417 (RP) Address in an IPv6 Multicast Address", RFC 3956, 1418 November 2004. 1420 [16] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1421 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1423 [17] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 1424 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 1426 [18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1427 Addresses", RFC 4193, October 2005. 1429 [19] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful 1430 (draft-dupont-ipv6-rfc3041harmful-05.txt)", June 2004. 1432 [20] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- 1433 v6ops-port-scanning-implications-01.txt)", July 2004. 1435 [21] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to 1436 think about when Renumbering an IPv6 network 1437 (draft-chown-v6ops-renumber-thinkabout-03)", October 2004. 1439 [22] Huston, G., "Architectural Commentary on Site Multi-homing 1440 using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)", 1441 July 2004. 1443 [23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 1444 Methodology for Network Address Translator (NAT) Traversal for 1445 Offer/Answer Protocols (draft-ietf-mmusic-ice-11)", 1446 October 2006. 1448 [24] "UPNP Web Site, "Universal Plug and Play Web Site", Web Site 1449 http://www.upnp.org/", July 2005. 1451 Appendix A. Additional Benefits due to Native IPv6 and Universal Unique 1452 Addressing 1454 The users of native IPv6 technology and global unique IPv6 addresses 1455 have the potential to make use of the enhanced IPv6 capabilities, in 1456 addition to the benefits offered by the IPv4 technology. 1458 A.1. Universal Any-to-Any Connectivity 1460 One of the original design points of the Internet was any-to-any 1461 connectivity. The dramatic growth of Internet connected systems 1462 coupled with the limited address space of the IPv4 protocol spawned 1463 address conservation techniques. NAT was introduced as a tool to 1464 reduce demand on the limited IPv4 address pool, but the side effect 1465 of the NAT technology was to remove the any-to-any connectivity 1466 capability. By removing the need for address conservation (and 1467 therefore NAT), IPv6 returns the any-to-any connectivity model and 1468 removes the limitations on application developers. With the freedom 1469 to innovate unconstrained by NAT traversal efforts, developers will 1470 be able to focus on new advanced network services (i.e. peer-to-peer 1471 applications, IPv6 embedded IPsec communication between two 1472 communicating devices, instant messaging, Internet telephony, etc..) 1473 rather than focusing on discovering and traversing the increasingly 1474 complex NAT environment. 1476 It will also allow application and service developers to rethink the 1477 security model involved with any-to-any connectivity, as the current 1478 edge firewall solution in IPv4 may not be sufficient for any- to-any 1479 service models. 1481 A.2. Auto-configuration 1483 IPv6 offers a scalable approach to minimizing human interaction and 1484 device configuration. Whereas IPv4 implementations require touching 1485 each end system to indicate the use of DHCP vs. a static address and 1486 management of a server with the pool size large enough for the 1487 potential number of connected devices, IPv6 uses an indication from 1488 the router to instruct the end systems to use DHCP or the stateless 1489 auto configuration approach supporting a virtually limitless number 1490 of devices on the subnet. This minimizes the number of systems that 1491 require human interaction as well as improves consistency between all 1492 the systems on a subnet. In the case that there is no router to 1493 provide this indication, an address for use only on the local link 1494 will be derived from the interface media layer address. 1496 A.3. Native Multicast Services 1498 Multicast services in IPv4 were severely restricted by the limited 1499 address space available to use for group assignments and an implicit 1500 locally defined range for group membership. IPv6 multicast corrects 1501 this situation by embedding explicit scope indications as well as 1502 expanding to 4 billion groups per scope. In the source specific 1503 multicast case, this is further expanded to 4 billion groups per 1504 scope per subnet by embedding the 64 bits of subnet identifier into 1505 the multicast address. 1507 IPv6 allows also for innovative usage of the IPv6 address length, and 1508 makes it possible to embed the multicast 'Rendezvous Point' (or RP) 1509 [15]directly in the IPv6 multicast address when using ASM multicast. 1510 This is not possible with limited size of the IPv4 address. This 1511 approach also simplifies the multicast model considerably, making it 1512 easier to understand and deploy. 1514 A.4. Increased Security Protection 1516 The security protection offered by native IPv6 technology is more 1517 advanced than IPv4 technology. There are various transport 1518 mechanisms enhanced to allow a network to operate more securely with 1519 less performance impact: 1520 o IPv6 has the IPsec technology directly embedded into the IPv6 1521 protocol. This allows for simpler peer-to-peer authentication and 1522 encryption, once a simple key/trust management model is developed, 1523 while the usage of some other less secure mechanisms is avoided 1524 (i.e. md5 password hash for neighbor authentication). 1525 o While a firewall is specifically designed to disallow applicaions 1526 based on local policy, they do not interfere with those that are 1527 allowed. This is a security improvement over NAT, where the work- 1528 arounds to enable applications allowed by local policy are 1529 effectively architected man-in-the-middle attacks on the packets 1530 which precludes end-to-end auditing or IP level identification. 1531 o All flows on the Internet will be better traceable due to a unique 1532 and globally routable source and destination IPv6 address. This 1533 may facilitate an easier methodology for back-tracing DoS attacks 1534 and avoid illegal access to network resources by simpler traffic 1535 filtering. 1536 o The usage of private address-space in IPv6 is now provided by 1537 Unique Local Addresses, which will avoid conflict situations when 1538 merging networks and securing the internal communication on a 1539 local network infrastructure due to simpler traffic filtering 1540 policy. 1541 o The technology to enable source-routing on a network 1542 infrastructure has been enhanced to allow this feature to 1543 function, without impacting the processing power of intermediate 1544 network devices. The only devices impacted with the source- 1545 routing will be the source and destination node and the 1546 intermediate source-routed nodes. This impact behavior is 1547 different if IPv4 is used, because then all intermediate devices 1548 would have had to look into the source- route header. 1550 A.5. Mobility 1552 Anytime, anywhere, universal access requires MIPv6 services in 1553 support of mobile nodes. While a Home Agent is required for initial 1554 connection establishment in either protocol version, IPv6 mobile 1555 nodes are able to optimize the path between them using the MIPv6 1556 option header while IPv4 mobile nodes are required to triangle route 1557 all packets. In general terms this will minimize the network 1558 resources used and maximize the quality of the communication. 1560 A.6. Merging Networks 1562 When two IPv4 networks want to merge it is not guaranteed that both 1563 networks would be using different address-ranges on some parts of the 1564 network infrastructure due to the usage of RFC 1918 private 1565 addressing. This potential overlap in address space may complicate a 1566 merge of two and more networks dramatically due to the additional 1567 IPv4 renumbering effort. i.e. when the first network has a service 1568 running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by 1569 the 2nd merging network. Similar address conflicts can happen when 1570 two network devices from these merging networks want to communicate. 1572 With the usage of IPv6 the addressing overlap will not exist because 1573 of the existence of the Unique Local Address usage for private and 1574 local addressing. 1576 Appendix B. Revision history 1578 B.1. Changes from *-vandevelde-v6ops-nap-00 to 1579 *-vandevelde-v6ops-nap-01 1580 o Document introduction has been revised and overview table added 1581 o Comments and suggestions from nap-00 draft have been included. 1582 o Initial section of -00 draft 2.6 and 4.6 have been aggregated into 1583 a new case study section 5. 1584 o The list of additional IPv6 benefits has been placed into 1585 appendix. 1586 o new security considerations section added. 1587 o GAP analysis revised. 1588 o Section 2.6 and 4.6 have been included. 1590 B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00 1591 o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *- 1592 ietf-v6ops-nap-00.txt. 1593 o Editorial changes. 1595 B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 1596 o Added text in Chapter 2.2 and 4.2 to address more details on 1597 firewall and proxy 1598 o Revised Eric Klein contact details 1599 o Added note in 4.2 that control over the proposed statefull-filter 1600 should be by a simple user-interface 1602 B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 1603 o General Note: Header more consistent capitalized. 1604 o Section 1: para 3: s/...and privacy and will... translation./ 1605 ...and privacy. NAP will achieve these security goals without 1606 address translation whilst maintaining any-to-any connectivity./ 1607 o Section 1: Various editorial changes happened 1608 o Section 2.1: Changed: 'Frequently a simple user interface is 1609 sufficient for configuring'. into 'Frequently a simple user 1610 interface, or no user interface is sufficient' 1611 o Section 2.2: (Simple Security ) Better not to use the word -evil- 1612 in the text 1613 o Section 2.2: changed 'provided by NAT are actually ' into 1614 'provided by NAT is actually' 1615 o Section 2.2: para 3: s/actually false/actually an illusion/ 1616 o Section 2.2: para 2: added 'Also it will only be reliable if a 1617 mechanism such as 'trusted computing' is implemented in the end- 1618 system; without this enhancement administrators will be unwilling 1619 to trust the behavior of end-systems. 1620 o Section 2.3: para 1: s/of the NAT devices state/from the NAT 1621 device's state/ 1622 o Section 2.4: para1: clarified the definition of topology hiding 1623 o Section 2.4: last sentence of next-to-last paragraph, added 1624 punctuation at end of sentence. 1625 o Section 2.4: added first line: When mentioning 'topology hiding' 1626 the goal is to make a reference that an entity outside the network 1627 can not make a correlation between the location of a device and 1628 the address of a device on the local network. 1629 o Section 2.4: para 1: s/reflected/represented/ 1630 o Section 2.5: last par: added reference: 'Section 2.7 describes 1631 some disadvantages that appear if independent networks using 1632 [RFC1918] addresses have to be merged.' 1633 o Section 2.6: Added text that private address-space is not 1634 limitless 1635 o Section 2.6: Various editorial changes 1636 o Section 2.7: Para 1 editorial revised 1637 o Section 2.7: last para: s/This solution/The addition of an extra 1638 NAT as a solution/ 1639 o Section 2.7: s/highly desirable to be/highly desirable due to 1640 resiliency and load-balancing to be/ 1641 o Section 2.7: added text on the reason why there are overlapping 1642 addresses 1643 o Section 2.7: last para: s/merged address space/overlapping address 1644 spaces in the merged networks/ 1645 o Section 3.1: Para 1 editorial changes 1646 o Section 3.1: s/by contacted web sites, so IPv6/by web sites that 1647 are accessed from the device: IPv6 / 1649 o Section 3.1: s/as that would have a serious negative impact on 1650 global routing/as that would have a negative effect on global 1651 route aggregation 1652 o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in 1653 global routing table is not scalable 1654 o Section 3.2: s3.2: Noted that it is not always interesting to mix 1655 ULA with global as that may lead to SAS issues 1656 o Section 3.3: last para: s/delegating router/delegating router 1657 (incorporating a DHCPv6 server)/, s/across an administrative/ 1658 possibly across an administrative/ 1659 o Section 3.4: Changed: 'random assignment has as purpose' to 1660 'random assignment has a purpose' 1661 o Section 3.4: para 2: Replace first sentence with: 'The random 1662 assignment is intended to mislead the outside world about the 1663 structure of the local network.' 1664 o Section 3.4: para 2: s/there is a correlation/needs to maintain a 1665 correlation/ 1666 o Section 3.4: para 2: s/like a/such as a/ 1667 o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from 1668 mapping/and from mapping of/ 1669 o Section 3.4: para 3: s/are reachable on/are allocated to devices 1670 on/ 1671 o Section 3.4: para 3: s/belonging to the same subnet next to each 1672 other/belonging to devices adjacent to each other on the same 1673 subnet/ 1674 o Section 3.4: s/aggregation device/indirection device/ 1675 o Section 4.1: split the 1 section up into 2 separate sections 1676 o Section 4.1: s/ End node connections involving other nodes on the 1677 global Internet will always use the global IPv6 addresses [9] 1678 derived from this prefix delegation./ End node connections 1679 involving other nodes on the global Internet will always use the 1680 global IPv6 addresses [9] derived from this prefix delegation. It 1681 should be noted that the policy table needs to be correctly set up 1682 so that true global prefixes are distinguished from ULAs and will 1683 be used for the source address in preference when the destination 1684 is not a ULA/ 1685 o Section 4.1: A more secure network environment can be established 1686 by having the referenced ULA addresses statically configured on 1687 the network devices as this decreases the dynamic aspects of the 1688 network, however the operational overhead is increased. 1689 o Section 4.2: Added note that IID should be randomized for port- 1690 scan protection 1691 o Section 4.2: Removed text: This is an automated procedure of 1692 sending Internet Control Message Protocol (ICMP) echo requests 1693 (also known as PINGs) to a range of IP addresses and recording 1694 replies. This can enable an attacker to map the network. 1696 o Section 4.2: paragraph beginning: "This simple rule...". The 1697 first sentence in this paragraph was overly-long. The sentence 1698 has been fragmented 1699 o Section 4.2: para 1: s/similar as for an/similar to that of an/ 1700 o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/ 1701 Internet. The use of firewall and Intrusion Detection Systems 1702 (IDS) is/ 1703 o Section 4.2: para 1: s/but has/but with/ 1704 o Section 4.2: para 1: s/end to end/end-to-end/ 1705 o Section 4.2: Item 3: s/amount/number/ 1706 o Section 4.2: Item 3: s/This goes from the assumption that the 1707 attacker has no/This protection is nullified if the attacker has/ 1708 o Section 4.2: para after Item 3: s/pose/offer/ (or provide). 1709 o Section 4.2: para after Item 3: s/best- practices/best practices/ 1710 o Section 4.2: para after example firewall rules: s/create similar 1711 protection and security holes the typical IPv4 NAT device will 1712 offer/provide (non-)protection and create security holes similar 1713 to those offered to a network using a typical IPv4 NAT device/ 1714 o Section 4.2: para next but one after firewall rules: s/What one 1715 does when topology probing is to get an idea of the available 1716 hosts/The intention of topology probing is to identify a selection 1717 of the available hosts/ 1718 o Section 4.2: s/This is directly the opposite of what IPv6 security 1719 best practices are trying to achieve./IPv6 security best practices 1720 will avoid this kind of illusory security but can only do this if 1721 correctly configured firewalls and IDS systems are used at the 1722 perimeter where some IPv4 networks have relied on NATs. 1723 o Section 4.2: s/ It is recommended for site administrators to take 1724 [17] into consideration to achieve the expected goal./ It is 1725 recommended for site administrators to take [17] into 1726 consideration to achieve the expected goal. This protection will 1727 also be nullified if IIDs are configured in a group near the start 1728 of the IID space./ 1729 o Section 4.2: Removed the example study and added complementary 1730 text to describe a potential behavior 1731 o Section 4.4: rewrite of the section to reduce the importance of 1732 the MIPv6 and tunneled solution 1733 o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested 1734 in the text, however text is added that any kind of tunneling 1735 should do the trick. 1736 o Section 4.4: para 2: after 'As discussed above' inserted '(see 1737 Section 3.1)' 1738 o Section 4.4: para 3: s/consolidated on/indirected via/ 1739 o Section 4.4: para 3: s/topololgy masked/each topology masked/ 1740 o Section 4.4: para 3: Expanded acronym COA 1741 o Section 4.4: para 3: s/rack mounted/static/ 1742 o Section 4.4: Rephrasing of text happened in this section 1743 o Section 4.5: change: "so that a NAT is not required" to: "so that 1744 IPv6 address translation is not required". 1745 o Section 4.5: changed 'periodically to look' into 'to look 1746 periodically' 1747 o Section 4.5: change: "2^64 hosts" to: "2^64 addresses". 1748 o Section 4.5: Removed the statement '(or even defined) 1749 o Section 4.6: last para: s/which will lead to the IPv4 practice/ 1750 which will require the adoption of the IPv4 workaround/ 1751 o Section 4.6: s/the IPv4 constricting scenarios of multiple devices 1752 sharing a/the constriction of IPv4 scenarios where multiple 1753 devices are forced to share a/ 1754 o Section 4.7: s/as the zero-touch external/as an almost zero-touch 1755 external/ 1756 o Section 5: Replaced first three sentences with: In presenting 1757 these case studies we have chosen to consider categories of 1758 network divided first according to their function either as 1759 carrier/ISP networks or end user (such as enterprise) networks 1760 with the latter category broken down according to the number of 1761 connected end hosts. 1762 o Section 5: bullet points: s/connection/connected end hosts/ 1763 o Section 5.1: s/addressing independence/addressing independence 1764 when using IPv4/ 1765 o Section 5.1: last para: s/is only affecting/will only affect/ 1766 o Section 5.1: changed 'allocation' into 'allocation' 1767 o Section 5.1: changed: '(typically a one or' into '(typically one 1768 or' 1769 o section 5.1: changed: s/allocation/assignment/ in one of the 1770 paragraphs 1771 o section 5.2: para 1: s?is too long?is too long (very often just a 1772 /32 just giving a single address)? 1773 o Section 5.4: (Case study: ISP networks) ULA usage for ISP/ 1774 Carrier-grade networks is mentioned in the draft, while it was 1775 suggested that for these NW the PI addresses are already very 1776 stable and they should be qualified for setting up proper 1777 filtering -> removed ULA from this section. 1778 o Section 5.4: changed 'intra- communication' into 'communication' 1779 o Section 5.4: s/chapter 5.1/Section 5.1/ 1780 o Section 6.1: (Completion of work on ULAs) Text revision to reflect 1781 current state of ULA or remove the chapter? Chapter removed ... 1782 ULA specification is in the RFC-editor queue. 1783 o Section 6.3: (Minimal Traceability) Better to say "topology 1784 masking _may be_ required" instead of "is required", because 1785 whether this is needed or not is a value judgment. 1786 o Section 6.4: (Renumbering Procedure) Renumbering procedure is in 1787 RFC queue. The section corrected in the current state? 1789 o Section 6.4: s/well solved/completely solved/ 1790 o In general the whole chapter 6 has been revised to reflect current 1791 status 1793 B.5. Changes from *-ietf-v6ops-nap-02 to *-ietf-v6ops-nap-03 1794 o Editorial changes in response to IESG review comments and 1795 questions. 1796 o Introduction: clarified impact & goal for limited additional NAT 1797 discussion here / modified tone wrt marketing / grammar cleanup 1798 o Introduction: s/market acceptance/deployment 1799 o Introduction: noted that users do not evaluate technical trade- 1800 offs and that marketing does not mention the downside of address 1801 translation 1802 o Introduction: added paragraph about why nat != security 1803 o Table1: s/benefit/Goal/ s/ULA/4193/ removed long numeric string / 1804 added app end points & number of subnets 1805 o Section 2: tone reduction about marketing 1806 o Section 2.1: grammar cleanup / clarified point about use of public 1807 space / added paragraph about topology restrictions / removed last 1808 paragraph about security 1809 o Section 2.2: moved paragraph about firewalls to 4.2 / deleted 1810 discussion about distributed security / clarified point about port 1811 overload 1812 o Section 2.3: Added opening sentence to explain the goal of the 1813 section / changed comment about theory to an absolute / qualified 1814 logging and checking times 1815 o Section 2.4: deleted confusing/redundant comments about identifier 1816 / clarified point about nodes appearing to be at the edge / added 1817 clarification that focused scanning on the port range reaches 1818 active nodes 1819 o Section 2.5: clarified that the reason for autonomy is large space 1820 & impact was on the local network 1821 o Section 2.6: clarified point about reduction of IPv4 consumption 1822 rate / s/30%/25% / added point about limitations of cascaded nat / 1823 added para about limited app endpoints as well as topology 1824 restrictions 1825 o Section 2.7: clarification about why multihoming & renumbering are 1826 discussed together / point about sparse allocation / s/speaces/ 1827 spaces 1828 o Section 3: s/emulate/replace / added para about 'gaps' being 1829 discussed later 1830 o Section 3.1: Cleaned up description of SLAAC & 3041 / specified 1831 server as DHCP / added comment about sparse allocation 1832 o Section 3.2: grammar cleanup / updated reference from ID to RFC 1833 4193 / added point about policy table in 3484 to bias ULA over ISP 1834 prefix 1836 o Section 3.3: Clarification about goal for section 1837 o Section 3.4: reorder paragraphs to put goal up front 1838 o Section 4.1: s/could/should/ s/prior to establishing/independent 1839 of the state of / clarified why concatenation would not collide / 1840 another comment about the 3484 table for ULA biasing / clarified 1841 point about lack of routing protocol 1842 o Section 4.2: clarified point about firewall at boundary / 1843 clarified point about valid lifetime / clarified point that IPsec 1844 works the same w/o NAT / added point about authenticating 1845 correspondent / clarified that the scanning threat is addresses as 1846 ports are the same once an address is known / rearranged paragraph 1847 to keep scanning thread together / inserted firewall discussion 1848 moved from 2.2 / clarified role of simple firewall / added comment 1849 about service provider mediated pinhole management 1850 o Section 4.3: added paragraph about tracking privacy address use 1851 o Section 4.4: clarified point about tracking wrt NAT / added 1852 comment about IGP complexity / s/conceal/isolate/ s/possible/ 1853 potential/ reworded ULA description which was technically 1854 backwards / additional description of the goal / added picture and 1855 referenced it from descriptions converted options to descriptive 1856 list / added discussion about blocking binding updates / added 1857 vlan option / s/would be to use/uses to make it clear this already 1858 works / para 2 s/prefixes/addresses and replaced last part of the 1859 sentence to clarify what was being hidden. 1860 o Section 4.5: Grammar cleanup / clarification about policy 1861 o Section 4.6: replaced long number string with power qnty of 1862 subnets / added reference to new capabilities like SEND 1863 o Section 4.7: s/CIDR-like/CIDR allocated/ s/this/to multiple 1864 addresses/ s/may/will likely/ s/if/when/ s/from SP/between sp/ 1865 Updated reference for renumbering proceedure to RFC 4192 1866 o Section 5: d/of these/ 1867 o Section 5.1: s/private enterprise/private enterprise, academic, 1868 research, or government / deleted redundant discussion about /48 1869 allocation / added discussion about larger deployments using 1870 tunneling / 1871 o Section 5.2: clarification of overload on port vs. protocol / 1872 added comment about upstream NAT / clarified 3041 use as short 1873 timeframe 1874 o Section 5.3: capitalize Internet 1875 o Section 5.4: s/IPv4/IP as role is not version specific / deleted 1876 comment about preference to ULA. 1877 o Section 6.1: (security) inserted section discussing need for 1878 dynamic pinhole management 1879 o Section 6.2: (topology mask) added comment about deployment scale 1880 / added comment about firewall blocking BU / clarified point about 1881 future work being an optimization to reduce firewall load 1883 o Section 6.3: (tracability) grammar cleanup 1884 o Section 6.4: (renumbering) Cut section since it is no longer a gap 1885 o Section A.2: word order - moved 'only' 1886 o Section A.6: deleted 'legitimate' 1887 o Section A.7: clarified how NAP delivers community of interest 1888 o Spell check 1890 B.6. Changes from *-ietf-v6ops-nap-03 to *-ietf-v6ops-nap-04 1891 o Editorial changes in response to IESG review comments and 1892 questions, as well as I-D nits. 1893 o Changed the abreviation to NAP6 and the title from 'IPv6 Network 1894 Address Protection' to 'Network Architecture Protection for IPv6' 1895 o Introduction s/in/with 1896 o Introduction s/Indeed, product marketing departments have 1897 effectively driven a perception that some connectivity/ Indeed, it 1898 is often claimed that some connectivity and .../ 1899 o Section 2.1 s/[RFC 1918]/xref... 1900 o Section 2.5 s/[RFC1918]/xref... 1901 o Section 2.7 s/huge/major/ 1902 o Section 3.2 Added additional paragraph at the end of section to 1903 address ULA comment from Cullen J. 1904 o Section 3.2 last bullet - should qualify 'scope' as 'routing 1905 scope' 1906 o Section 3.4 Rewrote the section for clarity sake to address 1907 consern from Cullen J. 1908 o Section 4.1 para 1 - s/ This would allow local nodes to 1909 communicate amongst themselves independent of the state of a 1910 global connection. /This would allow local nodes in a topology 1911 more complex than a single link to communicate amongst themselves 1912 independent of the state of a global connection. 1913 o Section 4.2 s/efficiency/efficiency, and even these helpers do not 1914 work in all situations. 1915 o Section 4.2 added reference to [RFC3948] and added more 1916 contexttext around IPsec/NAT and IPv6 1917 o Section 4.2 moved comment about nullifying earlier in para 1918 o Section 4.3 added privacy addresses consideration by adding 1919 "Unless privacy addresses [RFC3041] are in use," 1920 o Section 4.4 last para - typo s/ DHCP could be use / DHCP could be 1921 used 1922 o Section 4.4 removed brackets from 3041 1923 o Section 4.4 s/requires hosts to participate/ requires hosts to 1924 securely participate 1925 o Section 4.4 added note that hosts should listen to IGP because DAD 1926 does not work for virutal subnet 1927 o Section 4.4 added note that DAD is a normal part of HA 1928 o Section 4.4 s/updates/update messages 1929 o Section 4.4 s/routes/traffic 1930 o Section 4.4 s/leaving the Home Address/ leaving the logical subnet 1931 Home Address 1932 o Section 4.4 replaced MIPv6 downsides sentence with text J.Arkko 1933 sent to the list 1934 o Section 4.4 added comment in vlan about host perception of a 1935 shared common segment 1936 o Section 4.4 diagram s/simple gateway home agent/ topology masking 1937 router 1938 o Section 4.4 added comment about subnet scope multicast restriction 1939 for logical subnet 1940 o Section 4.4 added comment about how a topology hidden node learns 1941 its home address 1942 o Section 4.7 Rephrased section based on J. Arkko suggestion 1943 o Section 6. s/roles/scenarios/ 1944 o Section 6.1 rewritten section 1945 o Section 6.4 s/with firewall/with existing firewall 1946 o Section 8. removed last line of section 1947 o Section A.7 Removed section to address suggestion from Cullen J. 1948 o Author details: modified Brian Carpenter's address details 1950 B.7. Changes from *-ietf-v6ops-nap-04 to *-ietf-v6ops-nap-05 1951 o Editorial changes in response to IESG review comments and 1952 questions, as well as I-D nits. 1953 o Abstract s/does not support NAT by design/was designed with the 1954 intention of making NAT unnecessary 1955 o Introduction s/people/network administrators 1956 o Introduction s/preferred task/needs 1957 o Introduction s/goals for utilizing/uses of 1958 o Introduction added or a manual on how to configure a network 1959 o Introduction reworded discussion about security policy goals 1960 o Introduction s/need/expiration of state 1961 o Introduction s/the need/The ability for nodes 1962 o Introduction s/allow/while allowing 1963 o Introduction s/"benefits"/benefits 1964 o Introduction s/a complete/an optimal 1965 o Section 2.1 s/be available/also be deployed 1966 o Section 2.2 added comment about one-size-fits-all answer 1967 o Section 2.2 added discussion about better-than-nothing protection 1968 o Section 2.4 changed context from 'a user' to 'a system' 1969 o Section 2.5 s/take benefit from using/make use of 1970 o Section 2.5 reordered wording about 'Another benefit...' 1971 o Section 3.2 reordered wording of bullet 3 1972 o Section 4.1 moved 3484 policy table discussion earlier in the 1973 paragraph 1974 o Section 4.2 moved qualifier from IPv4 host to IPv6 host 1975 o Section 4.2 clarification wording changes in bullet 2 1976 o Section 4.2 added reference to bullet 3 1977 o Section 4.2 s/example, a DSL/example a DSL or Cable Modem 1978 o Section 4.2 moved discussion about SP dynamic pinhole management 1979 to 6.1 1980 o Section 4.4 moved 3041 reference earlier in section 1981 o Section 4.4 added sentence explaining figure and moved figure 1982 ahead of bulleted list 1983 o Section 4.7 s/to, for instance,/to 1984 o Section 6 clarification that the gaps apply to standards efforts 1985 and products may lag 1986 o Section 6.1 inserted discussion about SP dynamic pinhole 1987 management from 4.2 1988 o Section 6.2 s/no functional gap/no functional standards gap 1989 o Section 6.2 s/HA./HA unless ULAs were used internally. 1990 o Section 8 s/To/While section 6 identifies additional optimization 1991 work, to 1992 o Section 11 made all references informative, added BCP 78 as 1993 normative 1994 o Appendix A4 reworded bullet 2 1995 o 1997 B.8. Changes from *-ietf-v6ops-nap-05 to *-ietf-v6ops-nap-06 1998 o Editorial changes in response to IESG review comments and 1999 questions, as well as I-D nits. 2000 o Change of the titke of teh document from 'Network Address 2001 Protection' to 'Local Address Protection' 2002 o Change from 'NAP6' acronym to 'LNP' 2003 o Ch2.4: Removal of paragraph starting with 'At the same time a NAT 2004 creates.....' 2005 o Ch4.2: s/virtually impossible due to the potential number of 2006 combinations available/usually significantly harder and more 2007 expensive than for IPv4/ 2008 o Ch8: modified section on the marketing claims 2009 o ch5.2: s/and through economic pressure are typically forced today 2010 to use NAT/and today typically use NAT as the cheapest available 2011 solution for connectivity and address management 2012 o 2014 Authors' Addresses 2016 Gunter Van de Velde 2017 Cisco Systems 2018 De Kleetlaan 6a 2019 Diegem 1831 2020 Belgium 2022 Phone: +32 2704 5473 2023 Email: gunter@cisco.com 2025 Tony Hain 2026 Cisco Systems 2027 500 108th Ave. NE 2028 Bellevue, Wa. 2029 USA 2031 Email: alh-ietf@tndh.net 2033 Ralph Droms 2034 Cisco Systems 2035 1414 Massachusetts Avenue 2036 Boxborough, MA 01719 2037 USA 2039 Email: rdroms@cisco.com 2041 Brian Carpenter 2042 IBM 2043 8 Chemin de Blandonnet 2044 1214 Vernier, 2045 CH 2047 Email: brc@zurich.ibm.com 2049 Eric Klein 2050 Tel Aviv University 2051 Tel Aviv, 2052 Israel 2054 Phone: 2055 Email: ericlklein@softhome.net 2057 Full Copyright Statement 2059 Copyright (C) The Internet Society (2007). 2061 This document is subject to the rights, licenses and restrictions 2062 contained in BCP 78, and except as set forth therein, the authors 2063 retain all their rights. 2065 This document and the information contained herein are provided on an 2066 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2067 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2068 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2069 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2070 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2071 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2073 Intellectual Property 2075 The IETF takes no position regarding the validity or scope of any 2076 Intellectual Property Rights or other rights that might be claimed to 2077 pertain to the implementation or use of the technology described in 2078 this document or the extent to which any license under such rights 2079 might or might not be available; nor does it represent that it has 2080 made any independent effort to identify any such rights. Information 2081 on the procedures with respect to rights in RFC documents can be 2082 found in BCP 78 and BCP 79. 2084 Copies of IPR disclosures made to the IETF Secretariat and any 2085 assurances of licenses to be made available, or the result of an 2086 attempt made to obtain a general license or permission for the use of 2087 such proprietary rights by implementers or users of this 2088 specification can be obtained from the IETF on-line IPR repository at 2089 http://www.ietf.org/ipr. 2091 The IETF invites any interested party to bring to its attention any 2092 copyrights, patents or patent applications, or other proprietary 2093 rights that may cover technology that may be required to implement 2094 this standard. Please address the information to the IETF at 2095 ietf-ipr@ietf.org. 2097 Acknowledgment 2099 Funding for the RFC Editor function is provided by the IETF 2100 Administrative Support Activity (IASA).