RFC 4864
Local Network Protection for IPv6
Local Network Protection for IPv6 💖
okay bestie, let's get the vibe set first 🎀 this RFC is a Request for Comments from the IETF, and it's labelled Informational 🌸 so it's sharing ideas, not setting a rule.
The crew behind it is G. Van de Velde, T. Hain, R. Droms, B. Carpenter, and E. Klein 🫶 The affiliations listed are Cisco Systems, IBM, and Tel Aviv University ✨ It came out in May 2007 📅 and the header doesn't list anything it obsoletes or updates, so it's a standalone read 🦋
Status of This Memo 🍓
ok so this memo is just here to share information with the Internet community 💅 it is not a standard of any kind, and it's totally fine to pass around, because distribution is unlimited 🌈
Copyright Notice ⭐
the IETF Trust holds the copyright, and the year is 2007 🎀
Abstract 🔥
okay real talk, NAT has tons of perceived perks 🙈 its big headline benefit is "amplifying" the address space, but IPv6 doesn't need that trick at all 💜 and NAT comes with a long list of serious downsides on top of that 💀
people also think NAT gives you extra goodies, like management and security attributes that could be handy for an Internet Protocol site 🧚 the main point of this doc is that IPv6 was designed so NAT wouldn't be necessary 👑 and it shows that Local Network Protection (LNP) using IPv6 can give you the same benefits, or even more, without doing any address translation at all 💖✨
Table of Contents 🌸
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . 11
3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 11
3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 12
3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13
3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13
4. Using IPv6 Technology to Provide the Market Perceived
Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Simple Gateway between Internet and Internal Network . . . 14
4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15
4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17
4.4. Privacy and Topology Hiding Using IPv6 . . . . . . . . . . 17
4.5. Independent Control of Addressing in a Private Network . . 20
4.6. Global Address Pool Conservation . . . . . . . . . . . . . 21
4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Medium/Large Private Networks . . . . . . . . . . . . . . 22
5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 24
5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25
5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 26
6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 27
6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 28
6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 28
6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. Informative References . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Additional Benefits Due to Native IPv6 and
Universal Unique Addressing . . . . . . . . . . . . . 32
A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 32
A.2. Auto-Configuration . . . . . . . . . . . . . . . . . . . . 32
A.3. Native Multicast Services . . . . . . . . . . . . . . . . 33
A.4. Increased Security Protection . . . . . . . . . . . . . . 33
A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 341. Introduction ✨
okay so there have been periodic claims that IPv6 will need Network Address Translation (NAT) 🤔 bc network admins use NAT for a bunch of different needs on IPv4, and those needs don't just disappear when you move to IPv6. 🌸 NAT has lots of perceived benefits, but its main one, "amplifying" the available address space, isn't needed in IPv6. The serious downsides NAT causes for applications, plus the ambiguous address space that comes with it [1] [5], have already been well documented [4] [6], so we're not going to rehash all of that here. 💅 Still, NAT is everywhere, so it obviously has some perceived benefits, even though most people using it haven't actually looked at the technical trade-offs. 🙈 It's also often claimed that some connectivity and security problems can only be solved with a NAT device, and nobody mentions the negative impact on applications. 💀 This gets amplified by vendor best-practice docs and sample configs that pile up everywhere and don't separate the translation part (expanding addresses) from the state part (limiting connectivity). 😭
This document looks at the ways a NAT device gets used in an IPv4 environment and is regularly cited as a "solution" to perceived problems. ✨ Then it shows how a network manager's goals can still be met in an IPv6 network without using NAT's header modification feature. 🦋 Heads up: this document is 'informational', because it talks about approaches that will work to accomplish the network manager's goals. 🎀 It is specifically not a Best Current Practice (BCP) recommending any one approach, and it's not a manual on how to configure a network. 🧚
When it comes to security and privacy, this document looks at how to mitigate a bunch of threats. 🔥 Some are obviously external, like a hacker or a worm-infected machine outside trying to break into the local network. 👑 Some are local, like a disgruntled employee messing with business operations, or a user who accidentally downloads malware that then attacks from the inside. 💀 Some may be built into the device hardware ("embedded"), like firmware in a domestic appliance that "calls home" to its manufacturer without the user's consent. 🙅♀️
Another thing it covers is the idea that NAT can be used to meet the goals of a security policy. 🌈 Here's the tea: NAT does satisfy some policy goals, like topology hiding, but at the same time it defeats others, like being able to produce an end-to-end audit trail at the network level. 🫶 That said, there are some artifacts of NAT devices that do provide real value:
- The need to establish state before anything gets through from outside to inside solves one set of problems.
- The expiration of state to stop receiving any packets when finished with a flow solves a set of problems.
- The ability for nodes to appear to be attached at the edge of the network solves a set of problems.
- The ability to have addresses that are not publicly routed solves yet another set (mostly changes where the state is and scale requirements for the first one).
This document describes several techniques that may be combined in an IPv6 deployment to protect the integrity of its network architecture. ✨ It's focused on the 'how to accomplish a goal' perspective and leaves most of the 'why that goal is useful' perspective to other documents. 💖 These techniques, collectively known as Local Network Protection (LNP), keep a well-defined boundary between "inside" and "outside" the private network, while still allowing firewalling, topology hiding, and privacy. 🎀 LNP gets these security goals without address translation, and it gets back the ability for arbitrary any-to-any connectivity. 🦋 Literally iconic. 👑
The table below summarises IPv6 LNP. It lays out the marketed benefits of IPv4+NAT, with a cross-reference to how each one is delivered in both IPv4 and IPv6 environments. 🍓
Goal 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 |
| | see Section 2.4 | see Section 4.4 |
+------------------|-----------------------|-----------------------+
| Addressing | RFC 1918 | RFC 3177 & 4193 |
| Autonomy | see Section 2.5 | see Section 4.5 |
+------------------|-----------------------|-----------------------+
| Global Address | RFC 1918 | 17*10^18 subnets |
| Pool | << 2^48 application | 3.4*10^38 addresses |
| Conservation | end points | full port list / addr |
| | topology restricted | unrestricted topology |
| | see Section 2.6 | see Section 4.6 |
+------------------|-----------------------|-----------------------+
| Renumbering and | Address translation | Preferred lifetime |
| Multihoming | at border | per prefix & multiple|
| | | addresses per |
| | | interface |
| | see Section 2.7 | see Section 4.7 |
+------------------+-----------------------+-----------------------+This document first digs into the perceived benefits of NAT in more detail, then shows how IPv6 LNP can provide each of them. 🌸 It wraps up with an IPv6 LNP case study and a gap analysis of the standards work still to be done for an optimal LNP solution. 🧚 Let's gooo. ✨
2. Perceived Benefits of NAT and Its Impact on IPv4 💜
This section gives you the lowdown on the generally perceived benefits of using IPv4 NAT. 💅 The point isn't to analyse those benefits or check whether the perception is accurate (there are detailed discussions of that in [4]). Instead, it describes the deployment requirements and sets up the context for the later IPv6 approaches to dealing with those requirements. 🫶
2.1. Simple Gateway between Internet and Private Network 🎀
okay so a NAT device can connect a private network to the Internet, and the private network's addresses can come from basically any part of the address space (ambiguous [1]or global registered and unregistered addresses) 🌈 Extra effort is needed when the same range exists on both sides of the NAT, though. 🙈 The private network can be built from globally unique addresses, from ambiguous address space, or from both at the same time. 🦋 In the simple case of private use addresses, 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, and it doesn't need any specific configuration to do it. 🍓
Wide-scale deployments have shown that using NAT as a simple gateway between a private IPv4 network and the Internet is simple and practical for non-technical end users. 💖 Often a simple user interface, or even a default configuration, is enough to set up both device and application access rights. ✨
But this simplicity comes at a price, because the resulting topology puts restrictions on applications. 💀 NAT's simplicity works well when applications are limited to a client/server model with the server on the public side of the NAT. 🥲 For peer-to-peer or multi-party applications, or for servers deployed on the private side of the NAT, helper technologies must also be deployed. 🔧 Those helpers are often complex to develop and manage, which creates a hidden cost to this "simple gateway". 👀 Not me paying the hidden cost. 💅
2.2. Simple Security Due to Stateful Filter Implementation 🔒
Okay so this is a big myth-busting moment, bestie 💅 It's frequently believed that because NAT is session-oriented, it puts an extra barrier up to keep the private network protected from outside influences. Since a NAT device typically keeps state only for individual sessions, attackers, worms, etc., can't use that state to attack a specific host on any other port. 🙈 However, in the port overload case of Network Address Port Translation (NAPT), attacking all active ports will impact a potentially wide number of hosts. So this benefit may be partially real, but experienced hackers are well aware of NAT devices and are super familiar with private address space 💀 They've devised attack methods, like trojan horses, that readily penetrate NAT boundaries. Stateful filtering does offer a measure of protection against a variety of straightforward network attacks, but it does not protect against all attacks, even though it's being sold as a one-size-fits-all answer. Not it being the hero 😭
Translating address bits within the header does not provide security in itself. For example, picture a configuration with static NAT where all inbound ports translate to a single machine. In that scenario, the security risk for that machine is identical to the case with no NAT device in the communication path, because any connection to the public address will be delivered to the mapped target. Literally no protection, just a fancy address swap 🎀
The perceived security of NAT comes from the lack of pre-established or permanent mapping state. It's often used as a "better than nothing" level of protection because it doesn't require complex management to filter out unwanted traffic ✨ Dynamically establishing state in response to internal requests reduces the threat of unexpected external connections to internal devices, and this level of protection would also be available from a basic firewall. (A basic firewall, supporting clients accessing public side servers, would improve on that level of protection by avoiding the problem of state persisting as different clients use the same private side address over time 🦋) This role, often marketed as a firewall, is really an arbitrary artifact, while a real firewall often offers explicit and more comprehensive management controls. Real firewall energy 👑
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 the simple router discussed in Section 2.1. And here's the chaos: in situations where two or more devices need to host the same application or otherwise use the same public port, this complexity shifts from difficult to impossible 💀
2.3. User/Application Tracking 🕵️♀️
One usage of NAT is for the local network administrator to track user and application traffic. 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 access to which Internet location. This is done by periodically logging the network address translation details of the private and the public addresses from the NAT device's state database 📋
The subsequent 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 a private IPv4-address and a network element or user at all times, or the administrator has a time-correlated list of the address/port mappings. So much assuming, so little guaranteed 🫠
2.4. Privacy and Topology Hiding 🎭
One goal of 'topology hiding' is to prevent external entities from making a correlation between the topological location of devices 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) globally routable IPv4 address(es) 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) 🧚
By using NAT, a system appears to the Internet as if it originated inside the NAT box itself. In other words, the IPv4 address that appears on the Internet is only sufficient to identify the NAT, so all internal nodes appear to exist at the demarcation edge. 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. So although NATs do nothing to provide application level privacy, they do prevent the external tracking and profiling of individual systems by means of their IP addresses, usually known as 'device profiling' 🦋
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 network managers prefer to hide as much as possible of their internal network topology from outsiders as a useful precaution to mitigate scanning attacks. Mostly, this is achieved by blocking "traceroute", etc., though NAT entirely hides the internal subnet topology. Scanning is a particular concern in IPv4 networks because the subnet size is small enough that once the topology is known, it is easy to find all the hosts, then start scanning them for vulnerable ports. Once a list of available devices has been mapped, a port-scan on these IP addresses can be performed. 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 access to an end-system to command it to start initiating attacks on others. That's the seriously scary part, so please don't skip it 🚨
2.5. Independent Control of Addressing in a Private Network 🏡
Many private IPv4 networks make use of the address space defined in RFC 1918 to enlarge the available addressing space for their private network, and at the same time reduce their need for globally routable addresses. This type of local control of address resources allows a sufficiently large pool for a clean and hierarchical addressing structure in the local network 🌈
Another benefit is the ability to change providers with minimal operational difficulty due to the usage of independent addresses on a majority of the network infrastructure. Changing the addresses on the public side of the NAT avoids the administrative challenge of changing every device in the network. Less chaos, more glow-up ✨
Section 2.7 describes some disadvantages that appear if independent networks using ambiguous addresses [1] have to be merged.
2.6. Global Address Pool Conservation 🌍
While the widespread use of IPv4+NAT has reduced the potential consumption rate, the ongoing depletion of the IPv4 address range has already taken the remaining pool of unallocated IPv4 addresses well below 20%. While mathematical models based on historical IPv4 prefix consumption periodically attempt to predict the future exhaustion date of the IPv4 address pool, a possible result of this continuous resource consumption is that the administrative overhead for acquiring globally unique IPv4 addresses will at some point increase noticeably due 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 the private use address space is strictly limited in size. Some deployments have already outgrown that space and have begun cascading NAT to continue expanding, though this practice eventually breaks down over routing ambiguity. Additionally, while we are unlikely to know the full extent of the practice (because it is hidden behind a NAT), service providers have been known to announce previously unallocated public space to their customers (to avoid the problems associated with the same address space appearing on both sides), only to find that once that space was formally allocated and being publicly announced, their customers couldn't reach the registered networks 💔
The number of and types of applications that can be deployed by these ISPs and their customers are restricted by the ability to overload the port range on the public side of the most public NAT in the path. The limit of this approach is something substantially less than 2^48 possible active application endpoints (approximately [2^32 minus 2^29] * [2* 2^16 minus well-known port space]), as distinct from addressable devices each with its own application endpoint range. Those who advocate layering of NAT frequently forget to mention that there are topology restrictions placed on the applications. Forced into this limiting situation, such customers can rightly claim that despite the optimistic predictions of mathematical models, the global pool of IPv4 addresses is effectively already exhausted 🥺
2.7. Multihoming and Renumbering with NAT 🔁
Allowing a network to be multihomed and renumbering a network are quite different functions. However, these are argued together as reasons for using NAT, because 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 by being 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 Classless Inter-Domain Routing (CIDR) prefix [18] 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 RFC 1918 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 allows 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 major problems due to administrative difficulties of overlapping address spaces in the merged networks 💀
3. Description of the IPv6 Tools ✨
okay bestie, this section walks through the IPv6 features that can be used as part of the LNP solution to replace the protection stuff IPv4 NAT was doing 💅
The reader must clearly distinguish between features of IPv6 that were fully defined when this document was drafted and those that were potential features that still required more work to define them. 🧐 The latter are summarized later in the 'Gap Analysis' section of this document. However, we do not distinguish in this document between fully defined features of IPv6 and those that were already widely implemented at the time of writing. 🌸
3.1. Privacy Addresses (RFC 3041)
okay this one is sooo important 🙈 There are situations where it is desirable to prevent device profiling, for example, by web sites that are accessed from the device as it moves around the Internet. IPv6 privacy addresses were defined to provide that capability. 🕵️♀️ IPv6 addresses consist of a routing prefix, a subnet-id (SID) part, and an interface identifier (IID) part. As originally defined, IPv6 stateless address auto-configuration (SLAAC) will typically embed the IEEE Link Identifier of the interface as the IID part, though this practice facilitates tracking and profiling of a device through the consistent IID. 😬 RFC 3041 [7] describes an extension to SLAAC to enhance device privacy. Use of the privacy address extension causes nodes to generate global-scope addresses from interface identifiers that change over time, consistent with system administrator policy. Changing the interface identifier (thus the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when addresses used in different transactions actually correspond to the same node. A relatively short valid lifetime for the privacy address also has the 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 are expected to be from end-systems running stateless auto-configuration, there is nothing that prevents a Dynamic Host Configuration Protocol (DHCP) server from running the RFC 3041 algorithm for any new IEEE identifier it hears in a request, then remembering that for future queries. 🧚 This would allow using them in DNS for registered services since the assumption of a DHCP 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, is effectively a sparse allocation technique that 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 Section 3.4. Additional considerations are discussed in [19]. 💜
3.2. Unique Local Addresses
Achieving the goal of autonomy, that many perceive as a value of NAT, is required for local network and application services stability during periods of intermittent connectivity or moving between one or more providers. Such autonomy in a single routing prefix environment would lead to massive expansion of the global routing tables (as seen in IPv4), so IPv6 provides for simultaneous use of multiple prefixes. 🌈 The Unique Local Address (ULA) prefix [17] has been set aside for use in local communications. The ULA 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 as large-scale inter-domain distribution of routes for ULA prefixes would have a negative impact on global route aggregation. 🚫
ULAs have the following characteristics:
- For all practical purposes, a globally unique prefix
- allows networks to be combined or privately interconnected without creating address conflicts or requiring renumbering of interfaces using these prefixes, and
- if accidentally leaked outside of a network via routing or DNS, is highly unlikely that there will be a conflict with any other addresses.
- They are ISP independent and can be used for communications inside of a network without having any permanent or only intermittent Internet connectivity.
- They have a well-known prefix to allow for easy filtering at network boundaries preventing leakage of routes and packets that should remain local.
- In practice, applications may treat these addresses like global-scope addresses, but address selection algorithms may need to distinguish between ULAs and ordinary global-scope unicast addresses to ensure stability. The policy table defined in [11] is one way to bias this selection, by giving higher preference to
FC00::/7over2001::/3. Mixing the two kinds of addresses may lead to undeliverable packets during times of instability, but that mixing is not likely to happen when the rules of RFC 3484 are followed. ⚖️ - ULAs have no intrinsic security properties. However, they have the useful property that their routing scope is limited by default within an administrative boundary. Their usage is suggested at several points in this document, as a matter of administrative convenience. 🫶
3.3. DHCPv6 Prefix Delegation
One of the functions of a simple gateway is managing the local use address range. 🏠 The Prefix Delegation (DHCP-PD) options [12] provide a mechanism for automated delegation of IPv6 prefixes using the DHCP [10]. This mechanism (DHCP-PD) is intended for delegating a long-lived prefix from a delegating router (possibly 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
The main goal of untraceable IPv6 addresses is to create an apparently amorphous network infrastructure, as seen from external networks, to protect the local infrastructure from malicious outside influences and from mapping of any correlation between the network activities of multiple devices from external networks. 🥷 When using untraceable IPv6 addresses, it could be that two apparently sequential addresses are allocated to devices on very different parts of the local network instead of belonging to devices adjacent to each other on the same subnet. 🤯
Since IPv6 addresses will not be in short supply even within a single /64 (or shorter) prefix, it is possible to generate them effectively at random when untraceability is required. They will be globally routable IPv6 addresses under the site's prefix, 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. In particular, the subnet structure may be invisible in the address. Thus, a flat routing mechanism will be needed within the site. The local routers need to maintain a correlation between the topological location of the device and the untraceable IPv6 address. For smaller deployments, this correlation could be done by generating IPv6 host route entries, or for larger ones by utilizing an indirection device such as a Mobile IPv6 Home Agent. Additional details are in Section 4.7. 🎀
4. Using IPv6 Technology to Provide the Market Perceived Benefits of 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 should 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 in a topology more complex than a single link to communicate amongst themselves independent of the state of a global connection. If the network happened to concatenate with another local network, the randomness in ULA creation is highly unlikely to result in address collisions. 🌸
With external connectivity, the simple gateway should use DHCP-PD to acquire a routing prefix from the service provider for use when connecting to the global Internet. End-system connections involving other nodes on the global Internet that follow the policy table in RFC 3484 will always use the global IPv6 addresses derived from this prefix delegation. It should be noted that the address selection policy table should be configured to prefer the ULA prefix range over the DHCP-PD prefix range when the goal is to keep local communications stable during periods of transient external connectivity. 🫧
In the very simple case, there is no explicit routing protocol on either side of the gateway, and a single default route is used internally pointing out to the global Internet. A slightly more complex case might involve local internal 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 the service provider could install a route for the prefix delegated via DHCP-PD pointing toward the connecting link. 💅✨
4.2. IPv6 and Simple Security ✨
okay so an IPv6 host sitting directly on the Internet is basically in the same boat as an IPv4 host 🚢. Firewalls and Intrusion Detection Systems (IDSs) are recommended if you want boundary protection on top of your host defenses 🛡️. A proxy can work for certain applications, but ngl it breaks end-to-end transparency 😬. BUT with IPv6 you still get these protections without NAT, and end-to-end reachability stays intact 💖:
- Short lifetimes on privacy extension suffixes shrink the attack profile 📉, since the node won't respond to the address once its lifetime becomes invalid.
- IP security (IPsec) gets cited as the reason IPv6 is more secure, and it's giving because it's a mandatory service for IPv6 implementations 🔐. But broader availability doesn't improve security all by itself, because its use still depends on having a key infrastructure in place. IPsec is how you authenticate the correspondent, prevent session hijacking, prevent content tampering, and optionally mask the packet contents 🎀. IPsec is commonly available in some IPv4 implementations too, and with extensions it can support NAT traversal, but NAT support has limitations and doesn't work in all situations 🙃. Using IPsec with NATs needs an extra UDP encapsulation and keepalive overhead [13]. In the IPv4/NAT world, IPsec has mostly been limited to edge-to-edge Virtual Private Network (VPN) deployments 🧱. The potential for end-to-end IPsec gets way better when NAT is removed from the network, since connections can be initiated from either end ✨. Also, encrypted IPsec traffic will bypass content-aware firewalls, and that's presumed to be acceptable for parties the site has set up a security association with 🫶.
- The size of the address space of a typical subnet (64 bits of IID) makes a complete subnet ping sweep usually significantly harder and more expensive than with IPv4 [20] 🧚. Reducing the security threat of port scans on identified nodes requires sparse distribution within the subnet, so scans are less likely to find adjacent nodes 🌸. This scanning protection gets nullified if IIDs are configured in any structured groupings within the IID space 💀. As long as IIDs are essentially randomly distributed across the available space, address scanning-based attacks will effectively fail 🙌. This protection exists if the attacker has no direct access to the specific subnet and is trying to scan it remotely. If an attacker has local access, they could use Neighbor Discovery (ND) [3] and
ping6to the link-scope multicastff02::1to detect the IEEE-based address of local neighbors, then apply the global prefix to those to simplify the search 👀. (Of course, a locally connected attacker has many scanning options with IPv4 as well 🙄.)
Assuming the network administrator is aware of [20], the increased size of the IPv6 address makes topology probing much harder, and almost impossible for IPv6 devices 🏰. Topology probing is meant to identify a selection of the available hosts inside an enterprise, and it mostly starts with a ping sweep 🏓. Since IPv6 subnets are 64 bits worth of address space, an attacker would have to send out an unrealistic number of pings to map the network, and virus/worm propagation gets thwarted along the way 🦋. At full-rate full-duplex 40 Gbps (400 times the typical 100 Mbps LAN, and 13,000 times the typical DSL/cable access link), it takes over 5,000 years to scan the entirety of a single 64-bit subnet 🤯.
IPv4 NAT was not developed as a security mechanism. Despite marketing messages to the contrary, it is not a security mechanism 🙅♀️. That means it will offer some security holes while many people assume their network is secure just because of NAT. IPv6 security best practices will avoid this kind of illusory security, but they can only address the same threats if correctly configured firewalls and IDSs are used at the perimeter 🔥.
It must be noted that even a firewall doesn't fully secure a network. Many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows, etc. What a firewall does is prevent a network administration from having to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary 🧠💅.
To implement simple security for IPv6 in, for example, a DSL or cable modem-connected home network, the broadband gateway/router should be equipped with stateful firewall capabilities 🏠. These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state) 🪞. There should also be an easy interface that lets users create inbound 'pinholes' for specific purposes, such as online gaming 🎮.
Administrators and the designers of configuration interfaces for simple IPv6 firewalls need to provide a means of documenting the security caveats that come from a given set of configuration rules, so that users (who are normally oblivious to such things) can be made aware of the risks 📝. As rules get improved iteratively, the goal is to make the IPv6 Internet more secure without increasing the perceived complexity for users who just want to get a task done 💜.
4.3. User/Application Tracking 🕵️♀️
IPv6 enables the collection of information about data flows. Because all addresses used for Internet and intra-/inter-site communication are unique, it's possible for an enterprise or ISP to get very detailed information on any communication exchange between two or more devices 📊. Unless privacy addresses [7] are in use, this boosts 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 by the unique IPv6 source and destination addresses 🔍.
At the same time, this tracking is per address 📍. In environments where the goal is tracking back to the user, additional external information will be necessary to correlate a user with an address. With short-lifetime privacy address usage, that external information will need to be based on more stable information, such as the layer 2 media address 🫠✨.
4.4. Privacy and Topology Hiding Using IPv6 🎀
okay so bestie, IPv6 gives you partial host privacy 🦋 It uses RFC 3041 pseudo-random privacy addresses [7], which get generated whenever they're needed, so a session can use an address that only works for a limited time 💅 The catch is that this only lets someone trace a session back to the subnet that started it, not straight to the actual host. With IPv4 NAT, you can only trace things to the most public NAT interface, so IPv6 is giving more privacy in that sense ✨
The IPv6 address space is HUGE, so there's loads of room to randomize subnet allocations 🌈 When you do that, the link between a subnet and where it physically lives gets way weaker. If you randomize both the subnet and the interface ID, a casual snooper won't be able to figure out much about the network's topology 🙈 Getting one address tells them very little about the other addresses. This is different from IPv4, where the limited address space means that doesn't hold 💀 For most use cases, this is enough for address privacy and topology hiding, with the tradeoff being a more complex internal routing setup 🧚
As discussed in Section 3.1, an IPv6 address has multiple parts, and each part has different techniques for managing privacy. You can mix them together to protect the whole address 💜 Now say a network admin wants to fully isolate the internal IPv6 topology 👑 Most of the internal addresses are for internal use, so one option is to run all internal traffic on Unique Local Addresses (ULAs). By definition, this prefix block is not supposed to be advertised in the public routing system, so without a routing path, outside traffic will never reach the site 🫶 For the hosts that actually do need to talk to the outside world, using multiple IPv6 prefixes (ULAs plus one or more global addresses) means every internal node that doesn't need external connectivity, plus the internal addresses of the ones that do, stay hidden from the outside 🍓 The policy table defined in [11] can bias the selection process when there are multiple prefixes in use, so the ULA gets preferred when the correspondent is also local 🌸
There are other scenarios for the extreme case where a network manager also wants to completely conceal the internal IPv6 topology 😭 In these cases, the goal when replacing IPv4 NAT is to make all the topology-hidden nodes look like they logically sit at the edge of the network, just like they would behind a NAT 🫠 This figure shows how the logical subnets relate to the topology masking router, which the bullet points below talk about 👇
Internet
|
\
|
+------------------+
| topology |-+-+-+-+-+-+-+-+--
| masking | Logical subnets
| router |-+-+-+-+-+-+-+-+--
+------------------+ for topology
| hidden nodes
|
Real internal -------------+-
topology | |
| -+----------
-----------+--------+
|
|
|- One approach uses explicit host routes in the Interior Gateway Protocol (IGP) to cut the outside correlation between the physical attachment point and the end-to-end IPv6 address 🔥 In the figure above, the hosts would get prefixes from one or more logical subnets, and they'd inject host routes into the IGP to identify their real attachment point internally. BUT this solution has severe scalability issues, and it requires hosts to securely take part in the IGP, plus the firewall has to block all external-to-internal traceroutes for the logical subnet 💀 The specific limits depend on the IGP protocol, the physical topology, and how stable the system is. Either way, this should only be used where the number of routes is substantially fewer than the maximum the IGP can support (generally between 5,000 and 50,000 total entries, including subnet routes) 📉 Hosts should also listen to the IGP for duplicate use before finalizing an interface address assignment, because duplicate address detection only checks for use on the attached segment, not the logical subnet 👀
- Another technical approach to fully hide the internal topology is a tunneling mechanism 🚇 Mobile IPv6 without route optimization is one way to use an automated tunnel, since it always starts in tunnel mode via the Home Agent (HA) 🛸 In this deployment model, the application-perceived addresses of the nodes get routed through the edge HA, which acts as the topology masking router. This indirection truly masks the internal topology, because from outside the local network, every node with global access looks like it shares the prefix of one or more logical subnets attached to the HA, instead of its real attachment point 🥹 Note that here the HA is replacing the NAT function at the edge, so worries about extra latency from routing through a tunnel to the HA don't apply, since it's basically on the same path the NAT traffic would have taken ✨ Duplicate address detection is handled as a normal part of the HA binding update process 🎀 Turning off all binding updates with the correspondent node would seem necessary to stop topology information from leaking, BUT that would also force all internal traffic using the home address to route through the HA tunnel, which might not be desirable 🙅♀️ A more efficient method is to allow internal route optimizations while dropping outbound binding update messages at the firewall 💅 Another option for internal traffic is to use the policy table of RFC 3484 to bias a ULA prefix as preferred internally, leaving the logical subnet Home Address for external use 🦄 The downside of a Mobile IPv6-based solution is that it needs a Home Agent in the network, plus a security association with the HA for each hidden node, and it eats up some bandwidth for tunnel overhead 😩
- Another method (where the layer 2 topology allows it) uses a virtual LAN approach to logically attach the devices to one or more subnets on the edge router 🧃 This makes the end nodes believe they actually share a common segment. The downside is that all internal traffic gets directed over suboptimal paths via the edge router, and managing a distributed logical LAN is pretty complicated 🌀
One thing to be aware of: subnet-scope multicast won't work for the logical hidden subnets, except in the VLAN case ⚠️ Limited-scope multicast to a bunch of nodes scattered all over the place doesn't really make technical sense, so be careful not to deploy applications that expect limited-scope multicast alongside topology hiding 🙃
Another thing this document won't define is how a topology-hidden node learns its logical subnet 🤷♀️ Manual configuration would clearly be enough, BUT DHCP could be used for address assignment, with the node figuring out it's in hidden mode when the attached subnet prefix doesn't match the one it was assigned 🫧
4.5. Independent Control of Addressing in a Private Network 🏡
IPv6 gives you autonomy over local-use addresses through ULAs ✨ At the same time, IPv6 makes it easy to use multiple addresses per interface at once, so an IPv6 NAT isn't needed between the ULA and the public Internet, because nodes that need public Internet access will have a global-use address too 🫶 With IPv6, the need to ask for more address space becomes way less likely, thanks to the bigger subnets and an allocation policy that knows table fragmentation matters too 🧩 Global IPv6 allocation policy is managed through the Regional Internet Registries (RIRs), and they're expected to keep using derivatives of [8] for the foreseeable future, so the number of subnet prefixes available to an organization should not be a limitation that creates fake demand for NAT 🙌
Ongoing subnet maintenance can also get simpler with IPv6 🧹 Under IPv4 address space policy restrictions, every subnet has to be optimized, so you have to keep checking how many hosts are on a segment and how big its subnet is, then rebalance 😮💨 For example, an enterprise today might have a mix of IPv4 subnets from /28 - /23, and they may shrink or grow these as their user base changes 🎢 With IPv6, all subnets have /64 prefixes, which cuts down on the operational and configuration overhead 🥳
4.6. Global Address Pool Conservation 🌍
IPv6 has enough space to completely avoid the need for overlapping address space 💫 Since IPv6 allocations are based on subnets instead of hosts, a reasonable way to picture the pool is that there are about 17*10^18 unique subnet values 🤯 Sparse allocation practice within that space opens up new opportunities, like SEcure Neighbor Discovery (SEND) [15] ✨ As discussed before, the serious disadvantages of ambiguous address space are well documented, and with enough space there's no need to keep up the increasingly aggressive conservation practices that IPv4 requires 🙅♀️ IPv6 allocation policies and ISP business practices will keep evolving, but the recommendations in RFC 3177 are based on the technical potential of the huge IPv6 address space 💖 That document shows there's no resource limitation that would force the IPv4 workaround of ambiguous space behind a NAT 🫠 As a direct contrast, lots of expansion-oriented IPv6 deployment scenarios end up with multiple IPv6 addresses per device, whereas IPv4 scenarios are constricted, with multiple devices forced to share one scarce global address through a NAT 🥺🌟
4.7. Multihoming and Renumbering ✨
okay so IPv6 was literally built for this: sites and hosts can run with several CIDR-allocated prefixes at once, which means several ISPs at once 🌸 An address selection mechanism [11] is specified so hosts keep behaving consistently when several addresses are valid at the same time. That IPv4 headache with multiple addresses? Not a thing here 💅 IPv6 sites can and do run multiple active ISPs today, and the steps for adding, removing, and renumbering active prefixes at a site are written up in [16] and [21]. BUT ngl, multihoming and renumbering are still technically tricky even with IPv6, especially for session continuity across multihoming events or for how things interact with ingress filtering (see the Gap Analysis below) 🥺
The IPv6 address space the ISP hands out depends on whichever service provider you're connected to. So switching providers will most likely mean a renumbering effort 😭 When you change ISPs, or when ISPs readjust their addressing pools, DHCP-PD [12] can be used as an almost zero-touch external mechanism for prefix change. Pair it with a ULA prefix for internal connection stability and it's giving smooth 🫶 With the lifetime values managed properly and the external prefixes overlapping, you get a make-before-break transition: existing communications keep going on the old prefix for as long as it stays valid, while new communications use the new prefix. Iconic behaviour, honestly 🦋
5. Case Studies ✨
okay so for these case studies, we sorted networks into categories first by function: carrier/ISP networks, or end user networks (like enterprises). The end user side then gets broken down by how many end hosts are connected. For every category, IPv6 Local Network Protection gives you a secure and flexible setup, with better functionality than address translation 🔐🌈
- Medium/Large Private Networks (typically >10 connections)
- Small Private Networks (typically 1 to 10 connections)
- Single User Connection (typically 1 connection)
- ISP/Carrier Customer Networks
5.1. Medium/Large Private Networks ✨
this is giving enterprise, academic, research, and government networks 🏢 A lot of these have one or more exit points to the Internet. Now, these orgs have enough resources to get addressing independence with IPv4, but there are still a few reasons they might pick NAT anyway 🤷♀️ For the ISP, there's no need to import the IPv4 address range from the remote end customer, which makes IPv4 route summarization easier. The customer can use a bigger IPv4 address range (probably with less admin overhead) by using RFC 1918 and NAT. They also spend less effort switching to a new ISP, because the addresses on devices behind the NAT don't have to change when the customer gets a different address from a new ISP. With IPv4 address translation, you skip the expensive process of network renumbering 💸 And finally, the customer can give privacy to its hosts and hide the topology of its internal network if the internal addresses get mapped through NAT 🫣
It's expected that there will be enough IPv6 addresses for all networks and appliances for the foreseeable future 🌟 The basic IPv6 range an ISP gives a private network is currently /48, which is plenty for most medium and large enterprises. For really huge private networks, address ranges can be concatenated. The whole point of this assignment mechanism is to shrink the total number of entries in the public Internet routing table 🧠 A single /48 gives an enterprise network 65,536 different /64 subnet prefixes. Literally so many subnets 😭
To hide who a user is on this kind of network, IPv6 privacy extensions may be advised 🕵️♀️ This is useful when some outside element wants to track and collect everything sent to and from a certain host with a known IPv6 address. Privacy extensions add a random, time-limited factor to the host part of an IPv6 address, which makes it very hard for an external element to keep linking the IPv6 address to one specific host on the inside network 🎭 BUT the privacy extensions do not hide the internal structure of an enterprise network, so keep that in mind 🙈
When you need to hide the internal structure from the external IPv6 Internet, some form of 'untraceable' addresses may be used 🦋 These addresses look like they exist at the external edge of the network. They can be given to hosts that need topology masking, or to hosts that want to reach the IPv6 Internet or other external networks. The technology to assign them could be based on DHCPv6 or static configuration. To go with the 'Untraceable' addresses, you need at least awareness of where the IPv6 address is located when routing a packet through the internal network 🗺️ One way to get that is 'host based route-injection' in the local network infrastructure. This route-injection could be done with /128 host routes to each device that wants to connect to the Internet using an untraceable address. It gives the most dynamic masking, but there's a scalability limit: an IGP is typically not designed to carry many thousands of IPv6 prefixes, and a large enterprise may have thousands of hosts that want to connect to the Internet 📉
For larger deployments, an alternative is to use the tunneling aspect of MIPv6, even for non-mobile devices 🧚 With the logical subnet allocated as attached to the edge Home Agent, the real attachment and internal topology are masked from the outside. Dropping outbound binding updates at the firewall is also necessary, so the attachment information doesn't leak 🔒
A less flexible option is to have time-based IPv6 prefixes per link or subnet. This may cut the number of route entries in the IGP by a significant factor, but the trade-off is that masking is time and subnet based, which will complicate auditing systems 🧾 Dynamic allocation of 'Untraceable' addresses can also limit IPv6 access between local and external hosts to only those local hosts that are authorized for this capability 🚦
Using permanent ULA addresses on a site is a huge win: even if an enterprise changes its ISP, only the devices that want to connect beyond the site will be affected by the renumbering 🎀 Internal servers and services keep their allocated IPv6 ULA addresses, so the service stays available even during global address renumbering 💖
5.2. Small Private Networks ✨
also known as SOHO (Small Office/Home Office) networks 🏠 This category is for networks with only a few routers in the topology that usually have a single network egress point. These networks typically:
- are connected via either a dial-up connection or broadband access,
- don't have a dedicated Network Operation Center (NOC), and
- today, typically use NAT as the cheapest available solution for connectivity and address management
Usually the global IPv4 prefix they receive isn't fixed over time, and it's too long (very often a /32, giving just a single address) to give every node in the private network a unique, globally usable address 😩 Fixing either of those issues usually adds admin overhead for address management, which the user ends up dealing with. This category may even be limited to getting ambiguous IPv4 addresses from the service provider based on RFC 1918. ISPs typically pass along the higher admin cost of bigger address blocks, or of IPv4 prefixes that stay static over time, because each of those eats up a larger public address pool 💰
As a direct response to explicit charges per public address, most of this category has deployed NAPT (port demultiplexing NAT) to keep the number of addresses in use low 📦 Unfortunately, this also limits the equipment's Internet capability to mostly being a receiver of Internet data (a client), and it makes it pretty hard to run a worldwide Internet server (HTTP, FTP, etc.) because of the stateful operation of the NAT equipment 😵 Even with enough technical knowledge to manage the NAT for external access to a server, only one server can be mapped per protocol/port number per address, and only when the address from the ISP is publicly routed. If there's an upstream NAT providing private address space to the ISP side of the private NAT, you'll need extra negotiation with the ISP to set up an inbound mapping, if that's even possible 🫠
When deploying IPv6 LNP in this environment, there are two approaches possible for IPv6 addressing:
- DHCPv6 Prefix-Delegation (PD)
- ISP provides a static IPv6 address range
For the DHCPv6-PD solution, a dynamic address allocation approach is chosen 🪄 With the enhanced DHCPv6 protocol, the ISP can push an IPv6 prefix range down to the small private network automatically and populate all interfaces in that network dynamically. This cuts the admin burden way down, because everything happens automatically 🙌
For static configuration, the mechanisms could be the same as for medium/large enterprises. Typically, masking the topology isn't a high priority for these users, so IPv6 privacy extensions could be sufficient 🌷
For both alternatives, the ISP has unrestricted capability to summarize its RIR-allocated IPv6 prefix, while the small private network administrator has all the flexibility to use the received IPv6 prefix to their advantage, because it's big enough to give all local nodes a public address and the full range of ports whenever needed 👑
A full prefix is expected to be the primary deployment model, but 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 unrestricted availability of a large amount of globally routable and unique address space 🌍 If scarcity was the reason IPv4 used RFC 1918 addresses, that doesn't apply here: the ISP won't be motivated to give private addresses to a single user connection, since there are enough global addresses available at essentially the same cost. Also, the single device will likely want to mask its identity to the called party, or its attack profile, over a shorter time than the lifetime of the ISP attachment, so it will need to enable IPv6 privacy extensions 🥷 That in turn leads to the need for a minimum allocation of a /64 prefix rather than a single address 💜
5.3. Single User Connection 🎀
okay so this group is the people who connect to the internet through one IPv4 address on one device (a PC, a PDA, whatever 💻). their ISP usually hands them an ambiguous IPv4 address from the RFC 1918 range, and that's frequently imposed by the ISP, not picked by the user. if the address is ambiguous like that, the ISP runs NAT on it so the user can reach global internet 🌐. ngl that makes the device mostly a receiver of internet data, and it's super hard for it to become a worldwide server (HTTP, FTP, etc.) because NAT is stateful 🙈
with IPv6 LNP, this group is still the same crew: one single IPv6 address, one single piece of equipment (PC, PDA, etc.) 🦋
in the IPv6 world, the vibe is unrestricted availability of a huge amount of globally routable and unique IPv6 addresses 🌈 the ISP has no motivation to give a single user a private address, because the scarcity that pushed IPv4 into RFC 1918 addresses just isn't a thing here. if the single user wants to mask their identity, they may choose to enable IPv6 privacy extensions 🕶️ main character energy, fr
5.4. ISP/Carrier Customer Networks 💅
this group is the actual service providers doing the IP access and transport stuff. they tend to run three separate IP domains:
- For the first, they fall into the medium/large private networks category (above) for their own internal networks, LANs, etc.
- The second is the Operations address domain, which addresses their backbone and access switches, and other hardware. This address domain is separate from the other address domains for engineering reasons as well as simplicity in managing the security of the backbone.
- 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 IPv4 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 LNP is used in these three domains, the first category can use the same solutions as in Section 5.1 ✨ the second one, the Operations network, is a closed environment, so communication can be done based on ULAs 🔒 stable IPv6 Provider Independent addresses can also be used there, which gives a solid and scalable setup for a local IPv6 address plan. with proper network edge filters, outside access to the closed environment can be avoided 🚫
the third domain is the IPv6 addresses the ISP/carrier network assigns to customers. these will typically have prefix lengths ending on nibble boundaries so they match up with the DNS PTR records 🍓 since scarcity isn't a concern, the ISP can hand out globally routable IPv6 prefixes without any address translation. an ISP may still decide, for commercial reasons, to limit what end users can do with other tools like traffic and/or route filtering 💼
if the carrier network is a mobile provider, IPv6 is encouraged over the IPv4+NAT combo for Third Generation Partnership Project (3GPP)-attached devices 📱 in Section 2.3 of RFC 3314, 'Recommendations for IPv6 in 3GPP Standards' [9], the IPv6 WG recommends that one or more /64 prefixes be assigned to each primary Protocol Data Packet (PDP) context. that gives a 3GPP-attached node enough address space to allocate privacy addresses and/or route to a multi-link subnet, and it discourages NAT inside 3GPP-attached devices 🙌
6. IPv6 Gap Analysis 🔍
like IPv4 and any major standards effort, IPv6 standardization keeps going while deployments are happening 🚀 this section talks about a few topics that need more standardization, or documentation of best practice, to fully get the benefits or to optimize things when deploying LNP. from a standardization point of view, there's no blocker to immediate deployment of the LNP approach in many scenarios, though product implementations may lag behind the standards work 🐢 that said, the list below shows the extra work that should be undertaken to cover the missing scenarios.
6.1. Simple Security 🛡️
firewall traversal by dynamic pinhole management still needs further study 👀 there are a few partial solutions already, including Interactive Connectivity Establishment (ICE) [23] and Universal Plug and Play (UPNP) [24]. other approaches want to define service provider mediated pinhole management, where things like voice call signaling could dynamically open pinholes based on predefined authentication rules 📞 the basic security a stateful firewall gives will need some default configuration and automation to hide the technical complexity from a consumer who just wants a secure environment with working apps 🫶 and honestly, there's no reason a stateful IPv6 firewall product can't ship with default protection equal to or better than what today's IPv4/NAT products offer 🔥
6.2. Subnet Topology Masking 🙈
there's really no functional standards gap here, since a centrally assigned pool of addresses combined with host routes in the IGP is an effective way to mask topology for smaller deployments ✨ if needed, a best practice document could be written about how DHCP and the various IGPs interact, which would in effect define Untraceable Addresses 🧚
for larger deployments, there's also no gap in the HA tunneling approach when firewalls are set up to block outbound binding update messages 💜 a border Home Agent using internal tunneling to the logical mobile (potentially rack mounted) node can completely mask all internal topology, and it avoids the strain of a huge number of host routes in the IGP. some optimization work could happen in Mobile IP to define a policy message where a mobile node learns from the Home Agent that it shouldn't try to tell its correspondent about route optimization and expose its real location 🫣 this optimization reduces the load on the firewall, but internal traffic routing becomes less optimal because it would also transit the HA, unless ULAs were used internally 🤔 the trade-offs for this optimization work should be investigated in the IETF.
6.3. Minimal Traceability of Privacy Addresses 🕵️
privacy addresses [7] can definitely be used to limit how easily external traffic flows get traced back to specific hosts 🎭 but without a topology masking component on top, they'd still reveal the subnet address bits. for complete privacy, a best practice document describing how to combine privacy addresses and topology masking may be required 📝 that work is still to be done, and the IETF should pursue it.
6.4. Site Multihoming 🌐
this complex problem has never been fully solved for IPv4, which is exactly why NAT got used as a partial fix 😅 for IPv6, after several years of work, the IETF has converged on an architectural approach with service restoration as the initial aim [22] 💅 when this document was drafted, the IETF was actively defining the details of this multihoming approach. it seems most suitable for small and medium sites, though it will conflict with existing firewall state procedures ⚠️ there are also active talks in the address registries about assigning provider-independent address space, and their challenge is finding a reasonable metric for limiting how many organizations would qualify for a global routing entry 🤯 additional work seems necessary to satisfy the entire range of requirements.
7. Security Considerations 🔐
okay bestie, listen up, this part is serious 🥹 while issues that are potentially security related get discussed throughout the document, the approaches in here do not introduce any new security concerns. IPv4 NAT has been widely sold as a security tool, and suppliers have been building address translation into their firewalls 🧱 but the true impact of NATs on security has already been documented in [2] and [4], so go read those 📚
this document defines IPv6 approaches that together hit the goals of the network manager without the negative impact on applications or security that's inherent in a NAT approach 🎀 Section 6 identifies additional optimization work, and to the degree these techniques improve a network manager's ability to explicitly audit or control access (and so manage the overall attack exposure of local resources), they act to improve local network security 🛡️✨
8. Conclusion 🎉
this document has described a bunch of techniques that can be combined on an IPv6 site to protect the integrity of its network architecture 💖 these techniques, known collectively as Local Network Protection, keep a well-defined boundary between "inside" and "outside" the private network, and they allow firewalling, topology hiding, and privacy 🏰 because they preserve address transparency where it's needed, they get these goals done without the disadvantage of address translation 👑 so Local Network Protection in IPv6 can provide the benefits of IPv4 Network Address Translation without the corresponding disadvantages. iconic 😭
the document has also identified a few ongoing IETF work items that are needed to realize 100% of the benefits of LNP 🌸
9. Acknowledgements 🫶
Christian Huitema contributed during the initial round table to discuss the scope and goal of the document 🍵 and the European Union IST 6NET project acted as a catalyst for the work documented in this note 🇪🇺 editorial comments and contributions came in 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, Kurt Erik Lindqvist, Cullen Jennings, and other members of the v6ops WG and IESG 💜 thank you all, you're literally the best 🥰
10. Informative References ✨
okay so this is the bibliography bit, bestie 📚 every doc the spec leans on is listed here, numbered [1] through [24] so you can follow the trail. ngl the list is a whole vibe 💅
- [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. ✨
- [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] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. 🌈
- [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 🎀
- [11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. 👑
- [12] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 🔥
- [13] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. ⭐
- [14] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. 🦋
- [15] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 💅
- [16] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. 🌸
- [17] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. 💖
- [18] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. 🧚
- [19] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", Work in Progress, June 2004. 🙈
- [20] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", Work in Progress, October 2005. 👀
- [21] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006. 🧠
- [22] Huston, G., "Architectural Commentary on Site Multi-homing using a Level 3 Shim", Work in Progress, July 2005. 🌙
- [23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2006. 🫧
- [24] "Universal Plug and Play Web Site", July 2005, <http://www.upnp.org/>. 🔌
Appendix A. Additional Benefits Due to Native IPv6 and Universal Unique Addressing 🌟
okay bestie, this appendix is the glow-up tour ✨ native IPv6 and globally unique addresses let users tap into the enhanced IPv6 capabilities, on top of everything IPv4 already gives you 💖
A.1. Universal Any-to-Any Connectivity 🌍
any-to-any connectivity was one of the original design points of the Internet, and it's giving main character energy 👑 the huge growth of internet-connected systems plus the limited IPv4 address space birthed address conservation techniques. NAT came in to ease pressure on the IPv4 address pool, but its side effect was removing any-to-any connectivity. 💀 IPv6 fixes that by removing the need for address conservation (and therefore NAT), so the any-to-any model comes back and app developers are free from those limits 🫶
with no NAT traversal headaches, devs can focus on new advanced network services, like peer-to-peer applications, IPv6-embedded IPsec communication between two communicating devices, instant messaging, Internet telephony, and so on, instead of hunting for ways around an increasingly complex NAT environment 🦋
it also lets app and service devs rethink the security model for any-to-any connectivity, because the current edge firewall solution in IPv4 may not be enough for any-to-any service models 🔒
A.2. Auto-Configuration 🪄
IPv6 gives you a scalable way to cut down on human interaction and device configuration, bestie 🎀 in IPv4, you have to touch each end system to choose DHCP versus a static address, and manage a server with a pool big enough for every connected device 😭
with IPv6, the router can send an indication telling end systems to use DHCP or the stateless auto-configuration approach, which supports a virtually limitless number of devices on the subnet ✨ fewer systems need human touch, and everything on a subnet ends up more consistent 💅 and if there's no router to send that indication, an address for use only on the local link gets derived from the interface media layer address 🧚
A.3. Native Multicast Services 📡
multicast in IPv4 was seriously restricted by the small address space for group assignments and an implicit, locally defined range for group membership 🙃 IPv6 multicast fixes this with explicit scope indications and by expanding to 4 billion groups per scope 🌈 for source-specific multicast, it goes even further, to 4 billion groups per scope per subnet, by embedding the 64 bits of subnet identifier into the multicast address 🤯
IPv6 also gets creative with its address length, making it possible to embed the multicast Rendezvous Point (RP) [14] directly in the IPv6 multicast address when using Any-Source Multicast (ASM) 🫧 that just isn't possible with IPv4's limited address size, and it makes the multicast model way simpler to understand and deploy 💖
A.4. Increased Security Protection 🛡️
the security protection native IPv6 offers is more advanced than IPv4's, and there are various transport mechanisms that were enhanced so a network can run more securely with less performance impact 🔥
- IPv6 has IPsec built directly into the protocol 🔐 this allows simpler peer-to-peer authentication and encryption, once a simple key/trust management model is developed, and it means some less secure mechanisms (like MD5 password hash for neighbor authentication) can be avoided 🙅♀️
- a firewall is designed to disallow applications based on local policy, and it doesn't interfere with the ones that are allowed ✅ that's a security upgrade over NAT, where the workarounds that enable locally allowed applications are effectively architected man-in-the-middle attacks on the packets, which rules out end-to-end auditing or IP level identification 🕵️♀️
- all flows on the Internet are going to be more traceable thanks to a unique and globally routable source and destination IPv6 address 🔍 this may make it easier to back-trace Denial of Service (DoS) attacks and avoid illegal access to network resources through simpler traffic filtering 🚫
- private address space in IPv6 is now provided by Unique Local Addresses, which avoid conflicts when merging networks and help secure internal communication on a local network infrastructure, thanks to simpler traffic filtering policy 🏰
- source-routing on a network infrastructure has been enhanced so the feature works without hurting the processing power of intermediate network devices 🧭 the only devices affected are the source and destination nodes and the intermediate source-routed nodes 🙌 with IPv4, it's different, because every intermediate device would have had to look into the source route header 😵💫
A.5. Mobility 🚶♀️
anytime, anywhere, universal access needs MIPv6 services to support mobile nodes 🌏 a Home Agent is required for initial connection establishment in either protocol version, but IPv6 mobile nodes can optimize the path between them using the MIPv6 option header, while IPv4 mobile nodes have to triangle route all packets 🔺 generally speaking, that minimizes the network resources used and maximizes the quality of the communication 🚀
A.6. Merging Networks 🤝
when two IPv4 networks want to merge, there's no guarantee that both networks use different address ranges on some parts of the network infrastructure, because of RFC 1918 private addressing 😬 that overlap can make merging two or more networks dramatically more complicated, since the IPv4 renumbering effort adds up, for example when the first network runs a service (NTP, DNS, DHCP, HTTP, etc.) that the second network needs to access. similar address conflicts can happen when two network devices from the merging networks want to talk to each other 📵
with IPv6, the addressing overlap won't exist, because Unique Local Addresses are used for private and local addressing 💜
Authors' Addresses 💌
the people behind the spec, with where to find them:
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
8 Chemin de Blandonnet
1214 Vernier,
CH
EMail: brc@zurich.ibm.com
Eric Klein
Tel Aviv University
Tel Aviv,
Israel
EMail: ericlklein.ipv6@gmail.comFull Copyright Statement 🎀
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property ✨
okay so the IETF is basically saying "we're not picking a side" 💅 It takes no position on whether any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology in this document are valid or in scope. It also doesn't say whether any license under those rights might or might not be available, and it doesn't claim it has made any independent effort to find such rights 🙈 If you want the procedures for rights in RFC documents, go check out BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat are available, along with any assurances of licenses to be made available. The same goes for the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights. You can find all of that in 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. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶💜
📦 where this page comes from
- ietf: rfc4864 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms