Subject: Re: [v6ops] Thinking about problems in IPv6-only networks

From: Ole Troan <[email-masked]>
Date: Sun, 2 Sep 2018 19:08:49 +0200

George is making an important point here. 
If nothing else, the IPv6 only flag can be used to trigger IPv6 only testing and compliance. 

Cheers 
Ole

> On 30 Aug 2018, at 00:41, George Michaelson <[email-masked]> wrote:
> 
> despite having stood up at a microphone and accused Brian of
> propagating 'the evil bit' again, I actually think an advisory 'this
> is a v6 only managed network' is a good idea. It would allow people to
> write code which does:
> 
> test if v6only, in getting your v6 bindings:
> 
> On Thu, Aug 30, 2018 at 8:24 AM Brian E Carpenter
> <[email-masked]> wrote:
>> 
>>> On 2018-08-30 08:52, David Farmer wrote:
>>> On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) <[email-masked]>
>>> wrote:
>>> 
>>>>> They control the defaults for how Routers construct Router
>>>> Advertisements.
>>>> 
>>>> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to obtain
>>>> configuration for hosts.
>>> 
>>> 
>>> Only if there is, in fact, a DHCPv6 server and it is configured with
>>> appropriate information.  Maybe you wish to recommend net operators deploy
>>> DHCPv6, but change the default for the O flag in RAs is more that.
>>> 
>>> While I could be sympathetic to recommendations to provide DHCPv6 servers
>>> on networks. However, changing the defaults for the M or O flags is not
>>> something I can support.  If I provide a DHCPv6 server then it is my job to
>>> set the flags appropriately in the RA. If I don't provide a DHCPv6 I should
>>> not have to do anything. This is how the defaults for the M and O flag are
>>> currently set.
>> 
>> Exactly. Working out of the box on an unmanaged network has always been
>> a goal for IPv6, even back when it was called IPng. The defaults are
>> set appropriately for that goal.
>> 
>>    Brian
>> 
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Sep 2018 07:43:22 +1200

Sure. We can add that to the draft.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Sep 2018 21:00:21 +0200

> If nothing else, the IPv6 only flag can be used to trigger IPv6 only testing and compliance. 

In order for that to be possible, shouldn't reaction to the flag need to
be compulsory, rather than simply advisory?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Sep 2018 21:05:19 +0200

On 08/31/2018 03:47 PM, Lee Howard wrote:
> 
> 
> On 08/30/2018 03:26 PM, Mudric, Dusan (Dusan) wrote:
>>> a goal for IPv6,
>> I expected plug-and-play, or unmanaged network, means devices deployed
>> to those networks should work based on the network defaults. If DHCPv6
>> is added to the network, 'O' flag needs to be set. That means managing
>> the network.
> 
> An "unmanaged network" that is "based on the network defaults" sounds
> like it's in conflict with a server being "added to the network."

Agreed.

> The M bit means there are addresses available via DHCPv6. It doesn't
> mean you have to use them.

Well, the bits seems to indicate that that is how you get addresses.
Not using them is kind of the same as not using any information in the RAs.

> The O bit means there is other configuration information available via
> DHCPv6. It is redundant if the M bit is set.
> Neither requires a device to pay attention to them.

This seems more of a flaw thatn a feature to me.

>>>> If I don't provide a DHCPv6 I should
>>>> not have to do anything.
>> Right. If nothing is added to the network, there is no need to change
>> the network configuration. But that is not the point. Plug-and-play is
>> used when something is added to the network. There should not be a
>> need to change 'O' bit when DHCPv6 server and DHCPv6 capable hosts are
>> added to the network. And, if there are no DHCPv6 servers and DHCPv6
>> capable hosts in that network, sending 'O'=TRUE will not impact  the
>> network.
> 
> How does a router (a thing sending RAs) know a DHCPv6 server has been
> added to the network?

Same way as it knows there's no router providing IPv4 service when
setting the "IPv6 only" flag?

> Even if a router is configured as a DHCPv6 relay, how does it know
> whether the M and/or O bits apply? That is, how does it know whether the
> DHCPv6 server is supplying addresses (M bit), or no addresses but
> DNS/NTP/other configuration (O bit)? (If the M bit is set, O is implied,
> per rfc4861).
> 
> You could require DHCPv6 snooping, but it's several layers of logic to
> compare what the client requests vs. what the response is. And to revise
> RAs based on changing DHCPv6 configurations. If the router *is* the
> DHCPv6 server, the logic is much simpler.
> 
> I'm content to say that if you add a server to provide network layer
> information, you are managing the network, and are therefore overriding
> defaults and are expected to manage the network. Essentially, the M bit.

+1

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Sep 2018 07:43:30 +1200

> be compulsory, rather than simply advisory?

There's no such thing as compulsory in the Internet ;-).

It's a SHOULD in the draft**. Any node that emits IPv4 traffic when the bit
is set is either a legacy host or a dual stack host that's not entered
a v6-only mode. So that means it's a host worth checking as part of
the v6-only test.

**"Dual stack hosts that have a good reason to use IPv4, for example for
   a specific IPv4 link-local service, can continue to do so.  This is
   consistent with the SHOULD language in this document."

      Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 3 Sep 2018 22:05:39 +0200

On 09/03/2018 09:43 PM, Brian E Carpenter wrote:
> It's a SHOULD in the draft**.

Ack. FWIW, I have not checked a recent version of the I-D, and was
assuming (based on list discussion) that the requirement level was less
than SHOULD.

> Any node that emits IPv4 traffic when the bit

But... is that IPv6 only? At the end of the day, it would seem that for
most home and enterprise networks, you will always have a reason for
doing some IPv4.. so I wonder when one would see this bit have practical
effect. -- most enterprise and home networks will normally do DNS-SD or
LLMNR, and associated sevices. Also, think about e.g. printers that are
likely going to remain IPv4-only till they eventually beak and get replaced.

Put another way: Is the above "exception" really expected to be an
exception, or actually more like a norm (normal scenario)?

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 4 Sep 2018 14:03:26 +1200

> effect. -- most enterprise and home networks will normally do DNS-SD or

DNS-SD works for IPv6 too afaik

> likely going to remain IPv4-only till they eventually beak and get replaced.

Indeed. This is a long-term play; I would expect that if the IPv6only bit is
approved and deployed, it will become increasingly relevant as the legacy
nodes slowly vanish. And at the end it will become irrelevant again.
 
> exception, or actually more like a norm (normal scenario)?

I think it will be common behaviour in the short term. Certainly my
current home printer requires IPv4, for example.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Mon, 3 Sep 2018 20:03:31 -0700

> On Sep 3, 2018, at 13:05 , Fernando Gont <[email-masked]> wrote:
> 

Why?

I have a few legacy devices that force me back to IPv4 for a few things,
but I presume that they will age out in the next few years.

Other than that, it’s just the hold-out web sites like Amazon that are preventing
me from dropping IPv4 on my home networks altogether. Presumably those
will also fade with time (the sooner the better).

> exception, or actually more like a norm (normal scenario)?

Today, it’s certainly the norm. However, I certainly hope that in a few years
it becomes more exceptional. Certainly over the course of some time period,
it will become progressively more exceptional.

More importantly, I think IETF should be planning for and addressing that which
is within the IETF’s purview towards making that possible, achievable, feasible,
and desirable.

Owen

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 4 Sep 2018 15:28:28 +0000

From: Owen DeLong <[email-masked]>
Sent: Friday, August 31, 2018 11:18 PM
To: Mudric, Dusan (Dusan) <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; David Farmer <[email-masked]>; [email-masked]
Subject: Re: [v6ops] Thinking about problems in IPv6-only networks

On Aug 31, 2018, at 13:21 , Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:

The O flag will cause hosts to seek information from a DHCPv6 server,
hanging (possibly indefinitely) until that information is received. If there is no
DHCPv6 server available to provide that information, you have now broken
the network by changing the O flag without any reason to do so.

Possible but it is not required, by any standard that I know about, that applications should wait indefinitely for DHCPv6 server response.

Whether it’s required or not, it _IS_ the actual implementation in a number of existing systems.

SO… Changing the default value in this way breaks a lot of stuff that already exists. I’m not saying we should never
do that, but there certainly needs to be a compelling reason to do so or we shouldn’t do it.

So far, you have yet to provide anything remotely resembling a compelling reason.
[[Dusan]]

> like it's in conflict with a server being "added to the network."

+

It would be possible for a router manufacturer to obfuscate this by providing a suitable GUI to configure and enable a DHCP server, and as a side effect, turn on the M and/or O bits in the RAs issued by **that router**.

+

> OpenWRT enables both by default, and a host that supports both SLAAC and DHCPv6 e.g. Fedora Linux, will get addresses using both.

[[Dusan]]
I understand the view about adding a server to a network makes the network ‘unmanaged’. However, I don’t agree with the definition. The default server configuration should make the network ‘unmanaged’ and the added server should work in that network. The fact that DHCPv6 server cannot be easily integrated in the network and is out of sync for network changes, should not change the definition for ‘unmanaged’ network. We should rather fix DHCPv6 integration. There are ideas how to make ‘O’ bit automatically set for some routers (please see above). I suppose it can be done for all routers, if DHCPv6 server is better integrated.

In addition, I believe host default should allow the host to work ‘unmanaged’ in any kind of network (have not seen this defined in any RFC; is there RFC that defines this behavior?):

  *   SLAAC only,
  *   DHCPv6 only, or
  *   SLAAC + DHCPv6
That view is shared by Fedora and OpenWRT (see above). If hosts seek stateless DHCPv6 configuration by default, routers should offer it by default (set ‘O’ bit to TRUE).

> Owen

Dusan

-----Original Message-----
From: Owen DeLong <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 30, 2018 8:17 PM
To: Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>>
Cc: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; David Farmer
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Thinking about problems in IPv6-only networks

On Aug 30, 2018, at 12:26, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>>
wrote:

Exactly. Working out of the box on an unmanaged network has always
been

a goal for IPv6,
I expected plug-and-play, or unmanaged network, means devices
deployed to those networks should work based on the network defaults. If
DHCPv6 is added to the network, 'O' flag needs to be set. That means
managing the network.

If I don't provide a DHCPv6 I should
not have to do anything.
Right. If nothing is added to the network, there is no need to change the
network configuration. But that is not the point. Plug-and-play is used when
something is added to the network. There should not be a need to change
'O' bit when DHCPv6 server and DHCPv6 capable hosts are added to the
network. And, if there are no DHCPv6 servers and DHCPv6 capable hosts in
that network, sending 'O'=TRUE will not impact  the network.

You are badly mistaken.

The O flag will cause hosts to seek information from a DHCPv6 server,
hanging (possibly indefinitely) until that information is received. If there is no
DHCPv6 server available to provide that information, you have now broken
the network by changing the O flag without any reason to do so.

Owen

Dusan

-----Original Message-----
From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 29, 2018 6:24 PM
To: David Farmer <[email-masked]<mailto:[email-masked]>>; Mudric, Dusan (Dusan)
<[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] Thinking about problems in IPv6-only networks

On 2018-08-30 08:52, David Farmer wrote:
On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan)
<[email-masked]<mailto:[email-masked]>>

wrote:

And default 'O' flag set to TRUE should enabled stateless DHCPv6 to
obtain

configuration for hosts.

Only if there is, in fact, a DHCPv6 server and it is configured with
appropriate information.  Maybe you wish to recommend net operators
deploy

While I could be sympathetic to recommendations to provide DHCPv6
servers

Exactly. Working out of the box on an unmanaged network has always
been

   Brian
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIFAg&c=BFpWQw8bsuKpl
1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=7MH
tvme6nAWYF4uDMH3gO_auo_qxpA8VsctyigS3New&s=UAR1vCzZ7eYHUKdgl
xensNPphQb9IEool0hz1ozKIFs&e=

---

From: Simon Hobson <[email-masked]>
Date: Tue, 4 Sep 2018 18:28:58 +0100

Mudric, Dusan (Dusan) <[email-masked]> wrote:

Something jumbled up in a hard to decipher manner, it would be a lot easier if you a) quoted properly, and b) trimmed properly. It's just good manners that if you expect people to read what you are saying, then you don't make it hard for them to do so.

> I understand the view about adding a server to a network makes the network ‘unmanaged’.

I assume you meant "managed" there.

> However, I don’t agree with the definition.

Agree or not, it's the position (sort of) that most people are working with, and how things are written in the existing standards. I rather think that the scope for changing that is long gone - unless we want to throw more interoperability spanners in the way of IPv6 adoption.

FWIW, I'm more on the side of DHCP - but I can see the reasons some camps are "somewhat against it" for their usage cases.

> The default server configuration should make the network ‘unmanaged’ and the added server should work in that network. The fact that DHCPv6 server cannot be easily integrated in the network

Why can't it be easily integrated ?
If you have the technical skills to run up a DHCP server then you have the technical skills to set teh relevant bits according to how you want it to be used by clients. If you lack the admin privileges to change those bits, then arguably you should not have privileges to be adding servers that will affect how connected clients will work.

> 	• SLAAC only,
> 	• DHCPv6 only, or
> 	• SLAAC + DHCPv6

Well hosts *should* work in any network - all it needs is for the RAs to correctly describe the network. So, if the RAs say to use stateful DHCP only for addressing, then that's what the hosts should do. So if the network admin correctly configures the router, the hosts should "just work".

> That view is shared by Fedora and OpenWRT (see above). If hosts seek stateless DHCPv6 configuration by default, routers should offer it by default (set ‘O’ bit to TRUE).

It's arguable that a host using DHCP when the RAs say not to is in the wrong.

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 4 Sep 2018 18:34:36 +0000

> It's arguable that a host using DHCP when the RAs say not to is in the wrong.

Agree. But if 'O' bit is not supported on hosts, hosts should have DHCPv6 enabled by default. There are millions of IPv4 phones that use DHCPv4 for autoconfiguration (for phone applications), for example. When they migrate to IPv6, they should get the configuration from DHCPv6 server. DHCPv6 should not be disabled by default when migrating those phone to IPv6. That is why I think 'O' should be TRUE by default, so the phone applications can be automatically configured by DHCPv6 server. By default, phones can use SLAAC to get the addresses.

Dusan

> From: v6ops <[email-masked]> On Behalf Of Simon Hobson
> Sent: Tuesday, September 04, 2018 1:29 PM
> To: [email-masked]
> Something jumbled up in a hard to decipher manner, it would be a lot easier
> if you a) quoted properly, and b) trimmed properly. It's just good manners
> that if you expect people to read what you are saying, then you don't make it
> hard for them to do so.
> 
> 
> Agree or not, it's the position (sort of) that most people are working with,
> and how things are written in the existing standards. I rather think that the
> scope for changing that is long gone - unless we want to throw more
> interoperability spanners in the way of IPv6 adoption.
> 
> FWIW, I'm more on the side of DHCP - but I can see the reasons some camps
> are "somewhat against it" for their usage cases.
> 
> > The default server configuration should make the network ‘unmanaged’
> and the added server should work in that network. The fact that DHCPv6
> server cannot be easily integrated in the network
> 
> If you have the technical skills to run up a DHCP server then you have the
> technical skills to set teh relevant bits according to how you want it to be
> used by clients. If you lack the admin privileges to change those bits, then
> arguably you should not have privileges to be adding servers that will affect
> how connected clients will work.
> 
> > In addition, I believe host default should allow the host to work
> ‘unmanaged’ in any kind of network (have not seen this defined in any RFC;
> is there RFC that defines this behavior?):
> > 	• SLAAC only,
> > 	• DHCPv6 only, or
> > 	• SLAAC + DHCPv6
> 
> Well hosts *should* work in any network - all it needs is for the RAs to
> correctly describe the network. So, if the RAs say to use stateful DHCP only
> for addressing, then that's what the hosts should do. So if the network admin
> correctly configures the router, the hosts should "just work".
> 
> > That view is shared by Fedora and OpenWRT (see above). If hosts seek
> stateless DHCPv6 configuration by default, routers should offer it by default
> (set ‘O’ bit to TRUE).
> 
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=1Z0
> uTZ_VUO5UxXX1Aor97EoR6f2uP1cUXuPX9z0I-
> xQ&s=pbh8KLTb8zbfCD196WuW8FYQ-jO6KJytRoLzONXd7Ew&e=

---

From: Owen DeLong <[email-masked]>
Date: Tue, 4 Sep 2018 11:38:46 -0700

> On Aug 31, 2018, at 13:21 , Mudric, Dusan (Dusan) <[email-masked] <mailto:[email-masked]>> wrote:
>  

There’s nothing in the RFCs today which prohibits or prevents this. A router manufacturer who wants to do make this kind of integrated service configuration automatic is completely free to do so now.

That’s not what you proposed, however.

What you proposed was making the O=1 bit default across the board. That’s an absurd proposal that will only cause grief and has no benefit.

> SLAAC only,
> DHCPv6 only, or
> SLAAC + DHCPv6

Let’s move away from using the word Managed due to the obvious ambiguity now present in how different people in this conversation are using the term.

Instead, let’s talk about Default, and non-Default meanings and configurations, in terms of how bits are configured in RAs.

The following assumptions are inherent in any rational default definition:

	1.	Absent configuration by the administrator, the router does not know whether or not an external
		DHCPv6 server is present on the network. The only safe assumptions are:
		A.	An external DHCPv6 server may not be present. Absent administrator configuration
			otherwise, RAs emitted by the router should be M=0, O=0.
		B.	An external DHCPv6 server may be present. Absent administrator configuration
			otherwise, the router should not act as a DHCPv6 server.

	2.	If the network administrator chooses to deploy a DHCPv6 server, said administrator can
		reasonably be expected to also configure the router accordingly, setting the intended
		values for M (M=1 if IA_NA is the preferred and expected method of address distribution)
		and O (O=1 if DHCPv6 server is present and able to provide additional configuration
		information about the network environment and the administrator wants clients to obtain
		this information from said server).

Nothing in these assumptions supports your desired change, but neither does it preclude your desired
router manufacturer behavior.

If a router manufacturer wants to build a router which, when DHCPv6 server is turned on for a given link will also enable M and/or O bits in RAs on that interface, then said manufacturer is free to do so. This is no longer a default configuration, it’s just multiple items being changed away from default as a result of a  single user action. Absolutely permissible.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 4 Sep 2018 11:43:00 -0700

> On Sep 4, 2018, at 11:34 AM, Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 

???

DHCPv6 is OPTIONAL.

If you want to change that, go for it, but this isn’t the working group for that discussion. It’s not an operational matter, it’s a
protocol design issue. That debate has been had multiple times in multiple working groups and the consensus remains that
ND is mandatory and DHCPv6 is optional in terms of stack implementation.

There is not a question of cell phones that support DHCPv6 but ignore the O bit in RAs. It’s more a matter of cellphones (specifically Android in particular) which have no DHCPv6 code in the operating system in the phone at all.

It does not make sense to “enable DHCPv6” by default, since it’s not even necessarily implemented in the protocol stack.

Owen

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 4 Sep 2018 20:34:52 +0000

> Agree. But if 'O' bit is not supported on hosts, hosts should have DHCPv6
> enabled by default. There are millions of IPv4 phones that use DHCPv4 for
> autoconfiguration (for phone applications), for example. When they migrate
> to IPv6, they should get the configuration from DHCPv6 server. DHCPv6
> should not be disabled by default when migrating those phone to IPv6. That
> is why I think 'O' should be TRUE by default, so the phone applications can be
> automatically configured by DHCPv6 server. By default, phones can use
> SLAAC to get the addresses.

Hi Dusan,

There are millions of hosts with no DHCPv6 support. This is the case and will continue to be the case. Hosts that do not support DHCPv6 client will *never* have DHCPv6 enabled by default, or otherwise. Networks that are primarily intended for these sorts of devices will rarely (if ever) have DHCPv6 enabled.

As for the millions of IPv4 phones -- these millions of phones are not connecting directly to DSL/DOCSIS/PON/3GPP access networks. They are not connecting to (unmanaged) home networks and getting configuration by DHCPv4. They are not connecting directly to data center networks. They're definitely not connecting directly to core network routers. They *are* connecting to enterprise networks. Suggesting that all routers, in every use case and every scenario, must always support DHCPv6 server and provide stateless configuration, just because there exist some devices in specific use cases that require configuration info from DHCP, isn't reasonable.

If you want this specifically for enterprise routers, then perhaps you should be commenting on draft-ietf-v6ops-ipv6rtr-reqs. Note that this draft does require DHCPv6 support (Section 3.3, first bullet) for the routers it describes (see Section 1.3 on Use and Applicability).
Barbara

I

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 4 Sep 2018 20:56:33 +0000

Hi Owen,

> ND is mandatory and DHCPv6 is optional in terms of stack implementation.

Agree but nothing is perfect:
https://tools.ietf.org/html/rfc4862#section-5.5 
"the processing described below MUST be
   enabled by default."

This does not guarantee that a prefix will be assigned to the hosts (e.g. phones) and that they will have global SLAAC addresses. If a global SLAAC address is not created (e.g. no 'A' enabled prefix is assigned), DHCPv6 can help. Assuming DHCPv6 server is present, if the default network allows 'M'=TRUE, and hosts support DHCPv6 and 'M' bit, the hosts can assign DHCPv6 address automatically and hosts would have DHCPv6 and no SLAAC addresses. And, hosts can get other configuration from DHCPv6 server. If DHCPv6 server is not present, hosts should not choke on it. 

With 'O' (even 'M') bit set, the default network is DHCPv6 inclusive. If it is known that the network will not support DHCPv6, 'O' can be set to FALSE, to disable stateless DHCPv6 on clients that run it by default.

I am inclined to 'inclusive' networks. Since we are talking about one bit, and it is not that hard to change the default, I will stop here.

Thanks for sharing your views,
Dusan.

> Sent: Tuesday, September 04, 2018 2:43 PM
> Cc: Simon Hobson <[email-masked]>; [email-masked]
> If you want to change that, go for it, but this isn’t the working group for that
> discussion. It’s not an operational matter, it’s a
> protocol design issue. That debate has been had multiple times in multiple
> working groups and the consensus remains that
> There is not a question of cell phones that support DHCPv6 but ignore the O
> bit in RAs. It’s more a matter of cellphones (specifically Android in particular)
> which have no DHCPv6 code in the operating system in the phone at all.
> 
> It does not make sense to “enable DHCPv6” by default, since it’s not even
> necessarily implemented in the protocol stack.
> 
> Owen
> 
> >
> > Dusan
> >
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIFaQ&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=SHp
> hJ8IPsAqBlbZ3-BeE9h7yW_q_AyoTiNNyO_E2qTs&s=0nq3NL5JHQkDV3w81y-
> GXwj_mxvIchShUiJTyQno1Us&e=

---

From: Owen DeLong <[email-masked]>
Date: Tue, 4 Sep 2018 18:01:07 -0700

> On Sep 4, 2018, at 13:56 , Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 
> Hi Owen,
> 
> https://tools.ietf.org/html/rfc4862#section-5.5 <https://tools.ietf.org/html/rfc4862#section-5.5> 

If there is no A enabled prefix in the RA, there are two possibilities:

	1.	The network administrator does not want devices to get addresses via SLAAC.
	2.	The network administrator has failed to configure his router correctly to achieve his desired result.

In either case, it is _NOT_ appropriate to demand that the phone or any other device make incorrect or different assumptions
about the intent of the network administrator. These problems are easily detected and easily corrected by the network
administrator and that is the correct behavior under this circumstance.

If you default to M=TRUE, then on every network that has NO DHCPv6 server, you just broke a LOT of things.

There’s NO valid reason and NO benefit to making M=1 default.
 
> With 'O' (even 'M') bit set, the default network is DHCPv6 inclusive. If it is known that the network will not support DHCPv6, 'O' can be set to FALSE, to disable stateless DHCPv6 on clients that r…

How is that an improvement over the current situation where I can literally reverse all of your statements and be in a good place…

“With O=0 and M=0 as default, the network is SLAAC enabled. If it is known that the network will support DHCPv6, ‘O’ can be set to TRUE to enable stateless DHCPv6 or ‘M’ can be set to TRUE to enable stateful DHCPv6 on clients that are DHCPv6 capable.”

Since clients are required to be SLAAC capable and support for DHCPv6 on the client side is OPTIONAL, this is the more rational default.

> I am inclined to 'inclusive' networks. Since we are talking about one bit, and it is not that hard to change the default, I will stop here.

Every router that has any reasonable support for IPv6 has a convenient way to turn on O and/or M bits as needed for a network which includes a DHCPv6 server. There’s no rationale here for changing the default. As pointed out repeatedly before, changing this default would break multiple existing implementations. You can say “hosts should not choke on M=1 with no DHCPv6 server” all you want, but the reality is that legitimate and valid interpretations of the existing RFCs and multiple existing implementations already do exactly that… Choke if M=1 and DHCPv6 server is not present. Certainly there is a valid argument that making DHCPv6 host participation mandatory (M=1) in a network with no DHCPv6 services is a misconfiguration.

Misconfiguration as a default setting seems ill-advised at best.

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Sep 2018 13:13:00 +0200

Hi,

On Tue, Sep 04, 2018 at 08:56:33PM +0000, Mudric, Dusan (Dusan) wrote:
> I will stop here.

Thank you.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Sep 2018 06:11:47 -0300

Hello, Brian,

On 09/04/2018 04:03 AM, Brian E Carpenter wrote:
[...]
> DNS-SD works for IPv6 too afaik

Appolgies if my comment was misleading/sloppy -- I meant, in general:
they do deal with devices that are IPv4-only.

> nodes slowly vanish. And at the end it will become irrelevant again.

Apologies if this has already been discussed, and I just missed it:

I envision two alternatives:

1) "the network/router knows better", and then reaction to the IPv6-only
flag is more of a MUST (well, could be a "SHOULD", but certainly not
with a clause that is expected to be common.. otherwise it's not an
"exception", but rather a rule :-) ). That way, the flag could
indeed disable IPv4 on the network.

2) "end hosts know better", and reaction to the flag becomes kind of a
"MAY". And I'm not sure to what extent the flag will have much of a
practical effect on networks. -- particularly when the hosts don't
really "know better" -- the best they can do is "keep trying"... whether
for actually getting an IPv4 address and/or for things like DNS-SD.

Thanks!

Cheers,