Subject: Re: complete the advanced API (rfc2292bis)

From: Tim Hartrick <[email-masked]>
Date: Mon, 2 Jul 2001 12:27:17 -0700 (PDT)

Jinmei,

> 
> For the sending side, which would be the difficult part, I think we
> have two possible approaches.
> 
> 1. try to realize the full flexibility about the header chain; the API
>    allows applications to specify any combination of headers (in any
>    order).
> 2. only loosen the restriction about destination options headers;
>    (e.g.) add another ancillary data type/socket option to specify the
>    relationship between a destination options header and a fragment
>    header.
> 
> If we're aiming at the 1st goal, I'm quite sure that we'll need much
> time to discuss it and reach a consensus.  So, in this case, I'd like
> to separate this part from the "basic" part of the advanced API (as a
> separate draft).
> 
> If we take the second approach, it might be possible to get a
> consensus in a relatively short period.  So, it would be worth trying
> to keep the whole spec in a single document.
> 
> As for no.1 vs no.2, I'm inclined to support no.2.  Due to less
> flexibility, of course, we may see another ordering issue in the
> future.  However, at least at this moment, I don't see a possibility
> to use an extension header (except destination options headers) in a
> different way than the recommended way specified in RFC 2460.  And,
> with this approach, we might be able to avoid rewriting existing
> applications that already use rfc2292bis for some extension headers
> (except destination options ones).
> 
> Comments?
> 

I agree with approach no.2 not only because it is the most expedient but
I don't see what other flexibility is required.  If we allow the application,
via ancillary data, to specify multiple destination options headers and
place the fragmentation header (and possible AH and ESP) as the application
sees fit within the datagram then the only piece of flexability that is
missing is the ability to add as yet unspecified extension header types.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: Tue, 03 Jul 2001 10:18:23 +0200

In your previous mail you wrote:

   I agree with approach no.2 not only because it is the most expedient but
   I don't see what other flexibility is required.

=> explain how you can get the position of an extension header in
the current advanced API. There is a setsockopt per header/position
defined in RFC 2460 which gives a lot of different setsockopt (not
a real problem but this is unnecessarily rigid) and of course gives
no way to code something not described in RFC 2460.

   If we allow the application,
   via ancillary data, to specify multiple destination options headers and
   place the fragmentation header (and possible AH and ESP) as the application

=> how?

=> or an extension header forgotten in RFC 2460 like IPCOMP?

I believe we need concrete proposals now. The only two proposals I remember
are:
 - manage the whole array of headers (easy to implement but not to use)
 - manage headers as a stack with placeholders for some headers like
   fragmentations (the user should not give their contents, only their
   possible positions).
The second seems the best (not third proposal :-) but details have to be
written down. This gives enough flexibility too and is closed to the
conceptual model of extension headers.

Regards

[email-masked]