To double check, I did a capture on a fortinet FWF60D looking for my ipv6 address & it's request on the wifi interface.
( capture fortinet fortigate firewall )
NOTE: Here you can monitor packets, and write a pcap capture file, that could be read back within tcpdump, tshark/wireshark.
In this screen shot; " my phone is enable for dual-stack operations on the wifi interface ", so after I found my ipv4 address and arp entry on my testing macbook, I'm now able to drill-in and focus my efforts on the discovery for ipv6 address & any ND discovery.
These one-on-top screenshots; "shows my layer2 ether_address and snippet of a analyze ipv6 packet using tshark of my ping and ping request "
I've circled the corresponding ipv6 entries, and the ether frame mac_address.
I than used tcpdump for this post and this cmd line capture-filter, once I identified my adapter's mac_address
I could have filter out any thing non-Ipv6 by adding the <ip6>
Google, good job, we have ip6 aware interfaces for the WiFi, but no ipv6 details in the phone displays. Just only ipv4 information.
I'm leaving you, with some screen-shots of how this looks & from the phone display.
One interesting tidbit. If you check around the internet forums, you will see many discussions about if your try to engage a ipv6-only network. The Android phone will not establish a session if using the wifi interface ONLY for ipv6 addressing. ( It needs to have a ipv4 address enabled also )
Here's my phone associated to the my Fortigate AP.
Ipv6 RouterSolicitation reflects the "33:33:00:00:00:01" address during host solicitation for a ipv6 router.
And here's the 2nd SSID configured as a ipv6-only interface on a Fortigate FWF60D running latest 5.0.4 code.
So if you should ever enter a ipv6-only access wifi location, you will probably NOT get an ipv6 assignment.
Why Android OS has this stipulation is ridiculous, and more so when you think deep about it.
So in order to combat this flawed logic, you can either statically install an address on the phone wifi or place a APIPA a dhcp-server or some othert bogus network on the interface serving the phone. I know this is stupid, but this is google being just ....... Google :)
A interface that's precipitating within a ipv6-only address space, should not have a dependency with the need for a ipv4 address. That's the whole point of trying to move into a ipv6 realm. Maybe google missed this simple concept, & in their promotion of ipv6 world day.
As a matter of fact, if you recall the earlier post of mine; " where we took this same google nexus 4 phone , and enabled the dual stack on the GSM cellular interface "?
This same phone works as a ipv6-only phone ( no ipv4 support ), when using my celluar provider network.
( notice no ipv4 addressing? )
So why can't google allow the same principle for the wifi interface on their google Nexus4 phone ?
Also one more tidbit, if you happen to come across a ipv6-only GSM celluar phone, T-Mobile is most likely doing some NAT64 to allow you access to the various ipv4 portions of the internet. Check out this email header that I harvest from a mail message sent to myself ;
T-Mobile, a good job !
Okay, I'm done with ipv6 testing on my Android............for now. Stay tune, I will have some new things that are ipv6 related, next week.
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
=( @ @ )=