< draft-ietf-nat-app-guide-06.txt		draft-ietf-nat-app-guide-07.txt >
	NAT Working Group D. Senie		A new Request for Comments is now available in online RFC libraries.
	INTERNET-DRAFT Amaranth Networks Inc.
	Category: Informational June 2001
	Expires in six months
	NAT Friendly Application Design Guidelines
	draft-ietf-nat-app-guide-06.txt
	Status of this Memo
	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/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Copyright Notice
	Copyright (C) The Internet Society (1999-2001). All Rights Reserved.
	Preface:
	While many common Internet applications will operate cleanly in the
	presence of Network Address Translators, others suffer from a variety
	of problems when crossing these devices. This document discusses
	those things that application designers might wish to consider when
	designing new protocols. Guidelines are presented herein to help
	ensure new protocols and applications will, to the extent possible,
	be compatible with NAT.
	1. Introduction
	Other documents that describe Network Address Translation (NAT)
	discuss the Terminology and Considerations [RFC2663] and Protocol
	Issues [RFC3022], [RFC3027] or discuss the implications of NAT
	[RFC2993]. All of those relate to various issues with the NAT
	mechanism, effects on protocols and effects upon general Internet
	architecture.
	It is the focus of this document to provide recommendations to
	authors of new protocols about the effects to consider when designing
	new protocols such that special handling is not required at NAT
	gateway points.
	When a protocol is unable to pass cleanly through a NAT, the use of
	an Application Level Gateway (ALG) may still permit operation of the
	protocol. Depending on the encoding used in a protocol, an ALG may
	be difficult or easy to construct, though in some cases it may not be
	possible at all. While adjunct to NAT, the formulation of protocols
	that cannot directly operate through NAT should be considered such
	that the ALG design may be simple and automated. ALGs typically
	operate inside small routers along with the NAT component. Ideally,
	the ALG should be simple and not require excessive computation or
	state storage.
	Many of the same issues in application design that create issues for
	NAT (and thus can require ALG support) are also issues for firewalls.
	An application designer would do well to keep this in mind, as any
	protocol that does require special handling by NAT or firewall
	products will be more difficult to deploy than those that require no
	special handling.
	2. Discussion
	Network Address Translation presents a challenge to some existing
	applications. In many cases, it should be possible for developers of
	new applications to avoid problems if they understand the issues.
	This document aims to provide the application designer with
	information on what things they can do and what to avoid when trying
	to build applications that are able to function across NAT.
	The proliferation of NAT, especially in homes and small offices
	cannot be dismissed. The marketing of these technologies to homes and
	small businesses is often focused on a single-computer environment,
	and thus providers only give out a single IP address to each user.
	NAT has become a popular choice for connecting more than a single
	system per location.
	Clearly the most common problem associated with NAT implementations
	is the passing of addressing data between stations. Where possible,
	applications should find alternatives to such schemes. Studying a few
	existing protocols will serve to highlight the different approaches
	possible.
	Two common forms of Traditional NAT exist. With Basic NAT, only the
	IP addresses of packets are altered by the NAT implementation. Many
	applications will operate correctly with Basic NAT. The other common
	form is Network Address Port Translation. With NAPT, both the IP
	addresses and the source and destination ports (for TCP and UDP) are
	potentially altered by the gateway. As such, applications passing
	only port number information will work with Basic NAT, but not with
	NAPT.
	Application designers should strive for compatibility with NAPT, as
	this form of NAT is the most widely deployed. This is also the form
	of NAT that will likely see the greatest penetration in homes and
	small offices. Not all applications lend themselves to the
	architectural model imposed by NAPT.
	3. Recommendations and Examples
	Application designers who work within the constraints of NAT, and who
	do not rely on the presence of ALGs will generally find the easier
	acceptance in user communities where NAT is common. When designing a
	new application or service, the requirement for an ALG will limit
	deployment until the required additional code is incorporated into
	the many devices which implement NAT.
	Each of the areas called out below are examples of issues to consider
	when building an application. This list is likely not comprehensive,
	but does cover a number of important issues and considerations.
	3.1 Issues and Recommendations affecting all types of Network
	Address Translators
	3.1.1. Peer-to-Peer Applications Limitations
	Peer to peer applications are problematic in a NAT world. Client-
	server applications are more generally workable. Peer-to-peer
	applications rely on each peer being reachable as a server (i.e.
	bound to a listening port, and able to accept connections) for the
	other to connect to. With NAPT, there are likely many machines
	behind one address. With other types of NAT such as one-to-one
	mappings, there is a greater chance of making such applications
	work.
	Some implementations of NAT can be made to function for UDP-based
	peer-to-peer applications. This capability is dependent on the
	methodology used to implement the UDP sessions in the NAT device.
	If the NAT device tracks the tuple (private address, private port,
	public port) then it is possible for an outbound UDP packet to
	establish a channel by which incoming traffic can flow from a
	source other than that originally contacted by the system. NAT
	devices which track source and destination IP addresses, in
	addition to port numbers, will not permit third-party packets. NAT
	is often implemented in conjunction along with stateful-inspection
	firewall functionality. As such the latter implementation of UDP
	association tracking would be considered more secure.
	NAT/Firewall device implementations could be constructed to have a
	software switch within them, permitting the consumer the ability
	to select whether they want the greater security, or greater
	ability to run peer-to-peer applications.
	3.1.2. Applications Requiring End-to-End IPSec Will Fail
	Use of IPSec for end-to-end security will not function in the
	presence of a NAT implementation. Application designers may want
	to explore the use of TLS as a mechanism that will traverse NAT
	cleanly. See [RFC2709] for additional discussion on combining NAT
	with Tunnel-mode IPSec security on the same device.
	Some vendors have implemented a pass-through capability which
	permits IPSec tunnel mode from a client in the private realm to
	communicate with an endpoint in the public realm.
	3.1.3. Use DNS Names, Not IP Addresses In Payload
	Applications should, where possible, use fully qualified domain
	names rather than IP addresses when referring to IP endpoints.
	When endpoints are across a NAT gateway, private addresses must
	not be allowed to leak to the other endpoint. An example of where
	this can happen today is with the HTTP and HTML protocols. It is
	possible for web pages to be specified with numeric IP addresses,
	rather than with names, for example http://192.168.1.10/index.html
	could be used as a URL, but would likely create a problem if this
	address is on a server located behind a NAT gateway. Users outside
	the gateway would not be able to reach the address 192.168.1.10,
	and so would not see the page.
	Further exacerbating the problem is the possibility of duplicate
	addresses between realms. If a server offers a link with a private
	address space IP address embedded within it, such as 192.168.1.10,
	the page referenced may resolve to a system on the local network
	the browser is on, but would be a completely different server. The
	resulting confusion to end-users would be significant. Sessions
	involving multiple NAT implementations would be exceptionally
	vulnerable to address reuse issues of this sort.
	3.1.4. Multicast Considerations
	Not all NAT devices implement multicast routing protocols.
	Application designers should verify whether the devices in the
	networks where their applications will be deployed are able to
	process multicast traffic if their applications rely on that
	capability.
	3.1.5. Retention Of Address Mapping
	With the exception of statically configured NAT bindings,
	applications should not assume address mapping will be maintained
	from one session (association between machines, for whatever
	protocol for a period of time) to another. An example of this is
	RSVP, which forms one connection to reserve the resources, then
	the actual session for which resources were reserved is started.
	The sessions do not necessarily overlap. There is no guarantee
	that the NAT implementation will keep the binding association. As
	such, applications that rely on subsequent sessions being mapped
	to the same destination system may not function without an ALG.
	Another consideration is the number of addressing realms. It is
	entirely possible to have multiple levels of NAT implementations
	between the two end points involved. As such, one must think about
	the lifetime of such mappings at all such levels.
	Load balancers and other devices may use a single IP address and
	port to map to multiple actual end points. Many products implement
	variations on this theme, sometimes using NAT, sometimes using
	other technologies. The lack of guarantee of mapping is important
	to understand, since the mapping to one actual system to another
	may not survive across such intermediate boxes.
	Don't assume systems know their own IP addresses. A system behind
	a NAT may be reachable via a particular IP address, but that
	address may not be recognized by the system itself. Similarly,
	such systems may not know their own DNS names.
	3.2 Recommendations for NAPT
	As many of the issues specifically address NAPT issues, this
	section will group these issues. NAPT is the most common form of
	NAT in actual deployment in routers, especially in smaller offices
	and home offices.
	3.2.1 IP Addresses Specific To A Realm
	Avoid the use of IP address and port number information within the
	payload of packets. While in some cases ALGs will permit such
	protocols to function, this presupposes every NAT device can be
	updated in a timely fashion to support a new protocol. Since this
	is unlikely, application writers are urged to avoid addressing
	information in payloads all together.
	In addition to avoiding addresses and port numbers within packet
	payloads, it is important to avoid assumptions of (address, port)
	tuples are unique. Load balancing devices break this assumption.
	3.2.2 Avoid Session Bundles
	Independent sessions, such as used by HTTP, are preferred to
	protocols that attempt to manage a bundle of related sessions,
	such as FTP. The term "session" here is used to refer to any
	association between end systems, and may be using any transport
	protocol or combination of protocols (UDP, TCP, SCTP).
	In the FTP protocol, port information is passed over one TCP
	connection and is used to construct a second TCP connection for
	passing the actual data. Use of a separate connection to transfer
	the file data makes determination of file end quite simple,
	however other schemes could be envisioned which could use a single
	connection.
	The HTTP protocol, for example, uses a header and content length
	approach to passing data. In this model, all data is transferred
	over the single TCP connection, with the header portion indicating
	the length of the data to follow. HTTP has evolved to allow
	multiple objects to be passed on a single connection (thereby
	cutting the connection establishment overhead). Clearly a new file
	transfer function could be built that would perform most of the
	functions of FTP without the need for additional TCP connections.
	The goal is to keep to single connections where possible. This
	keeps us from needing to pass addressing information of any sort
	across the network. However, multiplexing traffic over a single
	connection can create problems as well.
	3.2.3. Session Bundles Originate From Same End
	Origination of connections is an important consideration. Where
	possible, the client should originate all connections. The FTP
	protocol is the most obvious example, where by default the server
	opens the data connection to a port on the client (the client
	having specified the port number via a PORT command over the
	control TCP session).
	As pointed out in [RFC1579], the use of the passive open option in
	FTP (PASV) remedies this situation as the client is responsible
	for opening the connection in this case. With client-opened
	connections, the standard functions of NAPT will process the
	request as it would any other simple TCP connection, and so an ALG
	is not required.
	In cases where session bundles are unavoidable, each session in
	the bundle should originate from the same end station.
	3.2.4. TCP preferred over UDP
	NAPT gateways must track which sessions are alive, and flush old
	sessions. TCP has clear advantages in this area, since there are
	specific beginning and end of session indicators in the packets
	(SYN and FIN packets). While UDP works for some types of
	applications with NAT, there can be issues when that data is
	infrequent. Since there is no clean way to know when an end
	station has finished using a UDP session, NAT implementations use
	timeouts to guess when a UDP session completes. If an application
	doesn't send data for a long period of time, the NAT translation
	may time out.
	NAT implementations will also use timers to guess when TCP
	sessions have disappeared as well. While TCP sessions should
	disappear only after FIN packets are exchanged, it is possible
	that such packets may never come, for example if both end stations
	die. As such, the NAT implementation must use a timer for cleaning
	up its resources.
	NAT implementers in many cases provide several timeouts, one for
	live TCP sessions, one for TCP sessions on which a FIN has been
	seen, and one for UDP sessions. It is best when such flexibility
	is provided, but some implementations appear to apply a single
	timer to all traffic.
	Protocols other than TCP and UDP can work with Traditional NAT in
	many cases, provided they are not carrying addressing information.
	For NAPT implementations Use of any protocols other than TCP and
	UDP will be problematic unless or until such protocols are
	programmed into the implementations.
	It's important to note that NAT deployments are based on the
	assumption of a client-server application model, with the clients
	in the private realm.
	3.2.5. IP Fragmentation
	Applications should attempt to avoid fragmentation when packets
	pass over NAPT devices. While not always practical or possible,
	there are failures that can occur with NAPT. Specifically, if two
	stations in the private realm pick matching fragmentation
	identifiers, and talk to the same remote host, it may be
	impossible to determine which fragments belong to which session. A
	clever NAPT implementation could track fragmentation identifiers
	and map those into a unique space, though it is not clear how many
	do so.
	Ideally, applications should limit packet size, use Path MTU
	Discovery or both. Unfortunately, at least some firewall/NAT
	devices block Path MTU Discovery, apparently believing all ICMP
	packets are evil.
	Some implementations of NAT may implement fragment reassembly
	prior to Forwarding, however many do not. Application designers
	are advised to design assuming the devices do not reassemble
	fragments.
	3.3 Issues and recommendations for Basic NAT
	If only Basic NAT implementations are involved, not NAPT, then
	many of the issues above do not apply. This is not to say that
	this form of NAT is better or worse than NAPT. Application
	designers may think they could just specify users must use Basic
	NAT, and many application issues would go away. This is
	unrealistic, however, as many users have no real alternative to
	NAPT due to the way their providers sell service.
	Many of the issues raised earlier still apply to Basic NAT, and
	many protocols will not function correctly without assistance.
	3.3.1. Use IP and TCP/UDP Headers Alone
	Applications that use only the information in the IP and TCP or
	UDP headers for communication (in other words, do not pass any
	additional addressing information in the payload of the packets),
	are clearly easier to support in a NAT environment. Where
	possible, applications designers should try to limit themselves in
	this area.
	This comes back to the same recommendation made for NAPT, that
	being to use a single connection whenever possible.
	The X windowing system, for example, uses fixed port numbers to
	address X servers. With X, the server (display) is addressed via
	ports 6000 through 6000 + n. These map to hostname:0 through
	hostname:n server displays. Since only the address and port are
	used, the NAT administrator could map these ports to one or more
	private addresses, yielding a functioning solution.
	The X example, in the case of NAPT, requires configuration of the
	NAT implementation. This results in the ability for no more than
	one station inside the NAT gateway to use such a protocol. This
	approach to the problem is thus OK for NAT but not recommended for
	NAPT environments.
	3.3.2. Avoid Addressing In Payload
	As with NAPT, transporting IP address and/or port number
	information in the payload is likely to cause trouble. As stated
	earlier, load balancers and similar platforms may well map the
	same IP address and port number to a completely different system.
	Thus it is problematic to assume an address or port number which
	is valid in the realm on one side of a NAT is valid on the other
	side.
	3.4 Bi-directional NAT
	Bi-directional NAT makes use of DNS mapping of names to point
	sessions originating outside the private realm to servers in the
	private realm. Through use of a DNS-ALG [RFC2694], lookups are
	performed to find the proper host and packets are sent to that
	host.
	Requirements for applications are the same as for Basic NAT.
	Addresses are mapped one-to-one to servers. Unlike Traditional NAT
	devices, Bi-directional NAT devices (in conjunction with DNS-ALG)
	are amenable to peer-to-peer applications.
	3.5 Twice NAT
	Twice NAT is address translation where both source and destination
	IP addresses are modified due to addressing conflicts between two
	private realms. Two bi-directional NAT boxes connected together
	would essentially perform the same task, though a common address
	space that is not otherwise used by either private realm would be
	required.
	Requirements for applications to work in the Twice NAT environment
	are the same as for Basic NAT. Addresses are mapped one to one.
	3.6 Multi-homed NAT
	Multi-homed NAT is the use of multiple NAT implementations to
	provide redundancy. The multiple implementations share
	configuration information so that sessions might continue in the
	event of a fail-over. Unless the multiple implementations share
	the same external addresses, sessions will have to restart
	regardless.
	Requirements for multi-homed NAT are the same as for Basic NAT or
	NAPT, depending on how the multi-homed NAT is implemented and
	configured.
	3.7 Realm Specific IP (RSIP)
	Realm Specific IP is described in [RFC2663] and defined in [RSIP]
	and related documents. Clients within a private realm using RSIP
	are aware of the delineation between private and public, and
	access a server to allocate address (and optionally port)
	information for use in conversing with hosts in the public realm.
	By doing this, clients create packets that need not be altered by
	the RSIP server on their way to the remote host. This technique
	can permit IPSec to function, and potentially makes any
	application function as if there were no special processing
	involved at all.
	RSIP uses a view of the world in which there are only two realms,
	the private and public. This isn't always the case. Situations
	with multiple levels of NAT implementations are growing. For
	example, some ISPs are handing out [RFC1918] addresses to their
	dialup users, rather than obtaining real addresses. Any user of
	such an ISP who also uses a NAT implementation will see two levels
	of NAT, and the advantages of RSIP will have been wasted.
	3.8 Performance Implications of Address Translation Implementations
	Resource utilization on the NAT gateway should be considered. An
	application that opens and closes many TCP connections, for
	example, will use up more resources on the NAT router than an
	application performing all transfers over a single TCP connection.
	HTTP 1.0 opened a connection for each object on a web page,
	whereas HTTP 1.1 permits the TCP session to be held open for
	additional objects that may need to be transferred. Clearly the
	latter imposes a lower overhead on the NAT gateway, as it is only
	maintaining state on a single connection instead of multiple
	connections.
	New session establishment will typically remain a software
	function even in implementations where the packet-by-packet
	translation work is handled by hardware forwarding engines. While
	high-performance NAT boxes may be built, protocols that open many
	sessions instead of multiplexing will be slower than those that do
	not.
	Applications with different types of data, such as interactive
	conferencing, require separate streams for the different types of
	data. In such cases the protocol needs of each stream must be
	optimized. While the goal of multiplexing over a single session is
	preferred, clearly there are cases where this is impractical.
	The latency of NAT translation overhead is implementation
	dependent. On a per-packet basis, for established sessions only
	the source or destination IP address is replaced, the source or
	destination port (for NAPT) and the checksums for IP, and TCP or
	UDP are recalculated. The functionality can be efficiently
	implemented in hardware or software.
	4. Security Considerations
	Network Address Translators have implications for IPSec, as noted
	above. When application developers are considering whether their
	applications function with NAT implementations, care should be given
	to selection of security methodology. Transport Layer Security (TLS)
	[RFC2246] operates across translation boundaries. End-to-end IPSec
	will prove problematic in many cases.
	5. References
	[RFC1579] S. Bellovin, "Firewall Friendly FTP," RFC 1579, February
	1994.
	[RFC2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0," RFC
	2246, January 1999.
	[RFC2993] T. Hain, "Architectural Implications of NAT," RFC 2993,
	November 2000.
	[RFC3027] M. Holdrege, P. Srisuresh, "Protocol Complications with the		RFC 3235
	IP Network Address Translator (NAT)," RFC 3027, January 2001.
	[RFC2663] P. Srisuresh, M. Holdrege, "IP Network Address Translator		Title: Network Address Translator (NAT)-Friendly
	(NAT) Terminology and Considerations," RFC 2663, August 1999.		Application Design Guidelines
			Author(s): D. Senie
			Status: Informational
			Date: January 2002
			Mailbox: dts@senie.com
			Pages: 13
			Characters: 29588
			Updates/Obsoletes/SeeAlso: NONE
	[RFC2709] P. Srisuresh, "Security Model with Tunnel-mode IPsec for		I-D Tag: draft-ietf-nat-app-guide-07.txt
	NAT Domains," RFC 2709, October 1999.
	[RSIP] M. Borella, et. al., "Realm Specific IP: Framework," <draft-		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3235.txt
	ietf-nat-rsip-framework-05.txt> - Work In Progress.
	[RFC3022] P. Srisuresh, K. Egevang, "Traditional IP Network Address		This document discusses those things that application designers might
	Translator (Traditional NAT)," RFC 3022, January 2001.		wish to consider when designing new protocols. While many common
			Internet applications will operate cleanly in the presence of Network
			Address Translators, others suffer from a variety of problems when
			crossing these devices. Guidelines are presented herein to help
			ensure new protocols and applications will, to the extent possible, be
			compatible with NAT (Network Address Translation).
	[RFC2694] P. Srisuresh, et. al., "DNS extensions to Network Address		This document is a product of the Network Address Translators Working
	Translators (DNS_ALG)," RFC 2694, September 1999.		Group of the IETF.
	6. Acknowledgements		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	I'd like to thank Pyda Srisuresh for his invaluable input and		This announcement is sent to the IETF list and the RFC-DIST list.
	feedback, and Keith Moore for his extensive comments.		Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	7. Author's Address		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	Daniel Senie		To: rfc-info@RFC-EDITOR.ORG
	Amaranth Networks Inc.		Subject: getting rfcs
	324 Still River Road
	Bolton, MA 01740
	Phone: (978) 779-6813		help: ways_to_get_rfcs
	EMail: dts@senie.com		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	534 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/