[trimming the cc's a bit...] > I am not suggesting that the requirement that a device support > 64-bit prefixes be relaxed. I am suggesting that the requirement > that prefixes only be 64-bit be relaxed.
Whether we like it or not, the 64 bit IID requirement is fairly deeply ingrained within IPv6. It is not easy to change that requirement in a meaningful way without impacting a number of basic documents (and implementations). For example, all the IPv6 over Foo documents make this assumption... Saying an IPv6 prefix could be something other that a 64 turns out to make little sense, if the IID is 64 bits. The sum of the IID and the prefix simply has to add up to 128 bits. Relaxing that restriction is much harder and would require implementations to change. Stateless address autoconfiguration requires this today. One has to go back and understand the history that led to 64-bit IIDs to understand why we are where we are today. Knowing what we know today, and given the option of a clean slide redesign, we'd surely do it differently. :-) But given where we are today, given the pain/cost/hassle of changing the specifications (and implementations), it is my opinion that the benefits of doing so simply don't justify the effort. We have more urgent places to invest our resources. > >"For all unicast addresses, except those that start with the binary > >value 000, Interface IDs are required to be 64 bits long and to be > >constructed in Modified EUI-64 format. " All addresses would have been required to support 64 IIDs, but at the time the change was made to switch from 48-bit IIDs to 64-bit ones, some of the "funny" address formats were incompatable with a 64-bit IID. For example, look at RFC 1888 & 4048. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
