Margaret Wasserman <[EMAIL PROTECTED]> writes: > At that time, it didn't seem like a big issue to add a hard /64 > boundary into the IPv6 address, because we already had several > hard boundaries in our addresses to provide separate fields for > aggregation (the TLA/SLA stuff). Since then, we have removed the > other hard boundaries and moved to a CIDR-like address structure, > but we have maintained the hard /64 boundary, and required Modfied > EUI-64 IIDs for all global unicast addresses.
> There are some major advantages to retaining this hard /64 boundary: > - It makes autoconfiguration simpler, since all prefixes are > /64s and all IIDs are 64-bits long. It would require > major, and inadvisable, changes to autoconfiguration to > allow autoconfiguration using prefixes longer than /64. It's more than just autoconfig. Right now, End sites can expect to get a /48, and they get use the 16 bits between a /48 and /64 anyway they care. If a site switches providers, it knows it will get 16 bits again, and it konws that it needs to (only) renumber the upper 48 bits. This is both simple and powerful. This comes in large part from the uniform /64 boundary between the adddress and the IID. If that were removed, it would potentially reopen discussion about which bits and end site should get for subnet addressing, with different people possibly being given different ranges and (even worse) different amounts. I think this would be a bad direction for us to go in. I don't see what the benefit would be, but I can surely see a number of non-productive areas we'd surely rathole on. > But, what I think this WG needs to think about and understand is _why_ > operators are using longer prefixes on their router-to-router links. This is a key question. Just because operators are doing this, doesn't mean they should or that we should just give in and say "I guess we should give in to reality". There is a cost/benefit of sticking with the /64 boundary. Before moving away from it, we really need to understand the cost/benefit of the alternative. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
