Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6"

From: Tim Hartrick <[email-masked]>
Date: Wed, 13 Feb 2002 12:11:40 -0800 (PST)

All,

> > 
> > >    Please let me make sure about this comment...are you proposing to
> > >    remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper
> > >    position of a destination options header (only with the IPV6_DSTOPTS
> > >    option)?
> > 
> > > => yes
> > 
> > >    If so, how can a user specify a couple of destination
> > >    options headers before and after a routing header?
> > 
> > > => he cannot but he doesn't need it and he cannot specify
> > > a destination option header just before a fragmentation header.
> > > IPV6_RTHDRDSTOPTS is unnecessary and misleading.
> > 
> > Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's
> > (even "advanced") applications.  So I, for one, can live with the
> > single option.  However, I'm also quite sure this part is
> > controversial.  I'd like to know others opinions...
> 
> Well, for one, I don't see a good enough reason to remove this.  This
> particular interface allows the user to specify the header that is discribed
> in 2460.  Remembering how much discussion (trouble) we all had figuring out
> this DO Header stuff, I would leave this particular option there.  This
> way, anyone trying to use 2460 header ordering can do so.
>

I have never and still don't see the need to disambiguate between destination
options which come before the routing header and those that come after.  On
the send side it is easy to order your ancillary data or setsockopt calls
in a way that gets you what you want.  On the receive side, if you one cares
whether an option was before or after the routing header one simply needs
to receive both destination options and routing headers.  Lastly, the current
definition requires that at least two passes be made over the options when
preparing to deliver ancillary data.  This is because IPV6_RTHDRDSTOPTS is
defined to be destination options which occur before the routing header.
Once can't tell what type of destination options one is delivering until the
entire datagram has been passed over to determine whether a routing header
is present.  All around badness.

Unfortunately, we have already been forced to write code that implements this
badness.  I would welcome the options removal but I don't believe that we
should spend a lot of time debating the point.
 
> 
> > >> - 11.5: is IPV6_REACHCONF really useful (example)?
> > 
> > >    Honestly, I personally do not see a practical usage of this option.
> > >    At least I've never seen an application that uses it.  I don't mind to
> > >    remove this, but if any other person wants to keep it, I'll just leave
> > >    the current text as is.  The definition has been there since a quite
> > >    old revision of the draft, and it can at least be implemented.
> > 
> > > => I don't believe the "it can at least be implemented" argument is
> > > enough to keep something (the opposite is :-).
> > 
> > Fair enough.  Again, I don't mind to drop this section unless someone
> > wants to keep it.
> > 
> 
> No strong opinions about this.  For most short communications (e.g. UDP)
> it may not be very usefull (particularly in view of DELAY_FIRST_PROBE_TIME
> being 5 seconds, so NUD waits a while).  For long communications,
> it probably will not be usefull either.
> 

The only credible argument I have heard in favor of this option what for use
with client side NFS over UDP.  We have not implemented it yet so I would not
miss this option if it disappeared.

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: Vladislav Yasevich <[email-masked]>
Date: Wed, 13 Feb 2002 15:59:35 -0500

Tim

The IPV6_RTHDRDSTOPTS is a send side only option any more (at least thats
how the spec reads).  For the recieve side,  IPV6_DSTOPTS gets you all
the destination options.

I guess that might be considered another argument for removing this option...

On the other hand, ordering of setsockopt() calls or ancillary data does
not necessarily translate into ordering in the packet (however that's
one way to implement it).

In the end, it's probably easier to keep the option then to remove it, but
I can live with either.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 14 Feb 2002 12:34:49 +0900

>>>>> On Wed, 13 Feb 2002 12:11:40 -0800 (PST), 
>>>>> Tim Hartrick <[email-masked]> said:

> in a way that gets you what you want.

I agree it is (or can be) easy for ancillary data, but I'm not sure
about the case of sticky (socket) option.  What is your idea in this case?

> On the receive side, if you one cares

We've already removed IPV6_RECVRTHDRDSTOPTS and simplified the
receive side, so these issues should have gone (although we've lost
symmetric semantics between send and receive sides - this can be
another motivation to simplify the send side as well).

> should spend a lot of time debating the point.

I agree.  If it is really easy to deal with the send side as you said,
it would be the best candidate (so I'd like to know the details).

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