Network Working Group D. Thaler
Internet-Draft Microsoft
Intended status: Informational L. Zhang
Expires: September 5, 2009 UCLA
March 4, 2009
IAB Thoughts on IPv6 Network Address Translation
draft-iab-ipv6-nat-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
There has been much recent discussion on the topic of whether the
IETF should develop standards for IPv6 Network Address Translators
Thaler & Zhang Expires September 5, 2009 [Page 1]
Internet-Draft IPv6 NAT Considerations March 2009
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is the Problem? . . . . . . . . . . . . . . . . . . . . . 3
2.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . . . 4
2.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 4
2.3. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 5
2.4. Preventing Host Counting . . . . . . . . . . . . . . . . . 5
2.5. Simple Security . . . . . . . . . . . . . . . . . . . . . 6
2.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Considerations of IPv6 NAT . . . . . . . . . . . 6
4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Thaler & Zhang Expires September 5, 2009 [Page 2]
Internet-Draft IPv6 NAT Considerations March 2009
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 last
year 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 which 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 with IPv4 NAT, where the lack of protocol
standards led to different IPv4 implementations, making NAT traversal
difficult.
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 in hand must be viewed from the overall
architecture 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 necessity 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, internal topology
hiding, and in particular preventing host counting. We discuss below
each of these perceived benefits from NAT.
Thaler & Zhang Expires September 5, 2009 [Page 3]
Internet-Draft IPv6 NAT Considerations March 2009
2.1. Avoiding Renumbering
As discussed in [RFC4864] Section 2.5, the ability to change
providers with minimal operational difficulty is an important
requirement in many networks. However, renumbering is still quite
painful today, as discussed in [I-D.carpenter-renum-needs-work].
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.
2.2. Site Multihoming
Another important requirement in many networks is site multihoming.
A multihomed site essentially requires that its 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 provider to the global routing system through
another 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 providers, to its exit router which is a IPv4 NAT
box. Using address translation to facilitate multihoming support has
Thaler & Zhang Expires September 5, 2009 [Page 4]
Internet-Draft IPv6 NAT Considerations March 2009
one unique advantage: there is no impact on the routing system
scalability, as the NAT box simply takes one address from each
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 it is important to point out that a multihomed site
announcing its own PI prefix(es) achieves important benefits that
NAT-based multihoming support does not provide. Using PI addresses,
end-to-end communications can be preserved in face of connectivity
failures of individual providers, as long as the site remains
connected through at least one operational provider. Announcing PI
prefixes also gives a multihomed site the ability to perform traffic
engineering and load balancing. While the users gain these benefits
from PI-based multihoming, we also note that, in today's routing
system, these gains are at the cost of the increased routing table
size for all providers.
2.3. 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 it remains an open question of whether one can successfully
hide the network topology through address translation. 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, the Hop Limit field, or other fields in the
packet header. An even bigger open question is what quantifiable
benefits topology hiding can bring, which will determine how much
cost one is willing to pay to achieve it.
2.4. Preventing Host Counting
As a specific measure of topology hiding, preventing an external
entity from counting the number of hosts on one's network is another
perceived benefit of NAT. Like topology hiding in general, it
remains to be seen how important this issue may really be in
practice.
Even where host counting is a concern, it is worth pointing out some
of the challenges in preventing it. In [Bellovin], Bellovin showed
how one can successfully count the number of hosts behind a NAT box.
Although that paper uses the IPid field to count IPv4 hosts, the
Thaler & Zhang Expires September 5, 2009 [Page 5]
Internet-Draft IPv6 NAT Considerations March 2009
point applies more generally, in that if any fields, such as fragment
ID, TCP initial sequence number, or ephemeral port number, are chosen
in a predictive fashion (e.g., sequentially), then an attacker may
correlate packets or connections coming from the same host.
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. As discussed in [RFC4864]
Section 2.2, the act of translation does not provide security in
itself, but rather the lack of pre-established or permanent filtering
state. 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 and supporting multihoming without
impacting routing scalability. Topology hiding and host counting may
be concerns to some, however solving them calls for further research
as address translation may or may not be an effective solution.
Furthermore, their quantifiable benefit is yet to be understood, and
one must compare that benefit against the potential costs.
3. Architectural Considerations of IPv6 NAT
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? 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 block in the Internet
Thaler & Zhang Expires September 5, 2009 [Page 6]
Internet-Draft IPv6 NAT Considerations March 2009
architecture.
One may argue that the answers to the above questions depend on
whether we can find adequate solutions to the renumbering and
multihoming problems. It is worthwhile pointing out that IPv6 NAT is
not the only solution to these two problems. Renumbering can be
avoided by allocating to users provider-independent addresses.
Multihoming is already a pervasive practice today, not some new
feature to be supported in the future, and NAT-based multihoming has
serious limitations as discussed earlier. The real issue is not
multihoming per se, but the need for a scalable routing system.
If the answer to the above two questions is no, then non-IPv6-NAT
parts of the world should *not* be affected by those sites that want
to deploy IPv6 NAT. More specifically, IPv6 users should 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, without having to address the issue of
traversing NAT boxes. Similarly, network operators 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.
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. As every coin has two sides, 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 (re-installing) 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:
Thaler & Zhang Expires September 5, 2009 [Page 7]
Internet-Draft IPv6 NAT Considerations March 2009
1. Endpoints get a stable, globally reachable address: In this class
of solution, end sites use provider-independent addressing and
hence endpoints are unaffected by changing ISPs. 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, operators 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 solution, hosts use locally-
scoped (and hence provider-independent) addresses for
communication within the site. 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 provide the host with globally routable addresses which
may change, but address changes are constrained to systems that
operate over or beyond the tunnel, including DNS servers and
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 which gets translated in the
network: In this class of solution, 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 long time concern in
operational communities, and an effective and deployable solution
must be found. We observe that the question in 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
Thaler & Zhang Expires September 5, 2009 [Page 8]
Internet-Draft IPv6 NAT Considerations March 2009
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
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. We strongly encourage the
community to consider end-to-end transparency as a requirement when
proposing any solution. 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. IANA Considerations
[RFC Editor: please remove this section prior to publication.]
This document has no IANA Actions.
7. References
Thaler & Zhang Expires September 5, 2009 [Page 9]
Internet-Draft IPv6 NAT Considerations March 2009
7.1. Normative References
7.2. 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>.
[I-D.carpenter-renum-needs-work]
Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
still needs work", draft-carpenter-renum-needs-work-02
(work in progress), February 2009.
[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>.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[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.
Authors' Addresses
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Thaler & Zhang Expires September 5, 2009 [Page 10]
Internet-Draft IPv6 NAT Considerations March 2009
Lixia Zhang
UCLA Computer Science Department
3713 Boelter Hall
Los Angeles, CA 90095
USA
Phone: +1 310 825 2695
Email: lixia@cs.ucla.edu
Thaler & Zhang Expires September 5, 2009 [Page 11]