idnits 2.17.1 draft-ietf-ospf-af-alt-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (September 28, 2006) is 6391 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) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 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 S. Mirtorabi 4 Intended status: Standards Track A. Roy 5 Expires: April 1, 2007 M. Barnes 6 Cisco Systems 7 Q. Vohra 8 R. Aggarwal 9 Juniper Networks 10 September 28, 2006 12 Support of address families in OSPFv3 13 draft-ietf-ospf-af-alt-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 1, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document describes a mechanism for supporting multiple address 47 families in OSPFv3 using multiple instances. It maps an address 48 family (AF) to an OSPFv3 instance using the Instance ID field in the 49 OSPFv3 packet header. This approach is fairly simple and minimizes 50 extensions to OSPFv3 for supporting multiple AF's. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Design Considerations . . . . . . . . . . . . . . . . . . 3 56 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Instance ID values for new AF's . . . . . . . . . . . . . 4 59 2.2. OSPFv3 Options and Prefix Options Chnages . . . . . . . . 4 60 2.2.1. OSPFv3 Options . . . . . . . . . . . . . . . . . . . . 4 61 2.2.2. Prefix Options . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Advertising Prefixes in new AF's . . . . . . . . . . . . . 5 63 2.4. Changes to the Hello processing . . . . . . . . . . . . . 5 64 2.5. Next hop for IPv4 unicast and multicast AF's . . . . . . . 6 65 2.6. Operation over Virtual Links . . . . . . . . . . . . . . . 6 66 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . . . . 15 74 1. Introduction 76 OSPFv3 has been defined to support IPv6 unicast AF. There is a need 77 to carry other AFs in OSPFv3 such as multicast IPv6, unicast or 78 multicast IPv4. This document introduces these other AFs in OSPFv3 79 by reserving Instance IDs and using one OSPFv3 instance for one AF. 81 1.1. Design Considerations 83 This section describes the rationale for adopting the multiple 84 instance ID approach for supporting multiple address families in 85 OSPFv3. As described earlier, OSPFv3 is designed to support multiple 86 instances. Hence mapping an instance to an address family doesn't 87 introduce new mechanisms in the protocol. It minimizes the protocol 88 extensions required and it simplifies the implementation. The 89 presence of a separate link state database per address family is also 90 easier to debug and operate. Additionally, it doesn't change the 91 existing instance, area and interface based configuration model in 92 most OSPF implementations. 94 1.2. Requirements notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC2119 [RFC2119]. 100 2. Proposed Solution 102 Currently the entire Instance ID number space is used for IPv6 103 unicast. We propose to assign different ranges to different AF's in 104 order to support other AF's in OSPFv3. Each AF will establish 105 different adjacency, have different link state database and compute 106 different shortest path tree. Additionally, the current LSAs that 107 are defined to carry IPv6 unicast prefix can be used without any 108 modification in different instances to carry different AF's prefixes. 110 It should be noted that OSPFv3 is running on the top of IPv6 and uses 111 IPv6 link local address for OSPFv3 control packet and next hop 112 calculation. Therefore, it is required that IPv6 be enabled on a 113 link, although the link may not be participating in IPv6 unicast AF. 115 2.1. Instance ID values for new AF's 117 Instance ID zero is already used by default for IPv6 unicast AF. We 118 define the following ranges for different AF's. The first value of 119 each range is considered as the default value for the corresponding 120 AF. 122 Instance ID # 0 - # 31 IPv6 unicast AF 123 Instance ID # 32 - # 63 IPv6 multicast AF 124 Instance ID # 64 - # 95 IPv4 unicast AF 125 Instance ID # 96 - # 127 IPv4 multicast AF 126 Instance ID # 128 - # 255 Reserved 128 OSPFv3 Instance IDs 130 2.2. OSPFv3 Options and Prefix Options Chnages 132 A new bit is added to the OSPFv3 options field and a couple of the 133 bits are only applicable to the IPv6 unicast AF. 135 2.2.1. OSPFv3 Options 137 1 2 138 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 140 | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|MC| E|V6| 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 143 The Options field 145 OSPFv3 Options 147 V6-bit 148 The V6 bit is used in OSPFv3 to exclude a node from IPv6 unicast 149 route calculation but allow it in the SPF calculation for other 150 address families. Since Instance ID now denotes the AF 151 explicitly, this bit is ignored in AF's other than IPv6 unicast. 153 MC-bit 154 This bit is not used in other AF's introduced in this document. 156 AF-bit 157 When a router supports AF, it MUST set this new bit in the Options 158 field of Hello Packets, DD packets and LSAs. 160 2.2.2. Prefix Options 162 0 1 2 3 4 5 6 7 163 +--+--+--+--+--+--+--+--+ 164 | | | | | P|* |LA|NU| 165 +--+--+--+--+--+--+--+--+ 167 Prefix Options 169 MC-bit 170 This bit is not used in other AF's introduced in this document. 172 NU-bit 173 The NU bit must be clear in all unicast AF's and it must be set in 174 all multicast AF's. 176 Note that all bits unused in a given AF could be redefined later. 178 2.3. Advertising Prefixes in new AF's 180 Each Prefix defined in OSPFv3 has a prefix length field. This 181 facilitate advertising prefixes of different lengths in different 182 AF's. The existing LSAs defined in OSPFv3 are used for this purpose 183 and there is no need to define new LSAs. 185 2.4. Changes to the Hello processing 187 When a router does not support an AF but it is configured with an 188 Instance ID in the same range, packets could be blackholed. This 189 could happen due to misconfiguration or router downgrade to a 190 previous code level. Blackholing is possible because the router 191 which doesn't support the AF can still be included in the SPF 192 calculated path as long as it establishes adjacencies using the 193 Instance ID corresponding to the AF. Note that router and network 194 LSAs are AF independent. 196 In order to avoid the above situation, hello processing is changed in 197 order to only establish adjacency with the routers that have the AF- 198 bit set in their Options field. 200 Receiving Hello Packets is specified in section 3.2.2.1 of [OSPFV3]. 201 The following check is added to Hello reception: 203 o When a router participate in an AF (sets the AF-bit in Options 204 field) it MUST discard Hello packets having the AF-bit clear in 205 the Options field. The only exception is IPv6 unicast AF, where 206 this check MUST NOT be done (to help backward compatibility). 208 2.5. Next hop for IPv4 unicast and multicast AF's 210 OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses for 211 OSPFv3 control packets and next hop calculations. Although IPV6 link 212 local addresses could be used as next hops for IPv4 address families, 213 it is desirable to have IPv4 next hop addresses. For example, in 214 IPv4 multicast having the nexthop address the same as the PIM 215 neighbor address (IPv4 address) makes it easier to know to which 216 upstream neighbor to send a PIM join when doing a RPF lookup for a 217 source. It is also easier for troubleshooting purposes to have a 218 next hop with the same semantics as the AF. 220 In order to achieve this, the link's IPv4 address will be advertised 221 in the "link local address" field of the IPv4 instance's Link-LSA. 222 This address is placed in the first 32 bit of "link local address" 223 field and used for IPv4 next hop calculations. 225 We call direct interface address (DIA) the address that is reachable 226 directly via the link provided that a layer 3 to layer 2 mapping is 227 available. Note that there is no explicit need for the IPv4 link 228 addresses to be on the same subnet. An implementation should resolve 229 layer 3 to layer 2 mappings via ARP or ND for a DIA even if the IPv4 230 address is not on the same subnet as the router's interface IP 231 address. 233 2.6. Operation over Virtual Links 235 OSPFv3 control packets sent over a virtual link are IPv6 packets and 236 may traverse multiples hops. Therefore, there must be a global IPv6 237 address associated with the virtual link so that the control packet 238 is forwarded correctly by the intermediate hops between VL end 239 points. Although this requirement can be satisfied in IPv6 unicast 240 AF, this will not function in other AFs as there cannot be a multihop 241 forwarding based on global IPv6 address or such a path may not exist. 242 Therefore virtual link are not currently supported in other AF's. 244 3. Backward Compatibility 246 Each new AF will have their corresponding Instance ID and can operate 247 with the existing non-capable routers in IPv6 unicast topology. 248 Further, when a non-capable router uses an Instance ID which is 249 reserved for a given AF, since the non-capable router will not have 250 the AF-bit set in the Hello an adjacency will not be established with 251 an AF capable router. Therefore, there are no backward compatibility 252 issues. AF's can be gradually deployed without disturbing networks 253 with current non-capable routers. 255 4. Security Considerations 257 The function described in this document does not create any new 258 security issues for the OSPF protocol. Security considerations for 259 the OSPFv are covered in [OSPFV3]. 261 5. IANA Considerations 263 The following IANA assignments are to be made from existing 264 registries: 266 o An OSPFv3 options bit will be allocated for support of address 267 families using separate instances. 269 6. Normative References 271 [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 272 RFC 2740, December 1999. 274 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 275 Requirement Levels", RFC 2119, March 1997. 277 Appendix A. Acknowledgments 279 The RFC text was produced using Marshall Rose's xml2rfc tool. 281 Authors' Addresses 283 Acee Lindem 284 Cisco Systems 285 7025 Kit Creek Road 286 Research Triangle Park, NC 27709 287 USA 289 Email: acee@cisco.com 291 Sina Mirtorabi 292 Cisco Systems 293 225 West Tasman Drive 294 San Jose, CA 95134 295 USA 297 Email: sina@cisco.com 299 Abhay Roy 300 Cisco Systems 301 225 West Tasman Drive 302 San Jose, CA 95134 303 USA 305 Email: akr@cisco.com 307 Michael Barnes 308 Cisco Systems 309 225 West Tasman Drive 310 San Jose, CA 95134 311 USA 313 Email: mjbarnes@cisco.com 315 Quaizar Vohra 316 Juniper Networks 317 1194 N. Mathilda Ave. 318 Sunnyvale, CA 94089 319 USA 321 Email: qv@juniper.net 322 Rahul Aggarwal 323 Juniper Networks 324 1194 N. Mathilda Ave. 325 Sunnyvale, CA 94089 326 USA 328 Email: rahul@juniper.net 330 Full Copyright Statement 332 Copyright (C) The Internet Society (2006). 334 This document is subject to the rights, licenses and restrictions 335 contained in BCP 78, and except as set forth therein, the authors 336 retain all their rights. 338 This document and the information contained herein are provided on an 339 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 340 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 341 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 342 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 343 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 344 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 346 Intellectual Property 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; nor does it represent that it has 353 made any independent effort to identify any such rights. Information 354 on the procedures with respect to rights in RFC documents can be 355 found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the use of 360 such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository at 362 http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at 368 ietf-ipr@ietf.org. 370 Acknowledgment 372 Funding for the RFC Editor function is provided by the IETF 373 Administrative Support Activity (IASA).