On Jan 26, 2012, at 3:31 PM, Tim Chown wrote: > > On 26 Jan 2012, at 16:53, Owen DeLong wrote: > >> On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote: >> >>> Does this mean we're also looking at residential allocations larger >>> than a /64 as the norm? >>> >> >> We certainly should be. I still think that /48s for residential is the right >> answer. >> >> My /48 is working quite nicely in my house. > > There seems to be a lot of discussion happening around a /60 or /56. I > wouldn't assume a /48 for residential networks, or a static prefix. >
I wouldn't assume anything. That doesn't change the fact that it is, really, the best thing to do. >>> So a CPE device with a stateful firewall that accepts a prefix via >>> DHCPv6-PD and makes use of SLAAC for internal network(s) is the >>> foundation, correct? >> >> I would expect it to be a combination of SLAAC, DHCPv6, and/or DHCPv6-PD. >> Which combination may be vendor dependent, but, hopefully the norm will >> include support for downstream routers and possibly chosen address style >> configuration (allowing the user to pick an address for their host and >> configure it at the CPE) which would require DHCP support. > > Yes, the assumption is multi-subnet in the homenet, with a method for > (efficient) prefix delegation internally. > Where the definition of (efficient) is highly flexible and almost certainly does not refer to bit conservation. >>> Then use random a ULA allocation that exists to route internally >>> (sounds a lot like a site-local scope; which I never understood the >>> reason we abandoned). >> >> I can actually see this as a reasonable use of ULA, but, I agree site-local >> scope would have been a better choice. The maybe you can maybe you cant >> route it nature of ULA is, IMHO it's only advantage over site-local and at >> the same time the greatest likelihood that it will be misused in a variety >> of harmful ways, not the least of which is to bring the brain-damage of NAT >> forward into the IPv6 enterprise. > > Site-locals didn't include the "random" prefix element, thus increasing the > chance of collision should two site-local sites communicate. See RFC3879 for > the issues. > True, but, it would have been easy enough to correct that or provide registered site-specific site local addressing if that was desired. >>> I'm just not seeing the value in adding ULA as a requirement unless >>> bundled with NPT for a multi-homed environment, especially if a >>> stateful firewall is already included. If anything, it might slow >>> down adoption due to increased complexity. >> >> I don't believe it adds visible complexity. I think it should be relatively >> transparent to the end-user. >> >> Basically, you have one prefix for communications within the house (ULA) and >> another prefix for communications outside. The prefix for external sessions >> may not be stable (may change periodically for operational or German >> reasons), but, the internal prefix remains stable and you can depend on it >> for configuring access to (e.g. printers, etc.). >> >> Sure, service discovery (mDNS, et. al) should obviate the need for most such >> configuration, but, there will likely always be something that doesn't quite >> get SD right somehow. >> >> Also, the ULA addresses don't mysteriously stop working when your connection >> to your ISP goes down, so, at least your LAN stuff doesn't die from ISP >> death. > > Consider also long-lived connections for example. > Long lived connections are still doomed unless you go to the complexity of BGP-based multihoming, LISP, or something similar to one of those two. Personally, I use BGP multihoming for my home and it's working pretty well. YMMV. > I don't think there's a conclusion as yet in homenet about ULAs, nor will a > conclusion prevent people doing as they please if they really want to. > Sad, but true. Owen
