In your previous mail you wrote:
| - this doesn't work well with "transparent" headers like fragmentation
| or IPsecs.
|
| This would still have some problems since certain extension headers
| (fragmentation, AH, ESP) aren't passed up to the application.
|
| => exactly my second concern.
Why?
=> mostly because an application cannot do something useful with them...
But the positions of these "transparent" headers are important then
I believe a stack is the best data structure.
I don't mean why is it a problem, but why are those headers
not passed up to the application?
=> because they have a functional meaning, they doesn't carry information
by themselves.
Or perhaps more directly, why should they not be passed up to the
application?
=> it is more an usage than other (ie. no deep reason for a "should not")
but the fact that a frag header was present, and where it occurred
in the chain of headers seems like useful information to me.
=> we agree about what the API should provide. We have just to find
the best (ie. simplest) way to do this.
I would think that much the same would be true of AH & ESP (though those
headers are beyond where I usually venture into the dark side...) - at the
very least knowing that onet was present, and where it occurred, ought
be useful.
=> yes
Similarly for sending - the kernel interface might well ignore whatever the
application stuck in one of these headers (frag, AH, ESP - perhaps others)
but it could use the presence of such a header to indicate where it should
place a header of equivalent type, constructed however it would have been
constructed without this method of determining its location.
=> we agree.
The "I might be able to use this for DOS attacks" is nonsense - there are
plenty of easier ways to generate arbitrary packets on a wire than worrying
about how to make some arbitrary IPv6 stack do what you want via its API.
=> someone (Itojun?) mentioned BPF (:-)...
Thanks
[EMAIL PROTECTED]
PS: we need:
- a way to get the header stack as it is received
- a way to get the header stack to use for replies (ie. with only
bidirectional items, mostly authenticated routing header).
Should we do this in the kernel (this function exists for TCP).
- pop/push operations
- a set/get for the top of the stack (pop/push can do this too?)
- the structure describing the header can be the header with
its type, its length in the stack (zero for transparent headers).
The effective length is a parameter of set/getsockopt() or ancillary
data.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
