idnits 2.17.00 (12 Aug 2021) /tmp/idnits11401/draft-chen-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 4 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 ** 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 228: '... RECOMMENDED to use the IP transpo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2014) is 3036 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 6506 (ref. 'RFC6505') (Obsoleted by RFC 7166) 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 A. Lindem 4 Category: Informational Ericsson 5 Expires in 6 months January 26, 2014 7 OSPFv3 over IPv4 for IPv6 Transition 8 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on date. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as 38 the document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This draft defines a mechanism to use IPv4 to transport OSPFv3 50 packets, in order to facilitate transition from IPv4-only to IPv6 and 51 dual-stack within a routing domain. Using OSPFv3 over IPv4 with the 52 existing OSPFv3 Address Family extension simplifies transition from 53 an OSFPv2 IPv4-only routing domain to an OSPFv3 dual-stack routing 54 domain, and later possibly to an IPv6-only routing domain. 56 Table of Contents 58 1. Introduction ....................................................3 59 2. Encapsulation in IPv4 ...........................................4 60 2.1. Source Address .............................................6 61 2.2. Destination ................................................6 62 2.3. Operation over Virtual Link ................................6 63 3. Security Considerations .........................................7 64 4. IANA Considerations .............................................7 65 5. References ......................................................7 67 1. Introduction 69 To facilitate transition from IPv4 [RFC791] to IPv6 [RFC2460], dual- 70 stack or IPv6 routing protocols should be gradually deployed. Dual- 71 stack routing protocols, such as Border Gateway Protocol [RFC4271], 72 have an advantage during the transition, because both IPv4 and IPv6 73 topologies can be transported using either IPv4 or IPv6. Some 74 IPv4-specific and IPv6-specific routing protocols share enough 75 similarities in their protocol packet formats and protocol signaling 76 that it is trivial to build an initial IPv6 routing domain over IPv4, 77 allowing IPv6 routing domains be deployed and tested before de- 78 commissioning IPv4 and moving to an IPv6-only network. 80 In the case of Open Shortest Path First (OSPF) interior gateway 81 routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over 82 IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3 83 further supports multiple address families [RFC5838], including both 84 the IPv6 unicast address family and the IPv4 unicast address family. 85 Consequently, it is possible to deploy OSPFv3 over IPv4 without any 86 changes to to either OSPFv3 or IPv4. 88 This draft specifies how to use IPv4 packets to transport OSPFv3 89 packets. The mechanism takes advantage of the fact that OSPFv2 and 90 OSPFv3 share the same IP protocol number, 89. Additionally, OSPFv2 91 and OSPFv3 also share the same OSPF packet header format, while the 92 OSPF packet header has its own OSPF version number that distinguishes 93 an OSPFv2 packet from an OSPFv3 packet. 95 In normal operation, it is expected that the IPv4 topology within the 96 OSPF domain will be congruent with the IPv6 topology of that OSPF 97 domain. In such cases, it is expected that either all OSPFv3 packets 98 will be carried over IPv4 or that all OSPFv3 packets will be carried 99 over IPv6. 101 If the IPv4 topology and IPv6 topology are not identical, the most 102 likely cause (as of the date this draft was written) is that some 103 parts of the network deployment are not yet upgraded to support both 104 IPv4 and IPv6. In situations where the IPv4 deployment is a proper 105 superset of the IPv6 deployment, it is expected that OSPFv3 packets 106 would be carried over IPv4, until the rest of the network deployment 107 is upgraded to support IPv6 in addition to IPv4. In situations where 108 the IPv6 deployment is a proper superset of the IPv4 deployment, for 109 example as IPv4 is phased out, it is expected that OSPFv3 would be 110 carried over IPv6. 112 Throughout this document, OSPF is used when the text applies to both 113 OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is 114 specific to one version of the OSPF protocol. Similarly, IP is used 115 when the text describes either version of the Internet protocol. 116 IPv4 or IPv6 is used when the text is specific to a single version of 117 the protocol. 119 2. Encapsulation in IPv4 121 Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through 122 an IPv4 network, this draft proposes that an OSPFv3 packet be 123 directly encapsulated within an IPv4 packet as the payload, without 124 the IPv6 packet header, as illustrated in Figure 1. In this case, 125 the IPv4 packet has an IPv4 protocol type of 89, denoting that the 126 payload is an OSPF packet. The payload of the IPv4 packet consists 127 of an OSPFv3 packet, beginning with the OSPF packet header, in which 128 the OSPF version number is 3. 130 An OSPFv3 packet followed by a OSPF link-local signaling (LLS) 131 extension data block [RFC5613] encapsulated in an IPv4 packet is 132 illustrated in Figure 2. 134 0 1 2 3 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 4 5 6 7 8 9 0 1 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 137 | 4 | IHL |Type of Service| Total Length | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 139 | Identification |Flags| Fragment Offset | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Time to Live | Protocol 89 | Header Checksum | IPv4 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 143 | Source Address | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 145 | Destination Address | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 147 | Options | Padding | v 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 149 | 3 | Type | Packet length | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Router ID | OSPFv3 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header 153 | Area ID | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 155 | Checksum | Instance ID | 0 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 157 | OSPFv3 Body ... | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: An IPv4 packet encapsulating an OSPFv3 packet. 162 +---------------+ 163 | IPv4 Header | 164 +---------------+ 165 | OSPFv3 Header | 166 |...............| 167 | | 168 | OSPFv3 Body | 169 | | 170 +---------------+ 171 | | 172 | LLS Data | 173 | | 174 +---------------+ 176 Figure 2: The IPv4 packet encapsulating an OSPFv3 packet with 177 a trailing OSPF link-local signaling data block. 179 2.1. Source Address 181 Consistent with OSPFv2, the IPv4 source address of an OSPF protocol 182 packet is one end of a router adjacency. For OSPFv3 over IPv4, the 183 source address is the IPv4 unicast address of the interface 184 transmitting the packet. 186 2.2. Destination Address 188 As defined in OSPFv2, the IPv4 destination address of an OSPF 189 protocol packet is either an IPv4 multicast address or the IPv4 190 unicast address of the other end of the adjacency. Two well-known 191 link-local multicast addresses are assigned to OSPFv2, the 192 AllSPFRouters address 224.0.0.5 and the AllDRouters address 193 224.0.0.6. The multicast address used depends on the OSPF packet 194 type, the OSPF interface type, and the OSPF router's role on the 195 multi-access networks. 197 Thus, for an OSPFv3 over IPv4 packet to be sent to AllSPFRouters, 198 the destination address field in the IPv4 packet should be 199 224.0.0.5. For an OSPFv3 over IPv4 packet to be sent to 200 AllDRouters, the destination address field in the IPv4 packet 201 should be 224.0.0.6. 203 When an OSPF router sends a unicast OSPF packet over a connected 204 interface, the destination of such an IP packet is the address 205 assigned to the receiving interface. Thus, a unicast OSPFv3 packet 206 carried in an IPv4 packet would specify the IPv4 unicast address of 207 the receiving interface as the destination address. 209 2.3. Operation over Virtual Link 211 When an OSPF router sends an OSPF packet over a virtual link, the 212 receiving router is a router which is not directly connected to the 213 sending router. Thus, the destination IP address of the IP packet 214 must be a reachable unicast IP address of the receiving router. 215 Because IPv6 is the presumed Internet protocol and an IPv4 216 destination is not routable, OSPFv3 address family extension 217 [RFC5838] specifies that only IPv6 address family virtual links are 218 supported. 220 As illustrated in Figure 1, this draft proposes that an OSPFv3 221 packet be carried within an IPv4 packet. As a result, an IPv4 222 packet in which the destination field is a unicast IPv4 address 223 assigned to the virtual router is routable, and OSPFv3 virtual 224 links in IPv4 unicast address families can be supported and the 225 restriction in Section 2.8 of RFC 5838 [RFC5838] can be removed. 226 If IPv4 transport, as specified herein, is used for IPv6 address 227 families, virtual links cannot be supported. Hence, it is 228 RECOMMENDED to use the IP transport matching the address family in 229 OSPF routing domains requiring virtual links. 231 3. Security Considerations 233 As described in [RFC4552], OSPFv3 uses IPsec [RFC4301] for 234 authentication and confidentiality. Consequently, an OSPFv3 packet 235 carried within an IPv4 packet requires IPsec to provide 236 authentication and confidentiality. Because IPsec is more commonly 237 implemented and more widely available on IPv4 systems than on IPv6 238 systems, this use is not more problematic than use of IPsec with 239 OSPFv3 over IPv6. Further work such as [ipsecospf] might be required 240 for IPv4 IPsec. 242 An optional OSPFv3 Authentication Trailer [RFC6505] also has been 243 defined as an alternative to using IPsec. The calculation of the 244 authentication data in the Authentication Trailer includes the source 245 IPv6 address to protect an OSPFv3 router from Man-in-the-Middle 246 attacks. For IPv4 encapsulation described in this draft, the IPv4 247 source address should be placed in the first 4 bytes of Apad followed 248 by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L 249 is the length of hash measured in octet. 251 The processing of the optional Authentication Trailer is confined 252 entirely within the OSPFv3 protocol, in which each OSPFv3 router is 253 responsible for the authentication without involvement from IPsec or 254 any other IP layer. Consequently, except for calculation of the 255 value Apad, transporting OSPFv3 packets using IPv4 does not change 256 the operation of the optional OSPFv3 Authentication Trailer. At 257 present, that Authentication Trailer has limited implementation and 258 also limited deployment. 260 4. IANA Considerations 262 No actions are required from IANA as result of the publication of 263 this document. 265 5. References 267 5.1 Normative References 269 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 270 1981. 272 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 273 (IPv6) Specification", RFC 2460, December 1998. 275 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 276 for IPv6", RFC 5340, July 2008. 278 [RFC2328] Moy, J., "OSPF Version 2", STD54, RFC 2328, April 1998. 280 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 281 R. Aggarwal, "Support of Address Families in OSPFv3", RFC 282 5838, April 2010. 284 5.2. Informative References 286 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 287 Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 288 2006. 290 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 291 via IPv4 Clouds", RFC 3056, February 2001. 293 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 294 Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. 296 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 297 for OSPFv3", RFC 4552, June 2006. 299 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 300 Internet Protocol", RFC 4301, December 2005. 302 [RFC6505] Bhatia, M., Manral, V., and A. Lindem, "Supporting 303 Authentication Trailer for OSPFv3", RFC 6506, February 304 2012. 306 [ipsecospf] Gupta, M. and Melam, M, Work in progress, "draft-gupta- 307 ospf-ospfv2-sec-01.txt", August 2009. 309 Authors' Addresses 311 I. Chen 312 Ericsson 313 Email: ing-wher.chen@ericsson.com 315 A. Lindem 316 Ericsson 317 Email: acee.lindem@ericsson.com