draft-ietf-v6ops-v6inixp-06.txt   draft-ietf-v6ops-v6inixp-07.txt 
Internet Engineering Task Force R. Gagliano Internet Engineering Task Force R. Gagliano
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational May 20, 2010 Intended status: Informational June 4, 2010
Expires: November 21, 2010 Expires: December 6, 2010
IPv6 Deployment in Internet Exchange Points (IXPs) IPv6 Deployment in Internet Exchange Points (IXPs)
draft-ietf-v6ops-v6inixp-06.txt draft-ietf-v6ops-v6inixp-07.txt
Abstract Abstract
This document provides guidance on IPv6 deployment in Internet This document provides guidance on IPv6 deployment in Internet
Exchange Points (IXP). It includes information regarding the switch Exchange Points (IXP). It includes information regarding the switch
fabric configuration, the addressing plan and general organizational fabric configuration, the addressing plan and general organizational
tasks that need to be performed. IXPs are mainly a layer 2 tasks that need to be performed. IXPs are mainly a layer 2
infrastructure and in many cases the best recommendations suggest infrastructure and in many cases the best recommendations suggest
that the IPv6 data, control and management plane should not be that the IPv6 data, control and management plane should not be
handled differently than in IPv4. handled differently than in IPv4.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 November 21, 2010. This Internet-Draft will expire on December 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 23 skipping to change at page 2, line 23
4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6 4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6
4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7 4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7
5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Route-Server . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Route-Server . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. External and Internal support . . . . . . . . . . . . . . . . 8 7. External and Internal support . . . . . . . . . . . . . . . . 8
8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. Informative References . . . . . . . . . . . . . . . . . . . . 9 12. Informative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Most Internet Exchange Points (IXP) work at the Layer 2 level, making Most Internet Exchange Points (IXP) work at the Layer 2 level, making
the adoption of IPv6 an easy task. However, IXPs normally implement the adoption of IPv6 an easy task. However, IXPs normally implement
additional services such as statistics, route servers, looking additional services such as statistics, route servers, looking
glasses and broadcast control that may be impacted by the glasses and broadcast control that may be impacted by the
implementation of IPv6. This document clarifies the impact of IPv6 implementation of IPv6. This document clarifies the impact of IPv6
on a new or an existing IXP. The document assumes an Ethernet switch on a new or an existing IXP. The document assumes an Ethernet switch
fabric, although other layer 2 configurations can be deployed. fabric, although other layer 2 configurations can be deployed.
2. Switch Fabric Configuration 2. Switch Fabric Configuration
An Ethernet based IXP switch fabric implements IPv6 over Ethernet as An Ethernet based IXP switch fabric implements IPv6 over Ethernet as
described in [RFC2464] . Therefore, the switching of IPv6 traffic described in [RFC2464] . Therefore, the switching of IPv6 traffic
happens in the same way as in IPv4. However, some management happens in the same way as in IPv4. However, some management
functions may require explicit IPv6 support (such as switch functions may require explicit IPv6 support (such as switch
management, SNMP [RFC3411] support and flow analysis exportation) and management, SNMP [RFC3411] support or flow analysis exportation) and
this should be assessed by the IXP operator. this should be assessed by the IXP operator.
There are two common configurations of IXP switch ports to support There are two common configurations of IXP switch ports to support
IPv6: IPv6:
1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6 1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6
traffic share a common LAN. No extra configuration is required traffic share a common LAN. No extra configuration is required
in the switch. in the switch.
2. independent VLAN (Virtual Local Area Network): when an IXP 2. independent VLAN (Virtual Local Area Network): when an IXP
logically separates IPv4 and IPv6 traffic in different VLANs. logically separates IPv4 and IPv6 traffic in different VLANs.
In both configurations, IPv6 and IPv4 traffic can either share a In both configurations, IPv6 and IPv4 traffic can either share a
common physical port or use independent physical ports. The use of common physical port or use independent physical ports. The use of
independent ports can be more costly in both capital expenses (as new independent ports can be more costly in both capital expenses (as new
ports are needed) and operational expenses. ports are needed) and operational expenses.
When using the same physical port for both IPv4 and IPv6 traffic, When using the same physical port for both IPv4 and IPv6 traffic,
some changes may be needed at the participants' interfaces some changes may be needed at the participants' interfaces
configurations. If the IXP implements the "dual-stack configurations. If the IXP implements the "dual-stack
configuration", IXP participants will configure dual-stack configuration", IXP's participants will configure dual-stack
interfaces. On the other hand, if the IXP implements the interfaces. On the other hand, if the IXP implements the
"independent VLAN configuration", IXP participants are required to "independent VLAN configuration", IXP participants are required to
pass one additional VLAN tag across the interconnection. In this pass one additional VLAN tag across the interconnection. In this
case, if the IXP did not originally use VLAN tagging, VLAN tagging case, if the IXP did not originally use VLAN tagging, VLAN tagging
may to be established and previous use may continue untagged as a should be established and previously configured LAN may continue
"native VLAN" or be transitioned to a tagged VLAN. The "independent untagged as a "native VLAN" or be transitioned to a tagged VLAN. The
VLAN" configuration provides a logical separation of IPv4 and IPv6 "independent VLAN" configuration provides a logical separation of
traffic, simplifying separate statistical analysis for IPv4 and IPv6 IPv4 and IPv6 traffic, simplifying separate statistical analysis for
traffic. Conversely, the "dual-stack" configuration (when performing IPv4 and IPv6 traffic. Conversely, the "dual-stack" configuration
separate statistical analysis for IPv4 and IPv6 traffic) would (when performing separate statistical analysis for IPv4 and IPv6
require the use of flows techniques such as IPFIX [RFC5101] to traffic) would require the use of flows techniques such as IPFIX
classify traffic based on the different ether-types (0x0800 for IPv4, [RFC5101] to classify traffic based on the different ether-types
0x0806 for ARP and 0x86DD for IPv6). (0x0800 for IPv4, 0x0806 for ARP and 0x86DD for IPv6).
The only technical requirement for IPv6 referring link MTUs is that The only technical requirement for IPv6 referring link MTUs is that
they need to be greater than or equal to 1280 octets [RFC2460]. The they need to be greater than or equal to 1280 octets [RFC2460]. The
MTU size for every LAN in an IXP should be well known by all its MTU size for every LAN in an IXP should be well known by all its
participants. participants.
3. Addressing Plan 3. Addressing Plan
Regional Internet Registries (RIRs) have specific address policies to Regional Internet Registries (RIRs) have specific address policies to
assign Provider Independent (PI) IPv6 address to IXPs. Those assign Provider Independent (PI) IPv6 address to IXPs. Those
skipping to change at page 5, line 38 skipping to change at page 5, line 38
address to its IPv4 address. In the following example, the last address to its IPv4 address. In the following example, the last
four decimals of the IPv4 address are copied to the last four decimals of the IPv4 address are copied to the last
hexadecimals of the IPv6 address, using the decimal number as the hexadecimals of the IPv6 address, using the decimal number as the
BCD encoding for the last three characters of the IID such as in BCD encoding for the last three characters of the IID such as in
the following example: the following example:
* IXP LAN prefix: 2001:db8::/64 * IXP LAN prefix: 2001:db8::/64
* IPv4 Address: 192.0.2.123/23 * IPv4 Address: 192.0.2.123/23
* IPv6 Address: 2001:db8:2:123/64 * IPv6 Address: 2001:db8:2::123/64
4. A fourth approach might be based on the IXPs ID for that 4. A fourth approach might be based on the IXPs ID for that
participant. participant.
IPv6 prefixes for IXP LANs are typically publicly well known and IPv6 prefixes for IXP LANs are typically publicly well known and
taken from dedicated IPv6 blocks for IXP assignments reserved for taken from dedicated IPv6 blocks for IXP assignments reserved for
this purpose by the different RIRs. These blocks are usually only this purpose by the different RIRs. These blocks are usually only
meant for addressing the exchange fabric, and may be filtered out by meant for addressing the exchange fabric, and may be filtered out by
DFZ (Default Free Zone) operators. When considering the routing of DFZ (Default Free Zone) operators. When considering the routing of
the IXP LANs two options are identified: the IXP LANs two options are identified:
o IXPs may decide that LANs should not to be globally routed in o IXPs may decide that LANs should not to be globally routed in
order to limit the possible origins of a Denial of Service (DoS) order to limit the possible origins of a Denial of Service (DoS)
attack to its participants' AS boundaries. In this configuration attack to its participants' AS boundaries. In this configuration
participants may route these prefixes inside their networks (e. g. participants may route these prefixes inside their networks (e. g.
using BGP no-export communities or routing the IXP LANs within the using BGP no-export communities or routing the IXP LANs within the
participants' IGP) to perform fault management. Using this participants' IGP) to perform fault management. Using this
configuration, the monitoring of the IXP LANs from outside of its configuration, the monitoring of the IXP LANs from outside of its
participants' AS boundaries is not possible. participants' AS boundaries is not possible.
o IXP may decide that LANs should (attempt to be) be globall routed. o IXP may decide that LANs should (attempt to be) be globally
In this case, IXP LANs monitoring from outside its participants' routed. In this case, IXP LANs monitoring from outside its
AS boundaries may be possible but the IXP LANs will be vulnerable participants' AS boundaries may be possible but the IXP LANs will
to DoS from outside of those boundaries. be vulnerable to DoS from outside of those boundaries.
Additionally, possible IXP external services (such as dns, web pages, Additionally, possible IXP external services (such as dns, web pages,
ftp servers) need to be globally routed. These should be addressed ftp servers) need to be globally routed. These should be addressed
from separate address blocks, either from upstream providers' address from separate address blocks, either from upstream providers' address
space, or separate independent assignments. Strict prefix length space, or separate independent assignments. Strict prefix length
filtering could be a reason for requesting more than one /48 filtering could be a reason for requesting more than one /48
assignment from a RIR (i.e. requesting one /48 assignment for the assignment from a RIR (i.e. requesting one /48 assignment for the
IXPs LANs that may not be globally routed and a different, non-IXP IXPs LANs that may not be globally routed and a different, non-IXP
/48 assignment for the IXP external services that will be globally /48 assignment for the IXP external services that will be globally
routed). routed).
skipping to change at page 6, line 37 skipping to change at page 6, line 37
There are two elements that need to be evaluated when studying IPv6 There are two elements that need to be evaluated when studying IPv6
multicast in an IXP: multicast support for neighbor discovery and multicast in an IXP: multicast support for neighbor discovery and
multicast peering. multicast peering.
4.1. Multicast Support and Monitoring for ND at an IXP 4.1. Multicast Support and Monitoring for ND at an IXP
IXPs typically control broadcast traffic across the switching fabric IXPs typically control broadcast traffic across the switching fabric
in order to avoid broadcast storms by only allowing limited ARP in order to avoid broadcast storms by only allowing limited ARP
[RFC0826] traffic for address resolution. In IPv6 there is not [RFC0826] traffic for address resolution. In IPv6 there is not
broadcast support but IXP may intend to control multicast traffic in broadcast support but IXPs may intend to control multicast traffic in
each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the
following necessary functions in an IXP switching fabric: Address following necessary functions in an IXP switching fabric: Address
Resolution, Neighbor Unreachability Detection and Duplicate Address Resolution, Neighbor Unreachability Detection and Duplicate Address
Detection. In order to perform these functions, Neighbor Detection. In order to perform these functions, Neighbor
Solicitation and Neighbor Advertisement packets are exchanged using Solicitation and Neighbor Advertisement packets are exchanged using
the link-local all-nodes multicast address (ff02::1) and/or the link-local all-nodes multicast address (ff02::1) and/or
solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02: solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02:
0:0:0:0:1:ffff:ffff). As described in [RFC4861] routers will 0:0:0:0:1:ffff:ffff). As described in [RFC4861] routers will
initialize its interfaces by joining its solicited-node multicast initialize its interfaces by joining its solicited-node multicast
addresses using either Multicast Listener Discovery (MLD) [RFC2710] addresses using either Multicast Listener Discovery (MLD) [RFC2710]
skipping to change at page 9, line 11 skipping to change at page 9, line 11
Policies for IPv6 traffic monitoring and filtering may be in place as Policies for IPv6 traffic monitoring and filtering may be in place as
described in Section Section 4 . described in Section Section 4 .
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
This memo includes procedures for monitoring and/or avoiding This memo includes references to procedures for monitoring and/or
particular ICMPv6 traffic at IXPs' LANs. None of these methods avoiding particular ICMPv6 traffic at IXPs' LANs. None of these
prevent Ethernet loops caused by mischief in the LAN. The document procedures prevent Ethernet loops caused by mischief in the LAN. The
also mentions how to limit IPv6 DoS attacks to the IXP switch fabric document also mentions how to limit IPv6 DoS attacks to the IXP
by not globally announce the IXP LANs prefix. switch fabric by not globally announce the IXP LANs prefix.
11. Acknowledgements 11. Acknowledgements
The author would like to thank the contributions from Alain Aina, The author would like to thank the contributions from Alain Aina,
Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels,
Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont and Louis Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont and Louis
Lee. Lee.
12. Informative References 12. Informative References
[I-D.ietf-v6ops-ra-guard] [I-D.ietf-v6ops-ra-guard]
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-05
(work in progress), May 2009. (work in progress), May 2010.
[I-D.ietf-v6ops-rogue-ra] [I-D.ietf-v6ops-rogue-ra]
Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in
progress), May 2009. progress), May 2009.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999. March 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999. October 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002. December 2002.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
Security Mechanism (GTSM)", RFC 3682, February 2004. Considered Harmful", RFC 3627, September 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
 End of changes. 15 change blocks. 
40 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/