On Tue, Jan 27, 2015 at 4:39 PM, Nathan Ward
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.
Have you actually tried it? Adding ipv6 ulas to a network makes applications that aren't smart about it, try making ula based connections to everywhere at some point or another. I am encouraged by the methods mosh-multipath is using, if you haven't tried mosh for your nailed up term sessions, it's a lifesaver: https://github.com/boutier/mosh
Do you have devices that have IPv6 stacks that break when prefix lifetimes expire? What sort of devices are these?
Nearly everything I have tried has some problem or another. Biggest problem is in retracting prefixes after a cpe reboots and gets a new ipv6 range. Devices downstream just "don't get it", and keep the old ipv6s around either forever or for the prefix lifetime and apps aren't smart about what to pick, either. prefix acquisition of anything other than a /64 is broken in most isc-dhcp dhclient users, dibber's latest release candidate almost sort of kind of works, and only the latest chaos calmer releases of openwrt are working even-semi-correctly with multiple odd cable modems.
It will be interesting to see how HNCP interacts with non-HNCP capable routers re. prefix delegation. Hopefully vendors can get implementations out
Well, I'd like to see the code mature faster, funding for that part of homenet has nearly run out. It would be nice to have the dhcps working better... and given the discussion here, I was unaware as to the depth of problems with ppp-o{e,a}. hnetd as currently written wants to own - dynamically - all the ip distribution (4, 6, and ula) on the router presently and that's not what people are used to. Dynamically renumbering people's internal networks was to me, always a non-starter - I'd hoped that geo oriented ipv6 would work out - you bought a house, you got a portable /48, but so far, no luck.
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.
needs more users/testers/time to mature.
I wonder how common home networks with multiple broadcast domains are, apart
It is a good question. I have no doubt that many double and triple natted home networks exist, merely because that's how the user plugged everything in. Setting up everything to bridge, or route, requires expertise that I'd hoped that a homenet standard would limit.
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.
Instant double nat in most environments.
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.
I do wish we had better data on this. Nearly every multicast/mdns capable app I have on my android doesn't work worth a damn with discovery, and has an option to manually enter the (ipv4) address. Apple is doing it's damndest to make mdns unusable for anything, also. http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-wha...
-- Nathan Ward
-- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks