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

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

Another response to multiple points:
 
> If people really care, they should just program the local routers and switches to block the IPv4 related multicast traffic. That will be much more direct than a bit in some RA.

Layer 2 or layer 3 blocking is fine, but it doesn't help
the battery life of the dual stack hosts.

> How about a transition rule for dual stack implementations? If there is IPv6 connectivity, don’t bother trying to establish IPv4? Maybe qualify that rule with availability of a 6to4 prefix?

I really hope you didn't mean "6to4". But that heuristic will only help
if all apps are IPv6-capable, which the IP stack cannot know. (It also
leaves IPv4 literals out in the cold.)

> 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...

The proposal addresses only one thing: attempting to reduce
futile IPv4 traffic. It neither creates nor blocks IPv4 traffic.

> In very high dentistry and therefore
> typically congested WiFi environments...

A new view of dentist's office networking ;-)

> Probably the best that can be done by the client is to be "less aggressive" in trying to configure IPv4 when IPv6 is available and you don't seem to see IPv4 traffic from other nodes.

Indeed, but that's mainly an implementation choice. This proposal offers
a hint to assist that heuristic, if you like.

> Let's not forget about battery life.

Agreed. Every little helps.

> It just seems operationally simpler to create a new option in dhcpv4

I don't see how that works on a network with no DHCPv4 server.

> if IPv4 appears you probably want to start
> using it after a reasonable amount of time.

Indeed. And under the proposal, any RA with flag==0 would be
an instant trigger to wake up the IPv4 stack. (And no, that
isn't a serious DOS risk, since it is no worse than what
we have today.)

   Brian