draft-ietf-ospf-ipv4-embedded-ipv6-routing-08.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-09.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: September 30, 2013 France Telecom Expires: October 01, 2013 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
March 29, 2013 March 30, 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-08 draft-ietf-ospf-ipv4-embedded-ipv6-routing-09
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 September 30, 2013. This Internet-Draft will expire on October 01, 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 40 skipping to change at page 2, line 40
5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 9 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 9
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 10 Transit Network . . . . . . . . . . . . . . . . . . . . . 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. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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 12, line 17 skipping to change at page 12, line 17
In some deployments, IPv4 client networks are inter-connected across In some deployments, IPv4 client networks are inter-connected across
the IPv6 network, but also directly connected to each other. The the IPv6 network, but also directly connected to each other. The
direct connections between IPv4 client networks, as sometimes called direct connections between IPv4 client networks, as sometimes called
"backdoor" connections, can certainly be used to transport IPv4 "backdoor" connections, can certainly be used to transport IPv4
packets between IPv4 client networks. In general, backdoor packets between IPv4 client networks. In general, backdoor
connections are preferred over the IPv6 network since there requires connections are preferred over the IPv6 network since there requires
no address family translation. no address family translation.
9. Prevention of Loops 9. Prevention of Loops
In some deployments, IPv4 client networks are inter-connected across
the IPv6 network, but also directly connected to each other. The
direct connections between IPv4 client networks, as sometimes called
"backdoor" connections, can certainly be used to transport IPv4
packets between IPv4 client networks. In general, backdoor
connections are preferred over the IPv6 network since there requires
no address family translation.
10. Prevention of Loops
If an LSA sent from an AFXLBR into a client network could then be If an LSA sent from an AFXLBR into a client network could then be
received by another AFXLBR, it would be possible for routing loops to received by another AFXLBR, it would be possible for routing loops to
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.
11. 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. If a separate
OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is used for 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 IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is
the same as that of the default OSPFv3 topology. 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
skipping to change at page 13, line 19 skipping to change at page 13, line 5
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
Database Description packet. Database Description packet.
The details of passing the proper MTU into IPv4 client networks are The details of passing the proper MTU into IPv4 client networks are
beyond the scope of this document. beyond the scope of this document.
12. Security Considerations 11. Security Considerations
There are several security aspects that require attention in the There are several security aspects that require attention in the
deployment practice described in this document. deployment practice described in this document.
In the OSPFv3 transit network, the security considerations for OSPFv3 In the OSPFv3 transit network, the security considerations for OSPFv3
are covered in [RFC5340], and in particular, IPsec can be used for are covered in [RFC5340], and in particular, IPsec can be used for
OSPFv3 authentication and confidentiality as suggested in [RFC5838]. OSPFv3 authentication and confidentiality as suggested in [RFC5838].
When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 When a separate OSPFv3 instance is used to support IPv4-embedded IPv6
routing, the same Security Association (SA) (refer to [RFC4552] ) routing, the same Security Association (SA) (refer to [RFC4552] )
skipping to change at page 14, line 8 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.
13. IANA Considerations 12. IANA Considerations
No new IANA assignments are required for this document. No new IANA assignments are required for this document.
14. Acknowledgements 13. Acknowledgements
Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and
Brian Carpenter for their comments. Brian Carpenter for their comments.
15. References 14. 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.
15.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
 End of changes. 13 change blocks. 
31 lines changed or deleted 20 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/