[zanog-discuss] dual-stack FTTH - where are things at, really?
Andrew.Alston at liquidtelecom.com
Wed Nov 6 12:13:52 SAST 2019
We went through this CPE issue as well – and tested around 40 CPE’s – and you’re right it’s a problem.
The mikrotik does work – but there are some caveats. Firstly – do not do dynamic V6 assignments to the customers – assign /48 statically – and then use DHCP/PD for the /64. The reason for this goes something like this:
On connect – the CPE gets the /48 – it in turn assigns a /64 to the lan segment. CPE disconnects – it gets a new /48 – CPE then assigns another /64 – except – it doesn’t ever issue an RA withdrawal – and because V6 source selection is a mess – you end up with a blackhole.
In almost every CPE we tested – from multiple vendors – this was a major problem. The solution – static /48s – and its also the reason why when we wrote RIPE-690 (https://www.ripe.net/publications/docs/ripe-690) we recommended against dynamic assignment to end-users
With regards to what CPE’s work – if its GPON – Huawei makes the best v6 compliant ONT’s on the market – by a million miles – there is simply nothing that worked with the same ease. On the normal run of the mill cpe’s – the mikrotik stuff was reasonable – but far from perfect. There are also CPE’s made by a company called Fritzbox – those things worked pretty well – but last time I looked they had one major drawback – their UI can be put into English mode – but it wasn’t great – and the thing is primarily in german – no idea how far along they have come since I last tested though.
But the one piece of advice I can give you – do not do dynamic v6 assignment to end customers – you will end up with a headache
From: zanog-discuss <zanog-discuss-bounces at lists.nog.net.za> On Behalf Of Mark Tinka via zanog-discuss
Sent: Wednesday, 6 November 2019 11:49
To: zanog-discuss at lists.nog.net.za
Subject: Re: [zanog-discuss] dual-stack FTTH - where are things at, really?
On 5/Nov/19 17:31, Greg Antic via zanog-discuss wrote:
I represent AS37670, we certainly are running IPv6...
I'm still amazed by what you, Greg, and your team have done (and continue to do) around this.
I really hope others can follow your lead and start making native IPv6 available for all Broadband services.
On our end, on the back of our association with former MacroLan, 2020 will be the year we start delivering native IPv6 on our Broadband services on that network.
- CPE devices are a headache, sadly the very common and popular TPLINK devices just don’t handle IPv6 properly or at all. Mikrotik is still leader however at the price point and base features versus TPLINK etc few providers will give them away for free. The Ubiquiti Unifi gateways also work well as do our GPON ONT's.
The Mikrotik hAP Lite router I use at my house costs ZAR359. It's been a work-horse for 3 years, always receives the latest updates, and just works:
The traditional home CPE's (the TP-Link, Linksys, Netgear, Asus, Buffalo, D-Link group) are very poor at keeping up with software features and standards. So the only way to upgrade those has been to go out and buy a new one as little as a year after you made the initial purchase. That's a business model that doesn't foster IPv6 deployment because ISP's aren't going to truck-roll upgrades at their cost, and users won't upgrade at their cost either.
I hear good things about Ubiquiti's routers, but I don't know if you can maintain the same hardware for years and still keep it current with new software like you can with Mikrotik.
Google's wi-fi routers are also pretty good, but besides being very expensive (US$150 - US$300 for a set), you are forced to run them as routers if you want to use their Google Wifi app. For me, the Mikrotik is where I wanted to do routing, and to get my Google OnHub wi-fi devices to operate in AP-only mode was a nightmare. Needless to say, in AP-only mode, the Google Wifi app cannot connect to them to manage them. Quite silly, actually, as Google assume you will ALWAYS use these devices as routers, even when you have an existing router. But granted, they do make for very good wi-fi AP's - excellent coverage + 802.11ac.
- The ability to remotely manage a customer CPE is a problem, to date we are yet to find a home customer willing to setup IPv6 themselves. Providers should be considering remote management functionality where possible and CPE hardware vendors should be enabling IPv6 by default in some form, still too much manual configuration and tinkering required.
So there are a few ways (at least on Juniper BNG's, anyway), that you can manage the CPE:
* Give it an address via ND/RA.
* Give it an address via IA_NA.
* Use PD to generate an IPv6 address on the Loopback interface between the CPE and BNG.
Are you using any of these methods to assign the CPE a WAN-facing IPv6 address?
- We opted to statically assign a /56 per FTTx customer because we saw issues with DHCP-PD where a CPE wouldn’t release its PD, CPE reboots > radius and BNG do their thing > assign a new prefix but CPE hasn’t updated to the new prefix and IPv6 is broken.
Was this issue with any specific CPE, or all of them?
By static assignment, I assume you are doing this via RADIUS, yes?
We also considered what would happen if you decided to statically configure IPv6 at an FTTx site, DHCP-PD isn't practical for that but I think this may never actually take off like it was in IPv4.
You mean like actually manually configuring an IP address rather than managing this via the BNG/RADIUS?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zanog-discuss