Does your phone/tablet support 802.11k/v/r/u/w? Can you help complete the list?

I am trying to contribute to this page. I have quite a few devices in my lab, but need help.
Do you have a Cisco WLC/AP, and a BYOD that is not in the list?
Can you set the WLAN to 802.11r (FT) and try to associate? If it works, can you send to me the association request/response?
Can you do the same for 802.11k/v?
The rest (802.11u / 802.11w) can easily be checked from the WiFi Alliance website (check here). 802.11w is Protected Management Frame, and 11u is Passpoint...
Thanks!

802.11w. AKA PMF

802.11w purpose

802.11 includes 3 types of frames: data, control (RTS/CTS/ACK) and management. Typically, only the data frames are encrypted. The original reasoning was that management frames could be expected before association, and designing an encryption process for frames sent to devices that knew nothing of your encryption scheme did not strike the 802.11 designers as a logical requirement.
However, some 802.11 management frames include deauthentication and disassociation messages, that are sent to associated stations, and that can be spoofed, resulting in valid stations dropping from the cell due to mischievous devices impersonating the AP. To make things worse, other management frames contain key parameters, necessary for the station healthy life in the cell. Spoof the AP MAC address, send wrong values, and your nice station can get in trouble.
802.11w was published in 2009 to attempt to protect against this type of hacking.

802.11w process:

802.11w only applies to WLANs running Robust Security Networks (RSN), i.e. using AES/CCMP, WPA2, or WPA1/TKIP (this last one being in general deprecated, you want to stick to WPA2). When you enable  Protected Management Frames (PMF, AKA 802.11w) on such a WLAN, your AP goes through the same 4 way handshake, but also adds a hash, a signature, that will be present in several management frames while your station is associated. This hash is built from the WPA/WPA2 negotiation (this is why WPA2/AES-CCMP or TKIP is required). An attacker trying to spoof the AP MAC address will not have the secure hash, and will not be able to sign the management frame. Your PMF station ignores improperly signed management frames.

Management frames classes:
The "management frame" family is fairly large, and is organised in 3 classes. These classes match the state of the station receiving the frames:

1. Class 1 management frames include frames that can be received before authentication and association (beacon, probe responses, authentication request and response, 802.11h spectrum management frames). Those management frames are said to be "of class 1", and cannot be protected (as the receiving station is not associated yet, and therefore does not have any keying material yet).
2. Once the station authenticates, it can still receive class 1 frames, but can now also receive class 2 frames (i.e. management frames that cannot be received by non-authenticated stations, but that can be received by stations that are authenticated, but not associated yet). These class 2 frames include association request/responses, re-association request/response, and disassociation frames.
3. Once the station is associated, it can receive management frames of class 1 and 2, but also management frames of class 3 (management frames "that you need to be associated to receive them" :-)). These class 3 management frames include disassociation /de-authentication frames, and most unicast action frames (QoS, BSS transition, radio measurement, etc).

The IEEE (figure 10-6 in 802.11-2012) is a pretty clear representation of what state allows reception of which frame:

This frame class naming convention can be confusing, because 802.11w relates to the frame class to determine if (and in what case) it can be protected. The purpose is of course to protect type 3 management frames (as association is needed to get some keying material): disassociation, deauthentication and action frames. Notice that deauthentication can also be class 2. In that case, it is sent to an authenticated-but-not-associated station, is not signed, and therefore cannot be protected.

PMF vs MFP:
Do not confuse PMF Protected Management Frames (802.11w) with Cisco MFP (Management Frame Protection). Cisco MFP was developed in 2005, and has two modes:

• One 'infrastructure mode', where the APs sign their beacons and other broadcast management frames. Other APs can detect 'unsigned' broadcast management frames and report rogues to the WLC. This mode does not exist with 802.11w.
• One client mode, where the client participation is added. In this mode, the AP also signs management frames sent to the client (on top of the infrastructure part, that is also there). Cisco MFP was used as a basis for 802.11w development. You could say that 802.11w is somewhat like "Cisco MFP client part". On Cisco controllers, you can enable both PMF and MFP. Cisco client MFP requires your client to have CCXv5, in order to negotiate a signature process with the AP.

Protection negotiation:
Once 802.11w is enabled in the WLAN, the AP advertises (in beacons and probe responses) specific values for the RSN information element:

• Auth Key Management is set to SHA256 (instead of SHA1 with standard WPA2). The screenshot above has MFP set to Mandatory. If yous et 802.11w to "Optional", you will see both SHA256 and the standard OUI 00-0f-ac for AES/CCMP (WPA2).
• In the RSN Capabilities subelement, MFP cabale is set to 1, and MFP Required is also set to 1 if your WLAN is configured for 802.11w Mandatory (it would be set to 0 if the WLAN is set to 802.11w Optional).

Then, the process is a standard Open 802.11 authentication (authentication request / response). In the association request, the client mentions that it also supports 802.11w (if your client does not support 802.11w and your WLAN is set to 802.11w Mandatory, the client does not even try to associate. If the WLAN is set to 802.11w Optional, the client uses 802.11w if it it supports PMF, and standard WPA/WPA2 otherwise). This is what an association request (of a client supporting 802.11w looks like):

The client request SHA256 Key Management, and mentions that it supports PMF. The AP registers the client with its capabilities (as you know, the association response only contains, besides the AID, standard communication parameters, like supported rates and WMM information; no 802.11w-specific information is mentioned there).
The 4 way handshake is then very similar to the standard WPA2 4 way handshake. The only difference is that the station and AP use SHA256 instead of SHA1 (and the key is therefore longer)... and that the AP also needs to provide management frame protection for clients in the cell that support 802.11w. This means that you will have both a group temporal key (GTK), but also an Integrity group temporal key (IGTK), sent by the AP in EAPoL frame 3 to the 802.11 stations:

Management frames sent to groups of 802.11w stations are protected with this IGTK (used to generate a specific MIC). Note that these frames are not encrypted. This is why the 802.11w "tiny prints" (although they make it pretty clear) state that BIP (Broadcast/Multicast Integrity Protocol) provides message integrity and access control for group addressed Robust Management frames. In other words, the Message Integrity Check (MIC) ensures that you cannot spoof the sender MAC, or change the content without being noticed, but BIP does not encrypt the frame content.
Unicast Management frames also have this special MIC, but they are also encrypted, thus not only ensuring "message integrity and access control", but also "confidentiality". For example, below is  a standard Disassociation frame sent from an AP to a station in a WPA2 WLAN:

Nothing protects this frame. It clearly shows the source, destination, frame type and reason code. Any attacker could generate such a frame. In contrast, below is the same Disassociation frame, this time generated in a WLAN set for 802.11w, and sent to a 802.11w-enabled station:

You can still see the source, destination and frame type, but the content is encrypted with CCMP. You cannot see the reason code, and cannot see the MIC. An attacker would not be able to generate such a frame with a high chance of being successful. This process exists because the AP and the station exchanged encryption parameters both for the data frames, and for the unicast management frames (on top of using the 802.11w secured MIC).

802.11w is not the ultimate security for a WLAN
Just a quick word on this. You will read all over the Internet that "802.11w is not secure". Let's put things in perspective. 802.11w protects some management frames, that's all it does. There may be cases where either side (the AP or the station) may receive invalid frames, and may simply ignore the source. If you are clever (for example sourcing a frame from the broadcast address), you may get the cell in a configuration where traffic becomes difficult. In other words, adding the extra protection with 802.11w also adds some additional rejection mechanisms that can be exploited to make your wifi network unusable. 802.11w, or any other mechanism for that matter, cannot prevent that (it is also very easy to render a WPA2 cell unusable)... however, any additional security mechanism (including 802.11w) makes attackers' life harder.

802.11w Configuration:

Now this is the easy part. Set your WLAN to WPA1+WPA2. The set PMF to optinal (allowing both 802.11w and non-802.11w stations to associate) or Required (only 802.11w stations can associate).

   You will then see a "Comeback Timer" and SA Query Timeout parameters. These are often source of confusion. What happens if an attacker spoofs an AP MAC, and sends (invalid) management frames to a station? The station will ignore them. What happens if an attacker spoofs a 802.11w client MAC and sends (invalid) management frame to the AP? For example an association request (while the 802.11w station is already associated)? The AP has to think that the new association request is either wrong (spoofed frame by an attacker), or that the station did send a disassociation message before, that the AP missed (and the station is now re-associating). So the AP will respond with 2 messages:

• The first message is a response to this new association request, saying that the request is rejected, with a status code 30. This status code stands for "Association request rejected temporarily; Try again later". The AP also mentions when this "later" is going to be. This is the "comeback timer", a value ranging between 1 and 10 seconds (default 1 second, which is good in most cases). At this point, the station requesting the association has to wait a bit before sending a new association request. If the station is a valid client that really disassociated, then this delays a bit the association. But, if the association frame is spoofed (which is more likely to be the case), then this message has no impact on the legitimate, sill associated, valid 802.11w station.
• During the comeback interval, the AP wants to check if the 802.11w station is really still associated (and the new association request comes from an attacker), or if somehow, the AP managed to entirely miss that the station did disassociate at some point. So the AP is going to send to the 802.11w (that the AP believes to be still associated) a SA query message. This message basically says: "hey, you and I are still in a secured communication, right? We did the 4 way handshake thing, and negotiated security parameters that created a Secure Association (SA) between us? And er... you did not go away and did not tear down any of that, did you?" If the station is still associated properly (the new association request was coming from an attacker), it will respond, saying "yeah yeah, all good, I'm here" (all this exchange is encrypted of course). If the station is really gone... then it will not respond (as it deleted the SA upon sending the disassociation message, and is not associated anymore). So the AP has to wait for the station reply. If, after the SA Query timeout (200 milliseconds by default), no response is received from the client, then the AP understands that the client is really gone, deletes the SA, and is ready to receive the next association request and re-validate the client.

Down the same page, set the authentication form (PMF PSK or PMF 802.1X if you set 802.11w to Required, and 802.1X/PMF 802.1X or PSK/PMF PSK if yous et 802.11w to optional). Set the key value if using PSK.

Click Apply. Voila. To debug, use debug pmf events {enable | disable}.

802.11r

802.11r purpose

802.11r (AKA Fast Transition) is an IEEE 802.11 amendment published in 2008. The problem they were trying to solve at that time was as follows: when you roam from one cell to the other, you waste time. This is because your device stays associated to the current cell until the signal becomes too poor to be usable and then (only then):

• Leaves the channel to scan and discover other channels where the SSID is available (this scanning process wastes times, in a configuration where your communication is already bad)
• Once a new AP is chosen, the device needs to authenticate to that new AP, the disassociate from the old AP, then associate to the new AP. 

In a voice call, where every millisecond counts, this can take too long (you need to re-enter a 4 way WPA2 handshake, and maybe even get back to the RADIUS, before have a key that you can use). This process can be disruptive. The other bad news is that you have no idea on whether the new AP can continue your call or not (it may be completely overloaded already).

So 802.11r was designed to allow your device to run the next AP discovery process before leaving the previous cell, including negotiating the key with the new AP, and checking that the new AP can provide the same QoS services as the older one... and only then, once everything is ready, the device would make the short jump to the next AP. 802.11r can save a lot of time. In the illustration below, I roamed back and forth between two APs (WPA2/PSK). In the first case, 802.11r is not enabled.

Each blue diamond is the time elapsed between the last voice packet in the previous cell, and the first voice packet in the next cell. Depending on the scanning structure of the phone, you can see that I sometimes get to the next AP in a few tens of milliseconds, but sometimes performances are poor.
In the second example below, I enabled 802.11r on my APs, and performances are much better (careful, scale above is in seconds, because I get some long intervals, while the scale below is in MILLIseconds)..

802.11r process

802.11r is an extension to 802.11i. In other words, you can enable 802.11r only for your WPA2/CCKM WLANs (not WPAv1, not WPA2/TKIP, not for Open or WEP). At that time, the AP displays in its beacons and the Probe responses the FT information in 2 fields:

• The Mobility domain contains a hash value that is shared by all APs in the same 802.11r domain (i.e. between which 802.11r fast roaming is possible). In Cisco autonomous APs, this hash is derived from the IP address of your WDS. In a controller system, It is derived from the mobility group value.
• The Mobility domain section also mentions if QoS reservation (resource request protocol) is supported. Very few systems implement RRP, because it removes the intelligence from the client. It is usually better and more efficient to let the client assess the next cell load through QBSS IE information and decide of the best course of action, rather than constraining the client to negotiate QoS parameters.
• The Mobility domain section also mentions if negotiation with the next AP has to happen over the air, or over the DS (more on this below).   
• The RSN (Robust Security Network) field displays that Key management includes FT (with PSK or 802.1x, depending on how your clients authenticate).

Note: on Cisco controllers, (8.0 and later), you can enable "hybrid" WLANs, where you turn on either FT, WPA2/CCKM, or both. In this last case, you would see both FT and PSK (or 802.1x) key management:

Over the DS vs Over the Air:
Negotiation with the next AP can happen over the air, or over the DS. With "over the air", the client gets to the edge of the first cell, scans, finds another AP, and negotiates directly with this next AP the next key (and possibly QoS parameters). The advantage of this method is that communication is direct (no delay by going through the DS, not need for AP to AP wired communication protocol). The downside is that the client needs to leave its active channel to negotiate on another channel. Most BYODs send a frame to their current AP, telling them that they "go to sleep" (Null frame with Power Management set to 1, while in fact they go negotiate on another channel), then return to the active channel to "empty their and the AP buffer" (Null frame with Power management set to 0) before jumping out to the next AP.
The over the air process is direct, but may be disrupting in a location where the device is already at the edge of the cell (low data rate, lots of retries). To avoid that the negotiation also forces the device to go off channel for a while, the Over the DS method can be enabled. In this case, the device stays on the current channel (no need to pretend to sleep and leave the channel), and asks the current AP to negotiate with the next AP (your client still has to discover the next AP first, i.e. scan). This process saves time and increases efficiency, provided that both APs have a way to communicate. In a controller-based network, no problem. The unknown is in the efficiency (what is faster: direct negotiation, or going through the current AP, the WLC, then the next AP, with all the switches or routers that may be on the way?). The only answer is to test (or know your network, if APs are on the same switch and the WLC is close, DS is great. Add routers and switches, and the needle switches toward Over the air).

Key negotiation:
The major difference between 802.11r and standard WPA2/CCMP lies in the key negotiation. With standard WPA2/CCMP, the client and the RADIUS server generate a Master Session Key (MSK), which first 256 bits are used as the Pairwise Master Key, from which individual encryption keys (TK, temporal keys) are derived for individual frame encryption. With PSK (no RADIUS), the PSK is the MSK. The PMK is valid for the duration of the session, and roaming usually means renegotiating a new PMK (I am ignoring PMK caching various forms).
With 802.11r, the PMK derived from the MSK is in fact called PMK-R0. That key is kept where the authentication occurred (WLC, or first AP in an autonomous network). A second PMK is generated from the PMK-0; it is called PMK-R1. That PMK is the one used to derive the TK on the first AP. When the client negotiates with the next AP, the "domain ID" field and a PMK-R0 identifier tell if the next AP is in the same 802.11r domain as the previous AP, i.e. if the next AP also has access to the same PMK-R0. If domain is the same, then the client agrees with the next AP to generate a new PMK-R1 (from the same PMK-R0 in the central repository). The next PMK-R1 is passed to the next AP, and everything is ready.
In other words, client and next AP just need to know that they are in the same domain, and agree on the next PMK-R1 index. Then the client generates the new PMK-R1 on its side, while the next AP gets the same PMK-R1 from the wired side (WLC or WDS). No need for the client to perform authentication again.
During the 4 way handshake (FT style), the PMK-R0 and R1s are mentioned as part of the exchange (frame 2 of the 4 way handshake, sent from the AP, below):

The domain and PMK-R0 identifiers are enough to ensure that the device is in the same domain from one AP to the next, and the rest negotiates the PMK-R1 details.

The downside of this method is that non-802.11r client do not understand the "FT" key management method in the beacons and probe responses, and also do not understand the domain and key index in the 4 way handshakes. In short, they can't associate to WLANs set for 802.11r. This is the reason for the "hybrid" mode, where you configure both WPA2 and FT. non-802.11r associate using WPA2, while clients that support 802.11r use the more efficient FT method.
There are still some old clients that panic when seeing "FT" mentioned in the beacons/probe responses, even if WPA2 is there. This is because (poor programming) they do not recognize this security parameter, and refuse to associate, even if they do recognize WPA2. These older and poorly developed drivers tend to go away with newer devices and OS updates, but make sure to test 802.11r in your network before deploying it completely.

802.11r Configuration:

This is the easy part. In your WLAN, start by setting security to WPA+WPA2, then check Fast Transition (FT).  Default negotiation is over the Air, check Over the DS otherwise.
Clients can negotiate keys with the next AP, and then never jump there. The reassociation timeout determines the duration for which the newly negotiated key is valid. By default, if the client does not make the jump within 20 seconds, the next AP cancels the PMK-R1, considering that the client went elsewhere.

At the bottom of the screen, check FT 802.1X or FT PSK to enable 802.1X or PSK for 802.11r clients, and optionally also check 802.1X or PSK for the WPA2 clients (thus making the WLAN 'hybrid').
Of course, mode has to be the same for both (802.1X and FT 802.1X, OR PSK and FT PSK).

Click Apply. Done.
Use show wlan wlan-id and show client detailed to check your config. You cannot change the domain ID without changing WLC mobility configuration. Use debug ft keys {enable | disable} to follow the FT dialog from the WLC CLI.

CCIEW v3, what to expect

CCIE W v3 came out a few weeks ago. What should you expect?

AireOS:

The new version of the exam is based on AireOS 8.0 (previous version, v2, was based on 7.0). It is therefore fair game to expect to see "some of the new stuff" that appeared between 7.0 and 8.0, such as mDNS, IPv6 (for the infrastructure, IPv6 for clients was already in v2),  802.11ac, SSO, 802.11k/v/u/w/r, AVC, device Profiling, onboarding, RX_SOP, RF Profiling, but also all the enhancements that came into existing features, such as RADIUS DNS, QoS profiling from ISE (yes, ISE replaces ACS), wIPS, DNS-based ACLS, L2 ACLs, Min/Max power for TPC, and tons of changes on the Flex APs (local PEAP or TLS for example), not to mention new features on the MSE like Visitor Connect...
Okay, let's cut it short. It is not one of these updates where you think "I just need to brush up one one or two items, and I'll be good to go". You probably want to do a clean study of the entire WLC config guide 8.0. At the same time, the update from v1.0 to v2.0 also displayed a daunting list of changes, which is to be expected when an exam jumps across two major releases. Even if the list above looked scary to you, it is very likely that you have heard of, or worked with, quite a few of the items  in that list (unless your boss really thinks that 7.0 is the best code on earth). And if you have not heard of some of the items in the list, it is likely that they are not fundamental (doesn't mean that you won't get them in the lab, but they are likely not to be the core of your exam). The logic of any exam is always: make sure that the candidate knows the core of the body of knowledge (for example, it would be funny if the CCIE R&S exam did not test routing or VLANs). Once this is taken care of, the expert exam tends to test tinier items. The less items on that 'non-core' list, the more in depth you can expect tests on these "tinier items" to be. Similarly,  a longer list means that you are unlikely to be tested very deeply on many of these tinier items. Why not? Because despite Non Disclosure Agreements that people sign when taking the exam, people still talk, and it would not take long before forums would display "they only test items A and B". So, a longer list means that you are likely to get more items (and different items in each exam set). As the exam duration is still the same, each item is tested less in depth. It is still likely to be an expert level, but there is "expert" and "crazy expert". More items pushes the bar from "crazy" to just "expert", knowing your stuff well should be enough.

IOS-XE:

That's another scarecrow. As Converged Access is in the lab, you are likely to get 3650/3850 Switches and/or 5760s (maybe, maybe not, but likely). Are you expected to be a guru on these platforms? My bet is "probably not". As these beasts are on the blueprint, you need to know how to configure them for the classic functions that a wireless guy can expect from these boxes (WLAN, MC, MA, PoP, PoA, etc). However, these devices embark the IOS, and can do much, much more than wireless. A wireless guy is of course expected to know basic routing, but it is very unlikely that you may need to configure insane Wired-only functions. If you are comfortable running basic configurations in the GUI, you probably know most of what you need to know to survive this part. Add knowledge of what CLI configuration is done when you configure this or that in the GUI (in other words, survive the CLI), and you should be very close to where you need to be to enjoy the CA section in the exam. A common misconception about this version of the exam is that you need IOS-XE as deep as AireOS.

MSE/ISE/PI:

MSE is in the exam, with new functions. If you get a chance to read on what you can configure, you will soon discover that, just like in v2.0, the scope of what can be asked is limited. Rent and MSE for a day or 2, and you should know enough to be comfortable with any question. The same goes for PI. I often ask myself: what can they ask in PI that you could not find with a few clicks? Learning the interface is not hard... and all you need to know is the interface (there are very few features that you will find only in PI, and not in the WLC, that you would care about as a Wireless engineer).
ISE is just like ACS: scary because it is an entire world. Here again (and just like ACS), you are the wireless guy, so there should not be any feature that is so deep that you would need an ISE expert to help you. Knowing how to create standard policies is what ISE is about in the Wireless IE.

Troubleshooting/Diagnostic section:

This is new to this version of the exam, and aligns with similar sections of the other IE tracks. Google around, and you will find tons of examples of such diagnostic questions for the various tracks. The format is simple: you get a troubleshooting ticket, in the form of a collection of messages exchanged between people. Your job is to find the root cause of the problem. There is no direct interaction with a device (no typing and sweating through debug commands that you have to type). The goal is to read the exchange, to understand what is reported to be wrong. Then, navigate through the various exchanges to find the piece of information that would tell you what happened. Mmm... not clear? Maybe an example would help. Suppose you get a report from a customer saying that they cannot associate to the SSID (made up example, this is VERY unlikely to be what you will get in the real exam). What I would do here is wonder if no-one can associate, or just that one customer. And also I would want to know what the WLAN config is. You browse through the dialog and find that everyone else associates fine (hint, user config problem), further down, you find the spot where the config of the WLAN is described. It is WPA2/PSK. Okay, my next move would be to try to find the client config, or a sort of capture of the association exchange. And if you find that somewhere, and get a WLC message that complains about wrong key, bingo, the user has the wrong key configured, that's the problem. The real exam cases (you may get several cases, depending on each case difficulty) are probably a bit less "CCNA-level", but the logic is the same: browse through the docs to understand what the problem is, and try to spot information that shows the cause of the problem, and voila.

Conclusion: try or wait?

Most candidate wisely wait a few weeks when a  new exam comes out, so as not to be the first ones to crash test the new exam. Then, training organisations start publishing training material and the seats for the exam become hard to get... a major difficulty for this version will be for training companies to tell you exactly how much ISE, and how much IOS-XE, are required. A safe approach is to train you on almost everything (so as not to miss anything, and also not to disclose directly what they may have learned from other candidates on the exam specifics). If you have a chance to train on IOS-XE devices, and get your lab setup with what you will get in the lab, my advice would be not to wait, and give the exam a try. You may fail (but hey, maybe pass the first time, first-time passers are not unheard-of jewels anymore), but you will learn a lot on the exam logic, structure, and also on the depth to be expected to each section. In other words, you will learn how the game is played. This will help you tremendously pass the next time...

IPv6 survival guide for CCIE Wireless candidates

Ipv6 is on the menu for CCIE W v2.0. If you have no knowledge about IPv6, fear not: there is not much you need to know to survive the exam on that topic.
I uploaded a youtube video on IPv6 configuration for the lab here, and here are the basics you need to know what you are doing:

• IPv6 format and addresses

IPv6 addresses are longer than IPv4 addresses, 128 bits (16 bytes) instead of 32 bits (4 bytes).  They are written in hex, instead of decimal format, for example 2001:0bc2:b3f0:0000:0000:dcba:0000:0021. Each group represents 2 octets, so a complete address is 8 groups of 2 octets each. Each group has 4 hex values.
To simplify the view, leading 0s are removed, so :0bc2: and :bc2: are the same.
You can also represent a group of 4 0s as "0". So :0000: and :0: are the same. You can also simplify several groups of 0s as "::", so :0000:0000: and :: are the same. This simplification can be done only once in an address. So you can simplify the address above as 2001:bc2:b3f0::dcba:0:21 or 2001:bc2:b3f0:0:0:dcba::21, but not as 2001:bc2:b3f0::dcba::21 (otherwise, there would be no way to tell how many groups of 0s does each :: represent).

• IPv6 address mask

The network mask structure is a bit more complex than for Ipv4. Theoretically, the first 48 bits (6 bytes) are the network mask, used for inter-ISP routing. The next 16 bits are used for subnets inside the ISP network. 48+16 = 64, we used half of the address for the network mask.
The rest (64 bits) is the client address.
This makes that your common mask for IPv6 networks is /64. It is written /64, not 255.255.255.255.255.255.255.255.0.0.0.0.0.0.0.0 (and you see why by the length of the standard decimal mask).
You can still find specific masks. Just like for IPv4, you can use longer masks (to a certain, limited extend) for subnetting, and shorter masks when you want to fix only a few bits in the network part of the address.

• Special addresses

Just like for IPv4, there are special addresses in IPv6, that you may want to be aware of:

fe80::/10: this is what is called the link-local address. Notice the /10 mask. Fe80 hex is 11111110 10000000 in binary, any address that has the first ten bits set to 11111110 10 is link local. So link-local ranges from fe80:: (all the other bits are 0s) to febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff (11111110 1011111111... etc all ones to the end of the address). IPv6 generates a link local address immediately for any interface that has IPv6 enabled. It is only used on that link (not routed). You can configure it manually. If you don't, IPv6 uses the interface MAC address as the host part of the address. You can use this address to test the link (ping the device on the other end of the link), but you can't use it beyond the local link (you can't ping fe80:: addresses beyond a router). In IPv4, this address would be the equivalent to 169.254.0.0 APIPA addresses.

fc00::/7: this is the Unique Local Address (ULA is the little name). You will see that one often, because it is an address reserved for local, private space. It can be routed, but not to the internet. This is the equivalent to the RFC 1918 IPv4 address space (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16). Only the first 7 bits are fixed, so this space ranges from fc00:: (1111 1100 in the first byte) to  fdff (1111 1101 in the first byte, all the rest to 1s).
2000::/3: this is  a global unicast. This would be the equivalent to the IPv4 public address (but it works a bit differently).

ff00::8: this is  an IPv6 multicast address. Just like for IPv4, there are several well known IPv6 multicast addresses. This is the address that would be used if you were asked to forward IPv6 multicast traffic throughout your network alond with IPv4 multicast.

2001:: addresses: there are quite a few of them (2001:0000::/32 (Teredo), 2001:0002::/48 (benchmarking), 2001:0010::/28 (Orchid), 2001:db8::/32 (documentation)). They are used to translate IPv4 into IPv6 addresses (Teredo) for NAT, or for documentation and examples. They may be the ones used in your lab.

::ffff/96: this is another possible address you may be given. It is called the IPv4-mapped address, because it allows you to represent an IPv6 by using an IPv4 structure. For example, you can use ::fffff:192.0.2.7. As you can see, if your IPv4 address is 192.0.2.7, using an IPv6 address that is just the same with leading ffff makes it very easy for lab work.

You probably do not need to know much about these addresses for the IE wireless exam. You will probably be given a range of IPv6 addresses, and will just be asked to work your wireless gear to support them. Knowing the basic IPv6 address format will help you understand what was the reasoning behind the choice of the IPv6 block given to you: multicast, private address, etc.

• Testing IPv6

In the lab, you can expect to be asked to support Ipv6 connectivity, not to be asked to be an IPv6 guru and configure complex Ipv6 routing parameters, or even IPv6 to Ipv4 translation mechanisms.
If you want to test basic IPv6 connectivity to get a better grasp at how it works, you need a simple router, a basic switch and a laptop. Your windows 7 laptop already supports IPv6 on its interfaces:

You just need to keep it set to DHCP, and configure an IPv6 IP address and DHCP server on your router, just like in the video. You should see the client get an IPv6 address. The switch is layer 2, so it does not care about the IP address format above the Ethernet layer.
On your router, you need to enable Ipv6:

Router#conf t

Router (config)# ipv6 unicast-routing

Once IPv6 is enabled, you can create a DHCP scope for IPv6. For example, suppose that you want to create a DHCP scope for subnet FC0:6::/64. You first create the scope:
Router (config)# ipv6 dhcp pool vlan6
Router (config-dhcp)# prefix-delegation FC0:6::/64 64

Depending on your router IOS, the command used to provide the subnet information is prefix-delegation, followed by the subnet (fc00:6::/64 here) and an identifier (64 here), or the command addres-range followed by the subnet (which is the command we use in the demo video).
You do not need to add anything else (the router is going to announce the scope, and announce itself as the gateway), although there are some options you can add. But for wireless, the scope is the bare minimum you need to make it work.

Then, on the router interface to the switch, you need to create a subinterface, so that the switch can send tagged frames with VLAN 6 tag to the router. You then need to give your router an IPv6 address in VLAN 6 (you can also give an IPv4 address, if you want a point of reference to something you know), and you need to call for the DHCP scope, so the router starts providing addresses from that scope to DHCPv6 requests received on that interface:
Router (config)# interface FastEthernet0/0.6
Router (config-if)# encapsulation dot1Q 6
Router (config-if)# ipv6 address FC0:6::15/64
Router (config-if)# ipv6 dhcp server vlan6

Done, you can now plug your laptop to the switch, in an interface set for VLAN 6, and your laptop should get an IPv6 address from the router.


This is of course on the wired interface. The logic is the same for the wireless interface, except that the laptop would go through an AP and a WLC before getting to the VLAN6 dynamic interface on your controller, then to the switch and the router. The rest... is about wireless...

WLAN controller Local EAP profile vs external RADIUS server

You probably know that the the local EAP profile you can configure on a controller is a backup... it will be used only if no external RADIUS is defined for user authentication on the controller, or if the defined RADIUS cannot be reached. In other words, when you define a Local EAP profile on a controller that also has RADIUS servers, the order is as follows:
1. Try to use the RADIUS server defined in the WLAN
2. Try to use any RADIUS server defined in Security > AAA > RADIUS > Authentication.
3. If all this fails, try to use the local EAP profile.

Let's play with this idea:

With this WLAN configuration, am I going to use the 10.100.1.30 RADIUS server or the local EAP profile?
Did you answer the 10.100.1.30 RADIUS server? Well, almost right... but I first need to check that server:

Oops, Network User is NOT checked for 10.100.1.30. This supposedly means that I cannot use this RADIUS server for wireless client authentication (only for management users authentication)... but I called that server from the WLAN, so this global "Network User unchecked" parameter does not matter (thanks Stoef and Anonymous for this comment): because the RADIUS is called directly from the WLAN, the WLAN is going to try to use it anyway. But because Network User is unchecked globally, any other WLAN trying to use the global RADIUS server list (i.e. not having the RADIUS called directly from the WLAN) is going to skip that one RADIUS.
Things would be different if the RADIUS was disabled:

In this case (regardless of Network User being checked or not), I may be calling 10.100.1.30 from the WLAN, but the RADIUS is disabled, and cannot be used, and will be ignored.
Okay, so my controller is going to revert to plan 2, try to use any RADIUS server configured for Network User authentication in Security > AAA > RADIUS > Authentication.
Cool, there is one there (172.29.129.156), matching my criteria (Network User is checked, and the RADIUS server is enabled).
So, my controller is going to use it... or is it? If I look into Management > SNMP > Trap Logs:

Ooh, this is not my lucky day, 172.29.129.156 is not responding, so the controller removed it from the active server list (172.29.129.156 still has the "enabled" status in the RADIUS > Authentication page, this "enabled" status just means that you, the admin, intended to use this RADIUS, not that the controller can actually talk to it successfully).
Ok, then the controller is going to use the local EAP profile. I can see that by running the debug aaa local-auth db enable command:
*aaaQueueReader: Dec 02 16:21:49.385: LOCAL_AUTH: EAP: Received an auth request
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: Creating new context
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: Created new context eap session handle 94000011
*aaaQueueReader: Dec 02 16:21:49.386: LOCAL_AUTH: (EAP:18) Sending the Rxd EAP packet (id 1) to EAP subsys
*EAP Framework: Dec 02 16:21:49.386: LOCAL_AUTH: Found matching context for id - 18
*EAP Framework: Dec 02 16:21:49.386: LOCAL_AUTH: (EAP) Sending user credential request username 'cisco' to FILE
*aaaQueueReader: Dec 02 16:21:49.386: User cisco information retrieved
*aaaQueueReader: Dec 02 16:21:49.386: AuthorizationResponse: 0x2c190b9c

A lot of "LOCAL_AUTH" stuff is happening here, I am definitely using the controller local EAP.
Would have this happened anyway, even with a RADIUS server?
Nope, as soon as I re-enable my RADIUS server:

The authentication occurs on the RADIUS server, and I can see the result on my ACS server (if authentication was local to the controller, I would not see any hit on the ACS... you can try at home, the best way to try is to create one user on the controller, and another on the ACS, and see which one works depending on your configuration changes):

So, in summary, do not get caught by the appearences. Your controller will always ("always", that is on code 7.0.x) prefer an external RADIUS server to the internal local EAP profile, whatever your WLAN configuration looks like.
The WLC will revert to the local EAP profile ONLY if no external RADIUS can be used (external RADIUSes are not configured for network user authentication, or no external RADIUS answers). Always verify "the rest" (RADIUS servers configuration and reachability)  before trusting the WLAN configuration nicely displayed before your candid eyes... :-D

Stay tuned and sister blog

This blog has been very silent for the past few months. I did not want to post entries that would be too early for the CCIEW v2.0, and too late for the ones rushing to take the exam before the change.
But stay tuned! I will soon start re-posting new entries, this time entirely focused on CCIEW v2.0. With the zillions of questions I received so far, there seem to be tons of gotchas in this new exam.
I will also restart posting videos on the youtube channel soon.
Also, I received over the last few months many questions related to wireless, but not directly to the CCIE exam. To make things simple, I created a sister blog, where  I will post entries that will give you the background you may need to understand the "why" (and not the "how") of some configuration items present on the Cisco wireless solution. This sister blog is here: http://expertwireless2be.blogspot.com/