draft-ietf-ospf-ipv4-embedded-ipv6-routing-13.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-14.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: November 26, 2013 France Telecom Expires: December 13, 2013 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
May 25, 2013 June 11, 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-13 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 RFCs 6145 and 6052, along
with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in
the IPv6 network. the IPv6 network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 November 26, 2013. This Internet-Draft will expire on December 13, 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 14 skipping to change at page 2, line 14
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 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 . . . . . . . . . . . . . . . . . . . . 6
3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . 7 3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . 6
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.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8
4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8
4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8
5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 9 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 9 Transit Network . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9
5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 10 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 9
5.2. Advertising IPv4 Addresses into Client Networks . . . . . 10 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 9
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 11 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 10
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 11 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 11
9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11
10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. Operational Considerations . . . . . . . . . . . . . . . . . 13 12. Operational Considerations . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 15 15.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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:
skipping to change at page 3, line 47 skipping to change at page 3, line 47
the IPv4 networks by some mechanism. the IPv4 networks by 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- expenditure and optimize the operation compared to IPv4-IPv6 dual-
stack environment. Some solutions have been proposed to allow stack environment. Some solutions have been proposed to allow
delivery of IPv4 services over an IPv6-only network. This document delivery of IPv4 services over an IPv6-only network. This document
specifies an engineering technique that separates the routing table specifies an engineering technique that separates the routing table
dedicated to IPv4-embedded IPv6 destinations from the routing table dedicated to IPv4-embedded IPv6 destinations from the routing table
used for native IPv6 destinations. used for native IPv6 destinations.
OSPFv3 is designed to support multiple instances or multiple OSPFv3 is designed to support multiple instances. Maintaining a
topologies. Maintaining a separate routing table for IPv4-embedded separate routing table for IPv4-embedded IPv6 routes would simplify
IPv6 routes would simplify the implementation, trouble shooting and the implementation, trouble shooting and operation; it also prevents
operation; it also prevents overload of the native IPv6 routing overload of the native IPv6 routing table. A separate routing table
tables. A separate routing table can be generated from a separate can be generated from a separate routing instance.
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 inter-connected IPv4 networks are called IPv4 client networks. The
P(rovider) Routers in the core only support IPv6 but the AFBRs P(rovider) Routers in the core only support IPv6 but the AFBRs
(Address Family Border Routers) support IPv4 on interfaces facing (Address Family Border Routers) support IPv4 on interfaces facing
IPv4 client networks, and IPv6 on interfaces facing the core. The IPv4 client networks, and IPv6 on interfaces facing the core. The
routing solution defined in [RFC5565] for this scenario is to run routing solution defined in [RFC5565] for this scenario is to run
skipping to change at page 6, line 14 skipping to change at page 6, line 14
routes exchange, or i-BGP is not used at all. Another case is when routes exchange, or i-BGP 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 to be flooded However, this would require 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 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 Routers providing participating AFXLBR routers and a set of P Routers 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 To realize this, a separate OSPFv3 instance is configured in the IPv6
IPv4-embedded IPv6 routes: network according to [RFC5838]. This instance operates on all
participating AFXLBR and a set of P routers that inter-connecting
o The first one is to run a separate OSPFv3 instance for them. As a result, there would be a dedicated IPv4-embedded IPv6
IPv4-embedded IPv6 topology in the IPv6 network according to topology that is maintained on all these routers along with a
[RFC5838]. dedicated IPv4-embedded IPv6 routing table. This routing table in
the IPv6 network is solely for forwarding IPv4-embedded IPv6 packets.
o The second one is to stay with the existing OSPFv3 instance that
already operates in the IPv6 network, but maintain a separate
IPv4-embedded IPv6 topology, according to
[I-D.ietf-ospf-mt-ospfv3].
With either method, there would be a dedicated IPv4-embedded IPv6
topology that is maintained on all participating AFXLBR and P
Routers, along with a dedicated IPv4-embedded IPv6 routing table.
This routing table is then used solely in the IPv6 network for
IPv4-embedded IPv6 packets.
It would be an operator's preference as which method is to be used. This document elaborates on how configuration is done with this
This document elaborates on how configuration is done for each method method and related routing issues.
and related routing issues that are common to both.
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].
skipping to change at page 7, line 39 skipping to change at page 7, line 28
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
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 either in [RFC5838] or in OSPFv3 needs to use the mechanism defined in [RFC5838].
[I-D.ietf-ospf-mt-ospfv3] with the required configuration, as
described in Section 3.3 and Section 3.4, respectively.
3.3. OSPFv3 Topology with a Separate Instance ID
It is assumed that the IPv6 network that is inter-connected with IPv4 It is assumed that the IPv6 network that is inter-connected with IPv4
networks in this document is under one administration and as such, an networks in this document is under one administration and as such, an
OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3 OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3
operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6 operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6
network. This IID is configured on OSPFv3 router interfaces that network. This IID is configured on OSPFv3 router interfaces that
participate in the IPv4-embedded IPv6 topology. participate in the IPv4-embedded IPv6 topology.
The range for a locally configured OSPFv3 IID is allocated from 192 The range for a locally configured OSPFv3 IID is allocated from 192
to 255, inclusive, as "Private Use" per to 255, inclusive, as "Private Use" per
skipping to change at page 8, line 21 skipping to change at page 8, line 5
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
configured on the receiving OSPFv3 interface. This insures that only configured on the receiving OSPFv3 interface. This insures that only
interfaces configured as part of the OSPFv3 unicast IPv4-embedded interfaces configured as part of the OSPFv3 unicast IPv4-embedded
IPv6 topology are used for IPv4-embedded IPv6 unicast routing. 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].
3.4. OSPFv3 Topology with the Default Instance
Similar to that as described in the previous section, an OSPFv3
multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3
operation including unicast IPv4-embedded IPv6 routing in an IPv6
network. This MT-ID is configured on each OSPFv3 router interface
that participates in this routing topology.
The range for a locally configured OSPFv3 MT-ID is from 32 to 255,
inclusive, and this MT-ID must be used to encode the "MT-ID" field
included in extended Link State Advertisements (LSAs) for the
IPv4-embedded IPv6 unicast topology as documented in
[I-D.ietf-ospf-mt-ospfv3].
In addition, the MT bit in the OSPFv3 Option field MUST be set.
For more details, the reader is referred to
[I-D.ietf-ospf-mt-ospfv3].
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 (Section 3.3 and Section 3.4), an IPv4 mechanism described above (Section 3.2), an IPv4 packet is translated
packet is translated to an IPv6 packet at the ingress AFXLBR, and the to an IPv6 packet at the ingress AFXLBR, and the IPv6 packet is
IPv6 packet is translated back to an IPv4 packet at the egress translated back to an IPv4 packet at the egress AFXLBR. The IP
AFXLBR. The IP packet header translation is accomplished in packet header translation is accomplished in stateless manner
stateless manner according to rules specified in [RFC6145], with the according to rules specified in [RFC6145], with the address
address translation details explained in the next sub-section. 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 organization; 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].
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 IPv6 source address and
destination IPv6 address, respectively, and during translation from destination IPv6 address, respectively, and during translation from
an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 an 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
skipping to change at page 12, line 19 skipping to change at page 11, line 29
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-bit sent. DN-bit sent.
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. If a separate the same as that of the default OSPFv3 instance.
OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is used for
IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is
the same as that of the default OSPFv3 topology.
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 and the
resulting MTU, after taking into account of the difference between resulting MTU, after taking into account of the difference between
the IPv4 header length and the IPv6 header length, must be the IPv4 header length and the IPv6 header length, must be
"propagated" into IPv4 client networks, e.g., included in the OSPFv2 "propagated" into IPv4 client networks, e.g., included in the OSPFv2
skipping to change at page 13, line 29 skipping to change at page 12, line 34
o If firewalls are used in IPv4 and/or IPv6 networks, the o If firewalls are used in IPv4 and/or IPv6 networks, the
configuration on the routers must be consistent so there are no configuration on the routers must be consistent so there are no
holes in the IPv4 address filtering. holes in the 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 put 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 IETF as an integrated solution to transport
IPv4 packets over an IPv6 network using a separate OSPFv3 routing IPv4 packets over an IPv6 network using a separate OSPFv3 routing
table. There are several aspects that require attention for the table. There are several aspects that require attention for the
deployment and operation. 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, with different mechanisms. The two methods are
not related to each other, and they can co-exist in the same network not related to each other, and they can co-exist in the same network
if so deployed, without any conflict. 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, it is the operator's decision for
the choice. Note that each approach has its own characteristics and the choice. Note that each approach has its own characteristics and
requirements. E.g., the tunnel-based solution requries a mesh of requirements. E.g., the tunnel-based solution requires 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 performing 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.
The IPv4-embedded IPv6 routing table is created by using a separate
If the IPv4-embedded IPv6 routing table is created by using a OSPFv3 instance in the IPv6 network, the configuration is
separate OSPFv3 instance in the IPv6 network, configuration is accomplished according to [RFC5838], as described in Section 3.2.
accomplished according to [RFC5838], as described in Section 3.3, and
if the default OSPFv3 instance is used instead, configuration is
accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in
Section 3.4.
Note this document does not change any behavior of OSPFv3, and the Note this document does not change any behavior of OSPFv3, and the
existing or common practice should apply, in the context of 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 AFXLBR 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 the network design, such
that 1) aggregation are performed on IPv4 addresses and prefixes that 1) aggregation are performed on IPv4 addresses and prefixes
skipping to change at page 15, line 17 skipping to change at page 14, line 17
[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.
 End of changes. 24 change blocks. 
102 lines changed or deleted 54 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/