draft-ietf-ospf-ipv4-embedded-ipv6-routing-09.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-10.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 01, 2013 France Telecom Expires: October 14, 2013 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
March 30, 2013 April 12, 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-09 draft-ietf-ospf-ipv4-embedded-ipv6-routing-10
Abstract Abstract
This document describes routing packets destined to IPv4-embedded This document describes routing packets destined to IPv4-embedded
IPv6 addresses across an IPv6 core using OSPFv3 with a separate IPv6 addresses across an IPv6 core using OSPFv3 with a separate
routing table. routing table.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 01, 2013. This Internet-Draft will expire on October 14, 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 42 skipping to change at page 2, line 42
Transit Network . . . . . . . . . . . . . . . . . . . . . 10 Transit Network . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. Operational Considerations . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 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 4, line 30 skipping to change at page 4, line 30
AFBRs to exchange IPv4 routing information in the core, and the IPv4 AFBRs to exchange IPv4 routing information in the core, and the IPv4
packets are forwarded from one IPv4 client network to the other packets are forwarded from one IPv4 client network to the other
through a softwire using tunneling technology such as MPLS LSP, GRE, through a softwire using tunneling technology such as MPLS 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 inter-connected by an IPv6
network, which belongs to a different Autonomous System from those of network. The IPv6 network and the inter-connected IPv4 networks may
the IPv4 networks. We refer to the border node on the boundary of an or may not belong to the same Autonomous System. We refer to the
IPv4 client network and the IPv6 network as an Address Family border node on the boundary of an IPv4 client network and the IPv6
Translation Border Router (AFXLBR), which supports both the IPv4 and network as an Address Family Translation Border Router (AFXLBR),
IPv6 address families, and is capable of translating an IPv4 packet which supports both the IPv4 and IPv6 address families, and is
to an IPv6 packet, and vice versa, according to [RFC6145]. The capable of translating an IPv4 packet to an IPv6 packet, and vice
described scenario is illustrated in Figure 1. versa, according to [RFC6145]. The described scenario is illustrated
in Figure 1.
+--------+ +--------+ +--------+ +--------+
| IPv4 | | IPv4 | | IPv4 | | IPv4 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
| \ / | | \ / |
| \ / | | \ / |
| \ / | | \ / |
| X | | X |
skipping to change at page 5, line 32 skipping to change at page 5, line 34
| / \ | | / \ |
| / \ | | / \ |
+--------+ +--------+ +--------+ +--------+
| 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 Inter-connected by an IPv6 Network
Since the scenario occurs most commonly in a single Autonomous Since the scenario occurs most commonly within an organization, an
System, an IPv6 prefix can be locally allocated and used by AFXLBRs IPv6 prefix can be locally allocated and used by AFXLBRs to construct
to construct IPv4-embedded IPv6 addresses according to [RFC6052]. IPv4-embedded IPv6 addresses according to [RFC6052]. The embedded
The embedded IPv4 address or prefix belongs to an IPv4 client network IPv4 address or prefix belongs to an IPv4 client network that is
that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded connected to the AFXLBR. An AFXLBR injects IPv4-embedded IPv6
IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and addresses and prefixes into the IPv6 network using OSPFv3, and it
it also installs IPv4-embedded IPv6 routes advertised by other also installs IPv4-embedded IPv6 routes advertised by other AFXLBRs.
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 and 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 according to
[RFC6145], and in that process, source and destination IPv4 address [RFC6145], and in that process, source and destination IPv4 address
are translated into IPv4-embedded IPv6 addresses, respectively, are translated into IPv4-embedded IPv6 addresses, respectively,
according to [RFC6052]. The resulting IPv6 packet is then forwarded according to [RFC6052]. The resulting IPv6 packet is then forwarded
to the AFXLBR that connects to the destination IPv4 client network. to the AFXLBR that connects to the destination IPv4 client network.
The remote AFXLBR derives the IPv4 source and destination addresses The remote AFXLBR derives the IPv4 source and destination addresses
from the IPv4-embedded IPv6 addresses, respectively, according to from the IPv4-embedded IPv6 addresses, respectively, according to
skipping to change at page 6, line 31 skipping to change at page 6, line 31
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(rovider) Routers
redundant connectivity with alternate routing paths. providing 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 8, line 5 skipping to change at page 8, line 5
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 either in [RFC5838] or in
[I-D.ietf-ospf-mt-ospfv3] with the required configuration, as [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as
described in Section 3.3 and Section 3.4, respectively. described in Section 3.3 and Section 3.4, respectively.
3.3. OSPFv3 Topology with a Separate Instance ID 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 a single Autonomous System and as networks in this document is under one administration and as such, an
such, an OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3
OSPFv3 operation dedicated to unicast IPv4-embedded IPv6 routing in operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6
an IPv6 network. This IID is configured on OSPFv3 router interfaces network. This IID is configured on OSPFv3 router interfaces that
that participate in the IPv4-embedded IPv6 topology. participate in the IPv4-embedded IPv6 topology.
The range for a locally configured OSPFv3 IID is from 192 to 255, The range for a locally configured OSPFv3 IID is from 192 to 255,
inclusive, and this IID must be used to encode the "Instance ID" inclusive, and this IID must be used to encode the "Instance ID"
field in the packet header of OSPFv3 packets associated with the field in the packet header of OSPFv3 packets associated with the
OSPFv3 instance. 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
skipping to change at page 9, line 10 skipping to change at page 9, line 10
mechanism described above, an IPv4 packet is translated to an IPv6 mechanism described above, an IPv4 packet is translated to an IPv6
packet at the ingress AFXLBR, and the IPv6 packet is translated back packet at the ingress AFXLBR, and the IPv6 packet is translated back
to an IPv4 packet at the egress AFXLBR. The IP packet header to an IPv4 packet at the egress AFXLBR. The IP packet header
translation is accomplished in stateless manner according to rules translation is accomplished in stateless manner according to rules
specified in [RFC6145], with the address translation details specified in [RFC6145], with the address translation details
explained in the next sub-section. 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
Autonomous System and it is used to form IPv4-embedded IPv6 operator and it is used to form IPv4-embedded IPv6 addresses.
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
Autonomous System; and for the latter case, the IPv6 prefix length organzation; and for the latter case, the IPv6 prefix length may be
may be 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is used
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
corresponding IPv4 source address and destination IPv4 address, corresponding IPv4 source address and destination IPv4 address,
respectively. Note that the address translation is accomplished in a respectively. Note that the address translation is accomplished in a
skipping to change at page 9, line 49 skipping to change at page 9, line 48
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 needs to be disseminated throughout
the IPv6 network and this is performed by AFXLBRs that connect to the IPv6 network and this is performed by AFXLBRs that connect to
IPv4 client networks using OSPFv3. 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 inter-connect a bunch of IPv4 client networks with an IPv6
network, the IPv4 networks and IPv6 networks belong to separate and network, the IPv4 networks and IPv6 networks belong to the same or
independent Autonomous Systems, and as such, these AFXLBRs behave as separate Autonomous Systems, and as such, these AFXLBRs behave as 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 Autonomous System and the method the IPv6 prefix allocated by the operator and the method specified in
specified in [RFC6052]. These routes are then advertised by one or [RFC6052]. These routes are then advertised by one or more attached
more attached ASBRs into the IPv6 transit network using AS-External- ASBRs into the IPv6 transit network using AS-External-LSAs [RFC5340],
LSAs [RFC5340], i.e., with advertising scope comprising the entire i.e., with advertising scope comprising the entire Autonomous System.
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-embedded IPv6 address or prefixes is a Type 1 external metric, IPv4-embedded IPv6 address or prefixes is a Type 1 external metric,
which is comparable to the link state metric and we assume that in which is comparable to the link state metric and we assume that in
most cases, OSPFv2 is used in client IPv4 networks. This metric is most cases, OSPFv2 is used in client IPv4 networks. This metric is
added to the metric of the intra-AS path to the ASBR during the added to the metric of the intra-AS path to the ASBR during the
OSPFv3 route calculation. Through ASBR configuration, the metric can OSPFv3 route calculation. Through ASBR configuration, the metric can
be set to a Type 2 external metric, which is considered much larger be set to a Type 2 external metric, which is considered much larger
skipping to change at page 13, line 42 skipping to change at page 13, line 42
to prevent spoofing on embedded IPv4 addresses, which, otherwise, to prevent spoofing on embedded IPv4 addresses, which, otherwise,
might be used as source addresses of malicious packets. might 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, 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. IANA Considerations 12. Operational Considerations
This document put together some mechanisms based on existing
technologies developed by IETF as an integrated solution to transport
IPv4 packets over an IPv6 network using a separate OSPFv3 routing
table. There are several aspects that require attention for the
deployment and operation.
The tunnel-based solution documented in [RFC5565] and the solution
proposed in this document are both used for transporting IPv4 packets
over an IPv6 network, with different mechanisms. The two methods are
not related to each other, and they can co-exist in the same network
if so deployed, without any conflict.
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
requirements. E.g., the tunnel-based solution requries a mesh of
inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as
iBGP to exchange routes between AFBRs ([RFC5565]); the approach in
this document requires AFXLBR capable of perfoming IPv4-IPv6 packet
header translation per [RFC6145].
To deploy the solution as documented here, there requires some
configurations. An IPv6 prefix must first be chosen that is used to
form all the IPv4-embedded IPv6 addresses and prefixes advertised by
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
separate OSPFv3 instance in the IPv6 network, configuration is
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.
With the solution as described in this document, IPv4-embedded IPv6
addresses and prefixes will be injected 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 IPv6 routing. Care must
be taken during the network design, such that 1) aggregation are
performed on IPv4 addresses and prefixes before being advertised in
the IPv6 network as described in Section 6, and 2) estimates are made
as the amount of IPv4-embedded IPv6 routes that would be disseminated
in the IPv6 network, and the size of the separate OSPFv3 routing
table. Note this document does not change any behavior of OSPFv3,
and the existing or common practice should apply.
13. IANA Considerations
No new IANA assignments are required for this document. No new IANA assignments are required for this document.
13. 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.
14. References 15. References
14.1. Normative References
15.1. Normative References
[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", 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.
14.2. Informative References 15.2. Informative References
[I-D.ietf-ospf-mt-ospfv3] [I-D.ietf-ospf-mt-ospfv3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in
progress), July 2007. 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
 End of changes. 18 change blocks. 
51 lines changed or deleted 95 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/