3:51 p.m.
Hello everyone,
I have attended recently csnog.eu conference [1], where some interesting
presentations took place. They were usually in Czech, so it is not
something I am going to share more. But what took my interest were ipv6
readiness with some exceptions. Fedora is ready to be run on dual-stack
IPv4 and IPv6 networks just fine. But the presentation were about future
case where we run most hosts on IPv6 network only, but allow some older
devices to take and use also IPv4 address.
Fortunately there is roughly the same presentation[2] in English, which
took the place on RIPE 85 meeting. What catched my interest were talk
about Windows 11 and Apple systems are ready, but not really talk about
how any linux distribution is ready for such situation. It seems to me
we should improve the support for mentioned mechanisms in Fedora.
What do you think about it?
[1] https://indico.csnog.eu/event/13/contributions/121/
[2] https://ripe85.ripe.net/archives/video/923/
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
3:52 a.m.
Hi,
I have attended recently csnog.eu conference [1], where some
interesting
presentations took place. They were usually in Czech, so it is not
something I am going to share more. But what took my interest were ipv6
readiness with some exceptions. Fedora is ready to be run on dual-stack
IPv4 and IPv6 networks just fine. But the presentation were about future
case where we run most hosts on IPv6 network only, but allow some older
devices to take and use also IPv4 address.
I've been running Fedora on dual stack v4/v6 for well over a decade
without issues as my ISP has long supported it.
Fortunately there is roughly the same presentation[2] in English,
which
took the place on RIPE 85 meeting. What catched my interest were talk
about Windows 11 and Apple systems are ready, but not really talk about
how any linux distribution is ready for such situation. It seems to me
we should improve the support for mentioned mechanisms in Fedora.
What do you think about it?
There was a UK IPv6 Council meeting recently [1] that I was hoping to
attend but had conflicts, thankfully they've also published most of
the slides/videos which are useful and interesting.
Overall I have a bunch of thoughts as IPv6 is of large interest to
IoT/Edge so I have been following it somewhat. Reviewing a bunch of
the slides from that event, some referenced RIPE meetings, it lead me
to file a NetworkManager RFE [2] for RFC-8925 support. I also intend
to investigate setting up a IPv6 only VLAN but a quick look at my
Unifi GW UX didn't make it easy and I'm yet to dig into what's needed
from a cli PoV there :)
Overall I suspect there's some work directly in Fedora around defaults
but quite a bit may well be in upstream projects like NM. Happy to
help where I can.
Peter
[1] https://www.ipv6.org.uk/2023/02/03/enterprise-ipv6-workshop/
[2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1298
>
> [1] https://indico.csnog.eu/event/13/contributions/121/
> [2] https://ripe85.ripe.net/archives/video/923/
>
> --
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, http://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
7:03 a.m.
V Thu, May 25, 2023 at 10:51:26PM +0200, Petr Menšík napsal(a):
I have attended recently csnog.eu conference [1], where some
interesting
presentations took place. They were usually in Czech, so it is not something
I am going to share more. But what took my interest were ipv6 readiness with
some exceptions. Fedora is ready to be run on dual-stack IPv4 and IPv6
networks just fine. But the presentation were about future case where we run
most hosts on IPv6 network only, but allow some older devices to take and
use also IPv4 address.
Fortunately there is roughly the same presentation[2] in English, which took
the place on RIPE 85 meeting. What catched my interest were talk about
Windows 11 and Apple systems are ready, but not really talk about how any
linux distribution is ready for such situation. It seems to me we should
improve the support for mentioned mechanisms in Fedora.
What do you think about it?
[1] https://indico.csnog.eu/event/13/contributions/121/
[2] https://ripe85.ripe.net/archives/video/923/
The presentation was about CLAT (RFC 6877) implementations on end hosts.
Fedora already delivers clatd package
<https://koji.fedoraproject.org/koji/packageinfo?packageID=23002>;. Though
I have no idea whether it works.
-- Petr
2:05 p.m.
Petr Menšík wrote:
Hello everyone,
I have attended recently csnog.eu conference [1], where some interesting
presentations took place. They were usually in Czech, so it is not
something I am going to share more. But what took my interest were ipv6
readiness with some exceptions. Fedora is ready to be run on dual-stack
IPv4 and IPv6 networks just fine. But the presentation were about future
case where we run most hosts on IPv6 network only, but allow some older
devices to take and use also IPv4 address.
Fortunately there is roughly the same presentation[2] in English, which
took the place on RIPE 85 meeting. What catched my interest were talk
about Windows 11 and Apple systems are ready, but not really talk about
how any linux distribution is ready for such situation. It seems to me
we should improve the support for mentioned mechanisms in Fedora.
Having watched the latter presentation, I understand that the idea is
that, on a network with a limited pool of globally routable IPv4
addresses, IPv6-capable clients should use only IPv6 and refrain from
requesting IPv4 addresses, so that addresses will be available to
legacy devices that need IPv4.
It seems to me that it would be very difficult for a DHCP client
program to know whether the Fedora installation it's running on needs
an IPv4 address. I think it would have to be manually configured.
It's mentioned in the presentation that IPv6 support is required in
Apple's App Store. That's not currently the case in Fedora. In my own
opinion everything should by now assume IPv6 as the norm, and treat
IPv4 as the legacy protocol that must still be supported for
compatibility – but that's not Fedora's policy. The policy is as
follows:
| If an application contains native and stable support for both IPv4 and
| IPv6, and support for IPv6 does not negatively affect IPv4 then both
| MUST be enabled in the Fedora package.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_networking_su...
That means that IPv4-only programs are still quite welcome in Fedora if
their lack of IPv6 support is an upstream limitation and not introduced
by the packager. Thus the network configuration must expect that the
user might run such a program and might need IPv4 connectivity. The
policy should probably be changed before Fedora begins requesting only
IPv6 addresses by default.
Another concern is that the entire IPv6-mostly concept seems to assume
devices that are strictly clients. It doesn't seem like it would work
for anyone who runs any kind of server or peer-to-peer program. The idea
seems to be that IPv6 clients will access IPv4-only servers over NAT64.
Like all address translation, NAT64 is an obstacle to peer-to-peer
communication. If you need to communicate with a peer who is stuck with
an RFC 1918 address behind NAT on an IPv4-only network – a case that is
still far too common – and you're using IPv6 and NAT64, then you and
your peer will both be unable to connect to each other. If globally
routable IPv4 addresses are available on the network where you are,
then you'll want one so that your peer can at least connect to you.
Users of peer-to-peer programs will want to configure their DHCP client
to request an IPv4 address in case that need arises.
Björn Persson
7 a.m.
FYI, I have created tracker bug ipv6-mostly [1], which links bugs in
different components to make that possible.
More below
On 01. 06. 23 21:05, Björn Persson wrote:
Petr Menšík wrote:
> ...
> Fortunately there is roughly the same presentation[2] in English, which
> took the place on RIPE 85 meeting. What catched my interest were talk
> about Windows 11 and Apple systems are ready, but not really talk about
> how any linux distribution is ready for such situation. It seems to me
> we should improve the support for mentioned mechanisms in Fedora.
Having watched the latter presentation, I understand that the idea is
that, on a network with a limited pool of globally routable IPv4
addresses, IPv6-capable clients should use only IPv6 and refrain from
requesting IPv4 addresses, so that addresses will be available to
legacy devices that need IPv4.
It seems to me that it would be very difficult for a DHCP client
program to know whether the Fedora installation it's running on needs
an IPv4 address. I think it would have to be manually configured.
I think this is not expected from any clients. Of course we as a Fedora
vendor cannot know how the user will use it. I do not have native IPv6
connectivity myself. The presentation explains that it should keep the
IPv4 connectivity by using CLAT. How I understood that it would mean NM
would configure just IPv6 address on the interface, but should configure
also x464clat interface automatically for you. It would make your
machine to have IPv4 address on nat64 device, which would have also IPv4
default route directed to it. So ping 8.8.8.8 should work out of the
box, but your wifi or eth interface wouldn't have it assigned. Even in
case you request a tool to use just IPv4, it should work. Like curl -4
http://example.org or even curl http://93.184.216.34/.
We have already clatd package, but the ability to autoconfigure it is
missing. Current NM does not even parse information what DNS64 prefixes
are used on this network. That is required to make it autoconfigured IMO.
It's mentioned in the presentation that IPv6 support is required in
Apple's App Store. That's not currently the case in Fedora. In my own
opinion everything should by now assume IPv6 as the norm, and treat
IPv4 as the legacy protocol that must still be supported for
compatibility – but that's not Fedora's policy. The policy is as
follows:
| If an application contains native and stable support for both IPv4 and
| IPv6, and support for IPv6 does not negatively affect IPv4 then both
| MUST be enabled in the Fedora package.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_networking_su...
That means that IPv4-only programs are still quite welcome in Fedora if
their lack of IPv6 support is an upstream limitation and not introduced
by the packager. Thus the network configuration must expect that the
user might run such a program and might need IPv4 connectivity. The
policy should probably be changed before Fedora begins requesting only
IPv6 addresses by default.
Do we have any IPv4 only packages in Fedora? It would be nice to have
tracker bug for missing features in upstream packages. I don't know
about any more popular or used. But especially because such programs
still exist we need something like this. The solution provides client
IPv4 connectivity, because it expects private AS112 ranges to be used.
Maybe it could be used with public IPv4, but I don't think that makes
any sense.
We should definitely encourage and recommend full IPv6 support. For
applications not ready this is a way to make them working in most of cases.
Another concern is that the entire IPv6-mostly concept seems to
assume
devices that are strictly clients. It doesn't seem like it would work
for anyone who runs any kind of server or peer-to-peer program. The idea
seems to be that IPv6 clients will access IPv4-only servers over NAT64.
Like all address translation, NAT64 is an obstacle to peer-to-peer
communication. If you need to communicate with a peer who is stuck with
an RFC 1918 address behind NAT on an IPv4-only network – a case that is
still far too common – and you're using IPv6 and NAT64, then you and
your peer will both be unable to connect to each other. If globally
routable IPv4 addresses are available on the network where you are,
then you'll want one so that your peer can at least connect to you.
Users of peer-to-peer programs will want to configure their DHCP client
to request an IPv4 address in case that need arises.
Björn Persson
I expect servers should have dual stack if they need to provide IPv4
services. I admit couldn't test this concept myself, because I do not
have a network with at least native dual stack. Peer to peer
connectivity should be possible in the same way as with cascaded IPv4
routers used today. I expect UDP port punching should work. NAT64 should
be for a IPv4 server side just another client behind NAT. Most of
machines today do not require that. For relevant services we definitely
want to provide fully working IPv6 peer-to-peer connectivity instead.
If the network has IPv4 addresses available and public on top, it would
just not use ipv6-only DHCP option in its DHCPv4 server response. The
cool thing on this is you can cherry-pick clients on DHCP server side,
for example by vendor or MAC address. And only ask those to behave like
IPv6 only. While all others would receive dual stack network.
That is indeed quite useful for single-purpose IoT devices, whose you
can have quite a lot in a single network. NM has an ability to
configure, whether you want those addresses or not. If you set
ipv6.method=disabled on your connection, then NM should not even request
ipv6-only option and generally behave it never heard about IPv6. I have
filled bug #2182745 [2] to reduce unnecessary queries for DNS. Which
should help for both ipv6-only and ipv4-only networks. This should add a
new ability without a requirement to use it.
Regards,
Petr Menšík
1. https://bugzilla.redhat.com/show_bug.cgi?id=ipv6-mostly
2. https://bugzilla.redhat.com/show_bug.cgi?id=2182745
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
8:27 a.m.
Thought:
(disclaimer: I don't know much about networking)
IPv4 addresses are in some cases 'human readable' / 'human usable' /
'human friendly'.
How can one set up a temporary network of several devices for a LAN
party or any similar connecting application use cases?
From my own experience, the vast majority of people have no idea that
when one tells you "write in: ten zero zero eight", they have to put
dots in between. Because they have no idea what IP address is and how
it's formatted.
I can't imagine I would say this out loud to even a tech experienced
person and they would get it right the first time.
1a01:4204:b07d:af00:21c6:542a:611:73ea
Not mentioning all the times I need to connect devices in many rooms
across several floors in the whole building.
Is there any easy way to keep exchanging the IP address 'human usable' ?
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, May 25, 2023 at 10:51 PM Petr Menšík <pemensik(a)redhat.com> wrote:
Hello everyone,
I have attended recently csnog.eu conference [1], where some interesting
presentations took place. They were usually in Czech, so it is not
something I am going to share more. But what took my interest were ipv6
readiness with some exceptions. Fedora is ready to be run on dual-stack
IPv4 and IPv6 networks just fine. But the presentation were about future
case where we run most hosts on IPv6 network only, but allow some older
devices to take and use also IPv4 address.
Fortunately there is roughly the same presentation[2] in English, which
took the place on RIPE 85 meeting. What catched my interest were talk
about Windows 11 and Apple systems are ready, but not really talk about
how any linux distribution is ready for such situation. It seems to me
we should improve the support for mentioned mechanisms in Fedora.
What do you think about it?
[1] https://indico.csnog.eu/event/13/contributions/121/
[2] https://ripe85.ripe.net/archives/video/923/
9:02 a.m.
Once upon a time, Michal Schorm <mschorm(a)redhat.com> said:
How can one set up a temporary network of several devices for a LAN
party or any similar connecting application use cases?
From my own experience, the vast majority of people have no idea that
when one tells you "write in: ten zero zero eight", they have to put
dots in between. Because they have no idea what IP address is and how
it's formatted.
I can't imagine I would say this out loud to even a tech experienced
person and they would get it right the first time.
1a01:4204:b07d:af00:21c6:542a:611:73ea
Not mentioning all the times I need to connect devices in many rooms
across several floors in the whole building.
Is there any easy way to keep exchanging the IP address 'human usable' ?
There are some ways, but really, for those uses, just have a router
handling it, just like setting up DHCP for IPv4 is much easier than
having everybody type IPs (and then making sure there are no IP
conflicts and such). Even if you don't have Internet connectivity, you
can set up what's known as a ULA prefix (IIRC OpenWRT chooses a random
ULA prefix by default). That plus SLAAC and/or DHCPv6 means people plug
in and it "just works".
And from there, things like Zerconf/Avahi allow you to find other
systems on the local LAN without having to type IPs. Unless you are a
network person, the majority of the time now you shouldn't have to care
about IP addresses (v4 or v6).
But... since v6 addresses are hex, that does give a little more room for
manually assigning "creative" addresses... you'll see a number of things
that have an address that includes :dead:beef: for example. :)
Also, for people who like to use public DNS resolvers (you shouldn't)
like Google's 8.8.8.8, the shortest addresses on the Internet are 2a09::
and 2a11:: (shorter than any possible v4 address).
--
Chris Adams <linux(a)cmadams.net>
9:03 a.m.
The easy way is definitely pushing both IPv6 and IPv4 addresses of any
service into DNS. Use at least mdns (which is not resolving also IPv6 in
our default configuration sadly), which converts names to ipaddress and
back. That in my opinion is the target. To use human friendly names, not
IP addresses. Sure, IPv4 are shorter and easier to type in or even
spell. But we need the address bits, there is no workaround. IP
addresses are not user-friendly way.
Dnsmasq for example creates name<->IP address mapping for every machine
asking DHCP from it. That is the way to go. Name your machine and
reference it by name from others. Avahi is a good alternative for
locating your device, even when network does not do mapping to it. If
some device does not insert names automatically (hello Mikrotik!), ask
their vendor to fix that. Usage of IP addresses should be reduced to
strictly necessary minimum. Copy & paste should help with that.
Tomorrow is IPv6 Seminar at Prague [3], I am going to attend that. I
have still many questions, I am not really IPv6 guru (yet?).
On 05. 06. 23 15:27, Michal Schorm wrote:
Thought:
(disclaimer: I don't know much about networking)
IPv4 addresses are in some cases 'human readable' / 'human usable' /
'human friendly'.
How can one set up a temporary network of several devices for a LAN
party or any similar connecting application use cases?
From my own experience, the vast majority of people have no idea that
when one tells you "write in: ten zero zero eight", they have to put
dots in between. Because they have no idea what IP address is and how
it's formatted.
I can't imagine I would say this out loud to even a tech experienced
person and they would get it right the first time.
1a01:4204:b07d:af00:21c6:542a:611:73ea
For real addresses which users actually has to type it is usually better.
dns.google: 2001:4860:4860::8844
dns9.quad9.net: 2620:fe::9
Not mentioning all the times I need to connect devices in many rooms
across several floors in the whole building.
Is there any easy way to keep exchanging the IP address 'human usable' ?
No. But we have DNS there for decades to make them human usable. We just
need to use it everytime we can. Autoconfigure it when possible. What I
am not sure is how should SLAAC allocated addresses be paired with a
name provided by the network, into which they are connected to. It is
supported with DHCP(v6), but I don't know a good way for router
advertisements. A question for experts!
Though domain name services is the area I am expert in already. If there
is integration missing in some area, fill a bug! Even to me.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, May 25, 2023 at 10:51 PM Petr Menšík <pemensik(a)redhat.com> wrote:
> Hello everyone,
>
> I have attended recently csnog.eu conference [1], where some interesting
> presentations took place. They were usually in Czech, so it is not
> something I am going to share more. But what took my interest were ipv6
> readiness with some exceptions. Fedora is ready to be run on dual-stack
> IPv4 and IPv6 networks just fine. But the presentation were about future
> case where we run most hosts on IPv6 network only, but allow some older
> devices to take and use also IPv4 address.
>
> Fortunately there is roughly the same presentation[2] in English, which
> took the place on RIPE 85 meeting. What catched my interest were talk
> about Windows 11 and Apple systems are ready, but not really talk about
> how any linux distribution is ready for such situation. It seems to me
> we should improve the support for mentioned mechanisms in Fedora.
>
> What do you think about it?
>
> [1] https://indico.csnog.eu/event/13/contributions/121/
> [2] https://ripe85.ripe.net/archives/video/923/
3.
https://www.cesnet.cz/akce/seminar-ipv6-2023/
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
9:52 a.m.
V Mon, Jun 05, 2023 at 03:27:58PM +0200, Michal Schorm napsal(a):
Thought:
(disclaimer: I don't know much about networking)
IPv4 addresses are in some cases 'human readable' / 'human usable' /
'human friendly'.
How can one set up a temporary network of several devices for a LAN
party or any similar connecting application use cases?
From my own experience, the vast majority of people have no idea that
when one tells you "write in: ten zero zero eight", they have to put
dots in between. Because they have no idea what IP address is and how
it's formatted.
I can't imagine I would say this out loud to even a tech experienced
person and they would get it right the first time.
1a01:4204:b07d:af00:21c6:542a:611:73ea
Not mentioning all the times I need to connect devices in many rooms
across several floors in the whole building.
Is there any easy way to keep exchanging the IP address 'human usable' ?
It is. And it works exactly the same way as in IPv4. You pick a well-known
prefix and then append a simple number. Should I continue your example with
LAN, then the prefix is fe80::/64. E.g. fe80::1, fe80::2 etc. are valid
addresses.
(The fe80::/64 prefix has some theoretical constraints on some higher bits in
the address, but I guess nobody invites more than 2^24 people on a party, so
you don't have to be concerned. There are also practical constraints, like
this prefix is not routable and if you have more network interfaces, you would
have to follow it with a network interface identifier in your applications.)
-- Petr
330
days inactive
341
days old
8 comments
6 participants
participants (6)
-
Björn Persson -
Chris Adams -
Michal Schorm -
Peter Robinson -
Petr Menšík -
Petr Pisar