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:

>> No DHCPv4 service on the network.
> 
> That's one possible hint. Another, perhaps better one, would for the host to see if it has any IPv4 default router available at all.

A default (or any) router is not needed for IPv4 to be running and needed - so not really a good hint.

> Are any ARP requests ever received from the network?

Like, from all the other nodes trying to see if IPv4 should be used ? As I said, if some nodes are trying to figure it out, then they'll all see "IPv4 traffic" and assume it needs to be used - so it'll never be shut off.

>> As to whether anyone got anything wrong, well, the flag can also have been wrong. Was there a flag set on all routers, or was the IPv4 router only temporarily unavailable. We can play this game all day long.

Yes, we can compare apples and oranges all day. If the flag is set incorrectly then that's a positive action the administrator has taken - and if "stuff breaks" then the administrator can undo that action. In the same manner, perhaps we shouldn't allow administrators to manually set DNS servers in DHCPv4 - after all, if they set it wrong it will break the network !
If (or rather, when) the heuristics fail, you get random network failures which will be a right PITA to diagnose and even harder to fix. In practice I expect it would be a case of visiting each host and manually over-riding the heuristics.

> I realize that many like to shut off ICMP, but ICMP would provide any number of hints too, when available, such as, ping the default router.

The problem you have is that you are only considering the sort of network you seem to be familiar with. There are lots and lots of network topologies - some of which are isolated networks with no routers.
As I said earlier, one of the most "irritating" problems to deal with are those caused by vendors making assumptions about the network their equipment will be connected to. Such as having a UI that won't allow ".0" or ".255" as an address (assumes all networks are /24), UI that won't allow 192.168.x.x addresses to have larger than a /24 network (assumes 192.168 addresses are class C and won't allow supernetting, assume that the router will be doing DNS and don't allow other addresses to be used (the user won't want to use other servers), don't allow DHCP to be turned off (this must the the only router on the network), don't allow the default router address to be set in DHCP (again assumes this is the only router), etc, etc.
And you propose that the vendors come up with much more complicated, obscure, and harder to deal with assumptions about the networks the equipment be connected to.


> I just don’t think it's very difficult for a clever host to probe the network for IPv4 service, which would serve the same purpose as the flag. And I don’t see a very convincing argument that a small number of such tests would be more prone to failure than a flag?

OK, write down the rules to be used. No hand waving about "if <this> then that's a hint" - solid unambiguous rules, "if <this> then <that>".

Some hints to guide you :
There may (actually, almost certainly will) be devices on the network that won't be trying to turn off IPv4. They may be IPv4 only devices that the network admin doesn't care about breaking. So bear in mind that you can expect to see some IPv4 traffic on an "IPv6 only" network.
You may be on a network without a default router and/or without DHCP. Neither can be taken to signal lack of IPv4 service.
Some networks (part of the reason for support for this flag) don't have facilities to filter at L2, so on these networks you'll see all broadcast traffic.

So over to you, if it's not very difficult then you'll have no trouble will you ;-)


> So, put the onus on the equipment vendors, in case the netadmin wants to shut off IPv4, to determine how to proceed.

That's the surest way to guarantee failure. Without a standard to work to, you will get zero or more different ways - and if more than zero, then guaranteed interoperability issues. Most likely the vendors will turn round and say "so how do you want it doing ?" and we'd be back to discussing a network wide flag of some sort.