Subject: RE: rfc2553bis comments

From: "Dave Thaler" <[email-masked]>
Date: Mon, 26 Jun 2000 11:21:10 -0700

Francis Dupont writes:
>    If you don't do IPV6_MULTICAST_IF, the meaning would
>    be to send via some interface in the set identified by scope_id.
>    
> => some = one, all, any subset? This needs some clarifications of
> the scope is not the link-local one.

Exactly one.  Same as in IPv4.

-Dave

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Jun 2000 22:20:55 +0200

=> I think this interface will be selected according to the routing table,
ie. in general it will be the interface used for the default route, won't it?
(it is what happens with IPv4 and sin6_scope_id (in your proposal) will
not be used for the outgoing interface selection itself, only for a check
about the selection soundness, ie. with only a little improvement over
standard IPv4 multicast for emission)

Regards

[email-masked]

PS: about the (still missing) scope/zone specs, the zone A `is included
in the zone B if A < B (using for A and B the multicast scope numbers
like 2 (link), 5 (site), 8 (org), ...). This is in *no* current specs...
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Mon, 26 Jun 2000 16:45:17 -0700

I'm sure I'm not following all the intricacies of the arguments, but
maybe this is helpful (or maybe not, or maybe not even relevant):

  When sending a multicast packet in IPv4, one has the choice of either
  identifying a specific outgoing interface or leaving it to the IP layer
  to choose an outgoing interface (the "default" multicast interface).

  For IPv6, with its scoped addresses, the analogous capabilities would
  be a choice among:

	- identifying a particular outgoing interface, or

	- identifying only the outgoing zone (for non-global destinations),
	  and leaving it to the IP layer to choose an outgoing interface
	  within that zone, or

	- leaving it to the IP layer to choose both the outgoing zone (of
	  the scope of the destination address) and the outgoing interface
	  within that zone.

  All this could be done with the single sin6_scope_id field in the sending
  API, 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).

  On reception, the upper-layer should be told the arrival interface,
  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.
	  
At 10:20 PM +0200 6/26/00, Francis Dupont wrote:
>PS: about the (still missing) scope/zone specs,...

The scope/zone spec is not "still missing", though it certainly still needs
work.   draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide,
and an -01 revision was posted to the ipng mailing list by Brian Haberman
on March 22.  That -01 version never made it into the Internet Drafts
directories (it was posted during the time just before Adelaide while
ID submissions were being refused), but we will rectify that ASAP.

>...the zone A `is included in the zone B if A < B (using for A and B the
>multicast scope numbers like 2 (link), 5 (site), 8 (org), ...). This is
>in *no* current specs...

From draft-ietf-ipngwg-scoping-arch-00.txt:

>  There is an ordering relationship among scopes: 
>
>          o  for unicast scopes, link-local is a smaller scope than site-
>             local, and site-local is smaller scope than global. 
>          o  for multicast scopes, scopes with lesser values in the 
>             "scop" subfield of the multicast address [RFC 2373, section 
>             2.7] are smaller than scopes with greater values, with node-
>             local being the smallest and global being the largest.
>
>  However, two scopes of different size may cover the exact same region 
>  of topology, for example, a site may consist of a single link, in which 
>  both link-local and site-local scope effectively cover the same 
>  topological "distance".
>
>...
>
>  Zones have the following additional properties: 
>         
>          o  Zone boundaries cut through nodes, not links.  (There are 
>             two exceptions: the global zone has no boundary, and the 
>             boundary of a node-local zone conceptually cuts through an 
>             interface between a node and a link.) 
>          o  Zones of the same scope cannot overlap, i.e., they can have 
>             no links or interfaces in common. 
>          o  A zone of a given scope (less than global) falls completely 
>             within zones of larger scope, i.e., a smaller scope zone 
>             cannot include more topology than any larger scope zone with 
>             which it shares any links or interfaces. 

Steve

---

From: Jim Bound <[email-masked]>
Date: Mon, 26 Jun 2000 21:31:07 -0400

Hi Steve,

I am just listening but your mail has caused me to respond.

>maybe this is helpful (or maybe not, or maybe not even relevant):

Very relevant as you bring up important issue.

>  to choose an outgoing interface (the "default" multicast interface).

Exactly and this is all we should do for the basic API right now.  Ergo
I have not heard compelling technical or better yet implementation real
world arguments to alter the behavior of the spec to something different
for today.  It could be down the road when scopes (or zones) are better
understood and defined and in fact used in the "real world" we need an
adjunct to RFC 2553.  But right now we are deploying regular old
interfaces and this is a regular old basic API.

But after all air their views on this we can put statement for future
direction and work.  Just like you done with the flowlabel, anycast
addresses and a few others I can't think of off the top of my head.  I
feel we need to do the same with this API and leave very very simple and
basic for the IPv6 ISV community for the intial ports to IPv6.  

But on to your comments.

>	- identifying a particular outgoing interface, or

Yes we can do this today as the spec is written.

>	  and leaving it to the IP layer to choose an outgoing interface

There is not a concept of zone other than in drafts in mail discussions
and some prototype implementations.  This is premature for a real world
API.

>	  the scope of the destination address) and the outgoing interface

Its just an interface not a zone.

>  probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it).

I would claim all this sounds good but not real.  In fact I think things
will change again if we adopt global unique identifiers for site-local
addresses which will be presented at some point in time to the WG.

>  scope, since each interface can belong to only one zone of each scope.

What I would suggest is let implementations evolve.  For now its simply
an interface in and out.  If we want to deprecate it later that can be
done and in a friendly manner.
	  
>ID submissions were being refused), but we will rectify that ASAP.

Still needs work is an under statement.  But its not done and we cannot
base our API on work-in-progress and a very compelling argument for
leaving things alone for now. 

regards,
/jim

---

From: Steve Deering <[email-masked]>
Date: Mon, 26 Jun 2000 19:10:36 -0700

>and some prototype implementations.  This is premature for a real world

Fair enough.  But I believe the API can be written today in a way that
would allow later implementation of zones as proposed, without any change
to that API.

On the other hand, maybe the WG can come to agreement quickly on the
scope/zone architecture, and we can make that explicit in the basic API
spec.  (Hope springs eternal.)

>addresses which will be presented at some point in time to the WG.

If you are going to propose a different scoping model, I strongly suggest
that you document it in an ID before Pittsburgh.  From what I hear,
implementors would like this settled soon (actually, a long time ago).

In any case, I *think* the existing sin6_scope_id field in the API makes
IPv6_MULTICAST_IF redundant, so the latter could be deprecated now,
even if sin6_scope_id is only ever used to identify interfaces, rather
than interfaces plus zones.

>Still needs work is an under statement.

I don't recall receiving any comments on the draft, so apart from the work
the authors' know is still needed (mostly discussion of scoping in the
context of mobility), we haven't got any feedback to tell us about other
perceived inadequacies of the current document.  I encourage everyone to
look it over (the -01 version, please) and let us know.

Steve

---

From: Jim Bound <[email-masked]>
Date: Mon, 26 Jun 2000 23:19:00 -0400

Steve,

>implementors would like this settled soon (actually, a long time ago).

I know exactly what each "PRODUCT IMPLEMENTATION" offers and the
idea of scoping is not even on the table for deployment.  No one is even
suggesting who ships real products breaking the server apps I spoke of
they would be out of business right now for IPv6.  Hello, Mr. Customer I
am vendor X and here is my new IPv6 product, but beware it will break
your network server apps but go ahead implement sitelocal addresses with
overlapping servers.  I am speaking of an Open Systems enviornment where
all IETF standards are adhered too and proprietary extensions are
frowned upon by the customer, that would break multi-vendor total
interoperability.

But we need to work on it quickly I agree.  This API is for now not
tomorrow.  It could be we need adjuncts to the API, and new specs like
we may have new Addressing specs.

As far as my idea.  No way will I have a draft before Pittsburgh.  That
ain't happening.  I am willing to present the idea on the agenda
depending on what times/days IPng is happening at Pittsburgh.
Thats ujp to you and Bob.  I did not suggest it as I could not get a
full draft written up by the deadline or the IETF meeting.
But I also have one hell of an argument prepared for the IESG if we
don't fix the overlapping app problem in our deliberations for scoping.
I think I will at least raise some questions.

>than interfaces plus zones.

This is possible if we qualify for now that it is just an interface.
This is the first time it came up really we have been living with do
what IPv4 did.  We can do different but I don't want to open up a six
month debate on the API update and we are now faced with backwards
compatibility so we will need to support both.  We can't break ISV apps
each time we update this API spec and after this update we move to API
part II or put it in the Advanced API.  So we will need both if we go
this route.  Again folks have already ported applications we cannot
break those apps.  So for this spec deprecation is not a good idea.

>look it over (the -01 version, please) and let us know.

Hmmm for some reason I can't find the -01 version.  I will check that.
But I thought the draft was fine except I want another draft that makes
all addresses except link-local unique within a site.  This prevents
breaking Internet Server Apps that cross site boundaries.  I sent input
to that affect.  I do need now to check you did nothing to prohibit what
I want to suggest but I don't think you did?  

regards,
/jim

---

From: Steve Deering <[email-masked]>
Date: Mon, 26 Jun 2000 23:52:22 -0700

At 11:19 PM -0400 6/26/00, Jim Bound wrote:
>Hello, Mr. Customer I am vendor X and here is my new IPv6 product, but
>beware it will break your network server apps but go ahead implement
>sitelocal addresses with overlapping servers.

By "overlapping server", do you mean a server directly connected to more
than one site?  If so, sensible vendors Y and Z would say:

   Hello, Mr. Customer I am vendor Y and here is my new IPv6 product
   [ported in two hours from my old IPv4 product]. If you are using
   site-local addressing, be aware that each site will need its own
   copy of the server.  We have a special deal for you if you buy more
   than one.  :-)

   Hello, Mr. Customer I am vendor Z and here is my new IPv6 product
   which has been enhanced to support multiple sites from the same server.

>Thats ujp to you and Bob.

Let's see how the discussion here plays out before deciding about that.

>...So for this spec deprecation is not a good idea.

OK, you and and Tim have convinced me of that.

>Hmmm for some reason I can't find the -01 version.

It should appear in the ID directories in a day or two.  It was posted
to the ipng list on March 22, so if you archive past ipng mail, you
might find it sooner there.  (Or send me mail and I will send you a
personal copy.)

Steve

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Jun 2000 10:05:01 +0200

=> I apologize because I've forgotten the draft-ietf-ipngwg-scoping-arch-00.txt
document (I was disturbed by the fact that the -01 was never/not yet
available in the I-D directories). The zone inclusion property is in
the I-D and there are some rules about emission using it as:
For this reason (selection of a sub-zone), an implementation might 
find it useful to assign a distinct value for each zone index, so that 
they are unique across all zones, regardless of scope. 

If we have distinct values then we can implement any kind of outgoing
zone selection, ie. we can specify in the sin6_scope_id field the zone
of the outgoing interface, the only restriction is its scope must be
smaller or equal to the address scope. Then I have three questions
about this:
 - a link zone can have more than one interface, is there practical
   example where this can be a problem?
 - should we extend this model to global addresses (this is a proposal
   for the sin6_scope_id meaning)?
 - should we extend this model to the reception side, ie. one matches
   only when the incoming interface belongs to the right zone?
This seems not hard to implement (other opinions?), we just need
a scoped routing table (already needed today) and a good zone naming
scheme (users should understand it :-).
Last point, where to put this? In the rfc2553bis or the scoping arch?
(we can introduce a hard dependence between the two I-Ds)

=> this is relevant!

   
   
=> do you mean a particular outgoing link (someone has already corrected
me about the difference :-) or do you rely on IPV6_MULTICAST_IF?

=> I don't know if the non-global restriction is really needed.
There are some situations where it is very nice to have a per-interface
(sorry, a per-link) default route(r).

     API,

=> we can do a similar thing in the receiving API. I'd like to have the
same kind of usage between the sending and the receiving sides (in fact,
this point is the reason I've jumped into this discussion :-).

     if the local indexes for the interfaces plus all zones (i.e., links,
   
=> the only reason we should have to keep IPV6_MULTICAST_IF is an
interface specification can be finer than a link one...

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

=> there are two points: API (what the user will get) and PCB matching
then I don't fully understand you...

   That -01 version never made it into the Internet Drafts
   directories (it was posted during the time just before Adelaide while
   ID submissions were being refused), but we will rectify that ASAP.
   
=> thanks!

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Jun 2000 12:25:07 +0200

>  to choose an outgoing interface (the "default" multicast interface).
   
   Exactly and this is all we should do for the basic API right now.

=> we'd like to keep this when the sin6_scope_id is zero. In fact
I believe the current idea is to extend the (non-zero) sin6_scope_id
semantics and to specify what happens with multicast (where different
incompatible proposals are already implemented). If someone uses the
old style (mainly interface indexes for link-local and zero
sin6_scope_id for others) then one should get *exactly* the same behaviour.

   >  ... Then, I think we could
   
   I would claim all this sounds good but not real.

=> I believe that Steve has launched the idea of a nice extension of
the current API. If it is a sound extension (ie. the old part remains
as it is) this will satify both your concern (not yet a new API!) and
our (do the best possible usage of sin6_scope_id).

   In fact I think things
   
=> I believe this point is about multi-sited nodes where the old API
can't help (just because we didn't understand the issue) then the
new extension can only be an improvement.

Regards

---

From: Steve Deering <[email-masked]>
Date: Tue, 27 Jun 2000 07:37:11 -0700

At 10:08 AM -0400 6/27/00, Jim Bound wrote:
>Well 2 hours is a bit short but ISVs will not want to mess with their
>architecture for applications either and thats what this is all about.
>Also not all customers want two servers.

How common is it for a single server to be *directly* connected to more
than one customer site?  Usually, sites are connected via routers, either
indirectly through ISPs or directly through "back-door" private links.

>That would mean having to differentiate sin6_scope_id for each address
>which is not well defined today for anyone.

Yes, that's what we are trying to define so we can move forward.

Steve

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 11:02:43 -0400

>indirectly through ISPs or directly through "back-door" private links.

Well first we are not sure yet how they will define site?  If they use
site as "department" is how I view it and maybe a good assumption for
this discussion as a model to determine the pain.

But DNS and DHCP for sure.  Other less known apps are the ones developed
by Oracle, Sybase, Informix etc... where IP addresses are used to
identify clients records (much like DNS and DHCP do).

But once could have:

   fec0::1 site A 

               |
               Router
               |
   fec0::1 site B

Where all DHCP and DNS and Database accesses for both sites
(departments) are in site B.  Or department B maintains all servers for
all other departments (other sites).

The problem is that the src address to site B will be feco::1 or from
site A.  The server apps needs to know the zone via the sin6_scope_id
from the packet.  Then if the database lookup was:

  IPv6 address

It would have to change that to:

  IPv6 Address + sin6_scope_id

Site B would know this from the router connection to Site A (likewise
Site A would know B).

It really is putting a completely new variable in the net communications
paradigm for these apps.

Bottom line I would like to see us avoid that architecturally for
applications for Ipv6 and keep it simple as it was for IPv4.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 10:08:16 -0400

Steve,

>than one site?  If so, sensible vendors Y and Z would say:

Yes I believe that was obvious sorry if it was not and I too terse.

That would mean having to differentiate sin6_scope_id for each address
which is not well defined today for anyone.  Also with my thought of a
fix this all becomes uncessary if we use the rsvd bits in site-local to
provide uniqueness.  

Not a big fan of site-locals in DNS either but thats another discussion.

>might find it sooner there.  (Or send me mail and I will send you a

I am sured I pulled it over.  Hmmm...................

thanks,
/jim

---

From: Francis Dupont <[email-masked]>
Date: Thu, 29 Jun 2000 10:14:38 +0200

=> I don't believe this (reserved bits) idea will work because
even if we shout they should be random in order to avoid collisions
the human laziness will make only small values (1, 2, .., and don't
forget many will stay with zero because it is the current mandatory
value) to be used then they will collide.
All the problems of some well known IPv6 implementations using embedded
interface indexes in link-local addresses from place to place in the code
make me even less confident...
The sin6_scope_id is there in order to solve this issue, let it do its job!

Regards

---

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

>they are unique across all zones, regardless of scope. 

Yes, I think that makes the most sense.  Our current draft suggests,
but does not require, that different scopes use different zone indices,
but I'd be in favor of changing that in the next revision (just have
to convince my co-authors).

>   example where this can be a problem?

I'm not sure what you are asking.  Are you asking if there is a practical
reason to support multiple interfaces to the same link?  Or are you asking
if we have all the machinery necessary to properly support multiple
interfaces to the same link?

>   for the sin6_scope_id meaning)?

Our draft does mention the use of smaller-scope zone indices when sending
to a global destination address (section 7, last paragraph, penultimate
sentence).

>   only when the incoming interface belongs to the right zone?

Are you talking about using bind() to limit the zone of acceptance?

>me about the difference :-) or do you rely on IPV6_MULTICAST_IF?

In the above-quoted text, I was referring to an outgoing interface, not
an outgoing link.  If you read the scoping architecture draft carefully,
you'll see that we specify separate zone indices for interfaces and for
links.  For example, Figure 1 in the draft shows a node with zone indices
for each of the following zones:

  intf1, intf2, intf3, intf4, intf5, link1, link2, link3, link4,
  site1, site2, site3

The zone indices for interfaces arise from the definition of the (multicast)
node-local scope as spanning only a single interface. Then, by allowing
any transmission to be constrained to a lesser-scope zone, we can use
those node-local zone indices to specify a particular outgoing interface,
even for sending unicasts.

Now, that's a pretty sneaky way of unifying interface indices and zone
indices, and it is pretty counterintuitive too: a packet whose transmission
is constrained to a node-local zone ought not to be allowed to leave the
node.  And I think that if I were starting from scratch, I would eliminate
the node-local multicast scope altogether (and use link-local multicast
scope on the phantom loopback link to achieve the purposes for which
node-local was intended).  So I'm now more inclined towards explicitly
distinguishing between interface indices and zone indices, but giving
them distinct values so they can both be carried unambiguously within a
single field, such as the interface field in the in6_pktinfo structure.

>=> I don't know if the non-global restriction is really needed.

It's not.  In the above-quoted text, I was trying to avoid the diversionary
issue of using of lesser-scope zones.

>the zero sin6_scope_id in recvfrom() because there is only one global zone).

Yes, my thinking was muddled.  I think we need to distinguish between
two different uses of zone/interface indices:

  (1) to identify the zone of an address, in a node that is attached to
      more than one zone of that address's scope.  This is the purpose
      of the sin6_scope_id field in the sockaddr_in6 structure, and of
      the "%" qualifier in the textual representation of IPv6 addresses.

  (2) to constrain the set of interfaces over which a packet may be
      transmitted -- or on which a multicast group is to be joined --
      to a set *less than* that implied by the zone of the relevant
      address.  This is the purpose of the interface index in the
      in6_pktinfo structure, and in the IPV6_MULTICAST_IF and
      IPV6_JOIN_GROUP setsockopts, and of a "-i <interface>" or
      "-z <zone>" command line option in, for example, a ping command.

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

(If the above is just a restatement of what some of you have been
saying all along, please forgive me for spending more time talking
than listening.)

Steve

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Jun 2000 11:24:59 +0200

Our current draft suggests,
   but does not require, that different scopes use different zone indices,
   but I'd be in favor of changing that in the next revision (just have
   to convince my co-authors).
   
=> I'd like to have a require for the numerical values.

   
=> second but if we can convert node-local to interface-local the whole
issue will be magically solved!

   
=> yes, I like symmetry.

   links.

=> I've missed the usage of node-local (*) zone IDs for denoting
interfaces. (*) we *must* change the name to interface-local ASAP!

=> I agree but can we do these necessary changes?

   

=> don't forget that IPV6_JOIN_GROUP has a global effect then one can
easily misunderstand what is really "a multicast group join"...
I am not convinced that we need to distinguish between the two cases,
in fact I'd like to not go backward to -i/-z extra parameters to all
the applications...

   
=> I agree but what happens if we convert node-local to interface-local
(I think that the whole restriction will vanish).

=> I agree and in this case there is no issue because all the addresses
have a scope strictly greater than node-local with the exception of ::1
which is already very special.

=> why is it not enough for zones to use sin6_scope_id as suggested
in the scope arch I-D? I'd like to have both (extended) in6_pktinfo
and sin6_scope_id, functions are not exactly the same (in6_pktinfo
can specify the source address too) and there are a lot of old codes
using in6_pktinfo, for instance all the RIPng implementations I know...

=> I agree. We have to extend in6_pktinfo to IPv4 too in order to
have more regular codes.

=> fine.

Thanks

PS: the two remaining questions are:
 - do we agree about this model?
 - do we convert node-local to interface-local or put interface indexes
   into another space than zone IDs (this will force by side effect all
   the interface index restrictions)?
--------------------------------------------------------------------
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: Sat, 01 Jul 2000 02:52:00 +0900

>>>>> On Thu, 29 Jun 2000 18:36:29 -0700, 
>>>>> Steve Deering <[email-masked]> said:

> saying all along, please forgive me for spending more time talking

Hmm...this is surely a candidate that we can compromise, but please
let me ask you some questions about this model:

- In this model, we still interpret sin6_scope_id as a single space
  (over all scopes), right?

- Are we tring to allow users to specify broader scopes than
  interfaces in in6_pktinfo? (Note that the in6_pktinfo structure
  specifies an *interface* index according to RFC2292:
       struct in6_pktinfo {
         struct in6_addr ipi6_addr;    /* src/dst IPv6 address */
         unsigned int    ipi6_ifindex; /* send/recv interface index */
       };
  There's no ambiguity in this point, so if the answer is yes, then we
  are trying to make an extension to the advanced API.)

- If the answer to the previous question is yes, the interpretation of
  in6_pktinfo.ipi6_ifindex can be differrent between the sending side
  and the receiving side; for the sending side, we allow all type of
  zone identifier (as far as it is valid according to the
  corresponding address). For the receiving side, it is always
  interpreted as an interface index. Is this understanding correct?

- What if we specify a zone ID of a broader scope than interface for
  IPV6_JOIN_GROUP? Does this mean we're listening to the multicast
  group on all the interfaces of the zone?

Regardless of the answers to the questions, I think I have to consider
the model more carefully...personally, I still think we should go with
a simpler way (i.e the traditional way), but I may be wrong.

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