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

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

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

> Please read the draft again, since it intends to answer that exact question. (Nick and others have objected to some assertions in the text, but regardless of that... the draft intends to answer your question.)

   However, hosts transmitting IPv4 packets would still do so, consuming
   their own battery power and some radio bandwidth.  The intent of this
   specification is to provide a mechanism that prevents such traffic,
   and also works on networks without the ability to filter L2 traffic,
   or where there are portions of a network without the ability to
   filter L2 traffic.  It may also be valuable on unmanaged networks
   using routers pre-configured for IPv6-only operations and where Layer
   2 filtering is unavailable.
   ...
   Because there is no IPv4 support on IPv6-only routers, the only way
   to notify the dual stack hosts that this link is IPv6-Only is to use
   an IPv6 mechanism.  An active notification will be much more precise
   than attempting to deduce this fact by the lack of IPv4 responses or
   traffic.

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

In networks where IPv4 can legitimately be dropped, in principle, the admin will have determined that all legitimate hosts can reach everything with IPv6. EtherType filtering primarily protects the network. If no EtherType filtering is possible in parts of the network, then what help is a flag? The hosts that will create nuisance broadcasts would be unable to read that flag anyway, because they are not updated, presumably. Still, the network can simply not route IPv4, not provide IPv4 addresses in the DNS, not respond to DHCPv4 requests. Without EtherType filtering, IPv4 broadcasts would remain a nuisance in those parts of the network, until those users give up. Yes, legacy IPv4 users will be irritated by long waits, and then failure. But no flag will help that. Those hosts are not updated to read the flag anyway. And updated hosts will have the new heuristics, to minimize or prevent these nuisances.

For networks that support both stacks, but the equipment vendor is serious about conserving battery power, that device may try IPv6 first, regardless of any flag, would adjust IPv4 timers regardless of any flag, and so on. Just to save power. Why rely on a network admin?

   It is expected that on IPv6-Only networks it will be common for
   access to IPv4 external services to be reached by techniques such as
   NAT64 [RFC6146] and DNS64 [RFC6147] at the edge of the network.  This
   is beyond the scope of this document.

In this case, flag or no flag, any device with the updated IPv4 timeout timers, and especially those which try first to use IPv6, will be happy. Devices which will instead waste time insisting on IPv4, are not updated, and therefore, they won’t understand any flag.

   The intent is that the administrator of the router configures the
   router to set the IPv6-Only flag if she/he wants to tell the hosts on
   the link that the link is IPv6-Only.  This is a configuration flag,
   it is not something that the router decides on it's own.  Routers MAY
   log a configuration error if the flag is set and IPv4 is still active
   on the routers interface to the link.

I think I covered that above. It's a bit of a paradigm shift. Even without any new flag, the IETF can make device makers aware of this threat of no IPv4 service in some networks in the near future, and to take their own action. I don’t know how prevalent unmanaged switches are, in parts of the network that a network admin controls, but again, that is for network self-protection, mostly.

Bert