draft-ietf-v6ops-v6inixp-08.txt   draft-ietf-v6ops-v6inixp-09.txt 
Internet Engineering Task Force R. Gagliano Internet Engineering Task Force R. Gagliano
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational June 25, 2010 Intended status: Informational July 15, 2010
Expires: December 27, 2010 Expires: January 16, 2011
IPv6 Deployment in Internet Exchange Points (IXPs) IPv6 Deployment in Internet Exchange Points (IXPs)
draft-ietf-v6ops-v6inixp-08.txt draft-ietf-v6ops-v6inixp-09.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 December 27, 2010. This Internet-Draft will expire on January 16, 2011.
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 13 skipping to change at page 2, line 13
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
2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3
3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6 4.1. Multicast Support and Monitoring for Neighbor
Discovery 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
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 (such as switch management, SNMP [RFC3411] support or flow
management, SNMP [RFC3411] support or flow analysis exportation) and analysis exportation) may require IPv6 as underlying layer and this
this should be assessed by the IXP operator. 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)[IEEE.P802-1Q.1998]:
logically separates IPv4 and IPv6 traffic in different VLANs. when an IXP 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's participants will configure dual-stack configuration", IXP's participants will configure dual-stack
skipping to change at page 4, line 30 skipping to change at page 4, line 31
may be made by NIRs (National Internet Registries). Unique Local may be made by NIRs (National Internet Registries). Unique Local
IPv6 Unicast Addresses ( [RFC4193] ) are normally not used in an IXP IPv6 Unicast Addresses ( [RFC4193] ) are normally not used in an IXP
LAN as global reverse DNS resolution and whois services are required. LAN as global reverse DNS resolution and whois services are required.
IXPs will normally use manual address configuration. The manual IXPs will normally use manual address configuration. The manual
configuration of IPv6 addresses allows IXP participants to replace configuration of IPv6 addresses allows IXP participants to replace
network interfaces with no need to reconfigure Border Gateway network interfaces with no need to reconfigure Border Gateway
Protocol (BGP) sessions information and it also facilitates Protocol (BGP) sessions information and it also facilitates
management tasks. The IPv6 Addressing Architecture [RFC4291] management tasks. The IPv6 Addressing Architecture [RFC4291]
requires that interface identifiers are 64 bits in size for prefixes requires that interface identifiers are 64 bits in size for prefixes
starting with binary 000, resulting in a maximum prefix length of not starting with binary 000, resulting in a maximum prefix length of
/64. Longer prefix lengths up to /127 have been used operationally. /64. Longer prefix lengths up to /127 have been used operationally.
If prefix lengths longer than 64 bits are chosen, the implications If prefix lengths longer than 64 bits are chosen, the implications
described in [RFC3627] need to be considered. A /48 prefix allows described in [RFC3627] need to be considered. A /48 prefix allows
the addressing of 65536 /64 LANs. the addressing of 65536 /64 LANs.
When selecting the use of static Interface Identifiers (IIDs), there When selecting the use of static Interface Identifiers (IIDs), there
are different options on how to fill its 64 bits (or 16 hexadecimal are different options on how to fill its 64 bits (or 16 hexadecimal
characters). A non-exhaustive list of possible IID selection characters). A non-exhaustive list of possible IID selection
mechanisms is the following: mechanisms is the following:
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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 globally o IXP may decide that LANs should (attempt to be) be globally
routed. In this case, IXP LANs monitoring from outside its routed. In this case, IXP LANs monitoring from outside its
participants' AS boundaries may be possible but the IXP LANs will participants' AS boundaries may be possible but the IXP LANs will
be vulnerable 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).
4. Multicast IPv6 4. Multicast IPv6
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 Neighbor Discovery 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 IXPs 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
skipping to change at page 9, line 36 skipping to change at page 9, line 36
[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-05 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-05
(work in progress), May 2010. (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.
[IEEE.P802-1Q.1998]
Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", IEEE Draft P802.1Q, March 1998.
[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.
[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.
 End of changes. 11 change blocks. 
15 lines changed or deleted 22 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/