Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

[Nick Hilliard <[e-mail]>]

Sander Steffann wrote on 28/05/2019 09:44:
>> Doesn't solve the problem of hosts needlessly, wastefully and 
>> persistently trying to acquire IPv4 addresses that they'll never
>> get.
>> 
>> It's making hosts into hamsters in wheels, activity with no
>> progress.
> 
> Hosts that persistently keep asking for IPv4 leases despite being
> told "no" can be fixed much easier than by adding a new flag to
> IPv6... And hosts that keep misbehaving can't be expected to
> implement the flag either.

stepping back up the problem stack a bit, no adequate problem 
characterisation has been performed. So far, a single ipv6-only 
deployment case has been identified which merits some examination in the 
context of the draft's problem statement, namely large partially-managed 
wifi networks with BYOD.  Fully managed networks can use host management 
or ACLs to block ipv4 chatter.  Fully unmanaged large wifi networks are 
outside scope.

Last week with the help of some RIPE NCC staff, we did some rough 
characterisation of background chatter on the nat64 network at the RIPE 
meeting in Reykjavik.  The results showed that by packet count, in 
excess of 60% of the background ipv4 traffic was mdns and another 20-25% 
was netbios.  The remainder was a mixture of things (ARP, SSDP, random 
link-local, etc). Less than 1% of packets were DHCP requests.

These are very rough figures btw, i.e. barely anecdote-grade, but they 
suggest that support for the RFC2563 DHCP flag to disable IPv4 LL 
addresses should be sufficient to squish the overwhelming bulk of ipv4 
background noise.  If the numbers are even remotely representative of 
longer term data, then the remaining chatter would be operationally 
irrelevant.

We're planning to set up a more comprehensive set of counters at the 
next ripe meeting to get some better quality numbers.

Nick