idnits 2.17.1 draft-ietf-v6ops-v6inixp-01.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 (July 03, 2009) is 5412 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 333, 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 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) Summary: 5 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 July 03, 2009 5 Expires: January 4, 2010 7 IPv6 Deployment in Internet Exchange Points (IXPs) 8 draft-ietf-v6ops-v6inixp-01.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 January 4, 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 about the switch 48 fabric configuration, the addressing plan options and general 49 organizational tasks to be performed. IXP are mainly a layer 2 50 device and in many case the best recommendations state that the IPv6 51 data, control and management plane should not be handled differently 52 than 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Route Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Internal and External Services support . . . . . . . . . . . . 7 63 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 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, broadcast control that may be impacted by the implementation 78 of IPv6. This document gives guidance on the impact of IPv6 on a new 79 or an existing IXP that may or may not fit any particular deployment. 80 The document assumes an Ethernet switch fabric, algthouh other layer 81 2 canfigurations 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 its need should be 90 evaluated by the IXP administrator. 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 in IPFIX [RFC5101] considering the 118 different ether-types (0x0800 for IPv4 and 0x86DD for IPv6). 120 The only technical requirement for IPv6 referring link MTUs is that 121 it needs to be greater than or equal to 1280 octets [RFC2460]. 122 Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes, so typically 123 this requires no change of configuration. The MTU size for every LAN 124 in an IXP should be well know by all its participants. 126 3. Addressing Plan 128 Regional Internet Registries (RIRs) have specific address policies to 129 allocate Provider Independent (PI) IPv6 address to IXPs. Those 130 allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. 131 Depending on the country and region of operation, address allocations 132 may be provided by NIRs (National Internet Registries). 134 From the allocated prefix, following the recommendations of 135 [RFC4291], a /64 prefix should be allocated for each of the exchange 136 point IPv6 enabled LANs. A /48 prefix allows the addressing of 65536 137 LANs. As IXP will normally use manual address configuration, longer 138 prefixes (/65-/127), are technically feasible but are normally 139 discouraged because of operational practices.The manual configuration 140 of IPv6 addresses allows IXP participants to replace network 141 interfaces with no need to reconfigure Border Gateway Protocol (BGP) 142 sessions information and facilitates management tasks. 144 When selecting the use of static Interface Identifiers (IIDs), there 145 are different options on how to "intelligently" fill its 64 bits (or 146 16 hexadecimal characters). A non exhausted list of possible IID 147 selection mechanisms follows: 149 1. Some IXPs like to include the participants' ASN number decimal 150 encoding inside each IPv6 address. The ASN decimal number number 151 is used as the BCD (binary code decimal) encoding of the upper 152 part of the IID such as shown in this example: 154 * IXP LAN prefix: 2001:DB8::/64 156 * ASN: 64496 158 * IPv6 Address: 2001:DB8::0000:0006:4496:0001/64 or its 159 equivalent representation 2001:DB8::6:4496:1/64 161 In this example we are right justifying the participant' ASN 162 number from the the 112nd bit.Remember that 32 bits ASNs require 163 a maximum of 10 characters. Whith this example, up to 2^16 IPv6 164 addresses can be configured per ASN. 166 2. Although BCD encoding is more "human-readable", some IXPs prefer 167 to use the hexadecimal encoding of the ASNs number as the upper 168 part of the IID as follow: 170 * IXP LAN prefix: 2001:DB8::/64 172 * ASN: 64496 (DEC) or FBF0 (HEX) 174 * IPv6 Address: 2001:DB8::0000:0000:FBF0:0001/64 or its 175 equivalent representation 2001:DB8::FBF0:1/64 177 3. A third scheme for statically assigning IPv6 addresses on an IXP 178 LAN could be to relate some portion of a participant's IPv6 179 address to its IPv4 address. In the following example, the last 180 three decimals of the IPv4 address are copied to the last 181 hexadecimals of the IPv6 address, using the decimal number as the 182 BCD encoding for the last three characters of the IID such as in 183 the following example: 185 * IXP LAN prefix: 2001:DB8::/64 187 * IPv4 Address: 240.0.20.132/23 189 * IPv6 Address: 2001:DB8::132/64 191 4. A fourth approach might be based on the IXPs ID for that 192 participant. 194 The current practice that applies to IPv4 about publishing IXP 195 allocations to the DFZ (Default Free Zone) should also apply to the 196 IPv6 allocation (normally a /48 prefix). Typically IXPs LANs are not 197 globally reachable in order to avoid a Distributed Denial of Service 198 (DDoS) attack but participant may route these prefixes inside their 199 networks (ex. using BGP no-export communities or routing the IXP LANs 200 within the participant' IGP) to perform fault management. IXP 201 external services (such as dns, web pages, ftp servers) needs to be 202 globally routed and due to strict prefix length filtering could be 203 the reason to request a shorter than /48 assignment from an RIR (ex 204 requesting a /47 assignment and using one /48 for the IXPs LANs that 205 is not globally routed and one /48 for the IXP external services that 206 is globally routed). 208 4. Multicast IPv6 210 There are two elements that need to be evaluated when studying IPv6 211 multicast in an IXP: multicast support for netighbor discovery and 212 multicast peering. 214 IXPs typically control broadcast traffic accross switching fabric in 215 order to avoid broadcast storms by only allowing limited ARP 216 [RFC0826] traffic for address resolution. In IPv6 there is not 217 broadcast support but IXP may intend to control multicast traffic in 218 each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the 219 following necessary functions in an IXP switching fabric: Address 220 Resolution, Neighbor Unreachability Detection and Duplicate Address 221 Detection. In order to perform these functions, Neighbor 222 Solicitation and Neighbor Advertisement packets are exchange using 223 the link-local all-nodes multicast address (FF02::1) and/or 224 solicited-node multicast addresses (FF02:0:0:0:0:1:FF00:0000 to FF02: 225 0:0:0:0:1:FFFF:FFFF). As described in [RFC4861] routers will 226 initializate its interfaces by joining its solicited-node multicast 227 addresses using either Multicast Listener Discovery (MLD) [RFC2710] 228 or MLDv2 [RFC3810]. MLD messages may be sent to the corresponding 229 group address:FF02::2 (MLD) or FF02::16 (MLDv2). Similarly to the 230 ARP policy an IXP may limit multicast traffic acccross the switching 231 fabric in order to only allow ICMPv6 Neighbor Solicitation, Neighbor 232 Advertisement and MLD messages. Configuring default routes in an IXP 233 LAN without an agreement within the parties is normally against IXP 234 policies. For that reason, eventhough routers should ignore them, 235 rogue ICMPv6 route advertisements may be monitored in order to 236 prevent configuration errors. 238 For IPv6 Multicast traffic exhange, an IXP may decide to use either 239 the same LAN being used for unicast IPv6 traffic exchange, the same 240 LAN being used for IPv4 Multicast traffic exchange or a dedicated LAN 241 for IPv6 Multicast traffic exchange. The reason for having a 242 dedicated LAN for multicast is to prevent unwanted multicast traffic 243 to reach participants that do not have multicast support. Protocol 244 Independent Multicast [RFC4601] messages will be sent to the the 245 link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the 246 selected LAN and should be allowed. Implementing IPv6 PIM snooping 247 will allow that only the participants associated to a particular 248 group will receive its multicast traffic. BGP reachability 249 information for IPv6 multicast address-family (SAFI=2) is normally 250 exchanged using MP-BGP [RFC4760] and is used for Reverse Path 251 Forwarding (RPF) lookups performed by the IPv6 PIM (Protocol 252 Independent Multicast) protocol [RFC4601]. If a dedicated LAN is 253 configured for Multicast IPv6 traffic exchange, reachability 254 information for IPv6 Multicast address familly should be carried in 255 new BGP sessions. ICMPv6 Neighbor Discovery should be allowed in the 256 Multicast IPv6 LAN as described in the previous paragraph. 258 5. Reverse DNS 260 PTR records for all addresses assigned to participants should be 261 included in the IXP reverse zone under "ip6.arpa". DNS servers 262 should be reachable over IPv6 transport. 264 6. Route Server 266 IXPs may offer a Route Server service, either for Multi-Lateral 267 Peering Agreements (MLPA) service, looking glass service or route- 268 collection service. IPv6 support needs to be added to the BGP 269 speaking router. The equipment should be able to transport IPv6 270 traffic and to support Multi-protocol BGP (MP-BGP) extensions for 271 IPv6 address family ([RFC2545] and [RFC4760]). 273 A good practice is to have IPv6 SAFI (Subsequent Address Family 274 Identifiers) information carried over sessions established also on 275 top of the IPv6 IP/TCP stack and independently of the IPv4 sessions. 276 This configuration allows that in the event of IPv6 reachability 277 issues to any IPv6 peer, the IPv6 session will be turned down and the 278 IPv4 session to the same peer will not be affected. Please consider 279 the use of MD5 [RFC2385] or IPSEC [RFC4301] to authenticate the BGP 280 sessions. 282 The Router-Server or Looking Glass external service should be 283 available for external IPv6 access, either by an IPv6 enabled web 284 page or an IPv6 enabled console interface. 286 7. Internal and External Services support 288 Some external services that need to have IPv6 support are Traffic 289 Graphics, DNS, FTP, Web, Route Server and Looking Glass. Other 290 external services such as NTP servers, or SIP Gateways need to be 291 evaluated as well. In general, each service that is currently 292 accessed through IPv4 or that handle IPv4 addresses should be 293 evaluated for IPv6 support. 295 Internal services are also important when considering IPv6 adoption 296 at an IXP. Such services may not deal with IPv6 traffic but may 297 handle IPv6 addresses; that is the case of provisioning systems, 298 logging tools and statistics analysis tools. Databases and tools 299 should be evaluated for IPv6 support. 301 8. IXP Policies and IPv6 303 IXP Policies may need to be revised as any mention of IP should be 304 clarified if it refers to IPv4, IPv6 or both. The current 305 interpretation is that IP refers to the Internet Protocol, 306 independently of the its version (i.e. both IPv4 and IPv6). In any 307 case contracts and policies should be reviewed for any occurrence of 308 IP and/or IPv4 and replace it with the appropriate IP, IPv4 and/or 309 IPv6 language. 311 9. IANA Considerations 313 This memo includes no request to IANA. 315 10. Security Considerations 317 This memo includes no Security Considerations. 319 11. Acknowledgements 321 The author would like to thank the contributions from Stig Venaas, 322 Martin Levy, Bill Woodcock, Carlos Frias, Arien Vijn and Louis Lee. 324 12. References 326 12.1. Normative References 328 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 329 converting network protocol addresses to 48.bit Ethernet 330 address for transmission on Ethernet hardware", STD 37, 331 RFC 826, November 1982. 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 337 Signature Option", RFC 2385, August 1998. 339 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 340 (IPv6) Specification", RFC 2460, December 1998. 342 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 343 Networks", RFC 2464, December 1998. 345 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 346 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 347 March 1999. 349 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 350 Listener Discovery (MLD) for IPv6", RFC 2710, 351 October 1999. 353 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 354 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 356 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 357 Architecture", RFC 4291, February 2006. 359 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 360 Internet Protocol", RFC 4301, December 2005. 362 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 363 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 364 Protocol Specification (Revised)", RFC 4601, August 2006. 366 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 367 "Multiprotocol Extensions for BGP-4", RFC 4760, 368 January 2007. 370 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 371 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 372 September 2007. 374 [RFC5101] Claise, B., "Specification of the IP Flow Information 375 Export (IPFIX) Protocol for the Exchange of IP Traffic 376 Flow Information", RFC 5101, January 2008. 378 12.2. Informative References 380 [RIR_IXP_POLICIES] 381 Numbers Support Organization (NRO)., "RIRs Allocations 382 Policies for IXP. NRO Comparison matrix", 2008, 383 . 385 Author's Address 387 Roque Gagliano 388 LACNIC 389 Rambla Rep Mexico 6125 390 Montevideo, 11400 391 UY 393 Phone: +598 2 4005633 394 Email: roque@lacnic.net