idnits 2.17.1 draft-rgaglian-v6ops-v6inixp-01.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 : ---------------------------------------------------------------------------- == 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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (January 2009) is 5580 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) Summary: 2 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 January 2009 5 Expires: July 5, 2009 7 IPv6 Deployment in Internet Exchange Points (IXPs) 8 draft-rgaglian-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 July 5, 2009. 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 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document provides a guide for IPv6 deployment in Internet 48 Exchange Points (IXP). It includes information about the switching 49 fabric configuration, the addressing plan options and general 50 organizational tasks to be performed. IXP are mainly a layer 2 51 device (the switching fabric) and in many case the best 52 recommendations state that IPv6 traffic and management should not be 53 handled differently than in IPv4. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 59 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . . 3 60 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Route Server Configuration . . . . . . . . . . . . . . . . . . 6 63 6. Internal and External Services support . . . . . . . . . . . . 6 64 7. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . . 7 65 8. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 12.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 12.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Most Internet Exchange Points (IXP) work on the Layer 2 level, making 77 the adoption of IPv6 an easy task. However, IXPs normally implement 78 additional services such as statistics, route servers, looking 79 glasses, broadcast control and others that may be impacted by the 80 implementation of IPv6. This document gives guidance on the impact 81 of IPv6 on a new or an existing IXP that may or may not fit any 82 particular deployment. The document assumes an Ethernet switch 83 fabric, although other layer 2 canfigurations can be deployed. 85 1.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 88 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 89 this document are to be interpreted as described in RFC 2119 90 [RFC2119]. 92 2. Switch Fabric Configuration 94 An Ethernet based IXP switching fabric implements IPv6 over Ethernet 95 as described in RFC 2464 [RFC2464], therefore the switching of IPv6 96 traffic happens in the same way as in IPv4. However, some management 97 functions require explicit IPv6 support. Such functionalities may 98 include: switch management, SNMP support and flow analysis tools. 100 There are two common configurations of IXP switch ports to support 101 IPv6: 103 1. dual stack VLAN: both IPv4 and IPv6 traffic share a common VLAN. 104 No extra configuration is required in the switch. Typically 105 participants will configure dual stack interfaces in this 106 scenario but independent port can be an option. 108 2. independent VLAN: an IPv6 VLAN is created for IPv6 traffic. If 109 IXP participants are already using VLAN tagging on the interfaces 110 of their routers which face the IXP switch, this only requires 111 configuring one additional VLAN tag across the interconnection. 112 If participants are using untagged interconnections with the IXP 113 switch and wish to continue doing so, they will need to use a 114 separate physical port to access the IPv6-specific VLAN. 116 The "independent VLAN" configuration provides a physical separation 117 for IPv4 and IPv6 traffic simplifying the separated analysis for IPv4 118 and IPv6 traffic.However, it can be more costly in both capital 119 expenses (if new ports are needed) and operational expends. 121 The "dual stack" configuration allows a quick and cost-free start-up 122 for IPv6 support in the IXP. It also avoids transforming untagged 123 ports into tagged ports. Traffic split for statistical analysis may 124 be done using flows techniques such as in IPFIX [RFC5101] considering 125 the different ether-types (0x0800 for IPv4 and 0x86DD for IPv6). 127 The support for jumbo frames MTU should be evaluated. The only 128 technical requirement for IPv6 referring link MTUs is that it needs 129 to be greater than or equal to 1280 octets [RFC2460]. Most IXPs 130 support MTUs of 1500, 4470, or 9216 bytes, so this typically requires 131 no change of configuration. 133 3. Addressing Plan 135 Regional Internet Registries (RIRs) have specific address policies to 136 allocate Provider Independent (PI) IPv6 address to IXPs. Those 137 allocations are usually /48 prefixes [RIR_IXP_POLICIES]. Depending 138 on the country and region of operation, address allocations may be 139 provided by NIRs (National Internet Registries). 141 From the allocated prefix, following the recommendations of RFC 4291 142 [RFC4291], a /64 prefix should be allocated for each of the exchange 143 point Local Area Networks (LANs). A /48 prefix allows the addressing 144 of 65536 LANs. Longer prefixes (/65-/127), are technically feasible 145 using static address configuration, but should be avoided, in order 146 to keep EUI-64 compatibility. 148 The common practice for Interface Identifiers (IID) configuration is 149 to use static configuration, disallowing auto-configuration on every 150 interface. Also, on a LAN where all its participants are typically 151 routers, it is important that every node has it's router 152 advertisement messages RFC 4861 [RFC4861] turned off. The goal is 153 that none of the remaining routers configure it-selves a default 154 ICMPv6 route by accident. A scanning device can be set up at the IXP 155 LANs to monitor link-local multicast traffic (addresses ff02::/16), 156 allowing only ICMPv6 Neighbor Solicitation, Neighbor Advertisement 157 messages and MLD (Multicast Listener Discovery) if multicast peering 158 is permited in any particular VLAN. 160 When selecting the use of static IIDs, there are different options on 161 how to "intelligently" fill its 64 bits (or 16 hexadecimal 162 characters) in order to help both IXPs and paricipants network 163 operations. A non exhausted list of possible IID selection 164 mechanisms follows: 166 1. Some IXPs like to include the participants' ASN number decimal 167 encoding inside each IPv6 address. The ASN decimal number number 168 is used as the BCD (binary code decimal) encoding of the upper 169 part of the IID such as shown in this example: 171 * IXP LAN prefix: 2001:DB8::/64 173 * ASN: 64496 175 * IPv6 Address: 2001:DB8::6449:6000:0000:0001/64 or its 176 equivalent representation 2001:DB8::6449:6000:0:1/64 178 In this representation each ASN may require a maximum of 10 179 characters, as 16 characters are available, up to 2^24 IPv6 180 addresses can be configured per ASN. 182 2. Although BCD encoding is more "human-readable", some IXPs prefer 183 to use the hexadecimal encoding of the ASNs number as the upper 184 part of the IID as follow: 186 * IXP LAN prefix: 2001:DB8::/64 188 * ASN: 64496 (DEC) or FBF0 (HEX) 190 * IPv6 Address: 2001:DB8::0000:FBF0:0000:0001/64 or its 191 equivalent representation 2001:DB8::FBF0:0:1/64 193 In this representation each ASN may require a maximum of 8 194 characters, as 16 characters are available, up to 2^32 IPv6 195 addresses can be configured per ASN. 197 3. A third scheme for statically assigning IPv6 addresses on an IXP 198 LAN could be to relate some portion of a participant's IPv6 199 address to its correspondant IPv4 address. In the following 200 example, the last three decimals of the IPv4 address are copied 201 to the last hexadecimals of the IPv6 address, using the decimal 202 number as the BCD encoding for the last three characters of the 203 IID such as in the following example: 205 * IXP LAN prefix: 2001:DB8::/64 207 * IPv4 Address: 240.0.20.132/23 209 * IPv6 Address: 2001:DB8::132/64 211 4. A fourth configutation might be based on the IXPs ID for that 212 participant. 214 The current practice that applies to IPv4 about publishing IXP 215 allocations to the DFZ (Default Free Zone) should also apply to the 216 IPv6 allocation (normally a /48 prefix). IXP external services (such 217 as dns, web pages, ftp servers) could be part of this prefix. 219 4. Reverse DNS 221 PTR records for all addresses assigned to participants should be 222 included in the IXP reverse zone under "ip6.arpa". 224 5. Route Server Configuration 226 Some IXPs may offer a Route Server service, either for Multi-Lateral 227 (ML) Peering Agreements or for a looking glass service. IPv6 support 228 needs to be added to the router used as BGP end point. The equipment 229 should be able to transport IPv6 traffic and to support Multi- 230 protocol BGP (MP-BGP) extensions for IPv6 address family (RFC 2545 231 [RFC2545] and RFC 4760 [RFC4760]). 233 A good practice is to have IPv6 SAFI (Subsequent Address Family 234 Identifiers) information carried over sessions established also on 235 top of the IPv6 IP/TCP stack and independently of the IPv4 sessions. 236 This configuration allows that in the event of IPv6 reachability 237 issues to any IPv6 peer, the specific session will be turned down and 238 the IPv4 session to the same peer will not be affected. Please 239 consider the use of MD5 (even better IPSEC) to authenticate the BGP 240 sessions. 242 The Router-Server or Looking Glass external service should be 243 available for external IPv6 access, either by an IPv6 enabled web 244 page or an IPv6 enabled console server. 246 6. Internal and External Services support 248 Some external services that need to have IPv6 support are Traffic 249 Graphics, DNS, FTP, Web and Looking Glass. Other external services 250 such as NTP servers, or SIP Gateways need to be evaluated as well. 251 In general, each service that is accessed through IPv4 or that handle 252 IPv4 addresses should be compatible with IPv6. 254 Internal services are also important when considering IPv6 adoption 255 at an IXP. Such services may not deal with IPv6 traffic but may 256 handle IPv6 addresses; that is the case of provisioning systems, 257 logging tools and statistics analysis tools. Databases and tools 258 needs to be evaluated to determinate its IPv6 support level. 260 7. IXP Policies and IPv6 262 IXP Policies may need to be revised as any mention of IP should be 263 clarified if it refers to IPv4, IPv6 or both. The current 264 interpretation is that IP refers to the Internet Protocol, 265 independently of the its version (i.e. both IPv4 and IPv6). In any 266 case contracts and policies should be reviewed for any occurrence of 267 IP and/or IPv4 and replace it with the appropriate IP, IPv4 and/or 268 IPv6 language. 270 8. Multicast IPv6 272 Multicast IPv6 is not different from an IXP perspective than 273 Multicast IPv4. The IXP may decide to use a reserved VLAN for 274 Multicast traffic or to exchange that traffic in the same VLAN as the 275 unicast traffic. Link-local multicast traffic should be monitored as 276 this traffic should be reduced to ICMPv6 Neighbor Discovery RFC 4861 277 [RFC4861] and MLD (Multicast Listener Discovery) Protocol (MLDv2) RFC 278 3810 [RFC3810]. 280 9. IANA Considerations 282 This memo includes no request to IANA. 284 10. Security Considerations 286 This memo includes no Security Considerations. 288 11. Acknowledgements 290 The author would like to thank the contributions from Bill Woodcock 291 (PCH), Martin Levy (Hurricane Electric), Carlos FriaAas of FCCN 292 (GIGAPIX), Arien Vijn (AMS-IX) and Louis Lee (Equinix). 294 12. References 296 12.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 302 (IPv6) Specification", RFC 2460, December 1998. 304 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 305 Networks", RFC 2464, December 1998. 307 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 308 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 309 March 1999. 311 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 312 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 314 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 315 Architecture", RFC 4291, February 2006. 317 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 318 "Multiprotocol Extensions for BGP-4", RFC 4760, 319 January 2007. 321 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 322 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 323 September 2007. 325 [RFC5101] Claise, B., "Specification of the IP Flow Information 326 Export (IPFIX) Protocol for the Exchange of IP Traffic 327 Flow Information", RFC 5101, January 2008. 329 12.2. Informative References 331 [RIR_IXP_POLICIES] 332 Numbers Support Organization (NRO)., "RIRs Allocations 333 Policies for IXP. NRO Comparison matrix", 2008, 334 . 336 Author's Address 338 Roque Gagliano 339 LACNIC 340 Rambla Rep Mexico 6125 341 Montevideo, 11400 342 UY 344 Phone: +598 2 4005633 345 Email: roque@lacnic.net