Date: Fri, 6 Jun 2003 09:28:54 +0100
From: Zefram <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| but it's quite different from the suggestion
| that we started with, which was to have persistent unique prefixes in
| globally-scoped address space.
That may have been what was wanted, but despite the attempts to
produce that, it wasn't what appeared. We haven't yet found any
way to make unique prefixes that works. (There are ways that would
work if everyone - *everyone* - would agree to play by the rules,
but nothing more than that).
| For me, a major part of the appeal of
| fc00::/7 addresses is that they don't come with any non-global-scope
| semantics attached,
They do, you're just ignoring them.
| and so they'll play nicely (i.e., interact in the
| obvious way) with routable global addresses.
They won't (always). For most purposes original SL addresses played
nicely as well - where that couldn't be guaranteed, nor can it with
the new ones.
| People have started to suggest attaching scoping semantics to fc00::/7
| adddresses, which is what led to fec0::/10.
[I applied the correction from your later mail, here & below].
No, it wasn't. What led to that was that we already have that
address space defined, deployed, and in use. We can (and always could)
change the semantics a little to get rid of "multi-site-nodes" (and hence
the need for explicit scope identifiers in the addresses) - which is
what is effectively being done here, without affecting almost anything
else. Implementations that already exist and know about scoping can
easily ignore it by assigning everything the same scope. Implementations
that allow fec0::/10 now, but treat it just like global, just keep on
doing that (at the stack level). A few applications need to care, and
do so whatever we do here.
| People that want scoping: if you want fec0::/10, you know where to get it.
It isn't that anyone specifically wants scoping - it is that we recognise
that it is impossible to avoid. These addresses have limited scope of
applicability, and can only be expected to remain unique inside that
scope (they're better than the original SL in that it is more likely
that scopes can be combined without needing to have addressing altered).
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]
--------------------------------------------------------------------
