idnits 2.17.1 draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 (September 26, 2012) is 4223 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2328' is defined on line 533, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 0 errors (**), 0 flaws (~~), 3 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: March 30, 2013 France Telecom 6 A. Retana 7 Cisco Systems 8 September 26, 2012 10 Routing for IPv4-embedded IPv6 Packets 11 draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 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 March 30, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . 5 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 59 3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . . 6 61 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing 62 Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 64 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7 65 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7 66 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 67 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8 68 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 69 Transit Network . . . . . . . . . . . . . . . . . . . . . 8 70 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 71 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9 72 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 9 73 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 10 74 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 10 76 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11 77 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 14.2. Informative References . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 This document describes a routing scenario where IPv4 packets are 89 transported over an IPv6 network. 91 In this document the following terminology is used: 93 o An IPv4-embedded IPv6 address denotes an IPv6 address which 94 contains an embedded 32-bit IPv4 address constructed according to 95 the rules defined in [RFC6052]. 97 o IPv4-embedded IPv6 packets are packets of which destination 98 addresses are IPv4-embedded IPv6 addresses. 100 o AFBR (Address Family Border Router, [RFC5565]) refers to an edge 101 router, which supports both IPv4 and IPv6 address families, but 102 the backbone network it connects to only supports either the IPv4 103 or IPv6 address family. 105 o AFXLBR (Address Family Translation Border Router) is defined in 106 this document. It refers to a border router that supports both 107 IPv4 and IPv6 address families, located on the boundary of an 108 IPv4-only network and an IPv6-only network, and is capable of 109 performing IP header translation between IPv4 and IPv6 according 110 to [RFC6145]. 112 1.1. The Scenario 114 Due to exhaustion of public IPv4 addresses, there has been a 115 continuing effort within the IETF on IPv6 transitional techniques. 116 In the course of the transition, it is certain that networks based on 117 IPv4 and IPv6 technologies respectively, will co-exist at least for 118 some time. One scenario of this co-existence is the inter-connection 119 of IPv4-only and IPv6-only networks, and in particular, when an IPv6- 120 only network serves as inter-connection between several segregated 121 IPv4-only networks. In this scenario, IPv4 packets are transported 122 over the IPv6 network between IPv4 networks. In order to forward an 123 IPv4 packet from a source IPv4 network to the destination IPv4 124 network, IPv4 reachability information must be exchanged between the 125 IPv4 networks by some mechanism. 127 In general, running an IPv6-only network would reduce OPEX and 128 optimize the operation compared to IPv4-IPv6 dual-stack environment. 129 Some solutions have been proposed to allow delivery of IPv4 services 130 over an IPv6-only network. This document focuses on an engineering 131 technique which aims to separate the routing table dedicated to IPv4- 132 embedded IPv6 destinations from native IPv6 ones. 134 Maintaining a separate routing table for IPv4-embedded IPv6 routes 135 optimizes IPv4 packets forwarding. It also prevents overload of the 136 native IPv6 routing tables. A separate routing table can be 137 generated from a separate routing instance or a separate routing 138 topology. 140 1.2. Routing Solution per RFC5565 142 The aforementioned scenario is described in [RFC5565], i.e., IPv4- 143 over-IPv6 scenario, where the network core is IPv6-only, and the 144 inter-connected IPv4 networks are called IPv4 client networks. The P 145 routers in the core only support IPv6 but the AFBRs (Address Family 146 Border Routers) support IPv4 on interfaces facing IPv4 client 147 networks, and IPv6 on interfaces facing the core. The routing 148 solution defined in [RFC5565] for this scenario is to run i-BGP among 149 AFBRs to exchange IPv4 routing information in the core, and the IPv4 150 packets are forwarded from one IPv4 client network to the other 151 through a softwire using tunneling technology such as MPLS LSP, GRE, 152 L2TPv3, etc. 154 1.3. An Alternative Routing Solution with OSPFv3 156 In this document, we propose an alternative routing solution for the 157 scenario described in Section 1.1, where several segregated IPv4 158 networks, called IPv4 client networks, are interconnected by an IPv6 159 network. We refer to the border node on the boundary of an IPv4 160 client network and the IPv6 network as an Address Family Translation 161 Border Router (AFXLBR), which supports both the IPv4 and IPv6 address 162 families, and is capable of translating an IPv4 packet to an IPv6 163 packet, and vice versa, according to [RFC6145]. 165 Since the scenario occurs most commonly in a single Autonomous 166 System, an IPv6 prefix can be locally allocated and used by AFXLBRs 167 to construct IPv4-embedded IPv6 addresses according to [RFC6052]. 168 The embedded IPv4 address or prefix belongs to an IPv4 client network 169 that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded 170 IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and 171 it also installs IPv4-embedded IPv6 routes advertised by other 172 AFXLBRs. 174 When an AFXLBR receives an IPv4 packet from a locally connected IPv4 175 client network and destined to a remote IPv4 client network, it 176 translates the IPv4 header to the relevant IPv6 header according to 177 [RFC6145], and in that process, source and destination IPv4 address 178 are translated into IPv4-embedded IPv6 addresses, respectively, 179 according to [RFC6052]. The resulting IPv6 packet is then forwarded 180 to the AFXLBR that connects to the destination IPv4 client network. 181 The remote AFXLBR derives the IPv4 source and destination addresses 182 from the IPv4-embedded IPv6 addresses, respectively, according to 183 [RFC6052], and translates the header of the received IPv6 packet to 184 the relevant IPv4 header according to [RFC6145]. The resulting IPv4 185 packet is then forwarded according to the IPv4 routing table 186 maintained on the AFXLBR. 188 There are use cases where the proposed routing solution is useful. 189 One case is that some border nodes do not participate in i-BGP for 190 routes exchange, or i-BGP is not used at all. Another case is when 191 tunnels are not deployed in the IPv6 network, or native IPv6 192 forwarding is preferred. Note that with this routing solution, the 193 IPv4 and IPv6 header translation performed in both directions by the 194 AFXLBR is stateless. 196 1.4. OSPFv3 Routing with a Specific Topology 198 In general, IPv4-embedded IPv6 packets can be forwarded just like 199 native IPv6 packets with OSPFv3 running in the IPv6 network. 200 However, this would require IPv4-embedded IPv6 routes to be flooded 201 throughout the entire IPv6 network and stored on every router. This 202 is not desirable from the scaling perspective. Moreover, since all 203 IPv6 routes are stored in the same routing table, it would be 204 inconvenient to manage the resource required for routing and 205 forwarding based on traffic category, if so desired. 207 To improve the situation, a separate OSPFv3 routing table can be 208 constructed that is dedicated to the IPv4-embedded IPv6 topology, and 209 that table is solely used for routing IPv4-embedded IPv6 packets in 210 the IPv6 network. The IPv4-embedded IPv6 topology includes all the 211 participating AFXLBR routers and a set of P routers providing 212 redundant connectivity with alternate routing paths. 214 There are two methods to build a separate OSPFv3 routing table for 215 IPv4-embedded IPv6 routes: 217 o The first one is to run a separate OSPFv3 instance for IPv4- 218 embedded IPv6 topology in the IPv6 network according to [RFC5838]. 220 o The second one is to stay with the existing OSPFv3 instance that 221 already operates in the IPv6 network, but maintain a separate 222 IPv4-embedded IPv6 topology, according to 223 [I-D.ietf-ospf-mt-ospfv3]. 225 With either method, there would be a dedicated IPv4-embedded IPv6 226 topology that is maintained on all participating AFXLBR and P 227 routers, along with a dedicated IPv4-embedded IPv6 routing table. 228 This routing table is then used solely in the IPv6 network for IPv4- 229 embedded IPv6 packets. 231 It would be an operator's preference as which method is to be used. 232 This document elaborates on how configuration is done for each method 233 and related routing issues that are common to both. 235 This document only focuses on unicast routing for IPv4-embedded IPv6 236 packets using OSPFv3. 238 2. Requirements Language 240 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 241 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 242 document are to be interpreted as described in [RFC2119]. 244 3. Provisioning 246 3.1. Deciding the IPv4-embedded IPv6 Topology 248 Before deploying configurations that use a separate OSPFv3 routing 249 table for IPv4-embedded IPv6 addresses and prefixes, a decision must 250 be made on the set of routers and their interfaces in the IPv6 251 network that should be part of the IPv4-embedded IPv6 topology. 253 For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that 254 connect to IPv4 client networks MUST be members of this topology, and 255 also at least some of their network core facing interfaces along with 256 some P routers in the IPv6 network. 258 The IPv4-embedded IPv6 topology is a sub-topology of the entire IPv6 259 network, and if all routers (including AFXLBRs and P-routers) and all 260 their interfaces are included, the two topologies converge. In 261 general, as more P routers and their interfaces are configured on 262 this sub-topology, it would increase the inter-connectivity and 263 potentially, there would be more routing paths across the network 264 from one IPv4 client network to the other, at the cost of more 265 routers needing to participate in IPv4-embedded IPv6 routing. In any 266 case, the IPv4-embedded IPv6 topology MUST be continuous with no 267 partitions. 269 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 271 In an IPv6 network, in order to maintain a separate IPv6 routing 272 table that contains routes for IPv4-embedded IPv6 destinations only, 273 OSPFv3 needs to use the mechanism defined either in [RFC5838] or in 274 [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as 275 described in the following sub-sections. 277 3.3. OSPFv3 Topology with a Separate Instance ID 279 It is assumed that the scenario described in this document is under a 280 single Autonomous System and, as such, an OSPFv3 instance ID (IID) is 281 allocated locally and used for OSPFv3 operation dedicated to unicast 282 IPv4-embedded IPv6 routing in an IPv6 network. This IID is 283 configured on OSPFv3 router interfaces that participate in the IPv4- 284 embedded IPv6 topology. 286 The range for a locally configured OSPFv3 IID is from 192 to 255, 287 inclusive, and this IID must be used to encode the "Instance ID" 288 field in the packet header of OSPFv3 packets associated with the 289 OSPFv3 instance. 291 In addition, the "AF" bit in the OSPFv3 Option field MUST be set. 293 During Hello packet processing, an adjacency may only be established 294 when the received Hello packet contains the same Instance ID as 295 configured on the receiving OSPFv3 interface. This insures that only 296 interfaces configured as part of the OSPFv3 unicast IPv4-embedded 297 IPv6 topology are used for IPv4-embedded IPv6 unicast routing. 299 For more details, the reader is referred to [RFC5838]. 301 3.4. OSPFv3 Topology with the Default Instance 303 Similar to that as described in the previous section, an OSPFv3 304 multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3 305 operation including unicast IPv4-embedded IPv6 routing in an IPv6 306 network. This MTID is configured on each OSPFv3 router interface 307 that participates in this routing topology. 309 The range for a locally configured OSPFv3 MT-ID is from 32 to 255, 310 inclusive, and this MT-ID must be used to encode the "MT-ID" field 311 included in extended Link State Advertisements (LSAs) for the IPv4- 312 embedded IPv6 unicast topology as documented in 313 [I-D.ietf-ospf-mt-ospfv3]. 315 In addition, the MT bit in the OSPFv3 Option field must be set. 317 For more details, the reader is referred to 318 [I-D.ietf-ospf-mt-ospfv3]. 320 4. IP Packets Translation 322 When transporting IPv4 packets across an IPv6 network with the 323 mechanism described above, an IPv4 packet is translated to an IPv6 324 packet at the ingress AFXLBR, and the IPv6 packet is translated back 325 to an IPv4 packet at the egress AFXLBR. The IP packet translation is 326 accomplished in stateless manner according to rules specified in 327 [RFC6145], with the address translation details explained in the next 328 sub-section. 330 4.1. Address Translation 332 Prior to address translation, an IPv6 prefix is allocated by the 333 Autonomous System and it is used to form IPv4-embedded IPv6 334 addresses. 336 The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 64: 337 ff9b::/96, or a network-specific prefix that is unique to the 338 Autonomous System; and for the latter case, the IPv6 prefix length 339 may be 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is 340 used during the address translation between an IPv4 address and an 341 IPv4-embedded IPv6 address, as described in [RFC6052]. 343 During translation from an IPv4 header to an IPv6 header at an 344 ingress AFXLBR, the source IPv4 address and destination IPv4 address 345 are translated into the corresponding IPv6 source address and 346 destination IPv6 address, respectively, and during translation from 347 an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 348 address and destination IPv6 address are translated into the 349 corresponding IPv4 source address and destination IPv4 address, 350 respectively. Note that the address translation is accomplished in a 351 stateless manner. 353 5. Advertising IPv4-embedded IPv6 Routes 355 In order to forward IPv4 packets to the proper destination across an 356 IPv6 network, IPv4 reachability needs to be disseminated throughout 357 the IPv6 network and this is performed by AFXLBRs that connect to 358 IPv4 client networks using OSPFv3. 360 With the scenario described in this document, i.e., a set of AFXLBRs 361 that inter-connect a bunch of IPv4 client networks with an IPv6 362 network, the IPv4 networks and IPv6 networks belong to separate and 363 independent Autonomous Systems, and as such, these AFXLBRs behave as 364 AS Boundary Routers (ASBRs). 366 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit 367 Network 369 IPv4 addresses and prefixes in an IPv4 client network are translated 370 into IPv4-embedded IPv6 addresses and prefixes, respectively, using 371 the IPv6 prefix allocated by the Autonomous System and the method 372 specified in [RFC6052]. These routes are then advertised by one or 373 more attached ASBRs into the IPv6 transit network using AS-External- 374 LSAs [RFC5340], i.e., with advertising scope comprising the entire 375 Autonomous System. 377 5.1.1. Routing Metrics 379 By default, the metric in an AS-External-LSA that carries an IPv4- 380 embedded IPv6 address or prefixes is a Type 1 external metric, which 381 is comparable to the link state metric and we assume that in most 382 cases, OSPFv2 is used in client IPv4 networks. This metric is added 383 to the metric of the intra-AS path to the ASBR during the OSPFv3 384 route calculation. Through ASBR configuration, the metric can be set 385 to a Type 2 external metric, which is considered much larger than the 386 metric for any intra-AS path. Refer to the OSPFv3 specification 387 [RFC5340] for more detail. In either case, an external metric may 388 take the same value as in an IPv4 network (using OSPFv2 or another 389 routing protocol), but may also be specified based on some routing 390 policy; the details of which are outside of the scope of this 391 document. 393 5.1.2. Forwarding Address 395 If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is 396 used to carry an IPv6 address, that must also be an IPv4-embedded 397 IPv6 address where the embedded IPv4 address is the destination 398 address in an IPv4 client network. However, since an AFXLBR sits on 399 the border of an IPv4 network and an IPv6 network, it is RECOMMENDED 400 that the "Forwarding Address" field is not used, so that the AFXLBR 401 can make the forwarding decision based on its own IPv4 routing table. 403 5.2. Advertising IPv4 Addresses into Client Networks 405 IPv4-embedded IPv6 routes injected into the IPv6 network from one 406 IPv4 client network MAY be advertised into another IPv4 client 407 network, after the associated destination addresses and prefixes are 408 translated back to IPv4 addresses and prefixes, respectively. This 409 operation is similar to normal OSPFv3 operation, wherein an AS- 410 External-LSA can be advertised in a non-backbone area by default. 412 An IPv4 client network can limit which advertisements it receives 413 through configuration. 415 For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT 416 be advertised into any IPv6 client networks that also connected to 417 the IPv6 transit network. 419 6. Aggregation on IPv4 Addresses and Prefixes 421 In order to reduce the amount of LSAs that are injected to the IPv6 422 network, an implementation should provide mechanisms to aggregate 423 IPv4 addresses and prefixes at AFXLBR prior to advertisement as IPv4- 424 embedded IPv6 addresses and prefixes. In general, the aggregation 425 practice should be based on routing policy, which is outside of the 426 scope of this document. 428 7. Forwarding 430 There are three cases in forwarding IP packets in the scenario 431 described in this document: 433 1. On an AFXLBR, if an IPv4 packet that is received on an interface 434 connecting to an IPv4 client network with a destination IPv4 435 address belonging to another IPv4 client network, the header of 436 the packet is translated to the corresponding IPv6 header as 437 described in Section 4, and the packet is then forwarded to the 438 destination AFXLBR that advertised the IPv4-embedded IPv6 address 439 into the IPv6 network. 441 2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 442 embedded destination IPv4 address is in its IPv4 routing table, 443 the header of the packet is translated to the corresponding IPv4 444 header as described in Section 4, and the packet is then 445 forwarded accordingly. 447 3. On any router that is within the IPv4-embedded IPv6 topology 448 subset of the IPv6 network, if an IPv4-embedded IPv6 packet is 449 received and a route is found in the IPv4-embedded IPv6 routing 450 table, the packet is forwarded to the IPv6 next-hop just like the 451 handling for a normal IPv6 packet, without any translation. 453 The classification of IPv4-embedded IPv6 packet is according to the 454 IPv6 prefix of the destination address, which is either the Well 455 Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in 456 [RFC6052]. 458 8. Backdoor Connections 460 In some deployments, IPv4 client networks are inter-connected across 461 the IPv6 network, but also directly connected to each other. The 462 "backdoor" connections between IPv4 client networks can certainly be 463 used to transport IPv4 packets between IPv4 client networks. In 464 general, backdoor connections are preferred over the IPv6 network, 465 since there requires no address family translation. 467 9. Prevention of Loops 469 If an LSA sent from an AFXLBR into a client network could then be 470 received by another AFXLBR, it would be possible for routing loops to 471 occur. To prevent loops, an AFXLBR MUST set the DN-bit [RFC4576] in 472 any LSA that it sends to a client network. The AFXLBR MUST also 473 ignore any LSA received from a client network that already has the 474 DN-bit sent. 476 10. MTU Issues 478 In the IPv6 network, there are no new MTU issues introduced by this 479 document. If a separate OSPFv3 instance (per [RFC5838]) is used for 480 IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is 481 the same as that of the default OSPFv3 instance. If a separate 482 OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is used for 483 IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is 484 the same as that of the default OSPFv3 topology. 486 However, the MTU in the IPv6 network may be different than that of 487 IPv4 client networks. Since an IPv6 router will never fragment a 488 packet, the packet size of any IPv4-embedded IPv6 packet entering the 489 IPv6 network must be equal to or less than the MTU of the IPv6 490 network. In order to achieve this requirement, it is recommended 491 that AFXLBRs perform IPv6 path discovery among themselves and the 492 resulting MTU, after taking into account of the difference between 493 the IPv4 header length and the IPv6 header length, must be 494 "propagated" into IPv4 client networks, e.g., included in the OSPFv2 495 Database Description packet. 497 The details of passing the proper MTU into IPv4 client networks are 498 beyond the scope of this document. 500 11. Security Considerations 502 This document does not introduce any security issues other than those 503 identified in [RFC5838] and [RFC6052]. 505 12. IANA Considerations 507 No new IANA assignments are required for this document. 509 13. Acknowledgements 511 Many thanks to Acee Lindem, Dan Wing, Joel Halpern and Mike Shand for 512 their comments. 514 14. References 516 14.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a 522 Link State Advertisement (LSA) Options Bit to Prevent 523 Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", 524 RFC 4576, June 2006. 526 14.2. Informative References 528 [I-D.ietf-ospf-mt-ospfv3] 529 Mirtorabi, S. and A. Roy, "Multi-topology routing in 530 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 531 progress), July 2007. 533 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 535 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 536 for IPv6", RFC 5340, July 2008. 538 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 539 Framework", RFC 5565, June 2009. 541 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 542 Aggarwal, "Support of Address Families in OSPFv3", 543 RFC 5838, April 2010. 545 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 546 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 547 October 2010. 549 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 550 Algorithm", RFC 6145, April 2011. 552 Authors' Addresses 554 Dean Cheng 555 Huawei Technologies 556 2330 Central Expressway 557 Santa Clara, California 95050 558 USA 560 Email: dean.cheng@huawei.com 562 Mohamed Boucadair 563 France Telecom 564 Rennes, 35000 565 France 567 Email: mohamed.boucadair@orange.com 569 Alvaro Retana 570 Cisco Systems 571 7025 Kit Creek Rd. 572 Research Triangle Park, North Carolina 27709 573 USA 575 Email: aretana@cisco.com