> I'm not quite sure what point you're making. > > If it's the size of the network part or the host part of an IPv6 > address, as I recall the logic, the original stated requirement was > that an ipng address should be able to represent 10^12 networks (42 > bits) and 10^15 hosts (52 bits). Considering the H ratio and the way > the network and host part of an IPv4 address was/is used, one could > have imagined an address that set aside 43 or more bits for the host > part and 11 or more bits for the host part. That was the basis for > SIP's 64 bit address. > > Somewhere along the way, it was decided that a 128 bit address was > more appropriate - if 32 bits isn't enough for all uses for all time, > who says 64 is? Long story there that I wasn't a party to. But OK, it > became 128 bits, and someone started talking about maybe using the > MAC address in the host part. Someone noted that not all MAC > addresses were 48 bits; for example, an E.164 address (a telephone > number by any other name) when represented as BCD digits might easily > be 16 digits, and some 802 series addresses are 64 bits. So it was > suggested that 64 bits be set aside for the host part. > > That left the network part. There have been numerous discussions > about that, which I would summarize as the operators feeling a need > for flexibility, the IETF making some recommendations, and changing > those recommendations over time. > > If your point is that 64 bits exceeds 48 bits, yes, but 48 bits > doesn't meet the felt need. If it's not, then where are you going > with the question?
Yes, that was where I was going, by way of the selection of EUI-64 as II. In its current incarnation (which seems to be unchanging), EUI-64 is essentially MAC-48 with an extra 16 bits in the middle, which are fixed in value to "FFFE" (base 16). Here are a few related observations: - The mfg part (OUI) of MAC-48 is 24 bits, with approximately 16M values - Each mfg can assign 24 bits of unique IDs per OUI - The IEEE assigns further mfg numbers to the same mfg if it runs low or out - Currently, there are 10667 OUIs The fact that even today, we're at << 0.1% of number assignment on MACs, suggests that 48 bits is probably enough for quite some time. This doesn't mean that MAC addresses > 48 bits won't come along some day. What I'm suggesting is, that we can build in enough flexibility to handle that day, if/when it comes, without causing serious negative impact by forcing a "one size fits all" solution that, today, wastes 16 bits of address. (There is a second down-side to how such things as autoconf work when only 64-bit host addressing is supported. That is, that only (128 - N) bit network prefixes are supported. Which, due to the fixed 64 bit II size, means only /64 networks are supported. And yes, I'm going to "go there". Yes, it is potentially a can of worms, but there's good reason to revisit the issue - the /64 minimum prefix size has direct impact on number assignment policy issues, which don't need to exist (or rather, which get seriously trivialized when /64 -> /80 or more.) Here is another observation, from deep inspection of the OUI assignments. None of the current OUIs contain FFFF or FFFE. This happy coincindence means that, changing how autoconf works, and changing the II used for autoconf, can be done while guaranteeing backward and forward compatibility. Consider two possible schemes for building an II - EUI-64, and MAC-48 with an extra 16 bits of padding to the left. Looking only at the first 40 bits, ie 24 bits of OUI plus 16 bits of padding, the two patterns are: xxxxaaaaaa bbbbbbFFFE As long as no OUI includes FFFE, the two numbering schemes won't collide, regardless of the last 24 bits, and regardless of values for 'xxxx'. So, where does *that* take us? To a very interesting place, for sure... If we relax the rules for autoconf, to say that only for a given Router Advertisement of prefix X/N, that length(II) + N <= 128. We can pad any II value on the left, to fill up the host portion, and not worry about address conflicts. For example: - If we have xxxx:xxxx:xxxx:xxxx:xxxx/80 and we use the interface MAC-48 for the II, we get a unique address, with no padding. - If we have yyyy:yyyy:yyyy:yyyy:yy/72, and we pad the MAC-48 of the interface with zeros, the address is still unique for all MAC-48 values - And for backward compatibility, on Z/64, if we have both EUI-64 and padded MAC-48 addresses, there won't be any conflicting IPv6 addresses. The last example suggests very convenient backward compatiblity paths, and migration strategies. New style II's can be deployed on existing /64's, and any networks where all hosts are either statically configured or all new style, can have a new prefix length assigned with much greater flexibility. Even if, at some later date, MAC-64 becomes the "new LAN MAC standard", interoperability suggests that all hosts on such a network would need a MAC-64. This in turn means, all hosts on such a network would need II's with 64 bits. But conversely, *only* such networks need 64 bits of II. If, rather than say all II's *MUST* be 64 bits, we generalize the standards to allow for II's that vary in size depending on the underlying network, we get the benefit of supporting existing widely deployed 48-bit MAC without chewing up huge gobs of potential address space, for no obvious benefit, and a definite, if not overly obvious, cost. To be clear: I am proposing that autoconf be modified to support II padding; that II construction be permitted to be based on either EUI-64 or MAC-48; and that the II choice of EUI-64 vs MAC-48 be under the host's administrator's direct control. RA stuff is otherwise the same - if an RA is not compatible due to prefix size vs II size, autoconf will fail. However, the new flexibility means that old and new II's can be mixed on /64's. Additionally, RA's for any other prefix length between 0-63 and 65-80, would be supported by the new II, with or without padding. The general rule would even support mixed mode operation for multiple II sizes on the same network, presuming they were at all compatible at layer 2, and presuming the largest II would fit. The end result of all this, is to produce a modified RFC or set of RFCs, which supports a minimum autoconf-compatible prefix size of /80, rather than /64. And this last is so that RIR address assignment policies have more breathing room, to allow for lots and lots of assignments, hierarchical assignments on nibble boundaries (important to ip6.arpa delegations), and room for long term growth, all while minimizing (to "1") the number of PI or PA blocks assigned per ASN in the default-free zone of the public IPv6 Internet. It's a mouthful, and a huge PITA for getting these changes to the RFCs done, *and* code written by vendors, *and* upgrades deployed. If I didn't think it was extremely important work, essential for the long term viability and the short term uptake of IPv6, I wouldn't be advocating this path. I do believe it is that important, however, and encourage anyone who thinks I'm off my rocker, to read this a few times, think it over, and wait a day or two before replying. Installed base is important, and this addresses the issue. However, the un-installed base vastly dwarfs the installed base, so I think we should not get overly attached to EUI-64 as the be-all and end-all of autoconf. We should look instead to, how easy MAC-48 autoconf would be to understand, implement, and troubleshoot, and what *that* does to uptake of IPv6, particularly in the vendor space for SOHO "routers", firewalls, NAT devices, VPN devices, and the like. Currently, there are *zero* available IPv6 boxes in the <$200 price range. This is *not* good. The historical reasons for coming to a design choice are interesting, but ultimately, not important, when the driving forces for use cases lead to different choices, and alternatives can meet both the original design goals *and* the newer requirements. Brian P.S. If 99.999% of networks on which IPv6 will be deployed, are Ethernet, does it not make enormous sense to serve those with /80 prefixes, and let the rest eat up a few (or a few dozen) /64's or whatever is needed. P.P.S. Remember the original 16 bits argument? (99.999% / 65536) + 0.001% is only 0.0025% - so the net savings are 99.9975% on *network* allocations. This is about networks, not hosts. Network-bits + host-bits = constant. P.P.P.S Sorry about the long post. The ideas above are a package, and don't fit in fewer bits. :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
