Subject: Re: [mobile-ip] RH and path MTU discovery

From: Erik Nordmark <[email-masked]>
Date: Fri, 1 Feb 2002 12:19:35 +0100 (CET)

> How is this different from the case where a router fails on the
> original path and the route changes so that the original
> path MTU is no longer valid?

I don't understand what "this" exactly refers to.
Are you referring to the MIPv6 specific part (the fact that in a layered
implementation the IP layer adds the RH) or something else?

  Erik

> From: "Erik Nordmark" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, January 31, 2002 1:31 AM
> Subject: [mobile-ip] RH and path MTU discovery
> 
> 
> > Question for the list:
> >
> > I was thinking about "RH works for MIPv6" - have implementors
> > tested the interaction of MIPv6/RH with Path MTU discovery
> > and figured out how to make sure it works?
> >
> > The mipv6 draft doesn't say anything about this but it seems like
> > there are similar path MTU issues RH insertion by the IP stack
> > as there are with IPsec tunnel insertion by the IP stack
> > thus this is something that we presumably need to make sure is
> > well documented.
> >
> > The issues are:
> > TCP when initiating a connection needs to know which MSS to use.
> > The MSS will be different if the IP layer, e.g. based on a binding
> cache
> > entry, inserts things in the packet. This is independent whether what
> is
> > added is a RH, a HOA, or an extra IP header.
> > It seems like some advise would be useful to point out this issue.
> >
> > If a TCP connection starts out without using RH and later route
> optimization
> > has been setup (causing RH to be added by the IP layer) then a packet
> > that previously fit in the MTU will no longer fit. Thus the IP layer
> needs
> > to be able to notify the TCP layer that it is adding N bytes to the
> packets
> > so that TCP can adjust its understanding of the effective path MTU.
> >
> > Finally, during the connection there could be changes in the routing
> path
> > to the MN causing routers to send back ICMP packet too big messages.
> > Such packets would need to be recognized by TCP as effecting the MTU
> > for the connection even though the destination field in the
> > "packet in error" in the ICMP packet is the CoA instead of the HoA.
> > An explicit example:
> > TCP generates a packet with
> > src = CN
> > dst = HoA
> > (and TCP already knows that IP will add 24 bytes due to the RH so
> > it doesn't send packets that are too big)
> >
> > This causes IP to send
> > src = CN
> > dst = CoA
> > routing header with seg-left = 1, address = HoA
> >
> > If the packet is too big somewhere along the path an ICMP
> > error will be sent back with
> > src = some router
> > dst = CN
> > ICMP packet too big
> > mtu = 1300
> > packet in error
> > src = CN
> > dst = CoA
> > routing header with seg-left = 1, address = HoA
> >
> > The actual processing of this can be split between IP and TCP but
> > the effect must be the same as TCP having received a too big
> > packet reporting a smaller MTU and where the dst was the HoA i.e.
> > src = some router
> > dst = CN
> > ICMP packet too big
> > mtu = 1276  <=== NOTE
> > packet in error
> > src = CN
> > dst = HoA   <=== NOTE
> >
> > One possible way to implement this is to have the IP layer convert
> > the ICMP error before passing it to TCP. Another possible way
> > would be to have TCP be able to adjust the reported MTU
> > and extract the destination address from the RH.
> >
> >
> > Do implementations already solve this? Has it been widely tested?
> >
> > RFC 2473 describes the solution to this in the more general case of
> > IP-in-IPv6 tunneling, thus that might be useful as background reading.
> >
> >   Erik
> >
> >
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 1 Feb 2002 09:09:32 -0800

Erik,

"This" is the problem you laid out in your original message, namely
RH insertion resulting in the known path MTU becoming invalid.

But I see that others have made the point that was I think bothering
me, namely that having the path MTU become invalid is something
that could potentially occur for other reasons, and so a sufficiently
robust IPv6 stack would have to be prepared for it.

            jak