Subject: Re: complete the advanced API (rfc2292bis)

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

Markku

> 
> > From: JINMEI Tatuya / 神明達哉 <[email-masked]>
> > 
> > 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 like 1. It's simpler, easier to implement and document. Nice generic
> and dumb API.
>

Easier only if one doesn't have existing software which implements and uses
the current API along with documentation that documents the current API.
If one does have existing code and documentation then 1. just looks like
double the work and headaches for one's customers.

Note that the current Advanced API is not less than the second major
revision of this API.  For those of us that had the pleasure of implementing
the last major revision four or so years ago and then throwing it out,
1. seems like complete insanity.
 
> To me it seems to be more work, if you have to define, implement and
> document every possible extension header separately in the API (as 2
> will require).
> 

This would be true if it were possible to add a new extension header type
without modifying the kernel.  It isn't really possible in the implementations
I have seen so there really isn't any flexibility gained by throwing out
the existing extension header API.  New extension headers will require
kernel modifications.  Once kernel modifications are required, adding API
hooks to deal with the new extension header is straight forward.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: Markku Savela <[email-masked]>
Date: Tue, 3 Jul 2001 01:26:14 +0300

> From: Tim Hartrick <[email-masked]>

> hooks to deal with the new extension header is straight forward.

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.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 03 Jul 2001 07:36:24 +0900

I'm finding hard time trying to find a good balance between BPF, and
	basic API.  advanced API (ancillary data) should fit somewhere
	inbetween.  RFC2292 had a good balance by limiting the ordering of
	headers to what is documented in RFC2460, and limiting itself from
	handling non-IPv6 headers like AH/ESP (i believe users do not want to
	manipulate AH/ESP from normal socket API.  also, how do you plan to
	handle IPsec-tunnelled packets?).
	by removing more limitations, we get closer and closer to BPF...

	i guess, if we follow the spirit of RFC2292, we first need to
	evaluate RFC2460, to see if we need to remove some of suggested header 
	ordering constraints - MIP6 seem to conflict with it, with some reasons
	(i have trouble chasing recent MIP6 discussions, so i may be wrong).
	then, we design 2292bis to follow the new header ordering constraint.

	just a meta-thought.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jul 2001 14:20:04 +0200

This would be true if it were possible to add a new extension header type
   without modifying the kernel.  It isn't really possible in the
   implementations I have seen

=> I disagree: I use a table for header management with some free slots
so it is possible to add an option or an extension header without modifying
the current kernel, you just need to add some code (eventually) via
a dynamic kernel module.
So I can't agree with your conclusions...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 03 Jul 2001 14:35:28 +0200

I'm finding hard time trying to find a good balance between BPF, and
   	basic API.  advanced API (ancillary data) should fit somewhere
   	in between.  RFC2292 had a good balance by limiting the ordering of
   	headers to what is documented in RFC2460,

=> this is a concern because RFC 2460 doesn't document all useful cases
(IPCOMP was forgotten, MIP6 needs destination option at a new position, ...).

        and limiting itself from

=> manipulation of AH/ESP themselves no, but manipulation of the position yes.

=> MIP6 conflicts with it, I tried at the San Diego IETF to solve it:
 - me: 3 different documented positions (2 in RFC, 1 in MIP6 I-D) for
       destination option headers are a real mess. Give different numbers
       (i.e. make different headers), ...
 - Steve Deering (chair): don't change RFC 2460, it is near perfect (:-).
 - me: how to solve the conflict?
 - Steve: an application can decide to use an order not documented in
          RFC 2460 (i.e. the ordering is recommended, not mandatory,
          and can be updated (change the order, add new headers) if needed).
 - me: but how to code it, the (advanced) API doesn't give the needed
       flexibility.
 - Steve: fix the API!
 - Eric Nordmark (from another room): heu... What's happened?

=> I agree: with a clear description of RFC 2460 flexibility we'll know
what we need for the API.

   	just a meta-thought.
   
=> can you summarize what happened at San Diego (I am likely a bit biased)?

Thanks