doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6992.txt b/doc/rfc/rfc6992.txt
new file mode 100644
index 0000000..55eccbd
--- /dev/null
+++ b/doc/rfc/rfc6992.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+