In fact, my connection in NZ gives me a /48 via DHCPv6 PD, although some providers I gather are doing /56.
Andrew On 2/10/2012, at 10:41 AM, Dave Taht <[email protected]> wrote: > 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 _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
