draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-06.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: March 30, 2013 France Telecom Expires: July 29, 2013 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
September 26, 2012 January 25, 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 draft-ietf-ospf-ipv4-embedded-ipv6-routing-06
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 March 30, 2013. This Internet-Draft will expire on July 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
Transit Network . . . . . . . . . . . . . . . . . . . . . 8 Transit Network . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9
5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9
5.2. Advertising IPv4 Addresses into Client Networks . . . . . 9 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 9
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 10 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 10
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 10 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 10
9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11
10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
14.2. Informative References . . . . . . . . . . . . . . . . . . 12 14.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
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.
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 11, line 41 skipping to change at page 11, line 41
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.
11. Security Considerations 11. Security Considerations
This document does not introduce any security issues other than those There are several security aspects that require attention in the
identified in [RFC5838] and [RFC6052]. deployment practice described in this document.
In the OSPFv3 transit network, the security considerations for OSPFv3
are covered in [RFC5340], and in particular, IPsec can be used for
OSPFv3 authentication and confidentiality as suggested in [RFC5838].
When a separate OSPFv3 instance is used to support IPv4-embedded IPv6
routing, the same Security Association (SA) (refer to [RFC4552] )
must be used by the embedded IPv4 address instance as other instances
utilizing the same link as specified in [RFC5838].
Security considerations as currently documented in [RFC6052] must
also be thought through with proper implementation in this
engineering practice including the following:
o The IPv6 prefix that is used to carry an embedded IPv4 address
(refer to Section 4.1) must be configured by the authorized
operator on all participating AFXLBRs in a secure manner. This is
to help prevent an malicious attack resulting in network
disruption, denial of service, and possible information
disclosure.
o Effective mechanisms (such as reverse path checking) must be
implemented in the IPv6 transit network (including AFXLIBR nodes)
to prevent spoofing on embedded IPv4 addresses, which, otherwise,
might be used as source addresses of malicious packets.
o If firewalls are used in IPv4 and/or IPv6 networks, the
configuration on the routers must be consistent so there are no
holes in the IPv4 address filtering.
The details of security handling for this engineering practice are
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 and Mike Shand for
their comments. their comments.
skipping to change at page 12, line 29 skipping to change at page 13, line 14
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.
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.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
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 [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", Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010. RFC 5838, April 2010.
 End of changes. 9 change blocks. 
11 lines changed or deleted 44 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/