I can't imagine operating two different subnet addressing plans within a given organisation, just because I have two different prefixes. Operationally and administratively, that would be a nightmare.
And I can't imagine, in a 128 bit address space, being limited to less than 16 bits to design my subnet addressing plan, in a large organisation with hundreds of physical sites. So I am unconditionally against any scheme that generates prefixes longer than /48. Brian Aidan Williams wrote: > > Brian E Carpenter wrote: > > In a word: no. We mustn't generate prefixes longer than /48, since > > everybody will be designing 16 bit subnet addressing plans. > > My understanding is that the /48 is intended to facilitate > renumbering by notionally swapping the old prefix with the > new one. > > I don't see that this directly applies to site local because > the notion of swapping out site local prefixes for a global > prefix doesn't make sense to me. > > Once, people may have thought IPv6 would be deployed first > with site-locals and then people would lay their globals over > their site-local addressing plan. Is that realistic today? > I have just gone straight for globals using 6to4 and I want > site-locals because my 6to4 addresses are not as stable as > I would like. > > > It isn't > > acceptable to have different subnet addressing plans with site local > > and global prefixes. > > > > Why not? The address format proposed below doesn't need an > addressing plan and will work in parallel with an aggregetable > unicast addressing plan. > > - aidan > > > 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] > > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
