[GLLUG] radvd and vlans

[Tim Woodall]

On Wed, 7 Feb 2018, Tim Woodall via GLLUG wrote:

> On Tue, 6 Feb 2018, Chris Bell wrote:
>
>> 
>> Hello Tim,
>> I have been trying to learn how to do things using shorewall/shorewall6 in 
>> a
>> box with four ethernet interfaces. I do not have native IPv6, and do not 
>> know
>> when it will appear without warning, but I am trying to use 6to4 for 
>> testing.
>> The various facilities such as SixXS all appear to have been discontinued
>> within the last year.
>
> I can highly recommend AAISP. When I was having an IPv6 routing problem
> and tearing my hair out when it made no sense I dropped them an email
> and same day they came back saying they'd checked their routing tables
> and had I tried adding a static route? (which I hadn't - and going to do
> that uncovered the real issue of a presumably old but automatically
> added static route that was garbage. (I definitely hadn't added it so it
> must have been automatic or added when AAISP supplied the router)
>
> (I ought to have tried it without prompting but when ping is working one
> way but any attempt to connect the other way gets "no route to host"
> including ping and ssh doesn't work even the way ping works but
> ipv6scanner.com says that the port is open and both machines (on
> different /48s) can connect everywhere else, it's easy to forget to
> try the easy things.)
>
> My biggest IPv6 criticism is that the UI lets you add a random /64 or
> /60 route in your /48. Or you can get the entire /48 routed (which is
> how I've ended up with two /48s on two lines.) But no way to route a
> particular /64 if you want a specific one.
>
> Turns out that you can email support and they'll change the random /64
> into a particular one - meaning that I didn't need to route the entire
> /48 down a line to get specific /64s available. At some point I'll work
> out what I am using and get my allocation reduced to a single /48 (which
> I'll treat as two /49s)
>
>> I found that multiple physical interfaces appeared in random order in /etc/
>> network/interfaces until I included the workaround to pre-up check MAC
>> addresses in Debian Jessie, but the system has been modified in Stretch so 
>> that
> No idea what is happening here. I've not seen this issue. I know there
> were changes to how interfaces were named. Have you tried
> 70-persistent-net-rules? (the changes to cdrom device naming caused me
> grief - I think they were trying to cater for people who plug in
> different cdrom drives so that the one that is plugged in is always
> /dev/cdrom but that's not the way I wanted to work - particularly as I
> sonetimes had two connected and I wanted them consistently named)
>
>
>> each interface is named according to its location as found using lspci.
>> I tried to configure everything in shorewall6 but nothing worked as 
>> expected,
>> so I started from scratch setting things manually step by step. I have not
>> managed to use radvd to set an auto default plus a different prefix for 
>> some
>> interfaces using correctly allocated 64bit addresses based on fd00::/8
>> according to RFC4193,
>> ## ip address add
>> appears to accept additional addresses but they did not appear in
>> ## ip address show
>> while
>> ## ip route add
>> has simply rejected all attempts at routing between the interfaces using 
>> any
>> preferred prefix.  Everything was as configured in (local only) Bind9.
>
> Are you using busybox? I think the ip command is crippled in that. Also,
> I'd always use ip -6 addr add ...  I don't know if the -6 is optional as
> I've not tried without it.
>
> Are you using LL address for the gateway? This was probably the hardest
> thing to get my head around.
>
> Are you allowing all the neighbour discovery ICMP messages?
>
> I have the following on my firewall
>    ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -s fe80::/10 -j ACCEPT
>    ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -s fe80::/10 -j ACCEPT
>    ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -d fe80::/10 -j ACCEPT
>    ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -d fe80::/10 -j ACCEPT
>    ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -s 2001:08b0:xxxx::/48 -j
> ACCEPT
>    ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -s 2001:08b0:xxxx::/48 -j
> ACCEPT
>    ${IP6TABLES} -t filter -A INPUT  -p icmpv6 -d 2001:08b0:xxxx::/48 -j
> ACCEPT
>    ${IP6TABLES} -t filter -A OUTPUT -p icmpv6 -d 2001:08b0:xxxx::/48 -j
> ACCEPT
>
> These allow more than strictly required. Particularly lines 6 and 7. I
> think there's a ff00:: address involved in this that would probably be
> better than my entire /48 to/from anywhere.
>
> (and obfscating my /48 is probably futile - might even be visible in the
> header of the enail - but I'm hopefully now using privacy addressing)
>
> Tim.
>
>
>

Quick google - the addresses are ff02::2 - all routers multicast address
and ff02::1 - all hosts multicast address.