ipv6 NAT; accept_ra errors and about network choice

[Ian Wienand]

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