idnits 2.17.1 draft-ietf-ospf-transition-to-ospfv3-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5838, updated by this document, for RFC5378 checks: 2004-04-06) -- 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 (May 23, 2016) is 2866 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 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 5309 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft I. Chen 3 Ericsson 4 Intended Status: Standards Track A. Lindem 5 Updates: 5838 Cisco 6 R. Atkinson 7 Consultant 8 Expires in 6 months May 23, 2016 10 OSPFv3 over IPv4 for IPv6 Transition 11 13 Status of this Memo 15 Distribution of this memo is unlimited. 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire in 6 months. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as 41 the document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 This document defines a mechanism to use IPv4 to transport OSPFv3 56 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address 57 Family extension can simplify transition from an OSPFv2 IPv4-only 58 routing domain to an OSPFv3 dual-stack routing domain. This document 59 updates RFC 5838 to support virtual links in the IPv4 unicast address 60 family when using OSPFv3 over IPv4. 62 Table of Contents 64 1. Introduction ....................................................3 65 2. Terminology .....................................................4 66 3. Encapsulation in IPv4 ...........................................4 67 3.1. Source Address .............................................6 68 3.2. Destination ................................................6 69 3.3. Operation over Virtual Link ................................6 70 4. IPv4-only Use Case ..............................................7 71 5. Security Considerations .........................................7 72 6. IANA Considerations .............................................8 73 7. References ......................................................8 75 1. Introduction 77 Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3 78 Address Family extension can simplify transition from an IPv4-only 79 routing domain to an IPv6 [RFC2460], or dual-stack routing domain. 80 Dual-stack routing protocols, such as Border Gateway Protocol 81 [RFC4271], have an advantage during the transition, because both IPv4 82 and IPv6 address families can be advertised using either IPv4 or 83 IPv6. Some IPv4-specific and IPv6-specific routing protocols share 84 enough similarities in their protocol packet formats and protocol 85 signaling that it is trivial to deploy an initial IPv6 routing domain 86 by transporting the routing protocol over IPv4, thereby allowing IPv6 87 routing domains to be deployed and tested before decommissioning IPv4 88 and moving to an IPv6-only network. 90 In the case of the Open Shortest Path First (OSPF) interior gateway 91 routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over 92 IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3 93 further supports multiple address families [RFC5838], including both 94 the IPv6 unicast address family and the IPv4 unicast address family. 95 Consequently, it is possible to deploy OSPFv3 over IPv4 without any 96 changes to either OSPFv3 or to IPv4. During the transition to IPv6, 97 future OSPF extensions can focus on OSPFv3 and OSPFv2 can move to 98 maintenance mode. 100 This document specifies how to use IPv4 to transport OSPFv3 packets. 101 The mechanism takes advantage of the fact that OSPFv2 and OSPFv3 102 share the same IP protocol number, 89. Additionally, the OSPF packet 103 header for both OSPFv2 and OSPFv3 includes the OSPF header version 104 (i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3 105 packet) in the same location (i.e., the same offset from the start of 106 the header). 108 If the IPv4 topology and IPv6 topology are not identical, the most 109 likely cause is that some parts of the network deployment have not 110 yet been upgraded to support both IPv4 and IPv6. In situations where 111 the IPv4 deployment is a proper superset of the IPv6 deployment, it 112 is expected that OSPFv3 packets would be transported over IPv4, until 113 the rest of the network deployment is upgraded to support IPv6 in 114 addition to IPv4. In situations where the IPv6 deployment is a 115 proper superset of the IPv4 deployment, it is expected that OSPFv3 116 would be transported over IPv6. 118 Throughout this document, OSPF is used when the text applies to both 119 OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is 120 specific to one version of the OSPF protocol. Similarly, IP is used 121 when the text describes either version of the Internet protocol. 122 IPv4 or IPv6 is used when the text is specific to a single version of 123 the Internet protocol. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. Encapsulation in IPv4 133 Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through 134 an IPv4 network, an OSPFv3 packet can be directly encapsulated within 135 an IPv4 packet as the payload, without the IPv6 packet header, as 136 illustrated in Figure 1. For OSPFv3 transported over IPv4, the IPv4 137 packet has an IPv4 protocol type of 89, denoting that the payload is 138 an OSPF packet. The payload of the IPv4 packet consists of an OSPFv3 139 packet, beginning with the OSPF packet header having its OSPF version 140 field set to 3. 142 An OSPFv3 packet followed by an OSPF link-local signaling (LLS) 143 extension data block [RFC5613] encapsulated in an IPv4 packet is 144 illustrated in Figure 2. 146 0 1 2 3 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 149 | 4 | IHL |Type of Service| Total Length | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 151 | Identification |Flags| Fragment Offset | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Time to Live | Protocol 89 | Header Checksum | IPv4 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 155 | Source Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 157 | Destination Address | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 159 | Options | Padding | v 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 161 | 3 | Type | Packet length | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Router ID | OSPFv3 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 165 | Area ID | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 167 | Checksum | Instance ID | 0 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 169 | OSPFv3 Body ... | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: An IPv4 packet encapsulating an OSPFv3 packet. 174 +---------------+ 175 | IPv4 Header | 176 +---------------+ 177 | OSPFv3 Header | 178 |...............| 179 | | 180 | OSPFv3 Body | 181 | | 182 +---------------+ 183 | | 184 | LLS Data | 185 | | 186 +---------------+ 188 Figure 2: The IPv4 packet encapsulating an OSPFv3 packet with 189 a trailing OSPF link-local signaling data block. 191 3.1. Source Address 193 For OSPFv3 over IPv4, the source address is the primary IPv4 194 address for the interface over which the packet is transmitted. 195 All OSPFv3 routers on the link SHOULD share the same IPv4 subnet 196 for IPv4 transport to function correctly. 198 While OSPFv2 operates on a subnet, OSPFv3 operates on a link 199 [RFC5340]. Accordingly, an OSPFv3 router implementation MAY 200 support adjacencies with OSPFv3 neighbors on different IPv4 201 subnets. If this is supported, the IPv4 data plane MUST resolve 202 the layer-2 address using Address Resolution Protocol (ARP) on 203 multi-access networks and point-to-point over LAN [RFC5309] for 204 direct next-hops on different IPv4 subnets 206 3.2. Destination Address 208 As defined in OSPFv2, the IPv4 destination address of an OSPF 209 protocol packet is either an IPv4 multicast address or the IPv4 210 unicast address of an OSPFv2 neighbor. Two well-known link-local 211 multicast addresses are assigned to OSPFv2, the AllSPFRouters 212 address (224.0.0.5) and the AllDRouters address (224.0.0.6). The 213 multicast address used depends on the OSPF packet type, the OSPF 214 interface type, and the OSPF router's role on multi-access 215 networks. 217 Thus, for an OSPFv3 over IPv4 packet to be sent to AllSPFRouters, 218 the destination address field in the IPv4 packet MUST be 224.0.0.5. 219 For an OSPFv3 over IPv4 packet to be sent to AllDRouters, the 220 destination address field in the IPv4 packet MUST be 224.0.0.6. 222 When an OSPF router sends a unicast OSPF packet over a connected 223 interface, the destination of such an IP packet is the address 224 assigned to the receiving interface. Thus, a unicast OSPFv3 packet 225 transported in an IPv4 packet would specify the OSPFv3 neighbor's 226 IPv4 address as the destination address. 228 3.3. Operation over Virtual Links 230 When an OSPF router sends an OSPF packet over a virtual link, the 231 receiving router is a router that might not be directly connected 232 to the sending router. Thus, the destination IP address of the IP 233 packet must be a reachable unicast IP address for the virtual link 234 endpoint. Because IPv6 is the presumed Internet protocol and an 235 IPv4 destination is not routable, the OSPFv3 address family 236 extension [RFC5838] specifies that only IPv6 address family virtual 237 links are supported. 239 As illustrated in Figure 1, this document specifies OSPFv3 240 transport over IPv4. As a result, OSPFv3 virtual links can be 241 supported with IPv4 address families by simply setting the IPv4 242 destination address to a reachable IPv4 unicast address for the 243 virtual link endpoint. Hence, the restriction in Section 2.8 of 244 RFC 5838 [RFC5838] is removed. If IPv4 transport, as specified 245 herein, is used for IPv6 address families, virtual links cannot be 246 supported. Hence, it is RECOMMENDED to use the IP transport 247 matching the address family in OSPF routing domains requiring 248 virtual links. 250 4. IPv4-only Use Case 252 OSPFv3 only requires IPv6 link-local addresses to form adjacencies, 253 and does not require IPv6 global-scope addresses to establish an IPv6 254 routing domain. However, IPv6 over Ethernet [RFC2464] uses a 255 different EtherType (0x86dd) from IPv4 (0x0800) and the Address 256 Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4. 258 Some existing deployed link-layer equipment only supports IPv4 and 259 ARP. Such equipment contains hardware filters keyed on the EtherType 260 field of the Ethernet frame to filter which frames will be accepted 261 by that link-layer equipment. Because IPv6 uses a different 262 EtherType, IPv6 framing for OSPFv3 will not work with that equipment. 263 In other cases, PPP might be used over a serial interface, but again 264 only IPv4 over PPP might be supported over such interface. It is 265 hoped that equipment with such limitations will be eventually 266 upgraded or replaced. 268 In some locations, especially locations with less communications 269 infrastructure, satellite communications (SATCOM) is used to reduce 270 deployment costs for data networking. SATCOM often has lower cost to 271 deploy than running new copper or optical cables over long distances 272 to connect remote areas. Also, in a wide range of locations 273 including places with good communications infrastructure, Very Small 274 Aperture Terminals (VSAT) often are used by banks and retailers to 275 connect their branches and stores to a central location. 277 Some widely deployed VSAT equipment has either (A) Ethernet 278 interfaces that only support Ethernet Address Resolution Protocol 279 (ARP) and IPv4, or (B) serial interfaces that only support IPv4 and 280 Point-to-Point Protocol (PPP) packets. Such deployments and 281 equipment still can deploy and use OSPFv3 over IPv4 today, and then 282 later migrate to OSPFv3 over IPv6 after equipment is upgraded or 283 replaced. This can have lower operational costs than running OSPFv2 284 and then trying to make a flag-day switch to OSPFv3. By running 285 OSPFv3 over IPv4 now, the eventual transition to dual-stack, and then 286 to IPv6-only can be optimized. 288 5. Security Considerations 290 As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for 291 authentication and confidentiality. Consequently, an OSPFv3 packet 292 transported within an IPv4 packet requires IPsec to provide 293 authentication and confidentiality. Further work such as [ipsecospf] 294 would be required to support IPsec protection for OSPFv3 over IPv4 295 transport. 297 An optional OSPFv3 Authentication Trailer [RFC7166] also has been 298 defined as an alternative to using IPsec. The calculation of the 299 authentication data in the Authentication Trailer includes the source 300 IPv6 address to protect an OSPFv3 router from Man-in-the-Middle 301 attacks. For IPv4 encapsulation as described herein, the IPv4 source 302 address should be placed in the first 4 octets of Apad followed by 303 the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is 304 the length of hash measured in octets. 306 The processing of the optional Authentication Trailer is contained 307 entirely within the OSPFv3 protocol. In other words, each OSPFv3 308 router instance is responsible for the authentication, without 309 involvement from IPsec or any other IP layer function. Consequently, 310 except for calculation of the Apad value, transporting OSPFv3 packets 311 using IPv4 does not change the generation or validation of the 312 optional OSPFv3 Authentication Trailer. 314 6. IANA Considerations 316 No actions are required from IANA as result of the publication of 317 this document. 319 7. References 321 7.1. Normative References 323 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 324 1981. 326 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 327 (IPv6) Specification", RFC 2460, December 1998. 329 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 330 for IPv6", RFC 5340, July 2008. 332 [RFC2328] Moy, J., "OSPF Version 2", STD54, RFC 2328, April 1998. 334 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 335 R. Aggarwal, "Support of Address Families in OSPFv3", RFC 336 5838, April 2010. 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point 342 Operation over LAN in Link State Routing Protocols", RFC 343 5309, October 2008. 345 7.2. Informative References 347 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 348 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 349 2006. 351 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 352 via IPv4 Clouds", RFC 3056, February 2001. 354 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 355 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 357 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 358 Converting Network Protocol Addresses to 48.bit Ethernet 359 Address for Transmission on Ethernet Hardware", STD 37, 360 RFC 826, November 1982. 362 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 363 Networks", RFC 2464, December 1998. 365 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 366 for OSPFv3", RFC 4552, June 2006. 368 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 369 Internet Protocol", RFC 4301, December 2005. 371 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 372 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 374 [ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta- 375 ospf-ospfv2-sec-01.txt", August 2009. 377 Authors' Addresses 379 I. Chen 380 Ericsson 381 Email: ichen@kuatrotech.com 383 A. Lindem 384 Cisco 385 Email: acee@cisco.com 387 R. Atkinson 388 Consultant 389 Email: rja.lists@gmail.com