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

Dumb question: is it necessary, when there is a network in which IPv4 is disabled, to say that it is disabled? What does that accomplish?

From my perspective, if the DHCP server is disabled from an IPv4 perspective, it will stop responding to requests for an IPv4 address. Hosts can then build IPv4 link-local addresses if they choose, and communicate using them, but IPv4 will have no network services. Either IPv6 works or the network doesn't work for IPv4 traffic.

My thought is that we don't have a way to say "IPv6 is disabled here"; either IPv6 works or it doesn't. I don't quite see what is really different when the shoe is on the other foot.

> On Sep 8, 2017, at 7:52 AM, Lee Howard <Lee@asgard.org> wrote:
> 
> 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
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops