below... Bob Hinden wrote: > > Keith, > > >operationally I think it would be a mess to have site-locals routed > >differently within a site than globals. it's not that you can't do it, > >it's that it makes life more difficult, and GUPIs seem to be a better > >way to solve the same problem. > > I am not sure there is that much difference. In the current /48 provider > based global addresses, each subnet is identified by a /64 prefix. Both > approaches will generate /64 routes. I suspect that only in the largest > sites, will the subnet field also be used for aggregation inside of the site. > > This is all about tradeoffs. For example in the site-local prefix > FEC0::/10, there are 54-bits available for global identification and subnet > numbering. If 16-bits are for subnets, then there are 38-bits left for > global site identification. Is this big enough for a global > token? Probably not if it a random number or based on some other existing > global identifier. Might be OK if it was centrally allocated, but who is > going to do that? Also, what about sites that need more than 16-bits of > subnets? > > We could use a shorter prefix, but how much of the total IPv6 address space > do we want to use for this? For example, a /2 prefix would allow 16-bits > of subnets and a 46-bit token. But this would use 1/4 of the total IPv6 > address space. That doesn't seem wise. > > So I am not sure there is any solution that has the three properties: > > 1) globally unique > 2) 16-bit subnet field > 3) Uses a limited amount of the IPv6 address space > > We may have to pick the two we think are the most important. The current > site-local definition has 2) and 3). My global site local proposal has 1) > and 3). Andrew White's draft has 1) and 3).
There is the alternative that can definitely be satisfied: 1a) probably unique 2) 16-bit subnet field 3) Uses a limited amount of the IPv6 address space i.e. hash something into 38 bits that has a very high probability of being unique among a finite number of sites. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
