summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5963.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5963.txt')
-rw-r--r--doc/rfc/rfc5963.txt563
1 files changed, 563 insertions, 0 deletions
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,
+ <http://www.nro.net/documents/comp-pol.html#3-4-2>.
+
+
+
+
+
+
+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]
+