draft-ietf-ospf-ipv4-embedded-ipv6-routing-00.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-01.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 15, 2011 France Telecom Expires: April 12, 2012 France Telecom
April 13, 2011 October 10, 2011
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-00 draft-ietf-ospf-ipv4-embedded-ipv6-routing-01
Abstract Abstract
This document describes routing packets destined to IPv4-embedded This document describes routing packets destined to IPv4-embedded
IPv6 addresses across IPv6 transit core using OSPFv3 with a separate IPv6 addresses across IPv6 transit core using OSPFv3 with a separate
routing table. routing table.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 15, 2011. This Internet-Draft will expire on April 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 28 skipping to change at page 3, line 28
o AFBR (Address Family Border Router, [RFC5565]) refers to an edge o AFBR (Address Family Border Router, [RFC5565]) refers to an edge
router, which supports both IPv4 and IPv6 address families, of a router, which supports both IPv4 and IPv6 address families, of a
backbone that supports only IPv4 or IPv6 address family. backbone that supports only IPv4 or IPv6 address family.
o AFXLBR (Address Family Translation Border Router) is defined in o AFXLBR (Address Family Translation Border Router) is defined in
this document. It refers to a border router that supports both this document. It refers to a border router that supports both
IPv4 and IPv6 address families, located on the boundary of IPv4- IPv4 and IPv6 address families, located on the boundary of IPv4-
only network and IPv6-only network, and is capable of performing only network and IPv6-only network, and is capable of performing
IP header translation between IPv4 and IPv6 according to IP header translation between IPv4 and IPv6 according to
[I-D.ietf-behave-v6v4-xlate]. [RFC6145].
1.1. The Scenario 1.1. The Scenario
Due to exhaustion of public IPv4 addresses, there has been continuing Due to exhaustion of public IPv4 addresses, there has been continuing
effort within IETF on IPv6 transitional techniques. In the course of effort within IETF on IPv6 transitional techniques. In the course of
transition, it is certain that networks based on IPv4 and IPv6 transition, it is certain that networks based on IPv4 and IPv6
transfer capabilities, respectively, will co-exist at least for some transfer capabilities, respectively, will co-exist at least for some
time. One scenario of the co-existence is that IPv4-only networks time. One scenario of the co-existence is that IPv4-only networks
inter-connecting with IPv6-only networks, and in particular, when an inter-connecting with IPv6-only networks, and in particular, when an
IPv6-only network serves as a transit network that inter-connects IPv6-only network serves as a transit network that inter-connects
skipping to change at page 4, line 36 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
transit network, and in particular, we name the border node on the transit network, and in particular, we name the border node on the
boundary of an IPv4 client network and the IPv6 transit network as boundary of an IPv4 client network and the IPv6 transit network as
Address Family Translation Border Router, or AFXLBR, which supports Address Family Translation Border Router, or AFXLBR, which supports
both IPv4 and IPv6 address families, and is capable of translating an both IPv4 and IPv6 address families, and is capable of translating an
IPv4 packet to an IPv6 packet, and vice versa, according to IPv4 packet to an IPv6 packet, and vice versa, according to
[I-D.ietf-behave-v6v4-xlate]. [RFC6145].
Since the scenario occurs most in a single ISP operating environment, Since the scenario occurs most in a single ISP operating environment,
an IPv6 prefix can be locally allocated and used to construct IPv4- an IPv6 prefix can be locally allocated and used to construct IPv4-
embedded IPv6 addresses according to [RFC6052] by each AFXLBR, where embedded IPv6 addresses according to [RFC6052] by each AFXLBR, where
the embedded IPv4 addresses are associated with an IPv4 client the embedded IPv4 addresses are associated with an IPv4 client
network that is connected to the AFXLBR, and each IPv4 address is an network that is connected to the AFXLBR, and each IPv4 address is an
individual IPv4 address or prefix. An AFXLBR injects IPv4-embedded individual IPv4 address or prefix. An AFXLBR injects IPv4-embedded
IPv6 addresses/prefixes into the IPv6 transit network using OSPFv3 IPv6 addresses/prefixes into the IPv6 transit network using OSPFv3
and also installs those advertised by other AFXLBRs. When an IPv4 and also installs those advertised by other AFXLBRs. When an IPv4
packet is sent from one IPv4 client network to the other, it is first packet is sent from one IPv4 client network to the other, it is first
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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].
3. IP Packets Translation 3. IP Packets Translation
When transporting IPv4 packets across an IPv6 transit network with When transporting IPv4 packets across an IPv6 transit network with
the mechanism described above, an IPv4 packet is translated to an the mechanism described above, an IPv4 packet is translated to an
IPv6 packet at ingress AFXLBR, and the IPv6 packet is translated back IPv6 packet at ingress AFXLBR, and the IPv6 packet is translated back
to the original IPv4 packet at egress AFXLBR. The IP packet to the original IPv4 packet at egress AFXLBR. The IP packet
translation is accomplished in stateless manner according to rules translation is accomplished in stateless manner according to rules
specified in [I-D.ietf-behave-v6v4-xlate], with the address specified in [RFC6145], with the address translation detail explained
translation detail explained in the next sub-section. in the next sub-section.
3.1. Address Translation 3.1. Address Translation
Prior to the operation, an IPv6 prefix is allocated by the ISP and it Prior to the operation, an IPv6 prefix is allocated by the ISP and it
is used to form an IPv4-embedded IPv6 address. is used to form an IPv4-embedded IPv6 address.
The IPv6 prefix can either be a well-known IPv6 prefix (WKP) 64: The IPv6 prefix can either be a well-known IPv6 prefix (WKP) 64:
ff9b::/96, or a network-specific prefix that is unique to the ISP, ff9b::/96, or a network-specific prefix that is unique to the ISP,
and for the later case, the IPv6 prefix length may be 32, 40, 48, 56 and for the later case, the IPv6 prefix length may be 32, 40, 48, 56
or 64. In either case, this IPv6 prefix is used during the address or 64. In either case, this IPv6 prefix is used during the address
skipping to change at page 9, line 44 skipping to change at page 9, line 44
network, after the associated destination addresses/prefixes are network, after the associated destination addresses/prefixes are
translated back to IPv4 addresses/prefixes format. This operation is translated back to IPv4 addresses/prefixes format. This operation is
similar to the regular OSPFv3 operation, wherein an AS External LSA similar to the regular OSPFv3 operation, wherein an AS External LSA
can be advertised in a non-backbone area by default. can be advertised in a non-backbone area by default.
An IPv4 client network that does not want to receive such An IPv4 client network that does not want to receive such
advertisement can be configured as a stub area or with other routing advertisement can be configured as a stub area or with other routing
policy. policy.
For the purpose of this document, IPv4-embedded IPv6 routes must not For the purpose of this document, IPv4-embedded IPv6 routes must not
advertised into any IPv6 client networks that also connected to the be advertised into any IPv6 client networks that also connected to
IPv6 transit network. the IPv6 transit network.
5. Aggregation on IPv4 Addresses and Prefixes 5. Aggregation on IPv4 Addresses and Prefixes
In order to reduce the amount of AS External LSAs that are injected In order to reduce the amount of AS External LSAs that are injected
to the IPv6 transit network, effort must be made to aggregate IPv4 to the IPv6 transit network, effort must be made to aggregate IPv4
addresses and prefixes at each AFXLBR before advertising. addresses and prefixes at each AFXLBR before advertising.
6. Forwarding 6. Forwarding
There are three cases in forwarding IP packets in the scenario as There are three cases in forwarding IP packets in the scenario as
skipping to change at page 11, line 41 skipping to change at page 11, line 41
11. Acknowledgements 11. Acknowledgements
Many thanks to Acee Lindem, Dan Wing and Joel Halpern for their Many thanks to Acee Lindem, Dan Wing and Joel Halpern for their
comments. comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
progress), September 2010.
[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.
[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.
[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.
[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", Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010. 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.
12.2. Informative References 12.2. Informative References
[I-D.boucadair-softwire-dslite-v6only] [I-D.boucadair-softwire-dslite-v6only]
Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou,
M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual-
Stack Lite in IPv6 Network", Stack Lite in IPv6 Network",
draft-boucadair-softwire-dslite-v6only-01 (work in draft-boucadair-softwire-dslite-v6only-01 (work in
progress), April 2011. progress), April 2011.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
 End of changes. 9 change blocks. 
15 lines changed or deleted 13 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/