Subject: Re: complete the advanced API (rfc2292bis)

From: Tim Hartrick <[email-masked]>
Date: Tue, 3 Jul 2001 12:20:06 -0700 (PDT)

> 
> => explain how you can get the position of an extension header in
> the current advanced API. There is a setsockopt per header/position
> defined in RFC 2460 which gives a lot of different setsockopt (not
> a real problem but this is unnecessarily rigid) and of course gives
> no way to code something not described in RFC 2460.
>

The sticky options are quite restrictive at the moment.  Making them more
flexible is a little difficult.  Ancillary data can be made more flexible
fairly easily.
 
>    If we allow the application,
>    via ancillary data, to specify multiple destination options headers and
>    place the fragmentation header (and possible AH and ESP) as the application
> 
> => how?
>

Please see the archives.  We began defining position markers six months ago
and folks lost interest.
 
>    sees fit within the datagram then the only piece of flexability that is
>    missing is the ability to add as yet unspecified extension header types.
>    
> => or an extension header forgotten in RFC 2460 like IPCOMP?
>

I believe that all that is required is the ability to designate where the
fragmentable part the the datagram begins and where the "terminal" header
should be placed.  This would accomodate placement of ESP, AH, IPCOMP or
any other terminal header type.
 
>  - manage headers as a stack with placeholders for some headers like
>    fragmentations (the user should not give their contents, only their
>    possible positions).
> The second seems the best (not third proposal :-) but details have to be
> written down. This gives enough flexibility too and is closed to the
> conceptual model of extension headers.
> 

This can be done within the existing model.  So why is a complete redesign
essential except as a full employment program for kernel programmers?

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: Robert Elz <[email-masked]>
Date: Wed, 04 Jul 2001 14:43:07 +0700

Date:        Tue, 3 Jul 2001 12:20:06 -0700 (PDT)
    From:        Tim Hartrick <[email-masked]>
    Message-ID:  <[email-masked]>

  | I believe that all that is required is the ability to designate where the
  | fragmentable part the the datagram begins

Hang on a minute ... you think there is a "fragmentable part" and another
part?

Just one?

Why?

IPv6 has fixed vast numbers of limitations in IPv4, we should not be
re-imposing IPv4 back on it again, just because no-one has yet noticed
the beauty and flexibility o what IPv6 actually allows.

Eg; if I'm stuck at the end of a link with a low MTU (a gif tunnel
someone has configured with an MTU of 1280 - just enough to survive
with IPv6 or something like that), which then terminates at a more
reasonable link (GigaE or FDDI or something) with a 4K or bigger
MTU, and that gets most of the way to the destination, where the
final hop is a HIPPI (or whatever that thing is for which jumbograms
were invented, which has a very high per packet cost), then
I might be tempted to do ...

	IPv6 FH RH FH RH <data>

That is, I have a 32K (or whatever) packet, which I have split into
4K fragments, and then each of those fragments has been split into 1280
fragments for the first hop.

When the router gets my tiny fragments, it reassembles them (it has to, it
can't progress beyond the frag header until all the frags are ressembled,
and because of the IPv6 design of having the "next hop" address in the IPv6
header, it knows that all the frags will arrive).  It builds a 4K
packet out of that.

That Frag header is then deleted (it doesn't actually matter if it is
retained, it now shows one frag, ie: offset==0, MF==0).   Then the routing
header is examined, and the router adjusts the IPv6 header, and forwards
the packet to the next node from it - which is the one which has the HIPPI link.
This happens to each of the 8 (or 9 or whatever it is) 4K fragments of
the original big packet.   When the packets arrive at the HIPPI interface
the first routing header is found to be exhausted, and and so the
fragments of the 2nd fragmentation header are collected.   Once that
has been done, the 2nd routing header is uncovered, and the (now) 32K
packet is forwarded in one go to the destination over the very high MTU
link at the end.

I know this is something of a far fetched example - but there are all kinds
of potentials in the IPv6 architecture just waiting to be discovered by
someone with a need for them - all that's required then is for the
implementations to stay out of the way - allow the headers to be built
the way that the source node builds them, and then process them in
a strictly left to right order at the recipient, doing whatever is
needed for each header before going on to the next.

In a later message you said ...

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

I don't mind that as an approach - except there's no need for the
existing mechanisms to be retained.   That they're obsoleted from the
doc doesn't mean they will be yanked from implementations.   Implementations
carry around baggage from obsoleted interface all the time, there's nothing
new here.

Whether the old interfaces is obsoleted or not should depend upon whether
there's still a good reason for requiring it, after the new one is defined.
Obviously, until the new one is defined, we won't know that.

Then, when that is complete, and some of the existing interfaces are (perhaps)
obsoleted, the stack implementors will look and see how much demand there
is for them to retain the old interface - if it is used by lots of
code in the wild, then it will be retained.  If there's one, or even no,
applications using the thing, it is almost certainly simpler all around to
fix the application to use the new interface.

kre

---

From: "Avinash natarajan" <[email-masked]>
Date: Wed, 4 Jul 2001 15:09:46 +0530

hi...
    siit is required to keep a count of the number of udp checksums it generated(on receving udp ipv4 pkts with checksum zero)...
cud anybody tell it's significance??
sorry if it is elementary...
thanx..
rgds
avinash