Subject: [v6ops] out-of-focus: why DHCPv6 breaks Android computers?

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 28 Oct 2019 10:46:37 +0100

This message is out of focus of current discussions.

Why the presence of a DHCPv6 server breaks Android computers?

On my CPE at home, of ISP Free, I noticed recently this message: 'Watch 
out: if you activate the DHCPv6 server, certain Android computers are at 
risk of loosing their IPv6 connection'.

Why and how the presence of a DHCPv6 server on the CPE breaks Android 
computers?

I would like to try this DHCPv6 server to connect my Windows 2-in-1 
computer to work at home, but I dont want to break the other Android 
tablet that shows the weather report.

Alex

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 28 Oct 2019 10:29:24 +0000

Alex,

Most probably a bug in your Free CPE (that appears to be over-zealous)

-éric

From: v6ops <[email-masked]> on behalf of Alexandre Petrescu <[email-masked]>
Date: Monday, 28 October 2019 at 10:47
To: "[email-masked]" <[email-masked]>
Subject: [v6ops] out-of-focus: why DHCPv6 breaks Android computers?

On my CPE at home, of ISP Free, I noticed recently this message: 'Watch out: if you activate the DHCPv6 server, certain Android computers are at risk of loosing their IPv6 connection'.

Why and how the presence of a DHCPv6 server on the CPE breaks Android computers?

I would like to try this DHCPv6 server to connect my Windows 2-in-1 computer to work at home, but I dont want to break the other Android tablet that shows the weather report.

Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 28 Oct 2019 11:33:23 +0100

It may be that if you enable DHCPv6, SLAAC is disabled, and then Android will not work (as they don’t support DHCPv6)? So probably the “message” is not correct …

Regards,

Jordi

@jordipalet

El 28/10/19 11:30, "v6ops en nombre de Eric Vyncke (evyncke)" <[email-masked] en nombre de [email-masked]> escribió:

Alex,

-éric

Alex

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 28 Oct 2019 11:35:19 +0100

By the way, I’m not saying that it is correct to “disable” SLAAC if you enable DHCPv6, but I’ve seen some “bad designed” products that do that …

Regards,

Jordi

@jordipalet

El 28/10/19 11:34, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

Regards,

Jordi

@jordipalet

Alex,

-éric

Alex

---

From: Simon Hobson <[email-masked]>
Date: Mon, 28 Oct 2019 21:11:21 +0000

> Most probably a bug in your Free CPE (that appears to be over-zealous)

Could an alternative explanation be along the lines of :
User turns on DHCPv6 server -> CPE configures it's RA service to label the network as managed
End user device receives RA and finds the network is managed -> it turns off SLAAC
As the EU device has disabled SLAAC and doesn't support DHCPv6, it now loses IPv6 connectivity

---

From: Scott Morizot <[email-masked]>
Date: Mon, 28 Oct 2019 17:53:23 -0500

> As the EU device has disabled SLAAC and doesn't support DHCPv6, it now

No. Managed and autoconfig are separate and independent parts of the RA. We
turn the former on and the latter off on most subnets at work, but I
definitely know from experience that if you turn both on operating systems
that support both will usually happily configure *both* a DHCPv6 *and* a
SLAAC address.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 29 Oct 2019 11:18:24 +1100

> Why and how the presence of a DHCPv6 server on the CPE breaks Android computers?

The presence of DHCPv6 should not break Android devices (have not seen
it before).
Try it and see what happens? The only theory I have is that by
'activating DHCPv6'  your CPE actually means 'disabling SLAAC'. Then
yes, it would break things.

> I would like to try this DHCPv6 server to connect my Windows 2-in-1 computer to work at home,

Get the Creator update ;) Then it would work with RDNSS ;)

-- 
SY, Jen Linkova aka Furry

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Oct 2019 11:37:11 +0100

Le 29/10/2019 à 01:18, Jen Linkova a écrit :
>> On my CPE at home, of ISP Free, I noticed recently this message: 
>> 'Watch out: if you activate the DHCPv6 server, certain Android 
>> computers are at risk of loosing their IPv6 connection'.
>> 
> The presence of DHCPv6 should not break Android devices (have not 
> seen it before).

I may have not used the right word 'break'; a more conforming
translation is 'loose their IPv6 connection'.

While trying, that is what seem to happen: when turning on DHCPv6 server
on the CPE the Android stops browsing ipv6.google.com. (it could browse
when it was off).

Remark, under same conditions, my Windows PC resists well this flipping
of the DHCPv6 Server on CPE - it continues browsing ipv6.google.com
after the flipping.

> Try it and see what happens?

Thanks, I did learn a few things while trying.

> The only theory I have is that by 'activating DHCPv6'  your CPE 
> actually means 'disabling SLAAC'. Then yes, it would break things.

Well no.  After  activating DHCPv6 on CPE the CPE sent three RAs
changing the Lifetime and flipping the M(anaged) and A(utonomous) flags.

Packet dumps available upon request.

>> computer to work at home,
> 

Well, I have Windows 10 latest version (not Creator), but it seems to
work ok.

The RDNSS option is present already in the RAs sent by the CPE.  But I
do not understand why would one suggest the use of RDNSS could solve
this problem.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Oct 2019 11:38:19 +0100

> As the EU device has disabled SLAAC and doesn't support DHCPv6, it now loses IPv6 connectivity

After trying, I think that is what happens.

Alex

> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Oct 2019 11:39:38 +0100

Le 28/10/2019 à 11:35, JORDI PALET MARTINEZ a écrit :
> By the way, I’m not saying that it is correct to “disable” SLAAC if you 
> enable DHCPv6, but I’ve seen some “bad designed” products that do that …

Well, depends what we call SLAAC.

I agree with you some bad designed products do that.

In this particular case I think the CPE sends the proper RAs with the 
right (to me) A, M and Lifetime flags such that someone using DHCPv6 can 
do it.

Alex

> 
> Regards,
> 
> Jordi
> 
> @jordipalet
> 
> El 28/10/19 11:34, "v6ops en nombre de JORDI PALET MARTINEZ" 
> <[email-masked] <mailto:[email-masked]> en nombre de 
> jordi.palet=[email-masked] 
> <mailto:jordi.palet=[email-masked]>> escribió:
> 
> It may be that if you enable DHCPv6, SLAAC is disabled, and then Android 
> will not work (as they don’t support DHCPv6)? So probably the “message” 
> is not correct …
> 
> Regards,
> 
> Jordi
> 
> @jordipalet
> 
> El 28/10/19 11:30, "v6ops en nombre de Eric Vyncke (evyncke)" 
> <[email-masked] <mailto:[email-masked]> en nombre de 
> [email-masked] <mailto:[email-masked]>> escribió:
> 
> Alex,
> 
> *From: *v6ops <[email-masked]> on behalf of Alexandre Petrescu 
> <[email-masked]>
> *Date: *Monday, 28 October 2019 at 10:47
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[v6ops] out-of-focus: why DHCPv6 breaks Android computers?
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of 
> the individual(s) named above and further non-explicilty authorized 
> disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited and will be considered a criminal offense. If you are not the 
> intended recipient be aware that any disclosure, copying, distribution 
> or use of the contents of this information, even if partially, including 
> attached files, is strictly prohibited, will be considered a criminal 
> offense, so you must reply to the original sender to inform about this 
> communication and delete it.
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of 
> the individual(s) named above and further non-explicilty authorized 
> disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited and will be considered a criminal offense. If you are not the 
> intended recipient be aware that any disclosure, copying, distribution 
> or use of the contents of this information, even if partially, including 
> attached files, is strictly prohibited, will be considered a criminal 
> offense, so you must reply to the original sender to inform about this 
> communication and delete it.
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Oct 2019 11:51:36 +0100

> Most probably a bug in your Free CPE (that appears to be over-zealous)

I could try to report this bug to Free or Android, if I were whose 
thinking were buggy.

Or I could propose an RA flag for GUIs to accept Androids.

Until then, I keep DHCPv6 Server off in the CPE :-(

Alex

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Oct 2019 07:22:11 -0400

> Packet dumps available upon request.

That’s the problem.   It should turn on the managed bit but not turn off the autonomous bit.  The two can validly be on at the same time.

Of course, since their meanings are deprecated, it’s not too surprising that implementations get this wrong.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 29 Oct 2019 12:38:57 +0000

Indeed. CPE router should allow keeping both M and A flags, to allow simultaneous usage of DHCPv6 and SLAAC by the hosts.

About time to update RFC7084 -
https://tools.ietf.org/html/rfc7084#section-4.3

Cheers,
Rajiv

On Oct 29, 2019, at 7:22 AM, Ted Lemon <[email-masked]> wrote:

 On Oct 29, 2019, at 6:37 AM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
Well no.  After  activating DHCPv6 on CPE the CPE sent three RAs
changing the Lifetime and flipping the M(anaged) and A(utonomous) flags.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 29 Oct 2019 14:42:37 +0000

> From: Ted Lemon
>> On Oct 29, 2019, at 6:37 AM, Alexandre Petrescu <mailto:[email-masked]> wrote:

> Of course, since their meanings are deprecated, it’s not too surprising that implementations get this wrong.

Deprecated? Their meanings aren't deprecated at all, AFAIK. Specifically, the Autonomous bit continues to mean "this prefix can be used to generate SLAAC addresses". If there is no prefix with A set, then there is no prefix to use to generate SLAAC addresses. If there is a prefix with A set, hosts are free to create SLAAC addresses from it to their hearts' content. Or not. I agree that based on Alex's description of the A bit being flipped, it suggests there are no prefixes being advertised with A set -- which means SLAAC is being disabled.

And I'm not going to get started with debating the "M" hint. M's meaning is very clear. Problems arise when people try to attribute or (think they can) demand more meaning than it has. It's a beautiful little bit, and I like it very much. It doesn't deserve to be maligned like this. It has served me very well.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Oct 2019 11:46:33 -0400

On Oct 29, 2019, at 10:42 AM, STARK, BARBARA H <[email-masked]> wrote:
> It's a beautiful little bit, and I like it very much. It doesn't deserve to be maligned like this. It has served me very well.

I just meant that the RFC that described the meaning of the ‘M’ bit explicitly has been deprecated in favor of one that does not.  You’re right about the ‘A’ bit, and I’m sorry for maligning it.  :)

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Oct 2019 17:11:43 +0100

Ted,

> I just meant that the RFC that described the meaning of the ‘M’ bit explicitly has been deprecated in favor of one that does not.  You’re right about the ‘A’ bit, and I’m sorry for maligning it.  :)

Which RFC is that?
As far as I know the M-flag is defined in RFC4861.

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Oct 2019 14:11:39 -0400

> As far as I know the M-flag is defined in RFC4861.

Weird.   You are right.   I don’t know why I’m remembering it this way—I know that there was an issue, but I’m not seeing the problem I remember in the RFC.   The previous version doesn’t mention DHCP specifically, so maybe I’m remembering that version.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 29 Oct 2019 19:32:09 +0100

Le 29/10/2019 à 13:38, Rajiv Asati (rajiva) a écrit :
> 
> Indeed. CPE router should allow keeping both M and A flags, to allow 
> simultaneous usage of DHCPv6 and SLAAC by the hosts.

At high level, it makes sense to require to allow simultaneous DHCP and
SLAAC usage on a same subnet; a private email suggests the same.
With that, Android and Windows would live ok side-by-side on same subnet.

Further, thinking about how to implement the req, one would wonder
whether the prefix in PIO with A flag set in an RA with M set, would be
the same as the prefix used by the DHCP Server to form and deliver
addresses?

(if yes, I think that is difficult to achieve: (1) difficult to put same
prefix in the software implementing RA sending, and in the DHCP server
connfig files and (2) difficult to make sure the Server does not form an
address for a Client, address that a Host has already formed in the same
prefix).

(because of that reason, I think that trying to implement that
requirement would lead to designating a prefix for SLAAC and another
prefix for DHCP; that may sound a little bit as a waste).

Alex

> Cheers, Rajiv
>>  On Oct 29, 2019, at 6:37 AM, Alexandre Petrescu 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>> That’s the problem.   It should turn on the managed bit but not 
>> turn off the autonomous bit.  The two can validly be on at the
>> same time.
>> 
>> Of course, since their meanings are deprecated, it’s not too 
>> surprising that implementations get this wrong.
>>

---

From: Jen Linkova <[email-masked]>
Date: Wed, 30 Oct 2019 13:56:57 +1100

> With that, Android and Windows would live ok side-by-side on same subnet.

I'm still not sure I understand why you need DHCP for Windows...Unless
you got that Windows in an antique shop...;)
I have plenty of Windows machines in the network (in an IPv6-only one as well).

> connfig files

Could you elaborate on this one? How is "putting the prefix in the
software implementing RA sending" different from "configuring a prefix
on a router interface"?
It's like saying 'difficult to configure the same IPv4 or IPv6 prefix
on the router interface and on DHCP server'

>and (2) difficult to make sure the Server does not form an

That's could be done to the some degree of confidence - if the pool is
using the first addresses in the prefix (let's say, the highest 50
bits if the interface ID set to 0) then
it's rather unlikely that such interface ID would be generated by SLAAC.
However that's a good point, thanks for another item in my collection
of 'why I don't need DHCPv6' reasons ;))

> prefix for DHCP; that may sound a little bit as a waste).

I'm sure operating such a network will be...eh...entertaining...

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 30 Oct 2019 03:35:06 +0000

Yes, same prefix can be specified in DHCPv6 server and router RA PIO. If ever a conflict between the IPv6 addresses at a host, then the host could use DAD to resolve the conflict (and recycle the SLAAC derived address). Standard machinery. 

-- 
Cheers,
Rajiv  

-----Original Message-----
From: Alexandre Petrescu <[email-masked]>
Date: Tuesday, October 29, 2019 at 2:32 PM
To: Rajiv Asati <[email-masked]>, Ted Lemon <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] out-of-focus: why DHCPv6 breaks Android computers?

    

    
    
    Alex

---

From: Jen Linkova <[email-masked]>
Date: Wed, 30 Oct 2019 15:26:15 +1100

> Yes, same prefix can be specified in DHCPv6 server and router RA PIO. If ever a conflict between the IPv6 addresses at a host, then the host could use DAD to resolve the conflict (and recycle the S…

Well, I guess the more tricky case is 'a host got an address from
DHCP, DAD is failing because another host already assigned the same IP
(manually or via SLAAC)'. What's next (besides sending DECLINE back to
the server)?
Split-brain condition in address assignments is hard. The more I read
this thread the less I see the point of having DHCPv6 (for address
assignment) when we have SLAAC.

Oh...I think I'm breaking the promise I made to myself ("never get
involved into SLAAC vs DHCP discussion ever') again...;))

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Oct 2019 06:55:21 -0400

On Oct 30, 2019, at 12:26 AM, Jen Linkova <[email-masked]> wrote:
> 
> What's next (besides sending DECLINE back to the server)?

That’s what’s next.  This is exactly the right thing to do.   Having sent the decline, you would then do another solicit, and unless the DHCP server is broken, you’d get a new address.

Isn’t it also the case that there are addresses that will never be generated by SLAAC?   If so, the DHCP server could allocate addresses that fit that profile and we wouldn’t see this issue in the first place.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Oct 2019 16:51:43 +0100

Le 30/10/2019 à 05:26, Jen Linkova a écrit :
>> Yes, same prefix can be specified in DHCPv6 server and router RA
>> PIO. If ever a conflict between the IPv6 addresses at a host, then
>> the host could use DAD to resolve the conflict (and recycle the
>> SLAAC derived address). Standard machinery.
> 
> DHCP, DAD is failing because another host already assigned the same
> IP (manually or via SLAAC)'. What's next (besides sending DECLINE
> back to the server)? Split-brain condition in address assignments is
> hard. The more I read this thread the less I see the point of having
> DHCPv6 (for address assignment) when we have SLAAC.
> 

I dont want to discuss a vs b either.

Alex

> 
> 
>> -----Original Message----- From: Alexandre Petrescu
>> <[email-masked]> Date: Tuesday, October 29, 2019 at
>> 2:32 PM To: Rajiv Asati <[email-masked]>, Ted Lemon
>> <[email-masked]> Cc: "[email-masked]" <[email-masked]> Subject:
>> Re: [v6ops] out-of-focus: why DHCPv6 breaks Android computers?
>> 
>> 
>> 
>>> Indeed. CPE router should allow keeping both M and A flags, to
>>> allow simultaneous usage of DHCPv6 and SLAAC by the hosts.
>> 
>> At high level, it makes sense to require to allow simultaneous DHCP
>> and SLAAC usage on a same subnet; a private email suggests the
>> same. With that, Android and Windows would live ok side-by-side on
>> same subnet.
>> 
>> whether the prefix in PIO with A flag set in an RA with M set,
>> would be the same as the prefix used by the DHCP Server to form and
>> deliver addresses?
>> 
>> (if yes, I think that is difficult to achieve: (1) difficult to put
>> same prefix in the software implementing RA sending, and in the
>> DHCP server connfig files and (2) difficult to make sure the Server
>> does not form an address for a Client, address that a Host has
>> already formed in the same prefix).
>> 
>> requirement would lead to designating a prefix for SLAAC and
>> another prefix for DHCP; that may sound a little bit as a waste).
>> 
>> Alex
>> 
>>> 
>>>>> Well no.  After  activating DHCPv6 on CPE the CPE sent three
>>>>> RAs changing the Lifetime and flipping the M(anaged) and 
>>>>> A(utonomous) flags.
>>>>> 
>>>> That’s the problem.   It should turn on the managed bit but
>>>> not turn off the autonomous bit.  The two can validly be on at
>>>> the same time.
>>>> 
>>>> _______________________________________________ v6ops mailing
>>>> list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Oct 2019 16:53:05 +0100

Le 30/10/2019 à 04:35, Rajiv Asati (rajiva) a écrit :
> 
> Yes, same prefix can be specified in DHCPv6 server and router RA PIO.
> If ever a conflict between the IPv6 addresses at a host, then the
> host could use DAD to resolve the conflict (and recycle the SLAAC
> derived address). Standard machinery.

Why would conflict result into recycling through a SLAAC process and not 
a DHCP exchange.

There's no std machinery for that.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Oct 2019 17:02:44 +0100

Le 30/10/2019 à 03:56, Jen Linkova a écrit :
> I'm still not sure I understand why you need DHCP for
> Windows...Unless you got that Windows in an antique shop...;) I have
> plenty of Windows machines in the network (in an IPv6-only one as
> well).

Well, my Windows is very new from Dell, not from antique.

My Windows is on DHCPv4-only at work.  At home it works ok on DHCPv6 as 
well.  At home it is a mixed IPv4-IPv6.

My Windows could stop doing DHCPv6 if I request it to, but by default it 
does DHCPv6 in addition to SLAAC.

My Windows could run only SLAAC if I asked it to.

My CPE does IPv6 and SLAAC by default, and DHCPv6 is an option off by 
default.

So - do not worry.

>> DHCP server connfig files
> 
> software implementing RA sending" different from "configuring a
> prefix on a router interface"? It's like saying 'difficult to
> configure the same IPv4 or IPv6 prefix on the router interface and on
> DHCP server'

I meant to say : 'to maintain'.  If I change something in the DHCP conf 
files then I have to change the same in the RA conf files, to make sure 
the same prefix is present on both.

But, probably some software packages do that ok.

>> and (2) difficult to make sure the Server does not form an address
>> for a Client, address that a Host has already formed in the same 
>> prefix).
> 
> That's could be done to the some degree of confidence - if the pool
> is using the first addresses in the prefix (let's say, the highest
> 50 bits if the interface ID set to 0) then it's rather unlikely that
> such interface ID would be generated by SLAAC. However that's a good
> point, thanks for another item in my collection of 'why I don't need
> DHCPv6' reasons ;))

:-) that starts to sound like being against x in the a vs b discussion.

> I'm sure operating such a network will be...eh...entertaining...

Sure, however, one might need this behaviour.

I think that I might need the DHCPv6 server on the CPE.  The reason I 
might need it is because I might need a Prefix Delegated from that CPE.

Do you think that would not be a valid need?

(I guess you will invite me to check whether my CPE's DHCPv6 option 
responds to an IA_PD request, thing that I will maybe try one day).

(think that currently a /56 is assigned by ISP to my home network, and 
that last time I checked I had to manually decide on a GUI which /64 out 
of that /56 goes to which IP of which in-home router).

Alex