6:51 p.m.
Hi,
For a while (for a more than 10 Fedora releases) I used to disable IPv6
because I don't use it. It's been a while since I don't but I'm about
to disable it again on my new installation.
Is there a known application/service that might *misbehave* because it
expects a an ipv6 stack these days?
Thanks.
--
Jorge
7:10 p.m.
On Mon, 28 Dec 2020 20:51:46 -0400
Jorge Fábregas wrote:
Is there a known application/service that might *misbehave* because
it
expects a an ipv6 stack these days?
I always disable it because I'm convinced it confuses comcast :-).
The only thing I've ever noticed are occasional log errors
about fedora ntp servers, one of which might only have an ipv6
address (that's my guess anyway).
8:19 p.m.
On Mon, 2020-12-28 at 20:51 -0400, Jorge Fábregas wrote:
For a while (for a more than 10 Fedora releases) I used to disable
IPv6 because I don't use it. It's been a while since I don't but I'm
about to disable it again on my new installation.
Is there a known application/service that might *misbehave* because
it expects a an ipv6 stack these days?
In my case, the biggest consideration is: Does the ISP carry IPv6
traffic?
Mine didn't (and I'm using the biggest ISP in the country). But having
everything *else* in my LAN with working IPv6 meant that they often
tried to use IPv6 by default, and things would stall at every
connection attempt outside of my LAN.
To use IPv6 web services I'd need an IPv4 - IPv6 tunnel that's hosted
outside of my ISP. I don't have a need for that, so I'm not going to
pay for one.
So, I switch off IPv6 features on everything that lets me: The PC's
network interface, my DNS server, web browsers, audio streamers.
--
uname -rsvp
Linux 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
8:29 p.m.
On 29/12/2020 10:19, Tim via users wrote:
To use IPv6 web services I'd need an IPv4 - IPv6 tunnel
that's hosted
outside of my ISP. I don't have a need for that, so I'm not going to
pay for one.
Hurricane Electric tunnels are free.
https://www.tunnelbroker.net/
And they have a server in Sydney, NSW, AU216.218.142.50
I have both native IPv6 assigned by my ISP as well as using an IPv4-IPv6 tunnel on a
laptop for testing
purposes.
---
The key to getting good answers is to ask good questions.
10:44 p.m.
Tim:
> To use IPv6 web services I'd need an IPv4 - IPv6 tunnel
that's
> hosted outside of my ISP. I don't have a need for that, so I'm not
> going to pay for one.
Ed Greshko:
Hurricane Electric tunnels are free.
https://www.tunnelbroker.net/
The key issue is "need." I'm unaware of anything, so far, that
actually needed IPv6. As yet, I think everything is still accessible
through IPv4 (which is probably why my ISP is dragging their heels on
making IPv6 work).
--
uname -rsvp
Linux 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
12:10 a.m.
On 29/12/2020 12:44, Tim via users wrote:
The key issue is "need." I'm unaware of anything, so
far, that
actually needed IPv6. As yet, I think everything is still accessible
through IPv4 (which is probably why my ISP is dragging their heels on
making IPv6 work).
When I first configured the tunnel I didn't "need" it either. But since the
tunnel was free
I figured it was a good opportunity experiment with it and learn about IPv6.
---
The key to getting good answers is to ask good questions.
1:16 a.m.
On Tue, 2020-12-29 at 14:10 +0800, Ed Greshko wrote:
When I first configured the tunnel I didn't "need" it
either. But
since the tunnel was free I figured it was a good opportunity
experiment with it and learn about IPv6.
Fair enough. I've been putting off learning the quirks of IPv6. Yet
another set of numbers to learn about.
--
uname -rsvp
Linux 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
4:26 p.m.
On 12/29/20 7:10 AM, Ed Greshko wrote:
On 29/12/2020 12:44, Tim via users wrote:
> The key issue is "need." I'm unaware of anything, so far, that
> actually needed IPv6. As yet, I think everything is still accessible
> through IPv4 (which is probably why my ISP is dragging their heels on
> making IPv6 work).
When I first configured the tunnel I didn't "need" it either. But since
the tunnel was free
I figured it was a good opportunity experiment with it and learn about IPv6.
Same for me here.
And in some cases I've seen cloud based services (e.g. videoconferences) use IPv6
to reach the cloud provider datacenters. IPv6 direct reachability in that case
could have skipped a middle box bridging two NATted machines, or maybe a different
routing may have lowered the latency. Hard to tell, but if the software opted
for IPv6 there could have been a preference (maybe as simple as a faster ping test).
Regards.
--
Roberto Ragusa mail at robertoragusa.it
5:47 p.m.
On 30/12/2020 06:26, Roberto Ragusa wrote:
On 12/29/20 7:10 AM, Ed Greshko wrote:
> On 29/12/2020 12:44, Tim via users wrote:
>> The key issue is "need." I'm unaware of anything, so far, that
>> actually needed IPv6. As yet, I think everything is still accessible
>> through IPv4 (which is probably why my ISP is dragging their heels on
>> making IPv6 work).
>
> When I first configured the tunnel I didn't "need" it either. But since
the tunnel was free
> I figured it was a good opportunity experiment with it and learn about IPv6.
Same for me here.
And in some cases I've seen cloud based services (e.g. videoconferences) use IPv6
to reach the cloud provider datacenters. IPv6 direct reachability in that case
could have skipped a middle box bridging two NATted machines, or maybe a different
routing may have lowered the latency. Hard to tell, but if the software opted
for IPv6 there could have been a preference (maybe as simple as a faster ping test).
Chances are network admins have configured their systems according to RFC 3484.
See "man gai.conf".
By default IPv6 is preferred over IPv4 Fedora.
The rfc itself (https://www.ietf.org/rfc/rfc3484.txt) has some good examples of how admins
may
adjust preferences.
---
The key to getting good answers is to ask good questions.
4:25 a.m.
On 29.12.2020 07:10, Ed Greshko wrote:
On 29/12/2020 12:44, Tim via users wrote:
> The key issue is "need." I'm unaware of anything, so far, that
> actually needed IPv6. As yet, I think everything is still accessible
> through IPv4 (which is probably why my ISP is dragging their heels on
> making IPv6 work).
When I first configured the tunnel I didn't "need" it either. But
since the tunnel was free
I figured it was a good opportunity experiment with it and learn about
IPv6.
and the most important, this is a good thing to make things IPv6 compatible;
the only device which has disabled IPv6 is my printer as it can't be
configured with a fixed IPv6 - only with SLAAC, which I don't use;
by the way Google's Android hasn't learnt to deal with stateful DHCPv6
yet ...
either IPv6 will be used as the only internet protocol in the future or
it is used only be freaks now?
5:23 a.m.
On 2020-12-28 7:51 p.m., Jorge Fábregas wrote:
Is there a known application/service that might *misbehave* because
it
expects a an ipv6 stack these days?
The Fedora IP stack used to stall for several seconds in several
previous releases. The normal workaround for that was to disable IPv6,
causing pretty massive speedups. That problem went away at about Fedora
32 or 31.
IPv4 has an address-space capacity issue, and is effectively dead. The
allocated IPv4 address space remains tight in North America, and
completely exhausted in most other parts of the world. In my case,
while my internal network remains IPv4 since I use older switches, while
my upstream is IPv6. The only machine that has to be IPv6 internally is
my HP printer. My ISP does not have anywhere near enough IPv4 addresses
to support its large customer base, so they were forced to upgrade most
of their network to IPv6. Their v4-to-v6 translation and vice-versa
works pretty transparently. I haven't noticed any issues for a couple
of years now.
One interesting and nice side-effect of IPv6 is that I get a lot less
drive-by shooting trying to attack my network. I used to get about 3
port-scanning attempts/day, and now I go weeks without an
intrusion-detection hit. I don't think the bad guys have figured out
how to attack IPv6 addresses yet.
--
John Mellor
7:53 a.m.
Let me say up front I'm not very knowledgeable about v6 yet. One reason I
don't want to enable it is the exact flip side of the address scarcity of
v4. Because of that, external connections are nat'd. That seems to me to
offer an additional layer of protection for devices on my network, they
don't have externally routeable addresses. I think that is not true if I
turn on v6. Is this correct?
On Tue, Dec 29, 2020 at 6:24 AM John Mellor <john.mellor(a)gmail.com> wrote:
On 2020-12-28 7:51 p.m., Jorge Fábregas wrote:
> Is there a known application/service that might *misbehave* because it
> expects a an ipv6 stack these days?
The Fedora IP stack used to stall for several seconds in several
previous releases. The normal workaround for that was to disable IPv6,
causing pretty massive speedups. That problem went away at about Fedora
32 or 31.
IPv4 has an address-space capacity issue, and is effectively dead. The
allocated IPv4 address space remains tight in North America, and
completely exhausted in most other parts of the world. In my case,
while my internal network remains IPv4 since I use older switches, while
my upstream is IPv6. The only machine that has to be IPv6 internally is
my HP printer. My ISP does not have anywhere near enough IPv4 addresses
to support its large customer base, so they were forced to upgrade most
of their network to IPv6. Their v4-to-v6 translation and vice-versa
works pretty transparently. I haven't noticed any issues for a couple
of years now.
One interesting and nice side-effect of IPv6 is that I get a lot less
drive-by shooting trying to attack my network. I used to get about 3
port-scanning attempts/day, and now I go weeks without an
intrusion-detection hit. I don't think the bad guys have figured out
how to attack IPv6 addresses yet.
--
John Mellor
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
*Those who don't understand recursion are doomed to repeat it*
8:32 a.m.
Once upon a time, Neal Becker <ndbecker2(a)gmail.com> said:
Let me say up front I'm not very knowledgeable about v6 yet.
One reason I
don't want to enable it is the exact flip side of the address scarcity of
v4. Because of that, external connections are nat'd. That seems to me to
offer an additional layer of protection for devices on my network, they
don't have externally routeable addresses. I think that is not true if I
turn on v6. Is this correct?
There is no NAT for IPv6, but that's a feature. NAT doesn't really add
any security; NAT is a combination of two things: a stateful firewall
(which gives you the protection) and a packet mangler (which causes no
end of problems). You can still have a stateful firewall with IPv6, you
just don't need the packet mangler anymore.
Returning to end-to-end addressing is nice - for example, I can open up
SSH on my home firewall and connect to home systems from my cell phone
(because both my home and cell Internet providers have native IPv6). No
more silly port mappings and having to remember which port is mapped to
which device.
On business networks, the death of NAT is way overdue - my company has
VPN tunnels to a bunch of customer networks, and we're forever running
into the same NAT networks (10.0.0.0, 192.168.1.0, etc.). If everybody
would just get on the IPv6 train, address conflicts would be gone.
NAT just gives the feeling of security, when it's just the firewall part
that is the actual security layer.
--
Chris Adams <linux(a)cmadams.net>
7:57 p.m.
On Tue, 2020-12-29 at 08:32 -0600, Chris Adams wrote:
There is no NAT for IPv6, but that's a feature. NAT doesn't
really
add any security; NAT is a combination of two things: a stateful
firewall (which gives you the protection) and a packet mangler (which
causes no end of problems). You can still have a stateful firewall
with IPv6, you just don't need the packet mangler anymore.
That's the first time I've ever seen anyone say a stateful firewall is
a part of NAT. Sure, systems may have both, but I wouldn't call one
part of the other. I've certainly used systems with NAT, going back to
Win98SE days, that had no firewall.
The fact that NAT doesn't know what to do with surprise incoming
connections doesn't make it a firewall, just unconfigured networking.
While that brokenness may be beneficial to many people, it's not
something to rely on. I've seen modem-routers that (un)helpfully
forwarded all unexpected incoming network attempts to a PC behind NAT.
It was their attempt at un-breaking the many communication protocols
that instant messaging and gaming used that didn't work well
through NAT. Quite how it was going to determine which of your PCs to
forward it through to I don't know.
--
uname -rsvp
Linux 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
10:58 p.m.
Once upon a time, Tim via users <users(a)lists.fedoraproject.org> said:
On Tue, 2020-12-29 at 08:32 -0600, Chris Adams wrote:
> There is no NAT for IPv6, but that's a feature. NAT doesn't really
> add any security; NAT is a combination of two things: a stateful
> firewall (which gives you the protection) and a packet mangler (which
> causes no end of problems). You can still have a stateful firewall
> with IPv6, you just don't need the packet mangler anymore.
That's the first time I've ever seen anyone say a stateful firewall is
a part of NAT. Sure, systems may have both, but I wouldn't call one
part of the other. I've certainly used systems with NAT, going back to
Win98SE days, that had no firewall.
Anything that does IPv4 NAT is performing the functions of a stateful
firewall, plus packet mangling. You may not have control of the
firewall, but it is inherently there. You cannot have NAT without the
exact same state tracking and ALGs of a stateful firewall.
--
Chris Adams <linux(a)cmadams.net>
4:32 a.m.
On 29.12.2020 15:32, Chris Adams wrote:
Once upon a time, Neal Becker <ndbecker2(a)gmail.com> said:
> Let me say up front I'm not very knowledgeable about v6 yet. One reason I
> don't want to enable it is the exact flip side of the address scarcity of
> v4. Because of that, external connections are nat'd. That seems to me to
> offer an additional layer of protection for devices on my network, they
> don't have externally routeable addresses. I think that is not true if I
> turn on v6. Is this correct?
There is no NAT for IPv6, but that's a feature.
indeed, there is no need for NAT, but you can have it, if you want
see RFC 4193, the pendant to RFC 1918 ...
NAT doesn't really add any security;
this is wrong, the best security at all for which you don't have to do
anything is included with NAT
or how can you access my PC with e.g. 10.0.8.15?
NAT is a combination of two things: a stateful firewall
this is wrong, NAT is not a stateful firewall;
or in other words your two sentences disagree or you really mean by
"NAT doesn't really add any security" that a stateful firewall doesn't
have any security and is useless ...
9:54 a.m.
(top-posted to match the original OP)
Unless you are explicitly configuring more-public addresses on your IPv6
connections, your upstream gateway machine, router or switch should be
providing link-local addresses to anything local. All switches are
required not to forward link-local addresses upstream, giving you the
NAT-like isolation that you desire.
--
John Mellor
On 2020-12-29 8:53 a.m., Neal Becker wrote:
Let me say up front I'm not very knowledgeable about v6 yet.
One
reason I don't want to enable it is the exact flip side of the address
scarcity of v4. Because of that, external connections are nat'd.
That seems to me to offer an additional layer of protection for
devices on my network, they don't have externally
routeable addresses. I think that is not true if I turn on v6. Is
this correct?
On Tue, Dec 29, 2020 at 6:24 AM John Mellor <john.mellor(a)gmail.com
<mailto:john.mellor@gmail.com>> wrote:
On 2020-12-28 7:51 p.m., Jorge Fábregas wrote:
> Is there a known application/service that might *misbehave*
because it
> expects a an ipv6 stack these days?
The Fedora IP stack used to stall for several seconds in several
previous releases. The normal workaround for that was to disable
IPv6,
causing pretty massive speedups. That problem went away at about
Fedora
32 or 31.
IPv4 has an address-space capacity issue, and is effectively
dead. The
allocated IPv4 address space remains tight in North America, and
completely exhausted in most other parts of the world. In my case,
while my internal network remains IPv4 since I use older switches,
while
my upstream is IPv6. The only machine that has to be IPv6
internally is
my HP printer. My ISP does not have anywhere near enough IPv4
addresses
to support its large customer base, so they were forced to upgrade
most
of their network to IPv6. Their v4-to-v6 translation and vice-versa
works pretty transparently. I haven't noticed any issues for a
couple
of years now.
One interesting and nice side-effect of IPv6 is that I get a lot less
drive-by shooting trying to attack my network. I used to get about 3
port-scanning attempts/day, and now I go weeks without an
intrusion-detection hit. I don't think the bad guys have figured out
how to attack IPv6 addresses yet.
1206
days inactive
1207
days old
17 comments
9 participants
participants (9)
-
Chris Adams -
Ed Greshko -
John Mellor -
Jorge Fábregas -
Neal Becker -
Roberto Ragusa -
Tim -
Tom Horsley -
Walter H.