I have been tracking this conversation for a while, excuse the top post. 0) The state of cable modems is rather dismal as yet, with none that I'm aware of able to distribute anything bigger than /64. 6to4 is still the best option on that technology in the US. 1) At least some markets outside the USA (NZ, for sure) are managing to distribute /56 addresses via DSL/fiber 2) SLAAC is needed, too many dumb devices only implement that.
I note that dnsmasq now contains a clever hack to utilize dhcpv4 information to correctly assign names to SLAAC based addresses. 3) I gave up on the whole /64 and slaac vs dhcpv6 debate years ago and went to ahcp, not that I'm ever going to get any traction on it, regardless of how well it solves 0, above. On Mon, Oct 1, 2012 at 2:33 PM, Curtis Villamizar <[email protected]> wrote: > > In message <[email protected]> > RJ Atkinson writes: > >> >> On 01 Oct 2012, at 15:01 , Curtis Villamizar wrote: >> > You are suggesting if A then !B. >> >> No, my apologies for being unclear. >> I am NOT, repeat NOT, suggesting that. >> >> (A & !B) is a possible deployment option, of course, >> but it is not the ONLY option either. >> >> > I prefer if A and B, then C. >> >> I understand you have a personal preference. >> >> A set of people on this list have indicated that >> particular preference is strongly undesirable. > > I agree that it is *very* undesirable. It does work. I've tried it. > >> However, disallowing SLAAC is NOT the ONLY conceivable >> approach. One ought to try to think of other options >> (each of which probably has different tradeoffs). > > AFAIK SLAAC requires a /64 prefix. Is that not true? Or are you > suggesting changing it? > >> Yours, >> >> Ran > > If A and B, then C is a possibility. > > Only if C does SLAAC have to get disabled. It's not a good option and > not every toy is going to play nice but if it is forced, for some it > may be the best option. Another option is to use a tunnel rather than > the ISP native IPv6 if the ISP won't allocate prefixes other than /64. > > I've had a lengthy off-list discussion with Joel. There is mixed > response from one MSO, with /128 in a lame limited city trial today, > /64 RSN (for some unspecified value of RSN), and shorter prefix still > later. Its this sort of preference for a one size fits all least > common denominator at a provider that has me concerned that some > consumers may be stuck with a /64. > > It would be helpful if we had a consumer-ISP requirements from some > WG, but homenet might not be the place. > > It may be the homenet can say that in order for things to work in the > home certain things are required of the ISP or highly desireable > (DHCPv6 prefix allocation, DNS and rDNS delegation and secondary, at > least /60 on request and preferably without additional charge, etc). > Would that be out-of-scope for homenet, and if so, in what WG would it > be in-scope? If none, then can it become in-scope (charter update)? > > Curtis > > > btw- if DHCP is not used, then dynamic DNS has to get popluated > directly from the host and each host needs the key needed to make its > DDNS update (and not someone else's DDNS update) and it also needs to > know where the DDNS server is. This seems a lot more problematic than > putting DHCPv6 client on the host. Lack of either means DDNS doesn't > get updated. Also if DHCPv6 is not used, the domain name, DNS search > list, nameserver list, ntpservers, .. etc, still have to be populated. > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
