Building network automation solutions

9 module online course

Start now!

IPv6 End User Authentication on Metro Ethernet

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.


  1. Please excuse me if I'm missing something, but what about using 802.1x to authenticate the CPE?
  2. Do you really think the IPv4 solution is the best one? Pretending to create customer isolation by a combination of DHCP snooping, ARP inspection and other layer-violating hacks? Make it look like a PPP connection. Wouldn't it be better to keep the separation at layer 2? And with IP all the way to the edge, there is no issue of scaling VLANs either.

    (Yeah, I know I'm ranting, but I do very much dislike the N:1 VLAN model... :-))
  3. Australia is heading down the vlan per customer route (double stacked vlans) with National Broadband Network's FTTP deployment.
  4. You can authenticate the CPE (or host) with 802.1x, but you cannot prevent it from using a spoofed IPv6 source address and you don't know which IPv6 address a host is using.

    Also, it's probably perfectly possible to match 802.1x data, CPE MAC address, and DUID in DHCPv6 IA_PD request to figure out which prefix a user got ... but definitely not trivial.
  5. As I wrote, it makes me sad. I would love to see a network with no VLANs, only L3 switches and perfectly static configuration ... but do tell me, how many Cisco's ME access switches supports IPv6 at wire speed? :-P
  6. ME3400, ME3600 and ME3800 is just around the corner.
  7. > you cannot prevent it ...

    I was (maybe wrongly) going by the assumption that if CPE is authenticated, then it is under SP's control and thus implicitly trusted.
  8. Interesting perspective. If you allow only SP-managed CPEs (and they have semi-decent security), then you have pretty secure network almost by definition. Is that still a viable business model? The same idea was busted in the phone networks decades ago.
  9. I am certainly talking from a fairly isolated experience, which is local ISPs with HFC networks only allow CPE that they have supplied, configured and controlling themselves. And while it's not the case with DSL, the upcoming FTTH network (NBN) follows the same model - CPE comes with and forms an integral part of the service.
  10. As weird as it may seem, I like the PPPoE solution. When I was working at Algar (1999/2002) we were probably the first company to adopt PPPoE for broadband here in Brazil. At the same time Telefonica tried using DHCP with the Cisco 6000, and it was a nightmare. We launched our ADSL service at the same time, and after a couple years everyone was using PPPoE. The main advantages are not strictly technical though, but that (1) it maps to the telco mindset (PPPoE sessions behave as circuits after all) and (2) it makes it easy to implement billing and other administrative controls. On the tech side, it also allows to keep switch configuration to a minimum, which makes maintenance much easier than if you need to actually configure port by port, user by user. The cost is that you need an expensive box to deal with all the sessions, but Moore law is in our favor. I believe that's still the best way to handle ISP traffic.

    As an aside, at the time (2000 I think) we designed a solution where we could use PPPoE to serve two customers in the same home with two separate services. For example, one PPPoE tunnel could be used to deliver video and the other one would be a plain Internet connection. However, we never launched this and I don't know of any provider who sets up this kind of solution though.
  11. how about just forgetting about dhcp altogether, and use a fixed ipv6 block per user that you can easily setup in the switch.
  12. You need DHCPv6 (more precisely: IA_PD option) to autoconfigure the CPE. You don't expect end-users to type in their own IPv6 prefixes, do you =-X
  13. Wouldn´t be stateful SAVI plus stateful DHCPv6 a solution?

    Btw, is SAVI a topic on Cisco/Juniper/Brocade/Foundry´s roadmap?
  14. This sounds like a perfect fit ... not heard anything about planned support so far.
Add comment