Subject: RIPE on IPv6 only

From: Ole Troan <[email-masked]>
Date: Fri, 19 Oct 2018 12:24:20 +0200

https://ripe77.ripe.net/archives/video/2335/

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 19 Oct 2018 13:21:00 +0200

Thanks for the pointer.

There are hand claps and the overall room atmosphere is that this flag 
is not a good idea.

One can see at RIPE meeting some IETF participants too.

Alex

Le 19/10/2018 à 12:24, Ole Troan a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 19 Oct 2018 13:47:45 +0200

[Added “flag” to subject as this was a RIPE lightning talk about the IPv6 only flag draft, not IPv6 only in general].

Ole

> On 19 Oct 2018, at 12:24, Ole Troan <[email-masked]> wrote:
>

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Oct 2018 23:43:27 +1100

I don't think the presentation properly and completely presents all
the arguments.

I don't understand this:

"Alternative solutions are sufficient
• No control over switches & hosts, no DHCPv4
and desire to prevent unnecessary traffic?"

It seems to be suggesting that

- operators always have control over switches - I don't strongly
disagree with this, although it can be a possibility if e.g. you're
running up IPv6 only over a layer 2 network already present at the
site, such as at a conference in a hotel.

- operators of a network always have administrative control over the
end-user hosts attached to the network they're operating - however
they don't on any network that allows connection of  BYO hosts (which
I presume would be a description of the Wifi network at RIPE77 that
people attached their BYO phones and laptops to) and they don't for
any smartphones or Chromebooks on any network (heads up, Google and
Apple are your hosts' administrators if you have an Android/ChromeOS
or IOS phone unless you root your device). Devices such as Chromecasts
are also devices where the device owner doesn't have administrative
access or control.

- adding/enabling DHCPv4 infrastructure/service to purely to disable
IPv4 is efficient and logical - not having a DHCPv4 server enabled to
disable IPv4 is always going to be better because

o  less state and less processing in the device that would be
operating the DHCPv4 server, meaning resources free for other uses, or
less electricity consumption (granted, a minor reduction, none the
less, still a reduction, which adds up over many devices).

o  less possibilities of security vulnerability because less code is
running in both end hosts and the device that would have been used to
operate the DHCPv4 server. The devices potential network attack
surfaces are smaller.

o  end-hosts that have had IPv4 entirely switched off via an
out-of-band mechanism that hosts will already be using are not
vulnerable to a rogue DHCPv4 server that could be used to switch IPv4
back on.

> One can see at RIPE meeting some IETF participants too.

I think they need to participate here in the WG if they want to
express an opinion that we place more than cursory weight on,
otherwise they haven't seen or been involved in all the related
discussion.

How many of those who saw the presentation and expressed an opinion
have read the draft and spent time considering what is in it? The
draft has in the order of 8 pages of body text verses a 10 minute
lightning talk and a 10 slide slide deck with in order of 30 bullet
points.

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Sat, 20 Oct 2018 02:33:46 +1100

> There are hand claps and the overall room atmosphere is that this flag

While hand claps might be as good as hums to indicate the consensus, I
do hope that people how care would say smth in the list.

> One can see at RIPE meeting some IETF participants too.

Please take into account that it was a lightning talk so there was
really no time for discussions.
I mentioned that draft on the presentation I gave at RIPE77 IPv6
Working Group so the community should be well aware now.

--
SY, Jen Linkova aka Furry

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Oct 2018 18:12:59 +0200

Hi Mark & WG,

> and desire to prevent unnecessary traffic?"

What I meant is that only on a network where all those conditions are true would adding a new flag to RAs would be the only solution. If someone either can block the ethertype on switches, or can manage the connected hosts, or can run a small DHCPv4 server on the network then there are alternative solutions available. My point is that only on networks where none of these options are possible AND the operator actually cares about silencing IPv4 would this new RA flag be useful.

> otherwise they haven't seen or been involved in all the related

As I have personally experienced this working group is quite hostile to newcomers that don't agree with what is happening here. Personally I got a strong feeling that my opinions are not taken seriously and are being dismissed. The "if you don't agree then you don't know what you're talking about" feeling is quite strong...

The barrier to participation is enormous for many operators. Endless arguments while responses are being dismissed etc etc etc. Arguing against the established cabal feels quite futile. It makes me very sad, but my personal experiences confirm this.

I have discussed this with Ole and agreed that I would bring this forward at the RIPE meeting to get feedback from actual operators who aren't aware of what is happening in the IETF (for many reasons) and I would report the outcome to this working group. These are the results.

> lightning talk and a 10 slide slide deck with in order of 30 bullet

I don't know if you realise it, but this comment already feels very dismissive... I am sure you don't mean it like that, but the end result is the same. Not everybody has the time to read every draft, and when an attempt to make people aware of a draft outside the IETF leads to comments implying that those people probably haven't thought about it properly and their arguments/fears/etc shouldn't be taken seriously then you have exactly identified a major problem.

When someone from outside your circle disagrees with you, you can either engage with them or dismiss them. I hope the people in this working group choose the former.

Cheers,
Sander

PS: most of the "you" wording is addressed to this working group, not to Mark personally. Mark's message was just the trigger for this mail, not the reason :)

---

From: Jen Linkova <[email-masked]>
Date: Sat, 20 Oct 2018 03:39:42 +1100

On Sat, Oct 20, 2018 at 3:13 AM Sander Steffann <[email-masked]> wrote:
> What I meant is that only on a network where all those conditions are true would adding a new flag to RAs would be the only solution. If someone either can block the ethertype on switches, or can manage the connected hosts, or can run a small DHCPv4 server on the network then there are alternative solutions available.

- home network (I can not recall if my CPE allows ethertype
filtering...I doubt it would be possible, while enabling a flag in RA
sounds a bit more feasible);
- let's say my device connects to a network. If the network could
signal that there is no v4 and my device would save some battery - it
would be nice. The network operator might prefer to sent one flag on
one  or two routers vs deploying ACLs on all L2 switches.

>My point is that only on networks where none of these options are possible AND the operator actually cares about silencing IPv4 would this new RA flag be useful.

Enabling one bit in RA might be just much easier to deploy and operate
than other options (definitely easier than having DHCP server just to
signal that there is no v4);
-- 
SY, Jen Linkova aka Furry

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Oct 2018 18:49:09 +0200

Hi,

> sounds a bit more feasible);

True. However I don't think many home users care or know enough to care to avoid IPv4. They just want a functioning network.

> one  or two routers vs deploying ACLs on all L2 switches.

It would be nice, but not enough to justify the risk. See my message to Mikael for suggested wording that I would be happy with.

> signal that there is no v4);

Easier: yes. Significantly easier, considering that every CPE already has a DHCPv4 server available: probably not...

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 09:14:00 +1300

> What I meant is that only on a network where all those conditions are true would adding a new flag to RAs would be the only solution. If someone either can block the ethertype on switches, or can m…

That is what the latest version of the draft says, in effect, except that
there is also the case of an unmanaged LAN with an IPv6-only router out
of the manufacturer's box.

> The barrier to participation is enormous for many operators. Endless arguments while responses are being dismissed etc etc etc. Arguing against the established cabal feels quite futile. It makes me…

Sometimes, to be honest, it seems like we at the IETF have to argue
against an operator cabal whose starting position is that anything
new is suspect. I appreciate you sitting in the middle, of course,
that isn't easy.

> I have discussed this with Ole and agreed that I would bring this forward at the RIPE meeting to get feedback from actual operators who aren't aware of what is happening in the IETF (for many reaso…

It might have been nice to check the slides with the authors first.
We've updated the draft in response to feedback, including all the arguments
presented here as far as I can see. 

> When someone from outside your circle disagrees with you, you can either engage with them or dismiss them. I hope the people in this working group choose the former.

We try ;-). 

Regards
  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Oct 2018 09:17:33 +1300

> Easier: yes. Significantly easier, considering that every CPE already has a DHCPv4 server available: probably not...

How about an IPv6-only CPE bought from a supermarket ten years from now?

   Brian

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Oct 2018 23:34:14 +0200

Hi Brian,

> new is suspect.

And you get that even with relatively few operators participating :)  But honestly: yes. Every new thing needs brain cycles, training, learning how it can be used and abused, investigation security and operational consequences, gaining experience with debugging it etc. So even things that aren't going to be used by an operator incur cost. 

Operators will consider "do we really need this" for everything new. And IPv6 does have many many things to consider. Ole said to me that we can't just decide that someone's problem isn't worth solving, but we should consider the impact that solving someone's problem can have on the rest of us.

> I appreciate you sitting in the middle, of course, that isn't easy.

Thanks :)  It makes me happy to hear/read you say that!

> It might have been nice to check the slides with the authors first.

If only I had known earlier. I got the confirmation that my lightning talk was accepted while celebrating my girlfriend's birthday. I only had one hour in the morning to put those slides together.

> presented here as far as I can see. 

The slides were based on version 03. There is still language in there that goes further than would be safe, like: "A host that receives only RAs with the flag set to 1 SHOULD NOT attempt any IPv4 operations". That is contradicted a bit later when talking about delaying DHCPv4 until an application needs IPv4, but the meaning of "should not attempt any IPv4 operation" is too strong.

> We try ;-)

Thank you!!!
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 20 Oct 2018 10:25:06 +0100

> against an operator cabal whose starting position is that anything

people in the operational community will raise concerns about things 
which they think are going to cause problems.  This is a healthy thing 
to do.

Nick

---

From: Ole Troan <[email-masked]>
Date: Sat, 20 Oct 2018 11:37:49 +0200

> people in the operational community will raise concerns about things which they think are going to cause problems.  This is a healthy thing to do.

It might be because we have always treated the protocols as ships in the night.
This proposal suggests one ship should be allowed to sink the other. Understandably this makes people uncomfortable.

Ole

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Oct 2018 22:11:26 +1100

> This proposal suggests one ship should be allowed to sink the other. Understandably this makes people uncomfortable.

Actually I can think of a number of other examples where an IPv4 ship
carries IPv6 information and vice-versa..

It is possible to get IPv6 DNS RRs over IPv4/UDP/TCP transport, or
IPv4 DNS RRs over IPv6/UDP/TCP transport.

It is possible to receive IPv6 BGP routes over IPv4/TCP transport, or
IPv4 BGP routes over IPv6/TCP transport.

OSPFv3 over IPv6, and originally only to carry IPv6 information, can
now carry IPv4 information per RFC5838.

RFC7949 then specifies how to have OSPFv3 use IPv4 as its transport.

So now with OSPFv3 there is the same capabilities for IPv4 to be used
to carry IPv6 information and vice versa as there is with BGP.

While it's generally a good idea, it isn't a requirement for
information about one protocol to be exclusively carried in the exact
same protocol family.

The fundamental requirement to signal to switch off IPv4 on a remote
host is that the protocol to do it is not IPv4 (i.e. it needs to be an
out-of-(IPv4)-band protocol). This proposal is using IPv6, not because
it is a relative of or the replacement for IPv4, but because it is
universally supported non-IPv4 protocol that these IPv4 (dual stack)
hosts are guaranteed to speak.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 20 Oct 2018 12:33:54 +0100

> information about one protocol to be exclusively carried in the exact

Mark,

there is a fundamental difference between all these examples and the 
ipv6only flag, which is that all the examples you provide are negotiated 
bidirectionally.  This is an important distinction from a security 
management point of view.

Nick

---

From: Lee Howard <[email-masked]>
Date: Sat, 20 Oct 2018 10:08:20 -0400

>>> otherwise they haven't seen or been involved in all the related
That's an impressive level of gatekeeping there, Mark.
I'm sure I heard people advocating for GitHub as a discussion forum 
because they got so much great feedback there from people who weren't 
otherwise IETF participants.

> new is suspect. I appreciate you sitting in the middle, of course,

Wait. . . you don't treat anything new as suspect?

Every problem the IETF has comes from publishing more documents than are 
needed. Anything that can't be justified is a waste of many people's 
time. Hundreds of hours of labor go into writing, reading, revising, and 
reviewing a document. . . publishing an RFC costs close order of 
US$100,000. That's excluding the opportunity cost of what productive 
thing all those smart people could have been doing with their time.

We owe it to each other and the Internet not to waste time on stuff that 
won't get used.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Oct 2018 10:12:42 +1300

On 2018-10-21 03:08, Lee Howard wrote:
...
> We owe it to each other and the Internet not to waste time on stuff that 

I agree. But that's *always* a judgment call.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2018 08:40:46 +1100

> management point of view.

Can you please provide a description of this threat you think exists
that isn't mitigated by RA guard?

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 20 Oct 2018 23:17:16 +0100

Mark,

On the types of networks that support RA guard, this flag isn't relevant 
because a network access device which supports RA guard is almost 
certain to support ethertype filtering, which is a better overall 
approach for addressing the problem statement in this draft, because it 
works, it's available today and it doesn't require an update of every 
ipv6 stack on the network.

On the types of networks that don't support RA guard, this flag isn't 
relevant because either those networks are small enough that enabling 
this flag won't make much of a difference, or else they implicitly fall 
into the category of unmanaged, but large enough that broadcast traffic 
is considered to be a problem.  This is a textbook network design 
failure and it's not really the business of the IETF to fix broken 
network design.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2018 10:40:30 +1100

> That's an impressive level of gatekeeping there, Mark.

If people are allowed to express an equally weighted opinion without
having read the draft or participated in the WG discussions, then what
is the point of writing drafts or the WG discussions?

It would be easier for everybody if instead of writing Internet
Drafts, we could all just throw together a 10 page slide deck, and
have people form an well thought out and comprehensive opinion in 5 or
10 minutes ...

> otherwise IETF participants.

I don't really understand why more operators don't participate in the IETF.

I'm an operator. I participate in my own time. I signed up to this and
the v6ops mailing lists in 2002, lurked for a while and then started
participating by reading and commenting on drafts. I'm now
acknowledged in quite a number of RFCs, and have written a number of
my own IDs that people have read and provided feedback on.

If what I've said has been listened to and considered on its merit
many times for the past 16 years, then what other people say will be
and has been.

People do need to be willing to present explanation and evidence to
support their statements here; I think some people may have an
expectation that their statements will just be blindly accepted (which
is an appeal to authority), and when they're challenged on them, would
rather say "IETF doesn't listen".

> We owe it to each other and the Internet not to waste time on stuff that

RFC4291bis:

- Reviewed and revised at least 10 times in the WG.

- Passed WG last call.

- Passed IESG review.

- A few people objected at IETF Last Call, and their objections also
showed that they didn't know that what they were objecting to had also
been RFC4291 and its two ancestors - RFC3513 and RFC2373, a period
spanning 16 years at the time. Why hadn't they objected in that 16
years if they felt so strongly? There had been plenty of opportunity
(and it is literally in the name of the document - "Request For
Comments".)

- RFC4291bis now stuck in purgatory.

What makes this worse is that RFC4291bis was editorial and
clarifications, rather than anything radically different from RFC4291
and its ancestors.

What a massive waste of time.

There's a problem if people who aren't fully across the topic can
easily prevent advancement at a very advanced and final stage by
sending a few emails with pretty minimal justification. They should be
required to provide much more justification for their argument (write
up an ID explaining their objections for example) given the amount of
time and effort already spent.

The greater the consequence and cost of abandonment, the greater
requirement for justification for the objection.

We're seeing a similar sort of thing occur with this ID. The most
discussion about this draft and potential objections to it is
occurring at WG last call, rather than when the earlier revisions were
published and when it was up for WG adoption. If this doesn't advance,
despite a number of revisions before WG adoption and passing WG
adoption, then it is just more wasted WG time.

People need to somehow be incentivised to review and possibly object
to IDs as early as possible, rather than at much later stages such as
WG LC or IETF LC, when the costs of abandonment are so much higher.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2018 11:14:08 +1100

> ipv6 stack on the network.

Your ignoring the goal of preventing hosts spending their resources
sending packets that have no purpose and that will never succeed.

>From the draft:

--

   o  Similarly, hosts may waste battery power on futile attempts to
      access services by sending IPv4 packets.
--

If that wasn't one of the goals, then in most cases layer 2 frame
filters would be a pretty reasonable prevention. Ideally though, layer
2 filtering needs to be applied literally at the point where the host
attaches to the layer 2 media, and the packets need to be dropped
before any layer 1 and layer 2 link capacity has been consumed.

The updating of IPv6 stacks is quite achievable.

Most of the work we do here doesn't get deployed overnight, I think a
more typical time span we can expect for majority deployment of most
of the IETF work is in the order of 5 or so years (e.g. for something
relatively obscure, the IPv6 Flow Label Spec RFC was published in 2011
and it took until 2017 for Windows 10 to be updated. From memory,
Linux and Mac OS X were updated in in 2014/15 or 2016.)

However, if Apple and Google updated IOS and Android respectively to
support this flag, we'd have billions of hosts supporting it within 2
to 3 years.

As host security issues are becoming more publicly exposed and more
important, hosts being updated is becoming more regular. Portable
end-user devices and "cloud" applications is resulting in many more
hosts having to directly protect themselves from the Internet, because
they're being plugged directly into it, and that is driving the need
for much more regular host OS updates.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 21 Oct 2018 11:46:40 +0100

Mark,

This has been extensively discussed before, but summarising:

- there is only a single anecdote to support the claim in the problem 
statement; a single anecdote is not data.

- 6man is not qualified to determine what makes sense for battery life 
management on power-constrained devices.

- lack of ipv4 default route and arp mappings means that most ipv4 calls 
will not result in any packet transmission.

- For those which result in packet transmission, the code path execution 
which results in ipv4 wake-up calls are also used for ipv6 wake-up calls.

- vendors of power-constrained devices already use plenty of techniques 
to minimise packet transmission when a protocol is not available.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Sun, 21 Oct 2018 14:47:01 +0200

Hi Mark,

> filters would be a pretty reasonable prevention.

And to satisfy that goal, a much more "relaxed" wording can be used than "SHOULD NOT attempt any IPv4 operations". Reducing the frequency of DHCPv4 polling and disabling APIPA would already make a huge difference for the goal you mention above. I would think enough to satisfy the requirement.

And then, in the world we are moving towards, I think that giving up more easily on IPv4 should be the default, and I would suggest to OS implementers that this should be their default behaviour when they see IPv6 on the link and no IPv4.

Which makes the risk/cost/benefit ratio of this flag quite bad. Giving up on IPv4 should be the default, and this flag is not necessary.

Cheers.
Sander

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Oct 2018 09:17:56 +1100

Hi Sander,

On Sun., 21 Oct. 2018, 23:47 Sander Steffann, <[email-masked]> wrote:

> And to satisfy that goal

a much more "relaxed" wording can be used than "SHOULD NOT attempt any IPv4
> operations". Reducing the frequency of DHCPv4 polling and disabling APIPA
> would already make a huge difference for the goal you mention above. I
> would think enough to satisfy the requirement.
>

If the interface emits any IPv4 packets at all, the goal hasn't been
achieved. If the interface processes received IPv4 packets at the IPv4
layer, it hasn't really been achieved either.

IPv4 has not been switched off on that host for an IPv6 only link.

This flag would allow IPv4 to be switched off entirely for an interface,
with switching off IPv4 meaning more than just not performing DHCPv4.

It could also mean the IPv4 stack doesn't see the interface at all (e.g.
IPv4 socket calls can't see the interface, and if they refer to the
interface specifically they get an error) and link layer protocol demuxing
for IPv4 types can be disabled (e.g. type 0x800,0x806 if received on that
interface are not handed to the IPv4 stack.

The interface would only support IPv6 plus any other non-IPv4 protocols
e.g. LLDP.

If may even be possible to disable broadcast link layer frame reception in
the network card, since IPv6 only uses multicast (from memory, it is common
for ethernet NICs to have registers that enable/disable unicast, broadcast
and multicast reception.)

So even if there are ARPs or other IPv4 broadcasts like DHCPv4 Discovers,
which become link-layer broadcasts, they would be dropped by the NIC
itself, without interrupting the devices main CPU. These interrupts are one
of the things that deplete mobile devices batteries, because they can wake
up the device from energy saving sleeping. (Multicast address filters in
NICs can also limit what multicast traffic interrupts the device's main
CPU.)

> And then, in the world we are moving towards, I think that giving up more
> easily on IPv4 should be the default, and I would suggest to OS
> implementers that this should be their default behaviour when they see IPv6
> on the link and no IPv4.
>

How does a host positively know there is no IPv4 and intentionally no IPv4
on the link?

Absence of evidence is not evidence of absence.

Absence of a DHCPv4 server at the time of making a DHCPv4 Discover doesn't
necessarily mean there is no IPv4 on the link, it may also mean that the
DHCPv4 server is down at the time, a transient falt, or may mean a
transient period of packet loss (STP reconvergence for example).

When all distinct IPv6 RAs received by a host have this flag set, it is a
positive statement by the network operator that "yes, host, this link is
IPv6 only, no IPv4, so don't bother trying to use IPv4 at all - don't even
try DHCPv4 Discover."

This flag is the evidence from the network operator that IPv4 is
intentionally absent, because the link only supports IPv6.

Regards,
Mark.

> Which makes the risk/cost/benefit ratio of this flag quite bad. Giving up
> on IPv4 should be the default, and this flag is not necessary.

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Sun, 21 Oct 2018 22:40:18 +0000

From: ipv6 <[email-masked]> On Behalf Of Mark Smith

> How does a host positively know there is no IPv4 and intentionally no IPv4 on the link?
>

After reading points and counterpoints for all this time, I'm wondering if the best idea might not be to forego any such flag in the IP layer, and instead put the onus of any no-IPv4 operation on the OSs. It seems that the most credible reason for doing without IPv4 is for power-constrained hosts. Just let the OSs of such hosts probe the network, see if they can use IPv6 only, and move on from there.

E.g., need a printer? Try IPv6 first. If you find a printer, don’t even try IPv4. Need to route? Listen for RAs first, try IPv6 end to end to whatever you need, first. And so on.

This should work fine in home nets and the like. For well-managed enterprise nets, just filter at L2. Hosts that don’t work, with IPv4 shut off, probably don’t belong in that enterprise net anyway. Or, for labs and so on, the savvy lab folk can surely build a little IPv4 island, within the lab. That's easy. Bring your own switch(es).

> When all distinct IPv6 RAs received by a host have this flag set, it is a positive statement by the network operator that "yes, host, this link is IPv6 only, no IPv4, so don't bother trying to use IPv4 at all - don't even try DHCPv4 Discover."

Well, not 100% true even there. First, all routers have to have the flag set, and second, the lab environment issue again.

Perhaps it's time for a paradigm shift, away from routers, and to increased heuristics in modern dual stack OSs.

Bert

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Oct 2018 15:04:17 +1100

> > On Sun, 21 Oct 2018 at 09:17, Nick Hilliard <[email-masked]> wrote:

<snip>

> statement; a single anecdote is not data.

The impact of excessive amounts of link-layer broadcasts and IPv4
broadcasts on LANs has been well recognised for a long time.

"But broadcasts must be used with discretion, since all hosts that
receive one incur a certain amount of software overhead, if only to
discard it."

"Failures can also be caused by malfunctioning software; ,for example,
a program that repeatedly transmits broadcast packets can have a
devastating effect on the performance of every host on the network."

- "Practical Considerations in Ethernet Local Network Design", by
Ronald C. Crane and Edward A. Taft, October 1979, revised February
1980
https://ethernethistory.typepad.com/papers/PracticalConsiderations.pdf

4.7, "MINIMIZE BROADCAST ACTIVITY"

- RFC1001, "PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
TRANSPORT: CONCEPTS AND METHODS", 1987.

> management on power-constrained devices.

The authors of BCP202 are participants here. One of them works on Android.

> will not result in any packet transmission.

most != all.

Hosts will still be sending DHCPv4 DISCOVER packets which are
link-layer broadcast frames that get flooded to all hosts on the link,
even if the RFC2563 option is used.

> which results in ipv4 wake-up calls are also used for ipv6 wake-up calls.

Those code paths won't be executed for IPv4 if IPv4 is disabled on the
an interface.

Doing nothing is always more efficient than doing something and then
discarding it.

> to minimise packet transmission when a protocol is not available.

minimise != none.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Oct 2018 07:51:42 +0200 (CEST)

>From reading other postings here I think there is no consensus for a 
"hotplate hands-off" to turn off IPv4 as soon as you see this option.

However, as part of a heuristic to say "ok, I'm seeing this flag and I 
have not received any 0x0800/0x0806 frames ever since I attached even when 
I tried DHCPv4, so I'll turn off IPv4 until I see some IPv4 frames again" 
this might be successful.

Because for the typical BYOD use-case even link-local IPv4 is used to 
connect to printers and similar devices. So there is nobody sending RAs 
and there is no DHCP server on the link, but devices can still interact. 
Saying that this flag in combination with never receiving any IPv4 related 
packets ever, might convince the people doubting the use.

This would mean that hosts are expected to turn off IPv4 as per your 
description when it sees this flag AND the network filters 0x0800/0x0806 
frames (or the host is the only IPv4 speaker in the broadcast domain).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Sander Steffann <[email-masked]>
Date: Mon, 22 Oct 2018 08:00:51 +0200

Hi Mark,

> Op 22 okt. 2018, om 00:17 heeft Mark Smith <[email-masked]> het volgende geschreven:
> 
> Hi Sander,
> 
>> a much more "relaxed" wording can be used than "SHOULD NOT attempt any IPv4 operations". Reducing the frequency of DHCPv4 polling and disabling APIPA would already make a huge difference for the goal you mention above. I would think enough to satisfy the requirement.
> 
> If the interface emits any IPv4 packets at all, the goal hasn't been achieved. If the interface processes received IPv4 packets at the IPv4 layer, it hasn't really been achieved either.

Whoa. You said yourself that hosts wasting battery power on IPv4 is the main reason for this flag ("If that wasn't one of the goals, then in most cases layer 2 frame filters would be a pretty reasonable prevention."). Jumping from there to "don't emit/receive any IPv4" is quite a leap. And as I have said before: one that is not technically justifiable considering the risk/cost/benefit ratio.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Oct 2018 18:44:22 +1100

On Mon., 22 Oct. 2018, 17:02 Sander Steffann, <[email-masked]> wrote:

> >> a much more "relaxed" wording can be used than "SHOULD NOT attempt any
> IPv4 operations". Reducing the frequency of DHCPv4 polling and disabling
> APIPA would already make a huge difference for the goal you mention above.
> I would think enough to satisfy the requirement.
> >
> Whoa. You said yourself that hosts wasting battery power on IPv4 is the
> main reason for this flag

No I didn't say it was the main goal.

I said it was one of the goals that Nick is not recognising when he says
that layer 2 filters are adequate or equivalent.

("If that wasn't one of the goals, then in most cases layer 2 frame filters
> would be a pretty reasonable prevention."). Jumping from there to "don't
> emit/receive any IPv4" is quite a leap.

And as I have said before: one that is not technically justifiable
> considering the risk/cost/benefit ratio.
>

I expect you may not have any experience with large LANs that where built
in the 1990s, running IPX and/or Appletalk, where flooded link-layer
broadcast and multicast traffic could be a problem.

Cheap IPv4 routing, VLANs, plenty of address space via RFC1918s and the
convertion of using /24s for subnet addressing simplicity (i.e. 3rd octet
is the subnet ID), with the trade off for that addressing simplicity being
limiting the number of devices to 253 in a LAN, means link-layer broadcast
traffic levels have not been as issue in IPv4 networks in recent times.

I think IPv6 is likely to change that, as I remember what people were doing
with IPX and Appletalk before IPv4 came along, because IPX and Appletalk
(Phase II) didn't have a small number of addresses limit on a link either
(IPX has 48 bit host addresses, Appletalk Phase II does have a limit of 253
(or close to that) for a single network number, however similar to IPv6, it
properly supported multiple network numbers on a link ("cable range")).

With IPv6 the 253 device constraint goes away while still retaining
addressing simplicity.

People will keep attaching devices to the existing IPv6 link while they can
and until they encounter some other constraint, because that is what we did
on IPX and Appletalk networks. For a while CSMA/CD collision rates was the
first likely constraint to encounter until switches came along.

On an IPv6 only link, one of the possible constraints will be IPv4
link-layer broadcasts due to DHCPv4 DISCOVERS that will not and never be
answered.

Putting in a DHCPv4 server just to tell the hosts there is no IPv4 doesn't
eliminate the link-layer broadcasts from DHCPv4 DISCOVERS.

Remove those link-layer broadcasts, and the next possible constraint could
be IPv6 multicasts (assuming in none of these cases unicast capacity isn't
the constraint).

However, with MLD snooping, they become directed to interested nodes rather
than flooded to all of them. MLD snooping increases multicast forwarding
scaling, there will still be no IPv6 numbers of addresses on the link
constraint, so even more IPv6 nodes can be attached to the same link.

So unless there is some other reason to divide hosts up into separate IPv6
subnets (e.g. security domains) then I think there will be much larger IPv6
subnets than we've seen in recent times with IPv4. Attaching a new IPv6
host to an existing IPv6 subnet is the simplest, quickest and easiest
option.

At some point the link does reach capacity, there is no way to completely
avoid that. However the link capacity constraint imposed by IPv4 addressing
conventions disappear with IPv6.

On an IPv6 only link, IPv4 should not only not and never be the constraint
on how many devices can be attached, it shouldn't even be present, and
hosts attached to that link shouldn't be wasting their resources even
trying to send them.

Regards,
Mark.

---

From: Sander Steffann <[email-masked]>
Date: Mon, 22 Oct 2018 10:13:09 +0200

> I expect you may not have any experience with large LANs that where built in the 1990s, running IPX and/or Appletalk, where flooded link-layer broadcast and multicast traffic could be a problem.

Thank you for being condescending.

I'm giving up. I have given all my arguments. I'm not continuing to argue against someone who doesn't want to consider others.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Oct 2018 09:45:54 +1100

On Mon., 22 Oct. 2018, 19:13 Sander Steffann, <[email-masked]> wrote:

>
> > I expect you may not have any experience with large LANs that where
> built in the 1990s, running IPX and/or Appletalk, where flooded link-layer

Have you had that sort of experience?

Our perspectives are both influenced by and constrained by our experiences.

> I'm giving up. I have given all my arguments. I'm not continuing to argue
> against someone who doesn't want to consider others.
>

If I wasn't considering others, why would I continue to be engaging,
including repeatedly addressing repeated arguments that have actually been
addressed in the draft?

Considering somebody doesn't mean I have to agree with their position when
it is contrary to my own.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Oct 2018 10:37:27 +0200

> Perhaps it's time for a paradigm shift, away from routers, and to increased heuristics in modern dual stack OSs.

The perspective sounds interesting, but it is much harder to implement. 
(linux kernel can not rmmod ipv4 stack; I guess Windows kernel cant either).

Alex