idnits 2.17.1 draft-ietf-v6ops-v6inixp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 08, 2009) is 5343 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 347, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3682 (Obsoleted by RFC 5082) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Gagliano 3 Internet-Draft LACNIC 4 Intended status: Informational September 08, 2009 5 Expires: March 12, 2010 7 IPv6 Deployment in Internet Exchange Points (IXPs) 8 draft-ietf-v6ops-v6inixp-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 12, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document provides a guide for IPv6 deployment in Internet 47 Exchange Points (IXP). It includes information regarding the switch 48 fabric configuration, the addressing plan and general organizational 49 tasks to be performed. IXPs are mainly a layer 2 infrastructure and 50 in many case the best recommendations state that the IPv6 data, 51 control and management plane should not be handled differently than 52 in IPv4. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 58 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Route Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. External and Internal support . . . . . . . . . . . . . . . . 7 63 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 12.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Most Internet Exchange Points (IXP) work on the Layer 2 level, making 75 the adoption of IPv6 an easy task. However, IXPs normally implement 76 additional services such as statistics, route servers, looking 77 glasses and broadcast control that may be impacted by the 78 implementation of IPv6. This document clarifies the impact of IPv6 79 on a new or an existing IXP that may or may not fit any particular 80 deployment. The document assumes an Ethernet switch fabric, although 81 other layer 2 configurations can be deployed. 83 2. Switch Fabric Configuration 85 An Ethernet based IXP switch fabric implements IPv6 over Ethernet as 86 described in [RFC2464]. Therefore, the switching of IPv6 traffic 87 happens in the same way as in IPv4. However, some management 88 functions require explicit IPv6 support (such as switch management, 89 SNMP support and flow analysis exportation) and this should be 90 assessed by the IXP operator. 92 There are two common configurations of IXP switch ports to support 93 IPv6: 95 1. dual stack LAN: both IPv4 and IPv6 traffic share a common LAN. 96 No extra configuration is required in the switch. In this 97 scenario, participants will typically configure dual stack 98 interfaces, although independent port can be an option. 100 2. independent LAN: an exclusive IPv6 LAN is created for IPv6 101 traffic. If IXP participants are already using Virtual LAN 102 (VLAN) tagging on their routers interfaces that are facing the 103 IXP switch, this only requires passing one additional VLAN tag 104 across the interconnection. If participants are using untagged 105 interconnections with the IXP switch and wish to continue doing 106 so, they will need to facilitate a separate physical port to 107 access the IPv6-specific LAN. 109 The "independent LAN" configuration provides a physical separation 110 for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and 111 IPv6 traffic. However, it can be more costly in both capital 112 expenses (if new ports are needed) and operational expends. 113 Conversely, the dual stack implementation allows a quick and capital 114 cost-free start-up for IPv6 support in the IXP, allowing the IXP to 115 avoid transforming untagged ports into tagged ports. In this 116 implementation, traffic-split for statistical analysis may be done 117 using flows techniques such as IPFIX [RFC5101] considering the 118 different ether-types (0x0800 for IPv4, 0x0806 for ARP and 0x86DD for 119 IPv6). 121 The only technical requirement for IPv6 referring link MTUs is that 122 they need to be greater than or equal to 1280 octets [RFC2460]. 123 Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes. 124 Consequently, no MTU changes are typically required. The MTU size 125 for every LAN in an IXP should be well know by all its participants. 127 3. Addressing Plan 129 Regional Internet Registries (RIRs) have specific address policies to 130 allocate Provider Independent (PI) IPv6 address to IXPs. Those 131 allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. 132 Depending on the country and region of operation, address allocations 133 may be provided by NIRs (National Internet Registries). Unique Local 134 IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP 135 LAN as global reverse DNS resolution and whois services are required. 137 From the allocated prefix, following the recommendations of 138 [RFC4291], a /64 prefix should be allocated for each of the exchange 139 point IPv6 enabled LANs. A /48 prefix allows the addressing of 65536 140 LANs. As IXP will normally use manual address configuration, longer 141 prefixes (/65-/127), are technically feasible but are normally 142 discouraged because of operational practices. The manual 143 configuration of IPv6 addresses allows IXP participants to replace 144 network interfaces with no need to reconfigure Border Gateway 145 Protocol (BGP) sessions information and it also facilitates 146 management tasks. 148 When selecting the use of static Interface Identifiers (IIDs), there 149 are different options on how to "intelligently" fill its 64 bits (or 150 16 hexadecimal characters). A non-exhausted list of possible IID 151 selection mechanisms is the following: 153 1. Some IXPs like to include the participants' ASN number decimal 154 encoding inside each IPv6 address. The ASN decimal number is 155 used as the BCD (binary code decimal) encoding of the upper part 156 of the IID such as shown in this example: 158 * IXP LAN prefix: 2001:DB8::/64 160 * ASN: 64496 162 * IPv6 Address: 2001:DB8::0000:0006:4496:0001/64 or its 163 equivalent representation 2001:DB8::6:4496:1/64 165 In this example we are right justifying the participant' ASN 166 number from the 112nd bit. Remember that 32 bits ASNs require a 167 maximum of 10 characters. With this example, up to 2^16 IPv6 168 addresses can be configured per ASN. 170 2. Although BCD encoding is more "human-readable", some IXPs prefer 171 to use the hexadecimal encoding of the ASNs number as the upper 172 part of the IID as follow: 174 * IXP LAN prefix: 2001:DB8::/64 176 * ASN: 64496 (DEC) or FBF0 (HEX) 178 * IPv6 Address: 2001:DB8::0000:0000:FBF0:0001/64 or its 179 equivalent representation 2001:DB8::FBF0:1/64 181 3. A third scheme for statically assigning IPv6 addresses on an IXP 182 LAN could be to relate some portion of a participant's IPv6 183 address to its IPv4 address. In the following example, the last 184 three decimals of the IPv4 address are copied to the last 185 hexadecimals of the IPv6 address, using the decimal number as the 186 BCD encoding for the last three characters of the IID such as in 187 the following example: 189 * IXP LAN prefix: 2001:DB8::/64 191 * IPv4 Address: 240.0.20.132/23 193 * IPv6 Address: 2001:DB8::132/64 195 4. A fourth approach might be based on the IXPs ID for that 196 participant. 198 The current practice that applies to IPv4 about publishing IXP 199 allocations to the DFZ (Default Free Zone) should also apply to the 200 IPv6 allocation (normally a /48 prefix). Typically IXPs LANs are not 201 globally reachable in order to avoid a Distributed Denial of Service 202 (DDoS) attack but participant may route these prefixes inside their 203 networks (e. g. using BGP no-export communities or routing the IXP 204 LANs within the participants' IGP) to perform fault management. IXP 205 external services (such as dns, web pages, ftp servers) needs to be 206 globally routed and due to strict prefix length filtering could be 207 the reason to request more than one /48 assignment from a RIR (i.e. 208 requesting one /48 for the IXPs LANs that is not globally routed and 209 a different /48 for the IXP external services that is globally 210 routed). IPv6 prefixes for IXP LAN's are typically publicly well 211 known. 213 4. Multicast IPv6 215 There are two elements that need to be evaluated when studying IPv6 216 multicast in an IXP: multicast support for neighbor discovery and 217 multicast peering. 219 IXPs typically control broadcast traffic across the switching fabric 220 in order to avoid broadcast storms by only allowing limited ARP 221 [RFC0826] traffic for address resolution. In IPv6 there is not 222 broadcast support but IXP may intend to control multicast traffic in 223 each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the 224 following necessary functions in an IXP switching fabric: Address 225 Resolution, Neighbor Unreachability Detection and Duplicate Address 226 Detection. In order to perform these functions, Neighbor 227 Solicitation and Neighbor Advertisement packets are exchange using 228 the link-local all-nodes multicast address (FF02::1) and/or 229 solicited-node multicast addresses (FF02:0:0:0:0:1:FF00:0000 to FF02: 230 0:0:0:0:1:FFFF:FFFF). As described in [RFC4861] routers will 231 initialize its interfaces by joining its solicited-node multicast 232 addresses using either Multicast Listener Discovery (MLD) [RFC2710] 233 or MLDv2 [RFC3810]. MLD messages may be sent to the corresponding 234 group address:FF02::2 (MLD) or FF02::16 (MLDv2). Depending on the 235 addressing plan selected by the IXP, each solicited-node multicast 236 group may be shared by a sub-set of participants' conditioned by how 237 the last three octects of the addresses are selected. In Section 3 238 example 1, only participants with ASNs with the same two last digits 239 are going to share the same solocited-node multicast group. 241 Similarly to the ARP policy an IXP may limit multicast traffic 242 accross the switching fabric in order to only allow ICMPv6 Neighbor 243 Solicitation, Neighbor Advertisement and MLD messages. Configuring 244 default routes in an IXP LAN without an agreement within the parties 245 is normally against IXP policies. ICMPv6 Router Advertisement 246 packets should neither be issued nor accepted by routers connected to 247 the IXP. Where possible, the IXP operator should block link-local RA 248 packets using IPv6 RA-Guard. If this is not possible, the IXP 249 operator should monitor the exchange for rogue Router Advertisement 250 packets. 252 For IPv6 Multicast traffic exchange, an IXP may decide to use either 253 the same LAN being used for unicast IPv6 traffic exchange, the same 254 LAN being used for IPv4 Multicast traffic exchange or a dedicated LAN 255 for IPv6 Multicast traffic exchange. The reason for having a 256 dedicated LAN for multicast is to prevent unwanted multicast traffic 257 to reach participants that do not have multicast support. Protocol 258 Independent Multicast [RFC4601] messages will be sent to the the 259 link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the 260 selected LAN and should be allowed. Implementing IPv6 PIM snooping 261 will allow only the participants associated to a particular group to 262 receive its multicast traffic. BGP reachability information for IPv6 263 multicast address-family (SAFI=2) is normally exchanged using MP-BGP 264 [RFC4760] and is used for Reverse Path Forwarding (RPF) lookups 265 performed by the IPv6 PIM. If a dedicated LAN is configured for 266 Multicast IPv6 traffic exchange, reachability information for IPv6 267 Multicast address family should be carried in new BGP sessions. 268 ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN 269 as described in the previous paragraph. 271 5. Reverse DNS 273 PTR records for all addresses assigned to participants should be 274 included in the IXP reverse zone under "ip6.arpa" for troubleshooting 275 purposes. DNS servers should be reachable over IPv6 transport for 276 complete IPv6 support. 278 6. Route Server 280 IXPs may offer a Route Server service, either for Multi-Lateral 281 Peering Agreements (MLPA) service, looking glass service or route- 282 collection service. IPv6 support needs to be added to the BGP 283 speaking router. The equipment should be able to transport IPv6 284 traffic and to support Multi-protocol BGP (MP-BGP) extensions for 285 IPv6 address family ([RFC2545] and [RFC4760]). 287 A good practice is that all BGP sessions used to exchange IPv6 288 network information are configured using IPv6 data transport. This 289 configuration style ensures that as both network reachability 290 information and generic packet data transport use the same transport 291 plane, in the event of IPv6 reachability problems between IPv6 peers, 292 the IPv6 BGP session may be terminated independently of any IPv4 293 sessions. The use of MD5 [RFC2385] or IPSEC [RFC4301] to 294 authenticate the BGP sessions and the use of GTSM (The Generalized 295 TTL Security Mechanism) [RFC3682] should be considered. 297 The Router-Server or Looking Glass external service should be 298 available for external IPv6 access, either by an IPv6 enabled web 299 page or an IPv6 enabled console interface. 301 7. External and Internal support 303 Some external services that need to have IPv6 support are Traffic 304 Graphics, DNS, FTP, Web, Route Server and Looking Glass. Other 305 external services such as NTP servers, or SIP Gateways need to be 306 evaluated as well. In general, each service that is currently 307 accessed through IPv4 or that handle IPv4 addresses should be 308 evaluated for IPv6 support. 310 Internal services are also important when considering IPv6 adoption 311 at an IXP. Such services may not deal with IPv6 traffic but may 312 handle IPv6 addresses; that is the case of provisioning systems, 313 logging tools and statistics analysis tools. Databases and tools 314 should be evaluated for IPv6 support. 316 8. IXP Policies and IPv6 318 IXP Policies and contracts should be be revised as any mention of IP 319 should be clarified if it refers to IPv4, IPv6 or both. 321 9. IANA Considerations 323 This memo includes no request to IANA. 325 10. Security Considerations 327 This memo includes information on practices at IXPs for monitoring 328 and/or avoiding broadcast storms in IXP LANs caused by IPv6 multicast 329 traffic. It also mentions avoiding IPv6 DDoS attacks to the IXP 330 switching fabric by not globally announce the IXP LANs prefix. 332 11. Acknowledgements 334 The author would like to thank the contributions from Stig Venaas, 335 Martin Levy, Nick Hilliard, Martin Pels, Bill Woodcock, Carlos Frias, 336 Arien Vijn and Louis Lee. 338 12. References 340 12.1. Normative References 342 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 343 converting network protocol addresses to 48.bit Ethernet 344 address for transmission on Ethernet hardware", STD 37, 345 RFC 826, November 1982. 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 351 Signature Option", RFC 2385, August 1998. 353 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 354 (IPv6) Specification", RFC 2460, December 1998. 356 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 357 Networks", RFC 2464, December 1998. 359 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 360 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 361 March 1999. 363 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 364 Listener Discovery (MLD) for IPv6", RFC 2710, 365 October 1999. 367 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 368 Security Mechanism (GTSM)", RFC 3682, February 2004. 370 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 371 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 373 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 374 Addresses", RFC 4193, October 2005. 376 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 377 Architecture", RFC 4291, February 2006. 379 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 380 Internet Protocol", RFC 4301, December 2005. 382 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 383 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 384 Protocol Specification (Revised)", RFC 4601, August 2006. 386 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 387 "Multiprotocol Extensions for BGP-4", RFC 4760, 388 January 2007. 390 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 391 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 392 September 2007. 394 [RFC5101] Claise, B., "Specification of the IP Flow Information 395 Export (IPFIX) Protocol for the Exchange of IP Traffic 396 Flow Information", RFC 5101, January 2008. 398 12.2. Informative References 400 [RIR_IXP_POLICIES] 401 Numbers Support Organization (NRO)., "RIRs Allocations 402 Policies for IXP. NRO Comparison matrix", 2008, 403 . 405 Author's Address 407 Roque Gagliano 408 LACNIC 409 Rambla Rep Mexico 6125 410 Montevideo, 11400 411 UY 413 Phone: +598 2 4005633 414 Email: roque@lacnic.net