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

[Lee Howard <[e-mail]>]

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


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