NAT for IPv6-Only Hosts

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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.”

Abstract

This specification defines a NAT that allows IPv6-only hosts that are inside the NAT to operate with IPv4 hosts that are outside the NAT. It requires no modifications to the v4 hosts or applications, or to the operating system of v6 hosts, but it does require some changes to v6 applications. Typically this specification would be used to allow the hosts inside a NAT to connect to hosts outside it; but under some limitations, it can also allow hosts outside to connect to hosts inside.

The goal of this draft is to consider what is the minimal feasible approach to this problem. The current intention is to merge this with the nat64 draft. This draft is being discussed on the behave@ietf.org list.

1. Introduction
2. Architecture
    2.1. NAT from 6 to 4
    2.2. NAT from 4 to 6
3. Terminology
4. Mapping
5. Packet Forwarding
    5.1. UDP and TCP 6 to 4
    5.2. UDP and TCP 4 to 6
    5.3. IP Fragmentation
    5.4. TTL
    5.5. DSCP
    5.6. ICMP
        5.6.1. Option Yes ICMP
        5.6.2. Option No ICMP
    5.7. IPsec
    5.8. DCCP, SCTP, etc
6. ALGs
    6.1. FTP
    6.2. SIP
    6.3. Others
7. Helper Services
    7.1. STUN
    7.2. DNS
    7.3. DHCP
    7.4. V6 Routing / Tunnel
8. Requirement Conformance
    8.1. RFC 4787 Requirements
    8.2. draft-ietf-behave-tcp Requirements
    8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement Requirements
    8.4. draft-nishitani-cgn Requirements
    8.5. Multicast
9. IANA Considerations
10. Security Considerations
11. Acknowledgements
12. References
    12.1. Normative References
    12.2. Informative References
§ Author's Address
§ Intellectual Property and Copyright Statements

1. Introduction

A lot of thought has gone into the question of how to connect v6-only and v4-only hosts. This draft tries to identify the simplest approach to what would just "barely work," since what barely works is what is most likely to get deployed. The basic approach is to ask what works for v4 to v4 NATs and to pick a design that requires as few changes as possible from that. The assumption is that it is hard to deploy changes in existing v4 applications and in both v4 and v6 operating systems. Of course, this specification relies on subjective judgements about the relative complexity of deploying changes into various parts of the network.

This specification therefore amounts to a rough straw man meant to encourage discussion of what is the minimum that can be done.

2. Architecture

2.1. NAT from 6 to 4

The deployment topology that this work addresses has many v6-only hosts behind some large, carrier-grade NAT, and these hosts wish to be able to form connections to the v4 internet. This is the classic NAT64 case. The harder NAT46 case is discussed later. As shown in Figure 1, when a new connection is initiated by the host inside the NAT using internal address X1 and port x1, the NAT creates a mapping from the inside address port combination X1:x1 to some unused address and port on the outside. The external v4 address that X1:x1 was mapped to is referred to as X1':x1, and any packets that are sent to this port on the NAT are forwarded to X1:x1.

  +-------------------------------+
  |    +----------+ External v4   |
  |    |Server App|               |
  |    +----------+               |
  |    |Host OS   |               |
  |    +----------+               |
  |      Y1:y1                    |
  |                               |
  |                               |
  |      X1':x1'                  |
  |    +--------+   +-------+     |
  +----+--------+-----------------+
       | NAT64  |   | DNS64 |
  +----+--------+-----------------+
  |    +--------+   +-------+     |
  |         Internal v6           |
  |                               |
  |      X1:x1                    |
  |    +--------+                 |
  |    | Client |                 |
  |    +--------+                 |
  |    | Host OS|                 |
  |    +--------+                 |
  +-------------------------------+

The client application needs to know how to create a v6 destination address that will be routed to the v4 server. First the client application finds the v4 address of the server. One way to find the server is using a DNS query. The DNS query will go through a device that both synthesizes a DNS AAAA record for the A record and returns the A record. If the end application knows how to look at the A record directly and synthesize the v6 address to use, it can do that and continue to support features such as DNSSEC. If the application is unaware of the fact it is behind a NAT, it can use the AAAA record as a normal v6 only application would. The v6 address is formed by putting a ::FFFE:0:0/96 prefix before the v4 address. This prefix range is routed to the NAT, which can extract the v4 destination address.

The mapping from X1:x1/X1':x1' is maintained by the NAT as long as it sees periodic traffic being sent from X1:x1. This specification only defines the NAT for UDP and TCP but could be extended for other protocols that have a port multiplexing scheme. When a mapping is created for a particular port, that mapping exists for all protocols, not just the protocol that created the mapping. This greatly simplifies generating the keep alive traffic that is necessary to maintain the mapping.

2.2. NAT from 4 to 6

Making it possible for a v4 host to connect to a server on the v6 side requires more complex changes to the v6 applications than the trivial changes that were required in the 6 to 4 direction. However, many applications that usefully have a server running behind a NAT have already changed to work behind v4 to v4 NATs. The approach here is the same.

  +-------------------------------+
  |    +----------+ External v4   |
  |    |Client App|               |
  |    +----------+               |
  |    |Host OS   |               |
  |    +----------+               |
  |      Y1:y1                    |
  |                               |
  |                 +----+        |
  |      X1':x1'    |STUN|        |
  |    +--------+   +----+        |
  +----+--------+-----------------+
       | NAT    |
  +----+--------+-----------------+
  |    +--------+   Internal v6   |
  |                               |
  |                               |
  |      X1:x1                    |
  |    +--------+                 |
  |    | Server |                 |
  |    +--------+                 |
  |    | Host OS|                 |
  |    +--------+                 |
  +-------------------------------+

The server starts by creating a mapping in the NAT to a v4 address that it can use. The server does this by creating a connection to some server in the outside v4 space and having that server tell it what address and port the request came from, which reveals the external X1':x1' address port that has been mapped to the port the server is using. Typically a STUN server would be used. Note that a UDP transaction to a STUN server will allocate a mapping that can be used for incoming TCP connections. The NAT is required to run a STUN server on the external side at the address ::FFFE:127.0.0.1 on the default STUN port so the server will always be able to find a STUN server if it is behind a NAT. [[ Note - I have no idea if this address hack would work - but we can skin the cat with some other potato peeler if it does not ]]. The server needs to send periodic keep alive traffic to make sure the NAT does not remove the mapping. This can also be done with STUN.

Next the server lets the client know that it can be reached at the address port of X1':x1'. This might be done simply, such as by creating a URL that points to that location and providing it by whatever means the URL is found (email, IM, bathroom walls, whatever); or through a complex approach, such as by using a rendezvous server such as a SIP registrar or by using DNS SRV records as rendezvous servers that point at the correct address and port. At this point, a client in the v4 space can initiate a connection to the X1':x1', and this will form a connection to the server.

The applications that tend to be popular to run behind NATs are mostly P2P applications, such as file sharing and VoIP. Many of these types of applications have already undergone the changes that would be necessary to enable them to work behind a NAT such as the one described here, because these changes let them work behind v4 to v4 NATs. HTTP servers may also turn out to be valuable to run behind NATs. The use cases would likely not involve direct web page serving so much as places where a web application, such as Facebook, could make an RPC call to an application that was running on the v6 server behind the NAT. The URL that Facebook uses for the RPC calls can easily be updated by the application. This type of architecture is already becoming more common as people use virtual servers in elastic computing environments. These environments are often behind NATs to facilitate migration of virtual servers. It is worth noting, particularly for future protocol development, that if HTTP did a DNS SRV lookup, it would be possible to use DNS as the rendezvous server for a generic web browser on the v4 internet to reach a v6-only server behind the NAT.

3. Terminology

4. Mapping

When the NAT receives a packet with a source of X1:x1 from a host on the inside, the NAT first checks to see if it already has a mapping for it. If so, it resets the timer for the mapping; otherwise, it creates a new mapping. If the NAT already has any mapping from X1 to an external address X1', the external address used for this new mapping MUST be the same as the external address used for previous mappings of X1. The external address/port combination (X1':x1') allocated for the new mapping MUST NOT be in use by any other mapping. When choosing a port number for the mapping, well known port numbers MUST NOT be used.

The mappings timer MUST keep mappings for at least 10 minutes after any packet is sent from the internal host through that mapping. Note that applications should not assume that the mapping will be promptly removed after 10 minutes of inactivity, since NAT implementations often do not use a timer per mapping but instead use a periodic sweep approach to deleting mapping.

5. Packet Forwarding

5.1. UDP and TCP 6 to 4

When the NAT receives a UDP or TCP packet from the inside, it updates the mapping as described in Section 4 (Mapping), and then it extracts the external v4 address from the v6 address by striping the ::FFFE:0:0/96 prefix. Next it takes the payload section of the UDP or TCP packet and constructs a v4 UDP or TCP payload using this destination and source from the associated mapping. Then it sends the packet following the procedures defined for a host to send a UDP or TCP packet. Note that any IP options (other than fragmentation) are lost in this process; also, as defined in UDP and TCP, new checksums will be updated.

It is worth noting that the v4 destination address of the packet may be one of the external addresses of this NAT, in which case the packet is forwarded to that address and processed just like any other packet arriving at this address. Packets can therefore "hairpin" though the NAT. There is no good way to avoid this without some modifications to the applications to allow them to be aware of this and optimize around it. ICE is an example of a way applications can optimize around this hairpinning.

5.2. UDP and TCP 4 to 6

When the NAT receives a UDP or TCP packet from the outside, it checks to see if it has a mapping for the address port that the packet was received on. If it does, it uses the internal address and port associated with the mapping as the destination. It constructs a v6 UDP or TCP packet from the payload of the received packet and forwards that to the internal address. Note that checksums are updated when this new packet is created and sent.

If the NAT receives a TCP SYN packet for which there is no mapping it SHOULD silently discard it; otherwise TCP hole punching techniques using simultaneous opens will not work.

5.3. IP Fragmentation

The NAT MUST support reassembly of fragmented packets when the packets are received in order, but support for out of order fragments is OPTIONAL.

If the NAT receives a v4 packet with the do not fragment bit set, it MUST NOT forward it if the MTU of the v6 link would require the packet to be fragmented, and the NAT MUST NOT include a fragment header in the v6 packet. If the NAT receives a v4 packet that does not have the do not fragment bit set, then the packet, when forwarded, MUST include a fragment header; and if the packet is larger than the MTU, the packet MUST be appropriately fragmented. When the NAT receives a v6 packet without a fragment header, it MUST set the do not fragment bit in any v4 packets, and if the resulting v4 packet is larger than the MTU on the v4 link that will be used, the NAT MUST NOT forward the packet. When the NAT receives a v6 packet with a fragment header, it can send the v4 packet without the do not fragment bit set and can fragment the packet appropriately.

The problem with this approach is that the v6 host is likely to send packets less than 1280 octets with no fragmentation header. The v4 side will interpret these packets as being unable to be fragmented, and if they are destined for a host in which some element of the path has a shorter MTU, the packet will be discarded. The only practical way to mitigate this situation is to have the application send most of it packets with a fragmentation header, even if they are smaller than 1280 octets.

Application that support this specification, when sending to a v6 address that starts with the prefix ::FFFE:0:0/96 SHOULD include a fragment header regardless of the size of the packet.

5.4. TTL

When a packet is forwarded, the TTL is decremented by one. If it is zero, the packet is not forwarded.

5.5. DSCP

5.6. ICMP

[[ Note - this is going to be controversial. I suspect it actually goes too far but I'm deliberately presenting a pretty far out there side of the argument, in the hope that it will drive a discussion about what we really need, in practice, if we ignore IETF dogma. ]]

5.6.1. Option Yes ICMP

5.6.2. Option No ICMP

ICMP can be split into two parts, the part that reports errors for other transports and the part that supports exactly two applications, ping and traceroute. The problem with ICMP for reporting transport errors is that on today's internet ICMP is so often blocked that no application can rely on ICMP working. Applications tend to be designed to work without ICMP. NAT processing of ICMP packets is complicated because ICMP packets may contain embedded IP packets or fragments thereof. The security is further complicated by the fact that a UDP or TCP packet may cause an ICMP error to be generated by a host other than the host for which the original packet was destined. This possibility makes it difficult to determine which ICMP packets are valid and which are not. Furthermore, the way the APIs for UDP are typically used makes it hard for operating systems to notify applications of ICMP errors.

NAT processing of ICMP errors is complicated and of very limited value; for that reason forwarding ICMP error messages is OPTIONAL. Processing to allow ping and traceroute through the NAT is also OPTIONAL

5.7. IPsec

IPsec over UDP will work, but other forms of IPsec will generally not work in a reliable way.

5.8. DCCP, SCTP, etc

This specification can be extended by future specifications to support other transports but, given the immediate needs, this specification only requires support for UDP and TCP. This allows vendors that have not implemented other protocols to be compliant with this specification. No significant problems are see with using the same basic approach for DCCP.

SCTP may be more complicated. Often one of the reasons for using SCTP is to take advantage multi-homing for reliability reasons but this may require that the two SCTP sessions try and use different NATs. The requirements and deployments topologies are not clear.

6. ALGs

6.1. FTP

The deployment of personal firewalls and the misconfiguration of other firewalls has resulted in widespread breakage of active mode FTP. The general guess is that an FTP ALG will be needed to take PASV responses and turn them into EPAS responses. However, more experimentation is needed with what happens today with existing FTP clients running on v6 only hosts behind NATs to determine what is the best approach to this problem.

6.2. SIP

Many widely deployed SIP implementations work fine through NATs without requiring any ALGs. SIP was not designed to work with ALGs. More importantly, ALGs are not considered when designing new extensions to SIP and the combination of the extensions and the ALG often break badly. It is NOT RECOMMENDED for the NAT to have SIP ALGs, but if SIP ALGs are insisted upon, the best approach is to implement a dual homed proxy in the NAT that does v6 on one side and v4 on the other. This approach will be compatible with future SIP extensions and is significantly easier to correctly implement as SIP was designed so this would work.

6.3. Others

7. Helper Services

There are several services that, while not actually part of NATs, greatly facilitate being able to build applications that reliably work through NATs and should be logically, if not physically, associated with the NAT.

7.1. STUN

7.2. DNS

The NAT MUST provide a recursive DNS resolver that is capable of taking a DNS request received from the inside and resolving it on the outside.

The resolver SHOULD try to take DNS A records results from the outside and synthesize synthetic AAAA records that would be routed to the using the v6 prefix. This SHOULD NOT be done if a record exists that does not use the NAT prefix address.

7.3. DHCP

DHCP is very useful for the automated configuration of many things beyond IP addresses. [[ TODO should any particular DHCP things be required]]

7.4. V6 Routing / Tunnel

If a packet arrives from the inside with a v6 destination that is not in the ::FFFE:0:0/96 range, the NAT could/(should/may) forward this to the v6 internet. This could be via a direct v6 connection or some 646 tunnel. [[ Note not sure what to require / recommend here ]]

8. Requirement Conformance

8.1. RFC 4787 Requirements

8.2. draft-ietf-behave-tcp Requirements

NATs meeting this specification are compliant with the specification defined for [I‑D.ietf‑behave‑tcp] (Guha, S., “NAT Behavioral Requirements for TCP,” April 2007.), with the exception of Req-9, which requires ICMP, and Req-5, which requires that mapping of established TCP connections with no traffic to stay valid for 2 hours and 4 minutes, while this requires only 10 minutes.

8.3. draft-bagnulo-v6ops-6man-nat64-pb-statement Requirements

8.4. draft-nishitani-cgn Requirements

8.5. Multicast

More analysis is needed - your mileage may vary. Some important multicast applications such as an IP TV-like system that used an SSM sender in the v4 space with clients in the v6 space could probably be made to work fine, with little modification for v6-only clients. Some other multicast scenarios with senders in both the v4 and v6 space probably would not work.

9. IANA Considerations

Open Issues: What prefix to use. We will want to allocate a different prefix than the ::FFFE:0:0/96. This draft makes no argument about which prefix would be best, it just requires that the specification define some fixed prefix to use.

10. Security Considerations

Often NATs are combined with firewalls that perform address-dependent filtering (as defined in [RFC4787] (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.)) to improve security. The type of NAT envisioned here is a large, carrier-grade NAT with many clients behind it. Performing firewall operations at this location in the topology is not particularly effective because the attacker may well be on the "inside". The firewall capabilities should be provided much closer to the host being protected. The benefit of having mappings with address-independent filtering is that it make it possible to easily run servers inside the NAT with no modification of the clients outside the NAT. For this reason, this specification adopts a NAT design with address-independent filtering.

One of the concerns about a large scale NAT that a single host inside the NAT might be able to perform a DOS attack by using up a large portion of the available external ports simply by creating many mappings. To mitigate this, the NAT SHOULD allow a configurable limit to the number of mappings that can be created by a single host inside the NAT.

11. Acknowledgements

Thanks to Dave Ward who pointed out that I and others were spending too much time making this complicated and should stop talking and get on with writing some drafts. Thanks for helpful comments from Mangus Westerlud, Iljitsch van Beijnum, and .

12. References

12.1. Normative References

12.2. Informative References

Author's Address

Full Copyright Statement

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

[I-D.ietf-behave-rfc3489bis]	Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for (NAT) (STUN),” draft-ietf-behave-rfc3489bis-16 (work in progress), July 2008 (TXT).
[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2765]	Nordmark, E., “Stateless IP/ICMP Translation Algorithm (SIIT),” RFC 2765, February 2000 (TXT).

[I-D.bagnulo-v6ops-6man-nat64-pb-statement]	Bagnulo, M. and F. Baker, “IPv4/IPv6 Coexistence and Transition: Requirements for solutions,” draft-bagnulo-v6ops-6man-nat64-pb-statement-01 (work in progress), February 2008 (TXT).
[I-D.ietf-behave-tcp]	Guha, S., “NAT Behavioral Requirements for TCP,” draft-ietf-behave-tcp-07 (work in progress), April 2007 (TXT).
[I-D.nishitani-cgn]	Nishitani, T. and S. Miyakawa, “Carrier Grade Network Address Translator (NAT) Behavioral Requirements for Unicast UDP, TCP and ICMP,” draft-nishitani-cgn-00 (work in progress), July 2008 (TXT).
[RFC2983]	Black, D., “Differentiated Services and Tunnels,” RFC 2983, October 2000 (TXT).
[RFC4787]	Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” BCP 127, RFC 4787, January 2007 (TXT).

	Cullen Jennings
	Cisco Systems
	170 West Tasman Drive
	Mailstop SJC-21/2
	San Jose, CA 95134
	USA
Phone:	+1 408 902-3341
Email:	fluffy@cisco.com

NAT for IPv6-Only Hostsdraft-jennings-behave-nat6-01

Status of this Memo