IXPs

Author: Roque Gagliano, LACNIC.

Abstract:

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 (the switching fabric) and in many case the best recommendations state that IPv6 traffic and management should not be handled differently than in IPv4.

Index:

1- Introduction.
2- Switch fabric Configuration.
3- Addressing.
4- Reverse DNS.
5- Route Server Configuration.
6- Internal and External Services support.
7- IXP Policies and IPv6.
8- Multicast IPv6.
9- Acknowledge.
10- References.

1- Introduction

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. In many case the best recommendations state that IPv6 traffic and management should not be handled differently than in IPv4. This document gives some tips and guidance on the impact of IPv6 on a new or existing IXP that may or may not fit any particular implementation. As of late-2008 there are plenty of operational IPv6 IXÕs in the world and hence their practical experience has been incorporated into this document. This document assumes an Ethernet switch fabric, algthouh other layer 2 devices can be deployed.

2- Switch fabric Configuration

The switch fabric is a Layer 2 device, therefore the switching of IPv6 traffic happens in the same way as in IPv4. However, some functionalities in the management plane require support for IPv6 extensions. Such functionalities may include: switch management, SNMP support and flow analysis tools.

There are two common configurations of IXP switch ports to support IPv6:

• dual stack VLAN: both IPv4 and IPv6 traffic share a common VLAN. No extra configuration is required in the switch. Typically participants will also configure dual stack interfaces in this scenario but independent port can be an option.
• independent VLAN: one or many IPv6 VLANs is created for IPv6 traffic. If IXP participants are already employing VLAN tagging on the interfaces of their routers which face the IXP switch, this only requires passing additional VLAN tags across the interconnection. If participants are using untagged interconnections with the IXP switch and wish to continue doing so, they will need to use a separate physical port to access the IPv6-specific VLAN.

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 expends (if new ports are needed) and operational expends.

On the other side, the dual stack implementation allows a quick and capital cost-free start-up for IPv6 support in the IXP, and allows the IXP to avoid transforming access mode ports into tagged ports. In this implementation, traffic split for statistical analysis may be done using flows techniques 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 the MTU is that it needs to be greater than or equal to 1280 bytes [RFC 2460]. Typical option for MTU size are: 1500bytes, 4470bytes or 9216bytes).

3- Addressing

All five Regional Internet Registries (RIRs) have specific address policies to assign Provider Independent (PI) IPv6 address to IXPs. These assignments are usually /48 prefixes [RIR_IXP_POLICIES]. Depending on the country and region of operation, address allocations may be provided by NIR (National Internet Registries).

Links to the RIR websites and their coverage regions can be found online at: http://www.nro.net/about/internet-registries.html

From the assigned /48 prefix, following the recommendations of RFC 4291 [RFC4291], a /64 prefix should be assigned for each of the exchange point Local Area Networks (LANs). A /48 prefix allows the addressing of 65536 LANs. Longer prefixes (/65-/127), are technically feasible using static address configuration, but should be avoided, in order to keep EUI-64 and CGA (Cryptographically Generated Addresses) [RFC3972]. In this document we will assume a /64 prefix in every LAN.

The common practice for Interface Identifiers (IID) configuration is to use static configuration, disallowing auto-configuration on every interface. Also, on a LAN where all its participants are typically routers, itÕs important that every node has itÕs router advertisement protocol [RFC4861] turned off. The goal is that none of the remaining routers configure it-selves as a default ICMPv6 route by accident. A scanning device can be set up at the IXP LANs to monitor link-local multicast traffic (addresses ff02::/16), allowing only ICMPv6 Neighbor Solicitation and Neighbor Advertisement messages. Particularly rogue ICMPv6 route advertisements should be monitored.

When selecting the use of static 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:

1. Some IXPs like to include the participants' ASN number decimal encoding inside each IPv6 address. The ASN decimal number is used as the BCD (binary code decimal) encoding of the upper part of the IID such as shown in this example:
   
   IXP LAN prefix: 2001:DB8::/64
   ASN: 64496
   IPv6 Address: 2001:DB8::6449:6000:0000:0001/64 or its equivalent representation 2001:DB8::6:4496:1/64
   
   Please remember that 32 bits ASNs requires a maximum of 10 characters, as 16 characters are available, up to 2^6 IPv6 addresses can be configured per ASN.
    
2. Although BCD encoding is more "human-readable", some IXPs prefer to use the hexadecimal encoding of the ASNs number as the upper part of the IID as follow:
   
   IXP LAN prefix: 2001:DB8::/64
   ASN: 64496 (DEC) or FBF0 (HEX)
   IPv6 Address: 2001:DB8::0000:FBF0:0000:0001/64 or its equivalent representation 2001:DB8::FBF0:0:1/64
   
   The four zero before the ASN (bits 63-96) will be used by 32 bits ASNs.
    
3. A third scheme for statically assigning IPv6 addresses on an IXP LAN could be to relate some portion of a participant's IPv6 address to its IPv4 address. In the following example, the last three decimals of the IPv4 address are copied to the last hexadecimals of the IPv6 address, using the decimal number as the BCD encoding for the last three characters of the IID such as in the following example:
   
   IXP LAN prefix: 2001:DB8::/64
   IPv4 Address: 240.0.20.132/23
   IPv6 Address: 2001:DB8::132/64
    
4. A forth approach might be based on IXP internal ID for that participant.

The current practice that applies to IPv4 about publishing IXP allocations to the DFZ (default free zone) also applies to the IPv6 allocation (normally a /48 prefix). IXP external services (such as dns, web pages, ftp servers) could be part of this prefix. Beware that a /48 may not be routed globally due to strict prefix length filtering.

4- Reverse DNS

PTR records for all addresses assigned to participants should be included in the IXP reverse zone under "ip6.arpa".

5- Route Server Configuration

Some IXPs may offer a Route Server service, either for Multi-Lateral Peering Agreements (MLPA) or for a looking glass service. IPv6 support needs to be added to the router used as BGP end point. The equipment should be able to transport IPv6 traffic and to support Multi-protocol BGP (MP-BGP) extensions for IPv6 address family (RFC 2545 and RFC 4760).

A good practice is to have IPv6 reachability 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 specific session will be turned down (state changes to "Active") and the IPv4 session to the same peer will not be affected. Please consider the use of MD5 (even better IPSEC) 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 server.

6- Internal and External Services support

We already mentioned some external services that need to have IPv6 support, such as Traffic Graphics, DNS, FTP, Web 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 accessed through IPv4 or that handle IPv4 addresses should be compatible with IPv6.

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 needs to be evaluated to determinate its IPv6 support level.

7- IXP Policies and IPv6

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.

Specific IPv6 policies may be needed, particularly in IXP that control rogue ICMPv6 Router Advertisements and link-local multicast traffic from its participants or for MLPA (Multi Lateral Peering Agreement).

As with IPv4, the very success of an IPv6 IX is measured by the number of participants and/or the amount of traffic flowing across the switch. In order to acquire participants, itÕs important to market the fact that IPv6 is available on the IX.
Marketing is also important. The following steps will help promote IPv6 peering and traffic on an IX community:

• Announce the existence of IPv6 on the IX via the home page and if possible via a press release.
• Announce the existence of IPv6 via appropriate mailing lists including as an email to all participants.
• If the website lists participants and their ASN and allocated IPv4 address, more to include the IPv6 address.
• Review the existing participants ASNÕs and see if their ASN shows up in the IPv6 global routing tables; if so, then contact directly to promote the enabling of IPv6 peering at your IX.
• Include IPv6 information at the peeringdb.com database or other websites (such as napla.lacnic.net or pch.net).

8- Multicast IPv6

Multicast IPv6 is not different from an IXP perspective than Multicast IPv4. Again, the IXP may decide to use a reserved VLAN for multicast traffic or to exchange that traffic in the same VLAN as the unicast traffic. As it was already mentioned, link-local multicast traffic could be monitored to detect bad behaviors or configuration problems. This traffic should be reduced to ICMPv6 neighbor discovery [RFC4861] and MLD (Multicast Listener Discovery) Protocol (MLDv2) [RFC 3810].

9 - Acknowledges

I would like to thank the contributions from Martin Levy (Hurricane Electric), Carlos Friaas of FCCN (GIGAPIX), Arien Vijn (AMS-IX), Louis Lee (Equinix) and Bill Woodcock (PCH).

10 - References

[RIR_IXP_POLICIES] RIRs Allocations Policies for IXP. NRO Comparison matrix: http://www.nro.net/documents/comp-pol.html#3-4-2.

[RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC3810] L. Costa, Ed, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.