Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Simon Hobson <[e-mail]>]

Manfredi (US), Albert E <[e-mail]> wrote:

>> You've missed the fact that most nodes these days will autoconfigure a link-local IPv4 address. So "no address = no protocol" doesn't work. "no address (other than link-local) = no protocol" doesn't work either as it would break any network using link-local addressing - they do exist.
> 
> No problem, right? With the IPv6-ony flag set, what would a host do? If it does autoconfigure an IPv4 address, maybe to talk to some old printer

OK, explain how the device is to know whether or not it should be turning on IPv4 to see if there's an IPv4 printer it needs to talk to ?
If it does turn on IPv4, then you've missed the opportunity to save battery power generating IPv4 packets.
If it doesn't turn on IPv4 then it won't know if the printer is there to be found.

And since the printer may not be switched on when it first does the checks, then it would need to keep IPv4 on "just in case".

> There is nothing here that the flag changes.

Yes there is.
If the host sees that all RAs carry this flag set, then they can know that the admin is declaring that there aren't any IPv4 only devices that the device need be bothered with. It can leave IPv4 turned off, and not worry about not finding something it might need to.

IFF there is an old IPv4 only printer that the user needs to access, then the admin would not set this flag. The point you continue to miss is that the humans responsible will know what is and isn't there, and what can and can't be ignored. So if (for example) all printers (and other devices) are now IPv6 enabled OR ARE BEING DEPRECATED, then it's OK to set this flag.
There is NO WAY WHATSOEVER for ${random_device} to know this. It cannot differentiate between IPv4 traffic that's there because there are IPv4 only devices it may need to communicate with, and IPv4 traffic that's there because some devices haven't turned it off and you have no need to talk to them via IPv4.

I could even imagine networks where DHCPv4 is still provided, there is still IPv4 being actively used by legacy devices, but this flag is set because any device "new enough" to understand this flag and act on it doesn't need to still use IPv4.

If you think a device can figure out all this by itself, then again I suggest you write down explicit rules.


> And besides, who knows what hosts will do when they receive that IPv6-onky flag. We are simply speculating. Whether the better heuristics, or this new flag, makes little difference.

Well the advice in the RFC is to stop using IPv4. If they don't then it won't break anything else on the network, it'll just prevent them taking advantage of the battery/CPU/memory usage savings available.

> And our new heuristics can do exactly the same thing, without a flag. To conserve power, try first IPv6, and use only IPv6 if it works. If not, give IPv4 a short try.

So IPv6 works - as it should on any IPv6 only **OR** dual-protocol network. So why do you think that gives you any clue about whether IPv4 is still in use ?

> A host might still want to go to that old printer which only uses IPv4

In which case, the admin won't set the flag - if they do then that's a misconfiguration just the same as setting wrong information in DHCP would be. Really this is just basic network admin stuff - like "don't turn off your IPv4 routing if there are still IPv4 only devices needing it" !

> Reliably and automatically is to allow the device to use IPv6 and IPv4, i.e. the default. It will do just what the flag intends.
> 
> I just don’t see why the insistence on this flag, if I can do just as well without, and furthermore, without having to trust a net admin to set this flag.

You still don't get it do you. Continuing to use IPv4 when it's no longer supported on the network has a cost - it takes power, CPU cycles, memory, and network bandwidth. For battery powered devices, any saving is desirable; for wireless networks, bandwidth saving is desirable. So by having devices use this information, they can have better battery life, and all users of the wireless network can have better performance.

> The simple fact is, no one is begging for this flag

Well they have been begging for this flag - enough to keep this discussion going through quite a few revisions of the text etc.

> An equipment vendor serious about saving power has other options he can pursue on his own.

No they aren't - you have yet to come up with plausible rules for a host to do this on it's own. And remember, these rules need to work both for the IPv6 only networks **AND** not break any other networks the device may connect to.

> A network operator serious about preventing IPv4 chatter is perfectly capable of L2 filtering, wherever that's available,

L2 filtering does not completely remove the chatter - devices will still be sending ARP packets, they can still generate link-local addresses, they can still send (eg) mDNS packets. OK, filtering them will reduce (possibly eliminate depending on where it's done) the re-broadcast of them on the wireless network - but it won't prevent them being generated and taking up some bandwidth.

> Either way, the only hosts which will NOT holler, when you shit off IPv4, are the updated ones. Updated to read this flag, or updated with the better heuristics, makes no big difference.

Again, you've missed the point - it's not about hosts hollerin, it's about allowing hosts to operate more efficiently. It's already been talked about - "what about the legacy devices ?". Well these will be no worse off when you remove IPv4 services from the network, but they could actually be better off with the chatter removed from the devices that honour this flag.