idnits 2.17.1 draft-ietf-v6ops-v6inixp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2010) is 5189 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3627' is mentioned on line 164, but not defined ** Obsolete undefined reference: RFC 3627 (Obsoleted by RFC 6547) == Unused Reference: 'RFC2119' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'RFC2385' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC3682' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 437, 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: 2 errors (**), 0 flaws (~~), 9 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 LACNIC 4 Intended status: Informational February 8, 2010 5 Expires: August 12, 2010 7 IPv6 Deployment in Internet Exchange Points (IXPs) 8 draft-ietf-v6ops-v6inixp-05.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 to IETF 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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 12, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 74 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 75 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6 77 4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7 78 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 6. Route-Server . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. External and Internal support . . . . . . . . . . . . . . . . 8 81 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 85 12. Informative References . . . . . . . . . . . . . . . . . . . . 9 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 Most Internet Exchange Points (IXP) work at the Layer 2 level, making 91 the adoption of IPv6 an easy task. However, IXPs normally implement 92 additional services such as statistics, route servers, looking 93 glasses and broadcast control that may be impacted by the 94 implementation of IPv6. This document clarifies the impact of IPv6 95 on a new or an existing IXP. The document assumes an Ethernet switch 96 fabric, although other layer 2 configurations can be deployed. 98 2. Switch Fabric Configuration 100 An Ethernet based IXP switch fabric implements IPv6 over Ethernet as 101 described in [RFC2464]. Therefore, the switching of IPv6 traffic 102 happens in the same way as in IPv4. However, some management 103 functions may require explicit IPv6 support (such as switch 104 management, SNMP [RFC3411] support and flow analysis exportation) and 105 this should be assessed by the IXP operator. 107 There are two common configurations of IXP switch ports to support 108 IPv6: 110 1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6 111 traffic share a common LAN. No extra configuration is required 112 in the switch. 114 2. independent VLAN (Virtual Local Area Network): when an IXP 115 logically separates IPv4 and IPv6 traffic in different VLANs. 117 In both configurations, IPv6 and IPv4 traffic can either share a 118 common physical port or use independent physical ports. The use of 119 independent ports can be more costly in both capital expenses (as new 120 ports are needed) and operational expenses. 122 When using the same physical port for both IPv4 and IPv6 traffic, 123 some changes may be needed at the participants' interfaces 124 configurations. If the IXP implements the "dual-stack 125 configuration", IXP participants will configure dual-stack 126 interfaces. On the other hand, if the IXP implements the 127 "independent VLAN configuration", IXP participants are required to 128 pass one additional VLAN tag across the interconnection. In this 129 case, if the IXP did not originally use VLAN tagging, VLAN tagging 130 may to be established and previous use may continue untagged as a 131 "native VLAN" or be transitioned to a tagged VLAN. The "independent 132 VLAN" configuration provides a logical separation of IPv4 and IPv6 133 traffic, simplifying separate statistical analysis for IPv4 and IPv6 134 traffic. Conversely, the "dual-stack" configuration (when performing 135 separate statistical analysis for IPv4 and IPv6 traffic) would 136 require the use of flows techniques such as IPFIX [RFC5101] to 137 classify traffic based on the different ether-types (0x0800 for IPv4, 138 0x0806 for ARP and 0x86DD for IPv6). 140 The only technical requirement for IPv6 referring link MTUs is that 141 they need to be greater than or equal to 1280 octets [RFC2460]. The 142 MTU size for every LAN in an IXP should be well known by all its 143 participants. 145 3. Addressing Plan 147 Regional Internet Registries (RIRs) have specific address policies to 148 assign Provider Independent (PI) IPv6 address to IXPs. Those 149 allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. 150 Depending on the country and region of operation, address assignments 151 may be made by NIRs (National Internet Registries). Unique Local 152 IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP 153 LAN as global reverse DNS resolution and whois services are required. 155 IXPs will normally use manual address configuration. The manual 156 configuration of IPv6 addresses allows IXP participants to replace 157 network interfaces with no need to reconfigure Border Gateway 158 Protocol (BGP) sessions information and it also facilitates 159 management tasks. The IPv6 Addressing Architecture [RFC4291] 160 requires that interface identifiers are 64 bits in size for prefixes 161 starting with binary 000, resulting in a maximum prefix length of 162 /64. Longer prefix lengths up to /127 have been used operationally. 163 If prefix lengths longer than 64 bits are chosen, the implications 164 described in [RFC3627] need to be considered. A /48 prefix allows 165 the addressing of 65536 /64 LANs. 167 When selecting the use of static Interface Identifiers (IIDs), there 168 are different options on how to fill its 64 bits (or 16 hexadecimal 169 characters). A non-exhausted list of possible IID selection 170 mechanisms is the following: 172 1. Some IXPs like to include the participants' ASN number decimal 173 encoding inside each IPv6 address. The ASN decimal number is 174 used as the BCD (binary code decimal) encoding of the upper part 175 of the IID such as shown in this example: 177 * IXP LAN prefix: 2001:db8::/64 179 * ASN: 64496 180 * IPv6 Address: 2001:db8:0000:0000:0000:0006:4496:0001/64 or its 181 equivalent representation 2001:db8::6:4496:1/64 183 In this example we are right justifying the participant's ASN 184 number from the 112nd bit. Remember that 32 bits ASNs require a 185 maximum of 10 characters. With this example, up to 2^16 IPv6 186 addresses can be configured per ASN. 188 2. Although BCD encoding is more "human-readable", some IXPs prefer 189 to use the hexadecimal encoding of the ASNs number as the upper 190 part of the IID as follow: 192 * IXP LAN prefix: 2001:db8::/64 194 * ASN: 64496 (DEC) or fbf0 (HEX) 196 * IPv6 Address: 2001:db8:0000:0000:0000:0000:fbf0:0001/64 or its 197 equivalent representation 2001:db8::fbf0:1/64 199 In this case a maximum of 8 characters will be needed to 200 represent 32 bits ASNs. 202 3. A third scheme for statically assigning IPv6 addresses on an IXP 203 LAN could be to relate some portions of a participant's IPv6 204 address to its IPv4 address. In the following example, the last 205 four decimals of the IPv4 address are copied to the last 206 hexadecimals of the IPv6 address, using the decimal number as the 207 BCD encoding for the last three characters of the IID such as in 208 the following example: 210 * IXP LAN prefix: 2001:db8::/64 212 * IPv4 Address: 192.0.2.123/23 214 * IPv6 Address: 2001:db8:2:123/64 216 4. A fourth approach might be based on the IXPs ID for that 217 participant. 219 IPv6 prefixes for IXP LANs are typically publicly well known and 220 taken from dedicated IPv6 blocks for IXP assignments reserved for 221 this purpose by the different RIRs. These blocks are usually only 222 meant for addressing the exchange fabric, and may be filtered out by 223 DFZ (Default Free Zone) operators. When considering the routing of 224 the IXP LANs two options are identified: 226 o IXPs may decide that LANs should not to be globally routed in 227 order to limit the possible origins of a Denial of Service (DoS) 228 attack to its participants' AS boundaries. In this configuration 229 participants may route these prefixes inside their networks (e. g. 230 using BGP no-export communities or routing the IXP LANs within the 231 participants' IGP) to perform fault management. Using this 232 configuration, the monitoring of the IXP LANs from outside of its 233 participants' AS boundaries is not possible. 235 o IXP may decide that LANs should (attempt to be) be globall routed. 236 In this case, IXP LANs monitoring from outside its participants' 237 AS boundaries may be possible but the IXP LANs will be vulnerable 238 to DoS from outside of those boundaries. 240 Additionally, possible IXP external services (such as dns, web pages, 241 ftp servers) need to be globally routed. These should be addressed 242 from separate address blocks, either from upstream providers' address 243 space, or separate independent assignments. Strict prefix length 244 filtering could be a reason for requesting more than one /48 245 assignment from a RIR (i.e. requesting one /48 assignment for the 246 IXPs LANs that may not be globally routed and a different, non-IXP 247 /48 assignment for the IXP external services that will be globally 248 routed). 250 4. Multicast IPv6 252 There are two elements that need to be evaluated when studying IPv6 253 multicast in an IXP: multicast support for neighbor discovery and 254 multicast peering. 256 4.1. Multicast Support and Monitoring for ND at an IXP 258 IXPs typically control broadcast traffic across the switching fabric 259 in order to avoid broadcast storms by only allowing limited ARP 260 [RFC0826] traffic for address resolution. In IPv6 there is not 261 broadcast support but IXP may intend to control multicast traffic in 262 each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the 263 following necessary functions in an IXP switching fabric: Address 264 Resolution, Neighbor Unreachability Detection and Duplicate Address 265 Detection. In order to perform these functions, Neighbor 266 Solicitation and Neighbor Advertisement packets are exchanged using 267 the link-local all-nodes multicast address (ff02::1) and/or 268 solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02: 269 0:0:0:0:1:ffff:ffff). As described in [RFC4861] routers will 270 initialize its interfaces by joining its solicited-node multicast 271 addresses using either Multicast Listener Discovery (MLD) [RFC2710] 272 or MLDv2 [RFC3810]. MLD messages may be sent to the corresponding 273 group address ff02::2 (MLD) or ff02::16 (MLDv2). Depending on the 274 addressing plan selected by the IXP, each solicited-node multicast 275 group may be shared by a sub-set of participants' conditioned by how 276 the last three octets of the addresses are selected. In Section 3 277 example 1, only participants with ASNs with the same two last digits 278 are going to share the same solicited-node multicast group. 280 Similarly to the ARP policy an IXP may limit multicast traffic across 281 the switching fabric in order to only allow ICMPv6 Neighbor 282 Solicitation, Neighbor Advertisement and MLD messages. Configuring 283 default routes in an IXP LAN without an agreement between the parties 284 is normally against IXP policies. ICMPv6 Router Advertisement 285 packets should neither be issued nor accepted by routers connected to 286 the IXP. Where possible, the IXP operator should block link-local RA 287 packets using IPv6 RA-GUARD [I-D.ietf-v6ops-ra-guard]. If this is 288 not possible, the IXP operator should monitor the exchange for rogue 289 Router Advertisement packets as described in 290 [I-D.ietf-v6ops-rogue-ra]. 292 4.2. IPv6 Multicast traffic exchange at an IXP 294 For IPv6 Multicast traffic exchange, an IXP may decide to use either 295 the same LAN being used for unicast IPv6 traffic exchange, the same 296 LAN being used for IPv4 Multicast traffic exchange or a dedicated LAN 297 for IPv6 Multicast traffic exchange. The reason for having a 298 dedicated LAN for multicast is to prevent unwanted multicast traffic 299 to reach participants that do not have multicast support. Protocol 300 Independent Multicast (PIM) [RFC4601] messages will be sent to the 301 link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the 302 selected LAN and should be allowed. Implementing IPv6 PIM snooping 303 will allow only the participants associated to a particular group to 304 receive its multicast traffic. BGP reachability information for IPv6 305 multicast address-family (SAFI=2) is normally exchanged using MP-BGP 306 [RFC4760] and is used for Reverse Path Forwarding (RPF) lookups 307 performed by the IPv6 PIM. If a dedicated LAN is configured for 308 Multicast IPv6 traffic exchange, reachability information for IPv6 309 Multicast address family should be carried in new BGP sessions. 310 ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN 311 as described in the previous paragraph. 313 5. Reverse DNS 315 The inclusion of PTR records for all addresses assigned to 316 participants in the IXP reverse zone under "ip6.arpa" facilitates 317 troubleshooting, particularly when using tools such as traceroute. 318 If reverse DNS is configured, DNS servers should be reachable over 319 IPv6 transport for complete IPv6 support. 321 6. Route-Server 323 IXPs may offer a Route-Server service, either for Multi-Lateral 324 Peering Agreements (MLPA) service, looking glass service or route- 325 collection service. IPv6 support needs to be added to the BGP 326 speaking router. The equipment should be able to transport IPv6 327 traffic and to support Multi-protocol BGP (MP-BGP) extensions for 328 IPv6 address family ([RFC2545] and [RFC4760]). 330 A good practice is that all BGP sessions used to exchange IPv6 331 network information are configured using IPv6 data transport. This 332 configuration style ensures that both network reachability 333 information and generic packet data transport use the same transport 334 plane. Because of the size of the IPv6 space, limiting the maximum 335 number of IPv6 prefixes in every session should be studied. 337 External services should be available for external IPv6 access, 338 either by an IPv6 enabled web page or an IPv6 enabled console 339 interface. 341 7. External and Internal support 343 Some external services that need to have IPv6 support are traffic 344 graphics, DNS, FTP, Web, Route Server and Looking Glass. Other 345 external services such as NTP servers, or SIP Gateways need to be 346 evaluated as well. In general, each service that is currently 347 accessed through IPv4 or that handle IPv4 addresses should be 348 evaluated for IPv6 support. 350 Internal services are also important when considering IPv6 adoption 351 at an IXP. Such services may not deal with IPv6 traffic but may 352 handle IPv6 addresses; that is the case of provisioning systems, 353 logging tools and statistics analysis tools. Databases and tools 354 should be evaluated for IPv6 support. 356 8. IXP Policies and IPv6 358 IXP Policies and contracts should be revised as any mention of IP 359 should be clarified if it refers to IPv4, IPv6 or both. 361 Policies for IPv6 traffic monitoring and filtering may be in place as 362 described in Section Section 4. 364 9. IANA Considerations 366 This memo includes no request to IANA. 368 10. Security Considerations 370 This memo includes procedures for monitoring and/or avoiding 371 particular ICMPv6 traffic at IXPs' LANs. None of these methods 372 prevent Ethernet loops caused by mischief in the LAN. The document 373 also mentions how to limit IPv6 DoS attacks to the IXP switch fabric 374 by not globally announce the IXP LANs prefix. 376 11. Acknowledgements 378 The author would like to thank the contributions from Alain Aina, 379 Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, 380 Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont and Louis 381 Lee, 383 12. Informative References 385 [I-D.ietf-v6ops-ra-guard] 386 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 387 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03 388 (work in progress), May 2009. 390 [I-D.ietf-v6ops-rogue-ra] 391 Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 392 Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in 393 progress), May 2009. 395 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 396 converting network protocol addresses to 48.bit Ethernet 397 address for transmission on Ethernet hardware", STD 37, 398 RFC 826, November 1982. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 404 Signature Option", RFC 2385, August 1998. 406 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 407 (IPv6) Specification", RFC 2460, December 1998. 409 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 410 Networks", RFC 2464, December 1998. 412 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 413 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 414 March 1999. 416 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 417 Listener Discovery (MLD) for IPv6", RFC 2710, 418 October 1999. 420 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 421 Architecture for Describing Simple Network Management 422 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 423 December 2002. 425 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 426 Security Mechanism (GTSM)", RFC 3682, February 2004. 428 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 429 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 431 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 432 Addresses", RFC 4193, October 2005. 434 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 435 Architecture", RFC 4291, February 2006. 437 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 438 Internet Protocol", RFC 4301, December 2005. 440 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 441 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 442 Protocol Specification (Revised)", RFC 4601, August 2006. 444 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 445 "Multiprotocol Extensions for BGP-4", RFC 4760, 446 January 2007. 448 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 449 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 450 September 2007. 452 [RFC5101] Claise, B., "Specification of the IP Flow Information 453 Export (IPFIX) Protocol for the Exchange of IP Traffic 454 Flow Information", RFC 5101, January 2008. 456 [RIR_IXP_POLICIES] 457 Numbers Resource Organization (NRO)., "RIRs Allocations 458 Policies for IXP. NRO Comparison matrix", 2009, 459 . 461 Author's Address 463 Roque Gagliano 464 LACNIC 465 Rambla Rep Mexico 6125 466 Montevideo, 11400 467 Uruguay 469 Phone: +598 2 4005633 470 Email: roque@lacnic.net