PIM Interface ID: An Interface Identifier (ID) Hello Option for PIM
A PIM Hello option that lets a router tag each of its interfaces with a 64-bit identifier its neighbors can refer to.
Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395, October 2011, <https://www.rfc-editor.org/info/rfc6395>.
@misc{rfc6395,
series = {Request for Comments},
number = 6395,
howpublished = {RFC 6395},
publisher = {RFC Editor},
doi = {10.17487/RFC6395},
url = {https://www.rfc-editor.org/info/rfc6395},
author = {S. Gulrajani and S. Venaas},
title = {{An Interface Identifier (ID) Hello Option for PIM}},
pagetotal = 6,
year = 2011,
month = oct,
} RFC text
Contents
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.
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.
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.
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.
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.
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
AI ELI5
On this page
§1Why Interfaces Need Identifiers
This document defines a new option for PIM Hello messages (RFC 4601) that carries an Interface Identifier. A router generates an identifier for each of its PIM-enabled interfaces so that every interface has a different one. The identifiers can optionally be made unique within a wider scope, for example an administrative domain.
The RFC gives one example of use: PIM over Reliable Transport (PORT), where a single transport connection is used between two routers that have several interfaces connecting them. If those interfaces are unnumbered or use IPv6 link-local addresses, the identifier in a PORT Join/Prune message says which interface the message is about. For PORT the Router Identifier is not needed and can be set to zero.
All multi-byte integers are sent in network byte order, most significant byte first.
If two roads connect the same two towns, you need names for the roads to say which one you mean. This gives each of the router's links its own name tag.
§2The Interface Identifier Option
The option identifies the interface of a neighboring router through which a PIM Hello was sent. That lets PIM protocols refer to a particular interface on that neighbor.
A router needs to include the option only if it supports protocols that require it, though an implementation MAY always include it. How the identifier is used, and how unique and stable it must be, is left to the PIM protocols that use it. Such protocols should state their minimum requirements.
The identifier is 64 bits. The high 32 bits are the Router Identifier and the lower 32 bits are the Local Interface Identifier.
The name tag has two parts: one part says which router, and the other says which doorway on that router.
§2.1Rules for the Two Halves
The Local Interface Identifier must be unique among the router's PIM-enabled interfaces: there MUST NOT be two PIM interfaces with the same one. While an interface is up, its identifier MUST stay the same. If an interface goes down and comes up, the router SHOULD reuse it, but if the whole node restarts the identifiers MAY change. Many systems use an ifIndex (RFC 2863) for this. The value MUST be non-zero, because some protocols use 0 to mean that no interface is referenced.
The Router Identifier may uniquely identify the router, and how widely it must be unique depends on the protocols using it. An implementation picks it by a configured policy, for example an IPv4 unicast address of the router, but MUST allow it to be configured manually. It MAY reuse the identifier used by protocols such as BGP or OSPFv2 if the uniqueness needs are met. The value 0 means no Router Identifier is used, and an implementation MAY set it to zero if it only supports protocols that need uniqueness within one router.
No two doorways on one router may share a tag, and a doorway keeps its tag while it is open. A tag of zero means the tag is not being used.
§3The Option Format
The option is a type-length-value element. The Type is 31 and the Length is 8, counting only the value part. The value holds the Router Identifier (4 bytes) followed by the Local Interface Identifier (4 bytes).
The Router Identifier field MAY be 0 when no protocol requires one, but it MUST contain either a valid Router Identifier or zero. The Local Interface Identifier is unique among all PIM-enabled interfaces on the router.
It is a small label with a type, a size, and then the two numbers that make up the name tag.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 2 bytes | 31 | Option type, 31. |
LENGTH | Length | 2 bytes | 8 | Length of the value part in bytes. |
ROUTER-ID | Router Identifier | 4 bytes | Identifies the router within some scope; 0 when not used. | |
LOCAL-IF-ID | Local Interface Identifier | 4 bytes | Unique among the router's PIM-enabled interfaces; non-zero. |
§4Security Considerations
The identifier travels in PIM Hello messages, so the security considerations of RFC 4601 for Hello messages apply. In particular, a Hello may be forged and include an arbitrary Interface Identifier, or the identifier may be intentionally left out. The effects depend on how other protocols use the identifier.
Someone could write a fake name tag or remove a real one. How bad that is depends on what the neighbors do with the tags.
§5IANA Considerations
IANA has assigned the value 31 to the Interface ID option in the PIM Hello options registry. No other registry action is described.
The official list of Hello options now has this option written down as number 31.