Subject: getsockopt() for IPV6_HOPLIMIT

From: "Roy Brabson" <[email-masked]>
Date: Wed, 13 Jun 2001 12:24:31 -0400

I'm struggling to get my hands around the interaction between
IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, and IPV6_MULTICAST_HOPS.  It
seems pretty straight forward if IPV6_HOPLIMIT is specified as
ancilliary data - IPV6_HOPLIMIT overrides the current hoplimit
for that packet only.  But what about when IPV6_HOPLIMIT is
set using setsockopt()?

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?  And what should be returned after
setting IPV6_HOPLIMIT to 100 and following it with setting
IPV6_MULTICAST_HOPS to 5, 100 or 5?

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.

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: "Roy Brabson" <[email-masked]>
Date: Tue, 19 Jun 2001 09:32:31 -0400

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?

Also, I see that the current 2292bis draft has expired.  Are there
any plans to produce an updated version?  From previous postings
back in November regarding the -02 draft there appear to be some
incompatible changes which are being proposed, such as changing
IPV6_PATHMTU to return an ip6_mtuinfo structure instead of an
int, not to mention the changes I listed above (plus several
others).  I'd like to have our implementation track to the ID as
it progresses, but if there aren't any new drafts coming then
we should be implementing to the RFC.

Roy

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Jun 2001 13:54:28 +0200

In your previous mail you wrote:

     used. IPV6_HOPLIMIT can still be sent/received as ancillary data.

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

   Also, I see that the current 2292bis draft has expired.  Are there
   any plans to produce an updated version?  From previous postings
   back in November regarding the -02 draft there appear to be some
   incompatible changes which are being proposed

=> RFC2292 has many bugs (for instance IPV6_RECVPKTINFO is missing
and IPV6_PKTINFO is badly overloaded).

   I'd like to have our implementation track to the ID as
   it progresses, but if there aren't any new drafts coming then
   we should be implementing to the RFC.
   
=> you should not because of the bugs...

Regards

[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 25 Jun 2001 18:31:26 +0900

>>>>> On Tue, 19 Jun 2001 09:32:31 -0400, 
>>>>> "Roy Brabson" <[email-masked]> said:

> 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-masked]> said:

> on the getsockopt() call, 255 or 1?

It should be -1.

> And what should be returned after

It should be 100 regardless the existence of the IPV6_MULTICAST_HOPS
option.  However,

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

---

From: Markku Savela <[email-masked]>
Date: Mon, 25 Jun 2001 13:18:00 +0300

> > getsockopt() calls.

Strongly agree on this. Keep it simple!