Date: Tue, 6 Mar 2001 14:47:47 -0600
From: [EMAIL PROTECTED]
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46036985D0@bseis01nok>
| It extends bits to the left of the SLA to be used to differentiate one site
| from the other
No, it can't, because the addresses aren't guaranteed to be unique.
What it does is mean that sites are less likely (much much less likely)
to need to renumber their site local addresses when they merge (or
choose to use their site locals to implement a VPN, so they're immune
from global address renumbering as a unit - which is close to the same
thing as a merger though the sites probably wouldn't want to use that word).
Site differentiation still has to be done using the procedures that are
in place now for site locals that aren't even slightly unique.
so...
| and it does solve Alex's problem in a different way.
it doesn't - and I think for rational discussion of Paul's draft,
that needs to be very clearly understood. All that draft really
does is says "These MBZ bits in site local addresses, well, they
no longer MBZ" - and then goes on to give a sane procedure for
picking the value to put in those bits to minimise the chances of
a collision (it probably goes slightly overboard in the way that
is mandated, but that is perhaps a good thing).
Please, no-one read more into it than that - as it is, I see no
reason why the proposal shouldn't be accepted without even a lot
of discussion (the draft needs a good fraction of its content
ripped out - I have been discussing that with Paul off the list,
but that doesn't affect the basic idea or point).
| That has nothing to do with site locals FE80 vs FEC0 is pretty easy to
| pars.
Yes .. but if we were using bits in the address to distinguish scopes
as Alex asked about (and you may remember I proposed years ago), then
it should certainly be done for both link local and site local. Doing
just one of those wouldn't make any sense at all (it doesn't reduce the
API complexity, which is the only point).
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
