idnits 2.17.1 draft-chkpvc-enterprise-incremental-ipv6-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 : ---------------------------------------------------------------------------- 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 (July 13, 2012) is 4297 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2011 (Obsoleted by RFC 4293) -- Obsolete informational reference (is this intentional?): RFC 2096 (Obsoleted by RFC 4292) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-04 == Outdated reference: A later version (-08) exists of draft-ietf-savi-threat-scope-05 == Outdated reference: A later version (-05) exists of draft-lopez-v6ops-dc-ipv6-02 == Outdated reference: A later version (-19) exists of draft-templin-v6ops-isops-17 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops K. Chittimaneni 3 Internet-Draft Google Inc. 4 Intended status: Informational T. Chown 5 Expires: January 14, 2013 University of Southampton 6 L. Howard 7 Time Warner Cable 8 V. Kuarsingh 9 Rogers Communications 10 Y. Pouffary 11 Hewlett Packard 12 E. Vyncke 13 Cisco Systems 14 July 13, 2012 16 Enterprise Incremental IPv6 17 draft-chkpvc-enterprise-incremental-ipv6-01 19 Abstract 21 Enterprise network administrators worldwide are in various stages of 22 preparing for or deploying IPv6 into their networks. The 23 administrators face different challenges than operators of Internet 24 access providers, and have reasons for different priorities. The 25 overall problem for many administrators will be to offer Internet- 26 facing services over IPv6, while continuing to support IPv4, and 27 while introducing IPv6 access within the enterprise IT network. The 28 overall transition will take most networks from an IPv4-only 29 environment to a dual stack network environment and potentially an 30 IPv6-only operating mode. This document helps provide a framework 31 for enterprise network architects or administrators who may be faced 32 with many of these challenges as they consider their IPv6 support 33 strategies. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 14, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . . 4 70 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . . 5 71 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5 72 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 73 3. Preparation and Assessment Phase . . . . . . . . . . . . . . . 6 74 3.1. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 6 75 3.1.1. Network infrastructure readiness assessment . . . . . 6 76 3.1.2. Applications readiness assessment . . . . . . . . . . 7 77 3.1.3. Importance of readiness validation and testing . . . . 7 78 3.2. Training . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.4. Security and Routing Policy . . . . . . . . . . . . . . . 8 81 3.4.1. Demystifying some IPv6 Security Myths . . . . . . . . 8 82 3.4.2. Similarities between IPv6 and IPv4 security . . . . . 9 83 3.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 10 84 3.5. Address Plan . . . . . . . . . . . . . . . . . . . . . . . 11 85 3.6. Program Planning . . . . . . . . . . . . . . . . . . . . . 12 86 3.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . . 13 87 4. External Phase . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 15 89 4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 17 91 4.4. Servers and Applications . . . . . . . . . . . . . . . . . 17 92 5. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.1. Network Infrastructure . . . . . . . . . . . . . . . . . . 17 94 5.2. End user devices . . . . . . . . . . . . . . . . . . . . . 19 95 5.3. Corporate Systems . . . . . . . . . . . . . . . . . . . . 20 96 5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 6. Other Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 6.1. Guest network . . . . . . . . . . . . . . . . . . . . . . 20 99 6.2. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 20 100 7. Considerations For Specific Enterprises . . . . . . . . . . . 22 101 7.1. Content Delivery Networks . . . . . . . . . . . . . . . . 22 102 7.2. Data Center Virtualization . . . . . . . . . . . . . . . . 22 103 7.3. Campus Networks . . . . . . . . . . . . . . . . . . . . . 22 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 112 1. Introduction 114 An Enterprise Network as defined in [RFC4057] as: a network that has 115 multiple internal links, one or more router connections to one or 116 more Providers, and is actively managed by a network operations 117 entity (the "administrator", whether a single person or department of 118 administrators). Adminstrators generally support an internal 119 network, consisting of users' computers and related peripherals, a 120 server network, consisting of accounting and business application 121 servers, and an external network, consisting of Internet-accessible 122 services such as web servers, email servers, VPN systems, and 123 customer applications. This document is intended as guidance for 124 network architects and administrators in planning their IPv6 125 deployments. 127 The business reasons for spending time, effort, and money on IPv6 128 will be unique to each enterprise. The most common drivers are due 129 to the fact that when Internet service providers, including mobile 130 wireless carriers, run out of IPv4 addresses, they will provide 131 native IPv6 and non-native IPv4. The non-native IPv4 service may be 132 NAT64, NAT444, Dual-stack Lite, or other transition technology, but 133 whether tunneled or translated, the native traffic will be perform 134 better and more reliably than non-native. It is thus in the 135 enterprise's interests to deploy native IPv6 itself. 137 1.1. Enterprise Assumptions 139 For the purposes of this document, assume: 141 o The administrator is considering deploying IPv6 (but see 142 Section 1.2 below). 144 o The administrator has existing IPv4 networks and devices which 145 will continue to exist. 147 o The administrator will want to minimize the level of disruption to 148 the users and services by minimizing number of technologies and 149 functions that are needed to mediate any given application. In 150 other words, provide native IP wherever possible. 152 Based on these assumptions, an administrator will want to use 153 technologies which minimize the number of flows being tunnelled, 154 translated or intercepted at any given time. The administrator will 155 choose transition technologies or strategies which allow most traffic 156 to be native, and will manage non-native traffic. This will allow 157 the administrator to minimize the cost of IPv6 transition 158 technologies, by containing the number and scale of transition 159 systems. 161 1.2. IPv4-only Considerations 163 As described in [RFC6302] administrators should take certain steps 164 even if they are not considering IPv6. Specifically, Internet-facing 165 servers should log the source port number, timestamp (from a reliable 166 source), and the transport protocol. This will allow investigation 167 of malefactors behind address-sharing technologies such as NAT44 or 168 Dual-stack Lite. Enabling this additional logging will take a few 169 minutes on each server, and will probably require restarting the 170 service. 172 Other IPv6 considerations may impact ostensibly IPv4-only networks, 173 e.g. [RFC6104] describes the rogue IPv6 RA problem, which may cause 174 problems in IPv4-only networks where IPv6 is enabled in end systems 175 on that network. 177 1.3. Reasons for a Phased Approach 179 Given the challenges of migrating user workstations, corporate 180 systems, and Internet-facing servers, a phased approach allows 181 incremental deployment of IPv6, based on the administrator's own 182 determination of priorities. The Preparation Phases is highly 183 recommended to all administrators, as it will save errors and 184 complexity in later phases. Each administrator must decide whether 185 to begin with the External Phase (as recommended in [RFC5211]) or the 186 Internal Phase. There is no "correct" answer here; the decision is 187 one for each enterprise to make. 189 Some considerations: 191 o In many cases, customers outside the network will have IPv6 before 192 the internal enterprise network. For these customers, IPv6 may 193 well perform better, especially for certain applications, than 194 translated or tunneled IPv4, so the administrator may want to 195 prioritize the External Phase. 197 o Employees who access internal systems by VPN may find that their 198 ISPs provide translated IPv4, which does not support the required 199 VPN protocols. In these cases, the administrator may want to 200 prioritize the External Phase, and any other remotely-accessible 201 internal systems. 203 o Internet-facing servers cannot be managed over IPv6 unless the 204 management systems are IPv6-capable. These might be Network 205 Management Systems (NMS), monitoring systems, or just remote 206 management desktops. Thus in some cases, the Internet-facing 207 systems are dependent on IPv6-capable internal networks. However, 208 dual-stack Internet-facing systems can still be managed over IPv4. 210 o IPv6 is enabled by default on all modern operating systems, so it 211 may be more urgent to manage and have visibility on the internal 212 traffic. 214 o In many cases, the corporate accounting, payroll, human resource, 215 and other internal systems may only need to be reachable from the 216 internal network, so they may be a lower priority. But more and 217 more internal applications support IPv6 by default and it can be 218 expected that new applications will only support IPv6. 220 o Some organizations (even when using private IPv4 221 addresses[RFC1918]) are facing IPv4 address exhaustion because of 222 the internal network growth (for example the vast number of 223 virtual machines). 225 o IPv6 restores end to end reachability even for internal 226 applications (of course security policies must still be enforced) 227 which means that with IPv6 merging networks (after two 228 organizations merged) is much easier and faster. Yet, another 229 reason to move the internal network to IPv6. 231 These considerations are in conflict; each administrator must 232 prioritize according to their local conditions. 234 2. Requirements Language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in [RFC2119] when they 239 appear in ALL CAPS. These words may also appear in this document in 240 lower case as plain English words, absent their normative meanings. 242 3. Preparation and Assessment Phase 244 3.1. Inventory Phase 246 To comprehend the inventory phase spectrum we recommended dividing 247 the problem space in two: network infrastructure readiness and 248 applications readiness. 250 3.1.1. Network infrastructure readiness assessment 252 The network infrastructure readiness assessment for IPv6 as its name 253 state is focused on the network. The goal of this assessment is 254 identify the level of readiness of network equipment. This is an 255 important step as it will help identify the effort required to move 256 to an infrastructure that supports IPv6 with the same features as the 257 existing IPv4 network (for example MPLS-VPN [RFC4364] whose 258 equivalent in IPv6 is 6VPE [RFC4659]). 260 Be able to understand which network devices are already capable, 261 which devices can be made IPv6 ready with a code/firmware upgrade, 262 and which devices will need to be replaced. The data collection 263 consists of a network discovery to gain an understanding of the 264 topology and inventory network infrastructure equipment and code 265 versions with information gathered from static files and IP address 266 management, DNS and DHCP tools. 268 Remember understanding the starting point and what are the technical 269 issues and challenges is critical as IPv6 might already be present in 270 the environment thus creating inherent security risks. 272 3.1.2. Applications readiness assessment 274 Just like network equipment, application software needs to support 275 IPv6. This includes OS, firmware, middleware and applications 276 (including internally developed applications). Vendors will 277 typically handle IPv6 enablement of off-the-shelf products. 278 Enterprises need to request this support from vendors. For 279 internally developed applications it is the responsibility of the 280 enterprise to enable them for IPv6. Analyzing how a given 281 application communicates of the network will dictate the steps 282 required to support IPv6. Applications should be made to use APIs 283 which hide the specifics of a given IP address family. Any 284 applications that use APIs, such as the C language, which exposes the 285 IP version specificity need to be modified to also work with IPv6. 287 There are two ways to IPv6-enable your applications. The first 288 approach is to have separate logic for IPv4 and IPv6, thus leaving 289 the IPv4 code path mainly untouched. This approach causes the least 290 disruption to the existing IPv4 logic flow, but introduces more 291 complexity, since the application now has to deal with two logic 292 loops with complex race conditions and error recovery mechanisms 293 between these two logic loops. The second approach is to create a 294 combined IPv4/IPv6 logic, which ensures operation regardless of the 295 IP version used on the network. We recommend using industry IPv6- 296 porting tools to locate the code that need to be updated. 298 3.1.3. Importance of readiness validation and testing 300 Lastly IPv6 introduces a completely new way of addressing endpoints, 301 which can have ramifications at the network layer all the way up to 302 the applications. So to minimize disruption during the transition 303 phase we recommend complete functionality, scalability and security 304 testing to understand how IPv6 impacts the services and networking 305 infrastructure will be paramount. 307 3.2. Training 309 IPv6 planning and deployment in the enterprise is not an entirely 310 network centric affair. IPv6 adoption will be a multifaceted 311 undertaking that will touch everyone in the organization. While 312 technology and process transformations are taking place is it 313 critical that people training takes place as well. Training will 314 ensure that people and skill gaps are assessed proactively and 315 managed accordingly. We recommend that training needs be analyzed 316 and defined in order to successfully inform, train, and prepare staff 317 for the impacts of the system or process changes. 319 3.3. Routing 321 When deploying IPv6, we recommend initially choosing an IGP protocol 322 you are familiar with. That is to say if you are using OSPFv2 you 323 should be using OSPFv3. The main advantage of this approach is that 324 staff do not need to be trained and existing processes can be 325 leveraged. 327 Enterprises could also take the opportunity the introduction of IPv6 328 brings to analyze your current environment and to identify which 329 features you would like to change and what you would like to 330 implement. Then using the validation period as a way to validate 331 your new approach and even applying them to your IPv4 environment. 333 Either way IPv6 introduces the opportunity to rationalize the 334 environment and to architect it for growth. 336 3.4. Security and Routing Policy 338 It is obvious that IPv6 network should be deployed in a secure way. 339 The industry has learned a lot about network security with IPv4, so, 340 network operators should leverage this knowledge and expertise when 341 deploying IPv6. IPv6 is not so different than IPv4: it is a 342 connectionless network protocol using the same lower layer service 343 and delivering the same service to the upper layer. Therefore, the 344 security issues and mitigation techniques are mostly identical with 345 same exceptions that are described further. 347 3.4.1. Demystifying some IPv6 Security Myths 349 Some people believe that IPv6 is inherently more secure than IPv4 350 because it is new. Nothing can be more wrong. Indeed, being a new 351 protocol means that bugs in the implementations have yet to be 352 discovered and fixed and that few people have the operational 353 security expertise needed to operate securely an IPv6 network. This 354 lack of operational expertise is the biggest threat when deploying 355 IPv6: the importance of training is to be stressed again. 357 One security myth is that thanks to its huge address space, a network 358 cannot be scanned by enumerating all IPv6 address in a /64 LAN hence 359 a malevolent person cannot find a victim. [RFC5157] describes some 360 alternate techniques to find potential targets on a network, for 361 example enumerating all DNS names in a zone. 363 Another security myth is that IPv6 is more secure because it mandates 364 the use of IPsec everywhere. [RFC6434] clearly states that the IPv6 365 support is a SHOULD only. Moreover, if all the intra-enterprise 366 traffic is encrypted, then this renders all the network security 367 tools (IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless. 368 Therefore, IPsec should be used in IPv6 pretty much like in IPv4 (for 369 example to establish a VPN overlay over a non-trusted network or 370 reserve to some specific applications). 372 The last security myth is that amplification attacks (such as 373 http://www.cert.org/advisories/CA-1998-01.html) do not exist in IPv6 374 because there is no more broadcast. Alas, this is not true as ICMP 375 error (in some cases) or information messages can be generated by 376 routers and hosts when forwarding or receiving a multicast message 377 (section 2.4 of [RFC4443]). Therefore, the generation and the 378 forwarding rate of ICMPv6 messages must be rate limited as in IPv4. 380 3.4.2. Similarities between IPv6 and IPv4 security 382 As mentioned earlier, IPv6 is quite similar to IPv4, therefore 383 several attacks apply for both protocol family: 385 o Application layer attacks: such as cross-site scripting or SQL 386 injection 388 o Rogue device: such as a rogue WiFi Access Point 390 o Flooding and all traffic based denial of services (including the 391 use of control plane policing for IPv6 traffic see [RFC6192]) 393 o Etc 395 A specific case of congruence is the IPv6 ULA [RFC4193] and IPv4 396 private addressing [RFC1918] that do not provide any security by 397 'magic'. In both case, the edge router must apply strict data plane 398 and routing policy to block those private addresses to leave and 399 enter the network. This filtering can be done by the enterprise or 400 by the ISP. 402 IPv6 addresses can be spoofed as easily as IPv4 addresses and there 403 are packets with bogons IPv6 addresses (see 404 http://www.team-cymru.org/Services/Bogons/). The anti-bogon 405 filtering must be done in the data and routing planes. It can be 406 done by the enterprise or by the ISP. 408 3.4.3. Specific Security Issues for IPv6 410 Even if IPv6 is similar to IPv4, there are some differences that 411 create some IPv6-only vulnerabilities or issues. 413 Privacy extension addresses [RFC4941] are usually to protect 414 individual privacy by changing periodically the interface identifier 415 part of the IPv6 address to avoid tracking a host by its always 416 identical and unique EUI-64. While this presents a real advantage on 417 the Internet, it complicates the task of audit trail when a security 418 officer or network operator wants to trace back a log entry to a host 419 in their network because when the tracing is done the searched IPv6 420 address could have disappeared from the network. A good way to 421 prevent the use of privacy extension addresses without host 422 configuration is to send the Router Advertisement with the M-bit set 423 (to force the use of DHCPv6 to get an address) and with all 424 advertized prefixes without the A-bit set (to prevent the use of 425 stateless auto-configuration). 427 Extension headers complicate the task of stateless packet filters 428 such as ACL. If ACL are used to enforce a security policy, then the 429 enterprise must verify whether its ACL (but also stateful firewalls) 430 are able to process extension headers (this means understand them 431 enough to parse them to find the upper layers payloads) and to block 432 unwanted extension headers (e.g. to implement [RFC5095]). 434 Fragmentation is different in IPv6 because it is done only by source 435 host and never during a forwarding operation. This means that ICMPv6 436 packet-too-big must be allowed [RFC4890] through all filters. 437 Fragments can also be used to evade some security mechanisms such as 438 RA-guard [RFC6105], see also [RFC5722]which appears to be widely 439 implemented in 2012. 441 But, the biggest difference is the replacement of ARP (RFC 826) by 442 Neighbor Discovery Protocol [RFC4861]. NDP runs over ICMPv6 (this 443 means that security policies MUST allow some ICMPv6 messages see RFC 444 4890) but has the same lack of security as ARP (SeND [RFC3971] and 445 CGA [RFC3972] are not widely implemented). ARP can be made secure 446 with the help of techniques known as DHCPv4 snooping and dynamic ARP 447 inspection by access switches. Therefore, enterprises using those 448 techniques for IPv4 should use the equivalent techniques for IPv6: 449 this is RA-guard (RFC 6105) and all work in progress from the SAVI WG 450 ([I-D.ietf-savi-threat-scope] and others). Another DoS 451 vulnerabilities are related to NDP cache exhaustion 452 ([I-D.gashinsky-v6ops-v6nd-problems]) and they can be mitigated by 453 careful tuning of the NDP cache. In 2012, there are already several 454 vendors offering those features on their switches. 456 Running a dual-stack network doubles the attack exposure as a 457 malevolent person has now two attack vectors: IPv4 and IPv6. This 458 simply means that all routers and hosts operating in a dual-stack 459 environment with both protocol families enabled (even if by default) 460 must have a congruent security policy for both protocol version. For 461 example, permit TCP ports 80 and 443 to all web servers and deny all 462 other ports to the same servers must be implemented both for IPv4 and 463 IPv6. 465 3.5. Address Plan 467 The most common problem encountered in IPv6 networking is in applying 468 the same principles of conservation that are so important in IPv4. 469 IPv6 addresses do not need to be assigned conservatively. In fact, a 470 single larger allocation is considered more conservative than 471 multiple discountiguous small blocks, because a single block occupies 472 only a single entry in a routing table. The advice in [RFC5375] is 473 still sound, and is recommended to the reader. If considering ULAs, 474 give careful consideration to how well it is supported, especially in 475 multiple address and multicast scenarios, and assess the strength of 476 the requirement for ULA. 478 The enterprise administrator will want to evaluate whether the 479 enterprise will request address space from its ISP (or Local Internet 480 Registry (LIR)), or whether to request address space from the local 481 Internet Registry (whether a Regional Internet Registry such as 482 AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet 483 Registry, operated in some countries). There may be a registration 484 fee for requesting provider-independent (PI) space from and NIR/RIR, 485 but the enterprise will avoid some complexity if renumbering is 486 required after changing ISPs (it should be noted that renumbering 487 caused by outgrowing the space, merger, or other internal reason 488 might not be avoided with PI space). 490 Each location, no matter how small, should get at least a /48. In 491 addition to allowing for simple planning, this can allow a site to 492 use its prefix for local connectivity, should the need arise, and if 493 the local ISP supports it. Generally, workstations managed by the 494 enterprise will use stateful DHCPv6 for addressing on corporate LAN 495 segments. DHCPv6 allows for the additional configuration options 496 often employed by enterprise administrators, and by using stateful 497 DHCPv6, administrators correlating system logs know which system had 498 which address at any given time. 500 In the data center or server room, assume a /64 per VLAN. This 501 applies even if each individual system is on a separate VLAN; in a 502 /48 assignment, typical for a site, there are 65,535 /64 blocks. 503 Addresses are either configured manually on the server, or reserved 504 on a DHCPv6 server, which may also synchronize forward and reverse 505 DNS. 507 All user access networks MUST be a /64. Point-to-point links without 508 MAC addresses (this is where Neighbor Discovery Protocol does not 509 run) SHOULD be a /127 (see also [RFC6164]). 511 Plan to aggregate at every layer of network hierarchy. Where 512 multiple VLANs or other layer two domains converge, allow some room 513 for expansion. Renumbering due to outgrowing the network plan is a 514 nuisance, so allow room within it. Generally, grow to about twice 515 the current size can be accomodated; where rapid growth is planned, 516 allow for twice that growth. Also, for any part of the network where 517 DNS (or reverse DNS) zones may be delegated, it is important to 518 delegate addresses on nibble boundaries (this is on a multiple of 4 519 bits), to ensure propose name delegation. 521 3.6. Program Planning 523 As with any project, an IPv6 deployment project will have its own 524 phases. Generally, one person is identified as the project sponsor 525 or champion, who will make sure time and talent resources are 526 prioritized appropriately for the project. Because enabling IPv6 can 527 be a project with many interrelated tasks, identifying a project 528 manager is also recommended. The project manager and sponsor can 529 initiate the project, determining the scope of work and identifying 530 whose input is required, and who will be affected by work. The scope 531 will generally include the Preparation Phase, and may include the 532 Internal Phase, the External Phase, or both, and may include any or 533 all of the Other Phases identified. 535 The project manager will need to spend some time planning. It is 536 often useful for the sponsor to communicate with stakeholders at this 537 time, to explain why IPv6 is important to the enterprise. Then, as 538 the project manager is assessing what systems and elements will be 539 affected, the stakeholders will understand why it is important for 540 them to support the effort. Well-informed project participants can 541 help significantly by explaining the relationships between 542 components. For a large enterprise, it may take several iterations 543 to really understand the level of effort required; some systems will 544 require additional development, some might require software updates, 545 and others might need new versions or alternate vendors. Once the 546 projects are understood, the project manager can develop a schedule 547 and a budget, and work with the project sponsor to determine what 548 constraints can be adjusted, if necessary. 550 It is tempting to roll IPv6 projects into other architectural 551 upgrades - this can be an excellent way to improve the network and 552 reduce costs. Project participants are advised that by increasing 553 the scope of projects, the schedule is often affected. For instance, 554 a major systems upgrade may take a year to complete, where just 555 patching existing systems may take only a few months. Understanding 556 and evaluating these trade-offs are why a project manager is 557 important. 559 It is very common for assessments to continue in some areas even as 560 execution of the project begins in other areas. This is fine, as 561 long as recommendations in other parts of this document are 562 considered, especially regarding security (for instance, one should 563 not deploy IPv6 on a system before security has been evaluated). The 564 project manager will need to continue monitoring the progress of 565 discrete projects and tasks, to be aware of changes in schedule, 566 budget, or scope. "Feature creep" is common, where engineers or 567 management wish to add other features while IPv6 development or 568 deployment is ongoing; each feature will need to be individually 569 evaluated for its effect on the schedule and budget, and whether 570 expanding the scope increases risk to any other part of the project. 572 As projects are completed, the project manager will confirm that work 573 has been completed, often by means of seeing a completed test plan, 574 and will report back to the project sponsor on completed parts of the 575 project. A good project manager will remember to thank the people 576 who executed the project. 578 3.7. Tools Assessment 580 Enterprises will often have a number of operational tools and support 581 systems which are used to provision, monitor, manage and diagnose the 582 network and systems within their environment. These tools and 583 systems will need to be assessed for compatibility with IPv6 584 operation. The compatibility may be related to actual addressing and 585 connectivity of various devices as well as IPv6 awareness in many of 586 tools and processing logic. 588 The tools within the organization fall into two general categories, 589 those which focus on managing the network, and those which are 590 focused on managing systems and applications on the network. In 591 either instance, the tools will run on platforms which may or may not 592 be capable of operating in an IPv6 network. This lack in 593 functionality may be related to Operating system version, or based on 594 some hardware constraint. Those systems which are found to be 595 incapable of utilizing a IPv6 connection may need to be replaced or 596 upgraded. 598 In addition to devices working on an IPv6 network natively, or via a 599 tunnel, many tools and support systems may require additional updates 600 to be IPv6 aware or even a hardware upgrade (mainly because of the 601 memory utilization by IPv6 as the addresses are larger and because, 602 for a while, IPv4 and IPv6 addresses will coexist in the tool). This 603 awareness may include the ability to manage IPv6 elements and/or 604 applications in addition to the ability to store and utilize IPv6 605 addresses. 607 Considerations when assessing the tools and support systems may 608 include the fact that IPv6 addresses are significantly larger then 609 IPv4 requiring datastores to support the increased size. Such issues 610 are among those discussed in [RFC5952]. Many organizations may also 611 run dual stack networks, therefore the tools need not only support 612 IPv6 operation, but may also need to support the monitoring, 613 management and intersection with both IPv6 and IPv4 simultaneously. 614 It is important to note that managing IPv6 is not just constrained to 615 using large IPv6 addresses, but also that IPv6 interfaces and nodes 616 may use two or more addresses as part of normal operation. Updating 617 management systems to deal with these additional nuances will likely 618 time and considerable effort. 620 For networking focus systems, like node management systems, it is not 621 always necessary to support local IPv6 addressing and connectivity. 622 Operation, such as SNMP MIB polling can occur over IPv4 transport 623 while seeking responses related to IPv6 information. Where this may 624 seem advantageous to some, it should be noted that without local IPv6 625 connectivity, the management system may not be able to perform all 626 expected functions - such as reachability and service checks. 628 Organizations should be aware of changes to older IPv4-Only SNMP MIB 629 specifications have been made by the IETF related to legacy operation 630 in [RFC2096] and [RFC2011]. Updated specifications are now available 631 in [RFC4296] and [RFC4293] which modified the older MIB framework to 632 be IP protocol agnostic supporting IPv4 and IPv6. Polling systems 633 will need to be upgraded to support these updates as well as the end 634 stations which are polled. 636 4. External Phase 638 The external phase for Enterprise IPv6 adoption covers topics which 639 deal with how an organization connects their infrastructure to the 640 external world. These external connections may be toward the 641 Internet at larges, or other networks. The external phase covers 642 connectivity, security, monitoring of various elements and outward 643 facing or accessible services. 645 How an organization connects to the outside worlds is very important 646 as it is often a critical part of how a business functions, therefore 647 must be dealt accordingly. 649 4.1. Connectivity 651 The Enterprise will need to work with one or more Service Providers 652 to gain connectivity to the Internet or transport service 653 infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364] 654 and [RFC4659]. On significant factor guiding how an organization may 655 need to communist with the outside world will involve the use of PI 656 (Provider Independent) and/or PA (Provider Aggregatable) IPv6 space. 658 In the case of PI, the organization will need to support BGP based 659 connectivity for the most part since the address space is assigned 660 direction from the Regional Registry to the local network. In this 661 case, the local network would act as an Autonomous System on the 662 Internet and must advertise routes accordingly. PA space is 663 delegated form the upstream service provider and can then be assigned 664 to the local network. If PA space is used, other forms of route 665 exchange may be possible such as RIPng, OSPFv3 and static. PA 666 assigned space would normally be routed to the general Internet via 667 the upstream providers infrastructure lightening the burden on the 668 local network administrations. 670 PI and PA space have additional contrasting behaviours when use such 671 as how dual homing may work. Should an operator choose to dual home, 672 PI space would be routed to both upstream providers and then passed 673 on to other networks. Utilizing more then one upstream Service 674 Provider may introduce challenges since traffic utilizing a given PA 675 assign block would be expected to flow through the assigning provider 676 for entry to the Internet. Should traffic flow using sources 677 addresses which are not delegated form a given provider, reverse path 678 forwarding rules on the operator side may reject some traffic. These 679 considerations are quite different then those of IPv4 which relied on 680 NAT in most cases. 682 When seeking IPv6 connectivity to a Service Provider, the Enterprise 683 will want to attempt to use Native IPv6 connectivity. Native IPv6 684 connectivity is preferred since it provides the most rebuts form of 685 connectivity. If Native IPv6 connectivity is not possible due to 686 technical or business limitations, the Enterprise may utilize readily 687 available tunnelled IPv6 connectivity. There are IPv6 transit 688 providers which provide tunnelled IPv6 connectivity which can operate 689 over IPv4 networks. A Enterprise need not need to wait for their 690 local Service Provider to support IPv6, as tunnelled connectivity can 691 be used. 693 4.2. Security 695 The most important part of security for external IPv6 deployment is 696 filtering. Filtering can be done by stateless ACL or stateful 697 firewall. As described in section 2.4.3, the security policies must 698 be congruent for IPv4 and IPv6 except that ICMPv6 messages must be 699 allowed through and to the filtering device (see [RFC4890]): 701 o unreachable packet-too-big 703 o unreachable parameter-problem 705 o neighbor solicitation 707 o neighbor advertisement 709 ** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd 710 black holes? ** 712 It could also be safer to block all fragments where the transport 713 layer header is not in the first fragment to avoid attack as 714 described in [RFC5722]. Some filtering devices allow this filtering. 715 To be fully compliant with [RFC5095], it can be useful to drop all 716 packet containing the routing extension header type 0. 718 If Intrusion Prevention Systems (IPS) are used for IPv4 traffic, then 719 the same IPS should also be used for IPv6 traffic. This is just a 720 generalization of the dual-stack deployment: do for IPv6 what you do 721 for IPv4. This also include all email content protection (anti-spam, 722 content filtering, data leakage prevention, etc). 724 The peering router must also implement anti-spoofing technique based 725 on [RFC2827]. 727 In order to protect the networking device, it is advised to implement 728 control plane policing as per [RFC6192]. 730 The NDP cache exhaustion (see [I-D.gashinsky-v6ops-v6nd-problems]) 731 attack can be mitigated by two techniques: 733 o good NDP implementation with memory utilization limits as well as 734 rate-limiters and prioritization of requests. 736 o else, as the external deployment usually involves just a couple of 737 exposed IPv6 statically configured addresses (virtual address of 738 web, email servers, DNS server), then it is straightforward to 739 build an ingress ACL allowing traffic for those addresses and 740 denying traffic to any other addresses. This actually prevents 741 the attack as packet for random destination will be dropped and 742 will never trigger a neighbor resolution. 744 4.3. Monitoring 746 Monitoring the use of the Internet connectivity should be done for 747 IPv6 if it is done for IPv4. This includes the use of IP flow export 748 [RFC5102] to detect abnormal traffic pattern (such as port scanning, 749 SYN-flooding) and SNMP MIB [RFC4293] (another way to detect abnormal 750 bandwidth utilization). 752 4.4. Servers and Applications 754 5. Internal Phase 756 This phase deals with the delivery of IPv6 to the internal user 757 facing side of the IT infrastructure, which comprises of various 758 components such as network devices (routers, switches, etc.), end 759 user devices and peripherals (workstations, printers, etc.), and 760 internal corporate systems. 762 An important design paradigm to consider during this phase is "Dual 763 Stack when you can, tunnel when you must". Dual stacking allows you 764 to build a more robust IPv6 network that is of production quality as 765 opposed to tunnels that are harder to troubleshoot and support. 766 Tunnels however do provide operators with a quick and easy way to 767 play with IPv6 and gain some operational experience with the 768 protocol. [RFC4213] describes various transition mechanisms in more 769 detail. [I-D.templin-v6ops-isops] suggests operational guidance when 770 using ISATAP tunnels [RFC5214]. 772 5.1. Network Infrastructure 774 The typical enterprise network infrastructure comprises of a 775 combination of the following network elements - wired access 776 switches, wireless access points, and routers. Although, it is 777 fairly common to find hardware that collapses switching and routing 778 functionality into a single device. Basic wired access switches and 779 access points that operate only at the physical and link layer, don't 780 really have any special IPv6 considerations other than being able to 781 support IPv6 addresses themselves for management purposes, if the 782 same exists for IPv4. In many instances, these devices possess a lot 783 more intelligence than simply switching packets. For example, some 784 of these devices help assist with link layer security by 785 incorporating features such as ARP inspection and DHCP Snooping. 787 An important design choice to be made is what IGP to use inside the 788 network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6 789 today and picking one over the other is purely a design choice that 790 will be dictated mostly by existing operational policies in an 791 enterprise network. As mentioned earlier, it would be beneficial to 792 maintain operational parity between IPv4 and IPv6 and therefore it 793 might make sense to continue using the same protocol family that is 794 being used for IPv4. For example, if you use OSPFv2 for IPv4, it 795 might make sense to use OSPFv3 now. 797 Another important consideration in enterprise networks is first hop 798 router redundancy. This directly ties into network reachability from 799 an end host's point of view. IPv6 Neighbor Discovery (ND), 800 [RFC4861], provides a node with the capability to maintain a list of 801 available routers on the link, in order to be able to switch to a 802 backup path should the primary be unreachable. By default, ND will 803 detect a router failure in 38 seconds and cycle onto the next default 804 router listed in its cache. While this feature does provide with a 805 basic level of first hop router redundancy, most enterprise IPv4 806 networks are designed to fail over much faster. Although this delay 807 can be improved by adjusting the default timers, care must be taken 808 to protect against transient failures and to account for increased 809 traffic on the link. Another option to provide robust first hop 810 redundancy is to use the Virtual Router Redundancy Protocol for IPv6 811 (VRRPv3), [RFC5798]. This protocol provides a much faster switchover 812 to an alternate default router than default ND parameters. Using 813 VRRP, a backup router can take over for a failed default router in 814 around three seconds (using VRRP default parameters). This is done 815 without any interaction with the hosts and a minimum amount of VRRP 816 traffic. 818 Last but not the least, one of the most important design choices to 819 make while deploying IPv6 on the internal network is whether to use 820 Stateless Automatic Address Configuration (SLAAC), [RFC4862], or 821 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or 822 a combination thereof (possible when using a /64 subnet). Each 823 option has its own unique set of pros and cons and the choice will 824 ultimately depend on the operational policies that guide each 825 enterprise's network design. For example, if an enterprise is 826 looking for ease of use, rapid deployments, and less administrative 827 overhead, then SLAAC makes more sense. However, if the operational 828 policies call for precise control over IP address assignment for 829 auditing then DHCPv6 would be the way to go. DHCPv6 also allows you 830 tie into DNS systems for host entry updates and gives you the ability 831 to send other options information to clients. In the long term, 832 DHCPv6 makes most sense for use in a managed environment. 834 5.2. End user devices 836 Most operating systems (OS) that are loaded on workstations and 837 laptops in a typical enterprise support IPv6 today. However, there 838 are various out-of-the-box nuances that one should be mindful about. 839 For example, the default behavior of OSes vary, some may have IPv6 840 turned off entirely by default, some may only have certain features 841 such as privacy addresses turned off while others have IPv6 fully 842 enabled. It is important to note that most operating systems will, 843 by default, prefer to use native IPv6 over IPv4 when enabled. 844 Therefore, it is advised that enterprises investigate the default 845 behavior of their installed OS base and account for it during the 846 implementation of IPv6. Furthermore, some OSes may have tunneling 847 mechanisms turned on by default and in such cases, it is recommended 848 to administratively shut down such interfaces unless required. It is 849 recommended that IPv6 be deployed at the network infrastructure level 850 before it is rolled out to end user devices. 852 Smartphones and tablets are poised to become one of the major 853 consumers of IP addresses and enterprises should be ready to deploy 854 and support IPv6 on various networks that serve such devices. In 855 general, support for IPv6 in these devices, albeit in its infancy, 856 has been steadily rising. Most of the leading smartphone OSes have 857 some level of support for IPv6. However, the level of configurable 858 options are mostly at a minimum and are not consistent across all 859 platforms. Also, it is fairly common to find IPv6 support on the 860 wifi connection alone and not on the radio interface in these 861 devices. This is sometimes due to the radio network not being ready 862 or device related. An IPv6 enabled enterprise wifi network will 863 allow the majority of these devices to connect via IPv6. Much work 864 is still being done to bring the full IPv6 feature set across all 865 interfaces (802.11, 3G, LTE, etc.) and platforms. 867 IPv6 support in peripheral equipment such as printers, IP Cameras, 868 etc. has been steadily rising as well, although at a much slower pace 869 than traditional OSes and Smartphones. Most newer devices are coming 870 out with IPv6 support but there is still a large installed base of 871 legacy peripheral devices that might need IPv4 for sometime to come. 872 The audit phase mentioned earlier will make it easier for enterprises 873 to plan for equipment upgrades, in line with their corporate 874 equipment refresh cycle. 876 5.3. Corporate Systems 878 No IPv6 deployment will be successful without ensuring that all the 879 corporate systems that enterprise uses as part of their IT 880 infrastructure, support IPv6. Examples of such systems include, but 881 are not limited to, Email, Video Conferencing, Telephony (VoIP), DNS, 882 Radius, etc. All these systems must have their own detailed IPv6 883 rollout plan in conjunction with the network IPv6 rollout. It is 884 important to note that DNS is one of the main anchors in an 885 enterprise deployment, since most end hosts decide whether or not use 886 IPv6 based on the presence of AAAA records in a reply to a DNS query. 887 It is recommended that system administrators selectively turn on AAAA 888 records for various systems as and when they are IPv6 enabled. 889 Additionally, all monitoring and reporting tools across the 890 enterprise would need to be modified to support IPv6. 892 5.4. Security 894 IPv6 must be deployed in a secure way. This means that all existing 895 IPv4 security policies must be extended to support IPv6; IPv6 896 security policies will be the IPv6 equivalent of the existing IPv4 897 ones (taking into account the difference for ICMPv6 [RFC4890]). As 898 in IPv4, security policies for IPv6 will be enforced by firewalls, 899 ACL, IPS, VPN, ... 901 Privacy extension addresses [RFC4941] pose a real challenge for audit 902 trail. Therefore, it is recommended not to use them within the 903 enterprise network by using the configuration described previously. 905 But, the biggest problem is probably linked to all threats against 906 Neighbor Discovery. This means that the internal network at the 907 access layer (i.e. where hosts connect to the network over wired or 908 wireless) must implement RA-guard [RFC6105] and the techniques being 909 specified by SAVI WG [I-D.ietf-savi-threat-scope]. 911 6. Other Phases 913 To be added. 915 6.1. Guest network 917 To be added. 919 6.2. IPv6-only 921 Although IPv4 and IPv6 networks will coexist for a long time to come, 922 the long term enterprise network roadmap should include steps on 923 gradually deprecating IPv4 from the dual-stack network. In some 924 extreme cases, deploying dual-stack networks may not even be a viable 925 option for very large enterprises due to lack of availability of RFC 926 1918 addresses. In such cases, deploying IPv6-only networks might be 927 the only choice available to sustain network growth. 929 If nodes in the network don't need to talk to an IPv4-only node, then 930 deploying IPv6-only networks should fe fairly trivial. However, in 931 the current environment, given that IPv4 is the dominant protocol on 932 the Internet, an IPv6-only node most likely needs to talk to an IPv4- 933 only node on the Internet. It is therefore important to provide such 934 nodes with a translation mechanism to ensure communication between 935 nodes configured with different address families. As [RFC6144] 936 points out, it is important to look at address translation as a 937 transition strategy that will get you to an IPv6-only network. 939 There are various stateless and stateful IPv4/IPv6 translation 940 methods available today that help IPv4 to IPv6 communication. RFC 941 6144 provides a framework for IPv4/IPv6 translation and describes in 942 detail various scenarios in which such translation mechanisms could 943 be used. [RFC6145] describes stateless address translation. In this 944 mode, a specific IPv6 address range will represent IPv4 systems 945 (IPv4-converted addresses), and the IPv6 systems have addresses 946 (IPv4-translateable addresses) that can be algorithmically mapped to 947 a subset of the service provider's IPv4 addresses. [RFC6146], NAT64, 948 describes stateful address translation. As the name suggests, the 949 translation state is maintained between IPv4 address/port pairs and 950 IPv6 address/port pairs, enabling IPv6 systems to open sessions with 951 IPv4 systems. [RFC6147], DNS64, describes a mechanism for 952 synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs 953 6146 and RFC 6147 provide a viable method for an IPv6-only client to 954 initiate communications to an IPv4-only server. 956 The address translation mechanisms for the stateless and stateful 957 translations are defined in [RFC6052]. It is important to note that 958 both of these mechanisms have limitations as to which protocols they 959 support. For example, RFC 6146 only defines how stateful NAT64 960 translates unicast packets carrying TCP, UDP, and ICMP traffic only. 961 The ultimate choice of which translation mechanism to chose will be 962 dictated mostly by existing operational policies pertaining to 963 application support, logging requirements, etc. 965 There is additional work being done in the area of address 966 translation to enhance and/or optimize current mechanisms. For 967 example, [I-D.xli-behave-divi] describes limitations with the current 968 stateless translation, such as IPv4 address sharing and application 969 layer gateway (ALG) problems, and presents the concept and 970 implementation of dual-stateless IPv4/IPv6 translation (dIVI) to 971 address those issues. 973 7. Considerations For Specific Enterprises 975 7.1. Content Delivery Networks 977 To be added. 979 7.2. Data Center Virtualization 981 Another document ([I-D.lopez-v6ops-dc-ipv6]) describes in details the 982 specifics about IPv6 Data Center. 984 7.3. Campus Networks 986 A number of campus networks have made some initial IPv6 deployment. 987 There are generally three areas in which such deployments may be 988 made, which correspond to the Internal Phase, External Phase and 989 Other Phase (Guest Network) descrobed above. 991 In particular the areas commonly approached are: 993 o External-facing services. Typically the campus web presence and 994 commonly also external-facing DNS and MX services. 996 o Computer science department. This is where IPv6-related research 997 and/or teaching is most likely to occur, so enabling some or all 998 of the campus compauter science department network is a sensible 999 first step. 1001 o The eduroam wireless network. Eduroam is the defacto wireless 1002 roaming system for academic networks, and uses 802.1X based 1003 authentication, which is agnostic to the IP version used (unlike 1004 web-redirection gateway systems). 1006 8. Security Considerations 1008 9. Acknowledgements 1010 The authors would like to thank Chris Grundemann, Ray Hunter, Brian 1011 Carpenter, Tina Tsou for their comments on the mailing list. 1013 10. IANA Considerations 1015 There are no IANA considerations or implications that arise from this 1016 document. 1018 11. References 1020 11.1. Normative References 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 11.2. Informative References 1027 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1028 E. Lear, "Address Allocation for Private Internets", 1029 BCP 5, RFC 1918, February 1996. 1031 [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for 1032 the Internet Protocol using SMIv2", RFC 2011, 1033 November 1996. 1035 [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, 1036 January 1997. 1038 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1039 Defeating Denial of Service Attacks which employ IP Source 1040 Address Spoofing", BCP 38, RFC 2827, May 2000. 1042 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1043 and M. Carney, "Dynamic Host Configuration Protocol for 1044 IPv6 (DHCPv6)", RFC 3315, July 2003. 1046 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1047 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1049 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1050 RFC 3972, March 2005. 1052 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 1053 June 2005. 1055 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1056 Addresses", RFC 4193, October 2005. 1058 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1059 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1061 [RFC4293] Routhier, S., "Management Information Base for the 1062 Internet Protocol (IP)", RFC 4293, April 2006. 1064 [RFC4296] Bailey, S. and T. Talpey, "The Architecture of Direct Data 1065 Placement (DDP) and Remote Direct Memory Access (RDMA) on 1066 Internet Protocols", RFC 4296, December 2005. 1068 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1069 Networks (VPNs)", RFC 4364, February 2006. 1071 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1072 Message Protocol (ICMPv6) for the Internet Protocol 1073 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1075 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1076 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1077 IPv6 VPN", RFC 4659, September 2006. 1079 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1080 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1081 September 2007. 1083 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1084 Address Autoconfiguration", RFC 4862, September 2007. 1086 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1087 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1089 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1090 Extensions for Stateless Address Autoconfiguration in 1091 IPv6", RFC 4941, September 2007. 1093 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1094 of Type 0 Routing Headers in IPv6", RFC 5095, 1095 December 2007. 1097 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1098 Meyer, "Information Model for IP Flow Information Export", 1099 RFC 5102, January 2008. 1101 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1102 RFC 5157, March 2008. 1104 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 1105 July 2008. 1107 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1108 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1109 March 2008. 1111 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1112 and C. Hahn, "IPv6 Unicast Address Assignment 1113 Considerations", RFC 5375, December 2008. 1115 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1116 RFC 5722, December 2009. 1118 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 1119 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 1121 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1122 Address Text Representation", RFC 5952, August 2010. 1124 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1125 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1126 October 2010. 1128 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1129 Problem Statement", RFC 6104, February 2011. 1131 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1132 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1133 February 2011. 1135 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1136 IPv4/IPv6 Translation", RFC 6144, April 2011. 1138 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1139 Algorithm", RFC 6145, April 2011. 1141 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1142 NAT64: Network Address and Protocol Translation from IPv6 1143 Clients to IPv4 Servers", RFC 6146, April 2011. 1145 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1146 Beijnum, "DNS64: DNS Extensions for Network Address 1147 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1148 April 2011. 1150 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1151 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1152 Router Links", RFC 6164, April 2011. 1154 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1155 Router Control Plane", RFC 6192, March 2011. 1157 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1158 "Logging Recommendations for Internet-Facing Servers", 1159 BCP 162, RFC 6302, June 2011. 1161 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1162 Requirements", RFC 6434, December 2011. 1164 [I-D.xli-behave-divi] 1165 Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual- 1166 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 1167 (work in progress), October 2011. 1169 [I-D.gashinsky-v6ops-v6nd-problems] 1170 Jaeggli, J., Kumari, W., and I. Gashinsky, "Operational 1171 Neighbor Discovery Problem", 1172 draft-gashinsky-v6ops-v6nd-problems-00 (work in progress), 1173 October 2011. 1175 [I-D.ietf-savi-threat-scope] 1176 McPherson, D., Baker, F., and J. Halpern, "SAVI Threat 1177 Scope", draft-ietf-savi-threat-scope-05 (work in 1178 progress), April 2011. 1180 [I-D.lopez-v6ops-dc-ipv6] 1181 Chen, Z., Lopez, D., Tsou, T., and C. Zhou, "A Reference 1182 Framework for DC Migration to IPv6", 1183 draft-lopez-v6ops-dc-ipv6-02 (work in progress), 1184 June 2012. 1186 [I-D.templin-v6ops-isops] 1187 Templin, F., "Operational Guidance for IPv6 Deployment in 1188 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-17 1189 (work in progress), May 2012. 1191 Authors' Addresses 1193 Kiran K. Chittimaneni 1194 Google Inc. 1195 1600 Amphitheater Pkwy 1196 Mountain View, California CA 94043 1197 USA 1199 Email: kk@google.com 1200 Tim Chown 1201 University of Southampton 1202 Highfield 1203 Southampton, Hampshire SO17 1BJ 1204 United Kingdom 1206 Email: tjc@ecs.soton.ac.uk 1208 Lee Howard 1209 Time Warner Cable 1210 13820 Sunrise Valley Drive 1211 Herndon, VA 20171 1212 US 1214 Phone: +1 703 345 3513 1215 Email: lee.howard@twcable.com 1217 Victor Kuarsingh 1218 Rogers Communications 1219 8200 Dixie Road 1220 Brampton, Ontario 1221 Canada 1223 Email: victor.kuarsingh@rci.rogers.com 1225 Yanick Pouffary 1226 Hewlett Packard 1227 950 Route Des Colles 1228 Sophia-Antipolis 06901 1229 France 1231 Email: Yanick.Pouffary@hp.com 1233 Eric Vyncke 1234 Cisco Systems 1235 De Kleetlaan 6a 1236 Diegem 1831 1237 Belgium 1239 Phone: +32 2 778 4677 1240 Email: evyncke@cisco.com