On 27 January 2015 at 17:04:49, Dave Taht (dave.taht(a)gmail.com(mailto:dave.taht(a)gmail.com)) wrote:
On Tue, Jan 27, 2015 at 4:39 PM, Nathan Ward wrote:
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 have been using ULA in my home network for years, without issue. I’m on native now, was previously on 6to4, worked great both times. Selecting to use ULA addresses is not an application thing, the IPv6 stack in the OS should handle this for the applications. I assume you have devices that don’t have, or don’t have well configured, support for RFC6724 (or RFC3484)? Or, maybe some applications that don’t use it for some reason?
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.
Again, this isn’t an application thing, though I can imagine you might see some problems if your CPE reboots so doesn’t know what prefix it had previously, and so can’t deprecate the address. Perhaps your CPE could use a shorter preferred lifetime to reduce the impact of a reboot. Deprecated addresses (i.e. preferred lifetime has expired but valid lifetime has not) are still usable if no preferred address in the same scope is available, so setting short timers here shouldn’t cause too many problems for you.
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.
I've been running the WIDE DHCPv6 client on my OpenWRT router I've got at home for about 18 months and I haven't touched it, it's worked great. Is there something I'm missing?
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
I don't think people other than geeks really care what their addresses are, provided it works as well as it always has. We are sort of getting off topic below - Maybe we should take further discussion of this off-list, or, if you're at NZNOG the next few days perhaps we can talk in person?
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.
You can easily get data on this - capture packets outbound from your customers at your BNG/BRAS, and look at TTL. It's easy to infer initial TTL, and so you can get number of router hops. Let's assume all routers in a home are also NATing - or at least a very very large % of them. I looked at this with some other folks during a conference in 2008, and we saw about 17% of outbound packets looked like they were behind 2 or more routers (which I assume to be NAT devices). I haven't looked at data since, but I'd like to.
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.
Yes, and very common, and causes far less issues than many suppose - applications have evolved to work around "broken" networks like that, see above.
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...
I'm not sure that that's a fair assessment, given many of their protocols rely on multicast DNS - why would they intentionally break it? I haven't had any of the problems that Iljitsch has had, and from memory that article is mostly about resolving names rather than services. Some of the conclusions he draws in the article are pretty flawed and poorly researched, but, I'm sure it got plenty of hits. I don't have any experience with service discovery on Android devices. -- Nathan Ward