Subject: Re: complete the advanced API (rfc2292bis)

From: Derek Fawcus <[email-masked]>
Date: Mon, 2 Jul 2001 04:08:39 +0100

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

---

From: Tim Hartrick <[email-masked]>
Date: Mon, 2 Jul 2001 15:47:52 -0700 (PDT)

Markku,

> 
> If you consider dynamically loadable modules (DLL's) kernel
> extensions, then you are right. It should be possible to add support
> for a totally new extension header to an existing stack by a loadable
> module, which attaches to the stack, without touching the stack and
> API code itself.
> 
> This requirement does have some effect on API, and this is why I have
> some concern that the current "hardcoded known headers approach" will
> differ too much from what I have to put in.
> 

If dynamic loaded modules are available to extend the stack then it is
straight forward to use them to extend the existing API.

This is largely an academic discussion, however.  To my knowledge there
are no current proposals for adding new extension headers and as far as I
remember there have never been any such proposals.

If an implementor wants to code their implementation for an event that
isn't likely to ever come that is certainly the implementors choice.
However, I would object to existing code of other implementors being
discarded wholesale to make it easier for an implementor to make that
choice.

Tim Hartrick
Mentat Inc.

---

From: Tim Hartrick <[email-masked]>
Date: Mon, 2 Jul 2001 15:49:42 -0700 (PDT)

Itojun,

> 	just a meta-thought.

And a well reasoned meta-thought it is.:-)

Tim Hartrick
Mentat Inc.

---

From: Tim Hartrick <[email-masked]>
Date: Tue, 3 Jul 2001 13:33:43 -0700 (PDT)

> 
> So, I'd prefer to complete & document the receive case, and just leave the
> send case for a later doc to define.   That is, not have any method at all
> defined for inserting headers in the new doc for now (implementors can keep
> implementing the current spec).
> 

Only someone that has no running code for the existing API or customers
using it could reach this conclusion.  Throwing out half of the existing
mechanism is worse than throwing out the entire thing.  Real implementors
have implemented the existing mechanism and real customers are using it.
This is not an academic discussion.

What we have here in this discussion is a clear indication that the IETF
shouldn't be doing APIs.  People are free to propose and argue for courses
of action for which they won't have to bare any of the cost.  I would wish,
but have little hope, that this document be tranferred to POSIX or X/Open
for completion immediately.

Given that such good fortune is not likely.  I would argue that the existing
document should be finished as is and published as an RFC.  If after that
a group of contributors wants to create a new extension header API that is
completely distinct from the existing mechanism and DOES NOT obsolete it
that would be great.

In this way we have at least a hope that implementors and customers that
have a investment in the existing mechanism don't get orphaned but this in-
sane process.

This document has been in its current form for something on order of three
years without making forward progress.  Implementors have had no choice but
to write code to this API and customers have had little choice but to use
it.  Making substantial changes to this API at this point is just plain wrong.

Tim Hartrick
Mentat Inc.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 26 Jul 2001 23:52:42 +0200 (CEST)

Catching up on email after some vacation...

> I've just read the previous discussion.  It seems to me that we've
> basically reached a consensus for the receiving side; obsolete the
> IPV6_RECVRTHDRDSTOPTS option, and let the kernel send all headers (if
> requested) to applications in the receiving order.

As I recall this isn't sufficient. Some applications will need to be able
to tell e.g. whether a destination options header was before or after an ESP
header. For constency it would make sense to also be able to tell the
location of AH headers.

A possible solution would be to define IPV6_RECVESPHDR/IPV6_RECVAHHDR
and IPV6_ESPHDR/IPV6AHHDR. The latter two would be passed up as ancillary
data items of zero length (i.e. they would just be markers identifying
the location of the ESP/AH headers in the received packet).

> 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.

I think #2 is sufficient as a goal.
But assuming we want to solve this both for sticky options and
ancillary data it might turn out that a resonable solution would
actually solve #1 as well.
(For instance, the sticky option case could be solved by making the option
buffer carry an addition"index" identifying which extension header the
setsockopt refers to in the sequence starting with the IPv6 header (1st, 2nd, 
etc). Such a solution would allow specifying any order.)

  Erik