idnits 2.17.1 draft-ietf-ospf-transition-to-ospfv3-00.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 -- The document date (November 10, 2014) is 3453 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) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Cisco 6 R. Atkinson 7 Consultant 8 Expires in 6 months November 10, 2014 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 on date. 38 Copyright Notice 40 Copyright (c) 2014 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, in order to facilitate transition from IPv4-only to IPv6 and 57 dual-stack within a routing domain. Using OSPFv3 over IPv4 with the 58 existing OSPFv3 Address Family extension can simplify transition from 59 an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing 60 domain. 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 To facilitate transition from IPv4 [RFC791] to IPv6 [RFC2460], dual- 78 stack or IPv6 routing protocols should be gradually deployed. Dual- 79 stack routing protocols, such as Border Gateway Protocol [RFC4271], 80 have an advantage during the transition, because both IPv4 and IPv6 81 topologies can be transported using either IPv4 or IPv6. Some 82 IPv4-specific and IPv6-specific routing protocols share enough 83 similarities in their protocol packet formats and protocol signaling 84 that it is trivial to deploy an initial IPv6 routing domain by 85 carrying the routing protocol over IPv4 initially, thereby allowing 86 IPv6 routing domains be deployed and tested before decommissioning 87 IPv4 and moving to an IPv6-only network. 89 In the case of the Open Shortest Path First (OSPF) interior gateway 90 routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over 91 IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3 92 further supports multiple address families [RFC5838], including both 93 the IPv6 unicast address family and the IPv4 unicast address family. 94 Consequently, it is possible to deploy OSPFv3 over IPv4 without any 95 changes either to OSPFv3 or to IPv4. During the transition to IPv6, 96 future OSPF extension can focus on OSPFv3 and OSPFv2 can move into 97 maintenance mode. 99 This document specifies how to use IPv4 packets to transport OSPFv3 100 packets. The mechanism takes advantage of the fact that OSPFv2 and 101 OSPFv3 share the same IP protocol number, 89. Additionally, the OSPF 102 packet header for both OSPFv2 and OSPFv3 places the OSPF header 103 version (i.e., the field that distinguishes an OSPFv2 packet from an 104 OSPFv3 packet) in the same location. 106 This document does not attempt to connect an IPv4 topology and an 107 IPv6 topology that are not congruent. In normal operation, it is 108 expected that the IPv4 topology within the OSPF domain will be 109 congruent with the IPv6 topology of that OSPF domain. In such cases, 110 it is expected either that all OSPFv3 packets will be transported 111 over IPv4 or that all OSPFv3 packets will be transported over IPv6. 113 If the IPv4 topology and IPv6 topology are not identical, the most 114 likely cause is that some parts of the network deployment have not 115 yet been upgraded to support both IPv4 and IPv6. In situations where 116 the IPv4 deployment is a proper superset of the IPv6 deployment, it 117 is expected that OSPFv3 packets would be transported over IPv4, until 118 the rest of the network deployment is upgraded to support IPv6 in 119 addition to IPv4. In situations where the IPv6 deployment is a 120 proper superset of the IPv4 deployment, it is expected that OSPFv3 121 would be transported over IPv6. 123 Throughout this document, OSPF is used when the text applies to both 124 OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is 125 specific to one version of the OSPF protocol. Similarly, IP is used 126 when the text describes either version of the Internet protocol. 127 IPv4 or IPv6 is used when the text is specific to a single version of 128 the protocol. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Encapsulation in IPv4 138 Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through 139 an IPv4 network, an OSPFv3 packet can be directly encapsulated within 140 an IPv4 packet as the payload, without the IPv6 packet header, as 141 illustrated in Figure 1. For OSPFv3 transported over IPv4, the IPv4 142 packet has an IPv4 protocol type of 89, denoting that the payload is 143 an OSPF packet. The payload of the IPv4 packet consists of an OSPFv3 144 packet, beginning with the OSPF packet header with the OSPF version 145 number set to 3. 147 An OSPFv3 packet followed by an OSPF link-local signaling (LLS) 148 extension data block [RFC5613] encapsulated in an IPv4 packet is 149 illustrated in Figure 2. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 154 | 4 | IHL |Type of Service| Total Length | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 156 | Identification |Flags| Fragment Offset | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Time to Live | Protocol 89 | Header Checksum | IPv4 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 160 | Source Address | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 162 | Destination Address | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 164 | Options | Padding | v 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 166 | 3 | Type | Packet length | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Router ID | OSPFv3 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 170 | Area ID | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 172 | Checksum | Instance ID | 0 | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 174 | OSPFv3 Body ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: An IPv4 packet encapsulating an OSPFv3 packet. 179 +---------------+ 180 | IPv4 Header | 181 +---------------+ 182 | OSPFv3 Header | 183 |...............| 184 | | 185 | OSPFv3 Body | 186 | | 187 +---------------+ 188 | | 189 | LLS Data | 190 | | 191 +---------------+ 193 Figure 2: The IPv4 packet encapsulating an OSPFv3 packet with 194 a trailing OSPF link-local signaling data block. 196 3.1. Source Address 198 For OSPFv3 over IPv4, the source address is the IPv4 interface 199 address for the interface over which the packet is transmitted. 200 All OSPFv3 routers on the link MUST share the same IPv4 subnet for 201 IPv4 transport to function correctly. 203 3.2. Destination Address 205 As defined in OSPFv2, the IPv4 destination address of an OSPF 206 protocol packet is either an IPv4 multicast address or the IPv4 207 unicast address of an OSPFv2 neighbor. Two well-known link-local 208 multicast addresses are assigned to OSPFv2, the AllSPFRouters 209 address (224.0.0.5) and the AllDRouters address (224.0.0.6). The 210 multicast address used depends on the OSPF packet type, the OSPF 211 interface type, and the OSPF router's role on multi-access 212 networks. 214 Thus, for an OSPFv3 over IPv4 packet to be sent to AllSPFRouters, 215 the destination address field in the IPv4 packet should be 216 224.0.0.5. For an OSPFv3 over IPv4 packet to be sent to 217 AllDRouters, the destination address field in the IPv4 packet 218 should be 224.0.0.6. 220 When an OSPF router sends a unicast OSPF packet over a connected 221 interface, the destination of such an IP packet is the address 222 assigned to the receiving interface. Thus, a unicast OSPFv3 packet 223 transported in an IPv4 packet would specify the OSPFv3 neighbor's 224 IPv4 address as the destination address. 226 3.3. Operation over Virtual Link 228 When an OSPF router sends an OSPF packet over a virtual link, the 229 receiving router is a router which is not directly connected to the 230 sending router. Thus, the destination IP address of the IP packet 231 must be a reachable unicast IP address of the receiving router. 232 Because IPv6 is the presumed Internet protocol and an IPv4 233 destination is not routable, the OSPFv3 address family extension 234 [RFC5838] specifies that only IPv6 address family virtual links are 235 supported. 237 As illustrated in Figure 1, this document specifies OSPFv3 238 transport over IPv4. As a result, an IPv4 packet in which the 239 destination field is a unicast IPv4 address assigned to the virtual 240 router is routable, and OSPFv3 virtual links in IPv4 unicast 241 address families can be supported. Hence, the restriction in 242 Section 2.8 of RFC 5838 [RFC5838] is removed. If IPv4 transport, 243 as specified herein, is used for IPv6 address families, virtual 244 links cannot be supported. Hence, it is RECOMMENDED to use the IP 245 transport matching the address family in OSPF routing domains 246 requiring virtual links. 248 4. IPv4-only Use Case 250 OSPFv3 only requires IPv6 link-local addresses to establish a routing 251 domain, and does not require IPv6 global-scope addresses to establish 252 a routing domain. However, IPv6 over Ethernet [RFC2464] uses a 253 different EtherType (0x86dd) from IPv4 (0x0800) and also from the 254 Address Resolution Protocol (ARP) (0x0806) [RFC826] that is used with 255 IPv4. 257 Some existing deployed link-layer equipment only supports IPv4 and 258 ARP. Such equipment contains hardware filters keyed on the EtherType 259 field of the Ethernet frame to filter which frames will be accepted 260 into that link-layer equipment. Because IPv6 uses a different 261 EtherType, IPv6 framing for OSPFv3 won't work with that equipment. 262 In other cases, PPP might be used over a serial interface, but again 263 only IPv4 over PPP might be supported over that interface. It is 264 hoped that equipment with such limitations will be replaced 265 eventually. 267 In some locations, especially locations with less communications 268 infrastructure, satellite communications (SATCOM) is used to reduce 269 deployment costs for data networking. SATCOM often has lower cost to 270 deploy than running new copper or optical cables for long distances 271 to connect remote areas. Also, in a wide range of locations 272 including places with good communications infrastructure, Very Small 273 Aperture Terminals (VSAT) often are used by banks and retailers to 274 connect their stores to their main offices. 276 Some widely deployed VSAT equipment has either (A) Ethernet 277 interfaces that only support Ethernet Address Resolution Protocol 278 (ARP) and IPv4, or (B) serial interfaces that only support IPv4 and 279 Point-to-Point Protocol (PPP) packets. Such deployments and 280 equipment still can deploy and use OSPFv3 over IPv4 today, and then 281 later migrate to OSPFv3 over IPv6 after equipment is upgraded or 282 replaced. This can have lower operational costs than running OSPFv2 283 and then trying to make a flag-day switch to running OSPFv3. By 284 running OSPFv3 over IPv4 now, the eventual transition to dual-stack, 285 and then to IPv6-only can be optimized. 287 5. Security Considerations 289 As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for 290 authentication and confidentiality. Consequently, an OSPFv3 packet 291 transported within an IPv4 packet requires IPsec to provide 292 authentication and confidentiality. Further work such as [ipsecospf] 293 would be required to support IPsec protection for OSPFv3 over IPv4 294 transport. 296 An optional OSPFv3 Authentication Trailer [RFC7166] also has been 297 defined as an alternative to using IPsec. The calculation of the 298 authentication data in the Authentication Trailer includes the source 299 IPv6 address to protect an OSPFv3 router from Man-in-the-Middle 300 attacks. For IPv4 encapsulation as described herein, the IPv4 source 301 address should be placed in the first 4 octets of Apad followed by 302 the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is 303 the length of hash measured in octet. 305 The processing of the optional Authentication Trailer is contained 306 entirely within the OSPFv3 protocol. In other words, each OSPFv3 307 router instance is responsible for the authentication, without 308 involvement from IPsec or any other IP layer function. Consequently, 309 except for calculation of the value Apad, transporting OSPFv3 packets 310 using IPv4 does not change the operation of the optional OSPFv3 311 Authentication Trailer. 313 6. IANA Considerations 315 No actions are required from IANA as result of the publication of 316 this document. 318 7. References 320 7.1. Normative References 322 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 323 1981. 325 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 326 (IPv6) Specification", RFC 2460, December 1998. 328 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 329 for IPv6", RFC 5340, July 2008. 331 [RFC2328] Moy, J., "OSPF Version 2", STD54, RFC 2328, April 1998. 333 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 334 R. Aggarwal, "Support of Address Families in OSPFv3", RFC 335 5838, April 2010. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 7.2. Informative References 342 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 343 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 344 2006. 346 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 347 via IPv4 Clouds", RFC 3056, February 2001. 349 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 350 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 352 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 353 Converting Network Protocol Addresses to 48.bit Ethernet 354 Address for Transmission on Ethernet Hardware", STD 37, 355 RFC 826, November 1982. 357 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 358 Networks", RFC 2464, December 1998. 360 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 361 for OSPFv3", RFC 4552, June 2006. 363 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 364 Internet Protocol", RFC 4301, December 2005. 366 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 367 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 369 [ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta- 370 ospf-ospfv2-sec-01.txt", August 2009. 372 Authors' Addresses 374 I. Chen 375 Ericsson 376 Email: ing-wher.chen@ericsson.com 378 A. Lindem 379 Cisco 380 Email: acee@cisco.com 382 R. Atkinson 383 Consultant