In a word: no. We mustn't generate prefixes longer than /48, since everybody will be designing 16 bit subnet addressing plans. It isn't acceptable to have different subnet addressing plans with site local and global prefixes.
Brian Andrew White wrote: > > Some thoughts: > > As a method of doing globally unique site local addressing: > > Assuming aggregability is not an issue within a 'site' sized network, > consider generating site local subnet identifiers at the router, based on > IEEE EUI-48 identifiers (such as MAC addresses). > > For example, generate as fec0::/12: > > 12 bits: fef > 48 bits: MAC > 4 bits: 0 or subnets > > or, if we don't want them in fec0::/10 > > 10 bits: fe0 > 48 bits: MAC > 6 bits: 0 or subnets > > The '0 or subnets' is to allow for the possibility of choosing one EUI-48 on > a router and using that to allocate all appropriate subnets. > > By piggybacking on the existing registration scheme, we generate "unique" > site-local subnet ids at the router without needing external registration or > administration. > > Despite the zero-config nature of this, administration on the router is > still necessary, both to enable this mode (probably don't want site-local > behaviour enabled by default) and to determine whether a router is > authoritative for the link. An administrator may wish to configure a > multi-router link with the subnet prefix of only one router. > > An internet-draft describing this in more detail is written and will be > submitted in the next day or so. Comments welcome. > > Another comment on uniqueness: > > Under IPv6, even an ambiguous prefix is likely to not resolve to an address > because of the MAC generated machine id, so the likelihood of collision is > lower than might be expected from the prefix. > > Final thought: > > Whatever the outcome of the site local discussions, renumbering will remain > a serious problem under IPv6, that needs to be considered. Making > renumbering easier is a hard problem, but a good solution will help reduce a > variety of other problems. > > -- > Andrew White [EMAIL PROTECTED] -------------------------------------------------------------------- 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] --------------------------------------------------------------------
