idnits 2.17.1 draft-cheng-ospf-ipv4-embedded-ipv6-routing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 5, 2011) is 4827 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.boucadair-softwire-dslite-v6only' is defined on line 526, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group D. Cheng 2 Internet Draft Huawei Technologies 3 Category: Informational M. Boucadair 4 Expires: August 5, 2011 France Telecom 6 February 5, 2011 8 Routing for IPv4-embedded IPv6 Packets 10 draft-cheng-ospf-ipv4-embedded-ipv6-routing-03 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute 19 working documents as Internet-Drafts. The list of current Internet- 20 Drafts is at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on August 5, 2011. 29 Copyright Notice 31 Copyright (c) 2009 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://truestee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with 39 respect to this document. 41 Abstract 43 This document describes routing packets destined to IPv4-embedded 44 IPv6 addresses across IPv6 transit core using OSPFv3 with a separate 45 routing table. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119 [RFC2119]. 53 Table of Contents 55 1. Introduction...................................................3 56 1.1. The scenario..............................................3 57 1.2. Routing Solution per RFC5565..............................4 58 1.3. An Alternative Routing Solution with OSPFv3...............4 59 1.4. OSPFv3 Routing with a Specific Topology...................5 60 2. Provisioning...................................................6 61 2.1. Deciding the IPv4-embedded IPv6 Topology..................6 62 2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table..6 63 2.3. OSPFv3 Topology with a Separate Instance ID...............7 64 2.4. OSPFv3 Topology with the Default Instance.................7 65 3. IP Packets Translation.........................................7 66 3.1. Address Translation.......................................8 67 4. Advertising IPv4-embedded IPv6 Routes..........................8 68 4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 Transit 69 Network........................................................8 70 4.1.1. Routing Metrics......................................9 71 4.1.2. Forwarding Address...................................9 72 4.2. Advertising IPv4 Addresses into Client Networks...........9 73 5. Aggregation on IPv4 Addresses and Prefixes.....................9 74 6. Forwarding....................................................10 75 7. MTU Issue.....................................................10 76 8. Backdoor Connections..........................................11 77 9. Security......................................................11 78 10. IANA Considerations..........................................11 79 11. Acknowledgements.............................................11 80 12. References...................................................11 81 12.1. Normative References....................................11 82 12.2. Informative References..................................12 83 13. Authors' Addresses...........................................12 85 1. Introduction 87 This document describes a routing scenario where IPv4 packets are 88 transported over IPv6 network. 90 In this document the following terminology is used: 92 - An IPv4-embedded IPv6 address denotes an IPv6 address which 93 contains an embedded 32-bit IPv4 address constructed according 94 to the rules defined in [RFC6052]. 96 - IPv4-embedded IPv6 packets are packets of which destination 97 addresses are IPv4-embedded IPv6 addresses. 99 - AFBR (Address Family Border Router, [RFC5565]) refers to an edge 100 router, which supports both IPv4 and IPv6 address families, of a 101 backbone that supports only IPv4 or IPv6 address family. 103 - AFXLBR (Address Family Translation Border Router) is defined in 104 this document. It refers to a border router that supports both 105 IPv4 and IPv6 address families, located on the boundary of IPv4- 106 only network and IPv6-only network, and is capable of performing 107 IP header translation between IPv4 and IPv6 according to 108 [I-D.draft-ietf-behave-v6v4-xlate]. 110 1.1. The scenario 112 Due to exhaustion of public IPv4 addresses, there has been 113 continuing effort within IETF on IPv6 transitional techniques. In 114 the course of transition, it is certain that networks based on IPv4 115 and IPv6 transfer capabilities, respectively, will co-exist at least 116 for some time. One scenario of the co-existence is that IPv4-only 117 networks inter-connecting with IPv6-only networks, and in 118 particular, when an IPv6-only network serves as a transit network 119 that inter-connects several segregated IPv4-only networks. In this 120 scenario, IPv4 packets are transported over the IPv6 transit network 121 between IPv4 networks. In order to forward an IPv4 packet from a 122 source IPv4 network to the destination IPv4 network, IPv4 123 reachability information must be exchanged among involved networks 124 by dedicated means. 126 Unlike dual-stack networks, operating an IPv6-only network would 127 allow optimize OPEX and maintenance operations in particular. Some 128 solutions have been proposed to allow delivery of IPv4 services over 129 an IPv6-only network. This document focuses on an engineering 130 techniques which aims to separate the routing instance dedicated to 131 IPv4-embedded IPv6 destination from native IPv6 ones. 133 The purpose of running separate instances or topologies for IPv4- 134 embedded IPv6 traffic is to distinguish from the native IPv6 routing 135 topology, and the topology that is used for routing IPv4-embedded 136 IPv6 datagram only. Separate instances/topologies are also meant to 137 prevent any overload of the native IPv6 routing tables by IPv4- 138 embedded IPv6 routes. 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 interface facing IPv4 client 147 networks, and IPv6 on interface facing the core. The routing 148 solution defined in [RFC5565] for this scenario is to run i-BGP 149 among AFBRs to exchange IPv4 routing information with each other, 150 and the IPv4 packets are forwarded from one IPv4 client network to 151 the other through a softwire using tunneling technology such as MPLS 152 LSP, GRE, 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 transit network, and in particular, we name the border node on the 160 boundary of an IPv4 client network and the IPv6 transit network as 161 Address Family Translation Border Router, or AFXLBR, which supports 162 both IPv4 and IPv6 address families, and is capable of translating 163 an IPv4 packet to an IPv6 packet, and vice versa, according to 164 [I-D.draft-ietf-behave-v6v4-xlate]. 166 Since the scenario occurs most in a single ISP operating 167 environment, an IPv6 prefix can be locally allocated and used to 168 construct IPv4-embedded IPv6 addresses according to [RFC6052] by 169 each AFXLBR, where the embedded IPv4 addresses are associated with 170 an IPv4 client network that is connected to the AFXLBR, and each 171 IPv4 address is an individual IPv4 address or prefix. An AFXLBR 172 injects IPv4-embedded IPv6 addresses/prefixes into the IPv6 transit 173 network using OSPFv3 and also installs those advertised by other 174 AFXLBRs. When an IPv4 packet is sent from one IPv4 client network to 175 the other, it is first encapsulated with an IPv6 header, where the 176 source and destination IPv6 address are constructed, in a stateless 177 manner, as IPv4-embedded IPv6 address, respectively, and then 178 forwarded to the destination AFXLBR that is the advertising router 179 of the destination IPv4-embedded IPv6 address. The destination 180 AFXLBR replaces the IPv6 header by the corresponding IPv4 header, 181 where the source and destination IPv4 addresses are derived from the 182 IPv4-embedded IPv6 source and destination addresses, respectively, 183 and then forwards the IPv4 packet using its IPv4 routing table in 184 the attached IPv4 client network. 186 There are use cases where the proposed routing solution is useful. 187 One case is that some border nodes do not participate in i-BGP for 188 routes exchange (one example is documented in [I-D.boucadair- 189 softwire-dslite-v6only]), or i-BGP is not used at all. Another case 190 is that tunnel mechanism is not used in the IPv6 transit network, or 191 native IPv6 forwarding is preferred. Note also that with this 192 routing solution, the IPv4-IPv6 inter-connection and associated 193 header translation that occurs at an AFXLBR is stateless. 195 1.4. OSPFv3 Routing with a Specific Topology 197 Routing IPv4-embedded IPv6 packets in the IPv6 transit network using 198 OSPFv3, in general, may be performed by the OSPFv3 operation that is 199 already running in the IPv6 network. One concern however, is that 200 IPv4-embedded IPv6 routes would flood throughout the entire transit 201 network and stored on every router, which may not be desirable. 202 Also, since all IPv6 routes are stored in the same routing table, it 203 might be more difficult to manage the resource required for routing 204 and forwarding based on traffic category, if so desired. To solve 205 this problem and to ease the separation between native IPv6 and 206 IPv4-inferred routing policies, a separate OSPFv3 routing table can 207 be constructed that is dedicated to IPv4-embedded IPv6 topology, and 208 that table is solely used for routing IPv4-embedded IPv6 packets 209 (i.e., IPv4 part of the Internet) in the transit network. Further, 210 only a set of routers in the transit network are required to be 211 involved in such routing scheme, including AFXLBRs that connect to 212 IPv4 client networks along with a set of P routers in the core for 213 routing path. 215 There are two methods to build a separate OSPFv3 routing table for 216 IPv4-embedded IPv6 routing. 218 - The first one is to run a separate OSPFv3 instance for IPv4- 219 embedded IPv6 topology in the IPv6 transit network according to 220 [RFC5838], 222 - The second one is to stay with the existing OSPFv3 instance that 223 already operates in the transit network, but maintain a separate 224 IPv4-embedded topology, according to [I-D.ietf-ospf-mt-ospfv3]. 226 With both methods, there would be a dedicated IPv4-embedded IPv6 227 topology that is maintained by OSPFv3 speakers and thus a dedicated 228 IPv4-embedded IPv6 routing table, which is then used for routing 229 IPv4-embedded IPv6 packets (i.e., packets destined to an IPv4 230 destination). It would be operators' preference as which method is 231 going to be used. This document elaborates on how configuration is 232 done for each method and related routing issues that is common to 233 both. 235 This document only focuses on unicast routing for IPv4-embedded IPv6 236 packets using OSPFv3. 238 2. Provisioning 240 2.1. Deciding the IPv4-embedded IPv6 Topology 242 Before making appropriate configuration in order to generate a 243 separate OSPFv3 routing table for IPv4-embedded IPv6 244 addresses/prefixes, decision must be made on the set of routers and 245 their interfaces in the IPv6 transit network that should be on the 246 IPv4-embedded IPv6 topology. 248 For the purpose of this topology, all AFXLBRs that connect to IPv4 249 client networks should be members of this topology, and also at 250 least some of their network core facing interfaces, which depends on 251 which P routers in the IPv6 transit network would be on this 252 topology. 254 The IPv4-embedded IPv6 topology is a sub-topology of the entire IPv6 255 transit network, and if all routers (including AFXLBRs and P- 256 routers) and their interfaces are included, the two topologies 257 converge. In general, as more P routers and their interfaces are 258 configured on this sub-topology, it would increase the inter- 259 connectivity and potentially, there would be more routing paths 260 cross the transit network from one IPv4 client network to the other, 261 at the cost that more routers need to participate the IPv4-embedded 262 IPv6 routing. In any case, the IPv4-embedded IPv6 topology must be 263 continuous with no partitions. 265 2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 267 In an IPv6 transit network, in order to maintain a separate IPv6 268 routing table that contains routes for IPv4-embedded IPv6 269 destinations only, OSPFv3 needs to use the mechanism defined either 270 in [RFC5838] or [I-D.ietf-ospf-mt-ospfv3] with required 271 configuration tasks, as described in the following sub-sections. 273 2.3. OSPFv3 Topology with a Separate Instance ID 275 It is assumed that the scenario as described in this document is 276 under a single ISP and as such, an OSPFv3 instance ID (IID) is 277 allocated locally and used for an OSPFv3 operation dedicated to 278 unicast IPv4-embedded IPv6 routing in an IPv6 transit network. This 279 IID is configured on each OSPFv3 interface of routers that 280 participates in this routing instance. 282 The range for a locally configured OSPFv3 IID is from 128 to 255, 283 inclusively, and this number must be used to encode the "Instance 284 ID" field in the OSPFv3 packet header on every router that executes 285 this instance in the IPv6 transit network. 287 In addition, the "AF" bit in the OSPFv3 Option field must be set. 289 During the Hello packets processing, adjacency may only be 290 established when received Hello packets contain the same Instance 291 ID as configured on the receiving interface for OSPFv3 instance 292 dedicated to the IPv4-embedded IPv6 routing. 294 For more details, the reader is referred to [RFC5838]. 296 2.4. OSPFv3 Topology with the Default Instance 298 Similar to that as described in the previous section, an OSPFv3 299 multi-topology ID (MT-ID) is locally allocated and used for an 300 OSPFv3 operation including unicast IPv4-embedded IPv6 routing in an 301 IPv6 transit network. This MTID is configured on each OSPFv3 302 interface of routers that participates in this routing topology. 304 The range for a locally configured OSPFv3 MT-ID is from 32 to 255, 305 inclusively, and this number must be used to encode the "MT-ID" 306 field that is included in some of the extended LSAs as documented in 307 [I-D.ietf-ospf-mt-ospfv3]. 309 In addition, the MT bit in the OSPFv3 Option field must be set. 311 For more details, the reader is referred to [I-D.ietf-ospf-mt- 312 ospfv3]. 314 3. IP Packets Translation 316 When transporting IPv4 packets across an IPv6 transit network with 317 the mechanism described above, an IPv4 packet is translated to an 318 IPv6 packet at ingress AFXLBR, and the IPv6 packet is translated 319 back to the original IPv4 packet at egress AFXLBR. The IP packet 320 translation is accomplished in stateless manner according to rules 321 specified in [I-D.draft-ietf-behave-v6v4-xlate], with the address 322 translation detail explained in the next sub-section. 324 3.1. Address Translation 326 Prior to the operation, an IPv6 prefix is allocated by the ISP and 327 it is used to form an IPv4-embedded IPv6 address. 329 The IPv6 prefix can either be a well-known IPv6 prefix (WKP) 330 64:FF9B::/96, or a network-specific prefix that is unique to the 331 ISP, and for the later case, the IPv6 prefix length may be 32, 40, 332 48, 56 or 64. In either case, this IPv6 prefix is used during the 333 address translation between an IPv4 address and an IPv4-embedded 334 IPv6 address, which is performed according to [RFC6052]. 336 During translation from an IPv4 header to an IPv6 header at an 337 ingress AFXLBR, the source IPv4 address and destination IPv4 address 338 are translated into the corresponding IPv6 source address and 339 destination IPv6 address, respectively, and during translation from 340 an IPv6 header to an IPv4 header at an egress AFXLBR, the source 341 IPv6 address and destination IPv6 address are translated into the 342 corresponding IPv4 source address and destination IPv4 address, 343 respectively. Note that the address translation is accomplished in a 344 stateless manner. 346 4. Advertising IPv4-embedded IPv6 Routes 348 In order to forward IPv4 packets to the proper destination across 349 IPv6 transit network, IPv4 reachability needs to be disseminated 350 throughout the IPv6 transit network and this work is performed by 351 AFXLBRs that connect to IPv4 client networks using OSPFv3. 353 With the scenario described in this document, i.e. - a set of 354 AFXLBRs that inter-connect a bunch of IPv4 client networks with an 355 IPv6 transit network, we view that IPv4 networks and IPv6 networks 356 belong to separate Autonomous Systems, and as such, these AFXLBRs 357 are OSPFv3 ASBRs. 359 4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 Transit Network 361 IPv4 addresses and prefixes in an IPv4 client network are translated 362 into IPv4-embedded IPv6 addresses and prefixes, respectively, using 363 the same IPv6 prefix allocated by the ISP and the method specified 364 in [RFC6052], and then advertised by one or more attached ASBRs into 365 the IPv6 transit network using AS External LSA ([RFC5340]), i.e. - 366 with the advertising scope throughout the entire Autonomous System. 368 4.1.1. Routing Metrics 370 By default, the metric in an AS External LSA that carries an IPv4- 371 embedded IPv6 address or prefixes is a Type 1 external metric, which 372 is then to be added to the metric of an intra-AS path during OSPFv3 373 routes calculation. By configuration on an ASBR, the metric can be 374 set to a Type 2 external metric, which is considered much larger 375 than that on any intra-AS path. The detail is referred to OSPFv3 376 specification [RFC5340]. In either case, an external metric may be 377 exact the same unit as in an IPv4 network (running OSPFv2 or 378 others), but may also be specified by a routing policy, the detail 379 is outside of the scope of this document. 381 4.1.2. Forwarding Address 383 If the "Forwarding Address" field of an OSPFv3 AS External LSA is 384 used to carry an IPv6 address, that must also be an IPv4-embedded 385 IPv6 address where the embedded IPv4 address is the actual address 386 in an IPv4 client network to which, data traffic is forwarded to. 387 However, since an AFXLBR sits on the border of an IPv4 network and 388 an IPv6 network, it is recommended that the "Forwarding Address" 389 field not to be used by setting the F bit in the associated 390 OSPFv3 AS-external-LSA to zero, so that the AFXLBR can make the 391 forwarding decision based on its own IPv4 routing table. 393 4.2. Advertising IPv4 Addresses into Client Networks 395 IPv4-embedded IPv6 routes injected into the IPv6 transit network 396 from one IPv4 client network may be advertised into another IPv4 397 client network, after the associated destination addresses/prefixes 398 are translated back to IPv4 addresses/prefixes format. This 399 operation is similar to the regular OSPFv3 operation, wherein an AS 400 External LSA can be advertised in a non-backbone area by default. 402 An IPv4 client network that does not want to receive such 403 advertisement can be configured as a stub area or with other routing 404 policy. 406 For the purpose of this document, IPv4-embedded IPv6 routes must not 407 advertised into any IPv6 client networks that also connected to the 408 IPv6 transit network. 410 5. Aggregation on IPv4 Addresses and Prefixes 412 In order to reduce the amount of AS External LSAs that are injected 413 to the IPv6 transit network, effort must be made to aggregate IPv4 414 addresses and prefixes at each AFXLBR before advertising. 416 6. Forwarding 418 There are three cases in forwarding IP packets in the scenario as 419 described in this document, as follows: 421 1) On an AFXLBR, if an IPv4 packet that is received on an interface 422 connecting to an IPv4 client network with the destination IPv4 423 address belong to another IPv4 client network, the header of the 424 packet is translated to a corresponding IPv6 header as described 425 in Section 3, and the packet is then forwarded to the destination 426 AFXLBR that advertises the IPv4-embedded IPv6 address through the 427 IPv6 transit network. 429 2) On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 430 embedded destination IPv4 address is in its IPv4 routing table, 431 the header of the packet is translated to a corresponding IPv4 432 header as described in Section 3, and the packet is then forwarded 433 accordingly. 435 3) On any router that is within the IPv4-embedded IPv6 topology 436 located in the IPv6 transit network, if an IPv4-embedded IPv6 437 packet is received and a route is found in the IPv4-embedded IPv6 438 routing table, the packet is forwarded accordingly. 440 The classification of IPv4-embedded IPv6 packet is according to the 441 IPv6 prefix of the destination address, which is either the Well 442 Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in 443 [RFC6052]. 445 7. MTU Issue 447 In the IPv6 transit network, there is no new MTU issue introduced by 448 this document. If a separate OSPFv3 instance (per [RFC5838]) is used 449 for IPv4-embedded IPv6 routing, the MTU handling in the transit 450 network is the same as that of the default OSPFv3 instance. If a 451 separate OSPFv3 topology (per [I-D.ietf-ospf-mt-ospfv3]) is used for 452 IPv4-embedded IPv6 routing, the MTU handling in the transit network 453 is the same as that of the default OSPFv3 topology. 455 However, the MTU in the IPv6 transit network may be different than 456 that of IPv4 client networks. Since an IPv6 router will never 457 fragment a packet, the packet size of any IPv4-embedded IPv6 packet 458 entering the IPv6 transit network must be equal to or smaller than 459 the MTU of the IPv6 transit network. In order to achieve this 460 requirement, it is recommended that AFXLBRs to perform IPv6 path 461 discovery among themselves and the resulting MTU, after taking into 462 account of the difference between IPv4 header length and IPv6 header 463 length, must be "propagated" into IPv4 client networks, e.g.- 464 included in the OSPFv3 Database Description packet. 466 The detail of passing the proper MTU into IPv4 client networks is 467 beyond the scope of this document. 469 8. Backdoor Connections 471 In some deployments, there may exist direct connections among IPv4 472 client networks themselves in addition to the IPv6 transit network, 473 as "backdoor" connections referring to, where IPv4 packets can 474 either be transported between those IPv4 client networks via 475 backdoor connections, or through the IPv6 transit network. In 476 general, routing policies should be as such that the "backdoor" path 477 is preferred since the packet forwarding is within a single address 478 family without the need for IP header translation, among other 479 things. 481 9. Security 483 This document does not introduce any security issue than what has 484 been identified in [RFC5838], [I-D.ietf-ospf-mt-ospfv3] and 485 [RFC6052]. 487 10. IANA Considerations 489 No new IANA assignments are required for this document. 491 11. Acknowledgements 493 Many thanks to Acee Lindem, Dan Wing and Joel Halpern for their 494 comments. 496 12. References 498 12.1. Normative References 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, March 1997. 503 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, 504 "OSPF for IPv6", RFC 5340, July 2008. 506 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and 507 Aggarwal, R., "Support of address families in OSPFv3", RFC5838, 508 April 2010. 510 [I-D.ietf-ospf-mt-ospfv3] Mirtorabi, S. and A. Roy, "Multi- 511 topology routing in OSPFv3 (MT-OSPFv3)", 512 draft-ietf-ospf-mt-ospfv3-03 (work in progress), July 2007 514 [RFC6052] Huitema, C., Bao, C., Bagnulo, M. 515 Boucadair, M., and Li, X., 516 "IPv6 Addressing of IPv4/IPv6 Translators". October 2010 518 [I-D.draft-ietf-behave-v6v4-xlate] Li, X., Bao, C., 519 Baker, F., "IP/ICMP Translation Algorithm", September 2010. 521 12.2. Informative References 523 [RFC5565] Wu, J., Cui, Y., Metz, C., and Rosen, E., 524 "Softwire Mesh Network", RFC 5565, June 2009 526 [I-D.boucadair-softwire-dslite-v6only] Boucadair, M., 527 Jacquenet, C., Grimault, JL., Kassi-Lahlou, M. Levis, P., 528 Cheng, D., Lee, Y., "Deplying Dual-Stack Lite (DS-Lite) 529 in IPv6 Network", October 2010. 531 13. Authors' Addresses 533 Dean Cheng 534 Huawei Technologies, 535 2330 Central Expressway, CA 95050, USA 536 Email: dean.cheng@huawei.com 538 Mohamed Boucadair 539 France Telecom 540 3, Av Francois Chateaux 541 Rennes 35000 542 France 543 Email: mohamed.boucadair@orange-ftgroup.com