< draft-ietf-hip-base-07.txt		draft-ietf-hip-base-08.txt >
	Network Working Group R. Moskowitz		Network Working Group R. Moskowitz
	Internet-Draft ICSAlabs, a Division of TruSecure		Internet-Draft ICSAlabs, a Division of TruSecure
	Intended status: Informational Corporation		Expires: December 13, 2007 Corporation
	Expires: August 5, 2007 P. Nikander		P. Nikander
	P. Jokela (editor)		P. Jokela (editor)
	Ericsson Research NomadicLab		Ericsson Research NomadicLab
	T. Henderson		T. Henderson
	The Boeing Company		The Boeing Company
	February 1, 2007		June 11, 2007
	Host Identity Protocol		Host Identity Protocol
	draft-ietf-hip-base-07		draft-ietf-hip-base-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 August 5, 2007.		This Internet-Draft will expire on December 13, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This memo specifies the details of the Host Identity Protocol (HIP).		This memo specifies the details of the Host Identity Protocol (HIP).
	HIP allows consenting hosts to securely establish and maintain shared		HIP allows consenting hosts to securely establish and maintain shared
	IP-layer state, allowing separation of the identifier and locator		IP-layer state, allowing separation of the identifier and locator
	roles of IP addresses, thereby enabling continuity of communications		roles of IP addresses, thereby enabling continuity of communications
	across IP address changes. HIP is based on a Sigma-compliant Diffie-		across IP address changes. HIP is based on a Sigma-compliant Diffie-
	Hellman key exchange, using public-key identifiers from a new Host		Hellman key exchange, using public-key identifiers from a new Host
	Identity name space for mutual peer authentication. The protocol is		Identity name space for mutual peer authentication. The protocol is
	designed to be resistant to Denial-of-Service (DoS) and Man-in-the-		designed to be resistant to Denial-of-Service (DoS) and Man-in-the-
	middle (MitM) attacks, and when used together with another suitable		middle (MitM) attacks, and when used together with another suitable
	security protocol, such as Encapsulated Security Payload (ESP), it		security protocol, such as Encapsulated Security Payload (ESP), it
	provides integrity protection and optional encryption for upper layer		provides integrity protection and optional encryption for upper layer
	protocols, suchs as TCP and UDP.		protocols, such as TCP and UDP.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5		1.1. A New Name Space and Identifiers . . . . . . . . . . . . 5
	1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6		1.2. The HIP Base Exchange . . . . . . . . . . . . . . . . . . 6
	1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . 7		1.3. Memo structure . . . . . . . . . . . . . . . . . . . . . 7
	2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8		2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 8
	2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8		2.1. Requirements Terminology . . . . . . . . . . . . . . . . 8
	2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8		2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	5.4.2. Other Problems with the HIP Header and Packet		5.4.2. Other Problems with the HIP Header and Packet
	Structure . . . . . . . . . . . . . . . . . . . . . . 65		Structure . . . . . . . . . . . . . . . . . . . . . . 65
	5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65		5.4.3. Invalid Puzzle Solution . . . . . . . . . . . . . . . 65
	5.4.4. Non-existing HIP Association . . . . . . . . . . . . 65		5.4.4. Non-existing HIP Association . . . . . . . . . . . . 65
	6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66		6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 66
	6.1. Processing Outgoing Application Data . . . . . . . . . . 66		6.1. Processing Outgoing Application Data . . . . . . . . . . 66
	6.2. Processing Incoming Application Data . . . . . . . . . . 67		6.2. Processing Incoming Application Data . . . . . . . . . . 67
	6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68		6.3. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 68
	6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 69		6.4. HMAC and SIGNATURE Calculation and Verification . . . . . 69
	6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 69		6.4.1. HMAC Calculation . . . . . . . . . . . . . . . . . . 69
	6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 70		6.4.2. Signature Calculation . . . . . . . . . . . . . . . . 71
	6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 71		6.5. HIP KEYMAT Generation . . . . . . . . . . . . . . . . . . 73
	6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 72		6.6. Initiation of a HIP Exchange . . . . . . . . . . . . . . 75
	6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 73		6.6.1. Sending Multiple I1s in Parallel . . . . . . . . . . 76
	6.6.2. Processing Incoming ICMP Protocol Unreachable		6.6.2. Processing Incoming ICMP Protocol Unreachable
	Messages . . . . . . . . . . . . . . . . . . . . . . 74		Messages . . . . . . . . . . . . . . . . . . . . . . 76
	6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 74		6.7. Processing Incoming I1 Packets . . . . . . . . . . . . . 76
	6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 75		6.7.1. R1 Management . . . . . . . . . . . . . . . . . . . . 78
	6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 75		6.7.2. Handling Malformed Messages . . . . . . . . . . . . . 78
	6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 76		6.8. Processing Incoming R1 Packets . . . . . . . . . . . . . 78
	6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 78		6.8.1. Handling Malformed Messages . . . . . . . . . . . . . 80
	6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 78		6.9. Processing Incoming I2 Packets . . . . . . . . . . . . . 80
	6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 80		6.9.1. Handling Malformed Messages . . . . . . . . . . . . . 83
	6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 80		6.10. Processing Incoming R2 Packets . . . . . . . . . . . . . 83
	6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 81		6.11. Sending UPDATE Packets . . . . . . . . . . . . . . . . . 83
	6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 82		6.12. Receiving UPDATE Packets . . . . . . . . . . . . . . . . 84
	6.12.1. Handling a SEQ parameter in a received UPDATE		6.12.1. Handling a SEQ parameter in a received UPDATE
	message . . . . . . . . . . . . . . . . . . . . . . . 83		message . . . . . . . . . . . . . . . . . . . . . . . 85
	6.12.2. Handling an ACK Parameter in a Received UPDATE		6.12.2. Handling an ACK Parameter in a Received UPDATE
	Packet . . . . . . . . . . . . . . . . . . . . . . . 83		Packet . . . . . . . . . . . . . . . . . . . . . . . 86
	6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 84		6.13. Processing NOTIFY Packets . . . . . . . . . . . . . . . . 86
	6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 84		6.14. Processing CLOSE Packets . . . . . . . . . . . . . . . . 86
	6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 84		6.15. Processing CLOSE_ACK Packets . . . . . . . . . . . . . . 87
	6.16. Dropping HIP Associations . . . . . . . . . . . . . . . . 85		6.16. Handling State Loss . . . . . . . . . . . . . . . . . . . 87
	7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 86		7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 88
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 87		8. Security Considerations . . . . . . . . . . . . . . . . . . . 89
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 92		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 93		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
	11.1. Normative References . . . . . . . . . . . . . . . . . . 93		11.1. Normative References . . . . . . . . . . . . . . . . . . 95
	11.2. Informative References . . . . . . . . . . . . . . . . . 94		11.2. Informative References . . . . . . . . . . . . . . . . . 96
	Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 96		Appendix A. Using Responder Puzzles . . . . . . . . . . . . . . 98
	Appendix B. Generating a Public Key Encoding from a HI . . . . . 98		Appendix B. Generating a Public Key Encoding from a HI . . . . . 100
	Appendix C. Example Checksums for HIP Packets . . . . . . . . . 99		Appendix C. Example Checksums for HIP Packets . . . . . . . . . 101
	C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 99		C.1. IPv6 HIP Example (I1) . . . . . . . . . . . . . . . . . . 101
	C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 99		C.2. IPv4 HIP Packet (I1) . . . . . . . . . . . . . . . . . . 101
	C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 99		C.3. TCP Segment . . . . . . . . . . . . . . . . . . . . . . . 101
	Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 101		Appendix D. 384-bit Group . . . . . . . . . . . . . . . . . . . 103
	Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 102		Appendix E. OAKLEY Well-known group 1 . . . . . . . . . . . . . 104
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
	Intellectual Property and Copyright Statements . . . . . . . . . 104		Intellectual Property and Copyright Statements . . . . . . . . . 106
	1. Introduction		1. Introduction
	This memo specifies the details of the Host Identity Protocol (HIP).		This memo specifies the details of the Host Identity Protocol (HIP).
	A high-level description of the protocol and the underlying		A high-level description of the protocol and the underlying
	architectural thinking is available in the separate HIP architecture		architectural thinking is available in the separate HIP architecture
	description [I-D.ietf-hip-arch]. Briefly, the HIP architecture		description [I-D.ietf-hip-arch]. Briefly, the HIP architecture
	proposes an alternative to the dual use of IP addresses as "locators"		proposes an alternative to the dual use of IP addresses as "locators"
	(routing labels) and "identifiers" (endpoint, or host, identifiers).		(routing labels) and "identifiers" (endpoint, or host, identifiers).
	In HIP, public cryptographic keys, of a public/private key pair, are		In HIP, public cryptographic keys, of a public/private key pair, are
	skipping to change at page 10, line 49 ¶		skipping to change at page 10, line 49 ¶
	The Host Identity Tag is a 128 bits long value -- a hashed encoding		The Host Identity Tag is a 128 bits long value -- a hashed encoding
	of the Host Identifier. There are two advantages of using a hashed		of the Host Identifier. There are two advantages of using a hashed
	encoding over the actual Host Identity public key in protocols.		encoding over the actual Host Identity public key in protocols.
	Firstly, its fixed length makes for easier protocol coding and also		Firstly, its fixed length makes for easier protocol coding and also
	better manages the packet size cost of this technology. Secondly, it		better manages the packet size cost of this technology. Secondly, it
	presents a consistent format to the protocol whatever underlying		presents a consistent format to the protocol whatever underlying
	identity technology is used.		identity technology is used.
	"An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers		"An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
	(ORCHID)" [I-D.laganier-ipv6-khi] has been specified to store 128-bit		(ORCHID)" [RFC4843] has been specified to store 128-bit hash based
	hash based identifier called Overlay Routable Cryptographic Hash		identifier called Overlay Routable Cryptographic Hash Identifiers
	Identifiers (ORCHID) under a prefix, proposed to be allocated from		(ORCHID) under a prefix, proposed to be allocated from the IPv6
	the IPv6 address block as defined in [I-D.laganier-ipv6-khi]. The		address block as defined in [RFC4843]. The Host Identity Tag is a
	Host Identity Tag is a type of ORCHID, based on a SHA-1 hash of the		type of ORCHID, based on a SHA-1 hash of the host identity (Section 2
	host identity (Section 2 of [I-D.laganier-ipv6-khi]).		of [RFC4843]).
	3.2. Generating a HIT from a HI		3.2. Generating a HIT from a HI
	The HIT MUST be generated according to the ORCHID generation method		The HIT MUST be generated according to the ORCHID generation method
	described in [I-D.laganier-ipv6-khi] using a context ID value of		described in [RFC4843] using a context ID value of 0xF0EF F02F BFF4
	0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (this tag value has been		3D0F E793 0C3C 6E61 74EA (this tag value has been generated randomly
	generated randomly by the editor of this specification), and an input		by the editor of this specification), and an input encoding the Host
	encoding the Host Identity field (see Section 5.2.8) present in a HIP		Identity field (see Section 5.2.8) present in a HIP payload packet.
	payload packet. The hash algorithm SHA-1 has to be used when		The hash algorithm SHA-1 has to be used when generating HITs with
	generating HITs with this context ID. If a new ORCHID hash algorithm		this context ID. If a new ORCHID hash algorithm is needed in the
	is needed in the future for HIT generation, a new version of HIP has		future for HIT generation, a new version of HIP has to be specified
	to be specified with a new ORCHID context ID associated with the new		with a new ORCHID context ID associated with the new hash algorithm.
	hash algorithm.
	For Identities that are either RSA or DSA public keys, this input		For Identities that are either RSA or DSA public keys, this input
	consists of the public key encoding as specified in the corresponding		consists of the public key encoding as specified in the corresponding
	DNSSEC document, taking the algorithm specific portion of the RDATA		DNSSEC document, taking the algorithm specific portion of the RDATA
	part of the KEY RR. There is currently only two defined public key		part of the KEY RR. There is currently only two defined public key
	algorithms: RSA/SHA1 and DSA. Hence, either of the following		algorithms: RSA/SHA1 and DSA. Hence, either of the following
	applies:		applies:
	The RSA public key is encoded as defined in RFC3110 [RFC3110]		The RSA public key is encoded as defined in RFC3110 [RFC3110]
	Section 2, taking the exponent length (e_len), exponent (e) and		Section 2, taking the exponent length (e_len), exponent (e) and
	skipping to change at page 18, line 9 ¶		skipping to change at page 18, line 9 ¶
	There are multiple security issues involved with opportunistic mode		There are multiple security issues involved with opportunistic mode
	that must be carefully addressed in the implementation. Such a set		that must be carefully addressed in the implementation. Such a set
	up is vulnerable to, e.g., man-in-the-middle attacks, because the		up is vulnerable to, e.g., man-in-the-middle attacks, because the
	initializing node does not have any public key information about the		initializing node does not have any public key information about the
	peer.		peer.
	While this document defines the concept of the opportunistic mode,		While this document defines the concept of the opportunistic mode,
	and outlines the basic signalling mechanism to trigger it; i.e., send		and outlines the basic signalling mechanism to trigger it; i.e., send
	an I1 with a NULL destination HIT, this document does not specify the		an I1 with a NULL destination HIT, this document does not specify the
	details of the opportunistic mode. Especially, its security		details of the opportunistic mode. Especially, its security
	properties are not discussed beyond the warning above. It is		properties are not discussed beyond the warning above. However, the
	expected that a separate document will describe the opportunistic		authors believe that using the opportunistic mode is no less secure
	mode in more detail, including its security properties.		than communicating, without any cryptographic protection, over the
			current Internet. It is expected that a separate document will
			describe the opportunistic mode in more detail, including its
			security properties.
	4.2. Updating a HIP Association		4.2. Updating a HIP Association
	A HIP association between two hosts may need to be updated over time.		A HIP association between two hosts may need to be updated over time.
	Examples include the need to rekey expiring user data security		Examples include the need to rekey expiring user data security
	associations, add new security associations, or change IP addresses		associations, add new security associations, or change IP addresses
	associated with hosts. The UPDATE packet is used for those and other		associated with hosts. The UPDATE packet is used for those and other
	similar purposes. This document only specifies the UPDATE packet		similar purposes. This document only specifies the UPDATE packet
	format and basic processing rules, with mandatory parameters. The		format and basic processing rules, with mandatory parameters. The
	actual usage is defined in separate specifications.		actual usage is defined in separate specifications.
	skipping to change at page 23, line 19 ¶		skipping to change at page 23, line 19 ¶
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| Receive I1 | Send R1 and stay at I2-SENT |		| Receive I1 | Send R1 and stay at I2-SENT |
	| | |		| | |
	| Receive R1, process | If successful, send I2 and cycle at I2-SENT |		| Receive R1, process | If successful, send I2 and cycle at I2-SENT |
	| | |		| | |
	| | If fail, stay at I2-SENT |		| | If fail, stay at I2-SENT |
	| | |		| | |
	| Receive I2, process | If successful and local HIT is smaller than |		| Receive I2, process | If successful and local HIT is smaller than |
	| | the peer HIT, drop I2 and stay at I2-SENT |		| | the peer HIT, drop I2 and stay at I2-SENT |
	| | |		| | |
	| | If succesful and local HIT is greater than |		| | If successful and local HIT is greater than |
	| | the peer HIT, send R2 and go to R2-SENT |		| | the peer HIT, send R2 and go to R2-SENT |
	| | |		| | |
	| | If fail, stay at I2-SENT |		| | If fail, stay at I2-SENT |
	| | |		| | |
	| Receive R2, process | If successful, go to ESTABLISHED |		| Receive R2, process | If successful, go to ESTABLISHED |
	| | |		| | |
	| | If fail, stay at I2-SENT |		| | If fail, stay at I2-SENT |
	| | |		| | |
	| Receive ANYOTHER | Drop and stay at I2-SENT |		| Receive ANYOTHER | Drop and stay at I2-SENT |
	| | |		| | |
	skipping to change at page 33, line 33 ¶		skipping to change at page 33, line 33 ¶
	case that the forthcoming SHIM6 protocol happens to be compatible		case that the forthcoming SHIM6 protocol happens to be compatible
	with this specification, an implementation that implements both this		with this specification, an implementation that implements both this
	specification and the SHIM6 protocol may need to check these bits in		specification and the SHIM6 protocol may need to check these bits in
	order to determine how to handle the packet.		order to determine how to handle the packet.
	The HIT fields are always 128 bits (16 bytes) long.		The HIT fields are always 128 bits (16 bytes) long.
	5.1.1. Checksum		5.1.1. Checksum
	Since the checksum covers the source and destination addresses in the		Since the checksum covers the source and destination addresses in the
	IP header, it must be recomputed on HIP-aware NAT devies.		IP header, it must be recomputed on HIP-aware NAT devices.
	If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460]		If IPv6 is used to carry the HIP packet, the pseudo-header [RFC2460]
	contains the source and destination IPv6 addresses, HIP packet length		contains the source and destination IPv6 addresses, HIP packet length
	in the pseudo-header length field, a zero field, and the HIP protocol		in the pseudo-header length field, a zero field, and the HIP protocol
	number (see Section 4) in the Next Header field. The length field is		number (see Section 4) in the Next Header field. The length field is
	in bytes and can be calculated from the HIP header length field: (HIP		in bytes and can be calculated from the HIP header length field: (HIP
	Header Length + 1) * 8.		Header Length + 1) * 8.
	In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is		In case of using IPv4, the IPv4 UDP pseudo header format [RFC0768] is
	used. In the pseudo header, the source and destination addresses are		used. In the pseudo header, the source and destination addresses are
	skipping to change at page 49, line 25 ¶		skipping to change at page 49, line 25 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| peer Update ID |		| peer Update ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type 449		Type 449
	Length variable (multiple of 4)		Length variable (multiple of 4)
	peer Update ID 32-bit sequence number corresponding to the		peer Update ID 32-bit sequence number corresponding to the
	Update ID being acked.		Update ID being ACKed.
	The ACK parameter includes one or more Update IDs that have been		The ACK parameter includes one or more Update IDs that have been
	received from the peer. The Length field identifies the number of		received from the peer. The Length field identifies the number of
	peer Update IDs that are present in the parameter.		peer Update IDs that are present in the parameter.
	5.2.15. ENCRYPTED		5.2.15. ENCRYPTED
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 54, line 29 ¶		skipping to change at page 54, line 29 ¶
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Opaque data (variable length) |		| Opaque data (variable length) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type 897		Type 897
	Length variable		Length variable
	Opaque data Opaque data, supposed to be meaningful only to the		Opaque data Opaque data, supposed to be meaningful only to the
	node that sends ECHO_REQUEST_SIGNED and receives a		node that sends ECHO_REQUEST_SIGNED and receives a
	corresponding ECHO_RESPONSE_SIGNED or		corresponding ECHO_RESPONSE_SIGNED or
	ECHO_RESPONSE_UNSINGED.		ECHO_RESPONSE_UNSIGNED.
	The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data		The ECHO_REQUEST_SIGNED parameter contains an opaque blob of data
	that the sender wants to get echoed back in the corresponding reply		that the sender wants to get echoed back in the corresponding reply
	packet.		packet.
	The ECHO_REQUEST_SIGNED and corresponding echo response parameters		The ECHO_REQUEST_SIGNED and corresponding echo response parameters
	MAY be used for any purpose where a node wants to carry some state in		MAY be used for any purpose where a node wants to carry some state in
	a request packet and get it back in a response packet. The		a request packet and get it back in a response packet. The
	ECHO_REQUEST_SIGNED is covered by the HMAC and SIGNATURE. A HIP		ECHO_REQUEST_SIGNED is covered by the HMAC and SIGNATURE. A HIP
	packet can contain only one ECHO_REQUEST_SIGNED or		packet can contain only one ECHO_REQUEST_SIGNED or
	skipping to change at page 55, line 19 ¶		skipping to change at page 55, line 19 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Opaque data (variable length) |		| Opaque data (variable length) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type 63661		Type 63661
	Length variable		Length variable
	Opaque data Opaque data, supposed to be meaningful only to the		Opaque data Opaque data, supposed to be meaningful only to the
	node that sends ECHO_REQUEST_UNSIGNED and receives a		node that sends ECHO_REQUEST_UNSIGNED and receives a
	corresponding ECHO_RESPONSE_SIGNED or		corresponding ECHO_RESPONSE_UNSIGNED.
	ECHO_RESPONSE_UNSIGNED.
	The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data		The ECHO_REQUEST_UNSIGNED parameter contains an opaque blob of data
	that the sender wants to get echoed back in the corresponding reply		that the sender wants to get echoed back in the corresponding reply
	packet.		packet.
	The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters		The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters
	MAY be used for any purpose where a node wants to carry some state in		MAY be used for any purpose where a node wants to carry some state in
	a request packet and get it back in a response packet. The		a request packet and get it back in a response packet. The
	ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A		ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A
	HIP packet can contain only one ECHO_REQUEST_SIGNED or		HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters.
	ECHO_REQUEST_UNSIGNED parameter. The ECHO_REQUEST_UNSIGNED parameter		It is possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters
	MUST be responded with an ECHO_RESPONSE_UNSIGNED parameter.		in HIP packets passing by. The sender has to create the Opaque field
			so that it can later identify the corresponding
			ECHO_RESPONSE_UNSIGNED parameter.
			The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an
			ECHO_RESPONSE_UNSIGNED parameter.
	5.2.19. ECHO_RESPONSE_SIGNED		5.2.19. ECHO_RESPONSE_SIGNED
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Opaque data (variable length) |		| Opaque data (variable length) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 58, line 40 ¶		skipping to change at page 58, line 40 ¶
	SRC HIT = Responder's HIT		SRC HIT = Responder's HIT
	DST HIT = Initiator's HIT		DST HIT = Initiator's HIT
	IP ( HIP ( [ R1_COUNTER, ]		IP ( HIP ( [ R1_COUNTER, ]
	PUZZLE,		PUZZLE,
	DIFFIE_HELLMAN,		DIFFIE_HELLMAN,
	HIP_TRANSFORM,		HIP_TRANSFORM,
	HOST_ID,		HOST_ID,
	[ ECHO_REQUEST_SIGNED, ]		[ ECHO_REQUEST_SIGNED, ]
	HIP_SIGNATURE_2 )		HIP_SIGNATURE_2 )
	[, ECHO_REQUEST_UNSIGNED ])		<, ECHO_REQUEST_UNSIGNED >i)
	Valid control bits: A		Valid control bits: A
	If the Responder HI is an anonymous one, the A control MUST be set.		If the Responder HI is an anonymous one, the A control MUST be set.
	The Initiator HIT MUST match the one received in I1. If the		The Initiator HIT MUST match the one received in I1. If the
	Responder has multiple HIs, the Responder HIT used MUST match		Responder has multiple HIs, the Responder HIT used MUST match
	Initiator's request. If the Initiator used opportunistic mode, the		Initiator's request. If the Initiator used opportunistic mode, the
	Responder may select freely among its HIs. See also "HIP		Responder may select freely among its HIs. See also "HIP
	Opportunistic Mode" (Section 4.1.6)).		Opportunistic Mode" (Section 4.1.6)).
	skipping to change at page 59, line 42 ¶		skipping to change at page 59, line 42 ¶
	to potentially easier cryptographic attacks and the risk of not		to potentially easier cryptographic attacks and the risk of not
	having perfect forward security.		having perfect forward security.
	However, these risks involved in re-using the same key are		However, these risks involved in re-using the same key are
	statistical; that is, authors are not aware of any mechanism that		statistical; that is, authors are not aware of any mechanism that
	would allow manipulation of the protocol so that the risk of the re-		would allow manipulation of the protocol so that the risk of the re-
	use of a any given Responder Diffie-Hellman public key would differ		use of a any given Responder Diffie-Hellman public key would differ
	from the base probability. Consequently, it is RECOMMENDED that		from the base probability. Consequently, it is RECOMMENDED that
	implementations avoid re-using the same D-H key with multiple		implementations avoid re-using the same D-H key with multiple
	Initiators, but because the risk is considered statistical and not		Initiators, but because the risk is considered statistical and not
	known to be manipulatable, the implementations MAY re-use a key in		known to be manipulable, the implementations MAY re-use a key in
	order to ease resource constraint implementations and to increase the		order to ease resource constraint implementations and to increase the
	probability of successful communication with legitimate clients even		probability of successful communication with legitimate clients even
	under an I1 storm. In particular, when it is too expensive to		under an I1 storm. In particular, when it is too expensive to
	generate enough of pre-computed R1 packets to supply each potential		generate enough of pre-computed R1 packets to supply each potential
	Initiator with a different Diffie-Hellman key, the Responder MAY send		Initiator with a different Diffie-Hellman key, the Responder MAY send
	the same Diffie-Hellman key to several Initiators, thereby creating		the same Diffie-Hellman key to several Initiators, thereby creating
	the possibility of multiple legitimate Initiators ending up using the		the possibility of multiple legitimate Initiators ending up using the
	same Responder-side public key. However, as soon as the Responder		same Responder-side public key. However, as soon as the Responder
	knows that it will use a particular Diffie-Hellman key, it SHOULD		knows that it will use a particular Diffie-Hellman key, it SHOULD
	stop offering it. This design is aimed to allow resource-constrained		stop offering it. This design is aimed to allow resource-constrained
	skipping to change at page 61, line 4 ¶		skipping to change at page 61, line 4 ¶
	DST HIT = Responder's HIT		DST HIT = Responder's HIT
	IP ( HIP ( [R1_COUNTER,]		IP ( HIP ( [R1_COUNTER,]
	SOLUTION,		SOLUTION,
	DIFFIE_HELLMAN,		DIFFIE_HELLMAN,
	HIP_TRANSFORM,		HIP_TRANSFORM,
	ENCRYPTED { HOST_ID } or HOST_ID,		ENCRYPTED { HOST_ID } or HOST_ID,
	[ ECHO_RESPONSE_SIGNED ,]		[ ECHO_RESPONSE_SIGNED ,]
	HMAC,		HMAC,
	HIP_SIGNATURE		HIP_SIGNATURE
			<, ECHO_RESPONSE_UNSIGNED>i ) )
	[, ECHO_RESPONSE_UNSIGNED] ) )
	Valid control bits: A		Valid control bits: A
	The HITs used MUST match the ones used previously.		The HITs used MUST match the ones used previously.
	If the Initiator HI is an anonymous one, the A control MUST be set.		If the Initiator HI is an anonymous one, the A control MUST be set.
	The Initiator MAY include an unmodified copy of the R1_COUNTER		The Initiator MAY include an unmodified copy of the R1_COUNTER
	parameter received in the corresponding R1 packet into the I2 packet.		parameter received in the corresponding R1 packet into the I2 packet.
	skipping to change at page 62, line 17 ¶		skipping to change at page 62, line 17 ¶
	SRC HIT = Responder's HIT		SRC HIT = Responder's HIT
	DST HIT = Initiator's HIT		DST HIT = Initiator's HIT
	IP ( HIP ( HMAC_2, HIP_SIGNATURE ) )		IP ( HIP ( HMAC_2, HIP_SIGNATURE ) )
	Valid control bits: none		Valid control bits: none
	The HMAC_2 is calculated over whole HIP envelope, with Responder's		The HMAC_2 is calculated over whole HIP envelope, with Responder's
	HOST_ID parameter concatenated with the HIP envelope. The HOST_ID		HOST_ID parameter concatenated with the HIP envelope. The HOST_ID
	parameter is removed after the HMAC calculation. The procedure is		parameter is removed after the HMAC calculation. The procedure is
	described in 8.3.1.		described in Section 6.4.1.
	The signature is calculated over whole HIP envelope.		The signature is calculated over whole HIP envelope.
	The Initiator MUST validate both the HMAC and the signature.		The Initiator MUST validate both the HMAC and the signature.
	5.3.5. UPDATE - the HIP Update Packet		5.3.5. UPDATE - the HIP Update Packet
	Support for the UPDATE packet is MANDATORY.		Support for the UPDATE packet is MANDATORY.
	The HIP header values for the UPDATE packet:		The HIP header values for the UPDATE packet:
	skipping to change at page 62, line 42 ¶		skipping to change at page 62, line 42 ¶
	DST HIT = Recipient's HIT		DST HIT = Recipient's HIT
	IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) )		IP ( HIP ( [SEQ, ACK, ] HMAC, HIP_SIGNATURE ) )
	Valid control bits: None		Valid control bits: None
	The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE		The UPDATE packet contains mandatory HMAC and HIP_SIGNATURE
	parameters, and other optional parameters.		parameters, and other optional parameters.
	The UPDATE packet contains zero or one SEQ parameter. The presence		The UPDATE packet contains zero or one SEQ parameter. The presence
	of a SEQ parameter indicates that the receiver MUST ack the UPDATE.		of a SEQ parameter indicates that the receiver MUST ACK the UPDATE.
	An UPDATE that does not contain a SEQ parameter is simply an ACK of a		An UPDATE that does not contain a SEQ parameter is simply an ACK of a
	previous UPDATE and itself MUST NOT be acked.		previous UPDATE and itself MUST NOT be ACKed.
	An UPDATE packet contains zero or one ACK parameters. The ACK		An UPDATE packet contains zero or one ACK parameters. The ACK
	parameter echoes the SEQ sequence number of the UPDATE packet being		parameter echoes the SEQ sequence number of the UPDATE packet being
	acked. A host MAY choose to ack more than one UPDATE packet at a		ACKed. A host MAY choose to ACK more than one UPDATE packet at a
	time; e.g., the ACK may contain the last two SEQ values received, for		time; e.g., the ACK may contain the last two SEQ values received, for
	robustness to ack loss. ACK values are not cumulative; each received		robustness to ACK loss. ACK values are not cumulative; each received
	unique SEQ value requires at least one corresponding ACK value in		unique SEQ value requires at least one corresponding ACK value in
	reply. Received ACKs that are redundant are ignored.		reply. Received ACKs that are redundant are ignored.
	The UPDATE packet may contain both a SEQ and an ACK parameter. In		The UPDATE packet may contain both a SEQ and an ACK parameter. In
	this case, the ACK is being piggybacked on an outgoing UPDATE. In		this case, the ACK is being piggybacked on an outgoing UPDATE. In
	general, UPDATEs carrying SEQ SHOULD be acked upon completion of the		general, UPDATEs carrying SEQ SHOULD be ACKed upon completion of the
	processing of the UPDATE. A host MAY choose to hold the UPDATE		processing of the UPDATE. A host MAY choose to hold the UPDATE
	carrying ACK for a short period of time to allow for the possibility		carrying ACK for a short period of time to allow for the possibility
	of piggybacking the ACK parameter, in a manner similar to TCP delayed		of piggybacking the ACK parameter, in a manner similar to TCP delayed
	acknowledgments.		acknowledgments.
	A sender MAY choose to forego reliable transmission of a particular		A sender MAY choose to forgo reliable transmission of a particular
	UPDATE (e.g., it becomes overcome by events). The semantics are such		UPDATE (e.g., it becomes overcome by events). The semantics are such
	that the receiver MUST acknowledge the UPDATE but the sender MAY		that the receiver MUST acknowledge the UPDATE but the sender MAY
	choose to not care about receiving the ACK.		choose to not care about receiving the ACK.
	UPDATEs MAY be retransmitted without incrementing SEQ. If the same		UPDATEs MAY be retransmitted without incrementing SEQ. If the same
	subset of parameters is included in multiple UPDATEs with different		subset of parameters is included in multiple UPDATEs with different
	SEQs, the host MUST ensure that receiver processing of the parameters		SEQs, the host MUST ensure that receiver processing of the parameters
	multiple times will not result in a protocol error.		multiple times will not result in a protocol error.
	5.3.6. NOTIFY - the HIP Notify Packet		5.3.6. NOTIFY - the HIP Notify Packet
	skipping to change at page 67, line 44 ¶		skipping to change at page 67, line 44 ¶
	1. The incoming datagram is mapped to an existing HIP association,		1. The incoming datagram is mapped to an existing HIP association,
	typically using some information from the packet. For example,		typically using some information from the packet. For example,
	such mapping may be based on ESP Security Parameter Index (SPI).		such mapping may be based on ESP Security Parameter Index (SPI).
	2. The specific transport format is unwrapped, in a way depending on		2. The specific transport format is unwrapped, in a way depending on
	the transport format, yielding a packet that looks like a		the transport format, yielding a packet that looks like a
	standard (unencrypted) IP packet. If possible, this step SHOULD		standard (unencrypted) IP packet. If possible, this step SHOULD
	also verify that the packet was indeed (once) sent by the remote		also verify that the packet was indeed (once) sent by the remote
	HIP host, as identified by the HIP association.		HIP host, as identified by the HIP association.
			Depending on the used transport mode, the verification method can
			vary. While the HI (as well as HIT) is used as the higher layer
			identifier, the verification method has to verify that the data
			packet was sent by a node identity and that the actual identity
			maps to this particular HIT. When using ESP transport format
			[I-D.ietf-hip-esp], the verification is done using the SPI value
			in the data packet to find the corresponding SA with associated
			HIT and key, and decrypting the packet with that associated key.
	3. The IP addresses in the datagram are replaced with the HITs		3. The IP addresses in the datagram are replaced with the HITs
	associated with the HIP association. Note that this IP-address-		associated with the HIP association. Note that this IP-address-
	to-HIT conversion step MAY also be performed at some other point		to-HIT conversion step MAY also be performed at some other point
	in the stack.		in the stack.
	4. The datagram is delivered to the upper layer. Demultiplexing the		4. The datagram is delivered to the upper layer. Demultiplexing the
	datagram the right upper layer socket is based on the HITs.		datagram the right upper layer socket is based on the HITs.
	6.3. Solving the Puzzle		6.3. Solving the Puzzle
	skipping to change at page 69, line 36 ¶		skipping to change at page 69, line 46 ¶
	When processing HMAC_2, the difference is that the HMAC calculation		When processing HMAC_2, the difference is that the HMAC calculation
	includes a pseudo HOST_ID field containing the Responder's		includes a pseudo HOST_ID field containing the Responder's
	information as sent in the R1 packet earlier.		information as sent in the R1 packet earlier.
	Both the Initiator and the Responder should take some care when		Both the Initiator and the Responder should take some care when
	verifying or calculating the HMAC_2. Specifically, the Responder		verifying or calculating the HMAC_2. Specifically, the Responder
	should preserve other parameters than the HOST_ID when sending the		should preserve other parameters than the HOST_ID when sending the
	R2. Also, the Initiator has to preserve the HOST_ID exactly as it		R2. Also, the Initiator has to preserve the HOST_ID exactly as it
	was received in the R1 packet.		was received in the R1 packet.
			The scope of the calculation for HMAC and HMAC_2 is:
			HMAC: { HIP header | [ Parameters ] }
			where Parameters include all HIP parameters of the packet that is
			being calculated with Type values from 1 to (HMAC's Type value - 1)
			and exclude parameters with Type values greater or equal to HMAC's
			Type value.
			During HMAC Calculation, the following applies:
			o In HIP header, Checksum field is set to zero.
			o In HIP header, the Header Length field value is calculated to the
			beginning of the HMAC parameter.
			Parameter order is described in Section 5.2.1.
			HMAC_2: { HIP header | [ Parameters ] | HOST_ID }
			where Parameters include all HIP parameters for the packet that is
			being calculated with Type values from 1 to (HMAC_2's Type value - 1)
			and exclude parameters with Type values greater or equal to HMAC_2's
			Type value.
			During HMAC calculation, the following applies:
			o In HIP header, Checksum field is set to zero.
			o In HIP header, the Header Length field value is calculated to the
			beginning of the HMAC_2 parameter and added with the length of the
			concatenated HOST_ID parameter length.
			o HOST_ID parameter is exactly in the form it was received in the R1
			packet from the Responder.
			Parameter order is described in Section 5.2.1, except that HOST_ID
			parameter in this calculation is added to the end.
	The HMAC parameter is defined in Section 5.2.9 and HMAC_2 parameter		The HMAC parameter is defined in Section 5.2.9 and HMAC_2 parameter
	in Section 5.2.10. HMAC calculation and verification process:		in Section 5.2.10. HMAC calculation and verification process (the
			process applies both to HMAC and HMAC_2 except where HMAC_2 is
			mentioned separately) :
	Packet sender:		Packet sender:
	1. Create the HIP packet, without the HMAC or any possible		1. Create the HIP packet, without the HMAC, HIP_SIGNATURE,
	HIP_SIGNATURE or HIP_SIGNATURE_2 parameters.		HIP_SIGNATURE_2, or any other parameter with greater Type value
			than the HMAC parameter has.
	2. In case of HMAC_2 calculation, add a HOST_ID (Responder)		2. In case of HMAC_2 calculation, add a HOST_ID (Responder)
	parameter to the packet.		parameter to the end of the packet.
	3. Calculate the Length field in the HIP header.		3. Calculate the Header Length field in the HIP header including the
			added HOST_ID parameter in case of HMAC_2.
	4. Compute the HMAC.		4. Compute the HMAC using either HIP-gl or HIP-lg integrity key
			retrieved from KEYMAT as defined in Section 6.5.
	5. In case of HMAC_2, remove the HOST_ID parameter from the packet.		5. In case of HMAC_2, remove the HOST_ID parameter from the packet.
	6. Add the HMAC parameter to the packet and any HIP_SIGNATURE or		6. Add the HMAC parameter to the packet and any parameter with
	HIP_SIGNATURE_2 parameters that may follow.		greater Type value than the HMAC's (HMAC_2's) that may follow,
			including possible HIP_SIGNATURE or HIP_SIGNATURE_2 parameters
	7. Recalculate the Length field in the HIP header.		7. Recalculate the Length field in the HIP header.
	Packet receiver:		Packet receiver:
	1. Verify the HIP header Length field.		1. Verify the HIP header Length field.
	2. Remove the HMAC or HMAC_2 parameter, and if the packet contains		2. Remove the HMAC or HMAC_2 parameter, as well as all other
	any HIP_SIGNATURE or HIP_SIGNATURE_2 fields, remove them too,		parameters that follow it with greater Type value including
	saving the contents if they will be needed later.		possible HIP_SIGNATURE or HIP_SIGNATURE_2 fields, saving the
			contents if they will be needed later.
	3. In case of HMAC_2, build and add a HOST_ID parameter (with		3. In case of HMAC_2, build and add a HOST_ID parameter (with
	Responder information) to the packet. The HOST_ID parameter		Responder information) to the packet. The HOST_ID parameter
	should be identical to the one previously received from the		should be identical to the one previously received from the
	Responder.		Responder.
	4. Recalculate the HIP packet length in the HIP header and clear the		4. Recalculate the HIP packet length in the HIP header and clear the
	Checksum field (set it to all zeros).		Checksum field (set it to all zeros). In case of HMAC_2, the
			length is calculated with the added HOST_ID parameter.
	5. Compute the HMAC and verify it against the received HMAC.		5. Compute the HMAC using either HIP-gl or HIP-lg integrity key as
			defined in Section 6.5 and verify it against the received HMAC.
	6. In case of HMAC_2, remove the HOST_ID parameter from the packet		6. Set Checksum and Header Length field in HIP header to original
			values.
			7. In case of HMAC_2, remove the HOST_ID parameter from the packet
	before further processing.		before further processing.
	6.4.2. Signature Calculation		6.4.2. Signature Calculation
	The following process applies both to the HIP_SIGNATURE and		The following process applies both to the HIP_SIGNATURE and
	HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the		HIP_SIGNATURE_2 parameters. When processing HIP_SIGNATURE_2, the
	only difference is that instead of HIP_SIGNATURE parameter, the		only difference is that instead of HIP_SIGNATURE parameter, the
	HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE		HIP_SIGNATURE_2 parameter is used, and the Initiator's HIT and PUZZLE
	Opaque and Random #I fields are cleared (set to all zeros) before		Opaque and Random #I fields are cleared (set to all zeros) before
	computing the signature. The HIP_SIGNATURE parameter is defined in		computing the signature. The HIP_SIGNATURE parameter is defined in
	Section 5.2.11 and the HIP_SIGNATURE_2 parameter in Section 5.2.12.		Section 5.2.11 and the HIP_SIGNATURE_2 parameter in Section 5.2.12.
	Signature calculation and verification process:		The scope of the calculation for HIP_SIGNATURE and HIP_SIGNATURE_2
			is:
			HIP_SIGNATURE: { HIP header | [ Parameters ] }
			where Parameters include all HIP parameters for the packet that is
			being calculated with Type values from 1 to (HIP_SIGNATURE's Type
			value - 1).
			During signature calculation, the following apply:
			o In HIP header, Checksum field is set to zero.
			o In HIP header, the Header Length field value is calculated to the
			beginning of the HIP_SIGNATURE parameter.
			Parameter order is described in Section 5.2.1.
			HIP_SIGNATURE_2: { HIP header | [ Parameters ] }
			where Parameters include all HIP parameters for the packet that is
			being calculated with Type values from 1 to (HIP_SIGNATURE_2's Type
			value - 1).
			During signature calculation, the following apply:
			o In HIP header, Initiator's HIT field and Checksum fields are set
			to zero.
			o In HIP header, the Header Length field value is calculated to the
			beginning of the HIP_SIGNATURE_2 parameter.
			o PUZZLE parameter's Opaque and Random #I fields are set to zero.
			Parameter order is described in Section 5.2.1.
			Signature calculation and verification process (the process applies
			both to HIP_SIGNATURE and HIP_SIGNATURE_2 except in case where
			HIP_SIGNATURE_2 is separately mentioned):
	Packet sender:		Packet sender:
	1. Create the HIP packet without the HIP_SIGNATURE parameter or any		1. Create the HIP packet without the HIP_SIGNATURE parameter or any
	parameters that follow the HIP_SIGNATURE parameter.		parameters that follow the HIP_SIGNATURE parameter.
	2. Calculate the Length field and zero the Checksum field in the HIP		2. Calculate the Length field and zero the Checksum field in the HIP
	header.		header. In case of HIP_SIGNATURE_2, set Initiator's HIT field in
			HIP header as well as PUZZLE parameter's Opaque and Random #I
			fields to zero.
	3. Compute the signature.		3. Compute the signature using the private key corresponding to the
			Host Identifier (public key).
	4. Add the HIP_SIGNATURE parameter to the packet.		4. Add the HIP_SIGNATURE parameter to the packet.
	5. Add any parameters that follow the HIP_SIGNATURE parameter.		5. Add any parameters that follow the HIP_SIGNATURE parameter.
	6. Recalculate the Length field in the HIP header, and calculate the		6. Recalculate the Length field in the HIP header, and calculate the
	Checksum field.		Checksum field.
	Packet receiver:		Packet receiver:
	1. Verify the HIP header Length field.		1. Verify the HIP header Length field.
	2. Save the contents of the HIP_SIGNATURE parameter and any		2. Save the contents of the HIP_SIGNATURE parameter and any
	parameters following the HIP_SIGNATURE parameter and remove them		parameters following the HIP_SIGNATURE parameter and remove them
	from the packet.		from the packet.
	3. Recalculate the HIP packet Length in the HIP header and clear the		3. Recalculate the HIP packet Length in the HIP header and clear the
	Checksum field (set it to all zeros).		Checksum field (set it to all zeros). In case of
			HIP_SIGNATURE_2, set Initiator's HIT field in HIP header as well
			as PUZZLE parameter's Opaque and Random #I fields to zero.
	4. Compute the signature and verify it against the received		4. Compute the signature and verify it against the received
	signature.		signature using the packet sender's Host Identifier (public key).
			5. Restore the original packet by adding removed parameters (in step
			2) and resetting the values that were set to zero (in step 3).
	The verification can use either the HI received from a HIP packet,		The verification can use either the HI received from a HIP packet,
	the HI from a DNS query, if the FQDN has been received in the HOST_ID		the HI from a DNS query, if the FQDN has been received in the HOST_ID
	packet, or one received by some other means.		packet, or one received by some other means.
	6.5. HIP KEYMAT Generation		6.5. HIP KEYMAT Generation
	HIP keying material is derived from the Diffie-Hellman session key,		HIP keying material is derived from the Diffie-Hellman session key,
	Kij, produced during the HIP base exchange (Section 4.1.3). The		Kij, produced during the HIP base exchange (Section 4.1.3). The
	Initiator has Kij during the creation of the I2 packet, and the		Initiator has Kij during the creation of the I2 packet, and the
	skipping to change at page 72, line 38 ¶		skipping to change at page 75, line 4 ¶
	HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP		HIP-lg encryption key (currently unused) for HOST_l's outgoing HIP
	packets		packets
	HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets		HIP-lg integrity (HMAC) key for HOST_l's outgoing HIP packets
	The number of bits drawn for a given algorithm is the "natural" size		The number of bits drawn for a given algorithm is the "natural" size
	of the keys. For the mandatory algorithms, the following sizes		of the keys. For the mandatory algorithms, the following sizes
	apply:		apply:
	AES 128 bits		AES 128 bits
	SHA-1 160 bits		SHA-1 160 bits
	NULL 0 bits		NULL 0 bits
	If other key sizes are used, they must be treated as different		If other key sizes are used, they must be treated as different
	encryption algorithms and defined separtely.		encryption algorithms and defined separately.
	6.6. Initiation of a HIP Exchange		6.6. Initiation of a HIP Exchange
	An implementation may originate a HIP exchange to another host based		An implementation may originate a HIP exchange to another host based
	on a local policy decision, usually triggered by an application		on a local policy decision, usually triggered by an application
	datagram, in much the same way that an IPsec IKE key exchange can		datagram, in much the same way that an IPsec IKE key exchange can
	dynamically create a Security Association. Alternatively, a system		dynamically create a Security Association. Alternatively, a system
	may initiate a HIP exchange if it has rebooted or timed out, or		may initiate a HIP exchange if it has rebooted or timed out, or
	otherwise lost its HIP state, as described in Section 4.5.4.		otherwise lost its HIP state, as described in Section 4.5.4.
	skipping to change at page 73, line 41 ¶		skipping to change at page 76, line 12 ¶
	4. Upon timeout, the sender SHOULD retransmit the I1 and restart the		4. Upon timeout, the sender SHOULD retransmit the I1 and restart the
	timer, up to a maximum of I1_RETRIES_MAX tries.		timer, up to a maximum of I1_RETRIES_MAX tries.
	6.6.1. Sending Multiple I1s in Parallel		6.6.1. Sending Multiple I1s in Parallel
	For the sake of minimizing the session establishment latency, an		For the sake of minimizing the session establishment latency, an
	implementation MAY send the same I1 to more than one of the		implementation MAY send the same I1 to more than one of the
	Responder's addresses. However, it MUST NOT send to more than three		Responder's addresses. However, it MUST NOT send to more than three
	(3) addresses in parallel. Furthermore, upon timeout, the		(3) addresses in parallel. Furthermore, upon timeout, the
	implementation MUST refrain from sending the same I1 packet to		implementation MUST refrain from sending the same I1 packet to
	multiple addresses. These limitations are placed order to avoid		multiple addresses. I.e. if it retries to initialize the connection
			after timeout, it MUST NOT send the I1 packet to more than one
			destination address. These limitations are placed in order to avoid
	congestion of the network, and potential DoS attacks that might		congestion of the network, and potential DoS attacks that might
	happen, e.g., because someone claims to have hundreds or thousands of		happen, e.g., because someone claims to have hundreds or thousands of
	addresses which possibly could generate a huge number of I1 messages		addresses which possibly could generate a huge number of I1 messages
	from the Initiator.		from the Initiator.
	As the Responder is not guaranteed to distinguish the duplicate I1's		As the Responder is not guaranteed to distinguish the duplicate I1's
	it receives at several of its addresses (because it avoids to store		it receives at several of its addresses (because it avoids to store
	states when it answers back an R1), the Initiator may receive several		states when it answers back an R1), the Initiator may receive several
	duplicate R1's.		duplicate R1's.
	skipping to change at page 78, line 51 ¶		skipping to change at page 81, line 24 ¶
	received I2 is similar to the one that triggered moving to R2-		received I2 is similar to the one that triggered moving to R2-
	SENT. If so, it MAY retransmit a previously sent R2, reset the		SENT. If so, it MAY retransmit a previously sent R2, reset the
	R2-SENT timer, and stay in R2-SENT.		R2-SENT timer, and stay in R2-SENT.
	4. If the system is in the I2-SENT state, it makes a comparison		4. If the system is in the I2-SENT state, it makes a comparison
	between its local and sender's HITs (similarly as in		between its local and sender's HITs (similarly as in
	Section 6.5). If the local HIT is smaller than the sender's		Section 6.5). If the local HIT is smaller than the sender's
	HIT, it should drop the I2 packet, use peer Diffie-Hellman key		HIT, it should drop the I2 packet, use peer Diffie-Hellman key
	and nonce I from the R1 packet received earlier, and get the		and nonce I from the R1 packet received earlier, and get the
	local Diffie-Hellman key and nonce J from the I2 packet sent to		local Diffie-Hellman key and nonce J from the I2 packet sent to
	the peer ealier. Otherwise, the system should process the		the peer earlier. Otherwise, the system should process the
	received I2 packet and drop any previously derived Diffie-		received I2 packet and drop any previously derived Diffie-
	Hellman keying material Kij it might have formed upon sending		Hellman keying material Kij it might have formed upon sending
	the I2 previously. The peer Diffie-Hellman key and nonce J are		the I2 previously. The peer Diffie-Hellman key and nonce J are
	taken from the just arrived I2 and local Diffie-Hellman key and		taken from the just arrived I2 and local Diffie-Hellman key and
	nonce I are the ones that it sent earlier in the R1 packet.		nonce I are the ones that it sent earlier in the R1 packet.
	5. If the system is in the I1-SENT state, and the HITs in the I2		5. If the system is in the I1-SENT state, and the HITs in the I2
	match those used in the previously sent I1, the system uses this		match those used in the previously sent I1, the system uses this
	received I2 as the basis for the HIP assocation it was trying to		received I2 as the basis for the HIP association it was trying
	form, and stops retransmitting I1 (provided that the I2 passes		to form, and stops retransmitting I1 (provided that the I2
	the below additional checks).		passes the below additional checks).
	6. If the system is in any other state than R2-SENT, it SHOULD		6. If the system is in any other state than R2-SENT, it SHOULD
	check that the echoed R1 generation counter in I2 is within the		check that the echoed R1 generation counter in I2 is within the
	acceptable range. Implementations MUST accept puzzles from the		acceptable range. Implementations MUST accept puzzles from the
	current generation and MAY accept puzzles from earlier		current generation and MAY accept puzzles from earlier
	generations. If the newly received I2 is outside the accepted		generations. If the newly received I2 is outside the accepted
	range, the I2 is stale (perhaps replayed) and SHOULD be dropped.		range, the I2 is stale (perhaps replayed) and SHOULD be dropped.
	7. The system MUST validate the solution to the puzzle by computing		7. The system MUST validate the solution to the puzzle by computing
	the hash described in Section 5.3.3 using the same RHASH		the hash described in Section 5.3.3 using the same RHASH
	skipping to change at page 79, line 41 ¶		skipping to change at page 82, line 15 ¶
	9. The system must derive Diffie-Hellman keying material Kij based		9. The system must derive Diffie-Hellman keying material Kij based
	on the public value and Group ID in the DIFFIE_HELLMAN		on the public value and Group ID in the DIFFIE_HELLMAN
	parameter. This key is used to derive the HIP association keys,		parameter. This key is used to derive the HIP association keys,
	as described in Section 6.5. If the Diffie-Hellman Group ID is		as described in Section 6.5. If the Diffie-Hellman Group ID is
	unsupported, the I2 packet is silently dropped.		unsupported, the I2 packet is silently dropped.
	10. The encrypted HOST_ID decrypted by the Initiator encryption key		10. The encrypted HOST_ID decrypted by the Initiator encryption key
	defined in Section 6.5. If the decrypted data is not a HOST_ID		defined in Section 6.5. If the decrypted data is not a HOST_ID
	parameter, the I2 packet is silently dropped.		parameter, the I2 packet is silently dropped.
	11. The implementation SHOULD also verify that the Initiator's HIT		11. The implementation MUST also verify that the Initiator's HIT in
	in the I2 corresponds to the Host Identity sent in the I2.		the I2 corresponds to the Host Identity sent in the I2.
	12. The system MUST verify the HMAC according to the procedures in		12. The system MUST verify the HMAC according to the procedures in
	Section 5.2.9.		Section 5.2.9.
	13. The system MUST verify the HIP_SIGNATURE according to		13. The system MUST verify the HIP_SIGNATURE according to
	Section 5.2.11 and Section 5.3.3.		Section 5.2.11 and Section 5.3.3.
	14. If the checks above are valid, then the system proceeds with		14. If the checks above are valid, then the system proceeds with
	further I2 processing; otherwise, it discards the I2 and remains		further I2 processing; otherwise, it discards the I2 and remains
	in the same state.		in the same state.
	skipping to change at page 85, line 5 ¶		skipping to change at page 87, line 25 ¶
	When a host receives a CLOSE_ACK message it verifies that it is in		When a host receives a CLOSE_ACK message it verifies that it is in
	CLOSING or CLOSED state and that the CLOSE_ACK was in response to the		CLOSING or CLOSED state and that the CLOSE_ACK was in response to the
	CLOSE (using the included ECHO_REPLY_SIGNED in response to the sent		CLOSE (using the included ECHO_REPLY_SIGNED in response to the sent
	ECHO_REQUEST_SIGNED).		ECHO_REQUEST_SIGNED).
	The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is		The CLOSE_ACK uses HMAC and SIGNATURE for verification. The state is
	discarded when the state changes to UNASSOCIATED and, after that, the		discarded when the state changes to UNASSOCIATED and, after that, the
	host MAY respond with an ICMP Parameter Problem to an incoming CLOSE		host MAY respond with an ICMP Parameter Problem to an incoming CLOSE
	message (See Section 5.4.4).		message (See Section 5.4.4).
	6.16. Dropping HIP Associations		6.16. Handling State Loss
	A HIP implementation is free to drop a HIP association at any time,		In the case of system crash and unanticipated state loss, the system
	based on its own policy. If a HIP host decides to drop a HIP		SHOULD delete the corresponding HIP state, including the keying
	association, it deletes the corresponding HIP state, including the		material. That is, the state SHOULD NOT be stored on stable storage.
	keying material. The implementation MUST also drop the peer's R1		If the implementation does drop the state (as RECOMMENDED), it MUST
	generation counter value, unless a local policy explicitly defines		also drop the peer's R1 generation counter value, unless a local
	that the value of that particular host is stored. An implementation		policy explicitly defines that the value of that particular host is
	MUST NOT store R1 generation counters by default, but storing R1		stored. An implementation MUST NOT store R1 generation counters by
	generation counter values, if done, MUST be configured by explicit		default, but storing R1 generation counter values, if done, MUST be
	HITs.		configured by explicit HITs.
	7. HIP Policies		7. HIP Policies
	There are a number of variables that will influence the HIP exchanges		There are a number of variables that will influence the HIP exchanges
	that each host must support. All HIP implementations MUST support		that each host must support. All HIP implementations MUST support
	more than one simultaneous HIs, at least one of which SHOULD be		more than one simultaneous HIs, at least one of which SHOULD be
	reserved for anonymous usage. Although anonymous HIs will be rarely		reserved for anonymous usage. Although anonymous HIs will be rarely
	used as Responder HIs, they will be common for Initiators. Support		used as Responder HIs, they will be common for Initiators. Support
	for more than two HIs is RECOMMENDED.		for more than two HIs is RECOMMENDED.
	skipping to change at page 87, line 14 ¶		skipping to change at page 89, line 14 ¶
	8. Security Considerations		8. Security Considerations
	HIP is designed to provide secure authentication of hosts. HIP also		HIP is designed to provide secure authentication of hosts. HIP also
	attempts to limit the exposure of the host to various denial-of-		attempts to limit the exposure of the host to various denial-of-
	service and man-in-the-middle (MitM) attacks. In so doing, HIP		service and man-in-the-middle (MitM) attacks. In so doing, HIP
	itself is subject to its own DoS and MitM attacks that potentially		itself is subject to its own DoS and MitM attacks that potentially
	could be more damaging to a host's ability to conduct business as		could be more damaging to a host's ability to conduct business as
	usual.		usual.
	The 384-bit Diffie-Hellman Group is targetted to be used in hosts		The 384-bit Diffie-Hellman Group is targeted to be used in hosts that
	that either do not require or that are not powerful enough for		either do not require or that are not powerful enough for handling
	handling strong cryptography. Although there is a risk that with		strong cryptography. Although there is a risk that with suitable
	suitable equipment the encryption can be broken in real time, the		equipment the encryption can be broken in real time, the 384-bit
	384-bit group can provide some protection for end-hosts that are not		group can provide some protection for end-hosts that are not able to
	able to handle any stronger cryptography. When the security provided		handle any stronger cryptography. When the security provided by the
	by the 384-bit group is not enough for applications on a host, the		384-bit group is not enough for applications on a host, the support
	support for this group should be turned off in the configuration.		for this group should be turned off in the configuration.
	Denial-of-service attacks often take advantage of the cost of start		Denial-of-service attacks often take advantage of the cost of start
	of state for a protocol on the Responder compared to the 'cheapness'		of state for a protocol on the Responder compared to the 'cheapness'
	on the Initiator. HIP makes no attempt to increase the cost of the		on the Initiator. HIP makes no attempt to increase the cost of the
	start of state on the Initiator, but makes an effort to reduce the		start of state on the Initiator, but makes an effort to reduce the
	cost to the Responder. This is done by having the Responder start		cost to the Responder. This is done by having the Responder start
	the 3-way exchange instead of the Initiator, making the HIP protocol		the 3-way exchange instead of the Initiator, making the HIP protocol
	4 packets long. In doing this, packet 2 becomes a 'stock' packet		4 packets long. In doing this, packet 2 becomes a 'stock' packet
	that the Responder MAY use many times, until some Initiator has		that the Responder MAY use many times, until some Initiator has
	provided a valid response to such and R1 packet. During an I1 storm		provided a valid response to such and R1 packet. During an I1 storm
	skipping to change at page 90, line 13 ¶		skipping to change at page 92, line 13 ¶
	for an R2 HIP packet, deleting state only after a natural timeout.		for an R2 HIP packet, deleting state only after a natural timeout.
	9. IANA Considerations		9. IANA Considerations
	IANA has reserved protocol number 253 to be used for experimental		IANA has reserved protocol number 253 to be used for experimental
	purposes (see [RFC3692]). In HIP, this value is used until a		purposes (see [RFC3692]). In HIP, this value is used until a
	permanent protocol number has been assigned by IANA.		permanent protocol number has been assigned by IANA.
	This document defines a new 128-bit value under the CGA Message Type		This document defines a new 128-bit value under the CGA Message Type
	namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be		namespace [RFC3972], 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA, to be
	used for HIT generation as specified in ORCHID		used for HIT generation as specified in ORCHID [RFC4843].
	[I-D.laganier-ipv6-khi].
	This document also creates a set of new name spaces. These are		This document also creates a set of new name spaces. These are
	described below.		described below.
	Packet Type		Packet Type
	The 7-bit Packet Type field in a HIP protocol packet describes the		The 7-bit Packet Type field in a HIP protocol packet describes the
	type of a HIP protocol message. It is defined in Section 5.1.		type of a HIP protocol message. It is defined in Section 5.1.
	The current values are defined in Section 5.3.1 through		The current values are defined in Section 5.3.1 through
	Section 5.3.8.		Section 5.3.8.
	skipping to change at page 92, line 32 ¶		skipping to change at page 94, line 32 ¶
	Kocher taught Bob Moskowitz how to make the puzzle exchange expensive		Kocher taught Bob Moskowitz how to make the puzzle exchange expensive
	for the Initiator to respond, but easy for the Responder to validate.		for the Initiator to respond, but easy for the Responder to validate.
	Bill Sommerfeld supplied the Birthday concept, which later evolved		Bill Sommerfeld supplied the Birthday concept, which later evolved
	into the R1 generation counter, to simplify reboot management. Erik		into the R1 generation counter, to simplify reboot management. Erik
	Nordmark supplied CLOSE-mechanism for closing connections. Rodney		Nordmark supplied CLOSE-mechanism for closing connections. Rodney
	Thayer and Hugh Daniels provide extensive feedback. In the early		Thayer and Hugh Daniels provide extensive feedback. In the early
	times of this document, John Gilmore kept Bob Moskowitz challenged to		times of this document, John Gilmore kept Bob Moskowitz challenged to
	provide something of value.		provide something of value.
	During the later stages of this document, when the editing baton was		During the later stages of this document, when the editing baton was
	transfered to Pekka Nikander, the input from the early implementors		transferred to Pekka Nikander, the input from the early implementors
	were invaluable. Without having actual implementations, this		were invaluable. Without having actual implementations, this
	document would not be on the level it is now.		document would not be on the level it is now.
	In the usual IETF fashion, a large number of people have contributed		In the usual IETF fashion, a large number of people have contributed
	to the actual text or ideas. The list of these people include Jeff		to the actual text or ideas. The list of these people include Jeff
	Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew		Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Andrew
	McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik		McGregor, Julien Laganier, Miika Komu, Mika Kousa, Jan Melen, Henrik
	Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka		Petander, Michael Richardson, Tim Shepard, Jorma Wall, and Jukka
	Ylitalo. Our apologies to anyone whose name is missing.		Ylitalo. Our apologies to anyone whose name is missing.
	skipping to change at page 94, line 12 ¶		skipping to change at page 96, line 12 ¶
	Algorithm and Its Use with IPsec", RFC 3602,		Algorithm and Its Use with IPsec", RFC 3602,
	September 2003.		September 2003.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
	[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the		[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
	Internet Key Exchange Version 2 (IKEv2)", RFC 4307,		Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
	December 2005.		December 2005.
	[I-D.laganier-ipv6-khi]		[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
	Nikander, P., "An IPv6 Prefix for Overlay Routable		for Overlay Routable Cryptographic Hash Identifiers
	Cryptographic Hash Identifiers (ORCHID)",		(ORCHID)", RFC 4843, April 2007.
	draft-laganier-ipv6-khi-05 (work in progress),
	September 2006.
	[I-D.ietf-radext-rfc2486bis]		[I-D.ietf-radext-rfc2486bis]
	Aboba, B., "The Network Access Identifier",		Aboba, B., "The Network Access Identifier",
	draft-ietf-radext-rfc2486bis-06 (work in progress),		draft-ietf-radext-rfc2486bis-06 (work in progress),
	July 2005.		July 2005.
	[I-D.ietf-hip-esp]		[I-D.ietf-hip-esp]
	Jokela, P., "Using ESP transport format with HIP",		Jokela, P., "Using ESP transport format with HIP",
	draft-ietf-hip-esp-04 (work in progress), October 2006.		draft-ietf-hip-esp-05 (work in progress), February 2007.
	[FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.		[FIPS95] NIST, "FIPS PUB 180-1: Secure Hash Standard", April 1995.
	11.2. Informative References		11.2. Informative References
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, September 1981.		RFC 792, September 1981.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	(IKE)", RFC 2409, November 1998.		(IKE)", RFC 2409, November 1998.
	skipping to change at page 95, line 4 ¶		skipping to change at page 96, line 51 ¶
	[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers		[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
	Considered Useful", BCP 82, RFC 3692, January 2004.		Considered Useful", BCP 82, RFC 3692, January 2004.
	[I-D.ietf-hip-arch]		[I-D.ietf-hip-arch]
	Moskowitz, R. and P. Nikander, "Host Identity Protocol		Moskowitz, R. and P. Nikander, "Host Identity Protocol
	Architecture", draft-ietf-hip-arch-03 (work in progress),		Architecture", draft-ietf-hip-arch-03 (work in progress),
	August 2005.		August 2005.
	[I-D.ietf-shim6-proto]		[I-D.ietf-shim6-proto]
	Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim		Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming
	protocol", draft-ietf-shim6-proto-07 (work in progress),		Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work
	December 2006.		in progress), April 2007.
	[I-D.henderson-hip-applications]		[I-D.henderson-hip-applications]
	Henderson, T. and P. Nikander, "Using HIP with Legacy		Henderson, T. and P. Nikander, "Using HIP with Legacy
	Applications", draft-henderson-hip-applications-03 (work		Applications", draft-henderson-hip-applications-03 (work
	in progress), May 2006.		in progress), May 2006.
	[I-D.ietf-hip-mm]		[I-D.ietf-hip-mm]
	Nikander, P., "End-Host Mobility and Multihoming with the		Henderson, T., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-04 (work in		Host Identity Protocol", draft-ietf-hip-mm-05 (work in
	progress), June 2006.		progress), March 2007.
	[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-08 (work in progress), October 2006.		draft-ietf-hip-dns-09 (work in progress), April 2007.
	[I-D.ietf-hip-rvs]		[I-D.ietf-hip-rvs]
	Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", draft-ietf-hip-rvs-05 (work in		Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
	progress), June 2006.		progress), June 2006.
	[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the		[AUR03] Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
	HIP Base Exchange Protocol", in Proceedings of 10th		HIP Base Exchange Protocol", in Proceedings of 10th
	Australasian Conference on Information Security and		Australasian Conference on Information Security and
	Privacy, July 2003.		Privacy, July 2003.
	skipping to change at page 104, line 7 ¶		skipping to change at page 106, line 7 ¶
	Thomas R. Henderson		Thomas R. 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
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	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, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE 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.
	Intellectual Property		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
End of changes. 64 change blocks.
	150 lines changed or deleted		259 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/