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 _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg