idnits 2.17.1 draft-ietf-v6ops-v6inixp-03.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 : ---------------------------------------------------------------------------- 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 (October 23, 2009) is 5298 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 392, 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 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 (~~), 5 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 October 23, 2009 5 Expires: April 8, 2010 7 IPv6 Deployment in Internet Exchange Points (IXPs) 8 draft-ietf-v6ops-v6inixp-03.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. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 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 April 8, 2010. 43 Copyright Notice 45 Copyright (c) 2009 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 in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document provides guidance on IPv6 deployment in Internet 57 Exchange Points (IXP). It includes information regarding the switch 58 fabric configuration, the addressing plan and general organizational 59 tasks that need to be performed. IXPs are mainly a layer 2 60 infrastructure and in many cases the best recommendations suggest 61 that the IPv6 data, control and management plane should not be 62 handled differently than in IPv4. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 68 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6 71 4.2. IPv6 Multicast traffic exhange at an IXP . . . . . . . . . 7 72 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Route Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7. External and Internal support . . . . . . . . . . . . . . . . 8 75 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Most Internet Exchange Points (IXP) work at the Layer 2 level, making 87 the adoption of IPv6 an easy task. However, IXPs normally implement 88 additional services such as statistics, route servers, looking 89 glasses and broadcast control that may be impacted by the 90 implementation of IPv6. This document clarifies the impact of IPv6 91 on a new or an existing IXP. The document assumes an Ethernet switch 92 fabric, although other layer 2 configurations can be deployed. 94 2. Switch Fabric Configuration 96 An Ethernet based IXP switch fabric implements IPv6 over Ethernet as 97 described in [RFC2464]. Therefore, the switching of IPv6 traffic 98 happens in the same way as in IPv4. However, some management 99 functions require explicit IPv6 support (such as switch management, 100 SNMP [RFC1157] support and flow analysis exportation) and this should 101 be assessed by the IXP operator. 103 There are two common configurations of IXP switch ports to support 104 IPv6: 106 1. dual-stack LAN: both IPv4 and IPv6 traffic share a common LAN. 107 No extra configuration is required in the switch. In this 108 scenario, participants will typically configure dual-stack 109 interfaces, although independent interfaces are an option. 111 2. independent LAN: an exclusive IPv6 LAN is created for IPv6 112 traffic. If IXP participants are already using Virtual LAN 113 (VLAN) tagging on the interfaces of their routers that are facing 114 the IXP switch, this only requires passing one additional VLAN 115 tag across the interconnection. If participants are using 116 untagged interconnections with the IXP switch and wish to 117 continue doing so, they will need to facilitate a separate 118 physical port to access the IPv6-specific LAN. 120 The "independent LAN" configuration provides a physical separation 121 for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and 122 IPv6 traffic. However, it can be more costly in both capital 123 expenses (if new ports are needed) and operational expends. 124 Conversely, the dual-stack implementation allows a quick and capital 125 cost-free start-up for IPv6 support in the IXP, allowing the IXP to 126 avoid transforming untagged ports into tagged ports. In this 127 implementation, traffic-split for statistical analysis may be done 128 using flows techniques such as IPFIX [RFC5101] considering the 129 different ether-types (0x0800 for IPv4, 0x0806 for ARP and 0x86DD for 130 IPv6). 132 The only technical requirement for IPv6 referring link MTUs is that 133 they need to be greater than or equal to 1280 octets [RFC2460]. 134 Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes. 135 Consequently, no MTU changes are typically required. The MTU size 136 for every LAN in an IXP should be well known by all its participants. 138 3. Addressing Plan 140 Regional Internet Registries (RIRs) have specific address policies to 141 assign Provider Independent (PI) IPv6 address to IXPs. Those 142 allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. 143 Depending on the country and region of operation, address assignments 144 may be made by NIRs (National Internet Registries). Unique Local 145 IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP 146 LAN as global reverse DNS resolution and whois services are required. 148 From the allocated prefix, following the recommendations of 149 [RFC4291], a /64 prefix should be allocated for each of the exchange 150 point IPv6 enabled LANs. A /48 prefix allows the addressing of 65536 151 LANs. As IXP will normally use manual address configuration. Longer 152 prefixes (/65-/127), are technically feasible but are normally 153 discouraged because of operational practices. The manual 154 configuration of IPv6 addresses allows IXP participants to replace 155 network interfaces with no need to reconfigure Border Gateway 156 Protocol (BGP) sessions information and it also facilitates 157 management tasks. 159 When selecting the use of static Interface Identifiers (IIDs), there 160 are different options on how to "intelligently" fill its 64 bits (or 161 16 hexadecimal characters). A non-exhausted list of possible IID 162 selection mechanisms is the following: 164 1. Some IXPs like to include the participants' ASN number decimal 165 encoding inside each IPv6 address. The ASN decimal number is 166 used as the BCD (binary code decimal) encoding of the upper part 167 of the IID such as shown in this example: 169 * IXP LAN prefix: 2001:DB8::/64 171 * ASN: 64496 173 * IPv6 Address: 2001:DB8::0000:0006:4496:0001/64 or its 174 equivalent representation 2001:DB8::6:4496:1/64 176 In this example we are right justifying the participant' ASN 177 number from the 112nd bit. Remember that 32 bits ASNs require a 178 maximum of 10 characters. With this example, up to 2^16 IPv6 179 addresses can be configured per ASN. 181 2. Although BCD encoding is more "human-readable", some IXPs prefer 182 to use the hexadecimal encoding of the ASNs number as the upper 183 part of the IID as follow: 185 * IXP LAN prefix: 2001:DB8::/64 187 * ASN: 64496 (DEC) or FBF0 (HEX) 189 * IPv6 Address: 2001:DB8::0000:0000:FBF0:0001/64 or its 190 equivalent representation 2001:DB8::FBF0:1/64 192 3. A third scheme for statically assigning IPv6 addresses on an IXP 193 LAN could be to relate some portions of a participant's IPv6 194 address to its IPv4 address. In the following example, the last 195 three decimals of the IPv4 address are copied to the last 196 hexadecimals of the IPv6 address, using the decimal number as the 197 BCD encoding for the last three characters of the IID such as in 198 the following example: 200 * IXP LAN prefix: 2001:DB8::/64 202 * IPv4 Address: 192.0.2.123/23 204 * IPv6 Address: 2001:DB8::132/64 206 4. A fourth approach might be based on the IXPs ID for that 207 participant. 209 IPv6 prefixes for IXP LANs are typically publicly well known and 210 taken from dedicated IPv6 blocks for IXP assignments reserved for 211 this purpose by the different RIRs.The current practice that applies 212 to IPv4 about publishing IXP allocations to the DFZ (Default Free 213 Zone) should also apply to the IPv6 allocation. When considering the 214 routing of the IXP LANs two options are identified: 216 o IXPs may decide that LANs should not to be globally routed in 217 order to limit the possible origins of a Distributed Denial of 218 Service (DDoS) attack to its particpant' AS boundries. In this 219 configuration participants may route these prefixes inside their 220 networks (e. g. using BGP no-export communities or routing the IXP 221 LANs within the participants' IGP) to perform fault management. 222 Using this configuration, the monitoring of the IXP LANs from 223 outside of its participants' AS boundaries is not possible. 225 o IXP may decide that LANs should be globally routed. In this case, 226 IXP LANs monitoring from outside its participants' AS boundaries 227 is possible but the IXP LANs will be vulnerable to DDoS from 228 outside of those broundries. 230 IXP external services (such as dns, web pages, ftp servers) need to 231 be globally routed. Strict prefix length filtering could be the 232 reason for requesting more than one /48 assignment from a RIR (i.e. 233 requesting one /48 assignment for the IXPs LANs that may not be 234 globally routed and a different /48 assignment for the IXP external 235 services that will be globally routed). 237 4. Multicast IPv6 239 There are two elements that need to be evaluated when studying IPv6 240 multicast in an IXP: multicast support for neighbor discovery and 241 multicast peering. 243 4.1. Multicast Support and Monitoring for ND at an IXP 245 IXPs typically control broadcast traffic across the switching fabric 246 in order to avoid broadcast storms by only allowing limited ARP 247 [RFC0826] traffic for address resolution. In IPv6 there is not 248 broadcast support but IXP may intend to control multicast traffic in 249 each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the 250 following necessary functions in an IXP switching fabric: Address 251 Resolution, Neighbor Unreachability Detection and Duplicate Address 252 Detection. In order to perform these functions, Neighbor 253 Solicitation and Neighbor Advertisement packets are exchanged using 254 the link-local all-nodes multicast address (FF02::1) and/or 255 solicited-node multicast addresses (FF02:0:0:0:0:1:FF00:0000 to FF02: 256 0:0:0:0:1:FFFF:FFFF). As described in [RFC4861] routers will 257 initialize its interfaces by joining its solicited-node multicast 258 addresses using either Multicast Listener Discovery (MLD) [RFC2710] 259 or MLDv2 [RFC3810]. MLD messages may be sent to the corresponding 260 group address FF02::2 (MLD) or FF02::16 (MLDv2). Depending on the 261 addressing plan selected by the IXP, each solicited-node multicast 262 group may be shared by a sub-set of participants' conditioned by how 263 the last three octets of the addresses are selected. In Section 3 264 example 1, only participants with ASNs with the same two last digits 265 are going to share the same solicited-node multicast group. 267 Similarly to the ARP policy an IXP may limit multicast traffic across 268 the switching fabric in order to only allow ICMPv6 Neighbor 269 Solicitation, Neighbor Advertisement and MLD messages. Configuring 270 default routes in an IXP LAN without an agreement between the parties 271 is normally against IXP policies. ICMPv6 Router Advertisement 272 packets should neither be issued nor accepted by routers connected to 273 the IXP. Where possible, the IXP operator should block link-local RA 274 packets using IPv6 RA-GUARD [I-D.ietf-v6ops-ra-guard]. If this is 275 not possible, the IXP operator should monitor the exchange for rogue 276 Router Advertisement packets as decribed in 277 [I-D.ietf-v6ops-rogue-ra]. 279 4.2. IPv6 Multicast traffic exhange at an IXP 281 For IPv6 Multicast traffic exchange, an IXP may decide to use either 282 the same LAN being used for unicast IPv6 traffic exchange, the same 283 LAN being used for IPv4 Multicast traffic exchange or a dedicated LAN 284 for IPv6 Multicast traffic exchange. The reason for having a 285 dedicated LAN for multicast is to prevent unwanted multicast traffic 286 to reach participants that do not have multicast support. Protocol 287 Independent Multicast [RFC4601] messages will be sent to the link- 288 local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the selected 289 LAN and should be allowed. Implementing IPv6 PIM snooping will allow 290 only the participants associated to a particular group to receive its 291 multicast traffic. BGP reachability information for IPv6 multicast 292 address-family (SAFI=2) is normally exchanged using MP-BGP [RFC4760] 293 and is used for Reverse Path Forwarding (RPF) lookups performed by 294 the IPv6 PIM. If a dedicated LAN is configured for Multicast IPv6 295 traffic exchange, reachability information for IPv6 Multicast address 296 family should be carried in new BGP sessions. ICMPv6 Neighbor 297 Discovery should be allowed in the Multicast IPv6 LAN as described in 298 the previous paragraph. 300 5. Reverse DNS 302 The inclusion of PTR records for all addresses assigned to 303 participants in the IXP reverse zone under "ip6.arpa" facilitates 304 troubleshooting, particularly when using tools such as traceroute. 305 If reverse DNS is configured, DNS servers should be reachable over 306 IPv6 transport for complete IPv6 support. 308 6. Route Server 310 IXPs may offer a Route Server service, either for Multi-Lateral 311 Peering Agreements (MLPA) service, looking glass service or route- 312 collection service. IPv6 support needs to be added to the BGP 313 speaking router. The equipment should be able to transport IPv6 314 traffic and to support Multi-protocol BGP (MP-BGP) extensions for 315 IPv6 address family ([RFC2545] and [RFC4760]). 317 A good practice is that all BGP sessions used to exchange IPv6 318 network information are configured using IPv6 data transport. This 319 configuration style ensures that both network reachability 320 information and generic packet data transport use the same transport 321 plane. In the event of IPv6 reachability problems between IPv6 322 peers, the IPv6 BGP session may be terminated independently of any 323 IPv4 sessions. The use of MD5 [RFC2385] or IPSEC [RFC4301] to 324 authenticate the BGP sessions and the use of GTSM (The Generalized 325 TTL Security Mechanism) [RFC3682] should be considered. 327 The Router-Server or Looking Glass external service should be 328 available for external IPv6 access, either by an IPv6 enabled web 329 page or an IPv6 enabled console interface. 331 7. External and Internal support 333 Some external services that need to have IPv6 support are traffic 334 graphics, DNS, FTP, Web, Route Server and Looking Glass. Other 335 external services such as NTP servers, or SIP Gateways need to be 336 evaluated as well. In general, each service that is currently 337 accessed through IPv4 or that handle IPv4 addresses should be 338 evaluated for IPv6 support. 340 Internal services are also important when considering IPv6 adoption 341 at an IXP. Such services may not deal with IPv6 traffic but may 342 handle IPv6 addresses; that is the case of provisioning systems, 343 logging tools and statistics analysis tools. Databases and tools 344 should be evaluated for IPv6 support. 346 8. IXP Policies and IPv6 348 IXP Policies and contracts should be revised as any mention of IP 349 should be clarified if it refers to IPv4, IPv6 or both. 351 9. IANA Considerations 353 This memo includes no request to IANA. 355 10. Security Considerations 357 This memo includes information on practices at IXPs for monitoring 358 and/or avoiding broadcast storms in IXP LANs caused by IPv6 multicast 359 traffic. It also mentions avoiding IPv6 DDoS attacks to the IXP 360 switching fabric by not globally announce the IXP LANs prefix and 361 recommends to monitor ICMPv6 activity. 363 11. Acknowledgements 365 The author would like to thank the contributions from Alain Aina, 366 Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, 367 Bill Woodcock, Carlos Frias, Arien Vijn, Fernando Gont and Louis Lee, 369 12. References 371 12.1. Normative References 373 [I-D.ietf-v6ops-ra-guard] 374 Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. 375 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03 376 (work in progress), May 2009. 378 [I-D.ietf-v6ops-rogue-ra] 379 Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 380 Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in 381 progress), May 2009. 383 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 384 converting network protocol addresses to 48.bit Ethernet 385 address for transmission on Ethernet hardware", STD 37, 386 RFC 826, November 1982. 388 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 389 "Simple Network Management Protocol (SNMP)", STD 15, 390 RFC 1157, May 1990. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 396 Signature Option", RFC 2385, August 1998. 398 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 399 (IPv6) Specification", RFC 2460, December 1998. 401 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 402 Networks", RFC 2464, December 1998. 404 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 405 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 406 March 1999. 408 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 409 Listener Discovery (MLD) for IPv6", RFC 2710, 410 October 1999. 412 [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL 413 Security Mechanism (GTSM)", RFC 3682, February 2004. 415 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 416 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 418 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 419 Addresses", RFC 4193, October 2005. 421 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 422 Architecture", RFC 4291, February 2006. 424 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 425 Internet Protocol", RFC 4301, December 2005. 427 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 428 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 429 Protocol Specification (Revised)", RFC 4601, August 2006. 431 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 432 "Multiprotocol Extensions for BGP-4", RFC 4760, 433 January 2007. 435 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 436 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 437 September 2007. 439 [RFC5101] Claise, B., "Specification of the IP Flow Information 440 Export (IPFIX) Protocol for the Exchange of IP Traffic 441 Flow Information", RFC 5101, January 2008. 443 12.2. Informative References 445 [RIR_IXP_POLICIES] 446 Numbers Resource Organization (NRO)., "RIRs Allocations 447 Policies for IXP. NRO Comparison matrix", 2008, 448 . 450 Author's Address 452 Roque Gagliano 453 LACNIC 454 Rambla Rep Mexico 6125 455 Montevideo, 11400 456 UY 458 Phone: +598 2 4005633 459 Email: roque@lacnic.net