draft-ietf-pim-hello-intid-01.txt   rfc6395.txt 
Network Working Group S. Gulrajani Internet Engineering Task Force (IETF) S. Gulrajani
Internet-Draft S. Venaas Request for Comments: 6395 S. Venaas
Intended status: Standards Track cisco Systems Category: Standards Track Cisco Systems
Expires: December 9, 2011 June 7, 2011 ISSN: 2070-1721 October 2011
An Interface ID Hello Option for PIM An Interface Identifier (ID) Hello Option for PIM
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 identifier that can be used by PIM protocols to uniquely Interface Identifier that can be used by PIM protocols to uniquely
identify 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
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 9, 2011. 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 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . . 2
2. Interface Identifier Option . . . . . . . . . . . . . . . . . 4 2. Interface Identifier Option . . . . . . . . . . . . . . . . . . 2
2.1. Local Interface Identifier . . . . . . . . . . . . . . . . 4 2.1. Local Interface Identifier . . . . . . . . . . . . . . . . 3
2.2. Router Identifier . . . . . . . . . . . . . . . . . . . . 4 2.2. Router Identifier . . . . . . . . . . . . . . . . . . . . . 3
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 5
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 such 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 such that they are unique within, e.g., an be generated such that they are unique within, e.g., an
administrative 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 over Reliable Transport (PORT) [PIM-PORT], where a single Transport
between two routers that have multiple interfaces connecting them. connection is used between two routers that have multiple interfaces
If these interfaces have unnumbered or IPv6 Link local addresses, the connecting them. If these interfaces have unnumbered or IPv6 link-
Interface Identifier included in the PORT Join/Prune message will local addresses, the Interface Identifier included in the PORT Join/
identify which interface the message is associated with. For PIM Prune message will identify with which interface the message is
PORT the Router Identifier is not needed, and it can be set to zero. 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 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Interface Identifier Option 2. Interface Identifier Option
The Interface Identifier option is used to identify which interface The Interface Identifier option is used to identify the interface of
of a neighboring router a PIM Hello [RFC4601] is sent on. This a neighboring router through which a PIM Hello [RFC4601] was sent.
allows PIM protocols to refer to, or identify, a particular interface This allows PIM protocols to refer to, or identify, a particular
on a neighboring router. interface 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. The usage of the
Interface Identifier is used, and the uniqueness requirements, is Interface Identifier and the uniqueness requirements are left to the
left to the specifications of the PIM protocols that make use of it. specifications of the PIM protocols that implement it. It is assumed
It is assumed that different protocols may have different minimum that different protocols have different minimum requirements for
requirements for stability and uniqueness of the interface stability and uniqueness of the Interface Identifier but that they
identifier, but that they have no maximum requirement. When have no maximum requirement. When specified, these protocols should
specified, these protocols should indicate what their minimum indicate what their minimum requirements are.
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 form a Router
Identifier. Identifier.
2.1. Local Interface Identifier 2.1. Local Interface Identifier
The 32 bit Local Interface Identifier is selected such 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
comes up, the router SHOULD use the same Identifier. Many systems comes up, the router SHOULD use the same Identifier. If a node goes
make use of an ifIndex [RFC1213], which can be used as a Local 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. 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
this, is that some protocols may want to only optionally refer to an is that some protocols may have messages that optionally reference an
Interface using the Interface Identifier Hello option, and use the Interface Identifier, and they may use the value of 0 to show that no
value of 0 to show that it is not referred to. Note that the value Interface Identifier is being referenced. Note that the value of 0
of 0 is not a valid ifIndex as defined in [RFC1213]. is not a valid ifIndex as defined in [RFC2863].
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. The requirements for the scope in which the Router
domain, or possibly globally unique. The requirements for the scope Identifier needs to be unique depend on the protocols that utilize
in which it needs to be unique depend on the protocol that utilizes it. It may need to be unique within some administrative domain, or
this. A router implementation MAY choose an IPv4 unicast address it may possibly be globally unique.
assigned to the router as the Router Identifer, but MUST allow the
identifier to be configured manually. Protocols such as BGP
[RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32 A router implementation selects a Router Identifier according to a
bit identifiers for routers. One may use the same identifier to configured policy that defines the uniqueness scope. Thus, an
construct the Interface Identifier option, provided it meets the implementation MAY be configured to choose an IPv4 unicast address
stability and uniqueness requirements of protocols making use of this assigned to the router as the Router Identifier, but the
option. 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 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 = 31 | 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.
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. The field MUST
contain a valid Router Identifier or the value zero.
Local Interface Identifier: The Local Interface Identifier is a 4 Local Interface Identifier: The Local Interface Identifier is a
byte identifier that is unique among all PIM enabled interfaces on 4-byte identifier that is unique among all PIM-enabled interfaces
a router. 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 include an
arbitrary Interface Identifier, or the Interface Identifier may be arbitrary Interface Identifier, or the Interface Identifier may be
intentionally omitted. The effects of this depend on how the intentionally omitted. The effects of this depend on how the
Interface Identifier is used by other protocols. Interface Identifier is used by other protocols.
5. IANA Considerations 5. IANA Considerations
IANA has temporarily assigned the value 31 for the Interface IANA has assigned the value 31 for the Interface ID PIM-Hello option
Identifier Hello option defined in this document. IANA is requested defined in this document.
to make this assignment permanent.
6. Acknowledgments 6. Acknowledgments
The authors thank Yiqun Cai, Heidi Ou, Liming Wei, Gorry Fairhurst, The authors thank Yiqun Cai, Heidi Ou, Liming Wei, Gorry Fairhurst,
Bharat Joshi and Bill Atwood for 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):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
7.2. Informative References 7.2. Informative References
[HELLO-OPT] [HELLO-OPT] IANA, "PIM Hello Options", <http://www.iana.org/>.
IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per
RFC4601 http://www.iana.org/assignments/pim-hello-options,
March 2007.
[I-D.ietf-pim-port] [PIM-PORT] Farinacci, D., Wijnands, IJ., Venaas, S., and M.
Farinacci, D., Wijnands, I., Venaas, S., and M. Napierala, Napierala, "A Reliable Transport Mechanism for PIM", Work
"A Reliable Transport Mechanism for PIM", in Progress, August 2011.
draft-ietf-pim-port-06 (work in progress), March 2011.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
for Network Management of TCP/IP-based internets:MIB-II",
STD 17, RFC 1213, March 1991.
[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 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
Authors' Addresses Authors' Addresses
Sameer Gulrajani Sameer Gulrajani
cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sameerg@cisco.com EMail: sameerg@cisco.com
Stig Venaas Stig Venaas
cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: stig@cisco.com EMail: stig@cisco.com
 End of changes. 36 change blocks. 
115 lines changed or deleted 113 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/