Wireless Access

 View Only
last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

IPv6 client VLAN basics...

This thread has been viewed 16 times
  • 1.  IPv6 client VLAN basics...

    Posted Aug 11, 2022 01:48 PM

    We are running a dev system AOS 8.10, 1xMC,  2 controller cluster (and 2 controller backup cluster) all 7220s

    We have a newish FW and want to play with ipv6, now trying to get it working on a client VLAN. Of course we have limited IPv6 experience!

    We have:

    - enabled IPv6 globally on all controllers
    - given each controller (and MM) a static IPv6 global address on their management VLANs and set this to be the controller-ip (this all appears to work fine)
    - set the IPv6 default gateway address
    - have _not_ set a loopback address (we don't currently have this set on any controllers
    - routing for all VLANs that we are playing with (MD management and client VLANs) takes place on the FW
    - set an IPv6 address on client VLAN interface on all cluster members (this VLAN is native IPv6)
    - our FW chap has tried setting SLAAC and DHCPv6 (on the FW) but clients always fail to get an address - though strangely a device that was _already_ connected to the test SSID that drops onto the IPv6 client VLAN looked like it did pick up what looked like valid addresses though as soon as the owner tried to disconnect and reconnect it failed to connect, feels like this is a red herring or some product of circumstance but I mention it anyway.
    - APs are on IPv4 mgmt addresses
    - I am testing on a RAP from home. It's a tunnelled SSID (testing version of eduroam)

    I'm not sure what we are missing. On the client VLAN interfaces on the controllers what do we need to configure as a minimum? Do we have to configure DHCP helpers? MLD? Neighbour Discovery? The FW guy is fairly confident he has done what is necessary on the FW.

    The logon user role has default rules which I assume should allow IPv6 to work:

    Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Denylist Mirror DisScan IPv4/6 Contract Mark Description
    -------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- -------- ------ ------- ------ -------- ---- -----------
    1 user any udp 546 deny Low 6
    2 any any svc-v6-icmp permit Low 6
    3 any any svc-v6-dhcp permit Low 6
    4 any any svc-dns permit Low 6
    5 any fc00::/7 any-v6 permit Low 6
    6 any fe80::/64 any-v6 permit Low 6
    7 any ipv6-reserved-range any-v6 deny Low 6

    The SSID dot1x (test version of eduroam which works fine on an IPv4 VLAN)

    In the user table it is interesting because my device IPv6 link-local address appears, and is in the 'open' (post-auth) role. But even so adding a v6-allowall to that role makes no difference. My Android phone client just gets stuck on Obtaining IP address.

    I have been trying to follow the deployment guide but there is a lot to take in and it often just assumes we will know what we need.

    Any ideas what we are missing please? Or is there a step by step guide for this? Any help much appreciated



  • 2.  RE: IPv6 client VLAN basics...

    Posted Aug 11, 2022 01:54 PM
    Oh, I did just read this "An IPv6 AP can serve both IPv4 and IPv6 clients." does that mean the APs have to have IPv6 mgmt addresses?
    The doc that is from is ancient though

  • 3.  RE: IPv6 client VLAN basics...

    Posted Aug 12, 2022 06:30 AM
    Think this is an excellent video series to better understand IPv6. And be aware that for address assignments you have options like SLAAC and DHCPv6, where some client OSses support just one or both.

    For your Aruba environment, your controller doesn't need to have any IPv6 IPs... if you do routing and address assignment on your firewall or other external device, which is the same as IPv4 where you don't need an IP on the controller interface for L2 deployments. Enabling IPv6, and I think there is a separate setting for IPv6 in the controller firewall, is recommended, also because it gives visibilty.

    The connection between the AP and controller can run over either IPv4 or IPv6, and because the SSID is tunneled you can run any IP version for the clients that are associated to the AP.

    The video series mentioned above has quite some packet captures as well, and you can use that to determine if the issue lies in your controller (I would recommend to start with the authenticated role, not a restricted role that uses logon-control policies); and try to put a (wired) client in the VLAN offered by your firewall admin to verify if IPv6 works there (my guess would be that it won't).

    Herman Robers
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

  • 4.  RE: IPv6 client VLAN basics...

    Posted Aug 12, 2022 10:39 AM
    Thanks for the pointers Herman - yes that video series is excellent, very accessible.

    It turned out that the specific issue was that I was using Android for testing and that doesn't support DHCPv6 (so your client compatibility list was spot on), or at least not without adding the RDNSS option to the RA, there is a very helpful blog explaining this here:


    Though hopefully no-one has to go to the same lengths as he does!

    I removed the interface addresses from the client VLAN on our controller and any other random stuff I had switched on (so all I had to do was turn IPv6 on globally, and I did that in the firewall too), and the FW guy did his stuff to add the RDNSS option to the RA, and now Android connects and gets an IP (as do the Win 10 and Mac devices we have tested with, but it turned out they already were getting addresses, I just didn't think to test with them - lesson learned!). So we are happy that experiment 1 in IPv6 is a success! There are still some reachability issues with some websites but I think that's probably for the FW chap to sort out.