One of the areas where IPv6 sorely lacks feature parity with IPv4 is user authentication and source IP spoofing prevention in large-scale Carrier Ethernet networks. Metro Ethernet switches from numerous vendors offer all the IPv4 features a service provider needs to build a secure and reliable access network where the users can’t intercept other users’ traffic or spoof source IP addresses, and where it’s always possible to identify the end customer from an IPv4 address – a mandatory requirement in many countries. Unfortunately, you won’t find most of these features in those few Metro Ethernet switches that support IPv6.

Here’s a brief IPv4-on-Metro-Ethernet refresher:

• IPv4 DHCP is used to address the individual end users (either hosts or CPE devices using NAT);
• Access-layer switches use DHCP snooping and insert source port name (Option 82) in DHCP requests sent by the clients.
• DHCP servers log IP addresses assigned to the customers together with Option 82 values, making it possible to map source IPv4 address to end-user port on the access-layer switch.
• Access layer switches inspect DHCP replies and use dynamic ARP inspection and IP source guard to prevent ARP poisoning attacks or IP source address spoofing.

Most of these features don’t work too well in IPv6 world. DHCPv6 snooping is not widely supported (the only switches I found supporting it are HP Data Center switches), ND inspection or IPv6 source guard are almost non-existent.

When trying to figure out what you could do in a Metro Ethernet network having numerous users in the same VLAN I came up with the following options (ignoring lack of DHCPv6 snooping and ND inspection):

Use DHCPv6 instead of SLAAC. Works best in PowerPoint. DHCPv6 has an option equivalent to Option 82 (Option 37 – Relay Agent Remote ID), but it’s hard to use due to the way DHCPv6 relaying works.

DHCPv6 requests sent by IPv6 hosts or CPE devices must be encapsulated in new DHCPv6 envelopes (with source IPv6 address of the relaying device) every time the request is relayed or new options are added to the original request. If you want to use DHCPv6 Option 37 to authenticate the users, you have to connect the end-users directly to layer-3 switches.

In theory, the problem is solved: RFC 6221 (Lightweight DHCPv6 Relay Agent) has introduced the mechanism that allows layer-2 bridges to modify and relay client DHCPv6 requests. In practice, it hasn’t been implemented yet.

Use provider-managed CPE devices that use DHCPv6 prefix delegation. This one might be the best solution, but requires very tight control of CPE devices – if a malicious user manages to bypass the CPE device and connect directly to the Metro Ethernet network, he can do whatever he wishes. You can also experience “subtle” problems if your PE/BRAS reloads.

Use PPPoE over Carrier Ethernet. You wouldn’t believe it, but some service providers are actually doing this (and this approach does solve the authentication problems, as you can use CHAP and RADIUS). The vendors of high-end BRAS boxes must be ecstatic – just imagine how much silicon you need to provider 100 Mbps per user for tens of thousands of PPPoE sessions.

Getting creative

When I sent the question to RIPE IPv6 Working Group mailing list, I got two more suggestions:

Use VLAN per customer. This one is the cleanest (but also least scalable) solution. You can assign a static prefix to each customer if you place each customer in a separate VLAN on the PE/BRAS router. Identifying the customer becomes exceedingly simple (it’s static), there are no ND/RA issues (customers don’t see each other) and a simple RPF check prevents all IP address spoofing.

This solution has two scalability problems: VLAN numbering (which can be bypassed with Q-in-Q or PBB) and the complexity of BRAS configuration. It also forces all peer-to-peer traffic to flow through BRAS.

Monitor ND messages to collect IPv6-to-MAC mappings and inspect MAC address tables on layer-2 switches to map IPv6 address to source ports. Not exactly a solution I would use in a large-scale production network.

Dig more tunnels

Last week I ran a customized IPv6 workshop for a large service provider and we figured out the least complex and at the same time most reliable solution uses ... tunneling (ouch). If you run IPv4-only access network and 6rd on the CPE devices, you can retain IPv4 access network authentication and security features, eliminate the need for DHCPv6-based prefix delegation, and avoid ND/RA attacks. The only risk you can’t eliminate on the 6rd border router is source IPv6 address spoofing unless your vendor supports tunnel source-based RPF check on 6rd tunnel.

Summary: It’s a sad moment when you realize you have to use tunneling to build somewhat secure Metro Ethernet IPv6 access network, but that seems to be the state of the industry half a year after IPocalypse.