Subject: FW: rfc2553bis comments

From: Dave Thaler <[email-masked]>
Date: Thu, 22 Jun 2000 09:10:33 -0700

I just got a bounce message from the first time, 
apologies if this is a duplicate.

-----Original Message-----
From: Dave Thaler 
Sent: Wednesday, June 21, 2000 5:44 PM
To: Richard Draves; Francis Dupont
Cc: [email-masked]
Subject: RE: rfc2553bis comments 

> > Another point en passant, should in this case a bind() with a non-zero
> > scope_id do an automatical IPV6_JOIN_GROUP?
>
> I don't follow this - you can't bind() a multicast address.

Yes you can.

There's a discussion of this in (for example)
Stevens, Unix Network Programming, Vol. 1, 2nd ed.,
pp498-499.

-Dave
--------------------------------------------------------------------
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: Richard Draves <[email-masked]>
Date: Thu, 22 Jun 2000 12:30:00 -0700

> => I can

Winsock (or least, the MS implementation) doesn't allow this. I didn't know
that recent BSD variants have this capability - thanks for the correction.

To answer your question - yes, the bind() of a multicast address should
automatically join the group. So this is another reason to make
sin6_scope_id field be an interface id for multicast addresses of all
scopes.

Rich

---

From: Tim Hartrick <[email-masked]>
Date: Thu, 22 Jun 2000 12:43:25 -0700 (PDT)

Rich, Francis,

> sin6_scope_id field be an interface id for multicast addresses of all

I disagree with both of these things and generally agree with Dave
Thaler's previous note on this subject.  The sin6_scope_id specifies the
link, site, organization, etc. depending on the scope of the multicast
address.

The binding of a multicast address to socket by an application should be
independent of the joining of a multicast group on a particular interface.

Tim Hartrick
Mentat Inc.

---

From: Tim Hartrick <[email-masked]>
Date: Tue, 27 Jun 2000 09:28:27 -0700 (PDT)

Francis,

> 
>    I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_-
>    scope_id for what it was originally intended, to identify the zone from
>    which a datagram was received and to identify the zone to which a datagram
>    should be sent.  To the extent that that overlaps with what IPV6_MULTICAST_IF
>    does that is unfortunate but it certainly isn't the only or even the worst
>    example of duplicated functionality in the API specifications.
>    
> => if the functionality is duplicated (and it is in this case) we have to
> specify who has the precedence, ie. what happens when both are used.
> 

Sure.  But we would need to do that if we "deprecated" IPV6_MULTICAST_IF
since the IPV6_MULTICAST_IF option isn't really going anywhere.  None of
the implementors I know is going to be able to simply erase it from their
implementation.  If we have to keep it then we should just specify how
the sin6_scope_id interacts with it and move on.

From my perspective it is clear that because the sin6_scope_id has a finer
granularity of the application that it should take precedence over the
IPV6_MULTICAST_IF option.

For site-local, organization-local, other-local addresses this means that
when a non-zero sin6_scope_id is specified the outgoing interface is determined
by the routing table if the interface specified by the IPV6_MULTICAST_IF is
not part of the zone referenced by the sin6_scope_id.  For link-local addresses
a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF option.  For global
addresses the sin6_scope_id is not interpreted so the IPV6_MULTICAST_IF, if
set, determines which interface is to be used.

Tim Hartrick
Mentat Inc.

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 27 Jun 2000 10:38:29 -0700

Looks like the last try went out as HTML.
Resending, sorry for duplicate.
-Dave

-----Original Message-----
From: Dave Thaler 
Sent: Tuesday, June 27, 2000 9:53 AM
To: Francis Dupont; Steve Deering
Cc: [email-masked]
Subject: RE: rfc2553bis comments 

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: "Dave Thaler" <[email-masked]>
Date: Thu, 29 Jun 2000 21:36:21 -0700

All of the scenarios you describe are handled with
link-layer ifindexes.  Nothing says a link has to
be a physical link.  This is specified in RFC 2233
(Interfaces MIB), where there is an excellent 
discussion of the interface layering model and
the use of interface indices.

-Dave 

-----Original Message-----
From: Steve Deering [mailto:[email-masked]]
Sent: Thursday, June 29, 2000 9:27 PM
To: Dave Thaler
Cc: [email-masked]
Subject: RE: rfc2553bis comments

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

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).

would
wouldn't
>be helpful for an app wanting to choosing a link.

Huh?

Steve

---

From: Richard Draves <[email-masked]>
Date: Fri, 30 Jun 2000 09:52:10 -0700

My first reaction is I think your suggestions (reproduced below) are logical
& consistent, but I do worry about one thing. If I understand correctly,
you're saying that a user could say
	ping6 fec0::1%3
where 3 could be an interface index. On a multi-sited node, this would say
"I mean fec0::1 in the site that interface 3 belongs to". But it would not
constrain the packet to actually being sent out interface 3. It could be
sent via any interface belonging to the same site as interface 3. My worry
is that this would be rather confusing & nonintuitive for users.

Rich

> This leads to the following suggestions:
> 
>   - a non-zero sin6_scope_id value used when bind()ing a socket or
>     sending a packet is used only to identify the relevant zone of the
>     source or destination address, and *not* to identify a particular
>     interface for sending or receiving, even if the 
> sin6_scope_id happens
>     to be an interface index.  I.e., the use of an interface 
> index would
>     not be interpreted as (over) specifying the choice of outgoing
>     interface.  Of course, it would be  cleaner to just use 
> zone indices,
>     not interface indices, for sin6_scope_id, but backwards 
> compatibility
>     with existing implementations might argue for allowing either.
> 
>   - the sin6_scope_id value returned in a sockaddr_in6 when receiving
>     a packet is interpreted only as identifying the zone of the source
>     address, not as the specific interface on which the 
> packet arrived.
>     Again, it would be cleanest if only zone indices were used, but
>     interface indices could be "tolerated" for backwards-compatibility
>     reasons.
> 
>   - to constrain an outgoing packet to a specific interface 
> or a set of
>     interfaces smaller than the set belonging to the destination
>     address's zone, you would specify an interface index or a 
> zone index
>     in the in6_pktinfo structure of the advanced API.  For multicast
>     packets, you could alternatively use IPV6_MULTICAST_IF.
> 
>   - to determine the specific arrival interface of a packet, you would
>     use the in6_pktinfo structure of the advanced API.
> 
>   - when joining a multicast group, you would use IPV6_JOIN_GROUP with
>     either an interface index, a zone index, or zero (unspecified).