Re: Alternatives to the flag (Was:Confirmation to advance: draft-ietf-6man-ipv6only-flag-05)

[David Farmer <[e-mail]>]

On Wed, May 15, 2019 at 9:10 AM Nick Hilliard <[e-mail]> wrote:

> David Farmer wrote on 15/05/2019 14:27:
> > Ok, I could live with that. But, when I've heard this kind of thing
> > discussed before there were serious objections to it. The objections I
> > remenber heraing were the change you propose effectivly breaks local
> > printing from a dual-stack host to an IPv4-Only printer if there are any
> > problems with the local DHCP server.
> >
> > So, I'm not willing to drop what I think is a viable solution to the
> > problem unless other stakeholders are willing to buy into this kind of
> > change. In particular, I'm thinking the people maintaining mDNS in dnssd
> > wg. I can't see making the change proposed above without their buy-in.
> >
> > In theory, an IPv4 stack could passively detect the filtering of
> > Ethertype 0x0800 and 0x0806 by passively looking for other ARPs and/or
> > IPv4 service discovery traffic. However, both of these types of MAC
> > layer broadcast traffic are typically suppressed on most WiFi networks
> > by the use of proxy ARP and service discovery proxying or other forms of
> > control or filtering to limit MAC layer broadcast which is very
> > inefficient on WiFi.  And, battery-powered WiFi devices is where
> > suppressing the futile IPv4 traffic is most useful in this whole
> discussion.
> >
> > So I think we either need the flag or disable RFC 3927 by default on
> > dual-stack hosts.
>
> Mikael kindly pointed out that I misread your email.
>
> If there are ipv4 ethertype filters in place, RFC 2563 will obviously
> not work because dhcp requests will be blocked. This means that any
> traffic from the host device to the network will be broadcast (ARP) or
> multicast (mdns) only.
>
> MAC layer broadcast/multicast from AP to host is inefficient on WiFi
> because it uses basic rate, but we're talking here about a network with
> L2 ACLs in place, so this won't happen.  Host to AP broadcast/multicast
> frames are sent by unicast to the AP, i.e. normal transmit rate, which
> is efficient in terms of power usage.  That said, the low priority
> nature of mdns can be used to deprioritise transmission of these frames,
> i.e. coalescing transmits with other ipv6 packets, so that you don't end
> up with chip wakeups.


Ok, maybe I buy that, can someone tell me if that done today?


> Also, you can heuristically determine that if
> there are no mdns replies on ipv4 but plenty on ipv6, that ipv4 isn't
> active on the network.
>

So please expand on how you heuristically determine you don't need mDNS or
maybe IPv4 LL especially in the presence of ARP and service discovery
proxies which are common on WiFi to suppress MAC Layer broadcasts. Which I
believe makes it had to passively see others host's broadcast. I suppose
you could do an mDNS query for all host on the network and then get back
nothing and decide you are on an IPv6-Only network. But then how would you
know for sure you just aren't the only mDNS speaker on a dual-stack network
at the moment.

Talking this through, if you Layer 2 filter on IPv6-only, I agree that you
prevent any IPv4 traffic from waking up other devices on the network. But
dual-stack battery-powered devices will still produce futile IPv4
DHCPDISCOVERS, exponential back-off work for this. I'm not too worried
about the initial round, I think that is good power spent for now since the
host probably on a dual-stack network, not an IPv6-Only network. However,
I'm not seeing a good heuristic for squelching the IPv4 LL service discover
traffic. Now, I'm ok with what Philip proposed just don't do RFC3927 on
dual-stack hosts, but I don't think other stakeholders will go for this,
but I could be proved wrong.

So without a good heuristic for squelching the IPv4 LL service discover
traffic, battery-powered devices will futilely generate traffic, now I
grant you these devices won't use any more power than they would on a
dual-stack network, and in fact maybe a little less because they will never
receive IPv4 back in response. But if this traffic could be squelched,
there would be power savings, but you seem to be claiming this isn't worth
the effort. I think this is where we disagree.


If there are no MAC ACLs in place, then RFC 2563 provides a solution to
> ipv4 mdns chatter.
>
> Either way, the justification for another flag seems to be limited.
>

A good heuristic for squelching the IPv4 LL service discover traffic isn't
obvious to me.

Dropping RFC3927 on dual-stack hosts would work, but I'm skeptical of
needed buy off for that plan.

I'd be open to changing my mind with a good heuristic for squelching the
IPv4 LL service discover traffic, without it, the justification for the
flag is good enough for me.

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================