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_support
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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
