Wireless Access

I'm sharing my IPv6 experiences to this forum, in case others may benefit from my testing.

I've spent many hours testing as much as I could with management functions over IPv6 on the mobility controllers and APs, to try to learn what worked, and what did not. I have learned a lot, so wanted to share my results. All my recent testing was with 6.1.3.5.  My controller doesn't do any routing, as I have a neighboring router that provides all the layer 3 functions. Some of this information is also covered in Chapter 36 "IPv6 Support" in the 6.1 Users Guide (although I discovered much of this the hard way, before I found that chapter in the manual). Also, this is only discussing the management functions of the system, not the client IPv6 functionality, which has been working fine for us for years.

First, there are many things in the controller that do NOT work over IPv6. These include:
SNMP
RADIUS
NTP
SMTP
DNS
TFTP

There is no sign of a DHCPv6 client in either controller or AP.

Things that do work just fine over IPv6, for management access to the controller, are HTTP, HTTPS, and ssh. SYSLOG also works over IPv6.

There are a number of cosmetic bugs, like IPv6 addresses that show up in logs are truncated or mangled. Also, if you use a ULA address, those will not display in the GUI for some reason, although they do work fine.

You are able to give all controller interfaces an IPv6 address. APs will use SLAAC to get an IPv6 address if they hear RAs from a router. An easy way to verify that this all works is to ping6 any of the controller interfaces or the AP's SLAAC addresses.

For debugging from the controller, you can "ping ipv6", but you can't "traceroute ipv6". The documentation says you can "tracepath ipv6", but that is wrong. You can tracepath to an IPv6 address and it works, but you must leave out the phrase "ipv6", and there is no way to tracepath to an IPv4 address. Very inconsistent and confusing.

IPSEC over IPv6 is not implemented, so you cannot get a master controller talking to local controllers over IPv6 in a multi-controller environment. This also means that you can't reach remote APs over IPv6.

If you want to get your APs to communicate via IPv6 to your master or local controllers, it is a bit tricky. There are a number of caveats that you need to be aware of. The obvious way to configure which LMS the AP should use would be to configure your "ap system-profile" to specify an lms-ipv6 address and NOT give it an lms-ip address. You would think that would force it to use the IPv6 address for the LMS. However, that has no effect whatsoever. The only thing that works is to provision the AP to have a "Master Controller IP address" setting that is the IPv6 address of the LMS that you want to use. You cannot set the Host controller to an IPv6 address, because it cannot do the TFTP  boot via IPv6.

The other major caveat is that you must have a path MTU of 1500 all the way from controller to AP, when operating over IPv6. When using IPv6, the controller does not do anything to try to learn the path MTU to the AP, so assumes that the path can handle full ethernet frames. There are some large packets that get sent from the controller, that get IPv6 fragmented down to something that will just fit into 1500 byte frames, that will then get dropped by any tunnels you have along the path. In my case, I had an IPSEC tunnel in the path, with an MTU of 1422. Talking to APs over IPv4 works just fine over this path, but the large IPv6 packets will fail, and the AP will never come all the way up. However, if on the controller you run a "tracepath" to the IPv6 address of the AP, the controller will learn the path MTU, and remember it, and will resend the packets using smaller fragments, and the AP will immediately come up. Unfortunately it doesn't remember path MTU forever, and you'll eventually have to do another manual tracepath to get it to come back up again.

Do a "show datapath tunnel ipv6", and watch the "MTU" column to see what's going on here.

So, I have given up doing IPv6 to any APs that are at locations where I don't have a full 1500 byte path MTU. But, I can run them locally over IPv6 from any routed subnet just fine. Unfortunately I have to now manually configure the master controller address in every AP where I want this to work. So, a little more provisioning hassle if you want your APs operating over IPv6. And obviously any hope of running IPv6-only is gone for now.

To add to this information, I have some additional experience that people might find usefull.

In our network we use routeradvertisements to distrubute router information to clients and servers. We do this to be able to drop VRRP in the core and all servers get a static IPv6 address, but they take the default router and additional static routes from the router advertisements.

The problem I ran into is that the Aruba does not accept router advertisements in any way to configure routes. This means that we are not able to give it a IPv6 route to the outside world. This isn't really harmfull because we don't really need a default route at the moment, but in the future it might be usefull to have the posibility to tell the controller on what interface it should accept RA's and what it should do with them.

Besides this, on an interface where you want to do IPv6 you can tell it what prefix to use on that interface and it will set a SLAAC like address bases on that prefix on that interface. It would be much better it the controller would listen to the RA's on the network and derive it's prefix information from this.

Jan Hugo Prins

This is an update to my previous post, to correct one of my earlier points.

I indicated that setting the LMS IPv6 address in the ap system-profie had no effect.  Actually it does have effect, but ONLY if the AP is configured to talk to the master controller over IPv6.

So, if you provision an AP with an explcit master controller address that is an IPv6 address, then the LMS addresses in the ap system-profile that have any effect are the IPv6 addresses, and not the IPv4 addresses.  If the AP is using IPv4 to talk to the master controller, then only the LMS IPv4 addresses in the ap system-profile have effect.

In my environment, I have all APs provisioned with the IPv6 address of the master controller (except the APs that are behind tunnels, for the reasons given earlier), and all ap system-profile configurations have both the IPv4 and IPv6 LMS addresses for the desired local controller.  This gives me the same flexibility that I had before with just IPv4, as I can move APs easily from one controller to another by simply re-provisioning them into different AP groups that point to the desired LMS.

Thank you for your interest and sharing your IPv6 experience.  I look forward to hearing more.
ArubaOS continues to get features related to IPv6 amongst other things.  Radius and TACACs authentication over IPv6 was added in AOS 6.3.
With AOS 6.4, the controller will support additional IPv6 features including:
Support AP to controller discovery and alleviates manually configuration.
 - AP - DHCPv6 client is now supported on AP
 - AP - DNSv6 is supported on AP.  AP is also able to get DNSv6 server IP from RA or DHCPv6 to find its master

Controller
 - SNMPv6
 - NTPv6
 - VRRPv3
 - support L2 / L3 GRE tunnels
 - Image management using scp/tftp/ftp over IPv6 transport

Best Regards,

 -michael