On Fri, Jun 29, 2001 at 09:42:59AM -0700, Tim Hartrick wrote:
>
> As I understand the issues, applications may want to be able to specify
> where the non-fragmentable part of the datagram ends and where the fragmentable
Hmm - shouldn't the stack be able to determine this for itself? See if
there's a routing header, if so shove the fragment header after it, if
not shove after the HBH header (if present) or IPv6 header.
> part begins. They also need to be able to specify where in a chain of
> extension headers the stack should insert AUTH or ESP headers.
I can accept that.
> Similarly we need a mechanism which allows an application to determine
> when receiving a datagram where the fragmentable part of the datagram begins
That I can't see a need for. Why'd the receiver even care - it's the
complete reassembled packet he's interested in.
> and where in the chain of extension headers an AUTH or ESP header had
> been located.
Agreed.
That could be handled simply be allowing the header to pass through in
some fashion simply as a marker. They'd then be seen by the CMSG_
macros as any other type of header.
Say convert AH inline to the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
With the payload len set to zero, or even just leave the complete
AH header in place.
For ESP convert to the following inline:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (2 bytes) | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with pad length == 2, and the decrypted payload following it.
DF
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
