Subject: Re: (mobile-ip) Minimal Encap. and Fragmentation

From: Dave Johnson <[email-masked]>
Date: Sat, 07 Feb 1998 14:52:59 -0500

>In message <[email-masked]>,
>    John Williams <[email-masked]> writes:
>
>> Thus, in my opinion, the use of the minenc in conjunction to
>> datagram fragments should be defined as operating system (or
>> implementation) dependent.

In message <[email-masked]>,
Jim Solomon <[email-masked]> writes:

>When minimally encapsulating, the entry-point has no way to preserve
>the fragmentation information associated with the original (inner)
>packet in order for the exit-point to restore that information upon
>decapsulating -- it is lost forever.  Therefore, minenc only works
>when the original packet has *no* fragmentation information; i.e.,
>when the original packet is not a fragment.  Thus, minenc MUST NOT be
>used if the original packet is a fragment.

Another way to look at the problem is that minenc *could* be defined
to leave the fragmentation fields in the IP header alone when
encapsulating (rather than resetting them, as Jim implies), but
in that case, the receiver would not know to decapsulate *before*
trying to reassemble the fragments, since this would not follow the
normal order of IP processing on receipt of a packet.  Even if this
could be overcome (by making the receiver treat such packets as some
kind of special case), if the packet is further fragmented in 
transit, after minenc is applied to it but before reaching the final
destination where reassembly should take place, the eventual reassembly
at the final receiver would get horribly confused.

In either case (resetting the fragmentation fields in the header when
applying minenc, or leaving the fragmentation fields unchanged when
applying minenc), the reassembly doesn't work right.  However, this
doesn't mean that minenc can't be used when fragmentation is
*possible* for some destination.  In our implementation, for example,
if minenc is supported by the receiver, then each packet tunneled uses
either IP-in-IP or minenc, depending on whether the packet being
tunneled is a fragment or a whole IP packet.  The choice between the
two encapsulation protocols is made on a packet-by-packet bases.

					Dave

-----------------------------------------------------------------------------
IETF Mobile IP Working Group Mailing List - Archives:  software.watson.ibm.com
Unsubscribe:	unsubscribe mobile-ip		(as message body, not subject)
Direct all administrative requests to [email-masked]

---

From: John Williams <[email-masked]>
Date: Mon, 09 Feb 1998 09:11:04 +0200

> ... but
> normal order of IP processing on receipt of a packet ...

This is why I have to perform fragment *assembly* at the agents.It is
actually assembly rather than "minimal assembly operations" as I wrote
first !
Then, the required encapsulation/decapsulation operations are performed
on the full datagram, and finally the resulting datagram is indicated to
the NT's native TCP/IP driver which, miraculously, do not get anger due
to the unusual large packet, and just fragments and forwards it into the
tunnel (HA), or toward the MN (FA).
Now, concerning the FA, the packets should be trapped once again on
their way "downward", because the IP normal routing will make the
packets to be physically addressed to the default gateway, rather than
to the MN.

John.