Colleagues, I am glad to see that my initial humble e-mail has sparked such debate. Based on discussions with some of my colleagues, I feel the need to make a few addition points concerning extended addressing. Although I see no engineering reason why SLAAC will not work with non-64 bit prefixes, it most assuredly will fail if prefixes span links (using the RFC 2460 definition of link). This fact leads to some rather interesting conclusions:
1. It seems rather wasteful to assign 2^64 addresses to each link. This assignment corresponds to. 1.8x10^19 individual end systems. Even if this number of systems could be attached to a link, each speaker would only be able to transmit an octet every 4679 YEARS to the router on a gigabit link. I see no possible application for such an arrangement. 2. Since each VLAN is a link, i.e., a separate Ethernet broadcast domain, each VLAN on a physical interface must have its own prefix. As a result, to support the use of all possible VLAN identifiers (2^12 possibilities) each router interface with a VLAN module must be assigned at least a /52. For routers with multiple VLAN modules, 16 for example, this corresponds to the individual router requiring a /48. Although this is a worst case scenario, it illustrates the possibility of an enormous waste of address space. As a result of these observations, I am turning the question around: Why would anyone want to use a 64 bit interface identifier? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dickson Sent: Tuesday, September 30, 2008 5:18 PM To: Brian E Carpenter Cc: Alexandru Petrescu; IETF IPv6 Mailing List; Pekka Savola; Ron Bonica; [EMAIL PROTECTED]; Pasi Eronen; Sherman, Kurt T.; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; V6ops Chairs; Martin, Cynthia E. Subject: Re: what problem is solved by proscribing non-64 bit prefixes? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
