idnits 2.17.1 draft-ietf-ospf-multi-instance-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2328, but the abstract doesn't seem to mention this, which it should. 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 (October 29, 2011) is 4553 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 (==), 3 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: May 1, 2012 Cisco Systems 7 October 29, 2011 9 OSPF Multi-Instance Extensions 10 draft-ietf-ospf-multi-instance-06.txt 12 Abstract 14 OSPFv3 includes a mechanism for supporting multiple instances on the 15 same interface. OSPFv2 could benefit from such a mechanism in order 16 to support multiple routing domains on the same subnet. The OSPFv2 17 instance ID is reserved for support of separate OSPFv2 protocol 18 instances. This is different from OSPFv3 where it could be used for 19 other purposes such as putting the same interface in multiple areas. 20 OSPFv2 supports this capability using a separate subnet or the OSPF 21 multi-area adjacency capability. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 1, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 59 2. OSPFv2 Instance Packet Encoding . . . . . . . . . . . . . . . 4 60 3. OSPF Interface Instance ID . . . . . . . . . . . . . . . . . . 6 61 3.1. Sending and Receiving OSPF packets . . . . . . . . . . . . 6 62 4. State Sharing Optimizations between OSPF instances . . . . . . 7 63 5. OSPFv2 Authentication Impacts . . . . . . . . . . . . . . . . 8 64 6. Backward Compatibility and Deployment Considerations . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 OSPFv3 [OSPFV3] includes a mechanism for supporting multiple 76 instances on the same interface. OSPFv2 [OSPFV2] could benefit from 77 such a mechanism in order to support multiple routing domains on the 78 same subnet. The OSPFv2 Interface Instance ID is reserved for 79 support of separate OSPFv2 protocol instances. This is different 80 from OSPFv3 where it could be used for other purposes such as putting 81 the same interface in multiple areas. OSPFv2 supports this 82 capability using a separate subnet or the OSPF multi-area adjacency 83 capability [MULTI-AREA]. 85 1.1. Requirements notation 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC-KEYWORDS]. 91 2. OSPFv2 Instance Packet Encoding 93 OSPFv2 currently doesn't offer a mechanism to differentiate packets 94 for different instances sent and received on the same interface. In 95 support of this capability, this document introduces a modified 96 packet header format with the Authentication Type field is split into 97 an Instance ID and AuType. 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Version # | Type | Packet length | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Router ID | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Area ID | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Checksum | Instance ID | AuType | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Authentication | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Authentication | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 The OSPFv2 Packet Header 117 Version # 118 The OSPF version number - 2 120 Type 121 The OSPF packet type as specified [OSPFV2]. 123 Packet length 124 The length of the OSPF protocol packet in bytes. This length 125 includes the standard OSPF header. 127 Router ID 128 The Router ID of the packet's source. 130 Area ID 131 A 32-bit number identifying the area corresponding the packet as 132 specified in [OSPFV2]. 134 Checksum 135 OSPF standard checksum calculation as specified in specified in 136 [OSPFV2]. 138 Instance ID 139 Enables multiple instances of OSPF to be used on a single 140 interface. Each protocol instance would be assigned a separate 141 Instance ID; the Instance ID has local subnet significance only. 142 Received packets with an Instance ID not equal to one of the 143 Instance IDs corresponding to one of the configured OSPF Instances 144 for the receiving interface MUST be discarded. 146 AuType 147 OSPF authentication type as specified in specified in [OSPFV2]. 149 Authentication 150 A 64-bit field for authentication data (dependent on the 151 Authentication Type as specified in the AuType field). 153 3. OSPF Interface Instance ID 155 OSPF [OSPFV2] describes the conceptual interface data structure in 156 section 9. The OSPF Interface Instance ID will be added to this 157 structure. The OSPF Interface Instance ID will default to 0. Its 158 setting to a non-zero value may be accomplished through configuration 159 or implied by some usage beyond the scope of this document. 161 3.1. Sending and Receiving OSPF packets 163 When sending OSPF packets, if the OSPF Interface Instance ID has a 164 non-zero value, it will be set in the OSPF packet header. When 165 receiving OSPF packets, the OSPF Header Instance ID will be used to 166 aid in demultiplexing the packet and routing it to the correct OSPF 167 instance. Received packets with an Instance ID not equal to one of 168 the configured OSPF Instance IDs on the receiving interface MUST be 169 discarded. 171 4. State Sharing Optimizations between OSPF instances 173 This is beyond the scope of this draft and is an area for further 174 study. 176 5. OSPFv2 Authentication Impacts 178 Now that the AuType OSPFv2 header field has been reduced from 2 179 octets to 1 octet, OSPF routers not supporting this specification 180 will fail packet authentication for any instance other than the 181 default (i.e., the Base IPv4 Unicast Instance). This is solely due 182 to the difference in field definition as opposed to any explicit 183 change to OSPFv2 authentication as described Appendix D, [OSPFV2] or 184 [RFC5709]. However, this is exactly what is desired since OSPF 185 routers not supporting this specification should only support the 186 default instance (Refer to Section 6). 188 6. Backward Compatibility and Deployment Considerations 190 When there are OSPF routers that support OSPF Multi-Instance 191 extensions on the same broadcast capable interface as OSPF routers 192 that do not, packets with non-zero OSPF header Instance IDs will be 193 received by those legacy OSPF routers. Since the non-zero Instance 194 ID will be included in the AuType by these legacy OSPF routers, it 195 will be misinterpreted as a mismatched authentication type and the 196 packet will be dropped. This is exactly what is expected and 197 desired. 199 Previously, there was concern that certain implementations would log 200 every single authentication type mismatch. Additionally, if 201 ospfIfAuthFailure SNMP generation is enabled as specified in 202 [OSPF-MIB], a separate trap would be generated for each received OSPF 203 packet with a non-zero Instance ID. However, discussions with 204 implementers have led us to the conclusion that this is not as severe 205 a problem as we'd first thought and it will be even less of a problem 206 by the time the mechanism in this draft is standardized, implemented, 207 and deployed. Most implementations will dampen both the logging of 208 errors and the generation of identical SNMP traps. Hence, the more 209 drastic mechanisms to avoid legacy OSPF routers from receiving 210 multicast OSPF packets with non-zero Instance IDs have been removed. 212 7. Security Considerations 214 The enhancement described herein doesn't add any additional security 215 considerations to OSPFv2. Security considerations for OSPFv2 are 216 described in [OSPFV2]. 218 Given that only three OSPFv2 authentication types have been 219 standardized, it seems reasonable to reduce the OSPF packet header 220 field to 8 bits. 222 8. IANA Considerations 224 A new registry will be added for OSPF Instance IDs. The allocation 225 of OSPF Instance IDs is described below. 227 +-------------+----------------------+--------------------+ 228 | Value/Range | Designation | Assignment Policy | 229 +-------------+----------------------+--------------------+ 230 | 0 | Base IPv4 Unicast | Assigned | 231 | | Instance | | 232 | | | | 233 | 1 | Base IPv4 Multicast | Assigned | 234 | | Instance | | 235 | | | | 236 | 2 | Base IPv4 In-band | Assigned | 237 | | Management Instance | | 238 | | | | 239 | 3-127 | Local Policy | Reserved for local | 240 | | | policy assignment | 241 | | | | 242 | 128-255 | Unassigned | Standards Action | 243 +-------------+----------------------+--------------------+ 245 OSPFv2 Instance ID 247 9. References 249 9.1. Normative References 251 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 253 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 254 for IPv6", RFC 5340, July 2008. 256 [RFC-KEYWORDS] 257 Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", RFC 2119, March 1997. 260 9.2. Informative References 262 [MULTI-AREA] 263 Mirtorabi, S., Psenak, P., Lindem, A., and A. Oswal, "OSPF 264 Multi-Area Adjacency", RFC 5185, May 2008. 266 [OSPF-MIB] 267 Joyal, D., Galecki, P., Giacalone, S., Baker, F., and R. 268 Coltun, "OSPF Version 2 Management Information Base", 269 RFC 4750, December 2006. 271 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 272 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 273 Authentication", RFC 5709, October 2009. 275 Appendix A. Acknowledgments 277 The RFC text was produced using Marshall Rose's xml2rfc tool. 279 Thanks to Paul Wells for commenting on the backward compatibility 280 issues. 282 Thanks to Paul Wells and Vladica Stanisic for commenting during the 283 OSPF WG last call. 285 Thanks to Manav Bhatia for comments and being the document shepherd. 287 Authors' Addresses 289 Acee Lindem 290 Ericsson 291 102 Carric Bend Court 292 Cary, NC 27519 293 USA 295 Email: acee.lindem@ericsson.com 297 Abhay Roy 298 Cisco Systems 299 225 West Tasman Drive 300 San Jose, CA 95134 301 USA 303 Email: akr@cisco.com 305 Sina Mirtorabi 306 Cisco Systems 307 3 West Plumeria Drive 308 San Jose, CA 95134 309 USA 311 Email: sina@cisco.com