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

[Alexandre Petrescu <[e-mail]>]

Le 19/11/2017 à 08:50, JORDI PALET MARTINEZ a écrit :
> 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.

I tend to agree with this text, Jordi.

Recently I contacted a manufacturer of advanced camera-like lidars.
They do IPv4 only and broadcast to 255.255.255.255.  They request the
user to use closed circuits to avoid the noise due to broadcast.  They
said they dont have plans for IPv6 in the camera, in their roadmaps.

So we filed a ticket to add IPv6 in the device, hoping for some
resolution in a certain future.

Alex

  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 <[e-mail]> en
> nombre de David Farmer <[e-mail]> Responder a: <[e-mail]>
> Fecha: sábado, 18 de noviembre de 2017, 22:07 Para: Brian E
> Carpenter <[e-mail]> CC: 6man WG <[e-mail]>
> 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 
> <[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] <mailto:[e-mail]> 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 [e-mail] 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.
> 
> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>