Subject: Re: Comments on 2292bis (Adv. API)

From: Tim Hartrick <[email-masked]>
Date: Wed, 1 Sep 1999 20:23:57 -0700 (PDT)

> From [email-masked] Wed Sep  1 20:14:59 1999
> Received: from roll.mentat.com (roll [192.88.122.129])
> 	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA02470
> 	for <tim@leo>; Wed, 1 Sep 1999 20:14:58 -0700 (PDT)
> Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
> 	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id UAA18320
> 	for <[email-masked]>; Wed, 1 Sep 1999 20:14:57 -0700 (PDT)
> Received: from sunmail1.Sun.COM ([129.145.1.2])
> 	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29413;
> 	Wed, 1 Sep 1999 20:14:02 -0700 (PDT)
> Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31])

Erik,

> 
> Well, "last specified" isn't well defined when a single sendmsg can carry more
> than once ifindex (sounds like 3 currently with sin6_scope_id in the 
> destination, in IPV6_PKTINFO, and in sin6_scope_id in the nexthop).
>

Sure we need to define the ordering.  I would say that the address would be
first, and the options would be considered in the same order they are placed
in the cmsghdr vector.
 
> > > For IPV6_PKTINFO there might be a difference whether it is a sticky option
> > > or in ancillary data.
> > > 
> > 
> > I am not sure what you mean here.
> 
> A possible choice would be
> 	IPV6_PKTINFO in acillary data overrides sin6_scope_id in the destination
> but
> 	sin6_scope_id in the destination overrides a sticky IPV6_PKTINFO
> 
> I'm not saying that this makes sense - I'm just saying that when exploring
> the precedence rules we need to think about possible differences
> whether a pirce of information is used as a sticky option or
> as ancillary data.
>

I see.  Any chance that the problem can be done away with by simply not
allowing IPV6_PKTINFO and IPV6_NEXTHOP to be sticky?  Do they have much
utility as sticky options for a TCP connection?  Just asking while trying
to sort out all these permutations.....

tim
--------------------------------------------------------------------
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: Tim Hartrick <[email-masked]>
Date: Wed, 1 Sep 1999 20:35:41 -0700 (PDT)

Erik,

> I'm not directly disagreeing with you but in general this is not
> sufficient.
> Certain applications might desire to only receive packets on one
> interface while still being able to receive both unicast as well as
> one or more multicast addresses.
> 
> Either the app can use N sockets each bound to a link local unicast/multicast
> address with the appropriate scope-ip, or use single in6addr_any
> socket and IPV6_RCVPKTINFO to throw away the undesired packets.
> 
> It seems like we are creating multiple mechanisms to do the same thing.
> How do we gauge when we have enough mechanism?
> 

We certainly have lots of ways to solve the interface specification
problem as was noted earlier by Itojun I think.  This is an unfortunate
consequence of not developing the basic and advanced APIs together.

Do you see an easy way throw out something that is superfluous?  If we
don't need to be compatible with existing 2292 we could be a little more
vicious about reworking this.  For example we could completely rethink
PKTINFO and NEXTHOP and see if we can come up with alternatives that have
less duplication of capability with the scope-id.  Just off the top of my
head, of course.  I haven't really given it much thought.

tim