idnits 2.17.1 draft-ietf-ospf-ipv4-embedded-ipv6-routing-12.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 non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2013) is 3989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6506 (Obsoleted by RFC 7166) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cheng 3 Internet-Draft Huawei Technologies 4 Intended status: Informational M. Boucadair 5 Expires: November 25, 2013 France Telecom 6 A. Retana 7 Cisco Systems 8 May 24, 2013 10 Routing for IPv4-embedded IPv6 Packets 11 draft-ietf-ospf-ipv4-embedded-ipv6-routing-12 13 Abstract 15 This document describes a routing scenario where IPv4 packets are 16 transported over an IPv6 network, based on RFCs 6145 and 6052, along 17 with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in 18 the IPv6 network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 25, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. The Scenario . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . 4 57 1.3. An Alternative Routing Solution with OSPFv3 . . . . . . . 4 58 1.4. OSPFv3 Routing with a Specific Topology . . . . . . . . . 6 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 60 3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . 7 62 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 7 63 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 64 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8 65 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8 66 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 67 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 9 68 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 69 Transit Network . . . . . . . . . . . . . . . . . . . . . 9 70 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10 71 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 10 72 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 10 73 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 11 74 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 11 76 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12 77 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 12. Operational Considerations . . . . . . . . . . . . . . . . . 13 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 84 15.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 This document describes a routing scenario where IPv4 packets are 90 transported over an IPv6 network, based on [RFC6145] and [RFC6052], 91 along with a separate OSPFv3 routing table for IPv4-embedded IPv6 92 routes in the IPv6 network. This document does not introduce any new 93 IPv6 transition mechanism. 95 In this document the following terminology is used: 97 o An IPv4-embedded IPv6 address denotes an IPv6 address which 98 contains an embedded 32-bit IPv4 address constructed according to 99 the rules defined in [RFC6052]. 101 o IPv4-embedded IPv6 packets are packets of which destination 102 addresses are IPv4-embedded IPv6 addresses. 104 o AFBR (Address Family Border Router, [RFC5565]) refers to an edge 105 router, which supports both IPv4 and IPv6 address families, but 106 the backbone network it connects to only supports either the IPv4 107 or IPv6 address family. 109 o AFXLBR (Address Family Translation Border Router) is defined in 110 this document. It refers to a border router that supports both 111 IPv4 and IPv6 address families, located on the boundary of an 112 IPv4-only network and an IPv6-only network, and is capable of 113 performing IP header translation between IPv4 and IPv6 according 114 to [RFC6145]. 116 1.1. The Scenario 118 Due to exhaustion of public IPv4 addresses, there has been a 119 continuing effort within the IETF on IPv6 transitional techniques. 120 In the course of the transition, it is certain that networks based on 121 IPv4 and IPv6 technologies respectively, will co-exist at least for 122 some time. One scenario of this co-existence is the inter-connection 123 of IPv4-only and IPv6-only networks, and in particular, when an 124 IPv6-only network serves as inter-connection between several 125 segregated IPv4-only networks. In this scenario, IPv4 packets are 126 transported over the IPv6 network between IPv4 networks. In order to 127 forward an IPv4 packet from a source IPv4 network to the destination 128 IPv4 network, IPv4 reachability information must be exchanged between 129 the IPv4 networks by some mechanism. 131 In general, running an IPv6-only network would reduce operational 132 expenditure and optimize the operation compared to IPv4-IPv6 dual- 133 stack environment. Some solutions have been proposed to allow 134 delivery of IPv4 services over an IPv6-only network. This document 135 specifies an engineering technique that separates the routing table 136 dedicated to IPv4-embedded IPv6 destinations from the routing table 137 used for native IPv6 destinations. 139 OSPFv3 is designed to support multiple instances or multiple 140 topologies. Maintaining a separate routing table for IPv4-embedded 141 IPv6 routes would simplify the implementation, trouble shooting and 142 operation; it also prevents overload of the native IPv6 routing 143 tables. A separate routing table can be generated from a separate 144 routing instance or a separate routing topology. 146 1.2. Routing Solution per RFC5565 148 The aforementioned scenario is described in [RFC5565], i.e., IPv4 149 -over-IPv6 scenario, where the network core is IPv6-only, and the 150 inter-connected IPv4 networks are called IPv4 client networks. The 151 P(rovider) Routers in the core only support IPv6 but the AFBRs 152 (Address Family Border Routers) support IPv4 on interfaces facing 153 IPv4 client networks, and IPv6 on interfaces facing the core. The 154 routing solution defined in [RFC5565] for this scenario is to run 155 i-BGP among AFBRs to exchange IPv4 routing information in the core, 156 and the IPv4 packets are forwarded from one IPv4 client network to 157 the other through a softwire using tunneling technology such as MPLS 158 LSP, GRE, L2TPv3, etc. 160 1.3. An Alternative Routing Solution with OSPFv3 162 In this document, we propose an alternative routing solution for the 163 scenario described in Section 1.1, where several segregated IPv4 164 networks, called IPv4 client networks, are inter-connected by an IPv6 165 network. The IPv6 network and the inter-connected IPv4 networks may 166 or may not belong to the same Autonomous System. We refer to the 167 border node on the boundary of an IPv4 client network and the IPv6 168 network as an Address Family Translation Border Router (AFXLBR), 169 which supports both the IPv4 and IPv6 address families, and is 170 capable of translating an IPv4 packet to an IPv6 packet, and vice 171 versa, according to [RFC6145]. The described scenario is illustrated 172 in Figure 1. 174 +--------+ +--------+ 175 | IPv4 | | IPv4 | 176 | Client | | Client | 177 | Network| | Network| 178 +--------+ +--------+ 179 | \ / | 180 | \ / | 181 | \ / | 182 | X | 183 | / \ | 184 | / \ | 185 | / \ | 186 +--------+ +--------+ 187 | AFXLBR | | AFXLBR | 188 +--| IPv4/6 |---| IPv4/6 |--+ 189 | +--------+ +--------+ | 190 +--------+ | | +--------+ 191 | IPv6 | | | | IPv6 | 192 | Client |----| |----| Client | 193 | Network| | IPv6 | | Network| 194 +--------+ | only | +--------+ 195 | | 196 | +--------+ +--------+ | 197 +--| AFXLBR |---| AFXLBR |--+ 198 | IPv4/6 | | IPv4/6 | 199 +--------+ +--------+ 200 | \ / | 201 | \ / | 202 | \ / | 203 | X | 204 | / \ | 205 | / \ | 206 | / \ | 207 +--------+ +--------+ 208 | IPv4 | | IPv4 | 209 | Client | | Client | 210 | Network| | Network| 211 +--------+ +--------+ 213 Figure 1: Segregated IPv4 Networks Inter-connected by an IPv6 Network 215 Since the scenario occurs most commonly within an organization, an 216 IPv6 prefix can be locally allocated and used by AFXLBRs to construct 217 IPv4-embedded IPv6 addresses according to [RFC6052]. The embedded 218 IPv4 address or prefix belongs to an IPv4 client network that is 219 connected to the AFXLBR. An AFXLBR injects IPv4-embedded IPv6 220 addresses and prefixes into the IPv6 network using OSPFv3, and it 221 also installs IPv4-embedded IPv6 routes advertised by other AFXLBRs. 223 When an AFXLBR receives an IPv4 packet from a locally connected IPv4 224 client network and destined to a remote IPv4 client network, it 225 translates the IPv4 header to the relevant IPv6 header according to 226 [RFC6145], and in that process, source and destination IPv4 address 227 are translated into IPv4-embedded IPv6 addresses, respectively, 228 according to [RFC6052]. The resulting IPv6 packet is then forwarded 229 to the AFXLBR that connects to the destination IPv4 client network. 230 The remote AFXLBR derives the IPv4 source and destination addresses 231 from the IPv4-embedded IPv6 addresses, respectively, according to 232 [RFC6052], and translates the header of the received IPv6 packet to 233 the relevant IPv4 header according to [RFC6145]. The resulting IPv4 234 packet is then forwarded according to the IPv4 routing table 235 maintained on the AFXLBR. 237 There are use cases where the proposed routing solution is useful. 238 One case is that some border nodes do not participate in i-BGP for 239 routes exchange, or i-BGP is not used at all. Another case is when 240 tunnels are not deployed in the IPv6 network, or native IPv6 241 forwarding is preferred. Note that with this routing solution, the 242 IPv4 and IPv6 header translation performed in both directions by the 243 AFXLBR is stateless. 245 1.4. OSPFv3 Routing with a Specific Topology 247 In general, IPv4-embedded IPv6 packets can be forwarded just like 248 native IPv6 packets with OSPFv3 running in the IPv6 network. 249 However, this would require IPv4-embedded IPv6 routes to be flooded 250 throughout the entire IPv6 network and stored on every router. This 251 is not desirable from the scaling perspective. Moreover, since all 252 IPv6 routes are stored in the same routing table, it would be 253 inconvenient to manage the resource required for routing and 254 forwarding based on traffic category, if so desired. 256 To improve the situation, a separate OSPFv3 routing table can be 257 constructed that is dedicated to the IPv4-embedded IPv6 topology, and 258 that table is solely used for routing IPv4-embedded IPv6 packets in 259 the IPv6 network. The IPv4-embedded IPv6 topology includes all the 260 participating AFXLBR routers and a set of P Routers providing 261 redundant connectivity with alternate routing paths. 263 There are two methods to build a separate OSPFv3 routing table for 264 IPv4-embedded IPv6 routes: 266 o The first one is to run a separate OSPFv3 instance for 267 IPv4-embedded IPv6 topology in the IPv6 network according to 268 [RFC5838]. 270 o The second one is to stay with the existing OSPFv3 instance that 271 already operates in the IPv6 network, but maintain a separate 272 IPv4-embedded IPv6 topology, according to 273 [I-D.ietf-ospf-mt-ospfv3]. 275 With either method, there would be a dedicated IPv4-embedded IPv6 276 topology that is maintained on all participating AFXLBR and P 277 Routers, along with a dedicated IPv4-embedded IPv6 routing table. 278 This routing table is then used solely in the IPv6 network for 279 IPv4-embedded IPv6 packets. 281 It would be an operator's preference as which method is to be used. 282 This document elaborates on how configuration is done for each method 283 and related routing issues that are common to both. 285 This document only focuses on unicast routing for IPv4-embedded IPv6 286 packets using OSPFv3. 288 2. Requirements Language 290 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 291 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 292 document are to be interpreted as described in [RFC2119]. 294 3. Provisioning 296 3.1. Deciding the IPv4-embedded IPv6 Topology 298 Before deploying configurations that use a separate OSPFv3 routing 299 table for IPv4-embedded IPv6 addresses and prefixes, a decision must 300 be made on the set of routers and their interfaces in the IPv6 301 network that should be part of the IPv4-embedded IPv6 topology. 303 For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that 304 connect to IPv4 client networks MUST be members of this topology. An 305 AFXLBR MUST have at least one connection with a P Router in the IPv6 306 network or another AFXLBR. 308 The IPv4-embedded IPv6 topology is a sub-topology of the entire IPv6 309 network, and if all routers (including AFXLBRs and P routers) and all 310 their interfaces are included, the two topologies converge. 311 Generally speaking, when this sub-topology contains more inter- 312 connected P Routers, there would be more routing paths across the 313 IPv6 network from one IPv4 client network to the other; however, this 314 requires more routers in the IPv6 network to participate in 315 IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6 316 topology MUST be continuous with no partitions. 318 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 320 In an IPv6 network, in order to maintain a separate IPv6 routing 321 table that contains routes for IPv4-embedded IPv6 destinations only, 322 OSPFv3 needs to use the mechanism defined either in [RFC5838] or in 323 [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as 324 described in Section 3.3 and Section 3.4, respectively. 326 3.3. OSPFv3 Topology with a Separate Instance ID 328 It is assumed that the IPv6 network that is inter-connected with IPv4 329 networks in this document is under one administration and as such, an 330 OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3 331 operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6 332 network. This IID is configured on OSPFv3 router interfaces that 333 participate in the IPv4-embedded IPv6 topology. 335 The range for a locally configured OSPFv3 IID is allocated from 192 336 to 255, inclusive, as "Private Use" per 337 [I-D.ietf-ospf-ospfv3-iid-registry-update]. This IID must be used to 338 encode the "Instance ID" field in the packet header of OSPFv3 packets 339 associated with the OSPFv3 instance. 341 In addition, the "AF" bit in the OSPFv3 Option field MUST be set. 343 During Hello packet processing, an adjacency may only be established 344 when the received Hello packet contains the same Instance ID as 345 configured on the receiving OSPFv3 interface. This insures that only 346 interfaces configured as part of the OSPFv3 unicast IPv4-embedded 347 IPv6 topology are used for IPv4-embedded IPv6 unicast routing. 349 For more details, the reader is referred to [RFC5838]. 351 3.4. OSPFv3 Topology with the Default Instance 353 Similar to that as described in the previous section, an OSPFv3 354 multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3 355 operation including unicast IPv4-embedded IPv6 routing in an IPv6 356 network. This MT-ID is configured on each OSPFv3 router interface 357 that participates in this routing topology. 359 The range for a locally configured OSPFv3 MT-ID is from 32 to 255, 360 inclusive, and this MT-ID must be used to encode the "MT-ID" field 361 included in extended Link State Advertisements (LSAs) for the 362 IPv4-embedded IPv6 unicast topology as documented in 363 [I-D.ietf-ospf-mt-ospfv3]. 365 In addition, the MT bit in the OSPFv3 Option field MUST be set. 367 For more details, the reader is referred to 368 [I-D.ietf-ospf-mt-ospfv3]. 370 4. IP Packets Translation 372 When transporting IPv4 packets across an IPv6 network with the 373 mechanism described above (Section 3.3 and Section 3.4), an IPv4 374 packet is translated to an IPv6 packet at the ingress AFXLBR, and the 375 IPv6 packet is translated back to an IPv4 packet at the egress 376 AFXLBR. The IP packet header translation is accomplished in 377 stateless manner according to rules specified in [RFC6145], with the 378 address translation details explained in the next sub-section. 380 4.1. Address Translation 381 Prior to address translation, an IPv6 prefix is allocated by the 382 operator and it is used to form IPv4-embedded IPv6 addresses. 384 The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 385 64:ff9b::/96, or a network-specific prefix that is unique to the 386 organzation; and for the latter case, the IPv6 prefix length may be 387 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is used 388 during the address translation between an IPv4 address and an 389 IPv4-embedded IPv6 address, as described in [RFC6052]. 391 During translation from an IPv4 header to an IPv6 header at an 392 ingress AFXLBR, the source IPv4 address and destination IPv4 address 393 are translated into the corresponding IPv6 source address and 394 destination IPv6 address, respectively, and during translation from 395 an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 396 address and destination IPv6 address are translated into the 397 corresponding IPv4 source address and destination IPv4 address, 398 respectively. Note that the address translation is accomplished in a 399 stateless manner. 401 When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only 402 global IPv4 addresses to be embedded in the IPv6 address. An IPv6 403 address composed with a WKP and a non-global IPv4 address is hence 404 invalid, and packets that contain such address received by an AFXLBR 405 are dropped. 407 In the case where both the IPv4 client networks and the IPv6 transit 408 network belong to the same organization, non-global IPv4 addresses 409 may be used with a network-specific prefix [RFC6052]. 411 5. Advertising IPv4-embedded IPv6 Routes 413 In order to forward IPv4 packets to the proper destination across an 414 IPv6 network, IPv4 reachability needs to be disseminated throughout 415 the IPv6 network and this is performed by AFXLBRs that connect to 416 IPv4 client networks using OSPFv3. 418 With the scenario described in this document, i.e., a set of AFXLBRs 419 that inter-connect a bunch of IPv4 client networks with an IPv6 420 network, the IPv4 networks and IPv6 networks belong to the same or 421 separate Autonomous Systems, and as such, these AFXLBRs behave as AS 422 Boundary Routers (ASBRs). 424 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit 425 Network 427 IPv4 addresses and prefixes in an IPv4 client network are translated 428 into IPv4-embedded IPv6 addresses and prefixes, respectively, using 429 the IPv6 prefix allocated by the operator and the method specified in 430 [RFC6052]. These routes are then advertised by one or more attached 431 ASBRs into the IPv6 transit network using AS-External-LSAs [RFC5340], 432 i.e., with advertising scope comprising the entire Autonomous System. 434 5.1.1. Routing Metrics 436 By default, the metric in an AS-External-LSA that carries an 437 IPv4-embedded IPv6 address or prefixes is a Type 1 external metric, 438 which is comparable to the link state metric and we assume that in 439 most cases, OSPFv2 is used in client IPv4 networks. This metric is 440 added to the metric of the intra-AS path to the ASBR during the 441 OSPFv3 route calculation. Through ASBR configuration, the metric can 442 be set to a Type 2 external metric, which is considered much larger 443 than the metric for any intra-AS path. Refer to the OSPFv3 444 specification [RFC5340] for more detail. In either case, an external 445 metric may take the same value as in an IPv4 network (using OSPFv2 or 446 another routing protocol), but may also be specified based on some 447 routing policy; the details of which are outside of the scope of this 448 document. 450 5.1.2. Forwarding Address 452 If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is 453 used to carry an IPv6 address, that must also be an IPv4-embedded 454 IPv6 address where the embedded IPv4 address is the destination 455 address in an IPv4 client network. However, since an AFXLBR sits on 456 the border of an IPv4 network and an IPv6 network, it is RECOMMENDED 457 that the "Forwarding Address" field is not used, so that the AFXLBR 458 can make the forwarding decision based on its own IPv4 routing table. 460 5.2. Advertising IPv4 Addresses into Client Networks 462 IPv4-embedded IPv6 routes injected into the IPv6 network from one 463 IPv4 client network MAY be advertised into another IPv4 client 464 network, after the associated destination addresses and prefixes are 465 translated back to IPv4 addresses and prefixes, respectively. This 466 operation is similar to normal OSPFv3 operation, wherein an AS- 467 External-LSA can be advertised in a non-backbone area by default. 469 An IPv4 client network can limit which advertisements it receives 470 through configuration. 472 For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT 473 be advertised into any IPv6 client networks that also connected to 474 the IPv6 transit network. 476 6. Aggregation on IPv4 Addresses and Prefixes 478 In order to reduce the amount of LSAs that are injected to the IPv6 479 network, an implementation should provide mechanisms to aggregate 480 IPv4 addresses and prefixes at AFXLBR prior to advertisement as 481 IPv4-embedded IPv6 addresses and prefixes. In general, the 482 aggregation practice should be based on routing policy, which is 483 outside of the scope of this document. 485 7. Forwarding 487 There are three cases in forwarding IP packets in the scenario 488 described in this document: 490 1. On an AFXLBR, if an IPv4 packet that is received on an interface 491 connecting to an IPv4 segregated client network with a 492 destination IPv4 address belonging to another IPv4 client 493 network, the header of the packet is translated to the 494 corresponding IPv6 header as described in Section 4, and the 495 packet is then forwarded to the destination AFXLBR that 496 advertised the IPv4-embedded IPv6 address into the IPv6 network. 498 2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 499 embedded destination IPv4 address is in its IPv4 routing table, 500 the header of the packet is translated to the corresponding IPv4 501 header as described in Section 4, and the packet is then 502 forwarded accordingly. 504 3. On any router that is within the IPv4-embedded IPv6 topology 505 subset of the IPv6 network, if an IPv4-embedded IPv6 packet is 506 received and a route is found in the IPv4-embedded IPv6 routing 507 table, the packet is forwarded to the IPv6 next-hop just like the 508 handling for a normal IPv6 packet, without any translation. 510 The classification of IPv4-embedded IPv6 packet is according to the 511 IPv6 prefix of the destination address, which is either the Well 512 Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in 513 [RFC6052]. 515 8. Backdoor Connections 517 In some deployments, IPv4 client networks are inter-connected across 518 the IPv6 network, but also directly connected to each other. The 519 direct connections between IPv4 client networks, as sometimes called 520 "backdoor" connections, can certainly be used to transport IPv4 521 packets between IPv4 client networks. In general, backdoor 522 connections are preferred over the IPv6 network since there requires 523 no address family translation. 525 9. Prevention of Loops 527 If an LSA sent from an AFXLBR into a client network could then be 528 received by another AFXLBR, it would be possible for routing loops to 529 occur. To prevent loops, an AFXLBR MUST set the DN-bit [RFC4576] in 530 any LSA that it sends to a client network. The AFXLBR MUST also 531 ignore any LSA received from a client network that already has the 532 DN-bit sent. 534 10. MTU Issues 536 In the IPv6 network, there are no new MTU issues introduced by this 537 document. If a separate OSPFv3 instance (per [RFC5838]) is used for 538 IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is 539 the same as that of the default OSPFv3 instance. If a separate 540 OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is used for 541 IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is 542 the same as that of the default OSPFv3 topology. 544 However, the MTU in the IPv6 network may be different than that of 545 IPv4 client networks. Since an IPv6 router will never fragment a 546 packet, the packet size of any IPv4-embedded IPv6 packet entering the 547 IPv6 network must be equal to or less than the MTU of the IPv6 548 network. In order to achieve this requirement, it is recommended 549 that AFXLBRs perform IPv6 path discovery among themselves and the 550 resulting MTU, after taking into account of the difference between 551 the IPv4 header length and the IPv6 header length, must be 552 "propagated" into IPv4 client networks, e.g., included in the OSPFv2 553 Database Description packet. 555 The details of passing the proper MTU into IPv4 client networks are 556 beyond the scope of this document. 558 11. Security Considerations 560 There are several security aspects that require attention in the 561 deployment practice described in this document. 563 In the OSPFv3 transit network, the security considerations for OSPFv3 564 are handled as usual, and in particular, authentication mechanisms 565 described in [RFC6506] can be deployed. 567 When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 568 routing, the same Security Association (SA) (refer to [RFC4552] ) 569 MUST be used by the embedded IPv4 address instance as other instances 570 utilizing the same link as specified in [RFC5838]. 572 Security considerations as documented in [RFC6052] must also be 573 thought through with proper implementation including the following: 575 o The IPv6 prefix that is used to carry an embedded IPv4 address 576 (refer to Section 4.1) must be configured by the authorized 577 operator on all participating AFXLBRs in a secure manner. This is 578 to help prevent an malicious attack resulting in network 579 disruption, denial of service, and possible information 580 disclosure. 582 o Effective mechanisms (such as reverse path checking) must be 583 implemented in the IPv6 transit network (including AFXLIBR nodes) 584 to prevent spoofing on embedded IPv4 addresses, which, otherwise, 585 might be used as source addresses of malicious packets. 587 o If firewalls are used in IPv4 and/or IPv6 networks, the 588 configuration on the routers must be consistent so there are no 589 holes in the IPv4 address filtering. 591 The details of security handling are beyond the scope of this 592 document. 594 12. Operational Considerations 596 This document put together some mechanisms based on existing 597 technologies developed by IETF as an integrated solution to transport 598 IPv4 packets over an IPv6 network using a separate OSPFv3 routing 599 table. There are several aspects that require attention for the 600 deployment and operation. 602 The tunnel-based solution documented in [RFC5565] and the solution 603 proposed in this document are both used for transporting IPv4 packets 604 over an IPv6 network, with different mechanisms. The two methods are 605 not related to each other, and they can co-exist in the same network 606 if so deployed, without any conflict. 608 If one approach is to be deployed, it is the operator's decision for 609 the choice. Note that each approach has its own characteristics and 610 requirements. E.g., the tunnel-based solution requries a mesh of 611 inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as 612 iBGP to exchange routes between AFBRs ([RFC5565]); the approach in 613 this document requires AFXLBR capable of perfoming IPv4-IPv6 packet 614 header translation per [RFC6145]. 616 To deploy the solution as documented here, there requires some 617 configurations. An IPv6 prefix must first be chosen that is used to 618 form all the IPv4-embedded IPv6 addresses and prefixes advertised by 619 AFXLBR in the IPv6 network; the detail is referred to Section 4.1. 621 If the IPv4-embedded IPv6 routing table is created by using a 622 separate OSPFv3 instance in the IPv6 network, configuration is 623 accomplished according to [RFC5838], as described in Section 3.3, and 624 if the default OSPFv3 instance is used instead, configuration is 625 accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in 626 Section 3.4. 628 Note this document does not change any behavior of OSPFv3, and the 629 existing or common practice should apply, in the context of 630 scalability. For example, the amount of routes that are advertised 631 by OSPFv3 is one key concern. With the solution as described in this 632 document, IPv4-embedded IPv6 addresses and prefixes will be injected 633 by AFXLBR into some part of the IPv6 network (see Section 3.1 for 634 details), and a separate routing table will be used for IPv4-embedded 635 IPv6 routing. Care must be taken during the network design, such 636 that 1) aggregation are performed on IPv4 addresses and prefixes 637 before being advertised in the IPv6 network as described in 638 Section 6, and 2) estimates are made as the amount of IPv4-embedded 639 IPv6 routes that would be disseminated in the IPv6 network, and the 640 size of the separate OSPFv3 routing table. 642 13. IANA Considerations 644 No new IANA assignments are required for this document. 646 14. Acknowledgements 648 Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and 649 Brian Carpenter for their comments. 651 15. References 653 15.1. Normative References 655 [I-D.ietf-ospf-mt-ospfv3] 656 Mirtorabi, S. and A. Roy, "Multi-topology routing in 657 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 658 progress), July 2007. 660 [I-D.ietf-ospf-ospfv3-iid-registry-update] 661 Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry 662 Update", draft-ietf-ospf-ospfv3-iid-registry-update-04 663 (work in progress), April 2013. 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a 669 Link State Advertisement (LSA) Options Bit to Prevent 670 Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", 671 RFC 4576, June 2006. 673 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 674 Framework", RFC 5565, June 2009. 676 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 677 Aggarwal, "Support of Address Families in OSPFv3", RFC 678 5838, April 2010. 680 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 681 Algorithm", RFC 6145, April 2011. 683 15.2. Informative References 685 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 686 for OSPFv3", RFC 4552, June 2006. 688 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 689 for IPv6", RFC 5340, July 2008. 691 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 692 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 693 October 2010. 695 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 696 Authentication Trailer for OSPFv3", RFC 6506, February 697 2012. 699 Authors' Addresses 701 Dean Cheng 702 Huawei Technologies 703 2330 Central Expressway 704 Santa Clara, California 95050 705 USA 707 Email: dean.cheng@huawei.com 709 Mohamed Boucadair 710 France Telecom 711 Rennes 35000 712 France 714 Email: mohamed.boucadair@orange.com 715 Alvaro Retana 716 Cisco Systems 717 7025 Kit Creek Rd. 718 Research Triangle Park, North Carolina 27709 719 USA 721 Email: aretana@cisco.com