This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document provides a description of IPv6 deployment in Internet Exchange Points (IXP). It includes information about the switch fabric configuration, the addressing plan options and general organizational tasks to be performed. IXP are mainly a layer 2 device (a switching fabric) and in many case the best recommendations state that the IPv6 data, control and management should not be handled differently than in IPv4.
2. Switch Fabric Configuration
3. Addressing Plan
4. Reverse DNS
5. Route Server Configuration
6. Internal and External Services support
7. IXP Policies and IPv6
8. Multicast IPv6
9. IANA Considerations
10. Security Considerations
12.1. Normative References
12.2. Informative References
§ Author's Address
Most Internet Exchange Points (IXP) work on the Layer 2 level, making the adoption of IPv6 an easy task. However, IXPs normally implement additional services such as statistics, route servers, looking glasses, broadcast control and others that may be impacted by the implementation of IPv6. This document gives guidance on the impact of IPv6 on a new or an existing IXP that may or may not fit any particular deployment. The document assumes an Ethernet switch fabric, algthouh other layer 2 canfigurations can be deployed.
An Ethernet based IXP switch fabric implements IPv6 over Ethernet as described in [RFC2464] (Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.), therefore the switching of IPv6 traffic happens in the same way as in IPv4. However, some management functions require explicit IPv6 support, particularly: switch management, SNMP support and flow analysis tools.
There are two common configurations of IXP switch ports to support IPv6:
The "independent VLAN" configuration provides a physical separation for IPv4 and IPv6 traffic. This simplifies separate analysis for IPv4 and IPv6 traffic. However, it can be more costly in both capital expenses (if new ports are needed) and operational expends. Conversely, the dual stack implementation allows a quick and capital cost-free start-up for IPv6 support in the IXP, allowing the IXP to avoid transforming untagged ports into tagged ports. In this implementation, traffic split for statistical analysis may be done using flows techniques such as in IPFIX [RFC5101] (Claise, B., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” January 2008.) considering the different ether-types (0x0800 for IPv4 and 0x86DD for IPv6).
The support for jumbo frames MTU should be evaluated. The only technical requirement for IPv6 referring link MTUs is that it needs to be greater than or equal to 1280 octets [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.). Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes, so typically this requires no change of configuration.
Regional Internet Registries (RIRs) have specific address policies to allocate Provider Independent (PI) IPv6 address to IXPs. Those allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. Depending on the country and region of operation, address allocations may be provided by NIRs (National Internet Registries).
From the allocated prefix, following the recommendations of [RFC4291] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.), a /64 prefix should be allocated for each of the exchange point Local Area Networks (LANs). A /48 prefix allows the addressing of 65536 LANs. As IXP will normally use manual address configuration, longer prefixes (/65-/127), are technically feasible but are normally discouraged because of operational practices.The manual configuration of IPv6 addresses allows IXP participants to replace network interfaces with no need to reconfigure Border Gateway Protocol (BGP) sessions information and facilitates routing management tasks.
Not only interface auto-configuration is typically disabled in an IXP LAN but also on a LAN where all addresses are manually configured, it is important to avoid the exchange of router advertisement messages described in [RFC4861] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.).
When selecting the use of static Interface Identifiers (IIDs), there are different options on how to "intelligently" fill its 64 bits (or 16 hexadecimal characters). A non exhausted list of possible IID selection mechanisms follows:
The current practice that applies to IPv4 about publishing IXP allocations to the DFZ (Default Free Zone) should also apply to the IPv6 allocation (normally a /48 prefix). Typically IXPs LANs are not globally reachable in order to avoid a Distributed Denial of Service (DDoS) attack but participant may route these prefixes inside their networks (ex. using no-export communities) to perform fault management. IXP external services (such as dns, web pages, ftp servers) needs to be globally routed and due to strict prefix length filtering could be the reason to request a shorter than /48 assignment from an RIR (ex requesting a /47 assignment and using one /48 for the IXPs LANs that is not globally routed and one /48 for the IXP external services that is globally routed).
PTR records for all addresses assigned to participants should be included in the IXP reverse zone under "ip6.arpa". DNS servers should be reachable over IPv6 transport.
IXPs may offer a Route Server service, either for Multi-Lateral Peering Agreements (MLPA) service, looking glass service or route-collection service. IPv6 support needs to be added to the BGP speaking router. The equipment should be able to transport IPv6 traffic and to support Multi-protocol BGP (MP-BGP) extensions for IPv6 address family ([RFC2545] (Marques, P. and F. Dupont, “Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing,” March 1999.) and [RFC4760] (Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4,” January 2007.)).
A good practice is to have IPv6 SAFI (Subsequent Address Family Identifiers) information carried over sessions established also on top of the IPv6 IP/TCP stack and independently of the IPv4 sessions. This configuration allows that in the event of IPv6 reachability issues to any IPv6 peer, the IPv6 session will be turned down and the IPv4 session to the same peer will not be affected. Please consider the use of MD5 [RFC2385] (Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option,” August 1998.) or IPSEC [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) to authenticate the BGP sessions.
The Router-Server or Looking Glass external service should be available for external IPv6 access, either by an IPv6 enabled web page or an IPv6 enabled console interface.
Some external services that need to have IPv6 support are Traffic Graphics, DNS, FTP, Web, Route Server and Looking Glass. Other external services such as NTP servers, or SIP Gateways need to be evaluated as well. In general, each service that is currently accessed through IPv4 or that handle IPv4 addresses should be evaluated for IPv6 support.
Internal services are also important when considering IPv6 adoption at an IXP. Such services may not deal with IPv6 traffic but may handle IPv6 addresses; that is the case of provisioning systems, logging tools and statistics analysis tools. Databases and tools should be evaluated for IPv6 support.
IXP Policies may need to be revised as any mention of IP should be clarified if it refers to IPv4, IPv6 or both. The current interpretation is that IP refers to the Internet Protocol, independently of the its version (i.e. both IPv4 and IPv6). In any case contracts and policies should be reviewed for any occurrence of IP and/or IPv4 and replace it with the appropriate IP, IPv4 and/or IPv6 language.
There are two elements that needs to be evaluated when studying IPv6 multicast in an IXP: multicast support for netighbor discovery and multicast peering.
IXPs are used to control broadcast traffic in the switching fabric in order to avoid broadcast storm by allowing limited ARP [RFC0826] (Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware,” November 1982.) traffic for address resolution. In IPv6 there is not broadcast support. ICMPv6 Neighbor Discovery [RFC4861] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) implements the following necesarry functions in an IXP switching fabric: Address Resolution, Neighbor Unreachability Detection and Duplicate Address Detection. In order to perform this functions Neighbor Solicitations and Neighbor Advertisments packets are exchange using the link-local all-nodes multicast address (FF02::1). Similarly to the ARP policy an IXP may set up a scanning device for link-local multicast traffic in order to allow only limited ICMPv6 Neighbor Solicitation and Neighbor Advertisement messages. Particularly rogue ICMPv6 route advertisements may be monitored.
For IPv6 Multicast Peering sessions (SAFI=2) the IXP may decide to use a reserved VLAN or to exchange those prefixes in the same VLAN as the unicast IPv6 sessions (SAFI=1) or the same VLAN as the multicast IPv4 sessions. When forwarding inter-domain multicast traffic PIM messages in the link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d will be present in the selected VLAN.
This memo includes no request to IANA.
This memo includes no Security Considerations.
The author would like to thank the contributions from Bill Woodcock (PCH), Martin Levy (Hurricane Electric), Carlos FriaAas of FCCN (GIGAPIX), Arien Vijn (AMS-IX) and Louis Lee (Equinix).
|[RFC0826]||Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware,” STD 37, RFC 826, November 1982 (TXT).|
|[RFC2119]||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|[RFC2385]||Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option,” RFC 2385, August 1998 (TXT, HTML, XML).|
|[RFC2460]||Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML).|
|[RFC2464]||Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks,” RFC 2464, December 1998 (TXT, HTML, XML).|
|[RFC2545]||Marques, P. and F. Dupont, “Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing,” RFC 2545, March 1999 (TXT).|
|[RFC4291]||Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 4291, February 2006 (TXT).|
|[RFC4301]||Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” RFC 4301, December 2005 (TXT).|
|[RFC4760]||Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4,” RFC 4760, January 2007 (TXT).|
|[RFC4861]||Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” RFC 4861, September 2007 (TXT).|
|[RFC5101]||Claise, B., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” RFC 5101, January 2008 (TXT).|
|[RIR_IXP_POLICIES]||Numbers Support Organization (NRO)., “RIRs Allocations Policies for IXP. NRO Comparison matrix,” 2008.|
|Rambla Rep Mexico 6125|
|Phone:||+598 2 4005633|