idnits 2.17.1 draft-ietf-ospf-ipv4-embedded-ipv6-routing-09.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 (March 30, 2013) is 4038 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: October 01, 2013 France Telecom 6 A. Retana 7 Cisco Systems 8 March 30, 2013 10 Routing for IPv4-embedded IPv6 Packets 11 draft-ietf-ospf-ipv4-embedded-ipv6-routing-09 13 Abstract 15 This document describes routing packets destined to IPv4-embedded 16 IPv6 addresses across an IPv6 core using OSPFv3 with a separate 17 routing table. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 01, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. The Scenario . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . 4 56 1.3. An Alternative Routing Solution with OSPFv3 . . . . . . . 4 57 1.4. OSPFv3 Routing with a Specific Topology . . . . . . . . . 6 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 59 3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . 7 61 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 7 62 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 63 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8 64 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8 65 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 9 66 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 9 67 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 68 Transit Network . . . . . . . . . . . . . . . . . . . . . 10 69 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10 70 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 10 71 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 10 72 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 11 73 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 12 75 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12 76 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 14.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 This document describes a routing scenario where IPv4 packets are 88 transported over an IPv6 network, based on [RFC6145] and [RFC6052], 89 along with a separate OSPFv3 routing table for IPv4-embedded IPv6 90 routes in the IPv6 network. This document does not introduce any new 91 IPv6 transition mechanism. 93 In this document the following terminology is used: 95 o An IPv4-embedded IPv6 address denotes an IPv6 address which 96 contains an embedded 32-bit IPv4 address constructed according to 97 the rules defined in [RFC6052]. 99 o IPv4-embedded IPv6 packets are packets of which destination 100 addresses are IPv4-embedded IPv6 addresses. 102 o AFBR (Address Family Border Router, [RFC5565]) refers to an edge 103 router, which supports both IPv4 and IPv6 address families, but 104 the backbone network it connects to only supports either the IPv4 105 or IPv6 address family. 107 o AFXLBR (Address Family Translation Border Router) is defined in 108 this document. It refers to a border router that supports both 109 IPv4 and IPv6 address families, located on the boundary of an 110 IPv4-only network and an IPv6-only network, and is capable of 111 performing IP header translation between IPv4 and IPv6 according 112 to [RFC6145]. 114 1.1. The Scenario 116 Due to exhaustion of public IPv4 addresses, there has been a 117 continuing effort within the IETF on IPv6 transitional techniques. 118 In the course of the transition, it is certain that networks based on 119 IPv4 and IPv6 technologies respectively, will co-exist at least for 120 some time. One scenario of this co-existence is the inter-connection 121 of IPv4-only and IPv6-only networks, and in particular, when an 122 IPv6-only network serves as inter-connection between several 123 segregated IPv4-only networks. In this scenario, IPv4 packets are 124 transported over the IPv6 network between IPv4 networks. In order to 125 forward an IPv4 packet from a source IPv4 network to the destination 126 IPv4 network, IPv4 reachability information must be exchanged between 127 the IPv4 networks by some mechanism. 129 In general, running an IPv6-only network would reduce OPEX and 130 optimize the operation compared to IPv4-IPv6 dual-stack environment. 131 Some solutions have been proposed to allow delivery of IPv4 services 132 over an IPv6-only network. This document focuses on an engineering 133 technique which aims to separate the routing table dedicated to 134 IPv4-embedded IPv6 destinations from native IPv6 ones. 136 Maintaining a separate routing table for IPv4-embedded IPv6 routes 137 optimizes IPv4 packets forwarding. It also prevents overload of the 138 native IPv6 routing tables. A separate routing table can be 139 generated from a separate routing instance or a separate routing 140 topology. 142 1.2. Routing Solution per RFC5565 144 The aforementioned scenario is described in [RFC5565], i.e., IPv4 145 -over-IPv6 scenario, where the network core is IPv6-only, and the 146 inter-connected IPv4 networks are called IPv4 client networks. The P 147 Routers in the core only support IPv6 but the AFBRs (Address Family 148 Border Routers) support IPv4 on interfaces facing IPv4 client 149 networks, and IPv6 on interfaces facing the core. The routing 150 solution defined in [RFC5565] for this scenario is to run i-BGP among 151 AFBRs to exchange IPv4 routing information in the core, and the IPv4 152 packets are forwarded from one IPv4 client network to the other 153 through a softwire using tunneling technology such as MPLS LSP, GRE, 154 L2TPv3, etc. 156 1.3. An Alternative Routing Solution with OSPFv3 158 In this document, we propose an alternative routing solution for the 159 scenario described in Section 1.1, where several segregated IPv4 160 networks, called IPv4 client networks, are inter-connected by an IPv6 161 network, which belongs to a different Autonomous System from those of 162 the IPv4 networks. We refer to the border node on the boundary of an 163 IPv4 client network and the IPv6 network as an Address Family 164 Translation Border Router (AFXLBR), which supports both the IPv4 and 165 IPv6 address families, and is capable of translating an IPv4 packet 166 to an IPv6 packet, and vice versa, according to [RFC6145]. The 167 described scenario is illustrated in Figure 1. 169 +--------+ +--------+ 170 | IPv4 | | IPv4 | 171 | Client | | Client | 172 | Network| | Network| 173 +--------+ +--------+ 174 | \ / | 175 | \ / | 176 | \ / | 177 | X | 178 | / \ | 179 | / \ | 180 | / \ | 181 +--------+ +--------+ 182 | AFXLBR | | AFXLBR | 183 +--| IPv4/6 |---| IPv4/6 |--+ 184 | +--------+ +--------+ | 185 +--------+ | | +--------+ 186 | IPv6 | | | | IPv6 | 187 | Client |----| |----| Client | 188 | Network| | IPv6 | | Network| 189 +--------+ | only | +--------+ 190 | | 191 | +--------+ +--------+ | 192 +--| AFXLBR |---| AFXLBR |--+ 193 | IPv4/6 | | IPv4/6 | 194 +--------+ +--------+ 195 | \ / | 196 | \ / | 197 | \ / | 198 | X | 199 | / \ | 200 | / \ | 201 | / \ | 202 +--------+ +--------+ 203 | IPv4 | | IPv4 | 204 | Client | | Client | 205 | Network| | Network| 206 +--------+ +--------+ 208 Figure 1: Segregated IPv4 Networks Inter-connected by an IPv6 Network 210 Since the scenario occurs most commonly in a single Autonomous 211 System, an IPv6 prefix can be locally allocated and used by AFXLBRs 212 to construct IPv4-embedded IPv6 addresses according to [RFC6052]. 213 The embedded IPv4 address or prefix belongs to an IPv4 client network 214 that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded 215 IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and 216 it also installs IPv4-embedded IPv6 routes advertised by other 217 AFXLBRs. 219 When an AFXLBR receives an IPv4 packet from a locally connected IPv4 220 client network and destined to a remote IPv4 client network, it 221 translates the IPv4 header to the relevant IPv6 header according to 222 [RFC6145], and in that process, source and destination IPv4 address 223 are translated into IPv4-embedded IPv6 addresses, respectively, 224 according to [RFC6052]. The resulting IPv6 packet is then forwarded 225 to the AFXLBR that connects to the destination IPv4 client network. 226 The remote AFXLBR derives the IPv4 source and destination addresses 227 from the IPv4-embedded IPv6 addresses, respectively, according to 228 [RFC6052], and translates the header of the received IPv6 packet to 229 the relevant IPv4 header according to [RFC6145]. The resulting IPv4 230 packet is then forwarded according to the IPv4 routing table 231 maintained on the AFXLBR. 233 There are use cases where the proposed routing solution is useful. 234 One case is that some border nodes do not participate in i-BGP for 235 routes exchange, or i-BGP is not used at all. Another case is when 236 tunnels are not deployed in the IPv6 network, or native IPv6 237 forwarding is preferred. Note that with this routing solution, the 238 IPv4 and IPv6 header translation performed in both directions by the 239 AFXLBR is stateless. 241 1.4. OSPFv3 Routing with a Specific Topology 243 In general, IPv4-embedded IPv6 packets can be forwarded just like 244 native IPv6 packets with OSPFv3 running in the IPv6 network. 245 However, this would require IPv4-embedded IPv6 routes to be flooded 246 throughout the entire IPv6 network and stored on every router. This 247 is not desirable from the scaling perspective. Moreover, since all 248 IPv6 routes are stored in the same routing table, it would be 249 inconvenient to manage the resource required for routing and 250 forwarding based on traffic category, if so desired. 252 To improve the situation, a separate OSPFv3 routing table can be 253 constructed that is dedicated to the IPv4-embedded IPv6 topology, and 254 that table is solely used for routing IPv4-embedded IPv6 packets in 255 the IPv6 network. The IPv4-embedded IPv6 topology includes all the 256 participating AFXLBR routers and a set of P Routers providing 257 redundant connectivity with alternate routing paths. 259 There are two methods to build a separate OSPFv3 routing table for 260 IPv4-embedded IPv6 routes: 262 o The first one is to run a separate OSPFv3 instance for 263 IPv4-embedded IPv6 topology in the IPv6 network according to 264 [RFC5838]. 266 o The second one is to stay with the existing OSPFv3 instance that 267 already operates in the IPv6 network, but maintain a separate 268 IPv4-embedded IPv6 topology, according to 269 [I-D.ietf-ospf-mt-ospfv3]. 271 With either method, there would be a dedicated IPv4-embedded IPv6 272 topology that is maintained on all participating AFXLBR and P 273 Routers, along with a dedicated IPv4-embedded IPv6 routing table. 274 This routing table is then used solely in the IPv6 network for 275 IPv4-embedded IPv6 packets. 277 It would be an operator's preference as which method is to be used. 278 This document elaborates on how configuration is done for each method 279 and related routing issues that are common to both. 281 This document only focuses on unicast routing for IPv4-embedded IPv6 282 packets using OSPFv3. 284 2. Requirements Language 286 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 287 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 288 document are to be interpreted as described in [RFC2119]. 290 3. Provisioning 292 3.1. Deciding the IPv4-embedded IPv6 Topology 294 Before deploying configurations that use a separate OSPFv3 routing 295 table for IPv4-embedded IPv6 addresses and prefixes, a decision must 296 be made on the set of routers and their interfaces in the IPv6 297 network that should be part of the IPv4-embedded IPv6 topology. 299 For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that 300 connect to IPv4 client networks MUST be members of this topology. An 301 AFXLBR MUST have at least one connection with a P Router in the IPv6 302 network or another AFXLBR. 304 The IPv4-embedded IPv6 topology is a sub-topology of the entire IPv6 305 network, and if all routers (including AFXLBRs and P-routers) and all 306 their interfaces are included, the two topologies converge. 307 Generally speaking, when this sub-topology contains more inter- 308 connected P Routers, there would be more routing paths across the 309 IPv6 network from one IPv4 client network to the other; however, this 310 requires more routers in the IPv6 network to participate in 311 IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6 312 topology MUST be continuous with no partitions. 314 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 316 In an IPv6 network, in order to maintain a separate IPv6 routing 317 table that contains routes for IPv4-embedded IPv6 destinations only, 318 OSPFv3 needs to use the mechanism defined either in [RFC5838] or in 319 [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as 320 described in Section 3.3 and Section 3.4, respectively. 322 3.3. OSPFv3 Topology with a Separate Instance ID 323 It is assumed that the IPv6 network that is inter-connected with IPv4 324 networks in this document is under a single Autonomous System and as 325 such, an OSPFv3 instance ID (IID) is allocated locally and used for 326 OSPFv3 operation dedicated to unicast IPv4-embedded IPv6 routing in 327 an IPv6 network. This IID is configured on OSPFv3 router interfaces 328 that participate in the IPv4-embedded IPv6 topology. 330 The range for a locally configured OSPFv3 IID is from 192 to 255, 331 inclusive, and this IID must be used to encode the "Instance ID" 332 field in the packet header of OSPFv3 packets associated with the 333 OSPFv3 instance. 335 In addition, the "AF" bit in the OSPFv3 Option field MUST be set. 337 During Hello packet processing, an adjacency may only be established 338 when the received Hello packet contains the same Instance ID as 339 configured on the receiving OSPFv3 interface. This insures that only 340 interfaces configured as part of the OSPFv3 unicast IPv4-embedded 341 IPv6 topology are used for IPv4-embedded IPv6 unicast routing. 343 For more details, the reader is referred to [RFC5838]. 345 3.4. OSPFv3 Topology with the Default Instance 347 Similar to that as described in the previous section, an OSPFv3 348 multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3 349 operation including unicast IPv4-embedded IPv6 routing in an IPv6 350 network. This MT-ID is configured on each OSPFv3 router interface 351 that participates in this routing topology. 353 The range for a locally configured OSPFv3 MT-ID is from 32 to 255, 354 inclusive, and this MT-ID must be used to encode the "MT-ID" field 355 included in extended Link State Advertisements (LSAs) for the 356 IPv4-embedded IPv6 unicast topology as documented in 357 [I-D.ietf-ospf-mt-ospfv3]. 359 In addition, the MT bit in the OSPFv3 Option field MUST be set. 361 For more details, the reader is referred to 362 [I-D.ietf-ospf-mt-ospfv3]. 364 4. IP Packets Translation 366 When transporting IPv4 packets across an IPv6 network with the 367 mechanism described above, an IPv4 packet is translated to an IPv6 368 packet at the ingress AFXLBR, and the IPv6 packet is translated back 369 to an IPv4 packet at the egress AFXLBR. The IP packet header 370 translation is accomplished in stateless manner according to rules 371 specified in [RFC6145], with the address translation details 372 explained in the next sub-section. 374 4.1. Address Translation 376 Prior to address translation, an IPv6 prefix is allocated by the 377 Autonomous System and it is used to form IPv4-embedded IPv6 378 addresses. 380 The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 381 64:ff9b::/96, or a network-specific prefix that is unique to the 382 Autonomous System; and for the latter case, the IPv6 prefix length 383 may be 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is 384 used during the address translation between an IPv4 address and an 385 IPv4-embedded IPv6 address, as described in [RFC6052]. 387 During translation from an IPv4 header to an IPv6 header at an 388 ingress AFXLBR, the source IPv4 address and destination IPv4 address 389 are translated into the corresponding IPv6 source address and 390 destination IPv6 address, respectively, and during translation from 391 an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 392 address and destination IPv6 address are translated into the 393 corresponding IPv4 source address and destination IPv4 address, 394 respectively. Note that the address translation is accomplished in a 395 stateless manner. 397 When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only 398 global IPv4 addresses to be embedded in the IPv6 address. An IPv6 399 address composed with a WKP and a non-global IPv4 address is hence 400 invalid, and packets that contain such address received by an AFXLBR 401 are dropped. 403 In the case where both the IPv4 client networks and the IPv6 transit 404 network belong to the same organization, non-global IPv4 addresses 405 may be used with a network-specific prefix [RFC6052]. 407 5. Advertising IPv4-embedded IPv6 Routes 409 In order to forward IPv4 packets to the proper destination across an 410 IPv6 network, IPv4 reachability needs to be disseminated throughout 411 the IPv6 network and this is performed by AFXLBRs that connect to 412 IPv4 client networks using OSPFv3. 414 With the scenario described in this document, i.e., a set of AFXLBRs 415 that inter-connect a bunch of IPv4 client networks with an IPv6 416 network, the IPv4 networks and IPv6 networks belong to separate and 417 independent Autonomous Systems, and as such, these AFXLBRs behave as 418 AS Boundary Routers (ASBRs). 420 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit 421 Network 423 IPv4 addresses and prefixes in an IPv4 client network are translated 424 into IPv4-embedded IPv6 addresses and prefixes, respectively, using 425 the IPv6 prefix allocated by the Autonomous System and the method 426 specified in [RFC6052]. These routes are then advertised by one or 427 more attached ASBRs into the IPv6 transit network using AS-External- 428 LSAs [RFC5340], i.e., with advertising scope comprising the entire 429 Autonomous System. 431 5.1.1. Routing Metrics 433 By default, the metric in an AS-External-LSA that carries an 434 IPv4-embedded IPv6 address or prefixes is a Type 1 external metric, 435 which is comparable to the link state metric and we assume that in 436 most cases, OSPFv2 is used in client IPv4 networks. This metric is 437 added to the metric of the intra-AS path to the ASBR during the 438 OSPFv3 route calculation. Through ASBR configuration, the metric can 439 be set to a Type 2 external metric, which is considered much larger 440 than the metric for any intra-AS path. Refer to the OSPFv3 441 specification [RFC5340] for more detail. In either case, an external 442 metric may take the same value as in an IPv4 network (using OSPFv2 or 443 another routing protocol), but may also be specified based on some 444 routing policy; the details of which are outside of the scope of this 445 document. 447 5.1.2. Forwarding Address 449 If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is 450 used to carry an IPv6 address, that must also be an IPv4-embedded 451 IPv6 address where the embedded IPv4 address is the destination 452 address in an IPv4 client network. However, since an AFXLBR sits on 453 the border of an IPv4 network and an IPv6 network, it is RECOMMENDED 454 that the "Forwarding Address" field is not used, so that the AFXLBR 455 can make the forwarding decision based on its own IPv4 routing table. 457 5.2. Advertising IPv4 Addresses into Client Networks 459 IPv4-embedded IPv6 routes injected into the IPv6 network from one 460 IPv4 client network MAY be advertised into another IPv4 client 461 network, after the associated destination addresses and prefixes are 462 translated back to IPv4 addresses and prefixes, respectively. This 463 operation is similar to normal OSPFv3 operation, wherein an AS- 464 External-LSA can be advertised in a non-backbone area by default. 466 An IPv4 client network can limit which advertisements it receives 467 through configuration. 469 For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT 470 be advertised into any IPv6 client networks that also connected to 471 the IPv6 transit network. 473 6. Aggregation on IPv4 Addresses and Prefixes 475 In order to reduce the amount of LSAs that are injected to the IPv6 476 network, an implementation should provide mechanisms to aggregate 477 IPv4 addresses and prefixes at AFXLBR prior to advertisement as 478 IPv4-embedded IPv6 addresses and prefixes. In general, the 479 aggregation practice should be based on routing policy, which is 480 outside of the scope of this document. 482 7. Forwarding 484 There are three cases in forwarding IP packets in the scenario 485 described in this document: 487 1. On an AFXLBR, if an IPv4 packet that is received on an interface 488 connecting to an IPv4 client network with a destination IPv4 489 address belonging to another IPv4 client network, the header of 490 the packet is translated to the corresponding IPv6 header as 491 described in Section 4, and the packet is then forwarded to the 492 destination AFXLBR that advertised the IPv4-embedded IPv6 address 493 into the IPv6 network. 495 2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 496 embedded destination IPv4 address is in its IPv4 routing table, 497 the header of the packet is translated to the corresponding IPv4 498 header as described in Section 4, and the packet is then 499 forwarded accordingly. 501 3. On any router that is within the IPv4-embedded IPv6 topology 502 subset of the IPv6 network, if an IPv4-embedded IPv6 packet is 503 received and a route is found in the IPv4-embedded IPv6 routing 504 table, the packet is forwarded to the IPv6 next-hop just like the 505 handling for a normal IPv6 packet, without any translation. 507 The classification of IPv4-embedded IPv6 packet is according to the 508 IPv6 prefix of the destination address, which is either the Well 509 Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in 510 [RFC6052]. 512 8. Backdoor Connections 514 In some deployments, IPv4 client networks are inter-connected across 515 the IPv6 network, but also directly connected to each other. The 516 direct connections between IPv4 client networks, as sometimes called 517 "backdoor" connections, can certainly be used to transport IPv4 518 packets between IPv4 client networks. In general, backdoor 519 connections are preferred over the IPv6 network since there requires 520 no address family translation. 522 9. Prevention of Loops 524 If an LSA sent from an AFXLBR into a client network could then be 525 received by another AFXLBR, it would be possible for routing loops to 526 occur. To prevent loops, an AFXLBR MUST set the DN-bit [RFC4576] in 527 any LSA that it sends to a client network. The AFXLBR MUST also 528 ignore any LSA received from a client network that already has the 529 DN-bit sent. 531 10. MTU Issues 533 In the IPv6 network, there are no new MTU issues introduced by this 534 document. If a separate OSPFv3 instance (per [RFC5838]) is used for 535 IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is 536 the same as that of the default OSPFv3 instance. If a separate 537 OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) 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 topology. 541 However, the MTU in the IPv6 network may be different than that of 542 IPv4 client networks. Since an IPv6 router will never fragment a 543 packet, the packet size of any IPv4-embedded IPv6 packet entering the 544 IPv6 network must be equal to or less than the MTU of the IPv6 545 network. In order to achieve this requirement, it is recommended 546 that AFXLBRs perform IPv6 path discovery among themselves and the 547 resulting MTU, after taking into account of the difference between 548 the IPv4 header length and the IPv6 header length, must be 549 "propagated" into IPv4 client networks, e.g., included in the OSPFv2 550 Database Description packet. 552 The details of passing the proper MTU into IPv4 client networks are 553 beyond the scope of this document. 555 11. Security Considerations 557 There are several security aspects that require attention in the 558 deployment practice described in this document. 560 In the OSPFv3 transit network, the security considerations for OSPFv3 561 are covered in [RFC5340], and in particular, IPsec can be used for 562 OSPFv3 authentication and confidentiality as suggested in [RFC5838]. 564 When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 565 routing, the same Security Association (SA) (refer to [RFC4552] ) 566 must be used by the embedded IPv4 address instance as other instances 567 utilizing the same link as specified in [RFC5838]. 569 Security considerations as currently documented in [RFC6052] must 570 also be thought through with proper implementation including the 571 following: 573 o The IPv6 prefix that is used to carry an embedded IPv4 address 574 (refer to Section 4.1) must be configured by the authorized 575 operator on all participating AFXLBRs in a secure manner. This is 576 to help prevent an malicious attack resulting in network 577 disruption, denial of service, and possible information 578 disclosure. 580 o Effective mechanisms (such as reverse path checking) must be 581 implemented in the IPv6 transit network (including AFXLIBR nodes) 582 to prevent spoofing on embedded IPv4 addresses, which, otherwise, 583 might be used as source addresses of malicious packets. 585 o If firewalls are used in IPv4 and/or IPv6 networks, the 586 configuration on the routers must be consistent so there are no 587 holes in the IPv4 address filtering. 589 The details of security handling are beyond the scope of this 590 document. 592 12. IANA Considerations 594 No new IANA assignments are required for this document. 596 13. Acknowledgements 598 Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and 599 Brian Carpenter for their comments. 601 14. References 602 14.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a 608 Link State Advertisement (LSA) Options Bit to Prevent 609 Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", 610 RFC 4576, June 2006. 612 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 613 Framework", RFC 5565, June 2009. 615 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 616 Aggarwal, "Support of Address Families in OSPFv3", RFC 617 5838, April 2010. 619 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 620 Algorithm", RFC 6145, April 2011. 622 14.2. Informative References 624 [I-D.ietf-ospf-mt-ospfv3] 625 Mirtorabi, S. and A. Roy, "Multi-topology routing in 626 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 627 progress), July 2007. 629 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 630 for OSPFv3", RFC 4552, June 2006. 632 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 633 for IPv6", RFC 5340, July 2008. 635 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 636 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 637 October 2010. 639 Authors' Addresses 641 Dean Cheng 642 Huawei Technologies 643 2330 Central Expressway 644 Santa Clara, California 95050 645 USA 647 Email: dean.cheng@huawei.com 648 Mohamed Boucadair 649 France Telecom 650 Rennes 35000 651 France 653 Email: mohamed.boucadair@orange.com 655 Alvaro Retana 656 Cisco Systems 657 7025 Kit Creek Rd. 658 Research Triangle Park, North Carolina 27709 659 USA 661 Email: aretana@cisco.com