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

Agree with your analysis, but the problem I see is that many WiFi networks are very simple, even with high level of congestion, and they may not be able to apply such simple filters. Even home networks may have the same issues.

One way or the other, hosts get updated frequently, but switches, APs and L2 infrastructure don’t, even CEs or small routers in many hotspots don’t get updated.

Also, IPv4-only devices are typically never updated. For example, you buy today an IP camera, and is not easy to find one which is dual-stack. Of course, in this case the problem is different, because they will not work in a NAT64 IPv6-only network …

Because most of this traffic is created by laptops, tablets and smartphones that are the ones with frequently get updated, may be the ideal solution will be something in the stack, not relaying in the router update (so not relaying in RA, options, etc.), that automatically detects the lack of IPv4 support (trying to avoid fake DHCP servers), so they automatically stop sending any IPv4 traffic, or even using IPv4 link-local?

Regards,
Jordi

-----Mensaje original-----
De: ipv6 <ipv6-bounces@ietf.org> en nombre de David Farmer <farmer@umn.edu>
Responder a: <farmer@umn.edu>
Fecha: sábado, 18 de noviembre de 2017, 22:07
Para: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Asunto: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]

    On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> 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:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
    Networking & Telecommunication Services
    Office of Information Technology
    University of Minnesota   
    2218 University Ave SE        Phone: 612-626-0815 <tel:(612)%20626-0815>
    Minneapolis, MN 55414-3029   Cell: 612-812-9952 <tel:(612)%20812-9952>
    =============================================== 

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.