path: root/doc/rfc/rfc6992.txt

Internet Engineering Task Force (IETF)                          D. Cheng
Request for Comments: 6992                           Huawei Technologies
Category: Informational                                     M. Boucadair
ISSN: 2070-1721                                           France Telecom
                                                               A. Retana
                                                           Cisco Systems
                                                               July 2013


                 Routing for IPv4-Embedded IPv6 Packets

Abstract

   This document describes a routing scenario where IPv4 packets are
   transported over an IPv6 network, based on the methods described in
   RFCs 6145 and 6052, along with a separate OSPFv3 routing table for
   IPv4-embedded IPv6 routes in the IPv6 network.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6992.

Copyright Notice

   Copyright (c) 2013 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://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Cheng, et al.                 Informational                     [Page 1]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


Table of Contents

   1. Introduction ....................................................2
      1.1. The Scenario ...............................................3
      1.2. Routing Solution per RFC 5565 ..............................4
      1.3. An Alternative Routing Solution with OSPFv3 ................4
      1.4. OSPFv3 Routing with a Specific Topology ....................6
   2. Requirements Language ...........................................7
   3. Provisioning ....................................................7
      3.1. Deciding on the IPv4-Embedded IPv6 Topology ................7
      3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table ...7
   4. Translation of IP Packets .......................................8
      4.1. Address Translation ........................................8
   5. Advertising IPv4-Embedded IPv6 Routes ...........................9
      5.1. Advertising IPv4-Embedded IPv6 Routes through an
           IPv6 Transit Network .......................................9
           5.1.1. Routing Metrics .....................................9
           5.1.2. Forwarding Address .................................10
      5.2. Advertising IPv4 Addresses into Client Networks ...........10
   6. Aggregation on IPv4 Addresses and Prefixes .....................10
   7. Forwarding .....................................................10
   8. Backdoor Connections ...........................................11
   9. Prevention of Loops ............................................11
   10. MTU Issues ....................................................11
   11. Security Considerations .......................................12
   12. Operational Considerations ....................................13
   13. Acknowledgements ..............................................14
   14. References ....................................................14
      14.1. Normative References .....................................14
      14.2. Informative References ...................................14

1.  Introduction

   This document describes a routing scenario where IPv4 packets are
   transported over an IPv6 network, based on [RFC6145] and [RFC6052],
   along with a separate OSPFv3 routing table for IPv4-embedded IPv6
   routes in the IPv6 network.  This document does not introduce any new
   IPv6 transition mechanism.

   In this document, the following terminology is used:

   o  An IPv4-embedded IPv6 address denotes an IPv6 address that
      contains an embedded 32-bit IPv4 address constructed according to
      the rules defined in [RFC6052].

   o  IPv4-embedded IPv6 packets are packets of which destination
      addresses are IPv4-embedded IPv6 addresses.




Cheng, et al.                 Informational                     [Page 2]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


   o  AFBR (Address Family Border Router) [RFC5565] refers to an edge
      router that supports both IPv4 and IPv6 address families, but the
      backbone network it connects to only supports either the IPv4 or
      IPv6 address family.

   o  AFXLBR (Address Family Translation Border Router) is defined in
      this document.  It refers to a border router that supports both
      IPv4 and IPv6 address families located on the boundary of an IPv4-
      only network and an IPv6-only network and that is capable of
      performing IP header translation between IPv4 and IPv6 [RFC6145].

1.1.  The Scenario

   Due to exhaustion of public IPv4 addresses, there has been a
   continuing effort within the IETF to investigate and specify IPv6
   transitional techniques.  In the course of the transition, it is
   certain that networks based on IPv4 and IPv6 technologies,
   respectively, will coexist at least for some time.  One such scenario
   is the interconnection of IPv4-only and IPv6-only networks, and in
   particular, when an IPv6-only network serves as an interconnection
   between several segregated IPv4-only networks.  In this scenario,
   IPv4 packets are transported over the IPv6 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 between the IPv4 networks via some
   mechanism.

   In general, running an IPv6-only network would reduce operational
   expenditures and optimize operations as compared to an IPv4-IPv6
   dual-stack environment.  Some proposed solutions allow the delivery
   of IPv4 services over an IPv6-only network.  This document specifies
   an engineering technique that separates the routing table dedicated
   to IPv4-embedded IPv6 destinations from the routing table used for
   native IPv6 destinations.

   OSPFv3 is designed to support multiple instances.  Maintaining a
   separate routing table for IPv4-embedded IPv6 routes would simplify
   implementation, troubleshooting, and operation; it would also prevent
   overload of the native IPv6 routing table.  A separate routing table
   can be generated from a separate routing instance.











Cheng, et al.                 Informational                     [Page 3]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


1.2.  Routing Solution per RFC 5565

   The aforementioned scenario is described in [RFC5565], i.e., the
   IPv4-over-IPv6 scenario, where the network core is IPv6-only and the
   interconnected IPv4 networks are called IPv4 client networks.  The
   P Routers (Provider Routers) in the core only support IPv6, but the
   AFBRs support IPv4 on interfaces facing IPv4 client networks and IPv6
   on interfaces facing the core.  The routing solution defined in
   [RFC5565] for this scenario is to run IBGP among AFBRs to exchange
   IPv4 routing information in the core, 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.

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 where several segregated IPv4
   networks, called IPv4 client networks, are interconnected by an IPv6
   network.  The IPv6 network and the interconnected IPv4 networks may
   or may not belong to the same Autonomous System (AS).  We refer to
   the border node on the boundary of an IPv4 client network and the
   IPv6 network as an Address Family Translation Border Router (AFXLBR),
   which supports both the IPv4 and IPv6 address families and is capable
   of translating an IPv4 packet to an IPv6 packet, and vice versa,
   according to [RFC6145].  The described scenario is illustrated in
   Figure 1.
























Cheng, et al.                 Informational                     [Page 4]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


                        +--------+   +--------+
                        |  IPv4  |   |  IPv4  |
                        | Client |   | Client |
                        | Network|   | Network|
                        +--------+   +--------+
                            |   \     /   |
                            |    \   /    |
                            |     \ /     |
                            |      X      |
                            |     / \     |
                            |    /   \    |
                            |   /     \   |
                        +--------+   +--------+
                        | AFXLBR |   | AFXLBR |
                     +--| IPv4/6 |---| IPv4/6 |--+
                     |  +--------+   +--------+  |
       +--------+    |                           |    +--------+
       |  IPv6  |    |                           |    |  IPv6  |
       | Client |----|                           |----| Client |
       | Network|    |            IPv6           |    | Network|
       +--------+    |            only           |    +--------+
                     |                           |
                     |  +--------+   +--------+  |
                     +--| AFXLBR |---| AFXLBR |--+
                        | IPv4/6 |   | IPv4/6 |
                        +--------+   +--------+
                            |   \     /   |
                            |    \   /    |
                            |     \ /     |
                            |      X      |
                            |     / \     |
                            |    /   \    |
                            |   /     \   |
                        +--------+   +--------+
                        |  IPv4  |   |  IPv4  |
                        | Client |   | Client |
                        | Network|   | Network|
                        +--------+   +--------+

   Figure 1: Segregated IPv4 Networks Interconnected by an IPv6 Network

   Since the scenario occurs most commonly within an organization, an
   IPv6 prefix can be locally allocated and used by AFXLBRs to construct
   IPv4-embedded IPv6 addresses [RFC6052].  The embedded IPv4 address or
   prefix belongs to an IPv4 client network that is connected to the
   AFXLBR.  An AFXLBR injects IPv4-embedded IPv6 addresses and prefixes
   into the IPv6 network using OSPFv3, and it also installs
   IPv4-embedded IPv6 routes advertised by other AFXLBRs.



Cheng, et al.                 Informational                     [Page 5]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


   When an AFXLBR receives an IPv4 packet from a locally connected IPv4
   client network destined to a remote IPv4 client network, it
   translates the IPv4 header to the relevant IPv6 header [RFC6145], and
   in that process, the source and destination IPv4 addresses are
   translated into IPv4-embedded IPv6 addresses, respectively [RFC6052].
   The resulting IPv6 packet is then forwarded to the AFXLBR that
   connects to the destination IPv4 client network.  The remote AFXLBR
   derives the IPv4 source and destination addresses from the IPv4-
   embedded IPv6 addresses, respectively [RFC6052], and translates the
   header of the received IPv6 packet to the relevant IPv4 header
   [RFC6145].  The resulting IPv4 packet is then forwarded according to
   the IPv4 routing table maintained on the AFXLBR.

   There are use cases where the proposed routing solution is useful.
   One case is that some border nodes do not participate in IBGP for the
   exchange of routes, or IBGP is not used at all.  Another case is when
   tunnels are not deployed in the IPv6 network, or native IPv6
   forwarding is preferred.  Note that with this routing solution, the
   IPv4 and IPv6 header translation performed in both directions by the
   AFXLBR is stateless.

1.4.  OSPFv3 Routing with a Specific Topology

   In general, IPv4-embedded IPv6 packets can be forwarded just like
   native IPv6 packets with OSPFv3 running in the IPv6 network.
   However, this would require that IPv4-embedded IPv6 routes be flooded
   throughout the entire IPv6 network and stored on every router.  This
   is not desirable from a scaling perspective.  Moreover, since all
   IPv6 routes are stored in the same routing table, it would be
   inconvenient to manage the resource required for routing and
   forwarding based on traffic category, if so desired.

   To improve the situation, a separate OSPFv3 routing table dedicated
   to the IPv4-embedded IPv6 topology can be constructed; that table
   would be solely used for routing IPv4-embedded IPv6 packets in the
   IPv6 network.  The IPv4-embedded IPv6 topology includes all the
   participating AFXLBRs and a set of P Routers providing redundant
   connectivity with alternate routing paths.

   To realize this, a separate OSPFv3 instance is configured in the IPv6
   network [RFC5838].  This instance operates on all participating
   AFXLBRs and a set of P routers that interconnect them.  As a result,
   there would be a dedicated IPv4-embedded IPv6 topology that is
   maintained on all these routers, along with a dedicated IPv4-embedded
   IPv6 routing table.  This routing table in the IPv6 network is solely
   for forwarding IPv4-embedded IPv6 packets.





Cheng, et al.                 Informational                     [Page 6]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


   This document elaborates on how configuration is done with this
   method and on related routing issues.

   This document only focuses on unicast routing for IPv4-embedded IPv6
   packets using OSPFv3.

2.  Requirements Language

   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 [RFC2119].

3.  Provisioning

3.1.  Deciding on the IPv4-Embedded IPv6 Topology

   Before deploying configurations that use a separate OSPFv3 routing
   table for IPv4-embedded IPv6 addresses and prefixes, a decision must
   be made regarding the set of routers and their interfaces in the IPv6
   network that should be part of the IPv4-embedded IPv6 topology.

   For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that
   connect to IPv4 client networks MUST be members of this topology.  An
   AFXLBR MUST have at least one connection with a P Router in the IPv6
   network or another AFXLBR.

   The IPv4-embedded IPv6 topology is a subtopology of the entire IPv6
   network, and if all routers (including AFXLBRs and P routers) and all
   their interfaces are included, the two topologies converge.
   Generally speaking, when this subtopology contains more
   interconnected P Routers, there would be more routing paths across
   the IPv6 network from one IPv4 client network to the other; however,
   this requires more routers in the IPv6 network to participate in
   IPv4-embedded IPv6 routing.  In any case, the IPv4-embedded IPv6
   topology MUST be continuous with no partitions.

3.2.  Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table

   In an IPv6 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 in [RFC5838].

   It is assumed that the IPv6 network that is interconnected with IPv4
   networks as described in this document is under one administration,
   and as such an OSPFv3 Instance ID (IID) is allocated locally and used
   for OSPFv3 operation dedicated to unicast IPv4-embedded IPv6 routing
   in an IPv6 network.  This IID is configured on OSPFv3 router
   interfaces that participate in the IPv4-embedded IPv6 topology.



Cheng, et al.                 Informational                     [Page 7]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


   A locally configured OSPFv3 IID is allocated in the range 192 to 255,
   inclusive, in the "OSPFv3 Instance ID Address Family Values"
   registry; this range is reserved for "Private Use" [RFC6969].  This
   IID must be used to encode the "Instance ID" field in the packet
   header of OSPFv3 packets associated with the OSPFv3 instance.

   In addition, the AF-bit in the OSPFv3 Option field MUST be set.

   During Hello packet processing, an adjacency may only be established
   when the received Hello packet contains the same Instance ID as the
   Instance ID configured on the receiving OSPFv3 interface.  This
   insures that only interfaces configured as part of the OSPFv3 unicast
   IPv4-embedded IPv6 topology are used for IPv4-embedded IPv6 unicast
   routing.

   For more details, the reader is referred to [RFC5838].

4.  Translation of IP Packets

   When transporting IPv4 packets across an IPv6 network via the
   mechanism described above (Section 3.2), an IPv4 packet is translated
   to an IPv6 packet at the ingress AFXLBR, and the IPv6 packet is
   translated back to an IPv4 packet at the egress AFXLBR.  IP packet
   header translation is accomplished in a stateless manner according to
   rules specified in [RFC6145]; the details of address translation are
   explained in the next subsection.

4.1.  Address Translation

   Prior to address translation, an IPv6 prefix is allocated by the
   operator, and it is used to form IPv4-embedded IPv6 addresses.

   The IPv6 prefix can either be the IPv6 well-known prefix (WKP) 64:
   ff9b::/96 or a network-specific prefix that is unique to the
   organization; for the latter case, the IPv6 prefix length may be 32,
   40, 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, as described in [RFC6052].

   During translation from an IPv4 header to an IPv6 header at an
   ingress AFXLBR, the source IPv4 address and destination IPv4 address
   are translated into the corresponding source IPv6 address and
   destination IPv6 address, respectively.  During translation from an
   IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6
   address and destination IPv6 address are translated into the
   corresponding source IPv4 address and destination IPv4 address,
   respectively.  Note that address translation is accomplished in a
   stateless manner.



Cheng, et al.                 Informational                     [Page 8]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


   When an IPv6 WKP is used, [RFC6052] allows only global IPv4 addresses
   to be embedded in the IPv6 address.  An IPv6 address composed of a
   WKP and a non-global IPv4 address is hence invalid, and packets that
   contain such an address received by an AFXLBR are dropped.

   In the case where both the IPv4 client networks and the IPv6 transit
   network belong to the same organization, non-global IPv4 addresses
   may be used with a network-specific prefix [RFC6052].

5.  Advertising IPv4-Embedded IPv6 Routes

   In order to forward IPv4 packets to the proper destination across an
   IPv6 network, IPv4 reachability information needs to be disseminated
   throughout the IPv6 network.  This is performed by AFXLBRs that
   connect to IPv4 client networks using OSPFv3.

   With the scenario described in this document, i.e., a set of AFXLBRs
   that interconnect multiple IPv4 client networks with an IPv6 network,
   the IPv4 networks and IPv6 networks belong to the same or separate
   Autonomous Systems (ASs), and as such, these AFXLBRs behave as AS
   Boundary Routers (ASBRs).

5.1.  Advertising IPv4-Embedded IPv6 Routes through an IPv6 Transit
      Network

   IPv4 addresses and prefixes in an IPv4 client network are translated
   into IPv4-embedded IPv6 addresses and prefixes, respectively, using
   the IPv6 prefix allocated by the operator and the method specified in
   [RFC6052].  These routes are then advertised by one or more attached
   ASBRs into the IPv6 transit network using AS-External-LSAs [RFC5340],
   i.e., with advertising scope comprising the entire Autonomous System.

5.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 comparable to the link state metric, and we assume that in most
   cases OSPFv2 is used in client IPv4 networks.  This metric is added
   to the metric of the intra-AS path to the ASBR during the OSPFv3
   route calculation.  Through ASBR configuration, the metric can be set
   to a Type 2 external metric, which is considered much larger than the
   metric for any intra-AS path.  Refer to the OSPFv3 specification
   [RFC5340] for more details.  In either case, an external metric may
   take the same value as in an IPv4 network (using OSPFv2 or another
   routing protocol) but may also be specified based on some routing
   policy, the details of which are beyond the scope of this document.





Cheng, et al.                 Informational                     [Page 9]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


5.1.2.  Forwarding Address

   If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is
   used to carry an IPv6 address, that address must also be an
   IPv4-embedded IPv6 address where the embedded IPv4 address is the
   destination address in an IPv4 client network.  However, since an
   AFXLBR sits on the border of an IPv4 network and an IPv6 network, it
   is RECOMMENDED that the "Forwarding Address" field not be used, so
   that the AFXLBR can make the forwarding decision based on its own
   IPv4 routing table.

5.2.  Advertising IPv4 Addresses into Client Networks

   IPv4-embedded IPv6 routes injected into the IPv6 network from one
   IPv4 client network MAY be advertised into another IPv4 client
   network after the associated destination addresses and prefixes are
   translated back to IPv4 addresses and prefixes, respectively.  This
   operation is similar to normal OSPFv3 operation, wherein an
   AS-External-LSA can be advertised in a non-backbone area by default.

   An IPv4 client network can limit which advertisements it receives
   through configuration.

   For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT
   be advertised into any IPv6 client networks that are also connected
   to the IPv6 transit network.

6.  Aggregation on IPv4 Addresses and Prefixes

   In order to reduce the amount of Link State Advertisements (LSAs)
   that are injected into the IPv6 network, an implementation should
   provide mechanisms to aggregate IPv4 addresses and prefixes at an
   AFXLBR prior to advertisement as IPv4-embedded IPv6 addresses and
   prefixes.  In general, the aggregation practice should be based on
   routing policy, which is beyond the scope of this document.

7.  Forwarding

   There are three cases applicable to forwarding IP packets in the
   scenario described in this document:

   1.  On an AFXLBR, if an IPv4 packet is received on an interface
       connecting to an IPv4 segregated client network with a
       destination IPv4 address belonging to another IPv4 client
       network, the header of the packet is translated to the
       corresponding IPv6 header as described in Section 4, and the
       packet is then forwarded to the destination AFXLBR that
       advertised the IPv4-embedded IPv6 address into the IPv6 network.



Cheng, et al.                 Informational                    [Page 10]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


   2.  On an AFXLBR, 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 the corresponding IPv4
       header as described in Section 4, and the packet is then
       forwarded accordingly.

   3.  On any router that is within the IPv4-embedded IPv6 topology
       subset of the IPv6 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 to the IPv6 next hop, just like
       the handling for a normal IPv6 packet, without any translation.

   The classification of an IPv4-embedded IPv6 packet is done according
   to the IPv6 prefix of the destination address, which is either the
   WKP (i.e., 64:ff9b::/96) or locally allocated as defined in
   [RFC6052].

8.  Backdoor Connections

   In some deployments, IPv4 client networks are interconnected across
   the IPv6 network but are also directly connected to each other.  The
   direct connections between IPv4 client networks, sometimes called
   "backdoor" connections, can certainly be used to transport IPv4
   packets between IPv4 client networks.  In general, backdoor
   connections are preferred over the IPv6 network, since no address
   family translation is required.

9.  Prevention of Loops

   If an LSA sent from an AFXLBR into a client network could then be
   received by another AFXLBR, it would be possible for routing loops to
   occur.  To prevent loops, an AFXLBR MUST set the DN bit [RFC4576] in
   any LSA that it sends to a client network.  The AFXLBR MUST also
   ignore any LSA received from a client network that already has the DN
   bit set.

10.  MTU Issues

   In the IPv6 network, there are no new MTU issues introduced by this
   document.  If a separate OSPFv3 instance (per [RFC5838]) is used for
   IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is
   the same as that of the default OSPFv3 instance.

   However, the MTU in the IPv6 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 network must be equal to or less than the MTU of the IPv6
   network.  In order to achieve this requirement, it is recommended



Cheng, et al.                 Informational                    [Page 11]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


   that AFXLBRs perform IPv6 path discovery among themselves.  The
   resulting MTU, after taking into account the difference between the
   IPv4 header length and the IPv6 header length, must be "propagated"
   into IPv4 client networks, e.g., included in the OSPFv2 Database
   Description packet.

   The details of passing the proper MTU into IPv4 client networks are
   beyond the scope of this document.

11.  Security Considerations

   There are several security aspects that require attention in the
   deployment practices described in this document.

   In the OSPFv3 transit network, the security considerations for OSPFv3
   are handled as usual, and in particular, authentication mechanisms
   described in [RFC6506] can be deployed.

   When a separate OSPFv3 instance is used to support IPv4-embedded IPv6
   routing, the same Security Association (SA) [RFC4552] MUST be used by
   the embedded IPv4 address instance as other instances utilizing the
   same link, as specified in [RFC5838].

   Security considerations as documented in [RFC6052] must also be
   thought through and properly implemented, including the following:

   o  The IPv6 prefix that is used to carry an embedded IPv4 address
      (refer to Section 4.1) must be configured by the authorized
      operator on all participating AFXLBRs in a secure manner.  This is
      to help prevent a malicious attack resulting in network
      disruption, denial of service, and possible information
      disclosure.

   o  Effective mechanisms (such as reverse path checking) must be
      implemented in the IPv6 transit network (including AFXLBRs) to
      prevent spoofing of embedded IPv4 addresses, which otherwise might
      be used as source addresses of malicious packets.

   o  If firewalls are used in IPv4 and/or IPv6 networks, configuration
      of the routers must be consistent, so that there are no holes in
      IPv4 address filtering.

   The details of security handling are beyond the scope of this
   document.







Cheng, et al.                 Informational                    [Page 12]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


12.  Operational Considerations

   This document puts together some mechanisms based on existing
   technologies developed by the IETF as an integrated solution to
   transport IPv4 packets over an IPv6 network using a separate OSPFv3
   routing table.  There are several aspects of these mechanisms that
   require attention for deployment and operation.

   The tunnel-based solution documented in [RFC5565] and the solution
   proposed in this document are both used for transporting IPv4 packets
   over an IPv6 network, using different mechanisms.  The two methods
   are not related to each other, and they can coexist in the same
   network if so deployed, without any conflict.

   If one approach is to be deployed, the operator will decide which
   approach to use.  Note that each approach has its own characteristics
   and requirements.  For example, the tunnel-based solution requires a
   mesh of inter-AFBR softwires (tunnels) spanning the IPv6 network, as
   well as IBGP to exchange routes between AFBRs [RFC5565]; the approach
   in this document requires AFXLBRs that are capable of performing
   IPv4-IPv6 packet header translation per [RFC6145].

   To deploy the solution as documented here, some configurations are
   required.  An IPv6 prefix must first be chosen that is used to form
   all the IPv4-embedded IPv6 addresses and prefixes advertised by
   AFXLBRs in the IPv6 network; refer to Section 4.1 for details.  The
   IPv4-embedded IPv6 routing table is created by using a separate
   OSPFv3 instance in the IPv6 network.  As described in Section 3.2,
   this configuration is accomplished according to the mechanism
   described in [RFC5838].

   Note that this document does not change any behavior of OSPFv3, and
   the existing or common practice should apply in the context of
   scalability.  For example, the amount of routes that are advertised
   by OSPFv3 is one key concern.  With the solution as described in this
   document, IPv4-embedded IPv6 addresses and prefixes will be injected
   by AFXLBRs into some part of the IPv6 network (see Section 3.1 for
   details), and a separate routing table will be used for IPv4-embedded
   IPv6 routing.  Care must be taken during network design such that 1)
   aggregations are performed on IPv4 addresses and prefixes before
   being advertised in the IPv6 network as described in Section 6, and
   2) estimates are made as to the amount of IPv4-embedded IPv6 routes
   that would be disseminated in the IPv6 network and to the size of the
   separate OSPFv3 routing table.







Cheng, et al.                 Informational                    [Page 13]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


13.  Acknowledgements

   Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand, and
   Brian Carpenter for their comments.

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4576]  Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
              Link State Advertisement (LSA) Options Bit to Prevent
              Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
              RFC 4576, June 2006.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.

   [RFC5838]  Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
              Aggarwal, "Support of Address Families in OSPFv3",
              RFC 5838, April 2010.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

   [RFC6969]  Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry
              Update", RFC 6969, July 2013.

14.2.  Informative References

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, June 2006.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [RFC6506]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
              Authentication Trailer for OSPFv3", RFC 6506,
              February 2012.






Cheng, et al.                 Informational                    [Page 14]
^L
RFC 6992         Routing for IPv4-Embedded IPv6 Packets        July 2013


Authors' Addresses

   Dean Cheng
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, California  95050
   USA

   EMail: dean.cheng@huawei.com


   Mohamed Boucadair
   France Telecom
   Rennes,  35000
   France

   EMail: mohamed.boucadair@orange.com


   Alvaro Retana
   Cisco Systems
   7025 Kit Creek Rd.
   Research Triangle Park, North Carolina  27709
   USA

   EMail: aretana@cisco.com

























Cheng, et al.                 Informational                    [Page 15]
^L