>>>>> On Tue, 19 Jun 2001 09:32:31 -0400,
>>>>> "Roy Brabson" <[EMAIL PROTECTED]> said:
> I actually went back and read the existing RFC2292 - probably
> something I should have done originally - and I think I have
> a handle on this. Based on the current RFC and the -02 draft
> my interpretation is that:
> - IPV6_HOPLIMIT should not be allowed on a getsockopt() or
> setsockopt() call, but instead IPV6_RECVHOPLIMIT should be
> used. IPV6_HOPLIMIT can still be sent/received as ancillary
> ancillary data.
> - IPV6_RECVHOPLIMIT should be used on setsockopt() to request
> that the IPV6_HOPLIMIT be returned as ancillary data.
> Does this sound correct, or am I missing something?
I believe getsockopt(IPV6_HOPLIMIT) simply returns the value set by
setsockopt(IPV6_HOPLIMIT), or the default value (0 for RFC2292 and -1
for rfc2292bis) if the option has never been set on the corresponding
socket. There should be no ambiguity on this point.
Going back to your examples (I believe you assume the rfc2292bis
behavior in these examples),
>>>>> On Wed, 13 Jun 2001 12:24:31 -0400,
>>>>> "Roy Brabson" <[EMAIL PROTECTED]> said:
> Using setsockopt() calls, I think the behavior would be as follows:
> Unicast Hop Limit Multicast Hop Limit
> ----------------- -------------------
> default 255 1
> IPV6_HOPLIMIT=100 100 100
> IPV6_MULTICAST_HOPS=5 100 5
> IPV6_UNICAST_HOPS=50 50 5
> IPV6_HOPLIMIT=3 3 3
> The question is, what should be returned for a getsockopt() on
> IPV6_HOPLIMIT when the unicast and multicast hop limits are different?
> Take the default case for instance. What is the correct value to return
> on the getsockopt() call, 255 or 1?
It should be -1.
> And what should be returned after
> setting IPV6_HOPLIMIT to 100 and following it with setting
> IPV6_MULTICAST_HOPS to 5, 100 or 5?
It should be 100 regardless the existence of the IPV6_MULTICAST_HOPS
option. However,
> All of this would be *much* simpler if the advanced API only allowed
> IPV6_HOPLIMIT to be specified as ancillary data and required the use of
> IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and
> getsockopt() calls. Unfortunately, that isn't the case as 2292 allows
> IPV6_HOPLIMIT to be specified as a sticky option.
I tend to agree on this point. If we used a single socket for unicast
and multicast packets, and wanted to use a same hoplimit for both,
IPV6_HOPLIMIT would be useful, but I don't think it's worth the
complexity introduced by the combination of the 3 options.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
