[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on WIMP and MTU Handling
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
- Run the ID/Loc separation between the Network and Transport
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).