Re: IPv4 traffic on "ietf-v6ONLY"

[David Farmer <[e-mail]>]

On Wed, Nov 15, 2017 at 5:54 PM, Brian E Carpenter <
[e-mail]> wrote:

> On 16/11/2017 08:15, james woodyatt wrote:
> > On Nov 15, 2017, at 02:47, Philip Homburg <[e-mail].
> com> wrote:
> >>
> >> The safest option to do that is a DHCPv4 option that says 'no IPv4
> service here, go away'.
> >
> >
> > Better: extend ARP with a signal that says, “ARP is not welcome here."
>
> However, the IPv4 traffic seen on ietf-dns64 is negligible and harmless.
> That is a practical indication that this problem probably isn't worth
> solving.
>
> I submit for example that sending a new "not welcome" response to
> ARP requests would do more harm than good, since the legacy hosts
> would probably react badly.
>
>    Brian
>

I'd love to see some data to back up the conjecture, that is the "traffic
... is negligible and harmless"

I completely agree that "a new "not welcome" response to ARP requests would
do more harm than good."

The problem I see is that WiFi airtime is precious, and worse yet broadcast
packets (DHCPv4 discover and ARP) can use excessive airtime in some
situations, more than the fraction of the bits they represent would
indicate.  On a wired network I'm not all that worried, but on WiFi, I'd
like some data on the matter.

On enterprise WiFi, you could filter ethertypes 0x0800 and 0x0806 at the
AP, or they usually have DHCP and ARP proxies, either of which would
prevent sleeping devices from being pestered by the traffic.  However, the
traffic still consumes airtime and that's my concern, especially on large
congested WiFi networks, like at IETF.

Thanks.

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