summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6395.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6395.txt')
-rw-r--r--doc/rfc/rfc6395.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6395.txt b/doc/rfc/rfc6395.txt
new file mode 100644
index 0000000..6d0a051
--- /dev/null
+++ b/doc/rfc/rfc6395.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Gulrajani
+Request for Comments: 6395 S. Venaas
+Category: Standards Track Cisco Systems
+ISSN: 2070-1721 October 2011
+
+
+ An Interface Identifier (ID) Hello Option for PIM
+
+Abstract
+
+ This document defines a new PIM Hello option to advertise an
+ Interface Identifier that can be used by PIM protocols to uniquely
+ identify an interface of a neighboring router.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6395.
+
+Copyright Notice
+
+ Copyright (c) 2011 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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+Gulrajani & Venaas Standards Track [Page 1]
+
+RFC 6395 An Interface ID Hello Option for PIM October 2011
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . . 2
+ 2. Interface Identifier Option . . . . . . . . . . . . . . . . . . 2
+ 2.1. Local Interface Identifier . . . . . . . . . . . . . . . . 3
+ 2.2. Router Identifier . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 5
+
+1. Introduction
+
+ This document defines a new option for use in PIM Hello messages
+ [RFC4601] to carry an Interface Identifier. A router generates
+ identifiers for each of its PIM-enabled interfaces such that each
+ interface has a different identifier. The identifiers can optionally
+ be generated such that they are unique within, e.g., an
+ administrative domain.
+
+ An example where this Interface Identifier can be used is with PIM
+ over Reliable Transport (PORT) [PIM-PORT], where a single Transport
+ connection is used between two routers that have multiple interfaces
+ connecting them. If these interfaces have unnumbered or IPv6 link-
+ local addresses, the Interface Identifier included in the PORT Join/
+ Prune message will identify with which interface the message is
+ associated. For PORT, the Router Identifier is not needed, and it
+ can be set to zero.
+
+ All multi-byte integers in this specification are transmitted in
+ network byte order (i.e., most significant byte first).
+
+1.1. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Interface Identifier Option
+
+ The Interface Identifier option is used to identify the interface of
+ a neighboring router through which a PIM Hello [RFC4601] was sent.
+ This allows PIM protocols to refer to, or identify, a particular
+ interface on a neighboring router.
+
+
+
+Gulrajani & Venaas Standards Track [Page 2]
+
+RFC 6395 An Interface ID Hello Option for PIM October 2011
+
+
+ The Interface Identifier option need only be included in PIM Hello
+ messages if the router supports protocols that require it. An
+ implementation MAY choose to always include it. The usage of the
+ Interface Identifier and the uniqueness requirements are left to the
+ specifications of the PIM protocols that implement it. It is assumed
+ that different protocols have different minimum requirements for
+ stability and uniqueness of the Interface Identifier but that they
+ have no maximum requirement. When specified, these protocols should
+ indicate what their minimum requirements are.
+
+ The Interface Identifier consists of 64 bits. The lower 32 bits form
+ a Local Interface Identifier, and the high 32 bits form a Router
+ Identifier.
+
+2.1. Local Interface Identifier
+
+ The 32-bit Local Interface Identifier is selected such that it is
+ unique among the router's PIM-enabled interfaces. That is, there
+ MUST NOT be two PIM interfaces with the same Local Interface
+ Identifier. While an interface is up, the Identifier MUST always be
+ the same once it has been allocated. If an interface goes down and
+ comes up, the router SHOULD use the same Identifier. If a node goes
+ down and comes up again, the Identifier for each interface MAY
+ change. Many systems make use of an ifIndex [RFC2863] as a Local
+ Interface Identifier.
+
+ The Local Interface Identifier MUST be non-zero. The reason for this
+ is that some protocols may have messages that optionally reference an
+ Interface Identifier, and they may use the value of 0 to show that no
+ Interface Identifier is being referenced. Note that the value of 0
+ is not a valid ifIndex as defined in [RFC2863].
+
+2.2. Router Identifier
+
+ The 32-bit Router Identifier may be used to uniquely identify the
+ router. The requirements for the scope in which the Router
+ Identifier needs to be unique depend on the protocols that utilize
+ it. It may need to be unique within some administrative domain, or
+ it may possibly be globally unique.
+
+ A router implementation selects a Router Identifier according to a
+ configured policy that defines the uniqueness scope. Thus, an
+ implementation MAY be configured to choose an IPv4 unicast address
+ assigned to the router as the Router Identifier, but the
+ implementation MUST allow the identifier to be configured manually.
+
+
+
+
+
+
+Gulrajani & Venaas Standards Track [Page 3]
+
+RFC 6395 An Interface ID Hello Option for PIM October 2011
+
+
+ Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other
+ protocols that make use of 32-bit identifiers for routers. Provided
+ that the stability and uniqueness requirements of the protocols that
+ make use of the Router Identifier are met, an implementation MAY use
+ the same identifier used by other protocols.
+
+ The value 0 has a special meaning for the Router Identifier. It
+ means that no Router Identifier is used. If a router only supports
+ protocols that require the Interface Identifier to be unique for one
+ router (only making use of the Local Interface Identifier), then the
+ implementation MAY set the Router Identifier to zero.
+
+3. Message Format
+
+ Option Type: Interface Identifier
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 31 | Length = 8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Router Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Local Interface Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Allocated Hello Type values can be found in [HELLO-OPT].
+
+ Length: In bytes for the value part of the Type/Length/Value
+ encoding. The Interface Identifier will be 8 bytes long.
+
+ Router Identifier: The Router Identifier is a 4-byte identifier
+ uniquely identifying the router within some scope. It MAY be 0
+ when no protocols require a Router Identifier. The field MUST
+ contain a valid Router Identifier or the value zero.
+
+ 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
+
+ The Interface Identifier is included in PIM Hello messages. See
+ [RFC4601] for security considerations regarding PIM Hello messages.
+ In particular, PIM Hello messages may be forged and include an
+ arbitrary Interface Identifier, or the Interface Identifier may be
+ intentionally omitted. The effects of this depend on how the
+ Interface Identifier is used by other protocols.
+
+
+
+Gulrajani & Venaas Standards Track [Page 4]
+
+RFC 6395 An Interface ID Hello Option for PIM October 2011
+
+
+5. IANA Considerations
+
+ IANA has assigned the value 31 for the Interface ID PIM-Hello option
+ defined in this document.
+
+6. Acknowledgments
+
+ The authors thank Yiqun Cai, Heidi Ou, Liming Wei, Gorry Fairhurst,
+ Bharat Joshi, and Bill Atwood for providing valuable feedback.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+ "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+ Protocol Specification (Revised)", RFC 4601, August 2006.
+
+7.2. Informative References
+
+ [HELLO-OPT] IANA, "PIM Hello Options", <http://www.iana.org/>.
+
+ [PIM-PORT] Farinacci, D., Wijnands, IJ., Venaas, S., and M.
+ Napierala, "A Reliable Transport Mechanism for PIM", Work
+ in Progress, August 2011.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+ MIB", RFC 2863, June 2000.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+ Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulrajani & Venaas Standards Track [Page 5]
+
+RFC 6395 An Interface ID Hello Option for PIM October 2011
+
+
+Authors' Addresses
+
+ Sameer Gulrajani
+ Cisco Systems
+ Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: sameerg@cisco.com
+
+
+ Stig Venaas
+ Cisco Systems
+ Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: stig@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulrajani & Venaas Standards Track [Page 6]
+