Re: Comments on WIMP and MTU Handling

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 3-mrt-04, at 1:58, Margaret Wasserman wrote:

> If an ID/Loc layer will exist conceptually below the 
> fragmentation/reassembly function, it is problematic for it to add 
> optional bytes to the packet (such as a header or IP option that may 
> or may not be included).  There are some possibilities for dealing 
> with this:

>     - Run the ID/Loc separation between the Network and Transport 
> layers instead.

As opposed to network and link or transport and application???

Doing address agility first and then fragmentation makes implementing 
the former in a middlebox much harder, if not impossible.

>     - Reduce the MTU presented to upper layers, so that there is 
> always room for the optional header.

Also problematic. What if the MTU already is 1280 or not much larger, 
and the new MTU would be lower than 1280? But ignoring this for a 
moment, it should be just fine to have the transport learn a small MTU 
at one point in time (because a large option needs to be added) and 
then at a later time the full MTU is available because there is no need 
for an option at this time.

An alternative would be to fragment the segment coming from the 
transport layer without telling the transport layer about this, and 
then add the option to one of the fragments. This makes it necessary 
for the part of the stack doing the fragmenting to be aware of the 
multihoming solution, though.

Another way to get around this is to send the options as independent 
messages. However, since firewalls won't recognize these packets they 
may not make it to the destination host. Solution for that would be to 
add a transport layer header without any payload data so firewalls can 
see which session the packet belongs to (if any).