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

[Fred Baker <[e-mail]>]

> On Sep 8, 2017, at 11:03 AM, Lee Howard <[e-mail]> wrote:
> 
> 
> 
> On 9/8/17, 12:56 PM, "Fred Baker" <[e-mail]> wrote:
> 
>> 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?
> 
> Debatable, but some use cases are implied by the problems documented in
> the draft.
> 
>> 
>> 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.
> 
> Should a home gateway that doesn’t have an IPv4 WAN address still act as a
> DHCP server?

The question isn't whether some other world uses IPv4, it's whether there is a need for an IPv4 DHCP server inside the home. I don't know that having or not having an address on the WAN interface tells me that. I might have an IPv4 address on the WAN interface and not want to use it from inside the home, and I might not have such an address but need to use IPv4 on the LAN interface. I don't see any reason to presume that the WAN interface tells me anything about the LAN interface.

I would say "yes". The reason is that within the home, IPv4 may still be in use, and 169.254.x.x addresses may not serve it's purposes. The obvious examples of reasons are legacy devices that haven't been replaced/upgraded yet. 

> Some clients interpret a lack of DHCP response as an indication that the
> network is down, even if they have IPv6. Or so it is alleged; I have not
> tested it myself.


> How often does a DHCP client send Discover messages?
> How much ARP traffic is on a network?
> Do we need a way to mute this traffic, or do we just have to wait until
> device manufacturers decide to stop including IPv4 in their devices?

I don't know that *WE* need to think about this. Ripping functionality out of software is often difficult and error-prone. A vendor is unlikely to literally remove IPv4 capabilities; he's far more likely to rewrite the technology and not include it, or provide a way to turn it off (such as never sending a DHCP request because IPv4 is "manually configured"). What if they *NEVER* actually remove it, but everybody stops using it?

>> 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.
> 
> Assumptions (and therefore defaults) change depending on where you start.
> Most people still assume IPv4, even if they also assume IPv6.



> Lee
> 
> 
>> 
>>> On Sep 8, 2017, at 7:52 AM, Lee Howard <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
> 
>