tinc and IPv6 routing, or: how to set up a local IPv6

[Niklaas Baudet von Gersdorff]

Hello,

in case this is something obvious, please bear with me. I am not
a professional, it's just my hobby to play around with computers.

I am trying to set up a tinc VPN that connects two servers. In fact, the
VPN is working for IPv4, but I cannot get it work for IPv6. Because of
this, I assume it's rather a routing problem with IPv6 than a problem with
tinc. To be honest, I don't have any experience setting up a local IPv6;
so I guess that I'm doing something wrong here.

The main aim is to connect several jails that are running on each of the
machines. They are in IPv4 networks 10.1.0.0/16 (machine A) and 10.2.0.0/16
(machine B), and in IPv6 networks fd16:dcc0:f4cc:0:0:1::/96 (machine A) and
fd16:dcc0:f4cc:0:0:2::/96 (machine B) respectively. Both on lo1.

With the current configuration (see below) I end up with the following
routing tables:

A $ netstat -rn | grep -e 'fd16' -e '10\.'
10.0.0.0/8 link#4 U tap0
10.1.0.1 link#4 UHS lo0
10.1.1.1 link#3 UH lo1
10.2.0.0/16 10.1.0.1 UGS tap0
10.2.0.1 10.1.0.1 UGHS tap0
fd16:dcc0:f4cc::/80 link#4 U tap0
fd16:dcc0:f4cc::1:0:0/96 link#3 U lo1
fd16:dcc0:f4cc::1:0:1 link#4 UHS lo0
fd16:dcc0:f4cc::1:1:1 link#3 UHS lo0
fd16:dcc0:f4cc::2:0:0/96 fd16:dcc0:f4cc::1:0:1 UGS lo1
fd16:dcc0:f4cc::2:0:1 fd16:dcc0:f4cc::1:0:1 UGHS lo1
ff01::%lo1/32 fd16:dcc0:f4cc::1:1:1 U lo1
ff01::%tap0/32 fd16:dcc0:f4cc::1:0:1 U tap0
ff02::%lo1/32 fd16:dcc0:f4cc::1:1:1 U lo1
ff02::%tap0/32 fd16:dcc0:f4cc::1:0:1 U tap0


B $ netstat -rn | grep -e 'fd16' -e '10\.'
10.0.0.0/8 link#4 U tap0
10.1.0.0/16 10.2.0.1 UGS tap0
10.1.0.1 10.2.0.1 UGHS tap0
10.2.0.1 link#4 UHS lo0
10.2.1.1 link#3 UH lo1
fd16:dcc0:f4cc::/80 link#4 U tap0
fd16:dcc0:f4cc::1:0:0/96 fd16:dcc0:f4cc::2:0:1 UGS lo1
fd16:dcc0:f4cc::1:0:1 fd16:dcc0:f4cc::2:0:1 UGHS lo1
fd16:dcc0:f4cc::2:0:0/96 link#3 U lo1
fd16:dcc0:f4cc::2:0:1 link#4 UHS lo0
fd16:dcc0:f4cc::2:1:1 link#3 UHS lo0
ff01::%lo1/32 fd16:dcc0:f4cc::2:1:1 U lo1
ff01::%tap0/32 fd16:dcc0:f4cc::2:0:1 U tap0
ff02::%lo1/32 fd16:dcc0:f4cc::2:1:1 U lo1
ff02::%tap0/32 fd16:dcc0:f4cc::2:0:1 U tap0

Note: 10.{1,2}.1.1 are two jails running on machine A and B respectively.
These jails have also assigned IPv6 addresses fd16:dcc0:f4cc::{1,2}:1:1
respectively. 10.{1,2}.0.1 and fd16:dcc0:f4cc::{1,2}:0:1 are manually
assigned because tinc's documentation asks you to do so, see configuration
below.

So, on both machines I can `ping 10.{1,2}.{0,1}.1` and I get a response.
Obviously, depending on where I ping from the responses I get take some ms
more time since they come from the other machine. But if I `ping6
fd16:dcc0:f4cc::{1,2}:{0,1}:1` I only get a response from the machine the
ping6 originates from; that is, routing over the VPN seems not to work for
IPv6. For example, see the following outputs:

A $ ping -c 10 10.1.0.1
PING 10.1.0.1 (10.1.0.1): 56 data bytes
64 bytes from 10.1.0.1: icmp_seq=0 ttl=64 time=0.038 ms
64 bytes from 10.1.0.1: icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from 10.1.0.1: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 10.1.0.1: icmp_seq=3 ttl=64 time=0.089 ms
64 bytes from 10.1.0.1: icmp_seq=4 ttl=64 time=0.075 ms
64 bytes from 10.1.0.1: icmp_seq=5 ttl=64 time=0.057 ms
64 bytes from 10.1.0.1: icmp_seq=6 ttl=64 time=0.046 ms
64 bytes from 10.1.0.1: icmp_seq=7 ttl=64 time=0.051 ms
64 bytes from 10.1.0.1: icmp_seq=8 ttl=64 time=0.045 ms
64 bytes from 10.1.0.1: icmp_seq=9 ttl=64 time=0.050 ms

--- 10.1.0.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.038/0.053/0.089/0.016 ms


A $ ping -c 10 10.2.0.1
PING 10.2.0.1 (10.2.0.1): 56 data bytes
64 bytes from 10.2.0.1: icmp_seq=0 ttl=64 time=8.200 ms
64 bytes from 10.2.0.1: icmp_seq=1 ttl=64 time=7.846 ms
64 bytes from 10.2.0.1: icmp_seq=2 ttl=64 time=7.881 ms
64 bytes from 10.2.0.1: icmp_seq=3 ttl=64 time=7.652 ms
64 bytes from 10.2.0.1: icmp_seq=4 ttl=64 time=7.874 ms
64 bytes from 10.2.0.1: icmp_seq=5 ttl=64 time=7.876 ms
64 bytes from 10.2.0.1: icmp_seq=6 ttl=64 time=7.694 ms
64 bytes from 10.2.0.1: icmp_seq=7 ttl=64 time=7.893 ms
64 bytes from 10.2.0.1: icmp_seq=8 ttl=64 time=8.519 ms
64 bytes from 10.2.0.1: icmp_seq=9 ttl=64 time=8.129 ms

--- 10.2.0.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.652/7.956/8.519/0.245 ms


A $ ping6 -c 10 fd16:dcc0:f4cc::1:0:1
PING6(56=40+8+8 bytes) fd16:dcc0:f4cc::1:0:1 --> fd16:dcc0:f4cc::1:0:1
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=0 hlim=64 time=0.099 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=1 hlim=64 time=0.069 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=2 hlim=64 time=0.135 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=3 hlim=64 time=0.070 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=4 hlim=64 time=0.108 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=5 hlim=64 time=0.079 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=6 hlim=64 time=0.102 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=7 hlim=64 time=0.097 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=8 hlim=64 time=0.099 ms
16 bytes from fd16:dcc0:f4cc::1:0:1, icmp_seq=9 hlim=64 time=0.092 ms

--- fd16:dcc0:f4cc::1:0:1 ping6 statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.069/0.095/0.135/0.018 ms


A $ ping6 -c 10 fd16:dcc0:f4cc::2:0:1
PING6(56=40+8+8 bytes) fd16:dcc0:f4cc::1:1:1 --> fd16:dcc0:f4cc::2:0:1

--- fd16:dcc0:f4cc::2:0:1 ping6 statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss

The outputs look pretty the same on machine B -- just the other way
around. What is wrong with the IPv6 routing?

I have

ipv6_gateway_enable="YES"

/etc/rc.conf. See also:

A $ sysctl net.inet6.ip6.forwarding
net.inet6.ip6.forwarding: 1


B $ sysctl net.inet6.ip6.forwarding
net.inet6.ip6.forwarding: 1

I don't think it's a firewall problem because I have

set skip on { lo0 tap0 }

in /etc/pf.conf, and IPv4 VPN is working.

This is how the interfaces look like:

A $ ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:bd:6b:e5:19:00
inet6 fd16:dcc0:f4cc::1:0:1 prefixlen 80
inet6 fe80::2bd:6bff:fee5:1900%tap0 prefixlen 64 scopeid 0x4
inet 10.1.0.1 netmask 0xff000000 broadcast 10.255.255.255
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: active
Opened by PID 6110


B $ ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:bd:60:ca:17:00
inet6 fd16:dcc0:f4cc::2:0:1 prefixlen 80
inet6 fe80::2bd:60ff:feca:1700%tap0 prefixlen 64 scopeid 0x4
inet 10.2.0.1 netmask 0xff000000 broadcast 10.255.255.255
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: active
Opened by PID 16037

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

Again, this looks pretty the same on machine B. $INTERFACE gets expanded
to the interface that is set in tinc.conf (as you can see below), that is,
tap0.

I tried the variants with explicitly setting `-ifp $INTERFACE` because
I realised that

vvv
fd16:dcc0:f4cc::1:0:0/96 link#3 U lo1

although

vvvv
10.2.0.0/16 10.1.0.1 UGS tap0

The explicit setting changes the first to tap0 but still I cannot ping the
other machine over the VPN. Whether routing for the IPv6 network is set on
lo1 or tap0 also depends on whether I start the jails or the tinc daemon
first. I don't know whether that is an important issue.

This is tinc.conf on machine A:

Name = A
ConnectTo = B
BindToAddress = <public-ipv4>
BindToAddress = <public-ipv6>
Device = /dev/tap0

It looks pretty the same for machine B. Since the tinc daemons can
connect, I assume everything is set up correctly here.

This is the host configuration file for A:

Address = A.domain.tld
Subnet = fd16:dcc0:f4cc:0:0:1::/96
Subnet = 10.1.0.0/16

-----BEGIN RSA PUBLIC KEY-----
<secret>
-----END RSA PUBLIC KEY-----

Again, the configuration file for machine B looks pretty the same. Except
that the subnets are the ones mentioned above.

Last but not least, I am not sure whether I need to have rtadv running,
and if I have to, on which interface, lo1 or tap0? I tried to do so but
I get errors, and still couldn't ping the other side of the VPN:

A $ cat /etc/rtadvd.conf
tap0:\
:addrs#1:addr="fd16:dcc0:f4cc:0:0::":prefixlen#80:tc=ether:

A $ cat /etc/rc.conf
rtadvd_enable="YES"
rtadvd_interfaces="tap0"

A $ grep rtadvd /var/log/messages
May 19 10:36:18 A rtadvd[76279]: <getconfig> inet_pton failed for fd16:dcc0:f4cc:0:0:1:
May 19 10:36:18 A rtadvd[76279]: <getconfig> inet_pton failed for fd16:dcc0:f4cc:0:0:1:
May 19 10:36:34 A rtadvd[76279]: non-zero lifetime RA on RA receiving interface tap0. Ignored.
May 19 10:41:24 A rtadvd[77128]: <getconfig> inet_pton failed for fd16:dcc0:f4cc:0:0:1:
May 19 10:41:40 A rtadvd[77128]: non-zero lifetime RA on RA receiving interface tap0. Ignored.
May 19 10:43:12 A rtadvd[77441]: <getconfig> inet_pton failed for fd16:dcc0:f4cc:0:0:1:
May 19 10:43:28 A rtadvd[77441]: non-zero lifetime RA on RA receiving interface tap0. Ignored.
May 19 10:52:50 A rtadvd[77441]: non-zero lifetime RA on RA receiving interface tap0. Ignored.
May 19 12:19:19 A rtadvd[95216]: <getconfig> inet_pton failed for fd16:dcc0:f4cc:0:0:1:
May 19 12:19:35 A rtadvd[95216]: non-zero lifetime RA on RA receiving interface tap0. Ignored.

As said, I guess my IPv6 routing is broken because IPv4 works fine. But
I don't know where to look for mistakes and my knowledge is rather
superficial.

Any help is very much appreciated!

Niklaas

[Mark Tinka]

Post by Niklaas Baudet von Gersdorff
I am trying to set up a tinc VPN that connects two servers. In fact, the
VPN is working for IPv4, but I cannot get it work for IPv6. Because of
this, I assume it's rather a routing problem with IPv6 than a problem with
tinc. To be honest, I don't have any experience setting up a local IPv6;
so I guess that I'm doing something wrong here.

Firstly, does your ISP support IPv6?

Mark.

[Niklaas Baudet von Gersdorff]

Post by Mark Tinka

Post by Niklaas Baudet von Gersdorff
I am trying to set up a tinc VPN that connects two servers. In fact, the
VPN is working for IPv4, but I cannot get it work for IPv6. Because of
this, I assume it's rather a routing problem with IPv6 than a problem with
tinc. To be honest, I don't have any experience setting up a local IPv6;
so I guess that I'm doing something wrong here.

Firstly, does your ISP support IPv6?

Yes, I could set up IPv6 on both machines. I can `curl -6 google.com` and
get a response.

Niklaas

[Mark Tinka]

Post by Niklaas Baudet von Gersdorff
Yes, I could set up IPv6 on both machines. I can `curl -6 google.com` and
get a response.

Has your ISP assigned you any IPv6 address space for you to use in your
network?

Mark.

[Niklaas Baudet von Gersdorff]

Post by Mark Tinka
Has your ISP assigned you any IPv6 address space for you to use in your
network?

Yes, they have. But that's not the one I want to use for the VPN. I would
like to use ULAs. So I went to http://unique-local-ipv6.com/ and generated
some randomly: fd16:dcc0:f4cc::/48 So, while both machines use the
assigned addresses to communicate with the public internet, the ULA space
I would like to use for the machines to communicate within the VPN. Does
that make sense?

Niklaas

[Mark Tinka]

Post by Niklaas Baudet von Gersdorff
Yes, they have. But that's not the one I want to use for the VPN. I would
like to use ULAs. So I went to http://unique-local-ipv6.com/ and generated
some randomly: fd16:dcc0:f4cc::/48 So, while both machines use the
assigned addresses to communicate with the public internet, the ULA space
I would like to use for the machines to communicate within the VPN. Does
that make sense?

Well, that is what ULA's are for, but to be honest, I use GUA's for both
my public and private networks.

I know ULA's mimics RFC 1918, but I don't believe in NAT66, so I've
never tried ULA's.

I think your issue might somewhat be influenced by the use of ULA's.

Mark.

[Niklaas Baudet von Gersdorff]

Post by Mark Tinka
Well, that is what ULA's are for, but to be honest, I use GUA's for both
my public and private networks.
I know ULA's mimics RFC 1918, but I don't believe in NAT66, so I've
never tried ULA's.

OK, thanks for the advice. I haven't grasped how IPv6 works completely
yet. So, NAT66 is for prefix rewriting, right? Where would I need that?
Simple routing (as I tried to achieve) doesn't work here?

Post by Mark Tinka
I think your issue might somewhat be influenced by the use of ULA's.

I just stumbled over https://wiki.freebsd.org/IPv6TODO. Would you
recommend to wait with what I am trying to achieve? I mean, the VPN works
for IPv4, so I can let the servers communicate via v4 and not v6. Does
that have any disadvantages? I mean, shouldn't we all get IPv6-ready?

Thanks for sharing your experience.

Niklaas

[Mark Tinka]

Post by Niklaas Baudet von Gersdorff
OK, thanks for the advice. I haven't grasped how IPv6 works completely
yet. So, NAT66 is for prefix rewriting, right?

NAT66 is the equivalent of NAT44.

Post by Niklaas Baudet von Gersdorff
Where would I need that?

I'd say never. NAT66 is mostly being used by those are like NAT44.

NAT44 is useful because IPv4 addresses are in short supply. IPv6 is not
in short supply, so NAT66 is not that useful, but that's just my opinion.

Post by Niklaas Baudet von Gersdorff
Simple routing (as I tried to achieve) doesn't work here?

Have you tried it without the firewall? Technically, I can't see a
reason why it's not working, despite it being ULA.

Post by Niklaas Baudet von Gersdorff
I just stumbled over https://wiki.freebsd.org/IPv6TODO. Would you
recommend to wait with what I am trying to achieve? I mean, the VPN works
for IPv4, so I can let the servers communicate via v4 and not v6. Does
that have any disadvantages? I mean, shouldn't we all get IPv6-ready?

Don't wait. Get your IPv6 going sooner rather than later.

I'd advise to use GUA's instead, but for your internal purposes, ULA's
will work too.

Mark.

[Niklaas Baudet von Gersdorff]

Post by Mark Tinka

Post by Niklaas Baudet von Gersdorff
OK, thanks for the advice. I haven't grasped how IPv6 works
completely yet. So, NAT66 is for prefix rewriting, right?

NAT66 is the equivalent of NAT44.

Post by Niklaas Baudet von Gersdorff
Where would I need that?

I'd say never. NAT66 is mostly being used by those are like NAT44.
NAT44 is useful because IPv4 addresses are in short supply. IPv6 is
not in short supply, so NAT66 is not that useful, but that's just my
opinion.

Okay, I get that. But I do not quite get how that was related to my
question?

Post by Mark Tinka

Post by Niklaas Baudet von Gersdorff
Simple routing (as I tried to achieve) doesn't work here?

Have you tried it without the firewall? Technically, I can't see
a reason why it's not working, despite it being ULA.

I just disabled the firewall and tried it -- but without success.

Post by Mark Tinka
Don't wait. Get your IPv6 going sooner rather than later.
I'd advise to use GUA's instead, but for your internal purposes, ULA's
will work too.

I guess, I'll send a similar inquiry to tinc's mailinglist. Maybe the
issue is indeed related to tinc itself.

Anyway, thanks a lot for your advice!

Niklaas

[Niklaas Baudet von Gersdorff]

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

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
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

[Kevin Oberman]

On Thu, May 26, 2016 at 12:36 PM, Niklaas Baudet von Gersdorff <

Post by Niklaas Baudet von Gersdorff
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
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

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
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.
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
route add -inet6 -net fd16:dcc0:f4cc:1::/64 -interface $INTERFACE
To make this complete, these are the relevant host configurations for
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
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.

[Mark Tinka]

Post by Niklaas Baudet von Gersdorff
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.

Interesting, I did not know that.

I know that if you want SLAAC to work, you need to assign a /64 prefix.

We use /112's for hosts but based on GUA's, and that works fine.

Mark.

[Mark Tinka]

Post by Kevin Oberman
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.

Fully agree.

Mark.

[Niklaas Baudet von Gersdorff]

Post by Kevin Oberman
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.

Kevin, thanks for your comment. I have no professional background in IT,
so I really appreciate your remarks.

Post by Kevin Oberman
The most valid use is when you can only get a /64 from your provider.

I got a /112 for each of my virtual servers... So, I decided to go for
ULAs for the VPN between them.

Post by Kevin Oberman
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.

I agree. In addition, I would like to emphasise that it should be in
both FreeBSD's and tinc's handbook. I guess I could have known, if I had
read the RFCs, but adding some notes in the handbook(s) would ease
things a lot.

[Kevin Oberman]

On Fri, May 27, 2016 at 12:09 AM, Niklaas Baudet von Gersdorff <

Post by Niklaas Baudet von Gersdorff

Post by Kevin Oberman
The most valid use is when you can only get a /64 from your provider.

I got a /112 for each of my virtual servers... So, I decided to go for
ULAs for the VPN between them.

This is fine, but why not use link-local for the VPN links? That's the
primary reason for them. (N.B. I am not aware of your architectural
details, and ULAs for the VPNs might be appropriate.)

As long as they are properly allocated and statically routed, you can use a
/112 or any other prefix length, just don't assume that they will work in
any more global environment.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: ***@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

[Niklaas Baudet von Gersdorff]

Post by Kevin Oberman
This is fine, but why not use link-local for the VPN links? That's the
primary reason for them. (N.B. I am not aware of your architectural
details, and ULAs for the VPNs might be appropriate.)

Is it? I didn't know that I can use link-local addresses for the VPN
too. How do I decide between link-local or unique-local addresses for
the VPN? What do I make the decision dependent on?

Niklaas

[Mark Tinka]

Post by Niklaas Baudet von Gersdorff
Is it? I didn't know that I can use link-local addresses for the VPN
too. How do I decide between link-local or unique-local addresses for
the VPN? What do I make the decision dependent on?

Don't do it!

For any service, use GUA's. Always.

Mark.

[Mark Tinka]

Post by Kevin Oberman
This is fine, but why not use link-local for the VPN links? That's the
primary reason for them.

That's really not good advice.

I'd caution against using link-local addresses for any type of service.

Link-local addresses are used for host-to-host communications on the
same Layer 2 segment. Routers will not forward traffic with link-local
addresses.

Besides, link-local addresses are automatically created. They cannot be
guaranteed to be unique anymore than they can be guaranteed to be constant.

Mark.

[Niklaas Baudet von Gersdorff]

Post by Mark Tinka

Post by Kevin Oberman
This is fine, but why not use link-local for the VPN links? That's
the primary reason for them.

That's really not good advice.
I'd caution against using link-local addresses for any type of
service.
Link-local addresses are used for host-to-host communications on the
same Layer 2 segment. Routers will not forward traffic with link-local
addresses.
Besides, link-local addresses are automatically created. They cannot
be guaranteed to be unique anymore than they can be guaranteed to be
constant.

Thanks for repeating that. That's how I understood it as a novice too.
:-) And that's why I thought I should not go for them. Because I don't
have many GUAs available, I thought I should go for ULAs then.

Niklaas

[Mark Tinka]

Post by Niklaas Baudet von Gersdorff
Thanks for repeating that. That's how I understood it as a novice too.
:-) And that's why I thought I should not go for them. Because I don't
have many GUAs available, I thought I should go for ULAs then.

Why don't you have GUA IPv6 address space?

Your ISP should be able to assign you a /48 or /56 prefix for you to use
on your LAN. That's more than plenty of space.

Mark.

[Mark Tinka]

As I wrote, I only got a /112 form my ISP. This still exceeds the amount
of addresses that I need but I decided to go for ULAs for flexibility.
Anyway, it's working. :-)

I'd suggest going back to your ISP and asking for at least a /56.

If they don't want to give you this, time to look for another ISP.

Mark.