Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

[David Farmer <[e-mail]>]

On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter <
[e-mail]> wrote:

>
> Regards
>    Brian Carpenter
>
> On 19/11/2017 03:39, Jen Linkova wrote:
> > Hi Bob,
> >
> > To be honest I'm not convinced that there is a real problem to be
> solved..
> > The draft says
> >
> > 'A mechanism is needed  to inform hosts that there is no IPv4 support
> > and that they should turn off IPv4.'
> > and it would be great to have more detailed problem statement IMHO...
>
> Indeed. If there is no serious problem, don't fix. What I seemed to hear
> in Singapore was that people weren't happy with just ignoring the small
> amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement
> by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
> traffic, which is more of a burden for the infrastructure. We need to
> decide
> whether we care.
>
> (As to whether this belongs in 6man or sunset4, that's a secondary
> question.
> As for the other comments on this thread, I am too jet lagged to respond
> right now... later.)
>
>      Brian
>

Here is some analysis of the issues as I see them, hopefully this can help
lead us toward a problem statement;

I believe there are two separate issues here;

1. Security exposure; the inverse of the problems discussed in RFC7123,
basically malicious or accidental IPv4 service.
2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,
IPv4-LL, ARP, service discovery, etc...

There are several solutions available already;

A. Filter Ethertypes 0x0800 and 0x806 altogether
B. Rogue DHCP server filtering or DHCP snooping
C. Proxy ARP
D. Service Discovery Proxy or Filtering

How much of an actual problem the issues are and the efficacy of solutions
depends on the type of network technology and the environment its used in;

For wired networks, the residual IPv4 traffic, even the fact that it's
mostly broadcast, isn't a significant issue.  The primary problem in here
is the security exposure, and solution B is usually sufficient protection,
but if that isn't, solution A will totally eliminate this risk.

For WiFi networks it's a little more complicate; low density WiFi
environments are similar to wired networks, the primary issue being the
security exposure, with the same solutions, discussed above. However, there
is an additional secondary issue, the residual IPv4 broadcast traffic could
unnecessarily impact other devices, especially battery powered devices.
Frequently, at least in enterprise WiFi networks, solutions C and D are
implemented to reduce the impact of IPv4 broadcast traffic in operational
WiFi networks, they will have the same effect on the residual IPv4
broadcast traffic in this case.  But, again solution A implemented within
the WiFi network will totally eliminate both the security exposure and the
impact of broadcast traffic on other devices.

However, the residual IPv4 traffic still consumes radio airtime, even if
the WiFi network discards the traffic. In very high dentistry and therefore
typically congested WiFi environments this unnecessary traffic only
increase the over-the-air congestion. Furthermore, broadcast traffic in a
WiFi networks consume more airtime that comparable unicast traffic (worst
case as much as 300 times, but 10-50 times is very typical), increasing the
impact of the residual IPv4 traffic that is mostly broadcast. Only a
solution that keep hosts from generating the residual IPv4 traffic in the
first place can help reduce over-the-air congestion in these environments.

Thanks
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================