RADVD for IPv6 assignement, DNSMasq for DHCP handing out DNS for IPv6 clients – how to do

You didn't say who your ISP was, but the following works on Comcast in areas where they have rolled out IPv6.

I had to use wide-dhcpv6-client since none of the other DHCPv6 clients could handle all of getting an address for the ISP-facing interface, prefix delegation, and Comcast's maximum /60 network mask at the same time.

After installing wide-dhcpv6-client, edit /etc/network/interfaces so your eth1 IPv6 settings look like this:

iface eth1 inet6 auto
        post-up sysctl -w net.ipv6.conf.ext0.accept_ra=2

Edit /etc/wide-dhcpv6/dhcp6c.conf so it looks like this:

profile default
{
  information-only;

  request domain-name-servers;
  request domain-name;

  script "/etc/wide-dhcpv6/dhcp6c-script";
};

interface eth1 {
    send rapid-commit;

    send ia-na 0;
    send ia-pd 0;
};

id-assoc na 0 {

};

id-assoc pd 0 {
    prefix ::/60 infinity;

    # Internal interface (LAN)
    prefix-interface eth0 {
        sla-len 4;
        sla-id 0;
        ifid 1;
    };
};

The "na" section gets an IPv6 address for eth1 (facing your ISP). The "pd" section gets a prefix delegation for your internal network and will assign the IPv6 address "[prefix]::1" to eth0 (your internal interface). If you have additional internal networks, you can add additional "prefix-interface" sections for those interfaces and increment the "sla-id" for each one.

Then you need a router advertisement daemon on the system for your internal network. You can use either radvd or dnsmasq.

If you are using dnsmasq, the necessary additions to /etc/dnsmasq.conf for IPv6 are

# Enable IPv6 Router Advertisement (RA) features.
enable-ra

# Advertise delegated prefix based on the IPv6 address of eth0.
dhcp-range = ::1,constructor:eth0,   ra-stateless, ra-names, 4h

You'll need to install the dnsmasq from Debian testing since the version that ships with Debian wheezy does not do router advertisements properly.

Then ifdown and ifup your external interface, make sure dhcp6c is running, and see if both your external and internal interface have IPv6 addresses other than the link-local ones (the "fe80::..." addresses). If all of that worked, restart dnsmasq, and the systems on your LAN should start automatically configuring IPv6 addresses for themselves.

The issue I have is that the DSL router is sending neighbor solicitations packets on eth1 when it gets inbound packets from the internet, and those neighbor solicitations are not being passed from eth1 -> eth0 on the Linux router.

That's normal. Neighbour solicitations work just like ARP queries – they translate an IP address to a MAC address, and therefore they only make sense within the same broadcast domain. It makes no sense for a router to forward them.

(Though in some situations a router can proxy them, as described at the end, but... leave that for plan C.)

I am thinking that this is occurring because the DSL router thinks it is directly connected to the home network (which is how it would normally be in 99% of home networks without a Linux router in the middle).

Yes, and you never told it otherwise.

So your current situation is that the same IP subnet is being used by two different networks, and you're expecting the Linux router to work as a bridge... Which is almost the exact opposite of a router.

(If the confusing part is IPv6, think about the whole setup in IPv4 terms, as routing is more or less the same in both, and ND is mostly equivalent to ARP. So if you wouldn't use the same 192.168.1.0 subnet in v4...)

Your best course of action is to obtain a second /64, and use that for your Linux router's eth1 network. (If the DSL router obtains its prefix via DHCPv6-PD, it might be possible to trick it into requesting a second one.) The difference though is that the 2nd /64 wouldn't be used directly on an interface but instead routed towards the Linux router's address.

For example:

• DSL router has 2001:db8:0:0:a:b:c:d on the WAN interface.
• DSL router obtains 2001:db8:10:0::/64 from the ISP, self-assigns 2001:db8:10:0::1/64 on the LAN interface, and sends Router Advertisements for it.
• Linux router autoconfigures 2001:db8:10:0:x:y:z:t on eth1 based on RAs.
• Linux router obtains 2001:db8:10:1::/64 from the ISP (somehow), self-assigns 2001:db8:10:1::1/64 on the eth0 interface, and radvd sends Router Advertisements for that – not for the first subnet.
• The DSL router needs a route like "2001:db8:10:1::/64 via 2001:db8:10:0:x:y:z:t" so that all traffic for the 2nd subnet is forwarded towards the Linux router.

(Apologies for the not-very-clear example.)

Sometimes the ISP delegates a whole /60 or even /56 to you, and routes all of it towards the DSL router. In that case you could just set up the 2nd subnet without any DHCPV6-PD magic. Really though I cannot provide an good "generic" answer here as it's both ISP-dependent and CPE-dependent.

If obtaining a second /64 prefix is impossible, other possible options are:

• Turn the Linux system into a pure bridge, without any routing functionality.

• Use other sources for obtaining additional /64's, such as a tunnel provider (or 6to4). The existing tunnel services are going to work much more reliably (except for some extra latency) than the hacks described below.

• Make the DSL router only obtain the /64 but not configure it for LAN. (Depends on how flexible the router is.) Instead, again set up a route for that /64 via your Linux system's eth0 link-local address, and likewise set up a route on the Linux system for ::/0 via the DSL router's LAN link-local address. As a result, the /64 will be only used in the 2nd subnet, and the 1st one won't have any public prefix at all.

• Continue with your current setup, but install 'ndppd' to perform Neighbour Discovery proxying. (No, multicast forwarding won't do as ND packets often have link-local source addresses.) Be careful with this, it can make things really confusing.

• Use private (ULA) addresses for the 2nd LAN, and enable 1-to-many NAT (masquerading) on the Linux router...losing most of IPv6's usefulness in the process. (Yes, officially NAT doesn't exist in IPv6, but that didn't stop Linux netfilter/iptables from giving in and implementing it.)