idnits 2.17.00 (12 Aug 2021) /tmp/idnits25814/draft-vandevelde-v6ops-nap-01.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.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1369. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 951 has weird spacing: '...et, and will ...' == Line 1341 has weird spacing: '... o The list ...' -- 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 24, 2005) is 6319 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 1918' on line 220 -- 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 3315 (ref. '10') (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: draft-ietf-v6ops-renumbering-procedure has been published as RFC 4192 == Outdated reference: draft-ietf-ipv6-unique-local-addr has been published as RFC 4193 -- No information found for draft-dupont-ipv6- - is the name correct? == Outdated reference: A later version (-05) exists of draft-chown-v6ops-renumber-thinkabout-00 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 15 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 Expires: July 28, 2005 R. Droms 5 Cisco Systems 6 B. Carpenter 7 IBM Corporation 8 E. Klein 9 TTI Telecom 10 January 24, 2005 12 IPv6 Network Architecture Protection 13 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 28, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 Although there are many perceived benefits to Network Address 49 Translation (NAT), its primary benefit of "amplifying" available 50 address space is not needed in IPv6. In addition to NAT's many 51 serious disadvantages, there is a perception that other benefits 52 exist, such as a variety of management and security attributes that 53 could be useful for an Internet Protocol site. IPv6 does not support 54 NAT by design and this document shows how Network Architecture 55 Protection (NAP) using IPv6 can provide the same or more benefits 56 without the need for NAT. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Perceived benefits of NAT and its impact on IPv4 . . . . . . 6 62 2.1 Simple gateway between Internet and internal network . . . 6 63 2.2 Simple security due to stateful filter implementation . . 6 64 2.3 User/Application tracking . . . . . . . . . . . . . . . . 7 65 2.4 Privacy and topology hiding . . . . . . . . . . . . . . . 7 66 2.5 Independent control of addressing in a private network . . 8 67 2.6 Global address pool conservation . . . . . . . . . . . . . 8 68 2.7 Multihoming and renumbering with NAT . . . . . . . . . . . 9 69 3. Description of the IPv6 tools . . . . . . . . . . . . . . . 9 70 3.1 Privacy addresses (RFC 3041) . . . . . . . . . . . . . . . 9 71 3.2 Unique Local Addresses . . . . . . . . . . . . . . . . . . 10 72 3.3 DHCPv6 prefix delegation . . . . . . . . . . . . . . . . . 11 73 3.4 Untraceable IPv6 addresses . . . . . . . . . . . . . . . . 11 74 4. Using IPv6 technology to provide the market perceived 75 benefits of NAT . . . . . . . . . . . . . . . . . . . . . . 12 76 4.1 Simple gateway between Internet and internal network . . . 12 77 4.2 IPv6 and Simple security . . . . . . . . . . . . . . . . . 12 78 4.3 User/Application tracking . . . . . . . . . . . . . . . . 14 79 4.4 Privacy and topology hiding using IPv6 . . . . . . . . . . 14 80 4.5 Independent control of addressing in a private network . . 15 81 4.6 Global address pool conservation . . . . . . . . . . . . . 15 82 4.7 Multihoming and renumbering . . . . . . . . . . . . . . . 16 83 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . 16 84 5.1 Medium/large private networks . . . . . . . . . . . . . . 17 85 5.2 Small private networks . . . . . . . . . . . . . . . . . . 18 86 5.3 Single user connection . . . . . . . . . . . . . . . . . . 20 87 5.4 ISP/Carrier customer networks . . . . . . . . . . . . . . 20 88 6. IPv6 gap analysis . . . . . . . . . . . . . . . . . . . . . 21 89 6.1 Completion of work on ULAs . . . . . . . . . . . . . . . . 21 90 6.2 Subnet topology masking . . . . . . . . . . . . . . . . . 22 91 6.3 Minimal traceability of privacy addresses . . . . . . . . 22 92 6.4 Renumbering procedure . . . . . . . . . . . . . . . . . . 22 93 6.5 Site multihoming . . . . . . . . . . . . . . . . . . . . . 22 94 6.6 Untraceable addresses . . . . . . . . . . . . . . . . . . 22 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 96 8. Security Considerations . . . . . . . . . . . . . . . . . . 23 97 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 11.1 Normative References . . . . . . . . . . . . . . . . . . 24 101 11.2 Informative References . . . . . . . . . . . . . . . . . 24 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 103 A. Additional benefits due to Native IPv6 and universal 104 unique addressing . . . . . . . . . . . . . . . . . . . . . 26 105 A.1 Universal any-to-any connectivity . . . . . . . . . . . . 26 106 A.2 Auto-configuration . . . . . . . . . . . . . . . . . . . . 27 107 A.3 Native Multicast services . . . . . . . . . . . . . . . . 27 108 A.4 Increased security protection . . . . . . . . . . . . . . 28 109 A.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 A.6 Merging networks . . . . . . . . . . . . . . . . . . . . . 29 111 A.7 Community of interest . . . . . . . . . . . . . . . . . . 29 112 B. Revision history . . . . . . . . . . . . . . . . . . . . . . 29 113 B.1 Changes from *-nap-00 to *-nap-01 . . . . . . . . . . . . 29 114 Intellectual Property and Copyright Statements . . . . . . . 30 116 1. Introduction 118 Although there are many perceived benefits to Network Address 119 Translation (NAT), its primary benefit of "amplifying" available 120 address space is not needed in IPv6. The serious disadvantages of 121 ambiguous "private" address space and of Network Address Translation 122 (NAT) [2][6] have been well documented [5][7]. However, given its 123 wide market acceptance NAT undoubtedly has some perceived benefits. 124 Indeed, in an Internet model based on universal any-to-any 125 connectivity, product marketing departments have driven a perception 126 that some connectivity and security concerns can only be solved by 127 using a NAT device or by using logically separated LAN address 128 spaces. This document describes the market-perceived reasons to 129 utilize a NAT device in an IPv4 environment and shows how these needs 130 can be met and even exceeded with IPv6. The use of the facilities 131 from IPv6 described in this document avoids the negative impacts of 132 translation and may be described as Network Architecture Protection 133 (NAP). 135 As far as security and privacy is concerned, this document considers 136 how to mitigate a number of threats. Some are obviously external, 137 such as having a hacker trying to penetrate your network, or having a 138 worm infected machine outside your network trying to attack it. Some 139 are local such as a disgruntled employee disrupting business 140 operations, or the unintentional negligence of a user downloading 141 some malware which then proceeds to attack any device on the LAN. 142 Some may be embedded such as having some firmware in a domestic 143 appliance "call home" to its manufacturer without the user's consent. 145 This document describes several techniques that may be combined on an 146 IPv6 site to protect the integrity of its network architecture. 147 These techniques, known collectively as NAP, retain the concept of a 148 well defined boundary between "inside" and "outside" the private 149 network, and allow firewalling, topology hiding, and privacy and will 150 achieve these goals without address translation. 152 IPv6 Network Architecture Protection can be summarized in the 153 following table. It presents the marketed functions of NAT with a 154 cross-reference of how those are delivered in both the IPv4 and IPv6 155 environments. 157 Function IPv4 IPv6 158 +------------------+-----------------------+-----------------------+ 159 | Simple Gateway | DHCP - single | DHCP-PD - arbitrary | 160 | as default router| address upstream | length customer | 161 | and address pool | DHCP - limited | prefix upstream | 162 | manager | number of individual | SLAAC via RA | 163 | | devices downstream | downstream | 164 | | see section 2.1 | see section 4.1 | 165 +------------------|-----------------------|-----------------------+ 166 | Simple Security | Filtering side | Explicit Context | 167 | | effect due to lack | Based Access Control | 168 | | of translation state | (Reflexive ACL) | 169 | | see section 2.2 | see section 4.2 | 170 +------------------|-----------------------|-----------------------+ 171 | Local usage | NAT state table | Address uniqueness | 172 | tracking | | | 173 | | see section 2.3 | see section 4.3 | 174 +------------------|-----------------------|-----------------------+ 175 | End system | NAT transforms | Temporary use | 176 | privacy | device ID bits in | privacy addresses | 177 | | the address | | 178 | | see section 2.4 | see section 4.4 | 179 +------------------|-----------------------|-----------------------+ 180 | Topology hiding | NAT transforms | Untraceable addresses| 181 | | subnet bits in the | using IGP host routes| 182 | | address | /or MIPv6 tunnels for| 183 | | | stationary systems | 184 | | see section 2.4 | see section 4.4 | 185 +------------------|-----------------------|-----------------------+ 186 | Addressing | RFC 1918 | RFC 3177 & ULA | 187 | Autonomy | | | 188 | | see section 2.5 | see section 4.5 | 189 +------------------|-----------------------|-----------------------+ 190 | Global Address | RFC 1918 | 340,282,366,920,938, | 191 | Pool | | 463,463,374,607,431, | 192 | Conservation | | 768,211,456 | 193 | | | (3.4*10^38) addresses| 194 | | see section 2.6 | see section 4.6 | 195 +------------------|-----------------------|-----------------------+ 196 | Renumbering and | Address translation | Preferred lifetime | 197 | Multi-homing | at border | per prefix & Multiple| 198 | | | addresses per | 199 | | | interface | 200 | | see section 2.7 | see section 4.7 | 201 +------------------+-----------------------+-----------------------+ 203 This document first identifies the perceived benefits of NAT in more 204 detail, and then shows how IPv6 NAP can provide each of them. It 205 concludes with a IPv6 NAP case study and a gap analysis of work that 206 remains to be done for a complete NAP solution. 208 2. Perceived benefits of NAT and its impact on IPv4 210 This section provides visibility into the generally perceived 211 benefits of the use of IPv4 NAT. The goal of this description is not 212 to analyze these benefits or discuss the accuracy of the perception 213 (detailed discussions in [5]) , but to describe the deployment 214 requirements and set a context for the later descriptions of the IPv6 215 approaches for dealing with those requirements. 217 2.1 Simple gateway between Internet and internal network 219 A NAT device can connect a private network with any kind of address 220 (ambiguous [RFC 1918] or global registered address) towards the 221 Internet. The address space of the private network can be built from 222 globally unique addresses, from ambiguous address space or from both 223 simultaneously. Without specific configuration from public to 224 private, the NAT device enables access between the client side of an 225 application in the private network with the server side in the public 226 Internet. 228 Wide-scale deployments have shown that using NAT to attach a private 229 IPv4 network to the Internet is simple and practical for the 230 non-technical end user. Frequently a simple user interface is 231 sufficient for configuring both device and application access rights. 233 Additionally, thanks to successful marketing campaigns it is 234 perceived by end users that their equipment is protected from the bad 235 elements and attackers on the public IPv4 Internet. 237 2.2 Simple security due to stateful filter implementation 239 It is frequently believed that a NAT device puts in an extra barrier 240 to keep the private network protected from evil outside influences 241 due to the session-oriented character of NAT technology. Since a NAT 242 typically keeps state only for individual sessions, attackers, worms, 243 etc. cannot exploit this state to attack a host in general and on 244 any port. This benefit may be partially real; however, experienced 245 hackers are well aware of NAT devices and are very familiar with 246 private address space, and have devised methods of attack (such as 247 trojan horses) that readily penetrate NAT boundaries. The secure 248 feeling is in vain. 250 Address translation does not provide security in itself; for example, 251 consider a configuration with static NAT translation and all inbound 252 ports translating to a single machine. In such a scenario the 253 security risk for that machine is identical to the case with no NAT 254 device in the communication path. As result there is no specific 255 security value in the address translation function. The perceived 256 security comes from the lack of pre-established or permanent mapping 257 state. Dynamically establishing state in response to internal 258 requests reduces the threat of unexpected external connections to 259 internal devices. 261 In some cases, NAT operators (including domestic users) may be 262 obliged to configure quite complex port mapping rules to allow 263 external access to local applications such as a multi-player game or 264 web servers. In this case the NAT actually adds management 265 complexity compared to a simple router. In situations where 2 or 266 more devices need to host the same application this complexity shifts 267 from difficult to impossible. 269 2.3 User/Application tracking 271 Although NATs create temporary state for active sessions, in general 272 they provide limited capabilities for the administrator of the NAT to 273 gather information about who in the private network is requesting 274 access to which Internet location. This could in theory be done by 275 logging the network address translation details of the private and 276 the public addresses of the NAT devices state database. 278 The checking of this database is not always a simple task, especially 279 if Port Address Translation is used. It also has an unstated 280 assumption that the administrative instance has a mapping between an 281 IPv4-address and a network element or user at all times, or the 282 administrator has a time-correlated list of the address/port 283 mappings. 285 2.4 Privacy and topology hiding 287 The ability of NAT to provide internet access by the use of a single 288 (or few) global IPv4 routable addresses to a large community of users 289 offers a simple mechanism to hide the internal topology of a network. 290 In this scenario the large community will be reflected in the 291 internet by a single (or few) IPv4 address(es). 293 The use of NAT then results in a user behind a NAT gateway actually 294 appearing on the Internet as a user inside the NAT box itself; i.e., 295 the IPv4 address that appears on the Internet is only sufficient to 296 identify the NAT. When concealed behind a NAT it is impossible to 297 tell from the outside which member of a family, which customer of an 298 Internet cafe, or which employee of a company generated or received a 299 particular packet. Thus, although NATs do nothing to provide 300 application level privacy, they do prevent the external tracking and 301 profiling of individual host computers by means of their IP 302 addresses. At the same time a NAT creates a smaller pool of 303 addresses for a much more focused point of attack. 305 There is a similarity with privacy based on application level 306 proxies. When using an application level gateway for browsing the 307 web for example, the 'privacy' of a web user can be provided by 308 masking the true identity of the original web user towards the 309 outside world (although the details of what is - or is not - logged 310 at the NAT/proxy will be different). 312 Some enterprises prefer to hide as much as possible of their internal 313 network topology from outsiders. Mostly this is achieved by blocking 314 "traceroute" etc., but NAT of course entirely hides the internal 315 subnet topology, which some network managers believe is a useful 316 precaution to mitigate scanning attacks. Scanning for IPv6 can be 317 much harder in comparison with IPv4 as described in [18] 319 Once a list of available devices and IP addresses has been mapped, a 320 port-scan on these IP addresses can be performed. Scanning works by 321 tracking which ports do not receive unreachable errors from either 322 the firewall or host. With the list of open ports an attacker can 323 optimize the time needed for a successful attack by correlating it 324 with known vulnerabilities to reduce the number of attempts. For 325 example, FTP usually runs on port 21, and HTTP usually runs on port 326 80. These open ports could be used for initiating attacks on an end 327 system. 329 2.5 Independent control of addressing in a private network 331 Many private IPv4 networks take benefit from using the address space 332 defined in RFC 1918 to enlarge the available addressing space for 333 their private network, and at the same time reduce their need for 334 globally routable addresses. This type of local control of address 335 resources allows a clean and hierarchical addressing structure in the 336 network. 338 Another benefit is due to the usage of independent addresses on 339 majority of the network infrastructure there is an increased ability 340 to change provider with less operational difficulties. 342 2.6 Global address pool conservation 344 Due to the ongoing depletion of the IPv4 address range, the remaining 345 pool of unallocated IPv4 addresses is below 30%. While mathematical 346 models based on historical IPv4 prefix consumption periodically 347 attempt to predict the future exhaustion date of the IPv4 address 348 pool, a direct result of this continuous resource consumption is that 349 the administrative overhead for acquiring globally unique IPv4 350 addresses will continue increasing in direct response to tightening 351 allocation policies. In response to the increasing administrative 352 overhead many Internet Service Providers (ISPs) have already resorted 353 to the ambiguous addresses defined in RFC 1918 behind a NAT for the 354 various services they provide as well as connections for their end 355 customers. In turn this has restricted the number of and types of 356 applications that can be deployed by these ISPs and their customers. 357 Forced into this limiting situation such customers can rightly claim 358 that despite the optimistic predictions of mathematical models the 359 global pool of IPv4 addresses is effectively already exhausted. 361 2.7 Multihoming and renumbering with NAT 363 The elements of multihoming and renumbering are quite different. 364 However, multihoming is often a transitional state for renumbering, 365 and NAT interacts with both in the same way. 367 For enterprise networks, it is highly desirable to be connected to 368 more than one Internet Service Provider (ISP) and to be able to 369 change ISPs at will. This means that a site must be able to operate 370 under more than one CIDR prefix [1] and/or readily change its CIDR 371 prefix. Unfortunately, IPv4 was not designed to facilitate either of 372 these maneuvers. However, if a site is connected to its ISPs via NAT 373 boxes, only those boxes need to deal with multihoming and renumbering 374 issues. 376 Similarly, if two enterprise IPv4 networks need to be merged, it may 377 well be that installing a NAT box between them will avoid the need to 378 renumber one or both. For any enterprise, this can be a short term 379 financial saving, and allow more time to renumber the network 380 components. The longterm solution is a single network without usage 381 of NAT to avoid the ongoing operational complexity of overlapping 382 addresses. 384 This solution may be sufficient for some networks; however when the 385 merging networks were already using address translation it will 386 create huge problems due to admistrative difficulties of the merged 387 address space. 389 3. Description of the IPv6 tools 391 This section describes several features that can be used to provide 392 the protection features associated with IPv4 NAT. 394 3.1 Privacy addresses (RFC 3041) 396 There are situations where it is desirable to prevent device 397 profiling, such as by contacted web sites, so IPv6 privacy addresses 398 were defined to provide that capability. IPv6 addresses consist of a 399 routing prefix subnet-id part (SID) and an interface identifier part 400 (IID). For interfaces that contain embedded IEEE Link Identifiers 401 the interface identifier is typically derived from it, though this 402 practice facilitates tracking and profiling of a device as it moves 403 around the Internet. RFC 3041 describes an extension to IPv6 404 stateless address autoconfiguration for interfaces [8]. Use of the 405 privacy address extension causes nodes to generate global-scope 406 addresses from interface identifiers that change over time, even in 407 cases where the interface contains an embedded IEEE link identifier. 408 Changing the interface identifier (thus the global-scope addresses 409 generated from it) over time makes it more difficult for 410 eavesdroppers and other information collectors to identify when 411 addresses used in different transactions actually correspond to the 412 same node. A relatively short valid lifetime for the privacy address 413 also has the side effect of reducing the attack profile of a device, 414 as it is not directly attackable once it stops answering at the 415 temporary use address. 417 While the primary implementation and source of randomized RFC 3041 418 addresses is expected to be from end systems running stateless 419 autoconfiguration, there is nothing that prevents a DHCP server from 420 running the RFC 3041 algorithm for any new IEEE identifier it hears, 421 then remembering that for future queries. This would allow using 422 them in DNS for registered services since the assumption of a server 423 based deployment would be a persistent value that minimizes DNS 424 churn. A DHCP based deployment would also allow for local policy to 425 periodically change the entire collection of end device addresses 426 while maintaining some degree of central knowledge and control over 427 which addresses should be in use at any point in time. 429 Randomizing the IID, as defined in RFC 3041, only precludes tracking 430 of the lower 64 bits of the IPv6 address. Masking of the subnet ID 431 will require additional approaches as discussed below in 3.4. 432 Additional considerations are discussed in [17]. Providing privacy 433 for a subnet ID will require different technology. 435 3.2 Unique Local Addresses 437 Local network and application services stability during periods of 438 intermittent connectivity between one or more providers requires 439 address management autonomy. Such autonomy in a single routing 440 prefix environment would lead to massive expansion of the global 441 routing tables, so IPv6 provides for simultaneous use of multiple 442 prefixes. The Unique Local Address prefix (ULA) [16] has been set 443 aside for use in local communications. The ULA address prefix for 444 any network is routable over a locally defined collection of routers. 446 These prefixes are NOT to be routed on the public global Internet as 447 that would have a serious negative impact on global routing. 449 ULAs have the following characteristics: 450 o Globally unique prefix 451 * Allows networks to be combined or privately interconnected 452 without creating any address conflicts or requiring renumbering 453 of interfaces using these prefixes 454 * If accidentally leaked outside of a network via routing or DNS, 455 there is no conflict with any other addresses 456 o ISP independent and can be used for communications inside of a 457 network without having any permanent or intermittent Internet 458 connectivity 459 o Well known prefix to allow for easy filtering at network 460 boundaries 461 o In practice, applications may treat these addresses like global 462 scoped addresses 464 3.3 DHCPv6 prefix delegation 466 The Prefix Delegation (DHCP-PD) options [11] provide a mechanism for 467 automated delegation of IPv6 prefixes using the Dynamic Host 468 Configuration Protocol (DHCP) [10]. This mechanism (DHCP-PD) is 469 intended for delegating a long-lived prefix from a delegating router 470 to a requesting router, across an administrative boundary, where the 471 delegating router does not require knowledge about the topology of 472 the links in the network to which the prefixes will be assigned. 474 3.4 Untraceable IPv6 addresses 476 These should be globally routable IPv6 addresses which can be 477 randomly and independently assigned to IPv6 devices. 479 The random assignment has as purpose to confuse the outside world on 480 the structure of the local network. However for the local network 481 there is a correlation between the location of the device and the 482 untraceable IPv6 address. This correlation could be done by 483 generating IPv6 host route entries or by utilizing an aggregation 484 device like a Mobile IPv6 Home Gateway. 486 The main goal of untraceable IPv6 addresses is to create an 487 apparently unpredictable network infrastructure as seen from external 488 networks to protect the local infrastructure from malicious outside 489 influences or from mapping any correlation between the network 490 activities of multiple devices from external networks. When using 491 untraceable IPv6 addresses, it could be that two apparently 492 sequential addresses are reachable on very different parts of the 493 local network instead of belonging to the same subnet next to each 494 other. 496 4. Using IPv6 technology to provide the market perceived benefits of 497 NAT 499 The facilities in IPv6 can be used to provide the protection 500 perceived to be associated with IPv4 NAT. This section gives some 501 examples of how IPv6 can be used securely. 503 4.1 Simple gateway between Internet and internal network 505 As a simple gateway, the device has the role of managing both packet 506 Routing and local address management. A basic IPv6 router could have 507 a default configuration to advertize inside the site a locally 508 generated random ULA prefix, independently from the state of any 509 external connectivity. This would allow local nodes to communicate 510 amongst themselves prior to establishing a global connection. If the 511 network happened to concatenate with another local network, this is 512 highly unlikely to result in address collisions. With external 513 connectivity the simple gateway could also use DHCP-PD to acquire a 514 routing prefix from the service provider for use when connecting to 515 the global Internet. End node connections involving other nodes on 516 the global Internet will always use the global IPv6 addresses [9] 517 derived from this prefix delegation. In the very simple case there 518 is no explicit routing protocol and a single default route is used 519 out to the global Internet. A slightly more complex case might 520 involve local routing protocols, but with the entire local network 521 sharing a common global prefix there would still not be a need for an 522 external routing protocol as a default route would continue to be 523 consistent with the connectivity. 525 4.2 IPv6 and Simple security 527 The vulnerability of an IPv6 host is similar as for an IPv4 host 528 directly connected towards the Internet, and firewall and IDS systems 529 are recommended. However, with IPv6, the following protections are 530 available without the use of NAT: 532 1. Short lifetimes on privacy extension suffixes reduce the attack 533 profile since the node will not respond to the address once the 534 address is no longer valid. 535 2. IPsec is a mandatory service for IPv6 implementations. IPsec 536 functions to prevent session hijacking, prevent content 537 tampering, and optionally masks the packet contents. While IPsec 538 might be available in IPv4 implementations, deployment in NAT 539 environments either breaks the protocol or requires complex 540 helper services with limited functionality or efficiency. 542 3. The size of the typical subnet ::/64 will make a network ping 543 sweep and resulting port-scan virtually impossible due to the 544 amount of possible combinations available. This goes from the 545 assumption that the attacker has no access to a local connection. 546 If an attacker has local access then he could use ND [4] and 547 ping6 to ff02::1 to detect local neighbors. (Of course, a 548 locally connected attacker has many scanning options with IPv4 as 549 well.) It is recommended for site administrators to take [18] 550 into consideration to achieve the expected goal. 552 IPv4 NAT was not developed as a security mechanism. Despite 553 marketing messages to the contrary it is not a security mechanism, 554 and hence it will pose some security holes while many people assume 555 their network is secure due to the usage of NAT. This is directly 556 the opposite of what IPv6 security best-practices are trying to 557 achieve. 559 An example of a potential set of firewall rules could be: 561 Source_A: IPv6 Home broadband user 562 located on the internal network 563 Destination_B: IPv6 HTTP server 564 located on the external network 566 On the edge broadband router a security rule could be: 568 Internal network -> external network: 570 Actions: 571 Allow all traffic 572 Create reflective session state (true) for the session 574 External network -> internal network 576 Actions: 577 If the session had reflective 'true'-state, 578 then allow the inbound traffic 579 If the session had reflective 'false' state, 580 then drop the traffic 582 This simple rule would create similar protection and security holes 583 the typical IPv4 NAT device will offer and may for example be enabled 584 by default on all broadband edge-routers,with that difference that 585 the security caveats will be documented, and may hence be removed 586 with the next revision of the rule. The goal is that at every 587 iteration, the IPv6 internet will become more secure for the 588 oblivious users. 590 Assuming the network administrator is aware of [18] the increased 591 size of the IPv6 address will make topology probing much harder, and 592 almost impossible for IPv6 devices. What one does when topology 593 probing is to get an idea of the available hosts inside an 594 enterprise. This mostly starts with a ping-sweep. This is an 595 automated procedure of sending Internet Control Message Protocol 596 (ICMP) echo requests (also known as PINGs) to a range of IP addresses 597 and recording replies. This can enable an attacker to map the 598 network. Since the IPv6 subnets are 64 bits worth of address space, 599 this means that an attacker has to send out a simply unrealistic 600 number of pings to map the network, and virus/worm propagation will 601 be thwarted in the process. At full rate 40Gbps (400 times the 602 typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access 603 link) it takes over 5000 years to scan a single 64 bit space. 605 4.3 User/Application tracking 607 IPv6 enables the collection of information about data flows. Due to 608 the fact that all addresses used for Internet and intra-/inter- site 609 communication are unique, it is possible for an enterprise or ISP to 610 get very detailed information on any communication exchange between 611 two or more devices. This enhances the capability of data-flow 612 tracking for security audits compared with IPv4 NAT, because in IPv6 613 a flow between a sender and receiver will always be uniquely 614 identified due to the unique IPv6 source and destination addresses. 616 4.4 Privacy and topology hiding using IPv6 618 Partial host privacy is achieved in IPv6 using pseudo-random privacy 619 addresses (RFC 3041) which are generated as required, so that a 620 session can use an address that is valid only for a limited time. 621 Exactly like IPv4 NAT, this only allows such a session to be traced 622 back to the subnet that originates it, but not immediately to the 623 actual host. 625 If a network manager wishes to conceal the internal IPv6 topology, 626 and the majority of its host computer addresses, a good option will 627 be to run all internal traffic using ULA since such packets can by 628 definition never exit the site. For hosts that do in fact need to 629 generate external traffic, by using multiple IPv6 addresses (ULAs and 630 one or more global addresses), it will be possible to hide and mask 631 some or all of the internal network. As discussed above, there are 632 multiple parts to the IPv6 address, and different techniques to 633 manage privacy for each. 635 When a network manager also wishes to conceal the internal IPv6 636 topology, by using explicit host routes it is possible to locate 637 nodes on one segment while they appear externally to be on another. 639 An alternative method to hide the internal topology would be to use 640 Mobile IPv6 internally without route optimization where the public 641 facing addresses are consolidated on an edge Home Agent (HA), then 642 use MIPv6 in bidirectional tunnel mode between the HA and topology 643 masked node using the ULA as a COA This truly masks the internal 644 topology as all nodes with global access appear to share a common 645 subnet. There is no reason that rack mounted devices shouldn't be 646 considered mobile nodes to mask the internal topology. It looks 647 equivalent to running a VPN to a central server, however it does not 648 involve any encryption or significant overhead. 650 4.5 Independent control of addressing in a private network 652 IPv6 provides for autonomy in local use addresses through ULAs. At 653 the same time IPv6 simplifies simultaneous use of multiple addresses 654 per interface so that a NAT is not required (or even defined) between 655 the ULA and the public Internet. Nodes that need access to the 656 public Internet may have a ULA for local use, and will have a global 657 use address because the global use IPv6 address space is not a scarce 658 resource like the global use IPv4 space. While global IPv6 659 allocation policy is managed through the Regional Internet 660 Registries, it is expected that they will continue with derivatives 661 of RFC 3177 for the foreseeable future. 663 When using IPv6, the need to ask for more address space will become 664 far less likely due to the increased size of the subnets. These 665 subnets typically allow 2^64 hosts per subnet and an enterprise will 666 typically receive a /48 which allows segmentation into at least 2^16 667 different subnets. 669 The ongoing subnet size maintenance may become simpler when IPv6 670 technology is utilised. If IPv4 address space is optimised one has 671 periodically to look into the number of hosts on a segment and the 672 subnet size allocated to the segment; an enterprise today may have a 673 mix of /28 - /23 size subnets for example, and may shrink/grow these 674 as their network user base/etc changes. In v6, it's all /64. 676 4.6 Global address pool conservation 678 IPv6 provides sufficient space to completely avoid the need for 679 overlapping address space, 680 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total 681 possible addresses. As previously discussed, the serious 682 disadvantages of ambiguous address space have been well documented, 683 and with sufficient space there is no need to continue the 684 increasingly aggressive conservation practices that are necessary 685 with IPv4. While IPv6 allocation policies and ISP business practice 686 will continue to evolve, the recommendations in RFC 3177 are based on 687 the technical potential of the vast IPv6 address space. That 688 document demonstrates that there is no resource limitation which will 689 lead to the IPv4 practice of ambiguous space behind a NAT. As an 690 example of the direct contrast, many expansion oriented IPv6 691 deployment scenarios result in multiple IPv6 addresses per device, as 692 opposed to the IPv4 constricting scenarios of multiple devices 693 sharing a scarce global address. 695 4.7 Multihoming and renumbering 697 Multihoming and renumbering remain technically challenging with IPv6 698 (see the Gap Analysis below). However, IPv6 was designed to allow 699 sites and hosts to run with several simultaneous CIDR-like prefixes 700 and thus with several simultaneous ISPs. An address selection 701 mechanism [12] is specified so that hosts will behave consistently 702 when several addresses are simultaneously valid. The fundamental 703 difficulty that IPv4 has in this regard therefore does not apply to 704 IPv6. IPv6 sites can and do run today with multiple ISPs active, and 705 the processes for adding and removing active prefixes at a site have 706 been documented [15] and [19]. 708 The IPv6 address space allocated by the ISP will be dependent upon 709 the connecting Service provider. This may result in a renumbering 710 effort if the network changes from Service Provider. When changing 711 ISPs or ISPs readjusting their addressing pool, DHCP-PD [13] can be 712 used as the zero-touch external mechanism for prefix change in 713 conjunction with a ULA prefix for internal connection stability. 714 With appropriate management of the lifetime values and overlap of the 715 external prefixes, a smooth make-before-break transition is possible 716 as existing communications will continue on the old prefix as long as 717 it remains valid, while any new communications will use the new 718 prefix. 720 5. Case Studies 722 It is possible to divide the type of networks in different 723 categories. This can be done on various criteria. The criteria used 724 within this document are based on the number of components or 725 connections. For each of these category of networks we can use IPv6 726 Network Architecture Protection to achieve a secure and flexible 727 infrastructure, which provides an enhanced network functionality in 728 comparison with the usage of address translation. 730 o Medium/large private networks (typically >10 connections) 731 o Small private networks (typically 1 to 10 connections) 732 o Single user connection (typically 1 connection) 733 o ISP/Carrier customer networks 735 5.1 Medium/large private networks 737 Under this category fall the majority of private enterprise networks. 738 Many of these networks have one or more exit points to the Internet. 739 Though these organizations have sufficient resources to acquire 740 addressing independence there are several reasons why they might 741 choose to use NAT in such a network. For the ISP there is no need to 742 import the IPv4 address range from the remote end-customer, which 743 facilitates IPv4 address summarization. The customer can use a 744 larger IPv4 address range (probably with less-administrative 745 overhead) by the use of RFC 1918 and NAT. The customer also reduces 746 the overhead in changing to a new ISP, because the addresses assigned 747 to devices behind the NAT do not need to be changed when the customer 748 is assigned a different address by a new ISP. By using address 749 translation one avoids the need for network renumbering. Finally, 750 the customer can provide privacy about its hosts and the topology of 751 its internal network if the internal addresses are mapped through 752 NAT. 754 It is expected that there will be enough IPv6 addresses available for 755 all networks and appliances for the foreseeable future. The basic 756 IPv6 address-range an ISP allocates for a private network is large 757 enough (currently /48) for most of the medium and large enterprises, 758 while for the very large private enterprise networks address-ranges 759 can be concatenated. A single /48 alloaction provides an enterprise 760 network with 65536 different /64 prefixes. 762 The summarization benefit for the ISP is happening based on the IPv6 763 allocation rules. This means that the ISP will provide the 764 enterprise with an IPv6 address-range (typically a one or multiple 765 range(s) of '/48') from its RIR assigned IPv6 address-space. The 766 goal of this allocation mechanism is to decrease the total amount of 767 entries in the internet routing table. 769 To mask the identity of a user on a network of this type, the usage 770 of IPv6 privacy extensions may be advised. This technique is useful 771 when an external element wants to track and collect all information 772 sent and received by a certain host with known IPv6 address. Privacy 773 extensions add a random factor to the host part of an IPv6 address 774 and will make it very hard for an external element to keep 775 correlating the IPv6 address to a host on the inside network. The 776 usage of IPv6 privacy extensions does not mask the internal network 777 structure of an enterprise network. 779 If there is need to mask the internal structure towards the external 780 IPv6 internet, then some form of 'Untraceable' addresses may be used. 781 These addresses will be derived from a local pool, and may be 782 assigned to those hosts for which topology masking is required or 783 which want to reach the IPv6 Internet or other external networks. 784 The technology to assign these addresses to the hosts could be based 785 on DHCPv6. To complement the 'Untraceable' addresses it is needed to 786 have at least awareness of the IPv6 address location when routing an 787 IPv6 packet through the internal network. This could be achieved by 788 'route-injection' in the network infrastructure. This 789 route-injection could be done based on /128 host-routes to each 790 device that wants to connect to the Internet using an untraceable 791 address. This will provide the most dynamic masking, but will have a 792 scalability limitation, as an IGP is typically not designed to carry 793 many thousands of IPv6 prefixes. A large enterprise may have 794 thousands of hosts willing to connect to the Internet. Less flexible 795 masking could be to have time-based IPv6 prefixes per link or subnet. 796 This may reduce the amount of route entries in the IGP by a 797 significant factor, but has as trade-off that masking is time and 798 subnet based. 800 The dynamic allocation of 'Untraceable' addresses can also limit the 801 IPv6 access between local and external hosts to those local hosts 802 being authorized for this capability. Dynamically allocated 803 'Untraceable' addresses may also facilitate and simplify the 804 connectivity to the outside networks during renumbering, because the 805 existing IPv6 central address pool could be swapped for the newly 806 allocated IPv6 address pool. 808 The use of permanent ULA addresses on a site provides the benefit 809 that even if an enterprise would change its ISP, the renumbering is 810 only affecting those devices that have a wish to connect beyond the 811 site. Internal servers and services would not change their allocated 812 IPv6 ULA address, and the service would remain available even during 813 global address renumbering. 815 5.2 Small private networks 817 Also known as SOHO (Small Office/Home Office) networks, this 818 category describes those networks which have few routers in the 819 topology, and usually have a single network egress point. Typically 820 these networks are connected via either a dial-up connection or 821 broadband access; don't have dedicated Network Operation Center 822 (NOC); and through economic pressure are typically forced today to 823 use NAT. In most cases the received global IPv4 prefix is not fixed 824 over time and is too long to provide every node in the private 825 network with a unique globally usable address. Fixing either of 826 those issues typically adds an administrative overhead for address 827 management to the user. This category may even be limited to 828 receiving ambiguous IPv4 addresses from the service provider based on 829 RFC 1918. An ISP will typically pass along the higher administration 830 cost attached to larger address blocks, or IPv4 prefixes that are 831 static over time, due to the larger public address pool each of those 832 requires. 834 As a direct response to explicit charges per public address most of 835 this category has deployed NAPT (port demultiplexing NAT) to minimize 836 the number of addresses in use. Unfortunately this also limits the 837 Internet capability of the equipment to being mainly a receiver of 838 Internet data (client), and makes it quite hard for the equipment to 839 become a world wide Internet server (i.e. HTTP, FTP, etc.) due to 840 the stateful operation of the NAT equipment. Even when there is 841 sufficient technical knowledge to manage the NAT to enable a server, 842 only one server of any given protocol type is possible per address, 843 and then only when the address from the ISP is public. 845 When deploying IPv6 NAP in this environment, there are two approaches 846 possible with respect to IPv6 addressing. 847 o DHCPv6 Prefix-Delegation 848 o ISP provides a static IPv6 address-range 850 For the DHCPv6-PD solution, a dynamic address allocation approach 851 is chosen. By means of the enhanced DHCPv6 protocol it is possible 852 to have the ISP push down an IPv6 prefix range automatically towards 853 the small private network and populate all interfaces in that small 854 private network dynamically. This reduces the burden for 855 administrative overhead because everything happens automatically. 857 For the static configuration the mechanisms used could be the 858 same as for the medium/large enterprises. Typically the need for 859 masking the topology will not be of high priority for these users, 860 and the usage of IPv6 privacy extensions could be sufficient. 862 For both alternatives the ISP has the unrestricted capability for 863 summarization of its RIR allocated IPv6 prefix, while the small 864 private network administrator has all flexibility in using the 865 received IPv6 prefix to its advantage because it will be of 866 sufficient size to allow all the local nodes to have a public address 867 and full range of ports available whenever necessary. 869 While a full prefix is expected to be the primary deployment model 870 there may be cases where the ISP provides a single IPv6 address for 871 use on a single piece of equipment (PC, PDA, etc.). This is expected 872 to be rare though, because in the IPv6 world the assumption is that 873 there is an unrestricted availability of a large amount of globally 874 routable and unique address space. If scarcity was the motivation 875 with IPv4 to provide RFC 1918 addresses, in this environment the ISP 876 will not be motivated to allocate private addresses towards the 877 single user connection because there are enough global addresses 878 available at essentially the same cost. Also if the single device 879 wants to mask its identity to the called party or its attack profile 880 over a short time window it will need to enable IPv6 privacy 881 extensions, which in turn leads to the need for a minimum allocation 882 of a /64 prefix rather than a single address. 884 5.3 Single user connection 886 This group identifies the users which are connected via a single IPv4 887 address and use a single piece of equipment (PC, PDA, etc.). This 888 user may get an ambiguous IPv4 address (frequently imposed by the 889 ISP) from the service provider which is based on RFC 1918. If 890 ambiguous addressing is utilized, the service provider will execute 891 NAT on the allocated IPv4 address for global Internet connectivity. 892 This also limits the internet capability of the equipment to being 893 mainly a receiver of Internet data, and makes it quite hard for the 894 equipment to become a world wide internet server (i.e. HTTP, FTP, 895 etc.) due to the stateful operation of the NAT equipment. 897 When using IPv6 NAP, this group will identify the users which are 898 connected via a single IPv6 address and use a single piece of 899 equipment (PC, PDA, etc.). 901 In IPv6 world the assumption is that there is unrestricted 902 availability of a large amount of globally routable and unique IPv6 903 addresses. The ISP will not be motivated to allocate private 904 addresses towards the single user connection because he has enough 905 global addresses available, if scarcity was the motivation with IPv4 906 to provide RFC 1918 addresses. If the single user wants to mask his 907 identity, he may choose to enable IPv6 privacy extensions. 909 5.4 ISP/Carrier customer networks 911 This group refers to the actual service providers that are providing 912 the IPv4 access and transport services. They tend to have three 913 separate IPv4 domains that they support: 914 o For the first they fall into the Medium/large private networks 915 category (above) for their own internal networks, LANs etc. 916 o The second is the Operations network which addresses their 917 backbone and access switches, and other hardware, this is separate 918 for both engineering reasons as well as simplicity in managing the 919 security of the backbone. 920 o The third is the IP addresses (single or blocks) that they assign 921 to customers. These can be registered addresses (usually given to 922 category a and b and sometimes c) or can be from a pool of RFC 923 1918 addresses used with NAT for single user connections. 924 Therefore they can actually have two different NAT domains that 925 are not connected (internal LAN and single user customers). 927 When IPv6 NAP is utilized in these three domains then for the first 928 category it will be possible to use the same solutions as described 929 in chapter 5.1. The second domain of the ISP/carrier is the 930 Operations network. This environment tends to be a closed 931 environment, and consequently intra- communication can be done based 932 on ULA addresses. This would give a stable configuration with 933 respect to a local IPv6 address plan. Using these local scope 934 addresses would also prevent from being accessed from the external 935 network. The third is the IPv6 addresses that ISP/carrier network 936 assign to customers. These will typically be assigned with prefix 937 lengths terminating on nibble boundaries to be consistent with the 938 DNS PTR records. As scarcity of IPv6 addresses is not a concern, it 939 will be possible for the ISP to provide global routable IPv6 prefixes 940 without a requirement for address translation. An ISP may for 941 commercial reasons still decide to restrict the capabilities of the 942 end users by other means like traffic and/or route filtering etc. 944 If the carrier network is a mobile provider, then IPv6 is encouraged 945 in comparison with the combination of IPv4+NAT for 3GPP attached 946 devices. When looking in chapter 2.3 of RFC3314 'Recommendations for 947 IPv6 in 3GPP Standards September 2002' [9] it is found that the IPv6 948 WG recommends that one or more /64 prefixes should be assigned to 949 each primary PDP context. This will allow sufficient address space 950 for a 3GPP-attached node to allocate privacy addresses and/or route 951 to a multi-link subnet, and will discourage the use of NAT within 952 3GPP-attached devices. 954 6. IPv6 gap analysis 956 Like IPv4 and any major standards effort, IPv6 standardization 957 work continues as deployments are ongoing. This section discusses 958 several topics for which additional standardization, or documentation 959 of best practice, is required to fully realize the benefits of NAP. 960 None of these items are show-stoppers for immediate usage of NAP in 961 roles where there are no current gaps. 963 6.1 Completion of work on ULAs 965 As noted above, a new form of Unique Local IPv6 Unicast Addresses 966 (ULAs) is being standardized by the IETF. Experience to date has 967 shown that most network managers want to gain some operational 968 familiarity with IPv6 in their local environment before exposing 969 their network to the live global Internet. Since these addresses 970 allow autonomy for local deployment of IPv6 in private networks, this 971 work should be completed as soon as possible. In addition to 972 autonomy the routing limitation of ULA addresses protects nodes that 973 are only for local use from global exposure. 975 6.2 Subnet topology masking 977 There really is no functional gap here as a centrally assigned 978 pool of addresses in combination with host routes in the IGP is an 979 effective way to mask topology. If necessary a best practice 980 document could be developed describing the interaction between DHCP 981 and various IGPs which would in effect define Untraceable Addresses. 983 As an alternative some work in Mobile IP to define a policy 984 message where a mobile node would learn from the home agent that it 985 should not even try to inform its correspondent about route 986 optimization (and thereby expose its real location) would allow a 987 border home agent using internal tunneling to the logically mobile 988 node (potentially rack mounted) to completely mask all internal 989 topology while avoiding the strain from a large number of host routes 990 in the IGP. This work should be pursued in the IETF. 992 6.3 Minimal traceability of privacy addresses 994 Privacy addresses (RFC 3041) may certainly be used to limit the 995 traceability of external traffic flows back to specific hosts, but 996 lacking a topology masking component above they would still reveal 997 the subnet address bits. For complete privacy a best practice 998 document describing the combination of privacy addresses with 999 topology masking is required. This work remains to be done, and 1000 should be pursued by the IETF. 1002 6.4 Renumbering procedure 1004 Documentation of site renumbering procedures [15] should be 1005 completed. It should also be noticed that ULAs will help here too, 1006 since a change of ISP prefix will only affect hosts that need an 1007 externally routeable address as well as a ULA. 1009 6.5 Site multihoming 1011 This complex problem has never been well solved for IPv4, which is 1012 exactly why NAT has been used as a partial solution. For IPv6, after 1013 several years' work, the relevant IETF WG is finally converging on an 1014 architectural approach intended to reconcile enterprise and ISP 1015 perspectives. Again, ULAs will help since they will provide stable 1016 addressing for internal communications that are not affected by 1017 multihoming. 1019 6.6 Untraceable addresses 1021 The details of the untraceable addresses, along with any associated 1022 mechanisms such as route injection, must be worked out and specified. 1024 7. IANA Considerations 1026 This document requests no action by IANA 1028 8. Security Considerations 1030 While issues which are potentially security related are discussed 1031 throughout the document, the approaches herein do not introduce any 1032 new security concerns. Product marketing departments have widely 1033 sold IPv4 NAT as a security tool, though the misleading nature of 1034 those claims has been previously documented in RFC 2663 [3] and RFC 1035 2993 [5]. 1037 This document defines IPv6 approaches which collectively achieve 1038 the goals of the network manager without the negative impact on 1039 applications or security that are inherent in a NAT approach. To the 1040 degree that these techniques improve a network manager's ability to 1041 explicitly know about or control access, and thereby manage the 1042 overall attack exposure of local resources, they act to improve local 1043 network security. In particular the explicit nature of a content 1044 aware firewall in NAP will be a vast security improvement over the 1045 NAT artifact where lack of translation state has been widely sold as 1046 a form of protection. 1048 9. Conclusion 1050 This document has described a number of techniques that may be 1051 combined on an IPv6 site to protect the integrity of its network 1052 architecture. These techniques, known collectively as Network 1053 Architecture Protection, retain the concept of a well defined 1054 boundary between "inside" and "outside" the private network, and 1055 allow firewalling, topology hiding, and privacy. However, because 1056 they preserve address transparency where it is needed, they achieve 1057 these goals without the disadvantage of address translation. Thus, 1058 Network Architecture Protection in IPv6 can provide the benefits of 1059 IPv4 Network Address Translation without the corresponding 1060 disadvantages. 1062 The document has also identified a few ongoing IETF work items that 1063 are needed to realize 100% of the benefits of NAP. 1065 10. Acknowledgements 1067 Christian Huitema has contributed during the initial round table to 1068 discuss the scope and goal of the document, while the European Union 1069 IST 6NET project acted as a catalyst for the work documented in this 1070 draft. Editorial comments and contributions have been received from: 1071 Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar, 1072 Salman Asadullah, Patrick Grossetete and other members of the v6ops 1073 WG. 1075 11. References 1077 11.1 Normative References 1079 11.2 Informative References 1081 [1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless 1082 Inter-Domain Routing (CIDR): an Address Assignment and 1083 Aggregation Strategy", RFC 1519, September 1993. 1085 [2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 1086 Lear, "Address Allocation for Private Internets", BCP 5, 1087 RFC 1918, February 1996. 1089 [3] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 1090 (NAT) Terminology and Considerations", RFC 2663, August 1999. 1092 [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 1093 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1095 [5] Hain, T., "Architectural Implications of NAT", RFC 2993, 1096 November 2000. 1098 [6] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1099 Translator (Traditional NAT)", RFC 3022, January 2001. 1101 [7] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 1102 IP Network Address Translator", RFC 3027, January 2001. 1104 [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1105 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1107 [9] Wasserman, M., "Recommendations for IPv6 in Third Generation 1108 Partnership Project (3GPP) Standards", RFC 3314, September 1109 2002. 1111 [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 1112 Carney, "Dynamic Host Configuration Protocol for IPv6 1113 (DHCPv6)", RFC 3315, July 2003. 1115 [11] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, 1116 "Representing Internet Protocol version 6 (IPv6) Addresses in 1117 the Domain Name System (DNS)", RFC 3363, August 2002. 1119 [12] Draves, R., "Default Address Selection for Internet Protocol 1120 version 6 (IPv6)", RFC 3484, February 2003. 1122 [13] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1123 Configuration Protocol (DHCP) version 6", RFC 3633, December 1124 2003. 1126 [14] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 1127 (RP) Address in an IPv6 Multicast Address", RFC 3956, November 1128 2004. 1130 [15] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering 1131 an IPv6 Network without a Flag Day", 1132 Internet-Draft draft-ietf-v6ops-renumbering-procedure-03, 1133 November 2004. 1135 [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1136 Addresses", 1137 Internet-Draft draft-ietf-ipv6-unique-local-addr-08, November 1138 2004. 1140 [17] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful 1141 (draft-dupont-ipv6- rfc3041harmful-05.txt)", June 2004. 1143 [18] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning 1144 (chown-v6ops- port-scanning-implications-01.txt)", July 2004. 1146 [19] Chown, T., Tompson, M. and A. Ford, "Things to think about when 1147 Renumbering an IPv6 network 1148 (draft-chown-v6ops-renumber-thinkabout-00)", October 2004. 1150 Authors' Addresses 1152 Gunter Van de Velde 1153 Cisco Systems 1154 De Kleetlaan 6a 1155 Diegem 1831 1156 Belgium 1158 Phone: +32 2704 5473 1159 Email: gunter@cisco.com 1160 Tony Hain 1161 Cisco Systems 1162 500 108th Ave. NE 1163 Bellevue, Wa. 1164 USA 1166 Email: alh-ietf@tndh.net 1168 Ralph Droms 1169 Cisco Systems 1170 1414 Massachusetts Avenue 1171 Boxborough, MA 01719 1172 USA 1174 Email: rdroms@cisco.com 1176 Brian Carpenter 1177 IBM Corporation 1178 Sauemerstrasse 4 1179 Rueschlikon, 8803 1180 Switzerland 1182 Email: brc@zurich.ibm.com 1184 Eric Klein 1185 TTI Telecom 1186 Petach Tikvah, 1187 Israel 1189 Phone: +972 3 926-9130 1190 Email: erick@tti-telecom.com 1192 Appendix A. Additional benefits due to Native IPv6 and universal unique 1193 addressing 1195 The users of native IPv6 technology and global unique IPv6 addresses 1196 have the potential to make use of the enhanced IPv6 capabilities, in 1197 addition to the benefits offered by the IPv4 technology. 1199 A.1 Universal any-to-any connectivity 1201 One of the original design points of the Internet was any-to-any 1202 connectivity. The dramatic growth of Internet connected systems 1203 coupled with the limited address space of the IPv4 protocol spawned 1204 address conservation techniques. NAT was introduced as a tool to 1205 reduce demand on the limited IPv4 address pool, but the side effect 1206 of the NAT technology was to remove the any-to-any connectivity 1207 capability. By removing the need for address conservation (and 1208 therefore NAT), IPv6 returns the any-to-any connectivity model and 1209 removes the limitations on application developers. With the freedom 1210 to innovate unconstrained by NAT traversal efforts, developers will 1211 be able to focus on new advanced network services (i.e. peer-to-peer 1212 applications, IPv6 embedded IPsec communication between two 1213 communicating devices, instant messaging, Internet telephony, etc..) 1214 rather than focusing on discovering and traversing the increasingly 1215 complex NAT environment. 1217 It will also allow application and service developers to rethink the 1218 security model involved with any-to-any connectivity, as the current 1219 edge firewall solution in IPv4 may not be sufficient for Any-to-any 1220 service models. 1222 A.2 Auto-configuration 1224 IPv6 offers a scalable approach to minimizing human interaction and 1225 device configuration. Whereas IPv4 implementations require touching 1226 each end system to indicate the use of DHCP vs. a static address and 1227 management of a server with the pool size large enough for the 1228 potential number of connected devices, IPv6 uses an indication from 1229 the router to instruct the end systems to use DHCP or the stateless 1230 auto configuration approach supporting a virtually limitless number 1231 of devices on the subnet. This minimizes the number of systems that 1232 require human interaction as well as improves consistency between all 1233 the systems on a subnet. In the case that there is no router to 1234 provide this indication, an address for use on the local link only 1235 will be derived from the interface media layer address. 1237 A.3 Native Multicast services 1239 Multicast services in IPv4 were severely restricted by the limited 1240 address space available to use for group assignments and an implicit 1241 locally defined range for group membership. IPv6 multicast corrects 1242 this situation by embedding explicit scope indications as well as 1243 expanding to 4 billion groups per scope. In the source specific 1244 multicast case, this is further expanded to 4 billion groups per 1245 scope per subnet by embedding the 64 bits of subnet identifier into 1246 the multicast address. 1248 IPv6 allows also for innovative usage of the IPv6 address length, and 1249 makes it possible to embed the multicast 'Rendez-Vous Point' (or RP) 1250 [14] directly in the IPv6 multicast address when using ASM multicast. 1251 this is not possible with limited size of the IPv4 address. This 1252 approach also simplifies the multicast model considerably, making it 1253 easier to understand and deploy. 1255 A.4 Increased security protection 1257 The security protection offered by native IPv6 technology is more 1258 advanced than IPv4 technology. There are various transport 1259 mechanisms enhanced to allow a network to operate more securely with 1260 less performance impact: 1261 o IPv6 has the IPsec technology directly embedded into the IPv6 1262 protocol. This allows for simpler peer-to-peer encryption and 1263 authentication, once a simple key/trust management model is 1264 developed, while the usage of some other less secure mechanisms is 1265 avoided (i.e. md5 password hash for neighbor authentication). 1266 o On a local network, any user will have more security awareness. 1267 This awareness will motivate the usage of simple firewall 1268 applications/devices to be inserted on the border between the 1269 external network and the local (or home network) as there is no 1270 Address Translater and hance no false safety perception. 1271 o All flows on the Internet will be better traceable due to a unique 1272 and globally routable source and destination IPv6 address. This 1273 may facilitate an easier methodology for back-tracing DoS attacks 1274 and avoid illegal access to network resources by simpler traffic 1275 filtering. 1276 o The usage of private address-space in IPv6 is now provided by 1277 Unique Local Addresses, which will avoid conflict situations when 1278 merging networks and securing the internal communication on a 1279 local network infrastructure due to simpler traffic filtering 1280 policy. 1281 o The technology to enable source-routing on a network 1282 infrastructure has been enhanced to allow this feature to 1283 function, without impacting the processing power of intermediate 1284 network devices. The only devices impacted with the 1285 source-routing will be the source and destination node and the 1286 intermediate source-routed nodes. This impact behavior is 1287 different if IPv4 is used, because then all intermediate devices 1288 would have had to look into the source-route header. 1290 A.5 Mobility 1292 Anytime, anywhere, universal access requires MIPv6 services in 1293 support of mobile nodes. While a Home Agent is required for initial 1294 connection establishment in either protocol version, IPv6 mobile 1295 nodes are able to optimize the path between them using the MIPv6 1296 option header while IPv4 mobile nodes are required to triangle route 1297 all packets. In general terms this will minimize the network 1298 resources used and maximize the quality of the communication. 1300 A.6 Merging networks 1302 When two IPv4 networks want to merge it is not guaranteed that both 1303 networks would be using different address-ranges on some parts of the 1304 network infrastructure due to the legitimate usage of RFC 1918 1305 private addressing. This potential overlap in address space may 1306 complicate a merge of two and more networks dramatically due to the 1307 additional IPv4 renumbering effort. i.e. when the first network has 1308 a service running (NTP, DNS, DHCP, HTTP, etc..) which need to be 1309 accessed by the 2nd merging network. Similar address conflicts can 1310 happen when two network devices from these merging networks want to 1311 communicate. 1313 With the usage of IPv6 the addressing overlap will not exist because 1314 of the existence of the Unique Local Address usage for private and 1315 local addressing. 1317 A.7 Community of interest 1319 Although some Internet-enabled devices will function as fully-fledged 1320 Internet hosts, it is believed that many will be operated in a highly 1321 restricted manner functioning largely or entirely within a Community 1322 of Interest. By Community of Interest we mean a collection of hosts 1323 that are logically part of a group reflecting their ownership or 1324 function. Typically, members of a Community of Interest need to 1325 communicate within the community but should not be generally 1326 accessible on the Internet. They want the benefits of the 1327 connectivity provided by the Internet, but do not want to be exposed 1328 to the rest of the world. This functionality will be available 1329 through the usage of NAP and native IPv6 dataflows, without any 1330 stateful device in the middle. It will also allow to build virtual 1331 organization networks on the fly, which is very difficult to do in 1332 IPv4+NAT scenarios. 1334 Appendix B. Revision history 1336 B.1 Changes from *-nap-00 to *-nap-01 1337 o Document introduction has been revised and overview table added 1338 o Comments and suggestions from nap-00 draft have been included. 1339 o Initial section of -00 draft 2.6 and 4.6 have been aggregated into 1340 a new æcase studyÆ section 5. 1341 o The list of additional IPv6 benefits has been been placed into 1342 appendix. 1343 o new security considerations section added. 1344 o GAP analysis revised. 1345 o Section 2.6 and 4.6 have been included. 1347 Intellectual Property Statement 1349 The IETF takes no position regarding the validity or scope of any 1350 Intellectual Property Rights or other rights that might be claimed to 1351 pertain to the implementation or use of the technology described in 1352 this document or the extent to which any license under such rights 1353 might or might not be available; nor does it represent that it has 1354 made any independent effort to identify any such rights. Information 1355 on the procedures with respect to rights in RFC documents can be 1356 found in BCP 78 and BCP 79. 1358 Copies of IPR disclosures made to the IETF Secretariat and any 1359 assurances of licenses to be made available, or the result of an 1360 attempt made to obtain a general license or permission for the use of 1361 such proprietary rights by implementers or users of this 1362 specification can be obtained from the IETF on-line IPR repository at 1363 http://www.ietf.org/ipr. 1365 The IETF invites any interested party to bring to its attention any 1366 copyrights, patents or patent applications, or other proprietary 1367 rights that may cover technology that may be required to implement 1368 this standard. Please address the information to the IETF at 1369 ietf-ipr@ietf.org. 1371 Disclaimer of Validity 1373 This document and the information contained herein are provided on an 1374 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1375 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1376 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1377 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1378 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1381 Copyright Statement 1383 Copyright (C) The Internet Society (2005). This document is subject 1384 to the rights, licenses and restrictions contained in BCP 78, and 1385 except as set forth therein, the authors retain all their rights. 1387 Acknowledgment 1389 Funding for the RFC Editor function is currently provided by the 1390 Internet Society.