With my FireBrick hat on for a change, one of our customers has a Zen line with IPv6
He was surprised to find the IPv6 was not working when using a FireBrick FB2700, and so was I!
As usually, within a couple of hours of reporting the issue, we have new code that solves it, even on a weekend. I have to say though that I was impressed that Zen looked at the FireBrick web site and manual in an effort to help their customers with this. Well done guys.
For so long FireBrick has been used on A&A lines for IPv6, it is nice to see how other people do it.
The problem is that the protocols used for this are horrid. I think I mentioned this before. I really think a PPP level negotiation would make a lot more sense. I even have my name on a draft RFC, but no luck on that.
What happens is, after the IPV6CP negotiation for a 64 bit interface address, you can then send IPv6 using the FE80:: based address. To get any real IPv6 addresses works a lot like a LAN but with extra bits. You can get Router Announcements on the PPP, and pick an address and you can use DHCPv6 to request an address and prefixes for your LAN.
Traditionally, as it seems the most common way, FireBrick used the latter - expecting the DHCPv6 to allocate a "real" address on the link itself (maybe) and a prefix for LAN. We actually ask for one or more /64 prefixes for different LAN interfaces as configured, but by default it is all of the interfaces we have. You can configure which interfaces to use with which PPPoE links though, if you want.
We have a bug where the IPV6CP forced a new interface address, which Zen do, specifically 00:00:00:00:00:01 for some reason. We were not then using the right FE80:: address for DHCPv6, or rather not accepting replied to the address we were using due to a silly mismatch of the two.
It also looks like Zen do RA for the PPP side address, and DHCPv6 for Prefix Delegation, which sort of almost worked. We had some bugs. For a start, we did not handle "infinity" as the validity for these (even though that is what we requested), silly error, but it meant we expired every allocation one second before we got it! Took me a while to worth that one out...
We also did not handle a case of asking for a prefix even if no interfaces are set up to use it (e.g. where Zen is a secondary ISP on separate routing table).
However, with a few tweaks we have it sorted, only using DHCPv6, not RA, but picking an address for PPP link from the delegated addresses and requesting at least one /64 by default.
Obviously, we are happy to test with other ISPs and make sure we work. IPv6 should "just work" with a default config with any ISP, not just A&A.
Our customer now says IPv6 wastes a lot of time - not because of any difficulty setting up, but because he just spent an hour playing www.loopsofzen.uk which is only on IPv6.
Well done Zen, the world is gradually moving forward. A&A started doing IPv6 in 2002.