draft-ietf-ospf-ipv4-embedded-ipv6-routing-06.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-07.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: July 29, 2013 France Telecom Expires: August 5, 2013 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
January 25, 2013 February 1, 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-06 draft-ietf-ospf-ipv4-embedded-ipv6-routing-07
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 July 29, 2013. This Internet-Draft will expire on August 5, 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 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . 5 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 the IPv4-embedded IPv6 Topology . . . . . . . . . 7
3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing
Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Table . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 8
3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8
4. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 9
4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 9
5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 10
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 8 Transit Network . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10
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 . . . . . 11
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 10 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 11
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 10 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 12
9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12
10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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. transported over an IPv6 network, based on [RFC6145] and [RFC6052],
along with a separate OSPFv3 routing table for IPv4-embedded IPv6
routes in the IPv6 network. This document does not introduce any new
IPv6 transition mechanism.
In this document the following terminology is used: 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
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.
skipping to change at page 4, line 34 skipping to change at page 4, line 36
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 interconnected by an IPv6 networks, called IPv4 client networks, are interconnected by an IPv6
network. We refer to the border node on the boundary of an IPv4 network. We refer to the border node on the boundary of an IPv4
client network and the IPv6 network as an Address Family Translation client network and the IPv6 network as an Address Family Translation
Border Router (AFXLBR), which supports both the IPv4 and IPv6 address Border Router (AFXLBR), which supports both the IPv4 and IPv6 address
families, and is capable of translating an IPv4 packet to an IPv6 families, and is capable of translating an IPv4 packet to an IPv6
packet, and vice versa, according to [RFC6145]. packet, and vice versa, according to [RFC6145]. The described
scenario is illustrated in Figure 1.
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFXLBR | | AFXLBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client |----| |----| Client |
| Network| | IPv6 | | Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFXLBR |---| AFXLBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1: Segregated IPv4 Networks Inter-connected by an IPv6 Network
Since the scenario occurs most commonly in a single Autonomous Since the scenario occurs most commonly in a single Autonomous
System, an IPv6 prefix can be locally allocated and used by AFXLBRs System, an IPv6 prefix can be locally allocated and used by AFXLBRs
to construct IPv4-embedded IPv6 addresses according to [RFC6052]. to construct IPv4-embedded IPv6 addresses according to [RFC6052].
The embedded IPv4 address or prefix belongs to an IPv4 client network The embedded IPv4 address or prefix belongs to an IPv4 client network
that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded
IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and
it also installs IPv4-embedded IPv6 routes advertised by other it also installs IPv4-embedded IPv6 routes advertised by other
AFXLBRs. AFXLBRs.
skipping to change at page 8, line 5 skipping to change at page 9, line 15
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, 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 translation is to an IPv4 packet at the egress AFXLBR. The IP packet header
accomplished in stateless manner according to rules specified in translation is accomplished in stateless manner according to rules
[RFC6145], with the address translation details explained in the next specified in [RFC6145], with the address translation details
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 Autonomous System and it is used to form IPv4-embedded IPv6
addresses. addresses.
The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 64: 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 ff9b::/96, or a network-specific prefix that is unique to the
Autonomous System; and for the latter case, the IPv6 prefix length Autonomous System; and for the latter case, the IPv6 prefix length
skipping to change at page 8, line 33 skipping to change at page 9, line 43
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
stateless manner. stateless manner.
When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only
global IPv4 addresses to be embedded in the IPv6 address. An AFXLBR
MUST NOT translate packets in which an address is composed of the WKP
and a non-global IPv4 address; they MUST drop these packets.
In the case where both the IPv4 client networks and the IPv6 transit
network belong to the same organization, non-global IPv4 addresses
may be used with a network-specific prefix [RFC6052].
5. Advertising IPv4-embedded IPv6 Routes 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 separate and
skipping to change at page 12, line 37 skipping to change at page 14, line 11
The details of security handling for this engineering practice are The details of security handling for this engineering practice are
beyond the scope of this document. beyond the scope of this document.
12. IANA Considerations 12. IANA Considerations
No new IANA assignments are required for this document. No new IANA assignments are required for this document.
13. Acknowledgements 13. Acknowledgements
Many thanks to Acee Lindem, Dan Wing, Joel Halpern and Mike Shand for Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and
their comments. Brian Carpenter for their comments.
14. References 14. References
14.1. Normative References 14.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
Framework", RFC 5565, June 2009.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
14.2. Informative References 14.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
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010.
[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.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
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.
 End of changes. 16 change blocks. 
48 lines changed or deleted 103 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/