IPv6 and communication issues over a home LAN

[drossall]

I know what IPv4 and IPv6 are. For various reasons, relating to multiple email accounts and so on, we choose to run a small mail server on my desktop, which my wife's laptop uses for POP and SMTP. We have a BT Home Hub router.

Lately she's found that her laptop will sometimes fail to pick up mail, so I investigated. I tried pinging the desktop (by local network name) and found that the laptop was resolving an IPv6 address to do so (but then timing out). So I wondered if something somewhere was getting muddled and whether restricting the communication to a single protocol would work better.

I tried disabling IPv6 on the router (not easy, limited settings available, but I did disable address allocation, which should do it, and then renew the leases). No change. Then l disabled IPv6 on the laptop. That forced it to use IPv4, and it resolved the desktop's IPv4 correctly, but still timed out.

Next to the desktop. Like the laptop originally, that had addresses in both spaces. So I disabled IPv6 there too. Hey presto, pinging from the laptop got a pong, so to speak, and the email check from the laptop also worked (as you might expect).

I do realise that an IPv6 device can't talk to an IPv4 one without a gateway to translate, but here both machines had both types of address. I'm a bit on the edge of my knowledge. Are there known issues with Windows 10 PCs getting muddled when talking to each other with both protocols available? As above, this is an intermittent issue, not a systematic one.

And for that matter, given a network that also has Android and Apple mobile devices, a not-very-smart TV with a Roku stick, and sundry other stuff, is it better just to stick with IPv4 on the LAN?

[Kim]

IME IPv6 works fine in heterogeneous environments, with the exception of some Android devices which don't handle RAs gracefully in sleep mode, and will close sockets at random.

But it does have to be correctly configured, vis name resolution, firewalling, routing and so on.  Just like IPv4 configuration, some of this is subtle, and it really isn't helped by  a) consumer-grade routers piss-poor or completely absent IPv6 implementations  b) ISPs ditto  c) Google^[1]  d) Microsoft^[2].

There's also a learning curve for the stuff that will be new to those used to IPv4 networking: SLAAC, link-local addressing, privacy extensions, the absence of NAT, what the special prefixes for broadcast and things are, etc.

Turning IPv6 off completely is a viable stopgap solution for small networks, but I don't think it's a particularly sustainable one.

(Consider that your issue may be a name resolution one, rather than an IPv6 one, per se.  Windows on a typical domestic LAN with no DNS server is spectacularly awful at finding things.)


_{[1] They have a philosophical objection to implementing DHCPv6 in Android.
[2] Who are big fans of DHCPv6 and like to make network configuration tasks over-complicated at the best of times.}

[drossall]

Thanks, and yes, those IPv6 things are new to me.

The intermittent nature of the issue could point to name resolution, which is perhaps more subject to inconsistency than the underlying addresses. But some form of resolution was happening, because the Windows ping showed me the IPs it was targeting - that's how I spotted that IPv6 was in use, which I hadn't considered. I recognised the IPv4 address for the desktop as correct, and it didn't change when I disabled IPv6 everywhere. The IPv6 address, being more complex, wasn't something I'd just recognise, and I didn't try checking it on both ends and comparing properly.

Given, as you say, limited access on our consumer router, but no obvious evidence of resolution problem in the form of mismatches or actual resolution failures, how could I investigate further?

[Feanor]

"This is a complex subject, with the need for more than one colour of highlighter."

It depends.
If a device supports IPv6, then it can get it's configuration in different ways.
If it's on a network that is explicitly IPv6 enabled, then the router will provide the configuration.
Most commercial ISPs routers will not support this, but I notice that Sky do.

Otherwise, they will auto-configure using link-local ( fe80:: ) addresses.

In an explicitly configured network, there will usually also be a DNS server which will resolve names to IP addresses.
In an ad-hock network with only link-local addresses, I'm not sure how name resolution works.
In the IPv4 world, in the absence of DNS or WINS, windows would fall back to a broadcast name resolution.
Not sure how non-DNS name resolution works now; all my networks have a DNS server.
I presume there must be an equivalent to broadcast name resolution.

I think that some domestic routers will send configuration to the clients to use the router as a DNS server, and it will then use it's DHCP table to resolve local addresses, then forward external queries to the ISP.  The output of a windows "ipconfig /all" will reveal much of that.

I'd suggest that unless you have explicit control of these things, then disabling IPv6 is probably the simplest option.

[Kim]

I believe mDNS operates on ff02::fb as well as 224.0.0.251  (I know this because I've recently had to dabble with mDNS for the first time for a specific project; like you I have proper DNS resolution on my network and don't normally have to worry about this sort of thing.)  Of course mDNS is a standard, so Windows might not even be using it.

One possibly important factoid for the IPv6 newbie:  DNS names are independent of the IP connection used to resolve them.  Which is to say a DNS server operating on IPv4 will return both A and AAAA records when available, as will a DNS server oprating on IPv6.  Which address is used for a given connection is entirely down to the client software, which is itself constrained by what stack is available.  Tools such as 'ping' may default to either, and often have parameters to specify one or the other.

Trying IPv6 and then falling back to IPv4 is common, and indeed sensible, client (eg. web browser) behaviour.  This means that if you have an IPv6 stack but no connectivity, you may end up waiting for the timeout before an IPv4 connection is attempted to an address with both AAAA and A DNS records, or worse the client may give up entirely without trying the other stack.  On a correctly configured network with only IPv4 internet access, the IPv6 connection should fail with "no route to host" almost instantaneously and make this a non-problem, but of course there are a lot of misconfigured IPv6 stacks out there, and a lot of people with no IPv6 knowledge recommending disabling the entire IPv6 stack as a solution to this problem.

[drossall]

I think I've got some reading up to do. But the possibility of a router with incomplete user control/visibility of its settings interacting with Windows clients with unsatisfactory protocol implementations is not filling me with joy as a first opportunity to practice this stuff...

[Feanor]

The Windows IPv6 stack is actually very good.

[drossall]

Hmmm. Maybe I was too hasty blaming IPv6, and rather it was making the change that made the difference because it reset something. This morning, the laptop can't ping the desktop (and hence can't pick up mail), even on IPv4. It's resolving correctly to the 192.* IP, but then the ping fails. But pinging directly by IP works. So how, if it can resolve the IP, can it fail to ping?

It's calling it desktop.home when I ping desktop, which is a bit odd as we don't use a .home subdomain, but that's probably just MS being weird? As I say, the resolution is correct all the same.

[Kim]

The Windows IPv6 stack is actually very good.

This is true.  Everything since Windows 2000 or so just works.

[pcolbeck]

The Windows IPv6 stack is actually very good.

This is true.  Everything since Windows 2000 or so just works.

I heard a rumour that they got Cisco to redo the whole IP stack for them about then as previously even the IPv4 part was rubbish (badly implemented sliding windows etc). I remember doing some performance testing for a network with older versions of Windows server through line rate switches and file transfer (FTP in the test) was awful compared to an identical server running Unix (cant remember which version), packet trace showed how awful the Windows usage of the bandwidth was, max window size of three I think compared to a huge window on the Unix box once it ramped up the transfer.

[Afasoas]

Hmmm. Maybe I was too hasty blaming IPv6, and rather it was making the change that made the difference because it reset something. This morning, the laptop can't ping the desktop (and hence can't pick up mail), even on IPv4. It's resolving correctly to the 192.* IP, but then the ping fails. But pinging directly by IP works. So how, if it can resolve the IP, can it fail to ping?

I can't explain this. I would install Wireshark on the PC and the laptop and do a traffic capture on both whilst the problem is occuring to see where the ping request / ping response are disappearing.

I would probalby first sanity check that there is only one DHCP server on the network, and that each machine has the same subnet mask.
Also, are the IPv6 addresses getting resolved link local addresses beginning 'fe80:' ?

It's calling it desktop.home when I ping desktop, which is a bit odd as we don't use a .home subdomain, but that's probably just MS being weird? As I say, the resolution is correct all the same.

The .home domain will be coming from whatever is issuing the dhcp lease, the router presumably?

[drossall]

I would install Wireshark on the PC and the laptop and do a traffic capture on both whilst the problem is occuring to see where the ping request / ping response are disappearing.

That's a good plan, thanks.

The .home domain will be coming from whatever is issuing the dhcp lease, the router presumably?

An issue being that I don't have enough settings control in the router to look at that kind of thing. I may replace it (again) - I've already replaced the standard PlusNet one (which is generally regarded as useless) with a BT Home Hub, but I should have bought the business model and didn't - my mistake.