On 27 January 2015 at 17:04:49, Dave Taht
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
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
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.
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.
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.
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
I don't have any experience with service discovery on Android devices.