Table of Contents
The Phase 2—Infrastructure IPv6 Support in WLC Release 8.0 and Later section of this document provides information about the Infrastructure support for IPv6 protocols in the Unified controllers in Release 8.0.
The IPv6 feature set within the Cisco Unified Wireless Network software release version 7.2 allows the wireless network to support IPv4, Dual-Stack, and IPv6-only clients on the same wireless network. The overall goal for the addition of IPv6 client support to the Cisco Unified Wireless LAN is to maintain feature parity between IPv4 and IPv6 clients including mobility, security, guest access, quality of service, and endpoint visibility.
Up to eight IPv6 client addresses can be tracked per client. This allows IPv6 clients to have a link-local, SLAAC address, DHCPv6 address, and even addresses in alternative prefixes to be on a single interface. Work Group Bridge (WGB) clients connected to the uplink of an Autonomous Access Point in WGB mode can also support IPv6.
■Cisco AP 1040, 1130 (feature parity with release 7.6; release 8.0 features are not supported), 1140, 1240 (feature parity with release 7.6; release 8.0 features are not supported), 1250, 1260, 1600, 2600, 2700, 3500, 3500p, 3600, 3700, Cisco 600 Series OfficeExtend Access Points, AP 702, AP 702W, AP 801, and AP 802
To enable wireless IPv6 client connectivity, the underlying wired network must support IPv6 routing and an address assignment mechanism such as SLAAC or DHCPv6. The wireless LAN controller must have L2 adjacency to the IPv6 router, and the VLAN must be tagged when entering the controller interfaces. Prior to Release 8.0, APs did not require connectivity to an IPv6 network, as all traffic is encapsulated inside the IPv4 CAPWAP tunnel between the AP and the controller.
The most common method for IPv6 client address assignment is Stateless Address Auto Configuration (SLAAC). SLAAC provides simple plug and play connectivity where clients self-assign an address based on the IPv6 prefix. This process is achieved by the IPv6 router sending out periodic Router Advertisement messages which inform the client of the IPv6 prefix in use (the first 64 bits) and of the IPv6 default gateway. From that point, clients can generate the remaining 64 bits of their IPv6 address based on either the MAC address of the adapter or randomly. Duplicate address detection is performed by IPv6 clients to ensure random addresses that are picked do not collide with other clients. The address of the router sending advertisements is used as the default gateway for the client.
The DHCPv6 Stateless mode is used to provide clients with additional network information not available in the router advertisement. This information can include the DNS domain name, DNS server(s), and other vendor-specific options. The following interface configuration example is for an IPv6 router implementing stateless DHCPv6 with SLAAC enabled:
The DHCPv6 Stateful mode operates similar to DHCPv4, that is, it assigns addresses to each client instead of the client generating the address as in SLAAC. The following interface configuration is for an IPv6 router implementing stateful DHCPv6 with SLAAC turned off:
In order to deal with roaming IPv6 clients across controllers, the ICMPv6 messages such as NS, NA, RA, and RS must be dealt with specially to ensure that a client remains on the same Layer 3 network. The configuration for IPv6 mobility is the same as for IPv4 mobility and requires no separate software on the client side to achieve seamless roaming. The only required configuration is the controllers must be part of the same mobility group/domain.
1. If both controllers have access to the same VLAN the client was originally on, the roam is simply a Layer 2 roaming event where the client record is copied to the new controller and no traffic is tunneled back to the anchor controller.
2. If the second controller does not have access to the original VLAN the client was on, a Layer 3 roaming event will occur, meaning all traffic from the client must be tunneled via the mobility tunnel (Ethernet over IP) to the anchor controller. In a mixed deployment with Release 7.x and 8.x, Ethernet over IP is used. In pure 8.0 deployments, we support CAPWAP tunnel for IPv6 mobility tunnel.
a. To ensure that the client retains its original IPv6 address, the Router Advertisements from the original VLAN are sent by the anchor controller to the foreign controller where they are delivered to the client using L2 Unicast from the AP.
b. When the roamed client goes to renew its address via DHCPv6 or generate a new address via SLAAC, the Router Solicitation, Neighbor Advertisement, and Neighbor Solicitation packets continue to be tunneled to the original VLAN so that the client receives an IPv6 address that is applicable to that VLAN.
The interface groups feature allows an organization to have a single WLAN with multiple VLANs configured on the controller to permit load balancing of wireless clients across these VLANs. This feature is commonly used to keep IPv4 subnet sizes small while enabling a WLAN to scale to thousands of users across multiple VLANs in the group. To support IPv6 clients with interface groups, no additional configuration is required as the system automatically sends the correct router advertisement to the correct clients via L2 wireless unicast. By unicasting the router advertisement, clients on the same WLAN, but a different VLAN, do not receive the incorrect RA.
The RA Guard feature increases the security of the IPv6 network by dropping router advertisements coming from wireless clients. Without this feature, misconfigured or malicious IPv6 clients could announce themselves as a router for the network, often with a high priority, which could take precedence over legitimate IPv6 routers.
By default, RA guard is enabled at the AP (but can be disabled) and is always enabled on the controller. Dropping RAs at the AP is preferred as it is a more scalable solution and provides enhanced per-client RA drop counters. In all cases, the IPv6 RA is dropped at some point, protecting other wireless clients and upstream wired network from malicious or misconfigured IPv6 clients.
The DHCPv6 Server guard feature prevents wireless clients from handing out IPv6 addresses to other wireless clients or wired clients upstream. To prevent DHCPv6 addresses from being handed out, all DHCPv6 advertise packets from wireless clients are dropped. This feature operates on the controller, requires no configuration and is enabled automatically.
In order to restrict access to certain upstream wired resources or block certain applications, IPv6 Access Control lists can be used to identify traffic and permit or deny it. IPv6 Access Lists support the same options as IPv4 Access Lists including source, destination, source port, and destination port (port ranges are also supported). The wireless controller supports up to 64 unique IPv6 ACLs each with 64 unique rules in each. The wireless controller continues to support an additional 64 unique IPv4 ACLs with 64 unique rules in each for a total of 128 ACLs for a dual-stack client.
In order to support centralized access control through a centralized AAA server such as Cisco’s Identity Services Engine (ISE) or ACS, the IPv6 ACL can be provisioned on a per-client basis using AAA Override attributes. To use this feature, the IPv6 ACL must be configured on the controller and the WLAN must be configured with the AAA Override feature enabled. The actual named AAA attribute for an IPv6 ACL is Airespace-IPv6-ACL-Name similar to the Airespace-ACL-Name attribute used for provisioning an IPv4-based ACL. The AAA attribute contents must be equal to the name of the IPv6 ACL as configured in the controller.
The IPv6 neighbor discovery protocol (NDP) utilizes Neighbor Advertisement (NA) and Neighbor Solicitation (NS) packets in place of ARP to allow IPv6 clients to resolve the MAC address of other clients on the network. The NDP process initially uses multicast addresses to perform address resolution. This process consumes valuable wireless airtime because the multicast addresses are sent to all the clients in the network segment.
To increase the efficiency of the NDP process, neighbor discovery caching allows the controller to act as a proxy and responds back to the NS queries that it can support address resolution and duplicate address detection. Neighbor discovery caching is made possible by the underlying neighbor binding table present in the controller. The neighbor binding table keeps track of each IPv6 address and its associated MAC address. When an IPv6 client attempts to resolve another client’s link-layer address, the neighbor solicitation packet is intercepted by the controller that responds back with a neighbor advertisement packet.
Router Advertisement (RA) throttling allows the controller to enforce rate limiting of RAs headed towards the wireless network. By enabling RA throttling, routers that are configured to send RAs frequently (every 3 seconds) can be trimmed back to a minimum frequency that will still maintain IPv6 client connectivity. This allows airtime to be optimized by reducing the number of multicast packets that must be sent. In all cases, if a client sends a Router Solicitation (RS), then an RA will be allowed through the controller and unicast to the requesting client. This is to ensure that new clients or roaming clients are not negatively impacted by RA throttling.
Note: When RA throttling occurs, only the first IPv6 capable router are allowed through. For networks that have multiple IPv6 prefixes being served by different routers, RA throttling must be disabled.
The wireless and wired guest features present for IPv4 clients work in the same manner for dual-stack and IPv6-only clients. Once the guest user associates, they are placed in a “WEB_AUTH_REQ” run state until the client is authenticated via the IPv4 or IPv6 captive portal. The controller will intercept both IPv4 and IPv6 HTTP and HTTPS traffic in this state and redirect it to the virtual IP address of the controller. Once the user is authenticated via the captive portal, their MAC address is moved to the run state and both IPv4 and IPv6 traffic is allowed to pass.
To support the redirection of IPv6-only clients, the controller automatically creates an IPv6 virtual address based on the IPv4 virtual address configured on the controller. The virtual IPv6 address follows the convention of [::ffff:<virtual IPv4 address>]. For example, a virtual IP address of 192.0.2.1 would translate into [::ffff:192.0.2.1].
Enter an IPv6 enabled URL such as www.ipv6.google.com or an IPv6 address of a web site, for example—[2001::120]. The controller will intercept IPv6 HTTP and HTTPS traffic in this state and redirect it to the IPv6 virtual IP address of the controller as shown below:
When using a trusted SSL certificate for guest access authentication, ensure that both the IPv4 and IPv6 virtual address of the controller is defined in DNS to match the SSL certificates hostname. This ensures that clients do not receive a security warning stating that the certificate does not match the hostname of the device.
VideoStream enables reliable and scalable wireless multicast video delivery, sending each client VideoStream in a unicast format. The actual multicast to unicast conversion (of L2) occurs at the AP providing a scalable solution. In Release 8.0, the controller sends the IPv6 video traffic inside an IPv4 or IPv6 CAPWAP multicast tunnel which allows efficient network distribution to the AP.
IPv6 packets use a similar marking to IPv4’s use of DSCP values supporting up to 64 different traffic classes (0 – 63). For downstream packets from the wired network, the IPv6 “Traffic Class” value is copied to the header of CAPWAP tunnel to ensure that QoS is preserved end-to-end. In the upstream direction, the same occurs because client traffic marked at Layer 3 with IPv6 traffic class will be honored by marking the CAPWAP packets destined for the controller.
FlexConnect in local switching mode supports IPv6 clients by bridging the traffic to the local VLAN, similar to IPv4 operation. Client mobility is supported for Layer 2 roaming across the FlexConnect group.
Note: FlexConnect mode APs will join IPv4 or IPv6 Multicast group if AP Multicast mode is configured as Multicast in release 8.0; however, there will be slight Data through-put degradation impact in the FlexConnect centrally switched scenario compared to AP Multicast mode configured as Unicast.
■From the AP IPv6 Multicast Mode drop-down list, choose Multicast and enter a valid IPv6 multicast group address in the IPv6 Multicast Group Address text box. The IPv6 multicast group address must be in the FFXX::/16 range which is scoped for IPv6 multicast applications.
Note: Unlike previous versions of releases, IPv6 Unicast traffic support does not mandate that “Global Multicast Mode” be enabled on the controller. IPv6 Unicast traffic support is enabled automatically.
1. Go to the Controller tab > Multicast page. To support multicast IPv6 traffic, check the Enable MLD Snooping check box. In order for IPv6 Multicast to be enabled, the Enable Global Multicast Mode of the controller must be enabled as well.
2. To verify that IPv6 multicast traffic is being snooped, go to the Monitor tab > Multicast page. Notice that both IPv4 (IGMP) and IPv6 (MLD) multicast groups are listed. Click the “MGID” to view the wireless clients joined to that group address.
2. From the IPv6 RA Guard on AP drop-down list, choose Enable. RA Guard on the controller cannot be disabled. Along with RA Guard configuration, this page also displays any clients that have been identified as sending RAs.
6. Click Add New Rule, and enter the desired parameters for the rule, and click Apply. Leave the sequence number blank to place the rule at the end of the list. The Direction option of Inbound is used for traffic coming from the wireless network, and Outbound for traffic destined for wireless clients. Remember, the last rule in an ACL is an implicit deny-all.
7. IPv6 ACLs are applied on a per WLAN/SSID basis and can be used on multiple WLANs concurrently. To apply the IPv6 ACL, navigate to the WLANs tab and click the WLAN ID of the SSID in question. Click the Advanced tab and change the Override Interface ACL for IPv6 to the ACL name.
■Allow At-most: The maximum number of Router Advertisements per router that will be sent as multicast before throttling takes effect. The “No Limit” option will allow an unlimited amount of RAs through for that router.
Refer to Cisco Unified Wireless Network Solution: VideoStream Deployment Guide for information on enabling VideoStream on the 802.11a/g/n network as well as the WLAN SSID.
See Appendix A for sample IPv6 configurations on the 3750 switch.
Controller configuration for the native IPv6 support is similar to that of the IPv4 controller with the exception of the few interfaces accepting the IPv6 addresses as demonstrated in the following examples:
a. In the Interface Address area, enter the Primary IPv6 Address in the 2001:XX:XX:X0::XX format. Enter the Prefix Length as 64. In Primary IPv6 Gateway text box, assign the Link-Local address of the VLAN X0.
When you copy/paste the Link Local IPv6 address in the Primary IPv6 Gateway text box, ensure that there is no space in the beginning and end of the Link local IPv6 address. Click Apply to save the settings.
3. Once the IPv6 address is assigned to the WLC management interface, try accessing the WLC GUI, that is, launch https://[2001:10:10:X0::2] through your respective wired client connected to your controller.
4. Associate a wireless client, that is, your iPhone/iPad/laptop, to your respective controller WLAN and check if the client is able to receive the IPv4 and IPv6 addresses. Also, go to WLC > Monitor > Clients and click the client MAC address to view the IPv4 and IPv6 addresses.
The following screenshots display a client running MacOS, where the client is connected to the WLAN. The client receives both IPv4 and IPv6 addresses. Also, the client is able to ping the IPv6 address.
To support Mobility group configuration for Guest Anchor or Auto Anchor, the Guest Anchor should be on the 8.0 code to support controllers in release 8.0. This allows 8.0 WLCs sharing the mobility group to connect by using the CAPWAPv6 tunnel, and the WLCs running prior to release 8.0 will join by using the EoIP tunnel.
There is no need for New Mobility with this configuration. In this configuration mode, both ends of the Mobility tunnels have to be configured with IPv4 addresses. In pure 8.0 and later deployments, IPv6 addresses can be assigned and CAPWAPv6 can be used.
4. If an AP tries to join the WLC with configured prefer-mode and it fails to join, then it will fall back to choose the AP manager of the other transport and joins the same WLC. When both transports fail, the AP will move to the next discovery response.
1. As indicated above, Global prefer-mode will be pushed to default-group APs and to those AP Groups that do not have prefer-mode configured. The following example displays the Global prefer-mode configuration in the GUI, where the IPv4 or IPv6 address is chosen for the CAPWAP preferred-mode.
2. AP Group specific prefer-mode will be pushed to AP if prefer-mode of the AP Group is configured to the AP it belongs. Global prefer-mode will be pushed to default-group APs and to those AP Groups that do not have prefer-mode configured. To configure in the GUI CAPWAP preferred mode for the AP Group, see the following example:
This CLI command is used to configure the prefer-mode of the AP Group and all APs. Global prefer-mode is not applied to APs if the AP Group prefer-mode is already configured. After configuration, the AP restarts the CAPWAP to join with the configured prefer-mode after choosing the WLC based on its primary/secondary/tertiary configuration.
When selecting a primary, secondary, or tertiary controller, the process is similar to CAPWAPv4. The WLC management IP address can either be IPv4 or IPv6, it does not matter as long as the address is reachable. It is not possible to add both the IPv4 and IPv6 address because only one entry is allowed per WLC.
Example: Go to interface gi 1/0/24 and run the i pv6 rip cisco_user enable command (this interface is the uplink of your own IOS switch Core, if it is different from gi1/0/24, replace with the appropriate uplink port).
The DHCPv6 server can provide those configuration parameters that do not require the server to maintain any dynamic state for individual clients, such as DNS server addresses and domain search list options. The DHCPv6 server may be configured to perform prefix delegation.
All the configuration parameters for clients are independently configured into the DHCPv6 configuration pools, which are stored in NVRAM. A configuration pool can be associated with a particular DHCPv6 server on an interface when it is started. Prefixes to be delegated to clients may be specified either as a list of preassigned prefixes for a particular client or as IPv6 local prefix pools that are also stored in NVRAM. The list of manually configured prefixes or IPv6 local prefix pools can be referenced and used by DHCPv6 configuration pools.
The DHCPv6 server maintains an automatic binding table in its memory to track the assignment of some configuration parameters, such as prefixes between the server and its clients. The automatic bindings can be stored permanently in the database agent, which can be for example, a remote TFTP server or local NVRAM file system.
A DHCPv6 configuration information pool is a named entity that includes information about available configuration parameters and policies that control assignment of the parameters to clients from the pool. A pool is configured independently of the DHCPv6 service and is associated with the DHCPv6 service through the command-line interface (CLI).
A DHCP relay agent that resides on the client’s link, is used to relay messages between the client and server. The DHCP relay agent operation is transparent to the client. A client locates a DHCP server using a reserved, link-scoped multicast address. Therefore, it is a requirement that for direct communication between the client and the server, the client and the server must be attached to the same link. However, in some situations where management, economy, or scalability is a concern, it is desirable to allow a DHCP client to send a message to a DHCP server that is not connected to the same link.
The CAPWAP protocol allows a lightweight access point (AP) to use DHCP to discover a wireless controller to which it is connected to. Cisco lightweight APs running 8.0 and above support DHCP discovery for both IPv4 and IPv6 networks:
■IPv4—Cisco lightweight APs implement DHCP option 43 to supply the IPv4 management interface addresses of the primary, secondary, and tertiary wireless controllers (see the guide).
In 8.0 and above, Cisco lightweight APs support both stateless and stateful DHCPv6 addressing modes. In stateless mode, the APs obtain an IPv6 addressing using SLAAC while additional network information (not obtained from router advertisements) is obtained from a DHCPv6 server. In stateful mode, the APs obtain both IPv6 addressing and additional network information exclusively from DHCPv6 (similar to DHCPv4). In both modes, a DHCPv6 server is required to provide option 52 if wireless controller discovery using DHCPv6 is required. If a DHCPv6 server is not available, an alternative discovery method such as DNS or AP Priming is required.
Cisco lightweight APs request DHCPv6 options using DHCPv6 Solicit and Request packets which are forwarded to all DHCP servers multicast address (FF02::1:2). Request packets are forwarded in stateless mode while both Solicit and Request packets are forwarded in stateful mode. The Solicit and Request packets include an Option Request field that the APs use to request additional network information from the DHCPv6 server. The requested options include option 23 (Name Server), option 24 (Domain Search List) and option 52 (CAPWAP access controllers).
If the requested option 52 is defined within the IPv6 scope servicing the APs, the DHCPv6 server includes option 52 values in the DHCPv6 Advertise and Reply responses forwarded to the APs. The option 52 values forwarded to the APs may include up to three wireless controller management IPv6 addresses in order of preference.
Each DHCP server is unique and includes different pre-defined options from the server vendor. Unfortunately, option 52 is not pre-defined on Microsoft Windows Server 2008, Windows Server 2012, or Linux ISC which requires option 52 to be globally defined before the option and values can be assigned to a IPv6 scope.
When defining option 52 on DHCPv6 server, it is important to note that the option must be defined using a specific format. If not, the supplied wireless controller management interface IPv6 addresses will be rejected by the APs. To be supported by Cisco lightweight APs, option 52 must be defined as an array of IPv6 addresses and cannot be defined as a string or other type. If the option is not formatted correctly, the APs will reject the Advertise and Reply packets and fail to obtain an IPv6 address.
1. Modify the dhcpd6.conf file (typically, /etc/dhcp/dhcpd6.conf). Define a new unique option name (example, dhcp6.capwap-ac-v6) as shown in the following example. The option code value must be set to 52 and type set to array of ip6-address :
2. Locate the IPv6 scope servicing your Lightweight APs. Under the IPv6 range, add the newly defined option name (example, dhcpv6.capwap-ac-v6) followed by the management interface IPv6 addresses of the primary WLC. Optionally, define secondary and tertiary management interface IPv6 addresses if required. Note that a comma must separate each IPv6 address.
3. Enter a Name for the new option (for example, capwap-ac-v6), and then set the Data type to IPv6 Address. Check the Array check box, and then enter the Code value of 52. Click OK and then OK again. The new option is now defined and can be assigned to IPv6 scopes.
You can verify that a Cisco Lightweight Access Point (AP) has received an IPv6 address and options by logging into an AP and issuing the show ipv6 dhcp interface command. The output displays any assigned IPv6 addresses along with options and values:
In most enterprise deployments, the first hop router is configured to relay DHCPv6 messages to a centralized DHCP server. You can verify that the DHCPv6 packets are being exchanged between an AP and DHCPv6 server on an IOS device by issuing the debug ipv6 dhcp relay command.
In the above example, the DHCPv6 Solicit and Request packets from the AP are relayed to the DHCPv6 server with the IPv6 address 2001:470:52C5:A::7. The Advertise and Reply packets from the DHCPv6 server are relayed back to the APs link local address FE80::F27F:6FF:FEE8:1214.