Date: Mon, 18 Dec 2000 19:01:05 +0100
From: Francis Dupont <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| when there are multiple destination options headers in each of these two
| logical locations.
|
| => merge them???
Ugh!
| => this is the solution I use in my current code: a big buffer with the
| whole option array but:
Good.
| - this is less flexible than individual header management (for instance
| the good way to insert a header is to pickup the current array before).
It is more flexible, but perhaps more complex to handle.
| - 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? I don't mean why is it a problem, but why are those headers
not passed up to the application? Or perhaps more directly, why
should they not be passed up to the application? Sure, in general
they (the frag header in particular) doesn't supply much in the
way of information, and because the different frag headers on the
different frags all contain different data there's no way or reason
to send all of that - but the fact that a frag header was present, and
where it occurred in the chain of headers seems like useful information
to me (to those comparatively few processes that actually care about
any of this and aren't just doing read/write down a TCP stream anyway).
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.
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.
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.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
