[GLLUG] RADVD configuration

[Chris Bell]

On Wednesday 05 Apr 2017 18:04:22 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)

Sorry, typo in my email. Yes I am using fdxx:xxxx:xxxx:yyyy:: where the x 
characters are generated as a random number and yyyy are local (and actually 
only the last two bits vary between the three local networks).

> 
> 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 will not have a global prefix until my ISP lives up to its promise.
> 
> 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!

Yes, I have the shorewall box a few metres away from where I am sitting, with 
access currently enabled from the old IPv4 firewall, and I can reach all the 
other test equipment from my seat. (I did read the warnings about remote 
configuring of shorewall).
> 
> 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.

Hmm, as you say there is an option to retry, but it is supposed to retry by 
default anyway.

I have just been looking at RFC 8140. Interesting, although I still need to 
check the other references at the end.

> 
> Tim.
> 
> 
> _______________________________________________
> GLLUG mailing list
> GLLUG at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/gllug

-- 
Chris Bell
website chrisbell.org.uk