draft-ietf-hip-bone-00.txt		draft-ietf-hip-bone-01.txt
	HIP Working Group G. Camarillo		HIP Working Group G. Camarillo
	Internet-Draft P. Nikander		Internet-Draft P. Nikander
	Expires: April 30, 2009 J. Hautakorpi		Expires: September 10, 2009 J. Hautakorpi
	Ericsson		Ericsson
	A. Johnston		A. Johnston
	Avaya		Avaya
	October 27, 2008		March 9, 2009
	HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking		HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking
	Environment		Environment
	draft-ietf-hip-bone-00.txt		draft-ietf-hip-bone-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 30, 2009.		This Internet-Draft will expire on September 10, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	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 2, line 26		skipping to change at page 2, line 35
	2.3.2. Identifier Assignment and Authentication . . . . . . . 6		2.3.2. Identifier Assignment and Authentication . . . . . . . 6
	2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7		2.3.3. Connection Security . . . . . . . . . . . . . . . . . 7
	2.4. HIP Deployability and Legacy Applications . . . . . . . . 8		2.4. HIP Deployability and Legacy Applications . . . . . . . . 8
	3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8		3. The HIP BONE Framework . . . . . . . . . . . . . . . . . . . . 8
	3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9		3.1. Peer ID Assignment and Bootstrap . . . . . . . . . . . . . 9
	3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10		3.2. Connection Establishment . . . . . . . . . . . . . . . . . 10
	3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11		3.3. Lightweight Message Exchanges . . . . . . . . . . . . . . 11
	3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11		3.4. HIP BONE Instantiation . . . . . . . . . . . . . . . . . . 11
	4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12		4. Advantages of Using HIP BONE . . . . . . . . . . . . . . . . . 12
	5. RELOAD-based HIP BONE Instance Specification . . . . . . . . . 12		5. RELOAD-based HIP BONE Instance Specification . . . . . . . . . 12
			5.1. Peer Protocol . . . . . . . . . . . . . . . . . . . . . . 12
			5.2. Peer ID to ORCHID Transformation . . . . . . . . . . . . . 13
			5.3. Mapping between Protocol Primitives and HIP Messages . . . 13
	6. Architectural Considerations . . . . . . . . . . . . . . . . . 13		6. Architectural Considerations . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 15		10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Host Identity Protocol (HIP) [I-D.ietf-hip-base] defines a new		The Host Identity Protocol (HIP) [RFC5201] defines a new name space
	name space between the network and transport layers. HIP provides		between the network and transport layers. HIP provides upper layers
	upper layers with mobility, multihoming, NAT (Network Address		with mobility, multihoming, NAT (Network Address Translation)
	Translation) traversal, and security functionality. HIP implements		traversal, and security functionality. HIP implements the so called
	the so called identifier/locator (ID/locator) split, which implies		identifier/locator (ID/locator) split, which implies that IP
	that IP addresses are only used as locators, not as host identifiers.		addresses are only used as locators, not as host identifiers. This
	This split makes HIP a suitable protocol to build overlay networks		split makes HIP a suitable protocol to build overlay networks that
	that implement identifier-based overlay routing over IP networks,		implement identifier-based overlay routing over IP networks, which in
	which in turn implement locator-based routing.		turn implement locator-based routing.
	The remainder of this document is organized as follows. Section 2		The remainder of this document is organized as follows. Section 2
	provides background information on HIP. Section 3 describes the HIP		provides background information on HIP. Section 3 describes the HIP
	BONE (HIP-Based Overlay Networking Environment) framework. Section 4		BONE (HIP-Based Overlay Networking Environment) framework. Section 4
	discusses some of the advantages derived from using the HIP BONE		discusses some of the advantages derived from using the HIP BONE
	framework. Section 5 contains the RELOAD-based HIP BONE instance		framework. Section 5 contains the RELOAD-based HIP BONE instance
	specification. Finally, before the customary sections, Section 6		specification. Finally, before the customary sections, Section 6
	attempts to put the presented proposal into a larger architectural		attempts to put the presented proposal into a larger architectural
	context.		context.
	skipping to change at page 5, line 23		skipping to change at page 5, line 23
	| -------------------------->|		| -------------------------->|
	| 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 [I-D.ietf-hip-dns] or indirectly by sending		directly from the DNS [RFC5205] or indirectly by sending packets
	packets through a HIP rendezvous server [I-D.ietf-hip-rvs]. However,		through a HIP rendezvous server [RFC5204]. However, as an
	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
	NAT traversal scenario).		NAT traversal scenario).
	2.1.3. Locator Management		2.1.3. Locator Management
	Once a HIP connection between two hosts has been established with a		Once a HIP connection between two hosts has been established with a
	HIP base exchange, the hosts can start exchanging higher-layer		HIP base exchange, the hosts can start exchanging higher-layer
	traffic. If any of the hosts changes its set of locators, it runs an		traffic. If any of the hosts changes its set of locators, it runs an
	update exchange [I-D.ietf-hip-mm], which consists of three messages.		update exchange [RFC5206], which consists of three messages. If a
	If a host is multihomed, it simply provides more than one locator in		host is multihomed, it simply provides more than one locator in its
	its exchanges. However, if both of the end points move at the same		exchanges. However, if both of the end points move at the same time,
	time, or through some other reason both lose track of the peers'		or through some other reason both lose track of the peers' currently
	currently active locators, they need to resort to using a rendezvous		active locators, they need to resort to using a rendezvous server or
	server or getting new peer locators by some other means.		getting new peer locators by some other means.
	2.2. NAT Traversal		2.2. NAT Traversal
	HIP's NAT traversal mechanism is based on ICE (Interactive		HIP's NAT traversal mechanism is based on ICE (Interactive
	Connectivity Establishment) [I-D.ietf-mmusic-ice]. Hosts gather		Connectivity Establishment) [I-D.ietf-mmusic-ice]. Hosts gather
	address candidates and, as part of the HIP base exchange, hosts		address candidates and, as part of the HIP base exchange, hosts
	perform an ICE offer/answer exchange where they exchange their		perform an ICE offer/answer exchange where they exchange their
	respective address candidates. Hosts perform end-to-end STUN		respective address candidates. Hosts perform end-to-end STUN
	[I-D.ietf-behave-rfc3489bis] based connectivity checks in order to		[RFC5389] based connectivity checks in order to discover which
	discover which address candidate pairs yield connectivity.		address candidate pairs yield connectivity.
	Even though, architecturally, HIP lies below the transport layer		Even though, architecturally, HIP lies below the transport layer
	(i.e., HIP packets are carried directly in IP packets), in presence		(i.e., HIP packets are carried directly in IP packets), in presence
	of NATs, HIP sometimes needs to be tunneled in a transport protocol		of NATs, HIP sometimes needs to be tunneled in a transport protocol
	(i.e., HIP packets are carried by a transport protocol such as UDP).		(i.e., HIP packets are carried by a transport protocol such as UDP).
	2.3. Security		2.3. Security
	Security is an essential part of HIP. The following sections		Security is an essential part of HIP. The following sections
	describe the security-related functionality provided by HIP.		describe the security-related functionality provided by HIP.
	skipping to change at page 7, line 46		skipping to change at page 7, line 46
	However, such considerations go well beyond the current HIP		However, such considerations go well beyond the current HIP
	architecture and even beyond this proposal. For the purposes of the		architecture and even beyond this proposal. For the purposes of the
	present document, we merely want to point out that architecturally		present document, we merely want to point out that architecturally
	HIP supports both self-generated opportunistic identifiers and		HIP supports both self-generated opportunistic identifiers and
	administratively assigned ones.		administratively assigned ones.
	2.3.3. Connection Security		2.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		mechanism used to protect the traffic is IPsec ESP [RFC5202].
	[I-D.ietf-hip-esp]. However, there is ongoing work to specify how to		However, there is ongoing work to specify how to use different
	use different protection mechanisms.		protection mechanisms.
	2.4. HIP Deployability and Legacy Applications		2.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 [I-D.ietf-hip-applications] can use HIP through		aware) applications [RFC5338] can use HIP through the traditional
	the traditional IPv4 and IPv6 socket APIs.		IPv4 and IPv6 socket APIs.
	The idea is that when a legacy IPv6 application tries and obtains a		The idea is that when a legacy IPv6 application tries and obtains a
	remote host's IP address (e.g., by querying the DNS) the DNS resolver		remote host's IP address (e.g., by querying the DNS) the DNS resolver
	passes the remote host's ORCHID (which was also stored in the DNS) to		passes the remote host's ORCHID (which was also stored in the DNS) to
	the legacy application. At the same time, the DNS resolver stores		the legacy application. At the same time, the DNS resolver stores
	stores the remote host's IP address internally at the HIP module.		stores the remote host's IP address internally at the HIP module.
	Since the ORCHID looks like an IPv6 address, the legacy application		Since the ORCHID looks like an IPv6 address, the legacy application
	treats it as such. It opens a connection (e.g., TCP) using the		treats it as such. It opens a connection (e.g., TCP) using the
	traditional IPv6 socket API. The HIP module running in the same host		traditional IPv6 socket API. The HIP module running in the same host
	as the legacy application intercepts this call somehow (e.g., using		as the legacy application intercepts this call somehow (e.g., using
	skipping to change at page 10, line 39		skipping to change at page 10, line 39
	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
	initiator sends the I1 packet to the remote endpoint's locator.		initiator sends the I1 packet to the remote endpoint's locator.
	Initiators that do not have any locator for the remote endpoint need		Initiators that do not have any locator for the remote endpoint need
	to use a rendezvous service. Traditionally, a HIP rendezvous server		to use a rendezvous service. Traditionally, a HIP rendezvous server
	[I-D.ietf-hip-rvs] has provided such a rendezvous service. In HIP		[RFC5204] has provided such a rendezvous service. In HIP BONE, the
	BONE, the overlay itself provides the rendezvous service.		overlay itself provides the rendezvous service.
	Therefore, in HIP BONE, a node uses an I1 packet (as usual) to		Therefore, in HIP BONE, a node uses an I1 packet (as usual) to
	establish a connection with another node in the overlay. Nodes in		establish a connection with another node in the overlay. Nodes in
	the overlay forward I1 packets in a hop-by-hop fashion according to		the overlay forward I1 packets in a hop-by-hop fashion according to
	the overlay's routing table towards its destination. This way, the		the overlay's routing table towards its destination. This way, the
	overlay provides a rendezvous service between the nodes establishing		overlay provides a rendezvous service between the nodes establishing
	the connection. If the overlay nodes have active connections with		the connection. If the overlay nodes have active connections with
	other nodes in their forwarding tables and if those connections are		other nodes in their forwarding tables and if those connections are
	protected (typically with IPsec ESP), I1 packets may be sent over		protected (typically with IPsec ESP), I1 packets may be sent over
	protected connections between nodes. Alternatively, if there no such		protected connections between nodes. Alternatively, if there no such
	skipping to change at page 12, line 21		skipping to change at page 12, line 21
	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.
	o for what type of traffic or messages it is appropriate to use		o for what type of traffic or messages it is appropriate to use
	lightweight message exchanges.		lightweight message exchanges.
	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 particular HIP BONE instance specification left certain areas
			unspecified in order to leave their configuration up to each
			particular overlays.
	4. Advantages of Using HIP BONE		4. Advantages of Using HIP BONE
	Using HIP BONE, as opposed to a peer protocol, to perform connection		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		management in an overlay has a set of advantages. HIP BONE can be
	used by any peer protocol. This keeps each peer protocol from		used by any peer protocol. This keeps each peer protocol from
	defining primitives needed for connection management (e.g.,		defining primitives needed for connection management (e.g.,
	primitives to establish connections and to tunnel messages through		primitives to establish connections and to tunnel messages through
	the overlay) and NAT traversal. Having this functionality at a lower		the overlay) and NAT traversal. Having this functionality at a lower
	layer allows multiple upper-layer protocols to take advantage of it.		layer allows multiple upper-layer protocols to take advantage of it.
	Additionally, having a solution that integrates mobility and		Additionally, having a solution that integrates mobility and
	multihoming is useful in many scenarios. Peer protocols do not		multihoming is useful in many scenarios. Peer protocols do not
	typically specify mobility and multihoming solutions. Combining a		typically specify mobility and multihoming solutions. Combining a
	peer protocol including NAT traversal with a separate mobility		peer protocol including NAT traversal with a separate mobility
	mechanism and a separate multihoming mechanism can easily lead to		mechanism and a separate multihoming mechanism can easily lead to
	unexpected (and unpleasant) interactions.		unexpected (and unpleasant) interactions.
	5. RELOAD-based HIP BONE Instance Specification		5. RELOAD-based HIP BONE Instance Specification
	Editor's note: To be done when details about RELOAD are more stable.		This section specifies the RELOAD-based HIP BONE instance
			specification.
	OPEN ISSUES:		5.1. Peer Protocol
	o RELOAD uses 128-bit identifiers. Which identifiers should HIP		The peer protocol to be used is RELOAD, which is specified in
	use?		[I-D.ietf-p2psip-base].
	o How does a HIP entity know which overlay an incoming I1 belongs
	to?		5.2. Peer ID to ORCHID Transformation
	o The RELOAD forwarding header carries Via and Destination lists.
	What to use as the destination HIT? Final destination (Via and		RELOAD uses 128 bit peer IDs called Node-IDs. Since HIP uses 128 bit
	Destination list functionality in HIP) or next hop? In any case,		ORCHIDs, a peer's RELOAD Node-ID is used as the peer's ORCHID.
	intermediaries will need to process the messages to process those
	lists.		5.3. Mapping between Protocol Primitives and HIP Messages
			The Attach procedure in RELOAD establishes a connection between two
			peers. This procedure is performed using the AttachReq and AttachAns
			messages. When HIP is used, the Attach procedure is performed by
			using a HIP base exchange. That is, peers send HIP I1 messages
			instead of RELOAD AttachReq messages.
			The RELOAD AttachLite procedure is used for the same purpose as the
			Attach procedure in scenarios with no NATs. When HIP is used, the
			AttachLite procedure is also performed by using a HIP base exchange.
			That is, peers send HIP I1 messages instead of RELOAD AttachLiteReq
			messages.
			OPEN ISSUE: The RELOAD forwarding header carries Via and Destination
			lists. We should have the same functionality in HIP so that I1s can
			be source routed and R1s can use symmetric routing. The destination
			HIT for the I1 packet would be the destination peer. The header
			fields defined in RFC 5204 (RVS) and in the NAT traversal draft can
			be used to implement that functionality or as templates to specify
			new header fields that implement that functionality.
			OPEN ISSUE: RELOAD mandates TLS. That is, it does not support plain
			TCP or UDP. If HIP is used like this, there will be double
			encryption (avoidable using a null encryption algorithm at one of the
			levels) and double authentication.
	6. Architectural Considerations		6. Architectural Considerations
	Architecturally, HIP can be considered to create a new thin "waist"		Architecturally, HIP can be considered to create a new thin "waist"
	layer on the top of the IPv4 and IPv6 networks; see Figure 3. The		layer on the top of the IPv4 and IPv6 networks; see Figure 3. The
	HIP layer itself consist of the HIP signalling protocol and one or		HIP layer itself consist of the HIP signalling protocol and one or
	more data transport protocols; see Figure 4. The HIP signalling		more data transport protocols; see Figure 4. The HIP signalling
	packets and the data transport packets can take different routes. In		packets and the data transport packets can take different routes. In
	the HIP BONE, the HIP signalling packets are typically first routed		the HIP BONE, the HIP signalling packets are typically first routed
	through the overlay and then directly (if possible), while the data		through the overlay and then directly (if possible), while the data
	skipping to change at page 15, line 40		skipping to change at page 16, line 23
	9. IANA Considerations		9. IANA Considerations
	This document does not contain any IANA actions.		This document does not contain any IANA actions.
	10. Normative References		10. Normative References
	[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.
	[I-D.ietf-hip-base]		[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
	Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,		"Host Identity Protocol", RFC 5201, April 2008.
	"Host Identity Protocol", draft-ietf-hip-base-10 (work in
	progress), October 2007.		[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
			Encapsulating Security Payload (ESP) Transport Format with
			the Host Identity Protocol (HIP)", RFC 5202, April 2008.
			[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
			Rendezvous Extension", RFC 5204, April 2008.
			[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
			(HIP) Domain Name System (DNS) Extensions", RFC 5205,
			April 2008.
			[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
			Host Mobility and Multihoming with the Host Identity
			Protocol", RFC 5206, April 2008.
			[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
			Identity Protocol with Legacy Applications", RFC 5338,
			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-05 (work in progress),		draft-ietf-hip-native-api-05 (work in progress),
	July 2008.		July 2008.
	[I-D.ietf-hip-dns]		[I-D.nikander-hip-hiccups]
	Nikander, P. and J. Laganier, "Host Identity Protocol		Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
	(HIP) Domain Name System (DNS) Extensions",		Identity Protocol) Immediate Carriage and Conveyance of
	draft-ietf-hip-dns-09 (work in progress), April 2007.		Upper- layer Protocol Signaling (HICCUPS)",
			draft-nikander-hip-hiccups-01 (work in progress),
	[I-D.ietf-hip-rvs]		November 2008.
	Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
	Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
	progress), June 2006.
	[I-D.ietf-hip-mm]
	Henderson, T., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-05 (work in
	progress), March 2007.
	[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-behave-rfc3489bis]		[I-D.ietf-p2psip-base]
	Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,		Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
	"Session Traversal Utilities for (NAT) (STUN)",		H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
	draft-ietf-behave-rfc3489bis-18 (work in progress),		Base Protocol", draft-ietf-p2psip-base-02 (work in
	July 2008.		progress), March 2009.
	[I-D.ietf-hip-esp]
	Jokela, P., "Using ESP transport format with HIP",
	draft-ietf-hip-esp-06 (work in progress), June 2007.
	[I-D.ietf-hip-applications]
	Henderson, T., Nikander, P., and M. Komu, "Using the Host
	Identity Protocol with Legacy Applications",
	draft-ietf-hip-applications-04 (work in progress),
	July 2008.
	[I-D.nikander-hip-hiccups]
	Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
	Identity Protocol) Immediate Carriage and Conveyance of
	Upper- layer Protocol Signalling (HICCUPS)",
	draft-nikander-hip-hiccups-00 (work in progress),
	July 2008.
	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
	skipping to change at page 18, line 4		skipping to change at line 786
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: Jani.Hautakorpi@ericsson.com		Email: Jani.Hautakorpi@ericsson.com
	Alan Johnston		Alan Johnston
	Avaya		Avaya
	St. Louis, MO 63124		St. Louis, MO 63124
	Email: alan@sipstation.com		Email: alan@sipstation.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	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
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 23 change blocks.
	90 lines changed or deleted		126 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/