Internet Engineering Task Force R. Gagliano Internet-Draft LACNIC Intended status: Informational September 08, 2009 Expires: March 12, 2010 IPv6 Deployment in Internet Exchange Points (IXPs) draft-ietf-v6ops-v6inixp-02.txt Status of this Memo 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 March 12, 2010. Copyright Notice 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. Abstract This document provides a guide for IPv6 deployment in Internet Exchange Points (IXP). It includes information regarding the switch fabric configuration, the addressing plan and general organizational Gagliano Expires March 12, 2010 [Page 1] Internet-Draft IPv6 in IXPs September 2009 tasks to be performed. IXPs are mainly a layer 2 infrastructure and in many case the best recommendations state that the IPv6 data, control and management plane should not be handled differently than in IPv4. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Route Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. External and Internal support . . . . . . . . . . . . . . . . 7 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Gagliano Expires March 12, 2010 [Page 2] Internet-Draft IPv6 in IXPs September 2009 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 and broadcast control that may be impacted by the implementation of IPv6. This document clarifies 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, although other layer 2 configurations can 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 require explicit IPv6 support (such as switch management, SNMP support and flow analysis exportation) 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: both IPv4 and IPv6 traffic share a common LAN. No extra configuration is required in the switch. In this scenario, participants will typically configure dual stack interfaces, although independent port can be an option. 2. independent LAN: an exclusive IPv6 LAN is created for IPv6 traffic. If IXP participants are already using Virtual LAN (VLAN) tagging on their routers interfaces that are facing the IXP switch, this only requires passing one additional VLAN tag across the interconnection. If participants are using untagged interconnections with the IXP switch and wish to continue doing so, they will need to facilitate a separate physical port to access the IPv6-specific LAN. The "independent LAN" configuration provides a physical separation for IPv4 and IPv6 traffic simplifying 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 IPFIX [RFC5101] considering the different ether-types (0x0800 for IPv4, 0x0806 for ARP and 0x86DD for Gagliano Expires March 12, 2010 [Page 3] Internet-Draft IPv6 in IXPs September 2009 IPv6). The only technical requirement for IPv6 referring link MTUs is that they need to be greater than or equal to 1280 octets [RFC2460]. Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes. Consequently, no MTU changes are typically required. The MTU size for every LAN in an IXP should be well know by all its participants. 3. Addressing Plan 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). Unique Local IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP LAN as global reverse DNS resolution and whois services are required. From the allocated prefix, following the recommendations of [RFC4291], a /64 prefix should be allocated for each of the exchange point IPv6 enabled 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 it also facilitates management tasks. 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 is the following: 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::0000:0006:4496:0001/64 or its equivalent representation 2001:DB8::6:4496:1/64 In this example we are right justifying the participant' ASN Gagliano Expires March 12, 2010 [Page 4] Internet-Draft IPv6 in IXPs September 2009 number from the 112nd bit. Remember that 32 bits 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:FBF0:0001/64 or its equivalent representation 2001:DB8::FBF0:1/64 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 fourth approach might be based on the IXPs ID for that participant. 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 (e. g. using BGP no-export communities or routing the IXP LANs within the participants' IGP) 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 more than one /48 assignment from a RIR (i.e. requesting one /48 for the IXPs LANs that is not globally routed and a different /48 for the IXP external services that is globally routed). IPv6 prefixes for IXP LAN's are typically publicly well known. Gagliano Expires March 12, 2010 [Page 5] Internet-Draft IPv6 in IXPs September 2009 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. 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 IXP 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 exchange 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 its interfaces by joining its 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 octects of the addresses are selected. In Section 3 example 1, only participants with ASNs with the same two last digits are going to share the same solocited-node multicast group. Similarly to the ARP policy an IXP may limit multicast traffic accross 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 within 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 packets using IPv6 RA-Guard. If this is not possible, the IXP operator should monitor the exchange for rogue Router Advertisement packets. 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 to reach participants that do not have multicast support. Protocol Independent Multicast [RFC4601] messages will be sent to the the link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the selected LAN and should be allowed. Implementing IPv6 PIM snooping Gagliano Expires March 12, 2010 [Page 6] Internet-Draft IPv6 in IXPs September 2009 will allow only the participants associated to a particular group to receive its multicast traffic. BGP reachability information for IPv6 multicast address-family (SAFI=2) is normally exchanged using MP-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 PTR records for all addresses assigned to participants should be included in the IXP reverse zone under "ip6.arpa" for troubleshooting purposes. 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 Multi-protocol BGP (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 as both network reachability information and generic packet data transport use the same transport plane, in the event of IPv6 reachability problems between IPv6 peers, the IPv6 BGP session may be terminated independently of any IPv4 sessions. The use of MD5 [RFC2385] or IPSEC [RFC4301] to authenticate the BGP sessions and the use of GTSM (The Generalized TTL Security Mechanism) [RFC3682] should be considered. 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. 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 Gagliano Expires March 12, 2010 [Page 7] Internet-Draft IPv6 in IXPs September 2009 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. 8. IXP Policies and IPv6 IXP Policies and contracts should be be revised as any mention of IP should be clarified if it refers to IPv4, IPv6 or both. 9. IANA Considerations This memo includes no request to IANA. 10. Security Considerations This memo includes information on practices at IXPs for monitoring and/or avoiding broadcast storms in IXP LANs caused by IPv6 multicast traffic. It also mentions avoiding IPv6 DDoS attacks to the IXP switching fabric by not globally announce the IXP LANs prefix. 11. Acknowledgements The author would like to thank the contributions from Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, Bill Woodcock, Carlos Frias, Arien Vijn and Louis Lee. 12. References 12.1. Normative References [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Gagliano Expires March 12, 2010 [Page 8] Internet-Draft IPv6 in IXPs September 2009 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [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. [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004. [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. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [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. Gagliano Expires March 12, 2010 [Page 9] Internet-Draft IPv6 in IXPs September 2009 12.2. Informative References [RIR_IXP_POLICIES] Numbers Support Organization (NRO)., "RIRs Allocations Policies for IXP. NRO Comparison matrix", 2008, . Author's Address Roque Gagliano LACNIC Rambla Rep Mexico 6125 Montevideo, 11400 UY Phone: +598 2 4005633 Email: roque@lacnic.net Gagliano Expires March 12, 2010 [Page 10]