< draft-ietf-hip-rvs-04.txt		draft-ietf-hip-rvs-05.txt >
	Network Working Group J. Laganier		Network Working Group J. Laganier
	Internet-Draft DoCoMo Euro-Labs		Internet-Draft DoCoMo Euro-Labs
	Expires: April 13, 2006 L. Eggert		Expires: December 9, 2006 L. Eggert
	NEC		NEC
	October 10, 2005		June 7, 2006
	Host Identity Protocol (HIP) Rendezvous Extension		Host Identity Protocol (HIP) Rendezvous Extension
	draft-ietf-hip-rvs-04		draft-ietf-hip-rvs-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 13, 2006.		This Internet-Draft will expire on December 9, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document defines a rendezvous extension for the Host Identity		This document defines a rendezvous extension for the Host Identity
	Protocol (HIP). The rendezvous extension extends HIP and the HIP		Protocol (HIP). The rendezvous extension extends HIP and the HIP
	registration extension for initiating communication between HIP nodes		registration extension for initiating communication between HIP nodes
	via HIP rendezvous servers. Rendezvous servers improve reachability		via HIP rendezvous servers. Rendezvous servers improve reachability
	and operation when HIP nodes are multi-homed or mobile.		and operation when HIP nodes are multi-homed or mobile.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4		3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
	3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5		3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
	3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 5		3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 5
	3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 6		3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
	4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7		4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
	4.1 RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7		4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
	4.2 Parameter Formats and Processing . . . . . . . . . . . . . 7		4.2. Parameter Formats and Processing . . . . . . . . . . . . . 7
	4.2.1 RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 7		4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 7
	4.2.2 FROM Parameter . . . . . . . . . . . . . . . . . . . . 8		4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 8
	4.2.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9		4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9
	4.3 Modified Packets Processing . . . . . . . . . . . . . . . 9		4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9
	4.3.1 Processing Outgoing I1 Packets . . . . . . . . . . . . 9		4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 9
	4.3.2 Processing Incoming I1 packets . . . . . . . . . . . . 10		4.3.2. Processing Incoming I1 packets . . . . . . . . . . . . 10
	4.3.3 Processing Outgoing R1 Packets . . . . . . . . . . . . 10		4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 10
	4.3.4 Processing Incoming R1 packets . . . . . . . . . . . . 10		4.3.4. Processing Incoming R1 packets . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2 Informative References . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Host Identity Protocol architecture [I-D.ietf-hip-arch]		The Host Identity Protocol architecture [RFC4423] introduces the
	introduces the rendezvous mechanism to help a HIP node to contact a		rendezvous mechanism to help a HIP node to contact a frequently
	frequently moving HIP node. The rendezvous mechanism involves a		moving HIP node. The rendezvous mechanism involves a third party,
	third party, the rendezvous server (RVS), which serves as an initial		the rendezvous server (RVS), which serves as an initial contact point
	contact point ("rendezvous point") for its clients. The clients of		("rendezvous point") for its clients. The clients of an RVS are HIP
	an RVS are HIP nodes that use the HIP Registration Protocol		nodes that use the HIP Registration Protocol [I-D.ietf-hip-
	[I-D.ietf-hip-registration] to register their HIT->IP address		registration] to register their HIT->IP address mappings with the
	mappings with the RVS. After this registration, other HIP nodes can		RVS. After this registration, other HIP nodes can initiate a base
	initiate a base exchange using the IP address of the RVS instead of		exchange using the IP address of the RVS instead of the current IP
	the current IP address of the node they attempt to contact.		address of the node they attempt to contact. Essentially, the
	Essentially, the clients of an RVS become reachable at the RVS' IP		clients of an RVS become reachable at the RVS' IP addresses. Peers
	addresses. Peers can initiate a HIP base exchange with the IP		can initiate a HIP base exchange with the IP address of the RVS,
	address of the RVS, which will relay this initial communication such		which will relay this initial communication such that the base
	that the base exchange may successfully complete.		exchange may successfully complete.
	2. Terminology		2. Terminology
	This section defines terms used throughout the remainder of this		This section defines terms used throughout the remainder of this
	specification.		specification.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	the responder by sending an I1 packet to the responder's IP address,		the responder by sending an I1 packet to the responder's IP address,
	as per the HIP base specification [I-D.ietf-hip-base].		as per the HIP base specification [I-D.ietf-hip-base].
	+-----+ +-----+		+-----+ +-----+
	| |-------I1------>| |		| |-------I1------>| |
	| I |<------R1-------| R |		| I |<------R1-------| R |
	| |-------I2------>| |		| |-------I2------>| |
	| |<------R2-------| |		| |<------R2-------| |
	+-----+ +-----+		+-----+ +-----+
	Figure 1: HIP base exchange without rendezvous server.		Figure 1: HIP base exchange without rendezvous server.
	Proposed extensions for mobility and multi-homing [I-D.ietf-hip-mm]		Proposed extensions for mobility and multi-homing [I-D.ietf-hip-mm]
	allow a HIP node to notify its peers about changes in its set of IP		allow a HIP node to notify its peers about changes in its set of IP
	addresses. These extensions presumes initial reachability of the two		addresses. These extensions presumes initial reachability of the two
	nodes with respect to each other.		nodes with respect to each other.
	However, such a HIP node MAY also want to be reachable to other		However, such a HIP node MAY also want to be reachable to other
	future correspondent peers that are unaware of its location change.		future correspondent peers that are unaware of its location change.
	The HIP architecture [I-D.ietf-hip-arch] introduces rendezvous		The HIP architecture [RFC4423] introduces rendezvous servers with
	servers with whom a HIP node MAY register its host identity tags		whom a HIP node MAY register its host identity tags (HITs) and
	(HITs) and current IP addresses. An RVS relays HIP packets arriving		current IP addresses. An RVS relays HIP packets arriving for these
	for these HITs to the node's registered IP addresses. When a HIP		HITs to the node's registered IP addresses. When a HIP node has
	node has registered with an RVS, it SHOULD record the IP address of		registered with an RVS, it SHOULD record the IP address of its RVS in
	its RVS in its DNS record, using the HIPRVS DNS record type defined		its DNS record, using the HIPRVS DNS record type defined in
	in [I-D.ietf-hip-dns].		[I-D.ietf-hip-dns].
	+-----+		+-----+
	+--I1--->| RVS |---I1--+		+--I1--->| RVS |---I1--+
	| +-----+ |		| +-----+ |
	| v		| v
	+-----+ +-----+		+-----+ +-----+
	| |<------R1-------| |		| |<------R1-------| |
	| I |-------I2------>| R |		| I |-------I2------>| R |
	| |<------R2-------| |		| |<------R2-------| |
	+-----+ +-----+		+-----+ +-----+
	Figure 2: HIP base exchange with a rendezvous server.		Figure 2: HIP base exchange with a rendezvous server.
	Figure 2 shows a HIP base exchange involving a rendezvous server. It		Figure 2 shows a HIP base exchange involving a rendezvous server. It
	is assumed that HIP node R previously registered its HITs and current		is assumed that HIP node R previously registered its HITs and current
	IP addresses with the RVS, using the HIP registration protocol		IP addresses with the RVS, using the HIP registration protocol
	[I-D.ietf-hip-registration]. When the initiator I tries to establish		[I-D.ietf-hip-registration]. When the initiator I tries to establish
	contact with the responder R, it must send the I1 of the base		contact with the responder R, it must send the I1 of the base
	exchange either to one of R's IP addresses (if known via DNS or other		exchange either to one of R's IP addresses (if known via DNS or other
	means) or to one of R's rendezvous servers instead. Here, I obtains		means) or to one of R's rendezvous servers instead. Here, I obtains
	the IP address of R's rendezvous server from R's DNS record and then		the IP address of R's rendezvous server from R's DNS record and then
	sends the I1 packet of the HIP base exchange to RVS. RVS, noticing		sends the I1 packet of the HIP base exchange to RVS. RVS, noticing
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	relay the packets. Here, it determines that the HIT belongs to R and		relay the packets. Here, it determines that the HIT belongs to R and
	then relays the I1 packet to the registered IP address. R then		then relays the I1 packet to the registered IP address. R then
	completes the base exchange without further assistance from RVS by		completes the base exchange without further assistance from RVS by
	sending an R1 directly to the I's IP address, as obtained from the I1		sending an R1 directly to the I's IP address, as obtained from the I1
	packet. In this specification the client of the RVS is always the		packet. In this specification the client of the RVS is always the
	responder. However, there might be reasons to allow a client to		responder. However, there might be reasons to allow a client to
	initiate a base exchange through its own RVS, like NAT and firewall		initiate a base exchange through its own RVS, like NAT and firewall
	traversal. This specification does not address such scenarios which		traversal. This specification does not address such scenarios which
	should be specified in other documents.		should be specified in other documents.
	3.1 Diagram Notation		3.1. Diagram Notation
	Notation Significance		Notation Significance
	-------- ------------		-------- ------------
	I, R I and R are the respective source and destination IP		I, R I and R are the respective source and destination IP
	addresses in the IP header.		addresses in the IP header.
	HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the		HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the
	responder's HITs in the packet, respectively.		responder's HITs in the packet, respectively.
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	FROM:I A FROM parameter containing the IP address I is		FROM:I A FROM parameter containing the IP address I is
	present in the HIP header.		present in the HIP header.
	RVS_HMAC A RVS_HMAC parameter containing a HMAC keyed with the		RVS_HMAC A RVS_HMAC parameter containing a HMAC keyed with the
	appropriate registration key is present in the HIP		appropriate registration key is present in the HIP
	header.		header.
	VIA:RVS A VIA_RVS parameter containing the IP address RVS of a		VIA:RVS A VIA_RVS parameter containing the IP address RVS of a
	rendezvous server is present in the HIP header.		rendezvous server is present in the HIP header.
	3.2 Rendezvous Client Registration		3.2. Rendezvous Client Registration
	Before a rendezvous server starts to relay HIP packets to a		Before a rendezvous server starts to relay HIP packets to a
	rendezvous client, the rendezvous client needs to register with it to		rendezvous client, the rendezvous client needs to register with it to
	receive rendezvous service by using the HIP registration extension		receive rendezvous service by using the HIP registration extension
	[I-D.ietf-hip-registration] as illustrated in the following schema:		[I-D.ietf-hip-registration] as illustrated in the following schema:
	+-----+ +-----+		+-----+ +-----+
	| | I1 | |		| | I1 | |
	| |--------------------------->| |		| |--------------------------->| |
	| |<---------------------------| |		| |<---------------------------| |
	| I | R1(REG_INFO) | RVS |		| I | R1(REG_INFO) | RVS |
	| | I2(REG_REQ) | |		| | I2(REG_REQ) | |
	| |--------------------------->| |		| |--------------------------->| |
	| |<---------------------------| |		| |<---------------------------| |
	| | R2(REG_RES) | |		| | R2(REG_RES) | |
	+-----+ +-----+		+-----+ +-----+
	3.3 Relaying the Base Exchange		3.3. Relaying the Base Exchange
	If a HIP node and one of its rendezvous servers have a rendezvous		If a HIP node and one of its rendezvous servers have a rendezvous
	registration, the rendezvous servers relay inbound I1 packets that		registration, the rendezvous servers relay inbound I1 packets that
	contain one of the client's HITs by rewriting the IP header. They		contain one of the client's HITs by rewriting the IP header. They
	replace the destination IP address of the I1 packet with one of the		replace the destination IP address of the I1 packet with one of the
	IP addresses of the owner of the HIT, i.e., the rendezvous client.		IP addresses of the owner of the HIT, i.e., the rendezvous client.
	They MUST also recompute the IP checksum accordingly.		They MUST also recompute the IP checksum accordingly.
	Because of egress filtering on the path from the RVS to the client		Because of egress filtering on the path from the RVS to the client
	[RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source		[RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source
	IP address, i.e., the IP address of I, with one of its own IP		IP address, i.e., the IP address of I, with one of its own IP
	addresses. The replacement IP address SHOULD be chosen according to		addresses. The replacement IP address SHOULD be chosen according to
	[RFC1122] and, when IPv6 is used, to [RFC3484]. Because this		[RFC1122] and, when IPv6 is used, to [RFC3484]. Because this
	replacement conceals the initiator's IP address, the RVS MUST append		replacement conceals the initiator's IP address, the RVS MUST append
	a FROM parameter containing the original source IP address of the		a FROM parameter containing the original source IP address of the
	packet. This FROM parameter MUST be integrity protected by an		packet. This FROM parameter MUST be integrity protected by an
	RVS_HMAC keyed with the corresponding rendezvous registration		RVS_HMAC keyed with the corresponding rendezvous registration
	integrity key [I-D.ietf-hip-registration].		integrity key [I-D.ietf-hip-registration].
	I1(RVS, R, HIT-I, HIT-R		I1(RVS, R, HIT-I, HIT-R
	I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)		I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
	+----------------------->| |--------------------+		+----------------------->| |--------------------+
	| | RVS | |		| | RVS | |
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 26 ¶
	4. Rendezvous Server Extensions		4. Rendezvous Server Extensions
	The following sections describe extensions to the HIP registration		The following sections describe extensions to the HIP registration
	protocol [I-D.ietf-hip-registration], allowing a HIP node to register		protocol [I-D.ietf-hip-registration], allowing a HIP node to register
	with a rendezvous server for rendezvous service and notify the RVS		with a rendezvous server for rendezvous service and notify the RVS
	aware of changes to its current location. It also describes an		aware of changes to its current location. It also describes an
	extension to the HIP protocol [I-D.ietf-hip-base] itself, allowing		extension to the HIP protocol [I-D.ietf-hip-base] itself, allowing
	establishment of HIP associations via one or more HIP rendezvous		establishment of HIP associations via one or more HIP rendezvous
	server(s).		server(s).
	4.1 RENDEZVOUS Registration Type		4.1. RENDEZVOUS Registration Type
	This specification defines an additional registration for the HIP		This specification defines an additional registration for the HIP
	registration protocol [I-D.ietf-hip-registration] that allows		registration protocol [I-D.ietf-hip-registration] that allows
	registering with a rendezvous server for rendezvous service.		registering with a rendezvous server for rendezvous service.
	Number Registration Type		Number Registration Type
	------ -----------------		------ -----------------
	1 RENDEZVOUS		1 RENDEZVOUS
	4.2 Parameter Formats and Processing		4.2. Parameter Formats and Processing
	4.2.1 RVS_HMAC Parameter		4.2.1. RVS_HMAC Parameter
	The RVS_HMAC is a non-critical parameter whose only difference with		The RVS_HMAC is a non-critical parameter whose only difference with
	the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code.		the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code.
	This change causes it to be located after the FROM parameter (as		This change causes it to be located after the FROM parameter (as
	opposed to the HMAC):		opposed to the HMAC):
	Type [ TBD by IANA (65500 = 2^16 - 2^5 - 2^2) ]		Type [ TBD by IANA (65500 = 2^16 - 2^5 - 2^2) ]
	Length 20		Length 20
	HMAC 160 low order bits of a HMAC keyed with the		HMAC 160 low order bits of a HMAC keyed with the
	appropriate HIP integrity key (HIP_lg or HIP_gl),		appropriate HIP integrity key (HIP_lg or HIP_gl),
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	not to cover any excluded parameter when the		not to cover any excluded parameter when the
	"authenticator" field is calculated.		"authenticator" field is calculated.
	To allow a rendezvous client and its RVS to verify the integrity of		To allow a rendezvous client and its RVS to verify the integrity of
	packets flowing between them, both SHOULD protect packets with an		packets flowing between them, both SHOULD protect packets with an
	added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity		added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity
	key established while registration occurred. A valid RVS_HMAC SHOULD		key established while registration occurred. A valid RVS_HMAC SHOULD
	be present on every packets flowing between a client and a server and		be present on every packets flowing between a client and a server and
	MUST be present when a FROM parameters is processed.		MUST be present when a FROM parameters is processed.
	4.2.2 FROM Parameter		4.2.2. FROM 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 |
	| |		| |
	| |		| |
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	A rendezvous server MUST add a FROM parameter containing the original		A rendezvous server MUST add a FROM parameter containing the original
	source IP address of a HIP packet whenever the source IP address in		source IP address of a HIP packet whenever the source IP address in
	the IP header is rewritten. If one or more FROM parameters are		the IP header is rewritten. If one or more FROM parameters are
	already present, the new FROM parameter MUST be appended after the		already present, the new FROM parameter MUST be appended after the
	existing ones.		existing ones.
	Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC		Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC
	protecting the packet integrity, especially the IP address included		protecting the packet integrity, especially the IP address included
	in the FROM parameter.		in the FROM parameter.
	4.2.3 VIA_RVS Parameter		4.2.3. VIA_RVS 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 |
	| |		| |
	| |		| |
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	After the responder receives a relayed I1 packet, it can begin to		After the responder receives a relayed I1 packet, it can begin to
	send HIP packets addressed to the initiator's IP address, without		send HIP packets addressed to the initiator's IP address, without
	further assistance from an RVS. For debugging purposes, it MAY		further assistance from an RVS. For debugging purposes, it MAY
	include a subset of the IP addresses of its RVSs in some of these		include a subset of the IP addresses of its RVSs in some of these
	packets. When a responder does so, it MUST append a newly created		packets. When a responder does so, it MUST append a newly created
	VIA_RVS parameter at the end of the HIP packet. The main goal of		VIA_RVS parameter at the end of the HIP packet. The main goal of
	using the VIA_RVS parameter is to allow operators to diagnose		using the VIA_RVS parameter is to allow operators to diagnose
	possible issues encountered while establishing a HIP association via		possible issues encountered while establishing a HIP association via
	an RVS.		an RVS.
	4.3 Modified Packets Processing		4.3. Modified Packets Processing
	The following subsections describe the differences of processing of		The following subsections describe the differences of processing of
	I1 and R1 while a rendezvous server is involved in the base exchange.		I1 and R1 while a rendezvous server is involved in the base exchange.
	4.3.1 Processing Outgoing I1 Packets		4.3.1. Processing Outgoing I1 Packets
	An initiator SHOULD NOT send an opportunistic I1 with a NULL		An initiator SHOULD NOT send an opportunistic I1 with a NULL
	destination HIT to an IP address which is known to be a rendezvous		destination HIT to an IP address which is known to be a rendezvous
	server address, unless it wants to establish a HIP association with		server address, unless it wants to establish a HIP association with
	the rendezvous server itself and does not know its HIT.		the rendezvous server itself and does not know its HIT.
	When an RVS rewrites the source IP address of an I1 packet due to		When an RVS rewrites the source IP address of an I1 packet due to
	egress filtering, it MUST add a FROM parameter to the I1 that		egress filtering, it MUST add a FROM parameter to the I1 that
	contains the initiator's source IP address. This FROM parameter MUST		contains the initiator's source IP address. This FROM parameter MUST
	be protected by an RVS_HMAC keyed with the integrity key established		be protected by an RVS_HMAC keyed with the integrity key established
	at rendezvous registration.		at rendezvous registration.
	4.3.2 Processing Incoming I1 packets		4.3.2. Processing Incoming I1 packets
	When a rendezvous server receives an I1 whose destination HIT is not		When a rendezvous server receives an I1 whose destination HIT is not
	its own, it consults its registration database to find a registration		its own, it consults its registration database to find a registration
	for the rendezvous service established by the HIT owner. If it finds		for the rendezvous service established by the HIT owner. If it finds
	an appropriate registration, it relays the packet to the registered		an appropriate registration, it relays the packet to the registered
	IP address. If it does not find an appropriate registration, it		IP address. If it does not find an appropriate registration, it
	drops the packet.		drops the packet.
	A rendezvous server SHOULD interpret any incoming opportunistic I1		A rendezvous server SHOULD interpret any incoming opportunistic I1
	(i.e., an I1 with a NULL destination HIT) as an I1 addressed to		(i.e., an I1 with a NULL destination HIT) as an I1 addressed to
	skipping to change at page 10, line 31 ¶		skipping to change at page 10, line 31 ¶
	When a rendezvous client receives an I1, it MUST validate any present		When a rendezvous client receives an I1, it MUST validate any present
	RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet		RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet
	SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM		SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM
	parameter is present, the packet MUST be dropped.		parameter is present, the packet MUST be dropped.
	A rendezvous client acting as responder SHOULD drop opportunistic I1s		A rendezvous client acting as responder SHOULD drop opportunistic I1s
	that include a FROM parameter, because this indicates that the I1 has		that include a FROM parameter, because this indicates that the I1 has
	been relayed.		been relayed.
	4.3.3 Processing Outgoing R1 Packets		4.3.3. Processing Outgoing R1 Packets
	When a responder replies to an I1 relayed via an RVS, it MUST append		When a responder replies to an I1 relayed via an RVS, it MUST append
	to the regular R1 header a VIA_RVS parameter containing the IP		to the regular R1 header a VIA_RVS parameter containing the IP
	addresses of the traversed RVS's.		addresses of the traversed RVS's.
	4.3.4 Processing Incoming R1 packets		4.3.4. Processing Incoming R1 packets
	The HIP base specification [I-D.ietf-hip-base] mandates that a system		The HIP base specification [I-D.ietf-hip-base] mandates that a system
	receiving an R1 MUST first check to see if it has sent an I1 to the		receiving an R1 MUST first check to see if it has sent an I1 to the
	originator of the R1 (i.e., it is in state I1-SENT). When the R1 is		originator of the R1 (i.e., it is in state I1-SENT). When the R1 is
	replying to a relayed I1, this check SHOULD be based on HITs only.		replying to a relayed I1, this check SHOULD be based on HITs only.
	In case the IP addresses are also checked, then the source IP address		In case the IP addresses are also checked, then the source IP address
	MUST be checked against the IP address included in the VIA_RVS		MUST be checked against the IP address included in the VIA_RVS
	parameter.		parameter.
	5. Security Considerations		5. Security Considerations
	skipping to change at page 12, line 16 ¶		skipping to change at page 12, line 18 ¶
	Julien Laganier and Lars Eggert are partly funded by Ambient		Julien Laganier and Lars Eggert 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
	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.
	8. References		8. References
	8.1 Normative References		8.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-03 (work in progress), June 2005.		draft-ietf-hip-base-05 (work in progress), March 2006.
	[I-D.ietf-hip-dns]		[I-D.ietf-hip-dns]
	Nikander, P. and J. Laganier, "Host Identity Protocol		Nikander, P. and J. Laganier, "Host Identity Protocol
	(HIP) Domain Name System (DNS) Extensions",		(HIP) Domain Name System (DNS) Extensions",
	draft-ietf-hip-dns-03 (work in progress), October 2005.		draft-ietf-hip-dns-06 (work in progress), February 2006.
	[I-D.ietf-hip-registration]		[I-D.ietf-hip-registration]
	Laganier, J., "Host Identity Protocol (HIP) Registration		Laganier, J., "Host Identity Protocol (HIP) Registration
	Extension", draft-ietf-hip-registration-00 (work in		Extension", draft-ietf-hip-registration-01 (work in
	progress), September 2005.		progress), December 2005.
	[RFC1122] Braden, R., "Requirements for Internet Hosts -		[RFC1122] Braden, R., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	[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.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[RFC3484] Draves, R., "Default Address Selection for Internet		[RFC3484] Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.		Protocol version 6 (IPv6)", RFC 3484, February 2003.
	8.2 Informative References		8.2. Informative References
	[I-D.ietf-hip-arch]
	Moskowitz, R. and P. Nikander, "Host Identity Protocol
	Architecture", draft-ietf-hip-arch-03 (work in progress),
	August 2005.
	[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-02 (work in		Host Identity Protocol", draft-ietf-hip-mm-03 (work in
	progress), July 2005.		progress), March 2006.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC3013] Killalea, T., "Recommended Internet Service Provider		[RFC3013] Killalea, T., "Recommended Internet Service Provider
	Security Services and Procedures", BCP 46, RFC 3013,		Security Services and Procedures", BCP 46, RFC 3013,
	November 2000.		November 2000.
			[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
			(HIP) Architecture", RFC 4423, May 2006.
	Authors' Addresses		Authors' Addresses
	Julien Laganier		Julien Laganier
	DoCoMo Communications Laboratories Europe GmbH		DoCoMo Communications Laboratories Europe GmbH
	Landsberger Strasse 312		Landsberger Strasse 312
	Munich 80687		Munich 80687
	Germany		Germany
	Phone: +49 89 56824 231		Phone: +49 89 56824 231
	Email: julien.ietf@laposte.net		Email: julien.ietf@laposte.net
	skipping to change at page 14, line 41 ¶		skipping to change at page 15, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 34 change blocks.
	73 lines changed or deleted		71 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/