Subject: Routing Header scenario ......

From: Lori Napoli <[email-masked]>
Date: Fri, 23 Apr 2004 11:02:16 -0400

Thanks for the feedback on my routing header questions.  I think it would 
be meaningful to include an example of what I was referring to in my 
original question..

Original source         A
 First hop              B
 2nd hop                C
 3rd hop                D
 Final Dest             E
 
* A sends packet out with a routing header so the source = A, dest = B 
when the packet goes outbound.
* B processes routing header and changes dest = C and forwards the packet.
* C processes routing header and changes dest = D.  When he attempts to 
forward packet he can't due to fragmentation.  So C generates ICMPv6 msg 
to send back to A.  The inner header has source = A and dest = D.
* When A gets this ICMPv6 msg it updates it MTU to get to D.
 
So, the packet A originally sent never makes it to E.  What will make A 
realize the MTU needs to be adjusted for this send and that a Packet too 
Big msg received for destination D is relevant?

Here are some options:

* This could be done having the sending side look at the MTU values to ALL 
of the entries in the routing header but I would contend that this is very 
expensive since all the lookups would need to be done on each send since 
any MTU value could change, and a routing header supports 127 entries.

* This could be done by always using 1280 MTU when sending a packet that 
contains a routing header but since the RFC states that you can have 127 
entries in the routing header that would be inconsistent since then the 
routing header would exceed 1280 bytes and it is unfragmentable.

* This could be done by having the node receiving the IMCPv6 msg 
reconstruct the original inner header but this is impossible since the 
routing header can exceed 1280 bytes and an ICMPv6 msg can only be a max 
of 1280 bytes.  Therefore you are not guaranteed to have the entire 
routing header in the imbedded packet.

* This could be done by having the node that generates the ICMPv6 msg 
encode the original destination address so when the ICMPv6 msg is received 
by the originator it can determine who the original destination of the 
packet was.  This would have to be agreed upon and standardized so all 
implementations follow the same rules.

Any other thoughts/opinions on what should be done for this scenario? What 
do other implementations do?

Thanks
Lori

E-mail: [email-masked]