Android and DHCPv6 again
bruce.horth at gmail.com
Wed Oct 7 02:33:59 UTC 2015
The Android client should ignore the O-flag and just use the information in
the RA. Windows clients will ignore the DNS option in the RA and do a DHCP
request for the Other information.
My understanding is you can enabled the O-flag for stateless DHCPv6 and set
the RA DNS option at the same time. This configuration should work on
networks that have a mix of Windows and Android clients (seeing as Windows
clients do not natively support RFC6106).
On Tue, Oct 6, 2015 at 9:29 PM, Alejandro Acosta <
alejandroacostaalamo at gmail.com> wrote:
> This is a question a should test myself but anyhow I would like to
> hear your comments.
> What happen (on the client side/Android maybe) if I advertise the DNS
> information in the RA and I also enable the O bit?
> El 10/6/2015 a las 8:39 PM, Bruce Horth escribió:
> > Your device may be getting an address, but without a recursive DNS server
> > it may be useless.
> > If you're going to do SLAAC you'll also need to supply your client with a
> > recursive DNS server. Android prefers RFC 6106. As you mentioned, Google
> > has decided not to support DHCPv6 in Android. Unfortunately some router
> > manufacturers are only now getting around to implementing RFC 6106.
> > BH
> > On Sat, Oct 3, 2015 at 9:52 PM, Baldur Norddahl <
> baldur.norddahl at gmail.com>
> > wrote:
> >> Hi
> >> I noticed that my Nexus 9 tablet did not have any IPv6 although
> >> else in my house is IPv6 enabled. Then I noticed that my Samsung S6 was
> >> also without IPv6. Hmm.
> >> A little work with tcpdump and I got this:
> >> 03:27:15.978826 IP6 (hlim 255, next-header ICMPv6 (58) payload length:
> >> fe80::222:7ff:fe49:ffad > ip6-allnodes: [icmp6 sum ok] ICMP6, router
> >> advertisement, length 120
> >> hop limit 0, Flags [*managed*, other stateful], pref medium, router
> >> lifetime 1800s, reachable time 0s, retrans time 0s
> >> source link-address option (1), length 8 (1): 00:22:07:49:ff:ad
> >> mtu option (5), length 8 (1): 1500
> >> prefix info option (3), length 32 (4): 2a00:7660:5c6::/64, Flags
> >> *auto*], valid time 7040s, pref. time 1800s
> >> unknown option (24), length 16 (2):
> >> 0x0000: 3000 0000 1b80 2a00 7660 05c6 0000
> >> So my CPE is actually doing DHCPv6 and some nice people at Google
> >> that it will be better for me to be without IPv6 in that case :-(.
> >> But it also has the auto flag, so Android should be able to do SLAAC
> >> My Macbook Pro currently has the following set of addresses:
> >> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> >> ether 3c:15:c2:ba:76:d4
> >> inet6 fe80::3e15:c2ff:feba:76d4%en0 prefixlen 64 scopeid 0x4
> >> inet 192.168.1.214 netmask 0xffffff00 broadcast 192.168.1.255
> >> inet6 2a00:7660:5c6::3e15:c2ff:feba:76d4 prefixlen 64 autoconf
> >> inet6 2a00:7660:5c6::b5a5:5839:ca0f:267e prefixlen 64 autoconf temporary
> >> inet6 2a00:7660:5c6::899 prefixlen 64 dynamic
> >> nd6 options=1<PERFORMNUD>
> >> media: autoselect
> >> status: active
> >> To me it seems that the Macbook has one SLAAC address, one privacy
> >> extension address and one DHCPv6 managed address.
> >> In fact the CPE manufacturer is a little clever here. They gave me an
> >> address that I can use to access my computer ("899") while still
> >> SLAAC and privacy extensions. If I want to open ports in my firewall I
> >> could do that to the "899" address.
> >> But why is my Android devices without IPv6 in this setup?
> >> Regards,
> >> Baldur
More information about the NANOG