draft-ietf-behave-nat-udp-05.txt		draft-ietf-behave-nat-udp-06.txt
	BEHAVE F. Audet, Ed.		BEHAVE F. Audet, Ed.
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: October 9, 2006 C. Jennings		Expires: November 7, 2006 C. Jennings
	Cisco Systems		Cisco Systems
	April 7, 2006		May 6, 2006
	NAT Behavioral Requirements for Unicast UDP		NAT Behavioral Requirements for Unicast UDP
	draft-ietf-behave-nat-udp-05		draft-ietf-behave-nat-udp-06
	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 October 9, 2006.		This Internet-Draft will expire on November 7, 2006.
	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 24		skipping to change at page 2, line 24
	4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10		4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10
	4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 10		4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 10
	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 . . . 12
	5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14		5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14
	6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 15		6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 15
	7. Application Level Gateways . . . . . . . . . . . . . . . . . . 16		7. Application Level Gateways . . . . . . . . . . . . . . . . . . 16
	8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17		8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17
	9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 18		9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 18
	10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19		10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19
	10.1. Smaller Adjacent MTU . . . . . . . . . . . . . . . . . . . 19		11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 19
	10.2. Smaller Network MTU . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 23
	15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24		15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
	16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 25		17.1. Normative References . . . . . . . . . . . . . . . . . . . 24
	17.2. Informational References . . . . . . . . . . . . . . . . . 25		17.2. Informational References . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . . . 28		Intellectual Property and Copyright Statements . . . . . . . . . . 28
	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.
	skipping to change at page 8, line 9		skipping to change at page 8, line 9
	same external IP address. This is to avoid breaking peer-to-peer		same external IP address. This is to avoid breaking peer-to-peer
	applications that are not capable of negotiating the IP address		applications that are not capable of negotiating the IP address
	for RTP and the IP address for RTCP separately. As such it is		for RTP and the IP address for RTCP separately. As such it is
	envisioned that this requirement will become less important as		envisioned that this requirement will become less important as
	applications become NAT-friendlier with time. The main reason why		applications become NAT-friendlier with time. The main reason why
	this requirement is here is that in a peer-to-peer application,		this requirement is here is that in a peer-to-peer application,
	you are subject to the other peer's mistake. In particular, in		you are subject to the other peer's mistake. In particular, in
	the context of SIP, if my application supports the extensions		the context of SIP, if my application supports the extensions
	defined in RFC 3605 [16] for indicating RTP and RTCP addresses and		defined in RFC 3605 [16] for indicating RTP and RTCP addresses and
	ports separately, but the other peer does not, there may still be		ports separately, but the other peer does not, there may still be
	breakage in the form of the stream losing RTP packets. This		breakage in the form of the stream losing RTCP packets. This
	requirement will avoid the loss of RTP in this context, although		requirement will avoid the loss of RTP in this context, although
	the loss of RTCP may be inevitable in this particular example. It		the loss of RTCP may be inevitable in this particular example. It
	is also worth noting that RFC 3605 is unfortunately not a		is also worth noting that RFC 3605 is unfortunately not a
	mandatory part of SIP (RFC 3261). This requirement will therefore		mandatory part of SIP (RFC 3261). This requirement will therefore
	address a particularly nasty problem that will prevail for a		address a particularly nasty problem that will prevail for a
	significant period of time.		significant period of time.
	4.2. Port Assignment		4.2. Port Assignment
	4.2.1. Port Assignment Behavior		4.2.1. Port Assignment Behavior
	skipping to change at page 9, line 25		skipping to change at page 9, line 25
	preservation even in the case of collision (i.e., X'=X1'=X2' and		preservation even in the case of collision (i.e., X'=X1'=X2' and
	x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x).		x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x).
	These NATs rely on the source of the response from the external		These NATs rely on the source of the response from the external
	endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal		endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal
	endpoint (X1 or X2). Port overloading fails if the two internal		endpoint (X1 or X2). Port overloading fails if the two internal
	endpoints are establishing sessions to the same external destination.		endpoints are establishing sessions to the same external destination.
	Most applications fail in some cases with "Port overloading". It is		Most applications fail in some cases with "Port overloading". It is
	clear that "Port overloading" behavior will result in many problems.		clear that "Port overloading" behavior will result in many problems.
	For example it will fail if two internal endpoints try to reach the		For example it will fail if two internal endpoints try to reach the
	same external destination, e.g., a server used by both endpoints such		same external destination, e.g., a SIP proxy server used by both
	as a SIP proxy, or a web server, etc.		endpoints.
	When NATs do allocate a new source port, there is the issue of which		When NATs do allocate a new source port, there is the issue of which
	IANA-defined range of port to choose. The ranges are "well-known"		IANA-defined range of port to choose. The ranges are "well-known"
	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.
	It should be noted that port 0 is reserved and must not be used.
	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 1-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
	skipping to change at page 11, line 30		skipping to change at page 11, line 30
	4.3. Mapping Refresh		4.3. Mapping Refresh
	NAT mapping timeout implementations vary but include the timer's		NAT mapping timeout implementations vary but include the timer's
	value and the way the mapping timer is refreshed to keep the mapping		value and the way the mapping timer is refreshed to keep the mapping
	alive.		alive.
	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 1 minute,		REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
	unless REQ-5a applies.		minutes, unless REQ-5a applies.
	a) A NAT MAY have UDP mapping timers that have much shorter		a) A NAT MAY have UDP mapping timers that have much shorter
	timers, but only for specific ports in the well-known port		timers, but only for specific ports in the well-known port
	range (i.e., ports 0-1023) where the IANA- registered protocol		range (i.e., ports 0-1023) where the IANA- registered protocol
	is strictly a request/response protocol, such as for example		is strictly a request/response protocol, such as for example
	DNS over UDP/53.		DNS over UDP/53.
	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 for the NAT UDP mapping timer is		c) A default value of 5 minutes for the NAT UDP mapping timer is
	RECOMMENDED.		RECOMMENDED.
	Justification: This requirement is to ensure that the timeout is long		Justification: This requirement is to ensure that the timeout is long
	skipping to change at page 18, line 17		skipping to change at page 18, line 17
	Non-deterministic NATs generally change behavior when a conflict of		Non-deterministic NATs generally change behavior when a conflict of
	some sort happens, i.e. when the port that would normally be used is		some sort happens, i.e. when the port that would normally be used is
	already in use by another mapping. The NAT mapping and External		already in use by another mapping. The NAT mapping and External
	Filtering in the absence of conflict is referred to as the Primary		Filtering in the absence of conflict is referred to as the Primary
	behavior. The behavior after the first conflict is referred to as		behavior. The behavior after the first conflict is referred to as
	Secondary and after the second conflict is referred to as Tertiary.		Secondary and after the second conflict is referred to as Tertiary.
	No NATs have been observed that change on further conflicts but it is		No NATs have been observed that change on further conflicts but it is
	certainly possible that they exist.		certainly possible that they exist.
	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 mapping or the External Filtering Behavior at any		change the NAT translation (Section 4) or the Filtering
	point in time or under any particular conditions.		(Section 5) Behavior at any point in time or under any particular
			conditions.
	Justification: Non-deterministic NATs are very difficult to		Justification: Non-deterministic NATs are very difficult to
	troubleshoot because they require more intensive testing. This		troubleshoot because they require more intensive testing. This
	non-deterministic behavior is the root cause of much of the		non-deterministic behavior is the root cause of much of the
	uncertainty that NATs introduce about whether or not applications		uncertainty that NATs introduce about whether or not applications
	will work.		will work.
	9. ICMP Destination Unreachable Behavior		9. ICMP Destination Unreachable Behavior
	When a NAT sends a packet towards a host on the other side of the		When a NAT sends a packet towards a host on the other side of the
	skipping to change at page 19, line 5		skipping to change at page 19, line 5
	described in the paragraph above is referred to as "support ICMP		described in the paragraph above is referred to as "support ICMP
	Processing".		Processing".
	There is no significant security advantage to blocking ICMP		There is no significant security advantage to blocking ICMP
	Destination Unreachable packets. Additionally, blocking ICMP		Destination Unreachable packets. Additionally, blocking ICMP
	Destination Unreachable packets can interfere with application		Destination Unreachable packets can interfere with application
	failover, UDP Path MTU Discovery (see RFC1191 [3] and RFC1435 [4]),		failover, UDP Path MTU Discovery (see RFC1191 [3] and RFC1435 [4]),
	and traceroute. Blocking any ICMP message is discouraged, and		and traceroute. Blocking any ICMP message is discouraged, and
	blocking ICMP Destination Unreachable is strongly discouraged.		blocking ICMP Destination Unreachable is strongly discouraged.
	REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT		REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
	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.
	Justification: This is easy to do, is used for many things including		Justification: This is easy to do, is used for many things including
	MTU discovery and rapid detection of error conditions, and has no		MTU discovery and rapid detection of error conditions, and has no
	negative consequences.		negative consequences.
	10. Fragmentation of Outgoing Packets		10. Fragmentation of Outgoing Packets
	When sending a packet, there are two situations that may cause IP		When the MTU of the adjacent link is too small, fragmentation of
	fragmentation for packets from the inside to the outside. It is		packets going from the internal side to the external side of the NAT
	worth noting that many IP stacks do not use Path MTU Discovery with		may occur. This can occur if the NAT is doing PPPoE, or if the NAT
	UDP packets.		has been configured with a small MTU to reduce serialization delay
			when sending large packets and small higher-priority packets, or for
	10.1. Smaller Adjacent MTU		other reasons.
	The first situation is when the MTU of the adjacent link is too		It is worth nothing that many IP stacks do not use Path MTU Discovery
	small. This can occur if the NAT is doing PPPoE, or if the NAT has		with UDP packets.
	been configured with a small MTU to reduce serialization delay when
	sending large packets and small higher-priority packets, or for other
	reasons.
	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 has DF=1, the NAT SHOULD send back an ICMP		REQ-13: If the packet received on an internal IP address has DF=1,
	message "fragmentation needed and DF set" message to the host as		the NAT SHOULD send back an ICMP message "fragmentation needed and
	described in RFC 792 [2].		DF set" message to the host as described in RFC 792 [2].
	a) If the packet has DF=0, the NAT SHOULD fragment the packet and		a) If the packet has DF=0, the NAT SHOULD fragment the packet and
	send the fragments, in order.		send the fragments, in order.
	Justification: This is as per RFC 792.		Justification: This is as per RFC 792.
	a) This is the same function a router performs in a similar		a) This is the same function a router performs in a similar
	situation RFC 1812 [5].		situation RFC 1812 [5].
	10.2. Smaller Network MTU
	The second situation is when the MTU on some link in the middle of
	the network that is not the adjacent link is too small. If DF=0, the
	router adjacent to the small-MTU segment will fragment the packet and
	forward the fragments as specified in RFC 1812 [5].
	If DF=1, the router adjacent to the small-MTU segment will send the
	ICMP message "fragmentation needed and DF set" back towards the NAT.
	The NAT needs to forward this ICMP message to the inside host.
	The classification of NATs that perform this behavior is covered in
	Section 9.
	REQ-14: A NAT MUST support fragmentation of packets larger than link
	MTU.
	Justification: Fragmented packets become more common with large video
	packets and should continue to work. Applications can use MTU
	discovery to work around this problem.
	11. Receiving Fragmented Packets		11. Receiving Fragmented Packets
	For a variety of reasons, a NAT may receive a fragmented packet. The		For a variety of reasons, a NAT may receive a fragmented packet. The
	IP packet containing the header could arrive in any fragment		IP packet containing the header could arrive in any fragment
	depending on network conditions, packet ordering, and the		depending on network conditions, packet ordering, and the
	implementation of the IP stack that generated the fragments.		implementation of the IP stack that generated the fragments.
	A NAT that is capable only of receiving fragments in order (that is,		A NAT that is capable only of receiving fragments in order (that is,
	with the header in the first packet) and forwarding each of the		with the header in the first packet) and forwarding each of the
	fragments to the internal host is described as "Received Fragments		fragments to the internal host is described as "Received Fragments
	skipping to change at page 20, line 38		skipping to change at page 20, line 15
	A NAT that is capable of receiving fragments in or out of order and		A NAT that is capable of receiving fragments in or out of order and
	forwarding the individual packets (or a reassembled packet) to the		forwarding the individual packets (or a reassembled packet) to the
	internal host is referred to as "Receive Fragments Out of Order".		internal host is referred to as "Receive Fragments Out of Order".
	See the Security Considerations section of this document for a		See the Security Considerations section of this document for a
	discussion of this behavior.		discussion of this behavior.
	A NAT that is neither of these is referred to as "Receive Fragments		A NAT that is neither of these is referred to as "Receive Fragments
	None".		None".
	REQ-15: 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.
	Justification: See Security Considerations.		Justification: See Security Considerations.
	12. Requirements		12. Requirements
	skipping to change at page 21, line 24		skipping to change at page 21, line 4
	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 1-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 preservation"
	behavior of "Yes".		behavior of "Yes".
	REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 1 minute,		REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2
	unless REQ-5a applies.		minutes, unless REQ-5a applies.
	a) A NAT MAY have UDP mapping timers that have much shorter		a) A NAT MAY have UDP mapping timers that have much shorter
	timers, but only for specific ports in the well-known port		timers, but only for specific ports in the well-known port
	range (i.e., ports 0-1023) where the IANA- registered protocol		range (i.e., ports 0-1023) where the IANA- registered protocol
	is strictly a request/response protocol, such as for example		is strictly a request/response protocol, such as for example
	DNS over UDP/53.		DNS over UDP/53.
	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 for the NAT UDP mapping timer is		c) A default value of 5 minutes for the NAT UDP mapping timer is
	RECOMMENDED.		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
	refresh behavior" of "True".		refresh behavior" of "True".
	skipping to change at page 22, line 20		skipping to change at page 21, line 48
	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: If a NAT includes ALGs that affect UDP, it is RECOMMENDED		REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED
	that all of those ALGs be disabled by default.		that all of those ALGs be disabled by default.
	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 mapping or the External External Filtering Behavior		change the NAT translation (Section 4) or the Filtering
	at any point in time or under any particular conditions.		(Section 5) Behavior at any point in time or under any particular
	REQ-12: Receipt of any sort of ICMP message MUST NOT destroy the NAT		conditions.
	mapping.
			REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the
			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 has DF=1, the NAT SHOULD send back an ICMP		REQ-13 If the packet received on an internal IP address has DF=1, the
	message "fragmentation needed and DF set" message to the host as		NAT SHOULD send back an ICMP message "fragmentation needed and DF
	described in RFC 792 [2].		set" message to the host as described in RFC 792 [2].
	a) If the packet has DF=0, the NAT SHOULD fragment the packet and		a) If the packet has DF=0, the NAT SHOULD fragment the packet and
	send the fragments, in order.		send the fragments, in order.
	REQ-14: A NAT MUST support fragmentation of packets larger than link		REQ-14: A NAT MUST support receiving in order and out of order
	MTU.
	REQ-15: 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
End of changes. 24 change blocks.
	70 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/