idnits 2.17.1 draft-ietf-ospf-af-alt-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 427. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 433. 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 Copyright Line does not match the current year -- 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 (April 5, 2007) is 6203 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 2740 (ref. 'OSPFV3') (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem (Editor) 3 Internet-Draft Redback Networks 4 Intended status: Standards Track S. Mirtorabi 5 Expires: October 7, 2007 Force10 Networks 6 A. Roy 7 M. Barnes 8 Cisco Systems 9 R. Aggarwal 10 Juniper Networks 11 April 5, 2007 13 Support of address families in OSPFv3 14 draft-ietf-ospf-af-alt-05.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 7, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document describes a mechanism for supporting multiple address 48 families in OSPFv3 using multiple instances. It maps an address 49 family (AF) to an OSPFv3 instance using the Instance ID field in the 50 OSPFv3 packet header. This approach is fairly simple and minimizes 51 extensions to OSPFv3 for supporting multiple AFs. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Design Considerations . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 2. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Instance ID values for new AFs . . . . . . . . . . . . . . 4 60 2.2. OSPFv3 Options and Prefix Options Changes . . . . . . . . 4 61 2.2.1. OSPFv3 Options . . . . . . . . . . . . . . . . . . . . 4 62 2.2.2. Prefix Options . . . . . . . . . . . . . . . . . . . . 5 63 2.3. Advertising Prefixes in new AFs . . . . . . . . . . . . . 5 64 2.4. Changes to the Hello processing . . . . . . . . . . . . . 6 65 2.5. Next hop for IPv4 unicast and multicast AFs . . . . . . . 6 66 2.6. Operation over Virtual Links . . . . . . . . . . . . . . . 7 67 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 75 Intellectual Property and Copyright Statements . . . . . . . . . . 15 77 1. Introduction 79 OSPFv3 has been defined to support the base IPv6 unicast Address 80 Family (AF). There is a requirement to advertise other AFs in OSPFv3 81 including multicast IPv6, unicast IPv4, and multicast IPv4. This 82 document supports these other AFs in OSPFv3 by mapping each to a 83 separate Instance ID and OSPFv3 instance. 85 1.1. Design Considerations 87 This section describes the rationale for using the multiple instance 88 ID approach to support multiple address families in OSPFv3. As 89 described earlier, OSPFv3 is designed to support multiple instances. 90 Hence mapping an instance to an address family doesn't introduce any 91 new mechanisms to the protocol. It minimizes the protocol extensions 92 required and it simplifies the implementation. The presence of a 93 separate link state database per address family is also easier to 94 debug and operate. Additionally, it doesn't change the existing 95 instance, area, and interface based configuration model in most 96 OSPFv3 implementations. 98 1.2. Requirements notation 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC-KEYWORDS]. 104 2. Protocol Details 106 Currently the entire Instance ID number space is used for IPv6 107 unicast. This specification assigns different Instance ID ranges to 108 different AFs in order to support other AFs in OSPFv3. Each Instance 109 ID implies a separate OSPFv3 instance with its own neighbor 110 adjacencies, link state database, protocol data structures, and 111 shortest path first (SPF) computation. Additionally, the current 112 LSAs that are defined to advertise IPv6 unicast prefixes can be used 113 without any modifications to advertise prefixes from other AFs. 115 It should be noted that OSPFv3 is running on the top of IPv6 and uses 116 IPv6 link local addresses for OSPFv3 control packets and next hop 117 calculations. Therefore, it is required that IPv6 be enabled on a 118 link, although the link may not be participating in the IPv6 unicast 119 AF. 121 2.1. Instance ID values for new AFs 123 Instance ID zero is already defined by default for the IPv6 unicast 124 AF. We define the following ranges for different AFs. The first 125 value of each range is considered as the default value for the 126 corresponding AF. 128 Instance ID # 0 - # 31 IPv6 unicast AF 129 Instance ID # 32 - # 63 IPv6 multicast AF 130 Instance ID # 64 - # 95 IPv4 unicast AF 131 Instance ID # 96 - # 127 IPv4 multicast AF 132 Instance ID # 128 - # 255 Unassigned 134 OSPFv3 Instance IDs 136 2.2. OSPFv3 Options and Prefix Options Changes 138 A new bit is added to the OSPFv3 options field. A couple of the 139 option bits are only applicable to the IPv6 unicast AF. 141 2.2.1. OSPFv3 Options 143 1 2 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 146 | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|MC| E|V6| 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 149 The Options field 150 OSPFv3 Options 152 V6-bit 153 The V6 bit is used in OSPFv3 to exclude a node from IPv6 unicast 154 route calculation but allow it in the SPF calculation for other 155 address families. Since Instance ID now denotes the AF 156 explicitly, this bit is ignored in AFs other than IPv6 unicast. 158 MC-bit 159 This bit is not used in other AFs introduced in this document. 161 AF-bit 162 When a router supports AF, it MUST set this new bit in the OSPFv3 163 Options field of Hello Packets, DD packets, and LSAs. 165 2.2.2. Prefix Options 167 0 1 2 3 4 5 6 7 168 +--+--+--+--+--+--+--+--+ 169 | | | | | P|* |LA|NU| 170 +--+--+--+--+--+--+--+--+ 172 Prefix Options 174 MC-bit 175 This bit is ignored in AFs other than IPv6 Unicast. 177 NU-bit 178 The NU bit MUST be clear in all unicast AFs and it MUST be set in 179 all multicast AFs. 181 Note that all bits unused in a given AF MAY be redefined for AF 182 specific purposes in future specifications. 184 2.3. Advertising Prefixes in new AFs 186 Each Prefix defined in OSPFv3 has a prefix length field. This 187 facilitate advertising prefixes of different lengths in different 188 AFs. The existing LSAs defined in OSPFv3 are used for this purpose 189 and there is no need to define new LSAs. 191 2.4. Changes to the Hello processing 193 When a router does not support an AF but it is configured the 194 corresponding Instance ID packets could be black holed. This could 195 happen due to misconfiguration or a router software downgrade. Black 196 holing is possible because the router which doesn't support the AF 197 can still be included in the SPF calculated path as long as it 198 establishes adjacencies using the Instance ID corresponding to the 199 AF. Note that router and network LSAs are AF independent. 201 In order to avoid the above situation, hello processing is changed in 202 order to only establish adjacencies with routers that have the AF-bit 203 set in their Options field. 205 Receiving Hello Packets is specified in section 3.2.2.1 of [OSPFV3]. 206 The following check is added to Hello reception: 208 o When a router participates in an AF (sets the AF-bit in Options 209 field) it MUST discard Hello packets having the AF-bit clear in 210 the Options field. The only exception is IPv6 unicast AF, where 211 this check MUST NOT be done (for backward compatibility). 213 2.5. Next hop for IPv4 unicast and multicast AFs 215 OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses for 216 OSPFv3 control packets and next hop calculations. Although IPV6 link 217 local addresses could be used as next hops for IPv4 address families, 218 it is desirable to have IPv4 next hop addresses. For example, in 219 IPv4 multicast having the next hop address the same as the Protocol 220 Independent Multicast (PIM) [PIM] neighbor address (IPv4 address) 221 makes it easier to determine which upstream neighbor to send a PIM 222 join when doing a Reverse Path Forwarding (RPF) lookup. It is also 223 easier for troubleshooting to have a next hop with the same AF. 225 In order to achieve this, the link's IPv4 address will be advertised 226 in the "link local address" field of the IPv4 instance's Link-LSA. 227 This address is placed in the first 32 bit of "link local address" 228 field and used for IPv4 next hop calculations. 230 We call direct interface address (DIA) the address that is reachable 231 directly via the link provided that a layer 3 to layer 2 mapping is 232 available. Note that there is no explicit need for the IPv4 link 233 addresses to be on the same subnet. An implementation should resolve 234 layer 3 to layer 2 mappings via Address Resolution Protocol (ARP) 235 [ARP] or Neighbor Discovery (ND) [ND] for a DIA even if the IPv4 236 address is not on the same subnet as the router's interface IP 237 address. 239 2.6. Operation over Virtual Links 241 OSPFv3 control packets sent over a virtual link are IPv6 packets and 242 may traverse multiples hops. Therefore, there must be a global IPv6 243 address associated with the virtual link so that the control packet 244 is forwarded correctly by the intermediate hops between virtual link 245 endpoints. Although this requirement can be satisfied in IPv6 246 unicast AFs, it will not function in other AFs as there will not be a 247 routable global IPv6 address or forwarding path. Therefore, virtual 248 links are not supported in AFs other than IPv6 Unicast. 250 3. Backward Compatibility 252 In this section, we will define a non-capable OSPFv3 router as one 253 not supporting this specification. Each new AF will have a 254 corresponding Instance ID and can interoperate with the existing non- 255 capable OSPFv3 routers in an IPv6 unicast topology. Furthermore, 256 when a non-capable OSPFv3 router uses an Instance ID which is 257 reserved for a given AF, no adjacency will be formed with this router 258 since the AF-bit in the Options field will not be set in Hello 259 packets. Therefore, there are no backward compatibility issues. AFs 260 can be gradually deployed without disturbing networks with non- 261 capable OSPFv3 routers. 263 4. Security Considerations 265 The function described in this document does not create any new 266 security issues for the OSPF protocol. Security considerations for 267 the OSPFv3 are covered in [OSPFV3]. 269 5. IANA Considerations 271 The following IANA assignments are to be made from existing 272 registries: 274 o An OSPFv3 options bit will be allocated for support of address 275 families using separate instances. 277 IANA is requested to create a new registry, "OSPFv3 Instance ID 278 Address Family Values". for assignment of address families IDs. Note 279 that the Instance ID MAY be used for applications other than the 280 support of multiple address families. However, if it is being used 281 for address families the assignments herein should be honored. 283 +-------------+----------------------+--------------------+ 284 | Value/Range | Designation | Assignment Policy | 285 +-------------+----------------------+--------------------+ 286 | 0 | Base IPv6 Unicast AF | Already assigned | 287 | | | | 288 | 1-31 | IPv6 Unicast AFs | Already assigned | 289 | | dependent on local | | 290 | | policy | | 291 | | | | 292 | 32 | Base IPv6 Multicast | Already assigned | 293 | | | | 294 | 33-63 | IPv6 Multicast AFs | Already assigned | 295 | | dependent on local | | 296 | | policy | | 297 | | | | 298 | 64 | Base IPv4 Unicast AF | Already assigned | 299 | | | | 300 | 65-95 | IPv4 Unicast AFs | Already assigned | 301 | | dependent on local | | 302 | | policy | | 303 | | | | 304 | 96 | Base IPv4 Multicast | Already assigned | 305 | | | | 306 | 97-127 | IPv4 Multicast AFs | Already assigned | 307 | | dependent on local | | 308 | | policy | | 309 | | | | 310 | 128-255 | Unassigned | Standards Action | 311 +-------------+----------------------+--------------------+ 313 OSPFv3 Address Family Use of Instance IDs 315 o Instancs IDs 0-127 are assigned by this specification. 317 o Instance IDs in the range 128-255 are not assigned at this time. 318 Before any assignments can be made in this range, there MUST be a 319 Standards Track RFC including IANA Considerations explicitely 320 specifying the AF Instance IDs being assigned. 322 6. References 324 6.1. Normative References 326 [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 327 RFC 2740, December 1999. 329 [RFC-KEYWORDS] 330 Bradner, S., "Key words for use in RFC's to Indicate 331 Requirement Levels", RFC 2119, March 1997. 333 6.2. Informative References 335 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", 336 RFC 826, November 1982. 338 [ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 339 Discovery for IP Version 6 (IPv6)", RFC 2461, 340 December 1998. 342 [PIM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 343 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 344 Protocol Specification (Revised)", RFC 4601, August 2006. 346 Appendix A. Acknowledgments 348 The RFC text was produced using Marshall Rose's xml2rfc tool. 350 Thanks to Tom Henderson and the folks at Boeing for implementing in 351 quagga. 353 Authors' Addresses 355 Acee Lindem 356 Redback Networks 357 102 Carric Bend Court 358 Cary, NC 27519 359 USA 361 Email: acee@redback.com 363 Sina Mirtorabi 364 Force10 Networks 365 350 Holger Way 366 San Jose, CA 95134 367 USA 369 Email: sina@force10networks.com 371 Abhay Roy 372 Cisco Systems 373 225 West Tasman Drive 374 San Jose, CA 95134 375 USA 377 Email: akr@cisco.com 379 Michael Barnes 380 Cisco Systems 381 225 West Tasman Drive 382 San Jose, CA 95134 383 USA 385 Email: mjbarnes@cisco.com 387 Rahul Aggarwal 388 Juniper Networks 389 1194 N. Mathilda Ave. 390 Sunnyvale, CA 94089 391 USA 393 Email: rahul@juniper.net 395 Full Copyright Statement 397 Copyright (C) The IETF Trust (2007). 399 This document is subject to the rights, licenses and restrictions 400 contained in BCP 78, and except as set forth therein, the authors 401 retain all their rights. 403 This document and the information contained herein are provided on an 404 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 405 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 406 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 407 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 408 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 409 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 411 Intellectual Property 413 The IETF takes no position regarding the validity or scope of any 414 Intellectual Property Rights or other rights that might be claimed to 415 pertain to the implementation or use of the technology described in 416 this document or the extent to which any license under such rights 417 might or might not be available; nor does it represent that it has 418 made any independent effort to identify any such rights. Information 419 on the procedures with respect to rights in RFC documents can be 420 found in BCP 78 and BCP 79. 422 Copies of IPR disclosures made to the IETF Secretariat and any 423 assurances of licenses to be made available, or the result of an 424 attempt made to obtain a general license or permission for the use of 425 such proprietary rights by implementers or users of this 426 specification can be obtained from the IETF on-line IPR repository at 427 http://www.ietf.org/ipr. 429 The IETF invites any interested party to bring to its attention any 430 copyrights, patents or patent applications, or other proprietary 431 rights that may cover technology that may be required to implement 432 this standard. Please address the information to the IETF at 433 ietf-ipr@ietf.org. 435 Acknowledgment 437 Funding for the RFC Editor function is provided by the IETF 438 Administrative Support Activity (IASA).