From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6395.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc6395.txt (limited to 'doc/rfc/rfc6395.txt') 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", . + + [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] + -- cgit v1.2.3