# [SOLVED] Gentoo ipv6 router and linux clients

## araemo

So, I've done some searching, and found a lot of conflicting information on how to set up a linux based ipv6 router receiving an ipv6 prefix delegation from your ISP and using it for your LAN.

So far, I've created a custom script that I thought was working perfectly... until I noticed my linux systems cannot access the ipv6 internet unless I manually change their default (ipv6) gateway.

The script I built runs dhclient to get the prefix delegation, parses it out, and updates radvd.conf with the appropriate prefix, and then starts radvd.  I was lead to believe that is all I would have to do, but I do one more step before my windows clients are able to access the ipv6 internet: I statically assign an address from the delegated pool to my LAN NIC.  From everything I've read, that shouldn't be necessary, but once I do that, my windows clients start working.

The next item is my linux clients.. They are unable to ping any ipv6 hosts until I manually change their default route to point to that statically assigned IP above.  By default, they inherit the link-local address from my router's LAN interface as their default gateway.. and everything I can find suggests that is correct.  The windows clients also list that address as their default gateway, but they don't WORK until the global address is assigned to the LAN nic as well.

So, basically, what gives?  What do I need to set to get my linux clients working?  Am I missing something on the router config that is 'required', but windows is deriving automatically, or are my linux clients misconfigured?

Interesting fact: I can see the router passing the echo request, and the echo reply gets as far as my WAN interface, and it doesn't get blocked by my firewall (verified both), but it doesn't get passed.  I think the root cause of why it doesn't get passed is that my router doesn't seem to know how to reach the linux client, as shown by 'ip neigh', the address of that particular client shows as FAILED.  What confuses me is that as soon as I specify the default gateway on the client manually, and run a ping6, the router now shows the proper link-local MAC address in 'ip neigh'.  Why does the router not already know that, when it was already successfully passing packets on behalf of that IP/MAC?

tl;dr:

Router (LAN IP changed to 2::1 for argument):

```
araemo@router / $ ip neigh

2::2 dev lan0  FAILED

```

Client (IP changed to 2::2 for argument):

```
araemo@SQL01:~$ ping6 www.google.com

PING www.google.com(ord08s11-in-x12.1e100.net) 56 data bytes

^C

--- www.google.com ping statistics ---

6 packets transmitted, 0 received, 100% packet loss, time 4999ms

```

Until I run this on the client (IP changed to 2::2 for argument):

```
araemo@client:~$ sudo route -6 add ::/0 gw 2::1

araemo@client:~$ ping6 www.google.com

PING www.google.com(ord08s11-in-x13.1e100.net) 56 data bytes

64 bytes from ord08s11-in-x13.1e100.net: icmp_seq=1 ttl=51 time=57.2 ms

```

At which point, back on the router, I magically get:

```
araemo@router / $ ip neigh

2::2 dev lan0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

```

I feel like this is likely a router config issue, since if I delete the route on the client (so its default route is back to the fe80:: link-local address for the router), pinging still works for a while, until the neighbor discovery gets out of date.

radvd.conf:

```
interface lan0

{

        ## (Send advertisement messages to other hosts)

        AdvSendAdvert on;

        ## (Fragmentation is bad(tm))

        #AdvLinkMTU 1280;

        MaxRtrAdvInterval 300;

        ## (IPv6 subnet prefix we've been assigned by our PoP)

        prefix 2::1/64

        {

                AdvOnLink on;

                AdvAutonomous on;

                DeprecatePrefix on;

                AdvRouterAddr on;

        };

};
```

And my custom ipv6-up script:

04-ipv6.start:

http://pastebin.com/ka4BsyaX

The setup script is a bit rudimentary, but it seems to make ipv6 routing work for my windows clients.Last edited by araemo on Thu Jan 29, 2015 3:23 am; edited 2 times in total

----------

## UberLord

That dhclient script is quite bad really.

What happen if dhclient fails or the prefix changes?

I'm sure there is a better of of doing this with dhclient as well, but have you considered using dhcpcd instead?

ArchLinux has a good article on using dhcpcd alongside radvd where it just works - no script magic required. Their dhcpcd.conf entry for the ia_pd statement is a touch overkill though

```
ia_pd 2 eth1
```

should be fine for most. You *do* need their example though if you are delegated a /64 - most are a /48 or /56 so though so my example is fine.

Of course that doesn't solve your original issue about Linux clients not working, and as you've masked out the actual numbers my guess is that you're just adding the actual prefix to the interface as given.

So you're handed a prefix of dead:beef::/64 so you add dead:beef::/64 to your downstream link. This won't work - it needs to be changed from a prefix to an address like so - dead:beef::1/64. And voila it might start working.

dhcpcd of course does this for you  :Smile:  assuming I'm correct, you now have two solutions! Let us know how it works out for you.

----------

## araemo

Thank you for the pointer at that article, I think I had skimmed it, but most of it didn't seem applicable to what I was doing, so I must have missed that section.

You were wrong in your guess.. I was adding a 1 to the end of the prefix, so it goes from dead:beef::/64 to dead:beef::1/64, and that's what I was assigning to my LAN side.  I think it handled prefix changes fine though... but I knew it was kludgy and a bad idea, I just hadn't found any decent documentation on how to get the prefix delegation to flow automatically through to a different interface like the dhcpcd config you pointed me at.  Almost all the how-tos are for old tunnel providers that provided persistent prefixes.

So, to put something here as a warning to others: If you use a cable modem, and follow that archlinux guide to enabling dhcpcd prefix delegation... don't use their iaid line, and change the ia_pd line to:

ia_pd /::/64 intern0/0/64

Basically, by specifying the iaid you're telling dhcpcd to use 0x1 as its MAC address when generating its unique DHCP unique identifier, which is likely different from the MAC-derived one it used last time it requested an address through your modem.  In my case, swapping back and forth between a 'known good working' dhcpcd.conf and a ipv6-enabled one and just restarting net.wan0... confused my cable modem a LOT, causing a ton of ipv4 packet loss.  I MAY have been ok if I went whole-hog, changed the iaid to 1, and rebooted my router and my cable modem at the same time... but for use with your ISP, I don't see an issue in using the MAC-derived client ID.  Figuring out why it seemed like 'using dhcpcd to get a delegation kills my ipv6' took me about 24 hours... I just couldn't actually find anything my host was doing wrong, it really seemed like the packets just were not arriving from my modem sometimes. (and that's what it turns out it was!)

Also, my original issue?  I noticed that all my linux clients are downstream of a wireless bridge, so I booted a linux vm on a wired connection upstream of the wireless AP, and it worked fine out of the box.  Wireless clients running android also work fine.  And the odd one is that wired windows clients downstream of the wireless bridge also work fine... but since all the linux ones downstream of the bridge break, and ones upstream of it work fine, I bet the bridge is failing to pass some ipv6 broadcast traffic right.

So, for the TL;DR: DO NOT USE my script above. Use the archlinux guide to using dhcpcd.. but don't specify iaid, and change ia_pd from "1/::/64 intern0/0/64" to "/::/64 intern0/0/64"

Gonna mark this solved. :)

----------

## skaloo

/removedLast edited by skaloo on Thu Jan 29, 2015 6:42 pm; edited 2 times in total

----------

## UberLord

Please don't follow his guide. araemo is doing the Right Thing wheres skaloo is promoting bridging to work around a limitation in his ADSL router.

----------

