Re: [rrg] GLI-Split PMTUD

[Robin Whittle <[e-mail]>]

Short version:  I think GLI-gateways need to watch for PTB messages
                leaving the network and modify those which were
                generated by packets with the AB extension header.


Here are another question about (2009-12-22 version):

http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf

regarding Path MTU Discovery.

I will write in a separate message why I think GLI-Split is a
Core-Edge Elimination architecture.

Address-rewriting architectures such as GLI-Split and Six/One Router
have a significant advantage over those Core-Edge Separation
architectures which use encapsulation, which they all do except for
Ivip with upgrades to all DFZ routers.  Encapsulation leads to some
difficult Path MTU Discovery problems - which can in general be
solved at the expense of more complexity in the ITRs and ETRs, and in
the use of extra packets between them and to the Sending Host (SH) to
manage the difficulties.

On page 21:

   ... GLI-Split does not suffer from potential problems due to
   increased packet sizes after encapsulation ...

However, the GLI-gateways and the GLI-stacks sometimes add or remove
an "Address Buffer" (AB) extension header.  It is not clear how long
this would be, but I guess 4 bytes for flags and 16 for the address
it contains = 20 bytes.

Figure 5 shows GLI-gateway N adding an AB to the right-moving packet
and removing one from the left-moving packet.

For the right-moving packet, if the packet runs into an MTU limit
between the N GLI-gateway and the Destination Host (DH) with Identity
3, then the PTB (Packet Too Big) message will go back to the Sending
Host (SH), which is an ordinary IPv6 host.  The SH will not recognise
this PTB, since it contains the initial 500 or more bytes of the
left-going packet after the extension header was added.

As far as I know, the only solution for this would be for the one or
more GLI-gateways in the GLI-domain to look out for all PTBs leaving
the network and modify them, firstly to remove the AB extension
header and secondly to alter the MTU value accordingly so the SH gets
a value it can use, to create a packet which once extended by 20
bytes or so, will fit through the MTU limiting router.

Monitoring and potentially modifying outgoing PTBs would be a
considerable extra burden on GLI-gateways.

For the left-moving packet, if a PTB was generated within the
GLI-domain, then it would go straight back to the SH (on the right)
and the GLI-updated stack there would recognise it and calculate an
appropriately shorter MTU value to send to the rest of the stack, to
account for the extra AB extension header it will add to outgoing
packets addressed to the same IP address.

If the left-moving packet hits an MTU problem somewhere outside the
GLI-domain, the PTB should go back through the GLI-gateway, and again
the GLI-modified stack can interpret it correctly.

  - Robin