Network Working Group Keith Moore Internet-Draft University of Tennessee 22 February 2001 Expires: 22 August 2001 Running IPv6 over a (potentially-NATted) IPv4 Network draft-moore-6overnat-00.txt This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Comments regarding this internet-draft should be sent to the author, whose address appears below. Abstract This document describes a protocol (dubbed "6overNAT") for deploying IP version 6 over a network which supports IP version 4 but cannot (yet) natively support IP version 6. The target network may be separated from the public Internet by one or more network address translators (NATs), and the target network may itself contain NATs. This protocol is intended to allow IPv6-capable hosts on the private network to be assigned globally unique and routable IPv6 addresses, and to allow those hosts to exchange traffic with IPv6 hosts on the public IPv6 Internet (or given suitable connections, on other private IPv6 networks), without intervening translation of IPv6 addresses. It is intended that this protocol should allow almost any IPv4-capable enterprise network to begin using IPv6 over that network for a small marginal cost and with little effort. Moore Expires 22 August 2001 [Page 1] 6overNAT INTERNET-DRAFT 22 February 2001 1. Introduction For a variety of reasons, Network Address Translators (NATs) [1] are now widely deployed within private networks which are connected to the public Internet. In addition, some Internet Service Providers (ISPs) have deployed NATs between their customers and the public Internet. Because they violate fundamental assumptions of the Internet Protocol architecture, including the assumption that IP addresses are globally unique, NATs are now known to cause a large number of interoperability problems [2,3,4], especially for networked applications employing more than two communicating parties. On the other hand, the shortage of address space in IPv4 have made NATs a necessity for IPv4 networks. The Internet has grown so large that with reasonable allocation schemes there are no longer enough IPv4 addresses for each host to be assigned one uniquely. The result is that many desirable kinds of applications are difficult to deploy using IPv4 (as those applications require specific support at the NATs); sometimes to the point of making deployment infeasible. IP version 6 [5] was designed to alleviate the address space shortage by providing a much larger address space; thus, IPv6 provides a potential solution to this problem. However, upgrading all components of a network to support IPv6 "natively" can be quite expensive, and the products necessary to accomplish this are only now beginning to appear. This document describes a protocol for tunneling IPv6 traffic over any existing IPv4 private network (including a network containing NATs or separated from the public Internet by a NAT), and for providing IPv6 connectivity between hosts on that private network and hosts on other IPv6 networks, including the public IPv6 Internet. This protocol attempts to allow incremental deployment of IPv6 and IPv6-based applications, on a per-host and as-needed basis, at minimum expense. It is also hoped that existing NATs can be upgraded to support 6overNAT (just as a NAT vendor might add application-level gateway support for any UDP-based application), thus facilitating use of IPv6 while retaining NAT capability for IPv4. An additional goal of this protocol is to facilitate easy transition from this state to a native IPv6 capability, so that when appropriate conditions exist this can be accomplished with a minimum of additional effort. 1.1. Related work The "6overNAT" mechanism defined in this memo is similar to other mechanisms for using tunneling in the deployment of IPv6. Configured tunnels are discussed in [7]; they allow IPv6 packets to be transmitted between two points over an IPv4 tunnel, as long as the underlying network supports transmission of IPv4 protocol type 41. 6to4 [7] is similar to configured tunnels, but treats the entire public IPv4 Moore Expires 22 August 2001 [Page 2] 6overNAT INTERNET-DRAFT 22 February 2001 Internet as a large NBMA cloud; this avoids the need for an explicitly configured tunnel if the destination IPv6 address contains the 6to4 prefix (2002::/16) and the destination can be reached over the public IPv4 Internet. Both of these mechanisms these are generally applicable for connecting an enterprise IPv6 network to the public IPv6 Internet or to other IPv6 networks. By contrast, 6overNAT addresses the problem of deploying IPv6 within an existing enterprise IPv4 network. A network that uses 6overNAT locally can utilize any of 6to4, configured tunnels, or native IPv6, to provide connectivity to external IPv6 networks. 6over4 [8] is another mechanism for supporting IPv6 traffic within an IPv4 network. It can be used in either public or private IPv4 address space, but it requires that the underlying network support IP type 41, a single addressing realm, and IPv4 multicast. The presence of one or more NATs in the target network usually negates at least one of these conditions. By contrast, 6overNAT is designed to be usable in any private IPv4 network that can transmit UDP packets, regardless of whether it uses NATs or supports IPv4 multicast. 6overNAT also attempts to overcome some of the limitations imposed by typical NATs on the transmission of UDP datagrams - particularly the tendency of NATs to "time out" address bindings if they are not used within some interval. 1.2 Choice of 6overNAT vs. other IPv6 Encapsulations As stated above, 6overNAT can potentially be used over any enterprise IPv4 network which supports transmission of UDP datagrams, including (it is hoped) many networks for which an upgrade to IPv6 would otherwise be difficult or expensive. However, because the various measures employed by 6overNAT negatively affect its efficiency and reliability as compared to other encapsulations, 6overNAT may not be the best choice when other options are available. - If the underlying network can inherently support native IPv6 (which is the case for most passive networks and networks employing only layer 2 switching), and is not partitioned by one or more routers that lack IPv6 support, then native IPv6 is probably a better choice. - If the underlying network can support IPv4 multicast, and is not NATted, then 6over4 will be more efficient than 6overNAT. - If the underlying network comprises only a single IPv4 addressing realm which uses public IPv4 addresses, 6to4 is likely to be a better choice. - It will often be possible to run native IPv6, 6to4, or 6over4 over at least some parts of the underlying network. In a complex network where portions of the network were capable of supporting Moore Expires 22 August 2001 [Page 3] 6overNAT INTERNET-DRAFT 22 February 2001 native IPv6 or IPv4 multicast and other portions were not, the uniformity benefit of using 6overNAT everywhere would have to be balanced against the benefit of using more efficient mechanisms when possible. 1.3 Use of 6overNAT in public networks As currently written, 6overNAT is designed for use within a single enterprise network rather than on public networks. With the assistance of an external router located somewhere in the IPv4 Internet, it may be possible to use all or part of this protocol to establish a tunnel between a local IPv6-capable network (whether or not using 6overNAT internally) and one or more external IPv6 networks, over a NATted IPv4 connection. However, such use is outside the currently intended scope of this protocol, and at best, is for further study. 1.4. Keywords The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [10]. 2. Approach The basic approach is summarized as follows: A "border box" is installed at some point near the periphery of the private network. (See Figure 1) The border box is a specialized IPv6 router with several functions: o It transmits and receives IPv6 packets using the 6overNAT encapsulation (IPv6 over IPv4 UDP) described below, as well as transmitting and receiving IPv6 using other encapsulations (6to4, configured tunnels, native IPv6) when relaying packets between 6overNAT and external networks. 6overNAT thus uses IPv4 UDP as a link-layer, with the IPv4 address and port number serving as a 6-octet link-layer address. It is not required that the IPv4 address be public, nor that the address and port be transmitted intact between host and border box. So long as a 6overNAT host can send IPv4 UDP packets to the border box using a stable and well-known IPv4 address and port, and the border box can send IPv4 UDP packets back to that host using the source address and port which accompanied the packet when it was received, 6overNAT will work. o It listens for and responds to Router Solicitation and Neighbor Solicitation requests in order to establish "half-configured" tunnels between itself and local 6overNAT hosts. In order to work Moore Expires 22 August 2001 [Page 4] 6overNAT INTERNET-DRAFT 22 February 2001 around any potential IPv4 address translation between the border box and the 6overNAT host, the border box maintains a table of IPv6-to-IPv4 address bindings. o It acts as a gateway for Neighbor Discovery [9] requests and responses - forwarding them intact, forwarding them with alterations, or responding to them as necessary to create the illusion of a multicast-capable link layer over a potentially NATted, non-multicast capable IPv4 network. o Using Neighbor Discovery, it arranges for the direct routing of unicast traffic between local 6overNAT hosts in the same IPv4 addressing realm and which (from the IPv6 point-of-view) are configured to be on the same "link". Using Redirects, it MAY also arrange for direct routing of traffic between other pairs of 6overNAT hosts, including hosts in different IPv4 addressing realms. o It routes (unicast and multicast) packets between local 6overNAT hosts and hosts on other IPv6 networks just as any other IPv6 router. 6overNAT-capable hosts attached to the private network can then send IPv6 traffic to the border box by tunneling IPv6 over IPv4 UDP, using the border box's IPv4 address as the destination address of the UDP packet. Similarly, the border box will route IPv6 traffic destined for a local host by encapsulating that traffic in an IPv4 UDP datagram and sending it to the IPv4 address currently associated with that host. o When routing packets between external and internal hosts, the border box will perform the necessary encapsulation and decapsulation for local hosts (packets tunneled over IPv4 UDP) and remote hosts (packets transmitted using native IP, configured tunnels, or 6to4). Moore Expires 22 August 2001 [Page 5] 6overNAT INTERNET-DRAFT 22 February 2001 ................................ ................................... : : public IPv6 Internet : : private IPv4 network : : : : +----------+ : : | 6overNAT | +--------+ | host | +------+ | | +-----+----+ | IPv6 |====================| border |-=-=-=-=-=-=-=-=-=-=-=-=/ | host | | box | +------+ | |-=-=-=-=-=-=-=-=-=-=-=-=\ +--------+ +-----+----+ : : | 6overNAT | : : | host | : : +----------+ : : ................................ ................................... === IPv6 connection (may be native, configured tunnel, or 6to4) -=- IPv6 tunneled over IPv4 UDP (6overNAT) Figure 1. Oversimplified Illustration of the 6overNAT Mechanism 2.1 Border Box As described above, the border box provides several functions necessary to facilitate exchange of IPv6 datagrams between local 6overNAT hosts, and between such hosts and IPv6 hosts on other networks. The same physical appliance may also provide other functions. For instance: o It may serve as a general-purpose IPv6 router, providing IPv6 connectivity to some local hosts via means other than 6overNAT, in addition to its 6overNAT functions. o It may implement DHCPv6 and/or Dynamic DNS. o It may provide support for IPv4 routing (with or without NAT) and perhaps DHCP. o It may provide connectivity between IPv4 and IPv6 using NAT-PT [11] or other means, so long as packets exchanged between IPv6 hosts are passed transparently (modulo administrative controls) and without address translation. o It may implement a firewall which blocks traffic that is administratively prohibited by locally-specified policy. Moore Expires 22 August 2001 [Page 6] 6overNAT INTERNET-DRAFT 22 February 2001 A border box is an IPv6 router. This among other things, implies that normal support for router discovery for use between ordinary hosts and routers [9] (in addition to the specialized support detailed below), and support for ICMPv6 [12] are REQUIRED. Depending on the use for which it is intended, a border box may also need to support routing protocols to exchange reachability information with other routers. 2.1.1 Operating Environment Several different operating environments are possible for the "border box", depending on whether one or more NATs are installed on the target network. Regardless of the placement of the border box, it is intended that there be a uniform host protocol for 6overNAT; in other words, a host supporting 6overNAT should work in any of these environments. It should also be possible to construct a border box which is usable with several of these configurations. 2.1.1.1 Border Box Behind A NAT This configuration assumes that the border box has no native external IPv6 connectivity, and that its only external IPv4 connectivity is via a NAT box. Such a border box could be said to be "behind" a NAT box, where the NAT box partitions the private network from the public v4 Internet or from other v4 networks. This configuration is shown in Figure 2. In this case the external IPv6 connectivity must be accomplished by 6to4 [6] and/or an explicitly configured tunnel to an external relay router [7]. (Note: there may be considerable overlap between the hosts on the public IPv4 Internet and those on the public IPv6 Internet. In Figure 2 the two networks appear separately, but this is only intended to illustrate that the relay router exchanges packets between them.) Moore Expires 22 August 2001 [Page 7] 6overNAT INTERNET-DRAFT 22 February 2001 .................. ................... ............................... : : : : public : : public : : private IPv6 Internet : : IPv4 Internet : : IPv4 network : : : : : : : : +------+ +--------+ +-----+ +--------+ +----------+ | IPv6 |------| relay |+=+=+=+=+=+| NAT |+=+| border |-=-| 6overNAT | | host | | router | +-----+ | box | | host | +------+ +--------+ : : +--------+ +----------+ : : : : .................. ................... ............................... === IPv6 connection +=+ IPv6 tunneled over IPv4 protocol 41 (6to4 or configured tunnel) -=- IPv6 tunneled over IPv4 UDP (6overNAT) Figure 2. Border Box Inside the NAT In order for either 6to4 or the configured tunnel to work properly, the border box must be assigned a stable and routable IPv4 address; if the tunnel is over the public Internet, the address must also be a globally-unique, public (etc...) IPv4 address. The NAT separating the border box from the external network MUST be configured in such a way that any incoming traffic for IPv4 protocol type 41 at that address is routed to the border box. However, it is permissible for the destination IPv4 address of inbound "external" traffic to be translated by the time the packet reaches the border box. If there are multiple NATs between the border box and the external network, the same constraint applies -- each NAT between the public Internet and the border box will need to be configured to provide the effect of a stable external address (at least for IPv4 protocol 41) for the border box. By contrast, since there are no NATs in this configuration between the border box and the hosts using 6overNAT, local hosts using IPv6 do not consume external IPv4 addresses. Note: Both 6to4 and configured tunnels require the use of IPv4 protocol type 41. If the NAT for a particular network (as well as any other packet filters which might be in place) cannot be configured to pass traffic for IPv4 protocol type 41 to the border box, the "Behind the NAT" configuration is not applicable to that network. Moore Expires 22 August 2001 [Page 8] 6overNAT INTERNET-DRAFT 22 February 2001 2.1.1.2 Border Box External to NATs The border box may be located between the public IPv6 Internet (or other IPv6 networks of interest) and the outermost NAT box, as in Figure 3. In this case the IPv4 UDP tunnel between the border box and the IPv6 hosts that it serves will be subject to address translation by one or more NATs. ................................ ........... ....................... : : : : public IPv6 Internet : : IPv4 : : private IPv4 network : : network : : : : : : +------+ +--------+ +-----+ +----------+ | IPv6 |====================| border |-=-| NAT |-=-=-=-=| 6overNAT | | host | | box | | box | | host | +------+ +--------+ +-----+ +----------+ : : : : ................................ ........... ....................... === IPv6 connection -=- IPv6 tunneled over IPv4 UDP Figure 3. Border Box external to the NATted network In this configuration, connectivity between the border box and external IPv6 networks may be accomplished by any of native IPv6, configured tunnels, or 6to4. If either of the latter methods are used the border box MUST have a stable, public, globally-scoped IPv4 address assigned to it and inbound traffic destined for that address MUST be routed to the border box. By contrast, IPv6 traffic originating from the internal network will be sent to the border box over IPv4 UDP. The border box MUST have a stable IPv4 address assigned for this purpose (a private address is acceptable, but the assignment must be stable), and the NATs and/or routers between the originating hosts and the border box MUST be configured so that encapsulated IPv6 traffic sent by an originating host to the border box's IPv4 address will be routed to the border box. In addition, any responses from the border box to such traffic MUST be routed to the host with that IPv4 address. However it is understood that after some interval the intervening NATs may change the binding between a host and the IPv4 address used by that host. In addition, a NAT may "forget" the address bindings if it crashes, is restarted, or suffers a temporary power failure. The 6overNAT protocol attempts to Moore Expires 22 August 2001 [Page 9] 6overNAT INTERNET-DRAFT 22 February 2001 provide stable IPv6 addressing for local hosts in spite of these difficulties. Note that with this configuration, locally-originated packets arriving at the border box will have been assigned "external" IPv4 addresses by the NAT. Such addresses may well be scarce, and this might limit the number of internal IPv6 hosts that could be supported by this configuration. However, since there is no requirement that the source port used by the internal host be preserved, and 6overNAT uses IPv4 address and port as the link-layer address, NAPT (network address and port translation) MAY be used instead of ordinary NAT. This will help conserve external IPv4 addresses. 2.1.1.3 Border Box between NATs In a multiply-NATted network, a border box may be installed in a location where it is separated from local hosts by one or more NATs, and also receives its external connectivity through one or more NATs. In such a configuration, the operational constraints of both of the above configurations apply. 2.1.1.4 Border Box in Parallel with the NAT A border box may be located in parallel with a NAT. Such a border box would be a router with two interfaces - one on the outside of a NAT, using public IPv4 and/or IPv6 address space; and the other on the inside of the NAT, using private address space. This configuration is shown in Figure 4. Note that while logically the NAT provides connectivity to the IPv4 network and the border box provides connectivity to the public IPv6 network, the IPv6 external connectivity can still be provided over IPv4 using a configured tunnel or 6to4. Moore Expires 22 August 2001 [Page 10] 6overNAT INTERNET-DRAFT 22 February 2001 ................................ ................................... : : public IPv4 Internet : : private IPv4 network +------+ +-----+ | IPv4 |---------------------| NAT |----+ | host | | box | | +------+ +-----+ | ..............................: : | +----------+ : +---------------| 6overNAT | ............................... : +-=-=-=-=-=-=-=-| host | : : | +----------+ +------+ +--------+ | | IPv6 | | border | | | host |====================| box |-=+ +------+ +--------+ : : public IPv6 Internet : : ................................ ................................... --- IPv4 connection === IPv6 connection (native, configured tunnel, or 6to4) -=- IPv6 tunneled over IPv4 UDP (6overNAT) Figure 4. Border Box in Parallel with a NAT 2.1.1.5 Border Box Co-Located with a NAT For convenience and improved packaging, a border box can be co- located with an IPv4 NAT. In this case the box functions as a NAT for IPv4 traffic and as an IPv6 router (with necessary encapsulation) for IPv6 traffic. Such a device will presumably use the same hardware network interfaces for both IPv4 and IPv6 traffic. NOTE: A (border box + NAT) combination would appear to have an advantage over other configurations in that the border box would have direct access to the NAT's internal-external address mapping table, so it would not need special configuration (as in "border box behind the NAT") nor would it require occasional NS or RS messages to keep track of changes in the NAT's address bindings (as in "Border Box External to NATs"). However, since the network "behind" such a border box might itself contain NATs, NS/RS messages are still necessary even in this configuration. Still, a border box which was co-located with a NAT would likely be cheaper and more reliable than separate components. Moore Expires 22 August 2001 [Page 11] 6overNAT INTERNET-DRAFT 22 February 2001 3. 6overNAT protocol The following sections detail the protocol to be used by hosts and routers when routing IPv6 over UDP. 3.1 Frame Format 6overNAT packets are transmitted as UDP packets [13] within IPv4 [14]. The IPv4 protocol type is 17 (11 hex) for UDP. The IPv4 header contains the Destination and Source IPv4 addresses, which are the IPv4 addresses used on the local network to denote the endpoints of the 6overNAT tunnel. The UDP Source Port and UDP Destination Port are also used to denote the endpoints of the 6overNAT tunnel. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |Version| IHL |Type of Service| Total Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P | Time to Live | Protocol 0x11 | Header Checksum | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | IPv4 Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H | IPv4 Destination Address | E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A | IPv4 Options ... / D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E R ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v / ... IPv4 Opts | Padding | --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U | UDP Source Port | UDP Destination Port | D +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P | Length | Checksum | --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 header and payload ... / +-------+-------+-------+-------+-------+------+------+ To a host's IPv6 stack, a 6overNAT network looks like a multicast-capa- ble network. It looks like a multicast-capable network so that router and neighbor discovery and stateless address autoconfiguration will work in (almost) the same way for a 6overNAT network (pseudo-)interface as for other kinds of network interfaces. Moore Expires 22 August 2001 [Page 12] 6overNAT INTERNET-DRAFT 22 February 2001 3.1.1 Maximum Transmission Unit Since 6overNAT uses UDP as an underlying transport, a 6overNAT Maximum Transfer Unit (MTU) could potentially be as large as the payload of the largest valid UDP datagram (65527 bytes). For most link layers, such an MTU would require fragmentation of the UDP datagram at the IPv4 layer. For the sake of efficiency, the default link MTU assumed by a host, and the link MTU supplied by a Border Box during Router Advertisement SHOULD normally be set to the estimated IPv4 MTU associated with the path between the border box and the host, less the size of the IPv4 and UDP headers used by that host. An exception would be when the MTU thus derived were smaller than the minimum IPv6 MTU size of 1280 bytes [5]. In such cases the link MTU SHOULD be chosen to be no larger than the maximum payload of a UDP packet composed of the minimum number of IPv4 fragments required to transmit a UDP packet with a payload of 1280 bytes (in other words, minimize the maximum number of IPv4 fragments that are required to make an MTU-sized IPv6 packet.) When an MTU is specified by a Border Box it SHOULD assume that no IPv4 or UDP options will be used by the host. A host which adds IPv4 or UDP options to outgoing 6overNAT packets MAY adjust its own notion of MTU to allow room for those options. 6overNAT implementations SHOULD NOT set the "do not fragment" (DF) bit of the encapsulating IPv4 header, as this would thwart MTU discovery at the IPv6 level. 3.2 Link-Layer Addressing Discussion of 6overNAT addressing is inevitably cumbersome due to the number of addresses involved. Not only are there separate IPv6 and IPv4 layers, the IPv4 source and destination addresses used by tunnel endpoints may be different at each end of the tunnel due to the presence of NATs, and the translations between addresses across the NATs are subject to change at the whim of an intervening NAT. 3.2.1 Initial Address Selection for Hosts A host using 6overNAT determines its IPv6 link-local, site-local, and global addresses using any of the mechanisms which would be used by a normal IPv6 host. A host's addresses may be manually configured, or configured using Stateless Address Autoconfiguration [15] (with or without privacy extensions [16]), by DHCPv6, or by any other means available. When using Stateless Address Autoconfiguration with 6overNAT, the interface identifier for an interface using 6overNAT for may be derived exactly as it would be for an interface using native IPv6, even though Moore Expires 22 August 2001 [Page 13] 6overNAT INTERNET-DRAFT 22 February 2001 that interface is not being used natively. This would potentially allow a host or network to migrate from using 6overNAT to native IPv6 without changing IPv6 addresses. 3.2.2 Derivation of (IPv4) Tunnel Endpoint Addresses In order to send an IPv6 packet using 6overNAT it is necessary to determine the IPv4 address and port to be used as the remote tunnel endpoint. In effect, the address and port form a 48-bit "link-layer" address. The rules for determining the tunnel endpoint are different for hosts and border boxes. 3.2.2.1 Derivation of Tunnel Endpoints for Hosts Before a host can transmit or receive IPv6 traffic using 6overNAT, it must establish a tunnel with the border box. In order to do this an IPv4 address and port which, when used as a destination address, will cause the packet to be routed to the border box, must already be known by the host, via explicit configuration or some other means. (Note that because of NAT this destination IPv4 address and port may not be the ones that are seen by the border box; it's merely the address and port which happen to reach the border box from within the 6overNAT host's addressing realm) The rules that a host uses in determining the "link-layer" address (i.e. the IPv4 address and port) corresponding to an IPv6 destination address are as follows: o For any unicast IPv6 address for which the IPv4 address and port are known to the host via Neighbor Discovery or Redirects, the IPv4 address and port thus obtained are used. o For any other IPv6 broadcast or multicast address, the IPv4 address and port are those used to reach the border box. This (among other things) ensures that Neighbor Discovery requests are sent to the border box. 3.2.2.2 Derivation of Tunnel Endpoints for Border Boxes A border box must maintain a table of the mappings from IPv6 addresses to IPv4 addresses and UDP port numbers at which hosts will accept 6overNAT traffic. The border box potentially establishes such a mapping when it receives Neighbor Solicitation or Router Solicitation requests from that host at its own tunnel endpoint address. Any binding established is from the IPv6 source address from the incoming request to the source address and port obtained from the IPv4 header of the incoming request. Moore Expires 22 August 2001 [Page 14] 6overNAT INTERNET-DRAFT 22 February 2001 When a border box wishes to send or forward a packet to a 6overNAT unicast address, it consults this table to find a IPv4 host and port address from which traffic has recently been received from this host, and (if an entry is found in the table) uses that host and port address as the destination for the IPv4 UDP encapsulation. If there is no entry in the border box's table for that IPv6 destination address, the address is unreachable. Lacking a real multicast-capable link layer, the border box has no way to perform Neighbor Discovery for the host. General handling of packets transmitted to multicast addresses is TBD. However, packets destined for the all-routers multicast address are processed by the border box and not forwarded to other hosts. For a packet destined for a solicited-node multicast address, a separate copy of that packet is forwarded to each link-layer address which has an associated IPv6 address that corresponds to that multicast address. Packets for the all-hosts multicast address are processed only by the border box, and not forwarded to other hosts. 3.3 6overNAT and Neighbor Discovery 6overNAT uses Neighbor Discovery [9] in a few ways that are perhaps different than those intended by the designers of that protocol. 6overNAT hosts use ND not only to inform border boxes of their current IPv4 addresses and to inform them of changes to those addresses (which may for example occur due to expiration of translations in an intervening NAT), but also to trick the NATs into not expiring their address bindings. 6overNAT hosts also use ND to discover link-layer addresses of other 6overNAT hosts in a similar manner to the way that ND is used by ordinary v6 hosts. However, unlike the normal use of ND, ND in the context of 6overNAT requires support from the border box. Similarly, the border box aids in a host's use of ND for Unreachable Address Detection. Within the Neighbor Discovery protocol, 6overNAT composes a link- layer address as follows: two octets of all zeros, followed by four octets of IPv4 address (in network byte order), followed by two octets of port number (also in network byte order). The Length field corresponding to such addresses is set to 1 (meaning that the address is eight octets long). The first two octets are reserved for future extensions - (for instance, to allow border boxes to inform hosts that native and/or 6over4 routing are available as alternatives to 6overNAT.) 3.3.1 Host support for Neighbor Discovery A 6overNAT host uses ND on 6overNAT links just as for any other multicast-capable link, with the following exceptions: Moore Expires 22 August 2001 [Page 15] 6overNAT INTERNET-DRAFT 22 February 2001 o 6overNAT hosts MUST actively send a Router Solicitation message when bringing up a 6overNAT interface, in order to establish a tunnel to a border box. The tunnel cannot be assumed to exist until the host has received a Router Advertisement message, and it may be necessary to repeat Router Solicitation messages at occasional intervals until such a response is received. It is not sufficient for the host to merely wait on a Router Advertisement message, because the border box does not know the host's link-layer address (and so has no way to send the message) until it has received the Router Solicitation message from the host. o Once a tunnel is established, 6overNAT hosts MUST send occasional Neighbor Solicitation requests for the IPv6 address used by the border box. These messages are intended to maintain the address translation in any intervening NAT boxes. The intervals between such messages are TBD (and should probably be randomized) but are on the order of 1-2 minutes. These messages can be omitted if the host has both sent and received traffic from the border box within that interval. o 6overNAT hosts SHOULD NOT include a source link-layer address option in an RS message transmitted to a border box, because the address may be translated by an intervening NAT. Such options, if included, will be ignored by a border box. Similarly, 6overNAT hosts MUST ignore a source link-layer address option in an RA message sent over 6overNAT and instead use the address and port from the enclosing IPv4 header. 3.3.2 Border Box support for Neighbor Discovery Because 6overNAT assumes that the underlying IPv4 network may encompass multiple addressing realms and is not capable of multicast, border boxes bear much of the burden of supporting Neighbor Discovery. This section attempts to detail the handling of the Neighbor Discovery protocol by the border boxes. In its treatment of Neighbor Discovery, the border box treats requests between 6overNAT hosts on the same 6overNAT "link" differently than between hosts on different "links". Two 6overNAT hosts may be on the same link if they are located within the same addressing realm (i.e. there are no NATs between them) and if they may freely exchange UDP packets with one another over IPv4 (e.g. there are no intervening fire- walls which block UDP packets). Border boxes require explicit configu- ration in order to determine whether two hosts are on the same "link", this is done by telling the border box to associate a single "link" with a particular IPv4 subnet or set of subnets. In the absence of such con- figuration, the border box will assume that no two 6overNAT hosts are on the same "link". Moore Expires 22 August 2001 [Page 16] 6overNAT INTERNET-DRAFT 22 February 2001 3.3.2.1 Router Solicitation and Router Advertisement messages This special processing applies only to exchange of RS/RA messages between a border box and a 6overNAT host. In other circumstances, such as when the border box communicates with IPv6 hosts or routers over non-6overNAT links, the normal rules for RS/RA apply. Because the underlying IPv4 layer is assumed to not support multicast or broadcast, border boxes do not have a way of broadcasting unsolicited RA messages to 6overNAT hosts. Instead, they periodically send (via IPv4 unicast) an RA message to each 6overNAT host with which they have an active tunnel. Border boxes MUST ignore any source link-layer address option in a received RS message because the message may have been transmitted through a NAT. The link-layer address used by the border box will always be that from the enclosing IPv4 header. Similarly, border boxes MUST NOT set the source link-layer address option in RA messages transmitted to 6overNAT hosts. If the border box is configured to be aware of local IPv4 addressing realms, it SHOULD return in RA messages a list of IPv6 prefixes for which the hosts are in the same IPv4 addressing realm as the host to which the RA message is being sent, identifying those prefixes as "on-link". This will tell the 6overNAT host to send NS messages to determine the IPv4 address and port of those hosts, and allow direct routing of unicast messages between those hosts. 3.3.2.2 Neighbor Solicitation and Neighbor Advertisement messages NS messages received by border boxes are processed as follows: If the IPv6 source address is the unspecified address, any source link- layer address option is removed (it shouldn't be there anyway), and the NS message is forwarded to the destination. If the destination is a solicited-node address, a copy of the NS request will be forwarded to every link-layer (IPv4 host+port) address of which the border box is aware whose IPv6 address is compatible with the solicited-node address. This allows Duplicate Address Detection to work. If the source address of an NS request is a valid IPv6 interface address, the table of link-layer addresses is compared with the IPv4 source address and port number of the NS message to determine whether the border box already knows the link-layer address corresponding to this interface. If it does, the border box notes that the host is still alive and using the same link-layer address; this resets the time interval for sending an RA message to that host. If no entry for the IPv6 address is found, the border box will establish an entry for that IPv6 address so that any NA responses can be routed to it, and forward Moore Expires 22 August 2001 [Page 17] 6overNAT INTERNET-DRAFT 22 February 2001 the NS packet to its destination (if possible). If an entry for that IPv6 address is found with a different link-layer address, the NS request is forwarded to that link-layer address to facilitate Duplicate Address Detection by that host. In all of the above cases, any source link-layer address option MUST be removed from the NS request before it is forwarded, unless the border box knows that source and destination are in the same IPv4 addressing realm. When routing an NA messages containing the target link-layer address option and the border box cannot determine that source and destination are in the same IPv4 addressing realm, the border box will fill the target link-layer address field with its own address before forwarding. Unsolicited NA advertisements received from 6overNAT hosts and sent to the all-nodes multicast address will not be propagated to hosts, though the border box will update its address table to reflect the link- layer address of the host if it has changed. 3.3.2.3 Redirects Border boxes MAY issue Redirects if they determine that messages which could be routed directly using IPv4 unicast are instead being routed through the border box. In general the border box can only issue a Redirect if the target address and the destination address of the redirect are in the same IPv4 addressing realm. 3.4 Multicast The above procedures are intended to implement multicast only to the extent needed for Neighbor Discovery to work. Implementation of general-purpose multicast within a 6overNAT network is for further study. 4. Configuration In order to exchange packets using 6overNAT, hosts must know an IPv4 address and port number which, when used as a destination for UDP packets, will allow those packets to reach the border box. For now, manual configuration is required. Automatic determination of the local border box address would be useful, but is for further study. The default UDP port for border boxes is #### (TBD IANA). Border boxes must be configured just as any other IPv6 router. The specific configuration which is needed for a border box to support 6overNAT includes a list of (IPv4 prefix/length, addressing realm) pairs. The addressing realm component is just a small integer used to distinguish one addressing realm from another; if the same number Moore Expires 22 August 2001 [Page 18] 6overNAT INTERNET-DRAFT 22 February 2001 appears in multiple tuples, those hosts are in the same addressing realm. This list allows the border box to determine whether two 6overNAT hosts are in the same addressing realm, by looking up each of their prefixes (using the longest-match algorithm) and seeing if their addressing realms are the same. In the absence of such a list, the border box must treat each 6overNAT host as if it were on a separate link, so all 6overNAT traffic will be routed through the border box. When address prefixes are to be supplied in RA messages, border boxes should also be supplied with a list of (IPv4 prefix/length, IPv6 prefix/length) pairs. This will allow the border box to assign each host an IPv6 prefix which is based on its IPv4 prefix as seen by the border box. This may help facilitate transition to native IPv6. 5. Transition from 6overNAT to Native IPv6 6overNAT is intended as a transition mechanism, not as a permanent solution for IPv6 deployment. Because 6overNAT imposes some encoding overhead, is somewhat less reliable, and also less efficient than native IPv6 routing, increased use of IPv6 within a network will naturally produce an incentive to switch to native IPv6. 6overNAT is designed to allow hosts to retain their IPv6 addresses across such a transition. An IPv6 address prefix assigned to an IPv4 subnet at the time a 6overNAT border box is configured can be retained when that subnet switches to native IPv6 routing. It would be desirable for hosts to be able to automatically determine whether to use 6overNAT, 6over4, host 6to4, or native IP, in part so that they could be transitioned from one encapsulation method to another without having to manually reconfigure each host. This is for further study. 5. Security Considerations Security considerations need further study. At first glance, 6overNAT's use of Neighbor Discovery to discover hosts and routers and transmit reachability information seems no more dangerous than any other use of this protocol. However, a 6overNAT network might comprise a much greater number of hosts and cover a much larger area than a typical multicast-capable layer 2 network, and as such, the security risks might be greater. 6. IANA Considerations - A UDP port for 6overNAT needs to be assigned. Moore Expires 22 August 2001 [Page 19] 6overNAT INTERNET-DRAFT 22 February 2001 7. Author's address Keith Moore University of Tennessee, Knoxville 104 Ayres Hall Knoxville TN, 37996-1301 USA email: moore@cs.utk.edu 8. References [1] P. Srisuresh, K. Egevang. Traditional IP Network Address Translator (Traditional NAT). RFC 3022, January 2001. [2] T. Hain. Architectural Implications of NAT. RFC 2993, November 2000. [3] M. Holdrege, P. Srisuresh. Protocol Complications with the IP Network Address Translator. RFC 3027, January 2001. [4] K. Moore. Things That NATs Break. internet-draft , work in progress. [5] S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, December 1998. [6] B. Carpenter, K. Moore. Connection of IPv6 Domains via IPv4 Clouds. RFC 3056, February 2001. [7] R. Gilligan, E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers. RFC 2893, August 2000. [8] B. Carpenter, C. Jung. Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. RFC 2529, March 1999. [9] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998. [10] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [11] G. Tsirtsis, P. Srisuresh. Network Address Translation - Protocol Translation (NAT-PT). RFC 2766, February 2000. [12] A. Conta, S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 2463, December 1998. Moore Expires 22 August 2001 [Page 20] 6overNAT INTERNET-DRAFT 22 February 2001 [13] J. Postel. User Datagram Protocol. RFC 768, August 1980. [14] J. Postel. Internet Protocol. RFC 791, September 1981. [15] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration. RFC 2462, December 1998. [16] T. Narten, R. Draves. Privacy Extensions for Stateless Address Autoconfiguration in IPv6. RFC 3041, January 2001. Moore Expires 22 August 2001 [Page 21]