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