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

[Nick Hilliard <[e-mail]>]

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.  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.

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.

Nick