Re: Comments on WIMP and MTU Handling

[Brian E Carpenter <brc@zurich.ibm.com>]

So, we have found a new item for
draft-lear-multi6-things-to-think-about-01

under "2.3.3 Does your solution expand the size of an IP packet?"

such as:

What impact does your solution have on MTU size issues? Can the IPv6
standard MTU of 1280 bytes be supported?

  Brian


Iljitsch van Beijnum wrote:
> 
> 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).

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM