Subject: destination option update

From: Francis Dupont <[email-masked]>
Date: Fri, 15 Dec 2000 02:19:12 +0100

The working group has just decided the flawn is not in the specs but
in the advanced API then either:
 - or we found a good way to encode positions (I have no idea of how)
 - or we arbitrary restrict the advanced API expressiveness to
   some common cases (as it is done today but we already need to
   add a new position for destination option headers).
As I don't know if the first goal is possible to archieve I suggest
to go to the second if no progress is done before a reasonnable delay.

Regards

[email-masked]

PS: I believe my proposal will be still useful for the names
(not of headers but for positions). Of course other points are
still valid (and according to Steve Deering, it is legitimate
for a new application to use an existing header in a new position,
so mobile IPv6 doesn't violate RFC 2460).
PPS: current advanced API uses IPV6_[RECV]DSTOPTS/IPV6_[RECV]RTHDRDSTOPTS.
According to Steve this is wrong but he has not yet proposed something else.

--------------------------------------------------------------------
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: Tim Hartrick <[email-masked]>
Date: Mon, 18 Dec 2000 14:39:46 -0800 (PST)

Niels,

> 
> To me it would make sense to have associated data that is the index of
> the security association used (is that the right term? I'm not really
> up to date on IPSEC terminology).
> 
> Would it make sense to use the same ancillary data on the sending
> side, for applications that want full control of IPSEC and other
> headers? I'm imagining an application that makes creative use of
> nested ESP and source routing headers for hiding traffic.
> 

I question the utility and security of these additional facilities
but I am not a sear nor a security expert.  I would prefer to keep it
simple and opague unless absolutely required.  Other's opinions may vary.

tim