draft-ietf-hip-via-02.txt		draft-ietf-hip-via-03.txt
	HIP Working Group G. Camarillo		HIP Working Group G. Camarillo
	Internet-Draft A. Keranen		Internet-Draft A. Keranen
	Intended status: Experimental Ericsson		Intended status: Experimental Ericsson
	Expires: December 24, 2010 June 22, 2010		Expires: December 31, 2010 June 29, 2010
	Host Identity Protocol (HIP) Multi-hop Routing Extension		Host Identity Protocol (HIP) Multi-hop Routing Extension
	draft-ietf-hip-via-02.txt		draft-ietf-hip-via-03.txt
	Abstract		Abstract
	This document specifies two extensions to HIP to implement multi-hop		This document specifies two extensions to HIP to implement multi-hop
	routing. The first extension allows implementing source routing in		routing. The first extension allows implementing source routing in
	HIP. That is, a node sending a HIP packet can define a set of nodes		HIP. That is, a node sending a HIP packet can define a set of nodes
	that the HIP packet should traverse. The second extension allows a		that the HIP packet should traverse. The second extension allows a
	HIP packet to carry and record the list of nodes that forwarded it.		HIP packet to carry and record the list of nodes that forwarded it.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 24, 2010.		This Internet-Draft will expire on December 31, 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
	skipping to change at page 3, line 17		skipping to change at page 3, line 17
	When HIP [RFC5201] is used in certain contexts, nodes need the		When HIP [RFC5201] is used in certain contexts, nodes need the
	ability to perform source routing. That is, a node needs the ability		ability to perform source routing. That is, a node needs the ability
	to send a HIP signaling packet that will traverse a set of nodes		to send a HIP signaling packet that will traverse a set of nodes
	before reaching its destination. Such features are needed, e.g., in		before reaching its destination. Such features are needed, e.g., in
	HIP BONE [I-D.ietf-hip-bone] overlay networks or if two nodes wish to		HIP BONE [I-D.ietf-hip-bone] overlay networks or if two nodes wish to
	keep a third, or more, HIP nodes on the signaling path. This		keep a third, or more, HIP nodes on the signaling path. This
	document defines an extension that provides HIP with this		document defines an extension that provides HIP with this
	functionality.		functionality.
	Additionally, when HIP signaling packets are routed through multiple		Additionally, when HIP signaling packets are routed through multiple
	nodes, some of these nodes (e.g., the destination node) need the		nodes, some of these nodes (e.g., the destination host) need the
	ability to know the nodes a particular packet traversed. This		ability to know the nodes a particular packet traversed. This
	document defines another extension that provides HIP with this		document defines another extension that provides HIP with this
	functionality.		functionality.
	These two extensions enable multi-hop routing in HIP. Before these		These two extensions enable multi-hop routing in HIP. Before these
	extensions were specified, there were standardized ways for		extensions were specified, there were standardized ways for
	supporting only a single intermediate node (e.g., a rendezvous server		supporting only a single intermediate node (e.g., a rendezvous server
	[RFC5204]) between the source of a HIP packet and its destination.		[RFC5204]) between the source of a HIP packet and its destination.
	2. Terminology		2. Terminology
	skipping to change at page 7, line 49		skipping to change at page 7, line 49
	This document updates the IANA Registry for HIP Parameter Types		This document updates the IANA Registry for HIP Parameter Types
	[RFC5201] by assigning new HIP Parameter Type values for the new HIP		[RFC5201] by assigning new HIP Parameter Type values for the new HIP
	Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 4). This		Parameters: ROUTE_VIA and ROUTE_DST (defined in Section 4). This
	document also defines a new Notify Packet Type [RFC5201]		document also defines a new Notify Packet Type [RFC5201]
	UNKNOWN_NEXT_HOP in Section 3.3.		UNKNOWN_NEXT_HOP in Section 3.3.
	The ROUTE_DST and ROUTE_VIA parameters utilize bit flags, for which		The ROUTE_DST and ROUTE_VIA parameters utilize bit flags, for which
	IANA is to create and maintain a new sub-registry entitled "HIP Via		IANA is to create and maintain a new sub-registry entitled "HIP Via
	Flags" under the "Host Identity Protocol (HIP) Parameters" registry.		Flags" under the "Host Identity Protocol (HIP) Parameters" registry.
	Initial values for the registry are given in Table 1; future		Initial values for the registry are given in Table 1; future
	assignments are to be made through IETF Review [RFC5226].		assignments are to be made through IETF Review or IESG Approval
	Assignments consist of the bit position and the name of the flag.		[RFC5226]. Assignments consist of the bit position and the name of
			the flag.
	6. Security Considerations		6. Security Considerations
	The standard HIP mechanisms (e.g., using signatures, puzzles, and the		The standard HIP mechanisms (e.g., using signatures, puzzles, and the
	ENCRYPTED parameter [RFC5201]) provide protection against		ENCRYPTED parameter [RFC5201]) provide protection against
	eavesdropping, replay, message insertion, deletion, modification, and		eavesdropping, replay, message insertion, deletion, modification, and
	man-in-the-middle attacks. Yet, the extensions described in this		man-in-the-middle attacks. Yet, the extensions described in this
	document allow nodes to route HIP messages via other nodes and hence		document allow nodes to route HIP messages via other nodes and hence
	possibly try to mount Denial of Service (DoS) attacks against them.		possibly try to mount Denial of Service (DoS) attacks against them.
	The following sections describe possible attacks and means to		The following sections describe possible attacks and means to
	skipping to change at page 9, line 33		skipping to change at page 9, line 34
	Rendezvous Extension", RFC 5204, April 2008.		Rendezvous Extension", RFC 5204, 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.
	[I-D.ietf-hip-bone]		[I-D.ietf-hip-bone]
	Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,		Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
	and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)		and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
	Based Overlay Networking Environment",		Based Overlay Networking Environment",
	draft-ietf-hip-bone-06 (work in progress), April 2010.		draft-ietf-hip-bone-07 (work in progress), June 2010.
	[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-08 (work in		Base Protocol", draft-ietf-p2psip-base-08 (work in
	progress), March 2010.		progress), March 2010.
	Authors' Addresses		Authors' Addresses
	Gonzalo Camarillo		Gonzalo Camarillo
End of changes. 6 change blocks.
	7 lines changed or deleted		8 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/