Subject: Re: getsockopt() for IPV6_HOPLIMIT

From: "Roy Brabson" <[email-masked]>
Date: Wed, 20 Jun 2001 10:06:33 -0400

On Wednesday, 06/20/2001 at 01:54 ZE2, Francis Dupont
<[email-masked]> 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-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Jun 2001 14:11:00 +0200

I'm still unsure what to return on getsockopt() for IPV6_HOPLIMIT when
   the unicast and multicast hop limits are different.

=> there was already an old thread about this. If the socket is bound
there is no ambiguity. I believe the conclusion was to return an error
for unbound sockets (default hop limits are too different), this makes
the choice between sticky parameters / parameters per sendmsg() call
more sound (i.e. the source address is considered as a standard parameter).

   This can happen
   
=> there is nothing about interaction between IPV6_HOPLIMIT and
IPV6_XXXCAST_HOPS...

   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.

=> but the ancillary data coding style is considered as very painful
to use in some cases so the options are defined for both the sticky
and the ancillary styles.

   Introducing IPV6_HOPLIMIT on
   getsockopt() and setsockopt() seems to provide little to no value

=> the 6.3 section of last 2292bis I-D explicitely mentions sticky
IPV6_HOPLIMIT...

Regards

[email-masked]