Subject: RE: Question on scopes involving IPv6 addresses

From: [email-masked]
Date: Tue, 6 Mar 2001 12:19:43 -0600

Alex,
 
I spoke to quickly I just read Paul Francis's new spec.  Could be this may
get revisited after all.
see:  

draft-francis-ipngwg-unique-site-local-00.txt

regards

/jim

-----Original Message-----
From: Bound Jim (NET/Boston) 
Sent: Tuesday,March 06,2001 9:52 AM
To: 'ext Alex R n'; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: Question on scopes involving IPv6 addresses

Having the scope be part of the IPv6 address or having other distinguishing
attribute in the NLA (which is null now) was discussed and rejected. 
I was supportive of this idea.   But it does add an entire address space
management part to IPv6 site local addresses.  My input is don't go there.
Implementations will have to have scoping code following the scope-arch-02
draft architecture.  How that is done is and should be implementation
specific.  I think maintaining tables in an implementation is a question of
the type of implementation.  I think its better to extend existing OS kernel
protocol control block structures and search algorithms to be scope aware.
This also means that information can be extracted by user space applications
for management of scopes and for source/destination address selection.  But
all should use the assumption that FF05 prefixes will only exist within a
site and will not overlap sites, because they can be duplicated.
 
/jim

 
Going through scoped address architecture it provides a mechanism to
distinguing the same address belonging to different scopes. What I am
wondering is that 
 
a) Couldnt the scope index have been part of the IPv6 address.
b) For upper layers like UDP which identifes a connection based on addresses
wouldnt it be better to put the scope index into the address itself.
  One scenario is that we could have the same [source src port destination
dst port ]  pairs from different scopes as in the scenario earlier seen. Is
the upper layer suppose to handle this in a different manner like having
scoped tables.
 
Thanks
Alex

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Mar 2001 01:46:05 +0700

Date:        Tue, 6 Mar 2001 12:19:43 -0600 
    From:        [email-masked]
    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-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Mar 2001 20:22:21 +0100

In your previous mail you wrote:

=> this was already proposed and rejected. Some of us still use
this internally in their kernel and should be able to explain
why this is not a so good idea...

=> PS: I don't believe this is the Paul's idea which is more
a new version of Christian's one (i.e. a new attempt to make
site-local addresses live again, periodic discussion like the
ASCII/last-smart format of RFCs, with same conclusions (too difficult,
keep them where they are, and keep the ASCII format :-)).

Regards

[email-masked]