draft-ietf-ospf-ipv4-embedded-ipv6-routing-14.txt   rfc6992.txt 
Network Working Group D. Cheng Internet Engineering Task Force (IETF) D. Cheng
Internet-Draft Huawei Technologies Request for Comments: 6992 Huawei Technologies
Intended status: Informational M. Boucadair Category: Informational M. Boucadair
Expires: December 13, 2013 France Telecom ISSN: 2070-1721 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
June 11, 2013 July 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-Embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-14
Abstract Abstract
This document describes a routing scenario where IPv4 packets are This document describes a routing scenario where IPv4 packets are
transported over an IPv6 network, based on RFCs 6145 and 6052, along transported over an IPv6 network, based on the methods described in
with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for
the IPv6 network. IPv4-embedded IPv6 routes in the IPv6 network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on December 13, 2013. 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 Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
1.1. The Scenario . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Scenario ...............................................3
1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . 4 1.2. Routing Solution per RFC 5565 ..............................4
1.3. An Alternative Routing Solution with OSPFv3 . . . . . . . 4 1.3. An Alternative Routing Solution with OSPFv3 ................4
1.4. OSPFv3 Routing with a Specific Topology . . . . . . . . . 6 1.4. OSPFv3 Routing with a Specific Topology ....................6
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language ...........................................7
3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Provisioning ....................................................7
3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . 6 3.1. Deciding on the IPv4-Embedded IPv6 Topology ................7
3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 7 3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table ...7
4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8 4. Translation of IP Packets .......................................8
4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 4.1. Address Translation ........................................8
5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8 5. Advertising IPv4-Embedded IPv6 Routes ...........................9
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 5.1. Advertising IPv4-Embedded IPv6 Routes through an
Transit Network . . . . . . . . . . . . . . . . . . . . . 9 IPv6 Transit Network .......................................9
5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 5.1.1. Routing Metrics .....................................9
5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 9 5.1.2. Forwarding Address .................................10
5.2. Advertising IPv4 Addresses into Client Networks . . . . . 9 5.2. Advertising IPv4 Addresses into Client Networks ...........10
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 10 6. Aggregation on IPv4 Addresses and Prefixes .....................10
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Forwarding .....................................................10
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 11 8. Backdoor Connections ...........................................11
9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11 9. Prevention of Loops ............................................11
10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. MTU Issues ....................................................11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations .......................................12
12. Operational Considerations . . . . . . . . . . . . . . . . . 12 12. Operational Considerations ....................................13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Acknowledgements ..............................................14
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 14. References ....................................................14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14.1. Normative References .....................................14
15.1. Normative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References ...................................14
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document describes a routing scenario where IPv4 packets are This document describes a routing scenario where IPv4 packets are
transported over an IPv6 network, based on [RFC6145] and [RFC6052], transported over an IPv6 network, based on [RFC6145] and [RFC6052],
along with a separate OSPFv3 routing table for IPv4-embedded IPv6 along with a separate OSPFv3 routing table for IPv4-embedded IPv6
routes in the IPv6 network. This document does not introduce any new routes in the IPv6 network. This document does not introduce any new
IPv6 transition mechanism. IPv6 transition mechanism.
In this document the following terminology is used: In this document, the following terminology is used:
o An IPv4-embedded IPv6 address denotes an IPv6 address which o An IPv4-embedded IPv6 address denotes an IPv6 address that
contains an embedded 32-bit IPv4 address constructed according to contains an embedded 32-bit IPv4 address constructed according to
the rules defined in [RFC6052]. the rules defined in [RFC6052].
o IPv4-embedded IPv6 packets are packets of which destination o IPv4-embedded IPv6 packets are packets of which destination
addresses are IPv4-embedded IPv6 addresses. addresses are IPv4-embedded IPv6 addresses.
o AFBR (Address Family Border Router, [RFC5565]) refers to an edge o AFBR (Address Family Border Router) [RFC5565] refers to an edge
router, which supports both IPv4 and IPv6 address families, but router that supports both IPv4 and IPv6 address families, but the
the backbone network it connects to only supports either the IPv4 backbone network it connects to only supports either the IPv4 or
or IPv6 address family. IPv6 address family.
o AFXLBR (Address Family Translation Border Router) is defined in o AFXLBR (Address Family Translation Border Router) is defined in
this document. It refers to a border router that supports both this document. It refers to a border router that supports both
IPv4 and IPv6 address families, located on the boundary of an IPv4 and IPv6 address families located on the boundary of an IPv4-
IPv4-only network and an IPv6-only network, and is capable of only network and an IPv6-only network and that is capable of
performing IP header translation between IPv4 and IPv6 according performing IP header translation between IPv4 and IPv6 [RFC6145].
to [RFC6145].
1.1. The Scenario 1.1. The Scenario
Due to exhaustion of public IPv4 addresses, there has been a Due to exhaustion of public IPv4 addresses, there has been a
continuing effort within the IETF on IPv6 transitional techniques. continuing effort within the IETF to investigate and specify IPv6
In the course of the transition, it is certain that networks based on transitional techniques. In the course of the transition, it is
IPv4 and IPv6 technologies respectively, will co-exist at least for certain that networks based on IPv4 and IPv6 technologies,
some time. One scenario of this co-existence is the inter-connection respectively, will coexist at least for some time. One such scenario
of IPv4-only and IPv6-only networks, and in particular, when an is the interconnection of IPv4-only and IPv6-only networks, and in
IPv6-only network serves as inter-connection between several particular, when an IPv6-only network serves as an interconnection
segregated IPv4-only networks. In this scenario, IPv4 packets are between several segregated IPv4-only networks. In this scenario,
transported over the IPv6 network between IPv4 networks. In order to IPv4 packets are transported over the IPv6 network between IPv4
forward an IPv4 packet from a source IPv4 network to the destination networks. In order to forward an IPv4 packet from a source IPv4
IPv4 network, IPv4 reachability information must be exchanged between network to the destination IPv4 network, IPv4 reachability
the IPv4 networks by some mechanism. information must be exchanged between the IPv4 networks via some
mechanism.
In general, running an IPv6-only network would reduce operational In general, running an IPv6-only network would reduce operational
expenditure and optimize the operation compared to IPv4-IPv6 dual- expenditures and optimize operations as compared to an IPv4-IPv6
stack environment. Some solutions have been proposed to allow dual-stack environment. Some proposed solutions allow the delivery
delivery of IPv4 services over an IPv6-only network. This document of IPv4 services over an IPv6-only network. This document specifies
specifies an engineering technique that separates the routing table an engineering technique that separates the routing table dedicated
dedicated to IPv4-embedded IPv6 destinations from the routing table to IPv4-embedded IPv6 destinations from the routing table used for
used for native IPv6 destinations. native IPv6 destinations.
OSPFv3 is designed to support multiple instances. Maintaining a OSPFv3 is designed to support multiple instances. Maintaining a
separate routing table for IPv4-embedded IPv6 routes would simplify separate routing table for IPv4-embedded IPv6 routes would simplify
the implementation, trouble shooting and operation; it also prevents implementation, troubleshooting, and operation; it would also prevent
overload of the native IPv6 routing table. A separate routing table overload of the native IPv6 routing table. A separate routing table
can be generated from a separate routing instance. can be generated from a separate routing instance.
1.2. Routing Solution per RFC5565 1.2. Routing Solution per RFC 5565
The aforementioned scenario is described in [RFC5565], i.e., IPv4 The aforementioned scenario is described in [RFC5565], i.e., the
-over-IPv6 scenario, where the network core is IPv6-only, and the IPv4-over-IPv6 scenario, where the network core is IPv6-only and the
inter-connected IPv4 networks are called IPv4 client networks. The interconnected IPv4 networks are called IPv4 client networks. The
P(rovider) Routers in the core only support IPv6 but the AFBRs P Routers (Provider Routers) in the core only support IPv6, but the
(Address Family Border Routers) support IPv4 on interfaces facing AFBRs support IPv4 on interfaces facing IPv4 client networks and IPv6
IPv4 client networks, and IPv6 on interfaces facing the core. The on interfaces facing the core. The routing solution defined in
routing solution defined in [RFC5565] for this scenario is to run [RFC5565] for this scenario is to run IBGP among AFBRs to exchange
i-BGP among AFBRs to exchange IPv4 routing information in the core, IPv4 routing information in the core, and the IPv4 packets are
and the IPv4 packets are forwarded from one IPv4 client network to forwarded from one IPv4 client network to the other through a
the other through a softwire using tunneling technology such as MPLS softwire using tunneling technology, such as MPLS, LSP, GRE,
LSP, GRE, L2TPv3, etc. L2TPv3, etc.
1.3. An Alternative Routing Solution with OSPFv3 1.3. An Alternative Routing Solution with OSPFv3
In this document, we propose an alternative routing solution for the In this document, we propose an alternative routing solution for the
scenario described in Section 1.1, where several segregated IPv4 scenario described in Section 1.1 where several segregated IPv4
networks, called IPv4 client networks, are inter-connected by an IPv6 networks, called IPv4 client networks, are interconnected by an IPv6
network. The IPv6 network and the inter-connected IPv4 networks may network. The IPv6 network and the interconnected IPv4 networks may
or may not belong to the same Autonomous System. We refer to the or may not belong to the same Autonomous System (AS). We refer to
border node on the boundary of an IPv4 client network and the IPv6 the border node on the boundary of an IPv4 client network and the
network as an Address Family Translation Border Router (AFXLBR), IPv6 network as an Address Family Translation Border Router (AFXLBR),
which supports both the IPv4 and IPv6 address families, and is which supports both the IPv4 and IPv6 address families and is capable
capable of translating an IPv4 packet to an IPv6 packet, and vice of translating an IPv4 packet to an IPv6 packet, and vice versa,
versa, according to [RFC6145]. The described scenario is illustrated according to [RFC6145]. The described scenario is illustrated in
in Figure 1. Figure 1.
+--------+ +--------+ +--------+ +--------+
| IPv4 | | IPv4 | | IPv4 | | IPv4 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
| \ / | | \ / |
| \ / | | \ / |
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
+--------+ +--------+ +--------+ +--------+
| AFXLBR | | AFXLBR | | AFXLBR | | AFXLBR |
+--| IPv4/6 |---| IPv4/6 |--+ +--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ | | +--------+ +--------+ |
+--------+ | | +--------+ +--------+ | | +--------+
| IPv6 | | | | IPv6 | | IPv6 | | | | IPv6 |
| Client |----| |----| Client | | Client |----| |----| Client |
| Network| | IPv6 | | Network| | Network| | IPv6 | | Network|
+--------+ | only | +--------+ +--------+ | only | +--------+
| | | |
| +--------+ +--------+ | | +--------+ +--------+ |
+--| AFXLBR |---| AFXLBR |--+ +--| AFXLBR |---| AFXLBR |--+
| IPv4/6 | | IPv4/6 | | IPv4/6 | | IPv4/6 |
+--------+ +--------+ +--------+ +--------+
| \ / | | \ / |
| \ / | | \ / |
| \ / | | \ / |
| X | | X |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
+--------+ +--------+ +--------+ +--------+
| IPv4 | | IPv4 | | IPv4 | | IPv4 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
Figure 1: Segregated IPv4 Networks Inter-connected by an IPv6 Network Figure 1: Segregated IPv4 Networks Interconnected by an IPv6 Network
Since the scenario occurs most commonly within an organization, an Since the scenario occurs most commonly within an organization, an
IPv6 prefix can be locally allocated and used by AFXLBRs to construct IPv6 prefix can be locally allocated and used by AFXLBRs to construct
IPv4-embedded IPv6 addresses according to [RFC6052]. The embedded IPv4-embedded IPv6 addresses [RFC6052]. The embedded IPv4 address or
IPv4 address or prefix belongs to an IPv4 client network that is prefix belongs to an IPv4 client network that is connected to the
connected to the AFXLBR. An AFXLBR injects IPv4-embedded IPv6 AFXLBR. An AFXLBR injects IPv4-embedded IPv6 addresses and prefixes
addresses and prefixes into the IPv6 network using OSPFv3, and it into the IPv6 network using OSPFv3, and it also installs
also installs IPv4-embedded IPv6 routes advertised by other AFXLBRs. IPv4-embedded IPv6 routes advertised by other AFXLBRs.
When an AFXLBR receives an IPv4 packet from a locally connected IPv4 When an AFXLBR receives an IPv4 packet from a locally connected IPv4
client network and destined to a remote IPv4 client network, it client network destined to a remote IPv4 client network, it
translates the IPv4 header to the relevant IPv6 header according to translates the IPv4 header to the relevant IPv6 header [RFC6145], and
[RFC6145], and in that process, source and destination IPv4 address in that process, the source and destination IPv4 addresses are
are translated into IPv4-embedded IPv6 addresses, respectively, translated into IPv4-embedded IPv6 addresses, respectively [RFC6052].
according to [RFC6052]. The resulting IPv6 packet is then forwarded The resulting IPv6 packet is then forwarded to the AFXLBR that
to the AFXLBR that connects to the destination IPv4 client network. connects to the destination IPv4 client network. The remote AFXLBR
The remote AFXLBR derives the IPv4 source and destination addresses derives the IPv4 source and destination addresses from the IPv4-
from the IPv4-embedded IPv6 addresses, respectively, according to embedded IPv6 addresses, respectively [RFC6052], and translates the
[RFC6052], and translates the header of the received IPv6 packet to header of the received IPv6 packet to the relevant IPv4 header
the relevant IPv4 header according to [RFC6145]. The resulting IPv4 [RFC6145]. The resulting IPv4 packet is then forwarded according to
packet is then forwarded according to the IPv4 routing table the IPv4 routing table maintained on the AFXLBR.
maintained on the AFXLBR.
There are use cases where the proposed routing solution is useful. There are use cases where the proposed routing solution is useful.
One case is that some border nodes do not participate in i-BGP for One case is that some border nodes do not participate in IBGP for the
routes exchange, or i-BGP is not used at all. Another case is when 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 tunnels are not deployed in the IPv6 network, or native IPv6
forwarding is preferred. Note that with this routing solution, the forwarding is preferred. Note that with this routing solution, the
IPv4 and IPv6 header translation performed in both directions by the IPv4 and IPv6 header translation performed in both directions by the
AFXLBR is stateless. AFXLBR is stateless.
1.4. OSPFv3 Routing with a Specific Topology 1.4. OSPFv3 Routing with a Specific Topology
In general, IPv4-embedded IPv6 packets can be forwarded just like In general, IPv4-embedded IPv6 packets can be forwarded just like
native IPv6 packets with OSPFv3 running in the IPv6 network. native IPv6 packets with OSPFv3 running in the IPv6 network.
However, this would require IPv4-embedded IPv6 routes be flooded However, this would require that IPv4-embedded IPv6 routes be flooded
throughout the entire IPv6 network and stored on every router. This throughout the entire IPv6 network and stored on every router. This
is not desirable from the scaling perspective. Moreover, since all is not desirable from a scaling perspective. Moreover, since all
IPv6 routes are stored in the same routing table, it would be IPv6 routes are stored in the same routing table, it would be
inconvenient to manage the resource required for routing and inconvenient to manage the resource required for routing and
forwarding based on traffic category, if so desired. forwarding based on traffic category, if so desired.
To improve the situation, a separate OSPFv3 routing table can be To improve the situation, a separate OSPFv3 routing table dedicated
constructed that is dedicated to the IPv4-embedded IPv6 topology, and to the IPv4-embedded IPv6 topology can be constructed; that table
that table is solely used for routing IPv4-embedded IPv6 packets in would be solely used for routing IPv4-embedded IPv6 packets in the
the IPv6 network. The IPv4-embedded IPv6 topology includes all the IPv6 network. The IPv4-embedded IPv6 topology includes all the
participating AFXLBR routers and a set of P Routers providing participating AFXLBRs and a set of P Routers providing redundant
redundant connectivity with alternate routing paths. connectivity with alternate routing paths.
To realize this, a separate OSPFv3 instance is configured in the IPv6 To realize this, a separate OSPFv3 instance is configured in the IPv6
network according to [RFC5838]. This instance operates on all network [RFC5838]. This instance operates on all participating
participating AFXLBR and a set of P routers that inter-connecting AFXLBRs and a set of P routers that interconnect them. As a result,
them. As a result, there would be a dedicated IPv4-embedded IPv6 there would be a dedicated IPv4-embedded IPv6 topology that is
topology that is maintained on all these routers along with a maintained on all these routers, along with a dedicated IPv4-embedded
dedicated IPv4-embedded IPv6 routing table. This routing table in IPv6 routing table. This routing table in the IPv6 network is solely
the IPv6 network is solely for forwarding IPv4-embedded IPv6 packets. for forwarding IPv4-embedded IPv6 packets.
This document elaborates on how configuration is done with this This document elaborates on how configuration is done with this
method and related routing issues. method and on related routing issues.
This document only focuses on unicast routing for IPv4-embedded IPv6 This document only focuses on unicast routing for IPv4-embedded IPv6
packets using OSPFv3. packets using OSPFv3.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Provisioning 3. Provisioning
3.1. Deciding the IPv4-embedded IPv6 Topology 3.1. Deciding on the IPv4-Embedded IPv6 Topology
Before deploying configurations that use a separate OSPFv3 routing Before deploying configurations that use a separate OSPFv3 routing
table for IPv4-embedded IPv6 addresses and prefixes, a decision must table for IPv4-embedded IPv6 addresses and prefixes, a decision must
be made on the set of routers and their interfaces in the IPv6 be made regarding the set of routers and their interfaces in the IPv6
network that should be part of the IPv4-embedded IPv6 topology. network that should be part of the IPv4-embedded IPv6 topology.
For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that
connect to IPv4 client networks MUST be members of this topology. An 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 AFXLBR MUST have at least one connection with a P Router in the IPv6
network or another AFXLBR. network or another AFXLBR.
The IPv4-embedded IPv6 topology is a sub-topology of the entire IPv6 The IPv4-embedded IPv6 topology is a subtopology of the entire IPv6
network, and if all routers (including AFXLBRs and P routers) and all network, and if all routers (including AFXLBRs and P routers) and all
their interfaces are included, the two topologies converge. their interfaces are included, the two topologies converge.
Generally speaking, when this sub-topology contains more inter- Generally speaking, when this subtopology contains more
connected P Routers, there would be more routing paths across the interconnected P Routers, there would be more routing paths across
IPv6 network from one IPv4 client network to the other; however, this the IPv6 network from one IPv4 client network to the other; however,
requires more routers in the IPv6 network to participate in this requires more routers in the IPv6 network to participate in
IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6 IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6
topology MUST be continuous with no partitions. topology MUST be continuous with no partitions.
3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table
In an IPv6 network, in order to maintain a separate IPv6 routing In an IPv6 network, in order to maintain a separate IPv6 routing
table that contains routes for IPv4-embedded IPv6 destinations only, table that contains routes for IPv4-embedded IPv6 destinations only,
OSPFv3 needs to use the mechanism defined in [RFC5838]. OSPFv3 needs to use the mechanism defined in [RFC5838].
It is assumed that the IPv6 network that is inter-connected with IPv4 It is assumed that the IPv6 network that is interconnected with IPv4
networks in this document is under one administration and as such, an networks as described in this document is under one administration,
OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3 and as such an OSPFv3 Instance ID (IID) is allocated locally and used
operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6 for OSPFv3 operation dedicated to unicast IPv4-embedded IPv6 routing
network. This IID is configured on OSPFv3 router interfaces that in an IPv6 network. This IID is configured on OSPFv3 router
participate in the IPv4-embedded IPv6 topology. interfaces that participate in the IPv4-embedded IPv6 topology.
The range for a locally configured OSPFv3 IID is allocated from 192 A locally configured OSPFv3 IID is allocated in the range 192 to 255,
to 255, inclusive, as "Private Use" per inclusive, in the "OSPFv3 Instance ID Address Family Values"
[I-D.ietf-ospf-ospfv3-iid-registry-update]. This IID must be used to registry; this range is reserved for "Private Use" [RFC6969]. This
encode the "Instance ID" field in the packet header of OSPFv3 packets IID must be used to encode the "Instance ID" field in the packet
associated with the OSPFv3 instance. header of OSPFv3 packets associated with the OSPFv3 instance.
In addition, the "AF" bit in the OSPFv3 Option field MUST be set. In addition, the AF-bit in the OSPFv3 Option field MUST be set.
During Hello packet processing, an adjacency may only be established During Hello packet processing, an adjacency may only be established
when the received Hello packet contains the same Instance ID as when the received Hello packet contains the same Instance ID as the
configured on the receiving OSPFv3 interface. This insures that only Instance ID configured on the receiving OSPFv3 interface. This
interfaces configured as part of the OSPFv3 unicast IPv4-embedded insures that only interfaces configured as part of the OSPFv3 unicast
IPv6 topology are used for IPv4-embedded IPv6 unicast routing. IPv4-embedded IPv6 topology are used for IPv4-embedded IPv6 unicast
routing.
For more details, the reader is referred to [RFC5838]. For more details, the reader is referred to [RFC5838].
4. IP Packets Translation 4. Translation of IP Packets
When transporting IPv4 packets across an IPv6 network with the When transporting IPv4 packets across an IPv6 network via the
mechanism described above (Section 3.2), an IPv4 packet is translated mechanism described above (Section 3.2), an IPv4 packet is translated
to an IPv6 packet at the ingress AFXLBR, and the IPv6 packet is to an IPv6 packet at the ingress AFXLBR, and the IPv6 packet is
translated back to an IPv4 packet at the egress AFXLBR. The IP translated back to an IPv4 packet at the egress AFXLBR. IP packet
packet header translation is accomplished in stateless manner header translation is accomplished in a stateless manner according to
according to rules specified in [RFC6145], with the address rules specified in [RFC6145]; the details of address translation are
translation details explained in the next sub-section. explained in the next subsection.
4.1. Address Translation 4.1. Address Translation
Prior to address translation, an IPv6 prefix is allocated by the Prior to address translation, an IPv6 prefix is allocated by the
operator and it is used to form IPv4-embedded IPv6 addresses. operator, and it is used to form IPv4-embedded IPv6 addresses.
The IPv6 prefix can either be the well-known IPv6 prefix (WKP) The IPv6 prefix can either be the IPv6 well-known prefix (WKP) 64:
64:ff9b::/96, or a network-specific prefix that is unique to the ff9b::/96 or a network-specific prefix that is unique to the
organization; and for the latter case, the IPv6 prefix length may be organization; for the latter case, the IPv6 prefix length may be 32,
32, 40, 48, 56 or 64. In either case, this IPv6 prefix is used 40, 48, 56, or 64. In either case, this IPv6 prefix is used during
during the address translation between an IPv4 address and an the address translation between an IPv4 address and an IPv4-embedded
IPv4-embedded IPv6 address, as described in [RFC6052]. IPv6 address, as described in [RFC6052].
During translation from an IPv4 header to an IPv6 header at an During translation from an IPv4 header to an IPv6 header at an
ingress AFXLBR, the source IPv4 address and destination IPv4 address ingress AFXLBR, the source IPv4 address and destination IPv4 address
are translated into the corresponding IPv6 source address and are translated into the corresponding source IPv6 address and
destination IPv6 address, respectively, and during translation from destination IPv6 address, respectively. During translation from an
an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6
address and destination IPv6 address are translated into the address and destination IPv6 address are translated into the
corresponding IPv4 source address and destination IPv4 address, corresponding source IPv4 address and destination IPv4 address,
respectively. Note that the address translation is accomplished in a respectively. Note that address translation is accomplished in a
stateless manner. stateless manner.
When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only When an IPv6 WKP is used, [RFC6052] allows only global IPv4 addresses
global IPv4 addresses to be embedded in the IPv6 address. An IPv6 to be embedded in the IPv6 address. An IPv6 address composed of a
address composed with a WKP and a non-global IPv4 address is hence WKP and a non-global IPv4 address is hence invalid, and packets that
invalid, and packets that contain such address received by an AFXLBR contain such an address received by an AFXLBR are dropped.
are dropped.
In the case where both the IPv4 client networks and the IPv6 transit In the case where both the IPv4 client networks and the IPv6 transit
network belong to the same organization, non-global IPv4 addresses network belong to the same organization, non-global IPv4 addresses
may be used with a network-specific prefix [RFC6052]. may be used with a network-specific prefix [RFC6052].
5. Advertising IPv4-embedded IPv6 Routes 5. Advertising IPv4-Embedded IPv6 Routes
In order to forward IPv4 packets to the proper destination across an In order to forward IPv4 packets to the proper destination across an
IPv6 network, IPv4 reachability needs to be disseminated throughout IPv6 network, IPv4 reachability information needs to be disseminated
the IPv6 network and this is performed by AFXLBRs that connect to throughout the IPv6 network. This is performed by AFXLBRs that
IPv4 client networks using OSPFv3. connect to IPv4 client networks using OSPFv3.
With the scenario described in this document, i.e., a set of AFXLBRs With the scenario described in this document, i.e., a set of AFXLBRs
that inter-connect a bunch of IPv4 client networks with an IPv6 that interconnect multiple IPv4 client networks with an IPv6 network,
network, the IPv4 networks and IPv6 networks belong to the same or the IPv4 networks and IPv6 networks belong to the same or separate
separate Autonomous Systems, and as such, these AFXLBRs behave as AS Autonomous Systems (ASs), and as such, these AFXLBRs behave as AS
Boundary Routers (ASBRs). Boundary Routers (ASBRs).
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit 5.1. Advertising IPv4-Embedded IPv6 Routes through an IPv6 Transit
Network Network
IPv4 addresses and prefixes in an IPv4 client network are translated IPv4 addresses and prefixes in an IPv4 client network are translated
into IPv4-embedded IPv6 addresses and prefixes, respectively, using into IPv4-embedded IPv6 addresses and prefixes, respectively, using
the IPv6 prefix allocated by the operator and the method specified in the IPv6 prefix allocated by the operator and the method specified in
[RFC6052]. These routes are then advertised by one or more attached [RFC6052]. These routes are then advertised by one or more attached
ASBRs into the IPv6 transit network using AS-External-LSAs [RFC5340], ASBRs into the IPv6 transit network using AS-External-LSAs [RFC5340],
i.e., with advertising scope comprising the entire Autonomous System. i.e., with advertising scope comprising the entire Autonomous System.
5.1.1. Routing Metrics 5.1.1. Routing Metrics
By default, the metric in an AS-External-LSA that carries an By default, the metric in an AS-External-LSA that carries an IPv4-
IPv4-embedded IPv6 address or prefixes is a Type 1 external metric, embedded IPv6 address or prefixes is a Type 1 external metric, which
which is comparable to the link state metric and we assume that in is comparable to the link state metric, and we assume that in most
most cases, OSPFv2 is used in client IPv4 networks. This metric is cases OSPFv2 is used in client IPv4 networks. This metric is added
added to the metric of the intra-AS path to the ASBR during the to the metric of the intra-AS path to the ASBR during the OSPFv3
OSPFv3 route calculation. Through ASBR configuration, the metric can route calculation. Through ASBR configuration, the metric can be set
be set to a Type 2 external metric, which is considered much larger to a Type 2 external metric, which is considered much larger than the
than the metric for any intra-AS path. Refer to the OSPFv3 metric for any intra-AS path. Refer to the OSPFv3 specification
specification [RFC5340] for more detail. In either case, an external [RFC5340] for more details. In either case, an external metric may
metric may take the same value as in an IPv4 network (using OSPFv2 or take the same value as in an IPv4 network (using OSPFv2 or another
another routing protocol), but may also be specified based on some routing protocol) but may also be specified based on some routing
routing policy; the details of which are outside of the scope of this policy, the details of which are beyond the scope of this document.
document.
5.1.2. Forwarding Address 5.1.2. Forwarding Address
If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is 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 used to carry an IPv6 address, that address must also be an
IPv6 address where the embedded IPv4 address is the destination IPv4-embedded IPv6 address where the embedded IPv4 address is the
address in an IPv4 client network. However, since an AFXLBR sits on destination address in an IPv4 client network. However, since an
the border of an IPv4 network and an IPv6 network, it is RECOMMENDED AFXLBR sits on the border of an IPv4 network and an IPv6 network, it
that the "Forwarding Address" field is not used, so that the AFXLBR is RECOMMENDED that the "Forwarding Address" field not be used, so
can make the forwarding decision based on its own IPv4 routing table. that the AFXLBR can make the forwarding decision based on its own
IPv4 routing table.
5.2. Advertising IPv4 Addresses into Client Networks 5.2. Advertising IPv4 Addresses into Client Networks
IPv4-embedded IPv6 routes injected into the IPv6 network from one IPv4-embedded IPv6 routes injected into the IPv6 network from one
IPv4 client network MAY be advertised into another IPv4 client IPv4 client network MAY be advertised into another IPv4 client
network, after the associated destination addresses and prefixes are network after the associated destination addresses and prefixes are
translated back to IPv4 addresses and prefixes, respectively. This translated back to IPv4 addresses and prefixes, respectively. This
operation is similar to normal OSPFv3 operation, wherein an AS- operation is similar to normal OSPFv3 operation, wherein an
External-LSA can be advertised in a non-backbone area by default. AS-External-LSA can be advertised in a non-backbone area by default.
An IPv4 client network can limit which advertisements it receives An IPv4 client network can limit which advertisements it receives
through configuration. through configuration.
For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT
be advertised into any IPv6 client networks that also connected to be advertised into any IPv6 client networks that are also connected
the IPv6 transit network. to the IPv6 transit network.
6. Aggregation on IPv4 Addresses and Prefixes 6. Aggregation on IPv4 Addresses and Prefixes
In order to reduce the amount of LSAs that are injected to the IPv6 In order to reduce the amount of Link State Advertisements (LSAs)
network, an implementation should provide mechanisms to aggregate that are injected into the IPv6 network, an implementation should
IPv4 addresses and prefixes at AFXLBR prior to advertisement as provide mechanisms to aggregate IPv4 addresses and prefixes at an
IPv4-embedded IPv6 addresses and prefixes. In general, the AFXLBR prior to advertisement as IPv4-embedded IPv6 addresses and
aggregation practice should be based on routing policy, which is prefixes. In general, the aggregation practice should be based on
outside of the scope of this document. routing policy, which is beyond the scope of this document.
7. Forwarding 7. Forwarding
There are three cases in forwarding IP packets in the scenario There are three cases applicable to forwarding IP packets in the
described in this document: scenario described in this document:
1. On an AFXLBR, if an IPv4 packet that is received on an interface 1. On an AFXLBR, if an IPv4 packet is received on an interface
connecting to an IPv4 segregated client network with a connecting to an IPv4 segregated client network with a
destination IPv4 address belonging to another IPv4 client destination IPv4 address belonging to another IPv4 client
network, the header of the packet is translated to the network, the header of the packet is translated to the
corresponding IPv6 header as described in Section 4, and the corresponding IPv6 header as described in Section 4, and the
packet is then forwarded to the destination AFXLBR that packet is then forwarded to the destination AFXLBR that
advertised the IPv4-embedded IPv6 address into the IPv6 network. advertised the IPv4-embedded IPv6 address into the IPv6 network.
2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the
embedded destination IPv4 address is in its IPv4 routing table, embedded destination IPv4 address is in its IPv4 routing table,
the header of the packet is translated to the corresponding IPv4 the header of the packet is translated to the corresponding IPv4
header as described in Section 4, and the packet is then header as described in Section 4, and the packet is then
forwarded accordingly. forwarded accordingly.
3. On any router that is within the IPv4-embedded IPv6 topology 3. On any router that is within the IPv4-embedded IPv6 topology
subset of the IPv6 network, if an IPv4-embedded IPv6 packet is subset of the IPv6 network, if an IPv4-embedded IPv6 packet is
received and a route is found in the IPv4-embedded IPv6 routing 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 table, the packet is forwarded to the IPv6 next hop, just like
handling for a normal IPv6 packet, without any translation. the handling for a normal IPv6 packet, without any translation.
The classification of IPv4-embedded IPv6 packet is according to the The classification of an IPv4-embedded IPv6 packet is done according
IPv6 prefix of the destination address, which is either the Well to the IPv6 prefix of the destination address, which is either the
Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in WKP (i.e., 64:ff9b::/96) or locally allocated as defined in
[RFC6052]. [RFC6052].
8. Backdoor Connections 8. Backdoor Connections
In some deployments, IPv4 client networks are inter-connected across In some deployments, IPv4 client networks are interconnected across
the IPv6 network, but also directly connected to each other. The the IPv6 network but are also directly connected to each other. The
direct connections between IPv4 client networks, as sometimes called direct connections between IPv4 client networks, sometimes called
"backdoor" connections, can certainly be used to transport IPv4 "backdoor" connections, can certainly be used to transport IPv4
packets between IPv4 client networks. In general, backdoor packets between IPv4 client networks. In general, backdoor
connections are preferred over the IPv6 network since there requires connections are preferred over the IPv6 network, since no address
no address family translation. family translation is required.
9. Prevention of Loops 9. Prevention of Loops
If an LSA sent from an AFXLBR into a client network could then be 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 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 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 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 ignore any LSA received from a client network that already has the DN
DN-bit sent. bit set.
10. MTU Issues 10. MTU Issues
In the IPv6 network, there are no new MTU issues introduced by this In the IPv6 network, there are no new MTU issues introduced by this
document. If a separate OSPFv3 instance (per [RFC5838]) is used for document. If a separate OSPFv3 instance (per [RFC5838]) is used for
IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is
the same as that of the default OSPFv3 instance. the same as that of the default OSPFv3 instance.
However, the MTU in the IPv6 network may be different than that of However, the MTU in the IPv6 network may be different than that of
IPv4 client networks. Since an IPv6 router will never fragment a IPv4 client networks. Since an IPv6 router will never fragment a
packet, the packet size of any IPv4-embedded IPv6 packet entering the 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 IPv6 network must be equal to or less than the MTU of the IPv6
network. In order to achieve this requirement, it is recommended network. In order to achieve this requirement, it is recommended
that AFXLBRs perform IPv6 path discovery among themselves and the that AFXLBRs perform IPv6 path discovery among themselves. The
resulting MTU, after taking into account of the difference between resulting MTU, after taking into account the difference between the
the IPv4 header length and the IPv6 header length, must be IPv4 header length and the IPv6 header length, must be "propagated"
"propagated" into IPv4 client networks, e.g., included in the OSPFv2 into IPv4 client networks, e.g., included in the OSPFv2 Database
Database Description packet. Description packet.
The details of passing the proper MTU into IPv4 client networks are The details of passing the proper MTU into IPv4 client networks are
beyond the scope of this document. beyond the scope of this document.
11. Security Considerations 11. Security Considerations
There are several security aspects that require attention in the There are several security aspects that require attention in the
deployment practice described in this document. deployment practices described in this document.
In the OSPFv3 transit network, the security considerations for OSPFv3 In the OSPFv3 transit network, the security considerations for OSPFv3
are handled as usual, and in particular, authentication mechanisms are handled as usual, and in particular, authentication mechanisms
described in [RFC6506] can be deployed. described in [RFC6506] can be deployed.
When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 When a separate OSPFv3 instance is used to support IPv4-embedded IPv6
routing, the same Security Association (SA) (refer to [RFC4552] ) routing, the same Security Association (SA) [RFC4552] MUST be used by
MUST be used by the embedded IPv4 address instance as other instances the embedded IPv4 address instance as other instances utilizing the
utilizing the same link as specified in [RFC5838]. same link, as specified in [RFC5838].
Security considerations as documented in [RFC6052] must also be Security considerations as documented in [RFC6052] must also be
thought through with proper implementation including the following: thought through and properly implemented, including the following:
o The IPv6 prefix that is used to carry an embedded IPv4 address o The IPv6 prefix that is used to carry an embedded IPv4 address
(refer to Section 4.1) must be configured by the authorized (refer to Section 4.1) must be configured by the authorized
operator on all participating AFXLBRs in a secure manner. This is operator on all participating AFXLBRs in a secure manner. This is
to help prevent an malicious attack resulting in network to help prevent a malicious attack resulting in network
disruption, denial of service, and possible information disruption, denial of service, and possible information
disclosure. disclosure.
o Effective mechanisms (such as reverse path checking) must be o Effective mechanisms (such as reverse path checking) must be
implemented in the IPv6 transit network (including AFXLIBR nodes) implemented in the IPv6 transit network (including AFXLBRs) to
to prevent spoofing on embedded IPv4 addresses, which, otherwise, prevent spoofing of embedded IPv4 addresses, which otherwise might
might be used as source addresses of malicious packets. be used as source addresses of malicious packets.
o If firewalls are used in IPv4 and/or IPv6 networks, the o If firewalls are used in IPv4 and/or IPv6 networks, configuration
configuration on the routers must be consistent so there are no of the routers must be consistent, so that there are no holes in
holes in the IPv4 address filtering. IPv4 address filtering.
The details of security handling are beyond the scope of this The details of security handling are beyond the scope of this
document. document.
12. Operational Considerations 12. Operational Considerations
This document puts together some mechanisms based on existing This document puts together some mechanisms based on existing
technologies developed by IETF as an integrated solution to transport technologies developed by the IETF as an integrated solution to
IPv4 packets over an IPv6 network using a separate OSPFv3 routing transport IPv4 packets over an IPv6 network using a separate OSPFv3
table. There are several aspects that require attention for the routing table. There are several aspects of these mechanisms that
deployment and operation. require attention for deployment and operation.
The tunnel-based solution documented in [RFC5565] and the solution The tunnel-based solution documented in [RFC5565] and the solution
proposed in this document are both used for transporting IPv4 packets proposed in this document are both used for transporting IPv4 packets
over an IPv6 network, with different mechanisms. The two methods are over an IPv6 network, using different mechanisms. The two methods
not related to each other, and they can co-exist in the same network are not related to each other, and they can coexist in the same
if so deployed, without any conflict. network if so deployed, without any conflict.
If one approach is to be deployed, it is the operator's decision for If one approach is to be deployed, the operator will decide which
the choice. Note that each approach has its own characteristics and approach to use. Note that each approach has its own characteristics
requirements. E.g., the tunnel-based solution requires a mesh of and requirements. For example, the tunnel-based solution requires a
inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as mesh of inter-AFBR softwires (tunnels) spanning the IPv6 network, as
iBGP to exchange routes between AFBRs ([RFC5565]); the approach in well as IBGP to exchange routes between AFBRs [RFC5565]; the approach
this document requires AFXLBR capable of performing IPv4-IPv6 packet in this document requires AFXLBRs that are capable of performing
header translation per [RFC6145]. IPv4-IPv6 packet header translation per [RFC6145].
To deploy the solution as documented here, there requires some To deploy the solution as documented here, some configurations are
configurations. An IPv6 prefix must first be chosen that is used to required. An IPv6 prefix must first be chosen that is used to form
form all the IPv4-embedded IPv6 addresses and prefixes advertised by all the IPv4-embedded IPv6 addresses and prefixes advertised by
AFXLBR in the IPv6 network; the detail is referred to Section 4.1. AFXLBRs in the IPv6 network; refer to Section 4.1 for details. The
The IPv4-embedded IPv6 routing table is created by using a separate IPv4-embedded IPv6 routing table is created by using a separate
OSPFv3 instance in the IPv6 network, the configuration is OSPFv3 instance in the IPv6 network. As described in Section 3.2,
accomplished according to [RFC5838], as described in Section 3.2. this configuration is accomplished according to the mechanism
described in [RFC5838].
Note this document does not change any behavior of OSPFv3, and the Note that this document does not change any behavior of OSPFv3, and
existing or common practice should apply, in the context of the existing or common practice should apply in the context of
scalability. For example, the amount of routes that are advertised scalability. For example, the amount of routes that are advertised
by OSPFv3 is one key concern. With the solution as described in this by OSPFv3 is one key concern. With the solution as described in this
document, IPv4-embedded IPv6 addresses and prefixes will be injected document, IPv4-embedded IPv6 addresses and prefixes will be injected
by AFXLBR into some part of the IPv6 network (see Section 3.1 for 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 details), and a separate routing table will be used for IPv4-embedded
IPv6 routing. Care must be taken during the network design, such IPv6 routing. Care must be taken during network design such that 1)
that 1) aggregation are performed on IPv4 addresses and prefixes aggregations are performed on IPv4 addresses and prefixes before
before being advertised in the IPv6 network as described in being advertised in the IPv6 network as described in Section 6, and
Section 6, and 2) estimates are made as the amount of IPv4-embedded 2) estimates are made as to the amount of IPv4-embedded IPv6 routes
IPv6 routes that would be disseminated in the IPv6 network, and the that would be disseminated in the IPv6 network and to the size of the
size of the separate OSPFv3 routing table. separate OSPFv3 routing table.
13. IANA Considerations
No new IANA assignments are required for this document.
14. Acknowledgements 13. Acknowledgements
Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand, and
Brian Carpenter for their comments. Brian Carpenter for their comments.
15. References 14. References
15.1. Normative References
[I-D.ietf-ospf-ospfv3-iid-registry-update] 14.1. Normative References
Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry
Update", draft-ietf-ospf-ospfv3-iid-registry-update-04
(work in progress), April 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
Link State Advertisement (LSA) Options Bit to Prevent Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 4576, June 2006. RFC 4576, June 2006.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009. Framework", RFC 5565, June 2009.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3", RFC Aggarwal, "Support of Address Families in OSPFv3",
5838, April 2010. RFC 5838, April 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
15.2. Informative References [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 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006. for OSPFv3", RFC 4552, June 2006.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506, February Authentication Trailer for OSPFv3", RFC 6506,
2012. February 2012.
Authors' Addresses Authors' Addresses
Dean Cheng Dean Cheng
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, California 95050 Santa Clara, California 95050
USA USA
Email: dean.cheng@huawei.com EMail: dean.cheng@huawei.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes 35000 Rennes, 35000
France France
Email: mohamed.boucadair@orange.com EMail: mohamed.boucadair@orange.com
Alvaro Retana Alvaro Retana
Cisco Systems Cisco Systems
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709 Research Triangle Park, North Carolina 27709
USA USA
Email: aretana@cisco.com EMail: aretana@cisco.com
 End of changes. 88 change blocks. 
345 lines changed or deleted 337 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/