An Interface ID Hello Option for PIM
draft-ietf-pim-hello-intid-00.txt

Abstract

This document defines a new PIM Hello option to advertise an interface id that can be used by PIM protocols to uniquely identify an interface of a neighboring router.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 24, 2011.

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
• 1.1. Requirements Notation
• 2. Interface Identifier Option
• 2.1. Local Interface Identifier
• 2.2. Router Identifier
• 3. Message Format
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgments
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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 so that each interface has a different identifier. The identifiers can optionally be generated so that they are unique within, e.g., an administrative domain.

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 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 which interface the message is associated with. For PIM PORT the Router Identifier is not needed, and it can be set to zero.

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 which interface of a neighboring router a PIM Hello [RFC4601] is sent on. 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. How exactly the Interface Identifier is used, and the uniqueness requirements, is left to the specifications of the PIM protocols that make use of it. It is assumed that different protocols may have different minimum requirements for stability and uniqueness, 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 a Router Identifier.

2.1. Local Interface Identifier

The 32 bit Local Interface Identifier is selected so 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 up, the router SHOULD use the same Identifier. Many systems makes use of an ifIndex [RFC1213], which can be used as a Local Interface Identifier.

The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may want to only optionally refer to an 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 of 0 is not a valid ifIndex as defined in [RFC1213].

2.2. Router Identifier

The 32 bit Router Identifier may be used to uniquely identify the router. It may be selected to be unique within some administrative domain, or possibly globally unique. The requirements for the scope in which it needs to be unique depend on the protocol that utilizes this. A router implementation MAY choose an IPv4 unicast address assigned to the router as the Router Identifer, but MUST allow the identifier to be configured manually. Protocols like BGP [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 stability and uniqueness requirements of protocols making use of this option.

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 = TBD          |         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.

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 uniquely identifying the router within some scope. It MAY be 0 when no protocols require a Router Identifier.

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 may include an arbitrary Interface Identifier, or it may be intentionally omitted. The effects of this depend on how the Interface Identifier is used by other protocols.

5. IANA Considerations

IANA is requested to assign a PIM Hello option value for the Interface Identifier option defined in this document.

6. Acknowledgments

The authors thank Yiqun Cai, Heidi Ou and Gorry Fairhurst for providing valuable feedback.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses