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.
Subscribe to:
Post Comments (Atom)
Don't use UPS to ship to UK
I posted about shipping and importing and tax and duty - general info. But this is specific. DON'T USE UPS! I had assumed the UPS issue ...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Cheers Rev, nice work (as usual)
ReplyDeleteGood to see I'm still first on the loops of zen leader board. Lol.
ReplyDeleteBT is fine now too.
ReplyDeleteCool
DeleteWhen I first signed up for Zen's IPv6 trial, they explained how this was all very standards compliant (seemed messy to me..). Probably still have the email detailing the standards if its of interest...
ReplyDeleteI don't doubt it is, just so many to choose from :-(
DeleteEven on the ethernet side, the standards for IPv6 autoconfig are, frankly, a complete mess... Especially if you want any kind of control over the address the client machines have.
ReplyDeleteWe need to be able to identify which user traffic has come from. For IPv4 this is fairly easy, you can use a captive portal, or 802.1x to link an IP address with a user name. For IPv6 this is a complete and utter mess:
Everyone has to use router announcements to set up the link local addresses at least. You can use RA to also configure the global scope address through SLAAC. You can also configure stuff like DNS through RA, but nothing supports that so in reality you can't. Also, devices will usually do IPv6 privacy extensions - the router has no control over whether they do or not, and if they do then they are going to change their address regularly, so good luck trying to link an IP with a user name for any period of time.
So since nothing supports configuring DNS through RA you need DHCP anyway. You can run this in stateless mode, where the clients do SLAAC as normal and then DHCP to get things like the DNS address. But again, IPv6 privacy extensions mean clients keep changing address so you can't identify the users from captive portal logins (at least, not unless you want to regularly pop up the portal and piss off the user!).
DHCP can also be run in stateful mode, which is more like traditional IPv4 - the DHCP server is responsible for giving the device a global scope address. This seems to solve most of the problems until you realise that nothing supports it (at least, as far as I can tell Android doesn't support stateful DHCPv6 at all, and last time I checked Fedora didn't support it without a lot of faff).
So all in all a complete and utter mess...
Here's how I think it would have been sensible to do this stuff:
- Use router discovery to allocate all the addresses. The router could tell the client whether to do SLAAC with privacy extensions, SLAAC without privacy extensions or explicitly give the client an address much like stateful DHCP does.
- Discover all the other services, including the DNS servers through mDNS. This is already done to find things like printers, no reason why you can't also do it to find DNS servers, NTP servers, and all the other stuff you'd usually do through DHCP.
- Throw DHCPv6 in the bin.
For what it's worth, I do kind of support the idea of unifying the address allocation mechanism (i.e. using router discovery for PPP as well as ethernet); but the current system is a complete mess on all sides.
When Zen announced their IPv6 trial, I moved over to them from AAISP to save some money.
ReplyDeleteThey claimed their IPv6 implementation met TR-187, but we disagreed on that. The upshot was that I'm back on AAISP, who I'm confident know what they're doing.
Is it me, or is loopsofzen broken?
ReplyDeleteIt redirects to https://loopsofzen.uk/ but seems to be working fine for me.
Delete