IPv6 Link-Local Addresses and VLAN Interfaces

One of my readers sent me an email that’s easiest paraphrased into: “Why can’t I have a different IPv6 link-local address (LLA) on every access port connected to a VLAN interface?”

There’s probably nothing stopping someone from implementing such an approach, but it would go against the usual understanding of how bridging and routing interact in L2+L3 switches.

What Is a VLAN Interface?

A VLAN interface is nothing more than a routed (L3) virtual interface connected to a bridge domain (VLAN). Regardless of how this construct is implemented in hardware or software, it should look like a router connected to a bridge, or (ignoring optimizations in frame forwarding) a router connected to an Ethernet cable.

What MAC Address Should a VLAN Interface Use?

Every L3 interface (including a VLAN interface) potentially participating in the same L2 domain should have a unique L2 (MAC) address, which means that a L2+L3 switch needs a unique MAC address for each of its physical interfaces (because each physical interface could be turned into a L3 interface). You can usually see those addresses (bia or burned-in-address) in show interfaces printout.

A bridge (remarketed as a L2 switch) does not need a unique MAC address on every interface. All it needs is a single MAC address to send BPDUs (and other control-plane messages) from.

A VLAN interface could (theoretically) reuse a MAC address of a physical interface (in case the physical interface has a separate burned-in-address), or use a MAC address from a pool of addresses assigned by the vendor to the switch itself… but in most cases, the implementation details don’t really matter, as the MAC addresses have to be unique within a single L2 domain.

Stretching L2 domains or merging multiple L2 domains into a single transport domain with Q-in-Q encapsulation can lead to interesting results as some people trying to use the same HSRP group on multiple stretched VLANs found out the hard way.

Coming Back to IPv6 LLA

An IPv6 interface is usually assigned a single IPv6 LLA. A VLAN interface thus gets a single IPv6 LLA.

Physical access ports connected to a VLAN instance are not L3 ports, and thus don’t get a L3 address. Quite often they don’t even need a L2 address (see above).

You could assign numerous LLA to a VLAN interface (one per physical port), but they’d have to be bound to VLAN interface (not physical ports) anyway to retain the semantics of VLAN interface, so why bother.

Interestingly, based on recent discussions on one of the IPv6 mailing lists (where you’ll also find other interesting tidbits), it looks like some vendors decided to move in the opposite direction: they use the same IPv6 LLA on all IPv6 interfaces present in a network device. Yet again, that shouldn’t be a problem (after all, LLA are supposed to be unique only within a single L2 domain) until you’re forced to connect two IPv6 interfaces back-to-back to implement whatever design not supported by the underlying hardware (Nexus 7000 comes to mind ;).

Recent posts in the same categories

5 comments:

  1. Unknown 12 July 2017 07:28
    What's the reason they wanted different addresses for every port though? I'm assuming based on the context that the ports were all in the same L2 domain in this case, so what would they gain by having more than one address?
  2. Daryl Stark 12 July 2017 11:05
    Very interesting article, but I don't understand why anybody would want L3 addresses on L2 interfaces on a switch. It's not like they are going to put IPv4 addresses on those interfaces either.
  3. Ivan Pepelnjak 12 July 2017 15:36
    @Kim & Daryl: I have no idea why someone would want to do it...
    Replies
    1. Christoph 13 July 2017 09:27
      Ivan, are you sure your reader & we're talking about pure L2 switches and not L3 switches?
      In the context of L2 switches, this really makes not much sense especially when you also other L3 protocols (IPv4, f.e.) in the network.
      But with L3 switches & routed ports this might go into the direction of microsegmentation... - or even the CLNS way of adressing (sort of...).
      However, the question of the use case remains of course...

      Regards
      Christoph
    2. Ivan Pepelnjak 14 July 2017 07:36
      Well, that would definitely make some sense, but then you'd need to generate /128 routes from DAD probes or something similar (probably opening the whole SAVI pool-of-worms)
  4. Gary Nigg 13 July 2017 01:09
    I think much confusion comes from the distinction between "ports" and "interfaces." To me, there is a significant difference between them. "Ports" are L2 forwarding entities where as "interfaces" are L3 forwarding entities (which contain IP addresses). This is why pretty much all 802.3 & 802.1 IEEE stds use "ports." But because Cisco first created routers back in the day, their CLI often treats them as synonyms (unfortunately). A VLAN interface can consist of multiple L2 ports. Spanning Tree can block 3 of 4 ports on a VLAN interface. If STP respans, you don't want an IP host to have to re-ARP. So as you said, an *interface* must be represented by a single MAC address for things like ARP. But, L2 protocols like STP, LACP, LLDP need to distinguish among a set of ports in the same broadcast domain to determine best paths, LAG members, and physical connections.
  5. Grimish 09 October 2021 07:24

    Definitely creates some funny results. Having dove in head first without much reading but going to town on some IPv6 configuration on alot of cisco IOS, addressing vlans with different LLA's does have interesting results, potentially makes it more complicated. Needless to say I believe this is how one learns as well. Forget the documentation until you've entered enough commands into hundreds of devices :-P

Add comment
Home
Sidebar