< draft-ietf-hip-mm-04.txt		draft-ietf-hip-mm-05.txt >
	Network Working Group T. Henderson (editor)		Network Working Group T. Henderson (editor)
	Internet-Draft The Boeing Company		Internet-Draft The Boeing Company
	Expires: December 25, 2006 June 23, 2006		Expires: September 3, 2007 March 2, 2007
	End-Host Mobility and Multihoming with the Host Identity Protocol		End-Host Mobility and Multihoming with the Host Identity Protocol
	draft-ietf-hip-mm-04		draft-ietf-hip-mm-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 33 ¶		skipping to change at page 1, line 33 ¶
	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 25, 2006.		This Internet-Draft will expire on September 3, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines mobility and multihoming extensions to the Host		This document defines mobility and multihoming extensions to the Host
	Identity Protocol (HIP). Specifically, this document defines a		Identity Protocol (HIP). Specifically, this document defines a
	general "LOCATOR" parameter for HIP messages that allows for a HIP		general "LOCATOR" parameter for HIP messages that allows for a HIP
	host to notify peers about alternate addresses at which it may be		host to notify peers about alternate addresses at which it may be
	reached. This document also defines elements of procedure for		reached. This document also defines elements of procedure for
	mobility of a HIP host-- the process by which a host dynamically		mobility of a HIP host-- the process by which a host dynamically
	changes the primary locator that it uses to receive packets. While		changes the primary locator that it uses to receive packets. While
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 33 ¶
	3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 9		3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1.2. Mobility overview . . . . . . . . . . . . . . . . . . 9		3.1.2. Mobility overview . . . . . . . . . . . . . . . . . . 9
	3.1.3. Multihoming overview . . . . . . . . . . . . . . . . . 10		3.1.3. Multihoming overview . . . . . . . . . . . . . . . . . 10
	3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10		3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. Mobility with single SA pair (no rekeying) . . . . . . 11		3.2.1. Mobility with single SA pair (no rekeying) . . . . . . 11
	3.2.2. Mobility with single SA pair (mobile-initiated		3.2.2. Mobility with single SA pair (mobile-initiated
	rekey) . . . . . . . . . . . . . . . . . . . . . . . . 12		rekey) . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.2.3. Host multihoming . . . . . . . . . . . . . . . . . . . 13		3.2.3. Host multihoming . . . . . . . . . . . . . . . . . . . 13
	3.2.4. Site multihoming . . . . . . . . . . . . . . . . . . . 14		3.2.4. Site multihoming . . . . . . . . . . . . . . . . . . . 14
	3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 15		3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 15
	3.2.6. Combined mobility and multihoming . . . . . . . . . . 15		3.2.6. Combined mobility and multihoming . . . . . . . . . . 16
	3.2.7. Using LOCATORs across addressing realms . . . . . . . 16		3.2.7. Using LOCATORs across addressing realms . . . . . . . 16
	3.2.8. Network renumbering . . . . . . . . . . . . . . . . . 16		3.2.8. Network renumbering . . . . . . . . . . . . . . . . . 16
	3.2.9. Initiating the protocol in R1 or I2 . . . . . . . . . 16		3.2.9. Initiating the protocol in R1 or I2 . . . . . . . . . 16
	3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 17		3.3. Other Considerations . . . . . . . . . . . . . . . . . . . 18
	3.3.1. Address Verification . . . . . . . . . . . . . . . . . 18		3.3.1. Address Verification . . . . . . . . . . . . . . . . . 18
	3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 18		3.3.2. Credit-Based Authorization . . . . . . . . . . . . . . 18
	3.3.3. Preferred locator . . . . . . . . . . . . . . . . . . 19		3.3.3. Preferred locator . . . . . . . . . . . . . . . . . . 19
	3.3.4. Interaction with Security Associations . . . . . . . . 20		3.3.4. Interaction with Security Associations . . . . . . . . 20
	4. LOCATOR parameter format . . . . . . . . . . . . . . . . . . . 23		4. LOCATOR parameter format . . . . . . . . . . . . . . . . . . . 23
	4.1. Traffic Type and Preferred locator . . . . . . . . . . . . 24		4.1. Traffic Type and Preferred locator . . . . . . . . . . . . 24
	4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 25		4.2. Locator Type and Locator . . . . . . . . . . . . . . . . . 25
	4.3. UPDATE packet with included LOCATOR . . . . . . . . . . . 25		4.3. UPDATE packet with included LOCATOR . . . . . . . . . . . 25
	5. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 26		5. Processing rules . . . . . . . . . . . . . . . . . . . . . . . 26
	5.1. Locator data structure and status . . . . . . . . . . . . 26		5.1. Locator data structure and status . . . . . . . . . . . . 26
	5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 27		5.2. Sending LOCATORs . . . . . . . . . . . . . . . . . . . . . 27
	5.3. Handling received LOCATORs . . . . . . . . . . . . . . . . 29		5.3. Handling received LOCATORs . . . . . . . . . . . . . . . . 29
	5.4. Verifying address reachability . . . . . . . . . . . . . . 30		5.4. Verifying address reachability . . . . . . . . . . . . . . 31
	5.5. Changing the Preferred locator . . . . . . . . . . . . . . 31		5.5. Changing the Preferred locator . . . . . . . . . . . . . . 32
	5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 32		5.6. Credit-Based Authorization . . . . . . . . . . . . . . . . 33
	5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 32		5.6.1. Handling Payload Packets . . . . . . . . . . . . . . . 33
	5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 34		5.6.2. Credit Aging . . . . . . . . . . . . . . . . . . . . . 35
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 36		6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	6.1. Impersonation attacks . . . . . . . . . . . . . . . . . . 36		6.1. Impersonation attacks . . . . . . . . . . . . . . . . . . 37
	6.2. Denial of Service attacks . . . . . . . . . . . . . . . . 37		6.2. Denial of Service attacks . . . . . . . . . . . . . . . . 38
	6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 37		6.2.1. Flooding Attacks . . . . . . . . . . . . . . . . . . . 38
	6.2.2. Memory/Computational exhaustion DoS attacks . . . . . 38		6.2.2. Memory/Computational exhaustion DoS attacks . . . . . 39
	6.3. Mixed deployment environment . . . . . . . . . . . . . . . 38		6.3. Mixed deployment environment . . . . . . . . . . . . . . . 39
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 41		8. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 42
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9.1. Normative references . . . . . . . . . . . . . . . . . . . 42		9.1. Normative references . . . . . . . . . . . . . . . . . . . 43
	9.2. Informative references . . . . . . . . . . . . . . . . . . 42		9.2. Informative references . . . . . . . . . . . . . . . . . . 43
	Appendix A. Changes from previous versions . . . . . . . . . . . 43		Appendix A. Changes from previous versions . . . . . . . . . . . 44
	A.1. From nikander-hip-mm-00 to nikander-hip-mm-01 . . . . . . 43		A.1. From nikander-hip-mm-00 to nikander-hip-mm-01 . . . . . . 44
	A.2. From nikander-hip-mm-01 to nikander-hip-mm-02 . . . . . . 43		A.2. From nikander-hip-mm-01 to nikander-hip-mm-02 . . . . . . 44
	A.3. From -02 to draft-ietf-hip-mm-00 . . . . . . . . . . . . . 43		A.3. From -02 to draft-ietf-hip-mm-00 . . . . . . . . . . . . . 44
	A.4. From draft-ietf-hip-mm-00 to -01 . . . . . . . . . . . . . 44		A.4. From draft-ietf-hip-mm-00 to -01 . . . . . . . . . . . . . 45
	A.5. From draft-ietf-hip-mm-01 to -02 . . . . . . . . . . . . . 44		A.5. From draft-ietf-hip-mm-01 to -02 . . . . . . . . . . . . . 45
	A.6. From draft-ietf-hip-mm-02 to -03 . . . . . . . . . . . . . 44		A.6. From draft-ietf-hip-mm-02 to -03 . . . . . . . . . . . . . 45
	A.7. From draft-ietf-hip-mm-03 to -04 . . . . . . . . . . . . . 45		A.7. From draft-ietf-hip-mm-03 to -04 . . . . . . . . . . . . . 46
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46		A.8. From draft-ietf-hip-mm-04 to -05 . . . . . . . . . . . . . 46
	Intellectual Property and Copyright Statements . . . . . . . . . . 47		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
			Intellectual Property and Copyright Statements . . . . . . . . . . 48
	1. Introduction and Scope		1. Introduction and Scope
	The Host Identity Protocol [1] (HIP) supports an architecture that		The Host Identity Protocol [1] (HIP) supports an architecture that
	decouples the transport layer (TCP, UDP, etc.) from the		decouples the transport layer (TCP, UDP, etc.) from the
	internetworking layer (IPv4 and IPv6) by using public/private key		internetworking layer (IPv4 and IPv6) by using public/private key
	pairs, instead of IP addresses, as host identities. When a host uses		pairs, instead of IP addresses, as host identities. When a host uses
	HIP, the overlying protocol sublayers (e.g., transport layer sockets		HIP, the overlying protocol sublayers (e.g., transport layer sockets
	and ESP Security Associations) are instead bound to representations		and ESP Security Associations) are instead bound to representations
	of these host identities, and the IP addresses are only used for		of these host identities, and the IP addresses are only used for
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 11 ¶
	path MTU selection, and QoS. Transport-layer mobility triggers, and		path MTU selection, and QoS. Transport-layer mobility triggers, and
	the proper transport response to a HIP mobility or multihoming		the proper transport response to a HIP mobility or multihoming
	address change, are outside the scope of this document.		address change, are outside the scope of this document.
	2. Terminology and Conventions		2. Terminology and Conventions
	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 RFC2119 [7].		document are to be interpreted as described in RFC2119 [7].
	LOCATOR. The name of a HIP parameter containing zero or more Locator		LOCATOR. The name of a HIP parameter containing zero or more Locator
	fields. This parameter's name is distinguished from the Locator		fields. This parameter's name is distinguished from the Locator
	fields embedded within it by the use of all capital letters.		fields embedded within it by the use of all capital letters.
	Locator. A name that controls how the packet is routed through the		Locator. A name that controls how the packet is routed through the
	network and demultiplexed by the end host. It may include a		network and demultiplexed by the end host. It may include a
	concatenation of traditional network addresses such as an IPv6		concatenation of traditional network addresses such as an IPv6
	address and end-to-end identifiers such as an ESP SPI. It may		address and end-to-end identifiers such as an ESP SPI. It may
	also include transport port numbers or IPv6 Flow Labels as		also include transport port numbers or IPv6 Flow Labels as
	demultiplexing context, or it may simply be a network address.		demultiplexing context, or it may simply be a network address.
	Address. A name that denotes a point-of-attachment to the network.		Address. A name that denotes a point-of-attachment to the network.
	The two most common examples are an IPv4 address and an IPv6		The two most common examples are an IPv4 address and an IPv6
	address. The set of possible addresses is a subset of the set of		address. The set of possible addresses is a subset of the set of
	possible locators.		possible locators.
	Preferred locator. A locator on which a host prefers to receive data.		Preferred locator. A locator on which a host prefers to receive
	With respect to a given peer, a host always has one active		data. With respect to a given peer, a host always has one active
	Preferred locator, unless there are no active locators. By		Preferred locator, unless there are no active locators. By
	default, the locators used in the HIP base exchange are the		default, the locators used in the HIP base exchange are the
	Preferred locators.		Preferred locators.
	Credit Based Authorization. A host must verify a mobile or multi-		Credit Based Authorization. A host must verify a mobile or multi-
	homed peer's reachability at a new locator. Credit-Based		homed peer's reachability at a new locator. Credit-Based
	Authorization authorizes the peer to receive a certain amount of		Authorization authorizes the peer to receive a certain amount of
	data at the new locator before the result of such verification is		data at the new locator before the result of such verification is
	known.		known.
	3. Protocol Model		3. Protocol Model
	This section is an overview; more detailed specification follows this		This section is an overview; more detailed specification follows this
	section.		section.
	skipping to change at page 7, line 38 ¶		skipping to change at page 7, line 38 ¶
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| | IPsec | | ESP | | IPsec | |		| | IPsec | | ESP | | IPsec | |
	| | Stack | <-+-----------------------+-> | Stack | |		| | Stack | <-+-----------------------+-> | Stack | |
	| | | | | | | |		| | | | | | | |
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| | | |		| | | |
	| | | |		| | | |
	| Initiator | | Responder |		| Initiator | | Responder |
	+--------------------+ +--------------------+		+--------------------+ +--------------------+
	Figure 1: HIP deployment model		Figure 1: HIP deployment model
	The general deployment model for HIP is shown above, assuming		The general deployment model for HIP is shown above, assuming
	operation in an end-to-end fashion. This document specifies		operation in an end-to-end fashion. This document specifies
	extensions to the HIP protocol to enable end-host mobility and basic		extensions to the HIP protocol to enable end-host mobility and basic
	multihoming. In summary, these extensions to the HIP base protocol		multihoming. In summary, these extensions to the HIP base protocol
	enable the signaling of new addressing information to the peer in HIP		enable the signaling of new addressing information to the peer in HIP
	messages. The messages are authenticated via a signature or keyed		messages. The messages are authenticated via a signature or keyed
	hash message authentication code (HMAC) based on its host identity.		hash message authentication code (HMAC) based on its host identity.
	This document specifies the format of this new addressing (LOCATOR)		This document specifies the format of this new addressing (LOCATOR)
	parameter, the procedures for sending and processing this parameter		parameter, the procedures for sending and processing this parameter
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	| ---------		| ---------
	| |		| |
	---- ---------		---- ---------
	| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}		| MH |-> | HIP | {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
	---- ---------		---- ---------
	|		|
	---------		---------
	| IP |		| IP |
	---------		---------
	Figure 2: Architecture for HIP mobility and multihoming (MH)		Figure 2: Architecture for HIP mobility and multihoming (MH)
	Figure 2 depicts a layered architectural view of a HIP-enabled stack		Figure 2 depicts a layered architectural view of a HIP-enabled stack
	using ESP transport format. In HIP, upper-layer protocols (including		using ESP transport format. In HIP, upper-layer protocols (including
	TCP and ESP in this figure) are bound to HITs and not IP addresses.		TCP and ESP in this figure) are bound to HITs and not IP addresses.
	The HIP sublayer is responsible for maintaining the binding between		The HIP sublayer is responsible for maintaining the binding between
	HITs and IP addresses. The SPI is used to associate an incoming		HITs and IP addresses. The SPI is used to associate an incoming
	packet with the right HITs. The block labeled "MH" is introduced		packet with the right HITs. The block labeled "MH" is introduced
	below.		below.
	Consider first the case in which there is no mobility or multihoming,		Consider first the case in which there is no mobility or multihoming,
	skipping to change at page 9, line 6 ¶		skipping to change at page 9, line 6 ¶
	First, the peer must be notified of the address change using a HIP		First, the peer must be notified of the address change using a HIP
	UPDATE message. Second, each host must change its local bindings at		UPDATE message. Second, each host must change its local bindings at
	the HIP sublayer (new IP addresses). It may be that both the SPIs		the HIP sublayer (new IP addresses). It may be that both the SPIs
	and IP addresses are changed simultaneously in a single UPDATE; the		and IP addresses are changed simultaneously in a single UPDATE; the
	protocol described herein supports this. However, simultaneous		protocol described herein supports this. However, simultaneous
	movement of both hosts, notification of transport layer protocols of		movement of both hosts, notification of transport layer protocols of
	the path change, and procedures for possibly traversing middleboxes		the path change, and procedures for possibly traversing middleboxes
	are not covered by this document.		are not covered by this document.
	Finally, consider the case when a host is multihomed (has more than		Finally, consider the case when a host is multihomed (has more than
	one globally routable address) and makes these multiple addresses		one globally routable address) and has multiple addresses available
	available for use by the upper layer protocols, for fault tolerance.		at the HIP layer as alternative locators, for fault tolerance.
	Examples include the use of (possibly multiple) IPv4 and IPv6		Examples include the use of (possibly multiple) IPv4 and IPv6
	addresses on the same interface, or the use of multiple interfaces		addresses on the same interface, or the use of multiple interfaces
	attached to different service providers. Such host multihoming		attached to different service providers. Such host multihoming
	generally necessitates that a separate ESP SA is maintained for each		generally necessitates that a separate ESP SA is maintained for each
	interface in order to prevent packets that arrive over different		interface in order to prevent packets that arrive over different
	paths from falling outside of the ESP replay protection window.		paths from falling outside of the ESP anti-replay window [4].
	Multihoming thus makes possible that the bindings shown on the right		Multihoming thus makes possible that the bindings shown on the right
	side of Figure 2 are one to many (in the outbound direction, one HIT		side of Figure 2 are one to many (in the outbound direction, one HIT
	pair to multiple SPIs, and possibly then to multiple IP addresses).		pair to multiple SPIs, and possibly then to multiple IP addresses).
	However, only one SPI and address pair can be used for any given		However, only one SPI and address pair can be used for any given
	packet, so the job of the "MH" block depicted above is to dynamically		packet, so the job of the "MH" block depicted above is to dynamically
	manipulate these bindings. Beyond locally managing such multiple		manipulate these bindings. Beyond locally managing such multiple
	bindings, the peer-to-peer HIP signaling protocol needs to be		bindings, the peer-to-peer HIP signaling protocol needs to be
	flexible enough to define the desired mappings between HITs, SPIs,		flexible enough to define the desired mappings between HITs, SPIs,
	and addresses, and needs to ensure that UPDATE messages are sent		and addresses, and needs to ensure that UPDATE messages are sent
	along the right network paths so that any HIP-aware middleboxes can		along the right network paths so that any HIP-aware middleboxes can
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 43 ¶
	3.1.1. Locator		3.1.1. Locator
	This document defines a generalization of an address called a		This document defines a generalization of an address called a
	"locator". A locator specifies a point-of-attachment to the network		"locator". A locator specifies a point-of-attachment to the network
	but may also include additional end-to-end tunneling or per-host		but may also include additional end-to-end tunneling or per-host
	demultiplexing context that affects how packets are handled below the		demultiplexing context that affects how packets are handled below the
	logical HIP sublayer of the stack. This generalization is useful		logical HIP sublayer of the stack. This generalization is useful
	because IP addresses alone may not be sufficient to describe how		because IP addresses alone may not be sufficient to describe how
	packets should be handled below HIP. For example, in a host		packets should be handled below HIP. For example, in a host
	multihoming context, certain IP addresses may need to be associated		multihoming context, certain IP addresses may need to be associated
	with certain ESP SPIs, to avoid violation of the ESP anti-replay		with certain ESP SPIs, to avoid violation ESP anti-replay window.
	window [4]. Addresses may also be affiliated with transport ports in		Addresses may also be affiliated with transport ports in certain
	certain tunneling scenarios. Locators may simply be traditional		tunneling scenarios. Locators may simply be traditional network
	network addresses. The format of the locators is defined in		addresses. The format of the locators is defined in Section 4.
	Section 4.
	3.1.2. Mobility overview		3.1.2. Mobility overview
	When a host moves to another address, it notifies its peer of the new		When a host moves to another address, it notifies its peer of the new
	address by sending a HIP UPDATE packet containing a LOCATOR		address by sending a HIP UPDATE packet containing a LOCATOR
	parameter. This UPDATE packet is acknowledged by the peer, and is		parameter. This UPDATE packet is acknowledged by the peer. For
	protected by retransmission. The peer can authenticate the contents		reliability in the presence of packet loss, the UPDATE packet is
	of the UPDATE packet based on the signature and keyed hash of the		retransmitted as defined in the HIP protocol specification [2]. The
	packet.		peer can authenticate the contents of the UPDATE packet based on the
			signature and keyed hash of the packet.
	When using ESP Transport Format [6], the host may at the same time		When using ESP Transport Format [6], the host may at the same time
	decide to rekey its security association and possibly generate a new		decide to rekey its security association and possibly generate a new
	Diffie-Hellman key; all of these actions are triggered by including		Diffie-Hellman key; all of these actions are triggered by including
	additional parameters in the UPDATE packet, as defined in the base		additional parameters in the UPDATE packet, as defined in the base
	protocol specification [2] and ESP extension [6].		protocol specification [2] and ESP extension [6].
	When using ESP (and possibly other transport modes in the future),		When using ESP (and possibly other transport modes in the future),
	the host is able to receive packets that are protected using a HIP		the host is able to receive packets that are protected using a HIP
	created ESP SA from any address. Thus, a host can change its IP		created ESP SA from any address. Thus, a host can change its IP
	skipping to change at page 11, line 49 ¶		skipping to change at page 11, line 49 ¶
	Mobile Host Peer Host		Mobile Host Peer Host
	UPDATE(ESP_INFO, LOCATOR, SEQ)		UPDATE(ESP_INFO, LOCATOR, SEQ)
	----------------------------------->		----------------------------------->
	UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)		UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
	<-----------------------------------		<-----------------------------------
	UPDATE(ACK, ECHO_RESPONSE)		UPDATE(ACK, ECHO_RESPONSE)
	----------------------------------->		----------------------------------->
	Figure 3: Readdress without rekeying, but with address check		Figure 3: Readdress without rekeying, but with address check
	The steps of the packet processing are as follows:		The steps of the packet processing are as follows:
	1. The mobile host is disconnected from the peer host for a brief		1. The mobile host is disconnected from the peer host for a brief
	period of time while it switches from one IP address to another.		period of time while it switches from one IP address to another.
	Upon obtaining a new IP address, the mobile host sends a LOCATOR		Upon obtaining a new IP address, the mobile host sends a LOCATOR
	parameter to the peer host in an UPDATE message. The UPDATE		parameter to the peer host in an UPDATE message. The UPDATE
	message also contains an ESP_INFO parameter containing the values		message also contains an ESP_INFO parameter containing the values
	of the old and new SPIs for a security association. In this		of the old and new SPIs for a security association. In this
	case, the "Old SPI" and "New SPI" parameters both are set to the		case, the "Old SPI" and "New SPI" parameters both are set to the
	skipping to change at page 13, line 17 ¶		skipping to change at page 13, line 17 ¶
	Mobile Host Peer Host		Mobile Host Peer Host
	UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])		UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
	----------------------------------->		----------------------------------->
	UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)		UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
	<-----------------------------------		<-----------------------------------
	UPDATE(ACK, ECHO_RESPONSE)		UPDATE(ACK, ECHO_RESPONSE)
	----------------------------------->		----------------------------------->
	Figure 4: Readdress with mobile-initiated rekey		Figure 4: Readdress with mobile-initiated rekey
	3.2.3. Host multihoming		3.2.3. Host multihoming
	A (mobile or stationary) host may sometimes have more than one		A (mobile or stationary) host may sometimes have more than one
	interface or global address. The host may notify the peer host of		interface or global address. The host may notify the peer host of
	the additional interface or address by using the LOCATOR parameter.		the additional interface or address by using the LOCATOR parameter.
	To avoid problems with the ESP anti-replay window, a host SHOULD use		To avoid problems with the ESP anti-replay window, a host SHOULD use
	a different SA for each interface or address used to receive packets		a different SA for each interface or address used to receive packets
	from the peer host.		from the peer host, when multiple locator pairs are being used
			simultaneously rather than sequentially.
	When more than one locator is provided to the peer host, the host		When more than one locator is provided to the peer host, the host
	SHOULD indicate which locator is preferred. By default, the		SHOULD indicate which locator is preferred (the locator on which the
	addresses used in the base exchange are preferred until indicated		host prefers to receive traffic). By default, the addresses used in
	otherwise.		the base exchange are preferred until indicated otherwise.
			In the multihoming case, the sender may also have multiple valid
			locators from which to source traffic. In practice, a HIP
			association in a multihoming configuration may have both a preferred
			peer locator and a preferred local locator, although rules for source
			address selection should ultimately govern the selection of source
			locator based on the destination locator.
	Although the protocol may allow for configurations in which there is		Although the protocol may allow for configurations in which there is
	an asymmetric number of SAs between the hosts (e.g., one host has two		an asymmetric number of SAs between the hosts (e.g., one host has two
	interfaces and two inbound SAs, while the peer has one interface and		interfaces and two inbound SAs, while the peer has one interface and
	one inbound SA), it is RECOMMENDED that inbound and outbound SAs be		one inbound SA), it is RECOMMENDED that inbound and outbound SAs be
	created pairwise between hosts. When an ESP_INFO arrives to rekey a		created pairwise between hosts. When an ESP_INFO arrives to rekey a
	particular outbound SA, the corresponding inbound SA should be also		particular outbound SA, the corresponding inbound SA should be also
	rekeyed at that time. Although asymmetric SA configurations might be		rekeyed at that time. Although asymmetric SA configurations might be
	experimented with, their usage may constrain interoperability at this		experimented with, their usage may constrain interoperability at this
	time. However, it is recommended that implementations attempt to		time. However, it is recommended that implementations attempt to
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 34 ¶
	Multi-homed Host Peer Host		Multi-homed Host Peer Host
	UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])		UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
	----------------------------------->		----------------------------------->
	UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)		UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
	<-----------------------------------		<-----------------------------------
	UPDATE(ACK, ECHO_RESPONSE)		UPDATE(ACK, ECHO_RESPONSE)
	----------------------------------->		----------------------------------->
	Figure 5: Basic multihoming scenario		Figure 5: Basic multihoming scenario
	In multihoming scenarios, it is important that hosts receiving		In multihoming scenarios, it is important that hosts receiving
	UPDATEs associate them correctly with the destination address used in		UPDATEs associate them correctly with the destination address used in
	the packet carrying the UPDATE. When processing inbound LOCATORs		the packet carrying the UPDATE. When processing inbound LOCATORs
	that establish new security associations on an interface with		that establish new security associations on an interface with
	multiple addresses, a host uses the destination address of the UPDATE		multiple addresses, a host uses the destination address of the UPDATE
	containing LOCATOR as the local address to which the LOCATOR plus		containing LOCATOR as the local address to which the LOCATOR plus
	ESP_INFO is targeted. This is because hosts may send UPDATEs with		ESP_INFO is targeted. This is because hosts may send UPDATEs with
	the same (locator) IP address to different peer addresses-- this has		the same (locator) IP address to different peer addresses-- this has
	the effect of creating multiple inbound SAs implicitly affiliated		the effect of creating multiple inbound SAs implicitly affiliated
	skipping to change at page 15, line 41 ¶		skipping to change at page 15, line 49 ¶
	choice.		choice.
	-<- SPI1a -- -- SPI2a ->-		-<- SPI1a -- -- SPI2a ->-
	host1 < > addr1a <---> addr2a < > host2		host1 < > addr1a <---> addr2a < > host2
	->- SPI2a -- -- SPI1a -<-		->- SPI2a -- -- SPI1a -<-
	addr1b <---> addr2a (second SA pair)		addr1b <---> addr2a (second SA pair)
	addr1a <---> addr2b (third SA pair)		addr1a <---> addr2b (third SA pair)
	addr1b <---> addr2b (fourth SA pair)		addr1b <---> addr2b (fourth SA pair)
	Figure 6: Dual multihoming case in which each host uses LOCATOR to		Figure 6: Dual multihoming case in which each host uses LOCATOR to
	add a second address		add a second address
	3.2.6. Combined mobility and multihoming		3.2.6. Combined mobility and multihoming
	It looks likely that in the future many mobile hosts will be		It looks likely that in the future many mobile hosts will be
	simultaneously mobile and multi-homed, i.e., have multiple mobile		simultaneously mobile and multi-homed, i.e., have multiple mobile
	interfaces. Furthermore, if the interfaces use different access		interfaces. Furthermore, if the interfaces use different access
	technologies, it is fairly likely that one of the interfaces may		technologies, it is fairly likely that one of the interfaces may
	appear stable (retain its current IP address) while some other(s) may		appear stable (retain its current IP address) while some other(s) may
	experience mobility (undergo IP address change).		experience mobility (undergo IP address change).
	skipping to change at page 17, line 18 ¶		skipping to change at page 17, line 18 ¶
	<-----------------------------------		<-----------------------------------
	record additional addresses		record additional addresses
	change responder address		change responder address
	I2 sent to newly indicated preferred address		I2 sent to newly indicated preferred address
	----------------------------------->		----------------------------------->
	(process normally)		(process normally)
	R2		R2
	<-----------------------------------		<-----------------------------------
	(process normally, later verification of non-preferred locators)		(process normally, later verification of non-preferred locators)
	Figure 7: LOCATOR inclusion in R1		Figure 7: LOCATOR inclusion in R1
	An Initiator MAY include one or more LOCATOR parameters in the I2		An Initiator MAY include one or more LOCATOR parameters in the I2
	packet, independent of whether there was a LOCATOR parameter in the		packet, independent of whether there was a LOCATOR parameter in the
	R1 or not. These parameters MUST be protected by the I2 signature.		R1 or not. These parameters MUST be protected by the I2 signature.
	Even if the I2 packet contains LOCATOR parameters, the Responder MUST		Even if the I2 packet contains LOCATOR parameters, the Responder MUST
	still send the R2 packet to the source address of the I2. The new		still send the R2 packet to the source address of the I2. The new
	Preferred locator SHOULD be identical to the I2 source address. If		Preferred locator SHOULD be identical to the I2 source address. If
	the I2 packet contains LOCATOR parameters, all new locators must		the I2 packet contains LOCATOR parameters, all new locators must
	undergo address verification as usual, and the ESP traffic that		undergo address verification as usual, and the ESP traffic that
	subsequently follows should use the Preferred locator.		subsequently follows should use the Preferred locator.
	skipping to change at page 17, line 40 ¶		skipping to change at page 17, line 40 ¶
	Initiator Responder		Initiator Responder
	I2 with LOCATOR		I2 with LOCATOR
	----------------------------------->		----------------------------------->
	(process normally)		(process normally)
	record additional addresses		record additional addresses
	R2 sent to source address of I2		R2 sent to source address of I2
	<-----------------------------------		<-----------------------------------
	(process normally)		(process normally)
	Figure 8: LOCATOR inclusion in I2		Figure 8: LOCATOR inclusion in I2
	The I1 and I2 may be arriving from different source addresses if the		The I1 and I2 may be arriving from different source addresses if the
	LOCATOR parameter is present in R1. In this case, implementations		LOCATOR parameter is present in R1. In this case, implementations
	using pre-created R1 indexed with IP addresses fail the puzzle		using pre-created R1 indexed with IP addresses fail the puzzle
	solution of I2 packets inadvertently. See, for example, the example		solution of I2 packets inadvertently. See, for example, the example
	in Appendix A of [2]. As a solution, the responder's puzzle indexing		in Appendix A of [2]. As a solution, the responder's puzzle indexing
	mechanism must be flexible enough to accomodate the situation when R1		mechanism must be flexible enough to accomodate the situation when R1
	includes a LOCATOR parameter.		includes a LOCATOR parameter.
	3.3. Other Considerations		3.3. Other Considerations
	skipping to change at page 18, line 37 ¶		skipping to change at page 18, line 40 ¶
	Credit-Based Authorization (CBA) allows a host to securely use a new		Credit-Based Authorization (CBA) allows a host to securely use a new
	locator even though the peer's reachability at the address embedded		locator even though the peer's reachability at the address embedded
	in the locator has not yet been verified. This is accomplished based		in the locator has not yet been verified. This is accomplished based
	on the following three hypotheses:		on the following three hypotheses:
	1. A flooding attacker typically seeks to somehow multiply the		1. A flooding attacker typically seeks to somehow multiply the
	packets it generates for the purpose of its attack because		packets it generates for the purpose of its attack because
	bandwidth is an ample resource for many victims.		bandwidth is an ample resource for many victims.
	2. An attacker can always cause unamplified flooding by sending		2. An attacker can often cause unamplified flooding by sending
	packets to its victim directly.		packets to its victim, either by directly addressing the victim
			in the packets, or by guiding the packets along a specific path
			by means of an IPv6 Routing header, if Routing headers are not
			filtered by firewalls.
	3. Consequently, the additional effort required to set up a		3. Consequently, the additional effort required to set up a
	redirection-based flooding attack (without CBA and return		redirection-based flooding attack (without CBA and return
	routability checks) would pay off for the attacker only if		routability checks) would pay off for the attacker only if
	amplification could be obtained this way.		amplification could be obtained this way.
	On this basis, rather than eliminating malicious packet redirection		On this basis, rather than eliminating malicious packet redirection
	in the first place, Credit-Based Authorization prevents		in the first place, Credit-Based Authorization prevents
	amplifications. This is accomplished by limiting the data a host can		amplifications. This is accomplished by limiting the data a host can
	send to an unverified address of a peer by the data recently received		send to an unverified address of a peer by the data recently received
	skipping to change at page 19, line 22 ¶		skipping to change at page 19, line 27 ¶
	shown in Figure 9 are the results of credit aging (Section 5.6.2), a		shown in Figure 9 are the results of credit aging (Section 5.6.2), a
	mechanism used to dampen possible time-shifting attacks.		mechanism used to dampen possible time-shifting attacks.
	+-------+ +-------+		+-------+ +-------+
	| A | | B |		| A | | B |
	+-------+ +-------+		+-------+ +-------+
	| |		| |
	address |------------------------------->| credit += size(packet)		address |------------------------------->| credit += size(packet)
	ACTIVE | |		ACTIVE | |
	|------------------------------->| credit += size(packet)		|------------------------------->| credit += size(packet)
	|<-------------------------------| don't change credit		|<-------------------------------| do not change credit
	| |		| |
	+ address change |		+ address change |
	+ address verification starts |		+ address verification starts |
	address |<-------------------------------| credit -= size(packet)		address |<-------------------------------| credit -= size(packet)
	UNVERIFIED |------------------------------->| credit += size(packet)		UNVERIFIED |------------------------------->| credit += size(packet)
	|<-------------------------------| credit -= size(packet)		|<-------------------------------| credit -= size(packet)
	| |		| |
	|<-------------------------------| credit -= size(packet)		|<-------------------------------| credit -= size(packet)
	| X credit < size(packet)		| X credit < size(packet)
	| | => do not send packet!		| | => do not send packet!
	+ address verification concludes |		+ address verification concludes |
	address | |		address | |
	ACTIVE |<-------------------------------| don't change credit		ACTIVE |<-------------------------------| do not change credit
	| |		| |
	Figure 9: Readdressing Scenario		Figure 9: Readdressing Scenario
	3.3.3. Preferred locator		3.3.3. Preferred locator
	When a host has multiple locators, the peer host must decide upon		When a host has multiple locators, the peer host must decide upon
	which to use for outbound packets. It may be that a host would		which to use for outbound packets. It may be that a host would
	prefer to receive data on a particular inbound interface. HIP allows		prefer to receive data on a particular inbound interface. HIP allows
	a particular locator to be designated as a Preferred locator, and		a particular locator to be designated as a Preferred locator, and
	communicated to the peer (see Section 4).		communicated to the peer (see Section 4).
	In general, when multiple locators are used for a session, there is		In general, when multiple locators are used for a session, there is
	skipping to change at page 20, line 25 ¶		skipping to change at page 20, line 31 ¶
	Security Parameter Indices (SPIs), and addresses.		Security Parameter Indices (SPIs), and addresses.
	The relation between these levels for an association constructed as		The relation between these levels for an association constructed as
	defined in the base specification [2] and ESP transform [6] is		defined in the base specification [2] and ESP transform [6] is
	illustrated in Figure 10.		illustrated in Figure 10.
	-<- SPI1a -- -- SPI2a ->-		-<- SPI1a -- -- SPI2a ->-
	host1 < > addr1a <---> addr2a < > host2		host1 < > addr1a <---> addr2a < > host2
	->- SPI2a -- -- SPI1a -<-		->- SPI2a -- -- SPI1a -<-
	Figure 10: Relation between hosts, SPIs, and addresses (base		Figure 10: Relation between hosts, SPIs, and addresses (base
	specification)		specification)
	In Figure 10, host1 and host2 negotiate two unidirectional SAs, and		In Figure 10, host1 and host2 negotiate two unidirectional SAs, and
	each host selects the SPI value for its inbound SA. The addresses		each host selects the SPI value for its inbound SA. The addresses
	addr1a and addr2a are the source addresses that the hosts use in the		addr1a and addr2a are the source addresses that the hosts use in the
	base HIP exchange. These are the "preferred" (and only) addresses		base HIP exchange. These are the "preferred" (and only) addresses
	conveyed to the peer for use on each SA. That is, although packets		conveyed to the peer for use on each SA. That is, although packets
	sent to any of the hosts' interfaces may be accepted on the inbound		sent to any of the hosts' interfaces may be accepted on the inbound
	SA, the peer host in general knows of only the single destination		SA, the peer host in general knows of only the single destination
	address learned in the base exchange (e.g., for host1, it sends a		address learned in the base exchange (e.g., for host1, it sends a
	packet on SPI2a to addr2a to reach host2), unless other mechanisms		packet on SPI2a to addr2a to reach host2), unless other mechanisms
	skipping to change at page 23, line 42 ¶		skipping to change at page 23, line 42 ¶
	| Traffic Type | Locator Type | Locator Length | Reserved |P|		| Traffic Type | Locator Type | Locator Length | Reserved |P|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Locator Lifetime |		| Locator Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Locator |		| Locator |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 193		Type: 193
	Length: Length in octets, excluding Type and Length fields, and		Length: Length in octets, excluding Type and Length fields, and
	excluding padding.		excluding padding.
	Traffic Type: Defines whether the locator pertains to HIP signaling,		Traffic Type: Defines whether the locator pertains to HIP signaling,
	user data, or both.		user data, or both.
	Locator Type: Defines the semantics of the Locator field.		Locator Type: Defines the semantics of the Locator field.
	Locator Length: Defines the length of the Locator field, in units of		Locator Length: Defines the length of the Locator field, in units of
	4-byte words (Locators up to a maximum of 4*255 octets are		4-byte words (Locators up to a maximum of 4*255 octets are
	supported).		supported).
	Reserved: Zero when sent, ignored when received.		Reserved: Zero when sent, ignored when received.
	P: Preferred locator. Set to one if the locator is preferred for		P: Preferred locator. Set to one if the locator is preferred for
	that Traffic Type; otherwise set to zero.		that Traffic Type; otherwise set to zero.
	Locator Lifetime: Locator lifetime, in seconds.		Locator Lifetime: Locator lifetime, in seconds.
	Locator: The locator whose semantics and encoding are indicated by		Locator: The locator whose semantics and encoding are indicated by
	the Locator Type field. All Locator sub-fields are integral		the Locator Type field. All Locator sub-fields are integral
	multiples of four octets in length.		multiples of four octets in length.
	The Locator Lifetime indicates how long the following locator is		The Locator Lifetime indicates how long the following locator is
	expected to be valid. The lifetime is expressed in seconds. Each		expected to be valid. The lifetime is expressed in seconds. Each
	locator MUST have a non-zero lifetime. The address is expected to		locator MUST have a non-zero lifetime. The address is expected to
	become deprecated when the specified number of seconds has passed		become deprecated when the specified number of seconds has passed
	since the reception of the message. A deprecated address SHOULD NOT		since the reception of the message. A deprecated address SHOULD NOT
	be used as an destination address if an alternate (non-deprecated) is		be used as an destination address if an alternate (non-deprecated) is
	available and has sufficient scope.		available and has sufficient scope.
	4.1. Traffic Type and Preferred locator		4.1. Traffic Type and Preferred locator
	The following Traffic Type values are defined:		The following Traffic Type values are defined:
	0: Both signaling (HIP control packets) and user data.		0: Both signaling (HIP control packets) and user data.
	1: Signaling packets only.		1: Signaling packets only.
	2: Data packets only.		2: Data packets only.
	The "P" bit, when set, has scope over the corresponding Traffic Type.		The "P" bit, when set, has scope over the corresponding Traffic Type.
	That is, when a "P" bit is set for Traffic Type "2", for example, it		That is, when a "P" bit is set for Traffic Type "2", for example, it
	means that the locator is preferred for data packets. If there is a		means that the locator is preferred for data packets. If there is a
	conflict (for example, if P bit is set for an address of Type "0" and		conflict (for example, if P bit is set for an address of Type "0" and
	a different address of Type "2"), the more specific Traffic Type rule		a different address of Type "2"), the more specific Traffic Type rule
	applies (in this case, "2"). By default, the IP addresses used in		applies (in this case, "2"). By default, the IP addresses used in
	the base exchange are Preferred locators for both signaling and user		the base exchange are Preferred locators for both signaling and user
	data, unless a new Preferred locator supersedes them. If no locators		data, unless a new Preferred locator supersedes them. If no locators
	are indicated as preferred for a given Traffic Type, the		are indicated as preferred for a given Traffic Type, the
	implementation may use an arbitrary locator from the set of active		implementation may use an arbitrary locator from the set of active
	locators.		locators.
	4.2. Locator Type and Locator		4.2. Locator Type and Locator
	The following Locator Type values are defined, along with the		The following Locator Type values are defined, along with the
	associated semantics of the Locator field:		associated semantics of the Locator field:
	0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [8] (128		0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [8] (128
	bits long). This locator type is defined primarily for non-ESP-		bits long). This locator type is defined primarily for non-ESP-
	based usage.		based usage.
	1: The concatenation of an ESP SPI (first 32 bits) followed by an		1: The concatenation of an ESP SPI (first 32 bits) followed by an
	IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional		IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional
	128 bits). This IP address is defined primarily for ESP-based		128 bits). This IP address is defined primarily for ESP-based
	usage.		usage.
	4.3. UPDATE packet with included LOCATOR		4.3. UPDATE packet with included LOCATOR
	A number of combinations of parameters in an UPDATE packet are		A number of combinations of parameters in an UPDATE packet are
	possible (e.g., see Section 3.2). In this document, procedures are		possible (e.g., see Section 3.2). In this document, procedures are
	defined only for the case in which one LOCATOR and one ESP_INFO		defined only for the case in which one LOCATOR and one ESP_INFO
	parameter is used in any HIP packet. Furthermore, the LOCATOR SHOULD		parameter is used in any HIP packet. Furthermore, the LOCATOR SHOULD
	skipping to change at page 26, line 20 ¶		skipping to change at page 26, line 20 ¶
	5.1. Locator data structure and status		5.1. Locator data structure and status
	In a typical implementation, each outgoing locator is represented by		In a typical implementation, each outgoing locator is represented by
	a piece of state that contains the following data:		a piece of state that contains the following data:
	o the actual bit pattern representing the locator,		o the actual bit pattern representing the locator,
	o lifetime (seconds),		o lifetime (seconds),
	o status (UNVERIFIED, ACTIVE, DEPRECATED).		o status (UNVERIFIED, ACTIVE, DEPRECATED),
			o the Traffic Type scope of the locator, and
			o whether the locator is preferred for any particular scope.
	The status is used to track the reachability of the address embedded		The status is used to track the reachability of the address embedded
	within the LOCATOR parameter:		within the LOCATOR parameter:
	UNVERIFIED indicates that the reachability of the address has not		UNVERIFIED indicates that the reachability of the address has not
	been verified yet,		been verified yet,
	ACTIVE indicates that the reachability of the address has been		ACTIVE indicates that the reachability of the address has been
	verified and the address has not been deprecated,		verified and the address has not been deprecated,
	DEPRECATED indicates that the locator lifetime has expired		DEPRECATED indicates that the locator lifetime has expired
	The following state changes are allowed:		The following state changes are allowed:
	UNVERIFIED to ACTIVE The reachability procedure completes		UNVERIFIED to ACTIVE The reachability procedure completes
	successfully.		successfully.
	UNVERIFIED to DEPRECATED The locator lifetime expires while it is		UNVERIFIED to DEPRECATED The locator lifetime expires while the
	UNVERIFIED.		locator is UNVERIFIED.
	ACTIVE to DEPRECATED The locator lifetime expires while it is ACTIVE.		ACTIVE to DEPRECATED The locator lifetime expires while the locator
			is ACTIVE.
	ACTIVE to UNVERIFIED There has been no traffic on the address for		ACTIVE to UNVERIFIED There has been no traffic on the address for
	some time, and the local policy mandates that the address		some time, and the local policy mandates that the address
	reachability must be verified again before starting to use it		reachability must be verified again before starting to use it
	again.		again.
	DEPRECATED to UNVERIFIED The host receives a new lifetime for the		DEPRECATED to UNVERIFIED The host receives a new lifetime for the
	locator.		locator.
	A DEPRECATED address MUST NOT be changed to ACTIVE without first		A DEPRECATED address MUST NOT be changed to ACTIVE without first
	verifying its reachability.		verifying its reachability.
			Note that the state of whether a locator is preferred or not is not
			necessarily the same as the value of the Preferred bit in the Locator
			sub-parameter received from the peer. Peers may recommend certain
			locators to be preferred, but the decision on whether to actually use
			a locator as a preferred locator is a local decision possibly
			influenced by local policy.
	5.2. Sending LOCATORs		5.2. Sending LOCATORs
	The decision of when to send LOCATORs is basically a local policy		The decision of when to send LOCATORs is basically a local policy
	issue. However, it is RECOMMENDED that a host sends a LOCATOR		issue. However, it is RECOMMENDED that a host sends a LOCATOR
	whenever it recognizes a change of its IP addresses in use on an		whenever it recognizes a change of its IP addresses in use on an
	active HIP association, and assumes that the change is going to last		active HIP association, and assumes that the change is going to last
	at least for a few seconds. Rapidly sending LOCATORs that force the		at least for a few seconds. Rapidly sending LOCATORs that force the
	peer to change the preferred address SHOULD be avoided.		peer to change the preferred address SHOULD be avoided.
	When a host decides to inform its peers about changes in its IP		When a host decides to inform its peers about changes in its IP
	addresses, it has to decide how to group the various addresses with		addresses, it has to decide how to group the various addresses with
	SPIs. The grouping should consider also whether middlebox		SPIs. The grouping should consider also whether middlebox
	interaction requires sending (the same) LOCATOR in separate UPDATEs		interaction requires sending the same LOCATOR in separate UPDATEs on
	on different paths. Since each SPI is associated with a different		different paths. Since each SPI is associated with a different
	Security Association, the grouping policy may also be based on ESP		Security Association, the grouping policy may also be based on ESP
	anti-replay protection considerations. In the typical case, simply		anti-replay protection considerations. In the typical case, simply
	basing the grouping on actual kernel level physical and logical		basing the grouping on actual kernel level physical and logical
	interfaces may be the best policy. Grouping policy is outside of the		interfaces may be the best policy. Grouping policy is outside of the
	scope of this document.		scope of this document.
	Note that the purpose of announcing IP addresses in a LOCATOR is to		Note that the purpose of announcing IP addresses in a LOCATOR is to
	provide connectivity between the communicating hosts. In most cases,		provide connectivity between the communicating hosts. In most cases,
	tunnels or virtual interfaces such as IPsec tunnel interfaces or		tunnels or virtual interfaces such as IPsec tunnel interfaces or
	Mobile IP home addresses provide sub-optimal connectivity.		Mobile IP home addresses provide sub-optimal connectivity.
	Furthermore, it should be possible to replace most tunnels with HIP		Furthermore, it should be possible to replace most tunnels with HIP
	based "non-tunneling", therefore making most virtual interfaces		based "non-tunneling", therefore making most virtual interfaces
	fairly unnecessary in the future. Therefore, virtual interfaces		fairly unnecessary in the future. Therefore, virtual interfaces
	SHOULD NOT be announced in general. On the other hand, there are		SHOULD NOT be announced in general. On the other hand, there are
	clearly situations where tunnels are used for diagnostic and/or		clearly situations where tunnels are used for diagnostic and/or
	testing purposes. In such and other similar cases announcing the IP		testing purposes. In such and other similar cases announcing the IP
	addresses of virtual interfaces may be appropriate. Hosts MUST NOT		addresses of virtual interfaces may be appropriate.
	announce broadcast or multicast addresses in LOCATORs. The
	announcement of link-local addresses is a policy decision; such		Hosts MUST NOT announce broadcast or multicast addresses in LOCATORs.
	addresses used as Preferred locators will create reachability		Link-local addresses MAY be announced to peers that are known to be
	problems when the host moves to another link.		neighbors on the same link, such as when the IP destination address
			of a peer is also link-local. The announcement of link-local
			addresses in this case is a policy decision; link-local addresses
			used as Preferred locators will create reachability problems when the
			host moves to another link. In any case, link-local addresses MUST
			NOT be announced to a peer unless that peer is known to be on the
			same link.
	Once the host has decided on the groups and assignment of addresses		Once the host has decided on the groups and assignment of addresses
	to the SPIs, it creates a LOCATOR parameter that serves as a complete		to the SPIs, it creates a LOCATOR parameter that serves as a complete
	representation of the addresses and affiliated SPIs intended for		representation of the addresses and affiliated SPIs intended for
	active use. We now describe a few cases introduced in Section 3.2.		active use. We now describe a few cases introduced in Section 3.2.
	We assume that the Traffic Type for each locator is set to "0" (other		We assume that the Traffic Type for each locator is set to "0" (other
	values for Traffic Type may be specified in documents that separate		values for Traffic Type may be specified in documents that separate
	HIP control plane from data plane traffic). Other mobility and		HIP control plane from data plane traffic). Other mobility and
	multihoming cases are possible but are left for further		multihoming cases are possible but are left for further
	experimentation.		experimentation.
	1. Host mobility with no multihoming and no rekeying. The mobile		1. Host mobility with no multihoming and no rekeying. The mobile
	host creates a single UPDATE containing a single ESP_INFO with a		host creates a single UPDATE containing a single ESP_INFO with a
	single LOCATOR parameter. The ESP_INFO contains the current		single LOCATOR parameter. The ESP_INFO contains the current
	value of the SPI in both the "Old SPI" and "New SPI" fields. The		value of the SPI in both the "Old SPI" and "New SPI" fields. The
	LOCATOR contains a single Locator with a "Locator Type" of "1";		LOCATOR contains a single Locator with a "Locator Type" of "1";
	the SPI must match that of the ESP_INFO. The Preferred bit		the SPI must match that of the ESP_INFO. The Preferred bit
	SHOULD be set and the "Locator Lifetime" is set according to		SHOULD be set and the "Locator Lifetime" is set according to
	local policy. The UPDATE also contains a SEQ parameter as usual		local policy. The UPDATE also contains a SEQ parameter as usual.
	and is protected by retransmission. The UPDATE should be sent to		This packet is retransmitted as defined in the HIP protocol
	the peer's preferred IP address with an IP source address		specification [2]. The UPDATE should be sent to the peer's
	corresponding to the address in the LOCATOR parameter.		preferred IP address with an IP source address corresponding to
			the address in the LOCATOR parameter.
	2. Host mobility with no multihoming but with rekeying. The mobile		2. Host mobility with no multihoming but with rekeying. The mobile
	host creates a single UPDATE containing a single ESP_INFO with a		host creates a single UPDATE containing a single ESP_INFO with a
	single LOCATOR parameter (with a single address). The ESP_INFO		single LOCATOR parameter (with a single address). The ESP_INFO
	contains the current value of the SPI in the "Old SPI" and the		contains the current value of the SPI in the "Old SPI" and the
	new value of the SPI in the "New SPI", and a "Keymat Index" as		new value of the SPI in the "New SPI", and a "Keymat Index" as
	selected by local policy. Optionally, the host may choose to		selected by local policy. Optionally, the host may choose to
	initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN		initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN
	parameter. The LOCATOR contains a single Locator with "Locator		parameter. The LOCATOR contains a single Locator with "Locator
	Type" of "1"; the SPI must match that of the "New SPI" in the		Type" of "1"; the SPI must match that of the "New SPI" in the
	skipping to change at page 30, line 41 ¶		skipping to change at page 31, line 12 ¶
	LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and		LOCATOR parameter have either a state of UNVERIFIED or ACTIVE, and
	any old addresses on the old SA not listed in the LOCATOR parameter		any old addresses on the old SA not listed in the LOCATOR parameter
	have a state of DEPRECATED.		have a state of DEPRECATED.
	Once the host has processed the locators, if the LOCATOR parameter		Once the host has processed the locators, if the LOCATOR parameter
	contains a new Preferred locator, the host SHOULD initiate a change		contains a new Preferred locator, the host SHOULD initiate a change
	of the Preferred locator. This requires that the host first verifies		of the Preferred locator. This requires that the host first verifies
	reachability of the associated address, and only then changes the		reachability of the associated address, and only then changes the
	Preferred locator. See Section 5.5.		Preferred locator. See Section 5.5.
			If a host receives a locator with an unsupported Locator Type, when
			such locator is also declared to be the Preferred locator for the
			peer, the host SHOULD send a NOTIFY error with a Notify Message Type
			of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field
			containing the locator(s) that the receiver failed to process.
			Otherwise, a host MAY send a NOTIFY error if a (non-preferred)
			locator with an unsupported Locator Type is received in a LOCATOR
			parameter.
	5.4. Verifying address reachability		5.4. Verifying address reachability
	A host MUST verify the reachability of an UNVERIFIED address. The		A host MUST verify the reachability of an UNVERIFIED address. The
	status of a newly learned address MUST initially be set to UNVERIFIED		status of a newly learned address MUST initially be set to UNVERIFIED
	unless the new address is advertised in a R1 packet as a new		unless the new address is advertised in a R1 packet as a new
	Preferred locator. A host MAY also want to verify the reachability		Preferred locator. A host MAY also want to verify the reachability
	of an ACTIVE address again after some time, in which case it would		of an ACTIVE address again after some time, in which case it would
	set the status of the address to UNVERIFIED and reinitiate address		set the status of the address to UNVERIFIED and reinitiate address
	verification		verification
	skipping to change at page 31, line 36 ¶		skipping to change at page 32, line 17 ¶
	Mobile host Peer host		Mobile host Peer host
	prepare incoming SA		prepare incoming SA
	new SPI in ESP_INFO (UPDATE)		new SPI in ESP_INFO (UPDATE)
	<-----------------------------------		<-----------------------------------
	switch to new outgoing SA		switch to new outgoing SA
	data on new SA		data on new SA
	----------------------------------->		----------------------------------->
	mark address ACTIVE		mark address ACTIVE
	Figure 13: Address activation via use of new SA		Figure 13: Address activation via use of new SA
	When address verification is in progress for a new Preferred locator,		When address verification is in progress for a new Preferred locator,
	the host SHOULD select a different locator listed as ACTIVE, if one		the host SHOULD select a different locator listed as ACTIVE, if one
	such locator is available, to continue communications until address		such locator is available, to continue communications until address
	verification completes. Alternatively, the host MAY use the new		verification completes. Alternatively, the host MAY use the new
	Preferred locator while in UNVERIFIED status to the extent Credit-		Preferred locator while in UNVERIFIED status to the extent Credit-
	Based Authorization permits. Credit-Based Authorization is explained		Based Authorization permits. Credit-Based Authorization is explained
	in Section 5.6. Once address verification succeeds, the status of		in Section 5.6. Once address verification succeeds, the status of
	the new Preferred locator changes to ACTIVE.		the new Preferred locator changes to ACTIVE.
	skipping to change at page 33, line 28 ¶		skipping to change at page 34, line 14 ¶
	Inbound		Inbound
	packet		packet
	|		|
	| +----------------+ +---------------+		| +----------------+ +---------------+
	| | Increase | | Deliver |		| | Increase | | Deliver |
	+-----> | credit counter |-------------> | packet to |		+-----> | credit counter |-------------> | packet to |
	| by packet size | | application |		| by packet size | | application |
	+----------------+ +---------------+		+----------------+ +---------------+
	Figure 14: Receiving Packets with Credit-Based Authorization		Figure 14: Receiving Packets with Credit-Based Authorization
	Outbound		Outbound
	packet		packet
	| _________________		| _________________
	| / \ +---------------+		| / \ +---------------+
	| / Is the preferred \ No | Send packet |		| / Is the preferred \ No | Send packet |
	+-----> | destination address |-------------> | to preferred |		+-----> | destination address |-------------> | to preferred |
	\ UNVERIFIED? / | address |		\ UNVERIFIED? / | address |
	\_________________/ +---------------+		\_________________/ +---------------+
	|		|
	| Yes		| Yes
	skipping to change at page 34, line 42 ¶		skipping to change at page 35, line 43 ¶
	|		|
	| Yes		| Yes
	|		|
	v		v
	+---------------+ +---------------+		+---------------+ +---------------+
	| Reduce credit | | Send packet |		| Reduce credit | | Send packet |
	| counter by |----------------> | to preferred |		| counter by |----------------> | to preferred |
	| packet size | | address |		| packet size | | address |
	+---------------+ +---------------+		+---------------+ +---------------+
	Figure 15: Sending Packets with Credit-Based Authorization		Figure 15: Sending Packets with Credit-Based Authorization
	5.6.2. Credit Aging		5.6.2. Credit Aging
	A host ensures that the credit counters it maintains for its peers		A host ensures that the credit counters it maintains for its peers
	gradually decrease over time. Such "credit aging" prevents a		gradually decrease over time. Such "credit aging" prevents a
	malicious peer from building up credit at a very slow speed and using		malicious peer from building up credit at a very slow speed and using
	this, all at once, for a severe burst of redirected packets.		this, all at once, for a severe burst of redirected packets.
	Credit aging may be implemented by multiplying credit counters with a		Credit aging may be implemented by multiplying credit counters with a
	factor, CreditAgingFactor (a fractional value less than one), in		factor, CreditAgingFactor (a fractional value less than one), in
	skipping to change at page 41, line 5 ¶		skipping to change at page 41, line 11 ¶
	address via an UPDATE. Other possibilities exist but a simple		address via an UPDATE. Other possibilities exist but a simple
	solution is to prevent use of HIP address check information to		solution is to prevent use of HIP address check information to
	influence non-HIP sessions.		influence non-HIP sessions.
	7. IANA Considerations		7. IANA Considerations
	This document defines a LOCATOR parameter for the Host Identity		This document defines a LOCATOR parameter for the Host Identity
	Protocol [2]. This parameter is defined in Section 4 with a Type of		Protocol [2]. This parameter is defined in Section 4 with a Type of
	193.		193.
			This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message
			Type as defined in the Host Identity Protocol specification [2].
			This parameter is defined in Section 5.3 with a Value of 46.
	8. Authors and Acknowledgments		8. Authors and Acknowledgments
	Pekka Nikander originated this Internet Draft. Tom Henderson, Jari		Pekka Nikander originated this Internet Draft. Tom Henderson, Jari
	Arkko, Greg Perkins, and Christian Vogt have each contributed		Arkko, Greg Perkins, and Christian Vogt have each contributed
	sections to this draft.		sections to this draft.
	The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan		The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan
	Melen for many improvements to the draft.		Melen for many improvements to the draft.
	9. References		9. References
	9.1. Normative references		9.1. Normative references
	[1] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[1] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	Architecture", RFC 4423, August 2005.		Architecture", RFC 4423, August 2005.
	[2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-05		[2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-07
	(work in progress), March 2006.		(work in progress), February 2007.
	[3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		[3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", draft-ietf-hip-rvs-04 (work in progress),		Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
	October 2005.		progress), June 2006.
	[4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,		[4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
	December 2005.		December 2005.
	[5] Draves, R., "Default Address Selection for Internet Protocol		[5] Draves, R., "Default Address Selection for Internet Protocol
	version 6 (IPv6)", RFC 3484, February 2003.		version 6 (IPv6)", RFC 3484, February 2003.
	[6] Jokela, P., "Using ESP transport format with HIP",		[6] Jokela, P., "Using ESP transport format with HIP",
	draft-ietf-hip-esp-02 (work in progress), March 2006.		draft-ietf-hip-esp-05 (work in progress), February 2007.
	[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[8] Hinden, R. and S. Deering, "IP Version 6 Addressing		[8] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 2373, July 1998.		Architecture", RFC 2373, July 1998.
	9.2. Informative references		9.2. Informative references
	[9] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.		[9] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
	Nordmark, "Mobile IP Version 6 Route Optimization Security		Nordmark, "Mobile IP Version 6 Route Optimization Security
	Design Background", RFC 4225, December 2005.		Design Background", RFC 4225, December 2005.
	[10] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile		[10] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile
	IPv6 Early Binding Updates",		IPv6 Early Binding Updates",
	draft-vogt-mobopts-credit-based-authorization-00 (work in		draft-vogt-mobopts-credit-based-authorization-00 (work in
	skipping to change at page 46, line 5 ¶		skipping to change at page 46, line 39 ¶
	Rewrote Sections 5.2 and 5.3 on sending and receiving LOCATOR, to		Rewrote Sections 5.2 and 5.3 on sending and receiving LOCATOR, to
	more explicitly cover the scenario scope of this document.		more explicitly cover the scenario scope of this document.
	Removed unwritten "Policy Considerations" section		Removed unwritten "Policy Considerations" section
	A.7. From draft-ietf-hip-mm-03 to -04		A.7. From draft-ietf-hip-mm-03 to -04
	Responded to numerous WGLC comments and corrections from Miika Komu		Responded to numerous WGLC comments and corrections from Miika Komu
	(responses on the HIP mailing list)		(responses on the HIP mailing list)
			A.8. From draft-ietf-hip-mm-04 to -05
			Responded to Jeffrey Hutzelman comments as part of IETF secdir
			review, and discussion with Christian Vogt. This includes clarifying
			how UPDATE retransmissions are handled, a clarification on Credit-
			Based Authorization flooding attacks, how to handle unsupported
			Locator Type values, and the announcement of link-local addresses.
			Handled several editorial comments from Marcelo Bagnulo Braun
			regarding the host multihoming procedures.
			New use-case section by Marcelo Bagnulo Braun to clarify the
			multihoming case of sequential address usage (to be provided)
	Author's Address		Author's Address
	Tom Henderson		Tom Henderson
	The Boeing Company		The Boeing Company
	P.O. Box 3707		P.O. Box 3707
	Seattle, WA		Seattle, WA
	USA		USA
	Email: thomas.r.henderson@boeing.com		Email: thomas.r.henderson@boeing.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
			THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
			OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
			THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 47, line 29 ¶		skipping to change at page 48, line 45 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 74 change blocks.
	141 lines changed or deleted		200 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/