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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 5 Feb 2002 11:14:55 +0100

James, 

Don't kow if this was already answered, but 
I'll answer it anyway. 
Erik is making a very valid point about whether
the draft addresses how a CN receiving an 
ICMP error (packet too large) for a packet
containing the routing header. The draft is 
silent on this issue.
I've been to only one interop test when
I was working on our MIPv6 implementation
and we never had a test case for this.
Furthermore, I never saw a test case for 
this in the current test suites. 

I think the draft must explain the behaviour
of the implementation when this happens.

Hesham

  > -----Original Message-----
  > From: James Kempf [mailto:[email-masked]]
  > Sent: Friday, February 01, 2002 6:10 PM
  > To: Erik Nordmark
  > Cc: [email-masked]
  > Subject: Re: [mobile-ip] RH and path MTU discovery
  > 
  > 
  > 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
  > 
  > ----- Original Message -----
  > From: "Erik Nordmark" <[email-masked]>
  > To: <[email-masked]>
  > Cc: <[email-masked]>
  > Sent: Friday, February 01, 2002 3:19 AM
  > Subject: Re: [mobile-ip] RH and path MTU discovery
  > 
  > 
  > >
  > > > 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: "Jari T. Malinen" <[email-masked]>
Date: Tue, 05 Feb 2002 11:53:21 -0800

As Francis has pointed out this is a IPv6 generic
issue. This calls more for text to a rev of 2463 than to
be put into the already large MIPv6. As of testing,
it has not been in MIPv6 conformance test cases to my
understanding for the above reasons, its place is
rather in the PMTU discovery tests, not usually
considered part of MIPv6 tests. There could be an
implementation note on how to pass (or rather compensate
for) transparently added stuff when passing the packet
too big to the application layer. This is implementation
internal behavior that shouldn't affect protocol behavior.
A robust IPv6 stack should internally do this correctly.

BR,

-Jari