11:33 p.m.
Hello, thanks for looking!
On Tue, Aug 11, 2020 at 11:52:46PM -0400, Laine Stump wrote:
> The first problem I hit was trying to start that network:
>
> error: internal error: Check the host setup: enabling IPv6 forwarding
> with RA routes without accept_ra set to 2 is likely to cause routes
> loss. Interfaces to look at: wlp4s0
>
I can see 3 possibilities:
3) try to make libvirt's code intelligent, and look for clues that RAs are
handled elsewhere (someone would need to figure out what those "clues" are).
Perhaps my proposal at [1] falls into this category. The theory is to
only warn when an interface is already set to 1 [2] because that seems
to be when you would be expecting the interface to accept RA's, but
enabling forwarding would inhibit it. From sysctl docs:
Possible values are:
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled.
> The other thing that I'd like to expand the documentation
on, if I can
> get some clarity, is the choice of network. It seems like it has to
> be a /64, and it seems like the best choice is within fc00::/7, or at
> least that is what has been assigned for private networks like this
> [3]?
"locally assigned" addresses in IPv6 are... different. I've been trying to
figure this out myself (in order to *automatically* assign a network address
to a libvirt virtual network, as Dan suggested in the cover letter for the
IPv6 NAT patches), and I *think* you need to at least set the lowest bit of
the first byte of the address (that's the "locally assigned" bit). So that
would mean that all networks should be somewhere within FD00::/8 (but please
correct me if I'm wrong!)
... different ... indeed! :) I've proposed [3] with what I've found
out. Yes I agree it seems the intent of FD00::/8 is to be somewhat
analogous to 192.168 ... but you know of course it's IPv6 so there's a
page worth of details in the RFC on how to generate 40 random bits ...
> The only problem with this is that I think glibc filters this
range so
> nothing prefers IPv6.
What?? Exactly what isn't preferring IPv6? Do you mean outbound connections
that would be to an IPv6 address will be nixed in favor of an IPv4 address
if the source IP of the connection was going to be in FC00::/7? Or something
else? Do you have a reference for this?
The man page for gai.conf *implies* that glibc is following the
preference
rules suggested in RFC3484, which was written prior to RFC4193, so it seems
strange that it would give any special treatment to addresses in that range.
Does it behave in the same way if you use FD00::... instead of FC00::...?
(probably, but worth checking)
Yeah, on my Fedora 32 host I have to override gai.conf to prefer ipv6
(there is no default /etc/gai.conf) with what I took directly from RFC3484
---
label ::1/128 0
label ::/0 1
label 2002::/16 2
label ::/96 3
label ::ffff:0:0/96 4
precedence ::1/128 50
precedence ::/0 40
precedence 2002::/16 30
precedence ::/96 20
precedence ::ffff:0:0/96 10
---
I think the gai.conf it is actually using is reflected in
/usr/share/doc/glibc-common/gai.conf; which has this comment:
# This default differs from the tables given in RFC 3484 by handling
# (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
# The reason for this difference is that these addresses are never
# NATed while IPv4 site-local addresses most probably are. Given
# the precedence of IPv6 over IPv4 (see below) on machines having only
# site-local IPv4 and IPv6 addresses a lookup for a global address would
# see the IPv6 be preferred. The result is a long delay because the
# site-local IPv6 addresses cannot be used while the IPv4 address is
# (at least for the foreseeable future) NATed. We also treat Teredo
# tunnels special.
(it must be compiled in defaults?) So; it seems a choice made by the
practicalities of basically people having these addresses that
*weren't* routable and having a terrible experience. Of course, now
legitimate use is collateral damage. Perhaps we should raise this
with the distro -- but I expect if they update it, they might be back
in the position of people reporting "why is my website taking 30
seconds to load" :/ Of course I'm sure other distros have made other
choices too.
(BTW, he was playing around with defining an IPv6 libvirt network
that used
the same network as the host's physical interface, then turning on
ndp-proxy, and finally adding a host route for each guest IP; this permits
the guests to all be on the same IPv6 network as the host; if we can get all
of those steps automated in a libvirt virtual network, it will be even
better than IPv6 NAT!)
I just want to access ipv6 only clouds on my laptop from my work VM
over wifi and plugged into the docking station :) That might be
similar to what VirtualBox does? That allows a guest to have a NIC
bridged to a wifi card, that seems to get an address (RA makes it in?)
but no packets flow for me. Apparently with some wireless NICs it
might work, but not mine I guess.
-i
[1] https://www.redhat.com/archives/libvir-list/2020-August/msg00437.html
[2] https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
[3] https://www.redhat.com/archives/libvir-list/2020-August/msg00438.html