idnits 2.17.1 draft-ietf-pim-hello-intid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 7, 2011) is 4706 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- Duplicate reference: RFC4601, mentioned in 'HELLO-OPT', was also mentioned in 'RFC4601'. -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'HELLO-OPT') (Obsoleted by RFC 7761) == Outdated reference: A later version (-09) exists of draft-ietf-pim-port-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Gulrajani 3 Internet-Draft S. Venaas 4 Intended status: Standards Track cisco Systems 5 Expires: December 9, 2011 June 7, 2011 7 An Interface ID Hello Option for PIM 8 draft-ietf-pim-hello-intid-01.txt 10 Abstract 12 This document defines a new PIM Hello option to advertise an 13 interface identifier that can be used by PIM protocols to uniquely 14 identify an interface of a neighboring router. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 9, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 52 2. Interface Identifier Option . . . . . . . . . . . . . . . . . 4 53 2.1. Local Interface Identifier . . . . . . . . . . . . . . . . 4 54 2.2. Router Identifier . . . . . . . . . . . . . . . . . . . . 4 55 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 64 1. Introduction 66 This document defines a new option for use in PIM Hello messages 67 [RFC4601] to carry an Interface Identifier. A router generates 68 identifiers for each of its PIM enabled interfaces such that each 69 interface has a different identifier. The identifiers can optionally 70 be generated such that they are unique within, e.g., an 71 administrative domain. 73 An example where this Interface Identifier can be used is with PIM 74 PORT [I-D.ietf-pim-port], where a single Transport connection is used 75 between two routers that have multiple interfaces connecting them. 76 If these interfaces have unnumbered or IPv6 Link local addresses, the 77 Interface Identifier included in the PORT Join/Prune message will 78 identify which interface the message is associated with. For PIM 79 PORT the Router Identifier is not needed, and it can be set to zero. 81 1.1. Requirements Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Interface Identifier Option 89 The Interface Identifier option is used to identify which interface 90 of a neighboring router a PIM Hello [RFC4601] is sent on. This 91 allows PIM protocols to refer to, or identify, a particular interface 92 on a neighboring router. 94 The Interface Identifier option need only be included in PIM Hello 95 messages if the router supports protocols that require it. An 96 implementation MAY choose to always include it. How exactly the 97 Interface Identifier is used, and the uniqueness requirements, is 98 left to the specifications of the PIM protocols that make use of it. 99 It is assumed that different protocols may have different minimum 100 requirements for stability and uniqueness of the interface 101 identifier, but that they have no maximum requirement. When 102 specified, these protocols should indicate what their minimum 103 requirements are. 105 The Interface Identifier consists of 64 bits. The lower 32 bits form 106 a Local Interface Identifier, and the high 32 bits a Router 107 Identifier. 109 2.1. Local Interface Identifier 111 The 32 bit Local Interface Identifier is selected such that it is 112 unique among the router's PIM enabled interfaces. That is, there 113 MUST NOT be two PIM interfaces with the same Local Interface 114 Identifier. While an interface is up, the Identifier MUST always be 115 the same once it has been allocated. If an interface goes down and 116 comes up, the router SHOULD use the same Identifier. Many systems 117 make use of an ifIndex [RFC1213], which can be used as a Local 118 Interface Identifier. 120 The Local Interface Identifier MUST be non-zero. The reason for 121 this, is that some protocols may want to only optionally refer to an 122 Interface using the Interface Identifier Hello option, and use the 123 value of 0 to show that it is not referred to. Note that the value 124 of 0 is not a valid ifIndex as defined in [RFC1213]. 126 2.2. Router Identifier 128 The 32 bit Router Identifier may be used to uniquely identify the 129 router. It may be selected to be unique within some administrative 130 domain, or possibly globally unique. The requirements for the scope 131 in which it needs to be unique depend on the protocol that utilizes 132 this. A router implementation MAY choose an IPv4 unicast address 133 assigned to the router as the Router Identifer, but MUST allow the 134 identifier to be configured manually. Protocols such as BGP 136 [RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32 137 bit identifiers for routers. One may use the same identifier to 138 construct the Interface Identifier option, provided it meets the 139 stability and uniqueness requirements of protocols making use of this 140 option. 142 The value 0 has a special meaning for the Router Identifier. It 143 means that no Router Identifier is used. If a router only supports 144 protocols that require the Interface Identifier to be unique for one 145 router (only making use of the Local Interface Identifier), then the 146 implementation MAY set the Router Identifier to zero. 148 3. Message Format 150 Option Type: Interface Identifier 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type = 31 | Length = 8 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Router Identifier | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Local Interface Identifier | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Allocated Hello Type values can be found in [HELLO-OPT]. 164 Length: In bytes for the value part of the Type/Length/Value 165 encoding. The Interface Identifier will be 8 bytes long. 167 Router Identifier: The Router Identifier is a 4 byte identifier 168 uniquely identifying the router within some scope. It MAY be 0 169 when no protocols require a Router Identifier. 171 Local Interface Identifier: The Local Interface Identifier is a 4 172 byte identifier that is unique among all PIM enabled interfaces on 173 a router. 175 4. Security Considerations 177 The Interface Identifier is included in PIM Hello messages. See 178 [RFC4601] for security considerations regarding PIM Hello messages. 179 In particular, PIM Hello messages may be forged, and may include an 180 arbitrary Interface Identifier, or the Interface Identifier may be 181 intentionally omitted. The effects of this depend on how the 182 Interface Identifier is used by other protocols. 184 5. IANA Considerations 186 IANA has temporarily assigned the value 31 for the Interface 187 Identifier Hello option defined in this document. IANA is requested 188 to make this assignment permanent. 190 6. Acknowledgments 192 The authors thank Yiqun Cai, Heidi Ou, Liming Wei, Gorry Fairhurst, 193 Bharat Joshi and Bill Atwood for providing valuable feedback. 195 7. References 197 7.1. Normative References 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 202 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 203 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 204 Protocol Specification (Revised)", RFC 4601, August 2006. 206 7.2. Informative References 208 [HELLO-OPT] 209 IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per 210 RFC4601 http://www.iana.org/assignments/pim-hello-options, 211 March 2007. 213 [I-D.ietf-pim-port] 214 Farinacci, D., Wijnands, I., Venaas, S., and M. Napierala, 215 "A Reliable Transport Mechanism for PIM", 216 draft-ietf-pim-port-06 (work in progress), March 2011. 218 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 219 for Network Management of TCP/IP-based internets:MIB-II", 220 STD 17, RFC 1213, March 1991. 222 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 224 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 225 Protocol 4 (BGP-4)", RFC 4271, January 2006. 227 Authors' Addresses 229 Sameer Gulrajani 230 cisco Systems 231 Tasman Drive 232 San Jose, CA 95134 233 USA 235 Email: sameerg@cisco.com 237 Stig Venaas 238 cisco Systems 239 Tasman Drive 240 San Jose, CA 95134 241 USA 243 Email: stig@cisco.com