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
