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?
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.
=> 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 PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
