RFC 5963

IPv6 Deployment in Internet Exchange Points (IXPs)

📅 published August 2010, from ietf

RFC 5963: IPv6 Deployment in Internet Exchange Points (IXPs) 🦋

Okay bestie, here's the header rundown ✨ The Internet Engineering Task Force (IETF) published this, and the lead author is R. Gagliano at Cisco Systems. It's Request for Comments 5963, filed under the Informational category 💅 (so it's guidance, not a standard). The date is August 2010 🌸 and the ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so nothing gets replaced or patched by it.

Abstract ✨

Okay so this doc is basically a guide for getting IPv6 running at Internet Exchange Points (IXPs) 🧚 It covers how the switch fabric gets set up, how addresses get planned, and the general org stuff you'll need to handle. IXPs are mostly Layer 2 infrastructure, and in lots of cases the best advice is to treat the IPv6 data, control, and management planes the same way you treat IPv4. Iconic, no notes 💜

Status of This Memo

This one is not an Internet Standards Track spec. It's just published for info 🌈

It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🫶

Want the current status, any errata, or a way to send feedback? Head to http://www.rfc-editor.org/info/rfc5963 ✨

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) as they were in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this doc. Any Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💅

Table of Contents

   1. Introduction ....................................................2
   2. Switch Fabric Configuration .....................................2
   3. Addressing Plan .................................................3
   4. Multicast IPv6 ..................................................5
      4.1. Multicast Support and Monitoring for Neighbor
           Discovery at an IXP ........................................6
      4.2. IPv6 Multicast Traffic Exchange at an IXP ..................6
   5. Reverse DNS .....................................................7
   6. Route-Server ....................................................7
   7. External and Internal Support ...................................7
   8. IXP Policies and IPv6 ...........................................8
   9. Security Considerations .........................................8
  10. Acknowledgements ...............................................8
  11. Informative References .........................................8

1. Introduction ✨

Most IXPs run at Layer 2, which makes adopting IPv6 pretty easy 🦋 BUT (sorry, I'm yelling) IXPs usually run extra services like statistics, route servers, looking glasses, and broadcast controls, and those can get affected when you turn on IPv6. This doc walks through exactly how IPv6 affects a new or existing IXP. It assumes an Ethernet switch fabric, though other Layer 2 setups could also be deployed 💖

2. Switch Fabric Configuration ✨

An Ethernet-based IXP switch fabric runs IPv6 over Ethernet as described in [RFC2464]. So IPv6 traffic gets switched the same way IPv4 traffic does 🌸 Some management stuff, though (like switch management, SNMP (Simple Network Management Protocol) [RFC3411] support, or flow analysis exportation), might need IPv6 as an underlying layer, and the IXP operator should figure that out 🧚

There are two common ways to set up IXP switch ports for IPv6 💅

  1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6 traffic share a common LAN. No extra configuration is required in the switch. 🌈
  2. independent VLAN (Virtual Local Area Network)[IEEE.P802-1Q.1998]: when an IXP logically separates IPv4 and IPv6 traffic in different VLANs. 🦋

In both setups, IPv4 and IPv6 traffic can either share one physical port or use independent physical ports. Independent ports can get pricey, both in capital expenses (since you need new ports) and operational expenses 💸

When IPv4 and IPv6 share the same physical port, the participants' interface configs might need some tweaks. If the IXP goes with the "dual-stack configuration", participants configure dual-stack interfaces 🫶 If it goes with the "independent VLAN configuration", participants have to pass one additional VLAN tag across the interconnection. And if the IXP didn't use VLAN tagging before, it should set tagging up. The previously configured LAN can keep going untagged as a "native VLAN", or it can move over to a tagged VLAN 💜

The "independent VLAN" setup gives a logical split between IPv4 and IPv6 traffic, which makes separate statistical analysis way simpler ✨ The "dual-stack" setup, on the other hand, would need flow techniques like IPFIX (IP Flow Information Export) [RFC5101] if you want separate stats for IPv4 and IPv6. Those techniques classify traffic by its Ethertypes: 0x0800 for IPv4, 0x0806 for ARP (Address Resolution Protocol), and 0x86DD for IPv6 🔥

The only technical requirement for IPv6 when it comes to link MTUs is that they be greater than or equal to 1280 octets [RFC2460]. And the MTU for every LAN in an IXP should be well known by all its participants 🎀

3. Addressing Plan ✨

Regional Internet Registries (RIRs) have specific address policies for giving Provider Independent (PI) IPv6 addresses to IXPs. Those allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. Depending on the country and region, NIRs (National Internet Registries) might handle the address assignments 🌸 Unique Local IPv6 Unicast Addresses ([RFC4193]) are normally not used on an IXP LAN, because global reverse DNS resolution and whois services are required 🙈

IXPs normally go with manual address configuration. Manual config lets IXP participants swap out network interfaces without having to reconfigure their Border Gateway Protocol (BGP) session info, and it also makes management way easier 🧚 The IPv6 Addressing Architecture [RFC4291] says interface identifiers are 64 bits in size for prefixes that don't start with binary 000, which gives a maximum prefix length of /64. Longer prefix lengths, up to /127, have been used in the real world 💅

If you pick prefix lengths longer than 64 bits, you need to consider the implications described in [RFC3627]. Also, a /48 prefix lets you address 65536 /64 LANs 🦋

When you choose static Interface Identifiers (IIDs), there are different ways to fill those 64 bits (that's 16 hexadecimal characters). Here's a non-exhaustive list of IID selection mechanisms 👑

  1. Some IXPs like to put the decimal encoding of each participant's ASN (Autonomous System Number) inside their IPv6 address. The ASN decimal number gets used as the BCD (binary code decimal) encoding of the upper part of the IID, like in this example:
IXP LAN prefix: 2001:db8::/64
ASN: 64496
IPv6 Address: 2001:db8:0000:0000:0000:0006:4496:0001/64 or its
equivalent representation 2001:db8::6:4496:1/64

In this example, the participant's ASN is right-justified starting from the 112th bit. Keep in mind that 32-bit ASNs need a maximum of 10 characters. With this setup, up to 2^16 IPv6 addresses can be configured per ASN 🌈

  1. BCD encoding is more "human-readable", but some IXPs prefer the hexadecimal encoding of the ASN number as the upper part of the IID, like this:
IXP LAN prefix: 2001:db8::/64
ASN: 64496 (DEC) or fbf0 (HEX)
IPv6 Address: 2001:db8:0000:0000:0000:0000:fbf0:0001/64 or its
equivalent representation 2001:db8::fbf0:1/64

In this case, you'll need a maximum of 8 characters to represent 32-bit ASNs 🍓

  1. A third way to statically assign IPv6 addresses on an IXP LAN is to tie some portion of a participant's IPv6 address to its IPv4 address. In the example below, the last four decimals of the IPv4 address get copied into the last hexadecimals of the IPv6 address. The decimal number is used as the BCD encoding for the last three characters of the IID:
IXP LAN prefix: 2001:db8::/64
IPv4 Address: 192.0.2.123/23
IPv6 Address: 2001:db8:2::123/64
  1. Another approach might be based on the IXP's ID for that participant 💜

IPv6 prefixes for IXP LANs are usually publicly well known and come from dedicated IPv6 blocks that the different RIRs reserve for IXP assignments. These blocks are typically only meant for addressing the exchange fabric, and DFZ (Default Free Zone) operators may filter them out 🫶 When you're thinking about routing the IXP LANs, there are two options:

  • IXPs may decide that LANs should not be globally routed. This limits where a Denial-of-Service (DoS) attack can come from, keeping it within the participants' AS (Autonomous System) boundaries. In this setup, participants can route these prefixes inside their networks (for example, using BGP no-export communities or by routing the IXP LANs within the participants' IGP) to do fault management. But with this setup, you can't monitor the IXP LANs from outside the participants' AS boundaries 🙈
  • IXP may decide that LANs should (attempt to) be globally routed. In that case, IXP LAN monitoring from outside the participants' AS boundaries may be possible, but the IXP LANs will be vulnerable to DoS from outside those boundaries 😭

Also, IXP external services (like DNS, web pages, and FTP servers) need to be globally routed. Those should be addressed from separate address blocks, either from upstream providers' address space or from separate independent assignments. Strict prefix length filtering could be a reason to request more than one /48 assignment from a RIR. For example, you could request one /48 for the IXP LANs that won't be globally routed, plus a different, non-IXP /48 for the IXP external services that will be globally routed 💅

4. Multicast IPv6 ✨

Okay, so there are two elements to check when you're looking at IPv6 multicast in an IXP: multicast support for neighbor discovery, and multicast peering 🌸

4.1. Multicast Support and Monitoring for Neighbor Discovery at an IXP

okay so IXPs usually keep broadcast traffic under control across the switching fabric to avoid broadcast storms 🌩️, which is why they only allow limited ARP [RFC0826] traffic for address resolution. IPv6 has no broadcast support, so IXPs may want to control multicast traffic in each LAN instead 🫶. ICMPv6 Neighbor Discovery [RFC4861] covers the functions an IXP switching fabric needs: Address Resolution, Neighbor Unreachability Detection, and Duplicate Address Detection ✨. To do those jobs, Neighbor Solicitation and Neighbor Advertisement packets are exchanged using the link-local all-nodes multicast address ff02::1 and/or the 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 initialize their interfaces by joining their solicited-node multicast addresses using either Multicast Listener Discovery (MLD) [RFC2710] or MLDv2 [RFC3810]. MLD messages may be sent to the matching group address: ff02::2 (MLD) or ff02::16 (MLDv2) 🎀.

Depending on the addressing plan the IXP picks, a solicited-node multicast group may be shared by a subset of participants, and which ones depends on how the last three octets of the addresses are chosen. In Section 3, example 1, only participants with ASNs that share the same last two digits end up in the same solicited-node multicast group 🧚.

Similar to the ARP policy, an IXP may limit multicast traffic across the switching fabric so that only ICMPv6 Neighbor Solicitation, Neighbor Advertisement, and MLD messages get through 💅. Configuring default routes in an IXP LAN without an agreement between the parties is normally against IXP policies, so please don't do it 🙈. ICMPv6 Router Advertisement packets should neither be issued nor accepted by routers connected to the IXP. Where possible, the IXP operator should block link-local RA (Router Advertisement) packets using IPv6 RA-GUARD [V6OPS-RA-GUARD] . If that's not possible, the IXP operator should monitor the exchange for rogue Router Advertisement packets as described in [V6OPS-ROGUE-RA] . 👀

4.2. IPv6 Multicast Traffic Exchange at an IXP

For IPv6 multicast traffic exchange, an IXP has three options: reuse the LAN it uses for unicast IPv6 traffic, reuse the LAN it uses for IPv4 multicast traffic, or set up a dedicated LAN just for IPv6 multicast traffic 🦋. The reason for a dedicated LAN is to keep unwanted multicast traffic away from participants that don't have multicast support. Protocol Independent Multicast (PIM) [RFC4601] messages will be sent to the link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the selected LAN, and they should be allowed 🌸. Implementing IPv6 PIM snooping lets only the participants associated with a particular group receive that group's multicast traffic 🔥.

BGP reachability information for the IPv6 multicast address family (SAFI=2) is normally exchanged using MP-BGP (Multi-Protocol BGP) [RFC4760], and it's used for Reverse Path Forwarding (RPF) lookups performed by the IPv6 PIM 🧠. If a dedicated LAN is configured for IPv6 multicast traffic exchange, reachability information for the IPv6 multicast address family should be carried in new BGP sessions ✨. ICMPv6 Neighbor Discovery should be allowed in the IPv6 multicast LAN too, as described in the previous paragraph 💜.

5. Reverse DNS 🌈

The inclusion of PTR records for all addresses assigned to participants in the IXP reverse zone under "ip6.arpa" makes troubleshooting way easier, especially with tools like traceroute 🔍. If reverse DNS is configured, DNS servers should be reachable over IPv6 transport for complete IPv6 support 💖.

6. Route-Server 🛣️

IXPs may offer a route-server service, for Multi-Lateral Peering Agreements (MLPA), 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 support MP-BGP extensions for the IPv6 address family ([RFC2545] and [RFC4760]) 🫶.

A good practice is to configure all BGP sessions used to exchange IPv6 network information with IPv6 data transport. This setup makes sure that both network reachability information and generic packet data transport use the same transport plane, which is so clean 🧼. Because the IPv6 space is so huge, limiting the maximum number of IPv6 prefixes in every session should be studied 🤔.

External services should be available for external IPv6 access, either through an IPv6 enabled web page or an IPv6 enabled console interface 🌐.

7. External and Internal Support 🧩

Some external services that need 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, every service that is currently accessed through IPv4, or that handles IPv4 addresses, should be evaluated for IPv6 support 💅.

Internal services matter a lot too when an IXP is thinking about IPv6 adoption ✨. They may not deal with IPv6 traffic, but they may still handle IPv6 addresses. Think provisioning systems, logging tools, and statistics analysis tools 📚. Databases and tools should be evaluated for IPv6 support.

8. IXP Policies and IPv6 📜

IXP policies and contracts should be revised, and any mention of IP should be clarified to say whether it refers to IPv4, IPv6, or both 💜. Policies for IPv6 traffic monitoring and filtering may be in place, as described in Section 4 🛡️.

9. Security Considerations 🚨

This memo includes references to procedures for monitoring and/or avoiding particular ICMPv6 traffic at IXPs' LANs. None of these procedures prevent Ethernet loops caused by mischief in the LAN. 💀 Bestie, this part is serious.

The document also mentions how to limit IPv6 DoS attacks to the IXP switch fabric by not globally announcing the IXP LANs prefix 🔒.

10. Acknowledgements 🫶

The author would like to thank the contributions from Alain Aina, Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont, and Louis Lee 💖🙌.

11. Informative References 📚

[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
           converting network protocol addresses to 48.bit Ethernet
           address for transmission on Ethernet hardware", STD 37,
           RFC 826, November 1982.

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

[RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
           Networks", RFC 2464, December 1998.

[RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
           Extensions for IPv6 Inter-Domain Routing", RFC 2545,
           March 1999.

[RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
           Listener Discovery (MLD) for IPv6", RFC 2710,
           October 1999.

[RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
           Architecture for Describing Simple Network Management
           Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
           December 2002.

[RFC3627]  Savola, P., "Use of /127 Prefix Length Between Routers
           Considered Harmful", RFC 3627, September 2003.

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

[RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
           Addresses", RFC 4193, October 2005.

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

[RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
           "Protocol Independent Multicast - Sparse Mode (PIM-SM):
           Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
           "Multiprotocol Extensions for BGP-4", RFC 4760,
           January 2007.

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

[RFC5101]  Claise, B., "Specification of the IP Flow Information
           Export (IPFIX) Protocol for the Exchange of IP Traffic
           Flow Information", RFC 5101, January 2008.

[RIR_IXP_POLICIES]
           Numbers Resource Organization (NRO)., "RIRs Allocations
           Policies for IXP. NRO Comparison matrix", 2009,
           <http://www.nro.net/documents/comp-pol.html#3-4-2>.

[V6OPS-RA-GUARD]
           Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
           Mohacsi, "IPv6 RA-Guard", Work in Progress, June 2010.

[V6OPS-ROGUE-RA]
           Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
           Problem Statement", Work in Progress, June 2010.

Author's Address ✈️

Roque Gagliano
Cisco Systems
Avenue des Uttins 5
Rolle,   1180
Switzerland

EMail: rogaglia@cisco.com

That's the whole RFC, bestie! 🌈💖✨ Literally a masterpiece of IXP-land drama.

📦 where this page comes from