> The only problematic case, as far as I can see, would be ICMPv6 too
> big messages for path MTU discovery.  In this case, however, we can
> still update the MTU information gradually; we first update the MTU
> information to the intermediate destination stored in the destination
> address field of the inner IPv6 packet.  Then succeeding packets will
> go farther.  And, eventually, we can at least reach at the
> intermediate destination without seeing an ICMPv6 too big error.  Then
> the IPv6 destination address will be updated to the next intermediate
> destination (which might be the final one), and we can still reach
> there by the similar steps.


Thanks for your reply however I still think there is an issue with Path MTU.   If I send a packet outbound, typically I use the MTU associated with the destination to which I am sending the packet.  In the case of routing headers this will be the first hop (call it A).  Say that works fine, but now that node (A) sends the packet to another router (call it B) (so the destination address in the IP header has changed).    When this node tries to send the packet it out would need to fragment it so it generates an ICMPv6 msg back to the originator.   The inner IP header has the original source and some intermediate destination address (node B would have changed the destination address in the IP header when it processed the routing header before it realized it needed to fragment the packet so the destination address now would be C).  So when the originating host receives this it will adjust it's MTU to get to this intermediate node (node C).  But I don't think we will look at this information unless we are sending a packet to this node (node C) -- and in the case of routing headers we aren't - we're sending to some other node (in this case node A).

Lori
E-mail: [EMAIL PROTECTED]


Reply via email to