Network working group D. Cheng Internet Draft Huawei Category: Informational M. Boucadair Expires: July 13, 2011 France Telecom January 14, 2011 Routing for IPv4-Embedded IPv6 Packets draft-cheng-ospf-ipv4-embedded-ipv6-routing-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://truestee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Cheng & Boucadair Expires July 2011 [Page 1] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes routing packets destined to IPv4-Embedded IPv6 addresses across IPv6 transit core using OSPFv3 with a separate routing table. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 1.1. The scenario..............................................3 1.2. Routing Solution a la RFC5565.............................3 1.3. An Alternative Routing Solution with OSPFv3...............4 1.4. OSPFv3 Routing with a Specific Topology...................5 2. Provisioning...................................................6 2.1. Deciding the IPv4-Embedded IPv6 Topology..................6 2.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table..6 2.3. OSPFv3 Topology with a Separate Instance ID...............6 2.4. OSPFv3 Topology with the Default Instance.................7 3. IP Header Translation..........................................7 3.1. Address Translation.......................................7 4. Advertising IPv4-Embedded IPv6 Routes..........................8 4.1. Advertising IPv4-Embedded Ipv6 Routes into IPv6 Transit Network........................................................8 4.1.1. Routing Metrics......................................8 4.1.2. Forwarding Address...................................9 4.2. Advertising IPv4 Addresses into Client Networks...........9 5. Aggregation on IPv4 Addresses and Prefixes.....................9 6. Forwarding.....................................................9 7. MTU Issue.....................................................10 8. Backdoor Connections..........................................11 9. Security......................................................11 10. IANA Considerations..........................................11 11. Acknowledgements.............................................11 12. References...................................................11 12.1. Normative References....................................11 12.2. Informative References..................................12 Cheng & Boucadair Expires July 2011 [Page 2] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 1. Introduction This document describes a routing scenario where IPv4 packets are transported over IPv6 network. In this document the following terminology is used: - An IPv4-Embedded IPv6 address denotes an IPv6 address which contains an embedded 32-bit IPv4 address constructed according to the rules defined in [RFC6052]. - IPv4-Embedded IPv6 packets are packets of which destination addresses are IPv4-Embedded IPv6 addresses. - AFBR (Address Family Border Router, [RFC5565]) refers to a border router which is located at the boundaries of an IPv6-only domain and interconnect with an IPv4-only network. 1.1. The scenario Due to exhaustion of public IPv4 addresses, there has been continuing effort within IETF on IPv6 transitional techniques. In the course of transition, it is certain that networks based on IPv4 and IPv6 transfer capabilities, respectively, will co-exist at least for some time. One scenario of the co-existence is that IPv4-only networks inter-connecting with IPv6-only networks, and in particular, when an IPv6-only network serves as a transit network that inter-connects several segregated IPv4-only networks. In this scenario, IPv4 packets are transported over the IPv6 transit network between IPv4 networks. In order to forward an IPv4 packet from a source IPv4 network to the destination IPv4 network, IPv4 reachability information must be exchanged among involved networks by dedicated means. Unlike dual-stack networks, operating an IPv6-only network would allow optimize OPEX and maintenance operations in particular. Some solutions have been proposed to allow delivery of IPv4 services over an IPv6-only network. This document focuses on an engineering techniques which aims to separate the routing instance dedicated to IPv4-embedded IPv6 destination from native IPv6 ones. 1.2. Routing Solution a la RFC5565 The aforementioned scenario is described in [RFC5565], i.e.- IPv4- over-IPv6 scenario, where the network core is IPv6-only, and the inter-connected IPv4 networks are called IPv4 client networks. The P routers in the core only support IPv6 but the AFBRs (Address Family Cheng & Boucadair Expires July 2011 [Page 3] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 Border Routers) support IPv4 on interface facing IPv4 client networks, and IPv6 on interface facing the core. The routing solution defined in [RFC5565] for this scenario is to run i-BGP among AFBRs to exchange IPv4 routing information with each other, and the IPv4 packets are forwarded from one IPv4 client network to the other through a softwire using tunneling technology such as MPLS LSP, GRE, L2TPv3, etc. Some of the terms that are used in [RFC5565] are used in this document and they include AFBR, IPv4 client networks, IPv6 transit network, etc. 1.3. An Alternative Routing Solution with OSPFv3 In this document, we propose an alternative routing solution for the scenario described in Section 1.1. Since the scenario occurs most in a single ISP operating environment, an IPv6 prefix can be locally allocated and used to construct IPv4-Embedded IPv6 addresses according to [RFC6052] by each AFBR, where the embedded IPv4 addresses are associated with an IPv4 client network that is connected to the AFBR, and each IPv4 address is an individual IPv4 address or prefix. An AFBR injects IPv4-Embedded IPv6 addresses/prefixes into the IPv6 transit network using OSPFv3 and also installs those advertised by other AFBRs. When an IPv4 packet is sent from one IPv4 client network to the other, it is first encapsulated with an IPv6 header, where the source and destination IPv6 address are constructed, in a stateless manner, as IPv4-Embedded IPv6 address, respectively, and then forwarded to the destination AFBR that is the advertising router of the destination IPv4-Embedded IPv6 address. The destination AFBR replaces the IPv6 header by the corresponding IPv4 header, where the source and destination IPv4 addresses are derived from the IPv4-Embedded IPv6 source and destination addresses, respectively, and then forwards the IPv4 packet using its IPv4 routing table in the attached IPv4 client network. There are use cases where the proposed routing solution is useful. One case is that some AFBRs do not participate in i-BGP for routes exchange (one example is documented in [I-D.boucadair-softwire- dslite-v6only]), or i-BGP is not used at all. Another case is that tunnel mechanism is not used in the IPv6 transit network, or native IPv6 forwarding is preferred. Note also that with this routing solution, the IPv4-IPv6 inter-connection and associated header translation that occurs at an AFBR is stateless. Cheng & Boucadair Expires July 2011 [Page 4] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 1.4. OSPFv3 Routing with a Specific Topology Routing IPv4-Embedded IPv6 packets in the IPv6 transit network using OSPFv3, in general, may be performed by the OSPFv3 operation that is already running in the IPv6 network. One concern however, is that IPv4-Embedded IPv6 routes would flood throughout the entire transit network and stored on every router, which may not be desirable. Also, since all IPv6 routes are stored in the same routing table, it might be more difficult to manage the resource required for routing and forwarding based on traffic category, if so desired. To solve this problem and to ease the separation between native IPv6 and IPv4-inferred routing policies, a separate OSPFv3 routing table can be constructed that is dedicated to IPv4-Embedded IPv6 topology, and that table is solely used for routing IPv4-Embedded IPv6 packets (i.e., IPv4 part of the Internet) in the transit network. Further, only a set of routers in the transit network are required to be involved in such routing scheme, including AFBRs that connect to IPv4 client networks along with a set of P routers in the core for routing path. There are two methods to build a separate OSPFv3 routing table for IPv4-Embedded IPv6 routing. - The first one is to run a separate OSPFv3 instance for IPv4- Embedded IPv6 topology in the IPv6 transit network according to [RFC5838], - The second one is to stay with the existing OSPFv3 instance that already operates in the transit network, but maintain a separate IPv4-Embedded topology, according to [I-D.ietf-ospf-mt-ospfv3]. With both methods, there would be a dedicated IPv4-Embedded IPv6 topology that is maintained by OSPFv3 speakers and thus a dedicated IPv4-Embedded IPv6 routing table, which is then used for routing IPv4-Embedded IPv6 packets (i.e., packets destined to an IPv4 destination). It would be operators' preference as which method is going to be used. This document elaborates on how configuration is done for each method and related routing issues that is common to both. This document only focuses on unicast routing for IPv4-Embedded IPv6 packets using OSPFv3. Cheng & Boucadair Expires July 2011 [Page 5] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 2. Provisioning 2.1. Deciding the IPv4-Embedded IPv6 Topology Before making appropriate configuration in order to generate a separate OSPFv3 routing table for IPv4-Embedded IPv6 addresses/prefixes, decision must be made on the set of routers and their interfaces in the IPv6 transit network that should be on the IPv4-Embedded IPv6 topology. For the purpose of this topology, all AFBRs that connect to IPv4 client networks should be members of this topology, and also at least some of their network core facing interfaces, which depends on which P routers in the IPv6 transit network would be on this topology. The IPv4-Embedded IPv6 topology is a sub-topology of the entire IPv6 transit network, and if all routers (including AFBRs and P-routers) and their interfaces are included, the two topologies converge. In general, as more P routers and their interfaces are configured on this sub-topology, it would increase the inter-connectivity and potentially, there would be more routing paths cross the transit network from one IPv4 client network to the other, at the cost that more routers need to participate the IPv4-Embedded IPv6 routing. In any case, the IPv4-Embedded IPv6 topology must be continuous with no partitions. 2.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table In an IPv6 transit network, in order to maintain a separate IPv6 routing table that contains routes for IPv4-Embedded IPv6 destinations only, OSPFv3 needs to use the mechanism defined either in [RFC5838] or [I-D.ietf-ospf-mt-ospfv3] with required configuration tasks, as described in the following sub-sections. 2.3. OSPFv3 Topology with a Separate Instance ID It is assumed that the scenario as described in this document is under a single ISP and as such, an OSPFv3 instance ID (IID) is allocated locally and used for an OSPFv3 operation dedicated to unicast IPv4-Embedded IPv6 routing in an IPv6 transit network. This IID is configured on each OSPFv3 interface of routers that participates in this routing instance. The range for a locally configured OSPFv3 IID is from 128 to 255, inclusively, and this number must be used to encode the "Instance Cheng & Boucadair Expires July 2011 [Page 6] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 ID" field in the OSPFv3 packet header on every router that executes this instance in the IPv6 transit network. In addition, the "AF" bit in the OSPFv3 Option field must be set. During the Hello packets processing, adjacency may only be established when received Hello packets contain the same Instance ID as configured on the receiving interface for OSPFv3 instance dedicated to the IPv4-Embedded IPv6 routing. For more details, the reader is referred to [RFC5838]. 2.4. OSPFv3 Topology with the Default Instance Similar to that as described in the previous section, an OSPFv3 multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3 operation including unicast IPv4-Embedded IPv6 routing in an IPv6 transit network. This MTID is configured on each OSPFv3 interface of routers that participates in this routing topology. The range for a locally configured OSPFv3 MT-ID is from 32 to 255, inclusively, and this number must be used to encode the "MT-ID" field that is included in some of the extended LSAs as documented in [I-D.ietf-ospf-mt-ospfv3]. In addition, the MT bit in the OSPFv3 Option field must be set. For more details, the reader is referred to [I-D.ietf-ospf-mt- ospfv3]. 3. IP Header Translation When transporting IPv4 packets across an IPv6 transit network with the mechanism described above, the IPv4 header is replaced by an IPv6 header at an ingress AFBR and restored at an exit AFBR. The IP header translation is accomplished in stateless manner according to rules specified in [I-D.draft-ietf-behave-v6v4-xlate], with the address translation detail explained in the next sub-section. 3.1. Address Translation Prior to the operation, an IPv6 prefix is allocated by the ISP and it is used to form an IPv4-Embedded IPv6 address. The IPv6 prefix can either be a well-known IPv6 prefix (WKP) 64:FF9B::/96, or a network-specific prefix that is unique to the ISP, and for the later case, the IPv6 prefix length may be 32, 40, Cheng & Boucadair Expires July 2011 [Page 7] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 48, 56 or 64. In either case, this IPv6 prefix is used during the address translation between an IPv4 address and an IPv4-Embedded IPv6 address, which is performed according to [RFC6052]. During translation from an IPv4 header to an IPv6 header at an ingress AFBR, the source IPv4 address and destination IPv4 address are translated into the corresponding IPv6 source address and destination IPv6 address, respectively, and during translation from an IPv6 header to an IPv4 header at an exit AFBR, the source IPv6 address and destination IPv6 address are translated into the corresponding IPv4 source address and destination IPv4 address, respectively. Note that the address translation is accomplished in a stateless manner. 4. Advertising IPv4-Embedded IPv6 Routes In order to forward IPv4 packets to the proper destination across IPv6 transit network, IPv4 reachability needs to be disseminated throughout the IPv6 transit network and this work is performed by AFBRs that connect to IPv4 client networks using OSPFv3. With the scenario described in this document, i.e.- a set of AFBRs that inter-connect a bunch of IPv4 client networks with an IPv6 transit network, we view that IPv4 networks and IPv6 networks belong to separate Autonomous Systems, and as such, these AFBRs are OSPFv3 ASBRs. 4.1. Advertising IPv4-Embedded Ipv6 Routes into IPv6 Transit Network IPv4 addresses and prefixes in an IPv4 client network are translated into IPv4-Embedded IPv6 addresses and prefixes, respectively, using the same IPv6 prefix allocated by the ISP and the method specified in [RFC6052], and then advertised by one or more attached ASBRs into the IPv6 transit network using AS External LSA ([RFC5340]), i.e.- with the advertising scope throughout the entire Autonomous System. 4.1.1. Routing Metrics By default, the metric in an AS External LSA that carries an IPv4- Embedded IPv6 address or prefixes is a Type 1 external metric, which is then to be added to the metric of an intra-AS path during OSPFv3 routes calculation. By configuration on an ASBR, the metric can be set to a Type 2 external metric, which is considered much larger than that on any intra-AS path. The detail is referred to OSPFv3 specification [RFC5340]. In either case, an external metric may be exact the same unit as in an IPv4 network (running OSPFv2 or Cheng & Boucadair Expires July 2011 [Page 8] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 others), but may also be specified by a routing policy, the detail is outside of the scope of this document. 4.1.2. Forwarding Address If the "Forwarding Address" field of an OSPFv3 AS External LSA is used to carry an IPv6 address, that must also be an IPv4-Embedded IPv6 address where the embedded IPv4 address is the actual address in an IPv4 client network to which, data traffic is forwarded to. However, since an AFTR sits on the border of an IPv4 network and an IPv6 network, it is recommended that the "Forwarding Address" field not to be used by setting the F bit in the associated OSPFv3 AS-external-LSA to zero, so that the AFTR can make the forwarding decision based on its own IPv4 routing table. 4.2. Advertising IPv4 Addresses into Client Networks IPv4-Embedded IPv6 routes injected into the IPv6 transit network from one IPv4 client network may be advertised into another IPv4 client network, after the associated destination addresses/prefixes are translated back to IPv4 addresses/prefixes format. This operation is similar to the regular OSPFv3 operation, wherein an AS External LSA can be advertised in a non-backbone area by default. An IPv4 client network that does not want to receive such advertisement can be configured as a stub area or with other routing policy. For the purpose of this document, IPv4-Embedded IPv6 routes must not advertised into any IPv6 client networks that also connected to the IPv6 transit network. 5. Aggregation on IPv4 Addresses and Prefixes In order to reduce the amount of AS External LSAs that are injected to the IPv6 transit network, effort must be made to aggregate IPv4 addresses and prefixes at each AFBR before advertising. 6. Forwarding There are three cases in forwarding IP packets in the scenario as described in this document, as follows: 1) On an AFBR, if an IPv4 packet that is received on an interface connecting to an IPv4 client network with the destination IPv4 address belong to another IPv4 client network, the header of the packet is translated to a corresponding IPv6 header as described Cheng & Boucadair Expires July 2011 [Page 9] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 in Section 3, and the packet is then forwarded to the destination AFBR that advertises the IPv4-Embedded IPv6 address through the IPv6 transit network. 2) On an AFBR, if an IPv4-Embedded IPv6 packet is received and the embedded destination IPv4 address is in its IPv4 routing table, the header of the packet is translated to a corresponding IPv4 header as described in Section 3, and the packet is then forwarded accordingly. 3) On any router that is within the IPv4-Embedded IPv6 topology located in the IPv6 transit network, if an IPv4-Embedded IPv6 packet is received and a route is found in the IPv4-Embedded IPv6 routing table, the packet is forwarded accordingly. The classification of IPv4-Embedded IPv6 packet is according to the IPv6 prefix of the destination address, which is either a WKP (i.e., 64:FF9B::/96) or locally allocated as defined in [RFC6052]. 7. MTU Issue In the IPv6 transit network, there is no new MTU issue introduced by this document. If a separate OSPFv3 instance (per [RFC5838]) is used for IPv4-Embedded IPv6 routing, the MTU handling in the transit network is the same as that of the default OSPFv3 instance. If a separate OSPFv3 topology (per [I-D.ietf-ospf-mt-ospfv3]) is used for IPv4-Embedded IPv6 routing, the MTU handling in the transit network is the same as that of the default OSPFv3 topology. However, the MTU in the IPv6 transit network may be different than that of IPv4 client networks. Since an IPv6 router will never fragment a packet, the packet size of any IPv4-Embedded IPv6 packet entering the IPv6 transit network must be equal to or smaller than the MTU of the IPv6 transit network. In order to achieve this requirement, it is recommended that AFBRs to perform IPv6 path discovery among themselves and the resulting MTU, after taking into account of the difference between IPv4 header length and IPv6 header length, must be "propagated" into IPv4 client networks, e.g.- included in the OSPFv3 Database Description packet. The detail of passing the proper MTU into IPv4 client networks is beyond the scope of this document. Cheng & Boucadair Expires July 2011 [Page 10] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 8. Backdoor Connections In some deployments, there may exist direct connections among IPv4 client networks themselves in addition to the IPv6 transit network, as "backdoor" connections referring to, where IPv4 packets can either be transported between those IPv4 client networks via backdoor connections, or through the IPv6 transit network. In general, routing policies should be as such that the "backdoor" path is preferred since the packet forwarding is within a single address family without the need for IP header translation, among other things. 9. Security This document does not introduce any security issue than what has been identified in [RFC5838], [I-D.ietf-ospf-mt-ospfv3] and [RFC6052]. 10. IANA Considerations No new IANA assignments are required for this document. 11. Acknowledgements TBD 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and Aggarwal, R., "Support of address families in OSPFv3", RFC5838, April 2010. [I-D.ietf-ospf-mt-ospfv3] Mirtorabi, S. and A. Roy, "Multi- topology routing in OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in progress), July 2007 [RFC6052] Huitema, C., Bao, C., Bagnulo, M. Boucadair, M., and Li, X., "IPv6 Addressing of IPv4/IPv6 Translators". October 2010 Cheng & Boucadair Expires July 2011 [Page 11] Internet-Draft IPv4-Embedded IPv6 Routing January 2011 12.2. Informative References [RFC5565] Wu, J., Cui, Y., Metz, C., and Rosen, E., "Softwire Mesh Network", RFC 5565, June 2009 [I-D.boucadair-softwire-dslite-v6only] Boucadair, M., Jacquenet, C., Grimault, JL., Kassi-Lahlou, M. Levis, P., Cheng, D., Lee, Y., "Deplying Dual-Stack Lite (DS-Lite) in IPv6 Network", October 2010. [I-D.draft-ietf-behave-v6v4-xlate] Li, X., Bao, C., Baker, F., "IP/ICMP Translation Algorithm", September 2010. Authors' Addresses Dean Cheng Huawei Technologies, 2330 Central Expressway, CA 95050, USA Email: dean.cheng@huawei.com Mohamed Boucadair France Telecom 3, Av Francois Chateaux Rennes 35000 France Email: mohamed.boucadair@orange-ftgroup.com Cheng & Boucadair Expires July 2011 [Page 12]