Subject: RE: rfc2553bis comments

From: "Dave Thaler" <[email-masked]>
Date: Tue, 27 Jun 2000 09:52:37 -0700

Steve Deering writes:
>      if the local indexes for the interfaces plus all zones 
> (i.e., links,
>      sites, and any additional multicast zones configured on 
> the node) are
>      given distinct values out of the same scope_id space, 
> and if one index
>      value (say, 0) is reserved to mean "unspecified".  Then, 
> I think we could
>      probably get rid of IPV6_MULTICAST_IF altogether (i.e., 
> deprecate it).

I really don't like the idea of sharing the same numbering space
between interface ids and scope ids of higher levels, and requiring
uniqueness among them.

My reasoning is that ifindices are a link-layer id (per their original
definition in MIB-II), whereas site ids are network-layer (and IPv6
only)
ids with a very different meaning.  It's a layer violation to ask for 
uniqueness among them.

If the implementation used interface ids that were not ifindices, that
would
be a different thing, but then if_nametoindex() and related functions
wouldn't
be helpful for an app wanting to choosing a link.

Francis Dupont, responding, writes:
> => the only reason we should have to keep IPV6_MULTICAST_IF is an
> interface specification can be finer than a link one...

I agree with that reason, but obviously I don't think it's the
only reason :)

>      On reception, the upper-layer should be told the arrival 
> interface,

> => how? The sin6_scope_id should contains the index of the zone of the
> address scope (this rule implies global addresses in any 
> cases will get
> the zero sin6_scope_id in recvfrom() because there is only 
> one global zone).

I believe the reception interface (for both unicast
and multicast) can already be obtained if you use recvmsg.
 
>      from which it can also determine the arrival zones of 
> each possible
>      scope, since each interface can belong to only one zone 
> of each scope.

-Dave

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 27 Jun 2000 18:48:13 -0700 (PDT)

> ids with a very different meaning.  It's a layer violation to ask for 

Dave,

You can have multiple logically separate name spaces of finite size and
all fit them into a single 32 bit ID space.
For instance, this can be done by making the 32 bit ID space identify
the name space using some small number of high order bits, and
leave the rest of the bits to each namespace.

As long as you don't have to support 4 billion interface IDs or site IDs
in a single box this shouldn't be a problem.

   Erik

--------------------------------------------------------------------
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: Thu, 29 Jun 2000 09:37:16 +0200

In your previous mail you wrote:

=> if link-local scope IDs are named link IDs and have in general
the same value set than interface IDs per accident have you still
an objection?

   if_nametoindex() and related functions wouldn't
   be helpful for an app wanting to choosing a link.
   
=> I agree the confusion between interface indexes and link IDs is
confusing but with two sets of functions (one for interface indexes,
one for scope IDs) to have the same name is only user convenience.
This argument can be used for IPV6_MULTICAST_IF, PKTINFO, ..., too.

=> my purpose was just to recall how recvfrom() and co should fill
the sin6_scope_id field. I think there already is an agreement about that
(and I'd like to show no change is needed for this).

Regards

[email-masked]

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 21:27:27 -0700

At 9:52 AM -0700 6/27/00, Dave Thaler wrote:
>definition in MIB-II), whereas site ids are network-layer (and IPv6 only)

The interface ids used by IP apps are (supposed to be) IP-layer concepts,
not link-layer concepts.  For example, one link-layer ("physical") interface
might underlie multiple IP-layer ("logical") interfaces, such as tunnel
endpoints or the endpoints of multiple virtual circuits established over
the same physical interface.  Conversely, multiple physical interfaces,
such as some point-to-point interfaces to a set of parallel trunks, might
be presented to the IP layer as a single IP-layer interface (with the
link-layer performing packet-striping across the trunks, invisible to IP).

>If the implementation used interface ids that were not ifindices, that would
>be a different thing, but then if_nametoindex() and related functions wouldn't

Huh?

Steve