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