Subject: rfc2553bis comments

From: "Dave Thaler" <[email-masked]>
Date: Wed, 7 Jun 2000 11:37:07 -0700

Comments on draft-ietf-ipngwg-rfc2553bis-00.txt
(and on the POSIX spec by extension...):

1) It would be very useful to be able to obtain (via getaddrinfo) the
   list of local addresses to which you can bind.  There's at least two
   ways I can think of to potentially support this:
   a) AI_PASSIVE could return a list of sockaddrs, with the unspecified
      address always being first.
   b) Use a new flag to enable behavior of obtaining the whole list

2) In porting IPv4 apps to IPv6, it's inconvenient that nodename and
   servname cannot both be NULL.  There are applications that actually
   want to bind to INADDR_ANY/in6addr_any with an unspecified port.
   The intuitive behavior of allowing both to be NULL would be to get
   back local addresses without port numbers.

3) When multicast addresses are stored in a sockaddr_in6, how is the
scope
   id field interpreted?  My interpretation of the current wording
(which
   I agree with) is that it's interpreted the same way as for unicast
   addresses.  That is, a link-local multicast address uses the same
   sin6_scope_id as a link-local unicast address on that link.
   A site-local multicast address uses the same scope id as a site-local
   unicast address in that site.  For other multicast scope levels, the
scope id
   field can contain an id identifying the interfaces in that scope.
Again, I 
   believe this is the correct interpretation, and is consistent with
the current 
   RFC and draft.

   Reasoning (in case you disagree...)
   For *link-local* multicast, it's very convenient to store the scope
id
   for the link-local scope on the interface (i.e., the ifindex or
whatever
   the implementation uses).  This is especially useful in that one
doesn't
   need to do IPV6_MULTICAST_IF before sending to a link-local multicast
   address, since the sockaddr in the sendto() is unambiguous.

   For scopes between link-local and global, the issues are:
   1) is the scope_id for a site-local group the site id or an ifindex
      (or equivalent link id)?
   2) If you say the scope_id for multicast is always the ifindex, then
      you cannot tell that two sockaddrs actually refer to the same
group,
      like you could for unicast, when both interfaces are inside the
same
      scope.
   3) If the scope_id is not an ifindex, then what is the meaning for
      scopes other than global and site-local?
   Basically, there's a disconnect between some purposes wanting the
ifindex
   to know how to send/join, and using a site id (or equivalent) to
uniquely
   identify the address.  It's more consistent with unicast to use a
site id
   (and the current draft appears to say this is the case), not an
ifindex,
   but this would require an id for every scope level between link and
global
   scope.

   An "unspecified" value (e.g. 0) might be legal in a given
implementation
   for non-global multicast addresses, if it allows unspecified scope
ids
   in non-global unicast addresses.  (I'd tend to disallow this all
   together, but others disagree.)

-Dave

---

From: Francis Dupont <[email-masked]>
Date: Sat, 17 Jun 2000 21:11:56 +0200

In your previous mail you wrote (after reformatting into text):

   3) When multicast addresses are stored in a sockaddr_in6, how is the
   scope id field Interpreted?

=> I believe it should be an interface index because it is the way
it works today (or before scope id introduction if you prefer :-):
IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with
interface sets.
Another point en passant, should in this case a bind() with a non-zero
scope_id do an automatical IPV6_JOIN_GROUP?

Regards

[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]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 23 Jun 2000 07:33:37 +0900

>>>>> On Sat, 17 Jun 2000 21:11:56 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> it works today (or before scope id introduction if you prefer :-):

It would work, but I'd rather use the same semantics for both unicast
and multicast. That is, sin6_scope_id should just specify a zone ID,
not an interface, even for a multicast address.

> IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with

Yes, these are interfaces oriented. But, it sin6_scope_id is not, at
least in my understanding of scope architecture. Specifying a
particular interface by the sin6_scope_id field seems to me
overspecification, if the scope is wider than interface (i.e. link or
broader scopes).

Also, if the sin6_scope_id field specified a single interface for a
multicast address, we couldn't do

- bind a socket to a site-local multicast address with an appropriate
  sin6_scope_id,
- set IPV6_JOIN_GROUP for that address on multiple interfaces (of the
  specified scope zone), and then
- receive packets that arrive on the specified interfaces via the
  socket

I don't think this is really a practical example, but IMO, this type
of behavior is allowed in IPv4 (i.e. bind once, and call
IP_ADD_MEMBERSHIP multiple times to receive packets to the group on
multiple interfaces), and should be allowed in IPv6 as well.

					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]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Fri, 23 Jun 2000 11:14:02 +0200

=> it is a matter of taste... and things are very complex because
we'd like to have different interpretation on emission and reception sides
(my comment was about the emission side but for the reception side your
proposal seems better)

   Yes, these are interfaces oriented. But, it sin6_scope_id is not, at
   least in my understanding of scope architecture.

=> unfortunately the scope architecture is still waiting for its
documentation (:-)...

   Specifying a
   
=> to (over)specify an interface is better for emission, for reception
the whole thing is very different, for instance IPV6_JOIN_GROUP has
a global effect, ie it just enables reception of packets with
the specified multicast destination address on an interface, any socket
bound to the address or unbound will get them. The IPv6 scope ID
with your interpretation can make this different/better than in IPv4
(where you may have to get and check the receiving interface).

=> before listing these, can zero sin6_scope_id give the traditional
(ie IPv4) behaviour?

=> with the traditional behaviour the last point must be done by the user

=> if your purpose is to get (optionally) the same behaviour than for IPv4
then the zero sin6_scope_id is enough. But your idea perhaps is to enable
smarter filtering on reception?

Regards

PS: today my code ignores the sin6_scope_id for multicast address on reception
(ie. in6_pcbbind() resets it to zero and udp6_input() doesn't check it in
the multicast case loop).
--------------------------------------------------------------------
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: Dave Thaler <[email-masked]>
Date: Fri, 23 Jun 2000 15:56:31 -0700 (PDT)

> (my comment was about the emission side but for the reception side your

I _really_ don't like having more than one interpretation.
Since joining/leaving/specifying the outgoing interface can all be done by 
ifindex using existing apis without the scope_id, I don't see them as
being a good argument for use of scope_id.

The bind, getaddrinfo (when DNS returns a multicast address for a given
name), etc calls are the ones that should be of primary interest in my
opinion.  These tend to argue for zone ids, not interface indexes
(except for link-scoped where they're the same thing).

>    overspecification, if the scope is wider than interface (i.e. link or

Right.

> => before listing these, can zero sin6_scope_id give the traditional

This is a different (but important) question, which some of us have
also been discussing offline.  One good argument is that you should get
the same behavior for link-local unicast and multicast link-scoped
addresses if scope_id is zero.  (Whether that behavior is an error,
or an arbitrary choice is a different decision, and perhaps ought
to be left to local policy.)

>    multiple interfaces), and should be allowed in IPv6 as well.

I agree with this.

-Dave Thaler

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 26 Jun 2000 05:01:38 +0900

>>>>> On Fri, 23 Jun 2000 11:14:02 +0200, 

   
   
> (my comment was about the emission side but for the reception side your

I admit it would be a matter of taste, but I personally don't want to
have the different interpretation. The semantics of sin_scope_id can
be same for the reception and emission, and (IMO) it sould be same.

> => unfortunately the scope architecture is still waiting for its

Yes, it's just my understanding. So let's discuss this, and the
consensus should be documented (maybe in rfc2553bis?).

> => to (over)specify an interface is better for emission, for reception

I don't think it is not necessarily a better thing. A user might just
want to specify a multicast group (with some zone ID) and let the
kernel send packets to that group on an appropriate interface(s)
according to the kernel's routing table, etc.

> => before listing these, can zero sin6_scope_id give the traditional

Good question...my take is that zero means a "system default" zone of
the scope, but we could interpret zero as "wildcard". Anyway, it
should also be clarified, IMO.

> then the zero sin6_scope_id is enough.

yes, if we interpreted zero sin6_scope_id as wildcard.

> But your idea perhaps is to enable

Yes, the above example described the case that a user wanted to
receive multicast packets of a specified group *with a specified scope
zone*.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 26 Jun 2000 13:07:17 +0900

>>>>> On Mon, 26 Jun 2000 05:01:38 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> I don't think it is not necessarily a better thing.

Sorry, the wording was wrong here. My intention was

  "I think it is not necessarily a better thing."

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Jun 2000 09:49:00 +0200

=> I don't believe we should specify two different interpretations
but obviously we have to do the choice between:
 - use interface indexes and make scope IDs not very useful for the
   receiving side
 - use traditional (ie as for unicast) scope IDs and make the sin6_scope_id
   field nearly useless for emission to destinations to a scope larger
   than link-local (the only thing I can see is to check interfaces
   specified by IPV6_MULTICAST_IF are in the right zone)
I was in favour of the first solution, now I believe the second is better.

   
=> I agree (I've changed my mind)

   This is a different (but important) question, which some of us have
   also been discussing offline.

=> you should have guess I am in favour of this too...
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Jun 2000 09:57:26 +0200

I admit it would be a matter of taste, but I personally don't want to
   have the different interpretation. The semantics of sin_scope_id can
   be same for the reception and emission, and (IMO) it should be same.
   
=> it must be the same but we have to sacrify one side!

=> do you mean we should use the multicast routing table for
genuine packets (BSD IPv4 multicast is not very clear about this
for me, I have no concern but the specs need to be clear(er) about this).
This can make IPV6_MULTICAST_IF useless and/or things even more complex:
what semantics for sin6_scope_id on the sending side do you propose
(and is there a special case for the zero sin6_scope_id)?

=> I agree!

Regards

PS: I can see some progress (and a general agreement about both
the need for clarification (:-) and about the interest of this).
--------------------------------------------------------------------
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: Wed, 28 Jun 2000 12:05:00 +0900

>>>>> On Mon, 26 Jun 2000 09:57:26 +0200, 

>    I think it is not necessarily a better thing. A user might just
   
> for me, I have no concern but the specs need to be clear(er) about this).

Sort of that. We could install a route for ff00::/8 to some interface
as the multicast default route, or we could use a separate mechanism
to implement the default outgoing interface for multicast packets.

> (and is there a special case for the zero sin6_scope_id)?

I don't think such a default route makes IPV6_MULTICAST_IF useless,
but I admit it makes the situation complex. In any case, we should
clarify relationship and/or precedence about all these interfaces.

					JINMEI, Tatuya