[GLLUG] RADVD configuration

[Tim Woodall]

On Wed, 5 Apr 2017, Tim Woodall via GLLUG wrote:

> On Wed, 5 Apr 2017, Chris Bell via GLLUG wrote:
>
>> On Wednesday 05 Apr 2017 12:32:15 you wrote:
>>> Hi,
>>> 
>>> Think of the Global address as the one used between hosts (e.g. interface
>>> eth0), and the site local as the loopback (e.g. interface lo). (i.e. not
>>> route-able outside of the host)
>>> 
>>> Kind Regards
>>> 
>>> James
>>> 
>> Thanks for the reply. There is sparse documentation for RADVD, so I have 
>> been
>> ploughing through well over 100 RFC's trying to find information. An 
>> interface
>> can have more than one IPv6 address, in theory as many as you wish. The 
>> fexx::
>> series of address prefixes are available for site local use as specified in 
>> the
>> RFC's, and I am trying to use one site-local prefix for each of the local
>> networks, (I am required to generate a genuine random number for bits 9 to 
>> 56,
>> and they have the same initial 62 bits with only bits 63 and 64 changed), 
>> to
>> be used for site local connections only, and in addition all can eventually
>> share the same allocated global prefix.
>> According to the RFC's each network interface should receive the full
>> information from RADVD and then choose the correct prefix to match the 
>> route.
>> The shorewall6 interfaces should each have both a site local address prefix 
>> and
>> the global allocated address prefix. I have not seen anything to suggest 
>> that
>> the suffix for each address should be the same on any individual interface,
>> there could be an automatically generated suffix based on the MAC as well 
>> as one
>> or more manually configured. The fun thing is to persuade shorewall,
>> shorewall6, rdnss, dnssl, abro, and radvd to actually run, and then work
>> together, with a laborious time-consuming process of trying another
>> configuration amendment, reading the error messages, and so on.
>> It is not really necessary for my home network, but I think it is supposed 
>> to
>> work.
>> 
>> 
>
> I think you're possibly confused between unique-local and site-local.
> (Or I am :-) )
>
> site-local is (was) fec0::/10
> unique-local is fc00::/7 (really fd00::/8)
>
> Looks like you're trying to use the site-local prefix (first 8 bits)
> with unique-local addressing. That may, or may not, be what is causing
> some of your problems. If you're ending up with a link-local address
> then it won't be able to route.
>
> I've not tried to give multiple prefixes out via radvd. I have a global
> /48 and link-local addressing only.
>
> I have had problems with machines not picking up the correct prefixes
> when I've been changing them. It can be really hard to make the machines
> forget about what they saw previously/what they had configured
> previously - especially if they're also configured to generate random
> outgoing addresses which (obviously) they need to remember for a time
> and especially if you're trying to configure one or more of them
> remotely where you don't want to take down all the interfaces at once!
>
> Finally, radvd seems to have problems with interfaces that don't exist
> when it starts.
> My /etc/ppp/ipv6-up.d/ has a 0000radvd script that generates a config
> file for the interface that has just come up and then starts a radvd
> instance for it. There are various config options in radvd for
> interfaces that don't (yet) exist etc but I just couldn't ever get it to
> work so that it would advertise over a vpn.
>
> Tim.
>
And on checking my machines I saw that ipv6 wasn't working on the vpn.
If you ip link down/ip link up then it appears that the interface loses
all knowledge of ipv6 - despite /proc/sys/net staying the same (I was
renaming the interface)

I also am publishing my /48 via radvd but that isn't being picked up by
the routing tables. Only the /64 prefix. The router advertisement is
making it through the vpn - I can see it with radvdump - but it's not
appearing in ip -6 route show. (this may never have worked)

But I did try publishing two separate prefixes and they've both been
picked up.

My config file now looks (something) like this:

interface $IFNAME
{
   AdvSendAdvert on;
   UnicastOnly on;
   MinRtrAdvInterval 3;
   MaxRtrAdvInterval 10;
   route xxxx:xxxx:xxxx::/48
   {
   };
   prefix xxxx:xxxx:beef:$ADDR::/64
   {
     AdvOnLink on;
     AdvAutonomous on;
     AdvRouterAddr on;
   };
   prefix xxxx:xxxx:dead:$ADDR::/64
   {
     AdvOnLink on;
     AdvAutonomous on;
     AdvRouterAddr on;
   };
};

HTH

Tim.