diff options
Diffstat (limited to 'doc/rfc/rfc5902.txt')
| -rw-r--r-- | doc/rfc/rfc5902.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5902.txt b/doc/rfc/rfc5902.txt new file mode 100644 index 0000000..d5e3a6c --- /dev/null +++ b/doc/rfc/rfc5902.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Architecture Board (IAB) D. Thaler +Request for Comments: 5902 L. Zhang +Category: Informational G. Lebovitz +ISSN: 2070-1721 July 2010 + + + IAB Thoughts on IPv6 Network Address Translation + +Abstract + + There has been much recent discussion on the topic of whether the + IETF should develop standards for IPv6 Network Address Translators + (NATs). This document articulates the architectural issues raised by + IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the + IAB's thoughts on the current open issues and the solution space. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. Documents approved for publication by + the IAB are not a candidate for any level of Internet Standard; see + Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5902. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + +Thaler, et al. Informational [Page 1] + +RFC 5902 IPv6 NAT Considerations July 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. What is the problem? . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . . . 3 + 2.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 4 + 2.3. Homogenous Edge Network Configurations . . . . . . . . . . 4 + 2.4. Network Obfuscation . . . . . . . . . . . . . . . . . . . 5 + 2.4.1. Hiding Hosts . . . . . . . . . . . . . . . . . . . . . 5 + 2.4.2. Topology Hiding . . . . . . . . . . . . . . . . . . . 8 + 2.4.3. Summary Regarding NAT as a Tool for Network + Obfuscation . . . . . . . . . . . . . . . . . . . . . 8 + 2.5. Simple Security . . . . . . . . . . . . . . . . . . . . . 9 + 2.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3. Architectural Considerations of IPv6 NAT . . . . . . . . . . . 9 + 4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6. IAB Members at the Time of Approval . . . . . . . . . . . . . 13 + 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + In the past, the IAB has published a number of documents relating to + Internet transparency and the end-to-end principle, and other IETF + documents have also touched on these issues as well. These documents + articulate the general principles on which the Internet architecture + is based, as well as the core values that the Internet community + seeks to protect going forward. Most recently, RFC 4924 [RFC4924] + reaffirms these principles and provides a review of the various + documents in this area. + + Facing imminent IPv4 address space exhaustion, recently there have + been increased efforts in IPv6 deployment. However, since late 2008 + there have also been increased discussions about whether the IETF + should standardize network address translation within IPv6. People + who are against standardizing IPv6 NAT argue that there is no + fundamental need for IPv6 NAT, and that as IPv6 continues to roll + out, the Internet should converge towards reinstallation of the end- + to-end reachability that has been a key factor in the Internet's + success. On the other hand, people who are for IPv6 NAT believe that + NAT vendors would provide IPv6 NAT implementations anyway as NAT can + be a solution to a number of problems, and that the IETF should avoid + repeating the same mistake as with IPv4 NAT, where the lack of + protocol standards led to different IPv4 NAT implementations, making + NAT traversal difficult. + + + + + +Thaler, et al. Informational [Page 2] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + An earlier effort, [RFC4864], provides a discussion of the real or + perceived benefits of NAT and suggests alternatives for most of them, + with the intent of showing that NAT is not required to get the + desired benefits. However, it also identifies several gaps remaining + to be filled. + + This document provides the IAB's current thoughts on this debate. We + believe that the issue at hand must be viewed from an overall + architectural standpoint in order to fully assess the pros and cons + of IPv6 NAT on the global Internet and its future development. + +2. What is the problem? + + The discussions on the desire for IPv6 NAT can be summarized as + follows. Network address translation is viewed as a solution to + achieve a number of desired properties for individual networks: + avoiding renumbering, facilitating multihoming, making configurations + homogenous, hiding internal network details, and providing simple + security. + +2.1. Avoiding Renumbering + + As discussed in [RFC4864], Section 2.5, the ability to change service + providers with minimal operational difficulty is an important + requirement in many networks. However, renumbering is still quite + painful today, as discussed in [RFC5887]. Currently it requires + reconfiguring devices that deal with IP addresses or prefixes, + including DNS servers, DHCP servers, firewalls, IPsec policies, and + potentially many other systems such as intrusion detection systems, + inventory management systems, patch management systems, etc. + + In practice today, renumbering does not seem to be a significant + problem in consumer networks, such as home networks, where addresses + or prefixes are typically obtained through DHCP and are rarely + manually configured in any component. However, in managed networks, + renumbering can be a serious problem. + + We also note that many, if not most, large enterprise networks avoid + the renumbering problem by using provider-independent (PI) IP address + blocks. The use of PI addresses is inherent in today's Internet + operations. However, in smaller managed networks that cannot get + provider-independent IP address blocks, renumbering remains a serious + issue. Regional Internet Registries (RIRs) constantly receive + requests for PI address blocks; one main reason that they hesitate in + assigning PI address blocks to all users is the concern about the PI + addresses' impact on the routing system scalability. + + + + + +Thaler, et al. Informational [Page 3] + +RFC 5902 IPv6 NAT Considerations July 2010 + + +2.2. Site Multihoming + + Another important requirement in many networks is site multihoming. + A multihomed site essentially requires that its IP prefixes be + present in the global routing table to achieve the desired + reliability in its Internet connectivity as well as load balancing. + In today's practice, multihomed sites with PI addresses announce + their PI prefixes to the global routing system; multihomed sites with + provider-allocated (PA) addresses also announce the PA prefix they + obtained from one service provider to the global routing system + through another service provider, effectively disabling provider- + based prefix aggregation. This practice makes the global routing + table scale linearly with the number of multihomed user networks. + + This issue was identified in [RFC4864], Section 6.4. Unfortunately, + no solution except NAT has been deployed today that can insulate the + global routing system from the growing number of multihomed sites, + where a multihomed site simply assigns multiple IPv4 addresses (one + from each of its service providers) to its exit router, which is an + IPv4 NAT box. Using address translation to facilitate multihoming + support has one unique advantage: there is no impact on the routing + system scalability, as the NAT box simply takes one address from each + service provider, and the multihomed site does not inject its own + routes into the system. Intuitively, it also seems straightforward + to roll the same solution into multihoming support in the IPv6 + deployment. However, one should keep in mind that this approach + brings all the drawbacks of putting a site behind a NAT box, + including the loss of reachability to the servers behind the NAT box. + + It is also important to point out that a multihomed site announcing + its own prefix(es) achieves two important benefits that NAT-based + multihoming support does not provide. First, end-to-end + communications can be preserved in face of connectivity failures of + individual service providers, as long as the site remains connected + through at least one operational service provider. Second, + announcing one's prefixes also gives a multihomed site the ability to + perform traffic engineering and load balancing. + +2.3. Homogenous Edge Network Configurations + + Service providers supporting residential customers need to minimize + support costs (e.g., help desk calls). Often a key factor in + minimizing support costs is ensuring customers have homogenous + configurations, including the addressing architecture. Today, when + IPv4 NATs are provided by a service provider, all customers get the + same address space on their home networks, and hence the home gateway + + + + + +Thaler, et al. Informational [Page 4] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + always has the same address. From a customer-support perspective, + this perhaps represents the most important property of NAT usage + today. + + In IPv6, link-local addresses can be used to ensure that all home + gateways have the same address, and to provide homogenous addresses + to any other devices supported by the service provider. Unlike IPv4, + having a globally unique address does not prevent the use of a + homogenous address within the subnet. It is only in the case of + multi-subnet customers that IPv6 NAT would provide some homogeneity + that wouldn't be provided by link-local addresses. For multi-subnet + customers (e.g., a customer using a wireless access point behind the + service provider router/modem), service providers today might only + discuss problems (for IPv4 or IPv6) from computers connected directly + to the service provider router. + + It is currently unknown whether IPv6 link-local addresses provide + sufficient homogeneity to minimize help desk calls. If they do not, + providers might still desire IPv6 NATs in the residential gateways + they provide. + +2.4. Network Obfuscation + + Most network administrators want to hide the details of the computing + resources, information infrastructure, and communications networks + within their borders. This desire is rooted in the basic security + principle that an organization's assets are for its sole use and all + information about those assets, their operation, and the methods and + tactics of their use are proprietary secrets. Some organizations use + their information and communication technologies as a competitive + advantage in their industries. It is a generally held belief that + measures must be taken to protect those secrets. The first layer of + protection of those secrets is preventing access to the secrets or + knowledge about the secrets whenever possible. It is understandable + why network administrators would want to keep the details about the + hosts on their network, as well as the network infrastructure itself, + private. They believe that NAT helps achieve this goal. + +2.4.1. Hiding Hosts + + As a specific measure of network obfuscation, network administrators + wish to keep secret any and all information about the computer + systems residing within their network boundaries. Such computer + systems include workstations, laptops, servers, function-specific + end-points (e.g., printers, scanners, IP telephones, point-of-sale + machines, building door access-control devices), and such. They want + to prevent an external entity from counting the number of hosts on + the network. They also want to prevent host fingerprinting, i.e., + + + +Thaler, et al. Informational [Page 5] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + gaining information about the constitution, contents, or function of + a host. For example, they want to hide the role of a host, as + whether it is a user workstation, a finance server, a source code + build server, or a printer. A second element of host-fingerprinting + prevention is to hide details that could aid an attacker in + compromising the host. Such details might include the type of + operating system, its version number, any patches it may or may not + have, the make and model of the device hardware, any application + software packages loaded, those version numbers and patches, and so + on. With such information about hosts, an attacker can launch a more + focused, targeted attack. Operators want to stop both host counting + and host fingerprinting. + + Where host counting is a concern, it is worth pointing out some of + the challenges in preventing it. [Bellovin] showed how one can + successfully count the number of hosts behind a certain type of + simple NAT box. More complex NAT deployments, e.g., ones employing + Network Address Port Translators (NAPTs) with a pool of public + addresses that are randomly bound to internal hosts dynamically upon + receipt of any new connection, and do so without persistency across + connections from the same host are more successful in preventing host + counting. However, the more complex the NAT deployment, the less + likely that complex connection types like the Session Initiation + Protocol (SIP) [RFC3261] and the Stream Control Transmission Protocol + (SCTP) [RFC4960] will be able to successfully traverse the NAT. This + observation follows the age-old axiom for networked computer systems: + for every unit of security you gain, you give up a unit of + convenience, and for every unit of convenience you hope to gain, you + must give up a unit of security. + + If fields such as fragment ID, TCP initial sequence number, or + ephemeral port number are chosen in a predictable fashion (e.g., + sequentially), then an attacker may correlate packets or connections + coming from the same host. + + To prevent counting hosts by counting addresses, one might be tempted + to use a separate IP address for each transport-layer connection. + Such an approach introduces other architectural problems, however. + Within the host's subnet, various devices including switches, + routers, and even the host's own hardware interface often have a + limited amount of state available before causing communication that + uses a large number of addresses to suffer significant performance + problems. In addition, if an attacker can somehow determine an + average number of connections per host, the attacker can still + estimate the number of hosts based on the number of connections + observed. Hence, such an approach can adversely affect legitimate + communication at all times, simply to raise the bar for an attacker. + + + + +Thaler, et al. Informational [Page 6] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + Where host fingerprinting is concerned, even a complex NAT cannot + prevent fingerprinting completely. The way that different hosts + respond to different requests and sequences of events will indicate + consistently the type of a host that it is, its OS, version number, + and sometimes applications installed, etc. Products exist that do + this for network administrators as a service, as part of a + vulnerability assessment. + + These scanning tools initiate connections of various types across a + range of possible IP addresses reachable through that network. They + observe what returns, and then send follow-up messages accordingly + until they "fingerprint" the host thoroughly. When run as part of a + network assessment process, these tools are normally run from the + inside of the network, behind the NAT. If such a tool is set outside + a network boundary (as part of an external vulnerability assessment + or penetration test) along the path of packets, and is passively + observing and recording connection exchanges, over time it can + fingerprint hosts only if it has a means of determining which + externally viewed connections are originating from the same internal + host. If the NATing is simple and static, and each host's internal + address is always mapped to the same external address and vice versa, + the tool has 100% success fingerprinting the host. With the internal + hosts mapped to their external IP addresses and fingerprinted, the + attacker can launch targeted attacks into those hosts, or reliably + attempt to hijack those hosts' connections. If the NAT uses a single + external IP, or a pool of dynamically assigned IP addresses for each + host, but does so in a deterministic and predictable way, then the + operation of fingerprinting is more complex, but quite achievable. + + If the NAT uses dynamically assigned addresses, with short-term + persistency, but no externally learnable determinism, then the + problem gets harder for the attacker. The observer may be able to + fingerprint a host during the lifetime of a particular IP address + mapping, and across connections, but once that IP mapping is + terminated, the observer doesn't immediately know which new mapping + will be that same host. After much observation and correlation, the + attacker could sometimes determine if an observed new connection in + flight is from a familiar host. With that information, and a good + set of man-in-the-middle attack tools, the attacker could attempt to + compromise the host by hijacking a new connection of adequately long + duration. If temporal persistency is not deployed on the NAT, then + this tactic becomes almost impossible. As the difficulty and cost of + the attack increases, the number of attackers attempting to employ it + decreases. And certainly the attacker would not be able to initiate + a connection toward a host for which the attacker does not know the + current IP address binding. So, the attacker is limited to hijacking + observed connections thought to be from a familiar host, or to + blindly initiating attacks on connections in flight. This is why + + + +Thaler, et al. Informational [Page 7] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + network administrators appreciate complex NATs' ability to deter host + counting and fingerprinting, but such deterrence comes at a cost of + host reachability. + +2.4.2. Topology Hiding + + It is perceived that a network operator may want to hide the details + of the network topology, the size of the network, the identities of + the internal routers, and the interconnection among the routers. + This desire has been discussed in [RFC4864], Sections 4.4 and 6.2. + + However, the success of topology hiding is dependent upon the + complexity, dynamism, and pervasiveness of bindings the NAT employs + (all of which were described above). The more complex, the more the + topology will be hidden, but the less likely that complex connection + types will successfully traverse the NAT barrier. Thus, the trade- + off is reachability across applications. + + Even if one can hide the actual addresses of internal hosts through + address translation, this does not necessarily prove sufficient to + hide internal topology. It may be possible to infer some aspects of + topological information from passively observing packets. For + example, based on packet timing, delay measurements, the Hop Limit + field, or other fields in the packet header, one could infer the + relative distance between multiple hosts. Once an observed session + is believed to match a previously fingerprinted host, that host's + distance from the NAT device may be learned, but not its exact + location or particular internal subnet. + + Host fingerprinting is required in order to do a thorough distance + mapping. An attacker might then use message contents to lump certain + types of devices into logical clusters, and take educated guesses at + attacks. This is not, however, a thorough mapping. Some NATs change + the TTL hop counts, much like an application-layer proxy would, while + others don't; this is an administrative setting on more advanced + NATs. The simpler and more static the NAT, the more possible this + is. The more complex and dynamic and non-persistent the NAT + bindings, the more difficult. + +2.4.3. Summary Regarding NAT as a Tool for Network Obfuscation + + The degree of obfuscation a NAT can achieve will be a function of its + complexity as measured by: + + o The use of one-to-many NAPT mappings; + + + + + + +Thaler, et al. Informational [Page 8] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + o The randomness over time of the mappings from internal to external + IP addresses, i.e., non-deterministic mappings from an outsider's + perspective; + + o The lack of persistence of mappings, i.e., the shortness of + mapping lifetimes and not using the same mapping repeatedly; + + o The use of re-writing in IP header fields such as TTL. + + However, deployers be warned: as obfuscation increases, host + reachability decreases. Mechanisms such as STUN [RFC5389] and Teredo + [RFC4380] fail with the more complex NAT mechanisms. + +2.5. Simple Security + + It is commonly perceived that a NAT box provides one level of + protection because external hosts cannot directly initiate + communication with hosts behind a NAT. However, one should not + confuse NAT boxes with firewalls. As discussed in [RFC4864], Section + 2.2, the act of translation does not provide security in itself. The + stateful filtering function can provide the same level of protection + without requiring a translation function. For further discussion, + see [RFC4864], Section 4.2. + +2.6. Discussion + + At present, the primary benefits one may receive from deploying NAT + appear to be avoiding renumbering, facilitating multihoming without + impacting routing scalability, and making edge consumer network + configurations homogenous. + + Network obfuscation (host hiding, both counting and fingerprinting + prevention, and topology hiding) may well be achieved with more + complex NATs, but at the cost of losing some reachability and + application success. Again, when it comes to security, this is often + the case: to gain security one must give up some measure of + convenience. + +3. Architectural Considerations of IPv6 NAT + + First, it is important to distinguish between the effects of a NAT + box vs. the effects of a firewall. A firewall is intended to prevent + unwanted traffic [RFC4948] without impacting wanted traffic, whereas + a NAT box also interferes with wanted traffic. In the remainder of + this section, the term "reachability" is used with respect to wanted + traffic. + + + + + +Thaler, et al. Informational [Page 9] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + The discussions on IPv6 NAT often refer to the wide deployment of + IPv4 NAT, where people have both identified tangible benefits and + gained operational experience. However, the discussions so far seem + mostly focused on the potential benefits that IPv6 NAT may, or may + not, bring. Little attention has been paid to the bigger picture, as + we elaborate below. + + When considering the benefits that IPv6 NAT may bring to a site that + deploys it, we must not overlook a bigger question: if one site + deploys IPv6 NAT, what is the potential impact it brings to the rest + of the Internet that does not do IPv6 NAT? By "the rest of the + Internet", we mean the Internet community that develops, deploys, and + uses end-to-end applications and protocols and hence is affected by + any loss of transparency (see [RFC2993] and [RFC4924] for further + discussion). This important question does not seem to have been + addressed, or addressed adequately. + + We believe that the discussions on IPv6 NAT should be put in the + context of the overall Internet architecture. The foremost question + is not how many benefits one may derive from using IPv6 NAT, but more + fundamentally, whether a significant portion of parties on the + Internet are willing to deploy IPv6 NAT, and hence whether we want to + make IP address translation a permanent building block in the + Internet architecture. + + One may argue that the answers to the above questions depend on + whether we can find adequate solutions to the renumbering, site + multihoming, and edge network configuration problems, and whether the + solutions provide transparency or not. If transparency is not + provided, making NAT a permanent building block in the Internet would + represent a fundamental architectural change. + + It is desirable that IPv6 users and applications be able to reach + each other directly without having to worry about address translation + boxes between the two ends. IPv6 application developers in general + should be able to program based on the assumption of end-to-end + reachability (of wanted traffic), without having to address the issue + of traversing NAT boxes. For example, referrals and multi-party + conversations are straightforward with end-to-end addressing, but + vastly complicated in the presence of address translation. + Similarly, network administrators should be able to run their + networks without the added complexity of NATs, which can bring not + only the cost of additional boxes, but also increased difficulties in + network monitoring and problem debugging. + + + + + + + +Thaler, et al. Informational [Page 10] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + Given the diversity of the Internet user populations and the + diversity in today's operational practice, it is conceivable that + some parties may have a strong desire to deploy IPv6 NAT, and the + Internet should accommodate different views that lead to different + practices (i.e., some using IPv6 NAT, others not). + + If we accept the view that some, but not all, parties want IPv6 NAT, + then the real debate should not be on what benefits IPv6 NAT may + bring to the parties who deploy it. It is undeniable that network + address translation can bring certain benefits to its users. + However, the real challenge we should address is how to design IPv6 + NAT in such a way that it can hide its impact within some localized + scope. If IPv6 NAT design can achieve this goal, then the Internet + as a whole can strive for (reinstalling) the end-to-end reachability + model. + +4. Solution Space + + From an end-to-end perspective, the solution space for renumbering + and multihoming can be broadly divided into three classes: + + + 1. Endpoints get a stable, globally reachable address: In this class + of solutions, end sites use provider-independent addressing and + hence endpoints are unaffected by changing service providers. + For this to be a complete solution, provider-independent + addressing must be available to all managed networks (i.e., all + networks that use manual configuration of addresses or prefixes + in any type of system). However, in today's practice, assigning + provider-independent addresses to all networks, including small + ones, raises concerns with the scalability of the global routing + system. This is an area of ongoing research and experimentation. + In practice, network administrators have also been developing + short-term approaches to resolve today's gap between the + continued routing table growth and limitations in existing router + capacity [NANOG]. + + 2. Endpoints get a stable but non-globally-routable address on + physical interfaces but a dynamic, globally routable address + inside a tunnel: In this class of solutions, hosts use locally- + scoped (and hence provider-independent) addresses for + communication within the site using their physical interfaces. + As a result, managed systems such as routers, DHCP servers, etc., + all see stable addresses. Tunneling from the host to some + infrastructure device is then used to communicate externally. + Tunneling provides the host with globally routable addresses that + may change, but address changes are constrained to systems that + operate over or beyond the tunnel, including DNS servers and + + + +Thaler, et al. Informational [Page 11] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + applications. These systems, however, are the ones that often + can already deal with changes today using mechanisms such as DNS + dynamic update. However, if endpoints and the tunnel + infrastructure devices are owned by different organizations, then + solutions are harder to incrementally deploy due to the incentive + and coordination issues involved. + + 3. Endpoints get a stable address that gets translated in the + network: In this class of solutions, end sites use non-globally- + routable addresses within the site, and translate them to + globally routable addresses somewhere in the network. In + general, this causes the loss of end-to-end transparency, which + is the subject of [RFC4924] and the documents it surveys. If the + translation is reversible, and the translation is indeed reversed + by the time it reaches the other end of communication, then end- + to-end transparency can be provided. However, if the two + translators involved are owned by different organizations, then + solutions are harder to incrementally deploy due to the incentive + and coordination issues involved. + + Concerning routing scalability, although there is no immediate + danger, routing scalability has been a longtime concern in + operational communities, and an effective and deployable solution + must be found. We observe that the question at hand is not about + whether some parties can run NAT, but rather, whether the Internet as + a whole would be willing to rely on NAT to curtail the routing + scalability problem, and whether we have investigated all the + potential impacts of doing so to understand its cost on the overall + architecture. If effective solutions can be deployed in time to + allow assigning provider-independent IPv6 addresses to all user + communities, the Internet can avoid the complexity and fragility and + other unforeseen problems introduced by NAT. + +4.1. Discussion + + As [RFC4924] states: + + A network that does not filter or transform the data that it + carries may be said to be "transparent" or "oblivious" to the + content of packets. Networks that provide oblivious transport + enable the deployment of new services without requiring changes to + the core. It is this flexibility that is perhaps both the + Internet's most essential characteristic as well as one of the + most important contributors to its success. + + We believe that providing end-to-end transparency, as defined above, + is key to the success of the Internet. While some fields of traffic + (e.g., Hop Limit) are defined to be mutable, transparency requires + + + +Thaler, et al. Informational [Page 12] + +RFC 5902 IPv6 NAT Considerations July 2010 + + + that fields not defined as such arrive un-transformed. Currently, + the source and destination addresses are defined as immutable fields, + and are used as such by many protocols and applications. + + Each of the three classes of solution can be defined in a way that + preserves end-to-end transparency. + + While we do not consider IPv6 NATs to be desirable, we understand + that some deployment of them is likely unless workable solutions to + avoiding renumbering, facilitating multihoming without adversely + impacting routing scalability, and homogeneity are generally + recognized as useful and appropriate. + + As such, we strongly encourage the community to consider end-to-end + transparency as a requirement when proposing any solution, whether it + be based on tunneling or translation or some other technique. + Solutions can then be compared based on other aspects such as + scalability and ease of deployment. + +5. Security Considerations + + Section 2 discusses potential privacy concerns as part of the Host + Counting and Topology Hiding problems. + +6. IAB Members at the Time of Approval + + Marcelo Bagnulo + Gonzalo Camarillo + Stuart Cheshire + Vijay Gill + Russ Housley + John Klensin + Olaf Kolkman + Gregory Lebovitz + Andrew Malis + Danny McPherson + David Oran + Jon Peterson + Dave Thaler + + + + + + + + + + + + +Thaler, et al. Informational [Page 13] + +RFC 5902 IPv6 NAT Considerations July 2010 + + +7. Informative References + + [Bellovin] Bellovin, S., "A Technique for Counting NATted Hosts", + Proc. Second Internet Measurement Workshop, + November 2002, + <http://www.cs.columbia.edu/~smb/papers/fnat.pdf>. + + [NANOG] "Extending the Life of Layer 3 Switches in a 256k+ Route + World", NANOG 44, October 2008, <http://www.nanog.org/ + meetings/nanog44/presentations/Monday/ + Roisman_lightning.pdf>. + + [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, + November 2000. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + February 2006. + + [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and + E. Klein, "Local Network Protection for IPv6", RFC 4864, + May 2007. + + [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet + Transparency", RFC 4924, July 2007. + + [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the + IAB workshop on Unwanted Traffic March 9-10, 2006", + RFC 4948, August 2007. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008. + + [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering + Still Needs Work", RFC 5887, May 2010. + + + + + + + +Thaler, et al. Informational [Page 14] + +RFC 5902 IPv6 NAT Considerations July 2010 + + +Authors' Addresses + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + + Lixia Zhang + UCLA Computer Science Department + 3713 Boelter Hall + Los Angeles, CA 90095 + USA + + Phone: +1 310 825 2695 + EMail: lixia@cs.ucla.edu + + + Gregory Lebovitz + Juniper Networks, Inc. + 1194 North Mathilda Ave. + Sunnyvale, CA 94089 + USA + + EMail: gregory.ietf@gmail.com + + + Internet Architecture Board + + EMail: iab@iab.org + + + + + + + + + + + + + + + + + +Thaler, et al. Informational [Page 15] + |