BerkeleyLUG, have AC power, Wi-Fi & Internet ...
1 view
Skip to first unread message
Michael Paoli
Oct 15, 2019, 8:42:07 AM10/15/19
to BerkeleyLUG
6 of us here presently.
Ample space, have AC Power, etc.
The Cafe's complimentary Wi-Fi only offers IPv4 Internet,
however, also (marginally?) in range of "CalVistor",
which offers both IPv4 and IPv6.
$ curl https://www.ipv4.balug.org/myip https://www.ipv6.balug.org/myip
192.31.105.240
2607:f140:6000:1c:3ea9:f4ff:fe24:656c
$
Ample space, have AC Power, etc.
The Cafe's complimentary Wi-Fi only offers IPv4 Internet,
however, also (marginally?) in range of "CalVistor",
which offers both IPv4 and IPv6.
$ curl https://www.ipv4.balug.org/myip https://www.ipv6.balug.org/myip
192.31.105.240
2607:f140:6000:1c:3ea9:f4ff:fe24:656c
$
tom r lopes
Oct 15, 2019, 3:55:07 PM10/15/19
to berke...@googlegroups.com
Ipv4 good but maybe a bit of latency :-).
Thomas
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20191013131613.453923fwv6mbexwk%40webmail.rawbw.com.
Rick Moen
Oct 15, 2019, 5:43:57 PM10/15/19
to berke...@googlegroups.com
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.
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.
tom r lopes
Oct 15, 2019, 5:58:56 PM10/15/19
to berke...@googlegroups.com
Good to know. I'll have to play with that.
I was joking about the email being almost 2 days late.
I have no idea what happened. I use Gmail. Could be Gmail fault or Google groups or Michael's email or client.
Anyways I'll be at Balug tonight and hopefully you are there too. I'm sure you have some juicy Linux or sys admin horror stories.
Thomas
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20191015214353.GC12847%40linuxmafia.com.
Michael Paoli
Oct 15, 2019, 9:24:25 PM10/15/19
to BerkeleyLUG
Yes bit of, uh, ... "latency".
Google Groups snagged the message for moderation.
Received: by 2002:a25:d3cd:: with SMTP id e196ls2827374ybf.12.gmail; Tue, 15
Oct 2019 05:42:06 -0700 (PDT)
Received: by 2002:a81:a705:0:0:0:0:0 with SMTP id e5msywh;
Sun, 13 Oct 2019 13:16:15 -0700 (PDT)
Once past that, things moved at a much more reasonable speed.
Also, turns out the CalVisitor Wi-Fi had marginal signal,
so it would also drop out. But alas, too, the generally reliable
venue's Wi-Fi was also having some issues - at least intermittently.
Google Groups snagged the message for moderation.
Received: by 2002:a25:d3cd:: with SMTP id e196ls2827374ybf.12.gmail; Tue, 15
Oct 2019 05:42:06 -0700 (PDT)
Received: by 2002:a81:a705:0:0:0:0:0 with SMTP id e5msywh;
Sun, 13 Oct 2019 13:16:15 -0700 (PDT)
Once past that, things moved at a much more reasonable speed.
Also, turns out the CalVisitor Wi-Fi had marginal signal,
so it would also drop out. But alas, too, the generally reliable
venue's Wi-Fi was also having some issues - at least intermittently.
Michael Paoli
Oct 15, 2019, 9:46:25 PM10/15/19
to BerkeleyLUG
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" <ri...@linuxmafia.com>
> Subject: Re: BerkeleyLUG, have AC power, Wi-Fi & Internet ...
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" <ri...@linuxmafia.com>
> Subject: Re: BerkeleyLUG, have AC power, Wi-Fi & Internet ...
Rick Moen
Oct 16, 2019, 2:20:10 AM10/16/19
to BerkeleyLUG
Quoting Michael Paoli (Michae...@cal.berkeley.edu):
> 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.
For now, I'm more than OK with that, if/where it hassles me. Client issues
> 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.
I can easily make go away are ones I don't have to diagnose and fix.
Given that, in such cases I really don't care about ultimate root cause.
> 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
> One can also drop the non-local routable IPv6 IPs - at least in more
> severe cases - or drop certain routes.
Yeah, that'd be a good way to go.
> severe cases - or drop certain routes.
I tend to look up details when I need the information.
Reply all
Reply to author
Forward
0 new messages