Network Working Group G. Van de Velde Internet-Draft T. Hain Expires: April 25, 2006 R. Droms Cisco Systems B. Carpenter IBM Corporation E. Klein Tel Aviv University October 22, 2005 IPv6 Network Architecture Protection Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many Van de Velde, et al. Expires April 25, 2006 [Page 1] Internet-Draft IPv6 Network Architecture Protection October 2005 serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Perceived Benefits of NAT and its Impact on IPv4 . . . . . . . 6 2.1. Simple Gateway between Internet and Private Network . . . 6 2.2. Simple Security due to Stateful Filter Implementation . . 6 2.3. User/Application tracking . . . . . . . . . . . . . . . . 7 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 8 2.5. Independent Control of Addressing in a Private Network . . 9 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 9 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 10 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 10 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 10 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 11 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 12 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 12 4. Using IPv6 Technology to Provide the Market Perceived Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Simple Gateway between Internet and Internal Network . . . 13 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 13 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 15 4.4. Privacy and Topology Hiding using IPv6 . . . . . . . . . . 15 4.5. Independent Control of Addressing in a Private Network . . 16 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 17 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 17 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Medium/large private networks . . . . . . . . . . . . . . 18 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 20 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 21 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 22 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Subnet Topology Masking . . . . . . . . . . . . . . . . . 23 6.2. Minimal Traceability of Privacy Addresses . . . . . . . . 23 6.3. Renumbering Procedure . . . . . . . . . . . . . . . . . . 23 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 24 6.5. Untraceable Addresses . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 Van de Velde, et al. Expires April 25, 2006 [Page 2] Internet-Draft IPv6 Network Architecture Protection October 2005 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 Appendix A. Additional Benefits due to Native IPv6 and Universal Unique Addressing . . . . . . . . . . . . . 27 A.1. Universal Any-to-Any Aonnectivity . . . . . . . . . . . . 27 A.2. Auto-configuration . . . . . . . . . . . . . . . . . . . . 27 A.3. Native Multicast Services . . . . . . . . . . . . . . . . 28 A.4. Increased Security Protection . . . . . . . . . . . . . . 28 A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 29 A.7. Community of interest . . . . . . . . . . . . . . . . . . 29 Appendix B. Revision history . . . . . . . . . . . . . . . . . . 30 B.1. Changes from *-vandevelde-v6ops-nap-00 to *-vandevelde-v6ops-nap-01 . . . . . . . . . . . . . . . . 30 B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00 . . . . . . . . . . . . . . . . . . . 30 B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 . 30 B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 36 Van de Velde, et al. Expires April 25, 2006 [Page 3] Internet-Draft IPv6 Network Architecture Protection October 2005 1. Introduction Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. The serious disadvantages of ambiguous "private" address space and of Network Address Translation (NAT) [1][5] have been well documented [4][6]. However, given its wide market acceptance NAT undoubtedly has some perceived benefits. Indeed, in an Internet model based on universal any-to-any connectivity, product marketing departments have driven a perception hat some connectivity and security concerns can only be solved by using a NAT device or by using logically separated Local Area Network (LAN) address spaces. This document describes the reasons for utilizing a NAT device in an IPv4 environment that are regularly cited in marketing pronouncements. It then shows how these needs can be met without using NAT in an IPv6 network. Some of the IPv6 solutions offer advantages beyond the equivalent IPv4 NAT solution. The use of the facilities from IPv6 described in this document avoids the negative impacts of address translation. As far as security and privacy is concerned, this document considers how to mitigate a number of threats. Some are obviously external, such as having a hacker trying to penetrate your network, or having a worm infected machine outside your network trying to attack it. Some are local such as a disgruntled employee disrupting business operations, or the unintentional negligence of a user downloading some malware which then proceeds to attack any device on the LAN. Some may be inherent in the device hardware ("embedded") such as having some firmware in a domestic appliance "call home" to its manufacturer without the user's consent. This document describes several techniques that may be combined on an IPv6 site to protect the integrity of its network architecture. These techniques, known collectively as Network Architecture Protection (NAP), retain the concept of a well defined boundary between "inside" and "outside" the private network, and allow firewalling, topology hiding, and privacy. NAP will achieve these security goals without address translation whilst maintaining any-to- any connectivity. IPv6 Network Architecture Protection can be summarized in the following table. It presents the marketed "benefits" of NAT with a cross-reference of how those are delivered in both the IPv4 and IPv6 environments. Van de Velde, et al. Expires April 25, 2006 [Page 4] Internet-Draft IPv6 Network Architecture Protection October 2005 benefit IPv4 IPv6 +------------------+-----------------------+-----------------------+ | Simple Gateway | DHCP - single | DHCP-PD - arbitrary | | as default router| address upstream | length customer | | and address pool | DHCP - limited | prefix upstream | | manager | number of individual | SLAAC via RA | | | devices downstream | downstream | | | see section 2.1 | see section 4.1 | +------------------|-----------------------|-----------------------+ | Simple Security | Filtering side | Explicit Context | | | effect due to lack | Based Access Control | | | of translation state | (Reflexive ACL) | | | see section 2.2 | see section 4.2 | +------------------|-----------------------|-----------------------+ | Local usage | NAT state table | Address uniqueness | | tracking | | | | | see section 2.3 | see section 4.3 | +------------------|-----------------------|-----------------------+ | End-system | NAT transforms | Temporary use | | privacy | device ID bits in | privacy addresses | | | the address | | | | see section 2.4 | see section 4.4 | +------------------|-----------------------|-----------------------+ | Topology hiding | NAT transforms | Untraceable addresses| | | subnet bits in the | using IGP host routes| | | address | /or MIPv6 tunnels for| | | | stationary systems | | | see section 2.4 | see section 4.4 | +------------------|-----------------------|-----------------------+ | Addressing | RFC 1918 | RFC 3177 & ULA | | Autonomy | | | | | see section 2.5 | see section 4.5 | +------------------|-----------------------|-----------------------+ | Global Address | RFC 1918 | 340,282,366,920,938, | | Pool | | 463,463,374,607,431, | | Conservation | | 768,211,456 | | | | (3.4*10^38) addresses| | | see section 2.6 | see section 4.6 | +------------------|-----------------------|-----------------------+ | Renumbering and | Address translation | Preferred lifetime | | Multi-homing | at border | per prefix & Multiple| | | | addresses per | | | | interface | | | see section 2.7 | see section 4.7 | +------------------+-----------------------+-----------------------+ This document first identifies the perceived benefits of NAT in more detail, and then shows how IPv6 NAP can provide each of them. It Van de Velde, et al. Expires April 25, 2006 [Page 5] Internet-Draft IPv6 Network Architecture Protection October 2005 concludes with a IPv6 NAP case study and a gap analysis of work that remains to be done for a complete NAP solution. 2. Perceived Benefits of NAT and its Impact on IPv4 This section provides insight into the generally perceived benefits of the use of IPv4 NAT as extolled by product marketing. The goal of this description is not to analyze these benefits or discuss the accuracy of the perception (detailed discussions in [4]), but to describe the deployment requirements and set a context for the later descriptions of the IPv6 approaches for dealing with those requirements. 2.1. Simple Gateway between Internet and Private Network A NAT device can connect a private network with any kind of address (ambiguous [RFC 1918] or global registered address) towards the Internet. The address space of the private network can be built from globally unique addresses, from ambiguous address space or from both simultaneously. Without needing specific configuration, the NAT device enables access between the client side of a distributed client-server application in the private network and the server side in the public Internet. Wide-scale deployments have shown that using NAT to attach a private IPv4 network to the Internet is simple and practical for the non- technical end user. Frequently a simple user interface, or even a default configuration is sufficient for configuring both device and application access rights. Additionally, thanks to successful marketing campaigns it is perceived by end users that their equipment is protected from the malicious entities and attackers on the public IPv4 Internet. 2.2. Simple Security due to Stateful Filter Implementation A firewall doesn't fully secure a network, because many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows etc. What a firewall does is prevent a network administration from having to pay for bandwidth to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary. A distributed security mechanism to protect the end-systems may help Van de Velde, et al. Expires April 25, 2006 [Page 6] Internet-Draft IPv6 Network Architecture Protection October 2005 in the above situation; however, to deploy such a system is quite complex and may depend upon behaviour per operating system and release version. Also it will only be reliable if a mechanism such as 'trusted computing' is implemented in the end-system; without this enhancement administrators will be unwilling to trust the behavior of end-systems. As a result it will probably not be available in the next couple of years for end-user organizations. End-system-only security mechanisms do not protect the network infrastructure from being misused for transit, or against Distributed Denial of Service (DDOS) attacks against individual systems inside: and this is the area where a NAT device is perceived to provide some protection. It is frequently believed that through its session-oriented operation, NAT puts in an extra barrier to keep the private network protected from outside influences. Since a NAT device typically keeps state only for individual sessions, attackers, worms, etc. cannot exploit this state to attack a host in general and on any port. This benefit may be partially real, however, experienced hackers are well aware of NAT devices and are very familiar with private address space, and have devised methods of attack (such as trojan horses) that readily penetrate NAT boundaries. For these reasons the sense of security provided by NAT is actually an illusion. Address translation does not provide security in itself; for example, consider a configuration with static NAT translation and all inbound ports translating to a single machine. In such a scenario the security risk for that machine is identical to the case with no NAT device in the communication path. As result there is no specific security value in the address translation function. The perceived security comes from the lack of pre-established or permanent mapping state. Dynamically establishing state in response to internal requests reduces the threat of unexpected external connections to internal devices. In some cases, NAT operators (including domestic users) may be obliged to configure quite complex port mapping rules to allow external access to local applications such as a multi-player game or web servers. In this case the NAT actually adds management complexity compared to a simple router. In situations where two or more devices need to host the same application this complexity shifts from difficult to impossible. 2.3. User/Application tracking Although NATs create temporary state for active sessions, in general they provide limited capabilities for the administrator of the NAT to gather information about who in the private network is requesting Van de Velde, et al. Expires April 25, 2006 [Page 7] Internet-Draft IPv6 Network Architecture Protection October 2005 access to which Internet location. This could in theory be done by logging the network address translation details of the private and the public addresses from the NAT device's state database. The checking of this database is not always a simple task, especially if Port Address Translation is used. It also has an unstated assumption that the administrative instance has a mapping between an IPv4-address and a network element or user at all times, or the administrator has a time-correlated list of the address/port mappings. 2.4. Privacy and Topology Hiding The goal of 'topology hiding' is to provide devices on the private network with an identifier (IPv4 address) which an entity outside the network can use to communicate with or to reference the private network devices in protocols but prevents the external entity making a correlation between the topological location of the private device and the address on the local network. The ability of NAT to provide Internet access to a large community of users by the use of a single (or a few) global IPv4 routable addresses offers a simple mechanism to hide the internal topology of a network. In this scenario the large community will be represented in the Internet by a single (or a few) IPv4 address(es). The use of NAT then results in a user behind a NAT gateway actually appearing on the Internet as a user inside the NAT box itself; i.e., the IPv4 address that appears on the Internet is only sufficient to identify the NAT. When concealed behind a NAT it is impossible to tell from the outside which member of a family, which customer of an Internet cafe, or which employee of a company generated or received a particular packet. Thus, although NATs do nothing to provide application level privacy, they do prevent the external tracking and profiling of individual host computers by means of their IP addresses, usually known as 'device profiling'. At the same time a NAT creates a smaller pool of addresses for a much more focused point of attack. There is a similarity with privacy based on application level proxies. When using an application level gateway for browsing the web for example, the 'privacy' of a web user can be provided by masking the true identity of the original web user towards the outside world (although the details of what is - or is not - logged at the NAT/proxy will be different). Some enterprises prefer to hide as much as possible of their internal network topology from outsiders. Mostly this is achieved by blocking Van de Velde, et al. Expires April 25, 2006 [Page 8] Internet-Draft IPv6 Network Architecture Protection October 2005 "traceroute" etc., but NAT of course entirely hides the internal subnet topology, which some network managers believe is a useful precaution to mitigate scanning attacks. Scanning for IPv6 can be much harder in comparison with IPv4 as described in [18]. Once a list of available devices and IP addresses has been mapped, a port-scan on these IP addresses can be performed. Scanning works by tracking which ports do not receive unreachable errors from either the firewall or host. With the list of open ports an attacker can optimize the time needed for a successful attack by correlating it with known vulnerabilities to reduce the number of attempts. For example, FTP usually runs on port 21, and HTTP usually runs on port 80. Any vulnerable open ports could be used for initiating attacks on an end system. 2.5. Independent Control of Addressing in a Private Network Many private IPv4 networks take benefit from using the address space defined in RFC 1918 to enlarge the available addressing space for their private network, and at the same time reduce their need for globally routable addresses. This type of local control of address resources allows a clean and hierarchical addressing structure in the network. Another benefit is due to the usage of independent addresses on majority of the network infrastructure there is an increased ability to change provider with less operational difficulties. Section 2.7 describes some disadvantages that appear if independent networks using [RFC1918] addresses have to be merged. 2.6. Global Address Pool Conservation Due to the ongoing depletion of the IPv4 address range, the remaining pool of unallocated IPv4 addresses is below 30%. While mathematical models based on historical IPv4 prefix consumption periodically attempt to predict the future exhaustion date of the IPv4 address pool, a direct result of this continuous resource consumption is that the administrative overhead for acquiring globally unique IPv4 addresses will continue increasing in direct response to tightening allocation policies. In response to the increasing administrative overhead many Internet Service Providers (ISPs) have already resorted to the ambiguous addresses defined in RFC 1918 behind a NAT for the various services they provide as well as connections for their end customers. This happens even though that private address-space is strictly limited in size. In turn this has restricted the number of and types of applications that can be deployed by these ISPs and their customers. Forced into this limiting situation such customers Van de Velde, et al. Expires April 25, 2006 [Page 9] Internet-Draft IPv6 Network Architecture Protection October 2005 can rightly claim that despite the optimistic predictions of mathematical models the global pool of IPv4 addresses is effectively already exhausted, especially for larger enterprises. 2.7. Multihoming and Renumbering with NAT Allowing a network to be multihomed and renumbering a network are quite different functions. However, making a network multihomed is often a transitional state required as part of network renumbering, and NAT interacts with both in the same way. For enterprise networks, it is highly desirable to provide resiliency and load-balancing to be connected to more than one Internet Service Provider (ISP) and to be able to change ISPs at will. This means that a site must be able to operate under more than one CIDR prefix [14] and/or readily change its CIDR prefix. Unfortunately, IPv4 was not designed to facilitate either of these maneuvers. However, if a site is connected to its ISPs via NAT boxes, only those boxes need to deal with multihoming and renumbering issues. Similarly, if two enterprise IPv4 networks need to be merged and RFC1918 addresses are used, there is a high probability of address overlaps. In those situations it may well be that installing a NAT box between them will avoid the need to renumber one or both. For any enterprise, this can be a short term financial saving, and allow more time to renumber the network components. The long term solution is a single network without usage of NAT to avoid the ongoing operational complexity of overlapping addresses. The addition of an extra NAT as a solution may be sufficient for some networks; however when the merging networks were already using address translation it will create huge problems due to administrative difficulties of overlapping address speaces in the merged networks. 3. Description of the IPv6 Tools This section describes several features that can be used as part of the NAP solution to emulate the protection features associated with IPv4 NAT. 3.1. Privacy Addresses (RFC 3041) There are situations where it is desirable to prevent device profiling, for example by web sites that are accessed from the device; IPv6 privacy addresses were defined to provide that capability. IPv6 addresses consist of a routing prefix, subnet-id Van de Velde, et al. Expires April 25, 2006 [Page 10] Internet-Draft IPv6 Network Architecture Protection October 2005 part (SID) and an interface identifier part (IID). For interfaces that contain embedded IEEE Link Identifiers the interface identifier is typically derived from it, though this practice facilitates tracking and profiling of a device as it moves around the Internet. RFC 3041 describes an extension to IPv6 stateless address autoconfiguration (SLAAC) for interfaces [7]. Use of the privacy address extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE link identifier. Changing the interface identifier (thus the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when addresses used in different transactions actually correspond to the same node. A relatively short valid lifetime for the privacy address also has the side effect of reducing the attack profile of a device, as it is not directly attackable once it stops answering at the temporary use address. While the primary implementation and source of randomized RFC 3041 addresses is expected to be from end-systems running stateless autoconfiguration, there is nothing that prevents a DHCP server from running the RFC 3041 algorithm for any new IEEE identifier it hears, then remembering that for future queries. This would allow using them in DNS for registered services since the assumption of a server based deployment would be a persistent value that minimizes DNS churn. A DHCP based deployment would also allow for local policy to periodically change the entire collection of end device addresses while maintaining some degree of central knowledge and control over which addresses should be in use at any point in time. Randomizing the IID, as defined in RFC 3041, only precludes tracking of the lower 64 bits of the IPv6 address. Masking of the subnet ID will require additional approaches as discussed below in 3.4. Additional considerations are discussed in [17]. 3.2. Unique Local Addresses Local network and application services stability during periods of intermittent connectivity between one or more providers requires address management autonomy. Such autonomy in a single routing prefix environment would lead to massive expansion of the global routing tables, so IPv6 provides for simultaneous use of multiple prefixes. The Unique Local Address prefix (ULA) [13] has been set aside for use in local communications. The ULA address prefix for any network is routable over a locally defined collection of routers. These prefixes are not intended to be routed on the public global Internet; large scale inter-domain distribution of routes to ULA prefixes would have a negative impact on global route aggregation. Van de Velde, et al. Expires April 25, 2006 [Page 11] Internet-Draft IPv6 Network Architecture Protection October 2005 ULAs have the following characteristics: o Globally unique prefix * Allows networks to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces using these prefixes * If accidentally leaked outside of a network via routing or DNS, it is highly unlikely that there will be a conflict with any other addresses o ISP independent and can be used for communications inside of a network without having any permanent or intermittent Internet connectivity o Well-known prefix to allow for easy filtering at network boundaries preventing leakage of local routes and packets. o In practice, applications may treat these addresses like global scoped addresses but address selection algorithms need to distinguish between ULAs and ordinary global scope unicast addresses. Mixing the two kinds of addresses is likely to lead to undeliverable packets. 3.3. DHCPv6 Prefix Delegation The Prefix Delegation (DHCP-PD) options [11] provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host Configuration Protocol (DHCP) [9]. This mechanism (DHCP-PD) is intended for delegating a long-lived prefix from a delegating router (incorporating a DHCPv6 server) to a requesting router, possibly across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. 3.4. Untraceable IPv6 Addresses These should be globally routable IPv6 addresses which can be randomly and independently assigned to IPv6 devices. The random assignment is intended to mislead the outside world about the structure of the local network. However the local network needs to maintain a correlation between the location of the device and the untraceable IPv6 address. This correlation could be done by generating IPv6 host route entries or by utilizing an indirection device such as a Mobile IPv6 Home Agent. The main goal of untraceable IPv6 addresses is to create an apparently amorphous network infrastructure as seen from external networks to protect the local infrastructure from malicious outside influences and from mapping of any correlation between the network activities of multiple devices from external networks. When using untraceable IPv6 addresses, it could be that two apparently Van de Velde, et al. Expires April 25, 2006 [Page 12] Internet-Draft IPv6 Network Architecture Protection October 2005 sequential addresses are allocated to devices on very different parts of the local network instead of belonging to devices adjacent to each other on the same subnet. 4. Using IPv6 Technology to Provide the Market Perceived Benefits of NAT The facilities in IPv6 described in Section 3 can be used to provide the protection perceived to be associated with IPv4 NAT. This section gives some examples of how IPv6 can be used securely. 4.1. Simple Gateway between Internet and Internal Network As a simple gateway, the device manages both packet routing and local address management. A basic IPv6 router could have a default configuration to advertise inside the site a locally generated random ULA prefix, independently from the state of any external connectivity. This would allow local nodes to communicate amongst themselves prior to establishing a global connection. If the network happened to concatenate with another local network, this is highly unlikely to result in address collisions. A more secure network environment can be established by having the referenced ULA addresses statically configured on the network devices as this decreases the dynamic aspects of the network, however the operational overhead is increased. With external connectivity the simple gateway could also use DHCP-PD to acquire a routing prefix from the service provider for use when connecting to the global Internet. End-system connections involving other nodes on the global Internet will always use the global IPv6 addresses [9] derived from this prefix delegation. It should be noted that the address selection policy table in end-systems needs to be correctly set up so that true global prefixes are distinguished from ULAs and will be used for the source address in preference when the destination is not a ULA. In the very simple case there is no explicit routing protocol and a single default route is used out to the global Internet. A slightly more complex case might involve local routing protocols, but with the entire local network sharing a common global prefix there would still not be a need for an external routing protocol as a default route would continue to be consistent with the connectivity. 4.2. IPv6 and Simple Security The vulnerability of an IPv6 host is similar to that of an IPv4 host directly connected towards the Internet. The use of firewall and Van de Velde, et al. Expires April 25, 2006 [Page 13] Internet-Draft IPv6 Network Architecture Protection October 2005 Intrusion Detection Systems (IDS) is recommended. A proxy may be used for certain applications, but with the caveat that the end to end transparancy is broken. However, with IPv6, the following protections are available without the use of NAT while maintaining end-to-end reachability: 1. Short lifetimes on privacy extension suffixes reduce the attack profile since the node will not respond to the address once the address is no longer valid. 2. IPsec is a mandatory service for IPv6 implementations. IPsec functions to prevent session hijacking, prevent content tampering, and optionally masks the packet contents. While IPsec might be available in IPv4 implementations, deployment in NAT environments either breaks the protocol or requires complex helper services with limited functionality or efficiency. 3. The size of the address space of a typical subnet (64 bits of IID) will make an effective network ping sweep and resulting port-scan virtually impossible due to the number of possible combinations available, provided that IIDs are essentially randomly distributed across the available space. This protection is nullified if the attacker has no access to a local connection. If an attacker has local access then he could use ND [3] and ping6 to ff02::1 to detect local neighbors. (Of course, a locally connected attacker has many scanning options with IPv4 as well.) It is recommended for site administrators to take [18] into consideration to achieve the expected goal. This protection will also be nullified if IIDs are configured in a group near the start of the IID space. IPv4 NAT was not developed as a security mechanism. Despite marketing messages to the contrary it is not a security mechanism, and hence it will offer some security holes while many people assume their network is secure due to the usage of NAT. IPv6 security best practices will avoid this kind of illusory security but can only do this if correctly configured firewalls and IDS systems are used at the perimeter where some IPv4 networks have relied on NATs. To implement simple security for IPv6 in, for example, a DSL connected home network, the DSL broadband gateway/router should be equipped with stateful firewall capabilities. These should provide a default configuration which provides a minimum set of connectivity for users in the home network (e.g., just to external HTTP servers) with incoming traffic limited to return traffic resulting from outgoing packets (sometimes known as reflective session state) with an easy interface which allows users to create additional 'pinholes' for specific purposes. Administrators and the designers of configuration interfaces for simple IPv6 Firewalls need to provide a means of documenting the Van de Velde, et al. Expires April 25, 2006 [Page 14] Internet-Draft IPv6 Network Architecture Protection October 2005 security caveats that arise from a given set configuration rules so that users (who are normally oblivious to such things) can be made aware of the risks. As rules are improved iteratively, the goal will be to make use of the IPv6 Internet more secure for oblivious users. Assuming the network administrator is aware of [18] the increased size of the IPv6 address will make topology probing much harder, and almost impossible for IPv6 devices. The intention of topology probing is to identify a selection of the available hosts inside an enterprise. This mostly starts with a ping-sweep. Since the IPv6 subnets are 64 bits worth of address space, this means that an attacker has to send out a simply unrealistic number of pings to map the network, and virus/worm propagation will be thwarted in the process. At full rate 40Gbps (400 times the typical 100Mbps LAN, and 13,000 times the typical DSL/Cable access link) it takes over 5000 years to scan a single 64 bit space. 4.3. User/Application Tracking IPv6 enables the collection of information about data flows. Due to the fact that all addresses used for Internet and intra-/inter-site communication are unique, it is possible for an enterprise or ISP to get very detailed information on any communication exchange between two or more devices. This enhances the capability of data-flow tracking for security audits compared with IPv4 NAT, because in IPv6 a flow between a sender and receiver will always be uniquely identified due to the unique IPv6 source and destination addresses. 4.4. Privacy and Topology Hiding using IPv6 Partial host privacy is achieved in IPv6 using pseudo-random privacy addresses [RFC 3041] which are generated as required, so that a session can use an address that is valid only for a limited time. Exactly as with IPv4 NAT, this only allows such a session to be traced back to the subnet that originates it, but not immediately to the actual host. Due to the large IPv6 address space available there is plenty of freedom to randomize subnet allocations. By doing this, it is possible to reduce the correlation between a subnet and its location. When doing both subnet and IID randomization [RFC 3041] a casual snooper won't be able to deduce much about the networks topology. The obtaining of a single address will tell the snooper very little about other addresses. This is different from IPv4 where address space limitations cause this to be not true. In most usage cases this concept should be sufficient for address privacy and topology hiding. Van de Velde, et al. Expires April 25, 2006 [Page 15] Internet-Draft IPv6 Network Architecture Protection October 2005 In the case where a network administrator wishes to fully conceal the internal IPv6 topology, and the majority of its host computer addresses, a possible option is to run all internal traffic using Unique Local Addresses (ULA) since such packets can by definition never exit the site. For hosts that do in fact need to generate external traffic, by using multiple IPv6 addresses (ULAs and one or more global addresses), it will be possible to hide and mask some or all of the internal network. As discussed in Section 3.1, there are multiple parts to the IPv6 address, and different techniques to manage privacy for each. There are two possible scenarios for the extreme situation when a network manager also wishes to fully conceal the internal IPv6 topology. o One could use explicit host routes and remove the correlation between location and IPv6 address. This solution does however show severe scalability issues. o The other technology to fully hide the internal topology would be to use a tunneling mechanism. Mobile IPv6 without route optimization is one example. In this example the public facing addresses are indirected via an edge Home Agent (HA). This indirection method truly masks the internal topology as all nodes with global access appear to share a common prefix. The downside of using this method is that it makes usage of middleware like a Home Agent (HA). 4.5. Independent Control of Addressing in a Private Network IPv6 provides for autonomy in local use addresses through ULAs. At the same time IPv6 simplifies simultaneous use of multiple addresses per interface so that an IPv6 NAT is not required between the ULA and the public Internet. Nodes that need access to the public Internet may have a ULA for local use, and will have a global use address because the global use IPv6 address space is not a scarce resource like the global use IPv4 space. While global IPv6 allocation policy is managed through the Regional Internet Registries, it is expected that they will continue with derivatives of [RFC 3177] for the foreseeable future. When using IPv6, the need to ask for more address space will become far less likely due to the increased size of the subnets. These subnets typically allow 2^64 addresses per subnet and an enterprise will typically receive a /48 which allows segmentation into at least 2^16 different subnets. The ongoing subnet size maintenance may become simpler when IPv6 Van de Velde, et al. Expires April 25, 2006 [Page 16] Internet-Draft IPv6 Network Architecture Protection October 2005 technology is utilised. If IPv4 address space is optimised one has to look periodically into the number of hosts on a segment and the subnet size allocated to the segment; an enterprise today may have a mix of /28 - /23 size subnets for example, and may shrink/grow these as their network user base changes. For IPv6 all subnets have /64 prefixes. 4.6. Global Address Pool Conservation IPv6 provides sufficient space to completely avoid the need for overlapping address space, 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total possible addresses. As previously discussed, the serious disadvantages of ambiguous address space have been well documented, and with sufficient space there is no need to continue the increasingly aggressive conservation practices that are necessary with IPv4. While IPv6 allocation policies and ISP business practice will continue to evolve, the recommendations in RFC 3177 are based on the technical potential of the vast IPv6 address space. That document demonstrates that there is no resource limitation which will require the adoption of the IPv4 workaround of ambiguous space behind a NAT. As an example of the direct contrast, many expansion oriented IPv6 deployment scenarios result in multiple IPv6 addresses per device, as opposed to the constriction of IPv4 scenarios where multiple devices are forced to share a scarce global address. 4.7. Multihoming and Renumbering Multihoming and renumbering remain technically challenging with IPv6 (see the Gap Analysis below). However, IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR-like prefixes and thus with several simultaneous ISPs. An address selection mechanism [10] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in this regard therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and the processes for adding and removing active prefixes at a site have been documented [12] and [19]. The IPv6 address space allocated by the ISP will be dependent upon the connecting Service provider. This may result in a renumbering effort if the network changes from Service Provider. When changing ISPs or ISPs readjusting their addressing pool, DHCP-PD [11] can be used as an almost zero-touch external mechanism for prefix change in conjunction with a ULA prefix for internal connection stability. With appropriate management of the lifetime values and overlap of the external prefixes, a smooth make-before-break transition is possible as existing communications will continue on the old prefix as long as Van de Velde, et al. Expires April 25, 2006 [Page 17] Internet-Draft IPv6 Network Architecture Protection October 2005 it remains valid, while any new communications will use the new prefix. 5. Case Studies In presenting these case studies we have chosen to consider categories of network divided first according to their function either as carrier/ISP networks or end user (such as enterprise) networks with the latter category broken down according to the number of connected end hosts. For each of these category of networks we can use IPv6 Network Architecture Protection to achieve a secure and flexible infrastructure, which provides an enhanced network functionality in comparison with the usage of address translation. o Medium/Large Private Networks (typically >10 connections) o Small Private Networks (typically 1 to 10 connections) o Single User Connection (typically 1 connection) o ISP/Carrier Customer Networks 5.1. Medium/large private networks The majority of private enterprise networks fall into this category. Many of these networks have one or more exit points to the Internet. Though these organizations have sufficient resources to acquire addressing independence when using IPv4 there are several reasons why they might choose to use NAT in such a network. For the ISP there is no need to import the IPv4 address range from the remote end- customer, which facilitates IPv4 route summarization. The customer can use a larger IPv4 address range (probably with less- administrative overhead) by the use of RFC 1918 and NAT. The customer also reduces the overhead in changing to a new ISP, because the addresses assigned to devices behind the NAT do not need to be changed when the customer is assigned a different address by a new ISP. By using address translation one avoids the need for network renumbering. Finally, the customer can provide privacy for its hosts and the topology of its internal network if the internal addresses are mapped through NAT. It is expected that there will be enough IPv6 addresses available for all networks and appliances for the foreseeable future. The basic IPv6 address range an ISP allocates for a private network is large enough (currently /48) for most of the medium and large enterprises, while for the very large private enterprise networks address-ranges can be concatenated. A single /48 allocation provides an enterprise network with 65536 different /64 prefixes. Van de Velde, et al. Expires April 25, 2006 [Page 18] Internet-Draft IPv6 Network Architecture Protection October 2005 The summarization benefit for the ISP results from the IPv6 allocation rules. This means that the ISP will provide the enterprise with an IPv6 address-range (typically one or multiple range(s) of '/48') from its RIR assigned IPv6 address-space. The goal of this assignment mechanism is to decrease the total amount of entries in the internet routing table. If the ISP adopts appropriate policies there is high probability that an enterprise requiring additional space could acquire an adjacent address block. To mask the identity of a user on a network of this type, the usage of IPv6 privacy extensions may be advised. This technique is useful when an external element wants to track and collect all information sent and received by a certain host with known IPv6 address. Privacy extensions add a random factor to the host part of an IPv6 address and will make it very hard for an external element to keep correlating the IPv6 address to a host on the inside network. The usage of IPv6 privacy extensions does not mask the internal network structure of an enterprise network. If there is need to mask the internal structure towards the external IPv6 internet, then some form of 'untraceable' addresses may be used. These addresses will be derived from a local pool, and may be assigned to those hosts for which topology masking is required or which want to reach the IPv6 Internet or other external networks. The technology to assign these addresses to the hosts could be based on DHCPv6. To complement the 'Untraceable' addresses it is needed to have at least awareness of the IPv6 address location when routing an IPv6 packet through the internal network. This could be achieved by 'route-injection' in the network infrastructure. This route- injection could be done based on /128 host-routes to each device that wants to connect to the Internet using an untraceable address. This will provide the most dynamic masking, but will have a scalability limitation, as an IGP is typically not designed to carry many thousands of IPv6 prefixes. A large enterprise may have thousands of hosts willing to connect to the Internet. Less flexible masking could be to have time-based IPv6 prefixes per link or subnet. This may reduce the amount of route entries in the IGP by a significant factor, but has as trade-off that masking is time and subnet based. The dynamic allocation of 'Untraceable' addresses can also limit the IPv6 access between local and external hosts to those local hosts being authorized for this capability. Dynamically allocated 'Untraceable' addresses may also facilitate and simplify the connectivity to the outside networks during renumbering, because the existing IPv6 central address pool could be swapped for the newly allocated IPv6 address pool. The use of permanent ULA addresses on a site provides the benefit Van de Velde, et al. Expires April 25, 2006 [Page 19] Internet-Draft IPv6 Network Architecture Protection October 2005 that even if an enterprise would change its ISP, the renumbering will only affect those devices that have a wish to connect beyond the site. Internal servers and services would not change their allocated IPv6 ULA address, and the service would remain available even during global address renumbering. 5.2. Small Private Networks Also known as SOHO (Small Office/Home Office) networks, this category describes those networks which have few routers in the topology, and usually have a single network egress point. Typically these networks are: o connected via either a dial-up connection or broadband access o don't have dedicated Network Operation Center (NOC) o and through economic pressure are typically forced today to use NAT In most cases the received global IPv4 prefix is not fixed over time and is too long (very often just a /32 just giving a single address) to provide every node in the private network with a unique globally usable address. Fixing either of those issues typically adds an administrative overhead for address management to the user. This category may even be limited to receiving ambiguous IPv4 addresses from the service provider based on RFC 1918. An ISP will typically pass along the higher administration cost attached to larger address blocks, or IPv4 prefixes that are static over time, due to the larger public address pool each of those requires. As a direct response to explicit charges per public address most of this category has deployed NAPT (port demultiplexing NAT) to minimize the number of addresses in use. Unfortunately this also limits the Internet capability of the equipment to being mainly a receiver of Internet data (client), and makes it quite hard for the equipment to become a world wide Internet server (i.e. HTTP, FTP, etc.) due to the stateful operation of the NAT equipment. Even when there is sufficient technical knowledge to manage the NAT to enable a server, only one server of any given protocol type is possible per address, and then only when the address from the ISP is public. When deploying IPv6 NAP in this environment, there are two approaches possible with respect to IPv6 addressing. o DHCPv6 Prefix-Delegation o ISP provides a static IPv6 address-range For the DHCPv6-PD solution, a dynamic address allocation approach is chosen. By means of the enhanced DHCPv6 protocol it is possible to have the ISP push down an IPv6 prefix range automatically towards the Van de Velde, et al. Expires April 25, 2006 [Page 20] Internet-Draft IPv6 Network Architecture Protection October 2005 small private network and populate all interfaces in that small private network dynamically. This reduces the burden for administrative overhead because everything happens automatically. For the static configuration the mechanisms used could be the same as for the medium/large enterprises. Typically the need for masking the topology will not be of high priority for these users, and the usage of IPv6 privacy extensions could be sufficient. For both alternatives the ISP has the unrestricted capability for summarization of its RIR allocated IPv6 prefix, while the small private network administrator has all flexibility in using the received IPv6 prefix to its advantage because it will be of sufficient size to allow all the local nodes to have a public address and full range of ports available whenever necessary. While a full prefix is expected to be the primary deployment model there may be cases where the ISP provides a single IPv6 address for use on a single piece of equipment (PC, PDA, etc.). This is expected to be rare though, because in the IPv6 world the assumption is that there is an unrestricted availability of a large amount of globally routable and unique address space. If scarcity was the motivation with IPv4 to provide RFC 1918 addresses, in this environment the ISP will not be motivated to allocate private addresses towards the single user connection because there are enough global addresses available at essentially the same cost. Also if the single device wants to mask its identity to the called party or its attack profile over a short time window it will need to enable IPv6 privacy extensions, which in turn leads to the need for a minimum allocation of a /64 prefix rather than a single address. 5.3. Single User Connection This group identifies the users which are connected via a single IPv4 address and use a single piece of equipment (PC, PDA, etc.). This user may get an ambiguous IPv4 address (frequently imposed by the ISP) from the service provider which is based on RFC 1918. If ambiguous addressing is utilized, the service provider will execute NAT on the allocated IPv4 address for global Internet connectivity. This also limits the internet capability of the equipment to being mainly a receiver of Internet data, and makes it quite hard for the equipment to become a world wide internet server (i.e. HTTP, FTP, etc.) due to the stateful operation of the NAT equipment. When using IPv6 NAP, this group will identify the users which are connected via a single IPv6 address and use a single piece of equipment (PC, PDA, etc.). Van de Velde, et al. Expires April 25, 2006 [Page 21] Internet-Draft IPv6 Network Architecture Protection October 2005 In IPv6 world the assumption is that there is unrestricted availability of a large amount of globally routable and unique IPv6 addresses. The ISP will not be motivated to allocate private addresses towards the single user connection because he has enough global addresses available, if scarcity was the motivation with IPv4 to provide RFC 1918 addresses. If the single user wants to mask his identity, he may choose to enable IPv6 privacy extensions. 5.4. ISP/Carrier Customer Networks This group refers to the actual service providers that are providing the IPv4 access and transport services. They tend to have three separate IPv4 domains that they support: o For the first they fall into the Medium/large private networks category (above) for their own internal networks, LANs etc. o The second is the Operations network which addresses their backbone and access switches, and other hardware, this is separate for both engineering reasons as well as simplicity in managing the security of the backbone. o The third is the IP addresses (single or blocks) that they assign to customers. These can be registered addresses (usually given to category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of RFC 1918 addresses used with NAT for single user connections. Therefore they can actually have two different NAT domains that are not connected (internal LAN and single user customers). When IPv6 NAP is utilized in these three domains then for the first category it will be possible to use the same solutions as described in Section 5.1. The second domain of the ISP/carrier is the Operations network. This environment tends to be a closed environment, and consequently communication can be done based on ULA addresses, however, in this environment, stable IPv6 Provider Independent addresses can be used in preference to ULA addresses. This would give a solid and scalable configuration with respect to a local IPv6 address plan. By the usage of proper network edge filters, outside access to the closed environment can be avoided. The third is the IPv6 addresses that ISP/carrier network assign to customers. These will typically be assigned with prefix lengths terminating on nibble boundaries to be consistent with the DNS PTR records. As scarcity of IPv6 addresses is not a concern, it will be possible for the ISP to provide global routable IPv6 prefixes without a requirement for address translation. An ISP may for commercial reasons still decide to restrict the capabilities of the end users by other means like traffic and/or route filtering etc. If the carrier network is a mobile provider, then IPv6 is encouraged in comparison with the combination of IPv4+NAT for 3GPP attached devices. When looking in chapter 2.3 of RFC3314 'Recommendations for Van de Velde, et al. Expires April 25, 2006 [Page 22] Internet-Draft IPv6 Network Architecture Protection October 2005 IPv6 in 3GPP Standards' [15] it is found that the IPv6 WG recommends that one or more /64 prefixes should be assigned to each primary PDP context. This will allow sufficient address space for a 3GPP- attached node to allocate privacy addresses and/or route to a multi- link subnet, and will discourage the use of NAT within 3GPP-attached devices. 6. IPv6 Gap Analysis Like IPv4 and any major standards effort, IPv6 standardization work continues as deployments are ongoing. This section discusses several topics for which additional standardization, or documentation of best practice, is required to fully realize the benefits of NAP. None of these items are show-stoppers for immediate usage of NAP in roles where there are no current gaps. 6.1. Subnet Topology Masking There really is no functional gap here as a centrally assigned pool of addresses in combination with host routes in the IGP is an effective way to mask topology. If necessary a best practice document could be developed describing the interaction between DHCP and various IGPs which would in effect define Untraceable Addresses. As an alternative, some work in Mobile IP to define a policy message where a mobile node would learn from the Home Agent. It should not try to inform its correspondent about route optimization and thereby expose its real location. A border Home Agent using internal tunneling to the logical mobile node (potentially static) can completely mask all internal topology, while avoiding the strain from a large number of host routes in the IGP. This work should be pursued in the IETF. 6.2. Minimal Traceability of Privacy Addresses Privacy addresses (RFC 3041) may certainly be used to limit the traceability of external traffic flows back to specific hosts, but lacking a topology masking component above they would still reveal the subnet address bits. For complete privacy a best practice document describing the combination of privacy addresses with topology masking may be required. This work remains to be done, and should be pursued by the IETF. 6.3. Renumbering Procedure Documentation of site renumbering procedures [12] is completed and is in the RFC-editor's queue. It should also be noticed that ULAs may Van de Velde, et al. Expires April 25, 2006 [Page 23] Internet-Draft IPv6 Network Architecture Protection October 2005 help here too, since a change of ISP prefix will only affect hosts that need an externally routeable address as well as an ULA. 6.4. Site Multihoming This complex problem has never been completely solved for IPv4, which is exactly why NAT has been used as a partial solution. For IPv6, after several years' work, the IETF has converged on an architectural approach intended with service restoration as initial aim [20]. Again, ULAs may help since they will provide stable addressing for internal communications that are not affected by multihoming. 6.5. Untraceable Addresses The details of the untraceable addresses, along with any associated mechanisms such as route injection, must be worked out and specified. 7. IANA Considerations This document requests no action by IANA 8. Security Considerations While issues which are potentially security related are discussed throughout the document, the approaches herein do not introduce any new security concerns. Product marketing departments have widely sold IPv4 NAT as a security tool and suppliers have been implementing address translation functionality in their firewalls, though the misleading nature of those claims has been previously documented in RFC 2663 [2] and RFC 2993 [4]. This document defines IPv6 approaches which collectively achieve the goals of the network manager without the negative impact on applications or security that are inherent in a NAT approach. To the degree that these techniques improve a network manager's ability to explicitly know about or control access, and thereby manage the overall attack exposure of local resources, they act to improve local network security. In particular the explicit nature of a content aware firewall in NAP will be a vast security improvement over the NAT artifact where lack of translation state has been widely sold as a form of protection. 9. Conclusion This document has described a number of techniques that may be Van de Velde, et al. Expires April 25, 2006 [Page 24] Internet-Draft IPv6 Network Architecture Protection October 2005 combined on an IPv6 site to protect the integrity of its network architecture. These techniques, known collectively as Network Architecture Protection, retain the concept of a well defined boundary between "inside" and "outside" the private network, and allow firewalling, topology hiding, and privacy. However, because they preserve address transparency where it is needed, they achieve these goals without the disadvantage of address translation. Thus, Network Architecture Protection in IPv6 can provide the benefits of IPv4 Network Address Translation without the corresponding disadvantages. The document has also identified a few ongoing IETF work items that are needed to realize 100% of the benefits of NAP. 10. Acknowledgements Christian Huitema has contributed during the initial round table to discuss the scope and goal of the document, while the European Union IST 6NET project acted as a catalyst for the work documented in this note. Editorial comments and contributions have been received from: Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar, Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith, Elwyn Davies, Daniel Senie, Soininen Jonne, Lindqvist Erik Kurt and other members of the v6ops WG. 11. References 11.1. Normative References [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [4] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. Van de Velde, et al. Expires April 25, 2006 [Page 25] Internet-Draft IPv6 Network Architecture Protection October 2005 [6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [10] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [11] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [12] Baker, F., "Procedures for Renumbering an IPv6 Network without a Flag Day", draft-ietf-v6ops-renumbering-procedure-05 (work in progress), March 2005. [13] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in progress), January 2005. 11.2. Informative References [14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [15] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [16] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [17] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful (draft-dupont-ipv6- rfc3041harmful-05.txt)", June 2004. [18] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- v6ops- port-scanning-implications-01.txt)", July 2004. Van de Velde, et al. Expires April 25, 2006 [Page 26] Internet-Draft IPv6 Network Architecture Protection October 2005 [19] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network (draft-chown-v6ops-renumber-thinkabout-03)", October 2004. [20] Huston, G., "Architectural Commentary on Site Multi-homing using a Level 3 Shim (draft-ietf-shim6-arch-00.txt)", July 2004. Appendix A. Additional Benefits due to Native IPv6 and Universal Unique Addressing The users of native IPv6 technology and global unique IPv6 addresses have the potential to make use of the enhanced IPv6 capabilities, in addition to the benefits offered by the IPv4 technology. A.1. Universal Any-to-Any Aonnectivity One of the original design points of the Internet was any-to-any connectivity. The dramatic growth of Internet connected systems coupled with the limited address space of the IPv4 protocol spawned address conservation techniques. NAT was introduced as a tool to reduce demand on the limited IPv4 address pool, but the side effect of the NAT technology was to remove the any-to-any connectivity capability. By removing the need for address conservation (and therefore NAT), IPv6 returns the any-to-any connectivity model and removes the limitations on application developers. With the freedom to innovate unconstrained by NAT traversal efforts, developers will be able to focus on new advanced network services (i.e. peer-to-peer applications, IPv6 embedded IPsec communication between two communicating devices, instant messaging, Internet telephony, etc..) rather than focusing on discovering and traversing the increasingly complex NAT environment. It will also allow application and service developers to rethink the security model involved with any-to-any connectivity, as the current edge firewall solution in IPv4 may not be sufficient for Any-to-any service models. A.2. Auto-configuration IPv6 offers a scalable approach to minimizing human interaction and device configuration. Whereas IPv4 implementations require touching each end system to indicate the use of DHCP vs. a static address and management of a server with the pool size large enough for the potential number of connected devices, IPv6 uses an indication from the router to instruct the end systems to use DHCP or the stateless auto configuration approach supporting a virtually limitless number Van de Velde, et al. Expires April 25, 2006 [Page 27] Internet-Draft IPv6 Network Architecture Protection October 2005 of devices on the subnet. This minimizes the number of systems that require human interaction as well as improves consistency between all the systems on a subnet. In the case that there is no router to provide this indication, an address for use on the local link only will be derived from the interface media layer address. A.3. Native Multicast Services Multicast services in IPv4 were severely restricted by the limited address space available to use for group assignments and an implicit locally defined range for group membership. IPv6 multicast corrects this situation by embedding explicit scope indications as well as expanding to 4 billion groups per scope. In the source specific multicast case, this is further expanded to 4 billion groups per scope per subnet by embedding the 64 bits of subnet identifier into the multicast address. IPv6 allows also for innovative usage of the IPv6 address length, and makes it possible to embed the multicast 'Rendez-Vous Point' (or RP) [16] directly in the IPv6 multicast address when using ASM multicast. this is not possible with limited size of the IPv4 address. This approach also simplifies the multicast model considerably, making it easier to understand and deploy. A.4. Increased Security Protection The security protection offered by native IPv6 technology is more advanced than IPv4 technology. There are various transport mechanisms enhanced to allow a network to operate more securely with less performance impact: o IPv6 has the IPsec technology directly embedded into the IPv6 protocol. This allows for simpler peer-to-peer encryption and authentication, once a simple key/trust management model is developed, while the usage of some other less secure mechanisms is avoided (i.e. md5 password hash for neighbor authentication). o On a local network, any user will have more security awareness. This awareness will motivate the usage of simple firewall applications/devices to be inserted on the border between the external network and the local (or home network) as there is no Address Translater and hance no false safety perception. o All flows on the Internet will be better traceable due to a unique and globally routable source and destination IPv6 address. This may facilitate an easier methodology for back-tracing DoS attacks and avoid illegal access to network resources by simpler traffic filtering. o The usage of private address-space in IPv6 is now provided by Unique Local Addresses, which will avoid conflict situations when merging networks and securing the internal communication on a Van de Velde, et al. Expires April 25, 2006 [Page 28] Internet-Draft IPv6 Network Architecture Protection October 2005 local network infrastructure due to simpler traffic filtering policy. o The technology to enable source-routing on a network infrastructure has been enhanced to allow this feature to function, without impacting the processing power of intermediate network devices. The only devices impacted with the source- routing will be the source and destination node and the intermediate source-routed nodes. This impact behavior is different if IPv4 is used, because then all intermediate devices would have had to look into the source-route header. A.5. Mobility Anytime, anywhere, universal access requires MIPv6 services in support of mobile nodes. While a Home Agent is required for initial connection establishment in either protocol version, IPv6 mobile nodes are able to optimize the path between them using the MIPv6 option header while IPv4 mobile nodes are required to triangle route all packets. In general terms this will minimize the network resources used and maximize the quality of the communication. A.6. Merging Networks When two IPv4 networks want to merge it is not guaranteed that both networks would be using different address-ranges on some parts of the network infrastructure due to the legitimate usage of RFC 1918 private addressing. This potential overlap in address space may complicate a merge of two and more networks dramatically due to the additional IPv4 renumbering effort. i.e. when the first network has a service running (NTP, DNS, DHCP, HTTP, etc..) which need to be accessed by the 2nd merging network. Similar address conflicts can happen when two network devices from these merging networks want to communicate. With the usage of IPv6 the addressing overlap will not exist because of the existence of the Unique Local Address usage for private and local addressing. A.7. Community of interest Although some Internet-enabled devices will function as fully-fledged Internet hosts, it is believed that many will be operated in a highly restricted manner functioning largely or entirely within a Community of Interest. By Community of Interest we mean a collection of hosts that are logically part of a group reflecting their ownership or function. Typically, members of a Community of Interest need to communicate within the community but should not be generally accessible on the Internet. They want the benefits of the Van de Velde, et al. Expires April 25, 2006 [Page 29] Internet-Draft IPv6 Network Architecture Protection October 2005 connectivity provided by the Internet, but do not want to be exposed to the rest of the world. This functionality will be available through the usage of NAP and native IPv6 dataflows, without any stateful device in the middle. It will also allow to build virtual organization networks on the fly, which is very difficult to do in IPv4+NAT scenarios. Appendix B. Revision history B.1. Changes from *-vandevelde-v6ops-nap-00 to *-vandevelde-v6ops-nap-01 o Document introduction has been revised and overview table added o Comments and suggestions from nap-00 draft have been included. o Initial section of -00 draft 2.6 and 4.6 have been aggregated into a new case study section 5. o The list of additional IPv6 benefits has been been placed into appendix. o new security considerations section added. o GAP analysis revised. o Section 2.6 and 4.6 have been included. B.2. Changes from *-vandevelde-v6ops-nap-01 to *-ietf-v6ops-nap-00 o Change of Draft name from *-vandevelde-v6ops-nap-01.txt to *-ietf- v6ops-nap-00.txt. o Editorial changes. B.3. Changes from *-ietf-v6ops-nap-00 to *-ietf-v6ops-nap-01 o Added text in Chapter 2.2 and 4.2 to address more details on firewall and proxy o Revised Eric Klein contact details o Added note in 4.2 that control over the proposed statefull-filter should be by a simple user-interface B.4. Changes from *-ietf-v6ops-nap-01 to *-ietf-v6ops-nap-02 o General Note: Header more consistent capitelized. o Section 1: para 3: s/...and privacy and will... translation./ ...and privacy. NAP will achieve these security goals without address transaltion whilst maintaining any-to-any connectivity./ o Section 1: Various editorial changes happened o Section 2.1: Changed: 'Frequently a simple user interface is sufficient for configuring'. into 'Frequently a simple user interface, or no user interface is sufficient' o Section 2.2: (Simple Security ) Better not to use the word -evil- in the text o Section 2.2: changed 'provided by NAT are actually ' into 'provided by NAT is actually' Van de Velde, et al. Expires April 25, 2006 [Page 30] Internet-Draft IPv6 Network Architecture Protection October 2005 o Section 2.2: para 3: s/actually false/actually an illusion/ o Section 2.2: para 2: added 'Also it will only be reliable if a mechanism such as 'trusted computing' is implemented in the end- system; without this enhancement administrators will be unwilling to trust the behavior of end-systems. o Section 2.3: para 1: s/of the NAT devices state/from the NAT device's state/ o Section 2.4: para1: clarified the definition of topology hiding o Section 2.4: last sentence of next-to-last paragraph, added punctuation at end of sentence. o Section 2.4: added first line: When mentioning 'topology hiding' the goal is to make a reference that an entity outside the network can not make a correlation between the location of a device and the address of a device on the local network. o Section 2.4: para 1: s/reflected/represented/ o Section 2.5: last par: added reference: 'Section 2.7 describes some disadvantages that appear if independednt networks using [RFC1918] addresses have to be merged.' o Section 2.6: Added text that private address-space is not limitless o Section 2.6: Various editorial changes o Section 2.7: Para 1 editorial revised o Section 2.7: last para: s/This solution/The addition of an extra NAT as a solution/ o Section 2.7: s/highly desirable to be/highly desirable due to resiliency and load-balancing to be/ o Section 2.7: added text on the reason why there are overlapping addresses o Section 2.7: last para: s/merged address space/overlapping address speaces in the merged networks/ o Section 3.1: Para 1 editorial changes o Section 3.1: s/by contacted web sites, so IPv6/by web sites that are accessed from the device: IPv6 / o Section 3.1: s/as that would have a serious negative impact on global routing/as that would have a negative effect on global route aggregation o Section 3.2: s3.2: Par 1 editorial revised and noted that ULA in global routing table is not scalable o Section 3.2: s3.2: Noted that it is not always interresting to mix ULA with global as that may lead to SAS issues o Section 3.3: last para: s/delegating router/delegating router (incorporating a DHCPv6 server)/, s/across an administrative/ possibly across an administrative/ o Section 3.4: Changed: 'random assignment has as purpose' to 'random assignment has a purpose' o Section 3.4: para 2: Replace first sentence with: 'The random assignment is intended to mislead the outside world about the structure of the local network.' Van de Velde, et al. Expires April 25, 2006 [Page 31] Internet-Draft IPv6 Network Architecture Protection October 2005 o Section 3.4: para 2: s/there is a correlation/needs to maintain a correlation/ o Section 3.4: para 2: s/like a/such as a/ o Section 3.4: para 3: s/unpredictable/amorphous/, s/or from mapping/and from mapping of/ o Section 3.4: para 3: s/are reachable on/are allocated to devices on/ o Section 3.4: para 3: s/belonging to the same subnet next to each other/belonging to devices adjacent to each other on the same subnet/ o Section 3.4: s/aggregation device/indirection device/ o Section 4.1: splitted the 1 section up into 2 separate sections o Section 4.1: s/ End node connections involving other nodes on the global Internet will always use the global IPv6 addresses [9] derived from this prefix delegation./ End node connections involving other nodes on the global Internet will always use the global IPv6 addresses [9] derived from this prefix delegation. It should be noted that the policy table needs to be correctly set up so that true global prefixes are distinguished from ULAs and will be used for the source address in preference when the destination is not a ULA/ o Section 4.1: A more secure network environment can be established by having the referenced ULA addresses statically configured on the network devices as this decreases the dynamic aspects of the network, however the operational overhead is increased. o Section 4.2:Added note that IID should be randomized for port-scan protection o Section 4.2: Removed text: This is an automated procedure of sending Internet Control Message Protocol (ICMP) echo requests (also known as PINGs) to a range of IP addresses and recording replies. This can enable an attacker to map the network. o Section 4.2: paragraph beginning: "This simple rule...". The first sentence in this paragraph was overly-long. The sentence has been fragmented o Section 4.2: para 1: s/similar as for an/similar to that of an/ o Section 4.2: para 1: s/Internet, and firewall and IDS systems are/ Internet. The use of firewall and Intrusion Detection Systems (IDS) is/ o Section 4.2: para 1: s/but has/but with/ o Section 4.2: para 1: s/end to end/end-to-end/ o Section 4.2: Item 3: s/amount/number/ o Section 4.2: Item 3: s/This goes from the assumption that the attacker has no/This protection is nullified if the attacker has/ o Section 4.2: para after Item 3: s/pose/offer/ (or provide). o Section 4.2: para after Item 3: s/best- practices/best practices/ o Section 4.2: para after example firewall rules: s/create similar protection and security holes the typical IPv4 NAT device will offer/provide (non-)protection and create security holes similar Van de Velde, et al. Expires April 25, 2006 [Page 32] Internet-Draft IPv6 Network Architecture Protection October 2005 to those offered to a network using a typical IPv4 NAT device/ o Section 4.2: para next but one after firewall rules: s/What one does when topology probing is to get an idea of the available hosts/The intention of topology probing is to identify a selection of the available hosts/ o Section 4.2: s/This is directly the opposite of what IPv6 security best practices are trying to achieve./IPv6 security best practices will avoid this kind of illusory security but can only do this if correctly configured firewalls and IDS systems are used at the perimeter where some IPv4 networks have relied on NATs. o Section 4.2: s/ It is recommended for site administrators to take [17] into consideration to achieve the expected goal./ It is recommended for site administrators to take [17] into consideration to achieve the expected goal. This protection will also be nullified if IIDs are configured in a group near the start of the IID space./ o Section 4.2: Removed the example study and added complementiory text to describe a potential behavior o Section 4.4: rewrite of the section to reduce the importance of the MIpv^ and tunneled solution o Section 4.4: (Privacy and Topology Hiding) Mobile IP is suggested in the text, however text is added that any kind of tunneling should do the trick. o Section 4.4: para 2: after 'As discussed above' inserted '(see Section 3.1)' o Section 4.4: para 3: s/consolidated on/indirected via/ o Section 4.4: para 3: s/topololgy masked/each topology masked/ o Section 4.4: para 3: Expanded acronym COA o Section 4.4: para 3: s/rack mounted/static/ o Section 4.4: Rephrasing of text happened in this section o Section 4.5: change: "so that a NAT is not required" to: "so that IPv6 address translation is not required". o Section 4.5: changed 'periodically to look' into 'to look periodically' o Section 4.5: change: "2^64 hosts" to: "2^64 addresses". o Section 4.5: Removed the statement '(or even defined) o Section 4.6: last para: s/which will lead to the IPv4 practice/ which will require the adoption of the IPv4 workaround/ o Section 4.6: s/the IPv4 constricting scenarios of multiple devices sharing a/the constriction of IPv4 scenarios where multiple devies are forced to share a/ o Section 4.7: s/as the zero-touch external/as an almost zero-touch external/ o Section 5: Replaced first three sentences with: In presenting these case studies we have chosen to consider categories of network divided first according to their function either as carrier/ISP networks or end user (such as enterprise) networks with the latter category broken down according to the number of Van de Velde, et al. Expires April 25, 2006 [Page 33] Internet-Draft IPv6 Network Architecture Protection October 2005 connected end hosts. o Section 5: bullet points: s/connection/connected end hosts/ o Section 5.1: s/addressing independence/addressing independence when using IPv4/ o Section 5.1: last para: s/is only affecting/will only affect/ o Section 5.1: changed 'alloaction' into 'allocation' o Section 5.1: changed: '(typically a one or' into '(typically one or' o section 5.1: changed: s/allocation/assignment/ in one of the paragraphs o section 5.2: para 1: s?is too long?is too long (very often just a /32 just giving a single address)? o Section 5.4: (Case study: ISP networks) ULA usage for ISP/ Carrier-grade networks is mentioned in the draft, while it was suggested that for these NW the PI addresses are already very stable and they should be qualified for setting up proper filtering -> removed ULA from this section. o Section 5.4: changed 'intra- communication' into 'communication' o Section 5.4: s/chapter 5.1/Section 5.1/ o Section 6.1: (Completion of work on ULAs) Text revision to reflect current state of ULA or remove the chapter? Chapter removed ... ULA specification is in the RFC-editor queue. o Section 6.3: (Minimal Traceability) Better to say "topology masking _may be_ required" instead of "is required", because whether this is needed or not is a value judgment. o Section 6.4: (Renumbering Procedure) Renumbering procedure is in RFC queue. The section corrected in the current state? o Section 6.4: s/well solved/completely solved/ o In general the whole chapter 6 has been revised to reflect current status Van de Velde, et al. Expires April 25, 2006 [Page 34] Internet-Draft IPv6 Network Architecture Protection October 2005 Authors' Addresses Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 Email: gunter@cisco.com Tony Hain Cisco Systems 500 108th Ave. NE Bellevue, Wa. USA Email: alh-ietf@tndh.net Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: rdroms@cisco.com Brian Carpenter IBM Corporation Sauemerstrasse 4 Rueschlikon, 8803 Switzerland Email: brc@zurich.ibm.com Eric Klein Tel Aviv University Tel Aviv, Israel Phone: Email: ericlklein@softhome.net Van de Velde, et al. Expires April 25, 2006 [Page 35] Internet-Draft IPv6 Network Architecture Protection October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Van de Velde, et al. Expires April 25, 2006 [Page 36]