Subject: Comments on IPv4-only flag document

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2018 14:42:28 +0700

Playing back my comments at the mike:

1. I don't think it's useful to say that IPv4 should be enabled if the
default router lifetime goes to zero. The default router lifetime going to
zero is a normal occurrence, e.g., when the router loses uplink
connectivity. I would say that the flag is valid in all cases. If the
network says it doesn't have IPv4, and it doesn't have working IPv6, the
host can always disconnect, try another network, or ignore the flag.

2. We should not say that the flag means that IPv6 is "the only ip version
on the link". We don't want this draft to rule out new versions of IP.
Maybe instead of saying "no other versions of Internet protocol" we can say
"no lower-numbered version of the Internet protocol is in use".

3. We should say that this flag has no effect if IPv4 configuration has
already succeeded (e.g., the host has obtained a valid configuration from
DHCPv4). This should address many of the security questions that have been
raised.

Cheers,
Lorenzo

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 06 Nov 2018 08:26:09 +0000

> host can always disconnect, try another network, or ignore the flag.

Or use link-local ( and I am not saying v4 or v6 ).

The latest draft no longer says to turn IPv4 back on.  There are to 
cases I see in the draft (both in section 7):

(a) if a host goes from receiving all RAs with the flag set to 1 to a 
state with an RA that has the flag set to 0, “IPv4 operations MAY be 
started”  (no longer SHOULD)

(b) “If the lifetimes of all the routers on the link subsequently 
expire, then the host state for the link is not IPv6-Only.”   Which 
doesn’t say what to do (but I’d probably do the same as above).

It’s “implementors choice” and that’s probably good as some 
might want to try for simplicity and others might say “I have great 
callback mechanisms and unless someone asks for IPv4 I’ll not change 
anything”.  As you said “over-specifying” will never fit for 
everyone.

People will realise that once they were working IPv6-only going back to 
IPv4 makes little sense.

> "no lower-numbered version of the Internet protocol is in use".

And when we re-use 1235 that will not help either.   This will be the 
“Keep this new stuff out of my network” option so many people 
insisting on having these days.  If they can’t turn IPv4 and DHCPv4 
off currently, they won’t turn that flag off either.  Because it’s 
too hard.  Let them suffer by living in their legacy world and move 
forward.

In addition Section 4 is hinting very good at “we mean no IPv4 
here”.

> DHCPv4). This should address many of the security questions that have 

The latest version of the draft has changed to “MUST” for
   “Administrators MUST only use this mechanism if they are certain 
that
    the link is IPv6-Only.  For example, in cases where there is a need
    to continue to use IPv4, when there are intended to be IPv4-only
    hosts or IPv4 routers on the link, setting this flag to 1 is a
    configuration error.”

That is essentially what you are asking for.  “If there is working 
IPv4 (services|forwarding) this flag is a configuration error”.   As a 
host-side implementor I’d read this as “I MAY keep doing IPv4 in 
this case”.

/bz

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Nov 2018 09:37:27 +0100

> (b) If the lifetimes of all the routers on the link subsequently
> expire, then the host state for the link is not IPv6-Only.   Which
> doesnt say what to do (but Id probably do the same as above).

Not switching back makes for a really nice attack vector on an 
IPv4-only network without RA-guard: wait an incoming DHCPv4 discover and
send an RA with the IPv6-only set. Brilliant. 

It's great to have a draft that just consists of a new attack vector and
nothing else.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2018 15:39:40 +0700

On Tue, Nov 6, 2018 at 3:26 PM Bjoern A. Zeeb <
[email-masked]> wrote:

>    “Administrators MUST only use this mechanism if they are certain that
>     the link is IPv6-Only.  [...]
>

No, it's not what I'm asking for. That text doesn't address the case where
the RA was sent by an attacker on an IPv4-only network that is currently
working just fine. That is the case for the majority of networks today.
Such networks very likely don't have RA guard because they have never had a
need for it.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 6 Nov 2018 10:01:04 +0000

Lorenzo Colitti wrote on 06/11/2018 08:39:
> No, it's not what I'm asking for. That text doesn't address the case 
> where the RA was sent by an attacker on an IPv4-only network that is 
> currently working just fine. That is the case for the majority of 
> networks today. Such networks very likely don't have RA guard because 
> they have never had a need for it.

this is part of the reason that this draft is so objectively harmful: it 
encodes a protocol-level security vulnerability which will apply widely 
to most networks except those which have actively managed layer 2 
security mechanisms in place.

These networks could be - as you indicate - ipv4-only in the sense of 
not having any ipv6 routers, but will be ipv6 enabled to the extent that 
many hosts will have ipv6 RA solicitation configured by default because 
there is no admin to turn it off; they have no RA guard, and no real 
possibility of getting RA guard, because that requires active management 
and a realisation that without careful configuration, bad things could 
easily happen.

Just because the text doesn't address this case, this doesn't mean that 
someone with malicious intent won't address the case.

What does the IETF say to the victims of this form of attack?  That 
their use case is not addressed and is therefore out of scope?

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Nov 2018 17:12:10 +0700

> their use case is not addressed and is therefore out of scope?

I proposed that what the IETF should say about this is: if a host already
has a working IPv4 configuration, it SHOULD NOT not turn it off on receipt
of an IPv6-only flag.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 6 Nov 2018 21:37:46 +1100

Working != ipv4 link local. 

-- 
Mark Andrews

> On 6 Nov 2018, at 21:12, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> I proposed that what the IETF should say about this is: if a host already has a working IPv4 configuration, it SHOULD NOT not turn it off on receipt of an IPv6-only flag.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 06 Nov 2018 14:11:14 +0000

On 6 Nov 2018, at 8:39, Lorenzo Colitti wrote:

> where

Ok, so in Section 9 there’s a paragraph starting with

“A bad actor could use this mechanism to attempt turn off IPv4 service 
[..]”

If that paragraph would be more explicit:

A bad actor could use this mechanism to attempt turn off IPv4 service
    on a link that is intentionally using IPv4, by sending Router
    Advertisements with the IPv6-Only flag set to 1.

If a host has working IPv4 services or connectivity and receives a 
Router Advertisements packet with the IPv6-only flag set to 1 on the 
same link without any other IPv6 configuration (i.e., an otherwise 
IPv4-only link), it SHOULD consider the IPv6-Only flag a configuration 
error and MAY continue to use IPv4.

In the case that there are one or more legitimate routers on that link 
sending Router Advertisements
    with this flag set to 0, they would override this attack given the
    mechanism in Section 5.

(and continued as there is already)

Would that work for people?

/bz

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Nov 2018 14:28:05 +1300

Sorry I was unable to be on meetecho, but let me try to respond to
this thread in a single message:
On 2018-11-06 20:42, Lorenzo Colitti wrote:
> connectivity. 

Yes, but at that moment we cease to have a current signal of the
admistrator's intention. It seems to me that in terms of the law
of least astonishment, it's more correct to drop the IPv6-only 
assumption at that time.

> I would say that the flag is valid in all cases. If the

It can always do that anyway.

> "no lower-numbered version of the Internet protocol is in use".

Fair enough, although that's a far-future issue...

> DHCPv4). This should address many of the security questions that have been

I'm not sure. Maybe the administrator is about to switch off IPv4 services
and is announcing this by setting the flag? On the security issue, see later.

On 2018-11-06 21:37, Philip Homburg wrote:
(in reply to Bjoern)

> send an RA with the IPv6-only set. Brilliant. 

If it's an IPv4-only network, it has no RA-guard by definition. Yes,
as noted in the draft, this attack is possible. As also noted in the
draft, "this is really no different than what such a bad actor can do
anyway, if they have the ability to configure a bogus router in the
first place." In such a situation the network is wide open to a wide
variety of IPv4-based or IPv6-based attacks. Yes, this draft offers
one more option for the attacker. (Same response to Nick Hilliard's
message in this thread.)
 
> It's great to have a draft that just consists of a new attack vector and

Now that's just polemic. Of course we have to make a judgment call
whether the mitigations this proposal brings outweigh the risks.

> Working != ipv4 link local.

Indeed. The flag actually conveys no information related to link-local
operations. It only describes the admin intention for routing, DHCP
and DNS/IPv4 services.

On 2018-11-07 03:11, Bjoern A. Zeeb wrote:

...
> error and MAY continue to use IPv4.

I don't strongly object to this text, but as noted above, it may not
be an error or an attack: it may be an announcement by the admin that
she just switched off the IPv4 services. 

BTW, the "MAY continue to use IPv4" is always true, as implied by the
SHOULD language in the draft.

Regards
   Brian

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Nov 2018 11:37:35 +0700

Brian,

On the last point:

> ....

This was one of the conclusions in yesterday’s 6man discussion.  I think it is reasonable to have the draft be explicit that if the host has working IPv4 connections (for example, via addresses received from DHCPv4, not auto configured IPv4 addresses) then the flag can be ignored.

The case that started the idea in this draft was the IPv6-Only link at IETF 100 meeting in Singapore, where there were no IPv4 services.   The goal is to turn off the background auto-configured IPv4 traffic and resulting ARP, etc.   Having this clarification will turn off this auto configured traffic, but at the same time make the flag more robust against attacks or misconfiguration on links with working IPv4 services.

Bob

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 12:07:00 +0700

> one more option for the attacker. (Same response to Nick Hilliard's

Brian, I really think we're never going to get consensus on this document
unless it's clear that it does not introduce a new severe security issue,
even if similar security issues don't exist today.

> operations. It only describes the admin intention for routing, DHCP

Um, no? That's not what the draft says at all. It says that a host "SHOULD
NOT attempt any IPv4 operations".

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Nov 2018 19:17:11 +1300

> even if similar security issues don't exist today.

I'm fine with Bob Hinden's response that arrived half an hour before yours.

> NOT attempt any IPv4 operations".

Yes, because that is (presumably) what the admin wants. But the factual
statement the admin is making is what I said: there's no routing, DHCP
or services over IPv4 (as per the definition of IPv6-Only in section 4).

(We have both a protocol spec and a recommended behavior in the draft,
and I think that's a bit confusing, but splitting them would be confusing
too.)

    Brian

---

From: Sander Steffann <[email-masked]>
Date: Wed, 7 Nov 2018 15:15:50 +0100

Hi Bob,

> This was one of the conclusions in yesterday’s 6man discussion.  I think it is reasonable to have the draft be explicit that if the host has working IPv4 connections (for example, via addresses rec…

Yep, I'd be happy with that. Let clients try to get IPv4 running, but when they fail then the flag can tell them "yes, that's intentional". As long as the flag helps devices making the right decision instead of prescribing they "SHOULD NOT attempt any IPv4 operations" completely.

Although I think device implementations will move in that direction even without this flag. As IPv6-only network become more and more common there is less and less benefit for them to aggressively keep retrying IPv4. So I'm not convinced that we even need this flag, but as long as it's just a hint to stop retrying after they already failed to get IPv4 it's not hurting anyone.

It's the "I don't want to see a single IPv4 packet on the network so they shouldn't even try IPv4 when this flag is set" way of looking at it that I am very strongly opposed to.

Cheers!
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 7 Nov 2018 15:01:58 +0000

Sander Steffann wrote on 07/11/2018 14:15:
> Hi Bob,
> 
>> This was one of the conclusions in yesterday’s 6man discussion.  I
>> think it is reasonable to have the draft be explicit that if the
>> host has working IPv4 connections (for example, via addresses
>> received from DHCPv4, not auto configured IPv4 addresses) then the
>> flag can be ignored.
> 
> Yep, I'd be happy with that. Let clients try to get IPv4 running, but
> when they fail then the flag can tell them "yes, that's intentional".
> As long as the flag helps devices making the right decision instead
> of prescribing they "SHOULD NOT attempt any IPv4 operations"
> completely.

If the semantics of the flag were changed to mean this, then it would 
not be worth implementing, for the reasons that you gave.

Also, from a helicopter point of view, ipv4 addressing strategies fall 
into three main categories: static, dhcp and rfc3927.  If this flag is 
ruled out of scope for static and dhcp configurations, then all that's 
left is rfc3927 ipv4 link-local.  We already have a flag in DHCP to 
instruct clients not to attempt rfc3927, so once again we're at a point 
where suggestions to make the ipv6only flag more palatable have reduced 
the scope of the flag to the point of it being irrelevant.

Also, these proposed semantics would allow a situation where it would be 
difficult to recover from certain types of targeted attacks if a DHCP 
server went offline, then a host came online, received some malicious 
ipv6only flags, then the dhcp server came back online again, but at that 
stage, the host would have disabled ipv4 so it couldn't recover until 
the malicious host stopped transmitting ipv6only packets.  So changing 
the semantics like this is not going to fix the underlying security 
issues, even if they are masked to a degree.

Nick

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 07 Nov 2018 15:41:28 +0000

On 7 Nov 2018, at 14:15, Sander Steffann wrote:

Hi,

>> think it is reasonable to have the draft be explicit that if the host 
>> has working IPv4 connections (for example, via addresses received 
>> from DHCPv4, not auto configured IPv4 addresses) then the flag can be 
>> ignored.
>
> As long as the flag helps devices making the right decision instead of 
> prescribing they "SHOULD NOT attempt any IPv4 operations" completely.
>
> Although I think device implementations will move in that direction 
> even without this flag. As IPv6-only network become more and more 
> common there is less and less benefit for them to aggressively keep 
> retrying IPv4. So I'm not convinced that we even need this flag, but 
> as long as it's just a hint to stop retrying after they already failed 
> to get IPv4 it's not hurting anyone.
>
> It's the "I don't want to see a single IPv4 packet on the network so 
> they shouldn't even try IPv4 when this flag is set" way of looking at 
> it that I am very strongly opposed to.

I can see where a lot of people here coming from.  I can see two world 
views.

What you describe in the last two paragraphs is what I call “clinging 
to history”.  To me it seems that you are living in an IPv4 world 
where this new IPv6 thing comes into.  It’s the history book page to 
me.

The other side of people here have long moved beyond that.  IPv4 is 
legacy for them.  They have gone through the process of getting rid of 
it as much as they could.  They didn’t see most of the problems people 
are discussing here as a problem, an obstacle, a real world problem, 
something common sense hadn’t dealt with in the process of migration 
and maybe a bit of swearing.  My default view is IPv6; IPv4 is the 
noise.  For these kind of people (like me) it is a point of “get rid 
of this IPv4 thing as I don’t want to see it anymore as there should 
be none here, so please don’t even try; if you have the urge to even 
try you are in the wrong place”.

It is a world of people being anxious about their IPv4 world, which they 
are so familiar with, going away as they haven’t made the step forward 
yet into the IPv6 (well not future anymore but day-to-day common 
business), and people who have made that step (a while ago) being 
depressed to still having to deal with a past they want to let go off.

I think while the IPv6-Only flag draft brings this out as a tip of the 
iceberg, it’s been the general problem during the last decade.  
Everyone who’s been brave and moved to dual-stack and then/or quickly 
to IPv6-only as this was the only vision they could see to survive 
long-term and not waste resources is happily smiling.  And I love to see 
smiling people.

No-one said the ride might not be bumpy.  The problems from 8 years ago 
are mostly long solved and people can focus on other things, but as 
it’s been more and more people from individuals to companies moving 
Terabits/s of IPv6-only traffic around the globe, the chances of a 
smoother ride increases every minute.

I sometimes have the feeling that people expect IPv6 to be the nice 
shiny problem free world and until it is that they won’t go there;  
don’t forget all the disasters you went through in the last 30 years 
of IPv4.  You survived them.  IPv6 will be no different to it.  A swiss 
army knife, a bit of duct tape, and a solution that isn’t 101% 
foolproof will still be with you at times.  Otherwise your life would be 
boring, your job would be obsolete, and you’d face other problems.  
The view a lot of people have is “I’d rather only deal with one of 
these worlds rather than two, so keep dual-stack to a minimum and move 
beyond that already.”

The question is:  do we want to hold on to a past, or think about a 
future (which might not be as scary as people think)?  Do we want to 
write a page for a history book, a page for today’s problems (which 
should have been solved years ago by pro-active people looking ahead), 
or a vision of the future world?

I don’t oppose to people saying “Ahh! But my IPv4!” and I respect 
that even if I can barely still think that way, but please also respect 
the view of others already saying “Baah! That IPv4.”.  In order to 
do that both sides have to accept the other currently exists;  yes it 
makes the document longer and more complicated than it needs to be for 
only one world view;  the only fact I see is that one world is going 
away and the other one has arrived.

All the best.  Survivors photo in 2020.

/bz

---

From: Sander Steffann <[email-masked]>
Date: Wed, 7 Nov 2018 17:28:52 +0100

Hi Bjoern,

> What you describe in the last two paragraphs is what I call “clinging to history”.  To me it seems that you are living in an IPv4 world where this new IPv6 thing comes into.  It’s the history book page to me.

HAHAHAHAHA! You have apparently never met me :)  My whole career is about deploying IPv6.

> For these kind of people (like me) it is a point of “get rid of this IPv4 thing as I don’t want to see it anymore as there should be none here, so please don’t even try; if you have the urge to even try you are in the wrong place”.

Why such a strong desire to avoid any IPv4 packets on a network? I understand the need to get rid of unnecessary chatter, but letting clients try to get IPv4 addresses once in a (long) while isn't going to hurt anyone. Your argument sounds more evangelical than technical. Those who want to get rid of IPv4 that badly in places where it technically matters have other options anyway. If those options aren't available it's an unmanaged network like home networks and I also see no place for this flag on those. There is no admin there that can make the decision to turn the flag on.

> [...]
> 
> I don’t oppose to people saying “Ahh! But my IPv4!” and I respect that even if I can barely still think that way, but please also respect the view of others already saying “Baah! That IPv4.”.  In order to do that both sides have to accept the other currently exists;  yes it makes the document longer and more complicated than it needs to be for only one world view;  the only fact I see is that one world is going away and the other one has arrived.

I am a big promoter of IPv6, but reality is that IPv4 is still around (no matter how much I want to move beyond that). Minimise IPv4, of course! It needs to dwindle and disappear, the sooner the better. But adding a flag to IPv6 to kill IPv4 isn't going to make that happen. Making everything available over IPv6 will, so that IPv4 isn't needed anymore. And at that time devices will adapt and stop caring about IPv4. A flag might make them do that a bit faster, but there is no point in forcing them and potentially breaking things in the process.

And the cost of such a flag isn't worth it. It's another thing people have to learn about, making IPv6 even more difficult for them. IPv6 is a really flexible protocol. Nice for us fans who have been picking this stuff up over the years, but horrible to those who have to learn it from scratch now to be able to do their job. I have done dozens of training sessions, and the RA flags are the most "scary" bit for most of the students. Adding more flags isn't going to help them to deploy IPv6. Not everybody running a network is as much of an expert as the people on this list, and we have to remember that. KISS.

Cheers,
Sander

---

From: Bob Hinden <[email-masked]>
Date: Wed, 7 Nov 2018 23:40:55 +0700

Sander,

> On Nov 7, 2018, at 9:15 PM, Sander Steffann <[email-masked]> wrote:
> 
> Hi Bob,
> 

Well the draft says SHOULD, so it didn’t say that.

In any case, we are working on some text for the draft to address the don’t stop existing IPv4 issue, I hope to get it to the list for review tomorrow.

Thanks,
Bob

---

From: Sander Steffann <[email-masked]>
Date: Wed, 7 Nov 2018 17:52:17 +0100

Hi,

> Well the draft says SHOULD, so it didn’t say that.

"SHOULD NOT attempt any IPv4 operations" leaves the possibility for implementers to ignore the flag, but it still says to completely switch off IPv4. There are more levels of action:
1) SHOULD NOT attempt any IPv4 operations
2) SHOULD give up on IPv4 if initial attempts fail
3) SHOULD retry IPv4 at a much lower frequency
4) ignore the flag

Option 4 is what legacy devices will do. I see serious problems with 1. Much less so with 2, and as good as none with 3. Considering the rationale behind the flag, and considering legacy devices that will still send IPv4 packets anyway and will experience connectivity issues if other devices turn IPv4 off completely, I see no justification for 1. Options 2 and 3 are still on the table as far as I'm concerned :)

> In any case, we are working on some text for the draft to address the don’t stop existing IPv4 issue, I hope to get it to the list for review tomorrow.

Thanks!
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 7 Nov 2018 17:13:15 +0000

Bjoern A. Zeeb wrote on 07/11/2018 15:41:
> It is a world of people being anxious about their IPv4 world

it's nothing of the sort.  The overwhelming majority of people don't 
know and don't care whether they get their cat videos over ipv6 or ipv4. 
  The people who build networks care about the total cost of ownership 
of their products rather than deployment of one particular protocol or 
another.

IPv6 deployment has gone as far as it's gone because the cost balance 
has made it worth peoples' time to deploy in bulk in specific 
circumstances, e.g. larger scale access networks (DSL, DOCSIS, cellular) 
and specific types of bulk hosting (e.g. CDNs, content carriers, and 
some high volume hosting sites).  The rationale for migration is based 
almost exclusively on the amortised total cost over timeframes that are 
relevant to the business in question.

The cost points that matter are: voluminous availability of ipv6 
addresses; the fact that the combination of functionality deficit 
between it and IPv4 has narrowed to the point that it's now usually 
feasible to deploy in specific bulk-provisioned end user systems; the 
cost of using ipv4 now being quite high, and because the cost of 
brown-field deployment is bearable if you have economies of scale (e.g. 
costs relating to initial deployment, debugging, support, front-line etc).

The long tail of smaller network deployments is moving at a snail's pace 
as far as ipv6 is concerned.  For many of these networks, ipv6 still 
makes little business sense because the economies of scale that make it 
worth it for larger companies don't work for smaller companies.  They 
can handle the $15/ip address capital cost because it doesn't matter 
much for a couple of /22s.

Don't misinterpret this email as a defense of ipv4 - it isn't.  It's 
just an unsentimental view of how networks are built and managed, which 
is often at odds with many of the views aired on 6man or even v6ops at 
the IETF.  We need to stop kidding ourselves in these working groups, 
and take a more realistic approach to how ipv6 is used and will be used 
in the real world.

This includes taking a critical approach to proposals which lack, for 
example, operational justification, or architectural justification, or 
vendor support, or are limited in deployment scope, or open up security 
problems, or have a high cost of deployment in terms of network 
complexity or direct cost.  The ipv6only-flag draft unfortunately falls 
into several of these categories.

BTW, you should take this utilitarian approach to ipv6 as a good thing 
because it means that ipv6 has matured to the point that it's deployable 
on most networks.  Deployment will happen on the basis of ipv6 being 
better than ipv4; that will happen naturally, all by itself. There's no 
need for the IETF to get involved in that process.

Nick

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 07 Nov 2018 22:38:24 +0000

On 7 Nov 2018, at 16:52, Sander Steffann wrote:

>>> they shouldn't even try IPv4 when this flag is set" way of looking 
>>> at it that I am very strongly opposed to.
>>
> "SHOULD NOT attempt any IPv4 operations" leaves the possibility for 
> implementers to ignore the flag, but it still says to completely 
> switch off IPv4. There are more levels of action:

Ok, as an implementor I see 50% of the idea missed in your list already 
(which is where complexity can come from):

(a) no IPv4/ARP packets in or out so that the total sum on the network 
goes down, the noise goes away, the broadcasts quiesce, ..  This is the 
“cleanup the network” and take off load of the upper half of the 
stack and application on RX processing side.

(b) save the planet (or my energy costs, i.e. my laptop and phone 
battery) even more:  in addition to not having to process so many 
packets anymore, I can stop applications doing IPv4 as well, or any of 
your list above, in order to save CPU and other peripherals power as 
well by limiting the upper half of the stack and application of the TX 
side.

If I think of doing this:

(a) is 50-100 lines of code on a per-link decision and done quickly 
nicely and has great gain but people don’t like it.

(b) is f*beep*ing complex, has to touch so many kinds of applications, 
often has to teach them about per-link behaviour, takes ages of time to 
implement, test, possibly upstream, ..  unless you can just turn them 
off and on like with a light-switch.

If you want a fully flavoured (b) this draft is too expensive to 
initially do and I can see why $OS-Vendor would say “no” even if 
they could save battery lifetime.  If you can do (a) and light switch 
(b) along with it for the worst bits of noise-generators, you can do it 
quickly, easily, and get it deployed.

K.I.S.S.

/bz