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

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

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Simon Hobson

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

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

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. From DHCP, from listening for router advertisements, or if one is set statically, can it be reached? Does ARP always fail? Are any ARP requests ever received from the network?

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

That would be another hint. Does DNS give me any IPv4 addresses? 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.

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

I mean, it's not like we have a huge mob begging for this flag. Many seem to be unhappy with it, for different reasons. So, put the onus on the equipment vendors, in case the netadmin wants to shut off IPv4, to determine how to proceed.

Bert