idnits 2.17.1 draft-ietf-ospf-multi-instance-09.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 (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2012) is 4473 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Ericsson 4 Updates: 2328 (if approved) A. Roy 5 Intended status: Standards Track S. Mirtorabi 6 Expires: July 22, 2012 Cisco Systems 7 January 19, 2012 9 OSPFv2 Multi-Instance Extensions 10 draft-ietf-ospf-multi-instance-09.txt 12 Abstract 14 OSPFv3 includes a mechanism to support multiple instances of the 15 protocol running on the same interface. OSPFv2 can utilize such a 16 mechanism in order to support multiple routing domains on the same 17 subnet. 19 This document defines the OSPFv2 instance ID to enable separate 20 OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where 21 the instance ID can be used for multiple purposes, such as putting 22 the same interface in multiple areas, the OSPFv2 instance ID is 23 reserved for identifying protocol instances. 25 This document updates RFC 2328. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 22, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. OSPFv2 Instance Packet Encoding . . . . . . . . . . . . . . . 4 64 3. OSPFv2 Interface Instance ID . . . . . . . . . . . . . . . . . 5 65 3.1. Sending and Receiving OSPFv2 packets . . . . . . . . . . . 5 66 3.2. Interface Instance ID Values . . . . . . . . . . . . . . . 5 67 4. State Sharing Optimizations between OSPFv2 instances . . . . . 6 68 5. OSPFv2 Authentication Impacts . . . . . . . . . . . . . . . . 7 69 6. Backward Compatibility and Deployment Considerations . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 OSPFv3 [OSPFV3] includes a mechanism to support multiple instances of 81 the protocol running on the same interface. OSPFv2 [OSPFV2] can 82 utilize such a mechanism in order to support multiple routing domains 83 on the same subnet. 85 This document defines the OSPFv2 instance ID to enable separate 86 OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where 87 the instance ID can be used for multiple purposes, such as putting 88 the same interface in multiple areas, the OSPFv2 instance ID is 89 reserved for identifying protocol instances. 91 1.1. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC-KEYWORDS]. 97 2. OSPFv2 Instance Packet Encoding 99 This document extends OSPFv2 with a mechanism to differentiate 100 packets for different instances sent and received on the same 101 interface. In support of this capability, a modified packet header 102 format with the Authentication Type field split into an Instance ID 103 and AuType. 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Version # | Type | Packet length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Router ID | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Area ID | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Checksum | Instance ID | AuType | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Authentication | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Authentication | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 The OSPFv2 Packet Header 123 All fields are as defined in [OSPFV2] except that the Instance ID 124 field is new, and the AuType field is reduced to 8 bits from 16 bits 125 without any change in meaning. The Instance ID field is defined as 126 follows: 128 Instance ID 129 Enables multiple instances of OSPFv2 to be used on a single 130 interface. Each protocol instance would be assigned a separate 131 Instance ID; the Instance ID has local subnet significance only. 132 Received packets with an Instance ID not equal to one of the 133 Instance IDs corresponding to one of the configured OSPFv2 134 Instances for the receiving interface MUST be discarded. 136 3. OSPFv2 Interface Instance ID 138 [OSPFV2] describes the conceptual interface data structure in section 139 9. The OSPFv2 Interface Instance ID is added to this structure. The 140 OSPFv2 Interface Instance ID has a default value of 0. Its setting 141 to a non-zero value may be accomplished through configuration. 143 3.1. Sending and Receiving OSPFv2 packets 145 When sending OSPFv2 packets, the OSPFv2 Interface Instance ID is set 146 in the OSPFv2 packet header. When receiving OSPFv2 packets, the 147 OSPFv2 Header Instance ID is used to aid in demultiplexing the packet 148 and routing it to the correct OSPFv2 instance. Received packets with 149 an Instance ID not equal to one of the configured OSPFv2 Instance IDs 150 on the receiving interface MUST be discarded. 152 3.2. Interface Instance ID Values 154 The following OSPFv2 Instance IDs have been defined: 156 0 157 Base IPv4 Instance - This is the default IPv4 routing instance 158 corresponding to default IPv4 unicast routing and the attendant 159 IPv4 routing table. Use of this instance ID provides backward 160 compatibility with the base OSPF specification [OSPFV2]. 162 1 163 Base IPv4 Multicast Instance - This IPv4 instance corresponds to 164 the separate IPv4 routing table used for the Reverse Path 165 Forwarding (RPF) checking performed on IPv4 multicast traffic. 167 2 168 Base IPv4 In-band Management Instance - This IPv4 instance 169 corresponds to a separate IPv4 routing table used for network 170 management applications. 172 3-127 173 Private Use - These Instance IDs are reserved for definition and 174 semantics defined by the local network administrator. For 175 example, separate Interface Instance IDs and their corresponding 176 OSPFv2 instances could be used to support independent non- 177 congruent topologies for different classes of IPv4 unicast 178 traffic. The details of such deployments are beyond the scope of 179 this document. 181 The first three Interface Instance IDs are analogous to the topology 182 IDs defined in [RFC4915]. 184 4. State Sharing Optimizations between OSPFv2 instances 186 This is beyond the scope of this draft and is an area for further 187 study. 189 5. OSPFv2 Authentication Impacts 191 Now that the AuType OSPFv2 header field has been reduced from 2 192 octets to 1 octet, OSPFv2 routers not supporting this specification 193 will fail packet authentication for any instance other than the 194 default (i.e., the Base IPv4 Unicast Instance). This is solely due 195 to the difference in field definition as opposed to any explicit 196 change to OSPFv2 authentication as described in Appendix D of RFC 197 2328 [OSPFV2] and RFC 5709 [RFC5709]. However, this is exactly what 198 is desired since OSPFv2 routers not supporting this specification 199 should only support the default instance (Refer to Section 6). 201 6. Backward Compatibility and Deployment Considerations 203 When there are OSPFv2 routers that support OSPFv2 Multi-Instance 204 extensions on the same broadcast capable interface as OSPFv2 routers 205 that do not, packets with non-zero OSPFv2 header Instance IDs are 206 received by those legacy OSPFv2 routers. Since the non-zero Instance 207 ID is included in the AuType by these legacy OSPFv2 routers, it is 208 misinterpreted as a mismatched authentication type and the packet is 209 dropped. This is exactly what is expected and desired. 211 Previously, there was concern that certain implementations would log 212 every single authentication type mismatch. However, discussions with 213 implementers have led us to the conclusion that this is not as severe 214 a problem as we'd first thought and it will be even less of a problem 215 by the time the mechanism in this draft is standardized, implemented, 216 and deployed. Most implementations will dampen the logging of 217 errors. Hence, the more drastic mechanisms to avoid legacy OSPFv2 218 routers from receiving multicast OSPFv2 packets with non-zero 219 Instance IDs have been removed. 221 If the OSPF MIB as specified in [OSPF-MIB] is implemented, even the 222 damped generation of the ospfIfAuthFailure or ospfVirtIfAuthFailure 223 SNMP notifications would be undesirable in situations where legacy 224 OSPFv2 routers are deployed on the same subnet as OSPFv2 routers 225 supporting this specification. Consequently, it is recommended that 226 implementations that implement this specification and the OSPF MIB 227 also implement SNMP Notification filtering as specified in section 6 228 of [RFC3413]. 230 7. Security Considerations 232 The enhancement described herein doesn't add any additional security 233 considerations to OSPFv2. Security considerations for OSPFv2 are 234 described in [OSPFV2]. 236 Given that only three OSPFv2 authentication types have been 237 standardized, it seems reasonable to reduce the OSPFv2 packet header 238 field to 8 bits. 240 8. IANA Considerations 242 The size of the AuType field is reduced from 16 octets to 8 octets. 243 This changes the OSPF Authentication Codes registry in that the 244 values 256-65535 are no longer defined. There is no backward 245 compatibility issue since this range of values was previously defined 246 as "Reserved and should not be assigned". 248 A new registry is added for OSPFv2 Instance IDs. The allocation of 249 OSPFv2 Instance IDs is described below. Refer to Section 3.2 for 250 more information. 252 +-------------+----------------------+--------------------+ 253 | Value/Range | Designation | Assignment Policy | 254 +-------------+----------------------+--------------------+ 255 | 0 | Base IPv4 Unicast | Assigned | 256 | | Instance | | 257 | | | | 258 | 1 | Base IPv4 Multicast | Assigned | 259 | | Instance | | 260 | | | | 261 | 2 | Base IPv4 In-band | Assigned | 262 | | Management Instance | | 263 | | | | 264 | 3-127 | Private Use | Reserved for local | 265 | | | policy assignment | 266 | | | | 267 | 128-255 | Unassigned | Standards Action | 268 +-------------+----------------------+--------------------+ 270 OSPFv2 Instance ID 272 9. References 274 9.1. Normative References 276 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 278 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 279 for IPv6", RFC 5340, July 2008. 281 [RFC-KEYWORDS] 282 Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", RFC 2119, March 1997. 285 9.2. Informative References 287 [OSPF-MIB] 288 Joyal, D., Galecki, P., Giacalone, S., Baker, F., and R. 289 Coltun, "OSPF Version 2 Management Information Base", 290 RFC 4750, December 2006. 292 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 293 Management Protocol (SNMP) Applications", STD 62, 294 RFC 3413, December 2002. 296 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 297 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 298 RFC 4915, June 2007. 300 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 301 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 302 Authentication", RFC 5709, October 2009. 304 Appendix A. Acknowledgments 306 The RFC text was produced using Marshall Rose's xml2rfc tool. 308 Thanks to Adrian Farrel for review and providing some suggested 309 improvements during the IESG review. 311 Thanks to Paul Wells for commenting on the backward compatibility 312 issues. 314 Thanks to Paul Wells and Vladica Stanisic for commenting during the 315 OSPF WG last call. 317 Thanks to Manav Bhatia for comments and being the document shepherd. 319 Thanks to Magnus Nystrom for comments under the auspices of the 320 Security Directorate review. 322 Thanks to Dan Romascanu for comments during the IESG review. 324 Thanks to Pete McCann for comments under the auspices of the Gen-ART 325 review. 327 Authors' Addresses 329 Acee Lindem 330 Ericsson 331 102 Carric Bend Court 332 Cary, NC 27519 333 USA 335 Email: acee.lindem@ericsson.com 337 Abhay Roy 338 Cisco Systems 339 225 West Tasman Drive 340 San Jose, CA 95134 341 USA 343 Email: akr@cisco.com 345 Sina Mirtorabi 346 Cisco Systems 347 3 West Plumeria Drive 348 San Jose, CA 95134 349 USA 351 Email: sina@cisco.com