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

[Simon Hobson <[e-mail]>]

Mark Andrews <[e-mail]> wrote:

>> I'd expect that, say, you spell out the cases that made you use "SHOULD"
>> rather than "MUST". Put another way: what are the scenarios that you
>> have already envisioned where hosts shouldn't disable the IPv4 stack?
> 
> When you as the administrator of the host know that the administrator of
> router erred.

From the OS vendor PoV, that's not a valid statement. The OS vendor does not know anything about your network - so really this is a case of providing a host specific configuration flag to over-ride something. In that respect, it's no different to manually configuring IPv6 addresses, manually setting routes, etc.

>> Or the network might not use IPv6 itself, but nodes might need IPv4 for
>> "peer to peer" stuff withing the network (whether transferring files,
>> printing documents, etc.). And those services are not provide by "the
>> network", so the networrk admin doesn't have much of a say about them
>> (i.e., he/she might not even know about apps that might require IPv4).
> 
> Then the network is not IPv6-only and you shouldn’t be setting the flag.
> 
> You can do a thousand "what if someone does something stupid”.

Indeed, and if you wanted to cater for all possible such admin errors then you might as well go home because the more you make something foolproof, the more ingenious you find the fools are.



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

-----Original Message-----
From: Brian E Carpenter <[e-mail]> 

> So, the network doesn't want to support IPv4. Is it not possible for the devices on the network to use their own updated heuristics? Their own timeout timers, without having to rely on the network admin? This much we already discussed briefly, earlier on. Is it not just as easy to tell device makers that some networks may be dropping IPv4 altogether, and let these device makers do what's right, instead of saying that the network will transit this flag, to achieve that same purpose? Either way, the hosts will need updating. (Some device makers will eventually give IPv6 priority.)


OK, go ahead and state how you think that might work :D
Lets look as some possible clues to look at.

No DHCPv4 service on the network. Well it could be because the network doesn't do IPv4, or it could be that the server is down or unreachable at the moment, or it could be that devices on this network are manually configured, or it could be that this network is using all self-assigned addresses.

So lets look and see if there's already some IPv4 traffic on the network. So we see some mDNS traffic - does that mean we should be using IPv4, or does it mean that the other device got it wrong. So can't use that as a clue since any device transmitting IPv4 traffic would "wake up" IPv4 on all the other hosts - and it's already accepted that there will almost certainly be devices around that won't recognise this flag, and so will continue trying to use IPv4.

I think it's safe to say that any attempt to "figure it out" would be prone to getting it wrong - quite a lot. One thing I can say from <a few years> in IT is that one of the worst things to come across is some bit of software that makes assumptions about how my network runs. Or put another way, I would be really, **really**, **REALLY** p**sed off to find devices randomly turning IPv4 on/off according to what would appear to be about as reliable as reading the tea leaves. Dealing with that problem would be much much more work than dealing with the problems this flag is intended to solve. Like trying to get serious work in done in MS Word without turning off all the "helpful" auto-something features.