On Wednesday, 06/20/2001 at 01:54 ZE2, Francis Dupont
<[EMAIL PROTECTED]> wrote:
> In your previous mail you wrote:
>
> 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 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?
>
> => no, IPV6_HOPLIMIT is the hop limit to use and IPV6_RECVHOPLIMIT
> is a flag saying that the received hop limit must be provided to the
user.
> IPV6_HOPLIMIT can be sticky or ancillary, IPV6_RECVHOPLIMIT must be
> sticky.
I'm still unsure what to return on getsockopt() for IPV6_HOPLIMIT when
the unicast and multicast hop limits are different. This can happen
in two cases. First, prior to any setsockopt() for IPV6_HOPLIMIT,
IPV6_UNICAST_HOPS, or IPV6_MULTICAST_HOPS. Second, a setsockopt()
for IPV6_HOPLIMIT followed by a setsockopt() for either
IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS.
I can see several approaches to handling this:
- Fail a getsockopt() for IPV6_HOPLIMIT if the unicast hoplimit
and multicast hoplimit are different. This will require that
the caller issue a setsockopt() for IPV6_HOPLIMIT before they
can issue a getsockopt() (that is, there is no default value
for IPV6_HOPLIMIT), and will also fail a getsockopt() for
IPV6_HOPLIMIT if a subsequent setsockopt() for
IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS is issued.
- Always return the unicast hoplimit for a getsockopt() for
IPV6_HOPLIMIT. This is a little strange when the unicast
and multicast hoplimits are different, but at least it is
predictable and provides a default value for IPV6_HOPLIMIT.
- Some other approach which I haven't thought of.
Hopefully an updated version of the draft (assuming there will
be one) will spell out what the proper behavior is.
I still think all of this is unnecessary, anyway. Applications
can use IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for getsockopt()
and setsockopt() and IPV6_HOPLIMIT for ancillary data and receive
consistent and predictable results. Introducing IPV6_HOPLIMIT on
getsockopt() and setsockopt() seems to provide little to no value
and just seems to muddy the water.
Roy Brabson
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
