[v6ops] LAN behavior when there's no IPv4 Internet access

[Lee Howard <[e-mail]>]

Thank you all for the discussion of covering the gaps identified in
draft-ietf-sunset4-gapanalysis. In particular, I think many of the gaps are
resolved with the revision of rfc6555 Happy Eyeballs.

I wonder, though, what should be the expected behavior of a stub network
when there is no IPv4 Internet access?

My current thinking is that the Internet gateway (IGD, Customer Premise
Router CPR, home gateway, etc.):
* May still route between multiple segments of the site network, and
therefore should be the IPv4 default gateway for those segments.
* Only knows whether native IPv4 is available. It may not be aware of NAT64
or other transition mechanisms where it’s not involved.
So, islands of IPv4 are probable, and that’s okay. Do we need a document
responding to gapanalysis that says so? Do we need to work out how to know
when it’s possible to disable IPv4 completely in a heterogenous unmanaged
site network? Or do we need to sit on these problems for several more years
and wait for IPv4 to become unused in many networks before we can deal with
the gaps?

For reference, here’s the relevant section of sunset4-gapanalysis:
3.1.  Indicating that IPv4 connectivity is unavailable

   PROBLEM 1:  When an IPv4 node boots and requests an IPv4 address
               (e.g., using DHCP), it typically interprets the absence
               of a response as a failure condition even when it is not.

   PROBLEM 2:  Home router devices often identify themselves as default
               routers in DHCP responses that they send to requests
               coming from the LAN, even in the absence of IPv4
               connectivity on the WAN.

3.2.  Disabling IPv4 in the LAN

   PROBLEM 3:  IPv4-enabled hosts inside an IPv6-only LAN can auto-
               configure IPv4 addresses [RFC3927] and enable various
               protocols over IPv4 such as mDNS [RFC6762] and LLMNR
               [RFC4795].  This can be undesirable for operational or
               security reasons, since in the absence of IPv4, no
               monitoring or logging of IPv4 will be in place.

   PROBLEM 4:  IPv4 can be completely disabled on a link by filtering it
               on the L2 switching device.  However, this may not be
               possible in all cases or may be too complex to deploy.
               For example, an ISP is often not able to control the L2
               switching device in the subscriber home network.

   PROBLEM 5:  A host with only Link-Local IPv4 addresses will "ARP for
               everything", as described in Section 2.6.2 of [RFC3927].
               Applications running on such a host connected to an
               IPv6-only network will believe that IPv4 connectivity is
               available, resulting in various bad or sub-optimal
               behavior patterns.  See
               [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further
               analysis.

   Some of these problems were described in [RFC2563], which
   standardized a DHCP option to disable IPv4 address auto-
   configuration.  However, using this option requires running an IPv4
   DHCP server, which is contrary to the goal of IPv4 sunsetting.

Thanks for discussion,
Lee