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