On 27 January 2015 at 16:14:31, Dave Taht (dave.taht(a)gmail.com(mailto:dave.taht(a)gmail.com)) wrote:
On Tue, Jan 27, 2015 at 4:01 PM, Nathan Ward wrote:
464XLAT is, from what I can see, impacted by the same flaws as DS-Lite. I haven’t followed it as closely as I did DS-Lite though, I’ll admit.
My understanding is that both require support on CPE, and neither reduce the CGN requirements in the ISP.
The benefit seems to be that you only need to run IPv6 in your access network.
I’d be surprised if any providers in NZ have so much trouble running dual stack that running v6 only is worth having to have CPE support.
The hard bit about NZ is that a large number of people own their own CPE, so upgrading software/replacing them with devices with support for new protocols is hard. If you decide to roll 464XLAT or DS-Lite, you have an interim state where you have some customers on the current native v4, and some on the translated/tunnelled v4. How long that interim state persists is anyone’s guess, and certainly sounds more complicated than just running v6 along side your existing native v4.
I note that over the past 2 years openwrt added support for nearly every IPv6 acquisition method out there, dslite, dhcpv6, 6over4 6to4, etc, etc. Did we miss one? The improvements are in Barrier Breaker and later.
Native IPv6 support for cable "just works", in particular. The biggest pita is that comcast, at least, wants to give out prefixes with short lifetimes, and a lot of client gear, when used with ipv6, has been expecting permanent IP6 addrs. IPv6 prefix distribution, not so much ready for prime time yet, although the homenet working group converged on hnetd for a in-home prefix distribution protocol, it's still kind of rough.
You get stable addressing (for internal use) from running ULA. Worth noting that the HNCP draft proposes just that. Do you have devices that have IPv6 stacks that break when prefix lifetimes expire? What sort of devices are these? It will be interesting to see how HNCP interacts with non-HNCP capable routers re. prefix delegation. Hopefully vendors can get implementations out there soon enough that any problems here won’t be too widespread, but maybe HNCP needs some thing to support delegating multiple prefixes to downstream non-HNCP devices. I wonder how common home networks with multiple broadcast domains are, apart from those situation where the customer is provided with a “modem” and then goes and buys a “wireless router” to go on the back of it. Given the number of in-home applications that work with some sort of multicast/broadcast discovery these days, I imagine putting devices on separate broadcast domains doesn’t happen so much. -- Nathan Ward