Date: Tue, 3 Jul 2001 12:20:06 -0700 (PDT)
From: Tim Hartrick <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
