Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Philip Homburg <[e-mail]>]

>Depends a bit on how the flag is refined:

The problem with this flag is that is solves such a remote corner case that 
the flag will cause more problems than it solves.

There are two areas where just keeping the IPv4 stack running as always is a
problem:
1) battery powered devices
2) big wifi networks

In the first case, the heuristics I presented are likely to be enough.
Tweeking mDNS may require some work, but there is no reason to assume it 
can't be done.

A vendor can show up here and say that they tried, and really need a flag.
I haven't seen that yet. At the same time, we can expect many operators to
be ignorant of the flag. So any vendor of a battery powered device will try
to reduce power consumption even if the flag is not set.

In the second case, filtering all IP/ARP traffic is likely to be enough
(the problem is actually sending the multicasts, filtering takes care of that)
We can assume that any professionally run big wifi network has at least RA
guard so telling operators to select equipment that can do ether type filtering
is not a big thing.

Which leaves us with smaller, mostly unmanaged wifi network that don't have
filtering capabilities. Most of the really small wifi networks are not
overloaded, so IPv4 traffic is not an issue. Those networks are often unmanaged
so nobody is going to set the flag anyhow.

In my opinion it is a very bad idea to increase the complexity for everyone
just because some people have an overloaded wifi and can't be bothered to buy
equipment that can do ether type filtering.