Date: Thu, 26 May 2016 21:11:51 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: tinc@tinc-vpn.org, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Mailinglists FreeBSD <freebsd-questions@freebsd.org> Subject: Re: IPv6, ULAs and FreeBSD Message-ID: <CAN6yY1uEwttkd7iCBrjoFytUjUiNL1Ew-j7pm=-S=dY9HBXPYQ@mail.gmail.com> In-Reply-To: <20160526193602.GF49239@box-fra-01.niklaas.eu> References: <20160519124446.GB2444@box-fra-01.niklaas.eu> <20160523034855.GA37797@box-fra-01.niklaas.eu> <20160524061707.GA77980@box-fra-01.niklaas.eu> <20160526193602.GF49239@box-fra-01.niklaas.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 26, 2016 at 12:36 PM, Niklaas Baudet von Gersdorff < stdin@niklaas.eu> wrote: > I was eventually able to solve this issue. I asked for help on several > mailing lists. So, for reference, here are links to the relevant > threads: > > https://lists.freebsd.org/pipermail/freebsd-questions/2016-May/271810.html > https://lists.freebsd.org/pipermail/freebsd-net/2016-May/045349.html > https://www.tinc-vpn.org/pipermail/tinc/2016-May/004573.html > > Niklaas Baudet von Gersdorff [2016-05-24 08:17 +0200] : > > > I want to serve IPv4 subnets 10.1.0.0/16 (machine A) and 10.2.0.0/16 > > (machine B), and IPv6 subnets fd16:dcc0:f4cc:0:0:1::/96 (machine A) and > > fd16:dcc0:f4cc:0:0:2::/96 (machine B) respectively. The jails are > > connected on lo1. > > Here lies the first problem. It seems that it's not legitimate to assign > /96 subnets when using unique local addresses (ULAs). I was right > getting some /48 subnet for my local IPv6 network; some easy way to get > one generated randomly is http://unique-local-ipv6.com/ . But instead of > assigning /96 subnets to each host, you must assign /64 subnets. I guess > (but I am not sure because I have not found any reference that mentions > this explicitly) you *must not* use any other subnet when dealing with > ULAs. > > So I decided for the following two subnets for machine A and > B respectively: fd16:dcc0:f4cc:1::/64 and fd16:dcc0:f4cc:2::/64. > > > The following is the tinc-up script on each machine that assignes IP > > addresses and creates routes. I commented out some variations that > > I tried but haven't had success with either: > > > > A $ cat /usr/local/etc/tinc/klaas/tinc-up > > ifconfig $INTERFACE inet6 fd16:dcc0:f4cc:0:0:1:0:1 prefixlen 80 > > route -6 add -host fd16:dcc0:f4cc:0:0:2:0:1 fd16:dcc0:f4cc:0:0:1:0:1 > > route -6 add -net fd16:dcc0:f4cc:0:0:2::/96 > fd16:dcc0:f4cc:0:0:1:0:1 > > #route -6 add -ifp $INTERFACE -host fd16:dcc0:f4cc::2:0:1 > fd16:dcc0:f4cc::1:0:1 > > #route -6 add -ifp $INTERFACE -net fd16:dcc0:f4cc::2:0:0/96 > fd16:dcc0:f4cc::1:0:1 > > > > ifconfig $INTERFACE 10.1.0.1 netmask 255.0.0.0 > > route -4 add -host 10.2.0.1 10.1.0.1 > > route -4 add -net 10.2.0.0/16 10.1.0.1 > > In addition, it seems not sufficient to solely assign IP address, but > you must also assign a route for the respective foreign (!) subnet(s) to > the tap interface. Without these I couldn't get the connection working. > Thus, you get the following tinc-up scripts for both machines: > > A $ cat /usr/local/etc/tinc/tinc-up > ifconfig $INTERFACE inet6 fd16:dcc0:f4cc:1::1 prefixlen 48 alias > ifconfig $INTERFACE 10.1.0.1 netmask 255.0.0.0 alias > > route add -inet6 -net fd16:dcc0:f4cc:2::/64 -interface $INTERFACE > > > B $ cat /usr/local/etc/tinc/tinc-up > ifconfig $INTERFACE inet6 fd16:dcc0:f4cc:2::1 prefixlen 48 alias > ifconfig $INTERFACE 10.2.0.1 netmask 255.0.0.0 alias > > route add -inet6 -net fd16:dcc0:f4cc:1::/64 -interface $INTERFACE > > The following you should include into tinc-down to clean up the route > when the daemon is shut down (alter this for machine B respectively): > > route add -inet6 -net fd16:dcc0:f4cc:1::/64 -interface $INTERFACE > > To make this complete, these are the relevant host configurations for > tinc: > > A $ cat /usr/local/etc/tinc/hosts/A > Address = A > Subnet = fd16:dcc0:f4cc:1::/64 > Subnet = 10.1.0.0/16 > > -----BEGIN RSA PUBLIC KEY----- > <secret> > -----END RSA PUBLIC KEY----- > > > A $ cat /usr/local/etc/tinc/hosts/B > Address = B > Subnet = fd16:dcc0:f4cc:2::/64 > Subnet = 10.2.0.0/16 > > -----BEGIN RSA PUBLIC KEY----- > <secret> > -----END RSA PUBLIC KEY----- > > For reference -- in hope that duckduckgo does a good job indexing this > and prevents others from struggling the same way as I did -- here are > the errors I would get from tinc if either the subnet was not set up > correctly (see above) or if I had not configured the routes: > > Cannot route packet: neighbor solicitation request for unknown address > fd16:dcc0:f4cc:0:0:1:0:1 > > In hope that nobody else has to struggle with this as long as I did. > > Niklaas > There are a lot of excellent reasons to avoid ULAs. There are a very few good, or even so-so reasons to use them. The most commonly cited reason is security which is almost always wrong. In almost 20 years of working with IPv6 I have yet to see any valid security reason for using ULAs. There are any number of excellent papers on this. The most valid use is when you can only get a /64 from your provider. RFCs recommend a minimum assignment to residential customers of a /56 but many providers seem to have missed this, so there is no choice. prefixes longer than /64 are effectively not possible. IPv6 does not care, but the supporting protocols , make a /64 or shorter assumption. More intractable is that hardware also often make similar assumptions. As you learned, you really, really don't waste your time trying to make it work. I really guess all of this needs to be in the handbook so people don't waste time trying to do things that are documented to either not work or not work effectively. And, unless you are really, really sure you need ULAs, They mostly just break things.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1uEwttkd7iCBrjoFytUjUiNL1Ew-j7pm=-S=dY9HBXPYQ>