draft-ietf-pim-hello-intid-00.txt		draft-ietf-pim-hello-intid-01.txt
	Network Working Group S. Gulrajani		Network Working Group S. Gulrajani
	Internet-Draft S. Venaas		Internet-Draft S. Venaas
	Intended status: Standards Track cisco Systems		Intended status: Standards Track cisco Systems
	Expires: October 24, 2011 April 22, 2011		Expires: December 9, 2011 June 7, 2011
	An Interface ID Hello Option for PIM		An Interface ID Hello Option for PIM
	draft-ietf-pim-hello-intid-00.txt		draft-ietf-pim-hello-intid-01.txt
	Abstract		Abstract
	This document defines a new PIM Hello option to advertise an		This document defines a new PIM Hello option to advertise an
	interface id that can be used by PIM protocols to uniquely identify		interface identifier that can be used by PIM protocols to uniquely
	an interface of a neighboring router.		identify an interface of a neighboring router.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on October 24, 2011.		This Internet-Draft will expire on December 9, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 9		skipping to change at page 3, line 9
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	This document defines a new option for use in PIM Hello messages		This document defines a new option for use in PIM Hello messages
	[RFC4601] to carry an Interface Identifier. A router generates		[RFC4601] to carry an Interface Identifier. A router generates
	identifiers for each of its PIM enabled interfaces so that each		identifiers for each of its PIM enabled interfaces such that each
	interface has a different identifier. The identifiers can optionally		interface has a different identifier. The identifiers can optionally
	be generated so that they are unique within, e.g., an administrative		be generated such that they are unique within, e.g., an
	domain.		administrative domain.
	An example where this Interface Identifier can be used is with PIM		An example where this Interface Identifier can be used is with PIM
	PORT [I-D.ietf-pim-port], where a single Transport connection is used		PORT [I-D.ietf-pim-port], where a single Transport connection is used
	between two routers that have multiple interfaces connecting them.		between two routers that have multiple interfaces connecting them.
	If these interfaces have unnumbered or IPv6 Link local addresses, the		If these interfaces have unnumbered or IPv6 Link local addresses, the
	Interface Identifier included in the PORT Join/Prune message will		Interface Identifier included in the PORT Join/Prune message will
	identify which interface the message is associated with. For PIM		identify which interface the message is associated with. For PIM
	PORT the Router Identifier is not needed, and it can be set to zero.		PORT the Router Identifier is not needed, and it can be set to zero.
	1.1. Requirements Notation		1.1. Requirements Notation
	skipping to change at page 4, line 18		skipping to change at page 4, line 18
	of a neighboring router a PIM Hello [RFC4601] is sent on. This		of a neighboring router a PIM Hello [RFC4601] is sent on. This
	allows PIM protocols to refer to, or identify, a particular interface		allows PIM protocols to refer to, or identify, a particular interface
	on a neighboring router.		on a neighboring router.
	The Interface Identifier option need only be included in PIM Hello		The Interface Identifier option need only be included in PIM Hello
	messages if the router supports protocols that require it. An		messages if the router supports protocols that require it. An
	implementation MAY choose to always include it. How exactly the		implementation MAY choose to always include it. How exactly the
	Interface Identifier is used, and the uniqueness requirements, is		Interface Identifier is used, and the uniqueness requirements, is
	left to the specifications of the PIM protocols that make use of it.		left to the specifications of the PIM protocols that make use of it.
	It is assumed that different protocols may have different minimum		It is assumed that different protocols may have different minimum
	requirements for stability and uniqueness, but that they have no		requirements for stability and uniqueness of the interface
	maximum requirement. When specified, these protocols should indicate		identifier, but that they have no maximum requirement. When
	what their minimum requirements are.		specified, these protocols should indicate what their minimum
			requirements are.
	The Interface Identifier consists of 64 bits. The lower 32 bits form		The Interface Identifier consists of 64 bits. The lower 32 bits form
	a Local Interface Identifier, and the high 32 bits a Router		a Local Interface Identifier, and the high 32 bits a Router
	Identifier.		Identifier.
	2.1. Local Interface Identifier		2.1. Local Interface Identifier
	The 32 bit Local Interface Identifier is selected so that it is		The 32 bit Local Interface Identifier is selected such that it is
	unique among the router's PIM enabled interfaces. That is, there		unique among the router's PIM enabled interfaces. That is, there
	MUST NOT be two PIM interfaces with the same Local Interface		MUST NOT be two PIM interfaces with the same Local Interface
	Identifier. While an interface is up, the Identifier MUST always be		Identifier. While an interface is up, the Identifier MUST always be
	the same once it has been allocated. If an interface goes down and		the same once it has been allocated. If an interface goes down and
	up, the router SHOULD use the same Identifier. Many systems makes		comes up, the router SHOULD use the same Identifier. Many systems
	use of an ifIndex [RFC1213], which can be used as a Local Interface		make use of an ifIndex [RFC1213], which can be used as a Local
	Identifier.		Interface Identifier.
	The Local Interface Identifier MUST be non-zero. The reason for		The Local Interface Identifier MUST be non-zero. The reason for
	this, is that some protocols may want to only optionally refer to an		this, is that some protocols may want to only optionally refer to an
	Interface using the Interface Identifier Hello option, and use the		Interface using the Interface Identifier Hello option, and use the
	value of 0 to show that it is not referred to. Note that the value		value of 0 to show that it is not referred to. Note that the value
	of 0 is not a valid ifIndex as defined in [RFC1213].		of 0 is not a valid ifIndex as defined in [RFC1213].
	2.2. Router Identifier		2.2. Router Identifier
	The 32 bit Router Identifier may be used to uniquely identify the		The 32 bit Router Identifier may be used to uniquely identify the
	router. It may be selected to be unique within some administrative		router. It may be selected to be unique within some administrative
	domain, or possibly globally unique. The requirements for the scope		domain, or possibly globally unique. The requirements for the scope
	in which it needs to be unique depend on the protocol that utilizes		in which it needs to be unique depend on the protocol that utilizes
	this. A router implementation MAY choose an IPv4 unicast address		this. A router implementation MAY choose an IPv4 unicast address
	assigned to the router as the Router Identifer, but MUST allow the		assigned to the router as the Router Identifer, but MUST allow the
	identifier to be configured manually. Protocols like BGP [RFC4271]		identifier to be configured manually. Protocols such as BGP
	and OSPFv2 [RFC2328] are other protocols making use of 32 bit
	identifiers for routers. One may use the same identifier to		[RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32
			bit identifiers for routers. One may use the same identifier to
	construct the Interface Identifier option, provided it meets the		construct the Interface Identifier option, provided it meets the
	stability and uniqueness requirements of protocols making use of this		stability and uniqueness requirements of protocols making use of this
	option.		option.
	The value 0 has a special meaning for the Router Identifier. It		The value 0 has a special meaning for the Router Identifier. It
	means that no Router Identifier is used. If a router only supports		means that no Router Identifier is used. If a router only supports
	protocols that require the Interface Identifier to be unique for one		protocols that require the Interface Identifier to be unique for one
	router (only making use of the Local Interface Identifier), then the		router (only making use of the Local Interface Identifier), then the
	implementation MAY set the Router Identifier to zero.		implementation MAY set the Router Identifier to zero.
	3. Message Format		3. Message Format
	Option Type: Interface Identifier		Option Type: Interface Identifier
	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 = TBD | Length = 8 |		| Type = 31 | Length = 8 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Router Identifier |		| Router Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Interface Identifier |		| Local Interface Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Allocated Hello Type values can be found in [HELLO-OPT].		Allocated Hello Type values can be found in [HELLO-OPT].
	Length: In bytes for the value part of the Type/Length/Value		Length: In bytes for the value part of the Type/Length/Value
	encoding. The Interface Identifier will be 8 bytes long.		encoding. The Interface Identifier will be 8 bytes long.
	Local Interface Identifier: The Local Interface Identifier is a 4
	byte identifier that is unique among all PIM enabled interfaces on
	a router.
	Router Identifier: The Router Identifier is a 4 byte identifier		Router Identifier: The Router Identifier is a 4 byte identifier
	uniquely identifying the router within some scope. It MAY be 0		uniquely identifying the router within some scope. It MAY be 0
	when no protocols require a Router Identifier.		when no protocols require a Router Identifier.
			Local Interface Identifier: The Local Interface Identifier is a 4
			byte identifier that is unique among all PIM enabled interfaces on
			a router.
	4. Security Considerations		4. Security Considerations
	The Interface Identifier is included in PIM Hello messages. See		The Interface Identifier is included in PIM Hello messages. See
	[RFC4601] for security considerations regarding PIM Hello messages.		[RFC4601] for security considerations regarding PIM Hello messages.
	In particular, PIM Hello messages may be forged, and may include an		In particular, PIM Hello messages may be forged, and may include an
	arbitrary Interface Identifier, or it may be intentionally omitted.		arbitrary Interface Identifier, or the Interface Identifier may be
	The effects of this depend on how the Interface Identifier is used by		intentionally omitted. The effects of this depend on how the
	other protocols.		Interface Identifier is used by other protocols.
	5. IANA Considerations		5. IANA Considerations
	IANA is requested to assign a PIM Hello option value for the		IANA has temporarily assigned the value 31 for the Interface
	Interface Identifier option defined in this document.		Identifier Hello option defined in this document. IANA is requested
			to make this assignment permanent.
	6. Acknowledgments		6. Acknowledgments
	The authors thank Yiqun Cai, Heidi Ou and Gorry Fairhurst for		The authors thank Yiqun Cai, Heidi Ou, Liming Wei, Gorry Fairhurst,
	providing valuable feedback.		Bharat Joshi and Bill Atwood for providing valuable feedback.
	7. References		7. References
	7.1. Normative References		7.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.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,		[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):		"Protocol Independent Multicast - Sparse Mode (PIM-SM):
End of changes. 16 change blocks.
	30 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/