idnits 2.17.1 draft-ietf-ospf-af-alt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 94: '... supports AF, it MUST set this bit in ...' RFC 2119 keyword, line 116: '... it MUST discard Hello packets havin...' RFC 2119 keyword, line 117: '...IPv6 unicast AF, where this check MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 2004) is 7346 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. 'Ref1') (Obsoleted by RFC 5340) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sina Mirtorabi 3 Internet Draft Abhay Roy 4 Document: draft-ietf-ospf-af-alt-00.txt Michael Barnes 5 Expiration Date: September 2004 Cisco Systems 7 Acee Lindem 8 Redback Networks 10 Quaizar Vohra 11 Rahul Aggarwal 12 Juniper Networks 14 March 2004 16 Support of address families in OSPFv3 17 draft-ietf-ospf-af-alt-00.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its Areas, and its Working Groups. Note that other 26 groups may also distribute working documents as Internet Drafts. 28 Internet Drafts are draft documents valid for a maximum of six 29 months. Internet Drafts may be updated, replaced, or obsoleted by 30 other documents at any time. It is not appropriate to use Internet 31 Drafts as reference material or to cite them other than as a "working 32 draft" or "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 Abstract 42 This document describes a mechanism for supporting multiple address 43 families in OSPFv3 using multiple instances. It maps an address 44 family (AF) to an OSPFv3 instance using the Instance ID field in the 45 OSPFv3 packet header. This approach is fairly simple and minimizes 46 extensions to OSPFv3 for supporting multiple AF's. 48 1. Motivation 50 OSPFv3 has been defined to support IPv6 unicast AF. There is a need 51 to carry other AFs in OSPFv3 such as multicast IPv6, unicast or 52 multicast IPv4. This document introduces these other AFs in OSPFv3 53 by reserving Instance IDs and using one OSPFv3 instance for one AF. 55 2. Proposed Solution 57 Currently the entire Instance ID number space is used for IPv6 58 unicast. We propose to assign different ranges to different AF's in 59 order to support other AF's in OSPFv3. Each AF will establish 60 different adjacency, have different link state database and compute 61 different shortest path tree. Additionally, the current LSAs that are 62 defined to carry IPv6 unicast prefix can be used without any 63 modification in different instances to carry different AF's prefixes. 65 It should be noted that OSPFv3 is running on the top of IPv6 and uses 66 IPv6 link local address for OSPFv3 control packet and next hop 67 calculation. Therefore, it is required that IPv6 be enabled on a link, 68 although the link may not be participating in IPv6 unicast AF. 70 3. Instance ID values for new AF's 72 Instance ID zero is already used by default for IPv6 unicast AF. 73 We define the following ranges for different AF's. The first value 74 of each range is considered as the default value for the 75 corresponding AF. 77 Instance ID # 0 - # 31 IPv6 unicast AF 78 Instance ID # 32 - # 63 IPv6 multicast AF 79 Instance ID # 64 - # 95 IPv4 unicast AF 80 Instance ID # 96 - # 127 IPv4 multicast AF 81 Instance ID # 128 - # 255 Reserved 83 4. New bit in Options field 85 A new bit is defined in the Options field for AF support. 87 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 88 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+--+--+--+--+--+--+ 89 | | | | | | | | | | | | | | | | | AF|DC| R| N|MC| E|V6| 90 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+--+--+--+--+--+--+ 92 AF-bit 94 When a router supports AF, it MUST set this bit in the Options 95 field of Hello Packets, DD packets and LSAs. 97 5. Changes to the Hello processing 99 When a router does not support an AF but it is configured with an 100 Instance ID in the same range, packets could be blackholed. This 101 could happen due to misconfiguration or router downgrade to a 102 previous code level. Blackholing is possible because the router which 103 doesn't support the AF can still be included in the SPF calculated 104 path as long as it establishes adjacencies using the Instance ID 105 corresponding to the AF. Note that router and network LSAs are AF 106 independent. 108 In order to avoid the above situation, hello processing is changed in 109 order to only establish adjacency with the routers that have the 110 AF-bit set in their Options field. 112 Receiving Hello Packets is specified in section 3.2.2.1 of [Ref1]. 113 The following check is added to Hello reception: 115 When a router participate in an AF (sets the AF-bit in Options field) 116 it MUST discard Hello packets having the AF-bit clear in the Options 117 field. The only exception is IPv6 unicast AF, where this check MUST 118 NOT be done (to help backward compatibility). 120 6. Modification to some of the bits defined in [Ref1] 122 Some of the bits defined in OSPFv3 are relevant to IPv6 unicast 123 AF, and are not needed in other AF's. Some may be applicable only 124 to a certain AF. Below is the list of changes to those bits: 126 o Options Field 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 129 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 130 | | | | | | | | | | | | | | | | | |DC| R| N|* | E|* | 131 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+ 133 o V6-bit 135 The V6 bit is used in OSPFv3 to exclude a node from IPv6 unicast 136 route calculation but allow it in the SPF calculation for 137 other address families. Since Instance ID now denotes the AF 138 explicitly, this bit is ignored in AF's other than IPv6 unicast. 140 o MC-bit 142 This bit is not used in other AF's introduced in this document. 144 o Prefix Options Field 146 0 1 2 3 4 5 6 7 147 +--+--+--+--+--+--+--+--+ 148 | | | | | P|* |LA|NU| 149 +--+--+--+--+--+--+--+--+ 151 o MC bit in the Prefix Options field 153 This bit is not used in other AF's introduced in this document. 155 o NU bit usage in the Prefix Options field 157 The NU bit must be clear in all unicast AF's and it must be set 158 in all multicast AF's. 160 Note that all bits unused in a given AF could be redefined later. 162 7. Carrying Prefixes in new AF's 164 Each Prefix defined in OSPFv3 has a prefix length field. This 165 facilitate advertising prefixes of different lengths in different 166 AF's. The existing LSAs defined in OSPFv3 are used for this 167 purpose and there is no need to define new LSAs. 169 8. Next hop for IPv4 unicast and multicast AF's 171 OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses 172 for OSPFv3 control packets and next hop calculations. Although IPV6 173 link local addresses could be used as next hops for IPv4 address 174 families, it is desirable to have IPv4 next hop addresses. For 175 example, in IPv4 multicast having the nexthop address the same as 176 the PIM neighbor address (IPv4 address) makes it easier to know to 177 which upstream neighbor to send a PIM join when doing a RPF lookup 178 for a source. It is also easier for troubleshooting purposes to have 179 a next hop with the same semantics as the AF. 181 In order to achieve this, the link's IPv4 address will be advertised 182 in the "link local address" field of the IPv4 instance's Link-LSA. 183 This address is placed in the first 32 bit of "link local address" 184 field and used for IPv4 next hop calculations. 186 We call direct interface address (DIA) the address that is reachable 187 directly via the link provided that a layer 3 to layer 2 mapping is 188 available. Note that there is no explicit need for the IPv4 link 189 addresses to be on the same subnet. An implementation should resolve 190 layer 3 to layer 2 mappings via ARP or ND for a DIA even if the IPv4 191 address is not on the same subnet as the router's interface IP address. 193 9. OSPFv3 over IPv4 195 Although OSPFv3 is defined to run over IPv6, it is possible to run 196 OSPFv3 over IPv4 and making IPv4 address-family, IPv6 independent. 197 This is achieved by using IPv4 for OSPFv3 control packet with the 198 same protocol number 89 as OSPFv2. The version in the OSPF packet 199 allows to distinguish between OSPFv2 and OSPFv3. 201 We define a parameter in interface data structure called V4TransProtocol. 202 V4TransProtocol flag can have two values: Enabled or Disabled, the default 203 value being Disabled. 205 when set to Enabled OSPFv3 use IPv4 as transport protocol 206 When set to Disabled OSPFv3 use IPv6 as transport protocol 208 Note that this parameter can only be enabled in IPv4 address family 209 (see section 3 for instance id range). 211 10. Virtual Link (VL) 213 When OSPFv3 is running over IPv4 there is no special requirement for 214 VL to be operational since OSPFv3 control packet are sent over IPv4. 215 However note that all routers within the area should run over IPv4 216 or provided that there is a contiguous path between the virtual link 217 end point that run over IPv4. 219 When OSPFv3 is running over IPv6, the control packet sent for virtual 220 link are IPv6 packets and may traverse multiples hops therefore there 221 must be a global IPv6 address associated with the virtual link so that 222 the control packet is forwarded correctly by the intermediate hops 223 between VL end points. Although this requirement can be satisfied in 224 IPv6 unicast AF, this will not function in other AF as there cannot 225 be a multihop forwarding based on global IPv6 address or such a path 226 may not exist. Therefore virtual link are not currently supported in 227 other AF's. 229 11. Backward compatibility issues 231 Each new AF will have their corresponding Instance ID and can 232 operate with the existing non-capable routers in IPv6 unicast 233 topology. Further, when a non-capable router uses an Instance ID which 234 is reserved for a given AF, since the non-capable router will not have 235 the AF-bit set in the Hello an adjacency will not be established with 236 an AF capable router. Therefore, there are no backward compatibility 237 issues. AF's can be gradually deployed without disturbing networks with 238 current non-capable routers. 240 12. Address-family design Considerations 242 This section describes the rationale for adopting the multiple 243 instance ID approach for supporting multiple address families in 244 OSPFv3. As described earlier, OSPFv3 is designed to support multiple 245 instances. Hence mapping an instance to an address family doesn't 246 introduce new mechanisms in the protocol. It minimizes the protocol 247 extensions required and it simplifies the implementation. The 248 presence of a separate link state database per address family is 249 also easier to debug and operate. Additionally, it doesn't change 250 the existing instance, area and interface based configuration model 251 in most OSPF implementations. 253 13. Security Considerations 255 The technique described in this document does not introduce any new 256 security issues to the OSPFv3 protocol. 258 14. References 260 [Ref1] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", 261 RFC 2740, December 1999. 263 15. Authors address 265 Sina Mirtorabi Acee Lindem 266 Cisco Systems Redback Networks 267 170 W. Tasman Dr. 102 Carric Bend Court 268 San Jose, CA 95134 Cary, NC 27519 269 Email: sina@cisco.com Email: acee@redback.com 271 Abhay Roy Quaizar Vohra 272 Cisco Systems Juniper Networks 273 170 W. Tasman Dr. 1194 North Mathilda Ave. 274 San Jose, CA 95134 Sunnyvale, CA 94089 275 Email: akr@cisco.com Email: qv@juniper.net 277 Michael Barnes Rahul Aggarwal 278 Cisco Systems Juniper Networks 279 170 W. Tasman Dr. 1194 North Mathilda Ave. 280 San Jose, CA 95134 Sunnyvale, CA 94089 281 Email: mjbarnes@cisco.com Email: rahul@juniper.net