draft-ietf-hip-bone-04.txt		draft-ietf-hip-bone-05.txt
	HIP Working Group G. Camarillo		HIP Working Group G. Camarillo
	Internet-Draft P. Nikander		Internet-Draft P. Nikander
	Intended status: Experimental J. Hautakorpi		Intended status: Experimental J. Hautakorpi
	Expires: July 30, 2010 A. Keranen		Expires: September 9, 2010 A. Keranen
	Ericsson		Ericsson
	A. Johnston		A. Johnston
	Avaya		Avaya
	January 26, 2010		March 8, 2010
	HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking		HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking
	Environment		Environment
	draft-ietf-hip-bone-04.txt		draft-ietf-hip-bone-05.txt
	Abstract		Abstract
	This document specifies a framework to build HIP (Host Identity		This document specifies a framework to build HIP (Host Identity
	Protocol)-based overlay networks. This framework uses HIP to perform		Protocol)-based overlay networks. This framework uses HIP to perform
	connection management. Other functions, such as data storage and		connection management. Other functions, such as data storage and
	retrieval or overlay maintenance, are implemented using protocols		retrieval or overlay maintenance, are implemented using protocols
	other than HIP. These protocols are loosely referred to as peer		other than HIP. These protocols are loosely referred to as peer
	protocols.		protocols.
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	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 July 30, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 3		3. Background on HIP . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 3		3.1. ID/locator Split . . . . . . . . . . . . . . . . . . . . . 4
	3.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 4		3.1.1. Identifier Format . . . . . . . . . . . . . . . . . . 5
	3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 5		3.1.2. HIP Base Exchange . . . . . . . . . . . . . . . . . . 5
	3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 5		3.1.3. Locator Management . . . . . . . . . . . . . . . . . . 6
	3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6		3.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 6		3.3.1. DoS Protection . . . . . . . . . . . . . . . . . . . . 7
	3.3.2. Identifier Assignment and Authentication . . . . . . . 7		3.3.2. Identifier Assignment and Authentication . . . . . . . 7
	3.3.3. Connection Security . . . . . . . . . . . . . . . . . 8		3.3.3. Connection Security . . . . . . . . . . . . . . . . . 8
	3.4. HIP Deployability and Legacy Applications . . . . . . . . 8		3.4. HIP Deployability and Legacy Applications . . . . . . . . 8
	4. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 9		4. Framework Overview . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9		5. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 12
	4.2. Connection Establishment . . . . . . . . . . . . . . . . . 10		5.1. Node ID Assignment and Bootstrap . . . . . . . . . . . . . 13
	4.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11		5.2. Connection Establishment . . . . . . . . . . . . . . . . . 14
	4.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11		5.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 15
	5. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12		5.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 15
	6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 13		6. Overlay HIP Parameters . . . . . . . . . . . . . . . . . . . . 16
	6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 13		6.1. Overlay Identifier . . . . . . . . . . . . . . . . . . . . 16
	6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 14		6.2. Overlay TTL . . . . . . . . . . . . . . . . . . . . . . . 17
	7. Architectural Considerations . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . . 19
	11.2. Informative References . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The Host Identity Protocol (HIP) [RFC5201] defines a new name space		The Host Identity Protocol (HIP) [RFC5201] defines a new name space
	between the network and transport layers. HIP provides upper layers		between the network and transport layers. HIP provides upper layers
	with mobility, multihoming, NAT (Network Address Translation)		with mobility, multihoming, NAT (Network Address Translation)
	traversal, and security functionality. HIP implements the so called		traversal, and security functionality. HIP implements the so called
	identifier/locator (ID/locator) split, which implies that IP		identifier/locator (ID/locator) split, which implies that IP
	addresses are only used as locators, not as host identifiers. This		addresses are only used as locators, not as host identifiers. This
	split makes HIP a suitable protocol to build overlay networks that		split makes HIP a suitable protocol to build overlay networks that
	implement identifier-based overlay routing over IP networks, which in		implement identifier-based overlay routing over IP networks, which in
	turn implement locator-based routing.		turn implement locator-based routing.
			Using HIP BONE, as opposed to a peer protocol, to perform connection
			management in an overlay has a set of advantages. HIP BONE can be
			used by any peer protocol. This keeps each peer protocol from
			defining primitives needed for connection management (e.g.,
			primitives to establish connections and to tunnel messages through
			the overlay) and NAT traversal. Having this functionality at a lower
			layer allows multiple upper-layer protocols to take advantage of it.
			Additionally, having a solution that integrates mobility and
			multihoming is useful in many scenarios. Peer protocols do not
			typically specify mobility and multihoming solutions. Combining a
			peer protocol including NAT traversal with a separate mobility
			mechanism and a separate multihoming mechanism can easily lead to
			unexpected (and unpleasant) interactions.
	The remainder of this document is organized as follows. Section 3		The remainder of this document is organized as follows. Section 3
	provides background information on HIP. Section 4 describes the HIP		provides background information on HIP. Section 4 gives an overview
	BONE (HIP-Based Overlay Networking Environment) framework. Section 5		of the HIP BONE (HIP-Based Overlay Networking Environment) framework
	discusses some of the advantages derived from using the HIP BONE		and architecture and Section 5 describes the framework in more
	framework. Section 6 introduces new HIP parameters for overlay		detail. Finally, before the customary sections, Section 6 introduces
	usage. Finally, before the customary sections, Section 7 attempts to		new HIP parameters for overlay usage.
	put the presented proposal into a larger architectural context.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
			The following terms are used in context of HIP BONEs:
			Overlay network: A network built on top of another network. In case
			of HIP BONEs, the underlying network is an IP network and the
			overlay can be, e.g., a peer-to-peer (P2P) network.
			Peer protocol: A protocol used by nodes in an overlay network for
			performing, e.g., data storage and retrieval or overlay
			maintenance. HIP is used for conveying the peer protocol messages
			between the nodes in the overlay network.
			HIP BONE instance: A HIP-based overlay network that uses a
			particular peer protocol and is based on the framework presented
			in this document.
			Node ID: A value that uniquely identifies a node in an overlay
			network. The value is not usually human-friendly, but for example
			a hash of a public key.
			Valid locator: A Locator (as defined in [RFC5206]; usually an IP
			address or an address and a port number) that a host is known to
			be reachable at, for example, because there is an active HIP
			association with the host.
	3. Background on HIP		3. Background on HIP
	This section provides background on HIP. Given the tutorial nature		This section provides background on HIP. Given the tutorial nature
	of this section, readers that are familiar with what HIP provides and		of this section, readers that are familiar with what HIP provides and
	how HIP works may want to skip it. All descriptions contain		how HIP works may want to skip it. All descriptions contain
	references to the relevant HIP specifications where readers can find		references to the relevant HIP specifications where readers can find
	detailed explanations on the different topics discussed in this		detailed explanations on the different topics discussed in this
	section.		section.
	3.1. ID/locator Split		3.1. ID/locator Split
	skipping to change at page 5, line 25		skipping to change at page 6, line 16
	| I1 |		| I1 |
	| -------------------------->|		| -------------------------->|
	| R1 |		| R1 |
	| <--------------------------|		| <--------------------------|
	| I2 |		| I2 |
	| -------------------------->|		| -------------------------->|
	| R2 |		| R2 |
	| <--------------------------|		| <--------------------------|
	Figure 2: HIP base exchange		Figure 2: HIP Base Exchange
	Of course, the initiator needs the responder's locator (or locators)		Of course, the initiator needs the responder's locator (or locators)
	in order to send its I1 packet. The initiator can obtain locators		in order to send its I1 packet. The initiator can obtain locators
	for the responder in multiple ways. For example, according to the		for the responder in multiple ways. For example, according to the
	current HIP specifications the initiator can get the locators		current HIP specifications the initiator can get the locators
	directly from the DNS [RFC5205] or indirectly by sending packets		directly from the DNS [RFC5205] or indirectly by sending packets
	through a HIP rendezvous server [RFC5204]. However, as an		through a HIP rendezvous server [RFC5204]. However, as an
	architecture HIP is open ended, and allows the locators to be		architecture HIP is open ended, and allows the locators to be
	obtained by any means (e.g., from packets traversing an overlay		obtained by any means (e.g., from packets traversing an overlay
	network or as part of the candidate address collection process in a		network or as part of the candidate address collection process in a
	skipping to change at page 7, line 41		skipping to change at page 8, line 26
	given a fixed public key K1, finding a different public key K2 such		given a fixed public key K1, finding a different public key K2 such
	that hash(K1) = hash(K2) is computationally very hard. Optimally, a		that hash(K1) = hash(K2) is computationally very hard. Optimally, a
	preimage attack on the 100-bit hash function used in ORCHIDs will		preimage attack on the 100-bit hash function used in ORCHIDs will
	take an order of 2^100 operations to be successful, and can be		take an order of 2^100 operations to be successful, and can be
	expected to take in the average 2^99 operations. Given that each		expected to take in the average 2^99 operations. Given that each
	operation requires the attacker to generate a new key pair, the		operation requires the attacker to generate a new key pair, the
	attack is completely impractical (see [RFC4843]).		attack is completely impractical (see [RFC4843]).
	HIP nodes using HITs as ORCHIDs do not typically use certificates		HIP nodes using HITs as ORCHIDs do not typically use certificates
	during their base exchanges. Instead, the use a leap-of-faith		during their base exchanges. Instead, the use a leap-of-faith
	mechanism, similar to SSH, whereby a node authenticates somehow		mechanism, similar to the Secure Shell (SSH) protocol [RFC4251],
	remote nodes the first time they connect it and, then, remembers		whereby a node authenticates somehow remote nodes the first time they
	their public keys. While user-assisted leap-of-faith (such as in		connect it and, then, remembers their public keys. While user-
	SSH) can be used to facilitate a human-operated offline path (such as		assisted leap-of-faith (such as in SSH) can be used to facilitate a
	a telephone call), automated leap-of-faith can be combined with a		human-operated offline path (such as a telephone call), automated
	reputation management system to create an incentive to behave.		leap-of-faith can be combined with a reputation management system to
	However, such considerations go well beyond the current HIP		create an incentive to behave. However, such considerations go well
	architecture and even beyond this proposal. For the purposes of the		beyond the current HIP architecture and even beyond this proposal.
	present document, we merely want to point out that architecturally		For the purposes of the present document, we merely want to point out
	HIP supports both self-generated opportunistic identifiers and		that architecturally HIP supports both self-generated opportunistic
	administratively assigned ones.		identifiers and administratively assigned ones.
	3.3.3. Connection Security		3.3.3. Connection Security
	Once two nodes complete a base exchange between them, the traffic		Once two nodes complete a base exchange between them, the traffic
	they exchange is encrypted and integrity protected. The security		they exchange is encrypted and integrity protected. The security
	mechanism used to protect the traffic is IPsec ESP [RFC5202].		mechanism used to protect the traffic is IPsec Encapsulating Security
	However, there is ongoing work to specify how to use different		Payload (ESP) [RFC5202]. However, there is ongoing work to specify
	protection mechanisms.		how to use different protection mechanisms.
	3.4. HIP Deployability and Legacy Applications		3.4. HIP Deployability and Legacy Applications
	As discussed earlier, HIP defines a native socket API		As discussed earlier, HIP defines a native socket API
	[I-D.ietf-hip-native-api] that applications can use to establish and		[I-D.ietf-hip-native-api] that applications can use to establish and
	manage connections. New applications can implement this API to get		manage connections. New applications can implement this API to get
	full advantage of HIP. However, in most cases, legacy (i.e., non-HIP		full advantage of HIP. However, in most cases, legacy (i.e., non-HIP
	aware) applications [RFC5338] can use HIP through the traditional		aware) applications [RFC5338] can use HIP through the traditional
	IPv4 and IPv6 socket APIs.		IPv4 and IPv6 socket APIs.
	skipping to change at page 8, line 36		skipping to change at page 9, line 21
	the remote host's IP address internally at the HIP module. Since the		the remote host's IP address internally at the HIP module. Since the
	ORCHID looks like an IPv6 address, the legacy application treats it		ORCHID looks like an IPv6 address, the legacy application treats it
	as such. It opens a connection (e.g., TCP) using the traditional		as such. It opens a connection (e.g., TCP) using the traditional
	IPv6 socket API. The HIP module running in the same host as the		IPv6 socket API. The HIP module running in the same host as the
	legacy application intercepts this call somehow (e.g., using an		legacy application intercepts this call somehow (e.g., using an
	interception library or setting up the host's routing tables so that		interception library or setting up the host's routing tables so that
	the HIP module receives the traffic) and runs HIP (on behalf of the		the HIP module receives the traffic) and runs HIP (on behalf of the
	legacy application) towards the IP address corresponding to the		legacy application) towards the IP address corresponding to the
	ORCHID. This mechanism works well in almost all cases. However,		ORCHID. This mechanism works well in almost all cases. However,
	applications involving referrals (i.e., passing of IPv6 addresses		applications involving referrals (i.e., passing of IPv6 addresses
	between applications) present issues, to be discussed in Section 4		between applications) present issues, to be discussed in Section 5
	below. Additionally, management applications that care about the		below. Additionally, management applications that care about the
	exact IP address format may not work well with such straightforward		exact IP address format may not work well with such straightforward
	approach.		approach.
	In order to make HIP work through the traditional IPv4 socket API,		In order to make HIP work through the traditional IPv4 socket API,
	the HIP module passes an LSI (Local Scope Identifier), instead of a		the HIP module passes an LSI (Local Scope Identifier), instead of a
	regular IPv4 address, to the legacy IPv4 application. The LSI looks		regular IPv4 address, to the legacy IPv4 application. The LSI looks
	like an IPv4 address, but is locally bound to an ORCHID. That is,		like an IPv4 address, but is locally bound to an ORCHID. That is,
	when the legacy application uses the LSI in a socket call, the HIP		when the legacy application uses the LSI in a socket call, the HIP
	module intercepts it and replaces the LSI with its corresponding		module intercepts it and replaces the LSI with its corresponding
	ORCHID. Therefore, LSIs always have local scope. They do not have		ORCHID. Therefore, LSIs always have local scope. They do not have
	any meaning outside the host running the application. The ORCHID is		any meaning outside the host running the application. The ORCHID is
	used on the wire; not the LSI. In the referral case, if it is not		used on the wire; not the LSI. In the referral case, if it is not
	possible to rewrite the application level packets to use ORCHIDs		possible to rewrite the application level packets to use ORCHIDs
	instead of LSIs, it may be hard to make IPv4 referrals work in		instead of LSIs, it may be hard to make IPv4 referrals work in
	Internet-wide settings. IPv4 LSIs have been successfully used in		Internet-wide settings. IPv4 LSIs have been successfully used in
	existing HIP deployments within a single corporate network.		existing HIP deployments within a single corporate network.
	4. The HIP BONE Framework		4. Framework Overview
	An overlay typically requires three types of operations:		The HIP BONE framework combines HIP with different peer protocols to
			provide robust and secure overlay network solutions.
			Many overlays typically require three types of operations:
	o overlay maintenance.		o overlay maintenance.
	o data storage and retrieval.		o data storage and retrieval.
	o connection management.		o connection management.
	Overlay maintenance operations deal with nodes joining and leaving		Overlay maintenance operations deal with nodes joining and leaving
	the overlay and with the maintenance of the overlay's routing tables.		the overlay and with the maintenance of the overlay's routing tables.
	Data storage and retrieval operations deal with nodes storing,		Data storage and retrieval operations deal with nodes storing,
	retrieving, and removing information in or from the overlay.		retrieving, and removing information in or from the overlay.
	Connection management operations deal with the establishment of		Connection management operations deal with the establishment of
	connections and the exchange of lightweight messages among the nodes		connections and the exchange of lightweight messages among the nodes
	of the overlay, potentially in the presence of NATs.		of the overlay, potentially in the presence of NATs.
	skipping to change at page 9, line 27		skipping to change at page 10, line 20
	retrieving, and removing information in or from the overlay.		retrieving, and removing information in or from the overlay.
	Connection management operations deal with the establishment of		Connection management operations deal with the establishment of
	connections and the exchange of lightweight messages among the nodes		connections and the exchange of lightweight messages among the nodes
	of the overlay, potentially in the presence of NATs.		of the overlay, potentially in the presence of NATs.
	The HIP BONE framework uses HIP to perform connection management.		The HIP BONE framework uses HIP to perform connection management.
	Data storage and retrieval and overlay maintenance are to be		Data storage and retrieval and overlay maintenance are to be
	implemented using protocols other than HIP. For lack of a better		implemented using protocols other than HIP. For lack of a better
	name, these protocols are referred to as peer protocols.		name, these protocols are referred to as peer protocols.
			One way to depict the relationship between the peer protocol and HIP
			modules is shown in Figure 3. The peer protocol module implements
			the overlay construction and maintenance features, and possibly
			storage (if the particular protocol supports such a feature). The
			HIP module consults the peer protocol's overlay topology part for
			making routing decisions and the peer protocol uses HIP for
			connection management and sending peer protocol messages to other
			hosts. The HIP BONE API that applications use is a combination of
			the HIP Native API and traditional socket API (as shown in Figure 1)
			with any additional API a particular instance implementation
			provides.
			Application
			-------------------------------- HIP BONE API
			+---+ +--------------------+
			| | | Peer Protocol |
			| | +--------+ +---------+
			| |<->|Topology| |(Storage)|
			| | +---------+----------+
			| | ^
			| | v
			| +------------------------+
			| HIP |
			+----------------------------+
			Figure 3: HIP with Peer Protocol
			Architecturally, HIP can be considered to create a new thin "waist"
			layer on top of the IPv4 and IPv6 networks; see Figure 4. The HIP
			layer itself consists of the HIP signaling protocol and one or more
			data transport protocols; see Figure 5. The HIP signaling packets
			and the data transport packets can take different routes. In the HIP
			BONE, the HIP signaling packets are typically first routed through
			the overlay and then directly (if possible), while the data transport
			packets are typically routed only directly between the end points.
			+--------------------------------------+
			| Transport (using HITs or LSIs) |
			+--------------------------------------+
			| HIP |
			+------------------+-------------------+
			| IPv4 | IPv6 |
			+------------------+-------------------+
			Figure 4: HIP as a Thin Waist
			+------------------+-------------------+
			| HIP signaling | data transports |
			+------------------+-------------------+
			Figure 5: HIP Layer Structure
			In HIP BONE, the peer protocol creates a new signaling layer on top
			of HIP. It is used to set up forwarding paths for HIP signaling
			messages. This is a similar relationship that an IP routing
			protocol, such as OSPF, has to the IP protocol itself. In the HIP
			BONE case, the peer protocol plays a role similar to OSPF, and HIP
			plays a role similar to IP. The ORCHIDs (or, in general, Node IDs if
			the ORCHID prefix is not used) are used for forwarding HIP packets
			according to the information in the routing tables. The peer
			protocols are used to exchange routing information based on Node IDs
			and to construct the routing tables.
			Architecturally, routing tables are located between the peer protocol
			and HIP, as shown in Figure 6. The peer protocol constructs the
			routing table and keeps it updated. The HIP layer accesses the
			routing table in order to make routing decisions. The bootstrap of a
			HIP BONE overlay does not create circular dependencies between the
			peer protocol (which needs to use HIP to establish connections with
			other nodes) and HIP (which needs the peer protocol to know how to
			route messages to other nodes) for the same reasons as the bootstrap
			of an IP network does not create circular dependencies between OSPF
			and IP. The first connections established by the peer protocol are
			with nodes whose locators are known. HIP establishes those
			connections as any connection between two HIP nodes where no overlays
			are present. That is, there is no need for the overlay to provide a
			rendezvous service for those connections.
			+--------------------------------------+
			| Peer protocol |
			+--------------------------------------+
			| Routing table |
			+--------------------------------------+
			| HIP |
			+--------------------------------------+
			Figure 6: Routing Tables
			It is possible that different overlays use different routing table
			formats. For example, the structure of the routing tables of two
			overlays based on different DHTs (Distributed Hash Tables) may be
			very different. In order to make routing decisions, the HIP layer
			needs to convert the routing table generated by the peer protocol
			into a forwarding table that allows the HIP layer select a next-hop
			for any packet being routed.
			In HIP BONE, the HIP usage of public keys and deriving ORCHIDs
			through a hash function can be utilized at the peer protocol side to
			better secure routing table maintenance and to protect against
			chosen-peer-ID attacks.
			The HIP BONE provides quite a lot of flexibility with regards to how
			to arrange the different protocols in detail. Figure 7 shows one
			potential stack structure.
			+-----------------------+--------------+
			| peer protocols | media |
			+------------------+----+--------------+
			| HIP signaling | data transport |
			| |
			+------------------+-------------------+
			| NAT | non-NAT | |
			| | |
			| IPv4 | IPv6 |
			+------------------+-------------------+
			Figure 7: Example HIP BONE Stack Structure
			5. The HIP BONE Framework
	HIP BONE is a generic framework that allows the use of different peer		HIP BONE is a generic framework that allows the use of different peer
	protocols. A particular HIP BONE instance uses a particular peer		protocols. A particular HIP BONE instance uses a particular peer
	protocol. The details on how to implement a HIP BONE using a given		protocol. The details on how to implement a HIP BONE using a given
	peer protocol need to be specified in a, so called, HIP BONE instance		peer protocol need to be specified in a, so called, HIP BONE instance
	specification. Section 4.4 discusses what details need to be		specification. Section 5.4 discusses what details need to be
	specified by HIP BONE instance specifications. For example, the HIP		specified by HIP BONE instance specifications. For example, the HIP
	BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is		BONE instance specification for RELOAD [I-D.ietf-p2psip-base] is
	specified in [I-D.ietf-hip-reload-instance].		specified in [I-D.ietf-hip-reload-instance].
	4.1. Peer ID Assignment and Bootstrap		5.1. Node ID Assignment and Bootstrap
	Nodes in an overlay are primarily identified by their Peer IDs.		Nodes in an overlay are primarily identified by their Node IDs.
	Overlays typically have an enrollment server that can generate Peer		Overlays typically have an enrollment server that can generate Node
	IDs, or at least some part of the Peer ID, and sign certificates. A		IDs, or at least some part of the Node ID, and sign certificates. A
	certificate generated by an enrollment server authorizes a particular		certificate generated by an enrollment server authorizes a particular
	user to use a particular Peer ID in a particular overlay. The way		user to use a particular Node ID in a particular overlay. The way
	users and overlays are identified are defined by the peer protocol		users and overlays are identified are defined by the peer protocol
	and HIP BONE instance specification.		and HIP BONE instance specification.
	The enrollment server of an overlay that were to use HITs derived		The enrollment server of an overlay that were to use HITs derived
	from public keys as Peer IDs could just authorize users to use the		from public keys as Node IDs could just authorize users to use the
	public keys and HITs associated to their nodes. Such a Peer ID has		public keys and HITs associated to their nodes. Such a Node ID has
	the same self-certifying property as HITs and the Peer ID can also be		the same self-certifying property as HITs and the Node ID can also be
	used in the HIP and legacy APIs as an ORCHID. This works well as		used in the HIP and legacy APIs as an ORCHID. This works well as
	long as the enrollment server is the one generating the public/		long as the enrollment server is the one generating the public/
	private key pairs for all those nodes. If the enrollment server		private key pairs for all those nodes. If the enrollment server
	authorizes users to use HITs that are generated directly by the nodes		authorizes users to use HITs that are generated directly by the nodes
	themselves, the system is open to a type of chosen-peer-ID attack.		themselves, the system is open to a type of chosen-peer-ID attack.
	If the overlay network or peer protocol has more specific		If the overlay network or peer protocol has more specific
	requirements for the Peer ID value that prevent using HITs derived		requirements for the Node ID value that prevent using HITs derived
	from public keys, each host will need a certificate (e.g., in their		from public keys, each host will need a certificate (e.g., in their
	HIP base exchanges) provided by the enrollment server to prove that		HIP base exchanges) provided by the enrollment server to prove that
	they are authorized to use a particular identifier in the overlay.		they are authorized to use a particular identifier in the overlay.
	Depending on how the certificates are constructed, they typically		Depending on how the certificates are constructed, they typically
	also need to contain the host's self-generated public key. Depending		also need to contain the host's self-generated public key. Depending
	on how the Peer IDs and public keys are attributed, different		on how the Node IDs and public keys are attributed, different
	scenarios become possible. For example, the Peer IDs may be		scenarios become possible. For example, the Node IDs may be
	attributed to users, there may be user public key identifiers, and		attributed to users, there may be user public key identifiers, and
	there may be separate host public key identifiers. Authorization		there may be separate host public key identifiers. Authorization
	certificates can be used to bind the different types of identifiers		certificates can be used to bind the different types of identifiers
	together.		together.
	HITs, as defined in [RFC5201], always start with the ORCHID prefix,		HITs, as defined in [RFC5201], always start with the ORCHID prefix.
	so there are 100 bits left in the HIT for different Peer ID values.		Therefore, there are 100 bits left in the HIT for different Node ID
	If an overlay network requires larger address space, it is also		values. If an overlay network requires larger address space, it is
	possible to use all the 128 bits of a HIT for addressing peer layer		also possible to use all the 128 bits of a HIT for addressing peer
	identifiers. The benefit of using ORCHID prefix for Peer IDs is that		layer identifiers. The benefit of using ORCHID prefix for Node IDs
	it makes possible to use them with legacy socket APIs, but in this		is that it makes possible to use them with legacy socket APIs, but in
	context most of the applications are assumed to be HIP aware and able		this context most of the applications are assumed to be HIP aware and
	to use a more advanced API supporting full 128-bit identifiers. Even		able to use a more advanced API supporting full 128-bit identifiers.
	larger address spaces could be supported with additional HIP		Even larger address spaces could be supported with an additional HIP
	parameter giving the source and destination Peer IDs, but defining		parameter giving the source and destination Node IDs, but defining
	such a parameter, if needed, is left for future documents.		such a parameter, if needed, is left for future documents.
	Bootstrap issues such as how to locate an enrollment or a bootstrap		Bootstrap issues such as how to locate an enrollment or a bootstrap
	server belong to the peer protocol.		server belong to the peer protocol.
	4.2. Connection Establishment		5.2. Connection Establishment
	Nodes in an overlay need to establish connection with other nodes in		Nodes in an overlay need to establish connection with other nodes in
	different cases. For example, a node typically has connections to		different cases. For example, a node typically has connections to
	the nodes in its forwarding table. Nodes also need to establish		the nodes in its forwarding table. Nodes also need to establish
	connections with other nodes in order to exchange application-layer		connections with other nodes in order to exchange application-layer
	messages.		messages.
	As discussed earlier, HIP uses the base exchange to establish		As discussed earlier, HIP uses the base exchange to establish
	connections. A HIP endpoint (the initiator) initiates a HIP base		connections. A HIP endpoint (the initiator) initiates a HIP base
	exchange with a remote endpoint by sending an I1 packet. The		exchange with a remote endpoint by sending an I1 packet. The
	skipping to change at page 11, line 30		skipping to change at page 15, line 5
	by a HIP rendezvous server.		by a HIP rendezvous server.
	Since HIP supports NAT traversal, a HIP base exchange over the		Since HIP supports NAT traversal, a HIP base exchange over the
	overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer		overlay will perform an ICE [I-D.ietf-mmusic-ice] offer/answer
	exchange between the nodes that are establishing the connection. In		exchange between the nodes that are establishing the connection. In
	order to perform this exchange, the nodes need to first gather		order to perform this exchange, the nodes need to first gather
	candidate addresses. Which nodes can be used to obtain reflexive		candidate addresses. Which nodes can be used to obtain reflexive
	address candidates and which ones can be used to obtain relayed		address candidates and which ones can be used to obtain relayed
	candidates is defined by the peer protocol.		candidates is defined by the peer protocol.
	4.3. Lightweight Message Exchanges		5.3. Lightweight Message Exchanges
	In some cases, nodes need to perform a lightweight query to another		In some cases, nodes need to perform a lightweight query to another
	node (e.g., a request followed by a single response). In this		node (e.g., a request followed by a single response). In this
	situation, establishing a connection using the mechanisms in		situation, establishing a connection using the mechanisms in
	Section 4.2 for a simple query would be an overkill. A better		Section 5.2 for a simple query would be an overkill. A better
	solution is to forward a HIP message through the overlay with the		solution is to forward a HIP message through the overlay with the
	query and another one with the response to the query. The payload of		query and another one with the response to the query. The payload of
	such HIP packets is integrity protected [I-D.ietf-hip-hiccups].		such HIP packets is integrity protected [I-D.ietf-hip-hiccups].
	Nodes in the overlay forward this HIP packet in a hop-by-hop fashion		Nodes in the overlay forward this HIP packet in a hop-by-hop fashion
	according to the overlay's routing table towards its destination,		according to the overlay's routing table towards its destination,
	typically through the protected connections established between them.		typically through the protected connections established between them.
	Again, the overlay acts as a rendezvous server between the nodes		Again, the overlay acts as a rendezvous server between the nodes
	exchanging the messages.		exchanging the messages.
	4.4. HIP BONE Instantiation		5.4. HIP BONE Instantiation
	As discussed in Section 4, HIP BONE is a generic framework that		As discussed in Section 5, HIP BONE is a generic framework that
	allows using different peer protocols. A particular HIP BONE		allows using different peer protocols. A particular HIP BONE
	instance uses a particular peer protocol. The details on how to		instance uses a particular peer protocol. The details on how to
	implement a HIP BONE using a given peer protocol need to be specified		implement a HIP BONE using a given peer protocol need to be specified
	in a, so called, HIP BONE instance specification. A HIP BONE		in a, so called, HIP BONE instance specification. A HIP BONE
	instance specification needs to define, minimally:		instance specification needs to define, minimally:
	o the peer protocol to be used.		o the peer protocol to be used.
	o what kind of Peer IDs are used and how they are derived.		o what kind of Node IDs are used and how they are derived.
	o which peer protocol primitives trigger HIP messages.		o which peer protocol primitives trigger HIP messages.
	o how the overlay identifier is generated.		o how the overlay identifier is generated.
	Additionally, a HIP BONE instance specification may need to specify		Additionally, a HIP BONE instance specification may need to specify
	other details that are specific to the peer protocol used.		other details that are specific to the peer protocol used.
	As an example, the HIP BONE instance specification for RELOAD		As an example, the HIP BONE instance specification for RELOAD
	[I-D.ietf-p2psip-base] is specified in		[I-D.ietf-p2psip-base] is specified in
	[I-D.ietf-hip-reload-instance].		[I-D.ietf-hip-reload-instance].
	It is assumed that areas not covered by a particular HIP BONE		It is assumed that areas not covered by a particular HIP BONE
	instance specification are specified by the peer protocol or		instance specification are specified by the peer protocol or
	elsewhere. These areas include:		elsewhere. These areas include:
	o the algorithm to create the overlay (e.g., a DHT).		o the algorithm to create the overlay (e.g., a DHT).
	o overlay maintenance functions.		o overlay maintenance functions.
	o data storage and retrieval functions.		o data storage and retrieval functions.
	o the process for obtaining a peer ID.		o the process for obtaining a Node ID.
	o bootstrap function		o bootstrap function.
	o how to select STUN and TURN servers for the candidate address		o how to select STUN and TURN servers for the candidate address
	collection process in NAT traversal scenarios.		collection process in NAT traversal scenarios.
	Note that the border between HIP BONE instance specification and a		Note that the border between HIP BONE instance specification and a
	peer protocol specifications is blurry. Depending on how generic the		peer protocol specifications is blurry. Depending on how generic the
	specification of a given peer protocol is, its associated HIP BONE		specification of a given peer protocol is, its associated HIP BONE
	instance specification may need to specify more or less details.		instance specification may need to specify more or less details.
	Also, a HIP BONE instance specification may leave certain areas		Also, a HIP BONE instance specification may leave certain areas
	unspecified in order to leave their configuration up to each		unspecified in order to leave their configuration up to each
	particular overlay.		particular overlay.
	5. Advantages of Using HIP BONE
	Using HIP BONE, as opposed to a peer protocol, to perform connection
	management in an overlay has a set of advantages. HIP BONE can be
	used by any peer protocol. This keeps each peer protocol from
	defining primitives needed for connection management (e.g.,
	primitives to establish connections and to tunnel messages through
	the overlay) and NAT traversal. Having this functionality at a lower
	layer allows multiple upper-layer protocols to take advantage of it.
	Additionally, having a solution that integrates mobility and
	multihoming is useful in many scenarios. Peer protocols do not
	typically specify mobility and multihoming solutions. Combining a
	peer protocol including NAT traversal with a separate mobility
	mechanism and a separate multihoming mechanism can easily lead to
	unexpected (and unpleasant) interactions.
	6. Overlay HIP Parameters		6. Overlay HIP Parameters
	This section defines generic format and protocol behavior for the		This section defines generic format and protocol behavior for the
	Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that		Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that
	can be used in HIP based overlay networks. HIP BONE instance		can be used in HIP based overlay networks. HIP BONE instance
	specifications define the exact format and content of the Overlay		specifications define the exact format and content of the Overlay
	Identifier parameter, the cases when the Overlay TTL parameter should		Identifier parameter, the cases when the Overlay TTL parameter should
	be used, and any additional behavior for each packet.		be used, and any additional behavior for each packet.
	6.1. Overlay Identifier		6.1. Overlay Identifier
	It is possible for a HIP host to participate simultaneously in		It is possible for a HIP host to participate simultaneously in
	multiple different overlay networks. Therefore, a host needs to know		multiple different overlay networks. Therefore, a host needs to know
	to which overlay an incoming HIP message belongs to. Thus, all HIP		to which overlay an incoming HIP message belongs to. Thus, all HIP
	messages that are sent via an overlay, or as a part of operations		messages that are sent via an overlay, or as a part of operations
	specific to a certain overlay, MUST contain an OVERLAY_ID parameter		specific to a certain overlay, MUST contain an OVERLAY_ID parameter
	with the identifier of the corresponding overlay network. Instance		with the identifier of the corresponding overlay network. Instance
	specifications define how the identifier is generated for different		specifications define how the identifier is generated for different
	types of overlay networks. The generation mechanism SHOULD be such		types of overlay networks. The generation mechanism MUST be such
	that it is unlikely to generate the same identifier for two different		that it is unlikely to generate the same identifier for two different
	overlay instances and hence it is RECOMMENDED that the identifier		overlay instances and hence it is RECOMMENDED that the identifier
	contains at least 32 bits of randomness.		contains at least 32 bits of randomness.
	The generic format of the OVERLAY_ID parameter is shown in Figure 3.		The generic format of the OVERLAY_ID parameter is shown in Figure 8.
	Instance specifications define valid length for the parameter and how		Instance specifications define valid length for the parameter and how
	the identifier values are generated.		the identifier values are generated.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier /		| Identifier /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ | Padding |		/ | Padding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type [ TBD by IANA; 980 ]		Type [ TBD by IANA; 980 ]
	Length Length of the Identifier in octets		Length Length of the Identifier in octets
	Identifier The identifier value		Identifier The identifier value
	Padding 0-7 bytes of padding if needed		Padding 0-7 bytes of padding if needed
	Figure 3: Format of the OVERLAY_ID parameter		Figure 8: Format of the OVERLAY_ID Parameter
	6.2. Overlay TTL		6.2. Overlay TTL
	HIP packets sent in an overlay network MAY contain an Overlay Time-		HIP packets sent in an overlay network MAY contain an Overlay Time-
	to-live (OVERLAY_TTL) parameter whose TTL value is decremented on		to-live (OVERLAY_TTL) parameter whose TTL value is decremented on
	each overlay network hop. When a HIP host receives a HIP packet with		each overlay network hop. When a HIP host receives a HIP packet with
	an OVERLAY_TTL parameter, and the host is not the final recipient of		an OVERLAY_TTL parameter, and the host is not the final recipient of
	the packet, it MUST decrement the TTL value in the parameter by one		the packet, it MUST decrement the TTL value in the parameter by one
	before forwarding the packet.		before forwarding the packet.
	If the TTL value in a received HIP packet is zero, and the receiving		If the TTL value in a received HIP packet is zero, and the receiving
	host is not the final recipient, the packet MUST be dropped and the		host is not the final recipient, the packet MUST be dropped and the
	host SHOULD send HIP Notify packet with type OVERLAY_TTL_EXCEEDED		host SHOULD send HIP Notify packet with type OVERLAY_TTL_EXCEEDED
	(value [TBD by IANA; 70]) to the sender of the original HIP packet.		(value [TBD by IANA; 70]) to the sender of the original HIP packet.
	The Notification Data field for the OVERLAY_TTL_EXCEEDED		The Notification Data field for the OVERLAY_TTL_EXCEEDED
	notifications SHOULD contain the HIP header and the TRANSACTION_ID		notifications SHOULD contain the HIP header and the TRANSACTION_ID
	parameter (if one exists) of the packet whose TTL exceeded.		[I-D.ietf-hip-hiccups] parameter (if one exists) of the packet whose
			TTL exceeded.
	Figure 4 shows the format of the OVERLAY_TTL. The TTL value is given		Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL
	as the number of overlay hops this packet has left and it is encoded		value is given as the number of overlay hops this packet has left and
	as unsigned integer.		it is encoded as an unsigned integer.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TTL | Reserved |		| TTL | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type [ TBD by IANA; 64010 ]		Type [ TBD by IANA; 64011 ]
	Length 4		Length 4
	TTL The Time-to-live value		TTL The Time-to-live value
	Reserved Reserved for future use		Reserved Reserved for future use
	Figure 4: Format of the OVERLAY_TTL parameter		Figure 9: Format of the OVERLAY_TTL Parameter
	7. Architectural Considerations
	Architecturally, HIP can be considered to create a new thin "waist"
	layer on the top of the IPv4 and IPv6 networks; see Figure 5. The
	HIP layer itself consists of the HIP signaling protocol and one or
	more data transport protocols; see Figure 6. The HIP signaling
	packets and the data transport packets can take different routes. In
	the HIP BONE, the HIP signaling packets are typically first routed
	through the overlay and then directly (if possible), while the data
	transport packets are typically routed only directly between the end
	points.
	+--------------------------------------+
	| Transport (using HITs or LSIs) |
	+--------------------------------------+
	| HIP |
	+------------------+-------------------+
	| IPv4 | IPv6 |
	+------------------+-------------------+
	Figure 5: HIP as a thin waist
	+------------------+-------------------+
	| HIP signaling | data transports |
	+------------------+-------------------+
	Figure 6: HIP layer structure
	In HIP BONE, the peer protocol creates a new signaling layer on the
	top of HIP. It is used to set up forwarding paths for HIP signaling
	messages. This is a similar relationship that an IP routing
	protocol, such as OSPF, has to the IP protocol itself. In the HIP
	BONE case, the peer protocol plays a role similar to OSPF, and HIP
	plays a role similar to IP. The ORCHIDs (or, in general, Peer IDs if
	the ORCHID prefix is not used) are used for forwarding HIP packets
	according to the information in the routing tables. The peer
	protocols are used to exchange routing information based on Peer IDs
	and to construct the routing tables.
	Architecturally, routing tables are located between the peer protocol
	and HIP, as shown in Figure 7. The peer protocol constructs the
	routing table and keeps it updated. The HIP layer accesses the
	routing table in order to make routing decisions. The bootstrap of a
	HIP BONE overlay does not create circular dependencies between the
	peer protocol (which needs to use HIP to establish connections with
	other nodes) and HIP (which needs the peer protocol to know how to
	route messages to other nodes) for the same reasons as the bootstrap
	of an IP network does not create circular dependencies between OSPF
	and IP. The first connections established by the peer protocol are
	with nodes whose locators are known. HIP establishes those
	connections as any connection between two HIP nodes where no overlays
	are present. That is, there is no need for the overlay to provide a
	rendezvous service for those connections.
	+--------------------------------------+
	| Peer protocol |
	+--------------------------------------+
	| Routing table |
	+--------------------------------------+
	| HIP |
	+--------------------------------------+
	Figure 7: Routing tables
	It is possible that different overlays use different routing table
	formats. For example, the structure of the routing tables of two
	overlays based on different DHTs (Distributed Hash Tables) may be
	very different. In order to make routing decisions, the HIP layer
	needs to convert the routing table generated by the peer protocol
	into a forwarding table that allows the HIP layer select a next-hop
	for any packet being routed.
	In HIP BONE, the HIP usage of public keys and deriving ORCHIDs
	through a hash function can be utilized at the peer protocol side to
	better secure routing table maintenance and to protect against
	chosen-peer-ID attacks.
	The HIP BONE provides quite a lot of flexibility with regards to how
	to arrange the different protocols in detail. Figure 8 shows one
	potential stack structure.
	+-----------------------+--------------+
	| peer protocols | media |
	+------------------+----+--------------+
	| HIP signaling | data transport |
	| |
	+------------------+-------------------+
	| NAT | non-NAT | |
	| | |
	| IPv4 | IPv6 |
	+------------------+-------------------+
	Figure 8: Example HIP BONE stack structure		The type of the OVERLAY_TTL parameter is critical (as defined in
			Section 5.2.1 of [RFC5201]) and therefore the final recipient of the
			packet, and all HIP hosts on the path, MUST support it. If the
			parameter is used in a scenario where the final recipient does not
			support the parameter, the parameter SHOULD be removed before
			forwarding the packet to the final recipient.
	8. Security Considerations		7. Security Considerations
	This document provides a high-level framework to build HIP-based		This document provides a high-level framework to build HIP-based
	overlays. The security properties of HIP and its extensions used in		overlays. The security properties of HIP and its extensions used in
	this framework are discussed in their respective specifications.		this framework are discussed in their respective specifications.
	Those security properties can be affected by the way HIP is used in a		Those security properties can be affected by the way HIP is used in a
	particular overlay (e.g., by how ORCHIDs are derived from Peer IDs).		particular overlay. However, those properties are mostly affected by
	However, those properties are mostly affected by the design decisions		the design decisions made to build a particular overlay; not so much
	made to build a particular overlay; not so much by the high-level		by the high-level framework specified in this document. Such design
	framework specified in this document. Such design decisions are		decisions are typically documented in a HIP BONE instance
	typically documented in a HIP BONE instance specification, which		specification, which describes the security properties of the
	describes the security properties of the resulting overlay.		resulting overlay.
	9. Acknowledgements		8. Acknowledgements
	HIP BONE is based on ideas coming from conversations and discussions		HIP BONE is based on ideas coming from conversations and discussions
	with a number of people in the HIP and P2PSIP communities. In		with a number of people in the HIP and P2PSIP communities. In
	particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas		particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas
	Henderson, Bruce Lowekamp, and Miika Komu provided useful input on		Henderson, Bruce Lowekamp, and Miika Komu provided useful input on
	HIP BONE.		HIP BONE.
	10. IANA Considerations		9. IANA Considerations
	This section is to be interpreted according to [RFC5226].		This section is to be interpreted according to [RFC5226].
	This document updates the IANA Registry for HIP Parameter Types		This document updates the IANA Registry for HIP Parameter Types
	[RFC5201] by assigning HIP Parameter Type values for the new HIP		[RFC5201] by assigning HIP Parameter Type values for the new HIP
	Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL		Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL
	(defined in Section 6.2). This document also defines new HIP Notify		(defined in Section 6.2). This document also defines a new HIP
	packet type [RFC5201] OVERLAY_TTL_EXCEEDED (Section 6.2).		Notify packet type [RFC5201] OVERLAY_TTL_EXCEEDED in Section 6.2.
	11. References		10. References
	11.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix		[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
	for Overlay Routable Cryptographic Hash Identifiers		for Overlay Routable Cryptographic Hash Identifiers
	(ORCHID)", RFC 4843, April 2007.		(ORCHID)", RFC 4843, April 2007.
	[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,		[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
	"Host Identity Protocol", RFC 5201, April 2008.		"Host Identity Protocol", RFC 5201, April 2008.
	[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the		[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
	Encapsulating Security Payload (ESP) Transport Format with		Encapsulating Security Payload (ESP) Transport Format with
	the Host Identity Protocol (HIP)", RFC 5202, April 2008.		the Host Identity Protocol (HIP)", RFC 5202, April 2008.
			[I-D.ietf-hip-nat-traversal]
			Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
			Keranen, "Basic HIP Extensions for Traversal of Network
			Address Translators", draft-ietf-hip-nat-traversal-09
			(work in progress), October 2009.
			[I-D.ietf-hip-hiccups]
			Camarillo, G. and J. Melen, "HIP (Host Identity Protocol)
			Immediate Carriage and Conveyance of Upper- layer Protocol
			Signaling (HICCUPS)", draft-ietf-hip-hiccups-02 (work in
			progress), March 2010.
			10.2. Informative References
			[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
			Protocol Architecture", RFC 4251, January 2006.
	[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)		[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", RFC 5204, April 2008.		Rendezvous Extension", RFC 5204, April 2008.
	[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol		[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
	(HIP) Domain Name System (DNS) Extensions", RFC 5205,		(HIP) Domain Name System (DNS) Extensions", RFC 5205,
	April 2008.		April 2008.
	[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-		[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
	Host Mobility and Multihoming with the Host Identity		Host Mobility and Multihoming with the Host Identity
	Protocol", RFC 5206, April 2008.		Protocol", RFC 5206, April 2008.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host		[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
	Identity Protocol with Legacy Applications", RFC 5338,		Identity Protocol with Legacy Applications", RFC 5338,
	September 2008.		September 2008.
			[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
			"Session Traversal Utilities for NAT (STUN)", RFC 5389,
			October 2008.
	[I-D.ietf-hip-native-api]		[I-D.ietf-hip-native-api]
	Komu, M. and T. Henderson, "Basic Socket Interface		Komu, M. and T. Henderson, "Basic Socket Interface
	Extensions for Host Identity Protocol (HIP)",		Extensions for Host Identity Protocol (HIP)",
	draft-ietf-hip-native-api-12 (work in progress),		draft-ietf-hip-native-api-12 (work in progress),
	January 2010.		January 2010.
	[I-D.ietf-hip-nat-traversal]
	Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
	Keranen, "Basic HIP Extensions for Traversal of Network
	Address Translators", draft-ietf-hip-nat-traversal-09
	(work in progress), October 2009.
	[I-D.ietf-hip-hiccups]
	Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
	Identity Protocol) Immediate Carriage and Conveyance of
	Upper-layer Protocol Signaling (HICCUPS)",
	draft-ietf-hip-hiccups-01 (work in progress),
	January 2009.
	11.2. Informative References
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	October 2008.
	[I-D.ietf-mmusic-ice]		[I-D.ietf-mmusic-ice]
	Rosenberg, J., "Interactive Connectivity Establishment		Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols",		Traversal for Offer/Answer Protocols",
	draft-ietf-mmusic-ice-19 (work in progress), October 2007.		draft-ietf-mmusic-ice-19 (work in progress), October 2007.
	[I-D.ietf-p2psip-base]		[I-D.ietf-p2psip-base]
	Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and		Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
	H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)		H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
	Base Protocol", draft-ietf-p2psip-base-06 (work in		Base Protocol", draft-ietf-p2psip-base-07 (work in
	progress), November 2009.		progress), February 2010.
	[I-D.ietf-hip-reload-instance]		[I-D.ietf-hip-reload-instance]
	Keranen, A., Camarillo, G., and J. Maenpaa, "HIP BONE		Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
	Instance Specification for RELOAD",		Protocol-Based Overlay Networking Environment (HIP BONE)
	draft-ietf-hip-reload-instance-00 (work in progress),		Instance Specification for REsource LOcation And Discovery
	Jan 2010.		(RELOAD)", draft-ietf-hip-reload-instance-00 (work in
			progress), January 2010.
	Authors' Addresses		Authors' Addresses
	Gonzalo Camarillo		Gonzalo Camarillo
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: Gonzalo.Camarillo@ericsson.com		Email: Gonzalo.Camarillo@ericsson.com
End of changes. 55 change blocks.
	238 lines changed or deleted		299 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/