Multi-auth "Per User VLAN" and IPv6

[Johannes Luther]

Hi board,

I tried to ask this question in the NAC board a while ago, but got no answer. I guess it's more an IPv6 FHS feature question...

in the configuration guide for IOS-XE, the following multi-auth limitation is described:

In the Multi-auth Per User VLAN assignment feature, egress traffic from multiple vlans are untagged on a port where the hosts receive traffic that is not meant for them. This can be a problem with broadcast and multicast traffic.

• IPv6 control packets: In IPv6 deployments, Router Advertisements (RA) are processed by hosts that are not supposed to receive them. When a host from one VLAN receives RA from a different VLAN, the host assign incorrect IPv6 address to itself. Such a host is unable to get access to the network. The workaround is to enable the IPv6 first hop security so that the broadcast ICMPv6 packets are converted to unicast and sent out from multi-auth enabled ports.. The packet is replicated for each client in multi-auth port belonging to the VLAN and the destination MAC is set to an individual client. Ports having one VLAN, ICMPv6 packets broadcast normally.
  

So the problem itself is crystal clear. End devices might receive broad- and multicast packets, which are outside their IP subnet scope.

However I have to idea how to configure the described workaround (The workaround is to enable the IPv6 first hop security so that the broadcast ICMPv6 packets are converted to unicast and sent out from multi-auth enabled ports).

How to configure IPv6 FHS that multicast RAs are replicated to each end device as an unicast frame?

[Johannes Luther]

Hi board,

I tried to ask this question in the NAC board a while ago, but got no answer. I guess it's more an IPv6 FHS feature question...

in the configuration guide for IOS-XE, the following multi-auth limitation is described:

In the Multi-auth Per User VLAN assignment feature, egress traffic from multiple vlans are untagged on a port where the hosts receive traffic that is not meant for them. This can be a problem with broadcast and multicast traffic.

• IPv6 control packets: In IPv6 deployments, Router Advertisements (RA) are processed by hosts that are not supposed to receive them. When a host from one VLAN receives RA from a different VLAN, the host assign incorrect IPv6 address to itself. Such a host is unable to get access to the network. The workaround is to enable the IPv6 first hop security so that the broadcast ICMPv6 packets are converted to unicast and sent out from multi-auth enabled ports.. The packet is replicated for each client in multi-auth port belonging to the VLAN and the destination MAC is set to an individual client. Ports having one VLAN, ICMPv6 packets broadcast normally.
  

So the problem itself is crystal clear. End devices might receive broad- and multicast packets, which are outside their IP subnet scope.

However I have to idea how to configure the described workaround (The workaround is to enable the IPv6 first hop security so that the broadcast ICMPv6 packets are converted to unicast and sent out from multi-auth enabled ports).

How to configure IPv6 FHS that multicast RAs are replicated to each end device as an unicast frame?

[Cristian Matei · Accepted solution]

Hi,

     This is quite interesting, and never considered this scenario. Let me know how it works, here's what you're looking for:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-16/ip6f-xe-16-book/ip6-nd-mcast-supp.html

Regards,

Cristian Matei.

[Johannes Luther]

Hey Cristian,

this was exactely what I'm searching for.

I won't test this at the moment, because I'm writing a paper and need to outline the issues with multi-auth and IPv6. At the end of the day I don't want this to implement :) But I was curious, if there is a feature out there, which does this in the wired world.

In the CUWN wireless word, this is the normal behavior, that RAs are converted to unicast frames towards the wireless clients...

Thanks again for the great answer - I was too blind to find the documentation!

Best regards

Johannes

[Cristian Matei]

Hi,

     CUWN world is different, there are no wires, everyone is connected but the same port/radio :) For wired, i think the multi-vlan case is a unique case where the problem shows up.

Regards,

Cristian Matei.

[Johannes Luther]

Well, in fact it's exactely the same issue there regarding Multicast replication in one cell.

If all clients within a SSID (BSSID) are in the same IP subnet, everything is perfectly well.

If the clients within a SSID are using different IP subnets (e.g. interface group feature), the same Multicast packets might be sent multiple times into the cell (one time per IP subnet if there are Multicast receivers).

So it's the same with IPv6 RAs ... if there are no dirty hacks, the clients will get confused regarding IPv6 connectivity, if the clients within a SSID are using different IP subnets. So it's exactely the same use case:

• Multiple clients in different IP subnets behind one switch port
• Multiple clients in different IP subnets within one radio cell in the same SSID

To workaround this issue, CUWN converts the RAs to unicast as well towards the clients.

[Cristian Matei]

Hi,

   We're saying the same thing, functionality/tweak is the same (what i meant by different is in bold):

           - in CUWN, you expect this to happen as within the same SSID, you can have users in different VLAN's/subnets

           - in wired, you rarely see one access port (like one SSID in CUWN) with users in different VLAN's/subnets, except for exceptions :)

Regards,

Cristian Matei.