From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5963.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc5963.txt (limited to 'doc/rfc/rfc5963.txt') diff --git a/doc/rfc/rfc5963.txt b/doc/rfc/rfc5963.txt new file mode 100644 index 0000000..7f74c65 --- /dev/null +++ b/doc/rfc/rfc5963.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Gagliano +Request for Comments: 5963 Cisco Systems +Category: Informational August 2010 +ISSN: 2070-1721 + + + IPv6 Deployment in Internet Exchange Points (IXPs) + +Abstract + + This document provides guidance on IPv6 deployment in Internet + Exchange Points (IXPs). It includes information regarding the switch + fabric configuration, the addressing plan and general organizational + tasks that need to be performed. IXPs are mainly a Layer 2 + infrastructure, and, in many cases, the best recommendations suggest + that the IPv6 data, control, and management plane should not be + handled differently than in IPv4. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5963. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Gagliano Informational [Page 1] + +RFC 5963 IPv6 in IXPs August 2010 + + +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 Internet Exchange Points (IXPs) work at 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, and broadcast controls that may be impacted by the + implementation of IPv6. This document clarifies the impact of IPv6 + on a new or an existing IXP. The document assumes an Ethernet switch + fabric, although other Layer 2 configurations could be deployed. + +2. Switch Fabric Configuration + + An Ethernet-based IXP switch fabric implements IPv6 over Ethernet as + described in [RFC2464] . Therefore, the switching of IPv6 traffic + happens in the same way as in IPv4. However, some management + functions (such as switch management, SNMP (Simple Network Management + Protocol) [RFC3411] support, or flow analysis exportation) may + require IPv6 as an underlying layer, and this should be assessed by + the IXP operator. + + There are two common configurations of IXP switch ports to support + 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. + + + + +Gagliano Informational [Page 2] + +RFC 5963 IPv6 in IXPs August 2010 + + + In both configurations, IPv6 and IPv4 traffic can either share a + common physical port or use independent physical ports. The use of + independent ports can be more costly in both capital expenses (as new + ports are needed) and operational expenses. + + When using the same physical port for both IPv4 and IPv6 traffic, + some changes may be needed at the participants' interfaces' + configurations. If the IXP implements the "dual-stack + configuration", IXP's participants will configure dual-stack + interfaces. On the other hand, if the IXP implements the + "independent VLAN configuration", IXP participants are required to + pass one additional VLAN tag across the interconnection. In this + case, if the IXP did not originally use VLAN tagging, VLAN tagging + should be established and the previously configured LAN may continue + untagged as a "native VLAN" or be transitioned to a tagged VLAN. The + "independent VLAN" configuration provides a logical separation of + IPv4 and IPv6 traffic, simplifying separate statistical analysis for + IPv4 and IPv6 traffic. Conversely, the "dual-stack" configuration + (when performing separate statistical analysis for IPv4 and IPv6 + traffic) would require the use of flow techniques such as IPFIX (IP + Flow Information Export) [RFC5101] to classify traffic based on the + different Ethertypes (0x0800 for IPv4, 0x0806 for ARP (Address + Resolution Protocol), and 0x86DD for IPv6). + + The only technical requirement for IPv6 referring link MTUs is that + 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 + participants. + +3. Addressing Plan + + Regional Internet Registries (RIRs) have specific address policies to + assign Provider Independent (PI) IPv6 addresses to IXPs. Those + allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. + Depending on the country and region of operation, address assignments + may be made by NIRs (National Internet Registries). Unique Local + IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP + LAN as global reverse DNS resolution and whois services are required. + + IXPs will normally use manual address configuration. 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 it also facilitates + management tasks. The IPv6 Addressing Architecture [RFC4291] + requires that interface identifiers are 64 bits in size for prefixes + not starting with binary 000, resulting in a maximum prefix length of + /64. Longer prefix lengths up to /127 have been used operationally. + + + + +Gagliano Informational [Page 3] + +RFC 5963 IPv6 in IXPs August 2010 + + + If prefix lengths longer than 64 bits are chosen, the implications + described in [RFC3627] need to be considered. A /48 prefix allows + the addressing of 65536 /64 LANs. + + When selecting the use of static Interface Identifiers (IIDs), there + are different options on how to fill its 64 bits (or 16 hexadecimal + characters). A non-exhaustive list of possible IID selection + mechanisms is the following: + + 1. Some IXPs like to include the decimal encoding of each + participant's ASN (Autonomous System Number) inside its + correspondent 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:0000:0000:0000:0006:4496:0001/64 or its + equivalent representation 2001:db8::6:4496:1/64 + + In this example, we are right-justifying the participant's ASN + number from the 112nd bit. Remember that 32-bit ASNs require a + maximum of 10 characters. With this example, up to 2^16 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:0000:0000:0000:fbf0:0001/64 or its + equivalent representation 2001:db8::fbf0:1/64 + + In this case, a maximum of 8 characters will be needed to + represent 32-bit ASNs. + + 3. A third scheme for statically assigning IPv6 addresses on an IXP + LAN could be to relate some portions of a participant's IPv6 + address to its IPv4 address. In the following example, the last + four 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: + + + +Gagliano Informational [Page 4] + +RFC 5963 IPv6 in IXPs August 2010 + + + * IXP LAN prefix: 2001:db8::/64 + + * IPv4 Address: 192.0.2.123/23 + + * IPv6 Address: 2001:db8:2::123/64 + + 4. A fourth approach might be based on the IXPs ID for that + participant. + + IPv6 prefixes for IXP LANs are typically publicly well known and + taken from dedicated IPv6 blocks for IXP assignments reserved for + this purpose by the different RIRs. These blocks are usually only + meant for addressing the exchange fabric, and may be filtered out by + DFZ (Default Free Zone) operators. When considering the routing of + the IXP LANs two options are identified: + + 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) + attack to its participants' AS (Autonomous System) boundaries. In + this configuration, participants may route these prefixes inside + their networks (e.g., using BGP no-export communities or routing + the IXP LANs within the participants' IGP) to perform fault + management. Using this configuration, the monitoring of the IXP + LANs from outside of its participants' AS boundaries is not + possible. + + o IXP may decide that LANs should (attempt to) be globally routed. + In this case, IXP LANs monitoring from outside its participants' + AS boundaries may be possible, but the IXP LANs will be vulnerable + to DoS from outside of those boundaries. + + Additionally, possible IXP external services (such as DNS, web pages, + FTP servers) need to be globally routed. These should be addressed + from separate address blocks, either from upstream providers' address + space or separate independent assignments. Strict prefix length + filtering could be a reason for requesting more than one /48 + 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 + /48 assignment for the IXP external services that will be globally + routed). + +4. Multicast IPv6 + + There are two elements that need to be evaluated when studying IPv6 + multicast in an IXP: multicast support for neighbor discovery and + multicast peering. + + + + + +Gagliano Informational [Page 5] + +RFC 5963 IPv6 in IXPs August 2010 + + +4.1. Multicast Support and Monitoring for Neighbor Discovery at an IXP + + IXPs typically control broadcast traffic across the switching fabric + in order to avoid broadcast storms by only allowing limited ARP + [RFC0826] traffic for address resolution. In IPv6 there is not + broadcast support, but IXPs may intend to control multicast traffic + in each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements + the following necessary functions in an IXP switching fabric: Address + Resolution, Neighbor Unreachability Detection, and Duplicate Address + Detection. In order to perform these functions, Neighbor + Solicitation and Neighbor Advertisement packets are exchanged using + 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: + 0:0:0:0:1:ffff:ffff). As described in [RFC4861], routers will + 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 corresponding + group address: ff02::2 (MLD) or ff02::16 (MLDv2). Depending on the + addressing plan selected by the IXP, each solicited-node multicast + group may be shared by a sub-set of participants' conditioned by how + the last three octets of the addresses are selected. In Section 3, + example 1, only participants with ASNs with the same last two digits + are going to share the same solicited-node multicast group. + + Similar to the ARP policy, an IXP may limit multicast traffic across + the switching fabric in order to only allow ICMPv6 Neighbor + Solicitation, Neighbor Advertisement, and MLD messages. Configuring + default routes in an IXP LAN without an agreement between the parties + is normally against IXP policies. 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 this is 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 may decide to use either + the same LAN being used for unicast IPv6 traffic exchange, the same + LAN being used for IPv4 Multicast traffic exchange, or a dedicated + LAN for IPv6 Multicast traffic exchange. The reason for having a + dedicated LAN for multicast is to prevent unwanted multicast traffic + from reaching participants that do not 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 should be allowed. Implementing IPv6 PIM + snooping will allow only the participants associated with a + + + +Gagliano Informational [Page 6] + +RFC 5963 IPv6 in IXPs August 2010 + + + particular group to receive its multicast traffic. BGP reachability + information for IPv6 multicast address family (SAFI=2) is normally + exchanged using MP-BGP (Multi-Protocol BGP) [RFC4760] and is used for + Reverse Path Forwarding (RPF) lookups performed by the IPv6 PIM. If + a dedicated LAN is configured for Multicast IPv6 traffic exchange, + reachability information for IPv6 Multicast address family should be + carried in new BGP sessions. ICMPv6 Neighbor Discovery should be + allowed in the Multicast IPv6 LAN 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" facilitates + troubleshooting, particularly when using tools such as 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, 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 MP-BGP extensions for IPv6 address family + ([RFC2545] and [RFC4760]). + + A good practice is that all BGP sessions used to exchange IPv6 + network information are configured using IPv6 data transport. This + configuration style ensures that both network reachability + information and generic packet data transport use the same transport + plane. Because of the size of the IPv6 space, limiting the maximum + number of IPv6 prefixes in every session should be studied. + + External services should be available for external IPv6 access, + either by an IPv6 enabled web page or an IPv6 enabled console + interface. + +7. External and Internal Support + + 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. + + + + + +Gagliano Informational [Page 7] + +RFC 5963 IPv6 in IXPs August 2010 + + + 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. + +8. IXP Policies and IPv6 + + IXP policies and contracts should be revised as any mention of IP + should be clarified if 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. The + document also mentions how to limit IPv6 DoS attacks to the IXP + switch fabric by not globally announce 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. + + + + +Gagliano Informational [Page 8] + +RFC 5963 IPv6 in IXPs August 2010 + + + [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, + . + + + + + + +Gagliano Informational [Page 9] + +RFC 5963 IPv6 in IXPs August 2010 + + + [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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gagliano Informational [Page 10] + -- cgit v1.2.3