draft-ietf-behave-nat-udp-07.txt		draft-ietf-behave-nat-udp-08.txt
	BEHAVE F. Audet, Ed.		BEHAVE F. Audet, Ed.
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: December 2, 2006 C. Jennings		Intended status: Standards Track C. Jennings
	Cisco Systems		Expires: April 13, 2007 Cisco Systems
	May 31, 2006		October 10, 2006
	NAT Behavioral Requirements for Unicast UDP		NAT Behavioral Requirements for Unicast UDP
	draft-ietf-behave-nat-udp-07		draft-ietf-behave-nat-udp-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 2, 2006.		This Internet-Draft will expire on April 13, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document defines basic terminology for describing different		This document defines basic terminology for describing different
	types of NAT behavior when handling Unicast UDP and also defines a		types of NAT behavior when handling Unicast UDP and also defines a
	set of requirements that would allow many applications, such as		set of requirements that would allow many applications, such as
	skipping to change at page 2, line 15		skipping to change at page 2, line 15
	Table of Contents		Table of Contents
	1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3		1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Network Address and Port Translation Behavior . . . . . . . . 5		4. Network Address and Port Translation Behavior . . . . . . . . 5
	4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5		4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5
	4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 8		4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 8
	4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 8		4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 8
	4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10		4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10
	4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 10		4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 11
	4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11		4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11
	4.4. Conflicting Internal and External IP Address Spaces . . . 12		4.4. Conflicting Internal and External IP Address Spaces . . . 13
	5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14		5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14
	6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 15		6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16
	7. Application Level Gateways . . . . . . . . . . . . . . . . . . 16		7. Application Level Gateways . . . . . . . . . . . . . . . . . . 17
	8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17		8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17
	9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 18		9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 19
	10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19		10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19
	11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 19		11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20
	12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20		12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 22		13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23		15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24
	16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 24		17.1. Normative References . . . . . . . . . . . . . . . . . . . 25
	17.2. Informational References . . . . . . . . . . . . . . . . . 25		17.2. Informational References . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . . . 29		Intellectual Property and Copyright Statements . . . . . . . . . . 29
	1. Applicability Statement		1. Applicability Statement
	The purpose of this specification is to define a set of requirements		The purpose of this specification is to define a set of requirements
	for NATs that would allow many applications, such as multimedia		for NATs that would allow many applications, such as multimedia
	communications or on-line gaming, to work consistently. Developing		communications or on-line gaming, to work consistently. Developing
	NATs that meet this set of requirements will greatly increase the		NATs that meet this set of requirements will greatly increase the
	likelihood that these applications will function properly.		likelihood that these applications will function properly.
	The requirements of this specification apply to Traditional NATs as		The requirements of this specification apply to Traditional NATs as
	described in [RFC2663].		described in [RFC2663].
	This document is meant to cover NATs of any size, from small		This document is meant to cover NATs of any size, from small
	residential NATs to large Enterprise NATs. However, it should be		residential NATs to large Enterprise NATs. However, it should be
	understood that Enterprise NATs normally provide much more than just		understood that Enterprise NATs normally provide much more than just
	NAT capabilities: for example, they typically provide firewall		NAT capabilities: for example, they typically provide firewall
	functionalities. Firewalls are specifically out-of-scope for this		functionalities. A comprehensive description of firewall behaviors
	specification; however, this specification does cover the inherent		and associated requirements is specifically out-of-scope for this
	filtering aspects of NATs which may resemble firewall operation.		specification. However, this specification does cover basic firewall
			aspects present in NATs (see Section 5).
	Approaches using directly signaled control of middle boxes are out of		Approaches using directly signaled control of middle boxes are out of
	scope.		scope.
	UDP Relays (e.g., TURN [I-D.ietf-behave-turn]) are out-of-scope.		UDP Relays (e.g., TURN [I-D.ietf-behave-turn]) are out-of-scope.
	Application aspects are out-of-scope, as the focus here is strictly		Application aspects are out-of-scope, as the focus here is strictly
	on the NAT itself.		on the NAT itself.
	This document only covers aspects of NAT traversal related to Unicast		This document only covers aspects of NAT traversal related to Unicast
	skipping to change at page 6, line 39		skipping to change at page 6, line 40
	...........| NAT |...............		...........| NAT |...............
	+--+---+-+ I		+--+---+-+ I
	| | n		| | n
	X:x | | X:x t		X:x | | X:x t
	++---++ e		++---++ e
	| X | r		| X | r
	+-----+ n		+-----+ n
	a		a
	l		l
			Address and Port Mapping
	The following address and port mapping behavior are defined:		The following address and port mapping behavior are defined:
	Endpoint Independent Mapping:		Endpoint Independent Mapping:
	The NAT reuses the port mapping for subsequent packets sent		The NAT reuses the port mapping for subsequent packets sent
	from the same internal IP address and port (X:x) to any		from the same internal IP address and port (X:x) to any
	external IP address and port. Specifically, X1':x1' equals		external IP address and port. Specifically, X1':x1' equals
	X2':x2' for all values of Y2:y2.		X2':x2' for all values of Y2:y2.
	Address Dependent Mapping:		Address Dependent Mapping:
	The NAT reuses the port mapping for subsequent packets sent		The NAT reuses the port mapping for subsequent packets sent
	skipping to change at page 8, line 43		skipping to change at page 8, line 50
	...........| NAT |...............		...........| NAT |...............
	+--+---+--+ I		+--+---+--+ I
	| | n		| | n
	+---------+ +---------+ t		+---------+ +---------+ t
	| X1:x1 X2':x2 | e		| X1:x1 X2':x2 | e
	+---+---+ +---+---+ r		+---+---+ +---+---+ r
	| X1 | | X2 | n		| X1 | | X2 | n
	+-------+ +-------+ a		+-------+ +-------+ a
	l		l
			Port Assignment
	Some NATs attempt to preserve the port number used internally when		Some NATs attempt to preserve the port number used internally when
	assigning a mapping to an external IP address and port (e.g.,		assigning a mapping to an external IP address and port (e.g.,
	x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A		x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A
	basic NAT, for example, will preserve the same port and will assign a		basic NAT, for example, will preserve the same port and will assign a
	different IP address from a pool of external IP addresses in case of		different IP address from a pool of external IP addresses in case of
	port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only		port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only
	possible as long as the NAT has enough external IP addresses. If the		possible as long as the NAT has enough external IP addresses. If the
	port x is already in use on all available external IP addresses, then		port x is already in use on all available external IP addresses, then
	the NAT needs to switch from Basic NAT to Network Address and Port		the NAT needs to switch from Basic NAT to Network Address and Port
	Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or		Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or
	skipping to change at page 9, line 41		skipping to change at page 9, line 49
	from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/		from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/
	private" from 49152 through 65535. For most protocols, these are		private" from 49152 through 65535. For most protocols, these are
	destination ports and not source ports, so mapping a source port to a		destination ports and not source ports, so mapping a source port to a
	source port that is already registered is unlikely to have any bad		source port that is already registered is unlikely to have any bad
	effects. Some NATs may choose to use only the ports in the dynamic		effects. Some NATs may choose to use only the ports in the dynamic
	range; the only down side of this practice is that it limits the		range; the only down side of this practice is that it limits the
	number of ports available. Other NAT devices may use everything but		number of ports available. Other NAT devices may use everything but
	the well-known range and may prefer to use the dynamic range first or		the well-known range and may prefer to use the dynamic range first or
	possibly avoid the actual registered ports in the registered range.		possibly avoid the actual registered ports in the registered range.
	Other NATs preserve the port range if it is in the well-known range.		Other NATs preserve the port range if it is in the well-known range.
			[RFC0768] specifies that the source port is set to zero if no reply
			packet are expected. In this case it does not matter what the NAT
			maps it to as the source port will not be used. However, many common
			OS APIs do not allow a user to send from port zero, applications do
			not use port zero, and the behavior of various existing NATs with
			regards to a packet with a source of port zero is unknown. This
			document does not specify any normative behavior for a NAT when
			handling a packet with a source port of zero which means that
			applications can not count on any sort of deterministic behavior for
			these packets.
	REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port		REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
	overloading".		overloading".
	a) If the host's source port was in the range 1-1023, it is		a) If the host's source port was in the range 0-1023, it is
	RECOMMENDED the NAT's source port be in the same range. If the		RECOMMENDED the NAT's source port be in the same range. If the
	host's source port was in the range 1024-65535, it is		host's source port was in the range 1024-65535, it is
	RECOMMENDED that the NAT's source port be in that range.		RECOMMENDED that the NAT's source port be in that range.
	Justification: This requirement must be met in order to enable two		Justification: This requirement must be met in order to enable two
	applications on the internal side of the NAT both to use the same		applications on the internal side of the NAT both to use the same
	port to try to communicate with the same destination. NATs that		port to try to communicate with the same destination. NATs that
	implement port preservation have to deal with conflicts on ports,		implement port preservation have to deal with conflicts on ports,
	and the multiple code paths this introduces often result in		and the multiple code paths this introduces often result in
	nondeterministic behavior. However, it should be understood that		nondeterministic behavior. However, it should be understood that
	skipping to change at page 10, line 38		skipping to change at page 11, line 5
	an implementation receives an odd RTP port number from the peer		an implementation receives an odd RTP port number from the peer
	(perhaps after having been translated by a NAT), and then follows the		(perhaps after having been translated by a NAT), and then follows the
	RFC 3550 rule to change the RTP port to the next lower even number,		RFC 3550 rule to change the RTP port to the next lower even number,
	this would obviously result in the loss of RTP. NAT-friendly		this would obviously result in the loss of RTP. NAT-friendly
	application aspects are outside the scope of this document. It is		application aspects are outside the scope of this document. It is
	expected that this issue will fade away with time, as implementations		expected that this issue will fade away with time, as implementations
	improve. Preserving the port parity allows for supporting		improve. Preserving the port parity allows for supporting
	communication with peers that do not support explicit specification		communication with peers that do not support explicit specification
	of both RTP and RTCP port numbers.		of both RTP and RTCP port numbers.
	REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation"		REQ-4: It is RECOMMENDED that a NAT have a "Port parity
	behavior of "Yes".		preservation" behavior of "Yes".
	Justification: This is to avoid breaking peer-to-peer applications		Justification: This is to avoid breaking peer-to-peer applications
	which do not explicitly and separately specify RTP and RTCP port		which do not explicitly and separately specify RTP and RTCP port
	numbers and which follow the RFC 3550 rule to decrement an odd RTP		numbers and which follow the RFC 3550 rule to decrement an odd RTP
	port to make it even. The same considerations as per the IP		port to make it even. The same considerations as per the IP
	address pooling requirement apply.		address pooling requirement apply.
	4.2.3. Port Contiguity		4.2.3. Port Contiguity
	Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1.		Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1.
	skipping to change at page 11, line 36		skipping to change at page 12, line 4
	The mapping timer is defined as the time a mapping will stay active		The mapping timer is defined as the time a mapping will stay active
	without packets traversing the NAT. There is great variation in the		without packets traversing the NAT. There is great variation in the
	values used by different NATs.		values used by different NATs.
	REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2		REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
	minutes, unless REQ-5a applies.		minutes, unless REQ-5a applies.
	a) For specific destination ports in the well-known port range		a) For specific destination ports in the well-known port range
	(ports 0-1023), a NAT MAY have shorter UDP mapping timers that		(ports 0-1023), a NAT MAY have shorter UDP mapping timers that
	are specific to the IANA-registered application running over		are specific to the IANA-registered application running over
	that specific destination port.		that specific destination port.
	b) The value of the NAT UDP mapping timer MAY be configurable.		b) The value of the NAT UDP mapping timer MAY be configurable.
	c) A default value of 5 minutes or more for the NAT UDP mapping		c) A default value of 5 minutes or more for the NAT UDP mapping
	timer is RECOMMENDED.		timer is RECOMMENDED.
	Justification: This requirement is to ensure that the timeout is long		Justification: This requirement is to ensure that the timeout is
	enough to avoid too frequent timer refresh packets.		long enough to avoid too frequent timer refresh packets.
	a) Some UDP protocols using UDP use very short-lived connections.		a) Some UDP protocols using UDP use very short-lived connections.
	There can be very many such connections; keeping them all in a		There can be very many such connections; keeping them all in a
	connections table could cause considerable load on the NAT.		connections table could cause considerable load on the NAT.
	Having shorter timers for these specific applications is		Having shorter timers for these specific applications is
	therefore an optimization technique. It is important that the		therefore an optimization technique. It is important that the
	shorter timers applied to specific protocols be used sparingly,		shorter timers applied to specific protocols be used sparingly,
	and only for protocols using well-known destination port that		and only for protocols using well-known destination port that
	are known to have a shorter timer, and that are known not to be		are known to have a shorter timer, and that are known not to be
	used by any applications for other purposes.		used by any applications for other purposes.
	b) Configuration is desirable for adapting to specific networks		b) Configuration is desirable for adapting to specific networks
	and troubleshooting.		and troubleshooting.
	c) This default is to avoid too frequent timer refresh packets.		c) This default is to avoid too frequent timer refresh packets.
	Some NATs keep the mapping active (i.e., refresh the timer value)		Some NATs keep the mapping active (i.e., refresh the timer value)
	when a packet goes from the internal side of the NAT to the external		when a packet goes from the internal side of the NAT to the external
	side of the NAT. This is referred to as having a NAT Outbound		side of the NAT. This is referred to as having a NAT Outbound
	refresh behavior of "True".		refresh behavior of "True".
	Some NATs keep the mapping active when a packet goes from the		Some NATs keep the mapping active when a packet goes from the
	skipping to change at page 16, line 16		skipping to change at page 16, line 33
	+----+ from X1:x1 to X2':x2' +-----+ X1':x1'		+----+ from X1:x1 to X2':x2' +-----+ X1':x1'
	| X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---		| X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
	+----+ | v |		+----+ | v |
	| v |		| v |
	| v |		| v |
	| v |		| v |
	+----+ from X1':x1' to X2:x2 | v | X2':x2'		+----+ from X1':x1' to X2:x2 | v | X2':x2'
	| X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---		| X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
	+----+ +-----+		+----+ +-----+
			Hairpinning Behavior
	Hairpinning allows two endpoints on the internal side of the NAT to		Hairpinning allows two endpoints on the internal side of the NAT to
	communicate even if they only use each other's external IP addresses		communicate even if they only use each other's external IP addresses
	and ports.		and ports.
	More formally, a NAT that supports hairpinning forwards packets		More formally, a NAT that supports hairpinning forwards packets
	originating from an internal address, X1:x1, destined for an external		originating from an internal address, X1:x1, destined for an external
	address X2':x2' that has an active mapping to an internal address		address X2':x2' that has an active mapping to an internal address
	X2:x2, back to that internal address X2:x2. Note that typically X1'		X2:x2, back to that internal address X2:x2. Note that typically X1'
	is the same as X2'.		is the same as X2'.
	skipping to change at page 17, line 9		skipping to change at page 17, line 30
	various protocols, including protocols for negotiating peer-to-peer		various protocols, including protocols for negotiating peer-to-peer
	sessions such as SIP.		sessions such as SIP.
	Certain NATs have these ALGs turned on permanently, others have them		Certain NATs have these ALGs turned on permanently, others have them
	turned on by default but let them be be turned off, and others have		turned on by default but let them be be turned off, and others have
	them turned off by default but let them be turned on.		them turned off by default but let them be turned on.
	NAT ALGs may interfere with UNSAF methods or protocols that try to be		NAT ALGs may interfere with UNSAF methods or protocols that try to be
	NAT-aware and must therefore be used with extreme caution.		NAT-aware and must therefore be used with extreme caution.
	REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms		REQ-10: To eliminate interference with UNSAF NAT traversal
	and allow integrity protection of UDP communications, NAT ALGs for		mechanisms and allow integrity protection of UDP communications,
	UDP-based protocols SHOULD be turned off. Future standards track		NAT ALGs for UDP-based protocols SHOULD be turned off. Future
	specifications that define an ALG can update this to recommend		standards track specifications that define an ALG can update this
	that the ALGs they define default on.		to recommend that the ALGs they define default on.
	a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow		a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
	the NAT administrator to enable or disable each ALG separately.		the NAT administrator to enable or disable each ALG separately.
	Justification: NAT ALGs may interfere with UNSAF methods.		Justification: NAT ALGs may interfere with UNSAF methods.
	a) This requirement allows the user to enable those ALGs that are		a) This requirement allows the user to enable those ALGs that are
	necessary to aid in the operation of some applications without		necessary to aid in the operation of some applications without
	enabling ALGs which interfere with the operation of other		enabling ALGs which interfere with the operation of other
	applications.		applications.
	8. Deterministic Properties		8. Deterministic Properties
	skipping to change at page 19, line 25		skipping to change at page 19, line 47
	10. Fragmentation of Outgoing Packets		10. Fragmentation of Outgoing Packets
	When the MTU of the adjacent link is too small, fragmentation of		When the MTU of the adjacent link is too small, fragmentation of
	packets going from the internal side to the external side of the NAT		packets going from the internal side to the external side of the NAT
	may occur. This can occur if the NAT is doing PPPoE, or if the NAT		may occur. This can occur if the NAT is doing PPPoE, or if the NAT
	has been configured with a small MTU to reduce serialization delay		has been configured with a small MTU to reduce serialization delay
	when sending large packets and small higher-priority packets, or for		when sending large packets and small higher-priority packets, or for
	other reasons.		other reasons.
	It is worth nothing that many IP stacks do not use Path MTU Discovery		It is worth noting that many IP stacks do not use Path MTU Discovery
	with UDP packets.		with UDP packets.
	The packet could have its Don't Fragment bit set to 1 (DF=1) or 0		The packet could have its Don't Fragment bit set to 1 (DF=1) or 0
	(DF=0).		(DF=0).
	REQ-13: If the packet received on an internal IP address has DF=1,		REQ-13: If the packet received on an internal IP address has DF=1,
	the NAT MUST send back an ICMP message "fragmentation needed and		the NAT MUST send back an ICMP message "fragmentation needed and
	DF set" message to the host as described in [RFC0792].		DF set" message to the host as described in [RFC0792].
	a) If the packet has DF=0, the NAT MUST fragment the packet and		a) If the packet has DF=0, the NAT MUST fragment the packet and
	SHOULD send the fragments in order.		SHOULD send the fragments in order.
	skipping to change at page 21, line 4		skipping to change at page 21, line 22
	specification (i.e., the "MUST"), is "compliant with this		specification (i.e., the "MUST"), is "compliant with this
	specification." A NAT that supports all of the requirements of this		specification." A NAT that supports all of the requirements of this
	specification (i.e., including the "RECOMMENDED") is "fully compliant		specification (i.e., including the "RECOMMENDED") is "fully compliant
	with all the mandatory and recommended requirements of this		with all the mandatory and recommended requirements of this
	specification."		specification."
	REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior.		REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior.
	REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling"		REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling"
	behavior of "Paired". Note that this requirement is not		behavior of "Paired". Note that this requirement is not
	applicable to NATs that do not support IP address pooling.		applicable to NATs that do not support IP address pooling.
	REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port		REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port
	overloading".		overloading".
	a) If the host's source port was in the range 1-1023, it is		a) If the host's source port was in the range 0-1023, it is
	RECOMMENDED the NAT's source port be in the same range. If the		RECOMMENDED the NAT's source port be in the same range. If the
	host's source port was in the range 1024-65535, it is		host's source port was in the range 1024-65535, it is
	RECOMMENDED that the NAT's source port be in that range.		RECOMMENDED that the NAT's source port be in that range.
	REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation"		REQ-4: It is RECOMMENDED that a NAT have a "Port parity
	behavior of "Yes".		preservation" behavior of "Yes".
	REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2		REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
	minutes, unless REQ-5a applies.		minutes, unless REQ-5a applies.
	a) For specific destination ports in the well-known port range		a) For specific destination ports in the well-known port range
	(ports 0-1023), a NAT MAY have shorter UDP mapping timers that		(ports 0-1023), a NAT MAY have shorter UDP mapping timers that
	are specific to the IANA-registered application running over		are specific to the IANA-registered application running over
	that specific destination port.		that specific destination port.
	b) The value of the NAT UDP mapping timer MAY be configurable.		b) The value of the NAT UDP mapping timer MAY be configurable.
	c) A default value of 5 minutes or more for the NAT UDP mapping		c) A default value of 5 minutes or more for the NAT UDP mapping
	timer is RECOMMENDED.		timer is RECOMMENDED.
	REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound		REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound
	skipping to change at page 21, line 42		skipping to change at page 22, line 15
	REQ-8: If application transparency is most important, it is		REQ-8: If application transparency is most important, it is
	RECOMMENDED that a NAT have "Endpoint independent filtering"		RECOMMENDED that a NAT have "Endpoint independent filtering"
	behavior. If a more stringent filtering behavior is most		behavior. If a more stringent filtering behavior is most
	important, it is RECOMMENDED that a NAT have "Address dependent		important, it is RECOMMENDED that a NAT have "Address dependent
	filtering" behavior.		filtering" behavior.
	a) The filtering behavior MAY be an option configurable by the		a) The filtering behavior MAY be an option configurable by the
	administrator of the NAT.		administrator of the NAT.
	REQ-9: A NAT MUST support "Hairpinning".		REQ-9: A NAT MUST support "Hairpinning".
	a) A NAT Hairpinning behavior MUST be "External source IP address		a) A NAT Hairpinning behavior MUST be "External source IP address
	and port".		and port".
	REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms		REQ-10: To eliminate interference with UNSAF NAT traversal
	and allow integrity protection of UDP communications, NAT ALGs for		mechanisms and allow integrity protection of UDP communications,
	UDP-based protocols SHOULD be turned off. Future standards track		NAT ALGs for UDP-based protocols SHOULD be turned off. Future
	specifications that define an ALG can update this to recommend		standards track specifications that define an ALG can update this
	that the ALGs they define default on.		to recommend that the ALGs they define default on.
	a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow		a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
	the NAT administrator to enable or disable each ALG separately.		the NAT administrator to enable or disable each ALG separately.
	REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT		REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
	change the NAT translation (Section 4) or the Filtering		change the NAT translation (Section 4) or the Filtering
	(Section 5) Behavior at any point in time or under any particular		(Section 5) Behavior at any point in time or under any particular
	conditions.		conditions.
	REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the		REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
	NAT mapping.		NAT mapping.
	a) The NAT's default configuration SHOULD NOT filter ICMP messages		a) The NAT's default configuration SHOULD NOT filter ICMP messages
	based on their source IP address.		based on their source IP address.
	b) It is RECOMMENDED that a NAT support ICMP Destination		b) It is RECOMMENDED that a NAT support ICMP Destination
	Unreachable messages.		Unreachable messages.
	skipping to change at page 22, line 15		skipping to change at page 22, line 32
	REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT		REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
	change the NAT translation (Section 4) or the Filtering		change the NAT translation (Section 4) or the Filtering
	(Section 5) Behavior at any point in time or under any particular		(Section 5) Behavior at any point in time or under any particular
	conditions.		conditions.
	REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the		REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
	NAT mapping.		NAT mapping.
	a) The NAT's default configuration SHOULD NOT filter ICMP messages		a) The NAT's default configuration SHOULD NOT filter ICMP messages
	based on their source IP address.		based on their source IP address.
	b) It is RECOMMENDED that a NAT support ICMP Destination		b) It is RECOMMENDED that a NAT support ICMP Destination
	Unreachable messages.		Unreachable messages.
	REQ-13 If the packet received on an internal IP address has DF=1, the		REQ-13 If the packet received on an internal IP address has DF=1,
	NAT MUST send back an ICMP message "fragmentation needed and DF		the NAT MUST send back an ICMP message "fragmentation needed and
	set" message to the host as described in [RFC0792].		DF set" message to the host as described in [RFC0792].
	a) If the packet has DF=0, the NAT MUST fragment the packet and		a) If the packet has DF=0, the NAT MUST fragment the packet and
	SHOULD send the fragments in order.		SHOULD send the fragments in order.
	REQ-14: A NAT MUST support receiving in order and out of order		REQ-14: A NAT MUST support receiving in order and out of order
	fragments, so it MUST have "Received Fragment Out of Order"		fragments, so it MUST have "Received Fragment Out of Order"
	behavior.		behavior.
	a) A NAT's out of order fragment processing mechanism MUST be		a) A NAT's out of order fragment processing mechanism MUST be
	designed so that fragmentation-based DoS attacks do not		designed so that fragmentation-based DoS attacks do not
	compromise the NAT's ability to process in-order and		compromise the NAT's ability to process in-order and
	unfragmented IP packets.		unfragmented IP packets.
	13. Security Considerations		13. Security Considerations
	NATs are often deployed to achieve security goals. Most of the		NATs are often deployed to achieve security goals. Most of the
	recommendations and requirements in this document do not affect the		recommendations and requirements in this document do not affect the
	security properties of these devices, but a few of them do have		security properties of these devices, but a few of them do have
	security implications and are discussed in this section.		security implications and are discussed in this section.
	This document recommends that the timers for mapping be refreshed		This document recommends that the timers for mapping be refreshed
	only on outgoing packets and does not make recommendations about		only on outgoing packets (see REQ-6) and does not make
	whether or not inbound packets should update the timers. If inbound		recommendations about whether or not inbound packets should update
	packets update the timers, an external attacker can keep the mapping		the timers. If inbound packets update the timers, an external
	alive forever and attack future devices that may end up with the same		attacker can keep the mapping alive forever and attack future devices
	internal address. A device that was also the DHCP server for the		that may end up with the same internal address. A device that was
	private address space could mitigate this by cleaning any mappings		also the DHCP server for the private address space could mitigate
	when a DHCP lease expired. For unicast UDP traffic (the scope of		this by cleaning any mappings when a DHCP lease expired. For unicast
	this document), it may not seem relevant to support inbound timer		UDP traffic (the scope of this document), it may not seem relevant to
	refresh; however, for multicast UDP, the question is harder. It is		support inbound timer refresh; however, for multicast UDP, the
	expected that future documents discussing NAT behavior with multicast		question is harder. It is expected that future documents discussing
	traffic will refine the requirements around handling of the inbound		NAT behavior with multicast traffic will refine the requirements
	refresh timer. Some devices today do update the timers on inbound		around handling of the inbound refresh timer. Some devices today do
	packets.		update the timers on inbound packets.
	This document recommends that the NAT filters be specific to the		This document recommends that the NAT filters be specific to the
	external IP address only and not to the external IP and port. It can		external IP address only (see REQ-8) and not to the external IP
	be argued that this is less secure than using the IP and port.		address and UDP port. It can be argued that this is less secure than
	Devices that wish to filter on IP and port do still comply with these		using the IP and port. Devices that wish to filter on IP and port do
	requirements.		still comply with these requirements.
	Non-deterministic NATs are risky from a security point of view. They		Non-deterministic NATs are risky from a security point of view. They
	are very difficult to test because they are, well, non-deterministic.		are very difficult to test because they are, well, non-deterministic.
	Testing by a person configuring one may result in the person thinking		Testing by a person configuring one may result in the person thinking
	it is behaving as desired, yet under different conditions, which an		it is behaving as desired, yet under different conditions, which an
	attacker can create, the NAT may behave differently. These		attacker can create, the NAT may behave differently. These
	requirements recommend that devices be deterministic.		requirements recommend that devices be deterministic.
	This document requires that NATs have an "external NAT mapping is		This document requires that NATs have an "external NAT mapping is
	endpoint independent" behavior. This does not reduce the security of		endpoint independent" behavior. This does not reduce the security of
	skipping to change at page 24, line 19		skipping to change at page 24, line 36
	Although this is not an UNSAF proposal, it is interesting to consider		Although this is not an UNSAF proposal, it is interesting to consider
	the impact of this work on these architectural considerations.		the impact of this work on these architectural considerations.
	Arch-1: The scope of this is limited to UDP packets in NATs like the		Arch-1: The scope of this is limited to UDP packets in NATs like the
	ones widely deployed today. The "fix" helps constrain the		ones widely deployed today. The "fix" helps constrain the
	variability of NATs for true UNSAF solutions such as STUN.		variability of NATs for true UNSAF solutions such as STUN.
	Arch-2: This will exit at the same rate that NATs exit. It does not		Arch-2: This will exit at the same rate that NATs exit. It does not
	imply any protocol machinery that would continue to live		imply any protocol machinery that would continue to live
	after NATs were gone or make it more difficult to remove		after NATs were gone or make it more difficult to remove
	them.		them.
	Arch-3: This does not reduce the overall brittleness of NATs but will		Arch-3: This does not reduce the overall brittleness of NATs but
	hopefully reduce some of the more outrageous NAT behaviors		will hopefully reduce some of the more outrageous NAT
	and make it easer to discuss and predict NAT behavior in		behaviors and make it easer to discuss and predict NAT
	given situations.		behavior in given situations.
	Arch-4: This work and the results [I-D.jennings-behave-test-results]		Arch-4: This work and the results [I-D.jennings-behave-test-results]
	of various NATs represent the most comprehensive work at IETF		of various NATs represent the most comprehensive work at
	on what the real issues are with NATs for applications like		IETF on what the real issues are with NATs for applications
	VoIP. This work and STUN have pointed out more than anything		like VoIP. This work and STUN have pointed out more than
	else the brittleness NATs introduce and the difficulty of		anything else the brittleness NATs introduce and the
	addressing these issues.		difficulty of addressing these issues.
	Arch-5: This work and the test results [I-D.jennings-behave-test-		Arch-5: This work and the test results
	results] provide a reference model for what any UNSAF		[I-D.jennings-behave-test-results] provide a reference model
	proposal might encounter in deployed NATs.		for what any UNSAF proposal might encounter in deployed
			NATs.
	16. Acknowledgments		16. Acknowledgments
	The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and		The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and
	Dan Kegel for the their multiple contributions on peer-to-peer		Dan Kegel for the their multiple contributions on peer-to-peer
	communications across a NAT. Dan Wing contributed substantial text		communications across a NAT. Dan Wing contributed substantial text
	on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy,		on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy,
	Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell,		Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell,
	Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert		Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert
	Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka		Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka
	Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola and Jari Arkko for		Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola, Peter Koch and
	their contributions.		Jari Arkko for their contributions.
	17. References		17. References
	17.1. Normative References		17.1. Normative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	September 1981.		September 1981.
	skipping to change at page 26, line 33		skipping to change at page 27, line 6
	[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute		[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
	in Session Description Protocol (SDP)", RFC 3605,		in Session Description Protocol (SDP)", RFC 3605,
	October 2003.		October 2003.
	[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through		[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
	Network Address Translations (NATs)", RFC 4380,		Network Address Translations (NATs)", RFC 4380,
	February 2006.		February 2006.
	[I-D.ietf-behave-rfc3489bis]		[I-D.ietf-behave-rfc3489bis]
	Rosenberg, J., "Simple Traversal of UDP Through Network		Rosenberg, J., "Simple Traversal Underneath Network
	Address Translators (NAT) (STUN)",		Address Translators (NAT) (STUN)",
	draft-ietf-behave-rfc3489bis-03 (work in progress),		draft-ietf-behave-rfc3489bis-04 (work in progress),
	March 2006.		July 2006.
	[I-D.ietf-mmusic-ice]		[I-D.ietf-mmusic-ice]
	Rosenberg, J., "Interactive Connectivity Establishment		Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Methodology for Network Address Translator (NAT)		(ICE): A Methodology for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols",		Traversal for Offer/Answer Protocols",
	draft-ietf-mmusic-ice-08 (work in progress), March 2006.		draft-ietf-mmusic-ice-11 (work in progress), October 2006.
	[I-D.jennings-behave-test-results]		[I-D.jennings-behave-test-results]
	Jennings, C., "NAT Classification Test Results",		Jennings, C., "NAT Classification Test Results",
	draft-jennings-behave-test-results-01 (work in progress),		draft-jennings-behave-test-results-02 (work in progress),
	July 2005.		June 2006.
	[I-D.ietf-behave-turn]		[I-D.ietf-behave-turn]
	Rosenberg, J., "Obtaining Relay Addresses from Simple		Rosenberg, J., "Obtaining Relay Addresses from Simple
	Traversal of UDP Through NAT (STUN)",		Traversal Underneath NAT (STUN)",
	draft-ietf-behave-turn-00 (work in progress), March 2006.		draft-ietf-behave-turn-02 (work in progress),
			October 2006.
	[ITU.H323]		[ITU.H323]
	"Packet-based Multimedia Communications Systems", ITU-		"Packet-based Multimedia Communications Systems", ITU-
	T Recommendation H.323, July 2003.		T Recommendation H.323, July 2003.
	Authors' Addresses		Authors' Addresses
	Francois Audet (editor)		Francois Audet (editor)
	Nortel Networks		Nortel Networks
	4655 Great America Parkway		4655 Great America Parkway
	skipping to change at page 29, line 5		skipping to change at page 29, line 5
	Cullen Jennings		Cullen Jennings
	Cisco Systems		Cisco Systems
	170 West Tasman Drive		170 West Tasman Drive
	MS: SJC-21/2		MS: SJC-21/2
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Phone: +1 408 902 3341		Phone: +1 408 902 3341
	Email: fluffy@cisco.com		Email: fluffy@cisco.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			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 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		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 29, line 29		skipping to change at page 29, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	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 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.
	Copyright Statement
	Copyright (C) The Internet Society (2006). 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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 41 change blocks.
	101 lines changed or deleted		118 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/