[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv4-only network and your Linux host operates a dual IPv4/IPv6 stack ... Re: BerkeleyLUG, have AC power, Wi-Fi & Internet ...

Well, yes and no.  ;-)  (who could'a guessed I would say that?).
dual stack IPv4/IPv6 generally doesn't cause issues
*in-and-of-itself* ... but it *can* (often mostly indirectly)
cause lots of issues/headaches ... in certain circumstances.

In general (at least it's a nice theory!) dual stack is not an
issue, and on well behaved networks, and with reasonably well behaved
clients, it's not.  Ah, but therein lies the rub.
Earlier in the IPv6 days, there were many many many buggy clients
(and other IPv6 bugginess) ... thankfully most of that is quite gone.
Nowadays, most of the issues are with networks and firewalls.

E.g. fairly common issue.  Dual stack network environment, client hosts
given IPv4 & IPv6 addresses and routes ... so far so good.
But, alas, *access* (or further routing thereof) very different,
e.g. connectivity to TCP pots 80 & 443 works great on IPv4,
but alas, fails on IPv6 because somebody put firewalls in (e.g. in
$work environment) that are passing IPv4 to TCP ports 80 & 443, but
not passing IPv6 traffic to TCP ports 80 & 443.  Now of course, e.g.
typically browser client, has no way to know the firewalls are not only
quite unfriendly in that regard, but quite inconsistently so and
discriminating against IPv6.  So client has no reason not to treat
IPv4 & IPv6 equally ... so it tries ... and
maybe about half the time or so it tries IPv6 ... and it fails, ... so,
having IPv4 also (in general case), it likely retries over IPv4 ... but that
can add lots of latency as all the IPv6 failures are waited on, timed
out, then retried over IPv6 ... and with no "memory" - in general,
on the part of the client or client's operating system, to move towards
favoring IPv4.  (The situation could also be reversed regarding IPv4 and
IPv6, but that's not as common).

So, ... how to fix that?  Well, first, what *not* to do.
Don't disable IPv6.  These days, there's really no reason not
to (also) be running IPv6.  If/where it gives one grief, treat
that as a bug - and fix it - or as necessary/appropriate, work around
the issue until it's fixed.  Disabling IPv6 effectively hides all those
issues, rather than leaving them where they can at least be checked on,
and work-arounds dropped as things get fixed.
And, more specifically on client?  One can do things like use a -4 (or -6)
flag in many cases, or adjust relevant configuration file(s) to favor
IPv4, or favor it communicating to certain servers or over certain routes.
One can also drop the non-local routable IPv6 IPs - at least in more
severe cases - or drop certain routes.  If the host can't route there via
IPv6 - and knows that based on its own routing information, then it
can't and won't even try IPv6 for that.  But there's, e.g. no reason
whatsoever to disable local and non-routable IPv6.  At present for
current supported operating systems, that should be considered an
integral part of the operating system, and shouldn't be disabled.
And for the most part, all those local and non-routable bits work
find these days - quite to highly rare anyone still runs into quite
significant issues still remaining there on most anything that's
current, supported, and reasonably mainstream.

Anyway, your mileage/experiences may vary ;-) ... but that's at least
approximately as I see it at the present time.


From: "Rick Moen" <rick@linuxmafia.com>
Subject: Re: BerkeleyLUG, have AC power, Wi-Fi & Internet ...
Date: Tue, 15 Oct 2019 14:43:53 -0700



Quoting tom r lopes (tomrlopes@gmail.com):


Ipv4 good but maybe a bit of latency :-).


If you're on an IPv4-only network and your Linux host operates a dual
IPv4/IPv6 stack, you can run into a situation where your host
continually attempts an IPv6 socket, waits for timeout, connection
fails, and only then attempts fallback to IPv4.  This is super-annoying,
dumb behaviour, of course, but might (or might not) be what you
perceived as 'maybe a bit of latency'.

To test, do an experimental 'dig' across the Internet with the IPv4-only
flag.  It's the '-4' flag, and there's a corresponding '-6' flag for
IPv6-only.

If that test reveals your stuck in the dumb-fallback scenario, there
are ways to force your stack (for that time period) to do IPv4-only.
I'm not going to spend time looking that up now, yet again, but it's
not difficult.


--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20191015184624.1253381nf0q2u3cw%40webmail.rawbw.com.