The transition to IPv6 is well underway. Most service providers have enabled IPv6 and run dual-stack networks offering their services in IPv4 and IPv6. There have been many talks about IPv6 in backbone networks, in residential networks and at peering points.

Enterprises have traditionally been reluctant to embrace IPv6 — there has been no actual need to implement it, with many seeing it as an additional cost and risk with no direct use for their daily business. However, this is starting to change.

Many enterprises are beginning to implement IPv6, often starting with enabling IPv6 on their email and web servers. This, at least, makes it possible to communicate with the outside world via both protocols. Some are also enabling IPv6 in their internal networks, including corporate WANs and data centres. In these instances, enterprises are using dual-stack designs. But what about the client networks comprising of mostly Windows PCs??

In this post, I’ll outline how enterprises can deploy IPv6 on client networks, including how they can continue to run IPv4.

Today’s enterprise networks

Enterprise networks today tend to be fairly unstructured. It is not uncommon to use 512 or even 1,024 IPv4 addresses in one network. As Layer 2 networks are failure and trust domains, all these clients in one large network share the same fate if something goes wrong. And things go wrong, as we all know.

In these networks, we often find mixed environments. Printers and PCs and other devices are all run on the same network without proper separation. A virus on one PC can take down the whole network segment. And even if all PCs are patched to the most recent level, most of the printers are not. But printers are allowed to access the Internet, aren’t they?

It gets even worse when you throw mobile laptops and bring-your-own devices into the mix. These machines connect to unsecured networks in hotels, airports and restaurants and get in contact with malware easily.

The network devices that are used to run office networks are Layer 2 rack switches. They connect to a pair of central routers with two uplinks using Spanning Tree Protocol (STP) to avoid loops in the network. The central routers run a first hop routing protocol (FHRP) like the virtual router redundancy protocol (VRRP). The floating IP is then given out to the clients as a default gateway address using DHCP.

Enabling IPv6 in these networks would make it even worse, because adding a protocol to an insecure environment makes it even more insecure. Therefore, this is not an option. Further, DHCPv6 works differently from DHCPv4, this makes a one-to-one replacement impossible.

Designing a new IPv6-only corp network

If running large Layer 2 networks in dual stack is not feasible, a completely new network design is needed. This network design should: address the Layer 2 fate sharing; get rid of spanning tree, if possible; and be a large step in the direction of IPv6-only networks.

In IPv6 there are enough addresses and networks to reserve a /64 network per device — as recommended in RFC 8273. Even the largest organisations should have enough address space to go down this road.

How does this work in real network design? Let’s take a Layer 3 rack switch that is capable of running an IPv6 routing protocol like OSPFv3. Assign one, and only one, virtual local area network (VLAN) to each of the physical ports of the switch, configure it as an ‘Access Port’, and configure a VLAN interface for each of these VLANs. The VLAN interface gets an IPv6 address from one /64 network. On a 48-port switch, we would use 48 VLANs, 48 VLAN interfaces, and 48 /64 networks, one per port.

The reason for using an Access Port on the switch is to make sure the Voice VLAN that you sometimes need in office environments still works. This is illustrated in Figure 1 below.

Figure 1: Network design showing access port on the switch to enable voice VLAN

The VLAN interface, configured with an IPv6 address, sends out router advertisements (RA) with the prefix information just on the one physical port, which is associated with the VLAN. One PC connects to the port and this PC, and only this PC, receives the RA.

The Layer 2 failure and trust domain is just one port in size. This eliminates all of the neighbour discovery insecurities like Rouge RA, Duplicate Address Detection attacks, and spoofed neighbour discovery messages. Even the ICMP redirect is not needed.

The PC builds an address from the prefix using Stateless Address Autoconfiguration (SLAAC ) and privacy extensions. Because we know the network used by the PC, the actual address does not matter for monitoring or troubleshooting and can change on a daily basis.

Figure 2: Router advertisement per port, access list between ports

In the RA the flag for ‘other configuration’ (the O flag) is set. This means, the PC should ask a DHCPv6 server for additional information, but not for an IPv6 address. This stateless DHCPv6 hands out information about DNS servers, NTP servers, and other relevant parameters used in the network. In this network design, stateful DHCPv6 is not needed anymore and can be turned off. This means there is no need for a centralised DHCPv6 infrastructure because stateless DHCPv6 can be done on every switch.

The Layer 3 rack switch runs OPPFv3 to connect to the routers, so no FHRP is needed anymore on the two central routers the rack switch connects to. The spanning tree design, not loved by many, is replaced with a routing infrastructure. Aggregating the many /64 networks to a larger network is an easy task and reduces the size of the routing table in the enterprise core.

Because we use a /64 per PC and have VLAN interfaces, we can configure access Lists on the VLAN interfaces if needed to get some extra security.

The PC, now online with IPv6 only, should then register itself with the Active Directory Server in its domain.

But how do I contact IPv4 hosts?

Have you ever used a VPN in a hotel room or an airport lounge? This usually tunnels IPv4 over IPv4. Running a VPN service inside your IPv6-only corporate network offers a means to route IPv4 prefixes too, assuming it is running on a machine that can egress both IPv4 and IPv6.

The clients connect to the VPN server using IPv6 as the transport protocol. IPv4 runs as a guest inside the tunnel. The VPN gateway hands out an IPv4 address, either a static address or an address from a pool of addresses, and DNS and other required information. The client registers the IPv4 address of the VPN interface in the corporate DNS and can use it without any restrictions.

To make it easier, the VPN should connect without asking for any login credentials. The user has already authenticated themselves to the PC or domain by using a username and password or any other means of identification.

IPv4 then runs as a service on top of IPv6 using the VPN. If, in the future, IPv4 is not needed anymore in the corp network, the administrators just de-configure the VPN tunnel and the transition to IPv6-only in this enterprise network is done.

The Microsoft factor

The position of Microsoft on IPv6-only is unclear.

They advise every network designer not to switch off IPv6 and run the network in dual-stack. Even if IPv4 is still active on the ethernet interface, it is not configured in the network design proposed here. No static IPv4 address, no DHCPv4. This should be a normal network design and not interpreted as an error by any operating system.

Hopefully, Microsoft makes their intentions on IPv6-only design known soon.

IPv6-only is achievable for enterprises

Using an IPv6 network per-client eliminates many known network problems. IPv6 First Hop Security is easy in this design. Using OSPFv3 on the rack switch increases the complexity, but it replaces the spanning tree and the FHRP protocols.

Further, designing from scratch means you're free to design a new address plan with the space you have, unencumbered by IPv4 restrictions.

Running IPv4 as a service makes it possible to migrate to IPv6-only on the ethernet. There is just one migration project, instead of implementing dual-stack first and then IPv6-only.

Benedikt Stockebrand and I gave a talk about this topic during the IPv6 working group at the RIPE 75 meeting. Everyone is invited to watch the video and download the slides.