idnits 2.17.1 draft-ietf-ospf-ipv4-embedded-ipv6-routing-03.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 (July 3, 2012) is 4316 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: January 4, 2013 France Telecom 6 July 3, 2012 8 Routing for IPv4-embedded IPv6 Packets 9 draft-ietf-ospf-ipv4-embedded-ipv6-routing-03 11 Abstract 13 This document describes routing packets destined to IPv4-embedded 14 IPv6 addresses across IPv6 transit core using OSPFv3 with a separate 15 routing table. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. The Scenario . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . . 4 54 1.3. An Alternative Routing Solution with OSPFv3 . . . . . . . 4 55 1.4. OSPFv3 Routing with a Specific Topology . . . . . . . . . 5 56 2. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . . 6 58 2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing 59 Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 61 2.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7 62 3. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 64 4. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8 65 4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 66 Transit Network . . . . . . . . . . . . . . . . . . . . . 8 67 4.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 68 4.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9 69 4.2. Advertising IPv4 Addresses into Client Networks . . . . . 9 70 5. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 9 71 6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 11 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This document describes a routing scenario where IPv4 packets are 85 transported over IPv6 network. 87 In this document the following terminology is used: 89 o An IPv4-embedded IPv6 address denotes an IPv6 address which 90 contains an embedded 32-bit IPv4 address constructed according to 91 the rules defined in [RFC6052]. 93 o IPv4-embedded IPv6 packets are packets of which destination 94 addresses are IPv4-embedded IPv6 addresses. 96 o AFBR (Address Family Border Router, [RFC5565]) refers to an edge 97 router (PE), which supports both IPv4 and IPv6 address families, 98 but the backbone network the PE connects to only supports IPv4 or 99 IPv6 address family. 101 o AFXLBR (Address Family Translation Border Router) is defined in 102 this document. It refers to a border router that supports both 103 IPv4 and IPv6 address families, located on the boundary of IPv4- 104 only network and IPv6-only network, and is capable of performing 105 IP header translation between IPv4 and IPv6 according to 106 [RFC6145]. 108 1.1. The Scenario 110 Due to exhaustion of public IPv4 addresses, there has been continuing 111 effort within IETF on IPv6 transitional techniques. In the course of 112 transition, it is certain that networks based on IPv4 and IPv6 113 technologies respectively, will co-exist at least for some time. One 114 scenario of the co-existence is that IPv4-only networks inter- 115 connecting with IPv6-only networks, and in particular, when an IPv6- 116 only network serves as a transit network that inter-connects several 117 segregated IPv4-only networks. In this scenario, IPv4 packets are 118 transported over the IPv6 transit network between IPv4 networks. In 119 order to forward an IPv4 packet from a source IPv4 network to the 120 destination IPv4 network, IPv4 reachability information must be 121 exchanged between the IPv4 networks by some mechanisms. 123 In general, running an IPv6-only network would reduce OPEX and 124 optimize the operation comparing to IPv4-IPv6 dual-stack environment. 125 Some solutions have been proposed to allow delivery of IPv4 services 126 over an IPv6-only network. This document focuses on an engineering 127 techniques which aims to separate the routing table dedicated to 128 IPv4-embedded IPv6 destination from native IPv6 ones. 130 Maintaining a separate routing table for IPv4-embedded IPv4 routes 131 optimizes IPv4 packets forwarding process. It also prevents any 132 overload of the native IPv6 routing tables. A separate routing table 133 can be generated from a separate routing instance or a separate 134 routing topology. 136 1.2. Routing Solution per RFC5565 138 The aforementioned scenario is described in [RFC5565], i.e.- IPv4- 139 over-IPv6 scenario, where the network core is IPv6-only, and the 140 inter-connected IPv4 networks are called IPv4 client networks. The P 141 routers in the core only support IPv6 but the AFBRs (Address Family 142 Border Routers) support IPv4 on interface facing IPv4 client 143 networks, and IPv6 on interface facing the core. The routing 144 solution defined in [RFC5565] for this scenario is to run i-BGP among 145 AFBRs to exchange IPv4 routing information with each other, and the 146 IPv4 packets are forwarded from one IPv4 client network to the other 147 through a softwire using tunneling technology such as MPLS LSP, GRE, 148 L2TPv3, etc. 150 1.3. An Alternative Routing Solution with OSPFv3 152 In this document, we propose an alternative routing solution for the 153 scenario described in Section 1.1, where several segregated IPv4 154 networks, called IPv4 client networks, are interconnected by an IPv6 155 transit network. We name the border node on the boundary of an IPv4 156 client network and the IPv6 transit network as Address Family 157 Translation Border Router (AFXLBR), which supports both IPv4 and IPv6 158 address families, and is capable of translating an IPv4 packet to an 159 IPv6 packet, and vice versa, according to [RFC6145]. 161 Since the scenario occurs most in a single ISP operating environment, 162 an IPv6 prefix can be locally allocated and used to construct IPv4- 163 embedded IPv6 addresses according to [RFC6052] by each AFXLBR. The 164 embedded IPv4 address or prefix belongs to an IPv4 client network 165 that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded 166 IPv6 addresses and prefixes into the IPv6 transit network using 167 OSPFv3, and it also installs IPv4-embedded IPv6 routes advertised by 168 other AFXLBRs. 170 When an AFXLBR receives an IPv4 packet from a locally connected IPv4 171 client network and destined to a remote IPv4 client network, it 172 translates the IPv4 header to the relevant IPv6 header according to 173 [RFC6145], and in that process, source and destination IPv4 address 174 are translated into IPv4-embedded IPv6 addresses, respectively, 175 according to [RFC6052]. The resulting IPv6 packet is then forwarded 176 to the AFXLBR that connects to the destination IPv4 client network. 177 The remote AFXLBR derives the IPv4 source and destination addresses 178 from the IPv4-embedded IPv6 addresses, respectively, according to 179 [RFC6052], and translates the header of the received IPv6 packet to 180 the relevant IPv4 header according to [RFC6145]. The resulting IPv4 181 packet is then forwarded according to the IPv4 routing table 182 maintained on the AFXLBR. 184 There are use cases where the proposed routing solution is useful. 185 One case is that some border nodes do not participate in i-BGP for 186 routes exchange (one example is documented in 187 [I-D.boucadair-softwire-dslite-v6only]), or i-BGP is not used at all. 188 Another case is that tunnel mechanism is not used in the IPv6 transit 189 network, or native IPv6 forwarding is preferred. Note that with this 190 routing solution, the IPv4 and IPv6 header translation that occurs at 191 an AFXLBR in both diretions is stateless. 193 1.4. OSPFv3 Routing with a Specific Topology 195 In general, IPv4-embedded IPv6 packets can be forwarded just like 196 native IPv6 packets with OSPFv3 running in the IPv6 transit network. 197 However, this would require IPv4-embedded IPv6 routes to be flooded 198 throughout the entire transit network and stored on every router. 199 This is not desirable in the scaling perspective. Moreover, since 200 all IPv6 routes are stored in the same routing table, it is 201 inconvenient to manage the resource required for routing and 202 forwarding based on traffic category, if so desired. 204 To improve the situation, a separate OSPFv3 routing table can be 205 constructed that is dedicated to IPv4-embedded IPv6 topology, and 206 that table is solely used for routing IPv4-embedded IPv6 packets in 207 the IPv6 transit network. The IPv4-embedded IPv6 topology include 208 all the participating AFXLBR routers and a set of P routers for 209 connectivity and routing paths. 211 There are two methods to build a separate OSPFv3 routing table for 212 IPv4-embedded IPv6 routes as follows: 214 o The first one is to run a separate OSPFv3 instance for IPv4- 215 embedded IPv6 topology in the IPv6 transit network according to 216 [RFC5838]. 218 o The second one is to stay with the existing OSPFv3 instance that 219 already operates in the transit network, but maintain a separate 220 IPv4-embedded IPv6 topology, according to 221 [I-D.ietf-ospf-mt-ospfv3]. 223 With either method, there would be a dedicated IPv4-embedded IPv6 224 topology that is maintained on all participating AFXLBR and P 225 routers, along with a dedicated IPv4-embedded IPv6 routing table. 227 The routing table is then used solely in the IPv6 transit network for 228 IPv4-embedded IPv6 packets. 230 It would be an operator's preference as which method is to be used. 231 This document elaborates on how configuration is done for each method 232 and related routing issues that is common to both. 234 This document only focuses on unicast routing for IPv4-embedded IPv6 235 packets using OSPFv3. 237 2. Provisioning 239 2.1. Deciding the IPv4-embedded IPv6 Topology 241 Before making appropriate configuration in order to generate a 242 separate OSPFv3 routing table for IPv4-embedded IPv6 addresses and 243 prefixes, decision must be made on the set of routers and their 244 interfaces in the IPv6 transit network that should be on the IPv4- 245 embedded IPv6 topology. 247 For the purpose of this topology, all AFXLBRs that connect to IPv4 248 client networks must be members of this topology, and also at least 249 some of their network core facing interfaces along with some P 250 routers in the IPv6 transit network would be on this topology. 252 The IPv4-embedded IPv6 topology is a sub-topology of the entire IPv6 253 transit network, and if all routers (including AFXLBRs and P-routers) 254 and all their interfaces are included, the two topologies converge. 255 In general, as more P routers and their interfaces are configured on 256 this sub-topology, it would increase the inter-connectivity and 257 potentially, there would be more routing paths across the transit 258 network from one IPv4 client network to the other, at the cost that 259 more routers need to participate the IPv4-embedded IPv6 routing. In 260 any case, the IPv4-embedded IPv6 topology must be continuous with no 261 partitions. 263 2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 265 In an IPv6 transit network, in order to maintain a separate IPv6 266 routing table that contains routes for IPv4-embedded IPv6 267 destinations only, OSPFv3 needs to use the mechanism defined either 268 in [RFC5838] or in [I-D.ietf-ospf-mt-ospfv3] with required 269 configuration, as described in the following sub-sections. 271 2.3. OSPFv3 Topology with a Separate Instance ID 273 It is assumed that the scenario as described in this document is 274 under a single ISP and as such, an OSPFv3 instance ID (IID) is 275 allocated locally and used for an OSPFv3 operation dedicated to 276 unicast IPv4-embedded IPv6 routing in an IPv6 transit network. This 277 IID is configured on each OSPFv3 interface of routers that 278 participates in this routing instance. 280 The range for a locally configured OSPFv3 IID is from 128 to 255, 281 inclusively, and this number must be used to encode the "Instance ID" 282 field in the OSPFv3 packet header on every router that executes this 283 instance in the IPv6 transit network. 285 In addition, the "AF" bit in the OSPFv3 Option field must be set. 287 During the Hello packets processing, adjacency may only be 288 established when received Hello packets contain the same Instance ID 289 as configured on the receiving interface for OSPFv3 instance 290 dedicated to the IPv4-embedded IPv6 routing. 292 For more details, the reader is referred to [RFC5838]. 294 2.4. OSPFv3 Topology with the Default Instance 296 Similar to that as described in the previous section, an OSPFv3 297 multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3 298 operation including unicast IPv4-embedded IPv6 routing in an IPv6 299 transit network. This MTID is configured on each OSPFv3 interface of 300 routers that participates in this routing topology. 302 The range for a locally configured OSPFv3 MT-ID is from 32 to 255, 303 inclusively, and this number must be used to encode the "MT-ID" field 304 that is included in some of the extended LSAs as documented in 305 [I-D.ietf-ospf-mt-ospfv3]. 307 In addition, the MT bit in the OSPFv3 Option field must be set. 309 For more details, the reader is referred to 310 [I-D.ietf-ospf-mt-ospfv3]. 312 3. IP Packets Translation 314 When transporting IPv4 packets across an IPv6 transit network with 315 the mechanism described above, an IPv4 packet is translated to an 316 IPv6 packet at ingress AFXLBR, and the IPv6 packet is translated back 317 to the original IPv4 packet at egress AFXLBR. The IP packet 318 translation is accomplished in stateless manner according to rules 319 specified in [RFC6145], with the address translation detail explained 320 in the next sub-section. 322 3.1. Address Translation 324 Prior to the operation, an IPv6 prefix is allocated by the ISP and it 325 is used to form IPv4-embedded IPv6 addresses. 327 The IPv6 prefix can either be a well-known IPv6 prefix (WKP) 64: 328 ff9b::/96, or a network-specific prefix that is unique to the ISP; 329 and for the later case, the IPv6 prefix length may be 32, 40, 48, 56 330 or 64. In either case, this IPv6 prefix is used during the address 331 translation between an IPv4 address and an IPv4-embedded IPv6 332 address, which is performed according to [RFC6052]. 334 During translation from an IPv4 header to an IPv6 header at an 335 ingress AFXLBR, the source IPv4 address and destination IPv4 address 336 are translated into the corresponding IPv6 source address and 337 destination IPv6 address, respectively, and during translation from 338 an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 339 address and destination IPv6 address are translated into the 340 corresponding IPv4 source address and destination IPv4 address, 341 respectively. Note that the address translation is accomplished in a 342 stateless manner. 344 4. Advertising IPv4-embedded IPv6 Routes 346 In order to forward IPv4 packets to the proper destination across 347 IPv6 transit network, IPv4 reachability needs to be disseminated 348 throughout the IPv6 transit network and this work is performed by 349 AFXLBRs that connect to IPv4 client networks using OSPFv3. 351 With the scenario described in this document, i.e. - a set of AFXLBRs 352 that inter-connect a bunch of IPv4 client networks with an IPv6 353 transit network, we view that IPv4 networks and IPv6 networks belong 354 to separate Autonomous Systems, and as such, these AFXLBRs are OSPFv3 355 ASBRs. 357 4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 Transit Network 359 IPv4 addresses and prefixes in an IPv4 client network are translated 360 into IPv4-embedded IPv6 addresses and prefixes, respectively, using 361 the same IPv6 prefix allocated by the ISP and the method specified in 362 [RFC6052]. These routes are then advertised by one or more attached 363 ASBRs into the IPv6 transit network using AS External LSA [RFC5340], 364 i.e. - with the advertising scope throughout the entire Autonomous 365 System. 367 4.1.1. Routing Metrics 369 By default, the metric in an AS External LSA that carries an IPv4- 370 embedded IPv6 address or prefixes is a Type 1 external metric, which 371 is then to be added to the metric of an intra-AS path during OSPFv3 372 routes calculation. By configuration on an ASBR, the metric can be 373 set to a Type 2 external metric, which is considered much larger than 374 that on any intra-AS path. The detail is referred to OSPFv3 375 specification [RFC5340]. In either case, an external metric may take 376 the same value as in an IPv4 network (running OSPFv2 or others), but 377 may also be specified based on some routing policy; the detail is 378 outside of the scope of this document. 380 4.1.2. Forwarding Address 382 If the "Forwarding Address" field of an OSPFv3 AS External LSA is 383 used to carry an IPv6 address, that must also be an IPv4-embedded 384 IPv6 address where the embedded IPv4 address is the destination 385 address in an IPv4 client network. However, since an AFXLBR sits on 386 the border of an IPv4 network and an IPv6 network, it is recommended 387 that the "Forwarding Address" field not to be used by setting the F 388 bit in the associated OSPFv3 AS-external-LSA to zero, so that the 389 AFXLBR can make the forwarding decision based on its own IPv4 routing 390 table. 392 4.2. Advertising IPv4 Addresses into Client Networks 394 IPv4-embedded IPv6 routes injected into the IPv6 transit network from 395 one IPv4 client network may be advertised into another IPv4 client 396 network, after the associated destination addresses and prefixes are 397 translated back to IPv4 addresses and prefixes, respectively. This 398 operation is similar to the regular OSPFv3 operation, wherein an AS 399 External LSA can be advertised in a non-backbone area by default. 401 An IPv4 client network that does not want to receive such 402 advertisement can be configured as a stub area or with other routing 403 policy. 405 For the purpose of this document, IPv4-embedded IPv6 routes must not 406 be advertised into any IPv6 client networks that also connected to 407 the IPv6 transit network. 409 5. Aggregation on IPv4 Addresses and Prefixes 411 In order to reduce the amount of AS External LSAs that are injected 412 to the IPv6 transit network, effort must be made to aggregate IPv4 413 addresses and prefixes at each AFXLBR before advertising. 415 6. Forwarding 417 There are three cases in forwarding IP packets in the scenario as 418 described in this document, as follows: 420 1. On an AFXLBR, if an IPv4 packet that is received on an interface 421 connecting to an IPv4 client network with the destination IPv4 422 address belong to another IPv4 client network, the header of the 423 packet is translated to a corresponding IPv6 header as described 424 in Section 3, and the packet is then forwarded to the destination 425 AFXLBR that advertises the IPv4-embedded IPv6 address through the 426 IPv6 transit network. 428 2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 429 embedded destination IPv4 address is in its IPv4 routing table, 430 the header of the packet is translated to a corresponding IPv4 431 header as described in Section 3, and the packet is then 432 forwarded accordingly. 434 3. On any router that is within the IPv4-embedded IPv6 topology 435 located in the IPv6 transit network, if an IPv4-embedded IPv6 436 packet is received and a route is found in the IPv4-embedded IPv6 437 routing table, the packet is forwarded accordingly. 439 The classification of IPv4-embedded IPv6 packet is according to the 440 IPv6 prefix of the destination address, which is either the Well 441 Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in 442 [RFC6052]. 444 7. MTU Issues 446 In the IPv6 transit network, there is no new MTU issue introduced by 447 this document. If a separate OSPFv3 instance (per [RFC5838]) is used 448 for IPv4-embedded IPv6 routing, the MTU handling in the transit 449 network is the same as that of the default OSPFv3 instance. If a 450 separate OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is 451 used for IPv4-embedded IPv6 routing, the MTU handling in the transit 452 network is the same as that of the default OSPFv3 topology. 454 However, the MTU in the IPv6 transit network may be different than 455 that of IPv4 client networks. Since an IPv6 router will never 456 fragment a packet, the packet size of any IPv4-embedded IPv6 packet 457 entering the IPv6 transit network must be equal to or less than the 458 MTU of the IPv6 transit network. In order to achieve this 459 requirement, it is recommended that AFXLBRs to perform IPv6 path 460 discovery among themselves and the resulting MTU, after taking into 461 account of the difference between IPv4 header length and IPv6 header 462 length, must be "propagated" into IPv4 client networks, e.g.- 463 included in the OSPFv2 Database Description packet. 465 The detail of passing the proper MTU into IPv4 client networks is 466 beyond the scope of this document. 468 8. Backdoor Connections 470 In some deployments, IPv4 client networks are inter-connected across 471 the IPv6 transit network, but also directly connected to each other. 472 The "backdoor" connections between IPv4 client networks can certainly 473 be used to transport IPv4 packets between IPv4 client networks. In 474 general, backdoor connections are prefered over the transportation 475 over the IPv6 transit network, since there requires no address family 476 translation. 478 9. Security Considerations 480 This document does not introduce any security issue than what has 481 been identified in [RFC5838] and [RFC6052]. 483 10. IANA Considerations 485 No new IANA assignments are required for this document. 487 11. Acknowledgements 489 Many thanks to Acee Lindem, Dan Wing and Joel Halpern for their 490 comments. 492 12. References 494 12.1. Normative References 496 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 497 for IPv6", RFC 5340, July 2008. 499 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 500 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 501 October 2010. 503 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 504 Algorithm", RFC 6145, April 2011. 506 12.2. Informative References 508 [I-D.boucadair-softwire-dslite-v6only] 509 Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, 510 M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- 511 Stack Lite in IPv6 Network", 512 draft-boucadair-softwire-dslite-v6only-01 (work in 513 progress), April 2011. 515 [I-D.ietf-ospf-mt-ospfv3] 516 Mirtorabi, S. and A. Roy, "Multi-topology routing in 517 OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in 518 progress), July 2007. 520 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 521 Framework", RFC 5565, June 2009. 523 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 524 Aggarwal, "Support of Address Families in OSPFv3", 525 RFC 5838, April 2010. 527 Authors' Addresses 529 Dean Cheng 530 Huawei Technologies 531 2330 Central Expressway 532 Santa Clara, California 95050 533 USA 535 Email: dean.cheng@huawei.com 537 Mohamed Boucadair 538 France Telecom 539 Rennes, 35000 540 France 542 Email: mohamed.boucadair@orange.com