RFC 7381

Enterprise IPv6 Deployment Guidelines

📅 published October 2014, from ietf

RFC 7381: Enterprise IPv6 Deployment Guidelines 🎀

okay bestie, let's start with the title block 💖 This is RFC 7381, titled "Enterprise IPv6 Deployment Guidelines", from the Internet Engineering Task Force (IETF). It's Informational (so not a Standards Track spec 🌸), it's published under ISSN 2070-1721, and it's dated October 2014. The author squad is K. Chittimaneni (Dropbox, Inc.), T. Chown (University of Southampton), L. Howard (Time Warner Cable), V. Kuarsingh (Dyn, Inc.), Y. Pouffary (Hewlett Packard), and E. Vyncke (Cisco Systems) 👑 It doesn't obsolete or update any other RFCs, since none are listed in its title block.

Abstract ✨

okay so enterprise network admins all over the world are at different points on the IPv6 journey 🦋 Some are just getting ready, some are already rolling it out, and everyone's got their own vibe. Their situation isn't the same as the folks running Internet access providers, so they've got different priorities, and that's totally valid 💅 For most admins, the big task is offering Internet-facing services over IPv6 while still supporting IPv4, and bringing IPv6 access into the enterprise IT network itself. The whole transition takes most networks from IPv4-only, to dual-stack, and eventually to an IPv6-only operating mode 🌈 This doc gives enterprise network architects and admins a framework for handling all of these challenges as they figure out their IPv6 support strategy 🫶

Status of This Memo 🌸

this one's not an Internet Standards Track spec, it's just published for info 💜

it's a product of the IETF, so it reflects what the IETF community agrees on. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is up for any level of Internet Standard though, so check out Section 2 of RFC 5741 if you want the details 🧚

if you want the latest status, errata, or a way to give feedback, head to http://www.rfc-editor.org/info/rfc7381 🍓

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, the same way the Simplified BSD License describes ⭐

Table of Contents 🦋

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Enterprise Assumptions  . . . . . . . . . . . . . . . . .   5
     1.2.  IPv4-Only Considerations  . . . . . . . . . . . . . . . .   5
     1.3.  Reasons for a Phased Approach . . . . . . . . . . . . . .   6
   2.  Preparation and Assessment Phase  . . . . . . . . . . . . . .   7
     2.1.  Program Planning  . . . . . . . . . . . . . . . . . . . .   7
     2.2.  Inventory Phase . . . . . . . . . . . . . . . . . . . . .   8
       2.2.1.  Network Infrastructure Readiness Assessment . . . . .   8
       2.2.2.  Application Readiness Assessment  . . . . . . . . . .   9
       2.2.3.  Importance of Readiness Validation and Testing  . . .   9
     2.3.  Training  . . . . . . . . . . . . . . . . . . . . . . . .  10
     2.4.  Security Policy . . . . . . . . . . . . . . . . . . . . .  10
       2.4.1.  IPv6 Is No More Secure Than IPv4  . . . . . . . . . .  10
       2.4.2.  Similarities between IPv6 and IPv4 Security . . . . .  11
       2.4.3.  Specific Security Issues for IPv6 . . . . . . . . . .  11
     2.5.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .  13
     2.6.  Address Plan  . . . . . . . . . . . . . . . . . . . . . .  14
     2.7.  Tools Assessment  . . . . . . . . . . . . . . . . . . . .  16
   3.  External Phase  . . . . . . . . . . . . . . . . . . . . . . .  17
     3.1.  Connectivity  . . . . . . . . . . . . . . . . . . . . . .  18
     3.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  19
     3.3.  Monitoring  . . . . . . . . . . . . . . . . . . . . . . .  20
     3.4.  Servers and Applications  . . . . . . . . . . . . . . . .  20
     3.5.  Network Prefix Translation for IPv6 . . . . . . . . . . .  21
   4.  Internal Phase  . . . . . . . . . . . . . . . . . . . . . . .  21
     4.1.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  22
     4.2.  Network Infrastructure  . . . . . . . . . . . . . . . . .  22
     4.3.  End-User Devices  . . . . . . . . . . . . . . . . . . . .  23
     4.4.  Corporate Systems . . . . . . . . . . . . . . . . . . . .  24
   5.  IPv6 Only . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   6.  Considerations for Specific Enterprises . . . . . . . . . . .  26
     6.1.  Content Delivery Networks . . . . . . . . . . . . . . . .  26
     6.2.  Data Center Virtualization  . . . . . . . . . . . . . . .  26
     6.3.  University Campus Networks  . . . . . . . . . . . . . . .  26
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  28
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  34
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1. Introduction 🧚

okay so an enterprise network is defined in [RFC4057] as one with multiple internal links, one or more router connections to one or more providers, and active management from a network operations entity (the "administrator", which could be one person or a whole department of admins) 💅 Admins usually look after an internal network made up of users' workstations, personal computers, mobile devices, other computing gear and peripherals 🌸 They also look after a server network with accounting and business application servers, plus an external network of Internet-reachable services like web servers, email servers, VPN systems, and customer apps. This doc is basically a guide for enterprise architects and admins planning their IPv6 rollouts ✨

the reasons to spend time, effort, and money on IPv6 are unique to every enterprise 🦋 The biggest driver is that once Internet service providers (mobile carriers included) run out of IPv4 addresses, they'll offer native IPv6 and non-native IPv4. That non-native IPv4 might come through NAT64, NAT444, Dual-Stack Lite (DS-Lite), Mapping of Address and Port using Translation (MAP-T), Mapping of Address and Port using Encapsulation (MAP-E), or some other transition tech 🫶 Native traffic usually performs better and more reliably than tunneled or translated traffic. For example, if you're a client network trying to reach an enterprise, the IPv6 experience will be better than the transitional IPv4 one if the enterprise deploys IPv6 on its public-facing services 💖 Native IPv6 paths are also simpler to manage and, when needed, easier to troubleshoot 🔥 And enterprises doing business in fast-growing parts of the world may find IPv6 growing even faster there, where new customers, employees, and partners are already on IPv6 👑 So it's really in the enterprise's interest to deploy native IPv6, at the very least on its public-facing services, and ultimately across most or all of its scope 🌈

the text in this doc gives specific guidance for enterprise networks and works alongside other IETF efforts, including [IPv6-DESIGN] and [RFC5375] ⭐

1.1. Enterprise Assumptions 🌸

for the purpose of this doc, we're assuming the following 💜

  • The administrator is considering deploying IPv6 (but see Section 1.2 below).
  • The administrator has existing IPv4 networks and devices that will continue to operate and be supported.
  • The administrator will want to minimize the level of disruption to the users and services by minimizing the number of technologies and functions that are needed to mediate any given application. In other words, provide native IP wherever possible.

so based on these assumptions, an admin will want technologies that keep the number of flows being tunneled, translated, or intercepted at any given moment as low as possible 🧚 The admin should pick transition technologies or strategies that keep most traffic native and can still manage the non-native stuff 🍓 That way, the cost of IPv6 transition stays under control, since the number and scale of transition systems stays small 💅

tunnels used for IPv6/IPv4 transition are expected to be near-term or mid-term mechanisms, while IPv6 tunneling will get used for lots of long-term operational stuff like security, routing control, mobility, multihoming, traffic engineering, and so on ✨ We call the first kind of tunnel "transition tunnels" 🦋

1.2. IPv4-Only Considerations 🎀

even if admins aren't considering IPv6 yet, [RFC6302] says there are certain steps they really should take 🫶 Specifically, Internet-facing servers should log the source port number, a timestamp (from a reliable source), and the transport protocol. this is what lets you investigate malefactors hiding behind address-sharing technologies like NAT444, MAP, or DS Lite 🔍 Those logs should be protected for integrity, safeguarded for privacy, and purged on a regular schedule within whatever log retention rules apply 🔒

other IPv6 stuff can still affect networks that look IPv4-only, though 👀 [RFC6104] describes the rogue IPv6 Router Advertisement (RA) problem, which can cause trouble on IPv4-only networks where IPv6 is switched on in end systems 🙈 If you want to dig deeper into the security side of IPv6 in IPv4-only networks, [RFC7123] has you covered 💀

1.3. Reasons for a Phased Approach 🦋

okay so bestie, when you're moving user workstations, corporate systems, and Internet-facing servers to IPv6, you can't just flip everything at once 😭. So a phased approach lets you roll out IPv6 bit by bit, based on your own priorities 💅. This doc suggests three phases: a Preparation and Assessment Phase, an Internal Phase, and an External Phase. The Preparation Phase is highly recommended for everyone, because it saves you from errors and extra complexity later 🫶. Then you have to decide whether to start with the External Phase (enabling IPv6 for Internet-facing systems, as recommended in [RFC5211]) or the Internal Phase (enabling IPv6 for internal interconnections first) ✨.

Every scenario is a little different, but here are some things to think about 🌸:

  • In many cases, customers outside the network will have IPv6 before the internal enterprise network 🌈. For these customers, IPv6 may well perform better, especially for certain applications, than translated or tunneled IPv4. So the administrator may want to prioritize the External Phase so those customers get the simplest and most robust connectivity to the enterprise, or at least to its external-facing elements 💖.
  • Employees who access internal systems by VPN may find that their ISPs provide translated IPv4, which doesn't support the required VPN protocols 🙈. In these cases, the administrator may want to prioritize the External Phase and any other remotely accessible internal systems. It's worth knowing that a bunch of emerging VPN solutions offer dual-stack connectivity, so a VPN service may help employees on IPv4-only access networks reach IPv6 resources in the enterprise network. It's kind of like the public tunnel broker services, but just for the enterprise 🧚. Some security considerations are described in [RFC7359] 🔐.
  • Internet-facing servers can't be managed over IPv6 unless the management systems are IPv6 capable 💀. These might be Network Management Systems (NMS), monitoring systems, or just remote management desktops. So in some cases, the Internet-facing systems depend on IPv6-capable internal networks. However, dual-stack Internet-facing systems can still be managed over IPv4 🫶.
  • Virtual Machines (VMs) may enable a faster rollout once the initial system deployment is complete 🚀. Managing VMs over IPv6 still depends on the management software supporting IPv6 ✨.
  • IPv6 is enabled by default on all modern operating systems, so it may be more urgent to manage and have visibility on internal traffic 👀. It's important to manage IPv6 for security purposes, even on an ostensibly IPv4-only network, as described in [RFC7123] 🛡️.
  • In many cases, corporate accounting, payroll, human resource, and other internal systems only need to be reachable from the internal network, so they may be a lower priority 📋. As enterprises require their vendors to support IPv6, more internal applications will support IPv6 by default, and it can be expected that eventually new applications will only support IPv6 😳. The inventory, as described in Section 2.2, will help determine the systems' readiness, as well as the readiness of the supporting network elements and security. That readiness is a consideration when prioritizing these corporate systems 💅.
  • Some large organizations are running into IPv4 address exhaustion, even when they use private IPv4 addresses [RFC1918] 😤. This happens because the internal network grows (for example, with a vast number of VMs), or because they acquire other companies, which often brings overlapping private IPv4 address issues 🍓.
  • IPv6 restores end-to-end transparency even for internal applications (of course, security policies must still be enforced) 🦋. When two organizations or networks merge [RFC6879], the unique addressing of IPv6 can make the merger much easier and faster 💜. A merger may, therefore, prioritize IPv6 for the affected systems 👑.

These considerations conflict with each other, so each administrator has to prioritize based on their company's conditions 🎀. It's also worth noting that the reasons given in "A Large Corporate User's View of IPng", described in [RFC1687], for being reluctant to deploy have mostly been satisfied or overcome in the years since ✨.

2. Preparation and Assessment Phase 🌷

2.1. Program Planning 📅

Enabling IPv6 is a change to the most fundamental Internet Protocol, and there are so many interdependencies 😵‍💫. So having a professional project manager organize the work is highly recommended. An executive sponsor should also be involved in setting the goals of enabling IPv6 (which will establish the order of the phases), and they should get regular updates 📣.

It may be necessary to complete the Preparation Phase before deciding whether to prioritize the Internal or External Phase, since needs and readiness assessments are part of that phase 🔍. For a large enterprise, it may take several iterations to really understand the level of effort required. Depending on the required schedule, it may be useful to roll IPv6 projects into other architectural upgrades. This can be an excellent way to improve the network and reduce costs 🤑. However, when you increase the scope of projects, the schedule is often affected. For instance, a major systems upgrade may take a year to complete, while just patching existing systems may take only a few months ⏳.

Deploying IPv6 won't generally stop all other technology work 🙌. Once IPv6 has been identified as an important initiative, all projects, both new and in progress, will need to be reviewed to make sure they support IPv6 ✅.

It's normal for assessments to keep going in some areas while execution of the project begins in others. That's fine, as long as the recommendations in other parts of this document are considered, especially the ones about security. For instance, one should not deploy IPv6 on a system before security has been evaluated 🔐.

2.2. Inventory Phase 📦

To get a handle on the scope of the Inventory Phase, we recommend splitting the problem space in two: network infrastructure readiness and applications readiness 🧩.

2.2.1. Network Infrastructure Readiness Assessment 🏗️

The goal of this assessment is to identify the level of IPv6 readiness of network equipment 🔎. This will show the effort required to move to an infrastructure that supports IPv6 with the same functional service capabilities as the existing IPv4 network. It may also require a feature comparison and gap analysis between IPv4 and IPv6 functionality on the network equipment and software 📊. IPv6 support will require testing, because features often work differently in vendors' labs than in production networks 🧪. Some devices and software will require IPv4 support for IPv6 to work 😬.

The inventory will show which network devices are already capable, which devices can be made IPv6 ready with a code or firmware upgrade, and which devices will need to be replaced 🗂️. The data collection consists of a network discovery to understand the topology, and an inventory of network infrastructure equipment and code versions. That information is gathered from static files and IP address management, DNS, and DHCP tools 🗺️.

IPv6 might already be present in your environment through default configurations or VPNs, so an infrastructure assessment (at minimum) is essential to evaluate potential security risks 🚨.

2.2.2. Application Readiness Assessment 💻

Just like network equipment, application software needs to support IPv6 🧠. That includes OS, firmware, middleware, and applications (including internally developed ones). Vendors will typically handle IPv6 enablement for off-the-shelf products, but enterprises often need to request this support from them. For internally developed applications, it's the enterprise's responsibility to enable them for IPv6 🛠️. Analyzing how a given application communicates over the network will dictate the steps required to support IPv6 🕵️‍♀️. Applications should avoid instructions specific to a given IP address family. Any applications that use APIs, such as the C language, that expose the IP version specifically need to be modified to also work with IPv6 💅.

There are two ways to IPv6-enable applications 🎀. The first approach is to have separate logic for IPv4 and IPv6, which leaves the IPv4 code path mainly untouched. This causes the least disruption to the existing IPv4 logic flow, but adds complexity, since the application now has to deal with two logic loops, with complex race conditions and error recovery mechanisms between them 😵. The second approach is to create combined IPv4/IPv6 logic, which ensures operation regardless of the IP version used on the network 🌈. Knowing whether a given implementation will use IPv4 or IPv6 in a given deployment is a matter of some art. See Source Address Selection [RFC6724] and Happy Eyeballs [RFC6555] 🎨. It is generally recommended that the application developer use industry IPv6-porting tools to locate the code that needs updating 🔧. Some discussion of IPv6 application porting issues can be found in [RFC4038] 📚.

2.2.3. Importance of Readiness Validation and Testing 🧪

Last but not least, IPv6 introduces a completely new way of addressing endpoints, which can have ramifications at the network layer, all the way up to the applications 🌊. So to minimize disruption during the transition phase, we recommend complete functionality, scalability, and security testing to understand how IPv6 impacts the services and networking infrastructure 💖.

2.3. Training 🎓

Many organizations falter in IPv6 deployment because of a perceived training gap 😅. Training matters for anyone who works with addresses regularly, and for anyone whose work is changing 🧑‍🏫. Knowing better why IPv6 is being deployed will help inform the assessment of who needs training, and what training they need 💡.

2.4. Security Policy 🔐

It's obvious that IPv6 networks should be deployed in a secure way 🫡. The industry has learned a lot about network security with IPv4, so network operators should leverage that knowledge and expertise when deploying IPv6 🧠. IPv6 isn't so different from IPv4: it's a connectionless network protocol that uses the same lower-layer service and delivers the same service to the upper layer ✨. Therefore, the security issues and mitigation techniques are mostly identical, with the same exceptions described further on 💜.

2.4.1. IPv6 Is No More Secure Than IPv4 🦋

Okay bestie, so some people think IPv6 is inherently more secure than IPv4 just because it's new ✨ nope. Nothing could be more wrong 💀. Being a new protocol means bugs in the implementations haven't been discovered and fixed yet, and few people have the operational security expertise needed to run an IPv6 network securely. That lack of operational expertise is the biggest threat when deploying IPv6, so I'm saying it again: training matters 🎀.

One security myth is that, thanks to its huge address space, a network can't be scanned by enumerating all IPv6 addresses in a /64 LAN, so a malevolent person can't find a victim 🙈. [RFC5157] describes some alternate techniques for finding potential targets on a network, like enumerating all DNS names in a zone. More advice in this area is given in [HOST-SCANNING].

Another myth is that IPv6 is more secure because it mandates the use of IPsec everywhere. The original IPv6 specifications may have implied this, but [RFC6434] clearly states that IPsec support is not mandatory. Also, if all the intra-enterprise traffic is encrypted, both malefactors and security tools that rely on payload inspection (Intrusion Prevention System (IPS), firewall, Access Control List (ACL), IP Flow Information Export (IPFIX) ([RFC7011] and [RFC7012]), etc.) will be affected 😭. So IPsec is as useful in IPv6 as in IPv4 (for example, to establish a VPN overlay over a non-trusted network or to reserve for some specific applications) 🔐.

The last security myth is that amplification attacks (such as [SMURF]) don't exist in IPv6 because there is no more broadcast. Alas, this is not true, since ICMP error (in some cases) or information messages can be generated by routers and hosts when forwarding or receiving a multicast message (see Section 2.4 of [RFC4443]). Therefore, the generation and the forwarding rate of ICMPv6 messages must be limited, just like in IPv4 💅.

It should be noted that in a dual-stack network, the security implementation for both IPv4 and IPv6 needs to be considered 👑. You also have to think about security issues related to the interaction of (and transition between) the two while they coexist 🌈.

2.4.2. Similarities between IPv6 and IPv4 Security

As mentioned earlier, IPv6 is quite similar to IPv4, so several attacks apply to both protocol families, including:

  • Application layer attacks: such as cross-site scripting or SQL injection
  • Rogue device: such as a rogue Wi-Fi access point
  • Flooding and all traffic-based denial of services (including the use of control plane policing for IPv6 traffic: see [RFC6192])

A specific case of congruence is IPv6 Unique Local Addresses (ULAs) [RFC4193] and IPv4 private addressing [RFC1918]. Neither one gives you any security by 'magic' ✨. In both cases, the edge router must apply strict filters to block those private addresses from entering and, just as importantly, leaving the network. This filtering can be done by the enterprise or by the ISP, but the cautious administrator will prefer to do it in the enterprise 🧚.

IPv6 addresses can be spoofed as easily as IPv4 addresses, and there are packets with bogon IPv6 addresses (see [CYMRU]). Anti-bogon filtering must be done in the data and routing planes. It can be done by the enterprise or by the ISP, or both, but again, the cautious administrator will prefer to do it in the enterprise 🫶.

2.4.3. Specific Security Issues for IPv6

Even if IPv6 is similar to IPv4, there are some differences that create IPv6-only vulnerabilities or issues. We give examples of those differences in this section 🍓.

Privacy extension addresses [RFC4941] are usually used to protect individual privacy. They periodically change the interface identifier part of the IPv6 address, so a host can't be tracked by its otherwise always identical and unique 64-bit Extended Unique Identifier (EUI-64) based on Media Access Control (MAC) 🙈. While this is a real advantage on the Internet (moderated by the fact that the prefix part remains the same), it makes following an audit trail really tricky. When a security officer or network operator wants to trace a log entry back to a host in their network, the searched IPv6 address could have disappeared from the network by the time they check 😩. So the use of privacy extension addresses usually requires additional monitoring and logging of the binding of the IPv6 address to a data-link layer address (see also the monitoring section in [IPv6-SECURITY], Section 2.5). Some early enterprise deployments harvest IP/MAC address mappings from switch and router devices to provide address accountability. This approach has been shown to work, though it can involve gathering significantly more address data than in equivalent IPv4 networks 📊.

Another option is to try to prevent the use of privacy extension addresses by enforcing the use of DHCPv6, so hosts only get addresses assigned by a DHCPv6 server. This can be done by configuring routers to set the M bit in RAs, combined with all advertised prefixes being included without the A bit set (to prevent the use of stateless autoconfiguration). Of course, this technique requires that all hosts support stateful DHCPv6 🎀. It is important to note that not all operating systems exhibit the same behavior when processing RAs with the M bit set. The varying OS behavior is related to the lack of prescriptive definition around the A, M, and O bits within the Neighbor Discovery Protocol (NDP). [DHCPv6-SLAAC-PROBLEM] provides a much more detailed analysis of the interaction of the M bit and DHCPv6 🤓.

Extension headers complicate the task of stateless packet filters such as ACLs. If ACLs are used to enforce a security policy, then the enterprise must verify whether its ACLs (but also stateful firewalls) are able to process extension headers. That means they need to understand them well enough to parse them and find the upper-layer payloads, and to block unwanted extension headers (e.g., to implement [RFC5095]). This topic is discussed further in [RFC7045] 🔍.

Fragmentation is different in IPv6 because it is done only by the source host and never during a forwarding operation. This means that ICMPv6 packet-too-big messages must be allowed to pass through the network and not be filtered [RFC4890]. Fragments can also be used to evade some security mechanisms, such as RA-Guard [RFC6105]. See also [RFC5722] and [RFC7113] 🧩.

One of the biggest differences between IPv4 and IPv6 is the introduction of NDP [RFC4861], which includes a variety of important IPv6 protocol functions, including those provided in IPv4 by the Address Resolution Protocol (ARP) [RFC0826]. NDP runs over ICMPv6, which, as stated above, means that security policies must allow some ICMPv6 messages to pass, as described in RFC 4890. But NDP has the same lack of security as ARP, for example, in that there is no inherent message authentication 😬. Secure Neighbor Discovery (SEND) [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972] have been defined, but they are not widely implemented. The threat model for RAs within the NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue host could be either a rogue router or a rogue DHCP server 👀. An IPv4 network can be made more secure with the help of DHCPv4 snooping in edge switches, and likewise, RA snooping can improve IPv6 network security (in IPv4-only networks as well). So enterprises using such techniques for IPv4 should use the equivalent techniques for IPv6, including RA-Guard [RFC6105] and all work in progress from the Source Address Validation Improvement (SAVI) WG, e.g., [RFC6959]. That last one is similar to the protection given by dynamic ARP monitoring in IPv4 💖. Other DoS vulnerabilities are related to NDP cache exhaustion, and mitigation techniques can be found in [RFC6583] 🛡️.

As stated previously, running a dual-stack network doubles the attack exposure, because a malevolent person now has two attack vectors: IPv4 and IPv6 😈. This simply means that all routers and hosts operating in a dual-stack environment, with both protocol families enabled (even if by default), must have a congruent security policy for both protocol versions. For example, permitting TCP ports 80 and 443 to all web servers and denying all other ports to the same servers must be implemented for both IPv4 and IPv6. It is thus important that the tools available to administrators readily support this behavior 💅.

2.5. Routing

An important design choice is which IGP to use inside the network 🗺️. A variety of IGPs (IS-IS, OSPFv3, and Routing Information Protocol Next Generation (RIPng)) support IPv6 today, and picking one over the others is a design choice that will be dictated mostly by existing operational policies in an enterprise network. As mentioned earlier, it would be beneficial to maintain operational parity between IPv4 and IPv6, so it might make sense to continue using the same protocol family that is being used for IPv4 ✨. For example, in a network using OSPFv2 for IPv4, it might make sense to use OSPFv3 for IPv6. It is important to note that although OSPFv3 is similar to OSPFv2, they are not the same ⚠️.

On the other hand, some organizations may choose to run different routing protocols for different IP versions. For example, one may choose to run OSPFv2 for IPv4 and IS-IS for IPv6 🤷‍♀️. An important design question to consider here is whether to support one IGP or two different IGPs in the longer term. [IPv6-DESIGN] presents advice on the design choices that arise when considering IGPs, and discusses the advantages and disadvantages of the different approaches in detail 📚.

2.6. Address Plan ✨

okay bestie, the most common mess people run into with IPv6 is literally applying the same conservation habits they used in IPv4 💀. IPv6 addresses do not need to be assigned conservatively 🫶. Honestly, a single, bigger allocation is considered more conservative than a bunch of scattered small blocks, because one block only takes up ONE entry in a routing table 🦋. The advice in RFC 5375 is still sound and is recommended to the reader 💅, so go read it. If you're considering ULAs, give careful thought to how well they're supported, especially in multiple address and multicast scenarios, and figure out how strong the requirement for a ULA actually is. [ULA-USAGE] has way more detailed analysis and recommendations on using ULAs 🌸.

The enterprise admin will want to evaluate whether the enterprise will request address space from a Local Internet Registry (LIR), like an ISP; a Regional Internet Registry (RIR), like AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC; or a National Internet Registry (NIR) that's run in some countries 🌍. The usual setup is Provider-Aggregated (PA) address space from the enterprise's ISP, but PA space means renumbering when you switch providers 😭. Instead, an enterprise may request Provider-Independent (PI) space 🎀. This may involve an additional fee, but the enterprise may then be better able to be multihomed using that prefix, and it will avoid a renumbering process when changing ISPs. Just know that renumbering caused by outgrowing the space, a merger, or some other internal reason would still not be avoided with PI space (it should be noted, bestie 👑).

The type of address selected (PI vs. PA) should be congruent with the routing needs of the enterprise 🧚. The selection of address type will determine whether an operator will need to apply new routing techniques, and it may limit future flexibility. There is no right answer, but the needs of the External Phase may affect which address type gets picked ✨.

Each network location or site will need a prefix assignment 🍓. Depending on the type of site or location, various prefix sizes may be used. In general, historical guidance suggests that each site should get at least a /48, as documented in RFC 5375 and [RFC6177] 💜. On top of allowing for simple planning, this can allow a site to use its prefix for local connectivity, should the need arise, and if the local ISP supports it 🫶.

When assigning addresses to end systems, the enterprise may use manually configured addresses (common on servers), Stateless Address Autoconfiguration (SLAAC), or DHCPv6 for client systems 💻.

Early IPv6 enterprise deployments used SLAAC both for its simplicity and because DHCPv6 hadn't matured yet 🌱. However, DHCPv6 is now very mature, so workstations managed by an enterprise may use stateful DHCPv6 for addressing on corporate LAN segments 🔥. DHCPv6 allows for the extra configuration options enterprise admins often rely on, and with stateful DHCPv6, admins correlating system logs know which system had which address at any given time 🕵️‍♀️. That accountability model is familiar from IPv4 management, though DHCPv6 hosts are identified by a DHCP Unique Identifier (DUID) rather than a MAC address. For equivalent accountability with SLAAC (and potentially privacy addresses), a monitoring system that harvests IP/MAC mappings from switch and router equipment could be used 🦋.

A common deployment question for any enterprise network is how to get host DNS records updated 📡. Usually, either the host sends DNS updates or the DHCP server updates the records. If there is sufficient trust between the hosts and the DNS server, the hosts may update their own records (and the enterprise may use SLAAC for addressing) 🫶. Otherwise, the DHCPv6 server can be configured to update the DNS server. Note that an enterprise network with this more controlled environment will need to disable SLAAC on network segments and force end hosts to use DHCPv6 only 🚫.

In the data center or server room, assume a /64 per VLAN 🖥️. This applies even if each individual system is on a separate VLAN. In a /48 assignment, which is typical for a site, there are still 65,535 /64 blocks 🤯. Some administrators reserve a /64 but configure a small subnet, such as /112, /126, or /127, to stop rogue devices from attaching and grabbing numbers 🙈. An alternative is to monitor traffic for surprising addresses or Neighbor Discovery (ND) tables for new entries. Addresses are either configured manually on the server or reserved on a DHCPv6 server, which may also synchronize forward and reverse DNS (though see [RFC6866] for considerations on static addressing) 📋. SLAAC is not recommended for servers, because the RA timers need to line up with DNS Times to Live (TTLs) so that the DNS entry expires at the same time as the address ⏰.

All user access networks should be a /64 🌸. Point-to-point links where NDP is not used may also utilize a /127 (see [RFC6164]) 🧩.

Plan to aggregate at every layer of the network hierarchy 🏗️. There is no need for variable length subnet mask (VLSM) [RFC1817] in IPv6, and addressing plans based on conserving addresses are shortsighted 🙅‍♀️. Using prefixes longer than /64 on network segments will break common IPv6 functions such as SLAAC [RFC4862] 💀. Where multiple VLANs or other Layer 2 domains converge, allow some room for expansion. Renumbering because you outgrew the network plan is a nuisance, so allow room within it 🫠. Generally, plan to grow to about twice the current size that can be accommodated, and where rapid growth is planned, allow for twice that growth 📈. Also, if DNS (or reverse DNS) authority may be delegated to others in the enterprise, assignments need to be on nibble boundaries (that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48, /44). That way, delegated zones line up with assigned prefixes 🎯.

If using ULAs, it is important to note that AAAA and PTR records for ULAs are not recommended to be installed in the global DNS 🔒. Similarly, reverse (address-to-name) queries for ULA must not be sent to name servers outside of the organization, because of the load those queries would put on the authoritative name servers for the ip6.arpa zone 😱. For more details, please refer to Section 4.4 of [RFC4193] 📖.

Enterprise networks are increasingly including virtual networks, where a single physical node may host many virtualized addressable devices 🧚‍♀️. It is imperative that the addressing plans assigned to these virtual networks and devices be consistent and non-overlapping with the addresses assigned to real networks and nodes. For example, a virtual network set up in an isolated lab environment may later become attached to the production enterprise network 💥.

2.7. Tools Assessment 🛠️

Enterprises often have a bunch of operational tools and support systems that are used to provision, monitor, manage, and diagnose the network and systems in their environment 🧰. These tools and systems will need to be assessed for compatibility with IPv6 🔍. The compatibility may relate to the addressing and connectivity of various devices, as well as the IPv6 awareness of the tools and their processing logic.

The tools in an organization fall into two general categories: those that focus on managing the network, and those that focus on managing systems and applications on the network 📊. Either way, the tools will run on platforms that may or may not be capable of operating in an IPv6 network. This lack of functionality may relate to the operating system version or come down to some hardware constraint 🥲. Systems that are found to be incapable of using an IPv6 connection, or that depend on an IPv4 stack, may need to be replaced or upgraded 🔧.

On top of devices working on an IPv6 network natively or via a transition tunnel, many tools and support systems may require additional software updates to become IPv6 aware, or even a hardware upgrade (usually for extra memory, since IPv6 addresses are larger and, for a while, IPv4 and IPv6 addresses will coexist in the tool) 🧠. This awareness may include the ability to manage IPv6 elements and/or applications, as well as the ability to store and use IPv6 addresses 💾.

Things to consider when assessing tools and support systems include the fact that IPv6 addresses are significantly larger than IPv4 addresses, which means data stores need to support the bigger size 📏. Such issues are among those discussed in [RFC5952]. Many organizations may also run dual-stack networks, so the tools need to not only support IPv6 operation but may also need to support monitoring, management, and the intersection of both IPv6 and IPv4 at the same time 🌗. It is important to note that managing IPv6 is not just about dealing with large addresses. IPv6 interfaces and nodes are also likely to use two or more addresses as part of normal operation. Updating management systems to handle these extra nuances will likely take time and considerable effort 😮‍💨.

For networking systems, like node management systems, it is not always necessary to support local IPv6 addressing and connectivity 🤔. Operations such as SNMP MIB polling can happen over IPv4 transport while still seeking responses related to IPv6 information. Where this may seem advantageous to some, it should be noted that without local IPv6 connectivity, the management system may not be able to perform all expected functions, such as reachability and service checks 🚨.

Organizations should be aware that the IETF has made changes to older, IPv4-only SNMP MIB specifications, which relate to legacy operation in [RFC2096] and [RFC2011] 📜. Updated specifications are now available in [RFC4292] and [RFC4293], which modified the older MIB framework to be IP protocol agnostic, supporting both IPv4 and IPv6 ✨. Polling systems will need to be upgraded to support these updates, as well as the end stations that get polled 🫶.

3. External Phase 🌐

The External Phase of enterprise IPv6 adoption covers how an organization connects its infrastructure to the outside world 🦋. These external connections may go toward the Internet at large or toward other networks. The External Phase covers connectivity, security, and monitoring of various elements, along with outward-facing or accessible services 💖.

3.1. Connectivity

Okay so bestie, the enterprise has to team up with one or more service providers to get connected to the Internet or a transport service setup, like a BGP/MPLS IP VPN as described in [RFC4364] and [RFC4659] 🌐✨. A big thing that decides how an org talks to the outside world is whether they use PI and/or PA IPv6 space 💅.

Enterprises, heads up 🎀: depending on which address type they picked (PI vs. PA) during planning, they might need new routing functions and/or behaviors to connect to the ISP. With PI, the upstream ISP may offer to route the prefix (usually a /48) on their behalf and update the relevant routing databases 🗺️. Otherwise, the enterprise may have to do it themselves and use BGP to inject the prefix into the global BGP system 🦋.

The rules the RIRs set for an enterprise getting PI space have changed over time, lowkey wild 🙃. Like in Europe, the RIPE-NCC no longer requires an enterprise to be multihomed to be eligible for an IPv6 PI allocation. Requests can be made directly or via a LIR. The rules might change again and could vary between RIRs 🌈.

When you're looking for IPv6 connectivity from a service provider, native IPv6 is preferred since it's the most robust and efficient option 👑. If native IPv6 isn't possible due to technical or business limitations, the enterprise may use readily available transition tunnel IPv6 connectivity. There are IPv6 transit providers offering robust tunneled IPv6 connectivity that can run over IPv4 networks. Just know that you need to understand the transition-tunnel mechanism being used, and remember it'll have higher latency than native IPv4 or IPv6 and may have other problems, e.g., related to MTUs 💀.

Now, MTUs, bestie 🫶. When adding IPv6 to an existing IPv4 network, you have to evaluate MTU considerations. It's generally desirable to have the IPv6 and IPv4 MTU congruent to simplify operations (so the two address families behave similarly, that is, as expected) ✨. If the enterprise uses transition tunnels inside or externally for IPv6 connectivity, modifying the MTU on hosts/routers may be needed, since mid-stream fragmentation is no longer supported in IPv6 😭. Path MTU Discovery (pMTUD) is preferred for optimizing the MTU, so erroneous filtering of the related ICMPv6 message types should be monitored 🔍. Adjusting the MTU may be the only option if undesirable upstream ICMPv6 filtering can't be removed 🙈.

3.2. Security

The most important part of security for external IPv6 deployment is filtering and monitoring 🔥. Filtering can be done with stateless ACLs or a stateful firewall. Security policies must be consistent for IPv4 and IPv6 (or else the attacker will use the less-protected protocol stack) 🕵️, except that certain ICMPv6 messages must be allowed through and to the filtering device (see [RFC4890]):

  • Packet Too Big: essential to allow Path MTU discovery to work
  • Parameter Problem
  • Time Exceeded

Also, NDP messages (including Neighbor Solicitation, RAs, etc.) are required for local hosts 🧚.

It could also be safer to block all fragments where the transport layer header is not in the first fragment, to avoid the attacks described in [RFC5722] 🧱. Some filtering devices allow this filtering. Ingress filters and firewalls should follow [RFC5095] when handling routing extension header type 0, dropping the packet and sending ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case, ignore the header).

If an IPS is used for IPv4 traffic, then an IPS should also be used for IPv6 traffic. In general, make IPv6 security at least as good as IPv4. This also includes all email content protection (anti-spam, content filtering, data leakage prevention, etc.) 📧.

The edge router must also implement anti-spoofing techniques based on [RFC2827] (also known as BCP 38) 🛡️.

To protect the networking devices, it is advised to implement control plane policing as per [RFC6192] 💜.

The potential NDP cache exhaustion attack (see [RFC6583]) can be mitigated by two techniques 😤:

  • Good NDP implementation with memory utilization limits, as well as rate limiters and prioritization of requests.
  • Or, as the external deployment usually involves just a couple of exposed statically configured IPv6 addresses (virtual addresses of web, email, and DNS servers), it's straightforward to build an ingress ACL allowing traffic for those addresses and denying traffic to any other addresses. This actually prevents the attack, since a packet for a random destination will be dropped and will never trigger a neighbor resolution 🙌.

3.3. Monitoring

Monitoring the use of Internet connectivity should be done for IPv6 just like it's done for IPv4 📊. This includes using IPFIX [RFC7012] to report abnormal traffic patterns (such as port scanning, SYN flooding, and related IP source addresses) from monitoring tools, and evaluating data read from SNMP MIBs [RFC4293] (some of which also enable detection of abnormal bandwidth utilization) and syslogs (finding server and system errors). Where NetFlow is used, Version 9 is required for IPv6 support. Monitoring systems should be able to examine IPv6 traffic, use IPv6 for connectivity, and record IPv6 addresses, and any log parsing tools and reporting need to support IPv6 🔎.

Some of this data can be sensitive (including personally identifiable information), so care in securing it should be taken, with periodic purges 🔐. Integrity protection on logs and sources of log data is also important to detect unusual behavior (misconfigurations or attacks). Logs may be used in investigations, which depend on trustworthy data sources (tamper resistant) 🕵️‍♀️.

In addition, monitoring of external services (such as web sites) should be made address specific, so that people are notified when either the IPv4 or IPv6 version of a site fails 🚨.

3.4. Servers and Applications

The path to the servers accessed from the Internet usually involves security devices (firewall and IPS), server load balancing (SLB), and real physical servers. The latter stage is also multi-tiered for scalability and security between presentation and data storage. The ideal transition is to enable native dual stack on all devices, but as part of the phased approach, operators have used the following techniques with success 🍓:

  • Use a network device to apply NAT64 and basically translate an inbound TCP connection (or any other transport protocol) over IPv6 into a TCP connection over IPv4. This is the easiest to deploy since the path is mostly unchanged, but it hides all IPv6 remote users behind a single IPv4 address, which leads to several audit trail and security issues (see [RFC6302]) 😬.
  • Use the server load balancer, which acts as an application proxy to do this translation. Compared to NAT64, it has the potential benefit of going through the security devices as native IPv6 (so more audit and trace abilities), and it's also able to insert an HTTP X-Forward-For header that contains the remote IPv6 address. That latter feature allows for logging and rate limiting on the real servers based on the IPV6 address, even if those servers run only IPv4 🧁.

In either of these cases, care should be taken to secure logs for privacy reasons and to periodically purge them 🫧.

3.5. Network Prefix Translation for IPv6

Network Prefix Translation for IPv6, or NPTv6 as described in [RFC6296], provides a framework to utilize prefix ranges within the internal network that are separate (address independent) from the assigned prefix from the upstream provider or registry 🎭. As mentioned above, while NPTv6 has potential use cases in IPv6 networks, the implications of its deployment need to be fully understood, particularly where any applications might embed IPv6 addresses in their payloads 👀.

Use of NPTv6 can be chosen independently from how addresses are assigned and routed within the internal network, how prefixes are routed towards the Internet, or whether PA or PI addresses are used 🦄.

4. Internal Phase ✨

This phase deals with the delivery of IPv6 to the internal user-facing side of the Information Technology (IT) infrastructure, which comprises various components such as network devices (routers, switches, etc.), end-user devices and peripherals (workstations, printers, etc.), and internal corporate systems 🏢.

An important design paradigm to consider during this phase is "dual stack when you can, tunnel when you must" 💖. Dual stacking allows a more robust, production-quality IPv6 network than is typically facilitated by internal use of transition tunnels, which are harder to troubleshoot and support, and that may introduce scalability and performance issues. Of course, tunnels may still be used in production networks, but their use needs to be carefully considered, e.g., where the transition tunnel may be run through a security or filtering device. Tunnels do also provide a means to experiment with IPv6 and gain some operational experience with the protocol 🧪. [RFC4213] describes various transition mechanisms in more detail. [RFC6964] suggests operational guidance when using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) tunnels [RFC5214], though we would recommend use of dual stack wherever possible 🌸.

4.1. Security

IPv6 must be deployed in a secure way. This means that all existing IPv4 security policies must be extended to support IPv6, and IPv6 security policies will be the IPv6 equivalent of the existing IPv4 ones (taking into account the difference for ICMPv6 [RFC4890]). As in IPv4, security policies for IPv6 will be enforced by firewalls, ACLs, IPS, VPNs, and so on 🔒.

Privacy extension addresses [RFC4941] raise a challenge for an audit trail, as explained in Section 2.4.3 of this document. The enterprise may choose to attempt to enforce use of DHCPv6, or deploy monitoring tools that harvest accountability data from switches and routers (thus making the assumption that devices may use any addresses inside the network) 🙈.

One major issue is threats against ND. This means, for example, that the internal network at the access layer (where hosts connect to the network over wired or wireless) should implement RA-Guard [RFC6105] and the techniques being specified by the SAVI WG [RFC6959]; see also Section 2.4.3 of this document for more information 🛑💅.

4.2. Network Infrastructure 🏗️✨

okay so the typical enterprise network is a mix of wired access switches, wireless access points, and routers. It's pretty common for one box to do both switching and routing 🙈 Basic wired switches and access points only work at the physical and link layers, so they don't really need any special IPv6 treatment beyond being able to hold IPv6 addresses for management 💅 But lots of them are way smarter than just moving packets. Some help with link-layer security with features like ARP inspection and DHCP snooping, and some limit where multicast floods go by using IGMP snooping (or MLD snooping for IPv6) 🦋

First-hop router redundancy is a big deal in enterprise networks, bestie 👑 It directly affects whether an end host can reach anything. IPv6 ND [RFC4861] lets a node keep a list of the routers available on the link, so it can switch to a backup path if the primary goes down. By default, ND takes 38 seconds to notice a router failure, then it cycles onto the next default router in its cache 😭 That's a basic level of first-hop redundancy, but most enterprise IPv4 networks fail over way faster. You can speed it up by tweaking the default timers, but you have to be careful about transient failures and the extra traffic on the link 🧚

If you want something more robust, there's VRRPv3 for IPv6 [RFC5798] 💜 It switches over to an alternate default router much faster than default ND parameters do. With VRRPv3 default parameters, a backup router can take over for a failed default router in around three seconds. Best part is that it happens without any interaction with the hosts, and it uses a minimal amount of VRRP traffic. Main character energy ✨

Last but not least, one of the biggest design choices for IPv6 on the internal network is whether to use SLAAC [RFC4862], DHCPv6 [RFC3315], or a combination of the two 🌸 Each has pros and cons, and the answer depends on the operational policies guiding each enterprise's design. If the enterprise wants ease of use, rapid deployment, and less admin overhead, SLAAC makes more sense for workstations 💖 Servers still need manual or DHCPv6 assignments, as described in the Address Plan and External Phase sections of this document; see Sections 2.6 and 3, respectively. But if the operational policies call for precise control over IP address assignment for auditing, DHCPv6 may be the way to go 🔥 DHCPv6 also lets you tie into DNS systems for host entry updates, and it gives you a way to send other options and information to clients. Worth noting: in general operation, RAs are still needed in DHCPv6 networks, because there's no DHCPv6 Default Gateway option 🙈 And DHCPv6 is still needed in RA networks for other configuration info, like NTP servers or, if RAs don't support DNS resolvers [RFC6106], DNS resolver info 🫶

4.3. End-User Devices 💻🎀

Most operating systems (OSes) on workstations and laptops in a typical enterprise support IPv6 today. Still, there are out-of-the-box nuances you need to watch for 👀 The default behavior varies between OSes. Some have IPv6 turned off by default, some only have certain features like privacy extensions to IPv6 addresses (RFC 4941) turned off, and others have IPv6 fully enabled ✨ Even when IPv6 is on, the choice of which address gets used may be subject to source address selection (RFC 6724) and Happy Eyeballs (RFC 6555) 😭 So it's advised that enterprises look into the default behavior of their installed OS base and account for it during the Inventory Phases of their IPv6 prep 💅 Also, some OSes may have transition tunneling mechanisms turned on by default. In that case, it is recommended to administratively shut down those interfaces unless they're required 🌈

It's important to note that it is recommended to deploy IPv6 at the network and system infrastructure level before rolling it out to end-user devices 🧚 Make sure IPv6 is running and routed on the wire, and that it's secure and correctly monitored, before exposing IPv6 to end users 🔐

Smartphones and tablets are significant IPv6-capable platforms, depending on whether the carrier's data network supports it 📱

IPv6 support for peripherals varies 🖨️ Like servers, printers are generally configured with a static address (or a DHCP reservation) so clients can find them reliably 🦋

4.4. Corporate Systems 🏢💜

No IPv6 deployment will be successful unless every corporate system the enterprise uses as part of its IT infrastructure supports IPv6 😤 Examples include, but aren't limited to, email, video conferencing, telephony (VoIP), DNS, RADIUS, and so on. All of these systems must have their own detailed IPv6 rollout plan that runs alongside the network IPv6 rollout 🫶 DNS is one of the main anchors in an enterprise deployment, because most end hosts decide whether to use IPv6 based on whether there are IPv6 AAAA records in a reply to a DNS query 🔥 It is recommended that sysadmins selectively turn on AAAA records for systems as they become IPv6 enabled. Be careful, though: make sure every service running on that host name is IPv6 enabled before adding the AAAA record ⚠️ Care with web proxies is advised too, since a mismatch in IPv6 support between the client, proxy, and server can cause communication problems 🙈 And all monitoring and reporting tools across the enterprise will need to be modified to support IPv6 🌸

5. IPv6 Only 🌍✨

Early IPv6 enterprise deployments have generally taken a dual-stack approach, which means the existing IPv4 services weren't turned off 🦋 IPv4 and IPv6 networks will coexist for a long time, but the long-term enterprise roadmap should include steps to simplify engineering and operations by deprecating IPv4 from the dual-stack network 💅 In some extreme cases, a dual-stack network may not even be viable for very large enterprises, because the address space described in RFC 1918 isn't large enough to support the network's growth 😭 In those cases, IPv6-only networks might be the only choice that can sustain growth. In other cases, elements of an otherwise dual-stack network may run IPv6 only 👑

If nodes in the network don't need to talk to an IPv4-only node, deploying IPv6-only networks is pretty straightforward 💖 But most nodes will need to communicate with some IPv4-only nodes, so an IPv6-only node may need a translation mechanism. As [RFC6144] points out, it's important to look at address translation as a transition strategy toward running an IPv6-only network 🧚

There are various stateless and stateful IPv4/IPv6 translation methods available today that help with IPv6-to-IPv4 communication 🎀 RFC 6144 provides a framework for IPv4/IPv6 translation and describes in detail the various scenarios where these translation mechanisms could be used. [RFC6145] describes stateless address translation. In this mode, a specific IPv6 address range represents IPv4 systems (IPv4-converted addresses), and the IPv6 systems have addresses (IPv4-translatable addresses) that can be algorithmically mapped to a subset of the service provider's IPv4 addresses 🌈 NAT64 [RFC6146] describes stateful address translation. As the name suggests, the translation state is kept between IPv4 address/port pairs and IPv6 address/port pairs, which lets IPv6 systems open sessions with IPv4 systems 🔥 DNS64 [RFC6147] describes a mechanism for synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs 6146 and RFC 6147 give you a viable way for an IPv6-only client to start communications with an IPv4-only server 🫶 As described in Enterprise Assumptions, Section 1.1, the administrator will usually want most traffic or flows to stay native and only be translated as needed 💅

The address translation mechanisms for the stateless and stateful translations are defined in [RFC6052] ✨ Heads up: both of these mechanisms have limitations on which protocols they support 🙈 For example, RFC 6146 only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. The classic problems of IPv4 NAT also apply, like handling IP literals in application payloads 😭 Ultimately, the choice of translation mechanism will be dictated mostly by existing operational policies around application support, logging requirements, and so on 📋

There's additional work happening in address translation to enhance and optimize the current mechanisms 🧪 For example, [DIVI] describes limitations of the current stateless translation, like IPv4 address sharing and application layer gateway (ALG) problems. It presents the concept and implementation of dual-stateless IPv4/IPv6 translation (dIVI) to address those issues 💜

It's worth noting that for IPv6-only access networks using technologies like NAT64, the more content providers (and enterprises) that make their content available over IPv6, the less need there is to apply NAT64 to traffic leaving the access network 🌸 This matters for enterprises that might start their IPv6 deployment well into the global IPv6 transition. As time goes on, and given the current growth in IPv6 content, IPv6-only operation using NAT64 to manage some flows will get cheaper to run than traditional NAT44 deployments, since only IPv6-to-IPv4 flows need translation 🦋 [RFC6883] provides guidance and suggestions for Internet Content Providers and Application Service Providers in this context 📚

Enterprises should also be aware that their networks may converge with other networks in the future (through mergers, acquisitions, and so on) 🤝 An enterprise considering IPv6-only operation may need additional transition technologies and/or connectivity strategies, depending on the level of IPv6 readiness and deployment in the networks being merged 👑

6. Considerations for Specific Enterprises 🏪🎀

6.1. Content Delivery Networks 🌐💖

Some guidance for Internet Content and Application Service Providers can be found in [RFC6883], which includes a dedicated section on Content Delivery Networks (CDNs) 📖 An enterprise that relies on a CDN to deliver a 'better' e-commerce experience needs to make sure its CDN provider also supports IPv4/IPv6 traffic selection, so it can ensure 'best' access to the content 💅 A CDN could even enable external IPv6 content delivery when the enterprise provides that content over IPv4 🌈

6.2. Data Center Virtualization 🌸

okay bestie, if you're into the IPv6 data center side of things, it's all written up in [IPv6-DC] 🫶 go check it out!

6.3. University Campus Networks 🎓

okay so a bunch of campus networks around the world have already made some early IPv6 deployments ✨ and they were encouraged by their National Research and Education Network (NREN) backbones, which have been offering IPv6 natively since the early 2000's 🙈. unis are a natural place to start thinking about IPv6 early, maybe even more than other enterprises, because research and education is literally their whole thing 🧠💜

campus networks can roll out IPv6 at their own pace, no cap 🦋 you don't have to deploy it across the entire enterprise from day one. instead, pick specific projects that are deep enough to give the uni real experience but small enough to be a realistic first step 💅. there are generally three areas where these deployments are currently made.

the initial areas that get picked most often are:

  • External-facing services. Typically the campus web presence, and commonly also external-facing DNS and mail exchange (MX) services 🍓. this makes sure early IPv6-only adopters elsewhere can reach the campus services as simply and as robustly as possible 🌈
  • Computer science department. this is where IPv6-related research and/or teaching is most likely to happen, and where a lot of the next generation of network engineers are studying 🧚. so enabling some or all of the campus computer science department network is a sensible first step 👑
  • The eduroam wireless network. Eduroam [EDUROAM] is the de facto wireless roaming system for academic networks, and it uses authentication based on 802.1X, which doesn't care which IP version is used (unlike web-redirection gateway systems) 🔥. making a campus' eduroam network dual stack is a very viable early step ✨

the general IPv6 deployment model in a campus enterprise still follows the general principles described in this document 💖. the early stage projects above are commonly followed, but they still require the campus to acquire IPv6 connectivity and address space from their NREN (or another provider, in some parts of the world) and to enable IPv6 on the wire on at least part of the core of the campus network 🛜. this implies a requirement to have an initial address plan, and to make sure appropriate monitoring and security measures are in place, as described elsewhere in this document 🫶

campuses that have deployed so far don't use ULAs, and they don't use NPTv6 either 🙈. in general, campuses have very stable PA-based address allocations from their NRENs (or their equivalent) 🌷. however, campus enterprises may consider applying for IPv6 PI, and some have already done so 🦋. the discussions earlier in this text about PA vs. PI still apply, bestie 💅

finally, campuses may be more likely than many other enterprises to run multicast applications, like IP TV or live lecture or seminar streaming 📺. so they may wish to consider support for specific IPv6 multicast functionality, e.g., the Embedded Rendezvous Point (Embedded-RP) [RFC3956] in routers, and MLDv1 and MLDv2 snooping in switches 🎀

7. Security Considerations 🔐

okay this one is short but it's a big deal 😭 this document has multiple security sections detailing how to securely deploy an IPv6 network within an enterprise network. go read those, periodt 💀

8. Informative References 📚

Okay bestie, the reference list keeps going, and these are the RFCs the whole IPv6 deployment crew leans on. 🦋 Every entry is kept exactly as written, so you can look each one up. 💅

   [RFC6105]  Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
              Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
              February 2011, <http://www.rfc-editor.org/info/rfc6105>.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, November 2010,
              <http://www.rfc-editor.org/info/rfc6106>.

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", RFC 6144, April 2011,
              <http://www.rfc-editor.org/info/rfc6144>.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011,
              <http://www.rfc-editor.org/info/rfc6145>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011,
              <http://www.rfc-editor.org/info/rfc6146>.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011, <http://www.rfc-editor.org/info/rfc6147>.

   [RFC6164]  Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
              L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
              Router Links", RFC 6164, April 2011,
              <http://www.rfc-editor.org/info/rfc6164>.

   [RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 Address
              Assignment to End Sites", BCP 157, RFC 6177, March 2011,
              <http://www.rfc-editor.org/info/rfc6177>.

   [RFC6192]  Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
              Router Control Plane", RFC 6192, March 2011,
              <http://www.rfc-editor.org/info/rfc6192>.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, June 2011,
              <http://www.rfc-editor.org/info/rfc6296>.

   [RFC6302]  Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
              "Logging Recommendations for Internet-Facing Servers", BCP
              162, RFC 6302, June 2011,
              <http://www.rfc-editor.org/info/rfc6302>.

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", RFC 6434, December 2011,
              <http://www.rfc-editor.org/info/rfc6434>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012,
              <http://www.rfc-editor.org/info/rfc6555>.

   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems", RFC 6583, March 2012,
              <http://www.rfc-editor.org/info/rfc6583>.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012,
              <http://www.rfc-editor.org/info/rfc6724>.

   [RFC6866]  Carpenter, B. and S. Jiang, "Problem Statement for
              Renumbering IPv6 Hosts with Static Addresses in Enterprise
              Networks", RFC 6866, February 2013,
              <http://www.rfc-editor.org/info/rfc6866>.

   [RFC6879]  Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
              Network Renumbering Scenarios, Considerations, and
              Methods", RFC 6879, February 2013,
              <http://www.rfc-editor.org/info/rfc6879>.

   [RFC6883]  Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
              Content Providers and Application Service Providers", RFC
              6883, March 2013,
              <http://www.rfc-editor.org/info/rfc6883>.

   [RFC6959]  McPherson, D., Baker, F., and J. Halpern, "Source Address
              Validation Improvement (SAVI) Threat Scope", RFC 6959, May
              2013, <http://www.rfc-editor.org/info/rfc6959>.

   [RFC6964]  Templin, F., "Operational Guidance for IPv6 Deployment in
              IPv4 Sites Using the Intra-Site Automatic Tunnel
              Addressing Protocol (ISATAP)", RFC 6964, May 2013,
              <http://www.rfc-editor.org/rfc/rfc6964.txt>.

   [RFC7011]  Claise, B., Trammell, B., and P. Aitken, "Specification of
              the IP Flow Information Export (IPFIX) Protocol for the
              Exchange of Flow Information", STD 77, RFC 7011, September
              2013, <http://www.rfc-editor.org/info/rfc7011>.

   [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
              Information Export (IPFIX)", RFC 7012, September 2013,
              <http://www.rfc-editor.org/info/rfc7012>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045, December 2013,
              <http://www.rfc-editor.org/info/rfc7045>.

   [RFC7113]  Gont, F., "Implementation Advice for IPv6 Router
              Advertisement Guard (RA-Guard)", RFC 7113, February 2014,
              <http://www.rfc-editor.org/info/rfc7113>.

   [RFC7123]  Gont, F. and W. Liu, "Security Implications of IPv6 on
              IPv4 Networks", RFC 7123, February 2014,
              <http://www.rfc-editor.org/info/rfc7123>.

   [RFC7359]  Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel
              Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359,
              August 2014, <http://www.rfc-editor.org/info/rfc7359>.

   [SMURF]    The Cert Division of the Software Engineering Institute,
              "Smurf IP Denial-of-Service Attacks", CERT Advisory CA-
              1998-01, March 2000,
              <http://www.cert.org/advisories/CA-1998-01.html>.

   [ULA-USAGE]
              Liu, B. and S. Jiang, "Considerations of Using Unique
              Local Addresses", Work in Progress, draft-ietf-v6ops-ula-
              usage-recommendations-03, July 2014.

Acknowledgements

A huge shoutout to everyone who made this doc happen! 🫶 The authors want to thank Robert Sparks, Steve Hanna, Tom Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou, Christian Jacquenet, and Fred Templin for their substantial comments and contributions 💜 Literally iconic. 👑

Authors' Addresses

Here are the people who wrote it, with all their contact details 🎀

   Kiran K. Chittimaneni
   Dropbox, Inc.
   185 Berry Street, Suite 400
   San Francisco, CA  94107
   United States
   EMail: kk@dropbox.com

   Tim Chown
   University of Southampton
   Highfield
   Southampton, Hampshire  SO17 1BJ
   United Kingdom
   EMail: tjc@ecs.soton.ac.uk

   Lee Howard
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   United States
   Phone: +1 703 345 3513
   EMail: lee.howard@twcable.com

   Victor Kuarsingh
   Dyn, Inc.
   150 Dow Street
   Manchester, NH
   United States
   EMail: victor@jvknet.com

   Yanick Pouffary
   Hewlett Packard
   950 Route Des Colles
   Sophia-Antipolis  06901
   France
   EMail: Yanick.Pouffary@hp.com

   Eric Vyncke
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium
   Phone: +32 2 778 4677
   EMail: evyncke@cisco.com

And that's the whole doc, bestie!! 🌈✨🦋

📦 where this page comes from