idnits 2.17.1 draft-ietf-v6ops-v6inixp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 20, 2010) is 5062 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3627' is mentioned on line 146, but not defined ** Obsolete undefined reference: RFC 3627 (Obsoleted by RFC 6547) == Unused Reference: 'RFC2119' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC2385' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RFC3682' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 419, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-ra-guard-03 == Outdated reference: A later version (-02) exists of draft-ietf-v6ops-rogue-ra-00 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3682 (Obsoleted by RFC 5082) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Gagliano 3 Internet-Draft Cisco Systems 4 Intended status: Informational May 20, 2010 5 Expires: November 21, 2010 7 IPv6 Deployment in Internet Exchange Points (IXPs) 8 draft-ietf-v6ops-v6inixp-06.txt 10 Abstract 12 This document provides guidance on IPv6 deployment in Internet 13 Exchange Points (IXP). It includes information regarding the switch 14 fabric configuration, the addressing plan and general organizational 15 tasks that need to be performed. IXPs are mainly a layer 2 16 infrastructure and in many cases the best recommendations suggest 17 that the IPv6 data, control and management plane should not be 18 handled differently than in IPv4. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 21, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 56 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6 59 4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7 60 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Route-Server . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. External and Internal support . . . . . . . . . . . . . . . . 8 63 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 67 12. Informative References . . . . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 Most Internet Exchange Points (IXP) work at the Layer 2 level, making 73 the adoption of IPv6 an easy task. However, IXPs normally implement 74 additional services such as statistics, route servers, looking 75 glasses and broadcast control that may be impacted by the 76 implementation of IPv6. This document clarifies the impact of IPv6 77 on a new or an existing IXP. The document assumes an Ethernet switch 78 fabric, although other layer 2 configurations can be deployed. 80 2. Switch Fabric Configuration 82 An Ethernet based IXP switch fabric implements IPv6 over Ethernet as 83 described in [RFC2464] . Therefore, the switching of IPv6 traffic 84 happens in the same way as in IPv4. However, some management 85 functions may require explicit IPv6 support (such as switch 86 management, SNMP [RFC3411] support and flow analysis exportation) and 87 this should be assessed by the IXP operator. 89 There are two common configurations of IXP switch ports to support 90 IPv6: 92 1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6 93 traffic share a common LAN. No extra configuration is required 94 in the switch. 96 2. independent VLAN (Virtual Local Area Network): when an IXP 97 logically separates IPv4 and IPv6 traffic in different VLANs. 99 In both configurations, IPv6 and IPv4 traffic can either share a 100 common physical port or use independent physical ports. The use of 101 independent ports can be more costly in both capital expenses (as new 102 ports are needed) and operational expenses. 104 When using the same physical port for both IPv4 and IPv6 traffic, 105 some changes may be needed at the participants' interfaces 106 configurations. If the IXP implements the "dual-stack 107 configuration", IXP participants will configure dual-stack 108 interfaces. On the other hand, if the IXP implements the 109 "independent VLAN configuration", IXP participants are required to 110 pass one additional VLAN tag across the interconnection. In this 111 case, if the IXP did not originally use VLAN tagging, VLAN tagging 112 may to be established and previous use may continue untagged as a 113 "native VLAN" or be transitioned to a tagged VLAN. The "independent 114 VLAN" configuration provides a logical separation of IPv4 and IPv6 115 traffic, simplifying separate statistical analysis for IPv4 and IPv6 116 traffic. Conversely, the "dual-stack" configuration (when performing 117 separate statistical analysis for IPv4 and IPv6 traffic) would 118 require the use of flows techniques such as IPFIX [RFC5101] to 119 classify traffic based on the different ether-types (0x0800 for IPv4, 120 0x0806 for ARP and 0x86DD for IPv6). 122 The only technical requirement for IPv6 referring link MTUs is that 123 they need to be greater than or equal to 1280 octets [RFC2460]. The 124 MTU size for every LAN in an IXP should be well known by all its 125 participants. 127 3. Addressing Plan 129 Regional Internet Registries (RIRs) have specific address policies to 130 assign 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 assignments 133 may be made 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 IXPs will normally use manual address configuration. The manual 138 configuration of IPv6 addresses allows IXP participants to replace 139 network interfaces with no need to reconfigure Border Gateway 140 Protocol (BGP) sessions information and it also facilitates 141 management tasks. The IPv6 Addressing Architecture [RFC4291] 142 requires that interface identifiers are 64 bits in size for prefixes 143 starting with binary 000, resulting in a maximum prefix length of 144 /64. Longer prefix lengths up to /127 have been used operationally. 145 If prefix lengths longer than 64 bits are chosen, the implications 146 described in [RFC3627] need to be considered. A /48 prefix allows 147 the addressing of 65536 /64 LANs. 149 When selecting the use of static Interface Identifiers (IIDs), there 150 are different options on how to fill its 64 bits (or 16 hexadecimal 151 characters). A non-exhausted list of possible IID selection 152 mechanisms is the following: 154 1. Some IXPs like to include the participants' ASN number decimal 155 encoding inside each IPv6 address. The ASN decimal number is 156 used as the BCD (binary code decimal) encoding of the upper part 157 of the IID such as shown in this example: 159 * IXP LAN prefix: 2001:db8::/64 161 * ASN: 64496 162 * IPv6 Address: 2001:db8:0000:0000: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's 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:0000:0000:fbf0:0001/64 or its 179 equivalent representation 2001:db8::fbf0:1/64 181 In this case a maximum of 8 characters will be needed to 182 represent 32 bits ASNs. 184 3. A third scheme for statically assigning IPv6 addresses on an IXP 185 LAN could be to relate some portions of a participant's IPv6 186 address to its IPv4 address. In the following example, the last 187 four decimals of the IPv4 address are copied to the last 188 hexadecimals of the IPv6 address, using the decimal number as the 189 BCD encoding for the last three characters of the IID such as in 190 the following example: 192 * IXP LAN prefix: 2001:db8::/64 194 * IPv4 Address: 192.0.2.123/23 196 * IPv6 Address: 2001:db8:2:123/64 198 4. A fourth approach might be based on the IXPs ID for that 199 participant. 201 IPv6 prefixes for IXP LANs are typically publicly well known and 202 taken from dedicated IPv6 blocks for IXP assignments reserved for 203 this purpose by the different RIRs. These blocks are usually only 204 meant for addressing the exchange fabric, and may be filtered out by 205 DFZ (Default Free Zone) operators. When considering the routing of 206 the IXP LANs two options are identified: 208 o IXPs may decide that LANs should not to be globally routed in 209 order to limit the possible origins of a Denial of Service (DoS) 210 attack to its participants' AS boundaries. In this configuration 211 participants may route these prefixes inside their networks (e. g. 212 using BGP no-export communities or routing the IXP LANs within the 213 participants' IGP) to perform fault management. Using this 214 configuration, the monitoring of the IXP LANs from outside of its 215 participants' AS boundaries is not possible. 217 o IXP may decide that LANs should (attempt to be) be globall routed. 218 In this case, IXP LANs monitoring from outside its participants' 219 AS boundaries may be possible but the IXP LANs will be vulnerable 220 to DoS from outside of those boundaries. 222 Additionally, possible IXP external services (such as dns, web pages, 223 ftp servers) need to be globally routed. These should be addressed 224 from separate address blocks, either from upstream providers' address 225 space, or separate independent assignments. Strict prefix length 226 filtering could be a reason for requesting more than one /48 227 assignment from a RIR (i.e. requesting one /48 assignment for the 228 IXPs LANs that may not be globally routed and a different, non-IXP 229 /48 assignment for the IXP external services that will be globally 230 routed). 232 4. Multicast IPv6 234 There are two elements that need to be evaluated when studying IPv6 235 multicast in an IXP: multicast support for neighbor discovery and 236 multicast peering. 238 4.1. Multicast Support and Monitoring for ND at an IXP 240 IXPs typically control broadcast traffic across the switching fabric 241 in order to avoid broadcast storms by only allowing limited ARP 242 [RFC0826] traffic for address resolution. In IPv6 there is not 243 broadcast support but IXP may intend to control multicast traffic in 244 each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the 245 following necessary functions in an IXP switching fabric: Address 246 Resolution, Neighbor Unreachability Detection and Duplicate Address 247 Detection. In order to perform these functions, Neighbor 248 Solicitation and Neighbor Advertisement packets are exchanged using 249 the link-local all-nodes multicast address (ff02::1) and/or 250 solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02: 251 0:0:0:0:1:ffff:ffff). As described in [RFC4861] routers will 252 initialize its interfaces by joining its solicited-node multicast 253 addresses using either Multicast Listener Discovery (MLD) [RFC2710] 254 or MLDv2 [RFC3810] . MLD messages may be sent to the corresponding 255 group address ff02::2 (MLD) or ff02::16 (MLDv2). Depending on the 256 addressing plan selected by the IXP, each solicited-node multicast 257 group may be shared by a sub-set of participants' conditioned by how 258 the last three octets of the addresses are selected. In Section 3 259 example 1, only participants with ASNs with the same two last digits 260 are going to share the same solicited-node multicast group. 262 Similarly to the ARP policy an IXP may limit multicast traffic across 263 the switching fabric in order to only allow ICMPv6 Neighbor 264 Solicitation, Neighbor Advertisement and MLD messages. Configuring 265 default routes in an IXP LAN without an agreement between the parties 266 is normally against IXP policies. ICMPv6 Router Advertisement 267 packets should neither be issued nor accepted by routers connected to 268 the IXP. Where possible, the IXP operator should block link-local RA 269 packets using IPv6 RA-GUARD [I-D.ietf-v6ops-ra-guard] . If this is 270 not possible, the IXP operator should monitor the exchange for rogue 271 Router Advertisement packets as described in 272 [I-D.ietf-v6ops-rogue-ra] . 274 4.2. IPv6 Multicast traffic exchange at an IXP 276 For IPv6 Multicast traffic exchange, an IXP may decide to use either 277 the same LAN being used for unicast IPv6 traffic exchange, the same 278 LAN being used for IPv4 Multicast traffic exchange or a dedicated LAN 279 for IPv6 Multicast traffic exchange. The reason for having a 280 dedicated LAN for multicast is to prevent unwanted multicast traffic 281 to reach participants that do not have multicast support. Protocol 282 Independent Multicast (PIM) [RFC4601] messages will be sent to the 283 link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the 284 selected LAN and should be allowed. Implementing IPv6 PIM snooping 285 will allow only the participants associated to a particular group to 286 receive its multicast traffic. BGP reachability information for IPv6 287 multicast address-family (SAFI=2) is normally exchanged using MP-BGP 288 [RFC4760] and is used for Reverse Path Forwarding (RPF) lookups 289 performed by the IPv6 PIM. If a dedicated LAN is configured for 290 Multicast IPv6 traffic exchange, reachability information for IPv6 291 Multicast address family should be carried in new BGP sessions. 292 ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN 293 as described in the previous paragraph. 295 5. Reverse DNS 297 The inclusion of PTR records for all addresses assigned to 298 participants in the IXP reverse zone under "ip6.arpa" facilitates 299 troubleshooting, particularly when using tools such as traceroute. 300 If reverse DNS is configured, DNS servers should be reachable over 301 IPv6 transport for complete IPv6 support. 303 6. Route-Server 305 IXPs may offer a Route-Server service, either for Multi-Lateral 306 Peering Agreements (MLPA) service, looking glass service or route- 307 collection service. IPv6 support needs to be added to the BGP 308 speaking router. The equipment should be able to transport IPv6 309 traffic and to support Multi-protocol BGP (MP-BGP) extensions for 310 IPv6 address family ([RFC2545] and [RFC4760]). 312 A good practice is that all BGP sessions used to exchange IPv6 313 network information are configured using IPv6 data transport. This 314 configuration style ensures that both network reachability 315 information and generic packet data transport use the same transport 316 plane. Because of the size of the IPv6 space, limiting the maximum 317 number of IPv6 prefixes in every session should be studied. 319 External services should be available for external IPv6 access, 320 either by an IPv6 enabled web page or an IPv6 enabled console 321 interface. 323 7. External and Internal support 325 Some external services that need to have IPv6 support are traffic 326 graphics, DNS, FTP, Web, Route Server and Looking Glass. Other 327 external services such as NTP servers, or SIP Gateways need to be 328 evaluated as well. In general, each service that is currently 329 accessed through IPv4 or that handle IPv4 addresses should be 330 evaluated for IPv6 support. 332 Internal services are also important when considering IPv6 adoption 333 at an IXP. Such services may not deal with IPv6 traffic but may 334 handle IPv6 addresses; that is the case of provisioning systems, 335 logging tools and statistics analysis tools. Databases and tools 336 should be evaluated for IPv6 support. 338 8. IXP Policies and IPv6 340 IXP Policies and contracts should be revised as any mention of IP 341 should be clarified if it refers to IPv4, IPv6 or both. 343 Policies for IPv6 traffic monitoring and filtering may be in place as 344 described in Section Section 4 . 346 9. IANA Considerations 348 This memo includes no request to IANA. 350 10. Security Considerations 352 This memo includes procedures for monitoring and/or avoiding 353 particular ICMPv6 traffic at IXPs' LANs. None of these methods 354 prevent Ethernet loops caused by mischief in the LAN. The document 355 also mentions how to limit IPv6 DoS attacks to the IXP switch fabric 356 by not globally announce the IXP LANs prefix. 358 11. Acknowledgements 360 The author would like to thank the contributions from Alain Aina, 361 Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, 362 Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont and Louis 363 Lee. 365 12. Informative References 367 [I-D.ietf-v6ops-ra-guard] 368 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 369 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03 370 (work in progress), May 2009. 372 [I-D.ietf-v6ops-rogue-ra] 373 Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 374 Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in 375 progress), May 2009. 377 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 378 converting network protocol addresses to 48.bit Ethernet 379 address for transmission on Ethernet hardware", STD 37, 380 RFC 826, November 1982. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 386 Signature Option", RFC 2385, August 1998. 388 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 389 (IPv6) Specification", RFC 2460, December 1998. 391 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 392 Networks", RFC 2464, December 1998. 394 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 395 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 396 March 1999. 398 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 399 Listener Discovery (MLD) for IPv6", RFC 2710, 400 October 1999. 402 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 403 Architecture for Describing Simple Network Management 404 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 405 December 2002. 407 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 408 Security Mechanism (GTSM)", RFC 3682, February 2004. 410 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 411 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 413 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 414 Addresses", RFC 4193, October 2005. 416 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 417 Architecture", RFC 4291, February 2006. 419 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 420 Internet Protocol", RFC 4301, December 2005. 422 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 423 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 424 Protocol Specification (Revised)", RFC 4601, August 2006. 426 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 427 "Multiprotocol Extensions for BGP-4", RFC 4760, 428 January 2007. 430 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 431 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 432 September 2007. 434 [RFC5101] Claise, B., "Specification of the IP Flow Information 435 Export (IPFIX) Protocol for the Exchange of IP Traffic 436 Flow Information", RFC 5101, January 2008. 438 [RIR_IXP_POLICIES] 439 Numbers Resource Organization (NRO)., "RIRs Allocations 440 Policies for IXP. NRO Comparison matrix", 2009, 441 . 443 Author's Address 445 Roque Gagliano 446 Cisco Systems 447 Avenue des Uttins 5 448 Rolle, 1180 449 Switzerland 451 Email: rogaglia@cisco.com