Subject: Re: poposed changes to the scoping architecture draft

From: Tim Hartrick <[email-masked]>
Date: Fri, 22 Mar 2002 10:52:36 -0800 (PST)

Steve,

> >Perhaps we have two choices:
> >
> >1. treat :: as global
> >2. does (explicitly) not define the scope type (level) of ::
> >
> >Even the choice 2 will make the document clear, and it will not cause
> >a problem in a practical point of view.
> 
> I think of :: as indicating the absence of an address, in which case
> it doesn't have any scope.  For those who feel the need to assign a
> scope value to ::, it's probably safest to treat it as link-local
> (for example, to ensure that a router receiving a packet with a
> source address of :: is not forwarded to another link).
> 

In thinking about how these facilities are going to be used by applications,
it seems that we need a way to express a desire to accept connections or
datagrams from any address in a specific zone.  We also need a way to express a
desire to accept connections or datagrams for a specific address within
any zone.

That is, I would like to be able bind a socket to any of:

::%<specific type>.<specific zone>

::%<specific type>.<any zone>

::%<any type>.<any zone>

<specific address>%<specific zone> (The address specifies the type)

<specific address>%<any zone> (The address specifies the type)

How the unspecified address is treated by the forwarding code is orthogonal
to how applications make use of it to specify which connections or datagrams
are received on a socket.  I agree that the forwarding code should treat ::
as a link-local address.  I just wanted to point out that the ability to
use the scope type and zone id for filtering could have utility to some class
of applications.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 29 Mar 2002 19:05:14 +0900

>>>>> On Fri, 22 Mar 2002 10:52:36 -0800 (PST), 
>>>>> Tim Hartrick <[email-masked]> said:

> are received on a socket.

Okay, and I think this also means we should separate architecture (or
protocol) issues and API issues more clearly.  So, I'd propose:

  in the architecture draft, clarify that the form of
  <address>%<zone ID> is intended to be used for disambiguating scoped
  addresses (that have ambiguity) and that the format should not be
  used for global addresses or addresses that do not have scope (i.e.,
  ::).
    
  (but this does not mean it prohibits an implementation -particularly
   an API- from using the format for global addresses or for :: in an
   implementation dependent manner.)

With this policy

> ::%<any type>.<any zone>

all of the above are out of scope of the architecture draft (but are
not prohibited by the draft).

> <specific address>%<specific zone> (The address specifies the type)

The architecture draft only defines this format, and the usage in the
API will not contradict the semantics of the architecture.

> <specific address>%<any zone> (The address specifies the type)

This will be implemented by using 0 as <any zone>, but this is rather
an API issue and is out of scope of the architecture draft.

Does this make sense to you?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------