IPv6 in Enterprise Client Networks

By on 8 Jan 2018

Category: Tech matters

Tags: , , ,

Blog home

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 consisting of mostly Windows PCs?

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

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 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) and a 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 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 RFC8273. Even the largest organizations 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, 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: RA 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 IP 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 it can be turned off. This means there is no need for a centralized 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 corp 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 core network, the administrators just deconfigure 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 RIPE 75 meeting in the IPv6 working group. Everyone is invited to watch the video and download the slides.

Original post appeared on RIPE Labs

Wilhelm Boeddinghaus is a network consultant working with large customers on IPv6 deployments.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please answer the math question * Time limit is exhausted. Please reload CAPTCHA.

Top