Subject: Adoption call for <draft-hinden-ipv4flag-03>

From: Ole Troan <[email-masked]>
Date: Thu, 22 Mar 2018 16:47:49 +0000

This message starts a two week 6MAN call on adopting:

    Title     : IPv6 Router Advertisement IPv4 Unavailable Flag
    Authors   : R. Hinden, B. Carpenter
    Filename  : draft-hinden-ipv4flag-03
    Pages     : 9
    Date      : 2018-03-02

    https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/

as a working group item. Substantive comments and statements of support
for adopting this document should be directed to the mailing
list. Editorial suggestions can be sent to the authors.  This adoption
call will end on April 5th, 2018.

See also the gap analysis from sunset4 on disabling IPv4:
https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-3

Regards,

Ole Trøan

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Mar 2018 16:57:00 +0000

On Thu, Mar 22, 2018 at 4:47 PM, Ole Troan <[email-masked]> wrote:

> Substantive comments and statements of support
> list.

I support adopting this document. However, I think we may have to make it
less prescriptive than it is now if we are to gain consensus on it.

---

From: Rob Evans <[email-masked]>
Date: Thu, 22 Mar 2018 17:15:23 +0000

> for adopting this document should be directed to the mailing

I think this is a document worth adopting.  It might be worth
including a short paragraph about where it might be most useful (i.e.
managed networks).

Cheers,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Mar 2018 17:33:20 +0000

>     Title : IPv6 Router Advertisement IPv4 Unavailable Flag Authors :
    > R. Hinden, B. Carpenter Filename : draft-hinden-ipv4flag-03 Pages : 9
    > Date : 2018-03-02

    > call will end on April 5th, 2018.

I have read the previous iterations of the document, and read the -03
document.  I agree that we should adopt it.

(The document seems completely done, btw)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 22 Mar 2018 18:35:48 +0100 (CET)

>    https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/

I support adoption of this draft.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Mar 2018 17:37:02 +0000

I would love to hear from host implementers. If they would implement support for this flag.

Best regards,
Ole

> On 22 Mar 2018, at 16:47, Ole Troan <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: David Schinazi <[email-masked]>
Date: Thu, 22 Mar 2018 18:00:14 +0000

I do not support adoption of draft-hinden-ipv4flag as it currently stands.
It's still unclear to me what actual problems this draft is trying to solve, and that an RA flag is the right solution.
For example, perhaps deprecating RFC 3927 is another way to solve some of the problems described in the introduction.

Thanks,
David Schinazi

> On Mar 22, 2018, at 17:37, Ole Troan <[email-masked]> wrote:
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 22 Mar 2018 11:13:00 -0700

Well, IPv4 link-local is not, to my knowledge, mandatory to implement.

So, you could just decide to turn it off in your OS.  :-)

FWIW, Android effectively removed support for it in M (IIRC).
According to [1] that means ~>50% of devices.

IMHO, IPv6 link-local is a better way to go for link-local
communications anyway.

-ek

[1] https://developer.android.com/about/dashboards/index.html

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 22 Mar 2018 20:25:52 +0100

-- 

Roger Jorgensen
[email-masked] / [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Mar 2018 08:43:55 +1300

> For example, perhaps deprecating RFC 3927 is another way to solve some of the problems described in the introduction.

But we aren't actually trying to forbid link-local IPv4 if it is useful. On the
contrary, link-local IPv4 can work nicely in the absence of routeable IPv4.
(Exactly the same is true of IPv6, of course.)

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 22 Mar 2018 22:09:00 +0000

> On Mar 22, 2018, at 7:43 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Right.  The draft is not trying to turn off IPv4 everywhere.  It is a tool for sites where the administrator wants to run IPv6 only, and then tell the hosts to not use IPv4.  If it is helpful, we could say this in the draft.

Bob

---

From: Andy Smith <[email-masked]>
Date: Thu, 22 Mar 2018 17:28:49 -0500

I support this draft.

This proposal is a hint to IPv6 systems that IPv4 isn’t routable via this particular gateway.   

It is not necessarily a tool to extinguish IPv4 on a network — to do that, as was pointed out in the meeting, would require ether type filters on the directly attached network ports and/or AP’s.

-Andy

> On Mar 22, 2018, at 11:47 AM, Ole Troan <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 23 Mar 2018 08:25:38 +0000

Hi,

Regards,
Mark.

---

From: David Schinazi <[email-masked]>
Date: Fri, 23 Mar 2018 09:59:28 +0000

> On Mar 22, 2018, at 22:09, Bob Hinden <[email-masked]> wrote:
> 

It looks like I'm confused. When a host sees the IPv4 Unavailable Flag, what should it do with regard to IPv4 link-local?
The document states hosts "may choose to form an IPv4 link-local address", but if they do that I don't see how this bit helps with the problems described in the introduction.

David

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 23 Mar 2018 10:13:34 +0000

On Fri, Mar 23, 2018 at 9:59 AM, David Schinazi <[email-masked]> wrote:

> > Right.  The draft is not trying to turn off IPv4 everywhere.  It is a
> tool for sites where the administrator wants to run IPv6 only, and then
> tell the hosts to not use IPv4.  If it is helpful, we could say this in the
> draft.
>
> It looks like I'm confused. When a host sees the IPv4 Unavailable Flag,
> what should it do with regard to IPv4 link-local?
> The document states hosts "may choose to form an IPv4 link-local address",
> but if they do that I don't see how this bit helps with the problems
> described in the introduction.
>

One thing the host could do is disable the DHCPv4 client or make its
maximum backoff time to much higher than it is by default.

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Mar 2018 10:14:14 +0000

[Now with participant hat on]

Before adopting this document I would really like to be convinced that it adds "value".

- Do we understand the size of the problem?
  How much unnecessary traffic is there and for how long after the node has connected to a link?
  Is this the same problem on IPv4 only versus IPv6 only links?
  Given that this will not solve the problem with legacy hosts, what are the expected gain?
- Has solutions optimising only the host behaviour without relying on the network been investigated?
  (The document asserts that a network notification is more precise, but I would like to see that documented).

- This doesn't specify host behaviour, doesn't that lead to what would effectively be interoperability problems?
  E.g. some implementations support IPv4 link-locals, some implementations not.
  I presume the advice here is to the operator is. Thought shalt not enable this flag if there are IPv4 only devices on the link.

As a general comment on the draft itself, I still think it is wrong to make the flag say something about the "IPv4 service" for the advertising router. A host does typically not correlate an IPv6 router and an IPv4 router on a link. The two protocols are running as ships in the night. The correct approach here would be that the flag states that IPv4 is not enabled on the link. Similarly to other link properties like MTU.

Ole

---

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Mar 2018 10:19:28 +0000

David,

> On Mar 23, 2018, at 9:59 AM, David Schinazi <[email-masked]> wrote:
> 
> 

I think this is an area in the draft that could use some work and should be refined if this becomes a w.g. draft.

The intent is to not be too prescriptive regarding hosts.  The draft currently says:

   A host that receives only RAs with the flag set to 1 may choose not
   to form an IPv4 link-local address.  However, as noted above, if it
   contains link-local applications that can use IPv4, it may instead
   choose to form an IPv4 link-local address in the normal way
   [RFC3927], and then send the discovery traffic for such applications.

The intent is that the host will not form an IPv4 link-local unless it has a good reason to do so.  In essence it is a SHOULD NOT form link-locals.  Most hosts will not form IPv4 link locals, unless they have a specific reason to form them.

Does that help?

Bob

---

From: David Schinazi <[email-masked]>
Date: Fri, 23 Mar 2018 10:29:57 +0000

> On Mar 23, 2018, at 10:19, Bob Hinden <[email-masked]> wrote:
> 

Can you define "a good reason" to form IPv4 link-local addresses?
The main use case for IPv4 link-local on our platforms is to allow service discovery and connectivity (e.g. finding and talking to your printer) if DHCPv4 is down and the printer doesn't support IPv6. By definition, you do not know if such a printer exists on this network until you try to discover it. So from a host implementation perspective we always have that reason to try.

David

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Mar 2018 10:38:51 +0000

David,

> The main use case for IPv4 link-local on our platforms is to allow service discovery and connectivity (e.g. finding and talking to your printer) if DHCPv4 is down and the printer doesn't support IP…

I think how this would have to work would be that the presence of the flag indicates that the administrator "guarantees" that there are no IPv4 only devices on the link. The must mean "host MUST NOT enable IPv4", otherwise I don't see what value it adds. Any host already knows that the link may have IPv6 or it may support IPv4 or it may support both. Of course the prescriptive behaviour has another set of issues I'm sure.

Cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Mar 2018 11:42:35 +0000

> I would love to hear from host implementers. If they would implement

To extend who you might ask, as not doing DHCPv4 is part of the goal,
asking DHCP client implementors could be asked this question. On Linux,
NetworkManager people for instance.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Mar 2018 11:53:08 +0000

Brian E Carpenter <[email-masked]> wrote:
    >> I do not support adoption of draft-hinden-ipv4flag as it currently
    >> stands.  It's still unclear to me what actual problems this draft is
    >> trying to solve, and that an RA flag is the right solution.  For
    >> example, perhaps deprecating RFC 3927 is another way to solve some of
    >> the problems described in the introduction.

    > But we aren't actually trying to forbid link-local IPv4 if it is
    > useful. On the contrary, link-local IPv4 can work nicely in the absence
    > of routeable IPv4.  (Exactly the same is true of IPv6, of course.)

LL-v6 is better for battery life than LL-v4 because it uses directed
multicast for ND rather than broadcast.

---

From: Peter Hessler <[email-masked]>
Date: Fri, 23 Mar 2018 12:57:22 +0100

I would be involved with an implementation for OpenBSD.

Based on my understanding of the point of this draft:
If all RA's set the flag (and we have not yet received an DHCPACK on that
link) we would probably want to turn off dhcpv4 on the interface, not
enable any IPv4 link-local IP, and set sole control over resolv.conf to
slaacd.  If any RA sets the flag to 0, or if we have already received an
DHCPACK, then we would continue to use the link for IPv6 and IPv4 as
normal.

Because we also have a native RA daemon, we would set this option to zero
by default, and include a description in the documenation that an
administrator should not set this if there is IPv4 available on the
link.

If disabling IPv4 on that link isn't the intention of this draft, I don't
see why we would bother.

-peter

On 2018 Mar 22 (Thu) at 17:37:02 +0000 (+0000), Ole Troan wrote:
:I would love to hear from host implementers. If they would implement support for this flag.
:
:Best regards,
:Ole
:
:> On 22 Mar 2018, at 16:47, Ole Troan <[email-masked]> wrote:
:> 
:> This message starts a two week 6MAN call on adopting:
:> 
:>     Title     : IPv6 Router Advertisement IPv4 Unavailable Flag
:>     Authors   : R. Hinden, B. Carpenter
:>     Filename  : draft-hinden-ipv4flag-03
:>     Pages     : 9
:>     Date      : 2018-03-02
:> 
:>     https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
:> 
:> as a working group item. Substantive comments and statements of support
:> for adopting this document should be directed to the mailing
:> list. Editorial suggestions can be sent to the authors.  This adoption
:> call will end on April 5th, 2018.
:> 
:> See also the gap analysis from sunset4 on disabling IPv4:
:> https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-3
:> 
:> Regards,
:> 
:> Ole Trøan
:> --------------------------------------------------------------------
:> IETF IPv6 working group mailing list
:> [email-masked]
:> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
:> --------------------------------------------------------------------

-- 
Very few profundities can be expressed in less than 80 characters.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 23 Mar 2018 16:33:59 +0100 (CET)

> multicast for ND rather than broadcast.

You're referring to DMS on Wifi? 802.11v? Is this actually widely 
deployed?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Mar 2018 08:06:57 +1300

> Can you define "a good reason" to form IPv4 link-local addresses?

No. That's a pragmatic decision that depends on the deployment scenario and what
the host wants to do. I think it would be a mistake to even try to define "a good
reason". We're talking about unkown future devices in unknown future scenarios.

> The main use case for IPv4 link-local on our platforms is to allow service discovery and connectivity (e.g. finding and talking to your printer) if DHCPv4 is down and the printer doesn't support IP…

If your scenario happens to be one where printing might be useful and you haven't
found an IPv6 printer after N seconds, try IPv4. If that's not your scenario,
don't. That's why it's currently a lower case "may". (Changing it to SHOULD NOT
is fine, but it really means the same thing.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Mar 2018 08:09:53 +1300

> If disabling IPv4 on that link isn't the intention of this draft, I don't

I'd say the intention is to avoid *pointless* IPv4 traffic and its wastage
of air time and battery power, but without preventing useful IPv4 traffic.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Mar 2018 19:15:54 +0000

> You're referring to DMS on Wifi? 802.11v? Is this actually widely deployed?

I wrote directed multicast, but sorry, I meant to say solicited-node multicast.
Since that results in a hash of destination address to L2 address, you don't
wake as many nodes up as IPv4 does with broadcast.

(Absent L2 hacks in Access Points to try to cache/avert ARP taking over the
wifi)

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Mar 2018 08:28:01 +1300

Hi Ole,
>   How much unnecessary traffic is there and for how long after the node has connected to a link?

Well, we had observational data from the v6 only experiment in Singapore,
which is available somewhere. But I'm not sure the IETF population is typical.
However, the argument is that on a wireless network with mainly battery powered
devices, getting rid of even a few percent of the traffic, especially L2 broadcast
traffic, is very desirable.

>   Is this the same problem on IPv4 only versus IPv6 only links?

Probably not; I think the issue is asymmetric between v4 and v6.

>   Given that this will not solve the problem with legacy hosts, what are the expected gain?

As above: any reduction in traffic helps battery life.

>   (The document asserts that a network notification is more precise, but I would like to see that documented).

It gives the hosts more of a hint than the simple absence of v4 responses. I have no
idea how to quantify that.
 
>   I presume the advice here is to the operator is. Thought shalt not enable this flag if there are IPv4 only devices on the link.

Why? Those devices will behave exactly the same either way. All you are signalling,
to those who listen, is "I don't route IPv4 or answer DHCPv4."

> 
> As a general comment on the draft itself, I still think it is wrong to make the flag say something about the "IPv4 service" for the advertising router. A host does typically not correlate an IPv6 router and an IPv4 router on a link. The two protocols are running as ships in the night.

In fact that's exactly why the flag is defined as it is, and why the host
behaviour is defined the way it is. It is a slightly strange inversion of the
normal thinking.

> The correct approach here would be that the flag states that IPv4 is not enabled on the link. Similarly to other link properties like MTU.

That only works on a 100% managed network. The way we have it, where
routers only announce their own capability, is fail-safe on a network
with more casual management.

Regards
    Brian

---

From: Ole Troan <[email-masked]>
Date: Sat, 24 Mar 2018 00:43:49 +0100

Hi Brian,

> traffic, is very desirable.

For large scale wireless you need to use various techniques to limit that anyway.
Just IPv6 only would be too noisy. Be it filtering, L2/L3 mapping state in APs/WLCs, L3 unicast to L2 unicast etc.
(Or just don't build large wireless L2s).

It would be valuable to have numbers. And how much better if any a flag would perform than just the above mechanisms.
I am concerned though that since you argue that it is just a hint, instead of a "IPv4 is disabled on this link flag. Host behaviour is going to be hard to predict.  I'm leaning towards disagreeing with that use of the flag, more on that below.

[...]

> idea how to quantify that.

Right.

> to those who listen, is "I don't route IPv4 or answer DHCPv4."

Yes, I have increasing doubts about it's value.
And the "I" logic isn't logical. A link has 2 routers. An IPv4 router and an IPv6 router.
The host sees these as two completely independent routers, even if they were implemented in the same box.
Given that this flag is administratively configured, I see no purpose in the flag stating something about "this" router.

> with more casual management.

No.
The flag is administratively configured. That the flag is defined to say something about the link property does not mean that two routers on the link cannot disagree on that link property. That is then a misconfiguration, and the hosts can behave as you describe in the document.

Perhaps the mechanism could have more value if:
1) It specified if IPv4 was supported or not on the _link_
2) It was not a hint so that host behaviour could be defined

The people who have voiced their support, how do they see this working?

Cheers,
Ole

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 23 Mar 2018 23:50:23 +0000

> traffic, is very desirable.

The best performance improvements you can get are usually not from 
optimizations but from the work you don’t have to do.

While everyone thinks of wifi and batteries today, stop thinking this 
way.  Every switch, every router, every host, every device, every 
topology, every (I’ll stop here) .. will benefit.  Stop thinking about 
yesterday’s problems finding tomorrow’s solutions.  Safe the 
pigeons!  Safe the horses in front of the stagecoach!  Safe the 
letterman!  Safe your cooling system!  Safe the planet!  Stop thinking 
your wireless is off worse than your wired than your kid’s tin can 
telephone!

The problem is there is unneeded noise, noise that costs you; packet 
memory for buffers, latency, debugging overhead, battery life, extra 
cables, extra frequencies, more gear, 300.000 lines of code ready and 
available and attackable when they could just not be there, crappy 
eyeballs handling, ..

And at what cost?  1 single bit consistently set by netadmins and about 
10 lines of logic on a client to decide whether or not IPv4 is a thing 
to do or maybe not while on this link.

Ever wondered why OSX has a networksetup -setv4off <networkservice>?  
Windows has a netsh ..   It’s all there waiting for someone to call 
it.  All that’s missing is your fingers on a keyboard (you can use the 
GUI clicky thing as well) or 1 bit and 10 lines of logic to glue it 
together automagically so you don’t have to anymore.   Your choice!

Long live AppleTalk (oh wait).  Long live IPX (hmm).  Long live IPv4 
(did the penny drop yet?)

/bz

---

From: Lee Howard <[email-masked]>
Date: Sat, 24 Mar 2018 09:48:05 +0000

> Given that this flag is administratively configured, I see no purpose in the flag stating something about "this" router.
I started to agree with this: how would a host know that an IPv6 router 
was the same device as the Ipv4 router? And then I had an existential 
moment, "Who do I know that you're the router that isn't there?"

Well, if a host catalogs all of the RIOs is recevies and they all say 
"no IPv4 here" and nothing responds to DHCP (v4), then there's a sound 
inference to be made.
Maybe you'd configure link-local and send a broadcast ping to see if 
there's anything on link-local. Of course, then you have the problem 
that although nothing needs IPv4, nothing turns it off until everything 
else has.

> The people who have voiced their support, how do they see this working?

If possible, I would like to protect administrators from themselves.
But I described above what I think happens:
If everyone announcing a capability says "no IPv4 here" and nobody 
responds to the question "any IPv4 here?" then there's no IPv4 there.

Lee

---

From: Bob Hinden <[email-masked]>
Date: Sat, 24 Mar 2018 11:14:46 +0000

Lee,

> On Mar 24, 2018, at 9:48 AM, Lee Howard <[email-masked]> wrote:
> 
> 
> 
> I started to agree with this: how would a host know that an IPv6 router was the same device as the Ipv4 router? And then I had an existential moment, "Who do I know that you're the router that isn't there?"
> 
> Well, if a host catalogs all of the RIOs is recevies and they all say "no IPv4 here" and nothing responds to DHCP (v4), then there's a sound inference to be made.
> Maybe you'd configure link-local and send a broadcast ping to see if there's anything on link-local. Of course, then you have the problem that although nothing needs IPv4, nothing turns it off until everything else has.
> 
> If everyone announcing a capability says "no IPv4 here" and nobody responds to the question "any IPv4 here?" then there's no IPv4 there.

My thinking on this is that it’s administrative tool to inform the hosts.  It’s important to protect against misconfiguration (that why all RAs received need to have it set for the hosts to act on it), but I think it’s reasonable for the hosts to act on it.  The intent is that it would be enabled if the administrator doesn’t want IPv4 to be used and by inference all services are available via IPv6.

I think we need to figure out how authoritative the draft should specify this action.  I don’t think there is agreement on this yet, even among the authors :-)   That’s work to do if it becomes a w.g. draft.

Bob

>> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>>

---

From: Jared Mauch <[email-masked]>
Date: Sat, 24 Mar 2018 07:43:25 -0400

> The main use case for IPv4 link-local on our platforms is to allow service discovery and connectivity (e.g. finding and talking to your printer) if DHCPv4 is down and the printer doesn't support IP…

	This alone seems like enough of a reason to not adopt this draft
as a WG item.

	- jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Mar 2018 08:33:03 +1300

> 	This alone seems like enough of a reason to not adopt this draft

Did you read the text about host behaviour? The advice (not requirement) is that a host, if it has reason to try IPv4 services, reduces the frequency of polling for those services. If they exist on the link, it will find them. If they don't exist, it will waste less resource looking for them.

The question isn't whether this would work, which it clearly would. The question is whether this hint will save enough resource (air time and battery) to be worth the cost of implementation.

   Brian

---

From: Simon Hobson <[email-masked]>
Date: Sat, 24 Mar 2018 20:01:10 +0000

Bjoern A. Zeeb <[email-masked]> wrote:

> And at what cost?  1 single bit consistently set by netadmins and about 10 lines of logic on a client to decide whether or not IPv4 is a thing to do or maybe not while on this link.

Is it really that simple, I don't think that as proposed it really is that simple. Simply because it's not as simple as "all RAs have this bit set, disable IPv4 on this link" - it's as complicated as "all RAs have this bit set, so lets make a load of undefined changes in IPv4 behaviour"

> ...
> All that’s missing is your fingers on a keyboard (you can use the GUI clicky thing as well) or 1 bit and 10 lines of logic to glue it together automagically so you don’t have to anymore.

But that doesn't do what this proposal does.
IMO there is little saving unless it really is as simple as "all RAs say there's no IPv4, disable IPv4" - then the devices simply have to set IPv4 off and there's an immediate saving. If the admin sets this flag in all the routers while there are still IPv4 only devices/services running then that's their misconfiguration - much like turning off DNS or DHCP

> Did you read the text about host behaviour? The advice (not requirement) is that a host, if it has reason to try IPv4 services, reduces the frequency of polling for those services. If they exist on…

So in reality, all this flag says is "IPv4 may or may not be available/usable, but you'll still have to figure that out for yourself"

> The question isn't whether this would work, which it clearly would. The question is whether this hint will save enough resource (air time and battery) to be worth the cost of implementation.

More code to have bugs or unintended consequences for an unquantified saving.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Mar 2018 22:37:52 +0000

>> The main use case for IPv4 link-local on our platforms is to allow
    >>service discovery and connectivity (e.g. finding and talking to your
    >>printer) if DHCPv4 is down and the printer doesn't support IPv6. By
    >>definition, you do not know if such a printer exists on this network
    >>until you try to discover it. So from a host implementation perspective
    >>we always have that reason to try. 

    > is fine, but it really means the same thing.)

No, if the admin set the no-IPv4 flag and they forgot about the IPv6-less
printer, then they made a mistake, and they aren't ready to set that flag.

A clueful user can force IPv4 on again anyway.
A clueless user should call someone to complain.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Mar 2018 22:42:20 +0000

> Probably not; I think the issue is asymmetric between v4 and v6.

Also, should we consider standardizing a way to turn off IPv6, for a future
world when we need to turn it off for IPvN+1?
I think we can do it with an appropriate RA, but I'm not sure that we have
the how in a single place.

(The argument about using IPvN+1 to turn off version N, is, however valid)

---

From: Ole Troan <[email-masked]>
Date: Sun, 25 Mar 2018 09:35:30 +0200

Hi Bob,

[...]

> I think we need to figure out how authoritative the draft should specify this action.  I don’t think there is agreement on this yet, even among the authors :-)   That’s work to do if it becomes a w…

But I think that choice is important.

Is it:
"The flag indicates that hosts can disable all IPv4 processing on interface and if anything goes wrong it's on the administrators shoulders"

or

"The flag is a hint that the host may or may not find any IPv4 on the link and it has to figure that out itself, and if anything goes wrong the blame is squarely put on the host implementation".

I think I need to know which one of these it is before I can decide if I support the draft or not.

Best regards,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Sun, 25 Mar 2018 08:46:52 +0100

Ole,

> On Mar 25, 2018, at 8:35 AM, Ole Troan <[email-masked]> wrote:
> 
> Hi Bob,
> 
> [...]
> 

I agree this is an open issue, but I think that can be worked out after the draft is adopted.  This is, of course, only an adoption call, if it is adopted the draft will it reflect what the w.g. wants to do.

I lean toward it’s an administrative choice and should be used appropriately when an administrator wants the link to be IPv6 only.  Host behavior is best described as a SHOULD, that is do this unless you have good reason to do otherwise.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Mar 2018 08:14:11 +1300

> I lean toward it’s an administrative choice and should be used appropriately when an administrator wants the link to be IPv6 only.  Host behavior is best described as a SHOULD, that is do this unle…

Yes, I could agree to a SHOULD but in my mind it's more of a SHOULD-, because
I'm sure there will be hosts for which the best default behaviour is to use the
flag to reduce the frequency of IPv4 attempts rather than to stop them
completely. So we'd end up with a double SHOULD: administrators SHOULD
set this flag if no IPv4 is configured and hosts SHOULD take notice.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Mar 2018 17:32:31 -0400

> Is it:
    > "The flag indicates that hosts can disable all IPv4 processing on
    > interface and if anything goes wrong it's on the administrators
    > shoulders"

    > "The flag is a hint that the host may or may not find any IPv4 on the
    > link and it has to figure that out itself, and if anything goes wrong
    > the blame is squarely put on the host implementation".

    > I support the draft or not.

So, just so that I understand what each statement means to you, could you
charactize which statement would apply to, for instance, the DNS info in the
RA? (and/or any other RA option)

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Mar 2018 00:31:45 +0200

Michael,

> On 25 Mar 2018, at 23:32, Michael Richardson <[email-masked]> wrote:
> 
> 

One choice is to make it like the M/O flags and with that hard to reason much about host behavior. The other to make it unambiguous like A/L. 

Ole

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Mar 2018 19:36:41 -0400

> One choice is to make it like the M/O flags and with that hard to
    > reason much about host behavior. The other to make it unambiguous like
    > A/L.

That's a good point: we already have flags which are advisory vs configuration.

But, tell me how you feel about DNS info in the RA!

Is it advice to the host, and if it's wrong, it's the hosts' fault
(it should have tried DHCPv6 despite M=0/O=0?),
or is it's wrong is the admin's fault for not getting the value right?

---

From: Simon Hobson <[email-masked]>
Date: Mon, 26 Mar 2018 11:14:45 +0100

> or is it's wrong is the admin's fault for not getting the value right?

First, this is an irrelevant diversion - it's a different discussion unrelated to the thread topic.

Secondly, IMO the hosts should use the information they are provided with by the network - because in the general case, the host does not know any better. It's up to the administrator to get these things right.
IMO, once you go down the road of "but the administrator might get it wrong, we must autoconfigure a working system anyway" then you are into trying to guess what every user on every future network might want to do.

Elsewhere I've seen a discussion where opinions on DNS were expressed that hosts should ignore what the network says and run their own recursing resolver. This is fine if you only consider your own host and network, but is a recipe for "problems" in the general case - where access to external DNS servers may be blocked, or certain information is only available from the official resolvers, or ...

So yes, I believe that the default should be that each hosts accepts the information given to it. If the administrator specifies DNS servers then use those, if the administrator specifies that IPv4 isn't in use on this link then disable IPv4, ...
And IMO this "there is no IPv4" flag is meaningless unless it actually means "there isn't any IPv4 used on this link".

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 26 Mar 2018 11:42:21 +0000

> From Ole Troan
> One choice is to make it like the M/O flags and with that hard to reason much
> about host behavior. The other to make it unambiguous like A/L.

"unambiguous, like A/L"? You mean like sometimes (e.g. on a 3GPP link) the router is saying (with A flag) the host can have the entire prefix (RFC 7278) and no need for DAD on the link, but on other links the router is just saying the host can create individual addresses for itself and do DAD for each?  

And host behavior wrt A/L *is* "ambiguous". Even with the 6434bis requirement of MUST support SLAAC, it's still allowed to disable SLAAC on the host. Just because an A prefix is advertised doesn't mean you can assume a host will take an address from it. And some hosts may support RFC 7278, while others don't. Sometimes the host will do DAD (for addresses it assigns itself) on the link where it received the RA with the A prefix, and sometimes it won't (RFC 7278). Sometimes it will further advertise to its LAN that same prefix, and sometimes it won't. Sometimes the host will take multiple addresses, and sometimes only one.

I agree that host behavior wrt M/O can also be ambiguous. The router side of M/O is ambiguous because people don't agree whether stateful options other than IA_NA are M or O, and M=O=0 can be used to mean "there is no DHCPv6", "please don't do DHCPv6", or "I don't know of any DHCPv6"

I think host behavior wrt all RA flags is ambiguous. Unless you absolutely know that all hosts getting RA from a router exhibit a certain behavior (e.g., the hosts follow a 3GPP spec, CableLabs spec, etc.) there is some ambiguity in what any given host will do with any given RA flag. Hosts may be configured to passively ignore any and all RA flags, or exhibit specific behaviors on certain link types.

Note that these special host (and router) behaviors related to M/O/A were defined well after the flags were defined. That may happen with this "no IPv4" flag as well (if it is defined). 
Barbara

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Mar 2018 13:47:01 +0100

> One choice is to make it like the M/O flags and with that hard to reason much about host behavior. The other to make it unambiguous like A/L. 

Making this umbiguous would be, IMO, worse than doing nothing.

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Mar 2018 15:49:36 +0200

Barbara,

[...]

> Note that these special host (and router) behaviors related to M/O/A were defined well after the flags were defined. That may happen with this "no IPv4" flag as well (if it is defined).

That doesn't quite match my recollection. Anyway, let's look at this from another angel.

If you had this flag, and as an network operator, enabled the flag on a link.
How would you expect the hosts to behave?

Ole

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Mar 2018 15:47:11 +0100

> On Mar 26, 2018, at 2:49 PM, Ole Troan <[email-masked]> wrote:
> 
> Barbara,
> 
> [...]
> 

Angels might be helpful here :-)

> How would you expect the hosts to behave?

If I am the administrator of the network (aka network operator) and set this flag in the RAs that the routers sent, I would expect the hosts to do what it says and stop all IPv4 activity.  It would be up to me insure that all appropriate services ran on IPv6.

Bob

---

From: David Schinazi <[email-masked]>
Date: Mon, 26 Mar 2018 16:48:25 +0200

Hi Bob,

> On Mar 25, 2018, at 09:46, Bob Hinden <[email-masked]> wrote:
> 

In my humble opinion, it's premature to adopt if we haven't figured out what the working group wants to do because this issue is pretty fundamental. Hearing about someone who has implemented this would also be helpful, as that practical experience would inform the decisions that need to be made here.

Thanks,
David

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 26 Mar 2018 15:05:04 +0000

> From: Ole Troan 
> 
> > Note that these special host (and router) behaviors related to M/O/A were
> defined well after the flags were defined. That may happen with this "no
> IPv4" flag as well (if it is defined).
> 

That's a really interesting question. I don't think this would be appropriate in home networks. I think wireless networks already have v6-only deployments and don't need this flag. In wireline where we use our own CE routers, it's easier just to change the CE router configuration to disable IPv4 than rely on a flag. But for wireline where we don't manage the CE routers it might be interesting to think about a CE router requirement to not do DHCPv4 requests if it sees this flag. A requirement like that wouldn't go in draft-hinden-ipv4flag, but would come later in an update to CE router requirements. It could even trigger the CE router to enable some transition mechanism to support v4 only devices inside the LAN. Hmmm. Something to think about.
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2018 12:21:12 -0400

David Schinazi <[email-masked]> wrote:
    >> I agree this is an open issue, but I think that can be worked out
    >>after the draft is adopted.  This is, of course, only an adoption call,
    >>if it is adopted the draft will it reflect what the w.g. wants to do.

    > In my humble opinion, it's premature to adopt if we haven't figured out
    > what the working group wants to do because this issue is pretty
    > fundamental. Hearing about someone who has implemented this would also
    > be helpful, as that practical experience would inform the decisions
    > that need to be made here.

{I think that this is not the written IETF process, but you'd be forgiven
because it seems like it's taken over under the guise of creeping elevation
of in the whole specification process.. We've effectively moved WGLC
discussion into WG Adoption Call. }

We should adopt if we believe that there is a problem to solve and we are the
right WG to solve it (if it's in our charter, etc.).  We don't spend WG
time on personal drafts: if you want 6man to spend time on the *discussion*
then we adopt.

Once adopted, the WG can decide if we want a different solution.
If it turns out to be untenable, then we kill it with no solution.
But, adopting does not mean you like the solution, adopting means that you
want to spend time on the discussion.

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Mar 2018 19:54:24 +0200

Michael,

One reason WG adoption has become such a narrow gate to pass, is because it is increasingly difficult to kill or redirect adopted  work. It’s easier to agree on the premise for the work first. 

Cheers 
Ole

> On 26 Mar 2018, at 18:21, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2018 08:44:16 +1300

Ole,

This co-author at least will allow the WG to kill the draft after adoption, if
that's what the WG wants to do.

On another point: the flag is not ambiguous. It's carefully designed not to
be ambiguous, which is exactly why it describes the behaviour of the device
that sends it, and not what other devices on the network might or might
not be doing.

Host behaviour is intentionally not compulsory, because it's been made clear
on this list that different host scenarios may lead to different behaviours.

Some people would like a "Thou shalt not commit IPv4" flag. This is not
that flag. I think most implementers would laugh at that flag.

    Brian

Regards
   Brian Carpenter

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Mar 2018 22:00:50 +0200

Bob,

> If I am the administrator of the network (aka network operator) and set this flag in the RAs that the routers sent, I would expect the hosts to do what it says and stop all IPv4 activity.  It would…

Thanks! Yes, this definition of the flag would make host behaviour deterministic. And easy to reason about.
You could even rename it the ipv6-only flag.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Mar 2018 22:01:43 +0200

Brian,

> that flag. I think most implementers would laugh at that flag.

I think this use of the flag, without specifying host behaviour is what will lead to interoperability issues and confusion.

Cheers,
Ole

---

From: Simon Hobson <[email-masked]>
Date: Mon, 26 Mar 2018 21:34:33 +0100

> that sends it, and not what other devices on the network might or might

Which makes it ambiguous - because it does *NOT* say what the hosts must/should do, therefore every vendor will have to make their own guess at what it should do, and therefore the flag is a "do something undefined flag".
I can't see how an instruction to "do something undefined, guess what the network administrator might want you to do" is anything but ambiguous !

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2018 17:22:02 -0400

Ole Troan <[email-masked]> wrote:
    > One reason WG adoption has become such a narrow gate to pass, is
    > because it is increasingly difficult to kill or redirect adopted
    > work. It’s easier to agree on the premise for the work first.

You mean, chairs are unable to judge consensus and say no?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Mar 2018 11:35:56 +1300

> I can't see how an instruction to "do something undefined, guess what the network administrator might want you to do" is anything but ambiguous !

I'll reply to this message rather than Ole's, but you're saying the same thing.

We've already had at least one host stack implementer saying on this list that they won't do that, and that they will continue trying link-local IPv4 services. It simply isn't in the IETF's power, or the local network administrator's power, to determine what hosts do. Pretending otherwise is pointless.

When you take that fact on board, all that's left is an advisory flag. If the consensus is that this isn't worth implementing for the sake of some reduction in pointless broadcast packets, that's fine.

You can count me out if there's a proposal to make this a "mandatory" flag, because that would be meaningless.

    Brian

---

From: Glen Turner <[email-masked]>
Date: Tue, 27 Mar 2018 17:04:04 +1030

On Mon, 2018-03-26 Bob Hinden wrote:

> If I am the administrator of the network (aka network operator) and
> set this flag in the RAs that the routers sent, I would expect the
> hosts to do what it says and stop all IPv4 activity.  It would be up
> to me insure that all appropriate services ran on IPv6.

I would also add that a host seeing the flag should remove the
assumption that IPv4 will work over the link media. That is, when the
flag is seen then IPv4 link-local may fail.

For example, an access point could strip its specialist support for
IPv4/ethernet broadcast and multicast. Perhaps making the AP more
lightweight, or perhaps making the media perform better.

-- 
 Glen Turner
 Web: <http://www.gdt.id.au/~gdt/>
 Tel: 0416 295 857

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Mar 2018 09:14:18 +0200 (CEST)

> lightweight, or perhaps making the media perform better.

I've had this thought for a long time but didn't voice it before because 
it's kind of wish-washy.

There are use-cases to have two flags. One would be "I am a router and I 
haven't got any IPv4 config on me, so hint-hint, there might not be IPv4 
here". There is also a second flag "the network administrator said there 
is no IPv4 here, turn off your IPv4 stack on this interface".

The first one would be used in mixed environments, BYOD etc. The second 
one would be used in controlled networks where even ethertype filtering is 
done on the network.

As a third thing, it might be a good airtime optimization if the wifi NIC 
would do ethertype filtering and not even send out IPv4 ethertype packets 
(this signalling would be done on the wifi layer and has nothing to do 
with the discussion here). I'm considering asking 802.11 experts if this 
is already a thing (AP telling wifi NIC what ethertypes are supported), 
and if not, that perhaps should become a thing.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Mar 2018 09:39:10 +0100

On 03/27/2018 08:14 AM, Mikael Abrahamsson wrote:
[...]
> here". 

And what would a host do in this case?

> one would be used in controlled networks where even ethertype filtering
> is done on the network.
> 
> As a third thing, it might be a good airtime optimization if the wifi
> NIC would do ethertype filtering and not even send out IPv4 ethertype
> packets (this signalling would be done on the wifi layer and has nothing
> to do with the discussion here). I'm considering asking 802.11 experts
> if this is already a thing (AP telling wifi NIC what ethertypes are
> supported), and if not, that perhaps should become a thing.

Beware of what you ask. An attacker fires one of these packets and...
what's next? Rebooting to get the NIC to process IPv4 again?

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 27 Mar 2018 11:02:30 +0200 (CEST)

> And what would a host do in this case?

Try less hard to acquire IPv4 information.

>> packets (this signalling would be done on the wifi layer and has 
>> nothing to do with the discussion here). I'm considering asking 802.11 
>> experts if this is already a thing (AP telling wifi NIC what ethertypes 
>> are supported), and if not, that perhaps should become a thing.
>

Depends on which of these two caes. If you're allowing uncontrolled RAs on 
your LAN, you're screwed regardless. The wifi suggestion would be "out of 
band" for the L2/L3 layer (side channel on wifi, or for instance in 802.1x 
or some other method that is not "regular" L2/L3), and it would be per 
AP/SSID.

I know people who do MITM attacks on swedish trains by sending an RA out 
on the wifi and all of a sudden can MITM all traffic. We need to stop 
accomodating bad security practices by caring too much about these 
scenarios. People need to secure both link- and transport-layer.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 27 Mar 2018 09:03:15 +0000

> what's next? Rebooting to get the NIC to process IPv4 again?

What do you mean by rebooting?  Buying a new NIC.  This is hardware.  
The fuse is blown.  A reboot won’t fix that.

Wouldn’t that be great?  I’d invite these “attackers” to be very 
active all around the world all day long and we could stop this 
discussion and immediately forget about any IPv4 problems.   Problem 
solved.  q.e.d.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 27 Mar 2018 17:42:45 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Glen Turner

> assumption that IPv4 will work over the link media. That is,
> when the flag is seen then IPv4 link-local may fail.
>
> For example, an access point could strip its specialist support
> for IPv4/ethernet broadcast and multicast. Perhaps making the
> AP more lightweight, or perhaps making the media perform better.

I dunno. I keep thinking of the home network example, with IPv4-only printer, or other local IPv4-only peripheral device. I think the link layer needs to be agnostic of this flag. Can't have a new flag break things, for reasons that a typical home network operator wouldn't begin to comprehend.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2018 08:45:50 +1300

> Try less hard to acquire IPv4 information.

As described in the draft: back off the frequency of IPv4 discovery
broadcasts. (If we modified all IPv4 discovery mechanisms to back off
aggressively when there's no reply, that might be enough on its own;
but that isn't something 6man can do. Defining this bit might nudge
the industry in that direction.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2018 08:49:40 +1300

> I dunno. I keep thinking of the home network example, with IPv4-only printer, or other local IPv4-only peripheral device. I think the link layer needs to be agnostic of this flag. Can't have a new…

The switches in current home networks seem to be pure bridges, so this
wouldn't be an issue. Of course, future home switches might be more
sophisticated, i.e. able to block stuff, so a whole lot of problems
might arise, not just this one.

    Brian

---

From: "t.petch" <[email-masked]>
Date: Wed, 28 Mar 2018 16:38:12 +0100

Rather, WG Chairs vary widely in their outlook, which makes it more
difficult for participants.

I know WG Chairs who say that only one person spoke up during WG Last
Call so there is no consensus to forward the document to the IESG.

On the other hand, I see WG Chairs who say noone spoke up during WG Last
Call and so the document will be forwarded to the IESG.

I believe that the former serves the IETF better, be it at adoption, WG
LC, LC and so on.

Tom Petch

---

From: Simon Hobson <[email-masked]>
Date: Thu, 29 Mar 2018 16:28:30 +0100

> You can count me out if there's a proposal to make this a "mandatory" flag, because that would be meaningless.

Let me get this straight - you are basically saying that IETF cannot set standards that stipulate what hosts should do under certain conditions ? And because of that, this flag cannot be made into a "hosts should disable IPv4" flag.

So standards specifying how hosts should, for example, form IP addresses for interfaces are bogus because they stipulate what a host must do ? Standards can't, for example, specify what a host should do if a router changes the advertised lifetime for a prefix to zero. ...

Of course any vendor/developer is free to ignore whatever standards they like. Some will result in operability issues if ignored, some will simply just not achieve the desired effect if ignored. I see this flag as one of the latter - if a host doesn't disable IPv4 then there's nothing lost - but if it does then there are gains (IMO).

But at the moment the description of this flag is so wooly in it's meaning that it's barely worth bothering with - "take this as a hint and try to second guess what some admin wants you to do" is most definitely very vague. "Take this flag as indicating that the admin would like you to disable IPv4 because it's supposed to be an IPv6 only network" is more meaningful, but it won't cause any harm if hosts either ignore it or just "scale down" their attempts at configuring IPv4.

Bjoern A. Zeeb <[email-masked]> wrote:

> What do you mean by rebooting?  Buying a new NIC.  This is hardware.  The fuse is blown.  A reboot won’t fix that.

I don't think the suggestion was that this would somehow "blow a fuse", just that it would cause a host to lose IPv4 connectivity until the networking stack (or at least some part of it) is reset.

> Wouldn’t that be great?  I’d invite these “attackers” to be very active all around the world all day long and we could stop this discussion and immediately forget about any IPv4 problems.   Problem solved.  q.e.d.

Well that would be "interesting" to see !

But the thing is, networks are already vulnerable from spoofed services. If there is no filtering/management/detection in place, then any rogue device can send spurious RAs and cause problems - just like rogue DHCP servers cause problems with IPv4 (my favourite being the "lets use this router as an access point" problem).

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Mar 2018 08:55:12 +1300

On 30/03/2018 04:28, Simon Hobson wrote:
> Let me get this straight - you are basically saying that IETF cannot set standards that stipulate what hosts should do under certain conditions ? 

We can, of course, and often do so. But in this case, what's the point, when we know that at least one important host stack won't conform?

> And because of that, this flag cannot be made into a "hosts should disable IPv4" flag.

Hang on... you wrote "should". I understood that you were after a "must". In this case, the difference is important.
 
> Of course any vendor/developer is free to ignore whatever standards they like. Some will result in operability issues if ignored, some will simply just not achieve the desired effect if ignored. I…

Yes. We agree on that.

> But at the moment the description of this flag is so wooly in it's meaning that it's barely worth bothering with - "take this as a hint and try to second guess what some admin wants you to do" 

It doesn't say that. What I thought it implied was "take this as a hint and do what's best for you." So clearly the text isn't explicit enough.

> is most definitely very vague. "Take this flag as indicating that the admin would like you to disable IPv4 because it's supposed to be an IPv6 only network" is more meaningful, but it won't cause any harm if hosts either ignore it or just "scale down" their attempts at configuring IPv4.

So we are in fact arguing about wording, not about the underlying intention,

Regards
    Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 29 Mar 2018 21:24:25 +0000

On 29 Mar 2018, at 19:55, Brian E Carpenter wrote:

>> Let me get this straight - you are basically saying that IETF cannot 
>> set standards that stipulate what hosts should do under certain 
>> conditions ?
>
> We can, of course, and often do so. But in this case, what's the 
> point, when we know that at least one important host stack won't 
> conform?

Which one?

And why would you limit yourself because of that today, when you don’t 
know about tomorrow?  In 12 months a lot of things can change, needless 
to say in 6 years.

/bz

---

From: Tim Chown <[email-masked]>
Date: Thu, 29 Mar 2018 21:28:45 +0000

> On 29 Mar 2018, at 22:24, Bjoern A. Zeeb <[email-masked]> wrote:
> 
> And why would you limit yourself because of that today, when you don’t know about tomorrow?  In 12 months a lot of things can change, needless to say in 6 years.

Any bookmaker want to put odds on DHCPv6 support in Android within 12 months? :)

Tim

---

From: Simon Hobson <[email-masked]>
Date: Thu, 29 Mar 2018 23:03:06 +0100

> We can, of course, and often do so. But in this case, what's the point, when we know that at least one important host stack won't conform?

That same argument applies to so many things - why bother specifying that ISPs must provide more than one /64 then since you knew in advance that many would not do so. It's a dangerous road to go down to say "lets not bother making this a useful standard because one vendor will ignore it".

> Hang on... you wrote "should". I understood that you were after a "must". In this case, the difference is important.

Well since it's one of those things where we can assume it won't massively break something if a host doesn't comply, then "should" should be adequate. But it at least says "this is what a host SHOULD do" rather than "we don't care what the host does, and network admins won't have a clue either".

> It doesn't say that. What I thought it implied was "take this as a hint and do what's best for you." So clearly the text isn't explicit enough.

There's not a lot of difference. Only the local admin knows if IPv4 is supposed to be working on the link, and with the proposal he has no idea what setting the flag may (or more likely, won't) do for him. If all it is supposed to mean is "a little bit less IPv4 traffic but everything's still going to try using IPv4 anyway" then I suspect many admins would take the view that "so why bother, stuff's still going to do IPv4 anyway ?".

If the standard were set to "hosts should disbale IPv4" then the admin will mostly get what's expected - most hosts won't try IPv4. If one vendor chooses to ignore that, then their users will suffer from shorter battery life than they could be getting - and it's the vendor's fault, not IETF's. If they choose to just "back off" from configuring IPv4 as aggressively then users still gain as much as with the current proposal.
So it looks to me like there are gains to be made from it saying "hosts should turn off IPv4", and no losses compared to the current proposal.

> So we are in fact arguing about wording, not about the underlying intention,

No, I don't think that is the case.

As I see it there are two camps here.
One camp, and I'm in that one, think that a flag should be declarative - "there is no IPv4 in use here, please don't try".
The other camp want something that IMO is of little value - "there may, or may not, be IPv4 in use here" which is really the default situation anyway. Most arguments seem to stop at being "less aggressive" at trying to get an IPv4 address - and I really have to question just how much benefit that is if you still have to assume that IPv4 is available until you've satisfied yourself that it isn't. Saving just a few DHCP packets on activating a link ?

Saying that it won't cause harm if a host ignores the flag is not the same as saying that the two approaches are "just different words".

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 29 Mar 2018 23:12:44 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Simon Hobson

> One camp, and I'm in that one, think that a flag should be declarative
> - "there is no IPv4 in use here, please don't try".

Except, individual hosts might know better. Just because the router says so does not make it undeniably true.

> The other camp want something that IMO is of little value - "there
> may, or may not, be IPv4 in use here" which is really the default
> situation anyway.

Not exactly, though. In the common case, especially in home nets, in which you only have the one default gateway, the flag says, the default gateway does not do IPv4, does not hand out IPv4 addresses, won't route IPv4 packets, so don't bother trying to use IPv4 over the Internet. But that ISP you got the router/modem from doesn't know that you still have a 1983 PC XT running in your home net, because you're a packrat history buff. So the flag is useful. It avoids long delays, say in attempting to obtain an IPv4 address from the DHCP server, but at the same time, it shouldn't prevent consenting adults from running old equipment.

Bert

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Mar 2018 17:28:02 +1100

The ISP has no business setting this flag on the customer side.  It is a customer flag.  Only the customer can know if they want IPv4 to be disabled or not on their side of the router. 

The ISP sets what is required to communicate upstream.  

-- 
Mark Andrews

> On 30 Mar 2018, at 10:12, Manfredi, Albert E <[email-masked]> wrote:
>

---

From: Simon Hobson <[email-masked]>
Date: Fri, 30 Mar 2018 11:37:30 +0100

> Except, individual hosts might know better. Just because the router says so does not make it undeniably true.

How ? Short of manually configuring the device (in which case, why bother with this RA flag) there is no way for a host to determine whether it should be trying to use IPv4, and whether it should try to autoconf an address if DHCP fails.
If the router says "no IPv4" then either there really isn't supposed to be IPv4 or the admin had incorrectly configured the network.

Put another way, unless told by a flag that's "authoritative", how can any host (in the general case) know whether IPv4 is in use or not ? Looking to see if there's other IPv4 traffic doesn't work since any single host trying IPv4 would then trigger all other hosts to do the same. Not getting any response to DHCP requests doesn't tell you if auto conf should still be tried.

> Not exactly, though. In the common case, especially in home nets, in which you only have the one default gateway, the flag says, the default gateway does not do IPv4, does not hand out IPv4 address…

As already said, the ISP should not be setting this, and in a typical home network it's not going to make any meaningful difference.
Besides, the old XT won't (or at least, is highly unlikely to) be running an OS that understands IPv6 so won't even see this flag. I think the idea that there are still significant numbers of 8088 or 8086 machines out there and in use, and that they are running an OS up to date enough to be doing IPv6, AND up to date enough to understand this flag is ... "rather optimistic".

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 30 Mar 2018 14:55:03 +0000

> From: Simon Hobson
...
> Let me get this straight - you are basically saying that IETF cannot set
> standards that stipulate what hosts should do under certain conditions ? And
> because of that, this flag cannot be made into a "hosts should disable IPv4"
> flag.

Of course the IETF can. But doing this in the same doc that specifies the flag is a bad idea.
Consider the RA A flag.
The A flag was first defined in the year 1996 in RFC1970 (obsoleted by RFC2461 and then RFC4861). But they all say the same thing about host use of the A flag. " "When set indicates that this prefix can be used for stateless address configuration as specified in [ADDRCONF]."
Note the use of the non-normative word "can". 
The companion RFC referenced by the flag-defining spec as [ADDRCONF] does specify *a* behavior that can be exhibited in presence of this flag. Just now, in the year 2018, we're considering 6434bis to make *implementation* of RFC4862 behavior mandatory. But having this behavior enabled is still not mandatory.
RFC 7278 (from the year 2014) defines another possible behavior by hosts who see an A flagged prefix in RA. It is an informational RFC that defines a behavior specifically for a 3GPP link use case. 18 years after the flag was defined, a new possible behavior was defined.

IMO, what was done for the A flag is a good paradigm for handling describing host behavior when a particular RA flag is received. 
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Mar 2018 13:20:02 -0400

> We can, of course, and often do so. But in this case, what's the point,
    > when we know that at least one important host stack won't conform?

But, we also know that every host stack out there today won't conform.
So, we can get some portion of them to conform, and that reduces the
broadcast impact.   Maybe said host stack will change their mind.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Mar 2018 07:52:57 +1300

> The ISP has no business setting this flag on the customer side.  It is a customer flag.  Only the customer can know if they want IPv4 to be disabled or not on their side of the router. 

That's another reason that the semantics of the flag are about *what the router setting it is configured to do*. It makes no statement about whether IPv4 packets are allowed or forbidden; it simply says whether they will be handled by the router in question.
 
> The ISP sets what is required to communicate upstream. 

Sure. But if there is no IPv4 service upstream, the router could say so.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Mar 2018 07:56:48 +1300

Excuse front posting, but this sub-thread is talking about some other hypothetical
proposal, not about the proposal in the draft.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Mar 2018 08:02:32 +1300

> broadcast impact.   Maybe said host stack will change their mind.

Correct. And if you actually mean "should" not "must" (the word "stipulate"
could be read as a "must") we probably agree - the idea being to nudge stacks
in the right direction. But (and I think this is what Barbara's recent message
implies) most of the nudging will come from operational guidance; the proposed
bit is a small step in support of such guidance.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Mar 2018 16:51:16 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> The ISP has no business setting this flag on the customer side.  It is
    >> a customer flag.  Only the customer can know if they want IPv4 to be
    >> disabled or not on their side of the router.

    > That's another reason that the semantics of the flag are about *what
    > the router setting it is configured to do*. It makes no statement about
    > whether IPv4 packets are allowed or forbidden; it simply says whether
    > they will be handled by the router in question.

    > Sure. But if there is no IPv4 service upstream, the router could say so.

In DHCPv4, we have no way to say that a particular router does not offer a
default route.  All a router in such a situation can do is not run DHCPv4.
IPv4 only hosts, if they are lucky, might be able to use LLv4, or they might
conclude that there network is dead.

But, we *can* signal that there is no uplink in v6.
(Which perhaps explains how we might handle a future transition)

So perhaps that is really what we can do with this bit:
   "The router setting this bit is indicating that the lack of
    DHCPv4 response is not an error.  This router has no IPv4 uplink."

---

From: Simon Hobson <[email-masked]>
Date: Fri, 30 Mar 2018 22:03:44 +0100

> default route.  All a router in such a situation can do is not run DHCPv4.

Being pedantic, that is not correct.

A DHCP server may put any address in the default router option, not just it's own address - and the DHCP server(s) does not have to run on a router (mine doesn't). If a particular implementation doesn't allow that, then that's an implementation thing*, not a fundamental limitation.
Also, since only one default route can be provided, if you have more than one router, all but one of them won't be a default route - may be different for different classes of client if the DHCP server(s) are so configured.

But your other point is correct - if there's no DHCPv4 service running, then clients will typically create an auto configured address and try to use that. As I see it, this flag is a way of signalling that "there's no DHCPv4 service because IPv4 isn't in use" - it's just that there's a certain disagreement over what that flag should mean in detail.

* I've seen some "interesting" implementation limitations. Like the Netgear routers that didn't allow 255 or 0 as the last octet - because clearly every network in the world run's /24 and so they cannot be valid anywhere ! My current (ISP provided) router where the DHCP server doesn't work if you change the network address from 192.168.1.0/24. And one I came across not long ago, a cheap router where the DHCP service could not be disabled - the customer was trying to use it as a switch and access point.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 30 Mar 2018 22:10:35 +0100

>     DHCPv4 response is not an error.  This router has no IPv4 uplink."

if this is the intention of the draft, then modifying dhcpv4 to either
change the backoff algorithm or else build in an explicit back-off /
do-not-query timer seems like a much saner approach in terms of ease /
consistency of implementation.

Regarding LL traffic, if a host wants to talk LL ipv4, then that's an
issue for the host, not the router.  The router doesn't come into the
equation.

Overall, there is a mismatch between the specification of this draft
(i.e. a particular ipv6 router on an l2 domain is declaring itself not
to speak ipv4) and its apparent intentions (i.e. hosts on this l2 domain
shouldn't really attempt to use ipv4 on the interface connected to this
l2 domain).  This mismatch needs to be cleared up before it would be
appropriate to adopt the draft in the WG.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Mar 2018 13:12:24 +1300

>     DHCPv4 response is not an error.  This router has no IPv4 uplink."

Yes, that paraphrases what the draft says.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Mar 2018 13:17:11 +1300

> consistency of implementation.

Not, however, within the remit of 6man.

> issue for the host, not the router.  The router doesn't come into the

Absolutely, and the draft doesn't contradict that in any way.

> l2 domain).  

I disagree. If those intentions are apparent in the draft, I can't see them.
The intention is to (help to) reduce pointless IPv4 traffic, especially
broadcast traffic.

> This mismatch needs to be cleared up before it would be

Actually not, because adoption does not imply agreement with the draft,
only agreement to take up the topic.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 31 Mar 2018 12:07:32 +0900

On Sat, Mar 31, 2018 at 6:03 AM, Simon Hobson <[email-masked]>
wrote:

> A DHCP server may put any address in the default router option, not just
> it's own address - and the DHCP server(s) does not have to run on a router
> (mine doesn't). If a particular implementation doesn't allow that, then
> that's an implementation thing*, not a fundamental limitation.
>

In practice though, there are popular implementations that interpret the
lack of a default route as "point a default route at the DHCP server". Old
versions of Android used to do this until I fixed it in 6.0