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