Date: Tue, 6 Mar 2001 12:19:43 -0600
From: [EMAIL PROTECTED]
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46036985CA@bseis01nok>
| I spoke to quickly I just read Paul Francis's new spec. Could be this may
| get revisited after all.
They're actually two different issues - though perhaps related.
Paul's draft won't do a thing towards allowing the address scope to
not be a separate parameter (one way or another), which is what Alex
was asking about I think. In fact, if anything, it finally removes
that possibility completely. The only way the two could co-exist
would be to remove the default site local (the current one) as a
possible address completely, and to insist that all site local
addresses be unique (not just nearly unique). As things are, there's
still the (strong because of the default case) possibility that
site local addresses aren't unique in two links out of a site border
node.
And in any case, there would be link locals to deal with.
There was a proposal way back to simply embed the (local) scope
identifier in the address, as an API mechanism, so applications
would have one less thing to worry about. At the application level
that could have worked (before Paul's draft - now there are no bits
left in site locals to steak (borrow) for the purpose).
As an interface from the transport protocols it wouldn't have worked
however - the transport protocol needs to know the actual address bits
so it can correctly compute its header checksum. Trying to specify
how the transport protocol should mask out some bits of the addresses
(in some cases) would be a bit on the hairy side. That is, unless the
extra bits were carried on the wire - which seems like (but isn't) what
Paul is proposing for site locals - where it actually could be done
reasonably easily, but for link locals it turns out to be a non-trivial
problem.
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]
--------------------------------------------------------------------
