Brian E Carpenter wrote: > On 2008-10-01 08:26, Brian Dickson wrote: > ... > >> we would ideally also have corresponding IPv6 subnets that are >> algorithmically derived from the IPv4 subnets. >> > > I used to think that was a good way to design an initial > IPv6 addressing plan. But from helping people design a real > addressing plan for a real campus with many years of IPv4 > history, I've reached the conclusion that it's a really bad idea. > It's much better to design a clean IPv6 plan from the ground up, > rather than sweeping up the messy history of the IPv4 plan. > >
I think the thing to be careful of, is jumping from "this is a better way of doing things", to "everyone has to do it this way". Similarly, there is both a qualitative and quantitative difference between anecdotal things, and statistical things. For instance, what works for one campus will likely work for most campuses (campii?). However, educational institutions number in the thousands, roughly, while SMBs and ISPs number in the 100s of thousands or more. And many of those non-campus entities, are unable to (easily) go that route. > If you design a clean IPv6 plan that way, there doesn't seem to be > any incentive whatever to use anything other than /64 as > subnet prefixes (except for the router-router links, as Pekka > mentioned). There's a strong incentive in favour of /64, > i.e. the ability to use SLAAC, privacy addresses, and CGAs. > I agree. However... Saying "I agree" doesn't mean that the original argument, (of managing dual-stack networks of servers which do not need, cannot use, and will never want, SLAAC, privacy addresses, DHCPv6, or anything other than static configurations, possibly centrally managed), isn't valid. Or, basically, the counter-argument is, if you don't do a clean design, then you probably do need non-64 bit subnets, period. BTW - I am not advocating not doing a clean design. I'm saying that while dual-stack is prevalent, the benefits of managing the duality with crude but effective implements, outweighs the elegance of any alternative. Being able to deploy something (IPv6) should be the central focus, not making the thing being deployed more "clean". If the choice is fugly or not at all, the fugly choice must still prevail. Which means we need to accommodate schemes we don't like, don't advocate, but which are a means to the desired end (IPv6 deployment, especially in a dual-stack world.) Brian Dickson -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
