draft-ietf-ospf-ipv4-embedded-ipv6-routing-11.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-12.txt 
Network Working Group D. Cheng Network Working Group D. Cheng
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational M. Boucadair Intended status: Informational M. Boucadair
Expires: October 19, 2013 France Telecom Expires: November 25, 2013 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
April 17, 2013 May 24, 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-11 draft-ietf-ospf-ipv4-embedded-ipv6-routing-12
Abstract Abstract
This document describes routing packets destined to IPv4-embedded This document describes a routing scenario where IPv4 packets are
IPv6 addresses across an IPv6 core using OSPFv3 with a separate transported over an IPv6 network, based on RFCs 6145 and 6052, along
routing table. with a separate OSPFv3 routing table for 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2013. This Internet-Draft will expire on November 25, 2013.
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
skipping to change at page 2, line 29 skipping to change at page 2, line 21
1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . 4 1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 7 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7
3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . 7 3.1. Deciding 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
3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7
3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8
4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8
4.1. Address Translation . . . . . . . . . . . . . . . . . . . 9 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8
5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 9 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 IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 10 Transit Network . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10
5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 10 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 10
5.2. Advertising IPv4 Addresses into Client Networks . . . . . 10 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 10
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 11 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 11
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 12 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 11
9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12
10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Operational Considerations . . . . . . . . . . . . . . . . . 13 12. Operational Considerations . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 15 15.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 which
contains an embedded 32-bit IPv4 address constructed according to contains an embedded 32-bit IPv4 address constructed according to
skipping to change at page 3, line 46 skipping to change at page 3, line 39
IPv4 and IPv6 technologies respectively, will co-exist at least for IPv4 and IPv6 technologies respectively, will co-exist at least for
some time. One scenario of this co-existence is the inter-connection some time. One scenario of this co-existence is the inter-connection
of IPv4-only and IPv6-only networks, and in particular, when an of IPv4-only and IPv6-only networks, and in particular, when an
IPv6-only network serves as inter-connection between several IPv6-only network serves as inter-connection between several
segregated IPv4-only networks. In this scenario, IPv4 packets are segregated IPv4-only networks. In this scenario, IPv4 packets are
transported over the IPv6 network between IPv4 networks. In order to transported over the IPv6 network between IPv4 networks. In order to
forward an IPv4 packet from a source IPv4 network to the destination forward an IPv4 packet from a source IPv4 network to the destination
IPv4 network, IPv4 reachability information must be exchanged between IPv4 network, IPv4 reachability information must be exchanged between
the IPv4 networks by some mechanism. the IPv4 networks by some mechanism.
In general, running an IPv6-only network would reduce OPEX and In general, running an IPv6-only network would reduce operational
optimize the operation compared to IPv4-IPv6 dual-stack environment. expenditure and optimize the operation compared to IPv4-IPv6 dual-
Some solutions have been proposed to allow delivery of IPv4 services stack environment. Some solutions have been proposed to allow
over an IPv6-only network. This document focuses on an engineering delivery of IPv4 services over an IPv6-only network. This document
technique which aims to separate the routing table dedicated to specifies an engineering technique that separates the routing table
IPv4-embedded IPv6 destinations from native IPv6 ones. dedicated to IPv4-embedded IPv6 destinations from the routing table
used for native IPv6 destinations.
Maintaining a separate routing table for IPv4-embedded IPv6 routes OSPFv3 is designed to support multiple instances or multiple
optimizes IPv4 packets forwarding. It also prevents overload of the topologies. Maintaining a separate routing table for IPv4-embedded
native IPv6 routing tables. A separate routing table can be IPv6 routes would simplify the implementation, trouble shooting and
generated from a separate routing instance or a separate routing operation; it also prevents overload of the native IPv6 routing
topology. tables. A separate routing table can be generated from a separate
routing instance or a separate routing topology.
1.2. Routing Solution per RFC5565 1.2. Routing Solution per RFC5565
The aforementioned scenario is described in [RFC5565], i.e., IPv4 The aforementioned scenario is described in [RFC5565], i.e., IPv4
-over-IPv6 scenario, where the network core is IPv6-only, and the -over-IPv6 scenario, where the network core is IPv6-only, and the
inter-connected IPv4 networks are called IPv4 client networks. The P inter-connected IPv4 networks are called IPv4 client networks. The
Routers in the core only support IPv6 but the AFBRs (Address Family P(rovider) Routers in the core only support IPv6 but the AFBRs
Border Routers) support IPv4 on interfaces facing IPv4 client (Address Family Border Routers) support IPv4 on interfaces facing
networks, and IPv6 on interfaces facing the core. The routing IPv4 client networks, and IPv6 on interfaces facing the core. The
solution defined in [RFC5565] for this scenario is to run i-BGP among routing solution defined in [RFC5565] for this scenario is to run
AFBRs to exchange IPv4 routing information in the core, and the IPv4 i-BGP among AFBRs to exchange IPv4 routing information in the core,
packets are forwarded from one IPv4 client network to the other and the IPv4 packets are forwarded from one IPv4 client network to
through a softwire using tunneling technology such as MPLS LSP, GRE, the other through a softwire using tunneling technology such as MPLS
L2TPv3, etc. LSP, GRE, 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 inter-connected by an IPv6
network. The IPv6 network and the inter-connected IPv4 networks may network. The IPv6 network and the inter-connected 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. We refer to the
border node on the boundary of an IPv4 client network and the IPv6 border node on the boundary of an IPv4 client network and the IPv6
network as an Address Family Translation Border Router (AFXLBR), network as an Address Family Translation Border Router (AFXLBR),
skipping to change at page 6, line 31 skipping to change at page 6, line 25
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 the 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 can be
constructed that is dedicated to the IPv4-embedded IPv6 topology, and constructed that is dedicated to the IPv4-embedded IPv6 topology, and
that table is solely used for routing IPv4-embedded IPv6 packets in that table is solely used for routing IPv4-embedded IPv6 packets in
the IPv6 network. The IPv4-embedded IPv6 topology includes all the the IPv6 network. The IPv4-embedded IPv6 topology includes all the
participating AFXLBR routers and a set of P(rovider) Routers participating AFXLBR routers and a set of P Routers providing
providing redundant connectivity with alternate routing paths. redundant connectivity with alternate routing paths.
There are two methods to build a separate OSPFv3 routing table for There are two methods to build a separate OSPFv3 routing table for
IPv4-embedded IPv6 routes: IPv4-embedded IPv6 routes:
o The first one is to run a separate OSPFv3 instance for o The first one is to run a separate OSPFv3 instance for
IPv4-embedded IPv6 topology in the IPv6 network according to IPv4-embedded IPv6 topology in the IPv6 network according to
[RFC5838]. [RFC5838].
o The second one is to stay with the existing OSPFv3 instance that o The second one is to stay with the existing OSPFv3 instance that
already operates in the IPv6 network, but maintain a separate already operates in the IPv6 network, but maintain a separate
skipping to change at page 7, line 33 skipping to change at page 7, line 26
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 on 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 sub-topology 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 sub-topology contains more inter-
connected P Routers, there would be more routing paths across the connected P Routers, there would be more routing paths across the
IPv6 network from one IPv4 client network to the other; however, this IPv6 network from one IPv4 client network to the other; however, this
requires more routers in the IPv6 network to participate in 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
skipping to change at page 8, line 49 skipping to change at page 8, line 43
[I-D.ietf-ospf-mt-ospfv3]. [I-D.ietf-ospf-mt-ospfv3].
In addition, the MT bit in the OSPFv3 Option field MUST be set. In addition, the MT bit in the OSPFv3 Option field MUST be set.
For more details, the reader is referred to For more details, the reader is referred to
[I-D.ietf-ospf-mt-ospfv3]. [I-D.ietf-ospf-mt-ospfv3].
4. IP Packets Translation 4. IP Packets Translation
When transporting IPv4 packets across an IPv6 network with the When transporting IPv4 packets across an IPv6 network with the
mechanism described above, an IPv4 packet is translated to an IPv6 mechanism described above (Section 3.3 and Section 3.4), an IPv4
packet at the ingress AFXLBR, and the IPv6 packet is translated back packet is translated to an IPv6 packet at the ingress AFXLBR, and the
to an IPv4 packet at the egress AFXLBR. The IP packet header IPv6 packet is translated back to an IPv4 packet at the egress
translation is accomplished in stateless manner according to rules AFXLBR. The IP packet header translation is accomplished in
specified in [RFC6145], with the address translation details stateless manner according to rules specified in [RFC6145], with the
explained in the next sub-section. address translation details explained in the next sub-section.
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 well-known IPv6 prefix (WKP)
64:ff9b::/96, or a network-specific prefix that is unique to the 64:ff9b::/96, or a network-specific prefix that is unique to the
organzation; and for the latter case, the IPv6 prefix length may be organzation; and for the latter case, the IPv6 prefix length may be
32, 40, 48, 56 or 64. In either case, this IPv6 prefix is used 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is used
during the address translation between an IPv4 address and an during the address translation between an IPv4 address and an
IPv4-embedded IPv6 address, as described in [RFC6052]. IPv4-embedded IPv6 address, as described in [RFC6052].
skipping to change at page 11, line 24 skipping to change at page 11, line 20
IPv4-embedded IPv6 addresses and prefixes. In general, the IPv4-embedded IPv6 addresses and prefixes. In general, the
aggregation practice should be based on routing policy, which is aggregation practice should be based on routing policy, which is
outside of the scope of this document. outside of the scope of this document.
7. Forwarding 7. Forwarding
There are three cases in forwarding IP packets in the scenario There are three cases in forwarding IP packets in the scenario
described in this document: 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 that is received on an interface
connecting to an IPv4 client network with a destination IPv4 connecting to an IPv4 segregated client network with a
address belonging to another IPv4 client network, the header of destination IPv4 address belonging to another IPv4 client
the packet is translated to the corresponding IPv6 header as network, the header of the packet is translated to the
described in Section 4, and the packet is then forwarded to the corresponding IPv6 header as described in Section 4, and the
destination AFXLBR that advertised the IPv4-embedded IPv6 address packet is then forwarded to the destination AFXLBR that
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
skipping to change at page 13, line 11 skipping to change at page 12, line 44
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 practice 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 covered in [RFC5340], and in particular, IPsec can be used for are handled as usual, and in particular, authentication mechanisms
OSPFv3 authentication and confidentiality as suggested in [RFC5838]. 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) (refer to [RFC4552] )
must be used by the embedded IPv4 address instance as other instances MUST be used by the embedded IPv4 address instance as other instances
utilizing the same link as specified in [RFC5838]. utilizing the same link as specified in [RFC5838].
Security considerations as currently documented in [RFC6052] must Security considerations as documented in [RFC6052] must also be
also be thought through with proper implementation including the thought through with proper implementation including the following:
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 an 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 AFXLIBR nodes)
skipping to change at page 14, line 19 skipping to change at page 14, line 4
requirements. E.g., the tunnel-based solution requries a mesh of requirements. E.g., the tunnel-based solution requries a mesh of
inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as
iBGP to exchange routes between AFBRs ([RFC5565]); the approach in iBGP to exchange routes between AFBRs ([RFC5565]); the approach in
this document requires AFXLBR capable of perfoming IPv4-IPv6 packet this document requires AFXLBR capable of perfoming IPv4-IPv6 packet
header translation per [RFC6145]. header translation per [RFC6145].
To deploy the solution as documented here, there requires some To deploy the solution as documented here, there requires some
configurations. An IPv6 prefix must first be chosen that is used to configurations. An IPv6 prefix must first be chosen that is used to
form all the IPv4-embedded IPv6 addresses and prefixes advertised by form all the IPv4-embedded IPv6 addresses and prefixes advertised by
AFXLBR in the IPv6 network; the detail is referred to Section 4.1. AFXLBR in the IPv6 network; the detail is referred to Section 4.1.
If the IPv4-embedded IPv6 routing table is created by using a If the IPv4-embedded IPv6 routing table is created by using a
separate OSPFv3 instance in the IPv6 network, configuration is separate OSPFv3 instance in the IPv6 network, configuration is
accomplished according to [RFC5838], as described in Section 3.3, and accomplished according to [RFC5838], as described in Section 3.3, and
if the default OSPFv3 instance is used instead, configuration is if the default OSPFv3 instance is used instead, configuration is
accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in
Section 3.4. Section 3.4.
With the solution as described in this document, IPv4-embedded IPv6 Note this document does not change any behavior of OSPFv3, and the
addresses and prefixes will be injected by AFXLBR into some part of existing or common practice should apply, in the context of
the IPv6 network (see Section 3.1 for details), and a separate scalability. For example, the amount of routes that are advertised
routing table will be used for IPv4-embedded IPv6 routing. Care must by OSPFv3 is one key concern. With the solution as described in this
be taken during the network design, such that 1) aggregation are document, IPv4-embedded IPv6 addresses and prefixes will be injected
performed on IPv4 addresses and prefixes before being advertised in by AFXLBR into some part of the IPv6 network (see Section 3.1 for
the IPv6 network as described in Section 6, and 2) estimates are made details), and a separate routing table will be used for IPv4-embedded
as the amount of IPv4-embedded IPv6 routes that would be disseminated IPv6 routing. Care must be taken during the network design, such
in the IPv6 network, and the size of the separate OSPFv3 routing that 1) aggregation are performed on IPv4 addresses and prefixes
table. Note this document does not change any behavior of OSPFv3, before being advertised in the IPv6 network as described in
and the existing or common practice should apply. Section 6, and 2) estimates are made as the amount of IPv4-embedded
IPv6 routes that would be disseminated in the IPv6 network, and the
size of the separate OSPFv3 routing table.
13. IANA Considerations 13. IANA Considerations
No new IANA assignments are required for this document. No new IANA assignments are required for this document.
14. Acknowledgements 14. 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 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-ospf-mt-ospfv3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in
progress), July 2007.
[I-D.ietf-ospf-ospfv3-iid-registry-update] [I-D.ietf-ospf-ospfv3-iid-registry-update]
Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry
Update", draft-ietf-ospf-ospfv3-iid-registry-update-02 Update", draft-ietf-ospf-ospfv3-iid-registry-update-04
(work in progress), February 2013. (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
skipping to change at page 15, line 34 skipping to change at page 15, line 22
[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", RFC
5838, April 2010. 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 15.2. Informative References
[I-D.ietf-ospf-mt-ospfv3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in
progress), July 2007.
[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
Authentication Trailer for OSPFv3", RFC 6506, 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
 End of changes. 29 change blocks. 
73 lines changed or deleted 83 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/