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

From: Lee Howard <[email-masked]>
Date: Fri, 08 Sep 2017 10:52:54 -0400

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

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Sep 2017 09:56:17 -0700

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 <[email-masked]> 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?
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lee Howard <[email-masked]>
Date: Fri, 08 Sep 2017 14:03:02 -0400

On 9/8/17, 12:56 PM, "Fred Baker" <[email-masked]> 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

>>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?
>> 
>> 	• May still route between multiple segments of the site network, and
>> 	• 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?
>>

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Sep 2017 12:23:10 -0700

> On Sep 8, 2017, at 11:03 AM, Lee Howard <[email-masked]> wrote:
> 
> 
> 

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. 

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

---

From: David Schinazi <[email-masked]>
Date: Fri, 08 Sep 2017 13:08:47 -0700

While most Modern Operating Systems™ have good IPv6 support now, there will always be that one device in your home that supports neither IPv6 nor IPv4 link-local. Because of those, I don't think removing DHCPv4 from the home is worth doing in the next decades. I also don't think this should be handled by the IETF - as far as I know there was no RFC saying "stop using AppleTalk", it just went away when vendors felt that supporting it cost more than it was benefiting. The same will be true of IPv4, eventually. If the IETF wants to spend energy on sunsetting IPv4, I think it should be used on improving and documenting transition mechanisms like NAT64.

David Schinazi

> On Sep 8, 2017, at 12:23, Fred Baker <[email-masked]> wrote:
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Sep 2017 11:36:32 +1200

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

I agree. Apart from religious reasons, who cares if IPv4 is providing useful
legacy services in the home for the next seventy years? For example, there
are innumerable IPv4-only DHCP-using printers around, which are accessed in
ways that don't seem to involve DNS. Where's the harm?

It is presumably written somwhere that a DNS resolver in a CE that has no
Internet IPv4 connectivity MUST NOT return off-site A records; if not,
it should be.

Does anything need to be said about mDNS? Again, where's the harm in
using mDNS when there is no WAN IPv4?

>>               monitoring or logging of IPv4 will be in place.

Who says there will be no IPv4 monitoring or logging when there is no
IPv4 WAN connectivity?

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Sep 2017 09:17:30 +0200 (CEST)

> network is down, even if they have IPv6. Or so it is alleged; I have not 

With modern software, this seems to work better. It was not working 
properly a few years back, then it was several OSes that decided that lack 
of IPv4 was "no network". Win10, OSX and recent Ubuntu for instance, all 
this this is fine. It might take a bit longer to decide this, but it still 
works.

> device manufacturers decide to stop including IPv4 in their devices?

I would prefer if there was a signal to indicate "there is no IPv4 here". 
I'm fine if this is treated similarily to the M/O flags in IPv6 RAs, in 
that they're a signal and the client can choose to ignore them if it wants 
to.

An IPv6 flag meaning something like "as far as I know, there is no IPv4 on 
this LAN, do what you want with this information".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Sep 2017 14:26:47 +0200

> It is presumably written somwhere that a DNS resolver in a CE that
> has no Internet IPv4 connectivity MUST NOT return off-site A records;
> if not, it should be.

That would break local validating resolvers. Personally I dislike DNS
resolvers that lie, how well intentioned it may be.

I guess the proper way to solve the issue of only local IPv4 connectivity
is to have a DHCP option that lists which IPv4 prefixes are reachable.

Then a host can avoid installing a default route but install only routes for
the listed prefixes.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Sep 2017 08:34:17 +1200

On 12/09/2017 00:26, Philip Homburg wrote:
> That would break local validating resolvers.

Can you explain that a bit? Since the record concerned is useless,
why do we care whether it validates? Or would this somehow affect the
validation of AAAA records for the same domain?

In other words, how is this different from a case with IPv4 connectivity
when there is in fact no A record?

> Personally I dislike DNS

Fair enough, but it's matter of choosing the least bad solution.

> That won't work for legacy hosts that don't know about that option, and
> we really need to allow for legacy hosts.
That won't work for legacy hosts that don't know about that option, and
we really need to allow for legacy hosts.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Sep 2017 22:56:36 +0200

>validation of AAAA records for the same domain?

It is hard to tell what is going to happen when validation fails. That's
local policy.

One thing that may happen is that the validating resolver will consider the
local resolver in the CPE to be broken and sets up a TLS (or similar)
connection to a remote resolver, by passing all of this filtering.

>when there is in fact no A record?

The DNS record types available for a domain name are listed in the NSEC/NSEC3
record.

So if the query for 'A' results in a empty RR then the validating resolver
will look for a NSEC/NSEC3 record that confirms that this is indeed the case.

>we really need to allow for legacy hosts.

I assume that in the future there will be systems that can talk IPv6 and need
to know what IPv4 resources are locally available. Those systems would 
benefit from a new DHCP option.

Legacy systems that only talk IPv4 don't really care. They are limited to
whatever is locally available anyhow.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Sep 2017 12:59:02 +1200

> will look for a NSEC/NSEC3 record that confirms that this is indeed the case.

Ah, I see. That is a problem.

> whatever is locally available anyhow.

The thing is that if a home network includes a Windows 98 client and a
Windows 10 client, and has no WAN IPv4 service, there will be dual stack
sites that are accessible from Windows 10 and unreachable from Windows 98.
That translates into help desk calls.

I see a bright future for 464XLAT.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Sep 2017 11:14:36 +0200

>I see a bright future for 464XLAT.

464xlat or one of the many other ways of tunneling IPv4 over IPv6. But I assumed
that sunset is when there no (global) IPv4 access at all. 

What I am now wondering about is a form of NAT46/DNS46. I.e. host sends
an 'A' query to a DNS resolver, DNS resolver does a 'AAAA' look up and maps
the resulting IPv6 address to an address in 10.0.0.0/8. And then the NAT46
module would translate traffic.

This would allow legacy hosts to connect to the IPv6 internet.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Sep 2017 11:47:35 +0200 (CEST)

On Tue, 12 Sep 2017, Philip Homburg wrote:

> 464xlat or one of the many other ways of tunneling IPv4 over IPv6. But I 
> assumed that sunset is when there no (global) IPv4 access at all.

Sure, but I also think that it's a viable thing to contemplate what host 
support there should be to access legacy IPv4 resources over an IPv6 only 
access. In 10 years or something I can see IPv6 only access being a lot 
more common compared to today, but that long tail is ... long. So having 
hosts being able to access IPv4 resources using for instance NAT64+DNS64 
for older applications will be one component here that will make that 
transistion easier.

> an 'A' query to a DNS resolver, DNS resolver does a 'AAAA' look up and 
> maps the resulting IPv6 address to an address in 10.0.0.0/8. And then 
> the NAT46 module would translate traffic.
>

There has been work done in this space. I think this function would have 
to be done very close to the user, perhaps even in the HGW, or perhaps 
even in the device itself (if it has legacy applications that use the old 
IPv4 only socket API).

On for instance iOS I see it as very viable with the approach Apple has 
chosen by just mandating IPv6 to work. This can be done in a few years, 
applications are revved quite often or they're abandoned (just see now 
with 32bit applications being abandoned on iOS, it's A LOT of applications 
that will not work anymore). People seem to be fine with this.

On PCs, there is an expectation to be able to install older applications, 
and applications that are 10-15 years old sometimes. So I see the need to 
support these older applications, and I guess the only way to do that is 
either do NAT46 in the host or if available in the network, NAT64+464XLAT 
in the host.

The NAT46 approach would work even when not speaking to a DNS64 resolver, 
because this would be internal to the host itself.

---

From: Lee Howard <[email-masked]>
Date: Wed, 20 Sep 2017 11:31:25 -0400

>That translates into help desk calls.

Is that a problem we need to solve?

The successor version, Windows 2000, has 0.00% market share.
https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&
qpcustomd=0

Yes, there are devices that require IPv4 that are much newer than
Microsoft Windows, such as Microsoft Xbox. Someday, those will be so old
that hobbysists will enjoy cobbling ways to get them to interoperate.

Lee

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Sep 2017 19:20:22 +0200

Hi,

> That translates into help desk calls.

If there is a future home network that has IPv6, no IPv4, and *Windows 98*,
IPv6-only is the least of the worries that the owner of said network
should have...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Sep 2017 08:35:18 +1200

> IPv6-only is the least of the worries that the owner of said network

You're missing my point. Obviously Win98 was a provocative example, but the
point is that ISPs will do whatever they have to do to avoid help desk calls.
If switching off IPv4 generates help desk calls, they will never do it. EOM.

   Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 21 Sep 2017 12:57:54 +0200

Hi,

> If switching off IPv4 generates help desk calls, they will never do it. EOM.

True.  But if you can make a few millions by selling off your IPv4 address
block, this might counter a few helpdesk calls...

Gert Doering
        -- NetMaster