< draft-schmitt-hip-nat-traversal-01.txt		draft-schmitt-hip-nat-traversal-02.txt >
	HIP Working Group V. Schmitt		HIP Working Group V. Schmitt
	Internet-Draft NEC		Internet-Draft NEC
	Intended status: Standards Track A. Pathak		Expires: April 20, 2007 A. Pathak
	Expires: December 14, 2006 IIT Kanpur		IIT Kanpur
	M. Komu		M. Komu
	HIIT		HIIT
	L. Eggert		L. Eggert
	M. Stiemerling		M. Stiemerling
	NEC		NEC
	June 12, 2006		October 17, 2006
	HIP Extensions for the Traversal of Network Address Translators		HIP Extensions for the Traversal of Network Address Translators
	draft-schmitt-hip-nat-traversal-01		draft-schmitt-hip-nat-traversal-02
	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.
	This document may not be modified, and derivative works of it may not		This document may not be modified, and derivative works of it may not
	be created, except to publish it as an RFC and to translate it into		be created, except to publish it as an RFC and to translate it into
	languages other than English.		languages other than English.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 14, 2006.		This Internet-Draft will expire on April 20, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document specifies extensions to Host Identity Protocol (HIP) to		This document specifies extensions to Host Identity Protocol (HIP) to
	support traversal of Network Address Translator (NAT) middleboxes.		support traversal of Network Address Translator (NAT) middleboxes.
	The traversal mechanism tunnels HIP control and data traffic over UDP		The traversal mechanism tunnels HIP control and data traffic over UDP
	and enables HIP initiators which MAY be behind NATs to contact HIP		and enables HIP initiators which MAY be behind NATs to contact HIP
	responders which MAY be behind another NAT.		responders which MAY be behind another NAT.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Detecting NATs . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Detecting NATs . . . . . . . . . . . . . . . . . . . . . . . . 4
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 26 ¶
	3.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 5		3.1.1. Control Traffic . . . . . . . . . . . . . . . . . . . 5
	3.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 5		3.1.2. Control Channel Keep-Alives . . . . . . . . . . . . . 5
	3.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6		3.1.3. Data Traffic . . . . . . . . . . . . . . . . . . . . . 6
	3.1.4. FROM_NAT Parameter . . . . . . . . . . . . . . . . . . 6		3.1.4. FROM_NAT Parameter . . . . . . . . . . . . . . . . . . 6
	3.1.5. VIA_RVS_NAT Parameter . . . . . . . . . . . . . . . . 7		3.1.5. VIA_RVS_NAT Parameter . . . . . . . . . . . . . . . . 7
	3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 7		3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 7
	3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 7		3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . . 7
	3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 8		3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP . . . . . . . 8
	3.3. Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 8		3.3. Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 8
	3.3.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 9		3.3.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 9
	3.3.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 11		3.3.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 12
	3.3.3. Use of the Rendezvous Service when only the		3.3.3. Use of the Rendezvous Service when only the
	Initiator Is Behind NAT . . . . . . . . . . . . . . . 14		Initiator Is Behind NAT . . . . . . . . . . . . . . . 14
	3.4. Responder Behind NAT . . . . . . . . . . . . . . . . . . . 15		3.4. Responder Behind NAT . . . . . . . . . . . . . . . . . . . 15
	3.4.1. Rendezvous Client Registration From Behind NAT . . . . 16		3.4.1. Rendezvous Client Registration From Behind NAT . . . . 15
	3.4.2. NAT Traversal of HIP Control Traffic . . . . . . . . . 17		3.4.2. NAT Traversal of HIP Control Traffic . . . . . . . . . 17
	3.4.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . 19		3.4.3. NAT Traversal of HIP Data Traffic . . . . . . . . . . 19
	3.5. Both Hosts Behind NAT . . . . . . . . . . . . . . . . . . 21		3.5. Both Hosts Behind NAT . . . . . . . . . . . . . . . . . . 21
	3.5.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 21		3.5.1. NAT Traversal of HIP Control Traffic . . . . . . . . . 21
	3.5.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 24		3.5.2. NAT Traversal of HIP Data Traffic . . . . . . . . . . 23
	3.6. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 25		3.6. NAT Keep-Alives . . . . . . . . . . . . . . . . . . . . . 25
	3.7. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 26		3.7. HIP Mobility . . . . . . . . . . . . . . . . . . . . . . . 26
	3.8. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 27		3.8. HIP Multihoming . . . . . . . . . . . . . . . . . . . . . 27
	3.9. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 28		3.9. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 27
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 28		4. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 30		7.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	7.2. Informative References . . . . . . . . . . . . . . . . . . 30		7.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Appendix A. Document Revision History . . . . . . . . . . . . . . 31		Appendix A. Document Revision History . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	Intellectual Property and Copyright Statements . . . . . . . . . . 33		Intellectual Property and Copyright Statements . . . . . . . . . . 33
	1. Introduction		1. Introduction
	The Host Identity Protocol (HIP) describes a new communication		The Host Identity Protocol (HIP) describes a new communication
	mechanism for Internet hosts [RFC4423]. It introduces a new		mechanism for Internet hosts [RFC4423]. It introduces a new
	namespace and protocol layer between the network and transport layers		namespace and protocol layer between the network and transport layers
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	Three basic cases exist for NAT traversal. In the first case, only		Three basic cases exist for NAT traversal. In the first case, only
	the initiator of a HIP base exchange is located behind a NAT. In the		the initiator of a HIP base exchange is located behind a NAT. In the
	second case, only the responder of a HIP base exchange is located		second case, only the responder of a HIP base exchange is located
	behind a NAT. The respective peer host is assumed to be in the		behind a NAT. The respective peer host is assumed to be in the
	public Internet in both cases. In the third case, both parties are		public Internet in both cases. In the third case, both parties are
	located behind (different) NATs. This document describes extensions		located behind (different) NATs. This document describes extensions
	for the first case in Section 3.3, for the second case in Section 3.4		for the first case in Section 3.3, for the second case in Section 3.4
	and in Section 3.5 for the third case.		and in Section 3.5 for the third case.
	The mechanisms described here also cover use of rendezvous server		The mechanisms described here also cover use of rendezvous server
	from NATted environments. The use rendezvous server is mandatory		from NATted environments. The use rendezvous server MUST be used
	especially when the responder is behind a NAT. The limitation of the		when the responder is behind a NAT and the rendezvous MUST be located
	described rendezvous mechanisms is that they do not work with		in a public network. Chaining of NAT enabled rendezvous servers is
	symmetric NATs.		not possible, altough there may be other kind of rendezvous servers
			on the path. The limitation of the described rendezvous mechanisms
			is that it requires NAT boxes supporting both endpoint independent
			mapping [I-D.srisuresh-behave-p2p-state].
	The mechanisms described in this document are based on encapsulating		The mechanisms described in this document are based on encapsulating
	both the control and data traffic in UDP in order to traverse NAT(s).		both the control and data traffic in UDP in order to traverse NAT(s).
	The data traffic is assumed to be ESP. Other types of data traffic		The data traffic is assumed to be ESP. Other types of data traffic
	are out of scope.		are out of scope.
	The mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm],		The mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm],
	allow HIP hosts to change network location during the lifetime of a		allow HIP hosts to change network location during the lifetime of a
	HIP association. Consequently, hosts need to start using the		HIP association. Consequently, hosts need to start using the
	proposed NAT traversal mechanisms after a mobility event relocates		proposed NAT traversal mechanisms after a mobility event relocates
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 34 ¶
	are behind the same NAT. This is commonly referred as the Hairpin		are behind the same NAT. This is commonly referred as the Hairpin
	translation [I-D.srisuresh-behave-p2p-state] . The hairpin		translation [I-D.srisuresh-behave-p2p-state] . The hairpin
	translation poses an unnecessary overhead in terms of UDP processing		translation poses an unnecessary overhead in terms of UDP processing
	of packets and routing of packets through the NAT despite the hosts		of packets and routing of packets through the NAT despite the hosts
	being located within the same network.		being located within the same network.
	As a solution to the hairpin problem, an implementation MAY choose		As a solution to the hairpin problem, an implementation MAY choose
	first to send I1 packets without UDP encapsulation and wait for the		first to send I1 packets without UDP encapsulation and wait for the
	response for an implementation specific time. If the initiator does		response for an implementation specific time. If the initiator does
	not get a reply from the responder, it then can start retransmitting		not get a reply from the responder, it then can start retransmitting
	I1 packets UDP encapsulated. This approach solve the hairpin		I1 packets UDP encapsulated. This approach solves the hairpin
	problem, but incurs extra latency for the HIP connection.		problem, but incurs extra latency for the HIP connection.
	3. HIP Across NATs		3. HIP Across NATs
	HIP based communications between two hosts consists effectively of		HIP based communications between two hosts consists effectively of
	HIP control traffic and ESP encrypted data traffic. Before ESP data		HIP control traffic and ESP encrypted data traffic. Before ESP data
	traffic can be sent, the hosts send HIP control messages to negotiate		traffic can be sent, the hosts send HIP control messages to negotiate
	algorithms and exchange keys. After this, the hosts can start		algorithms and exchange keys. After this, the hosts can start
	sending encrypted ESP data traffic.		sending encrypted ESP data traffic.
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 29 ¶
	Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic.		Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic.
	Figure 2 shows how IPsec ESP BEET-mode packets are encapsulated		Figure 2 shows how IPsec ESP BEET-mode packets are encapsulated
	within UDP. Again, a minimal UDP packet carries the ESP packet in		within UDP. Again, a minimal UDP packet carries the ESP packet in
	its payload. Contents of the UDP source and destination ports are		its payload. Contents of the UDP source and destination ports are
	described in later sections. The UDP length and checksum field MUST		described in later sections. The UDP length and checksum field MUST
	be computed as described in [RFC0768].		be computed as described in [RFC0768].
	3.1.4. FROM_NAT Parameter		3.1.4. FROM_NAT Parameter
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Address |		| Address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Port | Padding |		| UDP Port | Padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ]		Type [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ]
	Length 24		Length 18
	Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.		Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
			UDP Port A UDP port number
	Figure 3: Format for FROM_NAT Parameter		Figure 3: Format for FROM_NAT Parameter
	Figure 3 shows FROM_NAT parameter. The use of this parameter is		Figure 3 shows FROM_NAT parameter. The use of this parameter is
	described in later sections.		described in later sections.
	3.1.5. VIA_RVS_NAT Parameter		3.1.5. VIA_RVS_NAT Parameter
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Address + Port |		| Address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. . .		| UDP Port | Padding |
	. . .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	| Address + Port |
	| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ]		Type [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ]
	Length Variable		Length 16
	Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address		Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address
			UDP Port A UDP port
	Figure 4: Format for VIA_RVS_NAT Parameter		Figure 4: Format for VIA_RVS_NAT Parameter
	Figure 4 shows VIA_RVS_NAT parameter. The use of this parameter is		Figure 4 shows VIA_RVS_NAT parameter. The parameter is used for
	described in later sections.		diagnostic purposes, similarly as VIA_RVS parameter in
			[I-D.ietf-hip-rvs]. The exact use of this parameter is described in
			later sections.
	3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP		3.2. UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP
	[RFC3948] describes UDP encapsulation of IPsec ESP transport and		[RFC3948] describes UDP encapsulation of IPsec ESP transport and
	tunnel mode. This section describes the changes required for UDP		tunnel mode. This section describes the changes required for UDP
	encapsulation of BEET mode.		encapsulation of BEET mode.
	3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP		3.2.1. UDP Encapsulation of IPsec BEET-Mode ESP
	In BEET IPsec mode, any present transport-layer checksums in the		In BEET IPsec mode, any present transport-layer checksums in the
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 10 ¶
	that contains the outer addresses of the SA. The other fields of the		that contains the outer addresses of the SA. The other fields of the
	UDP header are computed as described in [RFC0768].		UDP header are computed as described in [RFC0768].
	The resulting UDP packet MUST then undergo BEET IP header processing		The resulting UDP packet MUST then undergo BEET IP header processing
	as defined in Section 5.4 of [I-D.nikander-esp-beet-mode].		as defined in Section 5.4 of [I-D.nikander-esp-beet-mode].
	Figure 5 illustrates the BEET-mode UDP encapsulation procedure for a		Figure 5 illustrates the BEET-mode UDP encapsulation procedure for a
	TCP packet.		TCP packet.
	ORIGINAL TCP PACKET:		ORIGINAL TCP PACKET:
	--------------------------------------------		+------------------------------------------+
	| inner IPv6 hdr | ext hdrs | | |		| inner IPv6 hdr | ext hdrs | | |
	| with HITs | if present | TCP | Data |		| with HITs | if present | TCP | Data |
	--------------------------------------------		+------------------------------------------+
	PACKET AFTER BEET-MODE ESP PROCESSING:		PACKET AFTER BEET-MODE ESP PROCESSING:
	------------------------------------------------------------		+----------------------------------------------------------+
	| inner IPv6 hdr | ESP | dest | | | ESP | ESP |		| inner IPv6 hdr | ESP | dest | | | ESP | ESP |
	| with HITs | hdr | opts.| TCP | Data | Trailer | ICV |		| with HITs | hdr | opts.| TCP | Data | Trailer | ICV |
	------------------------------------------------------------		+----------------------------------------------------------+
	|<------- encryption -------->|		|<------- encryption -------->|
	|<----------- integrity ----------->|		|<----------- integrity ----------->|
	FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING:		FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING:
	--------------------------------------------------------------		+------------------------------------------------------------+
	| outer IPv4 | UDP | ESP | dest | | | ESP | ESP |		| outer IPv4 | UDP | ESP | dest | | | ESP | ESP |
	| hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV |		| hdr | hdr | hdr | opts.| TCP | Data | Trailer | ICV |
	--------------------------------------------------------------		+------------------------------------------------------------+
	|<------- encryption -------->|		|<------- encryption -------->|
	|<----------- integrity ----------->|		|<----------- integrity ----------->|
	Figure 5: UDP Encapsulation of an IPsec BEET-mode ESP packet		Figure 5: UDP Encapsulation of an IPsec BEET-mode ESP packet
	containing a TCP segment.		containing a TCP segment.
	3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP		3.2.2. UDP Decapsulation of IPsec BEET-Mode ESP
	An incoming UDP-encapsulated IPsec BEET-mode ESP packet is		An incoming UDP-encapsulated IPsec BEET-mode ESP packet is
	decapsulated as follows. First, if the UDP checksum is invalid, then		decapsulated as follows. First, if the UDP checksum is invalid, then
	the packet MUST be dropped. Then, the packet MUST be verified as		the packet MUST be dropped. Then, the packet MUST be verified as
	defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data		defined in [I-D.nikander-esp-beet-mode]. If verified, the ESP data
	contained in the payload of the UDP packet MUST be decrypted as		contained in the payload of the UDP packet MUST be decrypted as
	described in [I-D.nikander-esp-beet-mode].		described in [I-D.nikander-esp-beet-mode].
			The NAT traversal methods described in this section are based on
			connection reversal and UDP hole punching similar to
			[I-D.ietf-behave-nat-udp]. However, the methods in this section are
			adapted for HIP purposes, especially the rendezvous server in mind.
	3.3. Initiator Behind NAT		3.3. Initiator Behind NAT
	This section discusses mechanisms to reach a HIP responder located in		This section discusses mechanisms to reach a HIP responder located in
	publicly addressable network by a HIP initiator that is located		publicly addressable network by a HIP initiator that is located
	behind a NAT. The case where the responder is using a rendezvous		behind a NAT. The case where the responder is using a rendezvous
	service is also described.		service is also described.
			Table 1 lists some short-hand notations used in this section. For
			simplicity, the ports mangled by NAT are presented as example port
			numbers (11111 and 22222) instead of symbolic ones. In the examples,
			we assume that the NAT(s) timeout after I1-R1 exchange for
			illustration purposes, hence there different port numbers for I2-R2
			exchange.
			+------------------+------------------------------------------------+
			| Notation | Explanation |
			+------------------+------------------------------------------------+
			| HIT-I | Initiator's HIT |
			| HIT-R | Responder's HIT |
			| IP-I | Initiator's IP address |
			| IP-R | Responder's IP address |
			| IP-RVS | IP address of the responder's rendezvous |
			| | server |
			| IP-NAT-I | Public IP of the NAT of the initiator |
			| IP-NAT-R | Public IP of the NAT of the responder |
			| UDP(50500,11111) | UDP packet with source port 50500 and |
			| | destination port 11111 |
			| UDP(11111,22222) | Example port numbers mangled by a NAT |
			| UDP(44444,22222) | Port 44444 is used throughout the examples to |
			| | denote the NAT mangled source port of I2 as |
			| | received by the rendezvous server during the |
			| | registration |
			+------------------+------------------------------------------------+
			Table 1: Notations Used in This Section
	3.3.1. NAT Traversal of HIP Control Traffic		3.3.1. NAT Traversal of HIP Control Traffic
	This section describes the details of enabling NAT traversal for HIP		This section describes the details of enabling NAT traversal for HIP
	control traffic for the base exchange [I-D.ietf-hip-base] through UDP		control traffic for the base exchange [I-D.ietf-hip-base] through UDP
	encapsulation for the case when initiator of the association is		encapsulation for the case when initiator of the association is
	located behind a NAT and responder is located in publicly addressable		located behind a NAT and responder is located in publicly addressable
	network. UDP-encapsulated HIP control traffic MUST use the packet		network. UDP-encapsulated HIP control traffic MUST use the packet
	formats described in Section 3.1. When sending UDP-encapsulated HIP		formats described in Section 3.1. When sending UDP-encapsulated HIP
	control traffic, a HIP implementation MUST zero the HIP header		control traffic, a HIP implementation MUST zero the HIP header
	checksum before calculating the UDP checksum. The receiver MUST only		checksum before calculating the UDP checksum. The receiver MUST only
	verify the correctness of the UDP checksum and MUST NOT verify the		verify the correctness of the UDP checksum and MUST NOT verify the
	checksum of the HIP header.		checksum of the HIP header.
	The initiator of a UDP-encapsulated HIP base exchange MUST use the		The initiator of a UDP-encapsulated HIP base exchange MUST use the
	UDP destination port 50500 for all control packets it sends. It is		UDP destination port 50500 for all control packets it sends. It is
	RECOMMENDED use 50500 as the source port as well, but an		RECOMMENDED to use 50500 as the source port as well, but an
	implementation MAY use a (randomly selected) unoccupied source port.		implementation MAY use a (randomly selected) unoccupied source port.
	If it uses a random source port, it MUST listen for and accept		If it uses a random source port, it MUST listen for and accept
	arriving HIP control/ESP Data packets on this port until the		arriving HIP control/ESP Data packets on this port until the
	corresponding HIP association is torn down. The random source port		corresponding HIP association is torn down. The random source port
	is RECOMMENDED to be in the range of the dynamic and private ports		is RECOMMENDED to be in the range of the dynamic and private ports
	(49152-65535). Using a random source port instead of a fixed one		(49152-65535). Using a random source port instead of a fixed one
	makes it possible to have multiple clients behind a NAT middlebox		makes it possible to have multiple clients behind a NAT middlebox
	that does only address translation but no port translation.		that does only address translation but no port translation. This is
			referred to as port overloading in [I-D.ietf-behave-nat-udp].
	The responder of a UDP-encapsulated HIP base exchange MUST use 50500		The responder of a UDP-encapsulated HIP base exchange MUST use 50500
	as the source port for all UDP-encapsulated control packets it sends.		as the source port for all UDP-encapsulated control packets it sends.
	The source address for all the packets that the responder sends MUST		The source address for all the packets that the responder sends MUST
	be the same as the IP address on which responder receives packets		be the same as the IP address on which responder receives packets
	from initiator. The responder MUST NOT respond to any arriving UDP-		from initiator. The responder MUST NOT respond to any arriving UDP-
	encapsulated control message with an decapsulated reply. HIP		encapsulated control message with an decapsulated reply. HIP
	implementations that implement the NAT traversal mechanisms generally		implementations that implement the NAT traversal mechanisms MUST
	MUST process UDP-encapsulated base exchange messages equivalently to		process UDP-encapsulated base exchange messages equivalently to
	decapsulated messages, i.e., according to [I-D.ietf-hip-base].		decapsulated messages, i.e., according to [I-D.ietf-hip-base].
	The remainder of this section clarifies this process through an		The remainder of this section clarifies this process through an
	example which is illustrated in Figure 6. It shows an initiator with		example which is illustrated in Figure 6. It shows an initiator with
	the private IP address I behind a NAT. The NAT has the public IP		the private IP address I behind a NAT. The NAT has the public IP
	address as NAT. The responder is located in the public Internet at		address as NAT. The responder is located in the public Internet at
	the IP address R.		the IP address R.
	+----+		+---+ +---+ +---+
	| |		| |----(1)--->| |---------------(2)-------------->| |
	+---+ | | +---+		| | | N | | |
	| |----(1)--->| |---------------(2)-------------->| |		| |<---(4)----| A |<--------------(3)---------------| |
	| | | N | | |		| I | | T | | R |
	| |<---(4)----| A |<--------------(3)---------------| |		| |----(5)--->| - |---------------(6)-------------->| |
	| I | | T | | R |		| | | I | | |
	| |----(5)--->| |---------------(6)-------------->| |		| |<---(8)----| |<--------------(7)---------------| |
	| | | | | |		+---+ +---+ +---+
	| |<---(8)----| |<--------------(7)---------------| |
	+---+ +----+ +---+
	1. IP(I, R) UDP(I-rand, 50500) I1(HIT-I, HIT-R)
	2. IP(NAT, R) UDP(NAT-P, 50500) I1(HIT-I, HIT-R)
	3. IP(R, NAT) UDP(50500, NAT-P) R1(HIT-R, HIT-I)
	4. IP(R, I) UDP(50500, I-rand) R1(HIT-R, HIT-I)
	5. IP(I, R) UDP(I-rand, 50500) I2(HIT-I, HIT-R)
	6. IP(NAT, R) UDP(NAT-P', 50500) I2(HIT-I, HIT-R)
	7. IP(R, NAT) UDP(50500, NAT-P') R2(HIT-R, HIT-I)
	8. IP(R, I) UDP(50500, I-rand) R2(HIT-R, HIT-I)
	I: IP of Initiator		1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
	R: IP of Responder		2. IP(IP-NAT-I, IP-R) UDP(11111, 50500) I1(HIT-I, HIT-R)
	NAT: Public IP of NAT		3. IP(IP-R, IP-NAT-I) UDP(50500, 11111) R1(HIT-R, HIT-I)
	NAT-P: NAT Mangled Port		4. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I)
	NAT-P': NAT Mangled Port		5. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
	I-rand: Random Port Number - Chosen by initiator		6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I2(HIT-I, HIT-R)
	HIT-I: Initiator's HIT		7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R2(HIT-R, HIT-I)
	HIT-R: Responder's HIT		8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
	Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator		Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator
	behind a NAT, responder on the public Internet).		behind a NAT, responder on the public Internet).
	Before beginning the base exchange, the initiator detects that it is		Before beginning the base exchange, the initiator detects that it is
	behind a NAT. The initiator starts the base exchange by sending a		behind a NAT. The initiator starts the base exchange by sending a
	UDP-encapsulated I1 packet to the responder. According to the rules		UDP-encapsulated I1 packet to the responder. According to the rules
	specified above, the source IP address of this I1 packet is I and its		specified above, the source IP address of this I1 packet is IP-I and
	source UDP port is I-rand. It is addressed to R on port 50500. The		its source UDP port is 50500. It is addressed to IP-R on port 50500.
	NAT in Figure 6 forwards the I1 but substitutes the source I with its		The NAT in Figure 6 forwards the I1 but substitutes the source
	own public IP address NAT and substitutes the source UDP port I-rand		address IP-I with its own public address IP-NAT-I and the source UDP
	with NAT-P, which will usually be different from I-rand.		port 50500 with 11111.
	The responder in Figure 6 receives the UDP-encapsulated I1 packet on
	the UDP port 50500, it processes it according to [I-D.ietf-hip-base].
	The responder replies back with an R1 using the addresses and port
	information of I1. Thus R1 packet is destined to the source IP
	address and UDP port of the I1, i.e., IP address NAT and port NAT-P.
	The NAT substitutes the destination of this packet, replacing NAT:		When the responder in Figure 6 receives the UDP-encapsulated I1
	NAT-P with I:I-rand (IP address:port).		packet on UDP port 50500, it processes it according to
			[I-D.ietf-hip-base]. The responder replies back with an R1 using the
			addresses and port information of I1. Thus, the R1 packet is
			destined to the source IP address and UDP port of the I1, i.e., IP
			address IP-NAT-I and port 11111. The NAT receives the I1 and
			substitutes the destination of this packet with the initiator address
			(IP-I) and port information (50500).
	The initiator receives a UDP-encapsulated R1 packet from the		The initiator receives a UDP-encapsulated R1 packet from the
	responder and processes it according to [I-D.ietf-hip-base]. When it		responder and processes it according to [I-D.ietf-hip-base]. When it
	responds with a UDP-encapsulated I2 packet, it uses the same IP		responds with a UDP-encapsulated I2 packet, it uses the same IP
	source and destination addresses and UDP source and destination ports		source and destination addresses and UDP source and destination ports
	that it used for sending the corresponding I1 packet, i.e., the		that it used for sending the corresponding I1 packet, i.e., the
	packet is addressed as I:I-rand -> R:50500. The NAT again		packet is addressed from IP-I port 50500 to IP-R port 50500. The NAT
	substitutes the source information, replacing it with NAT:P'.		again substitutes the source information. To illustrate timeout, the
			NAT chooses a different source port (22222) for the I2 than for the
			I1 (11111) in this case.
	When a responder receives a UDP-encapsulated I2 packet destined to		When a responder receives a UDP-encapsulated I2 packet destined to
	UDP port 50500, it MUST use the UDP source port contained in this		UDP port 50500, it MUST use the UDP source port contained in this
	packet for further HIP communications with the initiator. It then		packet for further HIP communications with the initiator. It then
	processes the I2 packet according to [I-D.ietf-hip-base]. When it		processes the I2 packet according to [I-D.ietf-hip-base]. When it
	responds with an R2 message, it UDP-encapsulates it, using the UDP		responds with an R2 message, it UDP-encapsulates the message, using
	source port of the I2 packet as the destination UDP port, and sends		the UDP source port of the I2 packet as the destination UDP port, and
	it to the source IP address of the I2 packet, i.e., it sends the R2		sends it to the source IP address of the I2 packet, i.e., it sends
	packet from R:50500 to NAT:NAT-P'. The NAT again replaces the		the R2 packet from IP-R port 50500 to IP-NAT-I port 22222. The NAT
	destination information in the R2 with I:I-rand.		again replaces the destination information in the R2 with IP-I port
			50500
	Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT		Usually, the I1-R1 and I2-R2 exchanges occur fast enough for the NAT
	state to time out. This means that the NAT uses the state		state to persist. This means that the NAT uses the same port for the
	established during the I1-R1 exchange to translate the I2-R2		I1-R1 exchange to translate as the I2-R2 exchange. However, an
	exchange, i.e., the ports NAT-P and NAT-P' will be identical.		implementation MUST handle even the case where the NAT state times
	However, an implementation MUST handle even the case where the NAT		out between the two exchanges and the I1 and I2 arrive from different
	state times out between the two exchanges and the I1 and I2 arrive		UDP source ports and/or IP addresses, as shown in Figure 6.
	from different UDP source ports and/or IP addresses, as shown in
	Figure 6.
	3.3.2. NAT Traversal of HIP Data Traffic		3.3.2. NAT Traversal of HIP Data Traffic
	This section describes the details of enabling NAT traversal of HIP		This section describes the details of enabling NAT traversal of HIP
	data traffic. As described in Section 3, HIP data traffic is carried		data traffic. As described in Section 3, HIP data traffic is carried
	in UDP-encapsulated IPsec BEET-mode ESP packets.		in UDP-encapsulated IPsec BEET-mode ESP packets.
	3.3.2.1. IPsec BEET-Mode Security Associations		3.3.2.1. IPsec BEET-Mode Security Associations
	During the HIP base exchange, the two peers exchange parameters that		During the HIP base exchange, the two peers exchange parameters that
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 36 ¶
	The initiator MUST use UDP destination port 50500 for all UDP-		The initiator MUST use UDP destination port 50500 for all UDP-
	encapsulated ESP packets it sends. It MAY also use port 50500 as		encapsulated ESP packets it sends. It MAY also use port 50500 as
	source port or it MAY use a random source port. If it uses a random		source port or it MAY use a random source port. If it uses a random
	source port, it MUST listen for and accept arriving UDP-encapsulated		source port, it MUST listen for and accept arriving UDP-encapsulated
	ESP packets on this port until the corresponding HIP association is		ESP packets on this port until the corresponding HIP association is
	torn down.		torn down.
	The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST		The responder of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST
	use 50500 as the source port for all UDP-encapsulated ESP packets it		use 50500 as the source port for all UDP-encapsulated ESP packets it
	sends. The destination port is the port it is receiving UDP		sends. The destination port is the port from which the responder is
	encapsulated ESP data from the initiator.		receiving UDP encapsulated ESP data from the initiator.
	Both initiator and responder of a HIP association that uses the NAT		Both initiator and responder of a HIP association that uses the NAT
	traversal mechanism as described in this draft MUST define BEET mode		traversal mechanism as described in this draft MUST define BEET mode
	with UDP encapsulation as IPsec mode for SA after a successful base		with UDP encapsulation as IPsec mode for SA after a successful base
	exchange. The inner source address MUST be local HIT used during		exchange. The inner source address MUST be local HIT used during
	base exchange and inner destination address MUST be HIT of the		base exchange and inner destination address MUST be HIT of the
	respective peer. The other parts of the SA are described in		respective peer. The other parts of the SA are described in
	individual sections.		individual sections.
	3.3.2.1.1. Security Associations at the Initiator		3.3.2.1.1. Security Associations at the Initiator
	The initiator of a UDP-encapsulated base exchange defines its		The initiator of a UDP-encapsulated base exchange defines its
	outbound SA as shown in Table 1		outbound SA as shown in Table 2
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same local IP address from which the base exchange |		| Outer src | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| Outer dst | Same peer IP address to which base exchange |		| Outer dst | Same peer IP address to which base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| UDP src port | Same port number as chosen for I2 packet in base |		| UDP src port | Same port number as chosen for I2 packet in base |
	| | exchange |		| | exchange |
	| UDP dst port | Port 50500 |		| UDP dst port | Port 50500 |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 1: Outbound SA at initiator		Table 2: Outbound SA at initiator
	The initiator of a UDP-encapsulated base exchange defines its inbound		The initiator of a UDP-encapsulated base exchange defines its inbound
	SA as shown in Table 2		SA as shown in Table 3
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same peer IP address to which base exchange |		| Outer src | Same peer IP address to which base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| Outer dst | Same local IP address from which the base exchange |		| Outer dst | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| UDP src port | Port 50500 |		| UDP src port | Port 50500 |
	| UDP dst port | Initiator MUST use the UDP source port it uses in |		| UDP dst port | Initiator MUST use the UDP source port it uses in |
	| | the outbound SA here |		| | the outbound SA here |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 2: Inbound SA at initiator		Table 3: Inbound SA at initiator
	3.3.2.1.2. Security Associations at the Responder		3.3.2.1.2. Security Associations at the Responder
	The responder of a UDP-encapsulated base exchange defines its		The responder of a UDP-encapsulated base exchange defines its
	outbound SA shown in Table 3.		outbound SA shown in Table 4.
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	| Outer src | Same local IP address from which the base exchange |		| Outer src | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| Outer dst | Peer IP address of the I2 packet received during |		| Outer dst | Peer IP address of the I2 packet received during |
	| address | the base exchange |		| address | the base exchange |
	| UDP src | Port 50500 |		| UDP src | Port 50500 |
	| port | |		| port | |
	| UDP dst | Source UDP port of the I2 packet received from the |		| UDP dst | Source UDP port of the I2 packet received from the |
	| port | initiator during base exchange |		| port | initiator during base exchange |
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
			Table 4: Outbound SA at Responder
	Table 3: Outbound SA at Responder
	Similarly, the responder of a UDP-encapsulated base exchange defines		Similarly, the responder of a UDP-encapsulated base exchange defines
	its inbound SA as shown in Table 4		its inbound SA as shown in Table 5
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	| Outer src | Source IP address of the I2 packet received from |		| Outer src | Source IP address of the I2 packet received from |
	| address | the initiator during base exchange |		| address | the initiator during base exchange |
	| Outer dst | Same local IP address from which the base exchange |		| Outer dst | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| UDP src | Source UDP port of the I2 packet received from the |		| UDP src | Source UDP port of the I2 packet received from the |
	| port | initiator during base exchange |		| port | initiator during base exchange |
	| UDP dst | Port 50500 |		| UDP dst | Port 50500 |
	| port | |		| port | |
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	Table 4: Inbound SA at responder		Table 5: Inbound SA at responder
	3.3.3. Use of the Rendezvous Service when only the Initiator Is Behind		3.3.3. Use of the Rendezvous Service when only the Initiator Is Behind
	NAT		NAT
	The rendezvous extensions for HIP without NAT traversal have been		The rendezvous extensions for HIP without NAT traversal have been
	defined in [rvs]. This section addresses only the scenario when a		defined in [rvs]. This section addresses only the scenario where a
	HIP node from behind NAT uses rendezvous service to contact another		NATted HIP node uses rendezvous service to contact another HIP node
	HIP node which is in public addressable network. The described		in a publicly addressable network. Figure 7 illustrates the
	mechanism does not work with symmetric NATs.		mechanism described in this section.
	A rendezvous server MUST listen on UDP port number 50500 for incoming		A rendezvous server MUST listen on UDP port number 50500 for incoming
	UDP encapsulated I1 packets in order to support NAT traversal and		UDP encapsulated I1 packets. However, in this specific case with
	relay them to registered rendezvous clients.		only initiator behind NAT, the rendezvous server MUST not relay the
			I1 packets at all because the UDP hole punching does not work.
	The rendezvous registration between RVS and a rendezvous client		Instead, the rendezvous server replies to the initiator with a NOTIFY
	located in a public network is described in [rvs]. When a HIP node		message that includes the responder's locator in VIA_RVS parameter.
	from behind NAT tries to reach a rendezvous client through RVS, it
	sends an UDP encapsulated I1 packet on port 50500 to the RVS. The
	RVS MUST check the UDP header checksum of the incoming packet, and if
	found incorrect, RVS MUST discard the packet. The RVS relays the
	inbound I1 packets to the registered rendezvous client. The RVS
	relays the I1 from its own IP address to the rendezvous client
	address. Also, the IP checksum MUST be recalculated. RVS should
	discard the UDP header. RVS MUST append a FROM_NAT parameter
	(Figure 3) containing the original source IP address and source UDP
	port number that was present in the incoming UDP encapsulated I1
	packet. The FROM_NAT parameter MUST be integrity protected by an
	RVS_HMAC as described in [rvs]. RVS MUST compute the checksum of the
	I1 packet. Once this is completed, RVS relays the packet to the
	corresponding rendezvous client.
	The rendezvous client (i.e. the responder) MUST validate any RVS_HMAC		Upon receiving the NOTIFY with the locators of the responder through
	parameter present in the I1. If an RVS_HMAC parameter failed to		the NAT, the initiator MUST send an I1 to the responder. However, it
	verify, the packet MUST be dropped. When the responder replies to		MUST continue retransmissions using the RVS location. This is
	the I1 relayed by RVS, it MUST append a VIA_RVS parameter to the R1		mandatory because NOTIFY messages are not protected with signatures
	as described in [rvs]. In addition, it MUST send the R1 UDP		and can be forged by a rogue host.
	encapsulated. The destination port MUST be the same as the port
	number contained in the FROM_NAT parameter. The source port MUST be
	50500. The processing of R1 and onwards at the initiator is
	described in [rvs].
	+-------+		When the initiator receives an R1 through the NAT, the responder
	+--(2)-->| |------(3)------+		verifies the integrity of the packet and replies with an I2. The
	| | RVS | |		responder should be aware that the I2 may arrive from a different
	+----+ | | | |		port than the I1. In such a case, the responder should send the R2
	| | | +-------+ V		to the source port of I2.
	+---+ | | | +---+
	| |---(1)--->| |----+ | |
	| | | N | | |
	| |<---(5)---| A |<----------------(4)---------------| |
	| I | | T | | R |
	| |---(6)--->| |-----------------(7)-------------->| |
	| | | | | |
	| |<---(9)---| |<----------------(8)---------------| |
	+---+ +----+ +---+
	1. IP(I, RVS) UDP(I-rand, 50500) I1(HIT-I, HIT-R)		+---+ +---+ +-------+ +---+
	2. IP(NAT, RVS) UDP(NAT-P, 50500) I1(HIT-I, HIT-R)		| |----(1)--->| |---------------(2)-->| | | |
	3. IP(RVS, R) I1(HIT-I, HIT-R, FROM_NAT:[NAT,NAT-P], RVS_HMAC)		| | | | | RVS R | | |
	4. IP(R, NAT) UDP(50500, NAT-P) R1(HIT-R, HIT-I, VIA_RVS)		| |<---(4)----| |<--------------(3)---| | | |
	5. IP(R, I) UDP(50500, I-rand) R1(HIT-R, HIT-I, VIA_RVS)		| | | | +-------+ | |
	6. IP(I, R) UDP(I-rand, 50500) I2(HIT-I, HIT-R)		| | | N | | |
	7. IP(NAT, R) UDP(NAT-P, 50500) I2(HIT-I, HIT-R)		| |----(5)--->| A |---------------(6)-------------->| |
	8. IP(R, NAT) UDP(50500, NAT-P) R2(HIT-R, HIT-I)		| I | | T | | R |
	9. IP(R, I) UDP(50500, I-rand) R2(HIT-R, HIT-I)		| |<---(8)----| - |<--------------(7)---------------| |
			| | | T | | |
			| |----(9)--->| |---------------(10)------------->| |
			| | | | | |
			| |<---(11)---| |<--------------(12)--------------| |
			+---+ +---+ +---+
	I: IP of Initiator		1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R)
	R: IP of Responder		2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R)
	RVS: IP of RVS		3. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111)
	NAT: Public IP of NAT		NOTIFY(HIT-I, HIT-R, VIA_RVS(IP-R))
	NAT-P: NAT Mangled Port		4. IP(IP-I, IP-NAT-I) UDP(50500, 50500)
	I-rand: Random Port Number - Chosen by initiator		NOTIFY(HIT-I, HIT-R, VIA_RVS(IP-R))
	HIT-I: Initiator's HIT		5. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
	HIT-R: Responder's HIT		6. IP(IP-NAT-I, IP-R) UDP(22222, 50500) I1(HIT-I, HIT-R)
			7. IP(IP-R, IP-NAT-I) UDP(50500, 22222) R1(HIT-R, HIT-I)
			8. IP(IP-R, IP-I) UDP(50500, 50500) R1(HIT-R, HIT-I)
			9. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
			10. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I2(HIT-I, HIT-R)
			11. IP(IP-R, IP-NAT-I) UDP(50500, 33333) R2(HIT-R, HIT-I)
			12. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
	Figure 7: Example of a UDP-encapsulated HIP base exchange Through RVS		Figure 7: Example of a UDP-encapsulated HIP base exchange via RVS
	(initiator behind a NAT, responder and RVS on the public Internet).		(initiator behind a NAT, responder and RVS on the public Internet).
	3.4. Responder Behind NAT		3.4. Responder Behind NAT
	This section discusses mechanisms to reach a HIP responder that is		This section discusses mechanisms to reach a HIP responder that is
	located behind a NAT. This section assumes that the initiator is		located behind a NAT. This section assumes that the initiator is
	located on publicly addressable network. The initiator contacts the		located on publicly addressable network. The initiator contacts the
	responder through an RVS server.		responder through an RVS server.
	3.4.1. Rendezvous Client Registration From Behind NAT		3.4.1. Rendezvous Client Registration From Behind NAT
	[rvs] defines the rendezvous client registration when the rendezvous		The rendezvous client registration [rvs] describes the case when
	client is present in publicly addressable network. In this section,		rendezvous client is present in publicly addressable network. This
	an extension to the rendezvous client registration is defined for the		section defines an extension to the rendezvous client registration
	case when the rendezvous client is behind a NAT.		for the case when the rendezvous client has detected that it is
			behind a NAT. The process in the NAT case is identical to the case
			without NAT, except that UDP encapsulation is used. The registration
			is illustrated in Figure 8.
	A node behind a NAT MUST first register to the RVS when it going to		A node behind a NAT MUST first register to the RVS when it is going
	act as a responder for some other nodes. The node (i.e. rendezvous		to act as a responder for some other nodes. The node (i.e.
	client) performs a base exchange with the RVS over UDP as described		rendezvous client) performs a base exchange with the RVS over UDP as
	in Section 3.3 by sending I1 UDP encapsulated and 50500 as		described in Section 3.3 by sending I1 UDP encapsulated and 50500 as
	destination port number. RVS sends REG_INFO parameter in R1 over UDP		destination port number. RVS sends REG_INFO parameter in R1 to which
	to which rendezvous client replies with REG_REQ in I2 which is also		rendezvous client replies with REG_REQ in I2. Both I1 and R1 are
	sent over UDP. If RVS grants service to the rendezvous client, it		sent using UDP. If RVS grants service to the rendezvous client, it
	MUST store the source IP address and source port number of the I2 UDP		MUST store the source IP address and source port number of the I2 UDP
	packet that it had received from the rendezvous client during base		packet that it had received from the rendezvous client during base
	exchange. The source IP address belongs to the NAT and the source		exchange. The source IP address belongs to the NAT and the source
	port number is the NAT mangled port. RVS then replies with REG_RESP		port number is the NAT mangled port. RVS then replies with REG_RESP
	in R2 over UDP. If the registration process results in a successful		in R2 over UDP. If the registration process results in a successful
	REG_RESP, the rendezvous client MUST send NAT keepalives		REG_RESP, the rendezvous client MUST send NAT keepalives
	(Section 3.1.2) to keep the mapping in the NAT with the RVS open.		(Section 3.1.2) to keep the mapping in the NAT with the RVS open.
	The NAT keepalives sent from rendezvous client to the RVS MUST have		The NAT keepalives sent from rendezvous client to the RVS MUST have
	the same source port as the I2 packet.		the same source port as the I2 packet.
	When the RVS gets an I1 packet from a HIP node to be relayed to the		When the RVS receives an I1 packet from a HIP node to be relayed to
	successfully registered rendezvous client behind NAT, RVS MUST relay		the successfully registered rendezvous client behind NAT, RVS MUST
	the I1 over UDP with the destination port as the one stored during		relay the I1 over UDP with the destination port as the one stored
	registration. This process is illustrated in Section 3.4.2.		during registration. The RVS also zeroes the checksum of the I1.
			This process is explained in Section 3.4.2.
	+----+		+---+ +---+ +---+
	| | +-------+		| |----(1)--->| |---------------(2)-------------->| |
	+---+ | | UDP-I1 sport:p1 | |		| | | N | | |
	|RVS|---------->| |----------------------------->| |		| |<---(4)----| A |<--------------(3)---------------| |
	| C | | N | UDP-R2(REG_INFO) | |		| I | | T | | R |
	| L |<----------| A |<-----------------------------| R |		| |----(5)--->| - |---------------(6)-------------->| |
	| I | | T | | V |		| | | I | | |
	| E | | | UDP-I2(REG_REQ) sport:P2 | S |		| |<---(8)----| |<--------------(7)---------------| |
	| N |---------->| |----------------------------->| |		+---+ +---+ +---+
	| T |<----------| |<-----------------------------| |
	+---+ +----+ UDP-R2(REG_RES) +-------+
	RVS Stores P2 corresponding to I's HIT		Initiator = Rendezvous client, Responder = Rendezvous server
	Figure 8: UDP-encapsulated Rendezvous Client Registration (rendezvous		1. IP(IP-I, IP-R) UDP(50500, 50500) I1(HIT-I, HIT-R)
	client behind a NAT, RVS on the public Internet).		2. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I1(HIT-I, HIT-R)
			3. IP(IP-R, IP-NAT-I) UDP(50500, 33333)
			R1(HIT-R, HIT-I, REG_INFO)
			4. IP(IP-R, IP-I) UDP(50500, 50500)
			R1(HIT-R, HIT-I, REG_INFO)
			5. IP(IP-I, IP-R) UDP(50500, 50500)
			I2(HIT-I, HIT-R, REG_REQ)
			6. IP(IP-NAT-I, IP-R) UDP(44444, 50500)
			I2(HIT-I, HIT-R, REG_REQ)
			7. IP(IP-R, IP-NAT-I) UDP(50500, 44444)
			R2(HIT-R, HIT-I, REG_RES)
			8. IP(IP-R, IP-I) UDP(50500, 50500)
			R2(HIT-R, HIT-I, REG_RES)
			Figure 8: Rendezvous NAT Client Registration
	3.4.2. NAT Traversal of HIP Control Traffic		3.4.2. NAT Traversal of HIP Control Traffic
	This section describes the details of enabling NAT traversal for base		This section describes the details of enabling NAT traversal for base
	exchange packets [I-D.ietf-hip-base] through UDP encapsulation, for		exchange packets [I-D.ietf-hip-base] through UDP encapsulation, for
	the case when the HIP initiator is on publicly addressable network		the case when the HIP initiator is on publicly addressable network
	and the HIP responder is behind NAT. The process is illustrated in		and the HIP responder is behind NAT. The process is illustrated in
	Figure 9.		Figure 9.
	Before the HIP base exchange starts, the responder of the HIP base		Before the HIP base exchange starts, the responder of the HIP base
	exchange MUST have completed a successful rendezvous client		exchange MUST have completed a successful rendezvous client
	registration using the scheme defined in Section 3.4.1.		registration using the scheme defined in Section 3.4.1.
	The initiator of the HIP base exchange sends a plain I1 packet		The initiator of the HIP base exchange sends a plain I1 packet
	(without UDP encapsulation) to RVS as described in [rvs]. The RVS		(without UDP encapsulation) to the RVS as described in [rvs]. The
	relays the inbound I1 packet to the registered rendezvous client. If		RVS relays the inbound I1 packet to the registered rendezvous client.
	rendezvous client registration was not established over UDP, it		In this case, the incoming I1 is not UDP encapsulated, but the
	follows the procedures for relaying I1 as described in [rvs]. If the		rendezvous client has registered using UDP.
	rendezvous client registration was established over UDP, the RVS MUST
	follow the mechanism to relay the I1 as described here.
	To relay the I1 packet, RVS SHOULD zero the HIP header checksum from		To relay the I1 packet, RVS SHOULD zero the HIP header checksum from
	the I1 packet. RVS must add a FROM parameter, as described in [rvs],		the I1 packet. RVS must add a FROM parameter, as described in [rvs],
	which contains the IP address of HIP initiator. The FROM parameter		which contains the IP address of HIP initiator. The FROM parameter
	is integrity protected by a RVS_HMAC as described in [rvs]. RVS		is integrity protected by a RVS_HMAC as described in [rvs]. RVS
	replaces the destination IP address in the IP header of the packet		replaces the destination IP address in the IP header of the packet
	with IP that it had stored during the rendezvous client registration		with IP that it had stored during the rendezvous client registration
	(which is the IP address of the outermost NAT behind which rendezvous		(which is the IP address of the outermost NAT behind which rendezvous
	client is located). It MUST then encapsulate the I1 packet within		client is located). It MUST then encapsulate the I1 packet within
	UDP. The source port in the UDP header MUST be 50500 and the		UDP. The source port in the UDP header MUST be 50500 and the
	destination port MUST be the same as the source port number of the I2		destination port MUST be the same as the source port number (44444)
	packet which it had stored during the registration process. RVS then		of the I2 packet which it had stored during the registration process.
	recomputes the IP header checksum and sends the packet.		RVS then recomputes the IP header checksum and sends the packet.
	+-------+		+-------+
	+----->| |-----+		| |
	| | RVS | |		+----->| RVS +-----+ +----+
	| | | |		+---+ | | | | | | +---+
	| +-------+ | +----+		| |---(1)---+ +-------+ +----(2)--->| |---(3)--->| |
	+---+ | | | | +---+
	| |---(1)---+ +----(2)--->| |---(3)--->| |
	| | | N | | |		| | | N | | |
	| |<------------------(5)--------------------| A |<--(4)----| |		| |<------------------(5)--------------------| A |<--(4)----| |
	| I | | T | | R |		| I | | T | | R |
	| |-------------------(6)------------------->| |---(7)--->| |		| |-------------------(6)------------------->| - |---(7)--->| |
	| | | | | |		| | | R | | |
	| |<------------------(9)--------------------| |<--(8)----| |		| |<------------------(9)--------------------| |<--(8)----| |
	+---+ +----+ +---+		+---+ +----+ +---+
	1. IP(I, RVS) I1( HIT-I, HIT-R)		1. IP(IP-I, IP-RVS) I1(HIT-I, HIT-R)
	2. IP(RVS, NAT) UDP(50500, P) I1(HIT-I, HIT-R, FROM:I, RVS_HMAC)		2. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444)
	3. IP(RVS, R) UDP(50500, R-rnd2) I1(HIT-I, HIT-R, FROM:I, RVS_HMAC)		I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
	4. IP(R, I) UDP(R-rand, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT)		3. IP(IP-RVS, IP-R) UDP(50500, 50500)
	5. IP(NAT, I) UDP(NAT-P, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT)		I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
	6. IP(I, NAT) UDP(50500, NAT-P) I2(HIT-I, HIT-R)		4. IP(IP-R, IP-I)
	7. IP(I, R) UDP(50500, R-rand) I2(HIT-I, HIT-R)		UDP(50500, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500))
	8. IP(R, I) UDP(R-rand, 50500) R2(HIT-R, HIT-I)		5. IP(IP-NAT-R, IP-I)
	9. IP(NAT, I) UDP(NAT-P, 50500) R2(HIT-R, HIT-I)		UDP(44444, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500)
			6. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I2(HIT-I, HIT-R)
	I: IP of Initiator		7. IP(IP-I, IP-R) UDP(50500, 50500) I2(HIT-I, HIT-R)
	R: IP of Responder		8. IP(IP-R, IP-I) UDP(50500, 50500) R2(HIT-R, HIT-I)
	RVS: IP of RVS		9. IP(IP-NAT-R, IP-I) UDP(44444, 50500) R2(HIT-R, HIT-I)
	NAT: Public IP of NAT
	NAT-P: NAT Mangled Port for base exchange
	P: NAT Mangled Port for Rendezvous Client Registration
	R-rand: Random Port Number - Chosen by responder
	R-rnd2: Random Port Number chosen during
	rendezvous client registration
	HIT-I: Initiator's HIT
	HIT-R: Responder's HIT
	Figure 9: UDP-encapsulated HIP base exchange (initiator on public		Figure 9: UDP-encapsulated HIP base exchange (initiator on public
	Internet, responder behind a NAT).		Internet, responder behind a NAT).
	The relayed I1 packet travels from RVS to the NAT. The NAT changes		The relayed I1 packet travels from RVS to the NAT. The NAT changes
	the destination IP address of the UDP encapsulated I1 packet, and the		the destination IP address of the UDP encapsulated I1 packet, and the
	destination port number in the UDP header. The responder accepts the		destination port number in the UDP header. The responder accepts the
	packet from the RVS and processes it according to [rvs]. The		packet from the RVS and processes it according to [rvs]. The
	resulting R1 must be encapsulated within UDP. It is RECOMMENDED that		resulting R1 must be encapsulated within UDP. The responder MAY
	the responder uses 50500 as source port number, but it MAY choose a		append a VIA_RVS_NAT parameter to the message, which contains the IP
	random port number. The destination port number MUST be 50500. The		address of the rendezvous and the port the rendezvous used for
	destination address in the IP header MUST be the same as one		relaying the R1. The RECOMMENDED source port is 50500 and the
	specified in the FROM parameter of the relayed I1 packet.		destination port number MUST be 50500. The destination address in
			the IP header MUST be the same as the one specified in the FROM
			parameter of the relayed I1 packet.
	The initiator MUST listen on port 50500 and it receives the UDP		The initiator MUST listen on port 50500 and it receives the UDP
	encapsulated R1. After verifying the HIP packet, it concludes that		encapsulated R1. After verifying the HIP packet, it concludes that
	the responder is behind a NAT because the packet was UDP		the responder is behind a NAT because the packet was UDP
	encapsulated. The initiator processes the R1 control packet		encapsulated. The initiator processes the R1 control packet
	according to [I-D.ietf-hip-base] and replies using I2 that is UDP		according to [I-D.ietf-hip-base] and replies using I2 that is UDP
	encapsulated. The addresses and ports are derived from the received		encapsulated. The addresses and ports are derived from the received
	R1.		R1.
	The NAT translates and forwards the UDP encapsulated I2 packet to the		The NAT translates and forwards the UDP encapsulated I2 packet to the
	skipping to change at page 19, line 31 ¶		skipping to change at page 19, line 32 ¶
	3.4.3. NAT Traversal of HIP Data Traffic		3.4.3. NAT Traversal of HIP Data Traffic
	After a successful base exchange, both of the HIP nodes have all the		After a successful base exchange, both of the HIP nodes have all the
	parameters with them needed to establish UDP BEET mode Security		parameters with them needed to establish UDP BEET mode Security
	Association. The following section describe inbound and outbound		Association. The following section describe inbound and outbound
	security associations at initiator and responder.		security associations at initiator and responder.
	3.4.3.1. Security Associations at the Initiator		3.4.3.1. Security Associations at the Initiator
	The initiator of a base exchange defines its outbound SA as shown in		The initiator of a base exchange defines its outbound SA as shown in
	Table 5		Table 6
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same local IP address from which the base exchange |		| Outer src | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| Outer dst | Same peer IP address from which R2 packet was |		| Outer dst | Same peer IP address from which R2 packet was |
	| address | received during base exchange |		| address | received during base exchange |
	| UDP src port | Port 50500 |		| UDP src port | Port 50500 |
	| UDP dst port | Source port of incoming R2 packet during base |		| UDP dst port | Source port of incoming R2 packet during base |
	| | exchange |		| | exchange |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 5: Outbound SA at initiator		Table 6: Outbound SA at initiator
	The initiator of a base exchange defines its inbound SA as shown in		The initiator of a base exchange defines its inbound SA as shown in
	Table 6		Table 7
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same peer IP address from which R2 packet was |		| Outer src | Same peer IP address from which R2 packet was |
	| address | received during base exchange |		| address | received during base exchange |
	| Outer dst | Same local IP address from which the base exchange |		| Outer dst | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| UDP src port | Source port of incoming R2 packet during base |		| UDP src port | Source port of incoming R2 packet during base |
	| | exchange |		| | exchange |
	| UDP dst port | Port 50500 |		| UDP dst port | Port 50500 |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 6: Inbound SA at initiator		Table 7: Inbound SA at initiator
	3.4.3.2. Security Associations at the Responder		3.4.3.2. Security Associations at the Responder
	The responder of a UDP-encapsulated base exchange defines its		The responder of a UDP-encapsulated base exchange defines its
	outbound SA shown in Table 7.		outbound SA shown in Table 8.
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same local IP address from which the base exchange |		| Outer src | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| Outer dst | Same peer IP as that used during base exchange |		| Outer dst | Same peer IP as that used during base exchange |
	| address | |		| address | |
	| UDP src port | Same as source port chosen during base exchange |		| UDP src port | Same as source port chosen during base exchange |
	| UDP dst port | Port 50500 |		| UDP dst port | Port 50500 |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 7: Outbound SA at Responder		Table 8: Outbound SA at Responder
	Similarly, the responder of a UDP-encapsulated base exchange defines		Similarly, the responder of a UDP-encapsulated base exchange defines
	its inbound SA as shown in Table 8		its inbound SA as shown in Table 9
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Source peer IP address as used in base exchange |		| Outer src | Source peer IP address as used in base exchange |
	| address | |		| address | |
	| Outer dst | Same local IP address from which the base exchange |		| Outer dst | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| UDP src port | Port 50500 |		| UDP src port | Port 50500 |
	| UDP dst port | Same as source port chosen during base exchange |		| UDP dst port | Same as source port chosen during base exchange |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 8: Inbound SA at responder		Table 9: Inbound SA at responder
	3.5. Both Hosts Behind NAT		3.5. Both Hosts Behind NAT
	This section describe the details of enabling NAT traversal for HIP		This section describes the details of enabling NAT traversal for HIP
	control and ESP data traffic, such as the base exchange		control and ESP data traffic, such as the base exchange
	[I-D.ietf-hip-base], through UDP encapsulation, for the case when the		[I-D.ietf-hip-base], through UDP encapsulation, for the case when the
	HIP initiator and the HIP responder are both behind two separate		HIP initiator and the HIP responder are both behind two separate
	NATs. The described mechanism applies also when the hosts are behind		NATs. The described mechanism applies also when the hosts are behind
	the same NAT but may result in inefficient routing paths, unless the		the same NAT but may result in inefficient routing paths, unless the
	countermeasures described in section Section 2 are followed. The		countermeasures described in section Section 2 are followed. The
	main limitation of this approach is that it does not work with		limitation of this approach is that it requires that the NAT boxes
	symmetric NATs.		support endpoint independent mapping
			[I-D.srisuresh-behave-p2p-state].
	This section uses the rendezvous mechanisms described in		The registration and rendezvous relay are handled similarly as
	Section 3.3.3 and Section 3.4.1. This achieves the goal by combining		described in Section 3.3.3 and Section 3.4.1. Now that both hosts
	techniques described in Section 3.3 and Section 3.4.		are behind NATs, both the initiator (Section 3.3) and responder
			(Section 3.4) mechanisms are combined here.
	3.5.1. NAT Traversal of HIP Control Traffic		3.5.1. NAT Traversal of HIP Control Traffic
	This section describes traversal mechanism for HIP control traffic in		This section describes traversal mechanism for HIP control traffic in
	the situation when both the initiator and the responder are behind		the situation when both the initiator and the responder are behind
	NATs. Both hosts MUST first detect using external mechanism that		NATs. Both hosts MUST first detect using external mechanism that
	they are located behind NAT. The RVS MUST be located on publicly		they are located behind NAT. The RVS MUST be located on publicly
	addressable network. Before initiator begins the base exchange, the		addressable network. Before initiator begins the base exchange, the
	responder MUST have completed a successful rendezvous client		responder MUST have completed a successful rendezvous client
	registration with the RVS using the mechanism described in		registration with the RVS using the mechanism described in
	Section 3.4.1.		Section 3.4.1.
	Initiator of the HIP base exchange starts the base exchange by		Initiator of the HIP base exchange starts the base exchange by
	sending an UDP encapsulated I1 packet to RVS. The UDP packet MUST		sending an UDP encapsulated I1 packet to RVS. The UDP packet MUST
	have destination port number 50500 and initiator is RECOMMENDED to		have destination port number 50500 and initiator is RECOMMENDED to
	use 50500 as source port number but it MAY as well pick a random port		use 50500 as source port number. RVS MUST listen on UDP port 50500.
	number. RVS MUST listen on UDP port 50500. RVS MUST accept the		RVS MUST accept the packet as described in Section 3.3.3. As there
	packet as described in Section 3.3.3. As there has been a successful		has been a successful rendezvous client registration between the
	rendezvous client registration between the responder and the RVS as		responder and the RVS as described in Section 3.4.1, the RVS knows
	described in Section 3.4.1, the RVS knows the port number which it		the port number which it can use to communicate with the responder
	can use to communicate with the responder through the NAT. RVS MUST		through the NAT. RVS MUST add a FROM_NAT parameter to the I1 packet.
	add a FROM_NAT parameter to the I1 packet. The FROM_NAT parameter		The FROM_NAT parameter contains the source address of the I1 packet,
	contains the source address of the I1 packet, which is effectively		which is effectively the address of the outermost NAT of the
	the address of the outermost NAT of the initiator. The RVS copies		initiator. The RVS copies the source port of the UDP encapsulated I1
	the source port of the UDP encapsulated I1 packet into the port		packet into the port number field of the FROM_NAT parameter. The
	number field of the FROM_NAT parameter. The FROM_NAT parameter is		FROM_NAT parameter is integrity protected by an RVS_HMAC as described
	integrity protected by an RVS_HMAC as described in [rvs]. RVS MUST		in [rvs]. It MUST replace the destination IP address of the I1
	zero the checksum of the I1 packet. It MUST replace the destination		packet by the one it had stored earlier during rendezvous client
	IP address of the I1 packet by the one it had stored earlier during		registration. It MUST replace source IP address of I1 packet with
	rendezvous client registration. It MUST replace source IP address of		its own address. UDP source port of the relayed I1 packet MUST be
	I1 packet with its own address. UDP source port of the relayed I1		50500 and destination port MUST be the same as one it had stored
	packet is MUST be 50500 and destination port MUST be the same as one		during the client rendezvous registration. It MUST recompute the IP
	it had stored during the client rendezvous registration. IP header		header checksum.
	checksum MUST be recomputed. RVS SHOULD then relay the I1 packet.
	The responder receives the relayed I1 packet and proceeds with the		In this case, in which the I1 was UDP encapsulated and the rendezvous
	base exchange as described in Section 3.4. The initiator MUST		client is also behind a NAT, the rendezvous server sends two packets.
	complete the base exchange as described in Section 3.3.3.		First, it MUST relay the I1 packet to the responder (rendezvous
			client) using UDP. Second, it MUST send the locator and port (as
			observed by the rendezvous) of the responder in a VIA_RVS_NAT
			parameter in a NOTIFY packet to the inititiator. However, this will
			actually launch two parallel base exchanges. In the first case, the
			initiator receives the NOTIFY message, and acts on it as described in
			section Section 3.3.3, i.e., it sends an I1 directly to the address
			in the VIA_RVS_NAT parameter and continues to retransmit packet
			through the RVS. In the second case, the responder will receive the
			I1 relayed by the rendezvous. The responder acts as described in
			section Section 3.4.2 by replying with an R1.
	+-------+		This scheme launches two parallel exchanges, one of which is phased
	+--(2)-->| |--(3)--+		later than the other. Although this kind of operation is not usually
	| | RVS | |		very desirable, it is essential to guarantee successful NAT hole
	+----+ | | | | +----+		punching. The base exchange has been designed to handle simultaneous
	+---+ | | | +-------+ | | | +---+		base exchanges and the race between the two parallel base exchange
	| |--(1)-->| |--+ +-->| |--(4)-->| |		eventually terminates after initiator is in established state.
	| | | N | | N | | |
	| |<--(7)--| A |<-------------(6)--------------| A |<--(5)--| |
	| I | | T | | T | | R |
	| |--(8)-->| - |--------------(9)------------->| - |--(10)->| |
	| | | I | | R | | |
	| |<-(13)--| |<-------------(12)-------------| |<-(11)--| |
	+---+ +----+ +----+ +---+
	1. IP(I, RVS) UDP(I-rand, 50500) I1(HIT-I, HIT-R)		+---+ +----+ +-------+ +----+ +---+
	2. IP(NAT-I, RVS) UDP(P1, 50500) I1(HIT-I, HIT-R)		| |--(1)-->| |---(2)-->+ | | | | |
	3. IP(RVS, NAT-R) UDP(50500, P)		| | | | | RVS R | | | | |
	I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,P1], RVS_HMAC)		| | | |<--(3a)--+ |---(3b)---->| | | |
	4. IP(RVS, R) UDP(50500, RVS-P)		| | | N | +-------+ | N | | |
	I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,P1], RVS_HMAC)		| |<-(4a)--| A | | A |--(4b)->| |
	5. IP(R, NAT-I) UDP(R-rand, P1) R1(HIT-R, HIT-I, VIA_RVS_NAT)		| I | | T | | T | | R |
	6. IP(NAT-R, NAT-I) UDP(P2, P1) R1(HIT-R, HIT-I, VIA_RVS_NAT)		| |--(5a)->| - | | - |<-(5b)--| |
	7. IP(NAT-R, I) UDP(P2, I-rand) R1(HIT-R, HIT-I, VIA_RVS_NAT)		| | | I |<-(6b)------------------(6a)->| R | | |
	8. IP(I, NAT-R) UDP(I-rand, P2) I2(HIT-I, HIT-R)		| | | | | | | |
	9. IP(NAT-I, NAT-R) UDP(P1, P2) I2(HIT-I, HIT-R)		....................................................................
	10. IP(NAT-I, R) UDP(P1, R-rand) I2(HIT-I, HIT-R)		+---+ +----+ +----+ +---+
	11. IP(R, NAT-I) UDP(R-rand, P1) R2(HIT-R, HIT-I)
	12. IP(NAT-R, NAT-I) UDP(P2, P1) R2(HIT-R, HIT-I)
	13. IP(NAT-R, I) UDP(P2, I-rand) R2(HIT-R, HIT-I)
	I: IP of Initiator		1. IP(IP-I, IP-RVS) UDP(50500, 50500) I1(HIT-I, HIT-R)
	R: IP of Responder		2. IP(IP-NAT-I, IP-RVS) UDP(11111, 50500) I1(HIT-I, HIT-R)
	RVS: IP of RVS
	NAT-I: Public IP of NAT-I		3a. IP(IP-RVS, IP-NAT-I) UDP(50500, 11111)
	NAT-R: Public IP of NAT-R		NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
	I-rand: Random Port Number - Chosen by initiator		3b. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444)
	R-rand: Random Port Number - Chosen by responder		I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC)
	RVS-P: Random Port Number chosen during
	rendezvous client registration		4a. IP(IP-RVS-R, IP-I) UDP(50500, 50500)
	P1: NAT Mangled Port by NAT-I for Base Exchange		NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
	P2: NAT Mangled Port by NAT-R for Base Exchange		4b. IP(IP-RVS, IP-R) UDP(50500, 50500)
	P: NAT Mangled Port for Rendezvous Client Registration		I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC)
	HIT-I: Initiator's HIT
	HIT-R: Responder's HIT		5a. IP(IP-I, IP-NAT-R) UDP(50500, 44444) I1(HIT-I, HIT-R)
			5b. IP(IP-R, IP-NAT-I) UDP(50500, 11111)
			R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500))
			6a. IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) I1(HIT-I, HIT-R)
			6b. IP(IP-NAT-R, IP-NAT-I) UDP(44444, 11111)
			R1(HIT-R, HIT-I, VIA_RVS_NAT(RVS-IP, 50500))
	Figure 10: UDP-encapsulated HIP base exchange (initiator and		Figure 10: UDP-encapsulated HIP base exchange (initiator and
	responder behind a NAT, RVS on public IP).		responder behind a NAT, RVS on public IP).
	3.5.2. NAT Traversal of HIP Data Traffic		3.5.2. NAT Traversal of HIP Data Traffic
	After a successful base exchange, both the HIP nodes have all the		After a successful base exchange, both the HIP nodes have all the
	parameters with them to establish UDP BEET mode Security Association.		parameters with them to establish UDP BEET mode Security Association.
	The following section describe inbound and outbound security		The following section describes inbound and outbound security
	associations at initiator and responder.		associations at initiator and responder.
	3.5.2.1. Security Associations at the Initiator		3.5.2.1. Security Associations at the Initiator
	The initiator of a base exchange defines its outbound SA as shown in		The initiator of a base exchange defines its outbound SA as shown in
	Table 9		Table 10
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same local IP address from which the base exchange |		| Outer src | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| Outer dst | Same peer IP address from which R2 packet was |		| Outer dst | Same peer IP address from which R2 packet was |
	| address | received during base exchange |		| address | received during base exchange |
	| UDP src port | Same as the port number chosen to send I2 during |		| UDP src port | Same as the port number chosen to send I2 during |
	| | base exchange |		| | base exchange |
	| UDP dst port | Source port of incoming R2 packet during base |		| UDP dst port | Source port of incoming R2 packet during base |
	| | exchange |		| | exchange |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 9: Outbound SA at initiator		Table 10: Outbound SA at initiator
	The initiator of a base exchange defines its inbound SA as shown in		The initiator of a base exchange defines its inbound SA as shown in
	Table 10		Table 11
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same peer IP address from which R2 packet was |		| Outer src | Same peer IP address from which R2 packet was |
	| address | received during base exchange |		| address | received during base exchange |
	| Outer dst | Same local IP address from which the base exchange |		| Outer dst | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| UDP src port | Source port of incoming R2 packet during base |		| UDP src port | Source port of incoming R2 packet during base |
	| | exchange |		| | exchange |
	| UDP dst port | Same as the port number chosen to send I2 during |		| UDP dst port | Same as the port number chosen to send I2 during |
	| | base exchange |		| | base exchange |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 10: Inbound SA at initiator		Table 11: Inbound SA at initiator
	3.5.2.2. Security Associations at the Responder		3.5.2.2. Security Associations at the Responder
	The responder of a UDP-encapsulated base exchange defines its		The responder of a UDP-encapsulated base exchange defines its
	outbound SA shown in Table 11.		outbound SA shown in Table 12.
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Same local IP address from which the base exchange |		| Outer src | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| Outer dst | Same peer IP as that used during base exchange |		| Outer dst | Same peer IP as that used during base exchange |
	| address | |		| address | |
	| UDP src port | Same as source port chosen send R2 during base |		| UDP src port | Same as source port chosen send R2 during base |
	| | exchange |		| | exchange |
	| UDP dst port | Same as source port number of I2 packet during |		| UDP dst port | Same as source port number of I2 packet during |
	| | base exchange |		| | base exchange |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 11: Outbound SA at Responder		Table 12: Outbound SA at Responder
	Similarly, the responder of a UDP-encapsulated base exchange defines		Similarly, the responder of a UDP-encapsulated base exchange defines
	its inbound SA as shown in Table 12		its inbound SA as shown in Table 13
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Field | Value |		| Field | Value |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Outer src | Source peer IP address as used in base exchange |		| Outer src | Source peer IP address as used in base exchange |
	| address | |		| address | |
	| Outer dst | Same local IP address from which the base exchange |		| Outer dst | Same local IP address from which the base exchange |
	| address | packets were transmitted |		| address | packets were transmitted |
	| UDP src port | Same as source Port received from I2 during base |		| UDP src port | Same as source Port received from I2 during base |
	| | exchange |		| | exchange |
	| UDP dst port | Same as source port used to send R2 during base |		| UDP dst port | Same as source port used to send R2 during base |
	| | exchange |		| | exchange |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	Table 12: Inbound SA at responder		Table 13: Inbound SA at responder
	3.6. NAT Keep-Alives		3.6. NAT Keep-Alives
	Typically, NATs cache an established binding and time it out if they		Typically, NATs cache an established binding and time it out if they
	have not used it to relay traffic for a given period of time. This		have not used it to relay traffic for a given period of time. This
	timeout is different for different NAT implementations. The BEHAVE		timeout is different for different NAT implementations. The BEHAVE
	working group is discussing recommendations for standardized timeout		working group is discussing recommendations for standardized timeout
	values. To prevent NAT bindings that support the traversal of UDP-		values. To prevent NAT bindings that support the traversal of UDP-
	encapsulated HIP traffic from timing out during times when there is		encapsulated HIP traffic from timing out during times when there is
	no control or data traffic, HIP hosts SHOULD send periodic keep-alive		no control or data traffic, HIP hosts SHOULD send periodic keep-alive
	skipping to change at page 26, line 26 ¶		skipping to change at page 26, line 13 ¶
	discard the keep-alives.		discard the keep-alives.
	3.7. HIP Mobility		3.7. HIP Mobility
	After a successful base exchange, either host can change its network		After a successful base exchange, either host can change its network
	location using the mechanisms defined in [I-D.ietf-hip-mm]. This		location using the mechanisms defined in [I-D.ietf-hip-mm]. This
	section describes such mobility mechanisms in the presence of NATs.		section describes such mobility mechanisms in the presence of NATs.
	However, double jump scenario, where both hosts move simultaneously,		However, double jump scenario, where both hosts move simultaneously,
	is excluded.		is excluded.
	The mobile node can change its location as described in Table 13.		The mobile node can change its location as described in Table 14.
	+----+---------------------------+----------------------------------+		+----+---------------------------+----------------------------------+
	| No | From network | To network |		| No | From network | To network |
	+----+---------------------------+----------------------------------+		+----+---------------------------+----------------------------------+
	| 1 | Behind NAT | Publicly Addressable Network |		| 1 | Behind NAT | Publicly Addressable Network |
	| 2 | Publicly Addressable | Behind NAT |		| 2 | Publicly Addressable | Behind NAT |
	| | Network | |		| | Network | |
	| 3 | Behind NAT-A | Stays behind NAT-A, but |		| 3 | Behind NAT-A | Stays behind NAT-A, but |
	| | | different IP |		| | | different IP |
	| 4 | Behind NAT-A | Behind NAT-B |		| 4 | Behind NAT-A | Behind NAT-B |
	| 5 | Publicly Addressable | Publicly Addressable Network |		| 5 | Publicly Addressable | Publicly Addressable Network |
	| | Network | |		| | Network | |
	+----+---------------------------+----------------------------------+		+----+---------------------------+----------------------------------+
	Table 13: End host mobility scenarios		Table 14: End host mobility scenarios
			The corresponding peer node can be located as follows Table 15
	The corresponding peer node can be located as follows Table 14
	+----+------------------------------------------+		+----+------------------------------------------+
	| No | Peer Node network |		| No | Peer Node network |
	+----+------------------------------------------+		+----+------------------------------------------+
	| A | Publicly Addressable Network With RVS |		| A | Publicly Addressable Network With RVS |
	| B | Publicly Addressable Network Without RVS |		| B | Publicly Addressable Network Without RVS |
	| C | Behind NAT With RVS |		| C | Behind NAT With RVS |
	| D | Behind NAT Without RVS |		| D | Behind NAT Without RVS |
	+----+------------------------------------------+		+----+------------------------------------------+
	Table 14: Peer host Network Scenarios		Table 15: Peer host Network Scenarios
	The NAT traversal mechanisms may not work when the corresponding node		The NAT traversal mechanisms may not work when the corresponding node
	is behind a NAT without RVS (case D), except when the mobile node		is behind a NAT without RVS (case D), except when the mobile node
	stays behind the same cone NAT (case 3D).		stays behind the same cone NAT (case 3D).
	When a host changes its location, it SHOULD detect the presence of		When a host changes its location, it SHOULD detect the presence of
	NATs along the new paths to its peers using some external mechanism		NATs along the new paths to its peers using some external mechanism
	before sending any UPDATE messages. Alternatively, it MAY use some		before sending any UPDATE messages. Alternatively, it MAY use some
	heuristics to conclude that it is behind a NAT rather than incur the		heuristics to conclude that it is behind a NAT rather than incur the
	latency of running NAT detection first.		latency of running NAT detection first.
	The mobile node MUST send the UPDATE packet through the corresponding		The mobile node MUST send the UPDATE packet through the corresponding
	node's RVS if it has one, in addition to sending it to the		node's RVS if it has one, in addition to sending it to the
	corresponding node directly. The mobile node encapsulates the UPDATE		corresponding node directly. The mobile node encapsulates the UPDATE
	packet within UDP only if it is behind a NAT. The corresponding node		packet within UDP only when it is behind a NAT. The corresponding
	MUST reply using UDP if the packet was encapsulated within UDP, or		node MUST reply using UDP when the packet was encapsulated within
	without UDP if the UDP header was not present in the UPDATE packet.		UDP, or without UDP when the UDP header was not present in the UPDATE
			packet.
	The rendezvous server UPDATE relaying process is similar to I1. The		The rendezvous server UPDATE relaying process is similar to I1. The
	rendezvous server MUST add FROM parameter if it gets a UPDATE packet		rendezvous server MUST add FROM parameter when it gets a UPDATE
	without UDP encapsulation, or a FROM_NAT parameter if the UPDATE		packet without UDP encapsulation, or a FROM_NAT parameter when the
	packet it receives is UDP encapsulated and MUST protect the packet		UPDATE packet it receives is UDP encapsulated and MUST protect the
	with HMACs. Upon replying to the UPDATE, the corresponding node MUST		packet with HMACs. Upon replying to the UPDATE, the corresponding
	add a VIA_RVS (or VIA_RVS_NAT) parameter to the reply.		node MUST add a VIA_RVS (or VIA_RVS_NAT) parameter to the reply.
	When the UDP encapsulation for NAT traversal is used, private IP		When the UDP encapsulation for NAT traversal is used, private IP
	addresses should be filtered out from the LOCATOR parameter in the		addresses should be filtered out from the LOCATOR parameter in the
	HIP control packets. Exposing private addresses may impose privacy		HIP control packets. Exposing private addresses may impose privacy
	related problems.		related problems.
	3.8. HIP Multihoming		3.8. HIP Multihoming
	Multiple security associations can exists between the same hosts.		Multiple security associations can exists between the same hosts.
	They may be connected through several paths, some of which may		They may be connected through several paths, some of which may
	skipping to change at page 29, line 10 ¶		skipping to change at page 28, line 37 ¶
	encapsulation of standard IP tunnel mode when two hosts behind		encapsulation of standard IP tunnel mode when two hosts behind
	different NATs have the same private IP address and initiate		different NATs have the same private IP address and initiate
	communication to the same responder in the public Internet. The		communication to the same responder in the public Internet. The
	responder cannot distinguish between the two hosts, because security		responder cannot distinguish between the two hosts, because security
	associations are based on the same inner IP addresses.		associations are based on the same inner IP addresses.
	This issue does not exist with the UDP encapsulation of IPsec BEET		This issue does not exist with the UDP encapsulation of IPsec BEET
	mode as described in Section 3, because the responder use the HITs to		mode as described in Section 3, because the responder use the HITs to
	distinguish between different communication instances.		distinguish between different communication instances.
			The rendezvous usage in this draft has been designed to follow the
			design of the RVS draft [I-D.ietf-hip-rvs] and only I1 relayed.
			However, as NAT networking presents some additional challenges, it is
			not possible two follow the RVS design exactly. Particularly, the
			mechanisms described in Figure 7 and Section 3.5.1 require that the
			rendezvous server replies back to the initiator with a message which
			includes the address and port of the responder NAT. Another design
			choice would have been to relay also the R1 (and I2 in case of both
			hosts behind NAT) through the rendezvous server to delay the exposure
			of the responder NAT address and port related information for
			additional DoS protection. However, this choice was not selected to
			reduce round trip time. As a consequence, the renzvous client must
			be accept the risk of lowered privacy protection when it registers to
			the RVS over UDP as defined in section Figure 8.
	5. IANA Considerations		5. IANA Considerations
	This section is to be interpreted according to [RFC2434].		This section is to be interpreted according to [RFC2434].
	This draft currently uses a UDP port in the "Dynamic and/or Private		This draft currently uses a UDP port in the "Dynamic and/or Private
	Port" range, i.e., 50500. Upon publication of this document, IANA is		Port" range, i.e., 50500. Upon publication of this document, IANA is
	requested to register two UDP ports and the RFC editor is requested		requested to register two UDP ports and the RFC editor is requested
	to change all occurrences of port 50500 to the port IANA has		to change all occurrences of port 50500 to the port IANA has
	registered.		registered.
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Tobias Heer, Teemu Koponen, Juhana		The authors would like to thank Tobias Heer, Teemu Koponen, Juhana
	Mattila, Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov,		Mattila, Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov,
	Janne Lindqvist and Pekka Nikander for their comments on this		Janne Lindqvist, Pekka Nikander and Lauri Silvennoinen for their
	document.		comments on this document.
	[I-D.nikander-hip-path] presented some initial ideas for NAT		[I-D.nikander-hip-path] presented some initial ideas for NAT
	traversal of HIP communication. This document describes		traversal of HIP communication. This document describes
	significantly different mechanisms that, among other differences, use		significantly different mechanisms that, among other differences, use
	external NAT discovery and do not require encapsulation servers.		external NAT discovery and do not require encapsulation servers.
	Lars Eggert and Martin Stiemerling are partly funded by Ambient		Lars Eggert and Martin Stiemerling are partly funded by Ambient
	Networks, a research project supported by the European Commission		Networks, a research project supported by the European Commission
	under its Sixth Framework Program. The views and conclusions		under its Sixth Framework Program. The views and conclusions
	contained herein are those of the authors and should not be		contained herein are those of the authors and should not be
	skipping to change at page 30, line 4 ¶		skipping to change at page 29, line 41 ¶
	interpreted as necessarily representing the official policies or		interpreted as necessarily representing the official policies or
	endorsements, either expressed or implied, of the Ambient Networks		endorsements, either expressed or implied, of the Ambient Networks
	project or the European Commission.		project or the European Commission.
	Miika Komu is working for InfraHIP research group at Helsinki		Miika Komu is working for InfraHIP research group at Helsinki
	Institute for Information Technology (HIIT). The InfraHIP project is		Institute for Information Technology (HIIT). The InfraHIP project is
	funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and		funded by Tekes, Elisa, Nokia, The Finnish Defence Forces and
	Ericsson.		Ericsson.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-hip-base]		[I-D.ietf-hip-base]
	Moskowitz, R., "Host Identity Protocol",		Moskowitz, R., "Host Identity Protocol",
	draft-ietf-hip-base-05 (work in progress), March 2006.		draft-ietf-hip-base-05 (work in progress), March 2006.
	[I-D.ietf-hip-esp]		[I-D.ietf-hip-esp]
	Jokela, P., "Using ESP transport format with HIP",		Jokela, P., "Using ESP transport format with HIP",
	draft-ietf-hip-esp-02 (work in progress), March 2006.		draft-ietf-hip-esp-02 (work in progress), March 2006.
	[I-D.ietf-hip-mm]		[I-D.ietf-hip-mm]
	Nikander, P., "End-Host Mobility and Multihoming with the		Nikander, P., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-03 (work in		Host Identity Protocol", draft-ietf-hip-mm-03 (work in
	progress), March 2006.		progress), March 2006.
			[I-D.ietf-hip-rvs]
			Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
			Rendezvous Extension", draft-ietf-hip-rvs-04 (work in
			progress), October 2005.
	[I-D.nikander-esp-beet-mode]		[I-D.nikander-esp-beet-mode]
	Melen, J. and P. Nikander, "A Bound End-to-End Tunnel		Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
	(BEET) mode for ESP", draft-nikander-esp-beet-mode-05		(BEET) mode for ESP", draft-nikander-esp-beet-mode-05
	(work in progress), February 2006.		(work in progress), February 2006.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 30, line 42 ¶		skipping to change at page 30, line 38 ¶
	October 1998.		October 1998.
	[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	(HIP) Architecture", RFC 4423, May 2006.		(HIP) Architecture", RFC 4423, May 2006.
	[rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		[rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension".		Rendezvous Extension".
	7.2. Informative References		7.2. Informative References
			[I-D.ietf-behave-nat-udp]
			Audet, F. and C. Jennings, "NAT Behavioral Requirements
			for Unicast UDP", draft-ietf-behave-nat-udp-07 (work in
			progress), June 2006.
	[I-D.irtf-hiprg-nat]		[I-D.irtf-hiprg-nat]
	Stiemerling, M., "NAT and Firewall Traversal Issues of		Stiemerling, M., "NAT and Firewall Traversal Issues of
	Host Identity Protocol (HIP) Communication",		Host Identity Protocol (HIP) Communication",
	draft-irtf-hiprg-nat-02 (work in progress), May 2006.		draft-irtf-hiprg-nat-02 (work in progress), May 2006.
	[I-D.nikander-hip-path]		[I-D.nikander-hip-path]
	Nikander, P., "Preferred Alternatives for Tunnelling HIP		Nikander, P., "Preferred Alternatives for Tunnelling HIP
	(PATH)", draft-nikander-hip-path-01 (work in progress),		(PATH)", draft-nikander-hip-path-01 (work in progress),
	March 2006.		March 2006.
	[I-D.srisuresh-behave-p2p-state]		[I-D.srisuresh-behave-p2p-state]
	Srisuresh, P., "State of Peer-to-Peer(P2P) Communication		Srisuresh, P., "State of Peer-to-Peer(P2P) Communication
	Across Network Address Translators(NATs)",		Across Network Address Translators(NATs)",
	draft-srisuresh-behave-p2p-state-02 (work in progress),		draft-srisuresh-behave-p2p-state-03 (work in progress),
	March 2006.		June 2006.
	[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address		[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
	Translator (NAT) Terminology and Considerations",		Translator (NAT) Terminology and Considerations",
	RFC 2663, August 1999.		RFC 2663, August 1999.
	[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,		[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
	"STUN - Simple Traversal of User Datagram Protocol (UDP)		"STUN - Simple Traversal of User Datagram Protocol (UDP)
	Through Network Address Translators (NATs)", RFC 3489,		Through Network Address Translators (NATs)", RFC 3489,
	March 2003.		March 2003.
	skipping to change at page 33, line 47 ¶		skipping to change at page 33, line 47 ¶
	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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is provided by the IETF		Funding for the RFC Editor function is currently provided by the
	Administrative Support Activity (IASA).		Internet Society.
End of changes. 107 change blocks.
	353 lines changed or deleted		400 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/