Re: IPv4 traffic on "ietf-v6ONLY"

[Brian E Carpenter <[e-mail]>]

Update at the end...

On 15/11/2017 16:31, Brian E Carpenter wrote:
> On 15/11/2017 16:11, Ralph Droms wrote:
>>
>>
>>> On Nov 14, 2017, at 10:07 PM, Brian E Carpenter <[e-mail]> wrote:
>>>
>>> On 15/11/2017 15:59, Lee Howard wrote:
>>>>
>>>>
>>>> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
>>>> <[e-mail] on behalf of [e-mail]> wrote:
>>>>
>>>>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>>>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>>>>
>>>>> Also on the DNS64 network. But it is all one-way, you
>>>>> will notice. No replies as far as I can see. Most of them
>>>>> are sourced from 169.254.*.*, but there are some oddities such as
>>>>> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general
>>>>
>>>>
>>>> Does that return us to the question of how to tell hosts that IPv4 doesn’t
>>>> live here, and to stop trying?
>>>
>>> Maybe. But on the other hand there is no reason in principle
>>> that peer2peer traffic between 169.254.*.* addresses won't work.
>>> (There are reasons in practice, e.g. it doesn't work on Windows 7.)
>>
>> Can you get any sense of how much of the IPv4 traffic is useless?  Would it be useful to try to quench that useless traffic to improve network performance, behavior, operations?  
>>
> 
> At the moment I think it's 100% useless traffic - in the two captures,
> I see messages from many 169.254.*.* addresses and, I think, none that
> are sent to such an address (except 169.254.255.255). Haven't quite
> figured out the Wireshark display filter to be 100% certain

The correct display filter is ip.dst==169.254.0.0/16 and ip.dst!=169.254.255.255
and the result is exactly zero messages with a unicast destination
in 169.254.0.0/16. So I can assert that there is no peer to peer
IPv4 link local traffic, just futile attempts to reach multicast
destinations.

There's quite a lot to 255.255.255.255, with a large majority being 
"Dropbox LAN sync Discovery Protocol".

   Brian