Internet DRAFT - draft-huitema-natreq4ipv6
draft-huitema-natreq4ipv6
INTERNET DRAFT C. Huitema, Microsoft
<draft-huitema-natreq4ipv6-00.txt>
Expires August 16, 2001 February 16, 2001
Short term NAT requirements for IPv6 transition
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. 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.
Abstract
During the next few years, as the Ipv4 address space moves toward
exhaustion, it is likely that the deployment of NAT will accelerate.
By 2005, millions of NAT devices will likely be deployed on the
Internet, both within enterprises and consumer households. Should
those NAT devices not support either native Ipv6, or IPv6 transition
mechanisms such as 6 to 4, the result would be significant delays in
the deployment of IPv6.
This draft presents the requirements that NAT devices must meet in
order to enable a future transition to IPv6. Rather than specifying
every aspect of a NATÆs operation in detail, our focus is solely on
identifying those requirements that are absolutely essential to
ensure compatibility with what we believe will be the most popular
IPv6 transition mechanisms.
1 Introduction
During the next few years, as the Ipv4 address space moves toward
exhaustion, it is likely that the deployment of NAT will accelerate.
By 2005, millions of NAT devices will likely be deployed on the
Internet, both within enterprises and consumer households. Should
those NAT devices not support either native Ipv6, or IPv6 transition
mechanisms such as 6 to 4, the result would be significant delays in
the deployment of IPv6.
Huitema. [Page 1]
INTERNET-DRAFT Short term NAT requirements February 16, 2001
This draft presents the requirements that NAT devices must meet in
order to enable a future transition to IPv6. Rather than specifying
every aspect of a NATÆs operation in detail, our focus is solely on
identifying those requirements that are absolutely essential to
ensure compatibility with what we believe will be the most popular
IPv6 transition mechanisms.
1.01 Requirements language
In this document, the key words "MAY", "MUSTö, "MUST NOT",
"optional","recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [RFC2119].
1.1 The case for IPv6 transition
As described in [NAT Complications] todayÆs NAT devices are
relatively successful at supporting TCP/UDP ôclientö applications
which represented the bulk of Internet usage during the 1990s. These
applications include Web browsing with HTTP and SSL, FTP, email and
DNS. However, the current generation of NAT products has some
unfortunate consequences on the users ability to deploy new
applications, many of which follow a ôpeer-to-peerö model, and
expect all ôclientsö to be also able to behave as ôservers.ö Napster
is a typical example of one such popular application: the peer-to-
peer exchanges of music files cannot take place if both peers are
located behind a NAT. With peer-to-peer applications such as NAPSTER
now comprising more than 75 percent of Internet traffic in some
locations, it has become clear that NAT devices are in danger of
retarding the evolution of the Internet.
We believe that the proper solution to the NAT problem is to move
towards IPv6. We realize that IPv6 cannot be turned on instantly,
and thus we also believe that the interim solution will be to enable
peer-to-peer applications behind NATs by deploying IPv6 on home
networks, and linking these IPv6 islands together using IPv6
transition mechanisms such as 6to4. Unfortunately, not only does
the continued deployment of the current generation of NAT devices
make it more difficult to deploy new applications, but it will also
make it difficult to handle the IPv6 transition. We therefore
believe that action is required now in order to ensure that the
generation of NATs that will be deployed over the next few years is
IPv6-friendly.
Since we expect that the ôIPv6 islandö solution will eventually give
way to widespread native IPv6 deployment, our approach is designed
to be minimally intrusive. Rather than requiring large scale changes
to NATs in the short term, we are requiring only a few modest
changes to ensure IPv6 transition support. Also, rather than
requiring modifications to existing host TCP/IP stacks, we only
require minimal modifications to the applications.
Huitema. [Page 2]
INTERNET-DRAFT Short term NAT requirements February 16, 2001
2 Definitions
2.1 NAT
As defined in [RFC2663], Network Address Translation is a method by
which IP addresses are mapped from one realm to another, in an
attempt to provide transparent routing to hosts. Traditionally, NAT
devices are used to connect an isolated address realm with private
unregistered addresses to an external realm with globally unique
registered addresses.
2.2 Global IPv4 Internet
We use the term ôglobal IPv4 Internetö to designate the fraction of
the Internet that uses globally unique IP addresses, and where
connectivity to all globally unique addresses is expected.
2.3 Private network
We use the term ôprivate networkö to designate a network that uses
private addresses as defined in [RFC1918], and that usually connects
to the global IPv4 Internet through a NAT device.
2.4 Global IPv6 Internet
We use the term ôglobal IPv6 Internetö to designate a network of
nodes that are use globally unique IPv6 addresses, and where
connectivity to all globally unique addresses is expected.
3 Model, requirements
The goal of this document is to enable easy deployment of IPv6 in
private networks that are connected to the ôglobal IPv4 Internetö
through a NAT box. The connection can be performed in one of two
ways:
* The gateway device can support native IPV6 so that it performs
IPV6 routing functions in parallel to the IPv6 Network Address
Translation function.
* Hosts inside the private network can set up automatic tunnels
to reach the IPV6 Internet, using the 6to4 transition mechanism
[6to4].
The preferred solution is to ôupgradeö the connection device, so
that it performs IPv6 routing functions in parallel to the IPv4
address translation function. The second solution is to allow hosts
inside the private network to set up automatic tunnels to reach the
global IPv6 internet using the 6to4 technology.
The goal of supporting these mechanisms is to enable the interim
Huitema. [Page 3]
INTERNET-DRAFT Short term NAT requirements February 16, 2001
deployment of ôpeer-to-peerö applications behind NAT. These
applications could possibly be built using either TCP or UDP. The
ideal solution would be to enable hosts in private networks to
publish a set of global IP addresses and port at which they can
receive TCP connection requests and UDP datagrams.
4 Description of the solution
The proposed solution provides IPv6 support either through a local
implementation or through a transparent relay.
Our assumption is that IPv6 will be initially deployed by means of
ôtunnelsö over the existing IPv4 infrastructure. The ô6to4ö strategy
[6TO4] allows users to transform a single IPv4 address into an IPv6
prefix; an almost unlimited number of stations can then obtain
globally routable addresses using this prefix.
In a NAT environment, this can be instantiated handled in two ways:
1) An IPv6 capable NAT implements the ô6to4 routerö functionality,
and appears as an IPv6 router to the local PCs,
2) A NAT that has no knowledge of IPv6 transparently passes the IPv4
packets that encapsulate IPv6 traffic to a local PC, which will
in turn act as an IPv6 router for the local network.
We discuss the requirements for each of these approaches in turn.
4.1 Requirements for NATs implementing native IPV6
A NAT device can support IPv6 by providing the 6to4 relay
functionality. In this case, the NAT will construct a 6to4 prefix
from one of the global IPv4 addresses that it manages, and will
advertise this prefix to the local network. A NAT that has obtained
connectivity to the global Internet by other means than ô6to4ö, will
advertise the correspondent IPv6 prefix to the local network.
If the NAT product chooses to implement IPv6, it should do so
according to the relevant IETF standards, including the IPv6
Specification [RFC2460], Neighbor Discovery [RFC2461], IPv6
Stateless Address Autoconfiguration [RFC2462], and ICMPv6[RFC 2463].
4.2 Requirements for NATs supporting transparent IPV6 tunneling
However, in the short term it is likely that NAT devices will only
fully implement IPv4, and thus will not be capable of routing IPv6
natively. In this case, it is required that the NAT device enables
the hosts behind the NAT to utilize IPv6. This can be done if they
can support transparent tunneling of IPv6 packets.
The tunneling of IPv6 packets into IPv4 is defined in [RFC2893]. The
Huitema. [Page 4]
INTERNET-DRAFT Short term NAT requirements February 16, 2001
tunneled packets are identified by the protocol type ô41ö in the
IPv4 header. NAT devices that do not implement the ô6to4ö relaying
functions will MUST provide the transparency relay function as
follows:
1) Define a local variable, LOCAL-IPV6-ROUTER holding the IPv4
address of the ôlocal IPv6 router.ö This variable is initially set
to the null address, 0.0.0.0.
2) When a packet is sent from a local host for a remote destination,
specifying protocol type 41, copy the address of the local host
into the LOCAL-IPV6-ROUTER variable. Replace the source address by
the external address of the NAT.
3) When a packet is sent from a remote source to the global address
managed by the NAT for protocol type 41, check the value of the
LOCAL-IPV6-ROUTER variable. If the value is null, the NAT MUST
reject the packet. Otherwise, the NAT MUST replace the destination
address by the value of the LOCAL-IPV6-ROUTER variable, and relay
the packet to the corresponding local host.
This assumes that the NAT manages a single external address. Where
it manages several addresses, it the NAT SHOULD pick one of these
addresses as the preferred address for IPv6, and behave as if only
this address is available.
5 Discussion of the solution
Implementing an IPv6 relay in the NAT device obviously enables local
hosts to use IPv6. Transparent IPV6 tunneling also enables IPv6, if
one of the hosts is designated as the IPv6 route implementing
[6to4], or if several hosts cooperate using the service.
5.1 Single 6to4 router
The simplest way to deploy IPv6 behind a NAT providing transparent
tunneling is to select one of the local hosts to act as a 6to4
relay. This host will have to discover the global address used by
the local NAT, construct a 6to4 prefix based on that address, and
act as an IPv6 router for the local network. The global address can
be discovered either through an interaction with the local NAT, or
with the help of a server that has access to the global IPv4
Internet; specifying these mechanisms is outside the scope of this
memo.
The selected router will have to ensure that it sends at least one
IPv6 packet to an external target before it can receive tunneled
packets. Sending one packet will ensure that the address of the
selected router will be copied by the NAT in the LOCAL-IPV6-ROUTER
variable, and that the selected router will receive the IPv6 packets
sent by external hosts.
Huitema. [Page 5]
INTERNET-DRAFT Short term NAT requirements February 16, 2001
5.2 Cooperation between multiple hosts
It is possible to avoid the selection of a specific router by
letting several hosts on the private network act as cooperating 6to4
relays. Each of these hosts will discover the global address used by
the local NAT, construct a 6to4 prefix based on that address, and
act as an IPv6 router for the local network. Any of these routers
may receive tunneled packed; they must all be ready to relay over
the private network the packets that are bound to other hosts.
According to the specified algorithm, tunneled IPv6 packets will be
forwarded to the last router that sent an encapsulated IPv6 packet
to an external node. If all active routers send packets at regular
intervals, this ensures that the packets will be sent by the NAT to
an active router, rather than possibly being sent in a black hole
created by a failing router.
6 Security Considerations
6.1 The generic security risks of 6to4 tunneling and the appropriate
protections are discussed in [6to4]. The transparent IPV6 tunneling
option introduces an additional vulnerability, since a rogue host
on the private network could send tunneled packets at regular
intervals, be perceived by the NAT as the selected router, and uses
this in a denial of service attack. To protect against this
vulnerability, the administrators of private networks must ensure
that the local hosts adopt proper behavior.
7 IANA Considerations
None.
8 Copyright
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.
Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
Huitema. [Page 6]
INTERNET-DRAFT Short term NAT requirements February 16, 2001
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
9 Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
10 References
[RFC2460] S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 2460, December 1998.
[RFC2461] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). RFC 2461, December 1998.
[RFC2462] S. Thomson, T. Narten. IPv6 Stateless Address
Autoconfiguration. RFC 2462, December 1998.
[RFC2463] A. Conta, S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet. RFC 2463, December 1998.
Huitema. [Page 7]
INTERNET-DRAFT Short term NAT requirements February 16, 2001
[RFC2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997.
[RFC2663] P. Srisuresh, M. Holdrege. IP Network Address Translator
(NAT) Terminology and Considerations. RFC 2663, August 1999.
[RFC2893] R. Gilligan, E. Nordmark. Transition Mechanisms for IPv6
Hosts and Routers. RFC 2893, August 2000.
[RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot &
E. Lear. Address Allocation for Private Internets. RFC 1918,
February 1996.
[6TO4] B. Carpenter, K. Moore. Connection of IPv6 Domains via IPv4
Clouds. Work in Progress.
[NAT Complications] M. Holdrege, P. Srisuresh. Protocol
Complications with the IP Network Address Translator. Work in
Progress.
11 Authors' Addresses
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: huitema@microsoft.com
Huitema. [Page 8]
