Getting DHCPv6 prefix from ISP; how to distr. IPv6 connectivity to network clients?

General questions
1

Currently, I’m successfully getting an IPv6 subnet from Comcast using DHCPv6:

[code]ethernet eth0 {
address dhcp
address dhcpv6
description “Red Interface”
duplex auto
hw-id 00:50:56:3f:ff:01
smp_affinity auto
speed auto
}

$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description

br0 172.16.123.1/24 u/u Green Bridge from eth1 to vtun0
eth0 68...131/23 u/u Red Interface
2001:558:6016:19::::*/64
eth1 - u/u Green Interface
eth2 192.168.123.254/24 u/u DMZ 1 Interface
lo 127.0.0.1/8 u/u
::1/128
vtun0 - u/u Green VPN[/code]

This appears to be working great, and I can ping other public IPv6 address from my VyOS box.

Next I need to distribute addresses from this 2001:558:6016:19::/64 address space to clients on one of my subnets (these clients currently already get private IPv4 addresses via DHCP). I set up a static address in the 2001:558:6016:19::/64 space on br0 and then enabled router-advert on br0.

At first it appeared to be working. My eth1/br0 clients are getting IP addresses in the 2001:558:6016:19::/64 space. They can ping their own addresses, and they can ping the IPv6 address assigned to br0.

However, they can’t ping the IPv6 address assigned to eth0, and they can’t ping any other public IPv6 addresses. Remember: When I’m logged in to the VyOS machine, I can ping the IPv6 address assigned to eth0, and I can ping other public IPv6 addresses. But from a client machine with an IPv6 address, I can ping br0/eth1, but I can’t ping eth0 or other public IPv6 addresses.

I used tcpdump to monitor IP6 traffic on eth1 and eth0. For pings going to eth0 and to other public IP addresses, I can see the ICMPv6 echo requests reaching eth1 and I can see them leaving eth0, but an echo reply is never returned to eth0 (and, thus, nor eth1). When I ping the exact same IPv6 addresses while logged into VyOS, eth0 receives echo replies as expected.

The firewall isn’t an issue—for testing purposes, I’ve got it wide open for IPv6 traffic.

Routing shouldn’t be an issue—since the echo requests are going through eth1 and then eth0, they’ve obviously been routed properly.

2

See ipv6 neighbor discovery. That won’t work with two networks (eth0 and br0) sharing the same /64. I don’t think there is an equivalent of ipv4 proxy arp to connect those two nets yet let them share the same ipv6 address space.

3

You’re right in what you said, but turns out wrong in what the problem is. Comcast, it turns out, supports DHCPv6 and DHCPv6-PD (prefix delegation). If your router requests DHCPv6-PD, Comcast will assign a /128 in a /64 subnet to the WAN interface and delegate a /60 (for sixteen /64 subnets) for you to use on your LAN. If, however, your router only requests DHCPv6, Comcast will only assign it a single /128 in a /64 subnet.

VyOS does not yet support DHCPv6-PD (http://bugzilla.vyos.net/show_bug.cgi?id=112), so the ultimate outcome is that VyOS is unusable for IPv6 on Comcast. If you can only get a single IPv6 address, it’s impractical (arguably impossible) to use IPv6 for a fully-dual-stack in-home network. This is very unfortunate. I’m going to propose changing that Bugzilla from an enhancement to a bug since it makes VyOS unusable for IPv6 on the largest ISP in the country. I’d love some backup on my comment on the Bugzilla if you could provide it.

4

The following works (but not as well as DHCPv6-PD). You can ignore the ipv6 from your provider and instead get a free tunnel from tunnelbroker.net (or many others). The advantage to that is that your ipv6 addresses are now static, so you don’t have to play dns games to reference them globally.

The equivalent of ipv4 nat is rfc6296 prefix translation. That is not in vyos yet, but when available would allow you to map 1-1 your internal /64 to the external /64 given to you by your provider.

5

I’m not interested in a tunnel, but thanks for the suggestion. I’m looking for native IPv6. Additionally:

That’s part of the problem I was describing above. Comcast isn’t actually giving me a /64. It’s giving me a /128 belonging to a /64 subnet. So I don’t even have that /64 (if I did, I could hack around it). Comcast will only assign more than a /128 if you request it with DHCPv6-PD.

6

A bit offtopic but NPTv6 support has been merged in VyOS.

See this commit : Add initial support for NPTv6 (#387) · vyos/vyatta-nat@9571f0e · GitHub

8

Dark Dragon:

VyOS switched from Bugzilla to Phabricator and, unfortunately, no issues were migrated. I have migrated this issue and all of its comments as of today:

https://phabricator.vyos.net/T421

9

Does “set nat nptv6” not work for you? You can configure your inside interface with a private /64 block, then prefix translate that to the /64 obtained via dhcpv6 from your isp. The only issue is you need to reconfigure if the dhcpv6 block changes.

We could possibly add something like “set nat nptv6 rule 10 outside-prefix dhcpv6” to have vyos automatically change the nptv6 config when the dhcpv6 address renews.